draft-ietf-hip-rfc5202-bis-06.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 Verizon Intended status: Standards Track Verizon
Expires: January 29, 2015 J. Melen Expires: March 9, 2015 J. Melen
Ericsson Research NomadicLab Ericsson Research NomadicLab
July 28, 2014 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-06 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 36 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 January 29, 2015. This Internet-Draft will expire on March 9, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . 4 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 . . . 6 3.3. Security Association Establishment and Maintenance . . . 6
3.3.1. ESP Security Associations . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 8 3.3.5. Supported Ciphers . . . . . . . . . . . . . . . . . . 8
3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . 10 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. IPsec ESP Transport Format Type . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . 12 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . 13
5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . 12 5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 14 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
skipping to change at page 8, line 41 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 16, line 5 skipping to change at page 16, line 5
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
 End of changes. 10 change blocks. 
12 lines changed or deleted 19 lines changed or added

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