TOC 
Internet Engineering Task ForceD. Kuptsov
Internet-DraftA. Gurtov
Intended status: InformationalHelsinki Institute for Information
Expires: September 7, 2009Technology
 J. Bi
 Tsinghua Univeristy
 March 06, 2009


SAVAH: Source address validation architecture with Host Identity Protocol
draft-kuptsov-sava-hip-01

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 7, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document describes an architecture for the source address validation with help of Host Identity Protocol (HIP), SAVAH. The architecture utilizes the properties of cryptographically strong protocol to authenticate an originator of a network communication. In addition this architecture offers network access control, data protection, host mobilty and multihoming features and is suitable for the wireless networks. The proposed, architecture is the first-hop router solution, meaning that it should be deployed on the router placed on the edge of a local network topology.



Table of Contents

1.  Introduction
2.  SAVAH protocol overview
    2.1.  SAVAH router discovery and registration
    2.2.  Source address validation
    2.3.  SAVAH tunneling mode
3.  Packet format
4.  Security Considerations
5.  Credits
6.  Normative References
§  Authors' Addresses




 TOC 

1.  Introduction

This document specifies an extension to Host Identity Protocol (HIP) RFC 4423 (Moskowitz, R. and P. Nikander, “Host Identity Protocol (HIP) Architecture,” May 2006.) [RFC4423] and its component (i.e. HIP firewall) to perform per packet source address validation and authentication. The extension provides means to authenticate the traffic using properties of cryptographic algorithms. It is assumed that this approach is to be implemented on the edge, or first-hop, router of the local network. The approach in this document should be easily integrated with Source Address Validation Architecture (SAVA) specified in RFC5210 (Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, “A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience,” June 2008.) [RFC5210] and provide an alternative for a CGA based Source Address Authorization and Authentication (CSA) Mechanism (Bi, J., Wu, J., and G. Yao, “A CGA based Source Address Authorization and Authentication (CSA) Mechanism for First IPv6 Layer-3 Hop,” July 2008.) [I‑D.bi‑savi‑csa].

This document assumes that the solution is tailored to validate the source addresses only of the nodes that belong to the same network. Traffic generated from the hosts from outside network is not checked, validated or authenticated, meaning that some other solutions are needed to be used to achieve this goal.

To authenticate the traffic using HIP the following approaches can be used:



 TOC 

2.  SAVAH protocol overview

This section describes the SAVAH extension. It illustrates and explains the signaling and data packets, as well as it discusses the source address validation mechanism.


   Client               DHCP    Router                          Peer
      |  Request network  |        |                              |
      |   configuration   |        |                              |
      |------------------>|        |                              |
      |  Offer netwoork   |        |                              |
      |   configuration   |        |                              |
      |<------------------|        |                              |
+-----|                   |        |                              |
|Get  |                   |        |                              |
|gate |                   |        |                              |
|way  |                   |        |--------+                     |
+---->|            I1     |        | Check  |                     |
      |--------------------------->|  HIT   |                     |
      |                   |        | in ACL |                     |
      |                   |        |<-------+                     |
      |       R1 (REG_INFO)        |                              |
      |<---------------------------|                              |
      |                   |        |                              |
      |                   |        |--------+                     |
      |     I2 (REG_REQUEST)       | Check  |                     |
      |--------------------------->|  HIT   |                     |
      |                   |        | in ACL |                     |
      |                   |        |<-------+                     |
      |     R2 (REG_RESPONSE)      |                              |
      |<---------------------------|                              |
      |                   |        |                              |
      |                   |        |--------+                     |
      |     Plain IP(SAVAH opt)    | Check  |                     |
      |--------------------------->| source |                     |
      |                   |        |   IP   |                     |
      |                   |        |<-------+                     |
      |                   |        |    Plain IP (no SAVAH opt)   |
      |                   |        |----------------------------->|
      |                   |        |                              |
      |                   |        |                              |
      |                   |        |    Plain IP (no SAVAH opt)   |
      |<----------------------------------------------------------|
      |                   |        |                              |
      |                   |        |                              |

 Figure 1 

SAVAH is targeted to solve the source address validation problem in the edge router of the local network, serving as a default gateway. Because of that, SAVAH architecture is composed of two main components:

