idnits 2.17.1 draft-ietf-hip-via-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 256 has weird spacing: '... Length len...' == Line 260 has weird spacing: '...eserved reser...' -- The document date (June 29, 2010) is 5040 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 5204 (Obsoleted by RFC 8004) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-08 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group G. Camarillo 3 Internet-Draft A. Keranen 4 Intended status: Experimental Ericsson 5 Expires: December 31, 2010 June 29, 2010 7 Host Identity Protocol (HIP) Multi-hop Routing Extension 8 draft-ietf-hip-via-03.txt 10 Abstract 12 This document specifies two extensions to HIP to implement multi-hop 13 routing. The first extension allows implementing source routing in 14 HIP. That is, a node sending a HIP packet can define a set of nodes 15 that the HIP packet should traverse. The second extension allows a 16 HIP packet to carry and record the list of nodes that forwarded it. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 31, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 61 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Protocol Definitions . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Creating and Processing Via Lists . . . . . . . . . . . . . 4 64 3.2. Creating Destination Lists . . . . . . . . . . . . . . . . 4 65 3.3. Processing Destination Lists . . . . . . . . . . . . . . . 5 66 3.4. Fragmentation Considerations . . . . . . . . . . . . . . . 5 67 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. Source and Destination Route List Parameters . . . . . . . 6 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 71 6.1. Forged Destination and Via Lists . . . . . . . . . . . . . 8 72 6.2. Forwarding Loops . . . . . . . . . . . . . . . . . . . . . 8 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 When HIP [RFC5201] is used in certain contexts, nodes need the 82 ability to perform source routing. That is, a node needs the ability 83 to send a HIP signaling packet that will traverse a set of nodes 84 before reaching its destination. Such features are needed, e.g., in 85 HIP BONE [I-D.ietf-hip-bone] overlay networks or if two nodes wish to 86 keep a third, or more, HIP nodes on the signaling path. This 87 document defines an extension that provides HIP with this 88 functionality. 90 Additionally, when HIP signaling packets are routed through multiple 91 nodes, some of these nodes (e.g., the destination host) need the 92 ability to know the nodes a particular packet traversed. This 93 document defines another extension that provides HIP with this 94 functionality. 96 These two extensions enable multi-hop routing in HIP. Before these 97 extensions were specified, there were standardized ways for 98 supporting only a single intermediate node (e.g., a rendezvous server 99 [RFC5204]) between the source of a HIP packet and its destination. 101 2. Terminology 103 2.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2.2. Definitions 111 The following terms used in this document are similar to those 112 defined by RELOAD [I-D.ietf-p2psip-base] but used here in context of 113 HIP. 115 Destination list: A list of HITs of the nodes that a HIP packet 116 should traverse. 118 Via list: A list of HITs of the nodes that a HIP packet has 119 traversed. 121 Symmetric routing: A response to a message is routed back using the 122 same set of intermediary nodes as the original message used, 123 except in reversed order. Also known as symmetric recursive 124 routing. 126 3. Protocol Definitions 128 The multi-hop routing extensions may be used in different contexts 129 and whether a new HIP signaling packet should, for example, include a 130 Via list or have different options enabled, can depend on the 131 particular use case, local policies, and different protocols using 132 the extension. This section defines how the new parameters are 133 handled, but when to use these extensions, or how to configure them, 134 is out of scope for this document. 136 3.1. Creating and Processing Via Lists 138 When a node sending a HIP packet needs to record the nodes that are 139 on the path that the HIP packet traverses, it includes an empty 140 ROUTE_VIA parameter to the packet. 142 A node that receives a packet with a ROUTE_VIA parameter SHOULD add 143 its own HIT to the end of the ROUTE_VIA parameter, unless it is the 144 final recipient of the packet. If the node uses a different HIT on 145 the HIP association it used for receiving the packet than for sending 146 it forward, it SHOULD also add the receiving HIT to the route list 147 before the sending HIT. 149 If the node is the final recipient of the packet, and the received 150 packet generates a response HIP packet, the node checks the SYMMETRIC 151 flag from the ROUTE_VIA parameter. If the SYMMETRIC flag is set, the 152 node MUST create a ROUTE_DST parameter from the ROUTE_VIA parameter, 153 as described in Section 3.2, and include it in the response packet. 154 Also, if an intermediary node generates a new HIP packet (e.g., an 155 error NOTIFY packet) due to a HIP packet that had a ROUTE_VIA 156 parameter with SYMMETRIC flag set, and the new packet is intended for 157 the sender of the original HIP packet, the node SHOULD construct and 158 add a ROUTE_DST parameter into the new packet as in the previous 159 case. 161 3.2. Creating Destination Lists 163 A node that needs to define the other nodes that should be on the 164 path a HIP packet traverses adds a ROUTE_DST parameter to the HIP 165 packet. The node may either decide the path independently, or it may 166 create the path based on a ROUTE_VIA parameter. Only the originator 167 of a signed HIP packet can add a ROUTE_DST parameter to the HIP 168 packet, and none of the nodes on path can modify it, since the 169 parameter is covered by the signature. 171 When a node creates a ROUTE_DST parameter due to receiving a packet 172 with a ROUTE_VIA parameter, it copies all the HITs in the ROUTE_VIA 173 parameter to the ROUTE_DST parameter, but in reversed order. This 174 results in HIP response packet being forwarded using the same path as 175 the packet for which the response was generated for. If the exact 176 same set of nodes should be traversed by the response packet, also 177 the MUST_FOLLOW flag (see Table 1) SHOULD be set in the ROUTE_VIA 178 parameter (and eventually copied to the ROUTE_DST parameter) to 179 prevent the response packet possibly skipping some nodes on the list. 181 3.3. Processing Destination Lists 183 When a node receives a HIP packet that contains a ROUTE_DST 184 parameter, it first looks up its own HIT from the route list. If 185 node's own HIT is not in the list and the node is not the receiver of 186 the packet, the packet was incorrectly forwarded and MUST be dropped. 187 If the node's HIT is in the list more than once, the list is invalid 188 and the packet MUST be dropped to avoid forwarding loops. Next hop 189 for the packet is the HIT after node's own HIT in the list. If the 190 node's HIT was the last HIT in the list, the next hop is the 191 receiver's HIT in the HIP header. 193 If the MUST_FOLLOW flag in the ROUTE_DST parameter is not set, the 194 node SHOULD check whether it has a valid locator for one of the nodes 195 later in the list, or for the receiver of the packet, and it MAY 196 select such a node as the next hop. If the MUST_FOLLOW flag is set, 197 the node MUST NOT skip any nodes in the list. 199 If the node has a valid locator for the next hop, it MUST forward the 200 HIP packet to the next hop node. If the node can not determine a 201 valid locator for the next hop node, it SHOULD drop the packet and 202 SHOULD send back a NOTIFY error packet with type UNKNOWN_NEXT_HOP 203 (value [TBD by IANA; 90]). The Notification Data field for the error 204 notifications SHOULD contain the HIP header of the rejected packet 205 and the ROUTE_DST parameter. 207 3.4. Fragmentation Considerations 209 Via and Destination lists with multiple HITs can substantially 210 increase the size of the HIP packets and thus fragmentation issues 211 (see Section 5.1.3 of [RFC5201]) should be taken into consideration 212 when these extensions are used. Especially Via lists should be used 213 with care since the final size of the packet is not known unless the 214 maximum possible amount of hops is known beforehand. Both parameters 215 do still have a maximum size based on the maximum number of allowed 216 HITs (see Section 4.1). 218 4. Packet Formats 220 This memo defines two new HIP parameters that are used for recording 221 a route via multiple nodes (ROUTE_VIA) and for defining a route a 222 packet should traverse by the sender of the packet (ROUTE_DST). 224 The ROUTE_DST parameter is integrity protected with the signature 225 (where present) but ROUTE_VIA is not so that intermediary nodes can 226 add their own HITs to the list. Both parameters have critical type 227 (as defined in Section 5.2.1 of [RFC5201]) since the packet will not 228 be properly routed unless all nodes on path recognize the parameters. 230 4.1. Source and Destination Route List Parameters 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Type | Length | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Flags | Reserved | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | 240 | HIT #1 | 241 | | 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 . . . 245 . . . 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | | 248 | HIT #n | 249 | | 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Type [ TBD by IANA 254 ROUTE_DST: 971 255 ROUTE_VIA: 65525 ] 256 Length length in octets, excluding Type and Length 257 (i.e., number-of-HITs * 16 + 4) 258 Flags bit flags that can be used for requesting special 259 handling of the parameter 260 Reserved reserved for future use 261 HIT Host Identity Tag of one of the nodes on the path 263 Figure 1: Format of the ROUTE_VIA and ROUTE_DST Parameters 265 Figure 1 shows the format of both ROUTE_VIA and ROUTE_DST parameters. 266 The ROUTE_DST parameter, if present, MUST have at least one HIT, but 267 the ROUTE_VIA parameter can also have zero HITs. Neither of the 268 parameters SHALL NOT contain more than 32 HITs. The Flags field is 269 used for requesting special handling for Via and Destination lists. 270 The flags defined in this document are shown in Table 1. The 271 Reserved field can be used by future extensions; it MUST be zero when 272 sending and ignored when receiving this parameter. 274 +-----+-------------+-----------------------------------------------+ 275 | Pos | Name | Purpose | 276 +-----+-------------+-----------------------------------------------+ 277 | 0 | SYMMETRIC | The response packet MUST be sent with a | 278 | | | ROUTE_DST list made from the ROUTE_VIA list | 279 | | | containing this flag, i.e., using symmetric | 280 | | | routing. | 281 | 1 | MUST_FOLLOW | All the nodes in a ROUTE_DST list MUST be | 282 | | | traversed, i.e., even if a node would have a | 283 | | | valid locator for a node beyond the next hop, | 284 | | | it MUST NOT forward the packet there but to | 285 | | | the next hop node. | 286 +-----+-------------+-----------------------------------------------+ 288 Table 1: Bit Flags in ROUTE_VIA and ROUTE_DST Parameters 290 The "Pos" column in Table 1 shows the bit position of the flag (as in 291 Figure 1) in the Flags field, "Name" gives the name of the flag used 292 in this document, and "Purpose" gives brief description of the 293 meaning of that flag. 295 The flags apply to both ROUTE_VIA and ROUTE_DST parameters and when a 296 ROUTE_DST parameter is added to a packet because of a ROUTE_VIA 297 parameter, the same flags MUST be copied to the ROUTE_DST parameter. 299 5. IANA Considerations 301 This section is to be interpreted according to [RFC5226]. 303 This document updates the IANA Registry for HIP Parameter Types 304 [RFC5201] by assigning new HIP Parameter Type values for the new HIP 305 Parameters: ROUTE_VIA and ROUTE_DST (defined in Section 4). This 306 document also defines a new Notify Packet Type [RFC5201] 307 UNKNOWN_NEXT_HOP in Section 3.3. 309 The ROUTE_DST and ROUTE_VIA parameters utilize bit flags, for which 310 IANA is to create and maintain a new sub-registry entitled "HIP Via 311 Flags" under the "Host Identity Protocol (HIP) Parameters" registry. 312 Initial values for the registry are given in Table 1; future 313 assignments are to be made through IETF Review or IESG Approval 314 [RFC5226]. Assignments consist of the bit position and the name of 315 the flag. 317 6. Security Considerations 319 The standard HIP mechanisms (e.g., using signatures, puzzles, and the 320 ENCRYPTED parameter [RFC5201]) provide protection against 321 eavesdropping, replay, message insertion, deletion, modification, and 322 man-in-the-middle attacks. Yet, the extensions described in this 323 document allow nodes to route HIP messages via other nodes and hence 324 possibly try to mount Denial of Service (DoS) attacks against them. 325 The following sections describe possible attacks and means to 326 mitigate them. 328 6.1. Forged Destination and Via Lists 330 The Destination list is protected by the HIP signature so that the 331 receiver of the message can check that the list was indeed created by 332 the sender of the message and not modified on path. Also the nodes 333 forwarding the message MAY check the signature of the forwarded 334 packets if they have the Host Identity (HI) of the sender (e.g., from 335 a I2 or R1 message) and drop packets whose signature check fails. 336 With forwarding nodes checking the signature and allowing messages to 337 be forwarded only from nodes for which there is an active HIP 338 association, it is also possible to reliably identify attacking 339 nodes. 341 The limited amount of HITs allowed in a Destination list limits the 342 impact of attacks using a forged Destination list and the attacker 343 also needs to know a set of HIP nodes that are able to route the 344 message hop-by-hop for the attack to be effective. 346 A forged Via list results in a similar attack as with the Destination 347 list and with similar limitations. However, in this attack the 348 Destination list generated from the Via list is validly signed by the 349 responding node. To limit the effect of this kind of attacks a 350 responding node may further decrease the maximum acceptable number of 351 nodes in the Via lists or allow only certain HITs in the lists. 352 However, using these mechanisms require either good knowledge of the 353 overlay network (i.e., maximum realistic amount of hops) or knowing 354 the HITs of all potential nodes forwarding the messages. 356 6.2. Forwarding Loops 358 A malicious node could craft a destination route list that contains 359 the same HIT more than once and thus create a forwarding loop. The 360 check described in Section 3.3 should break such loops but nodes MAY 361 in addition utilize the OVERLAY_TTL [I-D.ietf-hip-bone] parameter for 362 additional protection against forwarding loops. 364 7. Acknowledgments 366 Tom Henderson provided valuable comments and improvement suggestions 367 for this document. 369 8. References 371 8.1. Normative References 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, March 1997. 376 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 377 "Host Identity Protocol", RFC 5201, April 2008. 379 8.2. Informative References 381 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 382 Rendezvous Extension", RFC 5204, April 2008. 384 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 385 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 386 May 2008. 388 [I-D.ietf-hip-bone] 389 Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., 390 and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) 391 Based Overlay Networking Environment", 392 draft-ietf-hip-bone-07 (work in progress), June 2010. 394 [I-D.ietf-p2psip-base] 395 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 396 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 397 Base Protocol", draft-ietf-p2psip-base-08 (work in 398 progress), March 2010. 400 Authors' Addresses 402 Gonzalo Camarillo 403 Ericsson 404 Hirsalantie 11 405 02420 Jorvas 406 Finland 408 Email: Gonzalo.Camarillo@ericsson.com 410 Ari Keranen 411 Ericsson 412 Hirsalantie 11 413 02420 Jorvas 414 Finland 416 Email: Ari.Keranen@ericsson.com