Re: SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01)

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 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 protected]>
> 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
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip