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