--- 1/draft-ietf-hip-rfc5202-bis-06.txt 2014-09-05 07:14:35.819879478 -0700 +++ 2/draft-ietf-hip-rfc5202-bis-07.txt 2014-09-05 07:14:35.895881354 -0700 @@ -1,22 +1,22 @@ Network Working Group P. Jokela Internet-Draft Ericsson Research NomadicLab Obsoletes: 5202 (if approved) R. Moskowitz Intended status: Standards Track Verizon -Expires: January 29, 2015 J. Melen +Expires: March 9, 2015 J. Melen Ericsson Research NomadicLab - July 28, 2014 + September 5, 2014 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) - draft-ietf-hip-rfc5202-bis-06 + draft-ietf-hip-rfc5202-bis-07 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). This document obsoletes RFC 5202. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -25,21 +25,21 @@ 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 January 29, 2015. + This Internet-Draft will expire on March 9, 2015. Copyright Notice Copyright (c) 2014 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 @@ -56,32 +56,32 @@ 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 3.3.1. ESP Security Associations . . . . . . . . . . . . . . 6 3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . 7 3.3.3. Security Association Management . . . . . . . . . . . 8 3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . 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.4. IPsec and HIP ESP Implementation Considerations . . . . . 9 3.4.1. Data Packet Processing Considerations . . . . . . . . 9 3.4.2. HIP Signaling Packet Considerations . . . . . . . . . 10 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.1.1. IPsec ESP Transport Format Type . . . . . . . . . . . 10 + 4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.1.1. IPsec ESP Transport Format Type . . . . . . . . . . . 11 4.1.2. Setting Up an ESP Security Association . . . . . . . 11 4.1.3. Updating an Existing ESP SA . . . . . . . . . . . . . 12 - 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . 12 - 5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . 12 + 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . 13 + 5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . 13 5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 14 5.1.3. NOTIFICATION Parameter . . . . . . . . . . . . . . . 16 5.2. HIP ESP Security Association Setup . . . . . . . . . . . 16 5.2.1. Setup During Base Exchange . . . . . . . . . . . . . 16 5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . 18 5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 18 5.3.2. Responding to the Rekeying Initialization . . . . . . 19 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 19 5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19 @@ -356,25 +356,32 @@ gets a new outbound SPI from its peer. 3.3.5. Supported Ciphers All HIP implementations MUST support AES-128-CBC and AES-256-CBC [RFC3602]. If the Initiator does not support any of the transforms offered by the Responder, it should abandon the negotiation and inform the peer with a NOTIFY message about a non-supported 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, it MUST be used together with SHA-256 authentication as specified in 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 The Sequence Number field is MANDATORY when ESP is used with HIP. 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 used. This means that each host MUST rekey before its sequence number reaches 2^64. 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. @@ -686,22 +693,22 @@ 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 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-128-CBC with HMAC-SHA-256 and NULL - with HMAC-SHA-256. + Mandatory implementations: AES-128-CBC with HMAC-SHA-256. NULL with + HMAC-SHA-256 SHOULD also be supported (see also Section 3.3.5). Under some conditions, it is possible to use Traffic Flow Confidentiality (TFC) [RFC4303] with ESP in BEET mode. However, the definition of such operation is future work and must be done in a separate specification. 5.1.3. NOTIFICATION Parameter The HIP base specification defines a set of NOTIFICATION error types. The following error types are required for describing errors in ESP