idnits 2.17.1 draft-camarillo-hip-via-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 203 has weird spacing: '... Length len...' == Line 207 has weird spacing: '...eserved reser...' -- The document date (July 6, 2009) is 5408 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 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5204 (Obsoleted by RFC 8004) == Outdated reference: A later version (-07) exists of draft-ietf-hip-bone-01 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: January 7, 2010 July 6, 2009 7 Host Identity Protocol (HIP) Multi-hop Routing Extension 8 draft-camarillo-hip-via-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 7, 2010. 33 Copyright Notice 35 Copyright (c) 2009 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 in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document specifies two extensions to HIP to implement multi-hop 47 routing. The first extension allows a HIP packet to carry the list 48 of hosts that forwarded it. The second extension allows implementing 49 source routing in HIP. That is, a host sending a HIP packet can 50 define a set of hosts that the HIP packet should traverse. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 57 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 3 59 4. Protocol Definitions . . . . . . . . . . . . . . . . . . . . . 3 60 4.1. Creating and Processing Via Route Lists . . . . . . . . . . 4 61 4.2. Creating Destination Route Lists . . . . . . . . . . . . . 4 62 4.3. Processing Destination Route Lists . . . . . . . . . . . . 4 63 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Source and Destination Route List Parameters . . . . . . . 6 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Forwarding Loops . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 When HIP [RFC5201] is used in certain contexts (e.g., in a HIP BONE 76 [I-D.ietf-hip-bone] overlay), hosts need the ability to perform 77 source routing. That is, a host needs the ability to send a HIP 78 packet that will traverse a set of hosts before reaching its 79 destination. This document defines an extension that provides HIP 80 with this functionality. 82 Additionally, when HIP packets are routed through multiple hosts, 83 some of these hosts (e.g., the destination host) need the ability to 84 know the hosts a particular packet traversed. This document defines 85 another extension that provides HIP with this functionality. 87 These two extensions enable multi-hop routing in HIP. Before these 88 extensions were specified, HIP only supported a single intermediate 89 host (i.e., a rendezvous server [RFC5204]) between the source of a 90 HIP packet and its destination. 92 2. Terminology 94 2.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 2.2. Definitions 102 Route list: A list of HITs of the hosts that a HIP packet has 103 traversed or should traverse. 105 Symmetric routing: A response to a message is routed back using the 106 same set of intermediary nodes as the original message used, 107 except in reversed order. 109 3. Overview of Operations 111 TODO: this will be a non-normative section that will give a high- 112 level overview about how these extensions work. 114 4. Protocol Definitions 115 4.1. Creating and Processing Via Route Lists 117 When a host sending a HIP packet needs to record the hosts that are 118 on the path that the HIP packet traverses, it includes an empty 119 ROUTE_VIA parameter to the packet. 121 A host that receives a packet with a ROUTE_VIA parameter adds its own 122 HIT to the end of the ROUTE_VIA parameter, unless it is the receiver 123 of the packet. If the host uses a different HIT on the HIP 124 association it used for receiving the packet than for sending it 125 forward, it should also add the receiving HIT to the route list 126 before the sending HIT. 128 If the host is the receiver of the packet, and the received packet 129 generates a response HIP packet, the host checks the SYMMETRIC flag 130 from the ROUTE_VIA parameter. If the SYMMETRIC flag is set, the host 131 MUST create a ROUTE_DST parameter from the ROUTE_VIA parameter as 132 described in Section 4.2 and include it in the response packet. 133 Also, if an intermediary host generates a new HIP packet (e.g, an 134 error NOTIFY packet) due to a HIP packet that had a ROUTE_VIA 135 parameter with SYMMETRIC flag set, and the new packet is intended for 136 the sender of the original HIP packet, the host MUST construct and 137 add a ROUTE_DST parameter into the new packet as in the previous 138 case. 140 4.2. Creating Destination Route Lists 142 A host can add a ROUTE_DST parameter to a new HIP packet when it 143 needs to define the hosts that should be on the path the HIP packet 144 traverses. The host may either decide the path independently, or it 145 may create the path based on a ROUTE_VIA parameter. Only the 146 originator of a signed HIP packet can add a ROUTE_DST parameter to 147 the HIP packet since the parameter is covered by the signature. 149 When a host creates a ROUTE_DST parameter due to receiving a packet 150 with a ROUTE_VIA parameter, it copies all the HITs in the ROUTE_VIA 151 parameter to the ROUTE_DST parameter, but in reversed order. This 152 results in HIP response packet being forwarded using the same set of 153 hosts as the packet for which the response was generated for. 155 4.3. Processing Destination Route Lists 157 When a host receives a HIP packet that contains a ROUTE_DST 158 parameter, it first looks up its own HIT from the route list. If 159 host's own HIT is not in the list and the host is not the receiver of 160 the packet, the packet was incorrectly forwarded and MUST be dropped. 161 Next hop for the packet is the HIT after host's own HIT in the list. 162 If the host's HIT was the last HIT in the list, the next hop is the 163 receiver's HIT in the HIP header. 165 5. Packet Formats 167 This memo defines two new HIP parameters that are used for recording 168 a route via multiple hosts (ROUTE_VIA) and to define a route a packet 169 should traverse by the sender of the packet (ROUTE_DST). 171 The ROUTE_DST parameter is integrity protected with the signature 172 (where present) but ROUTE_VIA is not so that intermediary hosts can 173 add their own HITs to the list. Both parameters have critical type 174 (as defined in Section 5.2.1 of [RFC5201]) since the packet will not 175 be properly routed unless all hosts on path recognize the parameters. 177 5.1. Source and Destination Route List Parameters 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Type | Length | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Flags | Reserved | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | | 187 | HIT #1 | 188 | | 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 . . . 192 . . . 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | | 195 | HIT #n | 196 | | 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Type [ TBD by IANA 201 ROUTE_DST: 971 202 ROUTE_VIA: 65525 ] 203 Length length in octets, excluding Type and Length 204 (i.e., number-of-HITs * 16 + 4) 205 Flags bit flags that can be used for requesting special 206 handling of the parameter 207 Reserved reserved for future use 208 HIT Host Identity Tag of one of the hosts on the path 210 Figure 1: Format of the ROUTE_VIA and ROUTE_DST parameters 212 Figure 1 shows the format of both ROUTE_VIA and ROUTE_DST parameters. 213 The ROUTE_DST parameter, if present, MUST have at least one HIT, but 214 the ROUTE_VIA parameter can also have zero HITs. Both can contain at 215 most 32 HITs. The Flags field is used for requesting special 216 handling for certain Route lists. The flags defined in this document 217 are shown in Table 1. The Reserved field can be used by future 218 extensions; it MUST be zero when sending and ignored when receiving 219 this parameter. 221 +-----+-----------+-------------------------------------------------+ 222 | Pos | Name | Purpose | 223 +-----+-----------+-------------------------------------------------+ 224 | 0 | SYMMETRIC | The response packet MUST be sent using | 225 | | | ROUTE_DST list made from this ROUTE_VIA list, | 226 | | | i.e., using symmetric routing. | 227 +-----+-----------+-------------------------------------------------+ 229 Table 1: Bit flags in ROUTE_VIA parameter 231 The "Pos" column in Table 1 shows the bit position of the flag (as in 232 Figure 1) in the Flags field, "Name" gives the name of the flag used 233 in this document, and "Purpose" gives brief description of the 234 meaning of that flag. 236 6. IANA Considerations 238 This section is to be interpreted according to [RFC5226]. 240 This document updates the IANA Registry for HIP Parameter Types 241 [RFC5201] by assigning new HIP Parameter Type values for the new HIP 242 Parameters: ROUTE_VIA and ROUTE_DST (defined in Section 5). 244 7. Security Considerations 246 7.1. Forwarding Loops 248 A malicious host could craft a destination route list that contains 249 the same HIT more than once and thus create a forwarding loop. Since 250 the IP layer TTL is decremented on each hop, the loop will be 251 eventually broken, but hosts may additionally protect themselves 252 against this attack by checking that their own HIT is in the 253 destination list only once and drop invalid packets. 255 8. References 257 8.1. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 263 "Host Identity Protocol", RFC 5201, April 2008. 265 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 266 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 267 May 2008. 269 8.2. Informative References 271 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 272 Rendezvous Extension", RFC 5204, April 2008. 274 [I-D.ietf-hip-bone] 275 Camarillo, G., Nikander, P., Hautakorpi, J., and A. 276 Johnston, "HIP BONE: Host Identity Protocol (HIP) Based 277 Overlay Networking Environment", draft-ietf-hip-bone-01 278 (work in progress), March 2009. 280 Authors' Addresses 282 Gonzalo Camarillo 283 Ericsson 284 Hirsalantie 11 285 02420 Jorvas 286 Finland 288 Email: Gonzalo.Camarillo@ericsson.com 290 Ari Keranen 291 Ericsson 292 Hirsalantie 11 293 02420 Jorvas 294 Finland 296 Email: ari.keranen@ericsson.com