Re: [straw] WGLC Comments on draft-ietf-straw-b2bua-loop-detection-02

["Hutton, Andrew" <[e-mail]>]

See below.

Andy

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[e-mail]]
> Sent: 20 September 2013 18:36
> To: Hutton, Andrew
> Cc: [e-mail]
> Subject: Re: [straw] WGLC Comments on draft-ietf-straw-b2bua-loop-
> detection-02
> 
> 
> Hi Andy,
> Thanks for reviewing!  Comments below...
> 
> On Sep 19, 2013, at 5:24 AM, "Hutton, Andrew" <andrew.hutton@siemens-
> enterprise.com> wrote:
> 
> > I have a couple of comments.
> >
> > 1. Section 4 states " It is RECOMMENDED that B2BUAs implement the
> loop-detection mechanism for the Via header field, as defined for a
> Proxy in [RFC5393]."
> >
> > This could be changed to a MUST requirement by changing it to "B2BUAs
> MUST implement the updates to [RFC3261] for strengthening the
> requirements to perform loop detection as specified in [RFC5393]".  I
> prefer this because it enforces the requirement that some form of loop-
> detection must be in place when forking.
> 
> This was raised back in June here:
> http://www.ietf.org/mail-archive/web/straw/current/msg00127.html
> 
> I'm fine with changing it to a MUST, but would like to hear more folks
> weigh in.
> 
> As an aside, I'm fairly sure changing it to a MUST won't make B2BUA's
> implement that check, because some B2BUAs literally can't do it safely;
> that check requires knowing what all of the variables used for routing
> requests are, and it's not technically possible to know that in some
> architectures.  For example, if your architecture allows using external
> systems/routing-engines, or scripts/plugins, or something flexible like
> that to control SIP request routing decisions... then I don't think you
> can safely preform that via header check. (by "safely" I mean
> accurately enough to detect legitimate spirals vs. loops)
> 

The MUST would only mean that as according to RFC5393 some kind of loop detection has to be implemented but if you think this is too strong then I am ok with how it is. Sorry I had missed the previous discussion.


> 
> > 2. Section 5 states " 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"
> >
> > I think this could do with some more explanation regarding mid-dialog
> requests and the issues associated with setting Max-Forwards based on
> Via or Record-Route. It would be good to remove this "MAY" and have
> clear requirements for handling mid-dialog requests. Do we really need
> to have the text about setting based on the number of via or record-
> route headers?
> 
> I'm not sure I understand what you mean.  This doc is about B2BUA
> handling copying the Max-Forwards, not about the originating UAC
> setting the MAx-Forwards.  The text in this section was based on this:
> http://www.ietf.org/mail-archive/web/straw/current/msg00157.html
> 

Ok now I think I understand the problem is that if the B2BUA decrements Max-Forwards for mid-dialog requests and the originator set the value based on the number of Via or Record-Route headers then the value is going to go to zero.  So I still think this needs a bit more explanation so the reader really understands this issue and can make a decision whether this applies in their environment or not.


> -hadriel