idnits 2.17.1 draft-lindell-waypoint-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 320, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 327, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 330, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 334, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 337, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2401 (ref. '3') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2408 (ref. '4') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2402 (ref. '5') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '6') (Obsoleted by RFC 4303, RFC 4305) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Bob Lindell 3 Expiration: August 2001 Bob Braden 4 File: draft-lindell-waypoint-00.txt USC/ISI 6 Waypoint - A Path Oriented Delivery Mechanism for 7 IP based Control, Measurement, and Signaling Protocols 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet 15 Engineering Task Force (IETF), its areas, and its working 16 groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "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 29 at http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes the Waypoint path oriented delivery 34 mechanism. Waypoint attempts to rationalize the packet 35 interception problem that has been addressed by different 36 mechanisms such as router alert or RSVP protocol number 46 37 intercept. It borrows concepts from prior mechanisms, 38 including the hop by hop security model of RSVP. Waypoint 39 strives to be complete, eliminating the need to reimplement 40 common functionality in the higher layers of the signaling 41 protocol stack. 43 1. Introduction 45 There are a broad range of protocols currently defined, or under 46 development, for the Internet Protocol that require that ability to 47 perform path oriented operations. Path oriented operations require the 48 ability to process control information at every router or some defined 49 subset of the routers along the end to end path traversed by a given IP 50 routing path. For some path oriented operations the signaling is 51 actually confined to a portion of the end to end path. On example is 52 path oriented network management operations confined to a providers 53 domain. Another example is the establishment of routing state within a 54 given domain (e.g. traffic engineered tunnels). In this document we use 55 the term end to end in this more general context. End to end will refer 56 to either the entire data path or a well defined contiguous portion of 57 the path. 59 We envision that a number of existing protocols, RSVP, RSVP-TE, and LDP 60 could be layered upon Waypoint. These protocols, with end to end 61 semantics and message reliability, most closely occupy the transport 62 layer of the OSI reference model. Waypoint, on the other hand, is 63 sandwiched somewhere in murky boundary between the transport and network 64 layers. It is distinctly above IP, and as such, is expected to be 65 implemented over the full range of IP protocols, both unicast and 66 multicast IPv4 and IPv6 at the present time. 68 A major motivation for Waypoint is the belief that its existance will 69 enable the creation of novel new path oriented control, signaling, and 70 measurement protocols. Particularly appealing are the simple stateless 71 measurement protocols. An example would be an enhanced path tracing 72 protocol that was implemented on top of Waypoint rather than ICMP. 74 2. Current Shortcomings 76 There are a number of long term shortcomings to the current approaches 77 of packet interception and the use of ICMP for measurement purposes. We 78 will briefly highlight some of these issues in this section. 80 The current implementation of RSVP-TE grew out of an interest in reusing 81 the existing RSVP protocol for MPLS tunnels. In the end, it required 82 only the addition of a few new message object types and some additional 83 processing rules. An unexpected result is that it seems to have reused 84 the RSVP protocol number as well! This may have been deliberate in 85 order to reuse the existing intercept mechanisms that may be limited to 86 only a single protocol number on some router implementations. In the 87 longer term, it would seem important for the clarity of implementations 88 to separate different path oriented operations with distinct protocol 89 and/or port numbers. 91 Both the router alert option and the RSVP protocol number 46 intercept 92 suffer from limited ability to control the interception process. 93 Experience has demonstrated interest in the ability to tunnel a packet 94 through a series of intermediate routers along a path. Similarly, for 95 realistic deployment scenarios, some routers along a path will not 96 implement a newly deployed service and it is desired that the packet be 97 forwarded through to the next router along the path capable of 98 processing the packet. Router alert and protocol 46 intercept requires 99 IP encapsulation as the only method that will tunnel packets through a 100 series of routers without intermediate processing. Router alert has 101 another unwanted performance penalty. When a signaling packet is 102 forwarded through a router that does not implement the path oriented 103 service, it will likely be processed in the slower forwarding path due 104 to the existance of an IP option in the packet. Basically, these 105 current mechanisms have limited hop control and performance penalties 106 over other approaches. 108 There are many variations of path oriented measurements that use ICMP. 109 All of these approaches suffer substantially either from a feature 110 perspective or measured results. It is well known that ICMP processing 111 on most routers is not representative of the router performance, 112 especially in the measured delay. Simple stateless path oriented 113 measurement solutions using Waypoint would eliminate many of these 114 flaws. Measurement packets could be properly timestamped at different 115 time in the reception, processing, and transmission stages to more 116 accurately represent the measured quantities of interest. The 117 information gleamed from an ICMP response is also quite limited. At 118 best, one is able to determine an IP address and some information about 119 the type of router. Clearly more novel services could be created if 120 there was an ability to perform path oriented operations coupled with 121 freedom to control the payload contents. 123 By definition, IPSEC provides end to end security. Path oriented 124 operations are therefore excluded from the use of IPSEC. To prevent 125 each protocol from inventing their own security solution, it is 126 important that the Internet architecture provide a comparable service to 127 IPSEC for path oriented protocols. 129 3. Functional Description 131 The Waypoint protocol envisions a large collection of well defined path 132 oriented protocols. To accommodate many services, Waypoint packets 133 carry port fields in an identical fashion to the use of port numbers in 134 the UDP and TCP protocols. Well known services will use globally 135 assigned well known Waypoint port numbers. 137 Waypoint, using IP, delivers packets along an end to end path. Unlike 138 other IP transport protocols, it is not a strictly end to end protocol. 139 Waypoint packets can be delivered to intermediate routers along the end 140 to end path even though the destination address of the packet is not 141 that of the router. This distinguishes Waypoint from most transport 142 protocols and places the functionality somewhere in the murky boundary 143 between the 3rd and 4th layer of the OSI protocol model. 145 Since Waypoint is not strictly end to end, the common functionality of 146 IPSEC cannot be used with Waypoint. In the place of IPSEC, Waypoint 147 defines its own secure transport functionality as a replacement service. 148 Again, it is important that Waypoint preserve the existing IP 149 functionality for the protocols which will be layered above Waypoint. 151 4. Protocol Packet Definition 153 The Waypoint protocol header appears immediately following the IP 154 protocol header. The IP protocol number for Waypoint is ??. The header 155 contains source and destination ports, a checksum field, and the length 156 of the Waypoint header. The header length field delineates additional 157 Waypoint header options for the payload. Waypoint header object are 158 framed as type, length, value (TLV) objects. The only currently defined 159 option is for security. 161 +-------------+-------------+-------------+-------------+ 162 | Checksum | Header Length | 163 +-------------+-------------+-------------+-------------+ 164 | Source Port | Destination Port | 165 +-------------+-------------+-------------+-------------+ 166 | Flags | Time to Delivery (TTD) | 167 +-------------+-------------+-------------+-------------+ 168 | | 169 / Waypoint options (e.g. Integrity) / 170 | | 171 +-------------+-------------+-------------+-------------+ 172 | | 173 / / 174 / / 175 / Payload / 176 / / 177 / / 178 | | 179 +-------------+-------------+-------------+-------------+ 181 5. Protocol Processing Rules 183 Waypoint packets are forwarded along the end to end path towards the IP 184 destination address for both unicast and multicast addresses. Unlike 185 the typical IP data packet, it is likely that a Waypoint packet will be 186 processed by an intermediate router that is part of the end to end 187 forwarding path, but is not the destination address of the packet. How 188 is this interception accomplished? 190 There are two primary solutions that have been implemented in the 191 context of the RSVP protocol. One solution was to define a unique 192 protocol number that is recognized by the router. Packets with this 193 protocol number are not forwarded, but instead delivered to the RSVP 194 protcol processing engine on the router. An alternative approach has 195 been defined using IP options. A router alert IP option, when present 196 in a packet, flags the packet for local delivery within the routers 197 protocol processing engine. 199 In Waypoint, we define a more general concept for packet interception 200 markings. Rather than a simple flag, Waypoint adopts the notion of a 201 "time to delivery" (TTD) field. At each forwarding router, the TTD 202 field is decremented, similar to the IP TTL field. When the TTD field 203 is zero, the packet is intercepted by the router. It will be quite 204 common to use a TTD field of 1 for many signaling protocols, but the 205 ability to skip over a fixed number of intermediate routers provides the 206 capability to "tunnel through" a sequence of routers when necessary. 208 One will notice that the TTD field is decremented in an identical 209 fashion to the IP TTL field. Waypoint defines a flag that allows the 210 TTL field to used as the TTD field. This seems like a useful option on 211 many routers. IP routers are already programmed to decrement the IP TTL 212 in the fast forwarding path and to send zero TTL packets to the slow 213 path for an ICMP response to the sender. If the TTL is zero and the IP 214 protocol number is Waypoint, this will cause a local delivery of the 215 packet instead of an ICMP response. Alternatively, a router can use the 216 TTD field in Waypoint, decrement the field (and update the checksum) 217 during forwarding, and deliver packets with a zero TTD to the local 218 protocol processing engine. 220 The destination port number of the Waypoint packet identifies the 221 particular signaling service that will process a given packet. If there 222 is no service associated with destination port number of a received 223 packet, an ICMP response should be generated. 225 5.1. Security Options Processing 227 If a security option is present in the packet, it is processed before 228 the packet is delivered to the signaling service. Currently, Waypoint 229 defines a hop by hop packet integrity option that provides functionality 230 similar to the IPSEC AH header. Because packets are processed at 231 intermediate routers, the key exchange and sharing rules of IPSEC, which 232 are end to end, cannot be applied to Waypoint. We instead adopt the hop 233 by hop integrity solution developed for the RSVP protocol. 235 Waypoint, unlike RSVP, needs to address confidentiality, as well as 236 authentication. The RSVP integrity solution will be enhanced to include 237 confidentiality for the Waypoint design. 239 6. Simple Waypoint Examples 241 The simplest control plane, path oriented, services are measurement 242 rather than signaling operations. This is expected since signaling 243 protocols generally have additional complexity to handle all of the 244 special cases due to errors or faults. Also, signaling protocols 245 usually maintain state and the state maintenance can add complexity. 246 The services mentioned in this section are all stateless. 248 There is a large class of measurement services, all basically similar, 249 that trace out an end to end path using an expanding ring search with 250 ICMP. Examples include traceroute, pathchar, and mercator[2]. All of 251 these tools attempt to provide as much information that can be gleaned 252 with ICMP responses; IP addresses, operating systems types, and link 253 round trip times. 255 It is also well known that measurements based on ICMP responses are 256 flawed. Many router implementations assign a low priority to the task 257 of ICMP responses. Measured round trip times can have excessive delay 258 and high variability. 260 A traceroute service, available on a well known Waypoint port of every 261 router would be an extremely useful service for the Internet. It could 262 provide a more robust service: a complete list of all IP addresses along 263 a path and accurate round trip delays. Removing the limitation of ICMP 264 functionality would allow a Waypoint based implementation to timestamp 265 the response and reply to accurately determine delay. 267 A pathchar implementation, based on Waypoint, would include link 268 capacity information rather than relying on the tedious task of 269 attempting to determine the capacity based on very noisy measurement 270 data. 272 7. Complex Signaling Protocols 274 There are a number of reasonably complex signaling protocols that are in 275 use or being proposed for use in the Internet. RSVP signals for end to 276 end QoS needs along a path. RSVP-TE is used for the set up of traffic 277 engineered tunnels. Another modifications of RSVP is being proposed for 278 optical switch path configuration. 280 At the heart of all of these protocols, there is a need to deliver 281 control packets at every, or nearly every router along the path. 282 Current mechanisms, such as router alert, provide no ability to separate 283 out signaling packets for different services. As an example, both RSVP 284 and RSVP-TE use IP protocol 46. A router which support both RSVP and 285 RSVP-TE concurrently would have to analyze the packet contents to 286 separate out which packets are being used for which protocol. In this 287 context, Waypoint, with a defined port space, provides a cleaner 288 alternative to the router alert option. 290 Waypoint does not address all of the common functionality between 291 various signaling protocols. This may include soft state managment, 292 interfaces to routing, and message reliability mechanisms. It is 293 believed that this common functionality, at the transport layer, may 294 lend itself to organization into a set of reusable building blocks. 295 Waypoint only strives to provide common functionality at the 296 intermediate layer between network and transport. 298 8. Conclusion 300 Waypoint provides an elementary deliver mechanism for both simple and 301 complex path oriented control, measurement, and signaling protocols. It 302 differs from current mechanisms, such as router alert, in a number of 303 important areas. First, it does not require the use of IP options, 304 which may add additional processing expense on some routers. It 305 provides hop by hop security, enabling signaling packets to have similar 306 security features to IP data packets which can use IPSEC. Unlike the 307 family of RSVP protocols, it provides a distinct port addresses for each 308 new protocol. The time to deliver (TTD) field provides increased 309 delivery control enabling protocols to "tunnel through" a series of 310 routers along a path. 312 It is believed that the implementation of Waypoint would be 313 straightforward and of low overhead for most router implementations. 314 The ability to use the TTL field as the TTD field should make Waypoint 315 more compatible with existing IP forwarding implementations and only 316 require simple modifications to the ICMP message generation path. 318 9. References 320 [1] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 321 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 322 Specification". RFC 2205, September 1997. 324 [2] Govindan R., Tangmunarunkit H., "Heuristics for Internet Map 325 Discovery", Proc IEEE Infocom 2000, Tel Aviv, Israel 327 [3] Atkinson, R., and S. Kent, "Security Architecture for the Internet 328 Protocol", RFC 2401, November 1998. 330 [4] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet 331 Security Association and Key Management Protocol (ISAKMP)", RFC 332 2408, November 1998. 334 [5] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, 335 November 1998. 337 [6] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload 338 (ESP)", RFC 2406, November 1998. 340 10. Security Considerations 342 To be completed. 344 11. Authors' Addresses 346 Bob Lindell 347 USC Information Sciences Institute 348 4676 Admiralty Way 349 Marina del Rey, CA 90292 350 Phone: (310) 448-8727 351 Email: lindell@ISI.EDU 353 Bob Braden 354 USC Information Sciences Institute 355 4676 Admiralty Way 356 Marina del Rey, CA 90292 357 Phone: (310) 448-9173 358 Email: braden@ISI.EDU