Subject: [Sip] Update to fork-loop-fix submitted

From: Robert Sparks <[email-masked]>
Date: Sun, 25 Jun 2006 10:51:52 -0400

Until it appears in the repository, see:
http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-02.txt

This was a moderately heavy touch - based on list feedback, I've
moved and updated the sections covering the loopdetection algorithm
in from 3261. In the process of writing the clarifying text, I  
discovered
several places that need clarification. They are listed as Open Issues
in the draft. Basically there are fields that I can't recall or  
reconstruct
how they would be useful in the part of the hash used for loop-detection
or spiral differentiation. If anyone can remember why they need to be
included, send a note to the list and we'll capture that in the draft.

Please review the updated loop-detection text very carefully.

Here's the changelog from the draft:

       Integrated several editorial fixes suggested by Jonathan  
Rosenberg

       Noted that the reduction of the attack to a single registration
       against a single URI as documented in previous versions, is, in
       fact, going to be effective against implementations conforming to
       the standards before this repair.

       Re-incorporated motivation from the original maxforwards-problem
       draft into the security considerations section based on feedback
       from Cullen Jennings

       Introduced replacement text for the loop detection algorithm
       description in RFC 3261, fixing the bug 648 (the topmost Via  
value
       must not be included in the second part) and clarifying the
       algorithm.  Removed several other fields suggested by 3261 and
       placed open issues around their presence.

       Added a Notes to Implementors section capturing the "common way"
       text and pointing to the interoperability issues that have been
       observed with loop detection at previous SIPits

Thanks,

RjS

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 25 Jun 2006 21:54:43 +0200

> In the process of writing the clarifying text, I  discovered

Open issue 1: Route headers

Consider a UA that forwards to proxy P1 using Route: P1; proxy P1 that 
forwards to P2 (using Route: P2), and then P2 using Route: P1, P3
This is not a loop; I think the rule should be 'all Route headers, excluding 
the ones pointing to the element itself'

Open issue 2: Call-ID, To-tag, and From-tag and CSeq
I think these can be safely excluded, as there are no valid scenarios in 
which some proxy would change them. However, in the rare case that a 
particular request causes a hash clash, a UAC should perhaps be enabled to 
retry the request using, say, CSeq+1. To enable this, CSeq number should be 
included (the UAC could not change any of the others for in-dialog requests)

Open issue 3 : Proxy-Require and Proxy-Authorization
Both of these can only be removed by proxies downstream, never added. If a 
request is first received with P-R and then without, in theory the routing 
decision could be different (but I don't know any existing extensions for 
which this would matter)

For P-A, when it is removed it could be that a 407 response would be more 
appropriate than a 482. My proposal would be to move step 4 in RFC3261 
section 16.3 to after current step 6. So: Proxy-Require check, then 
Proxy-Authorization check, then Loop Check. If this is done, then I think 
P-R and P-A can safely be excluded from the loop hash

As I have remarked before: since a forking proxy is required to be 
transaction stateful, the loop check could include a lookup for a previous 
transaction using the branch of the Via that is found matching.

Regards,

Jeroen