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

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 19 Sep 2013 09:24:31 +0000

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.

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?

Regards
Andy

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Sep 2013 10:11:41 +0000

(As co-chair)

Hi Andy,

Thank You Very Much for the review! 

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: 19. syyskuuta 2013 12:25
To: [email-masked]
Subject: [straw] WGLC Comments on draft-ietf-straw-b2bua-loop-detection-02

Regards
Andy
_______________________________________________
straw mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/straw

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 20 Sep 2013 13:35:43 -0400

Hi Andy,
Thanks for reviewing!  Comments below...

> 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]"…

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)

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

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

-hadriel

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 20 Sep 2013 18:36:14 +0000

See below.

Andy

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: 20 September 2013 18:36
> To: Hutton, Andrew
> Cc: [email-masked]
> Subject: Re: [straw] WGLC Comments on draft-ietf-straw-b2bua-loop-
> detection-02
> 
> 
> Hi Andy,
> > 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.
> 
> 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:

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.