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