idnits 2.17.1 draft-keranen-hip-over-hip-01.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 -- The document date (March 8, 2010) is 5162 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) == Outdated reference: A later version (-12) exists of draft-ietf-hip-cert-02 == Outdated reference: A later version (-05) exists of draft-ietf-hip-hiccups-02 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 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 8, 2010 5 Expires: September 9, 2010 7 Host Identity Protocol Signaling Message Transport Modes 8 draft-keranen-hip-over-hip-01 10 Abstract 12 This document specifies two transport modes for Host Identity 13 Protocol signaling messages that allow conveying them over encrypted 14 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 September 9, 2010. 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 . . . . . . . . . 4 61 3.3. HIP Messages on Encrypted Connections . . . . . . . . . . . 5 62 3.3.1. ESP mode . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.3.2. ESP-TCP mode . . . . . . . . . . . . . . . . . . . . . 5 64 3.4. Recovering from Failed Encrypted Connections . . . . . . . 6 65 3.5. Simultaneous Host Mobility . . . . . . . . . . . . . . . . 6 66 4. Notify Packet Types . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 72 8.2. Informational References . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 [I-D.ietf-hip-nat-traversal]. When two hosts perform a HIP 81 base exchange, they set up an encrypted connection between them for 82 data traffic, but continue to use plain IP or UDP for HIP signaling 83 messages. 85 This document defines how the encrypted connection can be used also 86 for HIP signaling messages. Two different modes are defined: HIP 87 over Encapsulating Security Payload (ESP) and HIP over TCP. The 88 benefit of sending HIP messages over ESP is that all signaling 89 traffic (including HIP headers) will be encrypted. If HIP messages 90 are sent over TCP (which in turn is transported over ESP), TCP can 91 handle also message fragmentation where needed. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 3. Protocol Extensions 101 This section defines how support for different HIP signaling message 102 transport modes is negotiated and the normative behavior required by 103 the extension. 105 3.1. Mode Negotiation in HIP Base Exchange 107 A HIP host implementing this specification SHOULD indicate the modes 108 it supports, and is willing to use, in the base exchange. The HIP 109 signaling message transport mode negotiation is similar to HIP NAT 110 traversal mode negotiation: first the Responder lists the supported 111 modes in a HIP_TRANSPORT_MODE parameter (see Figure 1) in the R1 112 packet. If the Initiator supports, and is willing to use, any of the 113 modes proposed by the Responder, it selects one of the modes by 114 adding a HIP_TRANSPORT_MODE parameter containing the selected mode to 115 the I2 packet. Finally, if the Initiator selected one of the modes 116 and the base exchange succeeds, hosts use the selected mode for the 117 following HIP signaling messages sent between them. 119 0 1 2 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Type | Length | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Mode ID #1 | Mode ID #2 | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Mode ID #n | Padding | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 Type [ TBD by IANA; 990 ] 130 Length length in octets, excluding Type, Length, and padding 131 Mode ID defines the proposed or selected transport mode(s) 133 The following mode IDs are defined: 135 ID name Value 136 RESERVED 0 137 DEFAULT 1 138 ESP 2 139 ESP-TCP 3 141 Figure 1: Format of the HIP_TRANSPORT_MODE parameter 143 The mode DEFAULT indicates that the same transport mode (e.g., plain 144 IP or UDP) that was used for the base exchange should be used for 145 subsequent HIP signaling messages. In the ESP mode the messages are 146 sent as such on the encrypted ESP connection and in the ESP-TCP mode 147 TCP is used within the ESP tunnel. 149 3.2. Mode Negotiation After HIP Base Exchange 151 If a HIP hosts wants to change to a different transport mode (or 152 start using a transport mode) some time after the base exchange, it 153 sends a HIP UPDATE packet with a HIP_TRANSPORT_MODE parameter 154 containing the mode(s) it would prefer to use. The host receiving 155 the UPDATE MUST respond with an UPDATE packet containing the mode 156 that is selected as in the negotiation during the base exchange. If 157 the receiving host does not support, or is not willing to use, any of 158 the listed modes, it MUST respond with a NO_VALID_HIP_TRANSPORT_MODE 159 NOTIFY packet (see Section 4) and continue using the same transport 160 mode. 162 Since the HIP_TRANSPORT_MODE parameter's type is not critical (as 163 defined in Section 5.2.1 of [RFC5201]), a host not supporting this 164 extension would simply acknowledge the UPDATE without responding with 165 an UPDATE containing a HIP_TRANSPORT_MODE parameter. 167 3.3. HIP Messages on Encrypted Connections 169 This specification defines two different transport modes for sending 170 HIP packets over encrypted ESP connections. These modes require that 171 the ESP transport format [RFC5202] is negotiated to be used between 172 the hosts. If the ESP transport format is not used, these modes MUST 173 NOT be offered in the HIP_TRANSPORT_MODE parameter. 175 The ESP mode provides simple protection for all the signaling traffic 176 and can be used as a generic replacement for the DEFAULT mode in 177 cases where all signaling traffic should be encrypted. If the HIP 178 messages may become so large that they would need to be fragmented, 179 e.g., because of HIP certificates [I-D.ietf-hip-cert] or DATA 180 messages [I-D.ietf-hip-hiccups], it is RECOMMENDED to use the ESP-TCP 181 mode which can handle message fragmentation at TCP level instead of 182 relying on IP level fragmentation. 184 3.3.1. ESP mode 186 If the ESP mode is selected in the base exchange, both hosts MUST 187 listen for incoming HIP signaling messages and send outgoing messages 188 on the encrypted connection. The ESP header's next header value for 189 such messages MUST be set to HIP (139). 191 3.3.2. ESP-TCP mode 193 If the ESP-TCP mode is selected, the host with the larger HIT 194 (calculated as defined in Section 6.5 of [RFC5201]) MUST start to 195 listen for an incoming TCP connection on the port 10500 on the 196 encrypted connection and the other host MUST create a TCP connection 197 to that port. The host with the lower HIT SHOULD use port 10500 as 198 the source port for the TCP connection. Once the TCP connection is 199 established, both hosts MUST listen for incoming HIP signaling 200 messages and send the outgoing messages using the TCP connection. 201 The ESP next header value for messages sent using the ESP-TCP mode 202 connections MUST be set to TCP (6). 204 If the hosts are unable to create the TCP connection, the host that 205 initiated the mode negotiation MUST restart the negotiation with 206 UPDATE message and SHOULD NOT propose the ESP-TCP mode. If local 207 policy does not allow using any other mode than ESP-TCP, the HIP 208 association MUST be closed. The UPDATE or CLOSE message MUST be sent 209 using the same transport mode that was used for negotiating the use 210 of the ESP-TCP mode. 212 Since TCP provides reliable transport, the HIP messages sent over TCP 213 MUST NOT be retransmitted for the purpose of achieving reliable 214 transmission. Instead, a host simply waits for the same time that 215 would be taken by the maximum amount of retransmissions with 216 unreliable transmission before concluding that there is no response. 218 3.4. Recovering from Failed Encrypted Connections 220 If the encrypted connection fails for some reason, it can no longer 221 be used for HIP signaling and the hosts SHOULD re-establish the 222 connection using HIP messages that are sent outside of the encrypted 223 connection. Hence, while listening for incoming HIP messages on the 224 encrypted connection, hosts MUST still accept incoming HIP messages 225 using the same transport method (e.g., UDP or plain IP) that was used 226 for the base exchange. When responding to a HIP message sent outside 227 of encrypted connection, the response MUST be sent using the same 228 transport method as the original message used. 230 The UPDATE messages used for re-establishing the encrypted connection 231 MUST contain a HIP_TRANSPORT_MODE parameter and the negotiation 232 proceeds as described in Section 3.2. 234 3.5. Simultaneous Host Mobility 236 If two hosts having a HIP association change addresses 237 simultaneously, they may not be able to send UPDATE messages to the 238 right address using the encrypted connection. This results in a 239 similar situation as if the encrypted connection had failed and the 240 hosts need to re-negotiate the new addresses using un-encrypted 241 UPDATE messages and possibly rendezvous [RFC5204] or HIP relay 242 [I-D.ietf-hip-nat-traversal] servers. Also these UPDATE messages 243 MUST contain the HIP_TRANSPORT_MODE parameter and perform the 244 transport mode negotiation. 246 4. Notify Packet Types 248 The new Notify Packet Types [RFC5201] defined in this document are 249 shown below. The Notification Data field for the error notifications 250 SHOULD contain the HIP header of the rejected packet. 252 NOTIFICATION PARAMETER - ERROR TYPES Value 253 ------------------------------------ ----- 255 NO_VALID_HIP_TRANSPORT_MODE 70 257 If a host sends UPDATE message that does not have any transport 258 mode the receiving host is willing to use, it sends back a NOTIFY 259 error packet with this type. 261 5. Security Considerations 263 By exchanging the HIP messages over ESP connection, all HIP signaling 264 data (after the base exchange) will be encrypted, but only if NULL 265 encryption is not used. Thus, host requiring confidentiality for the 266 HIP signaling messages must check that encryption is negotiated to be 267 used on the ESP connection. 269 6. Acknowledgements 271 Thanks to Gonzalo Camarillo, Kristian Slavov, Tom Henderson, and 272 Miika Komu for comments on the draft. 274 7. IANA Considerations 276 This section is to be interpreted according to [RFC5226]. 278 This document updates the IANA Registry for HIP Parameter Types 279 [RFC5201] by assigning new HIP Parameter Type value for the 280 HIP_TRANSPORT_MODE parameter (defined in Section 3.1). 282 The HIP_TRANSPORT_MODE parameter has 16-bit unsigned integer fields 283 for different modes, for which IANA is to create and maintain a new 284 sub-registry entitled "HIP Transport Modes" under the "Host Identity 285 Protocol (HIP) Parameters" registry. Initial values for the 286 transport mode registry are given in Section 3.1; future assignments 287 are to be made through IETF Review [RFC5226]. Assignments consist of 288 a transport mode identifier name and its associated value. 290 8. References 292 8.1. Normative References 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 298 "Host Identity Protocol", RFC 5201, April 2008. 300 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 301 Encapsulating Security Payload (ESP) Transport Format with 302 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 304 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 305 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 306 May 2008. 308 8.2. Informational References 310 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 311 Rendezvous Extension", RFC 5204, April 2008. 313 [I-D.ietf-hip-nat-traversal] 314 Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 315 Keranen, "Basic HIP Extensions for Traversal of Network 316 Address Translators", draft-ietf-hip-nat-traversal-09 317 (work in progress), October 2009. 319 [I-D.ietf-hip-cert] 320 Heer, T. and S. Varjonen, "HIP Certificates", 321 draft-ietf-hip-cert-02 (work in progress), October 2009. 323 [I-D.ietf-hip-hiccups] 324 Camarillo, G. and J. Melen, "HIP (Host Identity Protocol) 325 Immediate Carriage and Conveyance of Upper- layer Protocol 326 Signaling (HICCUPS)", draft-ietf-hip-hiccups-02 (work in 327 progress), March 2010. 329 Author's Address 331 Ari Keranen 332 Ericsson 333 Hirsalantie 11 334 02420 Jorvas 335 Finland 337 Email: Ari.Keranen@ericsson.com