Subject: [Sip] Security issues with ietf-sip-loop-fix

From: Cullen Jennings <[email-masked]>
Date: Mon, 2 Jul 2007 19:35:58 -0700

(this email with my AD hat on)

The type of SIP loops described in ietf-sip-loop-fix can be roughly  
classified into two categories. Loops that had happened because an  
accidental registration that causes a loop, and loops that happened  
due to malicious intent.

This draft attempted to deals with both. The abstract describes it as

   This document normatively updates RFC 3261, the Session Initiation
    Protocol (SIP), to address a security vulnerability identified in  
SIP
    proxy behavior.  This vulnerability enables an attack against SIP
    networks where a small number of legitimate, even authorized, SIP
    requests can stimulate massive amounts of proxy-to-proxy traffic.

During IETF LC, substantial comment came up about the security of  
this draft not really working in the case of malicious loops. A  
thread ensues that convinced many people on the thread that this  
draft did not really help with the malicious loops. (Not 100% sure  
here but I suspect that the authors and chairs were all convinced of  
this). I will let others explain the issues that came up as we decide  
what to do next.

I think that some of issue was discussed while the working group was  
considering this draft - however, I suspect that many participants  
did not understand how easily this security would be defeated. I for  
one significantly underestimated the how easy it was for a malicious  
attacker to cause this problem. I apologize to the folks that  
attempted to explain it to me and I just failed to "get it".

Anyways, we need to figure out what to do next with this draft. There  
are basically two paths forward that I see:

1) reduce the scope so that it only deals with accidental loops and  
provides no protection against malicious loops. I don't think this  
would change any of the mechanisms in the draft but it would probably  
change lots of the text around what security claims the draft made.

2) try to extend or replace the mechanism with one that does protect  
against malicious attack. A strong candidate to consider would be the  
work in draft-sparks-sipping-max-breadth.

If we go forward with path 1, the value of this draft is probably not  
super high because Max-Forwards deals with the the accidental loops  
in most cases  (but not all cases). If we go with path 2, the WG will  
need make sure it OK with the solution. I'm certainly open to other  
paths forward if someone has a good idea.

What I would like to do now is start some discussion about what the  
working group would like to do with this draft.

Thanks, Cullen

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Robert Sparks <[email-masked]>
Date: Tue, 3 Jul 2007 08:49:18 -0500

We've just submitted an update to the max-breadth draft - it greatly  
simplified the text of -00 and explores
the problem identified in the secdir review of fork-loop-fix a little.

In a nutshell, that problem is that an attacker can get a large  
number (on the order of max-forwards) of
AoRs to participate in the attack. In the real world, this is not  
hard to do. At that point, neither max-forwards
nor loop detection mitigates the damage of the attack. Furthermore,  
the damage is not inherently limited
to the services that provided the participating AoRs. The forking  
behavior can be configured such that
an innocent (perhaps not even SIP) endpoint gets a message every time  
the system forwards and forks.

The max-breadth draft as written now controls only the amplitude of  
such an attack at any given point in
time - it could be modified to control the total number of messages  
the attacked endpoint would see
(see open issue #1).

You can find the revised max-breadth draft at
http://www.nostrum.com/~rjsparks/draft-sparks-sipping-max-breadth-01.txt
until it appears in the repository. Even though it says sipping,  
please (for now) keep the discussion of
it on the SIP list.

Thanks!

RjS

On Jul 2, 2007, at 9:35 PM, Cullen Jennings wrote:

>    Protocol (SIP), to address a security vulnerability identified  
> in SIP
> here but I suspect that the authors and chairs were all convinced  
> of this). I will let others explain the issues that came up as we  
> decide what to do next.
>
> I think that some of issue was discussed while the working group  
> was considering this draft - however, I suspect that many  
> participants did not understand how easily this security would be  
> defeated. I for one significantly underestimated the how easy it  
> was for a malicious attacker to cause this problem. I apologize to  
> the folks that attempted to explain it to me and I just failed to  
> "get it".
>
> Anyways, we need to figure out what to do next with this draft.  
> There are basically two paths forward that I see:
>
> would change any of the mechanisms in the draft but it would  
> probably change lots of the text around what security claims the  
> draft made.
>
> 2) try to extend or replace the mechanism with one that does  
> protect against malicious attack. A strong candidate to consider  
> would be the work in draft-sparks-sipping-max-breadth.
>
> If we go forward with path 1, the value of this draft is probably  
> not super high because Max-Forwards deals with the the accidental  
> loops in most cases  (but not all cases). If we go with path 2, the  
> WG will need make sure it OK with the solution. I'm certainly open  
> to other paths forward if someone has a good idea.
>

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 03 Jul 2007 13:46:36 -0400

