--- 1/draft-ietf-hip-rfc5206-bis-01.txt 2011-03-15 01:14:31.000000000 +0100 +++ 2/draft-ietf-hip-rfc5206-bis-02.txt 2011-03-15 01:14:31.000000000 +0100 @@ -1,22 +1,22 @@ Network Working Group P. Nikander Internet-Draft Ericsson Research NomadicLab Obsoletes: 5206 (if approved) T. Henderson, Ed. Intended status: Standards Track The Boeing Company -Expires: April 21, 2011 C. Vogt +Expires: September 15, 2011 C. Vogt J. Arkko Ericsson Research NomadicLab - October 18, 2010 + March 14, 2011 Host Mobility with the Host Identity Protocol - draft-ietf-hip-rfc5206-bis-01 + draft-ietf-hip-rfc5206-bis-02 Abstract This document defines mobility extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same @@ -31,25 +31,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on April 21, 2011. + This Internet-Draft will expire on September 15, 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -68,69 +68,70 @@ than English. Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Operating Environment . . . . . . . . . . . . . . . . . . 6 3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 8 - 3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 + 3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . . 9 3.2.2. Mobility with a Single SA Pair (Mobile-Initiated Rekey) . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Using LOCATORs across Addressing Realms . . . . . . . 11 - 3.2.4. Network Renumbering . . . . . . . . . . . . . . . . . 11 + 3.2.4. Network Renumbering . . . . . . . . . . . . . . . . . 12 3.3. Other Considerations . . . . . . . . . . . . . . . . . . . 12 3.3.1. Address Verification . . . . . . . . . . . . . . . . . 12 3.3.2. Credit-Based Authorization . . . . . . . . . . . . . . 12 - 3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 13 + 3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 14 4. LOCATOR Parameter Format . . . . . . . . . . . . . . . . . . . 14 - 4.1. Traffic Type and Preferred Locator . . . . . . . . . . . . 15 + 4.1. Traffic Type and Preferred Locator . . . . . . . . . . . . 16 4.2. Locator Type and Locator . . . . . . . . . . . . . . . . . 16 - 4.3. UPDATE Packet with Included LOCATOR . . . . . . . . . . . 16 - 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 16 - 5.1. Locator Data Structure and Status . . . . . . . . . . . . 16 + 4.3. UPDATE Packet with Included LOCATOR . . . . . . . . . . . 17 + 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.1. Locator Data Structure and Status . . . . . . . . . . . . 17 5.2. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 18 - 5.3. Handling Received LOCATORs . . . . . . . . . . . . . . . . 19 - 5.4. Verifying Address Reachability . . . . . . . . . . . . . . 21 - 5.5. Changing the Preferred Locator . . . . . . . . . . . . . . 22 - 5.6. Credit-Based Authorization . . . . . . . . . . . . . . . . 23 - 5.6.1. Handling Payload Packets . . . . . . . . . . . . . . . 23 - 5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . . 25 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 - 6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 27 - 6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 28 - 6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . . 28 - 6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 28 - 6.3. Mixed Deployment Environment . . . . . . . . . . . . . . . 29 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 - 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 30 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 9.1. Normative references . . . . . . . . . . . . . . . . . . . 30 - 9.2. Informative references . . . . . . . . . . . . . . . . . . 30 - Appendix A. Document Revision History . . . . . . . . . . . . . . 31 + 5.3. Handling Received LOCATORs . . . . . . . . . . . . . . . . 20 + 5.4. Verifying Address Reachability . . . . . . . . . . . . . . 22 + 5.5. Changing the Preferred Locator . . . . . . . . . . . . . . 23 + 5.6. Credit-Based Authorization . . . . . . . . . . . . . . . . 24 + 5.6.1. Handling Payload Packets . . . . . . . . . . . . . . . 24 + 5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . . 26 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 28 + 6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 29 + 6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . . 29 + 6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 29 + 6.3. Mixed Deployment Environment . . . . . . . . . . . . . . . 30 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 + 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 31 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 9.1. Normative references . . . . . . . . . . . . . . . . . . . 31 + 9.2. Informative references . . . . . . . . . . . . . . . . . . 32 + Appendix A. Document Revision History . . . . . . . . . . . . . . 32 1. Introduction and Scope - The Host Identity Protocol [RFC4423] (HIP) supports an architecture - that decouples the transport layer (TCP, UDP, etc.) from the - internetworking layer (IPv4 and IPv6) by using public/private key - pairs, instead of IP addresses, as host identities. When a host uses - HIP, the overlying protocol sublayers (e.g., transport layer sockets - and Encapsulating Security Payload (ESP) Security Associations (SAs)) - are instead bound to representations of these host identities, and - the IP addresses are only used for packet forwarding. However, each - host must also know at least one IP address at which its peers are - reachable. Initially, these IP addresses are the ones used during - the HIP base exchange [RFC5201]. + The Host Identity Protocol [I-D.ietf-hip-rfc4423-bis] (HIP) supports + an architecture that decouples the transport layer (TCP, UDP, etc.) + from the internetworking layer (IPv4 and IPv6) by using public/ + private key pairs, instead of IP addresses, as host identities. When + a host uses HIP, the overlying protocol sublayers (e.g., transport + layer sockets and Encapsulating Security Payload (ESP) Security + Associations (SAs)) are instead bound to representations of these + host identities, and the IP addresses are only used for packet + forwarding. However, each host must also know at least one IP + address at which its peers are reachable. Initially, these IP + addresses are the ones used during the HIP base exchange + [I-D.ietf-hip-rfc5201-bis]. One consequence of such a decoupling is that new solutions to network-layer mobility and host multihoming are possible. There are potentially many variations of mobility and multihoming possible. The scope of this document encompasses messaging and elements of procedure for basic network-level host mobility, leaving more complicated scenarios and other variations for further study. More specifically: This document defines a generalized LOCATOR parameter for use in @@ -147,31 +148,32 @@ change in the preferred IP address used to reach a host. In particular, message flows to enable successful host mobility, including address verification methods, are defined herein. However, while the same LOCATOR parameter is intended to support host multihoming (parallel support of a number of addresses), and experimentation is encouraged, detailed elements of procedure for host multihoming are out of scope. While HIP can potentially be used with transports other than the ESP - transport format [RFC5202], this document largely assumes the use of - ESP and leaves other transport formats for further study. + transport format [I-D.ietf-hip-rfc5202-bis], this document largely + assumes the use of ESP and leaves other transport formats for further + study. There are a number of situations where the simple end-to-end readdressing functionality is not sufficient. These include the initial reachability of a mobile host, location privacy, simultaneous mobility of both hosts, and some modes of NAT traversal. In these situations, there is a need for some helper functionality in the - network, such as a HIP rendezvous server [RFC5204]. Such - functionality is out of the scope of this document. We also do not - consider localized mobility management extensions (i.e., mobility + network, such as a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis]. + Such functionality is out of the scope of this document. We also do + not consider localized mobility management extensions (i.e., mobility management techniques that do not involve directly signaling the correspondent node); this document is concerned with end-to-end mobility. Making underlying IP mobility transparent to the transport layer has implications on the proper response of transport congestion control, path MTU selection, and Quality of Service (QoS). Transport-layer mobility triggers, and the proper transport response to a HIP mobility or multihoming address change, are outside the scope of this document. 2. Terminology and Conventions @@ -207,25 +209,26 @@ authorizes the peer to receive a certain amount of data at the new locator before the result of such verification is known. 3. Protocol Model This section is an overview; more detailed specification follows this section. 3.1. Operating Environment - The Host Identity Protocol (HIP) [RFC5201] is a key establishment and - parameter negotiation protocol. Its primary applications are for - authenticating host messages based on host identities, and - establishing security associations (SAs) for the ESP transport format - [RFC5202] and possibly other protocols in the future. + The Host Identity Protocol (HIP) [I-D.ietf-hip-rfc5201-bis] is a key + establishment and parameter negotiation protocol. Its primary + applications are for authenticating host messages based on host + identities, and establishing security associations (SAs) for the ESP + transport format [I-D.ietf-hip-rfc5202-bis] and possibly other + protocols in the future. +--------------------+ +--------------------+ | | | | | +------------+ | | +------------+ | | | Key | | HIP | | Key | | | | Management | <-+-----------------------+-> | Management | | | | Process | | | | Process | | | +------------+ | | +------------+ | | ^ | | ^ | | | | | | | @@ -274,30 +278,31 @@ Figure 2 depicts a layered architectural view of a HIP-enabled stack using the ESP transport format. In HIP, upper-layer protocols (including TCP and ESP in this figure) are bound to Host Identity Tags (HITs) and not IP addresses. The HIP sublayer is responsible for maintaining the binding between HITs and IP addresses. The SPI is used to associate an incoming packet with the right HITs. The block labeled "MH" is introduced below. Consider first the case in which there is no mobility or multihoming, - as specified in the base protocol specification [RFC5201]. The HIP - base exchange establishes the HITs in use between the hosts, the SPIs - to use for ESP, and the IP addresses (used in both the HIP signaling - packets and ESP data packets). Note that there can only be one such - set of bindings in the outbound direction for any given packet, and - the only fields used for the binding at the HIP layer are the fields - exposed by ESP (the SPI and HITs). For the inbound direction, the - SPI is all that is required to find the right host context. ESP - rekeying events change the mapping between the HIT pair and SPI, but - do not change the IP addresses. + as specified in the base protocol specification + [I-D.ietf-hip-rfc5201-bis]. The HIP base exchange establishes the + HITs in use between the hosts, the SPIs to use for ESP, and the IP + addresses (used in both the HIP signaling packets and ESP data + packets). Note that there can only be one such set of bindings in + the outbound direction for any given packet, and the only fields used + for the binding at the HIP layer are the fields exposed by ESP (the + SPI and HITs). For the inbound direction, the SPI is all that is + required to find the right host context. ESP rekeying events change + the mapping between the HIT pair and SPI, but do not change the IP + addresses. Consider next a mobility event, in which a host moves to another IP address. Two things must occur in this case. First, the peer must be notified of the address change using a HIP UPDATE message. Second, each host must change its local bindings at the HIP sublayer (new IP addresses). It may be that both the SPIs and IP addresses are changed simultaneously in a single UPDATE; the protocol described herein supports this. However, simultaneous movement of both hosts, notification of transport layer protocols of the path change, and procedures for possibly traversing middleboxes are not covered by @@ -318,54 +323,56 @@ tunneling scenarios. Locators may simply be traditional network addresses. The format of the locator fields in the LOCATOR parameter is defined in Section 4. 3.1.2. Mobility Overview When a host moves to another address, it notifies its peer of the new address by sending a HIP UPDATE packet containing a LOCATOR parameter. This UPDATE packet is acknowledged by the peer. For reliability in the presence of packet loss, the UPDATE packet is - retransmitted as defined in the HIP protocol specification [RFC5201]. - The peer can authenticate the contents of the UPDATE packet based on - the signature and keyed hash of the packet. + retransmitted as defined in the HIP protocol specification + [I-D.ietf-hip-rfc5201-bis]. The peer can authenticate the contents + of the UPDATE packet based on the signature and keyed hash of the + packet. - When using ESP Transport Format [RFC5202], the host may at the same - time decide to rekey its security association and possibly generate a - new Diffie-Hellman key; all of these actions are triggered by - including additional parameters in the UPDATE packet, as defined in - the base protocol specification [RFC5201] and ESP extension - [RFC5202]. + When using ESP Transport Format [I-D.ietf-hip-rfc5202-bis], the host + may at the same time decide to rekey its security association and + possibly generate a new Diffie-Hellman key; all of these actions are + triggered by including additional parameters in the UPDATE packet, as + defined in the base protocol specification [I-D.ietf-hip-rfc5201-bis] + and ESP extension [I-D.ietf-hip-rfc5202-bis]. When using ESP (and possibly other transport modes in the future), the host is able to receive packets that are protected using a HIP created ESP SA from any address. Thus, a host can change its IP address and continue to send packets to its peers without necessarily rekeying. However, the peers are not able to send packets to these new addresses before they can reliably and securely update the set of addresses that they associate with the sending host. Furthermore, mobility may change the path characteristics in such a manner that reordering occurs and packets fall outside the ESP anti-replay window for the SA, thereby requiring rekeying. 3.2. Protocol Overview In this section, we briefly introduce a number of usage scenarios for HIP host mobility. These scenarios assume that HIP is being used - with the ESP transform [RFC5202], although other scenarios may be - defined in the future. To understand these usage scenarios, the - reader should be at least minimally familiar with the HIP protocol - specification [RFC5201]. However, for the (relatively) uninitiated - reader, it is most important to keep in mind that in HIP the actual - payload traffic is protected with ESP, and that the ESP SPI acts as - an index to the right host-to-host context. More specification - details are found later in Section 4 and Section 5. + with the ESP transform [I-D.ietf-hip-rfc5202-bis], although other + scenarios may be defined in the future. To understand these usage + scenarios, the reader should be at least minimally familiar with the + HIP protocol specification [I-D.ietf-hip-rfc5201-bis]. However, for + the (relatively) uninitiated reader, it is most important to keep in + mind that in HIP the actual payload traffic is protected with ESP, + and that the ESP SPI acts as an index to the right host-to-host + context. More specification details are found later in Section 4 and + Section 5. The scenarios below assume that the two hosts have completed a single HIP base exchange with each other. Both of the hosts therefore have one incoming and one outgoing SA. Further, each SA uses the same pair of IP addresses, which are the ones used in the base exchange. The readdressing protocol is an asymmetric protocol where a mobile host informs a peer host about changes of IP addresses on affected SPIs. The readdressing exchange is designed to be piggybacked on existing HIP exchanges. The majority of the packets on which the @@ -419,21 +426,21 @@ parameter to the peer host in an UPDATE message. The UPDATE message also contains an ESP_INFO parameter containing the values of the old and new SPIs for a security association. In this case, the OLD SPI and NEW SPI parameters both are set to the value of the preexisting incoming SPI; this ESP_INFO does not trigger a rekeying event but is instead included for possible parameter-inspecting middleboxes on the path. The LOCATOR parameter contains the new IP address (Locator Type of "1", defined below) and a locator lifetime. The mobile host waits for this UPDATE to be acknowledged, and retransmits if necessary, as - specified in the base specification [RFC5201]. + specified in the base specification [I-D.ietf-hip-rfc5201-bis]. 2. The peer host receives the UPDATE, validates it, and updates any local bindings between the HIP association and the mobile host's destination address. The peer host MUST perform an address verification by placing a nonce in the ECHO_REQUEST parameter of the UPDATE message sent back to the mobile host. It also includes an ESP_INFO parameter with the OLD SPI and NEW SPI parameters both set to the value of the preexisting incoming SPI, and sends this UPDATE (with piggybacked acknowledgment) to the mobile host at its new address. The peer MAY use the new address @@ -591,26 +598,26 @@ When a host has multiple locators, the peer host must decide which to use for outbound packets. It may be that a host would prefer to receive data on a particular inbound interface. HIP allows a particular locator to be designated as a Preferred locator and communicated to the peer (see Section 4). 4. LOCATOR Parameter Format The LOCATOR parameter is a critical parameter as defined by - [RFC5201]. It consists of the standard HIP parameter Type and Length - fields, plus zero or more Locator sub-parameters. Each Locator sub- - parameter contains a Traffic Type, Locator Type, Locator Length, - Preferred locator bit, Locator Lifetime, and a Locator encoding. A - LOCATOR containing zero Locator fields is permitted but has the - effect of deprecating all addresses. + [I-D.ietf-hip-rfc5201-bis]. It consists of the standard HIP + parameter Type and Length fields, plus zero or more Locator sub- + parameters. Each Locator sub-parameter contains a Traffic Type, + Locator Type, Locator Length, Preferred locator bit, Locator + Lifetime, and a Locator encoding. A LOCATOR containing zero Locator + fields is permitted but has the effect of deprecating all addresses. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Type | Locator Type | Locator Length | Reserved |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -829,24 +838,25 @@ are possible but are left for further experimentation. 1. Host mobility with no multihoming and no rekeying. The mobile host creates a single UPDATE containing a single ESP_INFO with a single LOCATOR parameter. The ESP_INFO contains the current value of the SPI in both the OLD SPI and NEW SPI fields. The LOCATOR contains a single Locator with a "Locator Type" of "1"; the SPI must match that of the ESP_INFO. The Preferred bit SHOULD be set and the "Locator Lifetime" is set according to local policy. The UPDATE also contains a SEQ parameter as usual. + This packet is retransmitted as defined in the HIP protocol - specification [RFC5201]. The UPDATE should be sent to the peer's - preferred IP address with an IP source address corresponding to - the address in the LOCATOR parameter. + specification [I-D.ietf-hip-rfc5201-bis]. The UPDATE should be + sent to the peer's preferred IP address with an IP source address + corresponding to the address in the LOCATOR parameter. 2. Host mobility with no multihoming but with rekeying. The mobile host creates a single UPDATE containing a single ESP_INFO with a single LOCATOR parameter (with a single address). The ESP_INFO contains the current value of the SPI in the OLD SPI and the new value of the SPI in the NEW SPI, and a KEYMAT Index as selected by local policy. Optionally, the host may choose to initiate a Diffie Hellman rekey by including a DIFFIE_HELLMAN parameter. The LOCATOR contains a single Locator with "Locator Type" of "1"; the SPI must match that of the NEW SPI in the ESP_INFO. @@ -1152,25 +1162,26 @@ the peer via a TCP connection and the end-to-end round-trip time does not exceed 500 milliseconds. Alternative credit-aging algorithms may use other parameter values or different parameters, which may even be dynamically established. 6. Security Considerations The HIP mobility mechanism provides a secure means of updating a host's IP address via HIP UPDATE packets. Upon receipt, a HIP host cryptographically verifies the sender of an UPDATE, so forging or - replaying a HIP UPDATE packet is very difficult (see [RFC5201]). - Therefore, security issues reside in other attack domains. The two - we consider are malicious redirection of legitimate connections as - well as redirection-based flooding attacks using this protocol. This - can be broken down into the following: + replaying a HIP UPDATE packet is very difficult (see + [I-D.ietf-hip-rfc5201-bis]). Therefore, security issues reside in + other attack domains. The two we consider are malicious redirection + of legitimate connections as well as redirection-based flooding + attacks using this protocol. This can be broken down into the + following: Impersonation attacks - direct conversation with the misled victim - man-in-the-middle attack DoS attacks - flooding attacks (== bandwidth-exhaustion attacks) @@ -1202,24 +1213,24 @@ the attacker tricks its victim into initiating the connection over an incorrect routing path (e.g., by acting as a router or using spoofed DNS entries). The HIP extensions defined in this specification change the situation in that they introduce an ability to redirect a connection (like IPv6), both before and after establishment. If no precautionary measures are taken, an attacker could misuse the redirection feature to impersonate a victim's peer from any arbitrary location. The authentication and authorization mechanisms of the HIP base exchange - [RFC5201] and the signatures in the UPDATE message prevent this - attack. Furthermore, ownership of a HIP association is securely - linked to a HIP HI/HIT. If an attacker somehow uses a bug in the - implementation or weakness in some protocol to redirect a HIP + [I-D.ietf-hip-rfc5201-bis] and the signatures in the UPDATE message + prevent this attack. Furthermore, ownership of a HIP association is + securely linked to a HIP HI/HIT. If an attacker somehow uses a bug + in the implementation or weakness in some protocol to redirect a HIP connection, the original owner can always reclaim their connection (they can always prove ownership of the private key associated with their public HI). MitM attacks are always possible if the attacker is present during the initial HIP base exchange and if the hosts do not authenticate each other's identities. However, once the opportunistic base exchange has taken place, even a MitM cannot steal the HIP connection anymore because it is very difficult for an attacker to create an UPDATE packet (or any HIP packet) that will be accepted as a @@ -1260,28 +1271,29 @@ amplification in the number and size of the redirected packets. As a result, the combination of a reachability check and credit-based authorization lowers a HIP redirection-based flooding attack to the level of a direct flooding attack in which the attacker itself sends the flooding traffic to the victim. 6.2.2. Memory/Computational-Exhaustion DoS Attacks We now consider whether or not the proposed extensions to HIP add any new DoS attacks (consideration of DoS attacks using the base HIP - exchange and updates is discussed in [RFC5201]). A simple attack is - to send many UPDATE packets containing many IP addresses that are not - flagged as preferred. The attacker continues to send such packets - until the number of IP addresses associated with the attacker's HI - crashes the system. Therefore, there SHOULD be a limit to the number - of IP addresses that can be associated with any HI. Other forms of - memory/computationally exhausting attacks via the HIP UPDATE packet - are handled in the base HIP document [RFC5201]. + exchange and updates is discussed in [I-D.ietf-hip-rfc5201-bis]). A + simple attack is to send many UPDATE packets containing many IP + addresses that are not flagged as preferred. The attacker continues + to send such packets until the number of IP addresses associated with + the attacker's HI crashes the system. Therefore, there SHOULD be a + limit to the number of IP addresses that can be associated with any + HI. Other forms of memory/computationally exhausting attacks via the + HIP UPDATE packet are handled in the base HIP document + [I-D.ietf-hip-rfc5201-bis]. A central server that has to deal with a large number of mobile clients may consider increasing the SA lifetimes to try to slow down the rate of rekeying UPDATEs or increasing the cookie difficulty to slow down the rate of attack-oriented connections. 6.3. Mixed Deployment Environment We now assume an environment with both HIP and non-HIP aware hosts. Four cases exist. @@ -1307,93 +1319,111 @@ 4. A HIP host attempts to steal a non-HIP host's session. A HIP host could spoof the non-HIP host's IP address during the base exchange or set the non-HIP host's IP address as its preferred address via an UPDATE. Other possibilities exist, but a simple solution is to prevent the use of HIP address check information to influence non-HIP sessions. 7. IANA Considerations This document defines a LOCATOR parameter for the Host Identity - Protocol [RFC5201]. This parameter is defined in Section 4 with a - Type of 193. + Protocol [I-D.ietf-hip-rfc5201-bis]. This parameter is defined in + Section 4 with a Type of 193. This document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message Type as defined in the Host Identity Protocol specification - [RFC5201]. This parameter is defined in Section 5.3 with a value of - 46. + + [I-D.ietf-hip-rfc5201-bis]. This parameter is defined in Section 5.3 + with a value of 46. 8. Authors and Acknowledgments Pekka Nikander and Jari Arkko originated this document, and Christian Vogt and Thomas Henderson (editor) later joined as co-authors. Greg Perkins contributed the initial draft of the security section. Petri Jokela was a co-author of the initial individual submission. The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan Melen for many improvements to the document. 9. References 9.1. Normative references - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. + [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol + Architecture", + draft-ietf-hip-rfc4423-bis-02 (work in + progress), February 2011. - [RFC3484] Draves, R., "Default Address Selection for Internet - Protocol version 6 (IPv6)", RFC 3484, February 2003. + [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and + T. Henderson, "Host Identity Protocol + Version 2 (HIPv2)", + draft-ietf-hip-rfc5201-bis-05 (work in + progress), March 2011. - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 4291, February 2006. + [I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., Nikander, P., + and J. Melen, "Using the Encapsulating + Security Payload (ESP) Transport Format + with the Host Identity Protocol (HIP)", + draft-ietf-hip-rfc5202-bis-00 (work in + progress), September 2010. - [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", - RFC 4303, December 2005. + [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host + Identity Protocol (HIP) Rendezvous + Extension", draft-ietf-hip-rfc5204-bis-01 + (work in progress), March 2011. - [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol - (HIP) Architecture", RFC 4423, May 2006. + [RFC2119] Bradner, S., "Key words for use in RFCs + to Indicate Requirement Levels", BCP 14, + RFC 2119, March 1997. - [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. - Henderson, "Host Identity Protocol", RFC 5201, - April 2008. + [RFC3484] Draves, R., "Default Address Selection + for Internet Protocol version 6 (IPv6)", + RFC 3484, February 2003. - [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the - Encapsulating Security Payload (ESP) Transport Format - with the Host Identity Protocol (HIP)", RFC 5202, - April 2008. + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 + Addressing Architecture", RFC 4291, + February 2006. - [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol - (HIP) Rendezvous Extension", RFC 5204, April 2008. + [RFC4303] Kent, S., "IP Encapsulating Security + Payload (ESP)", RFC 4303, December 2005. 9.2. Informative references - [CBA-MIPv6] Vogt, C. and J. Arkko, "Credit-Based Authorization for - Mobile IPv6 Early Binding Updates", Work in Progress, + [CBA-MIPv6] Vogt, C. and J. Arkko, "Credit-Based + Authorization for Mobile IPv6 Early + Binding Updates", Work in Progress, February 2005. - [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and - E. Nordmark, "Mobile IP Version 6 Route Optimization - Security Design Background", RFC 4225, December 2005. + [RFC4225] Nikander, P., Arkko, J., Aura, T., + Montenegro, G., and E. Nordmark, "Mobile + IP Version 6 Route Optimization Security + Design Background", RFC 4225, + December 2005. - [SIMPLE-CBA] Vogt, C. and J. Arkko, "Credit-Based Authorization for - Concurrent Reachability Verification", Work - in Progress, February 2006. + [SIMPLE-CBA] Vogt, C. and J. Arkko, "Credit-Based + Authorization for Concurrent Reachability + Verification", Work in Progress, + February 2006. Appendix A. Document Revision History To be removed upon publication - +----------+-------------------------------------------------------+ + +----------+--------------------------------------------------------+ | Revision | Comments | - +----------+-------------------------------------------------------+ + +----------+--------------------------------------------------------+ | draft-00 | Initial version from RFC5206 xml (unchanged). | | draft-01 | Remove multihoming-specific text; no other changes. | - +----------+-------------------------------------------------------+ + | draft-02 | Update references to point to -bis drafts; no other | + | | changes. | + +----------+--------------------------------------------------------+ Authors' Addresses Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 EMail: pekka.nikander@nomadiclab.com