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

From: Richard Barnes <[email-masked]>
Date: Fri, 11 Apr 2014 13:40:52 -0400

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..."

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.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 11 Apr 2014 14:08:00 -0400

On Apr 11, 2014, at 1:40 PM, Richard Barnes <[email-masked]> 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?

> 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. :)

-hadriel

---

From: Richard Barnes <[email-masked]>
Date: Fri, 11 Apr 2014 15:14:49 -0400

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