Subject: RE: [SIP] T2 and 182 Queued

From: Igor Slepchin <[email-masked]>
Date: Thu, 25 Jan 2001 00:12:09 -0500

1. If the UAC is gone, the UAS will get an ICMP error on the second
retransmission of 182 and is free to drop the call after that.
2. Whether UAS queues up messages for 10 or 100 minutes is not very
relevant; a DOS attack just requires somewhat less resources in the first
case than in the second. There is nothing SIP-specific in attacks that flood
the service provider with bogus messages.

---
Igor Slepchin

> -----Original Message-----
> From: David Frascone [mailto:[email-masked]]
> Sent: Wednesday, January 24, 2001 1:11 PM
> To: [email-masked]
> Subject: Re: [SIP] T2 and 182 Queued
> 
> 
> This bounced when Pat tried to send it, so I'm forwarding it.  
> 
> ----- Forwarded message from Pat Calhoun <[email-masked]> -----
> 
> Date: Wed, 24 Jan 2001 09:15:44 -0800 (PST)
> From: Pat Calhoun <[email-masked]>
> Reply-To: Pat Calhoun <[email-masked]>
> Subject: Re: [SIP] T2 and 182 Queued
> To: David Frascone <[email-masked]>
> Cc: [email-masked]
> Message-ID: <Roam.SIMC.2.0.6.980356544.32567.pcalhoun@nasnfs>
> 
> > 
> > Everything is happy above.  But, what about this:
> > 
> > 
> >     UA1                             UA2
> >      |                               |
> >      |             INVITE            |
> >      |------------------------------>|
> >      |                               |
> >      |      182 Queue Position 120   |
> >      |<------------------------------|
> >      |                               |
> >    Here, the UA1 pulls the plug on his computer, drives 
> into a tunnel,
> >    has a power outage, ISP drops the connection, etc.  No 
> cancel, just
> >    vanishes.
> > 
> >      |      182 Queue Position 110   |
> >      |<------------------------------|
> >      |                               |
> >      |      182 Queue Position 100   |
> >      |<------------------------------|
> >      |                               |
> >      |      182 Queue Position 1     |
> >      |<------------------------------|
> >      |                               |
> >      |            200 OK F4          |
> >      |<------------------------------|
> >      |                               |
> >      |   UA2 Timer FINALLY times out |
> >      |                               |
> >     UA1                             UA2
> > 
> > 
> > So, the UA keeps him in the queue, spitting out UDP packets 
> for a LONG
> > time, without ever knowing that UA1 is no longer on the 
> network.  So, if
> > T2 *is* used, the timeout is way too short.  If T2 is NOT 
> used, then there
> > is an big waste of retransmissions for queued calls.  
> Perhaps PRACK should be
> > required for long queue times?  There might even be a DOS 
> attack by forging
> > tons of INVITES to a full queue.
> > 
> > Now do you see the problem?  
> 
> Putting aside the obvious case of wasted resources, I think 
> that the potential
> for denial of service attacks is THE reason why this is 
> broken. Imagine
> competitor A issuing a UDP based IP address spoofing attack 
> on competitor B,
> filling up their call queues. With the number of calls, the 
> queue will quickly
> fill up, so I believe it is a MUST that the 182 messages be 
> ack'ed, to reduce
> the queue size. This should be a MUST, regardless of the wait time.
> 
> I think that proofing against DoS attacks should be a high 
> priority item for
> the WG.
> 
> PatC
> 
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to [email-masked] with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 25 Jan 2001 10:20:32 -0500

> retransmission of 182 and is free to drop the call after that.

This works unless the responses are directed to port 9 on some
unsuspecting target. That way, every incoming INVITE generates a bunch
of packets directed at the victim.

> the service provider with bogus messages.

Except the above multiplier.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: David Frascone <[email-masked]>
Date: Thu, 25 Jan 2001 09:29:37 -0600

Or, simply, if the packet is forged from an address that does exist.  It will
be silently dropped, as is the way with UDP.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 25 Jan 2001 10:59:27 -0500

> be silently dropped, as is the way with UDP.

Your statement is wrong. If you send a UDP packet to an unknown address,
you should get back an ICMP error ("destination unreachable"), which
causes Unix read's to fail the next time. (Java apparently doesn't have
this functionality, although this information is second-hand.)

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 25 Jan 2001 17:04:55 +0100

> this functionality, although this information is second-hand.)

It's supposedly in next version of the JDK to be released.

Still, I don't see what's stopping the Bad Guys from not sending ICMP
error messages. If they take being Bad seriously, that is.

--
Anders Kristensen

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 25 Jan 2001 11:28:13 -0500

> error messages. If they take being Bad seriously, that is.

There are three separate attacks: flooding the SIP server from your real
address (nothing you can do about it, you can suppress ICMP, but you can
call the FBI or sysadmin and do router-level packet filtering if things
persist), flooding the SIP server from a bogus address (again, nothing
to be done, but at least ICMP should limit the secondary damage) and the
smurf-like attack of using a SIP server as a "force multiplier" to some
other innocent, but valid address.

---

From: David Frascone <[email-masked]>
Date: Thu, 25 Jan 2001 13:27:37 -0600

I'm obviously not being very clear.  Let's assume that I'm forging packets
from different servers, and possibly from the discard port.  And, let's say
that I send one (1) bogus request every second.  

For each (1) bogus request, the proxy or UA will respond with (Someone 
counted this number in an earlier posting, but it will vary depending on
T1 and T2) 11 retransmissions of "User not found" or some such response.  Or,
if it is a proxy, it might do a DNS lookup, forward the request to a proxy,
and generate several more messages before it gets back to sending it's
11 retransmitted 4xx responses.

So, the DoS problem isn't a simple flood, it's the number of messages and
amount of network traffic  that can be generated from one bogus packet.

Now, imagine what happens if instead of sending one a second, the "Bad Guy"
decides to flood them.

*That* is the vunerability that *I'm* talking about.

-Dave