Subject: [SIP] T2 and 182 Queued

From: David Frascone <[email-masked]>
Date: Fri, 19 Jan 2001 09:08:00 -0600

When 182's are sent to indicate queueing, there is no mention of what happens
to T2.  I would *assume* that it needs to be reset, but it is not mentioned
in 2543bis-02.

4 seconds (the sugested default for T2) is *way* to short for a queued call.

Dave Frascone

_______________________________________________
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: David Frascone <[email-masked]>
Date: Wed, 24 Jan 2001 12:11:12 -0600

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

---

From: Billy Biggs <[email-masked]>
Date: Wed, 24 Jan 2001 13:26:13 -0500

> >    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.
> > 
> > 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.
> > 
> 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.

  There are more reasons why 182 Queued is a bad implementation:

  1. PSTN Gateways will have a difficult time doing text-to-speach on
     the reason phrase to play to PSTN callers, and I bet most will just
     play ringing.

  2. Proxies in the middle may decide they don't want to keep state past
     a minute or so, and will CANCEL the call themselves, returning 408
     Timeout or something.

  Any reasonable implementation of queuing will just connect the call
and inform the caller in the audio band to avoid problems.  To save
network bandwidth, the queueing system will just put the remote end on
hold appropriately.  This lets the system happily ping the far end.

  I doubt many people will actually use 182 in practice.  That said, it
does look good on paper, and I don't think it's worth removing from the
spec.

-- 
Billy Biggs
[email-masked]

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 25 Jan 2001 11:49:01 -0800 (PST)

[CC'ing Steve Bellovin]

> 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.
sigh. only if an ICMP error is received, and that is NOT guaranteed.

> 2. Whether UAS queues up messages for 10 or 100 minutes is not very
> relevant; 
correct.

> 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.

hmm.... I respectfully disagree. As I hope you probably know, carriers and
companies with web infrastructure have spent lots of time trying to figure out
how to deal with DoS attacks, such as the TCP SYN attack. Router and operating
system vendors have spent lots of time and energy in fixing code to prevent
these. Now you are stating that it is OK to ignore a new DoS attack, and worry
about it later when it affects deployed services.

I've heard crypto as the solution. Again, if a global PKI existed, we wouldn't
be dealing with ANY DoS attacks, because all IP flows would be secured. But we
all know that we are far from there...

The IESG, and some trusted security advisors, have requested that WGs be more
proactive in identiying, and fixing, protocols that are suceptible to DoS
attacks. I know that there are ways around the problem identified, so perhaps
the WG should be more active in fixing these. Mandating TCP is an obvious
choice, but perhaps there are ways to fix UDP as well?

What am I missing?

PatC

> 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]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 26 Jan 2001 13:01:09 -0500

> From: Patrice Calhoun [mailto:[email-masked]]
> Sent: Friday, January 26, 2001 12:59 PM
> To: James Undery
> Cc: Patrice Calhoun; Michael Thomas; [email-masked];
> 'Henning G. Schulzrinne'; 'Anders Kristensen'; 'David Frascone';
> [email-masked]
> > Patrice Calhoun wrote:
> > > OK, as I mentioned, I was open to other solutions other 
> than requiring
> > > TCP, as long as they worked.
> > 
> > TCP is not a solution I could just as easily DoS your 
> server with TCP. If you
> > totally remove UDP from the spec it may require a DDoS but 
> it is still
> > possible for a person to produce a script kiddie simple 
> program to take out
> > a SIP server if TCP is your only protection. The solution I 
> feel lies out
> > side the scope of RFC 2543 and its successors and in proper network
> > configuration using IPSec, firewalls, routers et al where 
> appropriate.
> 
> sigh. seems like we are going around in circles....
> 
> TCP provides protection against the attacks Dave and I 
> mentioned, namely
> spoofed source IP address. Since TCP does require the 3 way 
> handshake, it
> would be VERY difficult for a hacker to mount a successful SIP attack.
> 
> But, as you state, TCP can still be attacked, but these 
> attacks are better
> known, and many operating systems, routers and firewalls already have
> protection against the known ones.
> 
> so, to restate my (and the position from IESG and their 
> security advisors)
> position, is that protocols MUST NOT introduce "new attacks".
> 
> Once more I state (and did so in the e-mail you replied to) 
> that mandating
> authentication is a workable solution. My question was 
> whether we could
> mandate a non-replayable authentication scheme for all SIP messages.
> 
> PatC
> 
> 

---
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: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 29 Jan 2001 15:58:03 -0500

First of all, could we please defuse the emotion here? It isn't helping.

Could we hear from the SIP phone/small gateway crowd:
	1. Have you actually tried to implement something along the lines of
			IPSEC or TLS in your product?
	2. Do you believe such an implementation to be a serious impediment
			to achieving goals of SIP Phones?
We have the PacketCable specs, which do in fact include this level of
crypto.
A quick look at a popular IPSEC stack shows around 400K of base code,
plus 1.6M for IKE and a policy manager, and less than 16K of RAM.  
That is with a lot of algorithms.  YMMV

I believe the benefits outweigh the costs for good crypto as a minimum
requirement, but I'm not counting $.01 at a time. 

Brian 

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Sunday, January 28, 2001 4:18 PM
> To: Henning G. Schulzrinne
> Cc: Michael Thomas; Patrice Calhoun; [email-masked];
> 'Anders Kristensen'; 'David Frascone'; [email-masked]
> Henning G. Schulzrinne writes:
>  > Michael Thomas wrote:
>  > > The cost of implementing strong crypto on a
>  > > consumer class box is probably less than $1. Maybe
>  > 
>  > This is bogus. Have you tried to actually built one of 
> those boxes? I
>  > have and I know the prices for SRAM and DRAM, which are still major
>  > components of the end system cost.
> 
>    Yes, as a matter of fact I have. I just looked on Pricewatch
>    and ram seems to be going for about $.33/M and flash is going
>    about $1-2/M. I just size'd pluto and klips and got about 400k.
>    An embedded system could easily shave quite a bit of that down,
>    but even if it didn't we're talking about less than $1 _retail_
>    cost.
>    
>  > > less than $.50. Moore's law will make the cost of
>  > > crypto an utterly insignificant cost in the
>  > > future. Also: MEGACO and MGCP mandate the use of
>  > > IPsec, and the main feedback there was the worry
>  > 
>  > Megaco and MGCP are also almost exclusively run without 
> IPsec right now
>  > (Apparently, they aren't used all that much, but that's a separate
>  > problem). 
> 
>    The IETF isn't the protocol police, &tc. Are you
>    saying that MEGAGO/MGCP should just face reality
>    and put - oh say - digest authentication in too?
> 
>  > Plus, they are fixed-association devices across a single
>  > network hop, so none of the difficulties we're discussing 
> here apply.
> 
>    May I ask how you plan to do/scale cross realm Digest
>    since you're throwing the PKI scaling spectre around?
>  
>  > > Digest is worse than nothing at all (Basic at
>  > > least doesn't cop an attitude that it's anything
>  > > less than inadequate): as currently -- and likely
>  > > forever -- implemented does not provide basic
>  > > security features like replay protection,
>  > 
>  > You keep repeating this, but that still doesn't make it correct.
> 
>    \/\/hatever. Be my guest. Build insecure boxes for
>    specious reasons. Declare the problem intractable
>    and substitute non-scalable fake security instead.
>    Maybe we can have a great big group hug after we
>    properly fawn over the emperor's new cloths.
> 
> 		 Mike
>