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

Hi Theo,

Am 20.02.2009 5:20 Uhr, schrieb Theo Zourzouvillys:
> I've just submitted an ID that discusses the inherent UDP "problem",
> along with a potential workaround to stop it being used maliciously.
>
> I would really welcome any feedback:
>
>    http://www.ietf.org/internet-drafts/draft-zourzouvillys-sip-via-cookie-00.txt

in general I like your proposal, but I have a few questions/thoughts:

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

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?

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?
To be backward compatible it would need to accept requests without the 
extension, but then the door is open for the attacker again.
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.

As I said I like the general idea. But I believe that the attack 
scenario which you describe in your draft should be a little bit more 
narrow then described.

Best regards
   Nils Ohlmeier
_______________________________________________
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