Subject: [Sip] I-D ACTION:draft-ietf-sip-fork-loop-fix-03.txt

From: [email-masked]
Date: Thu, 07 Sep 2006 18:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies
	Author(s)	: R. Sparks, et al.
	Filename	: draft-ietf-sip-fork-loop-fix-03.txt
	Pages		: 13
	Date		: 2006-9-7
	
This document normatively updates RFC 3261, the Session Initiation
Protocol (SIP), to address a security vulnerability identified in SIP
proxy behavior.  This vulnerability enables an attack against SIP
networks where a small number of legitimate, even authorized, SIP
requests can stimulate massive amounts of proxy-to-proxy traffic.

This document strengthens loop-detection requirements on SIP proxies
when they fork requests (that is, forward a request to more than one
destination).  It also corrects and clarifies the description of the
loop-detection algorithm such proxies are required to implement.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-fix-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sip-fork-loop-fix-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-fork-loop-fix-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Sun, 10 Sep 2006 22:54:07 -0400

I'm wondering why we would recommend a cryptographic hash function.  
I'm also wondering why it needs to be as large as 128 bits.

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 11 Sep 2006 17:52:13 +0100

----- Original Message From: "Cullen Jennings"

> I'm wondering why we would recommend a cryptographic hash function.  I'm 
> also wondering why it needs to be as large as 128 bits.

Hi Cullen,

I raised a similar question a while back 
(http://www1.ietf.org/mail-archive/web/sip/current/msg15133.html . 
Unfortunately I can't find Robert's reply in the archives.)

I think 06 8:01 AM
Subject: Re: [Sip] loop fix

> Juha,
>
> Loop detection currently works the way it does to accomodate stateless 
> proxies. It is the least common denominator; it will also work for 
> stateful proxies, so there is no need to define separate mechanisms to 
> achieve the same goal. That is a benefit
>
> It is true that you can also detect loops by searching through existing 
> state, with the aforementioned drawbacks that it won't work as well across 
> reboots (I consider the performance of the lookup an implementation issue, 
> it can be made efficient).
>
> For the forking scenario, the proxy must by definition be stateful. So one 
> could use a lookup through existing state as a way to do loop detection. 
> There is nothing in the draft that prevents this - hashing is RECOMMENDED, 
> but nothing says you can't do it your way. In fact, loop detection is a 
> completely local feature - a proxy only has to recognise its own detection 
> mechanism. So as long as it keeps to standard RFC3261 syntax, there is not 
> actually a need to standardize any particular mechanism - just stating 
> that it MUST do loop detection is sufficient.
>
> What I personally don't like about the recommended mechanism, is the 
> overloading of Via branches for both transaction id and loop detection. 
> IMHO a much better solution is to separate the two; I personally use
>
> Via: SIP/2.0/UDP host:port;branch=z9h....;ld={loop hash}
>
> And it would be nice if there were some way to detect if some proxy is 
> doing loop detection or not. A separate parameter achieves this
>
> Regards,
>
> Jeroen
>
> ----- Original Message ----- 
> From: "Theo Zourzouvillys" <[email-masked]>
> To: "Juha Heinanen" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, September 11, 2006 6:36 AM
> Subject: Re: [Sip] loop fix
>
>
> On Sunday 10 September 2006 16:13, Juha Heinanen <[email-masked]> wrote:
>
>> > (1) speed - if you have a large number of active transactions, then 
>> > it's
>> > almost certainly a lot faster to construct and compare a hash in X
>> > number of via headers than search all the transactions received on
>> > that particular transport.
>>
>> in some implementations this is true. if it is not true in all
>> implementations, then the i-d should not give one SHOULD implementation
>> solution.
>
> As it is SHOULD (aka 'RECOMMENDED'), you have the flexibility of doing it 
> in
> other ways if your particular situation requires it - but as most 'common'
> implementations will worry about the things listed here, then SHOULD is 
> the
> right force for it in my opinion, as there are (as per rfc2119) "valid
> reasons in particular circumstances to ignore a particular item, but the 
> full
> implications must be understood and carefully weighed before choosing a
> different course."
>
>> > (2) resilience - a crashed proxy would still be able to perform loop
>> > detection, even after loosing all of it's state - assuming it keeps
>> > transactions in memory and not committed elsewhere before forwarding;
>>
>> this i don't quite understand. even if proxy looses all state, doesn't
>> it rebuild that state next time it receives the looped request again and
>> will detect the loop during the following round?
>
> Only after it looped again after crashing, and that assumes it's not 
> already
> crashed again since.  Given that the attack vector that the I-D is trying 
> to
> fix, i think it is sensible for it to catch a loop between crashes of an
> element, too.
>
> fork-loop-fix-03, 3.  Vulnerability: Leveraging Forking to Flood a 
> Network:
>
>   [...]
>   It is interesting to note that a few proxies rebooted during
>   the scenario, and rejoined in the attack when they restarted (as long
>   as they maintained registration state across reboots).  This points
>   out that if this attack were launched on the Internet at large, it
>   might require coordination among all the affected elements to stop
>   it.
>
>> > (3) scalability - loop may go through different proxies when load
>> > balancing. KEeping the hash in the via header allows peer pI then clarified off line with:

On Jul 6, 2006, at 1:28 PM, Pete Cordell wrote:

