idnits 2.17.1 draft-fu-ccamp-traceroute-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages 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.) ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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.) -- The document date (23 June 2003) is 7613 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 488 looks like a reference -- Missing reference section? '2' on line 492 looks like a reference -- Missing reference section? '3' on line 495 looks like a reference -- Missing reference section? '4' on line 499 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Xiaoming Fu 3 Internet Draft Rene Soltwisch 4 University of Goettingen 5 draft-fu-ccamp-traceroute-00.txt 6 23 June 2003 7 Expires: Dec 2003 9 A Proposal for Generic Traceroute Over Tunnels 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-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 material 23 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 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Abstract 33 We identify some issues for generic traceroute for tunnels (tunnel- 34 trace): (1) it is possible that some IP hops do not support tunneltrace, 35 (2) for each tunnel wishing to be traced, at least the two end points 36 should support the tunneltrace, (3) tracing message should be able to by- 37 pass firewalls and NATs. One possible solution, based on the CASP 38 signaling protocol (stateless mode), is proposed to support generic 39 routetracing over tunnels. 41 1 Introduction 43 UDP is the transport mechanism recommended as the basis for the IETF 44 CCAMP WG towards a generic traceroute tool that can also verify tunnel 45 paths and diagnose tunnel failures. Some protocols, e.g., GTTP [1], are 46 being developed based on UDP. 48 This draft identifies some issues concerning generic route tracing over 49 tunnels and proposes a solution based on a generic signaling protocol. 51 2 Some Issues with Transport Support for Generic Traceroute 53 In addition to the requirements for traceroute over generic tunnels pro- 54 posed in [2], we find there are some other issues for a generic tracer- 55 oute tool should consider: 57 Transition requirements: it would be difficult to have all IP 58 routers support the generic traceroute tool at the same time, 59 thus it can be quite possible some of IP hops do not support 60 the generic traceroute tool. Nevertheless, to enable tunnel 61 tracing, at least tunnel entry and exit points should support 62 the traceroute functionality. 64 Firewall traversal: some network administrators deploy packet fil- 65 ters which discard UDP or ICMP packets or packets with IP 66 options. The decision for dropping packets these packets might 67 be based on past security incidents. Thus, traceroute based on 68 UDP, ICMP or UDP/raw IP with router alert option may fail. 70 Transport of generic traceroute messages: it is possible (and 71 adopted by most of existing proposals) to use UDP end-to-end 72 addressing for the traceroute messages. However there are some 73 potential problems, for instance: 75 1) collecting information about tunnels and nodes along the 76 path might exceed the path MTU size. This might cause fragmen- 77 tation and reassemply. 79 2) Routing assymmetry requires that tunnnel tracing to be ini- 80 tiated by both end points to have information about the path 81 in both directions. 83 3 Traceroute based on CASP (CASP-T) 85 3.1 CASP Introduction 87 The Cross-Application Signaling Protocol (CASP) [3] is a generic signal- 88 ing protocol for path-coupled (and path-decoupled signaling) between two 89 nodes. Particular path-coupled signaling is attractive for this applica- 90 tion. 92 CASP splits signaling message transport and application specific infor- 93 mation. This allows to support different signaling applications 95 to reuse the same underlying transport mechanism. Furthermore it allows 96 to next-hop discovery from signaling message delivery, as shown in Fig- 97 ure 1. The messaging layer is responsible for delivering signaling mes- 98 sages from the initiator to the responder, typically the data source and 99 the data sink, respectively, or the reverse way. The CASP messaging 100 layer is built on existing reliable or unreliable transport protocols, 101 such as TCP, SCTP or UDP, depending on the needs of the application. 103 The client layer consists of a specialized client, namely next-peer dis- 104 covery, and any number of specific signaling client protocols, which 105 perform the actual signaling functions, e.g., QoS resource reservation, 106 firewall and configuration, code distribution for active networks, and 107 network diagnostics. Each node can choose its own next-hop discovery 108 mechanism, relying on manual configuration, router advertisements, link 109 state routing protocols, scout protocol [3], or server discovery solu- 110 tions such as DNS or SLP. A CASP message is simply forwarded to next 111 CASP hop if a CASP node doesn't support the requested client type. 113 The stateful mode of CASP relies on the soft-state maintained for sig- 114 naling clients and messaging layer. The stateless mode of CASP, however, 115 does not establish state in IP devices by using record-route objects 116 that enable to traverse the response message to follow the same path in 117 the reverse direction. 119 Traceroute based on CASP (CASP-T) works as a signaling client layer pro- 120 tocol upon the stateless mode operation of CASP. Depending on the need 121 of transport support, TCP or SCTP is recommended in CASP-T, but a CASP 122 node can decide individually to use UDP if it knows there is no UDP 123 firewall problem and the message size is not larger than MTU to next 124 CASP node. 126 3.2 CASP-T Overview 128 In this section, first we describe how the traceroute client for CASP 129 (CASP-T) works, then present its general working environment. 131 A CASP-T message traverses and records information in all intermediate 132 nodes between a source (initiator) and a destination node in a hop-by- 133 hop way. CASP-T returns information about the entire path with a single 134 roundtrip instead of iteratively requesting more and more information. 135 With regard to tunnels CASP-T works incrementally, which means, an 136 +- - - - - - - - - - - - - - - + - - - - - - - - - - - - - - + 137 | +--------------+ | | 138 Application+--------------+| 139 |Signaling+--------------+|| | +------------------------+ | 140 Protocols| CASP Clients ||+ |CASP Next-hop Discovery | 141 | |eg.,CASP-T,QoS|+ | | Clients (e.g. Scout) | | CASP 142 +--------------+ +------------------------+ Client 143 | ^ | ^ ^ ^ | Layer 144 +- - - - - - - - -| - - - - - -+ | | | 145 =|=================|=========================|========|===|===|========= 146 v v | | 147 | +------------------------------------+ | | | CASP 148 | CASP Messaging Layer | | | Messaging 149 | +------------------------------------+ | | | Layer 150 ^ ^ | | 151 +- - - - - - - - - - - - - - - |- - - - - - - - |- - |- -| - + 152 v v v | 153 +-------------------------------+ +-------+ | 154 |Reliable Transport(TCP,SCTP...)| | UDP | | 155 +-------------------------------+ +-------+ | 156 | | v 157 +---------------------------------------------+ 158 | IP | 159 +---------------------------------------------+ 161 Figure 1: Cross-Application Signaling Protocol 163 intermediate tunnel immediately. First the signaling message discovers 164 the end points of the tunnel, which then serves as a new source and des- 165 tination for a subsequent CASP-T session. Once the response message is 166 built the tunnel information is added. Essentially, CASP-T can be used 167 to identify the top-level hops (without looking into tunnels or clouds 168 do not support CASP-T), or all IP hops (including those within tunnels 169 and non-CASP-T clouds) in between the initiator and the destination. 170 Once the destination has been reached the results are sent back to its 171 initiator. When an examination into a tunnel is performed, the results 172 are not directly sent back to the tunnel entrance but forwarded from the 173 tunnel end to the tier-1 next CASP hop for examination. When an error 174 occurs, a CASP_TraceResponse message set with corresponding error code 175 is sent back (in a hop-by-hop fashion) to the initiator on the same 176 level, which is the CASP-T initiator or tunnel entrance in case of tun- 177 nel examination. 179 When the destination on top level is reached a response message is sent 180 back to the top level initiator. This message includes all captured 181 information and provides the entire route information. Classical trace- 182 route [4] can be incorporated within CASP-T to look into each IP hop 183 between two CASP nodes, as described in Section 3.3. This allows CASP-T 184 (and CASP) to be deployed incrementally. 186 Figure 2 shows an example to illustrate how CASP-T can trace IP hops 187 information inside a tunnel. At node B, CASP uses node D as destination 188 of the next-hop discovery to learn the next CASP hop supporting CASP-T. 189 Then it adds its local information into the traceroute payload of the 190 CASP message, and forwards the message to the next hop. The tunnel exit 191 point, node B, determines that it is not the final destination of the 192 signaling message, and repeats the discovery process (if the next hop is 193 not already known. 195 end-to-end addressed signaling message 196 +---------------------------------------------------------+ 197 | (a tunnel: B-->D) | 198 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% | 199 A V B % C D % E| 200 +----------+ +-----%----+ +----------+ +-----%----+ +---------+ 201 | CASP-T | | CASP-T | | CASP-T | | CASP-T | | CASP-T | 202 +----------+ +----------+ +----------+ +----------+ +---------+ 203 | CASP-M |-->| CASP-M |-->| CASP-M |-->| CASP-M |-->| CASP-M | 204 +----------+ +----------+ +----------+ +----------+ +---------+ 205 | ^ | ^ | ^ | ^ 206 | | | | | | | | 207 +------------+ +--------+ +-----------+ +-----------+ 208 hop-by-hop addressing and signaling message delivery 210 Figure 2: Tunnel routetracing using CASP-T 212 CASP-T is not necessary to be supported in all IP nodes; rather, it can 213 be configured in a more flexible way. Figure 3 shows an example where 214 protocol stacks regarding CASP are configured differently (next-hop dis- 215 covery is necessary for all CASP nodes; here we omit it in the figure). 216 CASP-T works on the Client Layer of the two-layer CASP architecture. It 217 is based on the functionalities provided by the messaging layer of CASP, 218 which supports secure, congestion-controlled delivery of signaling mes- 219 sages (of any size and for any purpose) between each two CASP aware 220 nodes, while the next CASP node can be discovered by a special discovery 221 client. Figure 3 illustrates a path from node A to B where node A, C and 222 E support CASP-T but node B does not. Some nodes, for instance node D in 223 our example, do not support CASP at all. Here, various nodes reuse the 224 same CASP messaging layer (CASP-M) and different client layers (e.g. 225 CASP-QoS and CASP-T). Interworking with CASP-QoS (e.g. Query message) 226 is possible. 228 end-to-end addressed signaling message 229 +-------------------------------------------------------+ 230 A V B C D E | 231 +------+--------+ +--------+ +------+ +---------+ +------+--------+ 232 |CASP-T|CASP-QoS| |CASP-QoS| |CASP-T| | IP hop, | |CASP-T|CASP-QoS| 233 +------+--------+ +--------+ +------+ | no CASP | +------+--------+ 234 | CASP-M |-->| CASP-M |-->|CASP-M|-------------->| CASP-M | 235 +---------------+ +--------+ +------+ +---------+ +---------------+ 236 | ^ | ^ | ^ 237 +---------------+ +--------+ +----------------------+ 238 hop-by-hop addressing and signaling message delivery 240 Figure 3: A Possible Configuration 242 3.3 Incorporating with classical traceroute 244 It is quite possible not all nodes along the path are CASP aware, there- 245 fore, a classical traceroute based on ICMP responses (classical way of 246 traceroute) is incorpated in CASP-T, to trace into such non-CASP-aware 247 clouds along the path. Figure 4 illustrates an example where node A and 248 D speak CASP but node B and C do not. When node A is reached, (classi- 249 cal) traceroute is performed to discover IP addresses and delays for 250 intermediate IP hops between A and D. These results, in addition to 251 information like path MTU and RTT between A and D measured by CASP-T, 252 are added as new trace objects to the CASP-Trace message in node A. This 253 CASP-Trace message in A will be forwarded to node D by CASP-T, and node 254 D will perform a similar operation as node A, until the destination is 255 reached. 257 3.4 Error Handling 258 A B C D 259 +-------+ +--------------+ +------+ +------+ 260 |CASP-T | |normal IP node| | IP | |CASP-T| 261 +-------+ +--------------+ +------+ +------+ 262 | ^ ^ ^ ^ ^ 263 | +--------------+ | | | 264 | +----------------------------------+ | | 265 | +--------------------------------------------------+ | 266 | classical traceroute | 267 +----------------------------------------------------------+ 268 CASP_Trace 270 Figure 4: CASP-T: Using Classical Traceroute 272 Errors might be caused due to various reasons. One error reason might be 273 a broken tunnel along the path and another reason might be caused by a 274 lost ICMP packet or a firewall dropping packets. 276 In such cases, an error has to be reported back to the initiator by a 277 CASP-T node along the path discovering the error situation. 279 3.5 CASP-T Messages 281 Currently, two types of CASP-T messages are defined: CASP_Trace and 282 CASP_TraceResponse messages. 284 As shown in Figure 5, a CASP_Trace message consists of one Initiator 285 object and several Trace objects collected along the path. 287 Figure 6 shows the CASP_TraceResponse message format. Trace objects 288 collected along the path are encapsulated as the CASP_TraceResponse pay- 289 load. 291 Type: Identify the type of the message. Here, 2 for CASP_TraceRe- 292 sponse. (Later version might include a reverse trace message.) 294 Version: 4 bit 295 Identifies the Version of the Protocol. Currently Version = 1. 297 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 298 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 299 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 300 | Type |Version| Error Code | Length | 301 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 302 | Tunnel depth |C | Reserved | 303 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 304 | Session ID | 305 | // | 306 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 307 | Source ID | 308 | // | 309 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 310 | Destination ID | 311 | // | 312 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 313 | Timestamp (date, seconds) | 314 | (milliseconds) | 315 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 316 | Initiator Object | 317 | // | 318 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 319 | Authorization Token | 320 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 321 |nextObj + Object 1 | 322 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 323 |nextObj + Object 2 | 324 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 325 |nextObj + Object 3 | 326 | // | 328 Type: The message type (here, 1 for CASP_Trace) 329 C=Classical traceroute flag 331 Figure 5: CASP_Trace message format 333 Error Code: 8 bit to identify protocol errors. 334 0 - no error 335 1 - access denied 336 2 - broken tunnel 337 3 - destination unreachable 339 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 340 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 341 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 342 | Type |Version| Error Code | Length | 343 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 344 | Session ID | 345 | // | 346 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 347 | Source ID | 348 | // | 349 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 350 | Destination ID | 351 | // | 352 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 353 | Trace objects as payload | 354 | // | 356 Type: The message type (here, 2 for CASP_TraceResponse) 358 Figure 6: CASP_TraceResponse message format 360 Length: 16 bit 361 The total length of the message 363 Tunnel depth: 8 bit 364 The maximum tunnel depth for the analyses. 365 0 - top level analysis only. 366 1 - 255 for the tunnel depth 368 Classical traceroute flag: 1 bit 369 0 - CASP node examination only 370 1 - Classical traceroute enabled 372 Session ID: 128bit 373 An identifier to identify the CASP_Trace message. It can be a 374 random number selected by the originator node. 376 Source and destination ID: 128bit 377 IPv4 address + identifier or IPv6 address 379 Timestamp: 64bit 380 32 bit for date in seconds since 01/01/1970 381 32 bit for milliseconds 383 3.6 CASP-T Objects 385 Trace Object := 387 := | | | | 388 | | | | 390 Depending on the ObjectType, ObjectValue can be one of the following: 392 IPVersion: can be either 4 or 6. 394 IPAddress: the node's IP address. 396 LocalHop: an increasing number and counts hops. 0 for the first hop 397 and all tunnel entrances 399 ErrorCode: indicates what kind of error occurs. 400 0 if there was no error. 401 1 for timeout, 402 2 for destination unreachable, 403 3 for connection interruption, 404 4 for explicit rejection of the measurement response, 405 5 authorization required, 406 6 access denied Other codes are reserved. 408 Delay: (in ms) shows the time to reach the node 410 MTU: is the Maximum Transportation Unit which indicates the payload 411 size of IP pages 413 Level: shows the depth of the tunnel 414 0 indicates top level 415 1 one level of tunnel 416 2+ several level of tunnel in tunnel. 418 Tunnel type: indicates what kind of tunnel the node belongs to. 419 (For example, IP-in-IP encapsulation, IPsec, GRE, MPLS, L2TP 420 or others) 422 Classical_Tracroute_Object: The correspondent ObjectValue can be 423 expressed as follows: 425 Value := 427 The Classical_Traceroute_Object is used for the case that no 428 CASP aware node are in between. In that case the classical 429 traceroute is used. IPAddress is the classical traceroute ini- 430 tiator. 432 Next CASP_hop is the destination hop is the number of hops the 433 reach the next CASP hop the result is the classical traceroute 434 result. 436 4 Security Considerations 438 CASP uses security mechanisms described in [3]. Generic traceroute over 439 tunnels introduces some security threats, such as source authentication, 440 trust relationships between neighboring nodes and between neighboring 441 network domains. 443 Authorization tokens are suggested in CASP-T to provide protection 444 against such threats. The details are to be investigated in a future 445 version of this document. 447 5 Open Issues and Discussions 449 Third-party Tracing: CASP-T can support third-party tracing, by 450 using the tracing source address different from the tracing 451 initiator (with certain changes in operations). 453 Overhead and Operational Time: Stateless mode of CASP does not 454 introduce significant overhead in the nodes it traverses. As 455 CASP is a generic protocol for various signaling purposes as 456 well, it is possible to reduce the overall overhead if other 457 signaling client protocols are supported. The way that results 458 are forwarded over reliable connections makes that approach 459 more robust against packet losses, and allows it to carry 460 larger size of messages. However, this has to tradeoff with 461 the possibly longer operational time because of the connection 462 establishment. Nevertheless, due to the possibility of reusing 463 existing TCP/SCTP connections (which can be used for both 464 CASP-T and other signaling clients) between CASP hops, the 465 average time for CASP-T can be, on average, low. 467 Extensibility: use of TCP or SCTP allows larger size of traceroute 468 message, avoiding fragmentation and defragmentation for deliv- 469 ery of the traced data. For example, CASP can be also used for 470 discovery of more information, such as flow-based measurement 471 information in IP nodes, if desired. 473 6 Acknowledgement 475 We would like to acknowledge Hannes Tschofenig for his useful comments 476 and discussions with Henning Schulzrinne. 478 7 Authors' Address 479 University of Goettingen 480 Institute for Informatics 481 Lotzestr. 16-18 482 37083 Goettingen 483 Germany 484 EMail: [fu,soltwisch]@cs.uni-goettingen.de 486 8 Bibliography 488 [1] R. Bonica et al., "Generic tunnel tracing protocol (GTTP) specifica- 489 tion," Internet Draft, Internet Engineering Task Force, July 2001. Work 490 in progress. 492 [2] R. Bonica, K. Kompella, and D. Meyer, "Tracing requirements for 493 generic tunnels," 2003. Work in progress. 495 [3] H. Schuzrinne, H. Tschofenig, X. Fu, J. Eisl, and R. Hancock, "Casp 496 -- cross-application signaling protocol." Internet draft, work in 497 progress, Sept. 2002. 499 [4] G. Kessler and S. Shepard, "A primer on internet and TCP/IP tools 500 and utilities," RFC FYI 30, 2151, Internet Engineering Task Force, June 501 1997. 503 Table of Contents 505 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2 506 2 Some Issues with Transport Support for Generic 507 Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 508 3 Traceroute based on CASP (CASP-T) . . . . . . . . . . . . 2 509 3.1 CASP Introduction . . . . . . . . . . . . . . . . . . . . 2 510 3.2 CASP-T Overview . . . . . . . . . . . . . . . . . . . . . 3 511 3.3 Incorporating with classical traceroute . . . . . . . . . 6 512 3.4 Error Handling . . . . . . . . . . . . . . . . . . . . . 6 513 3.5 CASP-T Messages . . . . . . . . . . . . . . . . . . . . . 7 514 3.6 CASP-T Objects . . . . . . . . . . . . . . . . . . . . . 10 515 4 Security Considerations . . . . . . . . . . . . . . . . . 11 516 5 Open Issues and Discussions . . . . . . . . . . . . . . . 11 517 6 Acknowledgement . . . . . . . . . . . . . . . . . . . . . 12 518 7 Authors' Address . . . . . . . . . . . . . . . . . . . . 12 519 8 Bibliography . . . . . . . . . . . . . . . . . . . . . . 12