Subject: Re: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01)

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 1 Mar 2009 22:22:01 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Theo Zourzouvillys
> Sent: Monday, February 23, 2009 5:49 AM
>
> On Sun, Feb 22, 2009 at 11:55 PM, Hadriel Kaplan <[email-masked]>
> wrote:
>
> > Essentially what you're proposing seems to me similar in concept to
> syncookies, but at the next layer up.
>
> yeah, it is - in fact probably why i subconsciously called them via
> cookies :-)

So if the protection mechanism involved requires a change on the proxy and a change on the UA's, to do the via-cookie mechanism, then why do the change so high in the SIP stack?  I mean essentially what you'd want is a *really* efficient response/check mechanism, before even parsing the message (or parsing it enough to create a legal 4xx response).

One way to do that would be to create a fixed-length, binary header as the first N bytes of the UDP payload, to carry the support indication and the challenge and challenge-response.  You could even treat this as a shim-layer between UDP and the SIP message layer (and below sigcomp if it's there).  That way the client side also doesn't have to process the cookie challenge at its SIP layer either, because the retransmission with the challenge response is done by the shim layer.  And of course a fixed-length header send-able in the SIP port somewhat already exists: STUN.

Obviously in a way you're really just re-creating TCP or SCTP in that regard, but that's what the via-cookie is doing anyway, just at a higher layer.

-hadriel

---

From: Theo Zourzouvillys <[email-masked]>
Date: Mon, 2 Mar 2009 10:08:49 +0000

On Mon, Mar 2, 2009 at 3:22 AM, Hadriel Kaplan <[email-masked]> wrote:

Hi Hadriel,

> So if the protection mechanism involved requires a change on the proxy and a change on the UA's, to do the via-cookie mechanism, then why do the change so high in the SIP stack?

only for adoption reasons:

First, It seemed to big a change to push and in reality get adopted in
the "short" term by people as any other lower change requires more
than just a few lines of code for people that want to implement it
without caring about performance (for example, a SIP phone or
something else that is not worried about high performance).  DCCP
offers the same features at a level already implemented by most major
operating systems, as does DTLS - so we could use either of those and
the problem goes away, too with potentially less complexity for
implementers (at least in the DCCP case).

Second, there are already a scary number of ALGs on DSL/cable routers
and deployed out there - any non 3261 compliant method would likely
require many of those be updated as well, although with all the SIP
diagnostic tools like ethereal/wireshark and monitoring etc.

 ~ Theo