[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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: <sip:a@P1>
           Contact: <sip:a@P2>, <sip:b@P2>

           REGISTER sip:P1 SIP/2.0
           To: <sip:b@P1>
           Contact: <sip:a@P2>, <sip:b@P2>

           REGISTER sip:P2 SIP/2.0
           To: <sip:a@P2>
           Contact: <sip:a@P1>, <sip:b@P1>

           REGISTER sip:P2 SIP/2.0
           To: <sip:b@P2>
           Contact: <sip:a@P1>, <sip:b@P1>

   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: <sip:a@P1>
   Contact: <sip:a@P1;unknown-param=whack>,<sip:a@P1;unknown-param=thud>



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

   &#65279; 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 <sip:sipsend@10.1.1.20>;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 <sip:sipsend@10.1.1.20>;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 <sip:sipsend@10.1.1.20>;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 <sip:sipsend@10.1.1.20>;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: <sip:65.220.123.162:5080
        ;lr;a;t=612f37e7;s=96e09e8e8c93a8c60bf460029847f4b1>
   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 <sip:sipsend@10.1.1.20>;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: <sip:65.220.123.162:5080
        ;lr;a;t=4f18a30b;s=a9711e1704ccd5273955589c5fe94745>
   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 <sip:sipsend@10.1.1.20>;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: <sip:65.220.123.162:5070;transport=tcp;lr>


   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]