Subject: [Sip] comments on draft-ietf-sip-fork-loop-fix-01

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 May 2006 00:32:32 -0400

My big comment on this document is, per Robert's most recent note, he is 
suggesting that we clarify the usage of loop detection in this document 
also. He has also suggested proposing an alternative algorithm for this. 
I think we need to see that text ASAP so we can conclude this; This is 
an important document and I hope it doesn't take as long as so many of 
our other ones.

Comments on the current draft:

>     Addressing an Amplification Vulnerability in Forking Proxies
>                     draft-ietf-sip-fork-loop-fix-01

The title should mention SIP somewhere. And spell it out of course.

>                   a@P2  b@P2 a@P2  b@P2  a@P2  b@P2 a@P2  b@P2
>                       /\    /\   /\    /\    /\    /\   /\    /\
>                                           .
>                                           .
>                                           .
> 
>    Figure 2

Figure 2 needs a label and a reference from the text.

> 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>

I don't think it takes any work to convince the service. RFC 3261 says 
that all URI params MUST be removed before looking up in the location 
service. Furthermore, contacts are compared using full URI equality. 
Thus, in a properly implemented proxy the single-account approach will 
always work. You should clarify that.

> When a SIP proxy forks a particular request to more than one
>    destination, it MUST ensure that request is not looping through this
>    proxy. 

"this" could refer to the destination or to itself. Suggest: "..looping 
through itself."

> A
>    proxy is not required to perform loop detection when forwarding a
>    request to a single location even if it previously forked that
>    request in its progression through the network.

Not required to perform it on that particular forwarding operation. It 
still needed to do it previously when it forked.

>  These requirements and the recommendation to use the loop-detection
>    mechanisms from RFC 3261 make the favorable trade of exponential
>    message growth for work that is at worst case order n^2 as a message
>    crosses n proxies.  Specifically, this work is order m*n where m is
>    the number of proxies in the path that fork the request to more than
>    one location.  In practice, m is expected to be small.

You should explain what this work is - checking each of the N via 
headers. You also don't explicitly say that this n^2 work is spread 
across n proxies. Its only N at any particular proxy.  This is important 
because, as I argued at the mike, I think the constant in front of this 
is sufficiently small to be unimportant.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 16 May 2006 08:36:40 +0200

> You should explain what this work is - checking each of the N via headers. 
> You also don't explicitly say that this n^2 work is spread across n 
> proxies. Its only N at any particular proxy.  This is important because, 
> as I argued at the mike, I think the constant in front of this is 
> sufficiently small to be unimportant.
>

I would expect that the bulk of the work is not inspecting the Via headers, 
but rather calculating the digest for distinguishing loops from spirals. And 
you're trading *potential* (typically very rare) exponential message growth 
for *guaranteed* (always, for every forked request) order n^2 work.

So on average, the trade-off might not be "favorable"

Regards,

Jeroen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 May 2006 02:48:39 -0400

inline.

Jeroen van Bemmel wrote:

>> across n proxies. Its only N at any particular proxy.  This is 
>> important because, as I argued at the mike, I think the constant in 
>> front of this is sufficiently small to be unimportant.
>>
> 
> I would expect that the bulk of the work is not inspecting the Via 
> headers, but rather calculating the digest for distinguishing loops from 
> spirals.

Sure. But you only need to do that when there is a loop of any sort. In 
other words, you first check to see if your address is on the Via list. 
Only if its there do you bother to check if it was a loop vs. a spiral.

> And you're trading *potential* (typically very rare) 
> exponential message growth for *guaranteed* (always, for every forked 
> request) order n^2 work.

Well, the huge potential damage from this attack really does require 
this tradeoff. I still don't think the work is that significant. Its 
O(N) on each proxy and I really do think this constant is very small. 
Just the time it takes to find your own address in the Via list.

-Jonathan R.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 16 May 2006 20:55:20 +0200

inline

> Only if its there do you bother to check if it was a loop vs. a spiral.

There are 2 points at which a proxy calculates a digest: upon reception 
(RFC3261 16.3 point 4) and when forwarding (RFC3261 16.6 point 8). You can 
avoid the first when there is no matching via header, and you can avoid the 
second when you already calculated the first, but it will have to be 
performed once for each passage of a request (before translation), 
regardless whether there is a loop or not.

>
>
>> And you're trading *potential* (typically very rare) exponential message 
>> growth for *guaranteed* (always, for every forked request) order n^2 
>> work.
>
> Well, the huge potential damage from this attack really does require this 
> tradeoff. I still don't think the work is that significant. Its O(N) on 
> each proxy and I really do think this constant is very small. Just the 
> time it takes to find your own address in the Via list.
>

It's not that I disagree with the necessity, just that it should be made 
explicit what is being traded-off here

Regards,

jeroen