Internet DRAFT - draft-lawrence-maxforward-problems
draft-lawrence-maxforward-problems
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
 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]