> Just to make sure I'm not talking a cross-purposes, the reference  to 
> cryptographic hashes I'm talking about is in 4.2.3.-
>
>   A common way to create the second part of the branch parameter value
>   when forking a request is to compute a cryptographic hash...
>
> I appreciate this has no normative value, but implies that  cryptographic 
> strength is recommended.
>
> Maybe just removing the word "cryptographic" is the right to do?  I 
> suppose the last sentence in that paragraph could go along the  lines of:
>
>     ...An MD5 [RFC1321] hash expressed in hexadecimal (base64
>   is not permissible for a token) is a reasonable choice of a hash
>   function, although other (non-cryptographic) hashes may suffice.

which Robert seemed to think this was reasonable.

As to the size of the hash, what size do you think is big enough?  Assuming 
the hash is working properly, even 16 bits is approaching five 9s territory 
for false positives.  Is there any reason why that's too simplistic a way to 
look at it?  I imagine 32-bits would be easy for most people to implement, 
and a logical size to choose as far as I can tell.  Should this be left as 
an implementation issue?

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
                         for XML to C++ data binding visit
                         http://www.tech-know-ware.com/lmx
                         (or http://www.xml2cpp.com)
=============================================

roxies to
>> > detect and stop looped requests quicker than it would otherwise.
>>
>> this is not a valid reason, since if there are multiple proxies, they
>> may be from different vendors and since there is no standardized way to
>> calculate and add the hash into via header, one proxy cannot interpret
>> the via header added by another proxy.
>
> indeed, with multiple vendors.  but none the less, it's a reason a proxy 
> may
> want to use Via hashes rather than internally (which is what you asked).
>
> ~ Theo
>
> -- 
> Theo P. Zourzouvillys
> http://www.crazygreek.co.uk
> [email-masked]
>

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 11 Sep 2006 17:52:13 +0100

Hi Cullen,

I think I then clarified off line with:

Pete.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 13 Sep 2006 23:02:42 -0500

I really thought I addressed your comment in the draft, Pete.

The word cryptographic appears exactly once in the current text, and  
it's in a section that the RFC editor will
delete before publishing. For convenience, here's where it occurs (in  
the Change-Log section):

> 9.1.  -02 to -03
<snip>
>
>       Removed the word "cryptographic" from the hash description in  
> the
>       non-normative note to implementers (per list discussion) and  
> added
>       characterization of the properties the hash chosen should have.

RjS

On Sep 11, 2006, at 11:52 AM, Pete Cordell wrote:

>> I'm wondering why we would recommend a cryptographic hash  
>> function.  I'm also wondering why it needs to be as large as 128  
>> bits.
>
> Hi Cullen,
>
> I raised a similar question a while back (http://www1.ietf.org/mail- 
> archive/web/sip/current/msg15133.html . Unfortunately I can't find  
> Robert's reply in the archives.)
>
>> Just to make sure I'm not talking a cross-purposes, the reference   
>> to cryptographic hashes I'm talking about is in 4.2.3.-
>>
>> I appreciate this has no normative value, but implies that   
>> cryptographic strength is recommended.
>>
>> Maybe just removing the word "cryptographic" is the right to do?   
>> I suppose the last sentence in that paragraph could go along the   
>> lines of:
>>
> As to the size of the hash, what size do you think is big enough?   
> Assuming the hash is working properly, even 16 bits is approaching  
> five 9s territory for false positives.  Is there any reason why  
> that's too simplistic a way to look at it?  I imagine 32-bits would  
> be easy for most people to implement, and a logical size to choose  
> as far as I can tell.  Should this be left as an implementation issue?
>
> Pete.
> --

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 14 Sep 2006 09:35:13 +0100

Hi Robert,

I'd actually missed the fact that you'd updated the draft and was really 
commenting on changes proposed to -02.

That said, I am of the opinion at the moment that recommending a 128-bit 
hash is overkill.  If due to poor distribution, the hash function works a 
tenth as well as the bit count suggests even a 32 bit hash will result in a 
false clash once in 400 million times.  My expectation is that the loop vs. 
spiral decision will only have to be made on a small minority of calls as 
well (figure out of the air - 1 in 50 maybe!).  So that would be a 1 in 20 
billion failure rate, which would seem OK to me.

I suppose one issue is that if you do happen to be the 20 billionth person 
trying to make such a call, then your call will fail every time, which may 
be a bad effect.

Pete.

----- Original Message ----- 
From: "Robert Sparks" <[email-masked]>
To: "Pete Cordell" <[email-masked]>
Cc: "Cullen Jennings" <[email-masked]>; "SIP" <[email-masked]>
Sent: Thursday, September 14, 2006 5:02 AM
Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03

> The word cryptographic appears exactly once in the current text, and  it's 
> in a section that the RFC editor will
> delete before publishing. For convenience, here's where it occurs (in  the 
> Change-Log section):
>
>> 9.1.  -02 to -03
>>
> <snip>
>>
>>       Removed the word "cryptographic" from the hash description in  the
>>       non-normative note to implementers (per list discussion) and  added
>> Assuming the hash is working properly, even 16 bits is approaching  five 
>> 9s territory for false positives.  Is there any reason why  that's too 
>> simplistic a way to look at it?  I imagine 32-bits would  be easy for 
>> most people to implement, and a logical size to choose  as far as I can 
>> tell.  Should this be left as an implementation issue?
>>
>> Pete.
>> --