draft-ietf-hip-rfc5202-bis-07.txt   rfc7402.txt 
Network Working Group P. Jokela Internet Engineering Task Force (IETF) P. Jokela
Internet-Draft Ericsson Research NomadicLab Request for Comments: 7402 Ericsson Research NomadicLab
Obsoletes: 5202 (if approved) R. Moskowitz Obsoletes: 5202 R. Moskowitz
Intended status: Standards Track Verizon Category: Standards Track HTT Consulting
Expires: March 9, 2015 J. Melen ISSN: 2070-1721 J. Melen
Ericsson Research NomadicLab Ericsson Research NomadicLab
September 5, 2014 April 2015
Using the Encapsulating Security Payload (ESP) Transport Format with the Using the Encapsulating Security Payload (ESP) Transport Format
Host Identity Protocol (HIP) with the Host Identity Protocol (HIP)
draft-ietf-hip-rfc5202-bis-07
Abstract Abstract
This memo specifies an Encapsulated Security Payload (ESP) based This memo specifies an Encapsulating 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 is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 9, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7402.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document ...............................4
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 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . 9 3.4.1. Data Packet Processing Considerations ..............10
3.4.2. HIP Signaling Packet Considerations . . . . . . . . . 10 3.4.2. HIP Signaling Packet Considerations ................10
4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . 10 4. The Protocol ...................................................11
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 . . . . . . . . . . . . . . . . . . . . 14 5.1.2. ESP_TRANSFORM ......................................15
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 ........................17
5.2.1. Setup During Base Exchange . . . . . . . . . . . . . 16 5.2.1. Setup during Base Exchange .........................17
5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . 18 5.3. HIP ESP Rekeying ..........................................18
5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 18 5.3.1. Initializing Rekeying ..............................19
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 .............................................20
5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19 5.4.1. Unknown SPI ........................................20
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 ......................21
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) ............22
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) ........23
6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 22 6.7. Dropping HIP Associations .................................23
6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . 22 6.8. Initiating ESP SA Rekeying ................................23
6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . 24 6.9. Processing Incoming UPDATE Packets ........................24
6.9.1. Processing UPDATE Packet: No Outstanding 6.9.1. Processing UPDATE Packet: No Outstanding
Rekeying Request . . . . . . . . . . . . . . . . . . 24 Rekeying Request ...................................25
6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 25 6.10. Finalizing Rekeying ......................................26
6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 26 6.11. Processing NOTIFY Packets ................................26
7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 26 7. Keying Material ................................................27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations ........................................27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations ............................................28
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 10. References ....................................................29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1. Normative References .....................................29
11.1. Normative references . . . . . . . . . . . . . . . . . . 28 10.2. Informative References ...................................30
11.2. Informative references . . . . . . . . . . . . . . . . . 29 Appendix A. A Note on Implementation Options ......................32
Appendix A. A Note on Implementation Options . . . . . . . . . . 31 Appendix B. Bound End-to-End Tunnel Mode for ESP ..................32
Appendix B. Bound End-to-End Tunnel mode for ESP . . . . . . . . 31 B.1. Protocol Definition ........................................33
B.1. Protocol definition . . . . . . . . . . . . . . . . . . . 32 B.1.1. Changes to Security Association Data Structures .....33
B.1.1. Changes to Security Association data structures . . . 32 B.1.2. Packet Format .......................................34
B.1.2. Packet format . . . . . . . . . . . . . . . . . . . . 32 B.1.3. Cryptographic Processing ............................36
B.1.3. Cryptographic processing . . . . . . . . . . . . . . 34 B.1.4. IP Header Processing ................................36
B.1.4. IP header processing . . . . . . . . . . . 34 B.1.5. Handling of Outgoing Packets ........................37
B.1.5. Handling of outgoing packets . . . . . . . . . . . . 35 B.1.6. Handling of Incoming Packets ........................38
B.1.6. Handling of incoming packets . . . . . . . . . . . . 36 B.1.7. Handling of IPv4 Options ............................39
B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 36 Acknowledgments ...................................................40
Authors' Addresses ................................................40
1. Introduction 1. Introduction
In the Host Identity Protocol Architecture In the Host Identity Protocol Architecture [HIP-ARCH], hosts are
[I-D.ietf-hip-rfc4423-bis], hosts are identified with public keys. identified with public keys. The Host Identity Protocol (HIP)
The Host Identity Protocol [I-D.ietf-hip-rfc5201-bis] base exchange [RFC7401] base exchange allows any two HIP-supporting hosts to
allows any two HIP-supporting hosts to authenticate each other and to authenticate each other and to create a HIP association between
create a HIP association between themselves. During the base themselves. During the base exchange, the hosts generate a piece of
exchange, the hosts generate a piece of shared keying material using shared keying material using an authenticated Diffie-Hellman
an authenticated Diffie-Hellman exchange. exchange.
The HIP base exchange specification [I-D.ietf-hip-rfc5201-bis] does The HIP base exchange specification [RFC7401] does not describe any
not describe any transport formats or methods for user data to be transport formats or methods for user data to be used during the
used during the actual communication; it only defines that it is actual communication; it only defines that it is mandatory to
mandatory to implement the Encapsulated Security Payload (ESP) implement the Encapsulating Security Payload (ESP) [RFC4303] based
[RFC4303] based transport format and method. This document specifies transport format and method. This document specifies how ESP is used
how ESP is used with HIP to carry actual user data. with HIP to carry actual user data.
To be more specific, this document specifies a set of HIP protocol To be more specific, this document specifies a set of HIP protocol
extensions and their handling. Using these extensions, a pair of ESP extensions and their handling. Using these extensions, a pair of ESP
Security Associations (SAs) is created between the hosts during the Security Associations (SAs) is created between the hosts during the
base exchange. The resulting ESP Security Associations use keys base exchange. The resulting ESP Security Associations use keys
drawn from the keying material (KEYMAT) generated during the base drawn from the keying material (KEYMAT) generated during the base
exchange. After the HIP association and required ESP SAs have been exchange. After the HIP association and required ESP SAs have been
established between the hosts, the user data communication is established between the hosts, the user data communication is
protected using ESP. In addition, this document specifies methods to protected using ESP. In addition, this document specifies methods to
update an existing ESP Security Association. update an existing ESP Security Association.
It should be noted that representations of Host Identity are not It should be noted that representations of Host Identity are not
carried explicitly in the headers of user data packets. Instead, the carried explicitly in the headers of user data packets. Instead, the
ESP Security Parameter Index (SPI) is used to indicate the right host ESP Security Parameter Index (SPI) is used to indicate the right host
context. The SPIs are selected during the HIP ESP setup exchange. context. The SPIs are selected during the HIP ESP setup exchange.
For user data packets, ESP SPIs (in possible combination with IP For user data packets, ESP SPIs (in possible combination with IP
addresses) are used indirectly to identify the host context, thereby addresses) are used indirectly to identify the host context, thereby
avoiding any additional explicit protocol headers. avoiding any additional explicit protocol headers.
HIP and ESP traffic have known issues with middlebox traversal RFC HIP and ESP traffic have known issues with middlebox traversal (RFC
5207 [RFC5207]. Other specifications exist for operating HIP and ESP 5207 [RFC5207]). Other specifications exist for operating HIP and
over UDP (RFC 5770 [RFC5770] is an experimental specification, and ESP over UDP. (RFC 5770 [RFC5770] is an experimental specification,
others are being developed). Middlebox traversal is out of scope for and others are being developed.) Middlebox traversal is out of scope
this document. for this document.
This document obsoletes RFC 5202. This document obsoletes RFC 5202.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Using ESP with HIP 3. Using ESP with HIP
skipping to change at page 5, line 21 skipping to change at page 5, line 21
3.2. Conceptual ESP Packet Processing 3.2. Conceptual ESP Packet Processing
ESP packet processing can be implemented in different ways in HIP. ESP packet processing can be implemented in different ways in HIP.
It is possible to implement it in a way that a standards compliant, It is possible to implement it in a way that a standards compliant,
unmodified IPsec implementation [RFC4303] can be used in conjunction unmodified IPsec implementation [RFC4303] can be used in conjunction
with some additional transport checksum processing above it, and if with some additional transport checksum processing above it, and if
IP addresses are used as indexes to the right host context. IP addresses are used as indexes to the right host context.
When a standards compliant IPsec implementation that uses IP When a standards compliant IPsec implementation that uses IP
addresses in the SPD and Security Association Database (SAD) is used, addresses in the Security Policy Database (SPD) and Security
the packet processing may take the following steps. For outgoing Association Database (SAD) is used, the packet processing may take
packets, assuming that the upper-layer pseudoheader has been built the following steps. For outgoing packets, assuming that the
using IP addresses, the implementation recalculates upper-layer upper-layer pseudo header has been built using IP addresses, the
checksums using Host Identity Tags (HITs) and, after that, changes implementation recalculates upper-layer checksums using Host Identity
the packet source and destination addresses back to corresponding IP Tags (HITs) and, after that, changes the packet source and
addresses. The packet is sent to the IPsec ESP for transport mode destination addresses back to corresponding IP addresses. The packet
handling and from there the encrypted packet is sent to the network. is sent to the IPsec ESP for transport mode handling, and from there
When an ESP packet is received, the packet is first put to the IPsec the encrypted packet is sent to the network. When an ESP packet is
ESP transport mode handling, and after decryption, the source and received, the packet is first put through the IPsec ESP transport
destination IP addresses are replaced with HITs and finally, upper- mode handling, and after decryption, the source and destination IP
layer checksums are verified before passing the packet to the upper addresses are replaced with HITs, and finally, upper-layer checksums
layer. are verified before passing the packet to the upper layer.
An alternative way to implement packet processing is the BEET (Bound An alternative way to implement packet processing is the BEET (Bound
End-to-End Tunnel) mode (see Appendix B). In BEET mode, the ESP End-to-End Tunnel) mode (see Appendix B). In BEET mode, the ESP
packet is formatted as a transport mode packet, but the semantics of packet is formatted as a transport mode packet, but the semantics of
the connection are the same as for tunnel mode. The "outer" the connection are the same as for tunnel mode. The "outer"
addresses of the packet are the IP addresses and the "inner" addresses of the packet are the IP addresses, and the "inner"
addresses are the HITs. For outgoing traffic, after the packet has addresses are the HITs. For outgoing traffic, after the packet has
been encrypted, the packet's IP header is changed to a new one that been encrypted, the packet's IP header is changed to a new one that
contains IP addresses instead of HITs, and the packet is sent to the contains IP addresses instead of HITs, and the packet is sent to the
network. When the ESP packet is received, the SPI value, together network. When the ESP packet is received, the SPI value, together
with the integrity protection, allow the packet to be securely with the integrity protection, allow the packet to be securely
associated with the right HIT pair. The packet header is replaced associated with the right HIT pair. The packet header is replaced
with a new header containing HITs, and the packet is decrypted. BEET with a new header containing HITs, and the packet is decrypted. BEET
mode is completely internal for host and doesn't require that the mode is completely internal for a host and doesn't require that the
corresponding host implements it, instead the corresponding host can corresponding host implement 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 < DST, SPI > value may denote different hosts and contexts at
different points of time, depending on the host that is currently different points of time, depending on the host that is currently
reachable at 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
skipping to change at page 6, line 40 skipping to change at page 6, line 40
this (using SHA1), and then use the high-order 32 bits as the SPI. this (using SHA1), and then use the high-order 32 bits as the SPI.
The selected SPI is communicated to the peer in the third (I2) and 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 fourth (R2) packets of the base HIP exchange. Changes in SPI are
signaled with ESP_INFO parameters. signaled with ESP_INFO parameters.
3.3. Security Association Establishment and Maintenance 3.3. Security Association Establishment and Maintenance
3.3.1. ESP Security Associations 3.3.1. ESP Security Associations
In HIP, ESP Security Associations are setup between the HIP nodes In HIP, ESP Security Associations are set up between the HIP nodes
during the base exchange [I-D.ietf-hip-rfc5201-bis]. Existing ESP during the base exchange [RFC7401]. Existing ESP SAs can be updated
SAs can be updated later using UPDATE messages. The reason for later using UPDATE messages. The reason for updating the ESP SA
updating the ESP SA later can be, for example, a need for rekeying later can be, for example, a need for rekeying the SA because of
the SA because of sequence number rollover. sequence number rollover.
Upon setting up a HIP association, each association is linked to two Upon setting up a HIP association, each association is linked to two
ESP SAs, one for incoming packets and one for outgoing packets. The ESP SAs, one for incoming packets and one for outgoing packets. The
Initiator's incoming SA corresponds with the Responder's outgoing Initiator's incoming SA corresponds with the Responder's outgoing
one, and vice versa. The Initiator defines the SPI for its incoming 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 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 SA-RI, and the corresponding SPI is called SPI-RI. Respectively, the
Responder's incoming SA corresponds with the Initiator's outgoing SA Responder's incoming SA corresponds with the Initiator's outgoing SA
and is called SA-IR, with the SPI being called SPI-IR. and is called SA-IR, with the SPI being called SPI-IR.
skipping to change at page 7, line 18 skipping to change at page 7, line 19
sending out the I2, as explained in Section 6.4. The keys are sending out the I2, as explained in Section 6.4. The keys are
derived from KEYMAT, as defined in Section 7. The Responder creates derived from KEYMAT, as defined in Section 7. The Responder creates
SA-RI as a part of I2 processing; see Section 6.5. SA-RI as a part of I2 processing; see Section 6.5.
The Responder creates SA-IR as a part of I2 processing, before 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 sending out R2; see Section 6.5. The Initiator creates SA-IR when
processing R2; see Section 6.6. processing R2; see Section 6.6.
The initial session keys are drawn from the generated keying The initial session keys are drawn from the generated keying
material, KEYMAT, after the HIP keys have been drawn as specified in material, KEYMAT, after the HIP keys have been drawn as specified in
[I-D.ietf-hip-rfc5201-bis]. [RFC7401].
When the HIP association is removed, the related ESP SAs MUST also be When the HIP association is removed, the related ESP SAs MUST also be
removed. removed.
3.3.2. Rekeying 3.3.2. Rekeying
After the initial HIP base exchange and SA establishment, both hosts After the initial HIP base exchange and SA establishment, both hosts
are in the ESTABLISHED state. There are no longer Initiator and are in the ESTABLISHED state. There are no longer Initiator and
Responder roles and the association is symmetric. In this Responder roles, and the association is symmetric. In this
subsection, the party that initiates the rekey procedure is denoted subsection, the party that initiates the rekey procedure is denoted
with I' and the peer with R'. with I' and the peer with R'.
An existing HIP-created ESP SA may need updating during the lifetime An existing HIP-created ESP SA may need updating during the lifetime
of the HIP association. This document specifies the rekeying of an of the HIP association. This document specifies the rekeying of an
existing HIP-created ESP SA, using the UPDATE message. The ESP_INFO existing HIP-created ESP SA, using the UPDATE message. The ESP_INFO
parameter introduced above is used for this purpose. parameter introduced above is used for this purpose.
I' initiates the ESP SA updating process when needed (see I' initiates the ESP SA updating process when needed (see
Section 6.8). It creates an UPDATE packet with required information Section 6.8). It creates an UPDATE packet with required information
and sends it to the peer node. The old SAs are still in use, local and sends it to the peer node. The old SAs are still in use, local
policy permitting. policy permitting.
R', after receiving and processing the UPDATE (see Section 6.9), R', after receiving and processing the UPDATE (see Section 6.9),
generates new SAs: SA-I'R' and SA-R'I'. It does not take the new generates new SAs: SA-I'R' and SA-R'I'. It does not take the new
outgoing SA into use, but still uses the old one, so there outgoing SA into use, but still uses the old one, so there
temporarily exists two SA pairs towards the same peer host. The SPI temporarily exist two SA pairs towards the same peer host. The SPI
for the new outgoing SA, SPI-R'I', is specified in the received for the new outgoing SA, SPI-R'I', is specified in the received
ESP_INFO parameter in the UPDATE packet. For the new incoming SA, R' ESP_INFO parameter in the UPDATE packet. For the new incoming SA, R'
generates the new SPI value, SPI-I'R', and includes it in the generates the new SPI value, SPI-I'R', and includes it in the
response UPDATE packet. response UPDATE packet.
When I' receives a response UPDATE from R', it generates new SAs, as When I' receives a response UPDATE from R', it generates new SAs, as
described in Section 6.9: SA-I'R' and SA-R'I'. It starts using the described in Section 6.9: SA-I'R' and SA-R'I'. It starts using the
new outgoing SA immediately. new outgoing SA immediately.
R' starts using the new outgoing SA when it receives traffic on the R' starts using the new outgoing SA when it receives traffic on the
skipping to change at page 8, line 28 skipping to change at page 8, line 28
HITs since a system can have more than one HIT). An inactivity timer HITs since a system can have more than one HIT). An inactivity timer
is RECOMMENDED for all SAs. If the state dictates the deletion of an is RECOMMENDED for all SAs. If the state dictates the deletion of an
SA, a timer is set to allow for any late arriving packets. SA, a timer is set to allow for any late arriving packets.
3.3.4. Security Parameter Index (SPI) 3.3.4. Security Parameter Index (SPI)
The SPIs in ESP provide a simple compression of the HIP data from all The SPIs in ESP provide a simple compression of the HIP data from all
packets after the HIP exchange. This does require a per HIT-pair packets after the HIP exchange. This does require a per HIT-pair
Security Association (and SPI), and a decrease of policy granularity Security Association (and SPI), and a decrease of policy granularity
over other Key Management Protocols like Internet Key Exchange (IKE) over other Key Management Protocols like Internet Key Exchange (IKE)
[RFC5996]. [RFC7296].
When a host updates the ESP SA, it provides a new inbound SPI to and When a host updates the ESP SA, it provides a new inbound SPI to and
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 SHOULD 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 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 AES-GMAC are examples), the suite MUST NOT be accepted if offered by
the peer unless the local policy configuration regarding the peer the peer unless the local policy configuration regarding the peer
host is explicitly set to allow an authentication-only mode. This is host is explicitly set to allow an authentication-only mode. This is
to prevent sessions from being downgraded to an authentication-only to prevent sessions from being downgraded to an authentication-only
mode when one side's policy requests privacy for the session. mode when one side's policy requests privacy for the session.
3.3.6. Sequence Number 3.3.6. Sequence Number
skipping to change at page 9, line 46 skipping to change at page 9, line 46
keying protocols. When the HIP implementation selects the SPI value, keying protocols. When the HIP implementation selects the SPI value,
it may lead to a collision if not implemented properly. To avoid the it may lead to a collision if not implemented properly. To avoid the
possibility for a collision, the HIP implementation MUST ensure that possibility for a collision, the HIP implementation MUST ensure that
the SPI values used for HIP SAs are not used for IPsec or other SAs, the SPI values used for HIP SAs are not used for IPsec or other SAs,
and vice versa. and vice versa.
Incoming packets using an SA that is not negotiated by HIP MUST NOT 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 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 the correct SA for packet decryption and MUST be used to
identify that the packet has an upper-layer checksum that is identify that the packet has an upper-layer checksum that is
calculated as specified in [I-D.ietf-hip-rfc5201-bis]. calculated as specified in [RFC7401].
3.4.1. Data Packet Processing Considerations 3.4.1. Data Packet Processing Considerations
For outbound traffic, the SPD or (coordinated) SPDs if there are two 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 -- one for HIP and one for IPsec) MUST ensure that packets intended
HIP processing are given a HIP-enabled SA and that packets intended for HIP processing are given a HIP-enabled SA and that packets
for IPsec processing are given an IPsec-enabled SA. The SP then MUST intended for IPsec processing are given an IPsec-enabled SA. The SP
be bound to the matching SA and non-HIP packets will not be processed then MUST be bound to the matching SA, and non-HIP packets will not
by this SA. Data originating from a socket that is not using HIP be processed by this SA. Data originating from a socket that is not
MUST NOT have checksum recalculated (as described in Section 3.2, using HIP MUST NOT have the checksum recalculated (as described in
paragraph 2) and data MUST NOT be passed to the SP or SA created by Section 3.2, paragraph 2), and data MUST NOT be passed to the SP or
the HIP. SA created by HIP.
It is possible that in case of overlapping policies, the outgoing It is possible that in the case of overlapping policies, the outgoing
packet would be handled both by the IPsec and HIP. In this case, it packet would be handled by both IPsec and HIP. In this case, it is
is possible that the HIP association is end-to-end, while the IPsec possible that the HIP association is end to end, while the IPsec SA
SA is for encryption between the HIP host and a Security Gateway. In is for encryption between the HIP host and a security gateway. In
case of a Security Gateway ESP association, the ESP uses always the case of a security gateway ESP association, the ESP always uses
tunnel mode. tunnel mode.
In case of IPsec tunnel mode, it is hard to see during the HIP SA In the case of IPsec tunnel mode, it is hard to see during the HIP SA
processing if the IPsec ESP SA has the same final destination. Thus, processing if the IPsec ESP SA has the same final destination. Thus,
traffic MUST be encrypted both with the HIP ESP SA and with the IPsec traffic MUST be encrypted with both the HIP ESP SA and the IPsec SA
SA when the IPsec ESP SA is used in tunnel mode. when the IPsec ESP SA is used in tunnel mode.
In case of IPsec transport mode, the connection end-points are the In the case of IPsec transport mode, the connection endpoints are the
same. However, for HIP data packets it is not possible to avoid HIP same. However, for HIP data packets it is not possible to avoid HIP
SA processing, while mapping the HIP data packet's IP addresses to SA processing, while mapping the HIP data packet's IP addresses to
the corresponding HITs requires SPI values from the ESP header. In the corresponding HITs requires SPI values from the ESP header. In
case of transport mode IPsec SA, the IPsec encryption MAY be skipped the case of a transport mode IPsec SA, the IPsec encryption MAY be
to avoid double encryption, if the local policy allows. skipped to avoid double encryption, if the local policy allows.
3.4.2. HIP Signaling Packet Considerations 3.4.2. HIP Signaling Packet Considerations
In general, HIP signaling packets should follow the same processing In general, HIP signaling packets should follow the same processing
as HIP data packets. as HIP data packets.
In case of IPsec tunnel mode, the HIP signaling packets are always In the case of IPsec tunnel mode, the HIP signaling packets are
encrypted using IPsec ESP SA. Note, that this hides the HIP always encrypted using an IPsec ESP SA. Note that this hides the HIP
signaling packets from the eventual HIP middle boxes on the path signaling packets from the eventual HIP middleboxes on the path
between the originating host and the Security Gateway. between the originating host and the security gateway.
In case of IPsec transport mode, the HIP signaling packets MAY skip In the case of IPsec transport mode, the HIP signaling packets MAY
the IPsec ESP SA encryption if the local policy allows. This allows skip the IPsec ESP SA encryption if the local policy allows. This
the eventual HIP middle boxes to handle the passing HIP signaling allows the eventual HIP middleboxes to handle the passing HIP
packets. signaling packets.
4. The Protocol 4. The Protocol
In this section, the protocol for setting up an ESP association to be In this section, the protocol for setting up an ESP association to be
used with HIP association is described. used with a HIP association is described.
4.1. ESP in HIP 4.1. ESP in HIP
4.1.1. IPsec ESP Transport Format Type 4.1.1. IPsec ESP Transport Format Type
The HIP handshake signals the TRANSPORT_FORMAT_LIST parameter in the The HIP handshake signals the TRANSPORT_FORMAT_LIST parameter in the
R1 and I2 messages. This parameter contains a list of the supported R1 and I2 messages. This parameter contains a list of the supported
HIP transport formats of the sending host in the order of preference. HIP transport formats of the sending host, in the order of
The transport format type for IPsec ESP is the type number of the preference. The transport format type for IPsec ESP is the type
ESP_TRANSFORM parameter, i.e., 4095. number of the ESP_TRANSFORM parameter, i.e., 4095.
4.1.2. Setting Up an ESP Security Association 4.1.2. Setting Up an ESP Security Association
Setting up an ESP Security Association between hosts using HIP Setting up an ESP Security Association between hosts using HIP is
consists of three messages passed between the hosts. The parameters performed by including parameters in the last three messages (R1, I2,
are included in R1, I2, and R2 messages during base exchange. and R2 messages) of the four-message HIP base exchange.
Initiator Responder Initiator Responder
I1 I1
----------------------------------> ---------------------------------->
R1: ESP_TRANSFORM R1: ESP_TRANSFORM
<---------------------------------- <----------------------------------
I2: ESP_TRANSFORM, ESP_INFO I2: ESP_TRANSFORM, ESP_INFO
----------------------------------> ---------------------------------->
R2: ESP_INFO R2: ESP_INFO
<---------------------------------- <----------------------------------
Setting up an ESP Security Association between HIP hosts requires
three messages to exchange the information that is required during an
ESP communication.
The R1 message contains the ESP_TRANSFORM parameter, in which the The R1 message contains the ESP_TRANSFORM parameter, in which the
sending host defines the possible ESP transforms it is willing to use sending host defines the possible ESP transforms it is willing to use
for the ESP SA. for the ESP SA.
Including the ESP_TRANSFORM parameter in the R1 message adds clarity Including the ESP_TRANSFORM parameter in the R1 message adds clarity
to the TRANSPORT_FORMAT_LIST, but may initiate negotiations for to the TRANSPORT_FORMAT_LIST but may initiate negotiations for
possibly unselected transforms. However, resource-constrained possibly unselected transforms. However, resource-constrained
devices will most likely restrict support to a single transform for devices will most likely restrict support to a single transform for
the sake of minimizing ROM overhead and the additional parameter adds the sake of minimizing ROM overhead, and the additional parameter
negligible overhead with unconstrained devices. adds negligible overhead with unconstrained devices.
The I2 message contains the response to an ESP_TRANSFORM received in The I2 message contains the response to an ESP_TRANSFORM received in
the R1 message. The sender must select one of the proposed ESP the R1 message. The sender must select one of the proposed ESP
transforms from the ESP_TRANSFORM parameter in the R1 message and transforms from the ESP_TRANSFORM parameter in the R1 message and
include the selected one in the ESP_TRANSFORM parameter in the I2 include the selected one in the ESP_TRANSFORM parameter in the I2
packet. In addition to the transform, the host includes the ESP_INFO packet. In addition to the transform, the host includes the ESP_INFO
parameter containing the SPI value to be used by the peer host. parameter containing the SPI value to be used by the peer host.
In the R2 message, the ESP SA setup is finalized. The packet In the R2 message, the ESP SA setup is finalized. The packet
contains the SPI information required by the Initiator for the ESP contains the SPI information required by the Initiator for the
SA. ESP SA.
4.1.3. Updating an Existing ESP SA 4.1.3. Updating an Existing ESP SA
The update process is accomplished using two messages. The HIP The update process is accomplished using three messages. The HIP
UPDATE message is used to update the parameters of an existing ESP UPDATE message is used to update the parameters of an existing ESP
SA. The UPDATE mechanism and message is defined in SA. The UPDATE mechanism and message are defined in [RFC7401], and
[I-D.ietf-hip-rfc5201-bis], and the additional parameters for the additional parameters for updating an existing ESP SA are
updating an existing ESP SA are described here. described here.
The following picture shows a typical exchange when an existing ESP The following picture shows a typical exchange when an existing ESP
SA is updated. Messages include SEQ and ACK parameters required by SA is updated. Messages include SEQ and ACK parameters required by
the UPDATE mechanism. the UPDATE mechanism.
H1 H2 H1 H2
UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN] UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN]
-----------------------------------------------------> ----------------------------------------------------->
UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN] UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN]
<----------------------------------------------------- <-----------------------------------------------------
UPDATE: ACK UPDATE: ACK
-----------------------------------------------------> ----------------------------------------------------->
The host willing to update the ESP SA creates and sends an UPDATE The host willing to update the ESP SA creates and sends an UPDATE
message. The message contains the ESP_INFO parameter containing the 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 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 index value for the keying material, giving the point from where the
next keys will be drawn. If new keying material must be generated, next keys will be drawn. If new keying material must be generated,
the UPDATE message will also contain the DIFFIE_HELLMAN parameter the UPDATE message will also contain the DIFFIE_HELLMAN parameter
defined in [I-D.ietf-hip-rfc5201-bis]. defined in [RFC7401].
The host receiving the UPDATE message requesting update of an The host receiving the UPDATE message requesting update of an
existing ESP SA MUST reply with an UPDATE message. In the reply existing ESP SA MUST reply with an UPDATE message. In the reply
message, the host sends the ESP_INFO parameter containing the message, the host sends the ESP_INFO parameter containing the
corresponding values: old SPI, new SPI, and the keying material corresponding values: old SPI, new SPI, and the keying material
index. If the incoming UPDATE contained a DIFFIE_HELLMAN parameter, index. If the incoming UPDATE contained a DIFFIE_HELLMAN parameter,
the reply packet MUST also contain a DIFFIE_HELLMAN parameter. the reply packet MUST also contain a DIFFIE_HELLMAN parameter.
5. Parameter and Packet Formats 5. Parameter and Packet Formats
In this section, new and modified HIP parameters are presented, as In this section, new and modified HIP parameters are presented, as
well as modified HIP packets. well as modified HIP packets.
5.1. New Parameters 5.1. New Parameters
Two new HIP parameters are defined for setting up ESP transport Two HIP parameters are defined for setting up ESP transport format
format associations in HIP communication and for rekeying existing associations in HIP communication and for rekeying existing ones.
ones. Also, the NOTIFICATION parameter, described in Also, the NOTIFICATION parameter, described in [RFC7401], has two
[I-D.ietf-hip-rfc5201-bis], has two new error parameters. error values defined for this specification.
Parameter Type Length Data Parameter Type Length Data
ESP_INFO 65 12 Remote's old SPI, ESP_INFO 65 12 Remote's old SPI,
new SPI, and other info new SPI, and other info
ESP_TRANSFORM 4095 variable ESP Encryption and ESP_TRANSFORM 4095 variable ESP Encryption and
Authentication Transform(s) Authentication Transform(s)
5.1.1. ESP_INFO 5.1.1. ESP_INFO
During the establishment and update of an ESP SA, the SPI value of During the establishment and update of an ESP SA, the SPI value of
both hosts must be transmitted between the hosts. In addition, hosts both hosts must be transmitted between the hosts. In addition, hosts
need the index value to the KEYMAT when they are drawing keys from need the index value to the KEYMAT when they are drawing keys from
the generated keying material. The ESP_INFO parameter is used to the generated keying material. The ESP_INFO parameter is used to
transmit the SPI values and the KEYMAT index information between the transmit the SPI values and the KEYMAT index information between the
hosts. hosts.
During the initial ESP SA setup, the hosts send the SPI value that During the initial ESP SA setup, the hosts send the SPI value that
they want the peer to use when sending ESP data to them. The value they want the peer to use when sending ESP data to them. The value
is set in the NEW SPI field of the ESP_INFO parameter. In the is set in the NEW SPI field of the ESP_INFO parameter. In the
initial setup, an old value for the SPI does not exist, thus the OLD initial setup, an old value for the SPI does not exist; thus, the OLD
SPI value field is set to zero. The OLD SPI field value may also be SPI field value is set to zero. The OLD SPI field value may also be
zero when additional SAs are set up between HIP hosts, e.g., in case zero when additional SAs are set up between HIP hosts, e.g., in the
of multihomed HIP hosts [RFC5206]. However, such use is beyond the case of multihomed HIP hosts [RFC5206]. However, such use is beyond
scope of this specification. the scope of this specification.
The KEYMAT index value points to the place in the KEYMAT from where The KEYMAT index value points to the place in the KEYMAT from where
the keying material for the ESP SAs is drawn. The KEYMAT index value the keying material for the ESP SAs is drawn. The KEYMAT index value
is zero only when the ESP_INFO is sent during a rekeying process and is zero only when the ESP_INFO is sent during a rekeying process and
new keying material is generated. new keying material is generated.
During the life of an SA established by HIP, one of the hosts may During the life of an SA established by HIP, one of the hosts may
need to reset the Sequence Number to one and rekey. The reason for need to reset the Sequence Number to one and rekey. The reason for
rekeying might be an approaching sequence number wrap in ESP, or a rekeying might be an approaching sequence number wrap in ESP, or a
local policy on use of a key. Rekeying ends the current SAs and local policy on the use of a key. Rekeying ends the current SAs and
starts new ones on both peers. starts new ones on both peers.
During the rekeying process, the ESP_INFO parameter is used to During the rekeying process, the ESP_INFO parameter is used to
transmit the changed SPI values and the keying material index. transmit the changed SPI values and the keying material index.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | KEYMAT Index | | Reserved | KEYMAT Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLD SPI | | OLD SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEW SPI | | NEW SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65 Type 65
Length 12 Length 12
KEYMAT Index Index, in bytes, where to continue to draw ESP keys KEYMAT Index index, in bytes, where to continue to draw ESP keys
from KEYMAT. If the packet includes a new from KEYMAT. If the packet includes a new
Diffie-Hellman key and the ESP_INFO is sent in an Diffie-Hellman key and the ESP_INFO is sent in an
UPDATE packet, the field MUST be zero. If the UPDATE packet, the field MUST be zero. If the
ESP_INFO is included in base exchange messages, the ESP_INFO is included in base exchange messages, the
KEYMAT Index must have the index value of the point KEYMAT Index must have the index value of the point
from where the ESP SA keys are drawn. Note that from where the ESP SA keys are drawn. Note that
the length of this field limits the amount of the length of this field limits the amount of
keying material that can be drawn from KEYMAT. If keying material that can be drawn from KEYMAT. If
that amount is exceeded, the packet MUST contain that amount is exceeded, the packet MUST contain
a new Diffie-Hellman key. a new Diffie-Hellman key.
skipping to change at page 15, line 17 skipping to change at page 15, line 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Suite ID #1 | | Reserved | Suite ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite ID #2 | Suite ID #3 | | Suite ID #2 | Suite ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite ID #n | Padding | | Suite ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4095 Type 4095
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
padding padding.
Reserved zero when sent, ignored when received Reserved zero when sent, ignored when received.
Suite ID defines the ESP Suite to be used Suite ID defines the ESP Suite to be used.
The following Suite IDs can be used: The following Suite IDs can be used:
Suite ID Value Suite ID Value
RESERVED 0 RESERVED 0 [RFC7402]
AES-128-CBC with HMAC-SHA1 1 [RFC3602], [RFC2404] AES-128-CBC with HMAC-SHA1 1 [RFC3602], [RFC2404]
DEPRECATED 2 DEPRECATED 2 [RFC7402]
DEPRECATED 3 DEPRECATED 3 [RFC7402]
DEPRECATED 4 DEPRECATED 4 [RFC7402]
DEPRECATED 5 DEPRECATED 5 [RFC7402]
DEPRECATED 6 DEPRECATED 6 [RFC7402]
NULL 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 an 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. NULL with Mandatory implementations: AES-128-CBC with HMAC-SHA-256. NULL with
HMAC-SHA-256 SHOULD also be supported (see also Section 3.3.5). 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 an operation is left for future work and must be
separate specification. done in a 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
Transform crypto suites during negotiation. Transform crypto suites during negotiation.
NOTIFICATION PARAMETER - ERROR TYPES Value NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ ----- ------------------------------------ -----
skipping to change at page 16, line 38 skipping to change at page 17, line 11
The ESP Transform crypto suite does not correspond to The ESP Transform crypto suite does not correspond to
one offered by the Responder. one offered by the Responder.
5.2. HIP ESP Security Association Setup 5.2. HIP ESP Security Association Setup
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,
the order of preference. All implementations MUST support AES- in the order of preference. All implementations MUST support
128-CBC [RFC3602] with HMAC-SHA-256 [RFC4868]. AES-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 24 skipping to change at page 17, line 40
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- All implementations MUST support AES-128-CBC [RFC3602] with
SHA-256 [RFC4868]. HMAC-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 19, line 40 skipping to change at page 20, line 8
IP ( HIP ( ESP_INFO, IP ( HIP ( ESP_INFO,
SEQ, SEQ,
ACK, ACK,
[ DIFFIE_HELLMAN, ] [ DIFFIE_HELLMAN, ]
HMAC, HMAC,
HIP_SIGNATURE ) ) HIP_SIGNATURE ) )
5.4. ICMP Messages 5.4. ICMP Messages
ICMP message handling is mainly described in the HIP base ICMP message handling is mainly described in the HIP base
specification [I-D.ietf-hip-rfc5201-bis]. In this section, we specification [RFC7401]. In this section, we describe the actions
describe the actions related to ESP security associations. related to ESP security associations.
5.4.1. Unknown SPI 5.4.1. Unknown SPI
If a HIP implementation receives an ESP packet that has an If a HIP implementation receives an ESP packet that has an
unrecognized SPI number, it MAY respond (subject to rate limiting the unrecognized SPI number, it MAY respond (subject to rate limiting the
responses) with an ICMP packet with type "Parameter Problem", with responses) with an ICMP packet with type "Parameter Problem", with
the pointer pointing to the beginning of SPI field in the ESP header. the pointer pointing to the beginning of the SPI field in the ESP
header.
6. Packet Processing 6. Packet Processing
Packet processing is mainly defined in the HIP base specification Packet processing is mainly defined in the HIP base specification
[I-D.ietf-hip-rfc5201-bis]. This section describes the changes and [RFC7401]. This section describes the changes and new requirements
new requirements for packet handling when the ESP transport format is for packet handling when the ESP transport format is used. Note that
used. Note that all HIP packets (currently protocol 139) MUST bypass all HIP packets (currently protocol 139) MUST bypass ESP processing.
ESP processing.
6.1. Processing Outgoing Application Data 6.1. Processing Outgoing Application Data
Outgoing application data handling is specified in the HIP base Outgoing application data handling is specified in the HIP base
specification [I-D.ietf-hip-rfc5201-bis]. When the ESP transport specification [RFC7401]. When the ESP transport format is used, and
format is used, and there is an active HIP session for the given < there is an active HIP session for the given < source, destination >
source, destination > HIT pair, the outgoing datagram is protected HIT pair, the outgoing datagram is protected using the ESP security
using the ESP security association. The following additional steps association. The following additional steps define the conceptual
define the conceptual processing rules for outgoing ESP protected processing rules for outgoing ESP protected datagrams.
datagrams.
1. Detect the proper ESP SA using the HITs in the packet header or 1. Detect the proper ESP SA using the HITs in the packet header or
other information associated with the packet other information associated with the packet.
2. Process the packet normally, as if the SA was a transport mode 2. Process the packet normally, as if the SA was a transport
SA. mode SA.
3. Ensure that the outgoing ESP protected packet has proper IP 3. Ensure that the outgoing ESP protected packet has proper IP
header format depending on the used IP address family, and proper header format, depending on the used IP address family, and
IP addresses in its IP header, e.g., by replacing HITs left by proper IP addresses in its IP header, e.g., by replacing HITs
the ESP processing. Note that this placement of proper IP left by the ESP processing. Note that this placement of proper
addresses MAY also be performed at some other point in the stack, IP addresses MAY also be performed at some other point in the
e.g., before ESP processing. stack, e.g., before ESP processing.
6.2. Processing Incoming Application Data 6.2. Processing Incoming Application Data
Incoming HIP user data packets arrive as ESP protected packets. In Incoming HIP user data packets arrive as ESP protected packets. In
the usual case, the receiving host has a corresponding ESP security the usual case, the receiving host has a corresponding ESP security
association, identified by the SPI and destination IP address in the association, identified by the SPI and destination IP address in the
packet. However, if the host has crashed or otherwise lost its HIP packet. However, if the host has crashed or otherwise lost its HIP
state, it may not have such an SA. state, it may not have such an SA.
The basic incoming data handling is specified in the HIP base The basic incoming data handling is specified in the HIP base
skipping to change at page 21, line 23 skipping to change at page 21, line 41
before replacing the addresses with HITs (such that the transport before replacing the addresses with HITs (such that the transport
checksum will pass if there are no errors). checksum will pass if there are no errors).
3. The transformed packet is next processed normally by ESP, as if 3. The transformed packet is next processed normally by ESP, as if
the packet were a transport mode packet. The packet may be the packet were a transport mode packet. The packet may be
dropped by ESP, as usual. In a typical implementation, the dropped by ESP, as usual. In a typical implementation, the
result of successful ESP decryption and verification is a result of successful ESP decryption and verification is a
datagram with the associated HITs as source and destination. datagram with the associated HITs as source and destination.
4. The datagram is delivered to the upper layer. Demultiplexing the 4. The datagram is delivered to the upper layer. Demultiplexing the
datagram to the right upper layer socket is performed as usual, datagram to the right upper-layer socket is performed as usual,
except that the HITs are used in place of IP addresses during the except that the HITs are used in place of IP addresses during the
demultiplexing. demultiplexing.
6.3. HMAC and SIGNATURE Calculation and Verification 6.3. HMAC and SIGNATURE Calculation and Verification
The new HIP parameters described in this document, ESP_INFO and The new HIP parameters described in this document, ESP_INFO and
ESP_TRANSFORM, must be protected using HMAC and signature ESP_TRANSFORM, must be protected using HMAC and signature
calculations. In a typical implementation, they are included in R1, calculations. In a typical implementation, they are included in R1,
I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as
described in [I-D.ietf-hip-rfc5201-bis]. described in [RFC7401].
6.4. Processing Incoming ESP SA Initialization (R1) 6.4. Processing Incoming ESP SA Initialization (R1)
The ESP SA setup is initialized in the R1 message. The receiving The ESP SA setup is initialized in the R1 message. The receiving
host (Initiator) selects one of the ESP transforms from the presented host (Initiator) selects one of the ESP transforms from the presented
values. If no suitable value is found, the negotiation is values. If no suitable value is found, the negotiation is
terminated. The selected values are subsequently used when terminated. The selected values are subsequently used when
generating and using encryption keys, and when sending the reply generating and using encryption keys, and when sending the reply
packet. If the proposed alternatives are not acceptable to the packet. If the proposed alternatives are not acceptable to the
system, it may abandon the ESP SA establishment negotiation, or it system, it may abandon the ESP SA establishment negotiation, or it
may resend the I1 message within the retry bounds. may resend the I1 message within the retry bounds.
After selecting the ESP transform and performing other R1 processing, After selecting the ESP transform and performing other R1
the system prepares and creates an incoming ESP security association. processing, the system prepares and creates an incoming ESP security
It may also prepare a security association for outgoing traffic, but association. It may also prepare a security association for outgoing
since it does not have the correct SPI value yet, it cannot activate traffic, but since it does not have the correct SPI value yet, it
it. cannot activate it.
6.5. Processing Incoming Initialization Reply (I2) 6.5. Processing Incoming Initialization Reply (I2)
The following steps are required to process the incoming ESP SA The following steps are required to process the incoming ESP SA
initialization replies in I2. The steps below assume that the I2 has 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 been accepted for processing (e.g., has not been dropped due to HIT
comparisons as described in [I-D.ietf-hip-rfc5201-bis]). comparisons as described in [RFC7401]).
o The ESP_TRANSFORM parameter is verified and it MUST contain a 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 single value in the parameter; and it MUST match one of the values
offered in the initialization packet. offered in the initialization packet.
o The ESP_INFO NEW SPI field is parsed to obtain the SPI that will 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 be used for the Security Association outbound from the Responder
and inbound to the Initiator. For this initial ESP SA and inbound to the Initiator. For this initial ESP SA
establishment, the old SPI value MUST be zero. The KEYMAT Index establishment, the old SPI value MUST be zero. The KEYMAT Index
field MUST contain the index value to the KEYMAT from where the field MUST contain the index value to the KEYMAT from where the
ESP SA keys are drawn. ESP SA keys are drawn.
o The system prepares and creates both incoming and outgoing ESP o The system prepares and creates both incoming and outgoing ESP
skipping to change at page 23, line 12 skipping to change at page 23, line 34
A system may initiate the SA rekeying procedure at any time. It MUST 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 initiate a rekey if its incoming ESP sequence counter is about to
overflow. The system MUST NOT replace its keying material until the overflow. The system MUST NOT replace its keying material until the
rekeying packet exchange successfully completes. rekeying packet exchange successfully completes.
Optionally, a system may include a new Diffie-Hellman key for use in Optionally, a system may include a new Diffie-Hellman key for use in
new KEYMAT generation. New KEYMAT generation occurs prior to drawing new KEYMAT generation. New KEYMAT generation occurs prior to drawing
the new keys. the new keys.
The rekeying procedure uses the UPDATE mechanism defined in The rekeying procedure uses the UPDATE mechanism defined in
[I-D.ietf-hip-rfc5201-bis]. Because each peer must update its half [RFC7401]. Because each peer must update its half of the security
of the security association pair (including new SPI creation), the association pair (including new SPI creation), the rekeying process
rekeying process requires that each side both send and receive an requires that each side both send and receive an UPDATE. A system
UPDATE. A system will then rekey the ESP SA when it has sent will then rekey the ESP SA when it has sent parameters to the peer
parameters to the peer and has received both an ACK of the relevant and has received both an ACK of the relevant UPDATE message and
UPDATE message and corresponding peer's parameters. It may be that corresponding peer's parameters. It may be that the ACK and the
the ACK and the required HIP parameters arrive in different UPDATE required HIP parameters arrive in different UPDATE messages. This is
messages. This is always true if a system does not initiate ESP SA always true if a system does not initiate an ESP SA update but
update but responds to an update request from the peer, and may also responds to an update request from the peer, and may also occur if
occur if two systems initiate update nearly simultaneously. In such two systems initiate update nearly simultaneously. In such a case,
a case, if the system has an outstanding update request, it saves the if the system has an outstanding update request, it saves the one
one parameter and waits for the other before completing rekeying. parameter and waits for the other before completing rekeying.
The following steps define the processing rules for initiating an ESP The following steps define the processing rules for initiating an ESP
SA update: SA update:
1. The system decides whether to continue to use the existing KEYMAT 1. The system decides whether to continue to use the existing KEYMAT
or to generate a new KEYMAT. In the latter case, the system MUST or to generate a new KEYMAT. In the latter case, the system MUST
generate a new Diffie-Hellman public key. generate a new Diffie-Hellman public key.
2. The system creates an UPDATE packet, which contains the ESP_INFO 2. The system creates an UPDATE packet, which contains the ESP_INFO
parameter. In addition, the host may include the optional parameter. In addition, the host may include the optional
DIFFIE_HELLMAN parameter. If the UPDATE contains the DIFFIE_HELLMAN parameter. If the UPDATE contains the
DIFFIE_HELLMAN parameter, the KEYMAT Index in the ESP_INFO DIFFIE_HELLMAN parameter, the KEYMAT Index in the ESP_INFO
parameter MUST be zero, and the Diffie-Hellman group ID must be parameter MUST be zero, and the Diffie-Hellman Group ID must be
unchanged from that used in the initial handshake. If the UPDATE unchanged from that used in the initial handshake. If the UPDATE
does not contain DIFFIE_HELLMAN, the ESP_INFO KEYMAT Index MUST does not contain DIFFIE_HELLMAN, the ESP_INFO KEYMAT Index MUST
be greater than or equal to the index of the next byte to be be greater than or equal to the index of the next byte to be
drawn from the current KEYMAT. drawn from the current KEYMAT.
3. The system sends the UPDATE packet. For reliability, the 3. The system sends the UPDATE packet. For reliability, the
underlying UPDATE retransmission mechanism MUST be used. underlying UPDATE retransmission mechanism MUST be used.
4. The system MUST NOT delete its existing SAs, but continue using 4. The system MUST NOT delete its existing SAs, but continue using
them if its policy still allows. The rekeying procedure SHOULD them if its policy still allows. The rekeying procedure SHOULD
skipping to change at page 24, line 19 skipping to change at page 24, line 47
outstanding ESP SA update request for an indefinite time. outstanding ESP SA update request for an indefinite time.
To simplify the state machine, a host MUST NOT generate new UPDATEs To simplify the state machine, a host MUST NOT generate new UPDATEs
while it has an outstanding ESP SA update request, unless it is while it has an outstanding ESP SA update request, unless it is
restarting the update process. restarting the update process.
6.9. Processing Incoming UPDATE Packets 6.9. Processing Incoming UPDATE Packets
When a system receives an UPDATE packet, it must be processed if the When a system receives an UPDATE packet, it must be processed if the
following conditions hold (in addition to the generic conditions following conditions hold (in addition to the generic conditions
specified for UPDATE processing in Section 6.12 of specified for UPDATE processing in Section 6.12 of [RFC7401]):
[I-D.ietf-hip-rfc5201-bis]):
1. A corresponding HIP association must exist. This is usually 1. A corresponding HIP association must exist. This is usually
ensured by the underlying UPDATE mechanism. ensured by the underlying UPDATE mechanism.
2. The state of the HIP association is ESTABLISHED or R2-SENT. 2. The state of the HIP association is ESTABLISHED or R2-SENT.
If the above conditions hold, the following steps define the If the above conditions hold, the following steps define the
conceptual processing rules for handling the received UPDATE packet: conceptual processing rules for handling the received UPDATE packet:
1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the 1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the
skipping to change at page 24, line 50 skipping to change at page 25, line 28
acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN) acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN)
parameters must be saved, and the packet processing continues as parameters must be saved, and the packet processing continues as
specified in Section 6.10. specified in Section 6.10.
6.9.1. Processing UPDATE Packet: No Outstanding Rekeying Request 6.9.1. Processing UPDATE Packet: No Outstanding Rekeying Request
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
handling a received UPDATE packet with the ESP_INFO parameter: handling a received UPDATE packet with the ESP_INFO parameter:
1. The system consults its policy to see if it needs to generate a 1. The system consults its policy to see if it needs to generate a
new Diffie-Hellman key, and generates a new key (with same Group new Diffie-Hellman key, and generates a new key (with same
ID) if needed. The system records any newly generated or Group ID) if needed. The system records any newly generated or
received Diffie-Hellman keys for use in KEYMAT generation upon received Diffie-Hellman keys for use in KEYMAT generation upon
finalizing the ESP SA update. finalizing the ESP SA update.
2. If the system generated a new Diffie-Hellman key in the previous 2. If the system generated a new Diffie-Hellman key in the previous
step, or if it received a DIFFIE_HELLMAN parameter, it sets the step, or if it received a DIFFIE_HELLMAN parameter, it sets the
ESP_INFO KEYMAT Index to zero. Otherwise, the ESP_INFO KEYMAT ESP_INFO KEYMAT Index to zero. Otherwise, the ESP_INFO KEYMAT
Index MUST be greater than or equal to the index of the next byte Index MUST be greater than or equal to the index of the next byte
to be drawn from the current KEYMAT. In this case, it is to be drawn from the current KEYMAT. In this case, it is
RECOMMENDED that the host use the KEYMAT Index requested by the RECOMMENDED that the host use the KEYMAT Index requested by the
peer in the received ESP_INFO. peer in the received ESP_INFO.
3. The system creates an UPDATE packet, which contains an ESP_INFO 3. The system creates an UPDATE packet, which contains an ESP_INFO
parameter and the optional DIFFIE_HELLMAN parameter. This UPDATE parameter and the optional DIFFIE_HELLMAN parameter. This UPDATE
would also typically acknowledge the peer's UPDATE with an ACK would also typically acknowledge the peer's UPDATE with an ACK
parameter, although a separate UPDATE ACK may be sent. parameter, although a separate UPDATE ACK may be sent.
4. The system sends the UPDATE packet and stores any received 4. The system sends the UPDATE packet and stores any received
ESP_INFO and DIFFIE_HELLMAN parameters. At this point, it only ESP_INFO and DIFFIE_HELLMAN parameters. At this point, it only
needs to receive an acknowledgment for the newly sent UPDATE to needs to receive an acknowledgment for the newly sent UPDATE to
finish ESP SA update. In the usual case, the acknowledgment is finish the ESP SA update. In the usual case, the acknowledgment
handled by the underlying UPDATE mechanism. is handled by the underlying UPDATE mechanism.
6.10. Finalizing Rekeying 6.10. Finalizing Rekeying
A system finalizes rekeying when it has both received the A system finalizes rekeying when it has both received the
corresponding UPDATE acknowledgment packet from the peer and it has corresponding UPDATE acknowledgment packet from the peer and
successfully received the peer's UPDATE. The following steps are successfully received the peer's UPDATE. The following steps
taken: are taken:
1. If the received UPDATE messages contain a new Diffie-Hellman key, 1. If the received UPDATE messages contain a new Diffie-Hellman key,
the system has a new Diffie-Hellman key due to initiating ESP SA the system has a new Diffie-Hellman key due to initiating an ESP
update, or both, the system generates a new KEYMAT. If there is SA update, or both, the system generates a new KEYMAT. If there
only one new Diffie-Hellman key, the old existing key is used as is only one new Diffie-Hellman key, the old existing key is used
the other key. as the other key.
2. If the system generated a new KEYMAT in the previous step, it 2. If the system generated a new KEYMAT in the previous step, it
sets the KEYMAT Index to zero, independent of whether the sets the KEYMAT Index to zero, independent of whether the
received UPDATE included a Diffie-Hellman key or not. If the received UPDATE included a Diffie-Hellman key or not. If the
system did not generate a new KEYMAT, it uses the greater KEYMAT system did not generate a new KEYMAT, it uses the greater KEYMAT
Index of the two (sent and received) ESP_INFO parameters. Index of the two (sent and received) ESP_INFO parameters.
3. The system draws keys for new incoming and outgoing ESP SAs, 3. The system draws keys for new incoming and outgoing ESP SAs,
starting from the KEYMAT Index, and prepares new incoming and starting from the KEYMAT Index, and prepares new incoming and
outgoing ESP SAs. The SPI for the outgoing SA is the new SPI outgoing ESP SAs. The SPI for the outgoing SA is the new SPI
value received in an ESP_INFO parameter. The SPI for the value received in an ESP_INFO parameter. The SPI for the
incoming SA was generated when the ESP_INFO was sent to the peer. incoming SA was generated when the ESP_INFO was sent to the peer.
The order of the keys retrieved from the KEYMAT during the The order of the keys retrieved from the KEYMAT during the
rekeying process is similar to that described in Section 7. rekeying process is similar to that described in Section 7. Note
that only IPsec ESP keys are retrieved during the rekeying
Note, that only IPsec ESP keys are retrieved during the rekeying
process, not the HIP keys. process, not the HIP keys.
4. The system starts to send to the new outgoing SA and prepares to 4. The system starts to send to the new outgoing SA and prepares to
start receiving data on the new incoming SA. Once the system start receiving data on the new incoming SA. Once the system
receives data on the new incoming SA, it may safely delete the receives data on the new incoming SA, it may safely delete the
old SAs. old SAs.
6.11. Processing NOTIFY Packets 6.11. Processing NOTIFY Packets
The processing of NOTIFY packets is described in the HIP base The processing of NOTIFY packets is described in the HIP base
skipping to change at page 26, line 44 skipping to change at page 27, line 31
denotes the host with the lower HIT value. When HIT values are denotes the host with the lower HIT value. When HIT values are
compared, they are interpreted as positive (unsigned) 128-bit compared, they are interpreted as positive (unsigned) 128-bit
integers in network byte order. integers in network byte order.
The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 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 exchange. Subsequent rekeys using UPDATE will only draw the four ESP
keys from KEYMAT. Section 6.9 describes the rules for reusing or keys from KEYMAT. Section 6.9 describes the rules for reusing or
regenerating KEYMAT based on the rekeying. regenerating KEYMAT based on the rekeying.
The number of bits drawn for a given algorithm is the "natural" size The number of bits drawn for a given algorithm is the "natural" size
of the keys, as specified in Section 6.5 of of the keys, as specified in Section 6.5 of [RFC7401].
[I-D.ietf-hip-rfc5201-bis].
8. Security Considerations 8. Security Considerations
In this document, the usage of ESP [RFC4303] between HIP hosts to In this document, the usage of ESP [RFC4303] between HIP hosts to
protect data traffic is introduced. The Security Considerations for protect data traffic is introduced. The security considerations for
ESP are discussed in the ESP specification. ESP are discussed in the ESP specification.
There are different ways to establish an ESP Security Association There are different ways to establish an ESP Security Association
between two nodes. This can be done, e.g., using IKE [RFC5996]. between two nodes. This can be done, e.g., using IKE [RFC7296].
This document specifies how the Host Identity Protocol is used to This document specifies how the Host Identity Protocol is used to
establish ESP Security Associations. establish ESP Security Associations.
The following issues are new or have changed from the standard ESP The following issues are new or have changed from the standard ESP
usage: usage:
o Initial keying material generation o Initial keying material generation
o Updating the keying material o Updating the keying material
The initial keying material is generated using the Host Identity The initial keying material is generated using the Host Identity
Protocol [I-D.ietf-hip-rfc5201-bis] using the Diffie-Hellman Protocol [RFC7401] using the Diffie-Hellman procedure. This document
procedure. This document extends the usage of the UPDATE packet, extends the usage of the UPDATE packet, defined in the base
defined in the base specification, to modify existing ESP SAs. The specification, to modify existing ESP SAs. The hosts may rekey,
hosts may rekey, i.e., force the generation of new keying material i.e., force the generation of new keying material using the
using the Diffie-Hellman procedure. The initial setup of ESP SA Diffie-Hellman procedure. The initial setup of ESP SAs between the
between the hosts is done during the base exchange, and the message hosts is done during the base exchange, and the message exchange is
exchange is protected using methods provided by base exchange. protected using methods provided by the base exchange. Changes in
Changes in connection parameters means basically that the old ESP SA connection parameters basically mean that the old ESP SA is removed
is removed and a new one is generated once the UPDATE message and a new one is generated once the UPDATE message exchange has been
exchange has been completed. The message exchange is protected using completed. The message exchange is protected using the HIP
the HIP association keys. Both HMAC and signing of packets is used. association keys. Both HMAC and signing of packets are used.
9. IANA Considerations 9. IANA Considerations
The following changes to the "Host Identity Protocol (HIP) The following changes to the "Host Identity Protocol (HIP)
Parameters" registries are requested. In all cases, the changes Parameters" registries have been made. In all cases, the changes
required are to update the reference from [RFC5202] to this updated the reference from [RFC5202] to this specification.
specification.
This document defines two Parameter Types and two NOTIFY Message This document defines two Parameter Types and two NOTIFY Message
Types for the Host Identity Protocol [I-D.ietf-hip-rfc5201-bis]. Types for the Host Identity Protocol [RFC7401].
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
Section 5.1.3, and they have been added to the Notify Message 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.
10. Acknowledgments
This document was separated from the base "Host Identity Protocol" The parameters and their type numbers are defined in Sections 5.1.1
specification in the beginning of 2005. Since then, a number of and 5.1.2, and they have been added to the "Parameter Types"
people have contributed to the text by providing comments and namespace created by [RFC7401]. No new action regarding these values
modification proposals. The list of people include Tom Henderson, is required by this specification, other than updating the reference
Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. from [RFC5202] to this specification.
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 The new NOTIFICATION error types and their values are defined in
from the base "Host Identity Protocol" specification. Thus, the list Section 5.1.3, and they have been added to the "Notify Message Types"
of people in the Acknowledgments section of that specification is namespace created by [RFC7401]. No new action regarding these values
also valid for this document. Many people have given valuable is required by this specification, other than updating the reference
feedback, and our apologies to anyone whose name is missing. from [RFC5202] to this specification.
11. References Section 5.1.2 of this document defines values for "ESP Transform
Suite IDs", which are registered in a new IANA registry, with an
"IETF Review" registration procedure [RFC5226] for new values.
11.1. Normative references 10. References
[I-D.ietf-hip-rfc5201-bis] 10.1. Normative References
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
hip-rfc5201-bis-14 (work in progress), October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998. ESP and AH", RFC 2404, November 1998,
<http://www.rfc-editor.org/info/rfc2404>.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998. Its Use With IPsec", RFC 2410, November 1998,
<http://www.rfc-editor.org/info/rfc2410>.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September Algorithm and Its Use with IPsec", RFC 3602,
2003. September 2003, <http://www.rfc-editor.org/info/rfc3602>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", RFC (GCM) in IPsec Encapsulating Security Payload (ESP)",
4106, June 2005. RFC 4106, June 2005, <http://www.rfc-editor.org/
info/rfc4106>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
4303, December 2005. RFC 4303, December 2005, <http://www.rfc-editor.org/
info/rfc4303>.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", RFC Mode with IPsec Encapsulating Security Payload (ESP)",
4309, December 2005. RFC 4309, December 2005, <http://www.rfc-editor.org/
info/rfc4309>.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
AES-CMAC Algorithm", RFC 4493, June 2006. AES-CMAC Algorithm", RFC 4493, June 2006,
<http://www.rfc-editor.org/info/rfc4493>.
[RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96
Algorithm and Its Use with IPsec", RFC 4494, June 2006. Algorithm and Its Use with IPsec", RFC 4494, June 2006,
<http://www.rfc-editor.org/info/rfc4494>.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
May 2006. May 2006, <http://www.rfc-editor.org/info/rfc4543>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256,
384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868,
May 2007, <http://www.rfc-editor.org/info/rfc4868>.
11.2. Informative references [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, April 2015, <http://www.rfc-editor.org/
info/rfc7401>.
[I-D.ietf-hip-rfc4423-bis] 10.2. Informative References
Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", draft-ietf-hip-rfc4423-bis-08 (work in
progress), April 2014.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [HIP-ARCH] Moskowitz, R., Ed., and M. Komu, "Host Identity Protocol
1981. Architecture", Work in Progress,
draft-ietf-hip-rfc4423-bis-09, October 2014.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005,
<http://www.rfc-editor.org/info/rfc4301>.
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 5202, April 2008. the Host Identity Protocol (HIP)", RFC 5202, April 2008,
<http://www.rfc-editor.org/info/rfc5202>.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko,
Host Mobility and Multihoming with the Host Identity "End-Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008. Protocol", RFC 5206, April 2008,
<http://www.rfc-editor.org/info/rfc5206>.
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol (HIP) Firewall Traversal Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, April 2008. Communication", RFC 5207, April 2008,
<http://www.rfc-editor.org/info/rfc5207>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions Keranen, "Basic Host Identity Protocol (HIP) Extensions
for Traversal of Network Address Translators", RFC 5770, for Traversal of Network Address Translators", RFC 5770,
April 2010. April 2010, <http://www.rfc-editor.org/info/rfc5770>.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC Kivinen, "Internet Key Exchange Protocol Version 2
5996, September 2010. (IKEv2)", STD 79, RFC 7296, October 2014,
<http://www.rfc-editor.org/info/rfc7296>.
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
the HITs and the SPI. In incoming packets, before IPsec processing, the HITs and the SPI. In incoming packets, before IPsec processing,
the IP addresses are replaced with HITs, based on the SPI in the the IP addresses are replaced with HITs, based on the SPI in the
incoming packet. In such an implementation, all IPsec policies are incoming packet. In such an implementation, all IPsec policies are
based on HITs and the upper layers only see packets with HITs in the based on HITs and the upper layers only see packets with HITs in the
place of IP addresses. Consequently, support of HIP does not place of IP addresses. Consequently, support of HIP does not
conflict with other uses of IPsec as long as the SPI spaces are kept conflict with other uses of IPsec as long as the SPI spaces are kept
separate. Appendix B describes another way to implement this separate. Appendix B describes another way to implement this
specification. specification.
Appendix B. Bound End-to-End Tunnel mode for ESP Appendix B. Bound End-to-End Tunnel Mode for ESP
This section introduces an alternative way of implementing the This section introduces an alternative way of implementing the
necessary functions for HIP ESP transport. Compared to the option of necessary functions for HIP ESP transport. Compared to the option of
implementing the required address rewrites outside of IPsec, BEET has implementing the required address rewrites outside of IPsec, BEET has
one implementation level benefit. In BEET-way of implementing, the one implementation-level benefit. In a BEET-mode-based
address rewriting information is kept in one place, at the SAD. On implementation, the address-rewriting information is kept in one
the other hand, when address rewriting is implemented separately, the place, at the SAD. On the other hand, when address rewriting is
implementation MUST make sure that the information in the SAD and the implemented separately, the implementation MUST make sure that the
separate address rewriting DB are kept in synchrony. As a result, information in the SAD and the information in the separate
the BEET-mode-based way of implementing this specification is address-rewriting database are kept in synchrony. As a result, the
RECOMMENDED over the separate implementation as it keeps the binds BEET-mode-based way of implementing this specification is RECOMMENDED
the identities, encryption and locators tightly together. It should over the separate implementation, as it binds the identities,
be noted that implementing BEET mode doesn't require that encryption, and locators tightly together. It should be noted that
corresponding hosts implement it as the behavior is only visible implementing BEET mode doesn't require that corresponding hosts
internally in a host. implement it, as the behavior is only visible internally in a host.
The BEET mode is a combination of IPsec tunnel and transport modes BEET mode is a combination of IPsec tunnel and transport modes, and
and provides some of the features from both. The HIP uses HITs as it provides some of the features from both. HIP uses HITs as the
the "inner" addresses and IP addresses as "outer" addresses, like IP "inner" addresses and IP addresses as "outer" addresses, like IP
addresses are used in the tunnel mode. Instead of tunneling packets addresses are used in tunnel mode. Instead of tunneling packets
between hosts, a conversion between inner and outer addresses is made between hosts, a conversion between inner and outer addresses is made
at end-hosts and the inner address is never sent on the wire after at end hosts, and the inner address is never sent on the wire after
the initial HIP negotiation. BEET provides IPsec transport mode the initial HIP negotiation. BEET provides IPsec transport mode
syntax (no inner headers) with limited tunnel mode semantics (fixed syntax (no inner headers) with limited tunnel mode semantics (fixed
logical inner addresses - the HITs - and changeable outer IP logical inner addresses -- the HITs -- and changeable outer IP
addresses). addresses).
B.1. Protocol definition B.1. Protocol Definition
In this section we define the exact protocol formats and operations. In this section, we define the exact protocol formats and operations.
B.1.1. Changes to Security Association data structures B.1.1. Changes to Security Association Data Structures
A BEET mode Security Association contains the same data as a regular A BEET mode Security Association contains the same data as a regular
tunnel mode Security Association, with the exception that the inner tunnel mode Security Association, with the exception that the inner
selectors must be single addresses and cannot be subnets. The data selectors must be single addresses and cannot be subnets. The data
includes the following: includes the following:
A pair of inner IP addresses. o A pair of inner IP addresses.
A pair of outer IP addresses. o A pair of outer IP addresses.
Cryptographic keys and other data as defined in RFC4301 [RFC4301] o Cryptographic keys and other data as defined in Section 4.4.2 of
Section 4.4.2. RFC 4301 [RFC4301].
A conforming implementation MAY store the data in a way similar to a A conforming implementation MAY store the data in a way similar to a
regular tunnel mode Security Association. regular tunnel mode Security Association.
Note that in a conforming implementation the inner and outer Note that in a conforming implementation the inner and outer
addresses MAY belong to different address families. All addresses MAY belong to different address families. All
implementations that support both IPv4 and IPv6 SHOULD support both implementations that support both IPv4 and IPv6 SHOULD support both
IPv4-over-IPv6 and IPv6-over-IPv4 tunneling. IPv4-over-IPv6 and IPv6-over-IPv4 tunneling.
B.1.2. Packet format B.1.2. Packet Format
The wire packet format is identical to the ESP transport mode wire The wire packet format is identical to the ESP transport mode wire
format as defined in [RFC4303] Section 3.1.1. However, the resulting format as defined in Section 3.1.1 of [RFC4303]. However, the
packet contains outer IP addresses instead of the inner IP addresses resulting packet contains outer IP addresses instead of the inner IP
received from the upper layer. The construction of the outer headers addresses received from the upper layer. The construction of the
is defined in RFC4301 [RFC4301] Section 5.1.2. The following diagram outer headers is defined in Section 5.1.2 of RFC 4301 [RFC4301]. The
illustrates ESP BEET mode positioning for typical IPv4 and IPv6 following diagram illustrates ESP BEET mode positioning for typical
packets. IPv4 and IPv6 packets.
IPv4 INNER ADDRESSES IPv4 INNER ADDRESSES
-------------------- --------------------
BEFORE APPLYING ESP BEFORE APPLYING ESP
------------------------------ ------------------------------
| inner IP hdr | | | | inner IP hdr | | |
| | TCP | Data | | | TCP | Data |
------------------------------ ------------------------------
skipping to change at page 33, line 13 skipping to change at page 34, line 35
---------------------------------------------------- ----------------------------------------------------
| outer IP hdr | | | | ESP | ESP | | outer IP hdr | | | | ESP | ESP |
| (any options) | ESP | TCP | Data | Trailer | ICV | | (any options) | ESP | TCP | Data | Trailer | ICV |
---------------------------------------------------- ----------------------------------------------------
|<---- encryption ---->| |<---- encryption ---->|
|<-------- integrity ------->| |<-------- integrity ------->|
AFTER APPLYING ESP, OUTER v6 ADDRESSES AFTER APPLYING ESP, OUTER v6 ADDRESSES
------------------------------------------------------ ------------------------------------------------------
| outer | new ext | | | | ESP | ESP | | outer | new ext | | | | ESP | ESP |
| IP hdr | hdrs. | ESP | TCP | Data | Trailer| ICV | | IP hdr | hdrs | ESP | TCP | Data | Trailer| ICV |
------------------------------------------------------ ------------------------------------------------------
|<--- encryption ---->| |<--- encryption ---->|
|<------- integrity ------->| |<------- integrity ------->|
IPv4 INNER ADDRESSES with options IPv4 INNER ADDRESSES with options
--------------------------------- ---------------------------------
BEFORE APPLYING ESP BEFORE APPLYING ESP
------------------------------ ------------------------------
| inner IP hdr | | | | inner IP hdr | | |
skipping to change at page 33, line 38 skipping to change at page 35, line 25
---------------------------------------------------------- ----------------------------------------------------------
| outer IP hdr | | | | | ESP | ESP | | outer IP hdr | | | | | ESP | ESP |
| (any options) | ESP | PH | TCP | Data | Trailer | ICV | | (any options) | ESP | PH | TCP | Data | Trailer | ICV |
---------------------------------------------------------- ----------------------------------------------------------
|<------- encryption ------->| |<------- encryption ------->|
|<----------- integrity ---------->| |<----------- integrity ---------->|
AFTER APPLYING ESP, OUTER v6 ADDRESSES AFTER APPLYING ESP, OUTER v6 ADDRESSES
------------------------------------------------------------ ------------------------------------------------------------
| outer | new ext | | | | | ESP | ESP | | outer | new ext | | | | | ESP | ESP |
| IP hdr | hdrs. | ESP | PH | TCP | Data | Trailer| ICV | | IP hdr | hdrs | ESP | PH | TCP | Data | Trailer| ICV |
------------------------------------------------------------ ------------------------------------------------------------
|<------ encryption ------->| |<------ encryption ------->|
|<---------- integrity ---------->| |<---------- integrity ---------->|
PH Pseudo Header for IPv4 options PH Pseudo Header for IPv4 options
IPv6 INNER ADDRESSES IPv6 INNER ADDRESSES
-------------------- --------------------
BEFORE APPLYING ESP BEFORE APPLYING ESP
------------------------------------------ ------------------------------------------
| | ext hdrs | | | | | ext hdrs | | |
| inner IP hdr | if present | TCP | Data | | inner IP hdr | if present | TCP | Data |
------------------------------------------ ------------------------------------------
AFTER APPLYING ESP, OUTER v6 ADDRESSES AFTER APPLYING ESP, OUTER v6 ADDRESSES
-------------------------------------------------------------- --------------------------------------------------------------
| outer | new ext | | dest | | | ESP | ESP | | outer | new ext | | dest | | | ESP | ESP |
| IP hdr | hdrs. | ESP | opts.| TCP | Data | Trailer | ICV | | IP hdr | hdrs | ESP | opts.| TCP | Data | Trailer | ICV |
-------------------------------------------------------------- --------------------------------------------------------------
|<---- encryption ---->| |<---- encryption ---->|
|<------- integrity ------>| |<------- integrity ------>|
AFTER APPLYING ESP, OUTER v4 ADDRESSES AFTER APPLYING ESP, OUTER v4 ADDRESSES
---------------------------------------------------- ----------------------------------------------------
| outer | | dest | | | ESP | ESP | | outer | | dest | | | ESP | ESP |
| IP hdr | ESP | opts.| TCP | Data | Trailer | ICV | | IP hdr | ESP | opts.| TCP | Data | Trailer | ICV |
---------------------------------------------------- ----------------------------------------------------
|<------- encryption -------->| |<------- encryption -------->|
|<----------- integrity ----------->| |<----------- integrity ----------->|
B.1.3. Cryptographic processing B.1.3. Cryptographic Processing
The outgoing packets MUST be protected exactly as in ESP transport The outgoing packets MUST be protected exactly as in ESP transport
mode [RFC4303]. That is, the upper layer protocol packet is wrapped mode [RFC4303]. That is, the upper-layer protocol packet is wrapped
into an ESP header, encrypted, and authenticated exactly as if into an ESP header, encrypted, and authenticated exactly as if
regular transport mode was used. The resulting ESP packet is subject regular transport mode was used. The resulting ESP packet is subject
to IP header processing as defined in Appendix B.1.4 and to IP header processing as defined in Appendices B.1.4 and B.1.5.
Appendix B.1.5. The incoming ESP protected messages are verified and The incoming ESP protected messages are verified and decrypted
decrypted exactly as if regular transport mode was used. The exactly as if regular transport mode was used. The resulting
resulting clear text packet is subject to IP header processing as cleartext packet is subject to IP header processing as defined in
defined in Appendix B.1.4 and Appendix B.1.6. Appendices B.1.4 and B.1.6.
B.1.4. IP header processing B.1.4. IP Header Processing
The biggest difference between the BEET mode and the other two modes The biggest difference between BEET mode and the other two modes is
is in IP header processing. In the regular transport mode the IP in IP header processing. In the regular transport mode, the IP
header is kept intact. In the regular tunnel mode an outer IP header header is kept intact. In the regular tunnel mode, an outer IP
is created on output and discarded on input. In the BEET mode the IP header is created on output and discarded on input. In BEET mode,
header is replaced with another one on both input and output. the IP header is replaced with another one on both input and output.
On the BEET mode output side, the IP header processing MUST first On the BEET mode output side, the IP header processing MUST first
ensure that the IP addresses in the original IP header contain the ensure that the IP addresses in the original IP header contain the
inner addresses as specified in the SA. This MAY be ensured by inner addresses as specified in the SA. This MAY be ensured by
proper policy processing, and it is possible that no checks are proper policy processing, and it is possible that no checks are
needed at the SA processing time. Once the IP header has been needed at the time of SA processing. Once the IP header has been
verified to contain the right IP inner addresses, it is discarded. A verified to contain the right IP inner addresses, it is discarded. A
new IP header is created, using the discarded inner header as a hint new IP header is created, using the fields of the discarded inner
for other fields but the IP addresses. The IP addresses in the new header (except the IP addresses) to populate the fields of the new
header MUST be the outer tunnel addresses. outer header. The IP addresses in the new header MUST be the outer
tunnel addresses.
On input side, the received IP header is simply discarded. Since the On the input side, the received IP header is simply discarded. Since
packet has been decrypted and verified, no further checks are the packet has been decrypted and verified, no further checks are
necessary. A new IP header, corresponding to a tunnel mode inner necessary. A new IP header corresponding to a BEET mode inner header
header, is created, using the discarded outer header as a hint for is created, using the fields of the discarded outer header (except
other fields but the IP addresses. The IP addresses in the new the IP addresses) to populate the fields of the new inner header.
header MUST be the inner addresses. The IP addresses in the new header MUST be the inner addresses.
As the outer header fields are used as hint for creating inner As the outer header fields are used as a hint for creating the inner
header, it must be noted that inner header differs as compared to header, it must be noted that the inner header differs as compared to
tunnel-mode inner header. In BEET mode the inner header will have a tunnel mode inner header. In BEET mode, the inner header will have
the TTL, DF-bit and other option values from the outer header. The the Time to Live (TTL), Don't Fragment (DF) bit, and other option
TTL, DF-bit and other option values of the inner header MUST be values from the outer header. The TTL, DF bit, and other option
processed by the stack. values of the inner header MUST be processed by the stack.
B.1.5. Handling of outgoing packets B.1.5. Handling of Outgoing Packets
The outgoing BEET mode packets are processed as follows: The outgoing BEET mode packets are processed as follows:
1. The system MUST verify that the IP header contains the inner 1. The system MUST verify that the IP header contains the inner
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. If the source address is still unassigned, it SHOULD be
be ensured that the designated inner source address would 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] is wrapped into an ESP header as defined in Section 3.3 of
Section 3.3. [RFC4303].
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 ensured that the right source address is selected at a
a later stage. Other than the addresses, it is RECOMMENDED that 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.
4. If there are any IPv4 options in the original packet, it is 4. If there are any IPv4 options in the original packet, it is
RECOMMENDED that they are discarded. If the inner header RECOMMENDED that they are discarded. If the inner header
contains one or more options that need to be transported between contains one or more options that need to be transported between
the tunnel end-points, sender MUST encapsulate the options as the tunnel endpoints, the sender MUST encapsulate the options as
defined in Appendix B.1.7 defined in Appendix B.1.7.
Instead of literally discarding the IP header and constructing a new Instead of literally discarding the IP header and constructing a new
one, a conforming implementation MAY simply replace the addresses in one, a conforming implementation MAY simply replace the addresses in
an existing header. However, if the RECOMMENDED feature of allowing an existing header. However, if the RECOMMENDED feature of allowing
the inner and outer addresses from different address families is the inner and outer addresses from different address families is
used, this simple strategy does not work. used, this simple strategy does not work.
B.1.6. Handling of incoming packets B.1.6. Handling of Incoming Packets
The incoming BEET mode packets are processed as follows: The incoming BEET mode packets are processed as follows:
1. The system MUST verify and decrypt the incoming packet 1. The system MUST verify and decrypt the incoming packet
successfully, as defined in [RFC4303] section 3.4. If the successfully, as defined in Section 3.4 of [RFC4303]. If the
verification or decryption fails, the packet MUST be discarded. verification or decryption fails, the packet MUST be discarded.
2. The original IP header is simply discarded, without any checks. 2. The original IP header is simply discarded, without any checks.
Since the ESP verification succeeded, the packet can be safely Since the ESP verification succeeded, the packet can be safely
assumed to have arrived from the right sender. assumed to have arrived from the right sender.
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 inner source and destination new IP header MUST contain the inner source and destination
addresses, as defined in the SA. If the sender has set the ESP addresses, as defined in the SA. If the sender has set the ESP
next protocol field to 94 and included the pseudo header as Next Header field to 94 and included the pseudo header as
described in Appendix B.1.7, the receiver MUST include the described in Appendix B.1.7, the receiver MUST include the
options after the constructed IP header. Note, that in some options after the constructed IP header. Note that in some
implementations the real IP header may have already been implementations the real IP header may have already been
discarded and the source and destination addresses are carried discarded and the source and destination addresses are carried
out-of-band. In such case the out-of-band addresses MUST be the out of band. In such a case, the out-of-band addresses MUST be
inner addresses. Other than the addresses, it is RECOMMENDED the inner addresses. Other than the addresses, it is RECOMMENDED
that the new IP header copies the fields from the original IP that the new IP header copies the fields from the original IP
header. header.
Instead of literally discarding the IP header and constructing a new Instead of literally discarding the IP header and constructing a new
one a conforming implementation MAY simply replace the addresses in one, a conforming implementation MAY simply replace the addresses in
an existing header. However, if the RECOMMENDED feature of allowing an existing header. However, if the RECOMMENDED feature of allowing
the inner and outer addresses from different address families is the inner and outer addresses from different address families is
used, this simple strategy does not work. used, this simple strategy does not work.
B.1.7. IPv4 options handling B.1.7. Handling of IPv4 Options
In BEET mode, if IPv4 options are transported inside the tunnel, the In BEET mode, if IPv4 options are transported inside the tunnel, the
sender MUST include a pseudo-header after ESP header. The pseudo- sender MUST include a pseudo header after the ESP header. The
header identifies that IPv4 options from the original packet are to pseudo header indicates that IPv4 options from the original packet
be applied on the packet on input side. are to be applied to the packet on the input side.
The sender MUST set the next protocol field on the ESP header as 94. The sender MUST set the Next Header field in the ESP header to 94.
The resulting pseudo header including the IPv4 options MUST be padded The resulting pseudo header, including the IPv4 options, MUST be
to 8 octet boundary. The padding length is expressed in octets, padded to an 8-octet boundary. The padding length is expressed in
valid padding lengths are 0 or 4 octets as the original IPv4 options octets; valid padding lengths are 0 or 4 octets, as the original IPv4
are already padded to 4 octet boundary. The padding MUST be filled options are already padded to a 4-octet boundary. The padding MUST
with NOP options as defined in Internet Protocol [RFC0791] section be filled with No Operation (NOP) options as defined in Section 3.1
3.1 Internet header format. The padding is added in front of the ("Internet Header Format") of [RFC0791] ("Internet Protocol"). The
original options to ensure that the receiver is able to reconstruct padding is added in front of the original options to ensure that the
the original IPv4 datagram. The Header Length field contains the receiver is able to reconstruct the original IPv4 datagram. The
length of the IPv4 options, and padding in 8 octets units. Header Length field contains the length of the IPv4 options, and
padding in 8-octet units.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Header Len | Pad Len | Reserved | | Next Header | Header Len | Pad Len | Reserved |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| Padding (if needed) | | Padding (if needed) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| IPv4 options ... | | IPv4 options ... |
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Next Header Identifies the data following this header Next Header identifies the data following this header.
Length in octets 8-bit unsigned integer. Length of the Length in octets 8-bit unsigned integer. Length of the
pseudo header in 8-octet units, not pseudo header in 8-octet units, not
including the first 8 octets. including the first 8 octets.
The receiver MUST remove this pseudo-header and padding as a part of The receiver MUST remove this pseudo header and padding as a part of
BEET processing, in order reconstruct the original IPv4 datagram. BEET processing, in order to reconstruct the original IPv4 datagram.
The IPv4 options included into the pseudo-header MUST be added after The IPv4 options included in the pseudo header MUST be added after
the reconstructed IPv4 (inner) header on the receiving side. the reconstructed IPv4 (inner) header on the receiving side.
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 includes Tom Henderson,
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 also want to thank 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.
Authors' Addresses Authors' Addresses
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
Verizon Telcom and Business HTT Consulting
1000 Bent Creek Blvd, Suite 200 Oak Park, MI
Mechanicsburg, PA United States
USA
EMail: rgm@labs.htt-consult.com
EMail: rgm@icsalabs.com
Jan Melen Jan Melen
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: jan.melen@nomadiclab.com EMail: jan.melen@nomadiclab.com
 End of changes. 156 change blocks. 
475 lines changed or deleted 482 lines changed or added

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