I don't like elephants.

There has been a great big elephant sitting in SIP that no one has wanted to talk about, for a long time.  Problem is, I don't like elephants.  They scare me.

People that are not intimate with SIP seem most surprised that a publicly accessible SIP server can commonly be used as an amplifier in a reflected denial of service attack.  They shouldn't be.  It's been like that forever.

So after years of ignoring the elephant in the room, i've tried to start tackling it, and have submitted some discussion on the matter along with an potential solution draft-zourzouvillys-sip-via-cookie-00.

It's not a complete solution to address all of the issues, but it brings UDP in line with stream based (and DTLS) transports so we can build a solution on top of this which mitigates the issues with in-dialog initiated attacks and RTP steering.

I AM THE SCARE MONGER, AND I BRING YOU ..... SCARES!

Until the problem this draft is trying to solve is fixed, any publicly accessible SIP server listening on UDP can likely be used as a amplifier in a reflected denial of service attack.  And that's bad, for all of us on the internet, not just the SIP world.  It means a SIP server can be used by an attacker as to amplify an attack against non-SIP infrastructure - that could be a web server, router, DNS server, or anything else an attacker so chooses.

By amplifier, we're talking one spoofed UDP request sent by an attacker resulting in 11 UDP responses sent to the victim (combined with other attacks, the pathological case results in ~35 UDP packets being sent to the victim from a single one by the attacker, along with a significant number of RTP packets).  Neither the victim nor the attacker need to have an account with the SI P server ("SIP server", for example, could be an asterisk install or just a bog standard SIP phone) - it just needs to be accessible and process requests statefully (and most do).

Ohh, and because it's UDP, it's not possible to trace the attacker, meaning we can't even find them and shut them down. woo.

Outlook

In the longer term, we've still got a few other elephants that need talking about: RTP target verification and Contact/Route validation for dialog creation are just two that can currently be abused for some potentially similarly scary attacks, and need to be solved rather than ignored.

Note that none of this is new.  This kind of feels like DNS all over again :-)

ho hum.