--- 1/draft-ietf-hip-rfc5202-bis-00.txt 2012-09-27 10:14:22.221342064 +0200 +++ 2/draft-ietf-hip-rfc5202-bis-01.txt 2012-09-27 10:14:22.297342093 +0200 @@ -1,96 +1,62 @@ Network Working Group P. Jokela Internet-Draft Ericsson Research NomadicLab Intended status: Standards Track R. Moskowitz -Expires: March 27, 2011 ICSA labs - P. Nikander +Expires: March 31, 2013 ICSAlabs, An Independent + Division of Verizon Business + Systems J. Melen Ericsson Research NomadicLab - September 23, 2010 + September 27, 2012 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) - draft-ietf-hip-rfc5202-bis-00 + draft-ietf-hip-rfc5202-bis-01 Abstract This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). -IESG Note - - The following issues describe IESG concerns about this document. The - IESG expects that these issues will be addressed when future versions - of HIP are designed. - - In case of complex Security Policy Databases (SPDs) and the co- - existence of HIP and security-related protocols such as IKE, - implementors may encounter conditions that are unspecified in these - documents. For example, when the SPD defines an IP address subnet to - be protected and a HIP host is residing in that IP address area, - there is a possibility that the communication is encrypted multiple - times. Readers are advised to pay special attention when running HIP - with complex SPD settings. Future specifications should clearly - define when multiple encryption is intended, and when it should be - avoided. - Status of This Memo - This Internet-Draft is submitted to IETF in full conformance with the + This Internet-Draft is submitted 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. + 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." - 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 March 27, 2011. + This Internet-Draft will expire on March 31, 2013. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2012 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 - described in the BSD License. - - This document may contain material from IETF Documents or IETF - Contributions published or made publicly available before November - 10, 2008. The person(s) controlling the copyright in some of this - material may not have granted the IETF Trust the right to allow - modifications of such material outside the IETF Standards Process. - Without obtaining an adequate license from the person(s) controlling - the copyright in such materials, this document may not be modified - outside the IETF Standards Process, and derivative works of it may - not be created outside the IETF Standards Process, except to format - it for publication as an RFC or to translate it into languages other - than English. + described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 4 3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 5 3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 5 3.2.1. Semantics of the Security Parameter Index (SPI) . . . 6 3.3. Security Association Establishment and Maintenance . . . . 6 @@ -138,40 +104,40 @@ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1. Normative references . . . . . . . . . . . . . . . . . . . 28 11.2. Informative references . . . . . . . . . . . . . . . . . . 28 Appendix A. A Note on Implementation Options . . . . . . . . . . 29 Appendix B. Bound End-to-End Tunnel mode for ESP . . . . . . . . 29 B.1. Protocol definition . . . . . . . . . . . . . . . . . . . 30 B.1.1. Changes to Security Association data structures . . . 30 - B.1.2. Packet format . . . . . . . . . . . . . . . . . . . . 31 + B.1.2. Packet format . . . . . . . . . . . . . . . . . . . . 30 B.1.3. Cryptographic processing . . . . . . . . . . . . . . . 32 - B.1.4. IP header processing . . . . . . . . . . . . . . . . . 33 + B.1.4. IP header processing . . . . . . . . . . . . . . . . . 32 B.1.5. Handling of outgoing packets . . . . . . . . . . . . . 33 B.1.6. Handling of incoming packets . . . . . . . . . . . . . 34 B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 35 1. Introduction In the Host Identity Protocol Architecture - [I-D.moskowitz-hip-rfc4423-bis], hosts are identified with public - keys. The Host Identity Protocol [I-D.moskowitz-hip-rfc5201-bis] - base exchange allows any two HIP-supporting hosts to authenticate - each other and to create a HIP association between themselves. - During the base exchange, the hosts generate a piece of shared keying - material using an authenticated Diffie-Hellman exchange. + [I-D.ietf-hip-rfc4423-bis], hosts are identified with public keys. + The Host Identity Protocol [I-D.ietf-hip-rfc5201-bis] base exchange + allows any two HIP-supporting hosts to authenticate each other and to + create a HIP association between themselves. During the base + exchange, the hosts generate a piece of shared keying material using + an authenticated Diffie-Hellman exchange. - The HIP base exchange specification [I-D.moskowitz-hip-rfc5201-bis] - does not describe any transport formats or methods for user data to - be used during the actual communication; it only defines that it is + The HIP base exchange specification [I-D.ietf-hip-rfc5201-bis] does + not describe any transport formats or methods for user data to be + used during the actual communication; it only defines that it is mandatory to implement the Encapsulated Security Payload (ESP) [RFC4303] based transport format and method. This document specifies how ESP is used with HIP to carry actual user data. To be more specific, this document specifies a set of HIP protocol extensions and their handling. Using these extensions, a pair of ESP Security Associations (SAs) is created between the hosts during the base exchange. The resulting ESP Security Associations use keys drawn from the keying material (KEYMAT) generated during the base exchange. After the HIP association and required ESP SAs have been @@ -198,21 +164,21 @@ The HIP base exchange is used to set up a HIP association between two hosts. The base exchange provides two-way host authentication and key material generation, but it does not provide any means for protecting data communication between the hosts. In this document, we specify the use of ESP for protecting user data traffic after the HIP base exchange. Note that this use of ESP is intended only for host-to-host traffic; security gateways are not supported. To support ESP use, the HIP base exchange messages require some minor additions to the parameters transported. In the R1 packet, the - Responder adds the possible ESP transforms in a new ESP_TRANSFORM + Responder adds the possible ESP transforms in a npew ESP_TRANSFORM parameter before sending it to the Initiator. The Initiator gets the proposed transforms, selects one of those proposed transforms, and adds it to the I2 packet in an ESP_TRANSFORM parameter. In this I2 packet, the Initiator also sends the SPI value that it wants to be used for ESP traffic flowing from the Responder to the Initiator. This information is carried using the new ESP_INFO parameter. When finalizing the ESP SA setup, the Responder sends its SPI value to the Initiator in the R2 packet, again using ESP_INFO. 3.1. ESP Packet Format @@ -288,22 +254,22 @@ The selected SPI is communicated to the peer in the third (I2) and fourth (R2) packets of the base HIP exchange. Changes in SPI are signaled with ESP_INFO parameters. 3.3. Security Association Establishment and Maintenance 3.3.1. ESP Security Associations In HIP, ESP Security Associations are setup between the HIP nodes - during the base exchange [I-D.moskowitz-hip-rfc5201-bis]. Existing - ESP SAs can be updated later using UPDATE messages. The reason for + during the base exchange [I-D.ietf-hip-rfc5201-bis]. Existing ESP + SAs can be updated later using UPDATE messages. The reason for updating the ESP SA later can be, for example, a need for rekeying the SA because of sequence number rollover. Upon setting up a HIP association, each association is linked to two ESP SAs, one for incoming packets and one for outgoing packets. The Initiator's incoming SA corresponds with the Responder's outgoing one, and vice versa. The Initiator defines the SPI for its incoming association, as defined in Section 3.2.1. This SA is herein called SA-RI, and the corresponding SPI is called SPI-RI. Respectively, the Responder's incoming SA corresponds with the Initiator's outgoing SA @@ -313,21 +279,21 @@ sending out the I2, as explained in Section 6.4. The keys are derived from KEYMAT, as defined in Section 7. The Responder creates SA-RI as a part of I2 processing; see Section 6.5. The Responder creates SA-IR as a part of I2 processing, before sending out R2; see Section 6.5. The Initiator creates SA-IR when processing R2; see Section 6.6. The initial session keys are drawn from the generated keying material, KEYMAT, after the HIP keys have been drawn as specified in - [I-D.moskowitz-hip-rfc5201-bis]. + [I-D.ietf-hip-rfc5201-bis]. When the HIP association is removed, the related ESP SAs MUST also be removed. 3.3.2. Rekeying After the initial HIP base exchange and SA establishment, both hosts are in the ESTABLISHED state. There are no longer Initiator and Responder roles and the association is symmetric. In this subsection, the party that initiates the rekey procedure is denoted @@ -430,21 +396,21 @@ In the sending host, the HIP SA processing takes place always before the IPsec processing. Vice versa, at the receiving host, the IPsec processing is done first for incoming packets and the decrypted packet is further given to the HIP processing. Incoming packets using an SA that is not negotiated by HIP MUST NOT be processed as described in Section 3.2, paragraph 2. The SPI will identify the correct SA for packet decryption and MUST be used to identify that the packet has an upper-layer checksum that is - calculated as specified in [I-D.moskowitz-hip-rfc5201-bis]. + calculated as specified in [I-D.ietf-hip-rfc5201-bis]. 3.4.1. Data Packet Processing Considerations For outbound traffic, the SPD or (coordinated) SPDs if there are two (one for HIP and one for IPsec) MUST ensure that packets intended for HIP processing are given a HIP-enabled SA and that packets intended for IPsec processing are given an IPsec-enabled SA. The SP then MUST be bound to the matching SA and non-HIP packets will not be processed by this SA. Data originating from a socket that is not using HIP MUST NOT have checksum recalculated (as described in Section 3.2, @@ -529,21 +495,21 @@ In the R2 message, the ESP SA setup is finalized. The packet contains the SPI information required by the Initiator for the ESP SA. 4.1.2. Updating an Existing ESP SA The update process is accomplished using two messages. The HIP UPDATE message is used to update the parameters of an existing ESP SA. The UPDATE mechanism and message is defined in - [I-D.moskowitz-hip-rfc5201-bis], and the additional parameters for + [I-D.ietf-hip-rfc5201-bis], and the additional parameters for updating an existing ESP SA are described here. The following picture shows a typical exchange when an existing ESP SA is updated. Messages include SEQ and ACK parameters required by the UPDATE mechanism. H1 H2 UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN] -----------------------------------------------------> @@ -552,41 +518,41 @@ UPDATE: ACK -----------------------------------------------------> The host willing to update the ESP SA creates and sends an UPDATE message. The message contains the ESP_INFO parameter containing the old SPI value that was used, the new SPI value to be used, and the index value for the keying material, giving the point from where the next keys will be drawn. If new keying material must be generated, the UPDATE message will also contain the DIFFIE_HELLMAN parameter - defined in [I-D.moskowitz-hip-rfc5201-bis]. + defined in [I-D.ietf-hip-rfc5201-bis]. The host receiving the UPDATE message requesting update of an existing ESP SA MUST reply with an UPDATE message. In the reply message, the host sends the ESP_INFO parameter containing the corresponding values: old SPI, new SPI, and the keying material index. If the incoming UPDATE contained a DIFFIE_HELLMAN parameter, the reply packet MUST also contain a DIFFIE_HELLMAN parameter. 5. Parameter and Packet Formats In this section, new and modified HIP parameters are presented, as well as modified HIP packets. 5.1. New Parameters Two new HIP parameters are defined for setting up ESP transport format associations in HIP communication and for rekeying existing ones. Also, the NOTIFY parameter, described in - [I-D.moskowitz-hip-rfc5201-bis], has two new error parameters. + [I-D.ietf-hip-rfc5201-bis], has two new error parameters. Parameter Type Length Data ESP_INFO 65 12 Remote's old SPI, new SPI, and other info ESP_TRANSFORM 4095 variable ESP Encryption and Authentication Transform(s) 5.1.1. ESP_INFO @@ -711,21 +677,21 @@ NULL-ENCRYPT with HMAC-SHA2 7 [RFC2410], [RFC4868] AES-128-CBC with HMAC-SHA2 8 [RFC3602], [RFC4868] AES-256-CBC with HMAC-SHA2 9 [RFC3602], [RFC4868] AES-CCM-8 10 [RFC4309] AES-CCM-16 11 [RFC4309] AES-GCM with a 8 octet ICV 12 [RFC4106] AES-GCM with a 16 octet ICV 13 [RFC4106] The sender of an ESP transform parameter MUST make sure that there are no more than six (6) Suite IDs in one ESP transform parameter. - Conversely, a recipient MUST be prepared to handle received transport + Conversely, a recipient MUST be prepared to handle received transform parameters that contain more than six Suite IDs. The limited number of Suite IDs sets the maximum size of the ESP_TRANSFORM parameter. As the default configuration, the ESP_TRANSFORM parameter MUST contain at least one of the mandatory Suite IDs. There MAY be a configuration option that allows the administrator to override this default. Mandatory implementations: AES-CBC with HMAC-SHA1 and NULL with HMAC- SHA1. @@ -885,47 +851,47 @@ IP ( HIP ( ESP_INFO, SEQ, ACK, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) ) 5.4. ICMP Messages ICMP message handling is mainly described in the HIP base - specification [I-D.moskowitz-hip-rfc5201-bis]. In this section, we + specification [I-D.ietf-hip-rfc5201-bis]. In this section, we describe the actions related to ESP security associations. 5.4.1. Unknown SPI If a HIP implementation receives an ESP packet that has an unrecognized SPI number, it MAY respond (subject to rate limiting the responses) with an ICMP packet with type "Parameter Problem", with the pointer pointing to the beginning of SPI field in the ESP header. 6. Packet Processing Packet processing is mainly defined in the HIP base specification - [I-D.moskowitz-hip-rfc5201-bis]. This section describes the changes - and new requirements for packet handling when the ESP transport - format is used. Note that all HIP packets (currently protocol 253) - MUST bypass ESP processing. + [I-D.ietf-hip-rfc5201-bis]. This section describes the changes and + new requirements for packet handling when the ESP transport format is + used. Note that all HIP packets (currently protocol 253) MUST bypass + ESP processing. 6.1. Processing Outgoing Application Data Outgoing application data handling is specified in the HIP base - specification [I-D.moskowitz-hip-rfc5201-bis]. When the ESP - transport format is used, and there is an active HIP session for the - given < source, destination > HIT pair, the outgoing datagram is - protected using the ESP security association. The following - additional steps define the conceptual processing rules for outgoing - ESP protected datagrams. + specification [I-D.ietf-hip-rfc5201-bis]. When the ESP transport + format is used, and there is an active HIP session for the given < + source, destination > HIT pair, the outgoing datagram is protected + using the ESP security association. The following additional steps + define the conceptual processing rules for outgoing ESP protected + datagrams. 1. Detect the proper ESP SA using the HITs in the packet header or other information associated with the packet 2. Process the packet normally, as if the SA was a transport mode SA. 3. Ensure that the outgoing ESP protected packet has proper IP header format depending on the used IP address family, and proper IP addresses in its IP header, e.g., by replacing HITs left by @@ -972,21 +938,21 @@ datagram to the right upper layer socket is performed as usual, except that the HITs are used in place of IP addresses during the demultiplexing. 6.3. HMAC and SIGNATURE Calculation and Verification The new HIP parameters described in this document, ESP_INFO and ESP_TRANSFORM, must be protected using HMAC and signature calculations. In a typical implementation, they are included in R1, I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as - described in [I-D.moskowitz-hip-rfc5201-bis]. + described in [I-D.ietf-hip-rfc5201-bis]. 6.4. Processing Incoming ESP SA Initialization (R1) The ESP SA setup is initialized in the R1 message. The receiving host (Initiator) selects one of the ESP transforms from the presented values. If no suitable value is found, the negotiation is terminated. The selected values are subsequently used when generating and using encryption keys, and when sending the reply packet. If the proposed alternatives are not acceptable to the system, it may abandon the ESP SA establishment negotiation, or it @@ -996,21 +962,21 @@ the system prepares and creates an incoming ESP security association. It may also prepare a security association for outgoing traffic, but since it does not have the correct SPI value yet, it cannot activate it. 6.5. Processing Incoming Initialization Reply (I2) The following steps are required to process the incoming ESP SA initialization replies in I2. The steps below assume that the I2 has been accepted for processing (e.g., has not been dropped due to HIT - comparisons as described in [I-D.moskowitz-hip-rfc5201-bis]). + comparisons as described in [I-D.ietf-hip-rfc5201-bis]). o The ESP_TRANSFORM parameter is verified and it MUST contain a single value in the parameter, and it MUST match one of the values offered in the initialization packet. o The ESP_INFO NEW SPI field is parsed to obtain the SPI that will be used for the Security Association outbound from the Responder and inbound to the Initiator. For this initial ESP SA establishment, the old SPI value MUST be zero. The KEYMAT Index field MUST contain the index value to the KEYMAT from where the @@ -1047,23 +1013,23 @@ A system may initiate the SA rekeying procedure at any time. It MUST initiate a rekey if its incoming ESP sequence counter is about to overflow. The system MUST NOT replace its keying material until the rekeying packet exchange successfully completes. Optionally, a system may include a new Diffie-Hellman key for use in new KEYMAT generation. New KEYMAT generation occurs prior to drawing the new keys. The rekeying procedure uses the UPDATE mechanism defined in - [I-D.moskowitz-hip-rfc5201-bis]. Because each peer must update its - half of the security association pair (including new SPI creation), - the rekeying process requires that each side both send and receive an + [I-D.ietf-hip-rfc5201-bis]. Because each peer must update its half + of the security association pair (including new SPI creation), the + rekeying process requires that each side both send and receive an UPDATE. A system will then rekey the ESP SA when it has sent parameters to the peer and has received both an ACK of the relevant UPDATE message and corresponding peer's parameters. It may be that the ACK and the required HIP parameters arrive in different UPDATE messages. This is always true if a system does not initiate ESP SA update but responds to an update request from the peer, and may also occur if two systems initiate update nearly simultaneously. In such a case, if the system has an outstanding update request, it saves the one parameter and waits for the other before completing rekeying. @@ -1103,21 +1069,21 @@ To simplify the state machine, a host MUST NOT generate new UPDATEs while it has an outstanding ESP SA update request, unless it is restarting the update process. 6.9. Processing Incoming UPDATE Packets When a system receives an UPDATE packet, it must be processed if the following conditions hold (in addition to the generic conditions specified for UPDATE processing in Section 6.12 of - [I-D.moskowitz-hip-rfc5201-bis]): + [I-D.ietf-hip-rfc5201-bis]): 1. A corresponding HIP association must exist. This is usually ensured by the underlying UPDATE mechanism. 2. The state of the HIP association is ESTABLISHED or R2-SENT. If the above conditions hold, the following steps define the conceptual processing rules for handling the received UPDATE packet: 1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the @@ -1222,38 +1188,31 @@ denotes the host with the lower HIT value. When HIT values are compared, they are interpreted as positive (unsigned) 128-bit integers in network byte order. The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 exchange. Subsequent rekeys using UPDATE will only draw the four ESP keys from KEYMAT. Section 6.9 describes the rules for reusing or regenerating KEYMAT based on the rekeying. The number of bits drawn for a given algorithm is the "natural" size - of the keys. For the mandatory algorithms, the following sizes - apply: - - AES 128 bits - - SHA-1 160 bits - - NULL 0 bits + of the keys, as specified in Section 6.5 of + [I-D.ietf-hip-rfc5201-bis]. 8. Security Considerations In this document, the usage of ESP [RFC4303] between HIP hosts to protect data traffic is introduced. The Security Considerations for ESP are discussed in the ESP specification. There are different ways to establish an ESP Security Association between two nodes. This can be done, e.g., using IKE [RFC4306]. - This document specifies how the Host Identity Protocol is used to establish ESP Security Associations. The following issues are new or have changed from the standard ESP usage: o Initial keying material generation o Updating the keying material @@ -1251,130 +1210,127 @@ establish ESP Security Associations. The following issues are new or have changed from the standard ESP usage: o Initial keying material generation o Updating the keying material The initial keying material is generated using the Host Identity - Protocol [I-D.moskowitz-hip-rfc5201-bis] using the Diffie-Hellman + Protocol [I-D.ietf-hip-rfc5201-bis] using the Diffie-Hellman procedure. This document extends the usage of the UPDATE packet, defined in the base specification, to modify existing ESP SAs. The hosts may rekey, i.e., force the generation of new keying material using the Diffie-Hellman procedure. The initial setup of ESP SA between the hosts is done during the base exchange, and the message exchange is protected using methods provided by base exchange. Changes in connection parameters means basically that the old ESP SA is removed and a new one is generated once the UPDATE message exchange has been completed. The message exchange is protected using the HIP association keys. Both HMAC and signing of packets is used. 9. IANA Considerations This document defines additional parameters and NOTIFY error types - for the Host Identity Protocol [I-D.moskowitz-hip-rfc5201-bis]. + for the Host Identity Protocol [I-D.ietf-hip-rfc5201-bis]. The new parameters and their type numbers are defined in Section 5.1.1 and Section 5.1.2, and they have been added to the - Parameter Type namespace specified in - [I-D.moskowitz-hip-rfc5201-bis]. + Parameter Type namespace specified in [I-D.ietf-hip-rfc5201-bis]. The new NOTIFY error types and their values are defined in Section 5.1.3, and they have been added to the Notify Message Type - namespace specified in [I-D.moskowitz-hip-rfc5201-bis]. + namespace specified in [I-D.ietf-hip-rfc5201-bis]. 10. Acknowledgments This document was separated from the base "Host Identity Protocol" specification in the beginning of 2005. Since then, a number of people have contributed to the text by providing comments and modification proposals. The list of people include Tom Henderson, - Jeff Ahrenholz, Jukka Ylitalo, and Miika Komu. The authors also want - to thank Charlie Kaufman for reviewing the document with his eye on - the usage of crypto algorithms. + Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. + Especially, the authors want to thank Pekka Nikander for his + invaluable contributions to the document since the first draft + version. The authors want to thank also Charlie Kaufman for + reviewing the document with his eye on the usage of crypto + algorithms. Due to the history of this document, most of the ideas are inherited from the base "Host Identity Protocol" specification. Thus, the list of people in the Acknowledgments section of that specification is also valid for this document. Many people have given valuable feedback, and our apologies to anyone whose name is missing. 11. References 11.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-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and + T. Henderson, "Host Identity Protocol + Version 2 (HIPv2)", + draft-ietf-hip-rfc5201-bis-09 (work in + progress), July 2012. + + [RFC2119] Bradner, S., "Key words for use in RFCs + to Indicate Requirement Levels", BCP 14, + RFC 2119, March 1997. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. - [RFC3602] Frankel, S., Glenn, R., and S. - Kelly, "The AES-CBC Cipher Algorithm - and Its Use with IPsec", RFC 3602, - September 2003. + [RFC3602] Frankel, S., Glenn, R., and S. Kelly, + "The AES-CBC Cipher Algorithm and Its Use + with IPsec", RFC 3602, September 2003. [RFC4303] Kent, S., "IP Encapsulating Security - Payload (ESP)", RFC 4303, - December 2005. + Payload (ESP)", RFC 4303, December 2005. 11.2. Informative references - [I-D.moskowitz-hip-rfc4423-bis] Moskowitz, R., "Host Identity - Protocol Architecture", - draft-moskowitz-hip-rfc4423-bis-02 - (work in progress), June 2010. - - [I-D.moskowitz-hip-rfc5201-bis] Moskowitz, R., Jokela, P., - Henderson, T., and T. Heer, "Host - Identity Protocol", - draft-moskowitz-hip-rfc5201-bis-02 - (work in progress), July 2010. + [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol + Architecture", + draft-ietf-hip-rfc4423-bis-04 (work in + progress), July 2012. - [RFC0791] Postel, J., "Internet Protocol", - STD 5, RFC 791, September 1981. + [RFC0791] Postel, J., "Internet Protocol", STD 5, + RFC 791, September 1981. [RFC2401] Kent, S. and R. Atkinson, "Security - Architecture for the Internet - Protocol", RFC 2401, November 1998. + Architecture for the Internet Protocol", + RFC 2401, November 1998. [RFC3260] Grossman, D., "New Terminology and - Clarifications for Diffserv", - RFC 3260, April 2002. + Clarifications for Diffserv", RFC 3260, + April 2002. - [RFC3474] Lin, Z. and D. Pendarakis, - "Documentation of IANA assignments - for Generalized MultiProtocol Label - Switching (GMPLS) Resource - Reservation Protocol - Traffic + [RFC3474] Lin, Z. and D. Pendarakis, "Documentation + of IANA assignments for Generalized + MultiProtocol Label Switching (GMPLS) + Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and - Extensions for Automatically - Switched Optical Network (ASON)", - RFC 3474, March 2003. + Extensions for Automatically Switched + Optical Network (ASON)", RFC 3474, + March 2003. [RFC4301] Kent, S. and K. Seo, "Security - Architecture for the Internet - Protocol", RFC 4301, December 2005. + Architecture for the Internet Protocol", + RFC 4301, December 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. - [RFC5206] Henderson, T., Ed., "End-Host - Mobility and Multihoming with the - Host Identity Protocol", RFC 5206, - April 2008. + [RFC5206] Henderson, T., Ed., "End-Host Mobility + and Multihoming with the Host Identity + Protocol", RFC 5206, April 2008. Appendix A. A Note on Implementation Options It is possible to implement this specification in multiple different ways. As noted above, one possible way of implementing this is to rewrite IP headers below IPsec. In such an implementation, IPsec is used as if it was processing IPv6 transport mode packets, with the IPv6 header containing HITs instead of IP addresses in the source and destination address fields. In outgoing packets, after IPsec processing, the HITs are replaced with actual IP addresses, based on @@ -1687,32 +1642,24 @@ Petri Jokela Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 EMail: petri.jokela@nomadiclab.com Robert Moskowitz - ICSA labs, An Independent Division of Verizon Business + ICSAlabs, An Independent Division of Verizon Business Systems 1000 Bent Creek Blvd, Suite 200 Mechanicsburg, PA USA EMail: rgm@icsalabs.com - Pekka Nikander - Ericsson Research NomadicLab - JORVAS FIN-02420 - FINLAND - - Phone: +358 9 299 1 - EMail: pekka.nikander@nomadiclab.com - Jan Melen Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 EMail: jan.melen@nomadiclab.com