Subject: RE: [SIP] T2 and 182 Queued

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

Wow... busy week prevents me from reading the sip list for 5 days and I come
back to a thread with 50 messages. 

> -----Original Message-----
> 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]
> Subject: Re: [SIP] T2 and 182 Queued
> 
> 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.

Well, it would prevent just the attacks you mention. The general problem is
when an unauthenticated message causes either (1) state to be stored in some
system, or (2) more than one message to be automatically generated in
response to that. Even with TCP, there will be proxies that bomb just from
sending a stream of INVITEs over that established TCP connection, eventually
running out of memory or some other such thing.

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

I don't think you can ever mandate anything, but there are certainly
recommendations that the specification can make. It would be helpful to look
at the various relationships in a SIP system; there are UAC to proxy, proxy
to proxy (both trusted peer and untrusted), proxy to UAS. I think you will
find that the solution you want differs in each case.

For UAC to proxy, Henning proposed the use of a stateless 407 challenge,
which works much like typical TCP SYN handshakes. Mike has complained that
the digest authentication provided  by SIP is not sufficiently strong. I
personally believe that there is no such thing as perfect security, and that
digest is far better than nothing. That aside, I'd welcome a draft on an
alternate, more secure user to proxy authentication mechanism that maintains
this stateless property. Until then, we can recommend that proxies not
establish state (i.e., they are always stateless proxies) for
unauthenticated messages.

For proxy to proxy, there are two cases. One is trusted, the case when a
company is, for example, purchasing wholesale termination services from
another (dialpad to Genuity, for example). In this case, something akin to
TLS is quite good. You establish the connection at the beginning of time,
and send all traffic over that. For untrusted, well, the recommendation
there is that your ingress proxies should generally be stateless until the
call is accepted. Assuming the acceptances aren't spoofed (and that needs to
be addressed as well), a 200 OK from a UAS is a good sign that the call is
not a DoS attack (there are issues with automated systems that answer
everything, I admit). The final interface is proxy to UAS. To avoid using
that as a DoS attack mechanism, the UAS should not create state or send
multiple messages unless it was able to either authenticate that the message
came from a trusted proxy (again, ala TLS, useful for proxy to gateway
connections), or from a trusted caller. 

I'm sure I've left some scenarios out, but its good that we are making
progress in identifying the issues.

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

_______________________________________________
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: Patrice Calhoun <[email-masked]>
Date: Fri, 26 Jan 2001 10:46:06 -0800 (PST)

Welcome to the thread!

:)

> running out of memory or some other such thing.

I think that a reasonable proxy COULD in fact thottle back, or even drop
requests, when it detects that some attack is being mounted from a single TCP
connection.

> find that the solution you want differs in each case.

Sure.
> which works much like typical TCP SYN handshakes.
And I don't have a problem with this (and somehow missed his proposal in the
slew of e-mails). This is a workable solution. The original attack, which was
to fill up a queue, could issue a 407 at each new invite, and this would
eliminate the problem. In fact, even if authentication was disabled at this
point, there would STILL be some level of safety.

> Mike has complained that

I believe that his point (if I can paraphrase from memory) is that replay is
required, and I do agree. Authentication w/o replay is not that useful, IMHO.

> connections), or from a trusted caller. 

I agree, but then stateless doesn't work well for 182 Queued, right?

---

From: David Frascone <[email-masked]>
Date: Fri, 26 Jan 2001 13:03:53 -0600

> point, there would STILL be some level of safety.

The only problem I have here is that one message (an INVITE) would generate
eleven or more (depending on T1) retransmissions of the 407.  So, one network
message will cause many more to be created.  But, it is definately better
than generating the retransmissions and generating network traffic to look up
the user.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 27 Jan 2001 05:42:26 -0800

> personally believe that there is no such thing as perfect security, and that

Before this acquires the state of perceived wisdom, the lack of strength
appears to be of the "if you don't implement the mechanisms available"
variety, i.e., it's not a protocol issue, it's mostly an implementation
issue. (It is true that the Digest checksums only cover parts of the
request. However, that has very little to do with the DOS issue.) The
general replay prevention for Digest authentication is exactly as strong
as IPsec replay prevention, with the qualification above. (I.e., it is
possible with Digest to snoop a message, change some parts of it, such
as the session description, and send it again within the time window
allowed by the replay window of the receiver. I'm not aware that similar
attacks have been perpetrated on HTTP, which has a similar problem in
most cases. Certainly has nothing to do with the common or likely DOS
attacks, where snooping is not part of the problem.)

> connections), or from a trusted caller.

That's essentially what I had proposed, unless I'm misreading your
comments.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 27 Jan 2001 05:43:56 -0800

> I agree, but then stateless doesn't work well for 182 Queued, right?

Not an issue, according to the discussion. You wouldn't send 182 (or
anything but a single 40x) until the caller has been authenticated.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 27 Jan 2001 05:53:36 -0800

> than generating the retransmissions and generating network traffic to look up

Please reread my original email. It explicitly says to only send *one*
401/407 for unauthenticated requests, nothing else. This will need
clarification in the spec, but an implementation can do this today and
nobody will be able to prove that you did it...

---

From: Michael Thomas <[email-masked]>
Date: Sat, 27 Jan 2001 16:57:30 -0800 (PST)

Henning Schulzrinne writes:
 > as IPsec replay prevention, with the qualification above. 

   It's also a lot less efficient too, requiring a
   mandatory CMD->CHALLENGE->CMD+DIGEST loop each
   time. Digest doesn't work in the response
   direction either. What's to prevent an attacker
   from taking down a 911 center by an attacker
   spoofing 500 responses?

 > I.e., it is

   If you're expecting to secure HTTP with digest
   and you're asking these kinds of questions,
   you've already outstriped the capabilities of 
   digest and should be using TLS.

		     Mike