Subject: AW: [Sip-security] Re: Proxy routed requirements in draft-thomas- sip-sec-framework-00.txt

From: Euchner Martin <[email-masked]>
Date: Fri, 7 Sep 2001 13:35:34 +0200

I would definitely agree to say that non-repudiation is a non issue for SIP for quite some time. This could be marked as for further study or so, if it would ever be an issue for SIP.

Denial-of-Service threats are more interesting. It is certainly true, that there are SIP DoS attacks which we should bother. As an example, Jonathan mentioned the DoS through amplification problem. Such direct SIP DoS attacks are something the SIP protocol should counter. I'm not certain, as to whether such DoS attacks have already been analyzed thoroughly and comprehensively for SIP; probably some more investigations are necessary.

However, there are also various other indirect DoS attacks, which may cause troubles at the SIP layer. Many of them would actually target the underlying network, some would be massive integrity or masquerade attacks, spamming, message flooding.

It is quite difficult to find a sound answer as to whether
-	such attacks should be detected or even prevented by non-SIP means; e.g. in the network, within routers, by firewalls, by network monitors, by ISPs etc. This should be the primary, first-line-of defense against DoS Attacks.
-	or SIP can at least do something simple to detect those DoS attacks that cannot be thwarted by above means. This would serve as a second-line of defense and complement to above one.
-	And where to spend the countermeasures.

	My personal opinion is, that SIP
-	should make sure that the protocol design addresses DoS threats: protocol state transitions should be done in a safe way, message amplification does not occur and such things. This is even an area that does not require cryptographic security.
-	some simple, low computational effort countermeasures: cookies perhaps as in IKE, symmetric integrity check values in SIP messages or other adequate cryptography. It might even be sufficient, if a weak DoS countermeasure be available. This would fit the 2nd line-of-defense strategy.

	The crucial points are:
-	What are the most serious DoS attacks for SIP? Which ones are just annoying and which one would really cause serious harm (financial fraud)?
-	How much are DoS countermeasures allowed to cost? What are the acceptable constraints such as additional protocol overhead, roundtrips just for DoS detection/prevention, that wouldn't be required if DoS attacks were a non-issue?
-	Which DoS attacks can we counter within some acceptable constraints and what are those constraints?
-	Which other DoS attacks would be considered out-of-scope for some reason and must be tackled otherwise?

Finally, SIP DoS prevention could be an issue in certain environments and scenarios, while in other ones, it would be a minor or even no issue at all. This would mean, that SIP DoS should be a separate, optional on/off feature.

In any way, DoS threats are an issue, but perhaps not the most urgent one for SIP security.

Kind Regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Phone: +49 89 722 55790
| Martin Euchner                 Fax  : +49 89 722 46841
| Siemens AG
| ICN M SR 3                     mailto:[email-masked] <mailto:[email-masked]> 
|                                mailto:[email-masked] <mailto:[email-masked]> 
| Hofmannstr. 51                 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm <http://intranet.icn.siemens.de/marketing/cs27/> 
| D-81359 Muenchen               Internet: http://www.siemens.de <http://www.siemens.de> 
| __________________
| Germany     
-----------------------------------------------------------------------

	-----Ursprüngliche Nachricht-----
	Von:	Michael Thomas [SMTP:[email-masked]]
	Gesendet am:	Freitag, 31. August 2001 18:23
	An:	Jari Arkko
	Cc:	[email-masked]; [email-masked]
	Betreff:	[Sip-security] Re: Proxy routed requirements in draft-thomas-sip-sec-framework-00.txt

	Jari Arkko writes:
	 > 
	 > Some further discussion: comparing Michael's
	 > draft and draft-ietf-sip-security-requirements-00.txt,
	 > I see that the former doesn't handle availability
	 > and non-repudiation requirements at all. Yet these
	 > are mentioned in the latter. I believe availability
	 > and DoS is a concern, and should perhaps be treated
	 > somewhere. Non-repudiation on the other hand is
	 > propably a can of worms we don't want to open...

	   Yes, I really don't want to go down the 
	   non-repudiation path. Maybe we just need to
	   say that it is an explicit non-goal. DoS is
	   a more fertile ground, but as we all know is
	   an open ended problem. In order to include
	   discussion of DoS requirements, I think we
	   first need to create some artificials bounds
	   on the discussion so that we have some chance
	   of creating a set of requirements which 
	   a potential solution can objectively measure
	   whether it meets. Ie, open ended statements like
	   "should be DoS resistant" aren't helpful.

	   How we frame this is an interesting question.
	   For outside attackers, we clearly need go no
	   farther than countering a pure flooding attack.
	   From the inside, however, is a lot trickier, and
	   involves potential tradeoffs (tradeoffs that we
	   probably don't want to make at this point, I'll
	   add). 

	   Maybe if we rounded up a bunch of potential DoS
	   attacks we could see a pattern so that we could
	   extract what our expectations are for SIP's 
	   resilience to them is?

	 > Also, in 3.2.5 you talk about the case for
	 > non-adjacent proxies, and wonder if there is
	 > any need for security measures in this
	 > interface. My comment on this is that
	 > protocol-wise you wouldn't even know if
	 > someone who e.g. sent some protected bits
	 > to you was a proxy or an end-node. So,
	 > if we provide tools to get security on the
	 > user->intermediate interface, then non-adjacent
	 > proxies can take advantage of the same
	 > mechanisms. (This comment doesn't of course
	 > say anything about the requirements for such use.
	 > It is perhaps not unthinkable to have a
	 > proxy that would handle security for you
	 > in certain situations.)

	   If there are no requirements, or the requirements
	   are identical, that's fine -- good even, I'd say.
	   The reason I created the fully connected graph
	   was to assess whether that was indeed the case.
	   It appears to me to be the case, but I'd like 
	   to see if other people have sceanrios I hadn't
	   considered, or don't fit that model well.

			Mike

	_______________________________________________
	Sip-security mailing list
	[email-masked]
	http://www1.ietf.org/mailman/listinfo/sip-security

_______________________________________________
Sip-security mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/sip-security

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Sep 2001 11:06:04 -0400

> -----Original Message-----
> From: Euchner Martin [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 7:36 AM
> To: 'Michael Thomas'; Jari Arkko; Euchner Martin
> Cc: [email-masked]
> Subject: AW: [Sip-security] Re: Proxy routed requirements in
> draft-thomas- sip-sec-framework-00.txt
> 
> Denial-of-Service threats are more interesting. It is 
> certainly true, that there are SIP DoS attacks which we 
> should bother. As an example, Jonathan mentioned the DoS 
> through amplification problem. Such direct SIP DoS attacks 
> are something the SIP protocol should counter. I'm not 
> certain, as to whether such DoS attacks have already been 
> analyzed thoroughly and comprehensively for SIP; probably 
> some more investigations are necessary.

I am sure more investigation is needed. We already know of a few problems.
One is that you simply send an INVITE without credentials to a server, and
it challenges you with 401. Based on the SIP spec rules, it will resend this
401, and therefore maintain state to do so. This can be used as an
amplification attack, and as a DoS attack. The counter, which is not well
documented, is to run the authentication "statelessly" - i.e., the server
sends the 401/407, but does not retransmit. This works OK for INVITE so long
as the server doesn't send a 1xx first. 

> -	such attacks should be detected or even prevented by 
> non-SIP means; e.g. in the network, within routers, by 
> firewalls, by network monitors, by ISPs etc. This should be 
> the primary, first-line-of defense against DoS Attacks.

Source address filtering helps with alot of these.

> -	should make sure that the protocol design addresses DoS 
> threats: protocol state transitions should be done in a safe 
> way, message amplification does not occur and such things. 
> This is even an area that does not require cryptographic security.

Right. We do have a real problem though right now. The stateless 401/407
appraoch above helps with proxies that have some kind of subscriber
relationships so that they can authenticate them. Many proxies, however,
cannot realistically authenticate the originator of a request (inbound
proxies, for example). So, these are subject to serious DoS attacks. One way
to resolve that is to always use something like TLS or TCP even, but this is
expensive in terms of connection management. We need to have a simple,
STATELESS, deployable, workable solution for a proxy to challenge the
previous hop, for the purposes of identifying that it is actually listening
on the address it advertised. 

I have a proposal on how to accomplish this. It works if we make the right
decision on request merging (i.e., merged requests are each treated as
independent transactions). Here is the proposal.

A server (uas, proxy, whatever) receives a request. It statelessly sends a
new response, 4xx, with a new challenge header:

Hop-Authenticate: null, realm=foobar.com, nonce=193347fakasd0asd8

THis uses the null authentication algorithm that Henning has proposed. The
previous hop receives this, and ACKs (the ACK is ignored by the proxy since
it generated a stateless response). Then, it resubmits the request (as if it
forked, much like as if the 4xx were a redirect instead), but now includes a
hop authorization header that merely reflects the nonce:

Hop-Authorization: null,realm=foodbar.com,nonce=193347fakasd0asd8

The server gets this, verifies the nonce is one it recently generated, and
then processes the request.

Since the resubmitted request has the same r-uri, request merging needs to
properly handle this case (i.e, not reject the request) which is why  I
mentioned this above.

I believe this approach works through stateless proxies, which is very good.

There is a backwards compatibility issue that is serious. Existing proxies
won't know to resubmit the request. We can come up with a way for a new
proxy to indicate that it does or doesn't support this extension in a
request. But, that introduces the attack back in! For the dos prevention to
work, a proxy would always need to be challenging the requests it gets.

There is also a huge penalty in this approach in terms of call setup delays,
potentially tripling them. In that regard, tls is better since that penalty
is bigger, but just once, as opposed to for each call setup. 

I know I am guilty of jumping to implementations before requirements work,
but we know that dos attack prevention is a requirement, and this is a big
problem.

I'll note that you could also use hop-authentication to allow a UAS to
actually challenge its inbound proxy using basic or digest... might be
useful to solve a few of the cases in Mike's draft. Combine that with James'
improved digest mechanism, and you have a reasonably lightweight way to do
proxy to proxy, and proxy to UAS authentication and message integrity.

> 
> 	The crucial points are:
> -	What are the most serious DoS attacks for SIP? Which 
> ones are just annoying and which one would really cause 
> serious harm (financial fraud)?

I think the most serious one is causing establishment of state for
unauthenticated transactions, which is the problem I have addressed above.

> most urgent one for SIP security.

I disagree. I think DoS threats are one of the most important security
problems. 

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com