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
