> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Theo Zourzouvillys > Sent: Sunday, February 22, 2009 3:33 PM > > On Sun, Feb 22, 2009 at 4:19 PM, Hadriel Kaplan <[email protected]> > wrote: > > > SBCs can be and almost always are configured to only accept requests > from registered UA's. > > What about an SBC that is configured at the edge of a network, for > example the thing that is the target of the URIs placed into ENUM?
Yup, these are essentially the same as IP-PBX trunks. I don't know of many that allow requests in from truly unknown sources, though - they usually know the remote devices in advance, even when ENUM is used - so if they wanted to they could use IPSec or TLS if this became a problem. (some do today, but many don't - it seems many peer over private connections anyway) > Or > service providers who want to accept calls from "the internet" through > an SBC? These are vulnerable, are they not? Yup, but for those we strongly recommend IPsec, TLS, or even just TCP, where at least syncookies stops the trivial stuff. Essentially what you're proposing seems to me similar in concept to syncookies, but at the next layer up. > are there ever any reasons for an SBC to not send the 401/407 > statelessly, and even send a 100? A 1:2 attack is still bad, albeit a > far cry from the pathological case. Nope there's no reason I know of, but it's rare to do that. Usually it's the registrar or some core device which sends the 401/407, so the SBC sends a 100 to stop the UA from retransmitting. I have tried to convince people to let the SBC do it, but it hasn't gotten that much interest. (despite the fact it has more benefits than just this one issue) > Having a single SIP element doing rate limiting doesn't matter though > when there are 7.2 million SIP devices on the net [1]. If each one > will allow a 1:10 amplification, that's all a botnet needs to make it > 10 times more valuable. Hell, even a 1:2 amplification is worth it > for them, especially as it's reflected. Your point is that botnets can take advantage of the SBC's to amplify their attacks on other UA's, right? But to do that they have to know the URI's/IP:port's of the other UA's they want to attack indirectly, and at that point why bother attacking via the SBC - just attack the UA's directly, spoofing other UA's, or spoofing the SBC's, or even not spoofing. I mean it's a botnet, so you have enough resources to cause a resource exhaustion attack on any UA's, and who cares if they can trace it? > ... cookies solves this particular attack though, doesn't it? > (although authentication does as well in this scenario due to a > nonce?), in the same way a syncookie does for the SYN flooding > problems of decades gone by. Yup, either cookie or auth would solve it, but my guess is we'd still want to blacklist if it's more than a short-lived event. That's what happens now: you get some leeway for a short while, but eventually you get kicked out for a longer period of time, because as far as we know you've got a broken UA or someone's learned your info, and we can't let you affect the overall network. -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
