SIPPING WG S. Lawrence Internet-Draft Pingtel Corp. Expires: April 19, 2006 A. Hawrylyshen Ditech Communications Corp. R. Sparks Estacado Systems October 16, 2005 Problems with Max-Forwards Processing (and Potential Solutions) draft-lawrence-maxforward-problems-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. The document analysis ways to limit the impact of this kind of attack, and proposes changes to the SIP protocol to help mitigate the risk. The document also Lawrence, et al. Expires April 19, 2006 [Page 1] Internet-Draft Max-Forwards Problems October 2005 proposes ways to improve diagnosis of failures caused by the hop limit being reached. The purpose of this document is to stimulate discussion of the identified problem and proposed solutions. Much of the proposed solution language appears normative, but implementors should not treat the current document as such. Comments are solicited, and should be directed to the SIPPING working group list at 'sipping@ietf.org'. Table of Contents 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Leveraging Forking to Flood A Network . . . . . . . . . . . . 3 4. The Attack in Practice - Observations from the SIPIT . . . . . 5 5. Mitigating the Risk . . . . . . . . . . . . . . . . . . . . . 6 6. Limiting Total Hops When Forking . . . . . . . . . . . . . . . 7 6.1. Restoring the Meaning of Max-Forwards . . . . . . . . . . 7 6.2. Max-Forward Split Weight Selection . . . . . . . . . . . . 9 6.3. Limitations and Issues with Splitting Max-Forwards . . . . 9 6.4. Parallel and Sequential Forking . . . . . . . . . . . . . 10 7. Diagnosing Hop Limit Exceeded Failures . . . . . . . . . . . . 10 7.1. Limitations of the 483 Error Response . . . . . . . . . . 11 7.2. Returning Useful Diagnostic Information in 483 Responses . . . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Lawrence, et al. Expires April 19, 2006 [Page 2] Internet-Draft Max-Forwards Problems October 2005 1. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 2. Introduction This document demonstrates how to leverage parallel forking to cause a small number (less than 10) of valid SIP requests to generate extremely large (order 2^70) number of proxy-to-proxy messages. The document proceeds to analyze possible ways to mitigate this potential attack. It also proposes mechanisms for better diagnoses of failures due to Max-Forwards being reached. The purpose of this document is to stimulate discussion of this problem. It is expected that additional potential solutions will be brought forth and that the community will move quickly to amend protocol and implementation behavior before the type of attack discussed here becomes regularly exploited. 3. Leveraging Forking to Flood A Network This section describes setting up the attack with a simplifying assumption, that two accounts on each of two different proxy/ registrar servers that do not perform loop-detection are available to the attacker. This assumption is not necessary for the attack, but makes representing (and hopefully understanding) the scenario simpler. The section will close with a discussion of how the attack might be realized with a single account on a single service. Consider two proxy/registrar services, P1 and P2, and four Addresses of Record, a@P1, b@P1, a@P2, and b@P2. Using normal REGISTER requests, establish bindings to these AoRs as follows (non-essential details elided): Lawrence, et al. Expires April 19, 2006 [Page 3] Internet-Draft Max-Forwards Problems October 2005 REGISTER sip:P1 SIP/2.0 To: Contact: , REGISTER sip:P1 SIP/2.0 To: Contact: , REGISTER sip:P2 SIP/2.0 To: Contact: , REGISTER sip:P2 SIP/2.0 To: Contact: , With these bindings in place, introduce an INVITE to any of the four AoRs, say a@P1. This request will fork to two requests handled by P2, which will fork to four requests handled by P1, which will fork to eight messages handled by P2, and so on: | a@P1 / \ / \ / \ / \ a@P2 b@P2 / \ / \ / \ / \ / \ / \ a@P1 b@P1 a@P1 b@P1 / \ / \ / \ / \ a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 /\ /\ /\ /\ /\ /\ /\ /\ . . . Figure 2 Requests will continue to propagate down this tree until Max-Forwards reaches zero. If the endpoint and two proxies involved follow RFC 3261 recommendations, the tree will be 70 rows deep, representing 2^70 requests. The actual number of messages may be much larger if the time to process the entire tree worth of requests is longer than Timer C at either proxy. In this case, a storm of 408s, and/or a storm of CANCELs will also be propagating through the tree along with Lawrence, et al. Expires April 19, 2006 [Page 4] Internet-Draft Max-Forwards Problems October 2005 the INVITEs. Remember that there are only two proxies involved in this scenario - each having to hold the state for all the transactions it sees (at least 2^69 simultaneously active transactions near the end of the scenario). The attack can be simplified to one account at one server if the service can be convinced that contacts with varying attributes (parameters, schemes, embedded headers) are sufficiently distinct, and these parameters are not used as part of AOR comparisons when forwarding a new request. Perhaps: REGISTER sip:P1 SIP/2.0 To: Contact: , 4. The Attack in Practice - Observations from the SIPIT Several participants at SIPIT 17 performed a variation of this scenario during one of the multi-party test sessions. We began with six proxies, each branching to the other 6. Two fell out within minutes. Of the remaining four, two were processing the tree as expected. The other two would occasionally exit and restart. Interestingly, the nature of the message flow through the tree took advantage of these restarting systems whenever they became available. (Please Note: details about specific implementations are not discussed outside the SIPIT - don't ask which proxy was which - the point of this description is to show the fairly wide variation in the implementation base on how proxies react to this scenario). All of the proxies involved put a cap on Max-Forwards of 20. If they receive a request with no Max-Forwards or a Max-Forwards greater than 20, any forwarded request will have a Max-Forwards of 20. It is interesting that the implementation community landed on this value with no apparent specification. The effect of folklore on the implementation base is non-trivial. We allowed the test to run for several hours. Extrapolating from that time, we estimated that the scenario would complete in just under 10 days. Admittedly, these proxies were heavily instrumented for test, so performance may not have been representative of deployed systems. But a system operating 10 times as fast would have taken a full day to process a scenario with a depth of only 2**20. It's almost within reason that these systems might survive the processing and memory requirements of such a scenario. However, if the systems involved use the recommendations in 3261, (and assuming they perform linearly as the state they hold increases), it would take 3 trillion Lawrence, et al. Expires April 19, 2006 [Page 5] Internet-Draft Max-Forwards Problems October 2005 years to play out the results of a single INVITE. 5. Mitigating the Risk Sue the offender : Past discussions of this kind of abuse have been short-circuited with the argument that systems with accounts have logs, and abusers can be punished. For this particular attack, it's not clear this defense is credible. Systems that don't recognize the situation and take corrective/preventative action are likely to fail so badly that records of the setup may be lost. (In the simple scenario, the registrations can occur in a radically different timeframe than the invite. The invite itself may have come from an innocent). It's even possible that the scenario may be set up unintentionally. Furthermore, for some existing deployments, the cost and auditability of an account is simply an email address. Finding someone to punish may be impossible. Finally, there are individuals who will not respond to any threat of punishment, and the effect of even a single instance of this kind of attack will be devastating to a service- provider. Put a smaller cap on Max-Forwards : The effect of the attack is exponential with the entering Max-Forwards value. Turning this value down limits the effect of the attack. This comes at the expense of severely limiting the reach of requests in the network, possibly to the point that existing architectures will begin to fail. For this reason, this path towards mitigation is not recommended. Control the number of requests, not the depth of requests : This is the essence of the proposal in Section 6. The idea is try to bound the total number of requests an initial request can spawn in the network instead of the maximum depth the request could be forwarded to. The tradeoffs of this different design choice are discussed in Section 6. Return to loop-detection : The complexity of loop detection is bounded by the square of the depth of the graph, which is appealing when faced with an exponential alternative. If a proposal like what is in Section 6 is unacceptable, reverting loop detection as specified pre-3261 may be desirable. To avoid the n^2 computational penalty in simple (what we hope are normal) cases, this loop detection behavior might not be initiated until the Via count exceeds a certain threshold. Disallow registration to arbitrary contacts : The way registration currently work is a key part of the success of the kind of attack documented here. The ability to bind to an arbitrary destination may not be a good thing. Instead, we may wish to limit registration bindings to allow only binding to the network element performing the registration, perhaps to the extreme of ignoring Lawrence, et al. Expires April 19, 2006 [Page 6] Internet-Draft Max-Forwards Problems October 2005 bits provided in the Contact in favor of transport artifacts observed in the registration request. The ideas being explored in the sip-outbound draft [outbound] are similar. Deprecate forking : (No, Dean did not put us up to this). This attack does not exist in a system that relies entirely on redirection and initiation of new requests by the original endpoint. Note, however, that per RFC 3261 section 8.3 [RFC3261] it is the responsibility of such an endpoint to detect forwarding loops between redirect servers. Doing so is not as computationally complex for the system as a whole as loop detection at proxies. 6. Limiting Total Hops When Forking  In the face of the scenario described in Section 3, there are cases where the Max-Forwards header does a very poor job of limiting the number of messages on the transport network that are the direct result of the original request. If we consider that a single request is processed by a sequence of proxies, each of which decrement the value in the Max-Forwards header while forwarding the request to exactly one element, we see that Max-Forwards accurately bounds the number of forwards (and hence the number of messages) that are generated as a result of the original request. In cases where there are proxies forking requests en-route to the target UAS, following the suggestions in [RFC3261] for processing the Max-Forwards header result not in an upper bound on total messages or hops, but on network breadth or span. This means that for a typical Max-Forwards value of 70, the number of messages in the network is not seventy, but 2^70, which, absent pathological failures and network load, results in an enormous number of messages being generated from a single original request. This is for the simple case illustrated in Figure 2 where requests fork to two target AoRs for each hop, more fork targets at each hop increase the size of the exponentiated base and result in scenarios that grow much more rapidly. In this environment Max-Forwards is really bounding not the number of forwards, but the depth of a tree containing an arbitrarily large number of forwards. 6.1. Restoring the Meaning of Max-Forwards To ensure that Max-Forwards is directly related to the number of requests that can result from processing a request, the proxy can elect to distribute the value of Max-Forwards between the resulting forked branches. Lawrence, et al. Expires April 19, 2006 [Page 7] Internet-Draft Max-Forwards Problems October 2005 Example of Splitting Max-Forwards Between Two Branches UA 1 Proxy 1 Proxy 2 F1 | INVITE (70) | | |------------->| | F2 | | INVITE (35) | | |------------->| F3 | | INVITE (35) | | |------------->| F1: Message from UA 1 to Proxy 1 INVITE sip:alice@example.com ... Max-Forwards: 70 ... F2: Message from Proxy 1 to Proxy 2 INVITE sip:alice@example.com SIP/2.0 Via: SIP/2.0/TCP 10.1.1.20:59449; branch=z9hG4bK-56ec69968c31f498c9a5573a00c8fc04.0 ... Max-Forwards: 35 ... F3: Message from Proxy 1 to Proxy 2 INVITE sip:alice@example.com SIP/2.0 Via: SIP/2.0/TCP 10.1.1.20:59449; branch=z9hG4bK-56ec69968c31f498c9a5573a00c8fc04.1 ... Max-Forwards: 35 ... Figure 4: Splitting Max-Forwards In general, the proxy would forward a request with original Max- Forwards of M to the N targets, setting the Max-Forwards in the outbound requests to: M --- - 1 if M > N and N > 1 N When 2N >= M >= N, all outbound requests can be set to 1. Lawrence, et al. Expires April 19, 2006 [Page 8] Internet-Draft Max-Forwards Problems October 2005 When N is 1, outbound requests can have Max-Forwards set to M-1. In no case should the sum of all N outgoing Max-Forwards (M_n) exceed the value in the original request (M): j --- \ / M_i <= M --- i=1 Bounding the sum in this fashion ensures that the Max-Forwards number has a direct impact on the number of requests and not just the span of the network that eventually processes the request. In the case where M < N, M/N-1 will be zero. This condition arises when the number of branches the proxy intends to create exceeds Max- Forwards. In this case, the implementation may choose to forward to all branches, setting Max-Forwards to 1. 6.2. Max-Forward Split Weight Selection There are a variety of mechanisms that a proxy might employ to select the weighting of each fork branch, and thus the value to put in the Max-Forwards header on that request. Similarly if a proxy/registrar has full knowledge about the depth of the path to a particular URI (to its own voice-mail servers for example), it might choose to only apportion that much of the remaining hops to that branch. This is a choice that would benefit from discussion in the community. The naive M/N suggestion above may prove adequate, but it is merely a sample mechanism for illustrating a potential solution. 6.3. Limitations and Issues with Splitting Max-Forwards Splitting the value of Max-Forwards using the suggestions in Section 6.1 results in limiting the depth that a request can reach into a network. The resulting maximum depth is now approximately: log ( M ) (or log base q of M) for q>1 q M for q=1 Where q is the mean number of fork branches created at each proxy. This could have implications in networks that rely on a large number Lawrence, et al. Expires April 19, 2006 [Page 9] Internet-Draft Max-Forwards Problems October 2005 of proxies or forwarded requests. If the initial default for Max- Forwards is 70, and a typical branching factor is 2, this bounds the depth of any search to 6. A branching factor of 3 results in a maximum depth of 3. Fortunately, most existing architectures which several proxies in a typical flow only branch at one or two of those proxies. The rest forward to a single location. In this kind of network, the simplistic calculation for apportioning Max-Forwards values yields more useful depths: 17 for a branching factor of 2, 7 for a branching factor of three. 6.4. Parallel and Sequential Forking An modification to the proposed solution would allow a service that branches to one set of contacts in parallel, followed by a separate parallel branch if the first fails to garner a 2xx or 6xx class response to apportion the available hops to each of the two parallel branches independently instead of dividing it among them. This weakens the control over the maximum number of messages generated, but improves the depth that can be reached with each of the parallel searches. This resonates with the typical use case of the first search trying to reach someone for live communication, and the second to reach a messaging system. This weakening might be mitigated by reducing Max-Forwards by one as the proxy proceeds to each new parallel search for a particular request. 7. Diagnosing Hop Limit Exceeded Failures When a request returns a 483 Hop Limit Exceeded response, it can be difficult to determine where the problem lies. In the authors experience, the problem is rarely that the target of the response was actually further away than the Max-Forwards limit allows. The problem is usually incorrect routing; often into a loop. The change suggested in Section 6 will, in effect, often reduce the maximum number of hops a request can traverse; if a request is forked between two alternatives, the "range" of each is (possibly) reduced by half. As this change is deployed, this may cause a temporary increase in the incidence of 483 responses. Lawrence, et al. Expires April 19, 2006 [Page 10] Internet-Draft Max-Forwards Problems October 2005 7.1. Limitations of the 483 Error Response In section 20.22 of RFC 3261 [RFC3261], it says: The Max-Forwards header field must be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. This can also be useful when the client is attempting to trace a request chain that appears to be failing or looping in mid-chain. In practice, there is too little information returned for this to be of much use as a diagnostic. When a request has traversed a series of proxies, the response follows the Vias back to the requester; in the case of a typical 483 response it can be difficult to determine even what server the response came from. Even when the rejecting server does identify itself, it can be difficult to figure out why the request got there. Take a simple example request (all domain names have been changed): INVITE sip:9999@example.com SIP/2.0 Via: SIP/2.0/TCP 10.1.1.20:59449 ;branch=z9hG4bK-56ec69968c31f498c9a5573a00c8fc04 To: sip:9999@example.com From: Sip Send ;tag=08e2f515 Call-ID: 159213b1aa5a67bc6eca6c4c2bad9f94@10.1.1.20 Cseq: 1 INVITE Max-Forwards: 1 User-Agent: sipsend/0.02 Date: Wed, 12 Oct 2005 20:09:29 GMT Content-Length: 0 this request was sent with the Max-Forwards value set to only 1 to force the error response: it should traverse only the first outbound proxy, and then be rejected by the next system that it encounters. Lawrence, et al. Expires April 19, 2006 [Page 11] Internet-Draft Max-Forwards Problems October 2005 The response received in this case was: SIP/2.0 483 Too Many Hops Via: SIP/2.0/TCP 10.1.1.20:59449 ;branch=z9hG4bK-56ec69968c31f498c9a5573a00c8fc04 To: sip:9999@example.com;tag=-1574266585 From: Sip Send ;tag=08e2f515 Call-ID: 159213b1aa5a67bc6eca6c4c2bad9f94@10.1.1.20 Cseq: 1 INVITE Content-Length: 0 There is no indication in the response of what server returned the error. Even with the error only one hop beyond the first proxy, there is no way to determine if that first proxy has routed the request incorrectly. 7.2. Returning Useful Diagnostic Information in 483 Responses In some ways, the Max-Forwards mechanism is analogous to the Time To Live (TTL) field in an IP datagram. The TTL field was originally [RFC0791] intended to be the maximum number of seconds that a datagram should remain in the network. In practice, it has evolved into a hop count, since each system forwarding a datagram was (is) required to decrement the TTL by (at least) one. As an aid to diagnosing problems, the Internet Control Message Protocol [RFC0792] defines a "Time Exceeded Message" to be sent by any system that discards an IP datagram because it was received with a TTL value of zero. The Time Exceeded Message is sent to the source address of the discarded datagram, and includes a field that carries the "Internet Header + 64 bits of Original Data Datagram". This allows the sender to see the datagram as it appeared where it was discarded. The 'traceroute' tool determines the route followed between a given pair of IP addresses by sending a series of IP packets from the source to the destination with gradually increasing TTL values. As each packet reaches its limit, an ICMP Time Exceeded Message is returned by the router that is discarding it, some checks on the route can be made examining how the original packet arrived at each hop. As an aid to diagnosing problems that result in 483 responses, it would be useful to know how the failed request arrived at the rejecting system; both what path it followed to get there, and what the request looked like when it ran out of hops. One way to accomplish this is to return the SIP header of the rejected message to the sender. RFC 3261 (section 7.4) says: "All responses MAY include a body.". RFC 3420 [RFC3420] defines the Content-Type "message/sipfrag" to "allow SIP entities to make assertions about a subset of a SIP message". Lawrence, et al. Expires April 19, 2006 [Page 12] Internet-Draft Max-Forwards Problems October 2005 When sending a 483 response, the response SHOULD be constructed with a message body of type message/sipfrag containing as much as possible of the SIP header from the rejected request. Some systems may not want to expose as much information as is available in a full set of SIP request headers. It is suggested in this case that at least all of the Route and Via headers from the request be returned in the message/sipfrag body. In our example, this would at least enable the end user to determine which proxies were in the routing loop and how the request arrived there. One open source implementation has been generating 483 responses as recommended above for over a year, and have explicitly tested both at SIPit and in production use for any interoperability problems it might cause. Other than implementations that cannot reassemble fragmented UDP packets, none have been observed. We will use this proposed change to diagnose an example routing problem. Here is a request sent to a proxy that implements the suggested content in a 483 response. INVITE sip:9999@interop.pingtel.com SIP/2.0 Via: SIP/2.0/TCP 10.1.1.20:40221 ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f To: sip:9999@interop.pingtel.com From: Sip Send ;tag=612f37e7 Call-ID: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 Cseq: 1 INVITE Max-Forwards: 9 User-Agent: sipsend/0.02 Date: Fri, 14 Oct 2005 15:35:53 GMT Content-Length: 0 The target user '9999' is one that has been deliberately configured to go into a forwarding loop alternating between two addresses (neither of them the original target); a situation that is currently difficult to diagnose. A relatively low Max-Forwards value of 9 was chosen to improve readability. Lawrence, et al. Expires April 19, 2006 [Page 13] Internet-Draft Max-Forwards Problems October 2005 The response received was: SIP/2.0 483 Too many hops From: Sip Send ;tag=612f37e7 To: sip:9999@interop.pingtel.com Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 Cseq: 1 INVITE Via: SIP/2.0/TCP 10.1.1.20:40221 ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f Content-Type: message/sipfrag Content-Length: 1014 Date: Fri, 14 Oct 2005 15:27:47 GMT INVITE sip:InfiniteLoop@interop.pingtel.com SIP/2.0 Record-Route: Via: SIP/2.0/TCP 65.220.123.162 ;branch=z9hG4bK-42e47bba67559bd9a3da1934a70bbc37 Via: SIP/2.0/TCP 65.220.123.162:5080 ;branch=z9hG4bK-50d909f1209f7a820de85c7831846330 Via: SIP/2.0/TCP 65.220.123.162 ;branch=z9hG4bK-994f162bc179fb75093166fabbfd13c7 Via: SIP/2.0/TCP 65.220.123.162:5080 ;branch=z9hG4bK-708842ad6ea22f8fa6e39c503d3d803e Via: SIP/2.0/TCP 65.220.123.162 ;branch=z9hG4bK-50b581a06ca023ebcddbc82c5221149c Via: SIP/2.0/TCP 65.220.123.14:1084 ;branch=z9hG4bK994220327571023745d7996c13560a11.0 Via: SIP/2.0/TCP 65.220.123.14:40221 ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f To: sip:9999@interop.pingtel.com From: Sip Send ;tag=612f37e7 Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 Cseq: 1 INVITE Max-Forwards: 0 User-Agent: sipsend/0.02 Date: Fri, 14 Oct 2005 15:35:53 GMT Content-Length: 0 This response shows what server returned the error; its' address - 65.220.123.162 - is in the topmost Via of the returned request. It also shows that the target URI has been changed to the user 'InfiniteLoop'. Lawrence, et al. Expires April 19, 2006 [Page 14] Internet-Draft Max-Forwards Problems October 2005 Resending the request with a hop limit one less than before (8), shows that at that hop the request URI is to user 'LoopForever': INVITE sip:LoopForever@interop.pingtel.com SIP/2.0 Record-Route: Via: SIP/2.0/TCP 65.220.123.162 ;branch=z9hG4bK-9b7f69455266f7cccd4ae8a285c0417c Via: SIP/2.0/TCP 65.220.123.162:5080 ;branch=z9hG4bK-b9d3e2aff65e68497849a2609bf8c373 Via: SIP/2.0/TCP 65.220.123.162 ;branch=z9hG4bK-a178f4c5a3b8bbf35f979bc6c6d33022 Via: SIP/2.0/TCP 65.220.123.162:5080 ;branch=z9hG4bK-3c098b8d58e4b6ce98fca3495263e795 Via: SIP/2.0/TCP 65.220.123.162 ;branch=z9hG4bK-e7ceb06ed917d59024c905b3ee60e4cc Via: SIP/2.0/TCP 65.220.123.14:1085 ;branch=z9hG4bK8d685f52450e87da45d7996c13560a11.0 Via: SIP/2.0/TCP 65.220.123.14:56114 ;branch=z9hG4bK-4ae5a563b0cbc76aef7be17115836dea To: sip:9999@interop.pingtel.com From: Sip Send ;tag=4f18a30b Call-Id: 39106d45526cb5e78bf8dac378e05817@10.1.1.20 Cseq: 1 INVITE Max-Forwards: 0 User-Agent: sipsend/0.02 Date: Fri, 14 Oct 2005 15:42:21 GMT Content-Length: 0 Route: Reducing the limit one at a time (or starting from 1 and working forward), the sender can determine that the InfiniteLoop/LoopForever forwarding loop exists (in reality, of course, the user names would rarely be such good hints), and where in the forwarding sequence the original '9999' was changed to enter the loop. Without the returned request headers, the 483 response does not help the request originator (or any proxy administrator on the path) diagnose why the error has occurred. With it, in this case a diagnostic application running as a User Agent is able to at least identify what the problem is and in which proxy. 8. IANA Considerations None. Lawrence, et al. Expires April 19, 2006 [Page 15] Internet-Draft Max-Forwards Problems October 2005 9. Security Considerations In that this draft describes a potential denial of service attack on SIP proxies and user agents, and the networks they are on, along with a proposed solution, it is all about security. 10. Acknowledgments Thanks go to the implementors that subjected their code to this scenario and helped analyze the results at SIPIT 17. The discussion around limiting what kind of contact-binding registration can create is motivated by a discussion with Cullen Jennings. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3420] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002. 11.2. Informative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [outbound] Jennings, C., Ed. and R. Mahy, Ed., "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", July 2005. Lawrence, et al. Expires April 19, 2006 [Page 16] Internet-Draft Max-Forwards Problems October 2005 Authors' Addresses Scott Lawrence Pingtel Corp. 400 West Cummings Park Suite 2200 Woburn, MA 01801 USA Phone: +1 781 938 5306 Email: slawrence@pingtel.com Alan Hawrylyshen Ditech Communications Corp. 602 - 11 Ave SW Suite 310 Calgary, Alberta T2R 1J8 Canada Phone: +1 403 561 7313 Email: ahawrylyshen@ditechcom.com Robert Sparks Estacado Systems 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA Email: RjS@nostrum.com Lawrence, et al. Expires April 19, 2006 [Page 17] Internet-Draft Max-Forwards Problems October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lawrence, et al. Expires April 19, 2006 [Page 18]