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
On Jul 4, 2007, at 6:07 AM, DRAGE, Keith ((Keith)) wrote:
(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 PROTECTED]
Sent: Tuesday, July 03, 2007 3:36 AM
To: SIP
Subject: [Sip] Security issues with ietf-sip-loop-fix
(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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
