draft-ietf-hip-over-hip-03.txt   draft-ietf-hip-over-hip-04.txt 
HIP Working Group A. Keranen HIP Working Group A. Keranen
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Experimental October 25, 2010 Intended status: Experimental December 16, 2010
Expires: April 28, 2011 Expires: June 19, 2011
Host Identity Protocol Signaling Message Transport Modes Host Identity Protocol Signaling Message Transport Modes
draft-ietf-hip-over-hip-03 draft-ietf-hip-over-hip-04
Abstract Abstract
This document specifies two transport modes for Host Identity This document specifies two transport modes for Host Identity
Protocol (HIP) signaling messages that allow conveying them over Protocol (HIP) signaling messages that allow conveying them over
encrypted connections initiated with the Host Identity Protocol. encrypted connections initiated with the Host Identity Protocol.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
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 April 28, 2011. This Internet-Draft will expire on June 19, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 3 3. Transport Mode Negotiation . . . . . . . . . . . . . . . . . . 3
3.1. Mode Negotiation in HIP Base Exchange . . . . . . . . . . 3 3.1. Mode Negotiation in the HIP Base Exchange . . . . . . . . 3
3.2. Mode Negotiation After HIP Base Exchange . . . . . . . . . 5 3.2. Mode Negotiation After the HIP Base Exchange . . . . . . . 5
3.3. HIP Messages on Encrypted Connections . . . . . . . . . . 5 3.3. Error Notifications . . . . . . . . . . . . . . . . . . . 5
3.3.1. ESP mode . . . . . . . . . . . . . . . . . . . . . . . 6 4. HIP Messages on Encrypted Connections . . . . . . . . . . . . 5
3.3.2. ESP-TCP mode . . . . . . . . . . . . . . . . . . . . . 6 4.1. ESP mode . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Recovering from Failed Encrypted Connections . . . . . . . 7 4.2. ESP-TCP mode . . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Host Mobility and Multihoming . . . . . . . . . . . . . . 7 5. Recovering from Failed Encrypted Connections . . . . . . . . . 7
4. Notify Packet Types . . . . . . . . . . . . . . . . . . . . . 7 6. Host Mobility and Multihoming . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informational References . . . . . . . . . . . . . . . . . 9 10.2. Informational References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Mobility and Multihoming Examples . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Host Identity Protocol (HIP) [RFC5201] signaling messages can be Host Identity Protocol (HIP) [RFC5201] signaling messages can be
exchanged over plain IP using the protocol number reserved for this exchanged over plain IP using the protocol number reserved for this
purpose, or over UDP using the UDP port reserved for HIP NAT purpose, or over UDP using the UDP port reserved for HIP NAT
traversal [RFC5770]. When two hosts perform a HIP base exchange, traversal [RFC5770]. When two hosts perform a HIP base exchange,
they set up an encrypted connection between them for data traffic, they set up an encrypted connection between them for data traffic,
but continue to use plain IP or UDP for HIP signaling messages. but continue to use plain IP or UDP for HIP signaling messages.
skipping to change at page 3, line 28 skipping to change at page 3, line 28
traffic (including HIP headers) will be encrypted. If HIP messages traffic (including HIP headers) will be encrypted. If HIP messages
are sent over TCP (which in turn is transported over ESP), TCP can are sent over TCP (which in turn is transported over ESP), TCP can
handle also message fragmentation where needed. handle also message fragmentation where needed.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Protocol Extensions 3. Transport Mode Negotiation
This section defines how support for different HIP signaling message This section defines how support for different HIP signaling message
transport modes is negotiated and the normative behavior required by transport modes is indicated and how the use of different modes is
the extension. negotiated.
3.1. Mode Negotiation in HIP Base Exchange 3.1. Mode Negotiation in the HIP Base Exchange
A HIP host implementing this specification SHOULD indicate the modes A HIP host implementing this specification SHOULD indicate the modes
it supports, and is willing to use, in the base exchange. The HIP it supports, and is willing to use, in the base exchange. The HIP
signaling message transport mode negotiation is similar to HIP NAT signaling message transport mode negotiation is similar to HIP NAT
traversal mode negotiation: first the Responder lists the supported traversal mode negotiation: first the Responder lists the supported
modes in a HIP_TRANSPORT_MODE parameter (see Figure 1) in the R1 modes in a HIP_TRANSPORT_MODE parameter (see Figure 1) in the R1
packet. The modes are listed in priority order; the more preferred packet. The modes are listed in priority order; the more preferred
mode(s) first. If the Initiator supports, and is willing to use, any mode(s) first. If the Initiator supports, and is willing to use, any
of the modes proposed by the Responder, it selects one of the modes of the modes proposed by the Responder, it selects one of the modes
by adding a HIP_TRANSPORT_MODE parameter containing the selected mode by adding a HIP_TRANSPORT_MODE parameter containing the selected mode
to the I2 packet. Finally, if the Initiator selected one of the to the I2 packet. Finally, if the Initiator selected one of the
modes and the base exchange succeeds, hosts MUST use the selected modes and the base exchange succeeds, hosts MUST use the selected
mode for the following HIP signaling messages sent between them for mode for the following HIP signaling messages sent between them for
the duration of the HIP association or until another mode is the duration of the HIP association or until another mode is
negotiated. negotiated.
If the Initiator cannot or will not use any of the modes proposed by If the Initiator cannot, or will not, use any of the modes proposed
the Responder, the Initiator SHOULD include an empty by the Responder, the Initiator SHOULD include an empty
HIP_TRANSPORT_MODE parameter to the I2 packet to signal that it HIP_TRANSPORT_MODE parameter to the I2 packet to signal that it
support this extension but will not use any of the proposed modes. supports this extension but will not use any of the proposed modes.
Depending on local policy, the Responder MAY either abort the base Depending on local policy, the Responder MAY either abort the base
exchange or continue HIP signaling without using an encrypted exchange or continue HIP signaling without using an encrypted
connection, if there was no HIP_TRANSPORT_MODE parameter in I2 or the connection, if there was no HIP_TRANSPORT_MODE parameter in I2 or the
parameter was empty. If the Initiator selects a mode that the parameter was empty. If the Initiator selects a mode that the
Responder does not support (and hence was not included in R1), the Responder does not support (and hence was not included in R1), the
Responder MUST abort the base exchange. If the base exchange is Responder MUST abort the base exchange. If the base exchange is
aborted due to (possibly lack of) HIP_TRANSPORT_PARAMETER, the aborted due to (possibly lack of) HIP_TRANSPORT_PARAMETER, the
Responder SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet Responder SHOULD send a NO_VALID_HIP_TRANSPORT_MODE notification (see
(see Section 4) to the Initiator. Section 3.3) to the Initiator.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Mode ID #1 | | Port | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #2 | Mode ID #3 | | Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 10 skipping to change at page 5, line 10
subsequent HIP signaling messages. In the ESP mode the messages are subsequent HIP signaling messages. In the ESP mode the messages are
sent as such on the encrypted ESP connection and in the ESP-TCP mode sent as such on the encrypted ESP connection and in the ESP-TCP mode
TCP is used within the ESP tunnel. If a mode that uses a transport TCP is used within the ESP tunnel. If a mode that uses a transport
layer connection (e.g., ESP-TCP) is offered, the Port field MUST layer connection (e.g., ESP-TCP) is offered, the Port field MUST
contain the local port number the host will use for the connection. contain the local port number the host will use for the connection.
If none of the modes utilize a transport layer protocol, the Port If none of the modes utilize a transport layer protocol, the Port
field SHOULD be set to zero when the parameter is sent and ignored field SHOULD be set to zero when the parameter is sent and ignored
when received. The Port and Mode ID fields are encoded as unsigned when received. The Port and Mode ID fields are encoded as unsigned
integers using network byte order. integers using network byte order.
3.2. Mode Negotiation After HIP Base Exchange 3.2. Mode Negotiation After the HIP Base Exchange
If a HIP hosts wants to change to a different transport mode (or If a HIP hosts wants to change to a different transport mode (or
start using a transport mode) some time after the base exchange, it start using a transport mode) some time after the base exchange, it
sends a HIP UPDATE packet with a HIP_TRANSPORT_MODE parameter sends a HIP UPDATE packet with a HIP_TRANSPORT_MODE parameter
containing the mode(s) it would prefer to use. The host receiving containing the mode(s) it would prefer to use. The host receiving
the UPDATE SHOULD respond with an UPDATE packet containing the mode the UPDATE SHOULD respond with an UPDATE packet containing the mode
that is selected as in the negotiation during the base exchange. If that is selected as in the negotiation during the base exchange. If
the receiving host does not support, or is not willing to use, any of the receiving host does not support, or is not willing to use, any of
the listed modes, it SHOULD respond with an UPDATE packet where the the listed modes, it SHOULD respond with an UPDATE packet where the
HIP_TRANSPORT_MODE parameter contains only the currently used HIP_TRANSPORT_MODE parameter contains only the currently used
transport mode (even if one was not included in the previous UPDATE transport mode (even if that was not included in the previous UPDATE
packet) and continue using that mode. packet) and continue using that mode.
Since the HIP_TRANSPORT_MODE parameter's type is not critical (as Since the HIP_TRANSPORT_MODE parameter's type is not critical (as
defined in Section 5.2.1 of [RFC5201]), a host not supporting this defined in Section 5.2.1 of [RFC5201]), a host not supporting this
extension would simply reply with an acknowledgement UPDATE packet extension would simply reply with an acknowledgement UPDATE packet
without a HIP_TRANSPORT_MODE parameter. In such a case, depending on without a HIP_TRANSPORT_MODE parameter. In such a case, depending on
local policy as in mode negotiation during the base exchange, the local policy as in mode negotiation during the base exchange, the
host that requested the new transport mode MAY close the HIP host that requested the new transport mode MAY close the HIP
association. If the association is closed, the host closing the association. If the association is closed, the host closing the
association SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet association SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet
to the other host before closing the association. to the other host before closing the association.
3.3. HIP Messages on Encrypted Connections 3.3. Error Notifications
During a HIP signaling transport mode negotiation, if a
HIP_TRANSPORT_MODE parameter does not contain any mode the receiving
host is willing to use, or a HIP_TRANSPORT_MODE parameter does not
exist in a HIP packet where the receiving host expected to see it,
the receiving host may send back a NOTIFY packet with a NOTIFICATION
parameter [RFC5201] error type NO_VALID_HIP_TRANSPORT_MODE (value
[TBD by IANA; 100]). The Notification Data field for the error
notifications SHOULD contain the HIP header of the rejected packet.
4. HIP Messages on Encrypted Connections
This specification defines two different transport modes for sending This specification defines two different transport modes for sending
HIP packets over encrypted ESP connections. These modes require that HIP packets over encrypted ESP connections. These modes require that
the ESP transport format [RFC5202] is negotiated to be used between the ESP transport format [RFC5202] is negotiated to be used between
the hosts. If the ESP transport format is not used, these modes MUST the hosts. If the ESP transport format is not used, these modes MUST
NOT be offered in the HIP_TRANSPORT_MODE parameter. If a NOT be offered in the HIP_TRANSPORT_MODE parameter. If a
HIP_TRANSPORT_MODE parameter containing an ESP transport mode is HIP_TRANSPORT_MODE parameter containing an ESP transport mode is
received but the ESP transport format is not used, a host MUST NOT received but the ESP transport format is not used, a host MUST NOT
select such a mode but act as specified in Section 3.1 (if performing select such a mode but act as specified in Section 3.1 (if performing
a base exchange) or Section 3.2 (if performing an UPDATE) when no a base exchange) or Section 3.2 (if performing an UPDATE) when no
skipping to change at page 6, line 20 skipping to change at page 6, line 32
NOT be sent over the encrypted connection that is created using the NOT be sent over the encrypted connection that is created using the
keying material that is being changed, nor over an encrypted keying material that is being changed, nor over an encrypted
connection using the newly created keying material. connection using the newly created keying material.
It should be noted that when HIP messages are sent using an encrypted It should be noted that when HIP messages are sent using an encrypted
connection, on-path network elements (e.g., firewalls) that would connection, on-path network elements (e.g., firewalls) that would
normally see the HIP headers and contents of the un-encrypted normally see the HIP headers and contents of the un-encrypted
parameters, cannot see any part of the messages unless they have parameters, cannot see any part of the messages unless they have
access to the encryption keying material. access to the encryption keying material.
3.3.1. ESP mode 4.1. ESP mode
If the ESP mode is selected in the base exchange, both hosts MUST If the ESP mode is selected in the base exchange, both hosts MUST
listen for incoming HIP signaling messages and send outgoing messages listen for incoming HIP signaling messages and send outgoing messages
on the encrypted connection. The ESP header's next header value for on the encrypted connection. The ESP header's next header value for
such messages MUST be set to HIP (139). HIP messages sent over ESP MUST be set to HIP (139).
3.3.2. ESP-TCP mode 4.2. ESP-TCP mode
If the ESP-TCP mode is selected, the host with the larger HIT If the ESP-TCP mode is selected, the host with the larger HIT
(calculated as defined in Section 6.5 of [RFC5201]) MUST start to (calculated as defined in Section 6.5 of [RFC5201]) MUST start to
listen for an incoming TCP connection on the encrypted connection on listen for an incoming TCP connection on the encrypted connection on
the port it used in the Port field of the transport mode parameter. the port it used in the Port field of the transport mode parameter.
The other host MUST create a TCP connection to that port and the host The other host MUST create a TCP connection to that port and the host
SHOULD use the port it sent in the transport mode parameter as the SHOULD use the port it sent in the transport mode parameter as the
source port for the TCP connection. Once the TCP connection is source port for the TCP connection. Once the TCP connection is
established, both hosts MUST listen for incoming HIP signaling established, both hosts MUST listen for incoming HIP signaling
messages and send the outgoing messages using the TCP connection. messages and send the outgoing messages using the TCP connection.
The ESP next header value for messages sent using the ESP-TCP mode The ESP next header value for messages sent using the ESP-TCP mode
connections MUST be set to TCP (6). TCP connections MUST be set to TCP (6).
If the hosts are unable to create the TCP connection, the host that If the hosts are unable to create the TCP connection, the host that
initiated the mode negotiation MUST restart the negotiation with initiated the mode negotiation MUST restart the negotiation with
UPDATE message and SHOULD NOT propose the ESP-TCP mode. If local UPDATE message and SHOULD NOT propose the ESP-TCP mode. If local
policy does not allow using any other mode than ESP-TCP, the HIP policy does not allow using any other mode than ESP-TCP, the HIP
association MUST be closed. The UPDATE or CLOSE message MUST be sent association SHOULD be closed. The UPDATE or CLOSE message MUST be
using the same transport mode that was used for negotiating the use sent using the same transport mode that was used for negotiating the
of the ESP-TCP mode. use of the ESP-TCP mode.
Since TCP provides reliable transport, the HIP messages sent over TCP Since TCP provides reliable transport, the HIP messages sent over TCP
MUST NOT be retransmitted for the purpose of achieving reliable MUST NOT be retransmitted for the purpose of achieving reliable
transmission. Instead, a host SHOULD wait to detect that the TCP transmission. Instead, a host SHOULD wait to detect that the TCP
connection has failed to retransmit the packet successfully in a connection has failed to retransmit the packet successfully in a
timely manner (such detection is platform- and policy-specific) timely manner (such detection is platform- and policy-specific)
before concluding that there is no response. before concluding that there is no response.
3.4. Recovering from Failed Encrypted Connections 5. Recovering from Failed Encrypted Connections
If the encrypted connection fails for some reason, it can no longer If the encrypted connection fails for some reason, it can no longer
be used for HIP signaling and the hosts SHOULD re-establish the be used for HIP signaling and the hosts SHOULD re-establish the
connection using HIP messages that are sent outside of the encrypted connection using HIP messages that are sent outside of the encrypted
connection. Hence, while listening for incoming HIP messages on the connection. Hence, while listening for incoming HIP messages on the
encrypted connection, hosts MUST still accept incoming HIP messages encrypted connection, hosts MUST still accept incoming HIP messages
using the same transport method (e.g., UDP or plain IP) that was used using the same transport method (e.g., UDP or plain IP) that was used
for the base exchange. When responding to a HIP message sent outside for the base exchange. When responding to a HIP message sent outside
of encrypted connection, the response MUST be sent using the same of the encrypted connection, the response MUST be sent using the same
transport method as the original message used. If encryption was transport method as the original message used. If encryption was
used, hosts SHOULD send outside of the encrypted connection only HIP previously used, hosts SHOULD send outside of the encrypted
messages that are used to reestablish the encrypted connection. connection only HIP messages that are used to re-establish the
Especially, messages that are intended to be sent only encrypted encrypted connection. Especially, messages that are intended to be
(e.g., DATA messages using an encrypted transport mode) MUST NOT be sent only encrypted (e.g., DATA messages using an encrypted transport
sent before the encrypted connection is reestablished. mode) MUST be sent only using the encrypted connection.
The UPDATE messages used for re-establishing the encrypted connection The UPDATE messages used for re-establishing the encrypted connection
MUST contain a HIP_TRANSPORT_MODE parameter and the negotiation MUST contain a HIP_TRANSPORT_MODE parameter and the negotiation
proceeds as described in Section 3.2. proceeds as described in Section 3.2.
3.5. Host Mobility and Multihoming 6. Host Mobility and Multihoming
If the host's address changes, usually a new Security Association If a host obtains a new address, a new Security Association (SA) pair
(SA) is created for the new address as described in [RFC5206] and if may be created for (or an existing SA pair may be moved to) the new
an ESP or ESP-TCP transport mode is used, HIP signaling continues address, as described in [RFC5206]. If the ESP or ESP-TCP transport
using the new SA and the same transport mode as before. If the ESP- mode is used, HIP signaling continues using the (new) SA pair and the
TCP mode is used, the HIP signaling TCP connection is moved to the same transport mode as before.
new SA like any other TCP connection.
With the ESP mode, the first mobility UPDATE message SHOULD be sent
using the old SA and the following messages, including the response
to the first UPDATE, SHOULD be sent using the new SAs.
Retransmissions of the UPDATE messages use the same SA as the
original message. If the ESP-TCP mode is used, the HIP signaling TCP
connection is moved to the new SA pair like any other TCP connection.
However, the mobility UPDATE messages SHOULD NOT be sent over the TCP
connection, but using plain ESP like in the ESP mode, and
consequently hosts MUST be prepared to receive UPDATE messages over
plain ESP even if the ESP-TCP mode is used.
In some cases the host may not be able to send the mobility UPDATE In some cases the host may not be able to send the mobility UPDATE
messages using the encrypted connection before it breaks. This messages using the encrypted connection before it breaks. This
results in a similar situation as if the encrypted connection had results in a similar situation as if the encrypted connection had
failed and the hosts need to re-negotiate the new addresses using un- failed and the hosts need to re-negotiate the new addresses using un-
encrypted UPDATE messages and possibly rendezvous [RFC5204] or HIP encrypted UPDATE messages and possibly rendezvous [RFC5204] or HIP
relay [RFC5770] servers. Also these UPDATE messages MUST contain the relay [RFC5770] servers. Also these UPDATE messages MUST contain the
HIP_TRANSPORT_MODE parameter and perform the transport mode HIP_TRANSPORT_MODE parameter and perform the transport mode
negotiation. negotiation.
4. Notify Packet Types Examples of the signaling flows with mobility and multihoming are
shown in Appendix A.
The new Notify Packet Type [RFC5201] defined in this document is
shown below. The Notification Data field for the error notifications
SHOULD contain the HIP header of the rejected packet.
NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ -----
NO_VALID_HIP_TRANSPORT_MODE [TBD by IANA;100]
If a host sends an UPDATE message that does not have any transport
mode the receiving host is willing to use, the receiving host
sends back a NOTIFY error packet with this type.
5. Security Considerations 7. Security Considerations
By exchanging the HIP messages over ESP connection, all HIP signaling By exchanging the HIP messages over ESP connection, all HIP signaling
data (after the base exchange but excluding keying material data (after the base exchange but excluding keying material
(re)negotiation) will be encrypted, but only if NULL encryption is (re)negotiation and some of the mobility UPDATE messages) will be
not used. Thus, a host requiring confidentiality for the HIP encrypted, but only if NULL encryption is not used. Thus, a host
signaling messages must check that encryption is negotiated to be requiring confidentiality for the HIP signaling messages must check
used on the ESP connection. Moreover, the level of protection that encryption is negotiated to be used on the ESP connection.
provided by the ESP transport modes depends on the selected ESP Moreover, the level of protection provided by the ESP transport modes
transform; see [RFC5202] and [RFC4303] for security considerations of depends on the selected ESP transform; see [RFC5202] and [RFC4303]
the different ESP transforms. for security considerations of the different ESP transforms.
6. Acknowledgements 8. Acknowledgements
Thanks to Gonzalo Camarillo, Kristian Slavov, Tom Henderson, Miika Thanks to Gonzalo Camarillo, Kristian Slavov, Tom Henderson, Miika
Komu, Jan Melen, and Tobias Heer for comments on the draft. Komu, Jan Melen, and Tobias Heer for comments on the draft.
7. IANA Considerations 9. IANA Considerations
This section is to be interpreted according to [RFC5226]. This section is to be interpreted according to [RFC5226].
This document updates the IANA Registry for HIP Parameter Types This document updates the IANA Registry for HIP Parameter Types
[RFC5201] by assigning new HIP Parameter Type value for the [RFC5201] by assigning new HIP Parameter Type value for the
HIP_TRANSPORT_MODE parameter (defined in Section 3.1). HIP_TRANSPORT_MODE parameter (defined in Section 3.1).
The HIP_TRANSPORT_MODE parameter has 16-bit unsigned integer fields The HIP_TRANSPORT_MODE parameter has 16-bit unsigned integer fields
for different modes, for which IANA is to create and maintain a new for different modes, for which IANA is to create and maintain a new
sub-registry entitled "HIP Transport Modes" under the "Host Identity sub-registry entitled "HIP Transport Modes" under the "Host Identity
Protocol (HIP) Parameters" registry. Initial values for the Protocol (HIP) Parameters" registry. Initial values for the
transport mode registry are given in Section 3.1; future assignments transport mode registry are given in Section 3.1; future assignments
are to be made through IETF Review [RFC5226]. Assignments consist of are to be made through IETF Review [RFC5226]. Assignments consist of
a transport mode identifier name and its associated value. a transport mode identifier name and its associated value.
This document also defines new HIP Notify Packet Type [RFC5201] This document also defines new HIP NOTIFICATION message type
NO_VALID_HIP_TRANSPORT_MODE in Section 4. [RFC5201] NO_VALID_HIP_TRANSPORT_MODE in Section 3.3.
8. References 10. References
8.1. Normative References 10.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.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008. "Host Identity Protocol", RFC 5201, April 2008.
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 5202, April 2008. the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
8.2. Informational References 10.2. Informational References
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008. Rendezvous Extension", RFC 5204, April 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008. Protocol", RFC 5206, April 2008.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions Keranen, "Basic Host Identity Protocol (HIP) Extensions
for Traversal of Network Address Translators", RFC 5770, for Traversal of Network Address Translators", RFC 5770,
April 2010. April 2010.
[I-D.ietf-hip-cert] [I-D.ietf-hip-cert]
Heer, T. and S. Varjonen, "HIP Certificates", Heer, T. and S. Varjonen, "Host Identity Protocol
draft-ietf-hip-cert-04 (work in progress), September 2010. Certificates", draft-ietf-hip-cert-06 (work in progress),
November 2010.
[I-D.ietf-hip-hiccups] [I-D.ietf-hip-hiccups]
Camarillo, G. and J. Melen, "HIP (Host Identity Protocol) Camarillo, G. and J. Melen, "HIP (Host Identity Protocol)
Immediate Carriage and Conveyance of Upper- layer Protocol Immediate Carriage and Conveyance of Upper- layer Protocol
Signaling (HICCUPS)", draft-ietf-hip-hiccups-05 (work in Signaling (HICCUPS)", draft-ietf-hip-hiccups-05 (work in
progress), July 2010. progress), July 2010.
Appendix A. Mobility and Multihoming Examples
When changing interfaces due to mobility or multihoming, the hosts
use HIP messages to notify the other host about the new address and
to check that the host with the new address is still reachable. The
following examples show the signaling performed during the address
change in two different scenarios. Note that not all HIP parameters
nor all the content of the parameters is shown in the examples. This
section and the examples are not normative; for normative behavior,
see previous sections.
In the examples, the host A uses two different addresses (a1 and a2)
while the host B has just a single address (b1). In the first
example, make before break (Figure 2), host A starts to use the new
address but can still use the old address (due to multihoming) for
signaling. In the second example, break before make (Figure 3), host
A loses the first address before obtaining the second address (e.g.,
due to mobility) and the mobility HIP signaling is done without the
encrypted connection.
The following notations are used in the examples:
o ESPx(y): data y sent encapsulated in ESP with SA x; if ESP
encapsulation is not used, the data is sent over plain IP or UDP
o UPDATE(x,y,z): HIP UPDATE message [RFC5201] with parameters x,y,z
o LOCATOR(x): HIP LOCATOR parameter [RFC5206] with locator x
o ESP_INFO(x,y): HIP ESP_INFO parameter [RFC5202] with "old SPI"
value x and "new SPI" value y
o ACK, ECHO_REQ, and ECHO_RSP: HIP ACK, ECHO_REQUEST, and
ECHO_RESPONSE parameters [RFC5201]
A B
ESP1(...)
a1 <----------------------------------------------> b1
ESP1(UPDATE(LOCATOR(a2), ESP_INFO(0,SPI2a)))
a1 -----------------------------------------------> b1
(A and B create SAs a2 <-> b1 (ESP2)
retransmissions of the first UPDATE
happen over ESP1)
ESP2(UPDATE(ACK, ESP_INFO(0,SPI2b), ECHO_REQ)))
a2 <----------------------------------------------- b1
ESP2(UPDATE(ACK, ECHO_RSP))
a2 -----------------------------------------------> b1
ESP2(...)
a2 <----------------------------------------------> b1
Figure 2: Make Before Break
A B
ESP1(...)
a1 <----------------------------------------------> b1
(A moves from a1 to a2)
UPDATE(LOCATOR(a2), ESP_INFO(SPI1a, SPI1a))
a2 -----------------------------------------------> b1
UPDATE(ACK, ECHO_REQ, ESP_INFO(SPI1b,SPI1b))
a2 <----------------------------------------------- b1
UPDATE(ACK, ECHO_RSP)
a2 -----------------------------------------------> b1
(A and B move ESP1 SAs to a2 <-> b1)
ESP1(...)
a2 <----------------------------------------------> b1
Figure 3: Break Before Make
When the ESP-TCP mode is used, the signaling flows are similar since
TCP is not used for the mobility UPDATE messages as described in
Section 6.
Author's Address Author's Address
Ari Keranen Ari Keranen
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
02420 Jorvas 02420 Jorvas
Finland Finland
Email: Ari.Keranen@ericsson.com Email: ari.keranen@ericsson.com
 End of changes. 35 change blocks. 
84 lines changed or deleted 171 lines changed or added

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