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? Or service providers who want to accept calls from "the internet" through an SBC? These are vulnerable, are they not? ... i'm not worried about an amplification risk with a user that can be authenticaticated: the 401/407 can be sent statelessly, meaning only a very small amplification ratio and only 1:1 packets. (although note that most UAs and proxies i tested did not currently send them statelessly and instead created a IST for them along with them and fire timer G!) - i imagine a well designed SBC would perform differently, although i didn't happen to have a well designed SBC from a certain vendor available for testing, so couldn't say :-) > In typical deployments the request will be challenged, so the amplification >is the 100 and 401/407 challenges 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. > not a full call's worth of 18x/200 and RTP. bear in mind the via-cookie doesn't stop the in-dialog/rtp targeting, but it does mean that it's traceable, and thus "manageable" once a solution like via-cookie is in place. I think work needs to be done on that issue too, but it's no where near as risky as this issue is. > SBCs can and often do throttle the number of requests they'll accept in any > time period from any given UA. So they won't flood the target UA with bogus > responses, because they won't accept that many spoofed requests from it to > begin with - for some vendors they have hardware that will silently drop the > excess. 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. > What will sometimes happen is the SBC will dynamically black-list a flooding > UA, so that if you successfully spoof one you can knock it out of service > anyway, for a period of time. Of course this triggers traps to notify the > admins to look into it, but at least temporarily the damage is done. But > that's by design - if you're successfully spoofing another UA, then the best > an SBC can do is limit the impact of that to affect only the spoofed UA and > not impact other users. ... 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. > BTW, we do recommend to providers that they employ uRPF on their edge > routers, and some can and do. absolutely. over time we've got to the point where *most* UK SPs worth their salt are doing RPF, but .... > Others don't have that ability or don't own the whole network, or don't want >to take the performance impact of doing it on their routers. (because many >routers take a hit for uRPF) It's partially loosing battle trying to get service providers to do it (~6 years years ago i went on a rampage to try and get UK ISPs to do it - some did, most didn't. thankfully most have since then, though), and while it is important (it makes bot nets lifes harder) in the global scheme of things, as you say many don't - and it only takes one to have a problem. Even if everyone did RPF at the access layer, it doesn't stop attackers. They just become service providers themself (this is what spammers have done as thigns got more difficult for them). You don't even need to inject a prefix into global routing tables: simply transmitting the packets is all it takes, and won't even be traceable. There are bunches of issues at IXs as well: there is no way ports can be L3 filtered there currently. The SIDR WG is trying to find solutions to some this, but it's a long way off becoming reality imo. ~ Theo 1 - completely random guess from my (72k * 100). _______________________________________________ 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
