Re: [straw] AD review of draft-ietf-straw-b2bua-loop-detection-04

[Richard Barnes <[e-mail]>]

On Fri, Apr 11, 2014 at 2:08 PM, Hadriel Kaplan
<[e-mail]>wrote:

>
> On Apr 11, 2014, at 1:40 PM, Richard Barnes <[e-mail]> wrote:
>
> > I have reviewed this document in preparation for IETF LC.  Overall, it
> looks good to me; I have requested LC.  One editorial nit and one comment
> below.
> >
> > Thanks,
> > --Richard
> >
> > In Section 5, the antecedent of "which SHOULD be 70" appears to be the
> generated Max-Forwards header, so this doesn't really parse.  "The value
> for this header field SHOULD be 70..."
>
> You're right: that is an nit. :)
> I think it's understandable, though a bit odd yes.
>
> Can the RFC Editor change it?


Added the following RFC Editor note:

OLD:
   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].
NEW:
   If the received request did not contain a Max-Forwards header field,
   one MUST be created in any request generated in the UAC side, as
   described for Proxies in section 16.6 part 3 of [RFC3261].  As in that
   specification, the value of the new Max-Forwards header SHOULD be
   70.



> > In the security considerations, you mention resetting the Max-* headers.
> Is there a way this could be done that is compatible with the goals of this
> doc?  E.g., setting any random value for Max-Forwards, as long as it's
> lower than what came in?  Allowing something like this could bring more
> proxies into conformance with the overall objective of this document.
>
> I'd rather ask that up for WG consensus I think.
>
> Personally I'd rather not advocate any form of randomized modification.
>  My employer's products can do it if configured to (most other SBCs can too
> I assume), but it's a good way to get failed calls. You have to pick a
> random decrement number in some range, and the range can't be too small or
> it's worthless to do... but if the range is big, then crossing multiple
> SBCs and B2BUAs will quickly get it to 0 before it reaches the target.
>
> In some real-world call flows the SIP request crosses a surprising number
> of SIP hops. Even just decrementing by 1 people have reached the hop limit
> (though that was with a starting Max-Forwards of 40 if I recall correctly,
> but still...).
>
> And that's not to mention how hard it is to troubleshoot if some hop in
> the middle decrements by random values. And it would make the trace route
> mechanism have inconsistent behavior to the user.
>
> So personally I'd vote no - either the SIP device follows this RFC and
> decrements by 1, or they don't comply with the RFC.  Nice and binary. :)
>

I'm fine with either answer.

--Richard



>
> -hadriel
>
>