draft-ietf-hip-over-hip-02.txt   draft-ietf-hip-over-hip-03.txt 
HIP Working Group A. Keranen HIP Working Group A. Keranen
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Experimental October 18, 2010 Intended status: Experimental October 25, 2010
Expires: April 21, 2011 Expires: April 28, 2011
Host Identity Protocol Signaling Message Transport Modes Host Identity Protocol Signaling Message Transport Modes
draft-ietf-hip-over-hip-02 draft-ietf-hip-over-hip-03
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 21, 2011. This Internet-Draft will expire on April 28, 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. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 3
3.1. Mode Negotiation in HIP Base Exchange . . . . . . . . . . . 3 3.1. Mode Negotiation in HIP Base Exchange . . . . . . . . . . 3
3.2. Mode Negotiation After HIP Base Exchange . . . . . . . . . 5 3.2. Mode Negotiation After HIP Base Exchange . . . . . . . . . 5
3.3. HIP Messages on Encrypted Connections . . . . . . . . . . . 5 3.3. HIP Messages on Encrypted Connections . . . . . . . . . . 5
3.3.1. ESP mode . . . . . . . . . . . . . . . . . . . . . . . 6 3.3.1. ESP mode . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.2. ESP-TCP mode . . . . . . . . . . . . . . . . . . . . . 6 3.3.2. ESP-TCP mode . . . . . . . . . . . . . . . . . . . . . 6
3.4. Recovering from Failed Encrypted Connections . . . . . . . 6 3.4. Recovering from Failed Encrypted Connections . . . . . . . 7
3.5. Host Mobility . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Host Mobility and Multihoming . . . . . . . . . . . . . . 7
4. Notify Packet Types . . . . . . . . . . . . . . . . . . . . . . 7 4. Notify Packet Types . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informational References . . . . . . . . . . . . . . . . . 9 8.2. Informational References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
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 4, line 24 skipping to change at page 4, line 24
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 NOTIFY packet
(see Section 4) to the Initiator. (see Section 4) 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #1 | Mode ID #2 | | Port | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #n | Padding | | Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA; 7680 ] Type [ TBD by IANA; 7680 ]
Port transport layer port number (or zero if not used)
Length length in octets, excluding Type, Length, and Padding Length length in octets, excluding Type, Length, and Padding
Mode ID defines the proposed or selected transport mode(s) Mode ID defines the proposed or selected transport mode(s)
The following Mode IDs are defined: The following Mode IDs are defined:
ID name Value ID name Value
RESERVED 0 RESERVED 0
DEFAULT 1 DEFAULT 1
ESP 2 ESP 2
ESP-TCP 3 ESP-TCP 3
Figure 1: Format of the HIP_TRANSPORT_MODE parameter Figure 1: Format of the HIP_TRANSPORT_MODE parameter
The mode DEFAULT indicates that the same transport mode (e.g., plain The mode DEFAULT indicates that the same transport mode (e.g., plain
IP or UDP) that was used for the base exchange should be used for IP or UDP) that was used for the base exchange should be used for
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. 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
contain the local port number the host will use for the connection.
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
when received. The Port and Mode ID fields are encoded as unsigned
integers using network byte order.
3.2. Mode Negotiation After HIP Base Exchange 3.2. Mode Negotiation After 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
skipping to change at page 6, line 4 skipping to change at page 6, line 10
and can be used as a generic replacement for the DEFAULT mode in and can be used as a generic replacement for the DEFAULT mode in
cases where all signaling traffic should be encrypted. If the HIP cases where all signaling traffic should be encrypted. If the HIP
messages may become so large that they would need to be fragmented, messages may become so large that they would need to be fragmented,
e.g., because of HIP certificates [I-D.ietf-hip-cert] or DATA e.g., because of HIP certificates [I-D.ietf-hip-cert] or DATA
messages [I-D.ietf-hip-hiccups], it is RECOMMENDED to use the ESP-TCP messages [I-D.ietf-hip-hiccups], it is RECOMMENDED to use the ESP-TCP
mode which can handle message fragmentation at TCP level instead of mode which can handle message fragmentation at TCP level instead of
relying on IP level fragmentation. relying on IP level fragmentation.
HIP messages that result in changing or generating new keying HIP messages that result in changing or generating new keying
material, i.e., the base exchange and re-keying UPDATE messages, MUST material, i.e., the base exchange and re-keying UPDATE messages, MUST
NOT be sent over an 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
connection, on-path network elements (e.g., firewalls) that would
normally see the HIP headers and contents of the un-encrypted
parameters, cannot see any part of the messages unless they have
access to the encryption keying material.
3.3.1. ESP mode 3.3.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). such messages MUST be set to HIP (139).
3.3.2. ESP-TCP mode 3.3.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 port 10500 on the listen for an incoming TCP connection on the encrypted connection on
encrypted connection and the other host MUST create a TCP connection the port it used in the Port field of the transport mode parameter.
to that port. The host with the smaller HIT SHOULD use port 10500 as The other host MUST create a TCP connection to that port and the host
the source port for the TCP connection. Once the TCP connection is SHOULD use the port it sent in the transport mode parameter as the
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). 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 MUST be closed. The UPDATE or CLOSE message MUST be sent
skipping to change at page 7, line 5 skipping to change at page 7, line 18
3.4. Recovering from Failed Encrypted Connections 3.4. 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 encrypted connection, the response MUST be sent using the same
transport method as the original message used. Hosts SHOULD send transport method as the original message used. If encryption was
outside of the encrypted connection only HIP messages that are used used, hosts SHOULD send outside of the encrypted connection only HIP
to reestablish the encrypted connection. Especially, messages that messages that are used to reestablish the encrypted connection.
are intended to be sent only encrypted (e.g., DATA messages using an Especially, messages that are intended to be sent only encrypted
encrypted transport mode) MUST NOT be sent before the encrypted (e.g., DATA messages using an encrypted transport mode) MUST NOT be
connection is reestablished. sent before the encrypted connection is reestablished.
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 3.5. Host Mobility and Multihoming
If the host's address changes, it may not be able to send the If the host's address changes, usually a new Security Association
mobility UPDATE messages using the encrypted connection before it (SA) is created for the new address as described in [RFC5206] and if
breaks. This results in a similar situation as if the encrypted an ESP or ESP-TCP transport mode is used, HIP signaling continues
connection had failed and the hosts need to re-negotiate the new using the new SA and the same transport mode as before. If the ESP-
addresses using un-encrypted UPDATE messages and possibly rendezvous TCP mode is used, the HIP signaling TCP connection is moved to the
[RFC5204] or HIP relay [RFC5770] servers. Also these UPDATE messages new SA like any other TCP connection.
MUST contain the HIP_TRANSPORT_MODE parameter and perform the
transport mode negotiation. In some cases the host may not be able to send the mobility UPDATE
messages using the encrypted connection before it breaks. This
results in a similar situation as if the encrypted connection had
failed and the hosts need to re-negotiate the new addresses using un-
encrypted UPDATE messages and possibly rendezvous [RFC5204] or HIP
relay [RFC5770] servers. Also these UPDATE messages MUST contain the
HIP_TRANSPORT_MODE parameter and perform the transport mode
negotiation.
4. Notify Packet Types 4. Notify Packet Types
The new Notify Packet Type [RFC5201] defined in this document is The new Notify Packet Type [RFC5201] defined in this document is
shown below. The Notification Data field for the error notifications shown below. The Notification Data field for the error notifications
SHOULD contain the HIP header of the rejected packet. SHOULD contain the HIP header of the rejected packet.
NOTIFICATION PARAMETER - ERROR TYPES Value NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ ----- ------------------------------------ -----
skipping to change at page 8, line 11 skipping to change at page 8, line 30
not used. Thus, a host requiring confidentiality for the HIP not used. Thus, a host requiring confidentiality for the HIP
signaling messages must check that encryption is negotiated to be signaling messages must check that encryption is negotiated to be
used on the ESP connection. Moreover, the level of protection used on the ESP connection. Moreover, the level of protection
provided by the ESP transport modes depends on the selected ESP provided by the ESP transport modes depends on the selected ESP
transform; see [RFC5202] and [RFC4303] for security considerations of transform; see [RFC5202] and [RFC4303] for security considerations of
the different ESP transforms. the different ESP transforms.
6. Acknowledgements 6. Acknowledgements
Thanks to Gonzalo Camarillo, Kristian Slavov, Tom Henderson, Miika Thanks to Gonzalo Camarillo, Kristian Slavov, Tom Henderson, Miika
Komu, and Jan Melen for comments on the draft. Komu, Jan Melen, and Tobias Heer for comments on the draft.
7. IANA Considerations 7. 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
skipping to change at page 9, line 13 skipping to change at page 9, line 32
May 2008. May 2008.
8.2. Informational References 8.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-
Host Mobility and Multihoming with the Host Identity
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, "HIP Certificates",
draft-ietf-hip-cert-04 (work in progress), September 2010. draft-ietf-hip-cert-04 (work in progress), September 2010.
[I-D.ietf-hip-hiccups] [I-D.ietf-hip-hiccups]
 End of changes. 16 change blocks. 
46 lines changed or deleted 73 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/