draft-ietf-hip-esp-05.txt   draft-ietf-hip-esp-06.txt 
Network Working Group P. Jokela Network Working Group P. Jokela
Internet-Draft Ericsson Research NomadicLab Internet-Draft Ericsson Research NomadicLab
Expires: August 18, 2007 R. Moskowitz Expires: December 13, 2007 R. Moskowitz
ICSAlabs, a Division of TruSecure ICSAlabs, a Division of TruSecure
Corporation Corporation
P. Nikander P. Nikander
Ericsson Research NomadicLab Ericsson Research NomadicLab
February 14, 2007 June 11, 2007
Using ESP transport format with HIP Using ESP transport format with HIP
draft-ietf-hip-esp-05 draft-ietf-hip-esp-06
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 August 18, 2007. This Internet-Draft will expire on December 13, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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).
skipping to change at page 15, line 12 skipping to change at page 15, line 12
To permit this, the implementation MUST permit establishment and To permit this, the implementation MUST permit establishment and
maintenance of multiple SAs between a given sender and receiver, with maintenance of multiple SAs between a given sender and receiver, with
the same selectors. Distribution of traffic among these parallel SAs the same selectors. Distribution of traffic among these parallel SAs
to support QoS is locally determined by the sender and is not to support QoS is locally determined by the sender and is not
negotiated by HIP. The receiver MUST process the packets from the negotiated by HIP. The receiver MUST process the packets from the
different SAs without prejudice. It is possible that the DSCP value different SAs without prejudice. It is possible that the DSCP value
changes en route, but this should not cause problems with respect to changes en route, but this should not cause problems with respect to
IPsec processing since the value is not employed for SA selection and IPsec processing since the value is not employed for SA selection and
MUST NOT be checked as part of SA/packet validation. MUST NOT be checked as part of SA/packet validation.
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 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 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.
skipping to change at page 19, line 8 skipping to change at page 19, line 8
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-CBC [RFC3602] with HMAC-SHA-1-96 All implementations MUST support AES-CBC [RFC3602] with HMAC-SHA-1-96
[RFC2404]. [RFC2404].
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:
skipping to change at page 19, line 35 skipping to change at page 19, line 35
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.
Conceptually, the process can be represented by the following message Conceptually, the process can be represented by the following message
sequence using the host names I' and R' defined in Section 3.3.2. sequence using the host names I' and R' defined in Section 3.3.2.
For simplicity, HMAC and HIP_SIGNATURE are not depicted, and For simplicity, HMAC and HIP_SIGNATURE are not depicted, and
DIFFIE_HELLMAN keys are optional. The UPDATE with ACK_I need not be DIFFIE_HELLMAN keys are optional. The UPDATE with ACK_I need not be
piggybacked with the UPDATE with SEQ_R; it may be acked separately piggybacked with the UPDATE with SEQ_R; it may be ACKed separately
(in which case the sequence would include four packets). (in which case the sequence would include four packets).
I' R' I' R'
UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN]) UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN])
-----------------------------------> ----------------------------------->
UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN]) UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN])
<----------------------------------- <-----------------------------------
UPDATE(ACK_R) UPDATE(ACK_R)
-----------------------------------> ----------------------------------->
skipping to change at page 24, line 19 skipping to change at page 24, line 19
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-base]). comparisons as described in [I-D.ietf-hip-base]).
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
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.
skipping to change at page 25, line 34 skipping to change at page 25, line 34
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 new KEYMAT. In the latter case, the system MUST or to generate 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 UDPATE 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 or equal to the index of the next byte to be drawn be greater or equal to the index of the next byte to be drawn
from the current KEYMAT. 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
be initiated early enough to make sure that the SA replay be initiated early enough to make sure that the SA replay
counters do not overflow. counters do not overflow.
5. In case a protocol error occurs and the peer system acknowledges 5. In case a protocol error occurs and the peer system acknowledges
the UPDATE but does not itself send an ESP_INFO, the system may the UPDATE but does not itself send an ESP_INFO, the system may
not finalize the outstanding ESP SA update request. To guard not finalize the outstanding ESP SA update request. To guard
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. 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
skipping to change at page 26, line 31 skipping to change at page 26, line 31
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
received Keymat Index MUST be zero and the Group ID must match received KEYMAT Index MUST be zero and the Group ID must match
the Group ID in use on the association. If this test fails, the the Group ID in use on the association. If this test fails, the
packet SHOULD be dropped and the system SHOULD log an error packet SHOULD be dropped and the system SHOULD log an error
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
skipping to change at page 27, line 9 skipping to change at page 27, line 9
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.
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 step, or if it received a DIFFIE_HELLMAN parameter, it sets
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 or equal to the index of the next byte to Index MUST be greater or equal to the index of the next byte to
be drawn from the current KEYMAT. In this case, it is 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 parameter, and the optional DIFFIE_HELLMAN parameter. This
UPDATE would also typically acknowledge the peer's UPDATE with an UPDATE would also typically acknowledge the peer's UPDATE with an
ACK parameter, although a separate UPDATE ACK may be sent. ACK 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 acknowledgement for the newly sent UPDATE to needs to receive an acknowledgement for the newly sent UPDATE to
skipping to change at page 27, line 40 skipping to change at page 27, line 40
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 due to initiating key, the system has a new Diffie-Hellman key due to initiating
ESP SA update, or both, the system generates new KEYMAT. If ESP SA update, or both, the system generates new KEYMAT. If
there is only one new Diffie-Hellman key, the old existing key is there is only one new Diffie-Hellman key, the old existing key is
used as the other key. used as the other key.
2. If the system generated new KEYMAT in the previous step, it sets 2. If the system generated new KEYMAT in the previous step, it sets
Keymat Index to zero, independent of whether the received UPDATE KEYMAT Index to zero, independent of whether the received UPDATE
included a Diffie-Hellman key or not. If the system did not included a Diffie-Hellman key or not. If the system did not
generate new KEYMAT, it uses the greater Keymat Index of the two generate new KEYMAT, it uses the greater KEYMAT Index of the two
(sent and received) ESP_INFO parameters. (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 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 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
skipping to change at page 30, line 24 skipping to change at page 30, line 24
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
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-base] using Diffie-Hellman procedure. This Protocol [I-D.ietf-hip-base] using Diffie-Hellman procedure. This
document extends the usage of UDPATE packet, defined in the base document extends the usage of UPDATE packet, defined in the base
specification, to modify existing ESP SAs. The hosts may rekey, i.e. specification, to modify existing ESP SAs. The hosts may rekey, i.e.
force the generation of new keying material using Diffie-Hellman force the generation of new keying material using Diffie-Hellman
procedure. The initial setup of ESP SA between the hosts is done procedure. The initial setup of ESP SA between the hosts is done
during the base ecxhange and the message exchange is protected with during the base exchange and the message exchange is protected with
using methods provided by base exchange. Changing of connection using methods provided by base exchange. Changing of connection
parameters means basically that the old ESP SA is removed and a new parameters means basically that the old ESP SA is removed and a new
one is generated once the UPDATE message exchange has been completed. one is generated once the UPDATE message exchange has been completed.
The message exchange is protected using the HIP association keys. The message exchange is protected using the HIP association keys.
Both HMAC and signing of packets is used. Both HMAC and signing of packets is used.
9. IANA Considerations 9. IANA Considerations
This document defines additional parameters and NOTIFY error types This document defines additional parameters and NOTIFY error types
for the Host Identity Protocol [I-D.ietf-hip-base]. for the Host Identity Protocol [I-D.ietf-hip-base].
The new parameters and their type numbers are defined in The new parameters and their type numbers are defined in
Section 5.1.1 and Section 5.1.2 and they are added in the Parameter Section 5.1.1 and Section 5.1.2 and they are added in the Parameter
Type namespace, specified in [I-D.ietf-hip-base]. Type namespace, specified in [I-D.ietf-hip-base].
The new NOTFY error types and their values are defined in The new NOTIFY error types and their values are defined in
Section 5.1.3 and they are added in Notify Message Type namespace, Section 5.1.3 and they are added in Notify Message Type namespace,
specified in [I-D.ietf-hip-base]. specified in [I-D.ietf-hip-base].
10. Acknowledgments 10. Acknowledgments
This document was separated from the base "Host Identity Protocol" This document was separated from the base "Host Identity Protocol"
specification in the beginning of 2005. Since then, a number of specification in the beginning of 2005. Since then, a number of
people have contributed to the text by giving comments and people have contributed to the text by giving comments and
modification proposals. The list of people include Tom Henderson, modification proposals. The list of people include Tom Henderson,
Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. Authors Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. Authors
want also thank Charlie Kaufman for reviewing the document with the want also thank Charlie Kaufman for reviewing the document with the
eye on the usage of crypto algorithms. eye on the usage of crypto algorithms.
Due to the history of this document, most of the ideas are inherited Due to the history of this document, most of the ideas are inherited
from the base "Host Identity Protocol" specification. Thus the list from the base "Host Identity Protocol" specification. Thus the list
of people in the Acknowledgments section of that specification is of people in the Acknowledgments section of that specification is
also valid for this document. Many people have given valueable also valid for this document. Many people have given valuable
feedback, and our apologies for anyone whose name is missing. feedback, and our apologies for anyone whose name is missing.
11. References 11. References
11.1. Normative references 11.1. Normative references
[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.
[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
skipping to change at page 33, line 24 skipping to change at page 33, line 24
[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, Algorithm and Its Use with IPsec", RFC 3602,
September 2003. September 2003.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[I-D.ietf-hip-base] [I-D.ietf-hip-base]
Moskowitz, R., "Host Identity Protocol", Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-06 (work in progress), June 2006. draft-ietf-hip-base-07 (work in progress), February 2007.
11.2. Informative references 11.2. Informative references
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998. Algorithms", RFC 2451, November 1998.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
skipping to change at page 33, line 48 skipping to change at page 33, line 48
in progress), April 2005. in progress), April 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[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.
[I-D.nikander-esp-beet-mode] [I-D.nikander-esp-beet-mode]
Melen, J. and P. Nikander, "A Bound End-to-End Tunnel Melen, J. and P. Nikander, "A Bound End-to-End Tunnel
(BEET) mode for ESP", draft-nikander-esp-beet-mode-06 (BEET) mode for ESP", draft-nikander-esp-beet-mode-07
(work in progress), August 2006. (work in progress), February 2007.
[I-D.ietf-hip-mm] [I-D.ietf-hip-mm]
Nikander, P., "End-Host Mobility and Multihoming with the Henderson, T., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-04 (work in Host Identity Protocol", draft-ietf-hip-mm-05 (work in
progress), June 2006. progress), March 2007.
[RFC3260] Grossman, D., "New Terminology and Clarifications for [RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002. Diffserv", RFC 3260, April 2002.
[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA [RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA
assignments for Generalized MultiProtocol Label Switching assignments for Generalized MultiProtocol Label Switching
(GMPLS) Resource Reservation Protocol - Traffic (GMPLS) Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) Usage and Extensions for Engineering (RSVP-TE) Usage and Extensions for
Automatically Switched Optical Network (ASON)", RFC 3474, Automatically Switched Optical Network (ASON)", RFC 3474,
March 2003. March 2003.
skipping to change at page 35, line 12 skipping to change at page 35, line 12
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
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 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 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
 End of changes. 29 change blocks. 
34 lines changed or deleted 34 lines changed or added

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