DHCP server can be considered a third component in our architecture. Its main role in the network is to offer particular configuration for SAVAH aware hosts. For instance, DHCP can provide the default gateway IP address as well as HIT of the SAVAH router. Availability and proper configuration of DHCP server can help to solve the problem of opportunistic mode that is being discussed later in this section. However, we consider DHCP as an optional component in the network topology. SAVAH aware clients can be configured manually, meaning that the IP address and the HIT of the SAVAH router can be setup by a system administrator prior to any communication. However, manual configuration can be a tedious task in a large scale network. As a third option, if non of the advised is accessible in the local network, the SAVAH enabled client can try to discover the SAVAH router using the opportunistic mode. The message sequence diagram for SAVAH registration and further authentication process is shown in Figure 1. As discussed previously it can involve three entities in the local network to perform the source address validation: the SAVAH client, the SAVAH router and the DHCP server (optionally). The receiver on Figure 1 is playing the role of a legacy peer, i.e., it may or may not support HIP. Of course, if both communicating peers support HIP protocol the whole scenario requires only normal HIP-enabled firewall to filter the traffic based on HITs.



 TOC 

2.1.  SAVAH router discovery and registration

Successful passing of the address validation procedure on the first-hop router requires a client to register. This is completed through HIP registration extension RFC5203 (Laganier, J., Koponen, T., and L. Eggert, “Host Identity Protocol (HIP) Registration Extension,” April 2008.) [RFC5203]. Since SAVAH router is the first-hop router, it should be placed on the edge of the local network and serve as a default gateway. If the default gateway and the SAVAH router are not placed physically on the same node it becomes meaningless, because all network traffic flowing through the SAVAH-unaware router would not contain SAVAH option and would be discarded. If DHCP server does not offer a HIT of the SAVAH router during the address assignment phase, then the SAVAH client is obliged to discover the presence of the SAVAH service automatically. Otherwise, the client is aware of the HIT and the IP address of the SAVAH router and can register to the service directly. It is also possible to preconfigure the client and specify the IP address and HIT of the default gateway. Optionally, the presence of a SAVAH-unaware DHCP means that the client will obtain only the IP address of the default gateway. No prior knowledge of the SAVAH router's HIT forces the client to discover the service using the HIP opportunistic mode (Lindqvist, J., “Establishing Host Identity Protocol Opportunistic Mode with TCP Option,” March 2006.) [I‑D.lindqvist‑hip‑opportunistic] and a set of standardized procedures for HIP service registration as described in RFC5203 (Laganier, J., Koponen, T., and L. Eggert, “Host Identity Protocol (HIP) Registration Extension,” April 2008.) [RFC5203].The drawback of such broadcasting is that in the opportunistic mode the client is unaware of the HIT of SAVAH router and any node can thus pretend to be a valid router. This reminds a similar problem with SSH, when connecting to an unknown hosts. Hence, the opportunistic mode should be used only in a trusted environment. To trigger a registration in opportunistic mode, the SAVAH client requests from the system the default gateway IP address and sends an I1 packet with the destination HIT as a hashed source IP address. On the other side, the default gateway running SAVAH in a server mode responds with an R1 packet containing an offer for available services in REG_INFO parameter. Upon receiving the R1 packet the client chooses the supported services and responds with an I2 packet containing a REG_REQUEST parameter to SAVAH server. If REG INFO parameter does not contain the SAVAH service offer, the client completes base exchange normally and afterward falls to a normal communication, i.e. SAVAH mode is not supported in this network. Finally, depending on the setup of the SAVAH router, it either grants or denies the service to client in a R2 packet in a REG_RESPONSE or REG_FAILED parameter correspondingly. Receiving REG_FAILED parameter in an R2 message during the base exchange or experiencing a timeout in a I1 state means that either the default gateway does not support SAVAH extension or that HIP daemon with SAVAH extension is not running at all. This situation should indicate to the SAVAH client to fallback to a normal communication, i.e., the packets that would be forwarded through the default gateway will not contain any authentic information. As an opposite result, if the SAVAH router grants the service to the registering client, both parties will posses a shared secret key.



 TOC 

2.2.  Source address validation

