Subject: RE: [SIP] How to stop a Lawnmower Man attack?

From: Christian Huitema <[email-masked]>
Date: Tue, 18 Jul 2000 12:50:56 -0700

The basic line of defense against DoS attacks is to avoid "packet
multipliers," transactions in which the attacker sends M packets to a 3rd
party, in order to have the 3rd party send N packets to the target. If M<N,
you have a packet multiplier, that will amplify the attack; if M>=N, then
the attacker would have caused more trouble by just sending packets to the
target.

As Mike outlines, out of band signalling mechanism can be used to launch
these attacks. The transaction, for each channel, asks the 3rd party to
"send packets to address X." The problem is compounded in the case of
SIP/SDP by two factors:
1) one can list multiple media lines in a single call, triggering a
multiplication from 1 SDP packet to N media initiations,
2) RTP only includes a very slow handshake mechanism, so that a station can
well start sending many packets before noticing the lack of RTCP in return.
SIP provides a first line of defense through its 3 ways handshake and its
authentication mechanisms. One can record the source of the prank; just
compromising a station may not be enough if the authentication requires
real-time input of some form of secret. In any case, the instrument of the
attack will be dutifully logged, which does provide some possibility of
recourse.

The second line of defense has to be the SIP stacks of the 3rd parties. The
problem here is that sending the media stream to a different address than
the signalling packets ought to be perfectly OK -- I may want to transfer a
call leg, I may want to send the phone call to my stereo box. So one should
not reject a call merely because it involves a different media address.
OTOH, one could turn to a chatty version of the dialogue, to ensure that
there is at least one packet exchanged for each of the media, thus enforcing
M>=N.

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 21 Jul 2000 11:27:56 -0700

Mike,

SIP Proxy Servers correspond to the Gatekeeper function in H.323.  They can 
both provide AAA and perform centralized routing.

thanks,
-rohan

At 10:15 AM 7/21/00 , Fox, Mike wrote:
>Oops I need correct one sentence...
> >> I would like to be clear in that I'm not trying to suggest
> >> that SIP does [ NOT ] support administrative control.
>
> >    I don't see how the protocol itself can help. I can
> >    see pretty simple call gapping measures at proxies,
> >    etc, help though but those don't require any new
> >    protocol mechanisms. Also: a UAS can always insist
> >    that the initial INVITE come through a trusted
> >    proxy rather than directly from the UAC. Assuming
> >    that proxies are more trustworthy because they at
> >    least have some admin behind them, you could limit
> >    the zombie attack as above.
>
>In other words a Gate Keeper. This is my conclusion too, but so far there is
>no GK element proscribed for SIP, why not? Others must have come to a
>different conclusion. The nature of the SIP/SDP will allow many flavors of
>attack. This is not the protocol's problem, but the issue does need to be
>addressed. I have not seen much public discussion in the way of threat
>analysis with regard to these issues from the the SIP comunity. I hope
>somewhere (perhaps ETSI/TIPHON WG 8) someone will give these issues deeper
>consideration.
>
>Best regards,
>Mike
>
>

---

From: [email-masked]
Date: Sun, 23 Jul 2000 19:11:12 -0600

My draft 

http://search.ietf.org/internet-drafts/draft-jfp-sipfw-policy-00.txt 

addresses the administration of certain policies (including
application-layer throttling and similar mechanisms) located at the points
of admission to a network. It is specifically predicated on the idea that a
well-managed SIP network will have rules that characterize the SIP traffic
that traverses particular network edges. Rather than recommending any
additions to the protocol, my draft suggests architectures in which the
deployment of policies in concert with standard firewalls can be modular and
reasonable painless.

I would be interested in hearing feedback regarding the applicability of my
draft to this sort of problem.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Sunday, July 23, 2000 1:32 AM
To: Fox, Mike
Cc: Michael Thomas; [email-masked]
Subject: Re: [SIP] How to stop a Lawnmower Man attack?

"Fox, Mike" wrote:
> no GK element proscribed for SIP, why not?

There is no need to define an additional element, or standardize
interfaces or protocols for it. This role can be played by a proxy. I
suspect, in fact, there are many ingenious ways you can build logic into
a proxy to prevent such attacks - call setup rate thresholds, etc.
Leaving these to the imaginations of implementors as a source of vendor
differentiation, rather than standardizing them in a protocol document,
seems a better way to go. 

That said, I do agree it would be nice to have a document that describes
the threats in a SIP system, with some discussions on protocol
mechanisms that might exist to alleviate them. This would be an
informational document. It was my hope that the security task force
(which has been a bit quiet as of late) would generate such a thing.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com