From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7403.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc7403.txt (limited to 'doc/rfc/rfc7403.txt') diff --git a/doc/rfc/rfc7403.txt b/doc/rfc/rfc7403.txt new file mode 100644 index 0000000..b4b1e28 --- /dev/null +++ b/doc/rfc/rfc7403.txt @@ -0,0 +1,395 @@ + + + + + + +Internet Engineering Task Force (IETF) H. Kaplan +Request for Comments: 7403 Oracle +Category: Standards Track November 2014 +ISSN: 2070-1721 + + + A Media-Based Traceroute Function + for the Session Initiation Protocol (SIP) + +Abstract + + SIP already provides the ability to perform hop-by-hop traceroute for + SIP messages using the Max-Forwards header field to determine the + reachability path of requests to a target. A mechanism for media- + loopback calls has also been defined separately, which enables test + calls to be generated that result in media being looped back to the + originator. This document describes a means of performing hop-by-hop + traceroute-style test calls using the media-loopback mechanism to + test the media path when SIP sessions go through media-relaying back- + to-back user agents (B2BUAs). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7403. + + + + + + + + + + + + + + + + + +Kaplan Standards Track [Page 1] + +RFC 7403 Media Traceroute for SIP November 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 3. The SIP Traceroute Mechanism ....................................4 + 3.1. Processing a Received Max-Forwards Header Field ............4 + 3.2. Answering the INVITE .......................................5 + 4. Security Considerations .........................................5 + 5. Normative References ............................................6 + Acknowledgments ....................................................7 + Author's Address....................................................7 + +1. Introduction + + In many deployments, the media for SIP-created sessions does not flow + directly from the originating User Agent Client (UAC) to the + answering User Agent Server (UAS). Often, SIP B2BUAs in the SIP + signaling path also insert themselves in the media plane path by + manipulating Session Description Protocol (SDP), either for injecting + media such as rich ringtones or music-on-hold or for relaying media + in order to provide functions such as transcoding, IPv4-IPv6 + conversion, NAT traversal, Secure Realtime Transport Protocol (SRTP) + termination, media steering, etc. + + As more SIP domains get deployed and interconnected, the odds of a + SIP session crossing such media-plane B2BUAs increases as well as the + number of such B2BUAs any given SIP session may go through. In other + words, any given SIP session may cross any number of B2BUAs both in + the SIP signaling plane as well as the media plane. + + When a failure or degradation occurs in the media plane, it is + difficult to determine where in the media path it occurred. In order + to aid managing and troubleshooting SIP-based sessions and media + + + +Kaplan Standards Track [Page 2] + +RFC 7403 Media Traceroute for SIP November 2014 + + + traversing such B2BUAs, it would be useful to progressively test the + media path as it reaches successive B2BUAs with a test controlled + solely by the source User Agent (UA). A mechanism to perform media- + loopback test sessions has been defined in [RFC6849], but it cannot + be used directly to test B2BUAs because, typically, the B2BUAs do not + have an Address of Record (AOR) to be targeted, nor is it known a + priori which B2BUAs will be traversed for any given session. + + For example, suppose calls from Alice to Bob have media problems. + Alice would like to test the media path to each B2BUA in the path to + Bob separately, to determine which segment has the issues. Alice + cannot target the B2BUAs directly for each test call; she doesn't + know which URIs to use to target them, nor would using such URIs + guarantee the same media path be used as a call to Bob. A better + solution would be to make a test call targeted to Bob, but with a SIP + traceroute-type mechanism that makes the call terminate at the + B2BUAs, such that she can perform test sessions to test the media + path to each downstream B2BUA. + + This document defines how such a mechanism can be employed, using the + mechanism in [RFC6849] along with the Max-Forwards SIP header field + such that a SIP UA can make multiple test calls, each reaching a + B2BUA further downstream. Each B2BUA in the path that supports the + mechanism in [RFC6849] would answer the media-loopback call; thus, + the originating SIP UA can test the media path up to that B2BUA. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + B2BUA: a SIP Back-to-Back User Agent, which is the logical + combination of a User Agent Server (UAS) and User Agent + Client (UAC). + + UAS: a SIP User Agent Server + + UAC: a SIP User Agent Client + + Traceroute: a mechanism to trace a path of hops from an originator to + a destination. For IP, this is typically done using the + Time To Live (TTL) field of the IP header, starting at + the value 1 and incrementing by 1 as each IP hop responds + with an ICMP error. For SIP, this can be done using Max- + Forwards header field starting with the value 0, in a + similar fashion to the TTL field. + + + + +Kaplan Standards Track [Page 3] + +RFC 7403 Media Traceroute for SIP November 2014 + + + It is assumed the reader is already familiar with media-loopback + [RFC6849]. + +3. The SIP Traceroute Mechanism + + The Max-Forwards header field can already be used to generate a + simple SIP-request traceroute by generating a SIP request initially + using a Max-Forwards value of 0, receiving a 483 Too Many Hops + response from the next-hop, and then incrementing the value for + subsequent SIP requests; one would thereby reach SIP devices further + and further downstream, receiving 483 from each of them. + + The mechanism described in this document uses such a traceroute of a + Max-Forwards style to perform media-loopback testing. To perform a + SIP media-plane traceroute, the originating UAC (Alice) generates a + SIP INVITE to a target AOR (Bob), with a Max-Forwards header field + value of 0 and with SDP based on [RFC6849]. The SIP next-hop will + either reject the request with a 483 Too Many Hops response or, if + the next-hop is a B2BUA that supports this mechanism and if the B2BUA + allows such testing from the requesting UAC, the B2BUA will answer + the INVITE to establish the dialog and create a media-loopback + session. + + The originating UAC can then end the media-loopback session, generate + another INVITE to the same target AOR with a Max-Forwards header + field value of 1, which will reach the second SIP next-hop, and so + on. + + A SIP Reason header field cause value of '483' (as defined in + [RFC3326]) will be in the 200 answer from each B2BUA answering the + INVITE, until the INVITE reaches the final UAS (Bob), which does not + use the Reason cause value (see Section 3.2 for details). + + Using this mechanism, a SIP UAC can test the path from itself to each + successive B2BUA on the path to a target. Such a mechanism could + also be useful for establishing a permanent test call between an + Enterprise and a Service Provider across a SIP Trunk, for example, or + for automated measurement systems to test the media path between + domains, etc. + +3.1. Processing a Received Max-Forwards Header Field + + As currently defined in [RFC3261], the UAS half of a B2BUA does not + technically need to inspect the Max-Forwards header field value for + received requests: only Proxies do. This behavior was updated by + [RFC7332], such that a compliant B2BUA needs to both inspect the + value in order to prevent loops, as well as copy and decrement the + value as if it were a Proxy. This document also requires such + + + +Kaplan Standards Track [Page 4] + +RFC 7403 Media Traceroute for SIP November 2014 + + + behavior in order for the mechanism to succeed; therefore, a B2BUA + supporting the traceroute mechanism defined in this document MUST + also comply with [RFC7332]. + +3.2. Answering the INVITE + + If a SIP B2BUA receives a dialog-creating INVITE request with a Max- + Forwards header value of 0, with SDP for media-loopback based on + [RFC6849], and the policies of the B2BUA allow it to answer such a + request, then it is answered as if the original target of the request + were the local SIP B2BUA. The normal procedures of SIP apply, as + well as [RFC6849], as if the request had been targeted at the local + B2BUA device as the intended destination all along. + + In the 200 response for the INVITE, the B2BUA MUST also add a Reason + header, per [RFC3326], with a protocol field value of "SIP", a cause + field value of "483", and a reason-text value of "Traceroute + Response". The purpose of the Reason header is to indicate to the + UAC that the request is being answered due to reaching a Max- + Forwards of 0, rather than being answered due to reaching the final + UAS. When the ultimate target UAS answers a loopback-based INVITE + with a Max-Forwards greater than or equal to 0, the Reason header + would not be added to the response and the UAC will know the + traceroute is complete. + + If a B2BUA receives an INVITE with media-loopback SDP and a Max- + Forwards header field value of 0, as defined in this document, and it + does not accept the session (e.g., due to local policy), then it + SHOULD respond with a 483 Too Many Hops response, per the normal + rules of [RFC3261], as it would previously. In other words, in such + a case, it behaves no differently than it would have if it did not + support this document's new behavior. + +4. Security Considerations + + There are security implications for the mechanism defined in this + document. Answering media-loopback calls in a B2BUA consumes + resources on the B2BUA, and network bandwidth in between and, thus, + exposes a vector for denial-of-service (DoS) attacks; therefore, + B2BUAs should provide configuration options to control who can make + such test calls, how many concurrent calls can be established and + maintained, and how long calls can continue. Entities that deploy + B2BUAs should set these options to values that reduce the DoS risk to + an acceptable level. For example, a B2BUA might perform digest- + challenge authentication with specific credentials for such calls or + it might only allow specific sources to make such calls, at a + + + + + +Kaplan Standards Track [Page 5] + +RFC 7403 Media Traceroute for SIP November 2014 + + + specific time. Such policies are typically vendor specific based on + local policies and deployment usage scenarios and cannot be + explicitly defined in this document. + + The security considerations of [RFC6849] also apply to this document. + Since B2BUAs are not end-user devices, there is no human user to + monitor the loopback session activity on the B2BUA as recommended in + [RFC6849]; instead, B2BUAs should log such events or provide some + form of administrative notification. + +5. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + . + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002, . + + [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason + Header Field for the Session Initiation Protocol (SIP)", + RFC 3326, December 2002, + . + + [RFC6849] Kaplan, H., Ed., Hedayat, K., Venna, N., Jones, P., and + N. Stratton, "An Extension to the Session Description + Protocol (SDP) and Real-time Transport Protocol (RTP) for + Media Loopback", RFC 6849, February 2013, + . + + [RFC7332] Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for + Session Initiation Protocol (SIP) Back-to-Back User + Agents (B2BUAs)", RFC 7332, August 2014, + . + + + + + + + + + + + + + + + +Kaplan Standards Track [Page 6] + +RFC 7403 Media Traceroute for SIP November 2014 + + +Acknowledgments + + The general concept of performing media-loopback on a hop-by-hop + basis using a decrementing header traceroute-style approach came out + of discussions several years ago, between the author, Kaynam Hedayat, + Nagarjuna Venna, and Patrick MeLampy. Other people that have + contributed to the topic over the years since then: Brett Tate, Paul + Kyzivat, Peter Dawes, Zaid Ally, Dianna Stiller, Jon Boone, and + several others whom I have lost the names of since. + +Author's Address + + Hadriel Kaplan + Oracle + EMail: hadrielk@yahoo.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kaplan Standards Track [Page 7] + -- cgit v1.2.3