Protocol Action: 'Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to- Back User Agents (B2BUAs)' to Proposed Standard (draft-ietf-straw-b2bua-loop-detection-04.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-
   to- Back User Agents (B2BUAs)'
  (draft-ietf-straw-b2bua-loop-detection-04.txt) as Proposed Standard

This document is the product of the Sip Traversal Required for
Applications to Work Working Group.

The IESG contact persons are Richard Barnes and Alissa Cooper.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-loop-detection/




Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

SIP provides a means of preventing infinite request forwarding loop in [RFC3261], and a means of mitigating parallel forking amplification floods in [RFC5393].  Neither document normatively defines specific behavior for B2BUAs, however.

Unbounded SIP request loops have actually occurred in SIP deployments, numerous times. The cause of loops is usually misconfiguration, but the reason they have been unbounded/unending is they crossed B2BUAs that reset the Max-Forwards value in the SIP requests they generated on their UAC side.  Although such behavior is technically legal per [RFC3261] because a B2BUA is a UAC, the resulting unbounded loops have caused service outages and make troubleshooting difficult.

Furthermore, [RFC5393] also provides a mechanism to mitigate the impact of parallel forking amplification issues, through the use of a "Max-Breadth" header field.  If a B2BUA does not pass on this header field, parallel forking amplification is not mitigated with the [RFC5393] mechanism.

This document defines normative requirements for Max-Forwards and Max-Breadth header field behaviors of B2BUAs, in order to mitigate the effect of loops and parallel forking amplification.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

The WG path of this document was reasonably short and efficient. Several technical comments were made during reviews and all were resolved with consensus.

There is consensus in the STRAW WG to publish this document.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The guidelines and procedures in the document is based on input  and experience from the implementer community.

Personnel:

Who is the Document Shepherd?


Christer Holmberg ([e-mail] -- STRAW WG co-chair).

Who is the Responsible Area Director?

Richard Barnes.

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.