draft-ietf-hip-esp-00.txt   draft-ietf-hip-esp-01.txt 
Network Working Group P. Jokela Network Working Group P. Jokela
Internet-Draft Ericsson Research NomadicLab Internet-Draft Ericsson Research NomadicLab
Expires: December 25, 2005 R. Moskowitz Expires: April 27, 2006 R. Moskowitz
ICSAlabs, a Division of TruSecure ICSAlabs, a Division of TruSecure
Corporation Corporation
P. Nikander P. Nikander
Ericsson Research NomadicLab Ericsson Research NomadicLab
June 23, 2005 October 24, 2005
Using ESP transport format with HIP Using ESP transport format with HIP
draft-ietf-hip-esp-00 draft-ietf-hip-esp-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 25, 2005. This Internet-Draft will expire on April 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This memo specifies an Encapsulated Security Payload (ESP) based This memo specifies an Encapsulated Security Payload (ESP) based
mechanism for transmission of user data packets, to be used with the mechanism for transmission of user data packets, to be used with the
Host Identity Protocol (HIP). Host Identity Protocol (HIP).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 6 3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 6
3.1 ESP Packet Format . . . . . . . . . . . . . . . . . . . . 6 3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 6
3.2 ESP Packet Processing . . . . . . . . . . . . . . . . . . 6 3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 6
3.2.1 Semantics of the Security Parameter Index (SPI) . . . 7 3.2.1. Semantics of the Security Parameter Index (SPI) . . . 7
3.3 Security Association Establishment and Maintenance . . . . 7 3.3. Security Association Establishment and Maintenance . . . . 7
3.3.1 ESP Security Associations . . . . . . . . . . . . . . 8 3.3.1. ESP Security Associations . . . . . . . . . . . . . . 7
3.3.2 Rekeying . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.3 Security Association Management . . . . . . . . . . . 9 3.3.3. Security Association Management . . . . . . . . . . . 9
3.3.4 Security Parameter Index (SPI) . . . . . . . . . . . . 9 3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 9
3.3.5 Supported Transforms . . . . . . . . . . . . . . . . . 9 3.3.5. Supported Transforms . . . . . . . . . . . . . . . . . 9
3.3.6 Sequence Number . . . . . . . . . . . . . . . . . . . 10 3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 9
3.3.7 Lifetimes and Timers . . . . . . . . . . . . . . . . . 10 3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 10
4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1 Setting up an ESP Security Association . . . . . . . . 11 4.1.1. Setting up an ESP Security Association . . . . . . . . 11
4.1.2 Updating an Existing ESP SA . . . . . . . . . . . . . 12 4.1.2. 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 . . . . . . . . . . . . . . . . . . . . 14
5.1.3 NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 15 5.1.3. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 15
5.2 HIP ESP Security Association Setup . . . . . . . . . . . . 16 5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 16
5.2.1 Setup During Base Exchange . . . . . . . . . . . . . . 16 5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 16
5.3 HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 17 5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 17
5.3.1 Initializing Rekeying . . . . . . . . . . . . . . . . 17 5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 17
5.3.2 Responding to the Rekeying Initialization . . . . . . 18 5.3.2. Responding to the Rekeying Initialization . . . . . . 18
5.4 ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 18 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 18
5.4.1 Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19 5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 18
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 20 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 19
6.1 Processing Outgoing Application Data . . . . . . . . . . . 20 6.1. Processing Outgoing Application Data . . . . . . . . . . . 19
6.2 Processing Incoming Application Data . . . . . . . . . . . 20 6.2. Processing Incoming Application Data . . . . . . . . . . . 19
6.3 HMAC and SIGNATURE Calculation and Verification . . . . . 21 6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 20
6.4 Processing Incoming ESP SA Initialization (R1) . . . . . . 21 6.4. Processing Incoming ESP SA Initialization (R1) . . . . . . 20
6.5 Processing Incoming Initialization Reply (I2) . . . . . . 22 6.5. Processing Incoming Initialization Reply (I2) . . . . . . 21
6.6 Processing Incoming ESP SA Setup Finalization (R2) . . . . 22 6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . . 21
6.7 Dropping HIP Associations . . . . . . . . . . . . . . . . 22 6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 21
6.8 Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 22 6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 21
6.9 Processing Incoming UPDATE Packets . . . . . . . . . . . . 24 6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . . 23
6.9.1 Processing UPDATE Packet: No Outstanding Rekeying 6.9.1. Processing UPDATE Packet: No Outstanding Rekeying
Request . . . . . . . . . . . . . . . . . . . . . . . 24 Request . . . . . . . . . . . . . . . . . . . . . . . 23
6.10 Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 25 6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 24
6.11 Processing NOTIFY Packets . . . . . . . . . . . . . . . . 26 6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 25
7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 27 7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1 Normative references . . . . . . . . . . . . . . . . . . . 30 10.1. Normative references . . . . . . . . . . . . . . . . . . . 29
10.2 Informative references . . . . . . . . . . . . . . . . . . 30 10.2. Informative references . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. A Note on Implementation Options . . . . . . . . . . 30
A. A Note on Implementation Options . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 32
1. Introduction 1. Introduction
In the Host Identity Protocol Architecture [8], hosts are identified In the Host Identity Protocol Architecture [7], hosts are identified
with public keys. The Host Identity Protocol [5] base exchange with public keys. The Host Identity Protocol [5] base exchange
allows any two HIP-supporting hosts to authenticate each other and to allows any two HIP-supporting hosts to authenticate each other and to
create a HIP association between themselves. During the base create a HIP association between themselves. During the base
exchange, the hosts generate a piece of shared keying material using exchange, the hosts generate a piece of shared keying material using
an authenticated Diffie-Hellman exchange. an authenticated Diffie-Hellman exchange.
The HIP base exchange specification [5] does not describe any The HIP base exchange specification [5] does not describe any
transport formats, or methods for user data, to be used during the transport formats, or methods for user data, to be used during the
actual communication; it only defines that it is mandatory to actual communication; it only defines that it is mandatory to
implement the Encapsulated Security Payload (ESP) [4] based implement the Encapsulated Security Payload (ESP) [4] based transport
transport format and method. This document specifies how ESP is used format and method. This document specifies how ESP is used with HIP
with HIP to carry actual user data. 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.
skipping to change at page 6, line 27 skipping to change at page 6, line 27
responder adds the possible ESP transforms in a new ESP_TRANSFORM responder adds the possible ESP transforms in a new ESP_TRANSFORM
parameter before sending it to the Initiator. The Initiator gets the parameter before sending it to the Initiator. The Initiator gets the
proposed transforms, selects one of those proposed transforms, and proposed transforms, selects one of those proposed transforms, and
adds it to the I2 packet in an ESP_TRANSFORM parameter. In this I2 adds it to the I2 packet in an ESP_TRANSFORM parameter. In this I2
packet, the Initiator also sends the SPI value that it wants to be packet, the Initiator also sends the SPI value that it wants to be
used for ESP traffic flowing from the Responder to the Initiator. used for ESP traffic flowing from the Responder to the Initiator.
This information is carried using the new ESP_INFO parameter. When This information is carried using the new ESP_INFO parameter. When
finalizing the ESP SA setup, the Responder sends its SPI value to the finalizing the ESP SA setup, the Responder sends its SPI value to the
Initiator in the R2 packet, again using ESP_INFO. Initiator in the R2 packet, again using ESP_INFO.
3.1 ESP Packet Format 3.1. ESP Packet Format
The ESP specification [4] defines the ESP packet format for IPsec. The ESP specification [4] defines the ESP packet format for IPsec.
The HIP ESP packet looks exactly the same as the IPsec ESP transport The HIP ESP packet looks exactly the same as the IPsec ESP transport
format packet. The semantics, however, are a bit different and are format packet. The semantics, however, are a bit different and are
described in more detail in the next subsection. described in more detail in the next subsection.
3.2 ESP Packet Processing 3.2. Conceptual ESP Packet Processing
The ESP specification [4] defines packet processing for ESP, and ESP packet processing can be implemented in different ways in HIP.
defines two modes of operation: tunnel mode and transport mode. It is possible to implement it in a way that a standards compliant,
This section reviews the main changes to ESP packet processing when unmodified IPsec implementation [4] can be used.
ESP is combined with HIP.
The main difference between standard ESP and HIP's use of ESP is the When a standards compliant IPsec implementation is used, the packet
use by HIP of a new mode for operation, which has been called "Bound processing may take the following steps: For outgoing packets, the
End-to-End Tunnel" (BEET) mode [12]. In BEET mode, the ESP packet is implementation recalculates upper layer checksums using HITs and,
after that, changes the packet source and destination addresses to
corresponding IP addresses. The packet is sent to the IPsec ESP for
transport mode handling and from there the encrypted packet is sent
to the network. When an ESP packet is received, the packet is first
put to the IPsec ESP transport mode handling, and after decryption,
the source and destination IP addresses are replaced with HITs and
finally, upper layer checksums are recalculated.
An alternative way to implement the packet processing is the BEET
(Bound End-to-End Tunnel) [11] mode. In BEET mode, the ESP packet is
formatted as a transport mode packet, but the semantics of the formatted as a transport mode packet, but the semantics of the
connection are the same as for tunnel mode. The "outer" addresses of connection are the same as for tunnel mode. The "outer" addresses of
the packet are the IP addresses and the "inner" addresses are the the packet are the IP addresses and the "inner" addresses are the
HITs. The HITs do not need to be transmitted over the network, HITs. For outgoing traffic, after the packet has been encrypted, the
because the SPI value in the ESP packet is used as the hint for the packet's IP header is changed to a new one, containing IP addresses
correct HIT pair used for the connection. This mode of operation instead of HITs and the packet is sent to the network. When ESP
avoids overhead typically associated with ESP tunnel mode. packet is received, the SPI value, together with the integrity
protection, allow the packet to be securely associated with the right
In ESP, the packet processing and SA lookup are based on IP HIT pair. The packet header is replaces with a new header,
addresses. In HIP, however, SAs are bound to end-host HITs instead containing HITs and the packet is decrypted.
of IP addresses. When a HIP ESP SA packet arrives at the end-host,
the host changes the IP addresses in the packet to the corresponding
HITs before ESP processing.
It should be noted that it is possible to support the HIP way of
using ESP with a fully standards compliant IPsec implementation by
adding the necessary header rewriting mechanisms below IPsec in the
stack. These mechanisms can be considered to be on the network side
of IPsec, thus they cannot add any integrity or confidentiality
problems that would not exist without them. However, explicit care
must be taken to avoid introducing any new denial-of-service attacks.
3.2.1 Semantics of the Security Parameter Index (SPI) 3.2.1. Semantics of the Security Parameter Index (SPI)
SPIs are used in ESP to find the right Security Association for SPIs are used in ESP to find the right Security Association for
received packets. The ESP SPIs have added significance when used received packets. The ESP SPIs have added significance when used
with HIP; they are a compressed representation of a pair of HITs. with HIP; they are a compressed representation of a pair of HITs.
Thus, SPIs MAY be used by intermediary systems in providing services Thus, SPIs MAY be used by intermediary systems in providing services
like address mapping. Note that since the SPI has significance at like address mapping. Note that since the SPI has significance at
the receiver, only the < DST, SPI >, where DST is a destination IP the receiver, only the < DST, SPI >, where DST is a destination IP
address, uniquely identifies the receiver HIT at any given point of address, uniquely identifies the receiver HIT at any given point of
time. The same SPI value may be used by several hosts. A single < time. The same SPI value may be used by several hosts. A single <
DST, SPI > value may denote different hosts and contexts at different DST, SPI > value may denote different hosts and contexts at different
skipping to change at page 7, line 48 skipping to change at page 7, line 46
to use a different IP address, it MAY change the SPI. to use a different IP address, it MAY change the SPI.
One method for SPI creation that meets the above criteria would be to One method for SPI creation that meets the above criteria would be to
concatenate the HIT with a 32-bit random or sequential number, hash concatenate the HIT with a 32-bit random or sequential number, hash
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 setup between the HIP nodes
during the base exchange [5]. Existing ESP SAs can be updated later during the base exchange [5]. Existing ESP SAs can be updated later
using UPDATE messages. The reason for updating the ESP SA later can using UPDATE messages. The reason for updating the ESP SA later can
be e.g. need for rekeying the SA because of sequence number rollover. be e.g. need for rekeying the SA because of 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 the former one, and vice versa. The Initiator defines the SPI for the former
skipping to change at page 8, line 37 skipping to change at page 8, line 32
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
[5]. [5].
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
skipping to change at page 9, line 24 skipping to change at page 9, line 20
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
new incoming SA. After this, R' can remove the old SAs. Similarly, new incoming SA. After this, R' can remove the old SAs. Similarly,
when the I' receives traffic from the new incoming SA, it can safely when the I' receives traffic from the new incoming SA, it can safely
remove the old SAs. remove the old SAs.
3.3.3 Security Association Management 3.3.3. Security Association Management
An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote
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 IKE. over other Key Management Protocols like IKE.
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 partner. gets a new outbound SPI from its partner.
3.3.5 Supported Transforms 3.3.5. Supported Transforms
All HIP implementations MUST support AES [3] and HMAC-SHA-1-96 [2]. All HIP implementations MUST support AES [3] and HMAC-SHA-1-96 [2].
If the Initiator does not support any of the transforms offered by If the Initiator does not support any of the transforms offered by
the Responder, it should abandon the negotiation and inform the peer the Responder, it should abandon the negotiation and inform the peer
with a NOTIFY message about a non-supported transform. with a NOTIFY message about a non-supported transform.
In addition to AES, all implementations MUST implement the ESP NULL In addition to AES, all implementations MUST implement the ESP NULL
encryption algorithm. When the ESP NULL encryption is used, it MUST encryption algorithm. When the ESP NULL encryption is used, it MUST
be used together with SHA1 or MD5 authentication as specified in be used together with SHA1 or MD5 authentication as specified in
Section 5.1.2 Section 5.1.2
3.3.6 Sequence Number 3.3.6. Sequence Number
The Sequence Number field is MANDATORY when ESP is used with HIP. The Sequence Number field is MANDATORY when ESP is used with HIP.
Anti-replay protection MUST be used in an ESP SA established with Anti-replay protection MUST be used in an ESP SA established with
HIP. This means that each host MUST rekey before its sequence number HIP. This means that each host MUST rekey before its sequence number
reaches 2^32, or if extended sequence numbers are used, 2^64. reaches 2^32, or if extended sequence numbers are used, 2^64.
In some instances, a 32-bit sequence number is inadequate. In the In some instances, a 32-bit sequence number is inadequate. In the
ESP_TRANSFORM parameter, a peer MAY require that a 64-bit sequence ESP_TRANSFORM parameter, a peer MAY require that a 64-bit sequence
numbers be used. In this case the higher 32 bits are NOT included in numbers be used. In this case the higher 32 bits are NOT included in
the ESP header, but are simply kept local to both peers. The 64-bit the ESP header, but are simply kept local to both peers. The 64-bit
sequence number is required in fast networks when there is a risk sequence number is required in fast networks when there is a risk
that the sequence number will rollover too often. See [10]. that the sequence number will rollover too often. See [9].
3.3.7 Lifetimes and Timers 3.3.7. Lifetimes and Timers
HIP does not negotiate any lifetimes. All ESP lifetimes are local HIP does not negotiate any lifetimes. All ESP lifetimes are local
policy. The only lifetimes a HIP implementation MUST support are policy. The only lifetimes a HIP implementation MUST support are
sequence number rollover (for replay protection), and SHOULD support sequence number rollover (for replay protection), and SHOULD support
timing out inactive ESP SAs. An SA times out if no packets are timing out inactive ESP SAs. An SA times out if no packets are
received using that SA. The default timeout value is 15 minutes. received using that SA. The default timeout value is 15 minutes.
Implementations MAY support lifetimes for the various ESP transforms. Implementations MAY support lifetimes for the various ESP transforms.
Each implementation SHOULD implement per-HIT configuration of the Each implementation SHOULD implement per-HIT configuration of the
inactivity timeout, allowing statically configured HIP associations inactivity timeout, allowing statically configured HIP associations
to stay alive for days, even when inactive. to stay alive for days, even when inactive.
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 HIP association is described.
4.1 ESP in HIP 4.1. ESP in HIP
4.1.1 Setting up an ESP Security Association 4.1.1. 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
consists of three messages passed between the hosts. The parameters consists of three messages passed between the hosts. The parameters
are included in R1, I2, and R2 messages during base exchange. are included in R1, I2, and R2 messages during base exchange.
Initiator Responder Initiator Responder
I1 I1
----------------------------------> ---------------------------------->
skipping to change at page 12, line 5 skipping to change at page 12, line 5
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 ESP
SA. SA.
4.1.2 Updating an Existing ESP SA 4.1.2. Updating an Existing ESP SA
The update process is accomplished using two messages. The HIP The update process is accomplished using two 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 [5] and the SA. The UPDATE mechanism and message is defined in [5] and the
additional parameters for updating an existing ESP SA are described additional parameters for updating an existing ESP SA are described
here. here.
The following picture shows a typical exchange when an existing ESP
SA is updated. Messages include SEQ and ACK parameters required by
the UPDATE mechanism.
H1 H2 H1 H2
UPDATE: ESP_INFO [, DIFFIE_HELLMAN] UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN]
-----------------------------------------------------> ----------------------------------------------------->
UPDATE: ESP_INFO [, DIFFIE_HELLMAN] UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN]
<----------------------------------------------------- <-----------------------------------------------------
Not shown in the above figures are the corresponding SEQ and ACK UPDATE: ACK
parameters; at a minimum, the exchange shown above would include a ----------------------------------------------------->
SEQ parameter in the first packet shown, both a SEQ and an ACK in the
second packet, and a third packet containing only an 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 [5]. defined in [5].
The host receiving the UPDATE message requesting update of an The host receiving the UPDATE message requesting update of an
skipping to change at page 13, line 10 skipping to change at page 13, line 10
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 new HIP parameters are defined for setting up ESP transport
format associations in HIP communication and for rekeying existing format associations in HIP communication and for rekeying existing
ones. Also, the NOTIFY parameter, described in [5], has two new ones. Also, the NOTIFY parameter, described in [5], has two new
error parameters. error parameters.
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 2048 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. Additional both hosts must be transmitted between the hosts. Additional
information that is required when the hosts are drawing keys from the information that is required when the hosts are drawing keys from the
generated keying material is the index value into the KEYMAT from generated keying material is the index value into the KEYMAT from
where the keys are drawn. The ESP_INFO parameter is used to transmit where the keys are drawn. The ESP_INFO parameter is used to transmit
this information between the hosts. this information between the 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 value field 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 case
of multihomed HIP hosts [6]. However, such use is beyond the scope of multihomed HIP hosts [12]. However, such use is beyond the scope
of this specification. 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
skipping to change at page 14, line 37 skipping to change at page 14, line 37
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 the from where the ESP SA keys are drawn. Note that the
length of this field limits the amount of 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.
Old SPI Old SPI for data sent to address(es) associated Old SPI Old SPI for data sent to address(es) associated
with this SA. If this is an initial SA setup, the with this SA. If this is an initial SA setup, the
Old SPI value is zero. Old SPI value is zero.
New SPI New SPI for data sent to address(es) associated New SPI New SPI for data sent to address(es) associated
with this SA." with this SA.
5.1.2 ESP_TRANSFORM 5.1.2. ESP_TRANSFORM
The ESP_TRANSFORM parameter is used during ESP SA establishment. The The ESP_TRANSFORM parameter is used during ESP SA establishment. The
first party sends a selection of transfrom families in the first party sends a selection of transfrom families in the
ESP_TRANSFORM parameter and the peer must select one of the proposed ESP_TRANSFORM parameter and the peer must select one of the proposed
values and include it in the response ESP_TRANSFORM parameter. values and include it in the response ESP_TRANSFORM parameter.
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 |E| Suite-ID #1 | | Reserved |E| Suite-ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite-ID #2 | Suite-ID #3 | | Suite-ID #2 | Suite-ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite-ID #n | Padding | | Suite-ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2048 Type 4095
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
padding padding
E One if the ESP transform requires 64-bit E One if the ESP transform requires 64-bit
sequence numbers sequence numbers
(see (see
Section 3.3.6 Section 3.3.6
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 are defined ([7],[9]): The following Suite-IDs are defined ([6],[8]):
Suite-ID Value Suite-ID Value
RESERVED 0 RESERVED 0
ESP-AES-CBC with HMAC-SHA1 1 ESP-AES-CBC with HMAC-SHA1 1
ESP-3DES-CBC with HMAC-SHA1 2 ESP-3DES-CBC with HMAC-SHA1 2
ESP-3DES-CBC with HMAC-MD5 3 ESP-3DES-CBC with HMAC-MD5 3
ESP-BLOWFISH-CBC with HMAC-SHA1 4 ESP-BLOWFISH-CBC with HMAC-SHA1 4
ESP-NULL with HMAC-SHA1 5 ESP-NULL with HMAC-SHA1 5
ESP-NULL with HMAC-MD5 6 ESP-NULL with HMAC-MD5 6
There MUST NOT be more than six (6) ESP Suite-IDs in one There MUST NOT be more than six (6) ESP Suite-IDs in one
ESP_TRANSFORM parameter. The limited number of Suite-IDs sets the ESP_TRANSFORM parameter. The limited number of Suite-IDs sets the
maximum size of ESP_TRANSFORM parameter. The ESP_TRANSFORM MUST maximum size of ESP_TRANSFORM parameter. The ESP_TRANSFORM MUST
contain at least one of the mandatory Suite-IDs. contain at least one of the mandatory Suite-IDs.
Mandatory implementations: ESP-AES-CBC with HMAC-SHA1 and ESP-NULL Mandatory implementations: ESP-AES-CBC with HMAC-SHA1 and ESP-NULL
with HMAC-SHA1. with HMAC-SHA1.
5.1.3 NOTIFY Parameter 5.1.3. NOTIFY Parameter
The HIP base specification defines a set of NOTIFY error types. The The HIP base specification defines a set of NOTIFY error types. The
following error types are required for describing errors in ESP following error types are required for describing errors in ESP
Transform crypto suites during negotiation. Transform crypto suites during negotiation.
NOTIFY PARAMETER - ERROR TYPES Value NOTIFY PARAMETER - ERROR TYPES Value
------------------------------ ----- ------------------------------ -----
NO_ESP_PROPOSAL_CHOSEN 18 NO_ESP_PROPOSAL_CHOSEN 18
None of the proposed ESP Transform crypto suites was None of the proposed ESP Transform crypto suites was
acceptable. acceptable.
INVALID_ESP_TRANSFORM_CHOSEN 19 INVALID_ESP_TRANSFORM_CHOSEN 19
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 both using following subsections define the ESP SA setup procedure both using
base exchange messages (R1, I2, R2) and using UPDATE messages. base exchange messages (R1, I2, R2) and using UPDATE messages.
5.2.1 Setup During Base Exchange 5.2.1. Setup During Base Exchange
5.2.1.1 Modifications in R1 5.2.1.1. Modifications in R1
The ESP_TRANSFORM contains the ESP modes supported by the sender, in The ESP_TRANSFORM contains the ESP modes supported by the sender, in
the order of preference. All implementations MUST support AES [3] the order of preference. All implementations MUST support AES [3]
with HMAC-SHA-1-96 [2]. with HMAC-SHA-1-96 [2].
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_TRANSFORM, HIP_TRANSFORM,
ESP_TRANSFORM, ESP_TRANSFORM,
HOST_ID, HOST_ID,
[ ECHO_REQUEST, ] [ ECHO_REQUEST, ]
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 [3] with HMAC-SHA-1-96 [2]. All implementations MUST support AES [3] with HMAC-SHA-1-96 [2].
The following figure shows the resulting I2 packet layout. The following figure shows the resulting I2 packet layout.
skipping to change at page 17, line 25 skipping to change at page 17, line 24
SOLUTION, SOLUTION,
DIFFIE_HELLMAN, DIFFIE_HELLMAN,
HIP_TRANSFORM, HIP_TRANSFORM,
ESP_TRANSFORM, ESP_TRANSFORM,
ENCRYPTED { HOST_ID }, ENCRYPTED { HOST_ID },
[ ECHO_RESPONSE ,] [ ECHO_RESPONSE ,]
HMAC, HMAC,
HIP_SIGNATURE HIP_SIGNATURE
[, ECHO_RESPONSE] ) ) [, ECHO_RESPONSE] ) )
5.2.1.3 Modifications in R2 5.2.1.3. Modifications in R2
The R2 contains an ESP_INFO parameter, which has the SPI value of the The R2 contains an ESP_INFO parameter, which has the SPI value of the
sender of the R2 for this association. The ESP_INFO also has the sender of the R2 for this association. The ESP_INFO also has the
keymat index value specifying where the ESP SA keys are drawn. keymat index value specifying where the ESP SA keys are drawn.
The following figure shows the resulting R2 packet layout. The following figure shows the resulting R2 packet layout.
The HIP parameters for the R2 packet: The HIP parameters for the R2 packet:
IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) ) IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) )
5.3 HIP ESP Rekeying 5.3. HIP ESP Rekeying
In this section, the procedure for rekeying an existing ESP SA is In this section, the procedure for rekeying an existing ESP SA is
presented. presented.
5.3.1 Initializing Rekeying 5.3.1. Initializing Rekeying
When HIP is used with ESP, the UPDATE packet is used to initiate When HIP is used with ESP, the UPDATE packet is used to initiate
rekeying. The UPDATE packet MUST carry an ESP_INFO and MAY carry a rekeying. The UPDATE packet MUST carry an ESP_INFO and MAY carry a
DIFFIE_HELLMAN parameter. DIFFIE_HELLMAN parameter.
Intermediate systems that use the SPI will have to inspect HIP Intermediate systems that use the SPI will have to inspect HIP
packets for those that carry rekeying information. The packet is packets for those that carry rekeying information. The packet is
signed for the benefit of the intermediate systems. Since signed for the benefit of the intermediate systems. Since
intermediate systems may need the new SPI values, the contents cannot intermediate systems may need the new SPI values, the contents cannot
be encrypted. be encrypted.
skipping to change at page 18, line 19 skipping to change at page 18, line 16
UPDATE packet. UPDATE packet.
The HIP parameters for the UPDATE packet initiating rekeying: The HIP parameters for the UPDATE packet initiating rekeying:
IP ( HIP ( ESP_INFO, IP ( HIP ( ESP_INFO,
SEQ, SEQ,
[DIFFIE_HELLMAN, ] [DIFFIE_HELLMAN, ]
HMAC, HMAC,
HIP_SIGNATURE ) ) HIP_SIGNATURE ) )
5.3.2 Responding to the Rekeying Initialization 5.3.2. Responding to the Rekeying Initialization
The UPDATE ACK is used to acknowledge the received UPDATE rekeying The UPDATE ACK is used to acknowledge the received UPDATE rekeying
initialization. The acknowledgement UPDATE packet MUST carry an initialization. The acknowledgement UPDATE packet MUST carry an
ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter. ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter.
Intermediate systems that use the SPI will have to inspect HIP Intermediate systems that use the SPI will have to inspect HIP
packets for packets carrying rekeying information. The packet is packets for packets carrying rekeying information. The packet is
signed for the benefit of the intermediate systems. Since signed for the benefit of the intermediate systems. Since
intermediate systems may need the new SPI values, the contents cannot intermediate systems may need the new SPI values, the contents cannot
be encrypted. be encrypted.
skipping to change at page 18, line 43 skipping to change at page 18, line 40
The HIP parameters for the UPDATE packet: The HIP parameters for the UPDATE packet:
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
The ICMP message handling is mainly described in the HIP base The ICMP message handling is mainly described in the HIP base
specification [5]. In this section, we describe the actions related specification [5]. In this section, we describe the actions related
to ESP security associations. 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 the beginning of SPI field in the ESP the Pointer pointing to the the beginning of SPI field in the ESP
header. 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
[5]. This section describes the changes and new requirements for [5]. This section describes the changes and new requirements for
packet handling when the ESP transport format is used. Note that all packet handling when the ESP transport format is used. Note that all
HIP packets (currently protocol 99) MUST bypass ESP processing. HIP packets (currently protocol 99) MUST bypass 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 [5]. When ESP transport format is used, and there is specification [5]. When ESP transport format is used, and there is
an active HIP session for the given < source, destination > HIT pair, an active HIP session for the given < source, destination > HIT pair,
the outgoing datagram is protected using the ESP security the outgoing datagram is protected using the ESP security
association. In a typical implementation, this will result in a association. In a typical implementation, this will result in a
BEET-mode ESP packet being sent. BEET-mode [12] was introduced above BEET-mode ESP packet being sent. BEET-mode [11] was introduced above
in Section 3.2. in Section 3.2.
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 mode
SA. SA.
3. Ensure that the outgoing ESP protected packet has proper IP 3. Ensure that the outgoing ESP protected packet has proper IP
addresses in its IP header, e.g., by replacing HITs left by the header format depending on the used IP address family, and proper
ESP processing. Note that this placement of proper IP addresses IP addresses in its IP header, e.g., by replacing HITs left by
MAY also be performed at some other point in the stack, e.g., the ESP processing. Note that this placement of proper IP
before ESP processing. addresses MAY also be performed at some other point in the 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
specification. Additional steps are required when ESP is used for specification. Additional steps are required when ESP is used for
protecting the data traffic. The following steps define the protecting the data traffic. The following steps define the
skipping to change at page 21, line 21 skipping to change at page 20, line 21
IPv4 addresses, the packet must be converted to IPv6 format IPv4 addresses, the packet must be converted to IPv6 format
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. If LSIs are used, the address field is converted to contain the 4. The datagram is delivered to the upper layer. Demultiplexing the
LSI value before the packet is sent to the application.
5. 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 [5]. described in [5].
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) select one of the ESP transforms from the presented host (Initiator) select 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 After selecting the ESP transform, and performing other R1
processing, the system prepares and creates an incoming ESP security processing, the system prepares and creates an incoming ESP security
association. It may also prepare a security association for outgoing association. It may also prepare a security association for outgoing
traffic, but since it does not have the correct SPI value yet, it traffic, but since it does not have the correct SPI value yet, it
cannot activate 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 [5]). comparisons as described in [5]).
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.
skipping to change at page 22, line 34 skipping to change at page 21, line 32
o The system prepares and creates both incoming and outgoing ESP o The system prepares and creates both incoming and outgoing ESP
security associations. security associations.
o Upon successful processing of the initialization reply message, o Upon successful processing of the initialization reply message,
the possible old Security Associations (as left over from an the possible old Security Associations (as left over from an
earlier incarnation of the HIP association) are dropped and the earlier incarnation of the HIP association) are dropped and the
new ones are installed, and a finalizing packet, R2, is sent. new ones are installed, and a finalizing packet, R2, is sent.
Possible ongoing rekeying attempts are dropped. Possible ongoing rekeying attempts are dropped.
6.6 Processing Incoming ESP SA Setup Finalization (R2) 6.6. Processing Incoming ESP SA Setup Finalization (R2)
Before the ESP SA can be finalized, the ESP_INFO New SPI field is Before the ESP SA can be finalized, the ESP_INFO New SPI field is
parsed to obtain the SPI that will be used for the ESP Security parsed to obtain the SPI that will be used for the ESP Security
Association inbound to the sender of the finalization message R2. Association inbound to the sender of the finalization message R2.
The system uses this SPI to create or activate the outgoing ESP The system uses this SPI to create or activate the outgoing ESP
security association used for sending packets to the peer. security association used for sending packets to the peer.
6.7 Dropping HIP Associations 6.7. Dropping HIP Associations
When the system drops a HIP association, as described in the HIP base When the system drops a HIP association, as described in the HIP base
specification, the associated ESP SAs MUST also be dropped. specification, the associated ESP SAs MUST also be dropped.
6.8 Initiating ESP SA Rekeying 6.8. Initiating ESP SA Rekeying
During ESP SA rekeying, the hosts draw new keys from the existing During ESP SA rekeying, the hosts draw new keys from the existing
keying material, or a new keying material is generated from where the keying material, or a new keying material is generated from where the
new keys are drawn. new keys are drawn.
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.
skipping to change at page 24, line 19 skipping to change at page 23, line 15
against this, a system MAY re-initiate the ESP SA update against this, a system MAY re-initiate the ESP SA update
procedure after some time waiting for the peer to respond, or it procedure after some time waiting for the peer to respond, or it
MAY decide to abort the ESP SA after waiting for an MAY decide to abort the ESP SA after waiting for an
implementation-dependent time. The system MUST NOT keep an implementation-dependent time. The system MUST NOT keep an
oustanding ESP SA update request for an indefinite time. oustanding 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: following conditions hold:
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
skipping to change at page 24, line 46 skipping to change at page 23, line 42
message. message.
2. If there is no outstanding rekeying request, the packet 2. If there is no outstanding rekeying request, the packet
processing continues as specified in Section 6.9.1. processing continues as specified in Section 6.9.1.
3. If there is an outstanding rekeying request, the UPDATE MUST be 3. If there is an outstanding rekeying request, the UPDATE MUST be
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 ESP_INFO parameter: handling a received UPDATE packet with 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 Group
ID) if needed. The system records any newly generated or 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.
skipping to change at page 25, line 28 skipping to change at page 24, line 22
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. parameter, and the optional DIFFIE_HELLMAN parameter.
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 acknowledgement for the sent UPDATE to finish needs to receive an acknowledgement for the sent UPDATE to finish
ESP SA update. In the usual case, the acknowledgement is handled ESP SA update. In the usual case, the acknowledgement is handled
by the underlying UPDATE mechanism. 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 acknowledgement packet from the peer and it has corresponding UPDATE acknowledgement packet from the peer and it has
successfully received the peer's UPDATE. The following steps are successfully received the peer's UPDATE. The following steps are
taken: taken:
1. If the received UPDATE messages contains a new Diffie-Hellman 1. If the received UPDATE messages contains a new Diffie-Hellman
key, the system has a new Diffie-Hellman key from initiating ESP key, the system has a new Diffie-Hellman key from initiating ESP
SA update, or both, the system generates new KEYMAT. If there is SA update, or both, the system generates new KEYMAT. If there is
only one new Diffie-Hellman key, the old existing key is used as only one new Diffie-Hellman key, the old existing key is used as
skipping to change at page 26, line 15 skipping to change at page 25, line 8
The order of the keys retrieved from the KEYMAT during rekeying The order of the keys retrieved from the KEYMAT during rekeying
process is similar to that described in Section 7. Note, that process is similar to that described in Section 7. Note, that
only IPsec ESP keys are retrieved during rekeying process, not only IPsec ESP keys are retrieved during rekeying process, not
the HIP keys. the HIP keys.
4. The system cancels any timers protecting the UPDATE. 4. The system cancels any timers protecting the UPDATE.
5. The system starts to send to the new outgoing SA and prepares to 5. The system starts to send to the new outgoing SA and prepares to
start receiving data on the new incoming SA. start receiving data on the new incoming SA.
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
specification. specification.
7. Keying Material 7. Keying Material
The keying material is generated as described in the HIP base The keying material is generated as described in the HIP base
specification. During the base exchange, the initial keys are drawn specification. During the base exchange, the initial keys are drawn
from the generated material. After the HIP association keys have from the generated material. After the HIP association keys have
been drawn, the ESP keys are drawn in the following order: been drawn, the ESP keys are drawn in the following order:
SA-gl ESP encryption key for HOST_g's outgoing traffic SA-gl ESP encryption key for HOST_g's outgoing traffic
SA-gl ESP authentication key for HOST_g's outgoing traffic SA-gl ESP authentication key for HOST_g's outgoing traffic
SA-lg ESP encryption key for HOST_l's outgoing traffic SA-lg ESP encryption key for HOST_l's outgoing traffic
SA-lg ESP authentication key for HOST_l's outgoing traffic SA-lg ESP authentication key for HOST_l's outgoing traffic
HOST_g denotes the host with the greater HIT value, and HOST_l the
host with the lower HIT value. When HIT values are compared, they
are interpreted as positive (unsigned) 128-bit integers in network
byte order.
The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 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. For the mandatory algorithms, the following sizes of the keys. For the mandatory algorithms, the following sizes
apply: apply:
AES 128 bits AES 128 bits
skipping to change at page 28, line 12 skipping to change at page 27, line 12
NULL 0 bits NULL 0 bits
8. Security Considerations 8. Security Considerations
In this document the usage of ESP [4] between HIP hosts to protect In this document the usage of ESP [4] between HIP hosts to protect
data traffic is introduced. The Security Considerations for ESP are data traffic is introduced. The Security Considerations for ESP are
discussed in the ESP specification. 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 [[11]]. This between two nodes. This can be done, e.g. using IKE [10]. This
document specifies how Host Identity Protocol is used to establish document specifies how Host Identity Protocol is used to establish
ESP Security Associations. ESP Security Associations.
The following issues are new, or changed from the standard ESP usage: The following issues are new, or changed from the standard ESP usage:
o Initial keying material generation o Initial keying material generation
o Updating the keying material o Updating the keying material
o Using the BEET mode
The initial keying material is generated using the Host Identity The initial keying material is generated using the Host Identity
Protocol [5] using Diffie-Hellman procedure. This document extends Protocol [5] using Diffie-Hellman procedure. This document extends
the usage of UDPATE packet, defined in the base specification, to the usage of UDPATE packet, defined in the base specification, to
modify existing ESP SAs. The hosts may rekey, i.e. force the modify existing ESP SAs. The hosts may rekey, i.e. force the
generation of new keying material using Diffie-Hellman procedure. generation of new keying material using Diffie-Hellman procedure.
The initial setup of ESP SA between the hosts is done during the base The initial setup of ESP SA between the hosts is done during the base
ecxhange and the message exchange is protected with using methods ecxhange and the message exchange is protected with using methods
provided by base exchange. Changing of connection parameters means provided by base exchange. Changing of connection parameters means
basically that the old ESP SA is removed and a new one is generated basically that the old ESP SA is removed and a new one is generated
once the UPDATE message exchange has been completed. The message once the UPDATE message exchange has been completed. The message
exchange is protected using the HIP association keys. Both HMAC and exchange is protected using the HIP association keys. Both HMAC and
signing of packets is used. signing of packets is used.
IPsec ESP defines two modes of operation: tunnel mode and transport
mode. This document takes advantage of the so called Bound End-to-
End Tunneling (BEET) [12], that is a combination of tunnel and
transport modes. The packet looks like a transport mode packet, but
the semantics is like in tunnel mode packets. The security issues
are discussed in the Security Considerations section in the BEET
specification.
9. IANA Considerations 9. IANA Considerations
This document defines additional parameters for the Host Identity This document defines additional parameters for the Host Identity
Protocol [5]. These parameters are defined in Section 5.1.1 and Protocol [5]. These parameters are defined in Section 5.1.1 and
Section 5.1.2 with the following numbers: Section 5.1.2 with the following numbers:
o ESP_INFO is 65. o ESP_INFO is 65.
o ESP_TRANSFORM is 2048. o ESP_TRANSFORM is 4095.
10. References 10. References
10.1 Normative references 10.1. Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP [2] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
and AH", RFC 2404, November 1998. and AH", RFC 2404, November 1998.
[3] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher [3] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September 2003. Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[4] Kent, S., "IP Encapsulating Security Payload (ESP)", [4] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-05 (work in progress), April 2003. draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005.
[5] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-00
(work in progress), June 2004.
[6] Nikander, P., "End-Host Mobility and Multi-Homing with Host [5] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03
Identity Protocol", draft-ietf-hip-mm-00 (work in progress), (work in progress), June 2005.
October 2004.
[7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [6] Schiller, J., "Cryptographic Algorithms for use in the Internet
draft-ietf-ipsec-ikev2-07 (work in progress), April 2003. Key Exchange Version 2", draft-ietf-ipsec-ikev2-algorithms-05
(work in progress), April 2004.
[8] Moskowitz, R., "Host Identity Protocol Architecture", [7] Moskowitz, R. and P. Nikander, "Host Identity Protocol
draft-ietf-hip-arch-01 (work in progress), December 2004. Architecture", draft-ietf-hip-arch-03 (work in progress),
August 2005.
10.2 Informative references [8] Schneier, B., "Applied Cryptography Second Edition: protocols
algorithms and source in code in C", 1996.
[9] Bellovin, S. and W. Aiello, "Just Fast Keying (JFK)", 10.2. Informative references
draft-ietf-ipsec-jfk-04 (work in progress), July 2002.
[10] Kent, S., "Security Architecture for the Internet Protocol", [9] Kent, S. and K. Seo, "Security Architecture for the Internet
draft-ietf-ipsec-rfc2401bis-00 (work in progress), Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress),
October 2003. April 2005.
[11] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[12] Nikander, P., "A Bound End-to-End Tunnel (BEET) mode for ESP", [11] Nikander, P., "A Bound End-to-End Tunnel (BEET) mode for ESP",
draft-nikander-esp-beet-mode-00 (expired) (work in progress), draft-nikander-esp-beet-mode-03 (work in progress), June 2005.
Oct 2003.
Authors' Addresses
Petri Jokela
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
Email: petri.jokela@nomadiclab.com
Robert Moskowitz
ICSAlabs, a Division of TruSecure Corporation
1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA
USA
Email: rgm@icsalabs.com
Pekka Nikander
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1 [12] Nikander, P., "End-Host Mobility and Multihoming with the Host
Email: pekka.nikander@nomadiclab.com Identity Protocol", draft-ietf-hip-mm-02 (work in progress),
July 2005.
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 is to rewrite ways. As noted above, one possible way of implementing is to rewrite
IP headers below IPsec. In such an implementation, IPsec is used as IP headers below IPsec. In such an implementation, IPsec is used as
if it was processing IPv6 transport mode packets, with the IPv6 if it was processing IPv6 transport mode packets, with the IPv6
header containing HITs instead of IP addresses in the source and header containing HITs instead of IP addresses in the source and
destionation address fields. In outgoing packets, after IPsec destionation 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 use of IPsec as long as the SPI spaces are kept conflict with other use of IPsec as long as the SPI spaces are kept
separate. separate.
Another way for implementing is to use the proposed BEET mode (A Another way for implementing is to use the proposed BEET mode (A
Bound End-to-End mode for ESP) [12]. The BEET mode provides some Bound End-to-End mode for ESP) [11]. The BEET mode provides some
features from both IPsec tunnel and transport modes. The HIP uses features from both IPsec tunnel and transport modes. The HIP uses
HITs as the "inner" addresses and IP addresses as "outer" addresses HITs as the "inner" addresses and IP addresses as "outer" addresses
like IP addresses are used in the tunnel mode. Instead of tunneling like IP addresses are used in the tunnel mode. Instead of tunneling
packets between hosts, a conversion between inner and outer addresses packets between hosts, a conversion between inner and outer addresses
is made at end-hosts and the inner address is never sent in the wire is made at end-hosts and the inner address is never sent in the wire
after the initial HIP negotiation. BEET provides IPsec transport after the initial HIP negotiation. BEET provides IPsec transport
mode syntax (no inner headers) with limited tunnel mode semantics mode syntax (no inner headers) with limited tunnel mode semantics
(fixed logical inner addresses - the HITs - and changeable outer IP (fixed logical inner addresses - the HITs - and changeable outer IP
addresses). addresses).
Compared to the option of implementing the required address rewrites Compared to the option of implementing the required address rewrites
outside of IPsec, BEET has one implementation level benefit. The outside of IPsec, BEET has one implementation level benefit. The
BEET-way of implementing the address rewriting keeps all the BEET-way of implementing the address rewriting keeps all the
configuration information in one place, at the SADB. On the other configuration information in one place, at the SADB. On the other
hand, when address rewriting is implemented separately, the hand, when address rewriting is implemented separately, the
implementation must make sure that the information in the SADB and implementation must make sure that the information in the SADB and
the separate address rewriting DB are kept in synchrony. As a the separate address rewriting DB are kept in synchrony. As a
result, the BEET mode based way of implementing is RECOMMENDED over result, the BEET mode based way of implementing is RECOMMENDED over
the separate implementation. the separate implementation.
Authors' Addresses
Petri Jokela
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
Email: petri.jokela@nomadiclab.com
Robert Moskowitz
ICSAlabs, a Division of TruSecure Corporation
1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA
USA
Email: rgm@icsalabs.com
Pekka Nikander
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
Email: pekka.nikander@nomadiclab.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 84 change blocks. 
202 lines changed or deleted 197 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/