For performance issues, the keys that are used for authentication (i.e., HMAC keys) in IPSec were selected to authenticate the source addresses. Depending on a setup, symmetric cryptography can be selected as well. Filtering based on HITs can be done to ensure that the peer trying to register to the SAVAH service is legitimate. This filtering can enforce to either grant or deny the SAVAH service to the registrars. The grounds for such a decision can be rules specified in the HIP-enabled firewall. By default, all packets with unknown identifier are dropped. After completion of the HIP base exchange, the SAVAH router adds the source IP address of the host to a database. This works if no record with such IP address already present in the database. If a record with such IP address already exists, it is likely that the host is trying to spoof someone else address and the packet should be dropped nor state is added. Moreover this incident can be logged and reported for further analysis. If the host experiences an address change, then the record is replaced with a new IP address. To ensure the validity of the host, HIP UPDATE packet has to be received and handled properly. This will guarantee that the host indeed who it is claiming to be. The record should be removed from the database upon a timeout or when the host removes a security association (e.g., HIP CLOSE packet is received from the corresponding host). To ensure that the client is alive, SAVAH router can also send heartbeats to the client, without waiting for the timeout. After the secret keys were established by means of the HIP base exchange, the SAVAH client may communicate with the nodes outside of the local network by including an authenticated source IP address in each packet. Current implementation has two options to deliver the authenticated hash value to the router. First approach is to replace the original source IP address of each packet with truncated result obtained from HMAC(key | {P}) operation, where {P} is the packet to be transmitted. We have chosen the packet value as a feed to HMAC function to introduce simple protect mechanism from replay attacks. This approach has some drawbacks. First of all, for IPv4 networks the size of authentication value will be only 32 bits. Secondly, that would decrease the performance since additional address translation would be required on the router. Finally, that method will require additional changes to the router to recognize locally routed traffic. A different way to carry the authenticated source IP address to SAVAH router is to store it in an IP option. Since the SAVAH router is the first-hop router and all SAVAH related options are striped out on the forward direction, this ensures that no modifications are required for other routers on the path. Placing the authentication value in the IP option can have certain advantages. First of all, this approach slightly optimizes the performance of the architecture. Secondly, stronger security can be achieved by increasing the length of the authentication value. We suggest to keep this length within wise bounds, since it affects the size of the actual payload. To authenticate the packet source address, the following algorithm is used. On the router side, each packet in forward direction is searched for the SAVAH IP option. If found, the router compares the value of the option against truncated 128-bit result from HMAC(key | {P}) operation, where {P} is the packet to be forwarded. If matches, the SAVAH option is striped out and the packet is re-injected to the network. If not, the pinhole is searched for a given source and destination IP addresses. If the pinhole is found, the packet is said to be an inbound packet for previously authenticated outbound communication. Finally, if both are failed the packet is dropped. If the tunneling approach is used, then the authentication succeeds if the SAVAH router can successfully decrypt the ESP packet and resend encapsulated in ESP original packet to its final destination. Unlike the lightweight approach for inbound traffic, the SAVAH router in a tunnel mode should properly encrypt and tunnel the packet to the corresponding mobile node.



 TOC 

2.3.  SAVAH tunneling mode

This section describes how SAVAH operates in tunneling mode. The major difference from the lightweight SAVHA mode (SAVAH protocol overview section (SAVAH protocol overview)) is that all traffic leaving the local host is encapsulated in ESP packets and forwarded to SAVAH router.


   Client               DHCP    Router                          Peer
      |  Request network  |          |                              |
      |   configuration   |          |                              |
      |------------------>|          |                              |
      |  Offer netwoork   |          |                              |
      |   configuration   |          |                              |
      |<------------------|          |                              |
+-----|                   |          |                              |
|Get  |                   |          |                              |
|gate |                   |          |                              |
|way  |                   |          |---------+                    |
+---->|            I1     |          |  Check  |                    |
      |----------------------------->|  HIT    |                    |
      |                   |          | in ACL  |                    |
      |                   |          |<--------+                    |
      |       R1 (REG_INFO)          |                              |
      |<-----------------------------|                              |
      |                   |          |                              |
      |                   |          |--------+                     |
      |     I2 (REG_REQUEST)         | Check  |                     |
      |----------------------------->|  HIT   |                     |
      |                   |          | in ACL |                     |
      |                   |          |<-------+                     |
      |     R2 (REG_RESPONSE)        |                              |
      |<-----------------------------|                              |
      |                   |          |                              |
      |                   |          |--------+                     |
      | ESP tunneld IP traffic       | Check  |                     |
      |----------------------------->| source |                     |
      |                   |          |   IP   |                     |
      |                   |          | Decrypt|                     |
      |                   |          |   ESP  |                     |
      |                   |          |<-------+                     |
      |                   |          |                              |
      |                   |          |                              |
      |                   |          |    Plain IP (non encypted)   |
      |                   |          |----------------------------->|
      |                   |          |                              |
      |                   |          |                              |
      |                   |          |    Plain IP (non encrypted)  |
      |                   |          |<-----------------------------|
      |                   |          |                              |
      |                   | +--------+                              |
      |                   | |Check   |                              |
      |                   | |pinhole |                              |
      |                   | |Encrypt |                              |
      |                   | |traffic |                              |
      |                   | +------->|                              |
      |                   |          |                              |
      |    ESP tunneled IP traffic   |                              |
      |<-----------------------------|                              |
      |                   |          |                              |

 Figure 2 

