[VOIPSEC] Actual Attacks
br at brianrosen.net
Sat Mar 12 18:54:44 GMT 2005
Since there are no protocol police, you are free to break end to end
connectivity if you wish. If you think that you can determine what are
acceptable messages that pass your B2BUA and your customers are happy with
your choices (meaning whatever capabilities of their endpoints don't work
because of your meddling doesn't annoy them enough to switch to service
providers that don't break their apps), please go right ahead.
You might ask what the marginal cost of carrying messages between endpoints
is, what free alternatives there are to users exchanging the same
information via HTTP, or IM or email, and ask, "what is it, exactly, that
you are protecting?"
You are applying a 30 year old mindset to another world, where your
assumptions (like passing bits between endpoints is "theft of service") no
longer hold true.
Right now there are two classes of VoIP service providers out there. Those
that think people will pay for things like QoS, and rigid signaling
constraints, and limited services that take millions of dollars and years to
deploy, vs carriers that offer straightforward connectivity, at a lower
price, with services new services rolled out nationwide over a weekend.
Time will tell if consumers value former over the latter.
Consider a simple VoIP provider who deploys a proxy server/registrar on a
hardened Linux platform with a single stage routing engine, a low cost
gateway, a simple minded billing system and a media server vs a typical old
style carrier network that has separate registrars, call servers,
applications servers, SBCs, ...
The cost for the first customer for the former, simpler system is around
100X less than the cost of the first customer for the latter, "protected"
system. It's around $1M vs around $100M for a nationwide rollout. The
marginal cost of adding the millionth customer to the simple system is
around 2-3X less than the marginal cost of adding the millionth customer to
the complex system. So far, the breadth of applications available favors
the simpler system because the cost to apps providers is 1/3 to 1/10 the
cost to deploy.
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Geoff Devine
> Sent: Thursday, March 03, 2005 11:02 AM
> To: Ari Takanen
> Cc: Voipsec at voipsa.org
> Subject: RE: [VOIPSEC] Actual Attacks
> Ari Takanen writes:
> > Any and every protocol has always enough freedom in the headers
> > and content that you can even implement tunnelling protocols
> > using them. Passing information like real IP addresses is just
> > the beginning. I am sure someone will implement IP-over-SDP-s-field
> > when the evildoers notice that SIP is open in all firewalls from
> > anywhere to anywhere. This is what happened to every protocol
> > that has been granted access through firewalls. There is not
> > much you can do to avoid this, is there?
> I cite ISDN as an example of a protocol where this is typically
> operationally impossible. The Q.931 spec defines an object called
> User-User Information that is the catch-all for passing opaque
> information from end to end. It turned out that in real world
> deployments, people were using this feature to steal service and
> operators disabled passing the object through. Australia had the worst
> problem. Users started using User-User-Info in SETUP messages as an IP
> datagram transport and the flood of call setup messages ended up
> bringing down their network. Basic Rate ISDN endpoints were, in
> essence, mounting a distributed denial of service attack against the
> signaling network.
> In the SIP environment, if you implement a Back 2 Back User Agent model
> where an intelligence in the middle of the network has policy to only
> allow signaling content it understands; and if you anonymize the
> endpoints so they can't communicate to each other directly, you can
> prevent these kinds of tunneling protocols and theft of service via
> Voipsec mailing list
> Voipsec at voipsa.org
More information about the Voipsec