(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
