Skip to main content

Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
draft-ietf-straw-b2bua-loop-detection-04

Yes

(Richard Barnes)

No Objection

(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Ted Lemon)

Note: This ballot was opened for revision 04 and is now closed.

Richard Barnes Former IESG member
Yes
Yes () Unknown

                            
Spencer Dawkins Former IESG member
Yes
Yes (2014-05-13) Unknown
I'm really glad to see this moving forward (because I've also talked to some of the folk who have had the pleasure of Max-Forwards=70 meltdowns). The recommendations seem clear and reasonable, and I'm happy to ballot Yes, with one nosy question. (I also agree with Barry's comment, and think I agree with Pete's as well, but you've already seen those).

This text:

   If the received request did not contain a Max-Forwards header field,
   one MUST be created in any request generated in the UAC side, which
   SHOULD be 70, as described for Proxies in section 16.6 part 3 of
   [RFC3261].

points back to this text:

      3. Max-Forwards

         If the copy contains a Max-Forwards header field, the proxy
         MUST decrement its value by one (1).

         If the copy does not contain a Max-Forwards header field, the
         proxy MUST add one with a field value, which SHOULD be 70.

         Some existing UAs will not provide a Max-Forwards header field
         in a request.

in a proposed standard published in 2002. I'm looking at the definition in 20.22 Max-Forwards, which says 

   This header field should be inserted by elements that can not
   otherwise guarantee loop detection.  For example, a B2BUA should
   insert a Max-Forwards header field.

So, what I'm wondering is, and a "no" answer would terminate my questions, which are pipelined just to avoid roundtrip latencies :-)

- Are UAs that don't insert Max-Forwards still deployed? If so,

- Would a spiral back out to a proxy or B2BUA that doesn't insert Max-Forwards still be vulnerable to the endless looping problem that this draft is addressing? If so,

I wouldn't dream of asking you to figure out how to detect such a loop (and especially not when what you've already got is a huge improvement and doing so would hold you up), but I'm wondering if it would make sense to 

- point this problem out in the draft, and/or

- consider whether a short BCP on "omitting Max-Forwards considered harmful" would have any positive effect.
Adrian Farrel Former IESG member
No Objection
No Objection (2014-05-11) Unknown
Obfuscation of the number of hops traversed so far can surely be allowed provided that it always reduces the TTL.
Alia Atlas Former IESG member
No Objection
No Objection (2014-05-14) Unknown
I also agree with Adrian's comment.  Decrementing by at least 1 but possibly more is a way of obfuscating hops taken.
Alissa Cooper Former IESG member
No Objection
No Objection (2014-05-12) Unknown
Section 9:
"Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA)."

What is this doing here?
Barry Leiba Former IESG member
No Objection
No Objection (2014-05-05) Unknown
Two non-blocking comments:

1. You should expand "UAC" and "UAS" on first use.

2. -- Section 4 --

   It is RECOMMENDED that B2BUAs implement the loop-detection mechanism
   for the Via header field, as defined for a Proxy in [RFC5393].

Why "RECOMMENDED" and not "REQUIRED"?  It would be good to explain, to give guidance about when it might be appropriate not to.
Benoît Claise Former IESG member
No Objection
No Objection () Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection () Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2014-05-14) Unknown
I agree with Adrian and Stephen's comments on other for obfuscation discussed in the security considerations section rather than resetting the number of hops.
Martin Stiemerling Former IESG member
No Objection
No Objection () Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2014-05-13) Unknown
In section 5:

   B2BUAs MAY perform the same actions for in-dialog
   requests, but doing so may cause issues with devices that set Max-
   Forwards values based upon the number of received Via or Record-Route
   headers.

Don't you instead mean:

   B2BUAs SHOULD NOT perform the same actions for in-dialog requests,
   because doing so may cause issues with devices that set Max-
   Forwards values based upon the number of received Via or Record-Route
   headers.
Stephen Farrell Former IESG member
No Objection
No Objection (2014-05-13) Unknown
Section 5: Does "decrement" here mean "reduce" or
"reduce-by-exactly-1"? If the former, then you might even
need to say to watch out in case the value is less than zero
(or would be after decrementing). If the latter, which I
guess is the case (since that's what's in 3261) maybe say so
just to be sure. No big deal if you're ok with it as-is.

I also agree with Adrian's comment.
Ted Lemon Former IESG member
No Objection
No Objection () Unknown