Re: draft-zourzouvillys-sip-via-cookie-00

Hi Theo,

Am 20.02.2009 16:36 Uhr, schrieb Theo Zourzouvillys:
> On Fri, Feb 20, 2009 at 9:46 AM, Nils Ohlmeier<[email protected]>  wrote:
>> I think the whole "attack scenario" which is described in the draft works
>> only if the attacker uses the proxy/registrar of the victim as a relay.
>> Reason 1): because the attacker hopefully does not know which UDP port of
>> the victim is currently "open" to accept incoming UDP packets. And if their
>> is a NAT or firewall in between the UA it will hopefully only accept UDP
>> packets from the proxy/registrar. If the UA of the victim runs on a public
>> IP without any "protection" it might accept SIP requests from anywhere,
>> although I would call this a very bad UA implementation.
>
> A victim does not need to have an open UDP port;  An attack can easily
> be launched against any IP address, even a non SIP related one.

Yes, similar to the DNS server aplimifaction attacs which are going on 
right now. I think should you should spend an extra section on the 
scenario to seperate it from the pure SIP scenario.

> A device behind NAT on the end of a link additionally has no
> protection at an IP level, as the link would easily become saturated
> as a reflector starts sending failure response retransmits from a IST
> every time timerG fires.

Ok, I fear a shortage of you draft caused some confusion here:
IMHO you should differentiate between the attacker, the amplifier and 
the victim.
I was referring here to a UAC behind a NAT being the amplifier. You 
seemed to refer to the real victim here.

With this said I think it would be good if you seperate in your draft 
between UA aplimifers and proxy amplifiers, because they result in 
different traffic numbers if I'm not wrong.

Thus my original though was and still is, that it is most likely easier 
to mis-use any SIP proxy as amplifier. But a proxy will most likely 
"only" re-send any error response 11 times to the victim.
I still believe a UAC should be harder to mis-use as an amplifier (see 
original reasons 1 and 2).

>> Reason 2): when the UA of the victim registeres itself it provides a Contact
>> URI. I general I believe UA should only accept incoming requests from their
>> registrar IP and port which contains the Contact URI which they provided at
>> the registration. This prevents very easily that someone sends drive by
>> requests just with the AOR of the victim as R-URI to the UA of the victim.
>> If a registrar forwards requests to registered UAs with the AOR of the user
>> in the R-URI the registrar is broken in my opinion.
>
> as above - a victim does not need to be a SIP UA - it doesn't even
> need to talk SIP.  The attacker may well be trying to attack a non SIP
> entity, for example a web, DNS, or mail server.
>
> On the flip side, a UA that "only accept"s requests from it's
> registrar if of course good practice, but is only a step in stopping
> SPIT, not denial of service (which this draft tries to tackle), unless
> the "only accept" is limited by routability.  Note even NAT doesn't
> stop a denial of service attack being launched against the NAT
> gateway, causing it's connectivity to become saturated.

See above.
As a victim it makes for sure no difference under which criterias a SIP 
implementation (if it speeks SIP at all) accepts messages. But as an 
amplifier it might make a difference. E.g. if the UA rejects the spoofed 
INVITE with a 305 Use Proxy (although this reply is ambigious), the 
victim will receive only 11 replies within 32 seconds. But if the UA 
accepts the INVITE and starts to ring, and the user accepts... your 
worst case scenario comes into play.

> This draft is specifically trying to stopping a SIP server transaction
> being used as an amplifying reflector in a (distributed) denial of
> service attack.  The victim of the attack does not need to be a SIP
> endpoint (it doesn't even need to have any ports open!)
>
>> Now the question is of the proxy/registrar accepts requests from its users
>> from anywhere. I guess that is what you mean with no authentication, right?
>
> Yes - any SIP server (note a UAS or proxy are both servers for this)
> which allows an unauthenticated, untrusted user to create an invite
> server transaction (even for failure delivery) is vulnerable.

Agreed. Although a failed server transaction results in a lot less harm 
then an accepted call. Maybe some calculations about the amount of bytes 
would be helpfull here.

>> One bigger concern for the whole approach is: if the attacker knows about
>> this cookie extension he will for sure not put an empty cookie in the Via
>> header of the request. But how does the proxy of the victim handle requests
>> without the cookie extension?
>
> Any proxy that does wish to be used as an amplifier should reject
> requests without cookies with a stateless 4XX, or send a stateless
> 401/407 if knows it can authenticate it's user.
>
> Of course this is not going to be realistic from day 1, but this
> document is a start in finding solutions to some of the DOS problems
> we're currently susceptible to by putting a SIP server "on the net".
>
> Right now, there are a large number of SIP endpoints out there that
> will amplify a single UDP packet sent to them, and the initiator of
> the attack isn't even traceable!

Yep. Like with this DNS amplification attack here:
http://isc.sans.org/diary.html?storyid=5713

(And that only uses the amplification of bytes from a 1:1 
request:response transaction... SIP is worse.)

> (i'm starting to sound like a scaremonger, so i'll stop now :))
>
>> If the proxy of the victim does not care about backward compatibility (maybe
>> because attack previntion is more important), wouldn't the need a way to
>> tell the sender of the request that the cookie extension is required to
>> successfully relay requests? So wouldn't we need a new value for the
>> Required header, or would a new 4XX response already be enough.
>
> I did briefly consider an option tag but the problem is a SIP UA does
> not need to implement anything for it to potentially work - for
> example a proxy can implement it on behalf of a group of trusted users
> (for example, a corporate proxy or an outbound proxy that has
> authenticated the inbound request).
>
> There would additionally be no mechanism for recovery if the server
> refuses to process UDP requests without cookie support.  The 4XX would
> provide a code that allows a machine to understand that it failed due
> to cookies (if it knew about, but didn't implement the extension) -
> and could for example try upgrading to TCP, [D]TLS etc.  The reason
> phrase provides something descriptive for devices that don't
> understand it.  For those that don't, it'll fall back to treating it
> like a 400.

Ok, accepted.

Cheers
   Nils
_______________________________________________
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