idnits 2.17.1 draft-ietf-hip-over-hip-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 144 has weird spacing: '... Length leng...' -- The document date (March 10, 2011) is 4789 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5202 (Obsoleted by RFC 7402) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5204 (Obsoleted by RFC 8004) -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) == Outdated reference: A later version (-12) exists of draft-ietf-hip-cert-11 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group A. Keranen 3 Internet-Draft Ericsson 4 Intended status: Experimental March 10, 2011 5 Expires: September 11, 2011 7 Encrypted Signaling Transport Modes for the Host Identity Protocol 8 draft-ietf-hip-over-hip-06 10 Abstract 12 This document specifies two transport modes for Host Identity 13 Protocol (HIP) signaling messages that allow conveying them over 14 encrypted connections initiated with the Host Identity Protocol. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 11, 2011. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Transport Mode Negotiation . . . . . . . . . . . . . . . . . . 3 53 3.1. Mode Negotiation in the HIP Base Exchange . . . . . . . . 3 54 3.2. Mode Negotiation After the HIP Base Exchange . . . . . . . 5 55 3.3. Error Notifications . . . . . . . . . . . . . . . . . . . 5 56 4. HIP Messages on Encrypted Connections . . . . . . . . . . . . 6 57 4.1. ESP Mode . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4.2. ESP-TCP Mode . . . . . . . . . . . . . . . . . . . . . . . 7 59 5. Recovering from Failed Encrypted Connections . . . . . . . . . 7 60 6. Host Mobility and Multihoming . . . . . . . . . . . . . . . . 8 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 66 10.2. Informational References . . . . . . . . . . . . . . . . . 10 67 Appendix A. Mobility and Multihoming Examples . . . . . . . . . . 11 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 1. Introduction 72 Host Identity Protocol (HIP) [RFC5201] signaling messages can be 73 exchanged over plain IP using the protocol number reserved for this 74 purpose, or over UDP using the UDP port reserved for HIP NAT 75 traversal [RFC5770]. When two hosts perform a HIP base exchange, 76 they set up an encrypted connection between them for data traffic, 77 but continue to use plain IP or UDP for HIP signaling messages. 79 This document defines how the encrypted connection can be used also 80 for HIP signaling messages. Two different modes are defined: HIP 81 over Encapsulating Security Payload (ESP) and HIP over TCP. The 82 benefit of sending HIP messages over ESP is that all signaling 83 traffic (including HIP headers) will be encrypted. If HIP messages 84 are sent over TCP (which in turn is transported over ESP), TCP can 85 handle also message fragmentation where needed. 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 3. Transport Mode Negotiation 95 This section defines how support for different HIP signaling message 96 transport modes is indicated and how the use of different modes is 97 negotiated. 99 3.1. Mode Negotiation in the HIP Base Exchange 101 A HIP host implementing this specification SHOULD indicate the modes 102 it supports, and is willing to use, in the base exchange. The HIP 103 signaling message transport mode negotiation is similar to HIP NAT 104 traversal mode negotiation: first the Responder lists the supported 105 modes in a HIP_TRANSPORT_MODE parameter (see Figure 1) in the R1 106 packet. The modes are listed in priority order; the more preferred 107 mode(s) first. If the Initiator supports, and is willing to use, any 108 of the modes proposed by the Responder, it selects one of the modes 109 by adding a HIP_TRANSPORT_MODE parameter containing the selected mode 110 to the I2 packet. Finally, if the Initiator selected one of the 111 modes and the base exchange succeeds, hosts MUST use the selected 112 mode for the following HIP signaling messages sent between them for 113 the duration of the HIP association or until another mode is 114 negotiated. 116 If the Initiator cannot, or will not, use any of the modes proposed 117 by the Responder, the Initiator SHOULD include an empty 118 HIP_TRANSPORT_MODE parameter to the I2 packet to signal that it 119 supports this extension but will not use any of the proposed modes. 120 Depending on local policy, the Responder MAY either abort the base 121 exchange or continue HIP signaling without using an encrypted 122 connection, if there was no HIP_TRANSPORT_MODE parameter in I2 or the 123 parameter was empty. If the Initiator selects a mode that the 124 Responder does not support (and hence was not included in R1), the 125 Responder MUST abort the base exchange. If the base exchange is 126 aborted due to (possibly lack of) HIP_TRANSPORT_PARAMETER, the 127 Responder SHOULD send a NO_VALID_HIP_TRANSPORT_MODE notification (see 128 Section 3.3) to the Initiator. 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Type | Length | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Port | Mode ID #1 | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Mode ID #2 | Mode ID #3 | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Mode ID #n | Padding | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Type [ TBD by IANA; 7680 ] 143 Port transport layer port number (or zero if not used) 144 Length length in octets, excluding Type, Length, and Padding 145 Mode ID defines the proposed or selected transport mode(s) 147 The following Mode IDs are defined: 149 ID name Value 150 RESERVED 0 151 DEFAULT 1 152 ESP 2 153 ESP-TCP 3 155 Figure 1: Format of the HIP_TRANSPORT_MODE parameter 157 The mode DEFAULT indicates that the same transport mode (e.g., plain 158 IP or UDP) that was used for the base exchange should be used for 159 subsequent HIP signaling messages. In the ESP mode the messages are 160 sent as such on the encrypted ESP connection and in the ESP-TCP mode 161 TCP is used within the ESP tunnel. If a mode that uses a transport 162 layer connection within the ESP tunnel (e.g., ESP-TCP) is offered, 163 the Port field MUST contain the local port number the host will use 164 for the connection. If none of the modes utilize a transport layer 165 protocol, the Port field SHOULD be set to zero when the parameter is 166 sent and ignored when received. The Port and Mode ID fields are 167 encoded as unsigned integers using network byte order. 169 The HIP_TRANSPORT_MODE parameter resides on the signed part of the 170 HIP packets, and hence it is covered by the signatures of the R1, I2, 171 and UPDATE packets. 173 3.2. Mode Negotiation After the HIP Base Exchange 175 If a HIP hosts wants to change to a different transport mode (or 176 start using a transport mode) some time after the base exchange, it 177 sends a HIP UPDATE packet with a HIP_TRANSPORT_MODE parameter 178 containing the mode(s) it would prefer to use. The host receiving 179 the UPDATE SHOULD respond with an UPDATE packet containing the mode 180 that is selected as in the negotiation during the base exchange. If 181 the receiving host does not support, or is not willing to use, any of 182 the listed modes, it SHOULD respond with an UPDATE packet where the 183 HIP_TRANSPORT_MODE parameter contains only the currently used 184 transport mode (even if that was not included in the previous UPDATE 185 packet) and continue using that mode. 187 Since the HIP_TRANSPORT_MODE parameter's type is not critical (as 188 defined in Section 5.2.1 of [RFC5201]), a host not supporting this 189 extension would simply reply with an acknowledgement UPDATE packet 190 without a HIP_TRANSPORT_MODE parameter. In such a case, depending on 191 local policy as in mode negotiation during the base exchange, the 192 host that requested the new transport mode MAY close the HIP 193 association. If the association is closed, the host closing the 194 association SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet 195 to the other host before closing the association. 197 3.3. Error Notifications 199 During a HIP signaling transport mode negotiation, if a 200 HIP_TRANSPORT_MODE parameter does not contain any mode the receiving 201 host is willing to use, or a HIP_TRANSPORT_MODE parameter does not 202 exist in a HIP packet where the receiving host expected to see it, 203 the receiving host MAY send back a NOTIFY packet with a NOTIFICATION 204 parameter [RFC5201] error type NO_VALID_HIP_TRANSPORT_MODE (value 205 [TBD by IANA; 100]). The Notification Data field for the error 206 notifications SHOULD contain the HIP header of the rejected packet. 208 4. HIP Messages on Encrypted Connections 210 This specification defines two different transport modes for sending 211 HIP packets over encrypted ESP connections. These modes require that 212 the ESP transport format [RFC5202] is negotiated to be used between 213 the hosts. If the ESP transport format is not used, these modes MUST 214 NOT be offered in the HIP_TRANSPORT_MODE parameter. If a 215 HIP_TRANSPORT_MODE parameter containing an ESP transport mode is 216 received but the ESP transport format is not used, a host MUST NOT 217 select such a mode but act as specified in Section 3.1 (if performing 218 a base exchange) or Section 3.2 (if performing an UPDATE) when no 219 valid mode is offered. 221 The ESP mode provides simple protection for all the signaling traffic 222 and can be used as a generic replacement for the DEFAULT mode in 223 cases where all signaling traffic should be encrypted. If the HIP 224 messages may become so large that they would need to be fragmented, 225 e.g., because of HIP certificates [I-D.ietf-hip-cert] or DATA 226 messages [RFC6078], it is RECOMMENDED to use the ESP-TCP mode which 227 can handle message fragmentation at TCP level instead of relying on 228 IP level fragmentation. 230 When HIP NAT traversal [RFC5770] is used, the ESP and HIP packets are 231 sent UDP-encapsulated. The use of different NAT traversal modes, and 232 in particular UDP-encapsulation, is independent of the transport mode 233 (as specified in this document) of HIP packets. However, when HIP 234 packets are sent over an ESP connection, no additional UDP- 235 encapsulation (i.e., within the ESP connection) for the HIP packets 236 is needed and MUST NOT be used since the ESP packets are already UDP- 237 encapsulated, if needed for NAT traversal. For example, if UDP- 238 encapsulation is used as defined in [RFC5770], and the ESP-TCP 239 transport mode is used as defined in this document, the HIP packets 240 are sent over IP, UDP, ESP, and TCP (in that order). 242 HIP messages that result in changing or generating new keying 243 material, i.e., the base exchange and re-keying UPDATE messages, MUST 244 NOT be sent over the encrypted connection that is created using the 245 keying material that is being changed, nor over an encrypted 246 connection using the newly created keying material. 248 It should be noted that when HIP messages are sent using an encrypted 249 connection, on-path network elements (e.g., firewalls and HIP-aware 250 NATs) that would normally see the HIP headers and contents of the un- 251 encrypted parameters, cannot see any part of the messages unless they 252 have access to the encryption keying material. The original HIP 253 design made an explicit decision to expose some of this information 254 to HIP-aware NATs. If an encrypted transport mode is used, only the 255 base exchange, or update without encryption, is visible to such NATs. 257 4.1. ESP Mode 259 If the ESP mode is selected in the base exchange, both hosts MUST 260 listen for incoming HIP signaling messages and send outgoing messages 261 on the encrypted connection. The ESP header's next header value for 262 HIP messages sent over ESP MUST be set to HIP (139). 264 4.2. ESP-TCP Mode 266 If the ESP-TCP mode is selected, the host with the larger HIT 267 (calculated as defined in Section 6.5 of [RFC5201]) MUST start to 268 listen for an incoming TCP connection on the encrypted connection 269 (i.e., to the HIT of the host) on the port it used in the Port field 270 of the transport mode parameter. The other host MUST create a TCP 271 connection to that port and the host MAY use the port it sent in the 272 transport mode parameter as the source port for the connection. Once 273 the TCP connection is established, both hosts MUST listen for 274 incoming HIP signaling messages and send the outgoing messages using 275 the TCP connection. The ESP next header value for messages sent 276 using the ESP-TCP mode TCP connections MUST be set to TCP (6). 278 If the hosts are unable to create the TCP connection, the host that 279 initiated the mode negotiation MUST restart the negotiation with 280 UPDATE message and SHOULD NOT propose the ESP-TCP mode. If local 281 policy does not allow using any other mode than ESP-TCP, the HIP 282 association SHOULD be closed. The UPDATE or CLOSE message MUST be 283 sent using the same transport mode that was used for negotiating the 284 use of the ESP-TCP mode. 286 Since TCP provides reliable transport, the HIP messages sent over TCP 287 MUST NOT be retransmitted. Instead, a host SHOULD wait to detect 288 that the TCP connection has failed to retransmit the packet 289 successfully in a timely manner (such detection is platform- and 290 policy-specific) before concluding that there is no response. 292 5. Recovering from Failed Encrypted Connections 294 If the encrypted connection fails for some reason, it can no longer 295 be used for HIP signaling and the hosts SHOULD re-establish the 296 connection using HIP messages that are sent outside of the encrypted 297 connection. Hence, while listening for incoming HIP messages on the 298 encrypted connection, hosts MUST still accept incoming HIP messages 299 using the same transport method (e.g., UDP or plain IP) that was used 300 for the base exchange. When responding to a HIP message sent outside 301 of the encrypted connection, the response MUST be sent using the same 302 transport method as the original message used. If encryption was 303 previously used, hosts SHOULD send outside of the encrypted 304 connection only HIP messages that are used to re-establish the 305 encrypted connection. Especially, messages for which the policy is 306 to send them only encrypted (e.g., DATA messages using an encrypted 307 transport mode) MUST be sent only using the encrypted connection. 308 Note that a policy MUST NOT prevent sending un-encrypted UPDATE 309 messages used for re-establishing the encrypted connection, since 310 that would prevent recovering from failed encrypted connections. 312 The UPDATE messages used for re-establishing the encrypted connection 313 MUST contain a HIP_TRANSPORT_MODE parameter and the negotiation 314 proceeds as described in Section 3.2. 316 6. Host Mobility and Multihoming 318 If a host obtains a new address, a new Security Association (SA) pair 319 may be created for (or an existing SA pair may be moved to) the new 320 address, as described in [RFC5206]. If the ESP or ESP-TCP transport 321 mode is used, HIP signaling continues using the (new) SA pair and the 322 same transport mode as before. 324 With the ESP mode, the first mobility UPDATE message SHOULD be sent 325 using the old SA and the following messages, including the response 326 to the first UPDATE, SHOULD be sent using the new SAs. 327 Retransmissions of the UPDATE messages use the same SA as the 328 original message. If the ESP-TCP mode is used, the HIP signaling TCP 329 connection is moved to the new SA pair like any other TCP connection. 330 However, the mobility UPDATE messages SHOULD NOT be sent over the TCP 331 connection, but using plain ESP like in the ESP mode, and 332 consequently hosts MUST be prepared to receive UPDATE messages over 333 plain ESP even if the ESP-TCP mode is used. 335 In some cases the host may not be able to send the mobility UPDATE 336 messages using the encrypted connection before it breaks. This 337 results in a similar situation as if the encrypted connection had 338 failed and the hosts need to re-negotiate the new addresses using un- 339 encrypted UPDATE messages and possibly rendezvous [RFC5204] or HIP 340 relay [RFC5770] servers. Also these UPDATE messages MUST contain the 341 HIP_TRANSPORT_MODE parameter and perform the transport mode 342 negotiation. 344 Examples of the signaling flows with mobility and multihoming are 345 shown in Appendix A. 347 7. Security Considerations 349 By exchanging the HIP messages over ESP connection, all HIP signaling 350 data (after the base exchange but excluding keying material 351 (re)negotiation and some of the mobility UPDATE messages) will be 352 encrypted, but only if NULL encryption is not used. Thus, a host 353 requiring confidentiality for the HIP signaling messages must check 354 that encryption is negotiated to be used on the ESP connection. 355 Moreover, the level of protection provided by the ESP transport modes 356 depends on the selected ESP transform; see [RFC5202] and [RFC4303] 357 for security considerations of the different ESP transforms. 359 While this extension to HIP allows for negotiation of security 360 features, there is no risk of downgrade attacks since the mode 361 negotiation happens using signed (R1/I2 or UPDATE) packets and only 362 after both hosts have been securely identified in the base exchange. 363 If an attacker would attempt to change the modes listed in the 364 HIP_TRANSPORT_MODE parameter, that would break the signatures and the 365 base exchange (or update) would not complete. Furthermore, since 366 both "secure" modes (ESP and ESP-TCP) defined in this document are 367 equally secure, only possible downgrade attack would be to make both 368 hosts accept the DEFAULT mode. If the local policy (of either host) 369 requires using a secure mode, the base exchange or update would again 370 simply fail (as described in Section 3.1). 372 8. Acknowledgements 374 Thanks to Gonzalo Camarillo, Kristian Slavov, Tom Henderson, Miika 375 Komu, Jan Melen, and Tobias Heer for reviews and comments. 377 9. IANA Considerations 379 This section is to be interpreted according to [RFC5226]. 381 This document updates the IANA Registry for HIP Parameter Types 382 [RFC5201] by assigning new HIP Parameter Type value for the 383 HIP_TRANSPORT_MODE parameter (defined in Section 3.1). 385 The HIP_TRANSPORT_MODE parameter has 16-bit unsigned integer fields 386 for different modes, for which IANA is to create and maintain a new 387 sub-registry entitled "HIP Transport Modes" under the "Host Identity 388 Protocol (HIP) Parameters" registry. Initial values for the 389 transport mode registry are given in Section 3.1; future assignments 390 are to be made through IETF Review or IESG Approval [RFC5226]. 391 Assignments consist of a transport mode identifier name and its 392 associated value. 394 This document also defines new HIP NOTIFICATION message type 395 [RFC5201] NO_VALID_HIP_TRANSPORT_MODE in Section 3.3. 397 10. References 399 10.1. Normative References 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 404 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 405 "Host Identity Protocol", RFC 5201, April 2008. 407 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 408 Encapsulating Security Payload (ESP) Transport Format with 409 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 411 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 412 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 413 May 2008. 415 10.2. Informational References 417 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 418 RFC 4303, December 2005. 420 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 421 Rendezvous Extension", RFC 5204, April 2008. 423 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 424 Host Mobility and Multihoming with the Host Identity 425 Protocol", RFC 5206, April 2008. 427 [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 428 Keranen, "Basic Host Identity Protocol (HIP) Extensions 429 for Traversal of Network Address Translators", RFC 5770, 430 April 2010. 432 [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) 433 Immediate Carriage and Conveyance of Upper-Layer Protocol 434 Signaling (HICCUPS)", RFC 6078, January 2011. 436 [I-D.ietf-hip-cert] 437 Heer, T. and S. Varjonen, "Host Identity Protocol 438 Certificates", draft-ietf-hip-cert-11 (work in progress), 439 March 2011. 441 Appendix A. Mobility and Multihoming Examples 443 When changing interfaces due to mobility or multihoming, the hosts 444 use HIP messages to notify the other host about the new address and 445 to check that the host with the new address is still reachable. The 446 following examples show the signaling performed during the address 447 change in two different scenarios. Note that not all HIP parameters 448 nor all the content of the parameters is shown in the examples. This 449 section and the examples are not normative; for normative behavior, 450 see previous sections. 452 In the examples, the host A uses two different addresses (a1 and a2) 453 while the host B has just a single address (b1). In the first 454 example, make before break (Figure 2), host A starts to use the new 455 address but can still use the old address (due to multihoming) for 456 signaling. In the second example, break before make (Figure 3), host 457 A loses the first address before obtaining the second address (e.g., 458 due to mobility) and the mobility HIP signaling is done without the 459 encrypted connection. 461 The following notations are used in the examples: 463 o ESPx(y): data y sent encapsulated in ESP with SA x; if ESP- 464 encapsulation is not used, the data is sent over plain IP or UDP 465 o UPDATE(x,y,z): HIP UPDATE message [RFC5201] with parameters x,y,z 466 o LOCATOR(x): HIP LOCATOR parameter [RFC5206] with locator x 467 o ESP_INFO(x,y): HIP ESP_INFO parameter [RFC5202] with "old SPI" 468 value x and "new SPI" value y 469 o ACK, ECHO_REQ, and ECHO_RSP: HIP ACK, ECHO_REQUEST, and 470 ECHO_RESPONSE parameters [RFC5201] 471 A B 472 ESP1(...) 473 a1 <----------------------------------------------> b1 475 ESP1(UPDATE(LOCATOR(a2), ESP_INFO(0,SPI2a))) 476 a1 -----------------------------------------------> b1 478 (A and B create SAs a2 <-> b1 (ESP2) 479 retransmissions of the first UPDATE 480 happen over ESP1) 482 ESP2(UPDATE(ACK, ESP_INFO(0,SPI2b), ECHO_REQ))) 483 a2 <----------------------------------------------- b1 485 ESP2(UPDATE(ACK, ECHO_RSP)) 486 a2 -----------------------------------------------> b1 488 ESP2(...) 489 a2 <----------------------------------------------> b1 491 Figure 2: Make Before Break 493 A B 494 ESP1(...) 495 a1 <----------------------------------------------> b1 496 (A moves from a1 to a2) 498 UPDATE(LOCATOR(a2), ESP_INFO(SPI1a, SPI1a)) 499 a2 -----------------------------------------------> b1 501 UPDATE(ACK, ECHO_REQ, ESP_INFO(SPI1b,SPI1b)) 502 a2 <----------------------------------------------- b1 504 UPDATE(ACK, ECHO_RSP) 505 a2 -----------------------------------------------> b1 506 (A and B move ESP1 SAs to a2 <-> b1) 508 ESP1(...) 509 a2 <----------------------------------------------> b1 511 Figure 3: Break Before Make 513 When the ESP-TCP mode is used, the signaling flows are similar since 514 TCP is not used for the mobility UPDATE messages as described in 515 Section 6. 517 Author's Address 519 Ari Keranen 520 Ericsson 521 Hirsalantie 11 522 02420 Jorvas 523 Finland 525 Email: ari.keranen@ericsson.com