idnits 2.17.1 draft-ietf-sip-hop-limit-diagnostics-00.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 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 401. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 414. ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (February 24, 2006) is 6636 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 (==), 7 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 Expires: August 28, 2006 A. Hawrylyshen 5 Ditech Communications Corp. 6 R. Sparks 7 Estacado Systems 8 February 24, 2006 10 Diagnostic Responses for SIP Hop Limit Errors 11 draft-ietf-sip-hop-limit-diagnostics-00 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 August 28, 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 The proposal in this document was originally presented in another 56 draft-lawrence-maxforward-problems-00 on the SIPPING working group 57 list. That draft raised a number of issues, each of which was 58 referred to the SIP working group to be addressed, but it was decided 59 to consider each issue separately. This proposal is, aside from 60 purely editorial corrections, unchanged from the earlier draft. 62 Table of Contents 64 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 65 2. Diagnosing Hop Limit Exceeded Failures . . . . . . . . . . . . 3 66 2.1. Limitations of the 483 Error Response . . . . . . . . . . 3 67 2.2. Returning Useful Diagnostic Information in 483 68 Responses . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.4. Implementation Experience . . . . . . . . . . . . . . . . 8 71 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 75 5.2. Informative References . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 77 Intellectual Property and Copyright Statements . . . . . . . . . . 12 79 1. Conventions and Definitions 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC-2119 [RFC2119]. 85 2. Diagnosing Hop Limit Exceeded Failures 87 The SIP protocol imposes a limit on the number of hops a request may 88 make from a sender to the recipient. The number of hops remaining 89 for the request is carried in the Max-Forwards header, and is 90 decremented each time the request is forwarded. When a SIP User 91 Agent receives a request whose Max-Forwards is zero, it returns a 483 92 error response to indicate that the limit was reached. 94 The 483 response alone does not provide enough information, for the 95 sender to determine where the problem lies. In the authors 96 experience, the problem is rarely that the target of the request was 97 actually further away than the Max-Forwards limit allowed. The 98 problem is usually incorrect routing; often a routing loop. 100 2.1. Limitations of the 483 Error Response 102 Section 20.22 of RFC 3261 [RFC3261] says: 103 The Max-Forwards header field must be used with any SIP method to 104 limit the number of proxies or gateways that can forward the 105 request to the next downstream server. This can also be useful 106 when the client is attempting to trace a request chain that 107 appears to be failing or looping in mid-chain. 109 In practice, there is too little information returned in a 483 110 response for it to be of much use as a diagnostic. When a request 111 has traversed a series of proxies, the response follows the Vias back 112 to the requester; in the case of a typical 483 response it can be 113 difficult to determine even what server the response came from. Even 114 when the rejecting server does identify itself, it can be difficult 115 to figure out why the request got there. 117 The following is an actual example request; the IP addresses and 118 domain names have been changed, but it is otherwise complete (it was 119 intentionally sent without SDP for brevity): 121 INVITE sip:9999@example.com SIP/2.0 122 Via: SIP/2.0/TCP 10.1.1.20:59449 123 ;branch=z9hG4bK-56ec69968c31f498c9a5573a00c8fc04 124 To: sip:9999@example.com 125 From: Sip Send ;tag=08e2f515 126 Call-ID: 159213b1aa5a67bc6eca6c4c2bad9f94@10.1.1.20 127 Cseq: 1 INVITE 128 Max-Forwards: 1 129 User-Agent: sipsend/0.02 130 Date: Wed, 12 Oct 2005 20:09:29 GMT 131 Content-Length: 0 133 This request was sent with the Max-Forwards value set to only 1 to 134 force the error response: it should traverse only the first outbound 135 proxy, and then be rejected by the next system that it encounters. 137 The response received in this case was: 139 SIP/2.0 483 Too Many Hops 140 Via: SIP/2.0/TCP 10.1.1.20:59449 141 ;branch=z9hG4bK-56ec69968c31f498c9a5573a00c8fc04 142 To: sip:9999@example.com;tag=-1574266585 143 From: Sip Send ;tag=08e2f515 144 Call-ID: 159213b1aa5a67bc6eca6c4c2bad9f94@10.1.1.20 145 Cseq: 1 INVITE 146 Content-Length: 0 148 There is no indication in the response of what server returned the 149 error. Even with the error only one hop beyond the first proxy, 150 there is no way to determine if that first proxy has routed the 151 request incorrectly. 153 2.2. Returning Useful Diagnostic Information in 483 Responses 155 In some ways, the Max-Forwards mechanism is analogous to the Time To 156 Live (TTL) field in an IP datagram. The TTL field was originally 157 [RFC0791] intended to be the maximum number of seconds that a 158 datagram should remain in the network. In practice, IP TTL has 159 evolved into a hop count, since each system forwarding a datagram was 160 (is) required to decrement the TTL by (at least) one. As an aid to 161 diagnosing problems, the Internet Control Message Protocol [RFC0792] 162 defines a "Time Exceeded Message" to be sent by any system that 163 discards an IP datagram because it was received with a TTL value of 164 zero. The Time Exceeded Message is sent to the source address of the 165 discarded datagram, and includes a field that carries the "Internet 166 Header + 64 bits of Original Data Datagram". This allows the sender 167 to see the datagram as it appeared where it was discarded. The 168 'traceroute' tool determines the route followed between a given pair 169 of IP addresses by sending a series of IP packets from the source to 170 the destination with gradually increasing TTL values. As each packet 171 reaches its limit, an ICMP Time Exceeded Message is returned by the 172 router that is discarding it; some checks on the route can be made by 173 examining the original packet as it arrived at each hop. 175 As an aid to diagnosing problems that result in 483 responses, it 176 would be useful to know how the failed request arrived at the 177 rejecting system; both what path it followed to get there, and what 178 the request looked like when it ran out of hops. One way to 179 accomplish this is to return the SIP header of the rejected message 180 to the sender. Doing so is already allowed by existing rules: 181 RFC 3261 (section 7.4) says: "All responses MAY include a body.". 182 RFC 3420 [RFC3420] defines the Content-Type "message/sipfrag" to 183 "allow SIP entities to make assertions about a subset of a SIP 184 message". 186 This document proposes the following new rule for all SIP 187 implementations: 188 Any 483 response SHOULD be constructed with a message body of type 189 message/sipfrag containing as much as possible of the SIP header 190 from the rejected request. 192 2.3. Example 194 We will use this proposed change to diagnose an example routing 195 problem. 197 Here is a request sent to a proxy that implements the suggested 198 content in a 483 response. 200 INVITE sip:9999@interop.pingtel.com SIP/2.0 201 Via: SIP/2.0/TCP 10.1.1.20:40221 202 ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f 203 To: sip:9999@interop.pingtel.com 204 From: Sip Send ;tag=612f37e7 205 Call-ID: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 206 Cseq: 1 INVITE 207 Max-Forwards: 9 208 User-Agent: sipsend/0.02 209 Date: Fri, 14 Oct 2005 15:35:53 GMT 210 Content-Length: 0 212 The target user '9999' is one that has been deliberately configured 213 to go into a forwarding loop alternating between two addresses 214 (neither of them the original target); a situation that is currently 215 difficult to diagnose. A relatively low Max-Forwards value of 9 was 216 chosen to improve readability. 218 The response received was: 220 SIP/2.0 483 Too many hops 221 From: Sip Send ;tag=612f37e7 222 To: sip:9999@interop.pingtel.com 223 Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 224 Cseq: 1 INVITE 225 Via: SIP/2.0/TCP 10.1.1.20:40221 226 ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f 227 Content-Type: message/sipfrag 228 Content-Length: 1014 229 Date: Fri, 14 Oct 2005 15:27:47 GMT 231 INVITE sip:InfiniteLoop@interop.pingtel.com SIP/2.0 232 Record-Route: 234 Via: SIP/2.0/TCP 192.0.2.162 235 ;branch=z9hG4bK-42e47bba67559bd9a3da1934a70bbc37 236 Via: SIP/2.0/TCP 192.0.2.162:5080 237 ;branch=z9hG4bK-50d909f1209f7a820de85c7831846330 238 Via: SIP/2.0/TCP 192.0.2.162 239 ;branch=z9hG4bK-994f162bc179fb75093166fabbfd13c7 240 Via: SIP/2.0/TCP 192.0.2.162:5080 241 ;branch=z9hG4bK-708842ad6ea22f8fa6e39c503d3d803e 242 Via: SIP/2.0/TCP 192.0.2.162 243 ;branch=z9hG4bK-50b581a06ca023ebcddbc82c5221149c 244 Via: SIP/2.0/TCP 192.0.2.14:1084 245 ;branch=z9hG4bK994220327571023745d7996c13560a11.0 246 Via: SIP/2.0/TCP 192.0.2.14:40221 247 ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f 248 To: sip:9999@interop.pingtel.com 249 From: Sip Send ;tag=612f37e7 250 Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 251 Cseq: 1 INVITE 252 Max-Forwards: 0 253 User-Agent: sipsend/0.02 254 Date: Fri, 14 Oct 2005 15:35:53 GMT 255 Content-Length: 0 257 This response shows what server returned the error; its' address - 258 192.0.2.162 - is in the topmost Via of the returned request. It also 259 shows that the target URI has been changed to the user 260 'InfiniteLoop'. 262 Resending the request with a hop limit one less than before (8), 263 shows that at that hop the request URI is to user 'LoopForever': 265 INVITE sip:LoopForever@interop.pingtel.com SIP/2.0 266 Record-Route: 268 Via: SIP/2.0/TCP 192.0.2.162 269 ;branch=z9hG4bK-9b7f69455266f7cccd4ae8a285c0417c 270 Via: SIP/2.0/TCP 192.0.2.162:5080 271 ;branch=z9hG4bK-b9d3e2aff65e68497849a2609bf8c373 272 Via: SIP/2.0/TCP 192.0.2.162 273 ;branch=z9hG4bK-a178f4c5a3b8bbf35f979bc6c6d33022 274 Via: SIP/2.0/TCP 192.0.2.162:5080 275 ;branch=z9hG4bK-3c098b8d58e4b6ce98fca3495263e795 276 Via: SIP/2.0/TCP 192.0.2.162 277 ;branch=z9hG4bK-e7ceb06ed917d59024c905b3ee60e4cc 278 Via: SIP/2.0/TCP 192.0.2.14:1085 279 ;branch=z9hG4bK8d685f52450e87da45d7996c13560a11.0 280 Via: SIP/2.0/TCP 192.0.2.14:56114 281 ;branch=z9hG4bK-4ae5a563b0cbc76aef7be17115836dea 282 To: sip:9999@interop.pingtel.com 283 From: Sip Send ;tag=4f18a30b 284 Call-Id: 39106d45526cb5e78bf8dac378e05817@10.1.1.20 285 Cseq: 1 INVITE 286 Max-Forwards: 0 287 User-Agent: sipsend/0.02 288 Date: Fri, 14 Oct 2005 15:42:21 GMT 289 Content-Length: 0 290 Route: 292 Reducing the limit one at a time (or starting from 1 and working 293 forward), the sender can determine that the InfiniteLoop/LoopForever 294 forwarding loop exists (in reality, of course, the user names would 295 rarely be such good hints), and where in the forwarding sequence the 296 original '9999' was changed to enter the loop. 298 Without the returned request headers, the 483 response does not help 299 the request originator (or any proxy administrator on the path) 300 diagnose why the error has occurred. With it, in this case a 301 diagnostic application running as a User Agent is able to at least 302 identify that there is a routing problem and which proxy is 303 misrouting the request. 305 2.4. Implementation Experience 307 One open source implementation has been generating 483 responses as 308 recommended above for well over a year, and have explicitly tested 309 both at SIPit and in production use for any interoperability problems 310 it might cause. No problems have been observed, except with some 311 implementations that cannot reassemble fragmented UDP packets (these 312 implementations tend to have problems with long paths). 314 3. IANA Considerations 316 None. 318 4. Security Considerations 320 The proposed mechanism provides a means by which topology and some 321 routing information about a set of SIP systems can be discovered. 322 The mechanism is very similar to that provided for IP routing by the 323 traceroute tool. 325 Some systems may not want to expose as much information as is 326 available in the full set of SIP request headers by returning them in 327 the error response body. It is suggested in this case that at least 328 all of the Route and Via headers from the request be returned in the 329 message/sipfrag body. In the example (Section 2.3), this would at 330 least enable the end user to determine which proxies were in the 331 routing loop and how the request arrived there, but not the specific 332 address transformations that caused the loop. 334 5. References 336 5.1. Normative References 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 342 A., Peterson, J., Sparks, R., Handley, M., and E. 343 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 344 June 2002. 346 [RFC3420] Sparks, R., "Internet Media Type message/sipfrag", 347 RFC 3420, November 2002. 349 5.2. Informative References 351 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 352 September 1981. 354 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 355 RFC 792, September 1981. 357 [maxforward] 358 Lawrence, S., Hawrylyshen, A., and R. Sparks, "Problems 359 with Max-Forwards Processing (and Potential Solutions)". 361 Authors' Addresses 363 Scott Lawrence 364 Pingtel Corp. 365 400 West Cummings Park 366 Suite 2200 367 Woburn, MA 01801 368 USA 370 Phone: +1 781 938 5306 371 Email: slawrence@pingtel.com 373 Alan Hawrylyshen 374 Ditech Communications Corp. 375 602 - 11 Ave SW 376 Suite 310 377 Calgary, Alberta T2R 1J8 378 Canada 380 Phone: +1 403 561 7313 381 Email: ahawrylyshen@ditechcom.com 383 Robert Sparks 384 Estacado Systems 385 17210 Campbell Road 386 Suite 250 387 Dallas, Texas 75254-4203 388 USA 390 Email: RjS@nostrum.com 392 Intellectual Property Statement 394 The IETF takes no position regarding the validity or scope of any 395 Intellectual Property Rights or other rights that might be claimed to 396 pertain to the implementation or use of the technology described in 397 this document or the extent to which any license under such rights 398 might or might not be available; nor does it represent that it has 399 made any independent effort to identify any such rights. Information 400 on the procedures with respect to rights in RFC documents can be 401 found in BCP 78 and BCP 79. 403 Copies of IPR disclosures made to the IETF Secretariat and any 404 assurances of licenses to be made available, or the result of an 405 attempt made to obtain a general license or permission for the use of 406 such proprietary rights by implementers or users of this 407 specification can be obtained from the IETF on-line IPR repository at 408 http://www.ietf.org/ipr. 410 The IETF invites any interested party to bring to its attention any 411 copyrights, patents or patent applications, or other proprietary 412 rights that may cover technology that may be required to implement 413 this standard. Please address the information to the IETF at 414 ietf-ipr@ietf.org. 416 Disclaimer of Validity 418 This document and the information contained herein are provided on an 419 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 420 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 421 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 422 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 423 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 424 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 426 Copyright Statement 428 Copyright (C) The Internet Society (2006). This document is subject 429 to the rights, licenses and restrictions contained in BCP 78, and 430 except as set forth therein, the authors retain all their rights. 432 Acknowledgment 434 Funding for the RFC Editor function is currently provided by the 435 Internet Society.