idnits 2.17.1 draft-ietf-hip-over-hip-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 149 has weird spacing: '... Length leng...' -- The document date (October 25, 2010) is 4931 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-04 Summary: 4 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 October 25, 2010 5 Expires: April 28, 2011 7 Host Identity Protocol Signaling Message Transport Modes 8 draft-ietf-hip-over-hip-03 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 to IETF 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), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 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 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 28, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Mode Negotiation in HIP Base Exchange . . . . . . . . . . 3 60 3.2. Mode Negotiation After HIP Base Exchange . . . . . . . . . 5 61 3.3. HIP Messages on Encrypted Connections . . . . . . . . . . 5 62 3.3.1. ESP mode . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3.2. ESP-TCP mode . . . . . . . . . . . . . . . . . . . . . 6 64 3.4. Recovering from Failed Encrypted Connections . . . . . . . 7 65 3.5. Host Mobility and Multihoming . . . . . . . . . . . . . . 7 66 4. Notify Packet Types . . . . . . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 72 8.2. Informational References . . . . . . . . . . . . . . . . . 9 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 Host Identity Protocol (HIP) [RFC5201] signaling messages can be 78 exchanged over plain IP using the protocol number reserved for this 79 purpose, or over UDP using the UDP port reserved for HIP NAT 80 traversal [RFC5770]. When two hosts perform a HIP base exchange, 81 they set up an encrypted connection between them for data traffic, 82 but continue to use plain IP or UDP for HIP signaling messages. 84 This document defines how the encrypted connection can be used also 85 for HIP signaling messages. Two different modes are defined: HIP 86 over Encapsulating Security Payload (ESP) and HIP over TCP. The 87 benefit of sending HIP messages over ESP is that all signaling 88 traffic (including HIP headers) will be encrypted. If HIP messages 89 are sent over TCP (which in turn is transported over ESP), TCP can 90 handle also message fragmentation where needed. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 3. Protocol Extensions 100 This section defines how support for different HIP signaling message 101 transport modes is negotiated and the normative behavior required by 102 the extension. 104 3.1. Mode Negotiation in HIP Base Exchange 106 A HIP host implementing this specification SHOULD indicate the modes 107 it supports, and is willing to use, in the base exchange. The HIP 108 signaling message transport mode negotiation is similar to HIP NAT 109 traversal mode negotiation: first the Responder lists the supported 110 modes in a HIP_TRANSPORT_MODE parameter (see Figure 1) in the R1 111 packet. The modes are listed in priority order; the more preferred 112 mode(s) first. If the Initiator supports, and is willing to use, any 113 of the modes proposed by the Responder, it selects one of the modes 114 by adding a HIP_TRANSPORT_MODE parameter containing the selected mode 115 to the I2 packet. Finally, if the Initiator selected one of the 116 modes and the base exchange succeeds, hosts MUST use the selected 117 mode for the following HIP signaling messages sent between them for 118 the duration of the HIP association or until another mode is 119 negotiated. 121 If the Initiator cannot or will not use any of the modes proposed by 122 the Responder, the Initiator SHOULD include an empty 123 HIP_TRANSPORT_MODE parameter to the I2 packet to signal that it 124 support this extension but will not use any of the proposed modes. 125 Depending on local policy, the Responder MAY either abort the base 126 exchange or continue HIP signaling without using an encrypted 127 connection, if there was no HIP_TRANSPORT_MODE parameter in I2 or the 128 parameter was empty. If the Initiator selects a mode that the 129 Responder does not support (and hence was not included in R1), the 130 Responder MUST abort the base exchange. If the base exchange is 131 aborted due to (possibly lack of) HIP_TRANSPORT_PARAMETER, the 132 Responder SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet 133 (see Section 4) to the Initiator. 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Type | Length | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Port | Mode ID #1 | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Mode ID #2 | Mode ID #3 | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Mode ID #n | Padding | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Type [ TBD by IANA; 7680 ] 148 Port transport layer port number (or zero if not used) 149 Length length in octets, excluding Type, Length, and Padding 150 Mode ID defines the proposed or selected transport mode(s) 152 The following Mode IDs are defined: 154 ID name Value 155 RESERVED 0 156 DEFAULT 1 157 ESP 2 158 ESP-TCP 3 160 Figure 1: Format of the HIP_TRANSPORT_MODE parameter 162 The mode DEFAULT indicates that the same transport mode (e.g., plain 163 IP or UDP) that was used for the base exchange should be used for 164 subsequent HIP signaling messages. In the ESP mode the messages are 165 sent as such on the encrypted ESP connection and in the ESP-TCP mode 166 TCP is used within the ESP tunnel. If a mode that uses a transport 167 layer connection (e.g., ESP-TCP) is offered, the Port field MUST 168 contain the local port number the host will use for the connection. 169 If none of the modes utilize a transport layer protocol, the Port 170 field SHOULD be set to zero when the parameter is sent and ignored 171 when received. The Port and Mode ID fields are encoded as unsigned 172 integers using network byte order. 174 3.2. Mode Negotiation After HIP Base Exchange 176 If a HIP hosts wants to change to a different transport mode (or 177 start using a transport mode) some time after the base exchange, it 178 sends a HIP UPDATE packet with a HIP_TRANSPORT_MODE parameter 179 containing the mode(s) it would prefer to use. The host receiving 180 the UPDATE SHOULD respond with an UPDATE packet containing the mode 181 that is selected as in the negotiation during the base exchange. If 182 the receiving host does not support, or is not willing to use, any of 183 the listed modes, it SHOULD respond with an UPDATE packet where the 184 HIP_TRANSPORT_MODE parameter contains only the currently used 185 transport mode (even if one was not included in the previous UPDATE 186 packet) and continue using that mode. 188 Since the HIP_TRANSPORT_MODE parameter's type is not critical (as 189 defined in Section 5.2.1 of [RFC5201]), a host not supporting this 190 extension would simply reply with an acknowledgement UPDATE packet 191 without a HIP_TRANSPORT_MODE parameter. In such a case, depending on 192 local policy as in mode negotiation during the base exchange, the 193 host that requested the new transport mode MAY close the HIP 194 association. If the association is closed, the host closing the 195 association SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet 196 to the other host before closing the association. 198 3.3. HIP Messages on Encrypted Connections 200 This specification defines two different transport modes for sending 201 HIP packets over encrypted ESP connections. These modes require that 202 the ESP transport format [RFC5202] is negotiated to be used between 203 the hosts. If the ESP transport format is not used, these modes MUST 204 NOT be offered in the HIP_TRANSPORT_MODE parameter. If a 205 HIP_TRANSPORT_MODE parameter containing an ESP transport mode is 206 received but the ESP transport format is not used, a host MUST NOT 207 select such a mode but act as specified in Section 3.1 (if performing 208 a base exchange) or Section 3.2 (if performing an UPDATE) when no 209 valid mode is offered. 211 The ESP mode provides simple protection for all the signaling traffic 212 and can be used as a generic replacement for the DEFAULT mode in 213 cases where all signaling traffic should be encrypted. If the HIP 214 messages may become so large that they would need to be fragmented, 215 e.g., because of HIP certificates [I-D.ietf-hip-cert] or DATA 216 messages [I-D.ietf-hip-hiccups], it is RECOMMENDED to use the ESP-TCP 217 mode which can handle message fragmentation at TCP level instead of 218 relying on IP level fragmentation. 220 HIP messages that result in changing or generating new keying 221 material, i.e., the base exchange and re-keying UPDATE messages, MUST 222 NOT be sent over the encrypted connection that is created using the 223 keying material that is being changed, nor over an encrypted 224 connection using the newly created keying material. 226 It should be noted that when HIP messages are sent using an encrypted 227 connection, on-path network elements (e.g., firewalls) that would 228 normally see the HIP headers and contents of the un-encrypted 229 parameters, cannot see any part of the messages unless they have 230 access to the encryption keying material. 232 3.3.1. ESP mode 234 If the ESP mode is selected in the base exchange, both hosts MUST 235 listen for incoming HIP signaling messages and send outgoing messages 236 on the encrypted connection. The ESP header's next header value for 237 such messages MUST be set to HIP (139). 239 3.3.2. ESP-TCP mode 241 If the ESP-TCP mode is selected, the host with the larger HIT 242 (calculated as defined in Section 6.5 of [RFC5201]) MUST start to 243 listen for an incoming TCP connection on the encrypted connection on 244 the port it used in the Port field of the transport mode parameter. 245 The other host MUST create a TCP connection to that port and the host 246 SHOULD use the port it sent in the transport mode parameter as the 247 source port for the TCP connection. Once the TCP connection is 248 established, both hosts MUST listen for incoming HIP signaling 249 messages and send the outgoing messages using the TCP connection. 250 The ESP next header value for messages sent using the ESP-TCP mode 251 connections MUST be set to TCP (6). 253 If the hosts are unable to create the TCP connection, the host that 254 initiated the mode negotiation MUST restart the negotiation with 255 UPDATE message and SHOULD NOT propose the ESP-TCP mode. If local 256 policy does not allow using any other mode than ESP-TCP, the HIP 257 association MUST be closed. The UPDATE or CLOSE message MUST be sent 258 using the same transport mode that was used for negotiating the use 259 of the ESP-TCP mode. 261 Since TCP provides reliable transport, the HIP messages sent over TCP 262 MUST NOT be retransmitted for the purpose of achieving reliable 263 transmission. Instead, a host SHOULD wait to detect that the TCP 264 connection has failed to retransmit the packet successfully in a 265 timely manner (such detection is platform- and policy-specific) 266 before concluding that there is no response. 268 3.4. Recovering from Failed Encrypted Connections 270 If the encrypted connection fails for some reason, it can no longer 271 be used for HIP signaling and the hosts SHOULD re-establish the 272 connection using HIP messages that are sent outside of the encrypted 273 connection. Hence, while listening for incoming HIP messages on the 274 encrypted connection, hosts MUST still accept incoming HIP messages 275 using the same transport method (e.g., UDP or plain IP) that was used 276 for the base exchange. When responding to a HIP message sent outside 277 of encrypted connection, the response MUST be sent using the same 278 transport method as the original message used. If encryption was 279 used, hosts SHOULD send outside of the encrypted connection only HIP 280 messages that are used to reestablish the encrypted connection. 281 Especially, messages that are intended to be sent only encrypted 282 (e.g., DATA messages using an encrypted transport mode) MUST NOT be 283 sent before the encrypted connection is reestablished. 285 The UPDATE messages used for re-establishing the encrypted connection 286 MUST contain a HIP_TRANSPORT_MODE parameter and the negotiation 287 proceeds as described in Section 3.2. 289 3.5. Host Mobility and Multihoming 291 If the host's address changes, usually a new Security Association 292 (SA) is created for the new address as described in [RFC5206] and if 293 an ESP or ESP-TCP transport mode is used, HIP signaling continues 294 using the new SA and the same transport mode as before. If the ESP- 295 TCP mode is used, the HIP signaling TCP connection is moved to the 296 new SA like any other TCP connection. 298 In some cases the host may not be able to send the mobility UPDATE 299 messages using the encrypted connection before it breaks. This 300 results in a similar situation as if the encrypted connection had 301 failed and the hosts need to re-negotiate the new addresses using un- 302 encrypted UPDATE messages and possibly rendezvous [RFC5204] or HIP 303 relay [RFC5770] servers. Also these UPDATE messages MUST contain the 304 HIP_TRANSPORT_MODE parameter and perform the transport mode 305 negotiation. 307 4. Notify Packet Types 309 The new Notify Packet Type [RFC5201] defined in this document is 310 shown below. The Notification Data field for the error notifications 311 SHOULD contain the HIP header of the rejected packet. 313 NOTIFICATION PARAMETER - ERROR TYPES Value 314 ------------------------------------ ----- 316 NO_VALID_HIP_TRANSPORT_MODE [TBD by IANA;100] 318 If a host sends an UPDATE message that does not have any transport 319 mode the receiving host is willing to use, the receiving host 320 sends back a NOTIFY error packet with this type. 322 5. Security Considerations 324 By exchanging the HIP messages over ESP connection, all HIP signaling 325 data (after the base exchange but excluding keying material 326 (re)negotiation) will be encrypted, but only if NULL encryption is 327 not used. Thus, a host requiring confidentiality for the HIP 328 signaling messages must check that encryption is negotiated to be 329 used on the ESP connection. Moreover, the level of protection 330 provided by the ESP transport modes depends on the selected ESP 331 transform; see [RFC5202] and [RFC4303] for security considerations of 332 the different ESP transforms. 334 6. Acknowledgements 336 Thanks to Gonzalo Camarillo, Kristian Slavov, Tom Henderson, Miika 337 Komu, Jan Melen, and Tobias Heer for comments on the draft. 339 7. IANA Considerations 341 This section is to be interpreted according to [RFC5226]. 343 This document updates the IANA Registry for HIP Parameter Types 344 [RFC5201] by assigning new HIP Parameter Type value for the 345 HIP_TRANSPORT_MODE parameter (defined in Section 3.1). 347 The HIP_TRANSPORT_MODE parameter has 16-bit unsigned integer fields 348 for different modes, for which IANA is to create and maintain a new 349 sub-registry entitled "HIP Transport Modes" under the "Host Identity 350 Protocol (HIP) Parameters" registry. Initial values for the 351 transport mode registry are given in Section 3.1; future assignments 352 are to be made through IETF Review [RFC5226]. Assignments consist of 353 a transport mode identifier name and its associated value. 355 This document also defines new HIP Notify Packet Type [RFC5201] 356 NO_VALID_HIP_TRANSPORT_MODE in Section 4. 358 8. References 360 8.1. Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, March 1997. 365 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 366 "Host Identity Protocol", RFC 5201, April 2008. 368 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 369 Encapsulating Security Payload (ESP) Transport Format with 370 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 372 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 373 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 374 May 2008. 376 8.2. Informational References 378 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 379 RFC 4303, December 2005. 381 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 382 Rendezvous Extension", RFC 5204, April 2008. 384 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 385 Host Mobility and Multihoming with the Host Identity 386 Protocol", RFC 5206, April 2008. 388 [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 389 Keranen, "Basic Host Identity Protocol (HIP) Extensions 390 for Traversal of Network Address Translators", RFC 5770, 391 April 2010. 393 [I-D.ietf-hip-cert] 394 Heer, T. and S. Varjonen, "HIP Certificates", 395 draft-ietf-hip-cert-04 (work in progress), September 2010. 397 [I-D.ietf-hip-hiccups] 398 Camarillo, G. and J. Melen, "HIP (Host Identity Protocol) 399 Immediate Carriage and Conveyance of Upper- layer Protocol 400 Signaling (HICCUPS)", draft-ietf-hip-hiccups-05 (work in 401 progress), July 2010. 403 Author's Address 405 Ari Keranen 406 Ericsson 407 Hirsalantie 11 408 02420 Jorvas 409 Finland 411 Email: Ari.Keranen@ericsson.com