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

[Hadriel Kaplan <[e-mail]>]

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?


> 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