idnits 2.17.1 draft-ietf-sip-hop-limit-diagnostics-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 423. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 Introduction section. -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- 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 (June 02, 2006) is 6531 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) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG S. Lawrence 3 Internet-Draft Pingtel Corp. 4 Updates: 3261 (if approved) A. Hawrylyshen 5 Expires: December 4, 2006 Ditech Networks Inc. 6 R. Sparks 7 Estacado Systems 8 June 02, 2006 10 Diagnostic Responses for SIP Hop Limit Errors 11 draft-ietf-sip-hop-limit-diagnostics-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 4, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 The SIP protocol imposes a limit on the number of hops a request may 45 make from a sender to the recipient. When this limit is reached, a 46 483 error response is returned. The present form of the 483 response 47 does not provide enough information for the sender or proxies on the 48 path to diagnose failures whose symptom is that the hop limit is 49 reached. This document proposes additional diagnostic information to 50 be returned in a 483 response. 52 Comments are solicited, and should be directed to the SIP working 53 group list at 'sip@ietf.org'. 55 Table of Contents 57 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 58 2. Diagnosing Hop Limit Exceeded Failures . . . . . . . . . . . . 3 59 2.1. Limitations of the 483 Error Response . . . . . . . . . . 3 60 2.2. Returning Useful Diagnostic Information in 483 61 Responses . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.4. Pruning Responses . . . . . . . . . . . . . . . . . . . . 8 64 3. Implementation Experience . . . . . . . . . . . . . . . . . . 9 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 71 Intellectual Property and Copyright Statements . . . . . . . . . . 12 73 1. Conventions and Definitions 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC-2119 [RFC2119]. 79 2. Diagnosing Hop Limit Exceeded Failures 81 The SIP protocol imposes a limit on the number of hops a request may 82 make from a sender to the recipient. The number of hops remaining 83 for the request is carried in the Max-Forwards header, and is 84 decremented each time the request is forwarded. When a SIP User 85 Agent receives a request whose Max-Forwards is zero, it returns a 483 86 error response to indicate that the limit was reached. 88 The 483 response alone does not provide enough information, for the 89 sender to determine where the problem lies. In the authors 90 experience, the problem is rarely that the target of the request was 91 actually further away than the Max-Forwards limit allowed. The 92 problem is usually incorrect routing; often a routing loop. 94 2.1. Limitations of the 483 Error Response 96 Section 20.22 of RFC 3261 [RFC3261] says: 97 The Max-Forwards header field must be used with any SIP method to 98 limit the number of proxies or gateways that can forward the 99 request to the next downstream server. This can also be useful 100 when the client is attempting to trace a request chain that 101 appears to be failing or looping in mid-chain. 103 In practice, there is too little information returned in a 483 104 response for it to be of much use as a diagnostic. When a request 105 has traversed a series of proxies, the response follows the Vias back 106 to the requester; in the case of a typical 483 response it can be 107 difficult to determine even what server the response came from. Even 108 when the rejecting server does identify itself, it can be difficult 109 to figure out why the request got there. 111 The following is an actual example request; the IP addresses and 112 domain names have been changed, but it is otherwise complete (it was 113 intentionally sent without SDP for brevity): 115 INVITE sip:9999@example.com SIP/2.0 116 Via: SIP/2.0/TCP 10.1.1.20:59449 117 ;branch=z9hG4bK-56ec69968c31f498c9a5573a00c8fc04 118 To: sip:9999@example.com 119 From: Sip Send ;tag=08e2f515 120 Call-ID: 159213b1aa5a67bc6eca6c4c2bad9f94@10.1.1.20 121 Cseq: 1 INVITE 122 Max-Forwards: 1 123 User-Agent: sipsend/0.02 124 Date: Wed, 12 Oct 2005 20:09:29 GMT 125 Content-Length: 0 127 This request was sent with the Max-Forwards value set to only 1 to 128 force the error response: it should traverse only the first outbound 129 proxy, and then be rejected by the next system that it encounters. 131 The response received in this case was: 133 SIP/2.0 483 Too Many Hops 134 Via: SIP/2.0/TCP 10.1.1.20:59449 135 ;branch=z9hG4bK-56ec69968c31f498c9a5573a00c8fc04 136 To: sip:9999@example.com;tag=-1574266585 137 From: Sip Send ;tag=08e2f515 138 Call-ID: 159213b1aa5a67bc6eca6c4c2bad9f94@10.1.1.20 139 Cseq: 1 INVITE 140 Content-Length: 0 142 There is no indication in the response of what server returned the 143 error. Even with the error only one hop beyond the first proxy, 144 there is no way to determine if that first proxy has routed the 145 request incorrectly. 147 2.2. Returning Useful Diagnostic Information in 483 Responses 149 In some ways, the Max-Forwards mechanism is analogous to the Time To 150 Live (TTL) field in an IP datagram. The TTL field was originally 151 [RFC0791] intended to be the maximum number of seconds that a 152 datagram should remain in the network. In practice, IP TTL has 153 evolved into a hop count, since each system forwarding a datagram was 154 (is) required to decrement the TTL by (at least) one. As an aid to 155 diagnosing problems, the Internet Control Message Protocol [RFC0792] 156 defines a "Time Exceeded Message" to be sent by any system that 157 discards an IP datagram because it was received with a TTL value of 158 zero. The Time Exceeded Message is sent to the source address of the 159 discarded datagram, and includes a field that carries the "Internet 160 Header + 64 bits of Original Data Datagram". This allows the sender 161 to see the datagram as it appeared where it was discarded. The 162 'traceroute' tool determines the route followed between a given pair 163 of IP addresses by sending a series of IP packets from the source to 164 the destination with gradually increasing TTL values. As each packet 165 reaches its limit, an ICMP Time Exceeded Message is returned by the 166 router that is discarding it; some checks on the route can be made by 167 examining the original packet as it arrived at each hop. 169 As an aid to diagnosing problems that result in 483 responses, it 170 would be useful to know how the failed request arrived at the 171 rejecting system; both what path it followed to get there, and what 172 the request looked like when it ran out of hops. One way to 173 accomplish this is to return the SIP header of the rejected message 174 to the sender. Doing so is already allowed by existing rules: 175 RFC 3261 (section 7.4) says: "All responses MAY include a body.". 176 RFC 3420 [RFC3420] defines the Content-Type "message/sipfrag" to 177 "allow SIP entities to make assertions about a subset of a SIP 178 message". 180 This document proposes the following new rule for all SIP 181 implementations: 182 Any 483 response SHOULD be constructed with both: 183 A message body of type message/sipfrag containing as much as 184 possible of the SIP header from the rejected request. 185 A Warning header with a warn-code of 399 that identifies the 186 system returning the error. 188 2.3. Example 190 We will use this proposed change to diagnose an example routing 191 problem. 193 Here is a request sent to a proxy that implements the suggested 194 content in a 483 response. 196 INVITE sip:9999@interop.pingtel.com SIP/2.0 197 Via: SIP/2.0/TCP 10.1.1.20:40221 198 ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f 199 To: sip:9999@interop.pingtel.com 200 From: Sip Send ;tag=612f37e7 201 Call-ID: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 202 Cseq: 1 INVITE 203 Max-Forwards: 9 204 User-Agent: sipsend/0.02 205 Date: Fri, 14 Oct 2005 15:35:53 GMT 206 Content-Length: 0 208 The target user '9999' is one that has been deliberately configured 209 to go into a forwarding loop alternating between two addresses 210 (neither of them the original target); a situation that is currently 211 difficult to diagnose. A relatively low Max-Forwards value of 9 was 212 chosen to improve readability. 214 The response received was: 216 SIP/2.0 483 Too many hops 217 Warning: 399 192.0.2.162:5080 Too Many Hops 218 From: Sip Send ;tag=612f37e7 219 To: sip:9999@interop.pingtel.com 220 Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 221 Cseq: 1 INVITE 222 Via: SIP/2.0/TCP 10.1.1.20:40221 223 ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f 224 Content-Type: message/sipfrag 225 Content-Length: 1014 226 Date: Fri, 14 Oct 2005 15:27:47 GMT 228 INVITE sip:InfiniteLoop@interop.pingtel.com SIP/2.0 229 Record-Route: 231 Via: SIP/2.0/TCP 192.0.2.162 232 ;branch=z9hG4bK-42e47bba67559bd9a3da1934a70bbc37 233 Via: SIP/2.0/TCP 192.0.2.162:5080 234 ;branch=z9hG4bK-50d909f1209f7a820de85c7831846330 235 Via: SIP/2.0/TCP 192.0.2.162 236 ;branch=z9hG4bK-994f162bc179fb75093166fabbfd13c7 237 Via: SIP/2.0/TCP 192.0.2.162:5080 238 ;branch=z9hG4bK-708842ad6ea22f8fa6e39c503d3d803e 239 Via: SIP/2.0/TCP 192.0.2.162 240 ;branch=z9hG4bK-50b581a06ca023ebcddbc82c5221149c 241 Via: SIP/2.0/TCP 192.0.2.14:1084 242 ;branch=z9hG4bK994220327571023745d7996c13560a11.0 243 Via: SIP/2.0/TCP 192.0.2.14:40221 244 ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f 245 To: sip:9999@interop.pingtel.com 246 From: Sip Send ;tag=612f37e7 247 Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 248 Cseq: 1 INVITE 249 Max-Forwards: 0 250 User-Agent: sipsend/0.02 251 Date: Fri, 14 Oct 2005 15:35:53 GMT 252 Content-Length: 0 254 The Warning header in this response identifies the server returning 255 the error (192.0.2.162:5080). The Via headers of the returned 256 message/sipfrag body show the path the failed message took. The 257 returned request line also shows that the target URI has been changed 258 to the user 'InfiniteLoop'. 260 Resending the request with a hop limit one less than before (8), 261 shows that at that hop the request URI is to user 'LoopForever': 263 INVITE sip:LoopForever@interop.pingtel.com SIP/2.0 264 Record-Route: 266 Via: SIP/2.0/TCP 192.0.2.162 267 ;branch=z9hG4bK-9b7f69455266f7cccd4ae8a285c0417c 268 Via: SIP/2.0/TCP 192.0.2.162:5080 269 ;branch=z9hG4bK-b9d3e2aff65e68497849a2609bf8c373 270 Via: SIP/2.0/TCP 192.0.2.162 271 ;branch=z9hG4bK-a178f4c5a3b8bbf35f979bc6c6d33022 272 Via: SIP/2.0/TCP 192.0.2.162:5080 273 ;branch=z9hG4bK-3c098b8d58e4b6ce98fca3495263e795 274 Via: SIP/2.0/TCP 192.0.2.162 275 ;branch=z9hG4bK-e7ceb06ed917d59024c905b3ee60e4cc 276 Via: SIP/2.0/TCP 192.0.2.14:1085 277 ;branch=z9hG4bK8d685f52450e87da45d7996c13560a11.0 278 Via: SIP/2.0/TCP 192.0.2.14:56114 279 ;branch=z9hG4bK-4ae5a563b0cbc76aef7be17115836dea 280 To: sip:9999@interop.pingtel.com 281 From: Sip Send ;tag=4f18a30b 282 Call-Id: 39106d45526cb5e78bf8dac378e05817@10.1.1.20 283 Cseq: 1 INVITE 284 Max-Forwards: 0 285 User-Agent: sipsend/0.02 286 Date: Fri, 14 Oct 2005 15:42:21 GMT 287 Content-Length: 0 288 Route: 290 Reducing the limit one at a time (or starting from 1 and working 291 forward), the sender can determine that the InfiniteLoop/LoopForever 292 forwarding loop exists (in reality, of course, the user names would 293 rarely be such good hints), and where in the forwarding sequence the 294 original '9999' was changed to enter the loop. 296 Without the returned request headers, the 483 response does not help 297 the request originator (or any proxy administrator on the path) 298 diagnose why the error has occurred. With it, in this case a 299 diagnostic application running as a User Agent is able to at least 300 identify that there is a routing problem and which proxy is 301 misrouting the request. 303 2.4. Pruning Responses 305 A server may be unable or unwilling to return the full request 306 message in every 483 response. The returned message may exceed the 307 maximum message size it can handle, or may include security-sensitive 308 information. 310 It is suggested in this case that at least all of the Route and Via 311 headers from the request be returned in the message/sipfrag body. In 312 the example (Section 2.3), this would at least enable the end user to 313 determine which proxies were in the routing loop and how the request 314 arrived there, but not the specific address transformations that 315 caused the loop. 317 If including all Via and Route headers is still too large, the 318 implementation SHOULD remove the oldest Vias (those nearest the 319 message originator) until the size is acceptable. This way, the 320 originator can detect that some Vias were removed (because the one 321 that it put on is missing). 323 3. Implementation Experience 325 One open source implementation has been generating 483 responses 326 roughly as recommended above, this has been explicitly tested both at 327 SIPit and in production use for any interoperability problems it 328 might cause. No problems have been observed, except with some 329 implementations that cannot reassemble fragmented UDP packets (these 330 implementations tend to have problems with long paths in any case). 332 4. IANA Considerations 334 None. 336 5. Security Considerations 338 The proposed mechanism provides a means by which topology and some 339 routing information about a set of SIP systems can be discovered. 340 The mechanism is very similar to that provided for IP routing by the 341 traceroute tool. 343 Some systems may not want to expose as much information as is 344 available in the full set of SIP request headers by returning them in 345 the error response body. In this case, the system returning the 346 error should prune the response as recommended in Section 2.4. 348 6. References 349 6.1. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, March 1997. 354 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 355 A., Peterson, J., Sparks, R., Handley, M., and E. 356 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 357 June 2002. 359 [RFC3420] Sparks, R., "Internet Media Type message/sipfrag", 360 RFC 3420, November 2002. 362 6.2. Informative References 364 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 365 September 1981. 367 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 368 RFC 792, September 1981. 370 Authors' Addresses 372 Scott Lawrence 373 Pingtel Corp. 374 400 West Cummings Park 375 Suite 2200 376 Woburn, MA 01801 377 USA 379 Phone: +1 781 938 5306 380 Email: slawrence@pingtel.com 382 Alan Hawrylyshen 383 Ditech Networks Inc. 384 1167 Kensington Rd NW 385 Suite 200 386 Calgary, Alberta T2N 1X7 387 Canada 389 Phone: +1 403 806 3366 390 Email: ahawrylyshen@ditechnetworks.com 392 Robert Sparks 393 Estacado Systems 394 17210 Campbell Road 395 Suite 250 396 Dallas, Texas 75254-4203 397 USA 399 Email: RjS@nostrum.com 401 Intellectual Property Statement 403 The IETF takes no position regarding the validity or scope of any 404 Intellectual Property Rights or other rights that might be claimed to 405 pertain to the implementation or use of the technology described in 406 this document or the extent to which any license under such rights 407 might or might not be available; nor does it represent that it has 408 made any independent effort to identify any such rights. Information 409 on the procedures with respect to rights in RFC documents can be 410 found in BCP 78 and BCP 79. 412 Copies of IPR disclosures made to the IETF Secretariat and any 413 assurances of licenses to be made available, or the result of an 414 attempt made to obtain a general license or permission for the use of 415 such proprietary rights by implementers or users of this 416 specification can be obtained from the IETF on-line IPR repository at 417 http://www.ietf.org/ipr. 419 The IETF invites any interested party to bring to its attention any 420 copyrights, patents or patent applications, or other proprietary 421 rights that may cover technology that may be required to implement 422 this standard. Please address the information to the IETF at 423 ietf-ipr@ietf.org. 425 Disclaimer of Validity 427 This document and the information contained herein are provided on an 428 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 429 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 430 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 431 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 432 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 433 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 435 Copyright Statement 437 Copyright (C) The Internet Society (2006). This document is subject 438 to the rights, licenses and restrictions contained in BCP 78, and 439 except as set forth therein, the authors retain all their rights. 441 Acknowledgment 443 Funding for the RFC Editor function is currently provided by the 444 Internet Society.