doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc6261.txt b/doc/rfc/rfc6261.txt
new file mode 100644
index 0000000..99439cd
--- /dev/null
+++ b/doc/rfc/rfc6261.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        A. Keranen
+Request for Comments: 6261                                      Ericsson
+Category: Experimental                                          May 2011
+ISSN: 2070-1721
+
+
+                Encrypted Signaling Transport Modes for
+                       the Host Identity Protocol
+
+Abstract
+
+   This document specifies two transport modes for Host Identity
+   Protocol (HIP) signaling messages that allow them to be conveyed over
+   encrypted connections initiated with the Host Identity Protocol.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6261.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Keranen                       Experimental                      [Page 1]
+
+RFC 6261         HIP Encrypted Signaling Transport Modes        May 2011
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   3.  Transport Mode Negotiation . . . . . . . . . . . . . . . . . .  3
+     3.1.  Mode Negotiation in the HIP Base Exchange  . . . . . . . .  3
+     3.2.  Mode Negotiation after the HIP Base Exchange . . . . . . .  5
+     3.3.  Error Notifications  . . . . . . . . . . . . . . . . . . .  5
+   4.  HIP Messages on Encrypted Connections  . . . . . . . . . . . .  5
+     4.1.  ESP Mode . . . . . . . . . . . . . . . . . . . . . . . . .  6
+     4.2.  ESP-TCP Mode . . . . . . . . . . . . . . . . . . . . . . .  6
+   5.  Recovering from Failed Encrypted Connections . . . . . . . . .  7
+   6.  Host Mobility and Multihoming  . . . . . . . . . . . . . . . .  8
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     10.1. Normative References . . . . . . . . . . . . . . . . . . .  9
+     10.2. Informational References . . . . . . . . . . . . . . . . . 10
+   Appendix A.  Mobility and Multihoming Examples . . . . . . . . . . 11
+
+1.  Introduction
+
+   Host Identity Protocol (HIP) [RFC5201] signaling messages can be
+   exchanged over plain IP using the protocol number reserved for this
+   purpose, or over UDP using the UDP port reserved for HIP NAT
+   traversal [RFC5770].  When two hosts perform a HIP base exchange,
+   they set up an encrypted connection between them for data traffic,
+   but continue to use plain IP or UDP for HIP signaling messages.
+
+   This document defines how the encrypted connection can be used also
+   for HIP signaling messages.  Two different modes are defined: HIP
+   over Encapsulating Security Payload (ESP) and HIP over TCP.  The
+   benefit of sending HIP messages over ESP is that all signaling
+   traffic (including HIP headers) will be encrypted.  If HIP messages
+   are sent over TCP (which in turn is transported over ESP), TCP can
+   handle also message fragmentation where needed.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+Keranen                       Experimental                      [Page 2]
+
+RFC 6261         HIP Encrypted Signaling Transport Modes        May 2011
+
+
+3.  Transport Mode Negotiation
+
+   This section defines how support for different HIP signaling message
+   transport modes is indicated and how the use of different modes is
+   negotiated.
+
+3.1.  Mode Negotiation in the HIP Base Exchange
+
+   A HIP host implementing this specification SHOULD indicate the modes
+   it supports, and is willing to use, in the base exchange.  The HIP
+   signaling message transport mode negotiation is similar to HIP NAT
+   traversal mode negotiation: first the Responder lists the supported
+   modes in a HIP_TRANSPORT_MODE parameter (see Figure 1) in the R1
+   packet.  The modes are listed in priority order, the more preferred
+   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
+   by adding a HIP_TRANSPORT_MODE parameter containing the selected mode
+   to the I2 packet.  Finally, if the Initiator selected one of the
+   modes and the base exchange succeeds, hosts MUST use the selected
+   mode for the following HIP signaling messages sent between them for
+   the duration of the HIP association or until another mode is
+   negotiated.
+
+   If the Initiator cannot, or will not, use any of the modes proposed
+   by the Responder, the Initiator SHOULD include an empty
+   HIP_TRANSPORT_MODE parameter to the I2 packet to signal that it
+   supports this extension but will not use any of the proposed modes.
+   Depending on local policy, the Responder MAY either abort the base
+   exchange or continue HIP signaling without using an encrypted
+   connection, if there was no HIP_TRANSPORT_MODE parameter in I2 or 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 MUST abort the base exchange.  If the base exchange is
+   aborted due to (possibly lack of) HIP_TRANSPORT_PARAMETER, the
+   Responder SHOULD send a NO_VALID_HIP_TRANSPORT_MODE notification (see
+   Section 3.3) to the Initiator.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Keranen                       Experimental                      [Page 3]
+
+RFC 6261         HIP Encrypted Signaling Transport Modes        May 2011
+
+
+      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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |             Type              |             Length            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |             Port              |           Mode ID #1          |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |          Mode ID #2           |           Mode ID #3          |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |          Mode ID #n           |             Padding           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+     Type     7680
+     Port     transport layer port number (or zero if not used)
+     Length   length in octets, excluding Type, Length, and Padding
+     Mode ID  defines the proposed or selected transport mode(s)
+
+     The following HIP Transport Mode IDs are defined:
+
+         ID name   Value
+         RESERVED    0
+         DEFAULT     1
+         ESP         2
+         ESP-TCP     3
+
+           Figure 1: Format of the HIP_TRANSPORT_MODE Parameter
+
+   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
+   subsequent HIP signaling messages.  In the ESP mode, the messages are
+   sent as such on the encrypted ESP connection; in the ESP-TCP mode,
+   TCP is used within the ESP tunnel.  If a mode that uses a transport
+   layer connection within the ESP tunnel (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.
+
+   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.
+
+
+
+
+
+
+
+
+
+Keranen                       Experimental                      [Page 4]
+
+RFC 6261         HIP Encrypted Signaling Transport Modes        May 2011
+
+
+3.2.  Mode Negotiation after the HIP Base Exchange
+
+   If a HIP host wants to change to a different transport mode (or start
+   using a transport mode) some time after the base exchange, it sends a
+   HIP UPDATE packet with a HIP_TRANSPORT_MODE parameter containing the
+   mode(s) it would prefer to use.  The host receiving the UPDATE SHOULD
+   respond with an UPDATE packet containing the mode 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 listed modes,
+   it SHOULD respond with an UPDATE packet where the HIP_TRANSPORT_MODE
+   parameter contains only the currently used transport mode (even if
+   that was not included in the previous UPDATE packet) and continue
+   using that mode.
+
+   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
+   extension would simply reply with an acknowledgement UPDATE packet
+   without a HIP_TRANSPORT_MODE parameter.  In such a case, depending on
+   local policy as in mode negotiation during the base exchange, the
+   host that requested the new transport mode MAY close the HIP
+   association.  If the association is closed, the host closing the
+   association SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet
+   to the other host before closing the association.
+
+3.3.  Error Notifications
+
+   During a HIP signaling transport mode negotiation, if a
+   HIP_TRANSPORT_MODE parameter does not contain any mode that 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 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
+   HIP packets over encrypted ESP connections.  These modes require that
+   the ESP transport format [RFC5202] is negotiated to be used between
+   the hosts.  If the ESP transport format is not used, these modes MUST
+   NOT be offered in the HIP_TRANSPORT_MODE parameter.  If a
+   HIP_TRANSPORT_MODE parameter containing an ESP transport mode is
+   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
+   a base exchange) or Section 3.2 (if performing an UPDATE) when no
+   valid mode is offered.
+
+
+
+Keranen                       Experimental                      [Page 5]
+
+RFC 6261         HIP Encrypted Signaling Transport Modes        May 2011
+
+
+   The ESP mode provides simple protection for all the signaling traffic
+   and can be used as a generic replacement for the DEFAULT mode in
+   cases where all signaling traffic should be encrypted.  If the HIP
+   messages may become so large that they would need to be fragmented,
+   e.g., because of HIP certificates [RFC6253] or DATA messages
+   [RFC6078], it is RECOMMENDED to use the ESP-TCP mode that can handle
+   message fragmentation at the TCP level instead of relying on 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
+   material, i.e., the base exchange and re-keying UPDATE messages, MUST
+   NOT be sent over the encrypted connection that is created using the
+   keying material that is being changed, nor over an encrypted
+   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 and HIP-aware
+   NATs) that would normally see the HIP headers and contents of the
+   unencrypted parameters, cannot see any part of the messages unless
+   they 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
+
+   If the ESP mode is selected in the base exchange, both hosts MUST
+   listen for incoming HIP signaling messages and send outgoing messages
+   on the encrypted connection.  The ESP header's next header value for
+   HIP messages sent over ESP MUST be set to HIP (139).
+
+4.2.  ESP-TCP Mode
+
+   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
+   listen for an incoming TCP connection on the encrypted connection
+
+
+
+Keranen                       Experimental                      [Page 6]
+
+RFC 6261         HIP Encrypted Signaling Transport Modes        May 2011
+
+
+   (i.e., to the HIT of the host) on 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 MAY use the port it sent in the
+   transport mode parameter as the source port for the connection.  Once
+   the TCP connection is established, both hosts MUST listen for
+   incoming HIP signaling messages and send the outgoing messages using
+   the TCP connection.  The ESP next header value for messages sent
+   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
+   initiated the mode negotiation MUST restart the negotiation with the
+   UPDATE message and SHOULD NOT propose the ESP-TCP mode.  If local
+   policy does not allow use of any mode other than ESP-TCP, the HIP
+   association SHOULD be closed.  The UPDATE or CLOSE message MUST be
+   sent using the same transport mode that was used for negotiating the
+   use of the ESP-TCP mode.
+
+   Since TCP provides reliable transport, the HIP messages sent over TCP
+   MUST NOT be retransmitted.  Instead, a host SHOULD wait to detect
+   that the TCP connection has failed to retransmit the packet
+   successfully in a timely manner (such detection is platform- and
+   policy-specific) before concluding that there is no response.
+
+5.  Recovering from Failed Encrypted Connections
+
+   If the encrypted connection fails for some reason, it can no longer
+   be used for HIP signaling and the hosts SHOULD re-establish the
+   connection using HIP messages that are sent outside of the encrypted
+   connection.  Hence, while listening for incoming HIP messages on the
+   encrypted connection, hosts MUST still accept incoming HIP messages
+   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
+   of the encrypted connection, the response MUST be sent using the same
+   transport method as the original message used.  If encryption was
+   previously used, hosts SHOULD send outside of the encrypted
+   connection only HIP messages that are used to re-establish the
+   encrypted connection.  In particular, when the policy requires that
+   only encrypted messages (e.g., DATA messages using an encrypted
+   transport mode) be sent, they MUST be sent using an encrypted
+   connection.  Note that a policy MUST NOT prevent sending unencrypted
+   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
+   MUST contain a HIP_TRANSPORT_MODE parameter and the negotiation
+   proceeds as described in Section 3.2.
+
+
+
+
+Keranen                       Experimental                      [Page 7]
+
+RFC 6261         HIP Encrypted Signaling Transport Modes        May 2011
+
+
+6.  Host Mobility and Multihoming
+
+   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
+   address, as described in [RFC5206].  If the ESP or ESP-TCP transport
+   mode is used, HIP signaling continues using the (new) SA pair and the
+   same transport mode as before.
+
+   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 as 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
+   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 renegotiate the new addresses using
+   unencrypted 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.
+
+   Examples of the signaling flows with mobility and multihoming are
+   shown in Appendix A.
+
+7.  Security Considerations
+
+   By exchanging the HIP messages over an ESP connection, all HIP
+   signaling data (after the base exchange but excluding keying material
+   (re)negotiation and some of the mobility UPDATE messages) will be
+   encrypted, but only if NULL encryption is not used.  Thus, a host
+   requiring confidentiality for the HIP signaling messages must check
+   that encryption is negotiated for use on the ESP connection.
+   Moreover, the level of protection provided by the ESP transport modes
+   depends on the selected ESP transform; see [RFC5202] and [RFC4303]
+   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
+
+
+
+Keranen                       Experimental                      [Page 8]
+
+RFC 6261         HIP Encrypted Signaling Transport Modes        May 2011
+
+
+   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, the 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
+
+   Thanks to Gonzalo Camarillo, Kristian Slavov, Tom Henderson, Miika
+   Komu, Jan Melen, and Tobias Heer for reviews and comments.
+
+9.  IANA Considerations
+
+   This section is to be interpreted according to [RFC5226].
+
+   This document updates the IANA maintained "Host Identity Protocol
+   (HIP) Parameters" registry [RFC5201] by assigning a new HIP Parameter
+   Type value (7680) for the HIP_TRANSPORT_MODE parameter (defined in
+   Section 3.1).
+
+   The HIP_TRANSPORT_MODE parameter has 16-bit unsigned integer fields
+   for different modes, for which IANA has created and now maintains a
+   new sub-registry entitled "HIP Transport Modes" under the "Host
+   Identity Protocol (HIP) Parameters" registry.  Initial values for the
+   transport mode registry are given in Section 3.1; future assignments
+   are to be made through IETF Review or IESG Approval [RFC5226].
+   Assignments consist of a transport mode identifier name and its
+   associated value.
+
+   This document also defines a new HIP NOTIFICATION message type
+   [RFC5201] NO_VALID_HIP_TRANSPORT_MODE (100) in Section 3.3.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
+              "Host Identity Protocol", RFC 5201, April 2008.
+
+   [RFC5202]  Jokela, P., Moskowitz, R., and P. Nikander, "Using the
+              Encapsulating Security Payload (ESP) Transport Format with
+              the Host Identity Protocol (HIP)", RFC 5202, April 2008.
+
+
+
+
+Keranen                       Experimental                      [Page 9]
+
+RFC 6261         HIP Encrypted Signaling Transport Modes        May 2011
+
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+10.2.  Informational References
+
+   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
+              RFC 4303, December 2005.
+
+   [RFC5204]  Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
+              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.
+              Keranen, "Basic Host Identity Protocol (HIP) Extensions
+              for Traversal of Network Address Translators", RFC 5770,
+              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.
+
+   [RFC6253]  Heer, T. and S. Varjonen, "Host Identity Protocol
+              Certificates", RFC 6253, May 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Keranen                       Experimental                     [Page 10]
+
+RFC 6261         HIP Encrypted Signaling Transport Modes        May 2011
+
+
+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, host A uses two different addresses (a1 and a2)
+   while 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]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Keranen                       Experimental                     [Page 11]
+
+RFC 6261         HIP Encrypted Signaling Transport Modes        May 2011
+
+
+            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.
+
+
+
+
+
+Keranen                       Experimental                     [Page 12]
+
+RFC 6261         HIP Encrypted Signaling Transport Modes        May 2011
+
+
+Author's Address
+
+   Ari Keranen
+   Ericsson
+   Hirsalantie 11
+   02420 Jorvas
+   Finland
+
+   EMail: ari.keranen@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Keranen                       Experimental                     [Page 13]
+