> paths forward if someone has a good idea.

While I agree that we need a stronger mechanism for the malicious case,
I have personally concluded that the earlier loop detection suggested by
ietf-sip-loop-fix is a good idea anyway.  Especially in those
configurations in which the maximum allowed value for Max-Forwards is
high (and I think the recommended default of 70 is _very_ high), it is
much better to detect the loop earlier than hop limit. 

I would be in favor of retaining some form of that recommendation.
Doing early loop detection will actually make the breadth-limiting
approach work better anyway, since it will allow non-looped branches to
proceed more quickly by pruning the loops sooner.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 4 Jul 2007 13:07:48 +0200

(as individual)

With regard to:

> If we go forward with path 1, the value of this draft is 
> probably not super high because Max-Forwards deals with the 
> the accidental loops in most cases  (but not all cases). If 
> we go with path 2, the WG will need make sure it OK with the 
> solution. I'm certainly open to other paths forward if 
> someone has a good idea.

There have been comments previously on this list that the default value
of 70 for Max-Forwards is too high, and that a lower default value
should have been used. Therefore Max-Forwards will find the accidental
loops, but will take longer to do it, if the default values are used.

Regards

Keith 

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Tuesday, July 03, 2007 3:36 AM
> To: SIP
> Subject: [Sip] Security issues with ietf-sip-loop-fix
> 
> 
> The type of SIP loops described in ietf-sip-loop-fix can be 
> roughly classified into two categories. Loops that had 
> happened because an accidental registration that causes a 
> loop, and loops that happened due to malicious intent.
> 
>     Protocol (SIP), to address a security vulnerability 
> identified in SIP
> During IETF LC, substantial comment came up about the 
> security of this draft not really working in the case of 
> malicious loops. A thread ensues that convinced many people 
> on the thread that this draft did not really help with the 
> malicious loops. (Not 100% sure here but I suspect that the 
> authors and chairs were all convinced of this). I will let 
> others explain the issues that came up as we decide what to do next.
> 
> I think that some of issue was discussed while the working 
> group was considering this draft - however, I suspect that 
> many participants did not understand how easily this security 
> would be defeated. I for one significantly underestimated the 
> how easy it was for a malicious attacker to cause this 
> problem. I apologize to the folks that attempted to explain 
> it to me and I just failed to "get it".
> 
> Anyways, we need to figure out what to do next with this 
> draft. There are basically two paths forward that I see:
> 
> 1) reduce the scope so that it only deals with accidental 
> loops and provides no protection against malicious loops. I 
> don't think this would change any of the mechanisms in the 
> draft but it would probably change lots of the text around 
> what security claims the draft made.
> 
> protect against malicious attack. A strong candidate to 
> consider would be the work in draft-sparks-sipping-max-breadth.
> 
> If we go forward with path 1, the value of this draft is 
> probably not super high because Max-Forwards deals with the 
> the accidental loops in most cases  (but not all cases). If 
> we go with path 2, the WG will need make sure it OK with the 
> solution. I'm certainly open to other paths forward if 
> someone has a good idea.
> 
> What I would like to do now is start some discussion about 
> what the working group would like to do with this draft.
> 
> Thanks, Cullen
> 
> 
> 
> 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 4 Jul 2007 13:11:29 +0200

(As WG chair and document shepherd for this document)

We do need to get this resolved, and have therefore allocated a slot to
the discussion at the forthcoming IETF meeting of the SIP WG.

This does however require material to put on the slides to lead the
discussion, rather than spending 15 minutes drawing thoughts out of the
microphone stream at the meeting.

So please post to the list with views on this before the meeting,
ideally backed up with technical thoughts to justify your position.

Regards

Keith

---

From: Robert Sparks <[email-masked]>
Date: Thu, 5 Jul 2007 08:52:05 -0500

To put a fine point on this - the kind of accidental loop you are  
talking about here
is one that does not have a fork in it.

It is possible (but much more unlikely) to set up something similar  
to the attack
in the draft by accident and a max-forwards as low as even 20 won't  
help much.

RjS