draft-ietf-hip-over-hip-05.txt   draft-ietf-hip-over-hip-06.txt 
HIP Working Group A. Keranen HIP Working Group A. Keranen
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Experimental January 18, 2011 Intended status: Experimental March 10, 2011
Expires: July 22, 2011 Expires: September 11, 2011
Host Identity Protocol Signaling Message Transport Modes Encrypted Signaling Transport Modes for the Host Identity Protocol
draft-ietf-hip-over-hip-05 draft-ietf-hip-over-hip-06
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 in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on July 22, 2011. This Internet-Draft will expire on September 11, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Transport Mode Negotiation . . . . . . . . . . . . . . . . . . 3 3. Transport Mode Negotiation . . . . . . . . . . . . . . . . . . 3
3.1. Mode Negotiation in the HIP Base Exchange . . . . . . . . 3 3.1. Mode Negotiation in the HIP Base Exchange . . . . . . . . 3
3.2. Mode Negotiation After the HIP Base Exchange . . . . . . . 5 3.2. Mode Negotiation After the HIP Base Exchange . . . . . . . 5
3.3. Error Notifications . . . . . . . . . . . . . . . . . . . 5 3.3. Error Notifications . . . . . . . . . . . . . . . . . . . 5
4. HIP Messages on Encrypted Connections . . . . . . . . . . . . 5 4. HIP Messages on Encrypted Connections . . . . . . . . . . . . 6
4.1. ESP mode . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. ESP Mode . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. ESP-TCP mode . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. ESP-TCP Mode . . . . . . . . . . . . . . . . . . . . . . . 7
5. Recovering from Failed Encrypted Connections . . . . . . . . . 7 5. Recovering from Failed Encrypted Connections . . . . . . . . . 7
6. Host Mobility and Multihoming . . . . . . . . . . . . . . . . 7 6. Host Mobility and Multihoming . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informational References . . . . . . . . . . . . . . . . . 9 10.2. Informational References . . . . . . . . . . . . . . . . . 10
Appendix A. Mobility and Multihoming Examples . . . . . . . . . . 10 Appendix A. Mobility and Multihoming Examples . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
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 51 skipping to change at page 4, line 51
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. 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 within the ESP tunnel (e.g., ESP-TCP) is offered,
contain the local port number the host will use for the connection. the Port field MUST contain the local port number the host will use
If none of the modes utilize a transport layer protocol, the Port for the connection. If none of the modes utilize a transport layer
field SHOULD be set to zero when the parameter is sent and ignored protocol, the Port field SHOULD be set to zero when the parameter is
when received. The Port and Mode ID fields are encoded as unsigned sent and ignored when received. The Port and Mode ID fields are
integers using network byte order. encoded as unsigned integers using network byte order.
The HIP_TRANSPORT_MODE parameter resides on the signed part of the
HIP packets, and hence it is covered by the signatures of the R1, I2,
and UPDATE packets.
3.2. Mode Negotiation After the 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
skipping to change at page 5, line 40 skipping to change at page 5, line 44
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. Error Notifications 3.3. Error Notifications
During a HIP signaling transport mode negotiation, if a During a HIP signaling transport mode negotiation, if a
HIP_TRANSPORT_MODE parameter does not contain any mode the receiving HIP_TRANSPORT_MODE parameter does not contain any mode the receiving
host is willing to use, or a HIP_TRANSPORT_MODE parameter does not 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, 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 the receiving host MAY send back a NOTIFY packet with a NOTIFICATION
parameter [RFC5201] error type NO_VALID_HIP_TRANSPORT_MODE (value parameter [RFC5201] error type NO_VALID_HIP_TRANSPORT_MODE (value
[TBD by IANA; 100]). The Notification Data field for the error [TBD by IANA; 100]). The Notification Data field for the error
notifications SHOULD contain the HIP header of the rejected packet. notifications SHOULD contain the HIP header of the rejected packet.
4. HIP Messages on Encrypted Connections 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
skipping to change at page 6, line 16 skipping to change at page 6, line 23
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
valid mode is offered. valid mode is offered.
The ESP mode provides simple protection for all the signaling traffic The ESP mode provides simple protection for all the signaling traffic
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 [RFC6078], it is RECOMMENDED to use the ESP-TCP mode which
mode which can handle message fragmentation at TCP level instead of can handle message fragmentation at TCP level instead of relying on
relying on IP level fragmentation. IP level fragmentation.
When HIP NAT traversal [RFC5770] is used, the ESP and HIP packets are
sent UDP-encapsulated. The use of different NAT traversal modes, and
in particular UDP-encapsulation, is independent of the transport mode
(as specified in this document) of HIP packets. However, when HIP
packets are sent over an ESP connection, no additional UDP-
encapsulation (i.e., within the ESP connection) for the HIP packets
is needed and MUST NOT be used since the ESP packets are already UDP-
encapsulated, if needed for NAT traversal. For example, if UDP-
encapsulation is used as defined in [RFC5770], and the ESP-TCP
transport mode is used as defined in this document, the HIP packets
are sent over IP, UDP, ESP, and TCP (in that order).
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 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 and HIP-aware
normally see the HIP headers and contents of the un-encrypted NATs) that would normally see the HIP headers and contents of the un-
parameters, cannot see any part of the messages unless they have encrypted parameters, cannot see any part of the messages unless they
access to the encryption keying material. have access to the encryption keying material. The original HIP
design made an explicit decision to expose some of this information
to HIP-aware NATs. If an encrypted transport mode is used, only the
base exchange, or update without encryption, is visible to such NATs.
4.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
HIP messages sent over ESP MUST be set to HIP (139). HIP messages sent over ESP MUST be set to HIP (139).
4.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
the port it used in the Port field of the transport mode parameter. (i.e., to the HIT of the host) on the port it used in the Port field
The other host MUST create a TCP connection to that port and the host of the transport mode parameter. The other host MUST create a TCP
SHOULD use the port it sent in the transport mode parameter as the connection to that port and the host MAY use the port it sent in the
source port for the TCP connection. Once the TCP connection is transport mode parameter as the source port for the connection. Once
established, both hosts MUST listen for incoming HIP signaling the TCP connection is established, both hosts MUST listen for
messages and send the outgoing messages using the TCP connection. incoming HIP signaling messages and send the outgoing messages using
The ESP next header value for messages sent using the ESP-TCP mode the TCP connection. The ESP next header value for messages sent
TCP connections MUST be set to TCP (6). using the ESP-TCP mode 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 SHOULD be closed. The UPDATE or CLOSE message MUST be association SHOULD be closed. The UPDATE or CLOSE message MUST be
sent using the same transport mode that was used for negotiating the sent using the same transport mode that was used for negotiating the
use 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. Instead, a host SHOULD wait to detect
transmission. Instead, a host SHOULD wait to detect that the TCP that the TCP connection has failed to retransmit the packet
connection has failed to retransmit the packet successfully in a successfully in a timely manner (such detection is platform- and
timely manner (such detection is platform- and policy-specific) policy-specific) before concluding that there is no response.
before concluding that there is no response.
5. 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 the 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
previously used, hosts SHOULD send outside of the encrypted previously used, hosts SHOULD send outside of the encrypted
connection only HIP messages that are used to re-establish the connection only HIP messages that are used to re-establish the
encrypted connection. Especially, messages that are intended to be encrypted connection. Especially, messages for which the policy is
sent only encrypted (e.g., DATA messages using an encrypted transport to send them only encrypted (e.g., DATA messages using an encrypted
mode) MUST be sent only using the encrypted connection. transport mode) MUST be sent only using the encrypted connection.
Note that a policy MUST NOT prevent sending un-encrypted UPDATE
messages used for re-establishing the encrypted connection, since
that would prevent recovering from failed encrypted connections.
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.
6. Host Mobility and Multihoming 6. Host Mobility and Multihoming
If a host obtains a new address, a new Security Association (SA) pair If a host obtains a new address, a new Security Association (SA) pair
may be created for (or an existing SA pair may be moved to) the new may be created for (or an existing SA pair may be moved to) the new
address, as described in [RFC5206]. If the ESP or ESP-TCP transport address, as described in [RFC5206]. If the ESP or ESP-TCP transport
skipping to change at page 8, line 37 skipping to change at page 9, line 17
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 and some of the mobility UPDATE messages) will be (re)negotiation and some of the mobility UPDATE messages) will be
encrypted, but only if NULL encryption is not used. Thus, a host encrypted, but only if NULL encryption is not used. Thus, a host
requiring confidentiality for the HIP signaling messages must check requiring confidentiality for the HIP signaling messages must check
that encryption is negotiated to be used on the ESP connection. that encryption is negotiated to be used on the ESP connection.
Moreover, the level of protection provided by the ESP transport modes Moreover, the level of protection provided by the ESP transport modes
depends on the selected ESP transform; see [RFC5202] and [RFC4303] depends on the selected ESP transform; see [RFC5202] and [RFC4303]
for security considerations of the different ESP transforms. for security considerations of the different ESP transforms.
While this extension to HIP allows for negotiation of security
features, there is no risk of downgrade attacks since the mode
negotiation happens using signed (R1/I2 or UPDATE) packets and only
after both hosts have been securely identified in the base exchange.
If an attacker would attempt to change the modes listed in the
HIP_TRANSPORT_MODE parameter, that would break the signatures and the
base exchange (or update) would not complete. Furthermore, since
both "secure" modes (ESP and ESP-TCP) defined in this document are
equally secure, only possible downgrade attack would be to make both
hosts accept the DEFAULT mode. If the local policy (of either host)
requires using a secure mode, the base exchange or update would again
simply fail (as described in Section 3.1).
8. 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 reviews and comments.
9. 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 or IESG Approval [RFC5226].
a transport mode identifier name and its associated value. Assignments consist of a transport mode identifier name and its
associated value.
This document also defines new HIP NOTIFICATION message type This document also defines new HIP NOTIFICATION message type
[RFC5201] NO_VALID_HIP_TRANSPORT_MODE in Section 3.3. [RFC5201] NO_VALID_HIP_TRANSPORT_MODE in Section 3.3.
10. References 10. References
10.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.
skipping to change at page 9, line 51 skipping to change at page 10, line 43
[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.
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP)
Immediate Carriage and Conveyance of Upper-Layer Protocol
Signaling (HICCUPS)", RFC 6078, January 2011.
[I-D.ietf-hip-cert] [I-D.ietf-hip-cert]
Heer, T. and S. Varjonen, "Host Identity Protocol Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", draft-ietf-hip-cert-08 (work in progress), Certificates", draft-ietf-hip-cert-11 (work in progress),
January 2011. March 2011.
[I-D.ietf-hip-hiccups]
Camarillo, G. and J. Melen, "HIP (Host Identity Protocol)
Immediate Carriage and Conveyance of Upper- layer Protocol
Signaling (HICCUPS)", draft-ietf-hip-hiccups-05 (work in
progress), July 2010.
Appendix A. Mobility and Multihoming Examples Appendix A. Mobility and Multihoming Examples
When changing interfaces due to mobility or multihoming, the hosts When changing interfaces due to mobility or multihoming, the hosts
use HIP messages to notify the other host about the new address and 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 to check that the host with the new address is still reachable. The
following examples show the signaling performed during the address following examples show the signaling performed during the address
change in two different scenarios. Note that not all HIP parameters change in two different scenarios. Note that not all HIP parameters
nor all the content of the parameters is shown in the examples. This nor all the content of the parameters is shown in the examples. This
section and the examples are not normative; for normative behavior, section and the examples are not normative; for normative behavior,
skipping to change at page 10, line 36 skipping to change at page 11, line 27
while the host B has just a single address (b1). In the first 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 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 address but can still use the old address (due to multihoming) for
signaling. In the second example, break before make (Figure 3), host signaling. In the second example, break before make (Figure 3), host
A loses the first address before obtaining the second address (e.g., A loses the first address before obtaining the second address (e.g.,
due to mobility) and the mobility HIP signaling is done without the due to mobility) and the mobility HIP signaling is done without the
encrypted connection. encrypted connection.
The following notations are used in the examples: The following notations are used in the examples:
o ESPx(y): data y sent encapsulated in ESP with SA x; if ESP 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 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 UPDATE(x,y,z): HIP UPDATE message [RFC5201] with parameters x,y,z
o LOCATOR(x): HIP LOCATOR parameter [RFC5206] with locator x o LOCATOR(x): HIP LOCATOR parameter [RFC5206] with locator x
o ESP_INFO(x,y): HIP ESP_INFO parameter [RFC5202] with "old SPI" o ESP_INFO(x,y): HIP ESP_INFO parameter [RFC5202] with "old SPI"
value x and "new SPI" value y value x and "new SPI" value y
o ACK, ECHO_REQ, and ECHO_RSP: HIP ACK, ECHO_REQUEST, and o ACK, ECHO_REQ, and ECHO_RSP: HIP ACK, ECHO_REQUEST, and
ECHO_RESPONSE parameters [RFC5201] ECHO_RESPONSE parameters [RFC5201]
A B A B
ESP1(...) ESP1(...)
a1 <----------------------------------------------> b1 a1 <----------------------------------------------> b1
 End of changes. 20 change blocks. 
62 lines changed or deleted 95 lines changed or added

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