idnits 2.17.1 draft-ietf-sip-hop-limit-diagnostics-03.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 487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 477. ** 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 16, 2006) is 6523 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 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 5 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 18, 2006 Ditech Networks Inc. 6 R. Sparks 7 Estacado Systems 8 June 16, 2006 10 Diagnostic Responses for Session Initiation Protocol Hop Limit Errors 11 draft-ietf-sip-hop-limit-diagnostics-03 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 18, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 The Session Initiation Protocol (SIP) imposes a limit on the number 45 of hops a request can transit on the way to its destination. When 46 this limit is reached, a 483 (Too Many Hops) error response is 47 returned. The present form of the 483 response does not provide 48 enough information for the UAC or proxy on the path to diagnose 49 failures whose symptom is that the hop limit is reached. This 50 document specifies additional diagnostic information to be returned 51 in a 483 response. 53 Table of Contents 55 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 56 2. Diagnosing Hop Limit Exceeded Failures . . . . . . . . . . . . 4 57 2.1. Limitations of the 483 Error Response . . . . . . . . . . 4 58 2.2. Improved Diagnostic Information in Responses . . . . . . . 5 59 3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3.1. Pruning Responses . . . . . . . . . . . . . . . . . . . . 7 61 4. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 70 Intellectual Property and Copyright Statements . . . . . . . . . . 17 72 1. Conventions and Definitions 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC-2119 [RFC2119]. 78 2. Diagnosing Hop Limit Exceeded Failures 80 The SIP protocol imposes a limit on the number of hops a request can 81 transit on the way to its destination. The number of hops remaining 82 for the request is carried in the Max-Forwards header, and is 83 decremented each time the request is forwarded. When a SIP User 84 Agent receives a request whose Max-Forwards is zero (0), it returns a 85 483 error response to indicate that the limit was reached. 87 The 483 response alone does not provide enough information for the 88 originating UAC to determine where the problem lies. The problem is 89 rarely that the target of the request was actually further away than 90 the Max-Forwards limit allowed. The problem is usually incorrect 91 routing; often a routing loop. 93 2.1. Limitations of the 483 Error Response 95 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 tool. When a 105 request has traversed a series of proxies, the response follows the 106 Vias back to the requester - in the case of a typical 483 response it 107 can be difficult to determine even what server the response came 108 from. Even when the rejecting server does identify itself, it can be 109 difficult 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 126 This request was sent with the Max-Forwards header field value set to 127 only 1 to force the error response: it should traverse only the first 128 outbound proxy, and then be rejected by the next system that it 129 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. Improved Diagnostic Information in Responses 149 In some ways, the SIP Max-Forwards mechanism is analogous to the Time 150 To 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 (0). The Time Exceeded Message is sent to the source address of 159 the discarded datagram, and includes a field that carries the 160 "Internet Header + 64 bits of Original Data Datagram". This allows 161 the originator to see the datagram as it appeared where it was 162 discarded. The 'traceroute' tool determines the route followed 163 between a given pair of IP addresses by sending a series of IP 164 packets from the source to the destination with gradually increasing 165 TTL values. As each packet reaches its limit, an ICMP Time Exceeded 166 Message is returned by the router that is discarding it; some checks 167 on the route can be made by examining the original packet as it 168 arrived at each hop. 170 As an aid to diagnosing problems that result in 483 responses, it 171 would be useful to know how the failed request arrived at the 172 rejecting system; both what path it followed to get there, and what 173 the request looked like when it ran out of hops. One way to 174 accomplish this is to return the SIP header of the rejected message 175 to the UAC that originated it. Doing so is already allowed by 176 existing rules: 178 RFC 3261 [RFC3420] (section 7.4) says: "All responses MAY include 179 a body.". 181 RFC 3420 [RFC3420] defines the Content-Type "message/sipfrag" to 182 "allow SIP entities to make assertions about a subset of a SIP 183 message". 185 3. Proxy Behavior 187 This document adds the following new rule for all SIP Proxy 188 implementations: 190 Any 483 response SHOULD be constructed with both: 192 A message body of type message/sipfrag containing as much as 193 possible of the SIP header from the rejected request. 195 A Warning header with a warn-code of 399 that identifies the 196 system returning the error. 198 Exceptions to this are allowed so that a system is allowed to omit 199 parts of the message either to limit the size of the response or 200 to conform to a local security policy. See Section 3.1. 202 3.1. Pruning Responses 204 A server may be unable or unwilling to return the full request 205 message in every 483 response. The returned message may exceed the 206 maximum message size it can handle, or may include security-sensitive 207 information. 209 It is RECOMMENDED that when the complete message cannot be returned, 210 that at least all of the Route and Via headers be included in the 211 message/sipfrag body. In the example (Section 6), this would at 212 least enable the end user to determine which proxies were in the 213 routing loop and how the request arrived there, but not the specific 214 address transformations that caused the loop. 216 If including all Via and Route headers is still too large, the 217 implementation SHOULD remove the oldest Vias (those nearest the 218 message originator) until the size is acceptable; the only exception 219 to this rule is when . This way, the originator can detect that some 220 Vias were removed (because the one that it put on is missing). 222 4. UAS Behavior 224 Since a UAS is not required to validate the Max-Forwards header field 225 value when processing a received message, it is not required to 226 return the received message header as described above for proxies, 227 but it MAY do so. 229 5. UAC Behavior 231 This specification does not mandate any new behavior for a UAC. The 232 returned message is available to the UAC to either pass on to the 233 user or to use for any automated diagnostic process. 235 Note that a UAC MUST be prepared to receive message bodies in a 236 response that it does not understand and did not request; this is 237 already required by [RFC3261] section 20.1 Accept: 239 The Accept header field follows the syntax defined in [H14.1]. 240 The semantics are also identical, with the exception that if no 241 Accept header field is present, the server SHOULD assume a default 242 value of application/sdp. 244 [H14.1] refers to RFC 2616 [RFC2616], which specifically limits the 245 semantics of the Accept header fields in section 10.4.7 '406 Not 246 Acceptable' as follows: 248 Note: HTTP/1.1 servers are allowed to return responses which are 249 not acceptable according to the accept headers sent in the 250 request. In some cases, this may even be preferable to sending a 251 406 response. User agents are encouraged to inspect the headers 252 of an incoming response to determine if it is acceptable. 254 6. Example 256 This example shows how this proposed change is used to diagnose an 257 example routing problem. 259 Here is a request sent to a proxy that implements the suggested 260 content in a 483 response. 262 INVITE sip:9999@example.com SIP/2.0 263 Via: SIP/2.0/TCP 10.1.1.20:40221 264 ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f 265 To: sip:9999@example.com 266 From: Sip Send ;tag=612f37e7 267 Call-ID: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 268 Cseq: 1 INVITE 269 Max-Forwards: 9 270 User-Agent: sipsend/0.02 271 Date: Fri, 14 Oct 2005 15:35:53 GMT 272 Content-Length: 0 274 The target user '9999' is one that has been deliberately configured 275 to go into a forwarding loop alternating between two addresses 276 (neither of them the original target); a situation that is currently 277 difficult to diagnose. A relatively low Max-Forwards header field 278 value of 9 was chosen to improve readability. 280 The response received was: 282 SIP/2.0 483 Too many hops 283 Warning: 399 192.0.2.162:5080 Too Many Hops 284 From: Sip Send ;tag=612f37e7 285 To: sip:9999@example.com 286 Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 287 Cseq: 1 INVITE 288 Via: SIP/2.0/TCP 10.1.1.20:40221 289 ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f 290 Content-Type: message/sipfrag 291 Content-Length: 1014 292 Date: Fri, 14 Oct 2005 15:27:47 GMT 294 INVITE sip:InfiniteLoop@example.com SIP/2.0 295 Record-Route: 297 Via: SIP/2.0/TCP 192.0.2.162 298 ;branch=z9hG4bK-42e47bba67559bd9a3da1934a70bbc37 299 Via: SIP/2.0/TCP 192.0.2.162:5080 300 ;branch=z9hG4bK-50d909f1209f7a820de85c7831846330 301 Via: SIP/2.0/TCP 192.0.2.162 302 ;branch=z9hG4bK-994f162bc179fb75093166fabbfd13c7 303 Via: SIP/2.0/TCP 192.0.2.162:5080 304 ;branch=z9hG4bK-708842ad6ea22f8fa6e39c503d3d803e 305 Via: SIP/2.0/TCP 192.0.2.162 306 ;branch=z9hG4bK-50b581a06ca023ebcddbc82c5221149c 307 Via: SIP/2.0/TCP 192.0.2.14:1084 308 ;branch=z9hG4bK994220327571023745d7996c13560a11.0 309 Via: SIP/2.0/TCP 192.0.2.14:40221 310 ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f 311 To: sip:9999@example.com 312 From: Sip Send ;tag=612f37e7 313 Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 314 Cseq: 1 INVITE 315 Max-Forwards: 0 316 User-Agent: sipsend/0.02 317 Date: Fri, 14 Oct 2005 15:35:53 GMT 318 Content-Length: 0 320 The Warning header in this response identifies the server returning 321 the error (192.0.2.162:5080). The Via headers of the returned 322 message/sipfrag body show the path the failed message took. The 323 returned request line also shows that the target URI has been changed 324 to the user 'InfiniteLoop'. 326 Resending the request with a hop limit one less than before (8), 327 shows that at that hop the request URI is to user 'LoopForever': 329 INVITE sip:LoopForever@example.com SIP/2.0 330 Record-Route: 332 Via: SIP/2.0/TCP 192.0.2.162 333 ;branch=z9hG4bK-9b7f69455266f7cccd4ae8a285c0417c 334 Via: SIP/2.0/TCP 192.0.2.162:5080 335 ;branch=z9hG4bK-b9d3e2aff65e68497849a2609bf8c373 336 Via: SIP/2.0/TCP 192.0.2.162 337 ;branch=z9hG4bK-a178f4c5a3b8bbf35f979bc6c6d33022 338 Via: SIP/2.0/TCP 192.0.2.162:5080 339 ;branch=z9hG4bK-3c098b8d58e4b6ce98fca3495263e795 340 Via: SIP/2.0/TCP 192.0.2.162 341 ;branch=z9hG4bK-e7ceb06ed917d59024c905b3ee60e4cc 342 Via: SIP/2.0/TCP 192.0.2.14:1085 343 ;branch=z9hG4bK8d685f52450e87da45d7996c13560a11.0 344 Via: SIP/2.0/TCP 192.0.2.14:56114 345 ;branch=z9hG4bK-4ae5a563b0cbc76aef7be17115836dea 346 To: sip:9999@example.com 347 From: Sip Send ;tag=4f18a30b 348 Call-Id: 39106d45526cb5e78bf8dac378e05817@10.1.1.20 349 Cseq: 1 INVITE 350 Max-Forwards: 0 351 User-Agent: sipsend/0.02 352 Date: Fri, 14 Oct 2005 15:42:21 GMT 353 Content-Length: 0 354 Route: 356 Reducing the limit one at a time (or starting from 1 and working 357 forward), a UAC can determine that the InfiniteLoop/LoopForever 358 forwarding loop exists (in reality, of course, the user names would 359 rarely be such good hints), and where in the forwarding sequence the 360 original '9999' was changed to enter the loop. 362 Without the returned request headers, the 483 response does not help 363 the request originator (or any proxy administrator on the path) 364 diagnose why the error has occurred. With it, in this case a 365 diagnostic application running as a User Agent is able to at least 366 identify that there is a routing problem and which proxy is 367 misrouting the request. 369 7. IANA Considerations 371 None. 373 8. Security Considerations 375 The proposed mechanism provides a means by which topology and some 376 routing information about a set of SIP systems can be discovered. 377 The mechanism is very similar to that provided for IP routing by the 378 traceroute tool. 380 Some systems may not want to expose as much information as is 381 available in the full set of SIP request headers by returning them in 382 the error response body. In this case, the system returning the 383 error should prune the response as recommended in Section 3.1. 385 It may be possible for an attacker to forge very large messages with 386 a deliberately low Max-Forwards header field values so that a Server 387 will send error responses. If those responses are fragemented and 388 sent on a transport that does not have congestion control, this could 389 cause a small number more response packets than the attacker sent 390 requests. The server is allowed to prune the response as recommended 391 in Section 3.1 to reduce the response size, which reduces the 392 opportunity for the attacker to generate many fragments. Other than 393 this, the returned response message is roughly twice the size of the 394 original request, and gets smaller as the Via and Route headers are 395 removed in transit, so there is little amplification. 397 9. References 399 9.1. Normative References 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 404 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 405 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 406 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 408 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 409 A., Peterson, J., Sparks, R., Handley, M., and E. 410 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 411 June 2002. 413 [RFC3420] Sparks, R., "Internet Media Type message/sipfrag", 414 RFC 3420, November 2002. 416 9.2. Informative References 418 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 419 September 1981. 421 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 422 RFC 792, September 1981. 424 Authors' Addresses 426 Scott Lawrence 427 Pingtel Corp. 428 400 West Cummings Park 429 Suite 2200 430 Woburn, MA 01801 431 USA 433 Phone: +1 781 938 5306 434 Email: slawrence@pingtel.com 436 Alan Hawrylyshen 437 Ditech Networks Inc. 438 1167 Kensington Rd NW 439 Suite 200 440 Calgary, Alberta T2N 1X7 441 Canada 443 Phone: +1 403 806 3366 444 Email: ahawrylyshen@ditechnetworks.com 446 Robert Sparks 447 Estacado Systems 448 17210 Campbell Road 449 Suite 250 450 Dallas, Texas 75254-4203 451 USA 453 Email: RjS@nostrum.com 455 Intellectual Property Statement 457 The IETF takes no position regarding the validity or scope of any 458 Intellectual Property Rights or other rights that might be claimed to 459 pertain to the implementation or use of the technology described in 460 this document or the extent to which any license under such rights 461 might or might not be available; nor does it represent that it has 462 made any independent effort to identify any such rights. Information 463 on the procedures with respect to rights in RFC documents can be 464 found in BCP 78 and BCP 79. 466 Copies of IPR disclosures made to the IETF Secretariat and any 467 assurances of licenses to be made available, or the result of an 468 attempt made to obtain a general license or permission for the use of 469 such proprietary rights by implementers or users of this 470 specification can be obtained from the IETF on-line IPR repository at 471 http://www.ietf.org/ipr. 473 The IETF invites any interested party to bring to its attention any 474 copyrights, patents or patent applications, or other proprietary 475 rights that may cover technology that may be required to implement 476 this standard. Please address the information to the IETF at 477 ietf-ipr@ietf.org. 479 Disclaimer of Validity 481 This document and the information contained herein are provided on an 482 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 483 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 484 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 485 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 486 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 487 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 489 Copyright Statement 491 Copyright (C) The Internet Society (2006). This document is subject 492 to the rights, licenses and restrictions contained in BCP 78, and 493 except as set forth therein, the authors retain all their rights. 495 Acknowledgment 497 Funding for the RFC Editor function is currently provided by the 498 Internet Society.