< draft-ietf-hip-rfc5202-bis-05.txt   draft-ietf-hip-rfc5202-bis-07.txt >
Network Working Group P. Jokela Network Working Group P. Jokela
Internet-Draft Ericsson Research NomadicLab Internet-Draft Ericsson Research NomadicLab
Obsoletes: 5202 (if approved) R. Moskowitz Obsoletes: 5202 (if approved) R. Moskowitz
Intended status: Standards Track ICSAlabs, An Independent Intended status: Standards Track Verizon
Expires: May 22, 2014 Division of Verizon Business Expires: March 9, 2015 J. Melen
Systems
J. Melen
Ericsson Research NomadicLab Ericsson Research NomadicLab
November 18, 2013 September 5, 2014
Using the Encapsulating Security Payload (ESP) Transport Format with the Using the Encapsulating Security Payload (ESP) Transport Format with the
Host Identity Protocol (HIP) Host Identity Protocol (HIP)
draft-ietf-hip-rfc5202-bis-05 draft-ietf-hip-rfc5202-bis-07
Abstract Abstract
This memo specifies an Encapsulated Security Payload (ESP) based This memo specifies an Encapsulated Security Payload (ESP) based
mechanism for transmission of user data packets, to be used with the mechanism for transmission of user data packets, to be used with the
Host Identity Protocol (HIP). This document obsoletes RFC 5202. Host Identity Protocol (HIP). This document obsoletes RFC 5202.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 38 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 22, 2014. This Internet-Draft will expire on March 9, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 5 3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . 4
3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 5 3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 5
3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 5 3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . 5
3.2.1. Semantics of the Security Parameter Index (SPI) . . . 6 3.2.1. Semantics of the Security Parameter Index (SPI) . . . 6
3.3. Security Association Establishment and Maintenance . . . . 7 3.3. Security Association Establishment and Maintenance . . . 6
3.3.1. ESP Security Associations . . . . . . . . . . . . . . 7 3.3.1. ESP Security Associations . . . . . . . . . . . . . . 6
3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . 7
3.3.3. Security Association Management . . . . . . . . . . . 8 3.3.3. Security Association Management . . . . . . . . . . . 8
3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 8 3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . 8
3.3.5. Supported Ciphers . . . . . . . . . . . . . . . . . . 9 3.3.5. Supported Ciphers . . . . . . . . . . . . . . . . . . 8
3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 9 3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 9
3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 9 3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . 9
3.4. IPsec and HIP ESP Implementation Considerations . . . . . 9 3.4. IPsec and HIP ESP Implementation Considerations . . . . . 9
3.4.1. Data Packet Processing Considerations . . . . . . . . 10 3.4.1. Data Packet Processing Considerations . . . . . . . . 9
3.4.2. HIP Signaling Packet Considerations . . . . . . . . . 10 3.4.2. HIP Signaling Packet Considerations . . . . . . . . . 10
4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. IPsec ESP Transport Format Type . . . . . . . . . . . 11 4.1.1. IPsec ESP Transport Format Type . . . . . . . . . . . 11
4.1.2. Setting Up an ESP Security Association . . . . . . . . 11 4.1.2. Setting Up an ESP Security Association . . . . . . . 11
4.1.3. Updating an Existing ESP SA . . . . . . . . . . . . . 12 4.1.3. Updating an Existing ESP SA . . . . . . . . . . . . . 12
5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 13 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . 13
5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 13 5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 15 5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 14
5.1.3. NOTIFICATION Parameter . . . . . . . . . . . . . . . . 16 5.1.3. NOTIFICATION Parameter . . . . . . . . . . . . . . . 16
5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 16 5.2. HIP ESP Security Association Setup . . . . . . . . . . . 16
5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 16 5.2.1. Setup During Base Exchange . . . . . . . . . . . . . 16
5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 18 5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . 18
5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 18 5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 18
5.3.2. Responding to the Rekeying Initialization . . . . . . 19 5.3.2. Responding to the Rekeying Initialization . . . . . . 19
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 19 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 19
5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19 5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 20 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Processing Outgoing Application Data . . . . . . . . . . . 20 6.1. Processing Outgoing Application Data . . . . . . . . . . 20
6.2. Processing Incoming Application Data . . . . . . . . . . . 20 6.2. Processing Incoming Application Data . . . . . . . . . . 20
6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 21 6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 21
6.4. Processing Incoming ESP SA Initialization (R1) . . . . . . 21 6.4. Processing Incoming ESP SA Initialization (R1) . . . . . 21
6.5. Processing Incoming Initialization Reply (I2) . . . . . . 22 6.5. Processing Incoming Initialization Reply (I2) . . . . . . 22
6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . . 22 6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . 22
6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 22 6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 22
6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 22 6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . 22
6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . . 24 6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . 24
6.9.1. Processing UPDATE Packet: No Outstanding Rekeying 6.9.1. Processing UPDATE Packet: No Outstanding
Request . . . . . . . . . . . . . . . . . . . . . . . 24 Rekeying Request . . . . . . . . . . . . . . . . . . 24
6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 25 6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 25
6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 26 6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 26
7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 26 7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative references . . . . . . . . . . . . . . . . . . . 28 11.1. Normative references . . . . . . . . . . . . . . . . . . 28
11.2. Informative references . . . . . . . . . . . . . . . . . . 29 11.2. Informative references . . . . . . . . . . . . . . . . . 29
Appendix A. A Note on Implementation Options . . . . . . . . . . 30 Appendix A. A Note on Implementation Options . . . . . . . . . . 31
Appendix B. Bound End-to-End Tunnel mode for ESP . . . . . . . . 30 Appendix B. Bound End-to-End Tunnel mode for ESP . . . . . . . . 31
B.1. Protocol definition . . . . . . . . . . . . . . . . . . . 31 B.1. Protocol definition . . . . . . . . . . . . . . . . . . . 32
B.1.1. Changes to Security Association data structures . . . 31 B.1.1. Changes to Security Association data structures . . . 32
B.1.2. Packet format . . . . . . . . . . . . . . . . . . . . 31 B.1.2. Packet format . . . . . . . . . . . . . . . . . . . . 32
B.1.3. Cryptographic processing . . . . . . . . . . . . . . . 33 B.1.3. Cryptographic processing . . . . . . . . . . . . . . 34
B.1.4. IP header processing . . . . . . . . . . . . . . . . . 33 B.1.4. IP header processing . . . . . . . . . . . 34
B.1.5. Handling of outgoing packets . . . . . . . . . . . . . 34 B.1.5. Handling of outgoing packets . . . . . . . . . . . . 35
B.1.6. Handling of incoming packets . . . . . . . . . . . . . 35 B.1.6. Handling of incoming packets . . . . . . . . . . . . 36
B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 35 B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
In the Host Identity Protocol Architecture In the Host Identity Protocol Architecture
[I-D.ietf-hip-rfc4423-bis], hosts are identified with public keys. [I-D.ietf-hip-rfc4423-bis], hosts are identified with public keys.
The Host Identity Protocol [I-D.ietf-hip-rfc5201-bis] base exchange The Host Identity Protocol [I-D.ietf-hip-rfc5201-bis] base exchange
allows any two HIP-supporting hosts to authenticate each other and to allows any two HIP-supporting hosts to authenticate each other and to
create a HIP association between themselves. During the base create a HIP association between themselves. During the base
exchange, the hosts generate a piece of shared keying material using exchange, the hosts generate a piece of shared keying material using
an authenticated Diffie-Hellman exchange. an authenticated Diffie-Hellman exchange.
skipping to change at page 6, line 31 skipping to change at page 6, line 12
corresponding host implements it, instead the corresponding host can corresponding host implements it, instead the corresponding host can
have ESP transport mode and do HIT IP conversions outside ESP. have ESP transport mode and do HIT IP conversions outside ESP.
3.2.1. Semantics of the Security Parameter Index (SPI) 3.2.1. Semantics of the Security Parameter Index (SPI)
SPIs are used in ESP to find the right Security Association for SPIs are used in ESP to find the right Security Association for
received packets. The ESP SPIs have added significance when used received packets. The ESP SPIs have added significance when used
with HIP; they are a compressed representation of a pair of HITs. with HIP; they are a compressed representation of a pair of HITs.
Thus, SPIs MAY be used by intermediary systems in providing services Thus, SPIs MAY be used by intermediary systems in providing services
like address mapping. Note that since the SPI has significance at like address mapping. Note that since the SPI has significance at
the receiver, only the < DST, SPI >, where DST is a destination IP the receiver, only the ?< DST, SPI >?, where DST is a destination IP
address, uniquely identifies the receiver HIT at any given point of address, uniquely identifies the receiver HIT at any given point of
time. The same SPI value may be used by several hosts. A single < time. The same SPI value may be used by several hosts. A single ?<
DST, SPI > value may denote different hosts and contexts at different DST, SPI >? value may denote different hosts and contexts at
points of time, depending on the host that is currently reachable at different points of time, depending on the host that is currently
the DST. reachable at the DST.
Each host selects for itself the SPI it wants to see in packets Each host selects for itself the SPI it wants to see in packets
received from its peer. This allows it to select different SPIs for received from its peer. This allows it to select different SPIs for
different peers. The SPI selection SHOULD be random; the rules of different peers. The SPI selection SHOULD be random; the rules of
Section 2.1 of the ESP specification [RFC4303] must be followed. A Section 2.1 of the ESP specification [RFC4303] must be followed. A
different SPI SHOULD be used for each HIP exchange with a particular different SPI SHOULD be used for each HIP exchange with a particular
host; this is to avoid a replay attack. Additionally, when a host host; this is to avoid a replay attack. Additionally, when a host
rekeys, the SPI MUST be changed. Furthermore, if a host changes over rekeys, the SPI MUST be changed. Furthermore, if a host changes over
to use a different IP address, it MAY change the SPI. to use a different IP address, it MAY change the SPI.
skipping to change at page 9, line 13 skipping to change at page 8, line 41
gets a new outbound SPI from its peer. gets a new outbound SPI from its peer.
3.3.5. Supported Ciphers 3.3.5. Supported Ciphers
All HIP implementations MUST support AES-128-CBC and AES-256-CBC All HIP implementations MUST support AES-128-CBC and AES-256-CBC
[RFC3602]. If the Initiator does not support any of the transforms [RFC3602]. If the Initiator does not support any of the transforms
offered by the Responder, it should abandon the negotiation and offered by the Responder, it should abandon the negotiation and
inform the peer with a NOTIFY message about a non-supported inform the peer with a NOTIFY message about a non-supported
transform. transform.
In addition to AES-128-CBC, all implementations MUST implement the In addition to AES-128-CBC, all implementations SHOULD implement the
ESP NULL encryption algorithm. When the ESP NULL encryption is used, ESP NULL encryption algorithm. When the ESP NULL encryption is used,
it MUST be used together with SHA-256 authentication as specified in it MUST be used together with SHA-256 authentication as specified in
Section 5.1.2 Section 5.1.2
When an authentication-only suite is used (NULL, AES-CMAC-96, and
AES-GMAC are examples), the suite MUST NOT be accepted if offered by
the peer unless the local policy configuration regarding the peer
host is explicitly set to allow an authentication-only mode. This is
to prevent sessions from being downgraded to an authentication-only
mode when one side's policy requests privacy for the session.
3.3.6. Sequence Number 3.3.6. Sequence Number
The Sequence Number field is MANDATORY when ESP is used with HIP. The Sequence Number field is MANDATORY when ESP is used with HIP.
Anti-replay protection MUST be used in an ESP SA established with Anti-replay protection MUST be used in an ESP SA established with
HIP. When ESP is used with HIP, a 64-bit sequence number MUST be HIP. When ESP is used with HIP, a 64-bit sequence number MUST be
used. This means that each host MUST rekey before its sequence used. This means that each host MUST rekey before its sequence
number reaches 2^64. number reaches 2^64.
When using a 64-bit sequence number, the higher 32 bits are NOT When using a 64-bit sequence number, the higher 32 bits are NOT
included in the ESP header, but are simply kept local to both peers. included in the ESP header, but are simply kept local to both peers.
skipping to change at page 15, line 41 skipping to change at page 15, line 34
Suite ID Value Suite ID Value
RESERVED 0 RESERVED 0
AES-128-CBC with HMAC-SHA1 1 [RFC3602], [RFC2404] AES-128-CBC with HMAC-SHA1 1 [RFC3602], [RFC2404]
DEPRECATED 2 DEPRECATED 2
DEPRECATED 3 DEPRECATED 3
DEPRECATED 4 DEPRECATED 4
DEPRECATED 5 DEPRECATED 5
DEPRECATED 6 DEPRECATED 6
NULL-ENCRYPT with HMAC-SHA-256 7 [RFC2410], [RFC4868] NULL with HMAC-SHA-256 7 [RFC2410], [RFC4868]
AES-128-CBC with HMAC-SHA-256 8 [RFC3602], [RFC4868] AES-128-CBC with HMAC-SHA-256 8 [RFC3602], [RFC4868]
AES-256-CBC with HMAC-SHA-256 9 [RFC3602], [RFC4868] AES-256-CBC with HMAC-SHA-256 9 [RFC3602], [RFC4868]
AES-CCM-8 10 [RFC4309] AES-CCM-8 10 [RFC4309]
AES-CCM-16 11 [RFC4309] AES-CCM-16 11 [RFC4309]
AES-GCM with a 8 octet ICV 12 [RFC4106] AES-GCM with a 8 octet ICV 12 [RFC4106]
AES-GCM with a 16 octet ICV 13 [RFC4106] AES-GCM with a 16 octet ICV 13 [RFC4106]
AES-CMAC-96 14 [RFC4493], [RFC4494] AES-CMAC-96 14 [RFC4493], [RFC4494]
AES-GMAC 15 [RFC4543] AES-GMAC 15 [RFC4543]
The sender of an ESP transform parameter MUST make sure that there The sender of an ESP transform parameter MUST make sure that there
skipping to change at page 16, line 4 skipping to change at page 15, line 46
AES-256-CBC with HMAC-SHA-256 9 [RFC3602], [RFC4868] AES-256-CBC with HMAC-SHA-256 9 [RFC3602], [RFC4868]
AES-CCM-8 10 [RFC4309] AES-CCM-8 10 [RFC4309]
AES-CCM-16 11 [RFC4309] AES-CCM-16 11 [RFC4309]
AES-GCM with a 8 octet ICV 12 [RFC4106] AES-GCM with a 8 octet ICV 12 [RFC4106]
AES-GCM with a 16 octet ICV 13 [RFC4106] AES-GCM with a 16 octet ICV 13 [RFC4106]
AES-CMAC-96 14 [RFC4493], [RFC4494] AES-CMAC-96 14 [RFC4493], [RFC4494]
AES-GMAC 15 [RFC4543] AES-GMAC 15 [RFC4543]
The sender of an ESP transform parameter MUST make sure that there 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. are no more than six (6) Suite IDs in one ESP transform parameter.
Conversely, a recipient MUST be prepared to handle received transform Conversely, a recipient MUST be prepared to handle received transform
parameters that contain more than six Suite IDs. The limited number parameters that contain more than six Suite IDs. The limited number
of Suite IDs sets the maximum size of the ESP_TRANSFORM parameter. of Suite IDs sets the maximum size of the ESP_TRANSFORM parameter.
As the default configuration, the ESP_TRANSFORM parameter MUST As the default configuration, the ESP_TRANSFORM parameter MUST
contain at least one of the mandatory Suite IDs. There MAY be a contain at least one of the mandatory Suite IDs. There MAY be a
configuration option that allows the administrator to override this configuration option that allows the administrator to override this
default. default.
Mandatory implementations: AES-128-CBC with HMAC-SHA-256 and NULL Mandatory implementations: AES-128-CBC with HMAC-SHA-256. NULL with
with HMAC-SHA-256. HMAC-SHA-256 SHOULD also be supported (see also Section 3.3.5).
Under some conditions, it is possible to use Traffic Flow Under some conditions, it is possible to use Traffic Flow
Confidentiality (TFC) [RFC4303] with ESP in BEET mode. However, the Confidentiality (TFC) [RFC4303] with ESP in BEET mode. However, the
definition of such operation is future work and must be done in a definition of such operation is future work and must be done in a
separate specification. separate specification.
5.1.3. NOTIFICATION Parameter 5.1.3. NOTIFICATION Parameter
The HIP base specification defines a set of NOTIFICATION error types. The HIP base specification defines a set of NOTIFICATION error types.
The following error types are required for describing errors in ESP The following error types are required for describing errors in ESP
skipping to change at page 16, line 51 skipping to change at page 16, line 43
The ESP Security Association is set up during the base exchange. The The ESP Security Association is set up during the base exchange. The
following subsections define the ESP SA setup procedure using both following subsections define the ESP SA setup procedure using both
base exchange messages (R1, I2, R2) and UPDATE messages. base exchange messages (R1, I2, R2) and UPDATE messages.
5.2.1. Setup During Base Exchange 5.2.1. Setup During Base Exchange
5.2.1.1. Modifications in R1 5.2.1.1. Modifications in R1
The ESP_TRANSFORM contains the ESP modes supported by the sender, in The ESP_TRANSFORM contains the ESP modes supported by the sender, in
the order of preference. All implementations MUST support AES-128- the order of preference. All implementations MUST support AES-
CBC [RFC3602] with HMAC-SHA-256 [RFC4868]. 128-CBC [RFC3602] with HMAC-SHA-256 [RFC4868].
The following figure shows the resulting R1 packet layout. The following figure shows the resulting R1 packet layout.
The HIP parameters for the R1 packet: The HIP parameters for the R1 packet:
IP ( HIP ( [ R1_COUNTER, ] IP ( HIP ( [ R1_COUNTER, ]
PUZZLE, PUZZLE,
DIFFIE_HELLMAN, DIFFIE_HELLMAN,
HIP_CIPHER, HIP_CIPHER,
ESP_TRANSFORM, ESP_TRANSFORM,
skipping to change at page 17, line 27 skipping to change at page 17, line 24
HIP_SIGNATURE_2 ) HIP_SIGNATURE_2 )
[, ECHO_REQUEST ]) [, ECHO_REQUEST ])
5.2.1.2. Modifications in I2 5.2.1.2. Modifications in I2
The ESP_INFO contains the sender's SPI for this association as well The ESP_INFO contains the sender's SPI for this association as well
as the KEYMAT index from where the ESP SA keys will be drawn. The as the KEYMAT index from where the ESP SA keys will be drawn. The
old SPI value is set to zero. old SPI value is set to zero.
The ESP_TRANSFORM contains the ESP mode selected by the sender of R1. The ESP_TRANSFORM contains the ESP mode selected by the sender of R1.
All implementations MUST support AES-128-CBC [RFC3602] with HMAC-SHA- All implementations MUST support AES-128-CBC [RFC3602] with HMAC-
256 [RFC4868]. SHA-256 [RFC4868].
The following figure shows the resulting I2 packet layout. The following figure shows the resulting I2 packet layout.
The HIP parameters for the I2 packet: The HIP parameters for the I2 packet:
IP ( HIP ( ESP_INFO, IP ( HIP ( ESP_INFO,
[R1_COUNTER,] [R1_COUNTER,]
SOLUTION, SOLUTION,
DIFFIE_HELLMAN, DIFFIE_HELLMAN,
HIP_CIPHER, HIP_CIPHER,
skipping to change at page 27, line 32 skipping to change at page 27, line 32
using the Diffie-Hellman procedure. The initial setup of ESP SA using the Diffie-Hellman procedure. The initial setup of ESP SA
between the hosts is done during the base exchange, and the message between the hosts is done during the base exchange, and the message
exchange is protected using methods provided by base exchange. exchange is protected using methods provided by base exchange.
Changes in connection parameters means basically that the old ESP SA Changes in connection parameters means basically that the old ESP SA
is removed and a new one is generated once the UPDATE message is removed and a new one is generated once the UPDATE message
exchange has been completed. The message exchange is protected using exchange has been completed. The message exchange is protected using
the HIP association keys. Both HMAC and signing of packets is used. the HIP association keys. Both HMAC and signing of packets is used.
9. IANA Considerations 9. IANA Considerations
This document defines additional parameters and NOTIFY error types The following changes to the "Host Identity Protocol (HIP)
for the Host Identity Protocol [I-D.ietf-hip-rfc5201-bis]. Parameters" registries are requested. In all cases, the changes
required are to update the reference from [RFC5202] to this
specification.
The new parameters and their type numbers are defined in This document defines two Parameter Types and two NOTIFY Message
Section 5.1.1 and Section 5.1.2, and they have been added to the Types for the Host Identity Protocol [I-D.ietf-hip-rfc5201-bis].
Parameter Type namespace specified in [I-D.ietf-hip-rfc5201-bis].
The 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 created by [I-D.ietf-hip-rfc5201-bis]. No new action
regarding these values are required by this specification, other than
updating the reference from [RFC5202] to this specification.
The new NOTIFY error types and their values are defined in 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 Section 5.1.3, and they have been added to the Notify Message Type
namespace specified in [I-D.ietf-hip-rfc5201-bis]. namespace created by [I-D.ietf-hip-rfc5201-bis]. No new action
regarding these values are required by this specification, other than
updating the reference from [RFC5202] to this specification.
10. Acknowledgments 10. Acknowledgments
This document was separated from the base "Host Identity Protocol" This document was separated from the base "Host Identity Protocol"
specification in the beginning of 2005. Since then, a number of specification in the beginning of 2005. Since then, a number of
people have contributed to the text by providing comments and people have contributed to the text by providing comments and
modification proposals. The list of people include Tom Henderson, modification proposals. The list of people include Tom Henderson,
Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu.
Especially, the authors want to thank Pekka Nikander for his Especially, the authors want to thank Pekka Nikander for his
invaluable contributions to the document since the first draft invaluable contributions to the document since the first draft
skipping to change at page 28, line 17 skipping to change at page 28, line 28
Due to the history of this document, most of the ideas are inherited Due to the history of this document, most of the ideas are inherited
from the base "Host Identity Protocol" specification. Thus, the list from the base "Host Identity Protocol" specification. Thus, the list
of people in the Acknowledgments section of that specification is of people in the Acknowledgments section of that specification is
also valid for this document. Many people have given valuable also valid for this document. Many people have given valuable
feedback, and our apologies to anyone whose name is missing. feedback, and our apologies to anyone whose name is missing.
11. References 11. References
11.1. Normative references 11.1. Normative references
[I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and [I-D.ietf-hip-rfc5201-bis]
T. Henderson, "Host Identity Protocol Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
Version 2 (HIPv2)", "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
draft-ietf-hip-rfc5201-bis-14 (work in hip-rfc5201-bis-14 (work in progress), October 2013.
progress), October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
to Indicate Requirement Levels", BCP 14, Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2119, March 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
HMAC-SHA-1-96 within ESP and AH", ESP and AH", RFC 2404, November 1998.
RFC 2404, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Encryption Algorithm and Its Use With Its Use With IPsec", RFC 2410, November 1998.
IPsec", RFC 2410, November 1998.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
"The AES-CBC Cipher Algorithm and Its Use Algorithm and Its Use with IPsec", RFC 3602, September
with IPsec", RFC 3602, September 2003. 2003.
[RFC4106] Viega, J. and D. McGrew, "The Use of [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
Galois/Counter Mode (GCM) in IPsec (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
Encapsulating Security Payload (ESP)", 4106, June 2005.
RFC 4106, June 2005.
[RFC4303] Kent, S., "IP Encapsulating Security [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
Payload (ESP)", RFC 4303, December 2005. 4303, December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Standard (AES) CCM Mode with IPsec Mode with IPsec Encapsulating Security Payload (ESP)", RFC
Encapsulating Security Payload (ESP)", 4309, December 2005.
RFC 4309, December 2005.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
T. Iwata, "The AES-CMAC Algorithm", AES-CMAC Algorithm", RFC 4493, June 2006.
RFC 4493, June 2006.
[RFC4494] Song, JH., Poovendran, R., and J. Lee, [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96
"The AES-CMAC-96 Algorithm and Its Use Algorithm and Its Use with IPsec", RFC 4494, June 2006.
with IPsec", RFC 4494, June 2006.
[RFC4543] McGrew, D. and J. Viega, "The Use of [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Galois Message Authentication Code (GMAC) Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
in IPsec ESP and AH", RFC 4543, May 2006. May 2006.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
SHA-256, HMAC-SHA-384, and HMAC-SHA-512 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
with IPsec", RFC 4868, May 2007.
11.2. Informative references 11.2. Informative references
[I-D.ietf-hip-rfc4423-bis] Moskowitz, R. and M. Komu, "Host Identity [I-D.ietf-hip-rfc4423-bis]
Protocol Architecture", Moskowitz, R. and M. Komu, "Host Identity Protocol
draft-ietf-hip-rfc4423-bis-06 (work in Architecture", draft-ietf-hip-rfc4423-bis-08 (work in
progress), November 2013. progress), April 2014.
[RFC0791] Postel, J., "Internet Protocol", STD 5, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
RFC 791, September 1981. 1981.
[RFC4301] Kent, S. and K. Seo, "Security [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Architecture for the Internet Protocol", Internet Protocol", RFC 4301, December 2005.
RFC 4301, December 2005.
[RFC5206] Henderson, T., Ed., "End-Host Mobility [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
and Multihoming with the Host Identity Encapsulating Security Payload (ESP) Transport Format with
Protocol", RFC 5206, April 2008. the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5207] Stiemerling, M., Quittek, J., and L. [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Eggert, "NAT and Firewall Traversal Host Mobility and Multihoming with the Host Identity
Issues of Host Identity Protocol (HIP) Protocol", RFC 5206, April 2008.
Communication", RFC 5207, April 2008.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Melen, J., and A. Keranen, "Basic Host Firewall Traversal Issues of Host Identity Protocol (HIP)
Identity Protocol (HIP) Extensions for Communication", RFC 5207, April 2008.
Traversal of Network Address
Translators", RFC 5770, April 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Eronen, "Internet Key Exchange Protocol IANA Considerations Section in RFCs", BCP 26, RFC 5226,
Version 2 (IKEv2)", RFC 5996, May 2008.
September 2010.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions
for Traversal of Network Address Translators", RFC 5770,
April 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010.
Appendix A. A Note on Implementation Options Appendix A. A Note on Implementation Options
It is possible to implement this specification in multiple different It is possible to implement this specification in multiple different
ways. As noted above, one possible way of implementing this is to ways. As noted above, one possible way of implementing this is to
rewrite IP headers below IPsec. In such an implementation, IPsec is rewrite IP headers below IPsec. In such an implementation, IPsec is
used as if it was processing IPv6 transport mode packets, with the used as if it was processing IPv6 transport mode packets, with the
IPv6 header containing HITs instead of IP addresses in the source and IPv6 header containing HITs instead of IP addresses in the source and
destination address fields. In outgoing packets, after IPsec destination address fields. In outgoing packets, after IPsec
processing, the HITs are replaced with actual IP addresses, based on processing, the HITs are replaced with actual IP addresses, based on
skipping to change at page 34, line 34 skipping to change at page 35, line 34
source and destination addresses, exactly as defined in the SA. source and destination addresses, exactly as defined in the SA.
This verification MAY be explicit, or it MAY be implicit, for This verification MAY be explicit, or it MAY be implicit, for
example, as a result of prior policy processing. Note that in example, as a result of prior policy processing. Note that in
some implementations there may be no real IP header at this time some implementations there may be no real IP header at this time
but the source and destination addresses may be carried out-of- but the source and destination addresses may be carried out-of-
band. In case the source address is still unassigned, it SHOULD band. In case the source address is still unassigned, it SHOULD
be ensured that the designated inner source address would be be ensured that the designated inner source address would be
selected at a later stage. selected at a later stage.
2. The IP payload (the contents of the packet beyond the IP header) 2. The IP payload (the contents of the packet beyond the IP header)
is wrapped into an ESP header as defined in [RFC4303] Section is wrapped into an ESP header as defined in [RFC4303]
3.3. Section 3.3.
3. A new IP header is constructed, replacing the original one. The 3. A new IP header is constructed, replacing the original one. The
new IP header MUST contain the outer source and destination new IP header MUST contain the outer source and destination
addresses, as defined in the SA. Note that in some addresses, as defined in the SA. Note that in some
implementations there may be no real IP header at this time but implementations there may be no real IP header at this time but
the source and destination addresses may be carried out-of-band. the source and destination addresses may be carried out-of-band.
In the case where the source address must be left unassigned, it In the case where the source address must be left unassigned, it
SHOULD be made sure that the right source address is selected at SHOULD be made sure that the right source address is selected at
a later stage. Other than the addresses, it is RECOMMENDED that a later stage. Other than the addresses, it is RECOMMENDED that
the new IP header copies the fields from the original IP header. the new IP header copies the fields from the original IP header.
skipping to change at page 36, line 43 skipping to change at page 37, line 43
Petri Jokela Petri Jokela
Ericsson Research NomadicLab Ericsson Research NomadicLab
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone: +358 9 299 1 Phone: +358 9 299 1
EMail: petri.jokela@nomadiclab.com EMail: petri.jokela@nomadiclab.com
Robert Moskowitz Robert Moskowitz
ICSAlabs, An Independent Division of Verizon Business Systems Verizon Telcom and Business
1000 Bent Creek Blvd, Suite 200 1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA Mechanicsburg, PA
USA USA
EMail: rgm@icsalabs.com EMail: rgm@icsalabs.com
Jan Melen Jan Melen
Ericsson Research NomadicLab Ericsson Research NomadicLab
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
 End of changes. 39 change blocks. 
160 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/