The registration and source address validation mechanisms are the same as in lightweight SAVAH mode.

Once the encrypted packet arrives on the SAVAH router it decrypts the packet validates the source IP address and forwards the encapsulated original packet to the destination host.

Upon the arrival of the packet from the Internet on the SAVAH router, its task to check if the pinhole exists. If there was previous communication the SAVAH router encrypts the packet (in similar way it is done on the SAVAH client) and forwards ESP encapsulated packet to the corresponding SAVAH client.



 TOC 

3.  Packet format

This section describes the format of the IP options that are used to carry authentication data.

For IPv4 protocol the format of SAVAH option is as follows:


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option type |  Option Len   |                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                 +
|                                                               |
+                                                               +
|                   Encrypted source IP address                 |
+                                                               +
|                                                               |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |          Padding              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 3 

For IPv6 protocol the format of SAVAH option is as follows:


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |  Option type  |  Option Len   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                   Encrypted source IP address                 |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Padding Type | Padding Len   |          Padding              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 4 

IPv4/IPv6 packet structure for SAVAH in tunnel mode:



         BEFORE APPLYING ESP
-----------------------------
| Outer IP hdr |  Payload   |
|              |            |
-----------------------------

 Figure 5 



        AFTER APPLYING ESP
------------------------------------------------------------------
| SAVAH IP hdr    |     |              |         |  ESP    | ESP |
| (any options)   | ESP | Outer IP Hdr | Payload | Trailer | ICV |
------------------------------------------------------------------
                        |<----- encryption ----->|
                  |<--------- integrity -------->|

 Figure 6 



 TOC 

4.  Security Considerations

Using opportunistic mode in HIP should be considered as a security risk in untrusted environment, due to the fact that the router's HIT is not known before the registration. This gives a possibility to an attacker to hijack the HIP I1 packet and pretend to be a SAVAH router by sending the R1 packet to the client.

Using tunneling approach a single SAVAH router may become a single point of failure as well as a bottleneck in the network communication. For that reason it is recommended to use load balancing between multiple SAVAH router and forward the traffic from the client to the Internet through several (depending on the network size) SAVAH routers.



 TOC 

5.  Credits

The following people have provided thoughtful and helpful discussions and/or suggestions that have helped to improve this document:



 TOC 

6. Normative References

[I-D.bi-savi-csa] Bi, J., Wu, J., and G. Yao, “A CGA based Source Address Authorization and Authentication (CSA) Mechanism for First IPv6 Layer-3 Hop,” draft-bi-savi-csa-00 (work in progress), July 2008 (TXT).
[I-D.lindqvist-hip-opportunistic] Lindqvist, J., “Establishing Host Identity Protocol Opportunistic Mode with TCP Option,” draft-lindqvist-hip-opportunistic-01 (work in progress), March 2006 (TXT).
[RFC0791] Postel, J., “Internet Protocol,” STD 5, RFC 791, September 1981 (TXT).
[RFC2460] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1998 (TXT, HTML, XML).
[RFC4423] Moskowitz, R. and P. Nikander, “Host Identity Protocol (HIP) Architecture,” RFC 4423, May 2006 (TXT).
[RFC4727] Fenner, B., “Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers,” RFC 4727, November 2006 (TXT).
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, “Host Identity Protocol (HIP) Registration Extension,” RFC 5203, April 2008 (TXT).
[RFC5210] Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, “A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience,” RFC 5210, June 2008 (TXT).


 TOC 

Authors' Addresses

  Dmitriy Kuptsov
  Helsinki Institute for Information Technology
  PO. Box 9800
  TKK FI-02015
  Finland
Phone:  +358 50 301 2613
Email:  dmitriy.kuptsov@hiit.fi
  
  Andrei Gurtov
  Helsinki Institute for Information Technology
  PO. Box 9800
  TKK FI-02015
  Finland
Phone: 
Email:  gurtov@hiit.fi
  
  Jun Bi
  Tsinghua Univeristy
  Beijing,
  China
Phone: 
Email: