idnits 2.17.1 draft-martinsen-tram-stuntrace-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (June 1, 2015) is 3251 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) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Downref: Normative reference to an Experimental RFC: RFC 5780 -- Obsolete informational reference (is this intentional?): RFC 1393 (Obsoleted by RFC 6814) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM P. Martinsen 3 Internet-Draft D. Wing 4 Intended status: Standards Track Cisco 5 Expires: December 3, 2015 June 1, 2015 7 STUN Traceroute 8 draft-martinsen-tram-stuntrace-01 10 Abstract 12 After a UDP protocol such as RTP determines a network path is 13 experiencing problems, a traceroute is often useful to determine 14 which router or which link is contributing to the problem. However, 15 operating system traceroute commands follow a different path than the 16 actual UDP flow which complicates troubleshooting. A superior method 17 is shown which is absolutely path-congruent with the UDP protocol 18 itself, works on IPv4 and IPv6, and does not require administrative 19 privileges on most operating systems. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 3, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 57 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 58 4. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. PATH-NODE-PROBE . . . . . . . . . . . . . . . . . . . . . 5 60 5. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 5 61 5.1. Forming STUN Packet Probes . . . . . . . . . . . . . . . 5 62 5.2. Receiving a STUN Packet Probe . . . . . . . . . . . . . . 6 63 5.3. Receiving ICMP Messages . . . . . . . . . . . . . . . . . 6 64 6. IPv4 and IPv6 Differences . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 10.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Appendix A. Platform Implementation Details . . . . . . . . . . 9 72 A.1. Setting TTL or HOP_LIMIT on Probes . . . . . . . . . . . 9 73 A.2. Receiving ICMP Messages . . . . . . . . . . . . . . . . . 9 74 A.2.1. OS-X and iOS . . . . . . . . . . . . . . . . . . . . 9 75 A.2.2. Linux and Android . . . . . . . . . . . . . . . . . . 10 76 A.2.3. Windows . . . . . . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 Traceroute [RFC1393] is a simple tool available on most operating 82 systems and is popular to debug the network by simply getting round- 83 trip time along each hop to a remote IP address. More advanced 84 tools, such as MTR, provide more metrics such as packet loss and 85 round trip time to each hop over several seconds or minutes. 87 To simplify network debugging when dealing with bi-directional real 88 time media it is often useful to get as much information as possible 89 regarding the network path. In this specification probe packets are 90 sent using the same 5-tuple where (S)RTP media is flowing. This will 91 provide the most accurate results, as probe packets sent on a 92 different 5-tuple may take another path due to Equal-Cost Multipath 93 (ECMP, [RFC2992]), policy-based routing, and similar techniques. 95 To avoid those problems, the probe packets need to be sent from the 96 same socket and with the same DiffServ code point the normal (S)RTP 97 media packets. As shown in Appendix A, most operating systems can 98 pass the ICMP "Time to Live Exceeded" error to the application, so 99 the application can perform the diagnostics over that network path. 101 This specifications uses STUN [RFC5389] packets as probes. STUN 102 packets are designed to be multiplexed together with RTP [RFC3550] 103 (and SRTP [RFC3711]) and are unlikely to cause any "problems" for the 104 (S)RTP receiver. To differentiate each hop count, classic traceroute 105 uses different UDP port numbers (e.g., TTL=1 uses UDP port 55001, 106 TTL=2 uses UDP port 55002, etc.). The mechanism described here uses 107 the same UDP port number (so that the trace is path-congruent with 108 the (S)RTP packets), and uses different length UDP packets to 109 differentiate each hop count (e.g., TTL=1 uses length 501, TTL=2 uses 110 length 502, etc.). 112 Using a technique based on ICMP replies avoids a forklift upgrade of 113 the network to provide host applications with useful information. 114 ICMP is already supported in most network and application stacks. 116 Additional network characteristics like MTU and bandwidth 117 availability can be discovered by using 118 [I-D.petithuguenin-behave-stun-pmtud] and 119 [I-D.martinsen-tram-turnbandwidthprobe]. 121 2. Notational Conventions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 3. Overview of Operation 129 An application using (S)RTP to send and receive media like audio and 130 video following the guidelines in [RFC4961] uses symmetric send and 131 receive ports. The application opens one socket that it uses to both 132 send and receive media on. 134 It is important to note that the functionality described here can be 135 done on most OSes without any administrative privileges. 137 Figure 1 depicts the various components needed for this to work. The 138 application opens up its media socket as it would in normal cases 139 where media is to be sent and received. It also opens up a ICMP 140 socket or installs an error listener on the media socket. 142 POLL/ Network Node Network Node 143 SELECT 144 +-----+ | | | 145 | A |* ICMP +++ /+\++++++++++++|++++ | 146 | L | SOCKET | | | ++++++++++++ | 147 | I | | | | + | 148 | C |* MEDIA ==|===|===========|=================+|====<(S)RTP> 149 | E | SOCKET --\-/------------|------------------X 150 +-----+ | | |(TTL expired) 152 ====== Media Path 153 ------ STUN Probes (on same 5 tuple as Media) 154 ++++++ ICMP reply 156 Figure 1 158 The application also need to listen on the sockets for any incoming 159 ICMP packets or socket error messages. This is usually done with the 160 socket calls select() or poll(). How to actually receive the ICMP 161 messages will vary from OS to OS. See Appendix A for implementation 162 details on various OSes. 164 Once the application have media running and is listening for ICMP 165 replies it can start sending probes to detect networks nodes in the 166 media path. This is done by sending STUN messages and setting the 167 TTL/MAX_HOP limit in the IPv4/IPv6 header. Appendix A.1 explains how 168 to set this on various platforms. 170 The STUN packet is sent on the same socket as the media packet are 171 sent and received on. Mixing (S)RTP and STUN is well known behavior 172 and should not cause any problems. 174 Along the path, every layer 3 network node (a.k.a. router) decreases 175 the IPv4 TTL or IPv6 HOP_LIMIT field. If the field becomes 0 the 176 network node responds with a ICMP error "Time to Live Exceeded" (TTL 177 Exceeded) or "Hop Limit Exceeded in Transit" (Time Exceeded Message). 179 The application will receive a ICMP error in response to the 180 offending probe packet. The source IP address of the ICMP packet 181 will be the sending network node. This enables the application to 182 trace the path towards the destination. The ICMP reply contains at 183 least 8 bytes of the offending packet. The IP fragment of the 184 offending packet in the ICMP reply can be used to determining if this 185 ICMP reply actually was a reply to an offending packet the 186 application did send out. 188 4. New STUN Attributes 190 This STUN extension defines the following new attribute: 192 0xXXX0: PATH-NODE-PROBE 194 4.1. PATH-NODE-PROBE 196 This attribute have a length of 8. Padding is needed to hit the 197 required STUN 32 bit STUN attribute boundary. 199 0 200 0 1 2 3 4 5 6 7 201 +-+-+-+-+-+-+-+-+ 202 | HOP | 203 +-+-+-+-+-+-+-+-+ 205 Figure 2: PATH-NODE-PROBE Attribute 207 The HOP field indicates what hop in the network path (relative to the 208 application) the application is trying to learn the IP address of. 209 This field should be set to the same value as the TTL/HOP_LIMIT field 210 in the IPv4/IPv6 header of the probe packet leaving the application. 211 Note that the TTL/HOP_LIMIT field in the IPv4/IPv6 header will 212 decrease as the packet traverses the path. The HOP field in the 213 attribute will remain unchanged. 215 This attribute is useful for clients when receiving the whole 216 offending IP packet in the ICMP reply. The attribute will be 217 reflected back in a STUN response if the remote application supports 218 is. This makes it easier to correlate sent probe packets and ICMP 219 responses. 221 5. Base Protocol Procedures 223 The procedures are simple; send a probe packet that may or may not 224 trigger a reply from one of the nodes in the network path and then 225 listen and parse any incoming replies. The reply might be an ICMP 226 Time To Live Exceeded (from an intermediate hop), a STUN response 227 (from the (S)RTP peer), or any other ICMP error message. 229 5.1. Forming STUN Packet Probes 231 To reduce chances of a STUN traceroute probe being stopped by various 232 middle-boxes it is RECOMMENDED to use a STUN binding request as 233 described in ICE [RFC5245]. 235 Since the STUN packet can traverse the whole media-path and reach the 236 remote peer it is RECOMMENDED the agent follows the guidelines for 237 sending connectivity checks defined in ICE [RFC5245]. Adding a 238 USERNAME attribute and integrity protecting the STUN message enables 239 the remote peer to authenticate the STUN message and create an 240 appropriate response. If the remote peer is unable to authenticate 241 the STUN request it will not send any response. Getting a response 242 from the remote peer is useful as it is an indication the probe have 243 traveled the whole network path. 245 When forming the STUN packet probe the agent SHOULD add the PATH- 246 NODE-PROBE attribute and MAY add a PADDING attribute as described in 247 [RFC5780] Section 7.6. The PATH-NODE-PROBE attribute is useful for 248 STUN servers receiving the STUN probe and it can be used to correlate 249 any ICMP replies if the reply contains the complete offending packet. 250 Adding the PADDING attribute is useful for clients that needs to have 251 several outstanding probe packets on the same 5-tuple. The length of 252 the offending packet reported back in any ICMP reply will make it 253 possible to correlate this to the correct probe. 255 The agent sending the STUN packet probe MUST store the length of the 256 UDP packet (as reported in the IP header) containing the STUN probe. 258 Before sending the probe on the wire it is important to set the 259 appropriate TTL or HOP_LIMIT field in the IPv4 or IPv6 header before 260 the packet is sent. How to do this on various OSes are described in 261 Appendix A.1. 263 The probe MUST also be sent with the same DSCP value as the (S)RTP 264 packets. This is normally not a problem as the STUN probes and 265 (S)RTP packets are sent on the same socket. 267 5.2. Receiving a STUN Packet Probe 269 An agent that listens for STUN requests (a.k.a STUN server) that 270 receives a STUN request with a PATH-NODE-PROBE attribute, MUST 271 include a PATH-NODE-PROBE attribute with the same value in the 272 generated response. 274 Any PADDING attributes as defined in [RFC5780] SHOULD be ignored by 275 the STUN server. 277 5.3. Receiving ICMP Messages 279 After an agent sends a STUN probe it must be ready to receive a ICMP 280 reply or a STUN reply. Details on how to do this on various OSes are 281 described in Appendix A.2. 283 To prevent ICMP spoofing attacks [RFC5927] , the received ICMP packet 284 MUST be validated by port number and length in the IP fragment of the 285 offending packet contained in the ICMP payload. Port number 286 validation checks that the port number in the offending IP fragment 287 of the probe packet contained in the ICMP payload corresponds to the 288 (S)RTP media (and STUN probe) 5-tuple. The length validation checks 289 IP packet length field in the IP fragment of the offending packet 290 received in the ICMP reply. This value MUST correspond to any length 291 stored when the agent sent the STUN probe. If the agent uses the 292 PADDING (Defined in [RFC5780]) attribute to generate different length 293 on the STUN probes it is possible to have several outstanding probes, 294 thus speeding up the trace. 296 6. IPv4 and IPv6 Differences 298 Core functionality is the same. In IPv6 the IPv4 TTL field is 299 renamed to HOP_LIMIT to better reflect what it actually represent. 301 7. IANA Considerations 303 The code-point for the new STUN attribute defined in this 304 specification is described in Section 4. 306 8. Security Considerations 308 ICMP messages does leak network topology, which is a well-known 309 threat to networks and mitigations have long existed in routers and 310 firewalls so that networks can be configured to not leak this 311 topology information beyond their borders. 313 ICMP spoofing and DOS attack prevention exist in routers deployed on 314 the Internet today. 316 No new threats have been added in this specification. 318 9. Acknowledgements 320 Trond Andersen for actually implementing this and Wilson Chen for 321 helping out with different OS behavior testing. 323 10. References 325 10.1. Normative References 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 331 Jacobson, "RTP: A Transport Protocol for Real-Time 332 Applications", STD 64, RFC 3550, July 2003. 334 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 335 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 336 RFC 3711, March 2004. 338 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 339 BCP 131, RFC 4961, July 2007. 341 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 342 (ICE): A Protocol for Network Address Translator (NAT) 343 Traversal for Offer/Answer Protocols", RFC 5245, April 344 2010. 346 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 347 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 348 October 2008. 350 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 351 Using Session Traversal Utilities for NAT (STUN)", RFC 352 5780, May 2010. 354 10.2. Informative References 356 [I-D.martinsen-tram-turnbandwidthprobe] 357 Martinsen, P., Andersen, T., Salgueiro, G., and M. Petit- 358 Huguenin, "Traversal Using Relays around NAT (TURN) 359 Bandwidth Probe", draft-martinsen-tram- 360 turnbandwidthprobe-00 (work in progress), May 2015. 362 [I-D.petithuguenin-behave-stun-pmtud] 363 Petit-Huguenin, M., "Path MTU Discovery Using Session 364 Traversal Utilities for NAT (STUN)", draft-petithuguenin- 365 behave-stun-pmtud-03 (work in progress), March 2009. 367 [ICMPTest] 368 "ICMP test github repo", . 371 [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 372 January 1993. 374 [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path 375 Algorithm", RFC 2992, November 2000. 377 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 379 Appendix A. Platform Implementation Details 381 This section provides examples and hint on how probe packets can be 382 sent and ICMP messages received on various OSes. For a complete 383 example please refer to [ICMPTest]. 385 A.1. Setting TTL or HOP_LIMIT on Probes 387 Setting the appropriate value in the IPv4 or IPv6 header is the same 388 for most platforms. Use 390 setsockopt(sockHandle, IPPROTO_IP, IP_TTL, &sock_ttl, 391 sizeof(sock_ttl)); 393 for IPv4 or 395 setsockopt(sockHandle, 396 IPPROTO_IPV6, IPV6_UNICAST_HOPS, &sock_ttl, 397 sizeof(sock_ttl)); 399 for IPv6. 401 Sending the probes on the same socket as media is flowing requires 402 the implementations to only set this when sending the probe packet. 403 Remember to set it back to initial value when sending media. Most 404 OSes seems to handle the setsockopt call correctly and not set the 405 value in the IP header of any buffered packets. 407 A.2. Receiving ICMP Messages 409 A.2.1. OS-X and iOS 411 Creating a socket to listen for incoming ICMP messages can be done 412 as: 414 icmpSocket=socket(config.remoteAddr.ss_family, SOCK_DGRAM, 415 IPPROTO_ICMP); <<< 417 This is done in addition to the normal socket used to send media on 418 (RTP) and probes. (Yes, even if the probe are sent on the media 419 socket the ICMP reply will be on the ICMP sockets..) 421 Code in the while(1) loop of poll would look something like: 423 for(i=0;i