On Fri, Feb 20, 2009 at 9:46 AM, Nils Ohlmeier <[email protected]> wrote:
Hi Nils, Thanks for the feedback - i'll elaborate to make the issues you raised more clear in the next version of the document. > 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. 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. > 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. 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. > 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! (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. ~ Theo _______________________________________________ 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
