diff options
Diffstat (limited to 'doc/rfc/rfc5898.txt')
| -rw-r--r-- | doc/rfc/rfc5898.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc5898.txt b/doc/rfc/rfc5898.txt new file mode 100644 index 0000000..ea897ab --- /dev/null +++ b/doc/rfc/rfc5898.txt @@ -0,0 +1,955 @@ + + + + + + +Internet Engineering Task Force (IETF) F. Andreasen +Request for Comments: 5898 Cisco Systems +Category: Standards Track G. Camarillo +ISSN: 2070-1721 Ericsson + D. Oran + D. Wing + Cisco Systems + July 2010 + + + Connectivity Preconditions for Session Description Protocol (SDP) + Media Streams + +Abstract + + This document defines a new connectivity precondition for the Session + Description Protocol (SDP) precondition framework. A connectivity + precondition can be used to delay session establishment or + modification until media stream connectivity has been successfully + verified. The method of verification may vary depending on the type + of transport used for the media. For unreliable datagram transports + such as UDP, verification involves probing the stream with data or + control packets. For reliable connection-oriented transports such as + TCP, verification can be achieved simply by successful connection + establishment or by probing the connection with data or control + packets, depending on the situation. + +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/rfc5898. + + + + + + + + + + + +Andreasen, et al. Standards Track [Page 1] + +RFC 5898 Connectivity Precondition July 2010 + + +Copyright Notice + + Copyright (c) 2010 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. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Andreasen, et al. Standards Track [Page 2] + +RFC 5898 Connectivity Precondition July 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Connectivity Precondition Definition . . . . . . . . . . . . . 4 + 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Operational Semantics . . . . . . . . . . . . . . . . . . 4 + 3.3. Status Type . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.4. Direction Tag . . . . . . . . . . . . . . . . . . . . . . 5 + 3.5. Precondition Strength . . . . . . . . . . . . . . . . . . 5 + 4. Verifying Connectivity . . . . . . . . . . . . . . . . . . . . 6 + 4.1. Correlation of Dialog to Media Stream . . . . . . . . . . 7 + 4.2. Explicit Connectivity Verification Mechanisms . . . . . . 7 + 4.3. Verifying Connectivity for Connection-Oriented + Transports . . . . . . . . . . . . . . . . . . . . . . . . 9 + 5. Connectivity and Other Precondition Types . . . . . . . . . . 9 + 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 + +1. Introduction + + The concept of a Session Description Protocol (SDP) [RFC4566] + precondition in the Session Initiation Protocol (SIP) [RFC3261] is + defined in RFC 3312 [RFC3312] (updated by RFC 4032 [RFC4032]). A + precondition is a condition that has to be satisfied for a given + media stream in order for session establishment or modification to + proceed. When the precondition is not met, session progress is + delayed until the precondition is satisfied or the session + establishment fails. For example, RFC 3312 [RFC3312] defines the + Quality of Service precondition, which is used to ensure availability + of network resources prior to establishing a session (i.e., prior to + starting to alert the callee). + + SIP sessions are typically established in order to set up one or more + media streams. Even though a media stream may be negotiated + successfully through an SDP offer-answer exchange, the actual media + stream itself may fail. For example, when there is one or more + Network Address Translators (NATs) or firewalls in the media path, + the media stream may not be received by the far end. In cases where + the media is carried over a connection-oriented transport such as TCP + [RFC0793], the connection-establishment procedures may fail. The + connectivity precondition defined in this document ensures that + session progress is delayed until media stream connectivity has been + verified. + + + +Andreasen, et al. Standards Track [Page 3] + +RFC 5898 Connectivity Precondition July 2010 + + + The connectivity precondition type defined in this document follows + the guidelines provided in RFC 4032 [RFC4032] to extend the SIP + preconditions framework. + +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 RFC 2119 [RFC2119]. + +3. Connectivity Precondition Definition + +3.1. Syntax + + The connectivity precondition type is defined by the string "conn", + and hence we modify the grammar found in RFC 3312 [RFC3312] and RFC + 5027 [RFC5027] as follows: + + precondition-type = "conn" / "sec" / "qos" / token + + This precondition tag is registered with the IANA in Section 8. + +3.2. Operational Semantics + + According to RFC 4032 [RFC4032], documents defining new precondition + types need to describe the behavior of UAs (User Agents) from the + moment session establishment is suspended due to a set of + preconditions, until it is resumed when these preconditions are met. + An entity that wishes to delay session establishment or modification + until media stream connectivity has been established uses this + precondition-type in an offer. When a mandatory connectivity + precondition is received in an offer, session establishment or + modification is delayed until the connectivity precondition has been + met (i.e., until media stream connectivity has been established in + the desired direction or directions). The delay of session + establishment defined here implies that alerting of the called party + does not occur until the precondition has been satisfied. + + Packets may be both sent and received on the media streams in + question. However, such packets SHOULD be limited to packets that + are necessary to verify connectivity between the two endpoints + involved on the media stream. That is, the underlying media stream + SHOULD NOT be cut through. For example, Interactive Connectivity + Establishment (ICE) connectivity checks [RFC5245] and TCP SYN, SYN- + ACK, and ACK packets can be exchanged on media streams that support + them as a way of verifying connectivity. + + + + + +Andreasen, et al. Standards Track [Page 4] + +RFC 5898 Connectivity Precondition July 2010 + + + Some media streams are described by a single 'm' line but, + nevertheless, involve multiple addresses. For example, RFC 5109 + [RFC5109] specifies how to send FEC (Forward Error Correction) + information as a separate stream (the address for the FEC stream is + provided in an 'a=fmtp' line). When a media stream consists of + multiple destination addresses, connectivity to all of them MUST be + verified in order for the precondition to be met. In the case of RTP + media streams [RFC3550] that use RTCP, connectivity MUST be verified + for both RTP and RTCP; the RTCP transmission interval rules MUST + still be adhered to. + +3.3. Status Type + + RFC 3312 [RFC3312] defines support for two kinds of status types -- + namely, segmented and end-to-end. The connectivity precondition-type + defined here MUST be used with the end-to-end status type; use of the + segmented status type is undefined. + +3.4. Direction Tag + + The direction attributes defined in RFC 3312 [RFC3312] are + interpreted as follows: + + o send: the party that generated the session description is sending + packets on the media stream to the other party, and the other + party has received at least one of those packets. That is, there + is connectivity in the forward (sending) direction. + + o recv: the other party is sending packets on the media stream to + the party that generated the session description, and this party + has received at least one of those packets. That is, there is + connectivity in the backwards (receiving) direction. + + o sendrecv: both the send and recv conditions hold. + + Note that a "send" connectivity precondition from the offerer's point + of view corresponds to a "recv" connectivity precondition from the + answerer's point of view, and vice versa. If media stream + connectivity in both directions is required before session + establishment or modification continues, the desired status needs to + be set to "sendrecv". + +3.5. Precondition Strength + + Connectivity preconditions may have a strength-tag of either + "mandatory" or "optional". + + + + + +Andreasen, et al. Standards Track [Page 5] + +RFC 5898 Connectivity Precondition July 2010 + + + When a mandatory connectivity precondition is offered and the + answerer cannot satisfy the connectivity precondition (e.g., because + the offer does not include parameters that enable connectivity to be + verified without media cut through) the offer MUST be rejected as + described in RFC 3312 [RFC3312]. + + When an optional connectivity precondition is offered, the answerer + MUST generate its answer SDP as soon as possible. Since session + progress is not delayed in this case, it is not known whether the + associated media streams will have connectivity. If the answerer + wants to delay session progress until connectivity has been verified, + the answerer MUST increase the strength of the connectivity + precondition by using a strength-tag of "mandatory" in the answer. + + Note that use of a mandatory precondition requires the presence of a + SIP "Require" header with the option tag "precondition". Any SIP UA + that does not support a mandatory precondition will reject such + requests. To get around this issue, an optional connectivity + precondition and the SIP "Supported" header with the option tag + "precondition" can be used instead. + + Offers with connectivity preconditions in re-INVITEs or UPDATEs + follow the rules given in Section 6 of RFC 3312 [RFC3312]. That is: + + Both user agents SHOULD continue using the old session parameters + until all the mandatory preconditions are met. At that moment, + the user agents can begin using the new session parameters. + +4. Verifying Connectivity + + Media stream connectivity is ascertained by use of a connectivity + verification mechanism between the media endpoints. A connectivity + verification mechanism may be an explicit mechanism, such as ICE + [RFC5245] or ICE TCP [ICE-TCP], or it may be an implicit mechanism, + such as TCP. Explicit mechanisms provide specifications for when + connectivity between two endpoints using an offer/answer exchange is + ascertained, whereas implicit mechanisms do not. The verification + mechanism is negotiated as part of the normal offer/answer exchange; + however, it is not identified explicitly. More than one mechanism + may be negotiated, but the offerer and answerer need not use the + same. The following rules guide which connectivity verification + mechanism to use: + + o If an explicit connectivity verification mechanism (e.g., ICE) is + negotiated, the precondition is met when the mechanism verifies + connectivity successfully. + + + + + +Andreasen, et al. Standards Track [Page 6] + +RFC 5898 Connectivity Precondition July 2010 + + + o Otherwise, if a connection-oriented transport (e.g., TCP) is + negotiated, the precondition is met when the connection is + established. + + o Otherwise, if an implicit verification mechanism is provided by + the transport itself or the media stream data using the transport, + the precondition is met when the mechanism verifies connectivity + successfully. + + o Otherwise, connectivity cannot be verified reliably, and the + connectivity precondition will never be satisfied if requested. + + This document does not mandate any particular connectivity + verification mechanism; however, in the following, we provide + additional considerations for verification mechanisms. + +4.1. Correlation of Dialog to Media Stream + + SIP and SDP do not provide any inherent capabilities for associating + an incoming media stream packet with a particular dialog. Thus, when + an offerer is trying to ascertain connectivity, and an incoming media + stream packet is received, the offerer may not know which dialog had + its "recv" connectivity verified. Explicit connectivity verification + mechanisms therefore typically provide a means to correlate the media + stream, whose connectivity is being verified, with a particular SIP + dialog. However, some connectivity verification mechanisms may not + provide such a correlation. In the absence of a mechanism for the + correlation of dialog to media stream (e.g., ICE), a UAS (User Agent + Server) MUST NOT require the offerer to confirm a connectivity + precondition. + +4.2. Explicit Connectivity Verification Mechanisms + + Explicit connectivity verification mechanisms typically use probe + traffic with some sort of feedback to inform the sender whether + reception was successful. Below we provide two examples of such + mechanisms, and how they are used with connectivity preconditions: + + Interactive Connectivity Establishment (ICE) [RFC5245] provides one + or more candidate addresses in signaling between the offerer and the + answerer and then uses STUN (Simple Traversal of the UDP Protocol + through NAT) Binding Requests to determine which pairs of candidate + addresses have connectivity. Each STUN Binding Request contains a + password that is communicated in the SDP as well; this enables + correlation between STUN Binding Requests and candidate addresses for + a particular media stream. It also provides correlation with a + particular SIP dialog. + + + + +Andreasen, et al. Standards Track [Page 7] + +RFC 5898 Connectivity Precondition July 2010 + + + ICE implementations may be either full or lite (see [RFC5245]). Full + implementations generate and respond to STUN Binding Requests, + whereas lite implementations only respond to them. With ICE, one + side is a controlling agent, and the other side is a controlled + agent. A full implementation can take on either role, whereas a lite + implementation can only be a controlled agent. The controlling agent + decides which valid candidate to use and informs the controlled agent + of it by identifying the pair as the nominated pair. This leads to + the following connectivity precondition rules: + + o A full implementation ascertains both "send" and "recv" + connectivity when it operates as a STUN client and has sent a STUN + Binding Request that resulted in a successful check for all the + components of the media stream (as defined further in ICE). + + o A full or a lite implementation ascertains "recv" connectivity + when it operates as a STUN server and has received a STUN Binding + Request that resulted in a successful response for all the + components of the media stream (as defined further in ICE). + + o A lite implementation ascertains "send" and "recv" connectivity + when the controlling agent has informed it of the nominated pair + for all the components of the media stream. + + A simpler and slightly more delay-prone alternative to the above + rules is for all ICE implementations to ascertain "send" and "recv" + connectivity for a media stream when the ICE state for that media + stream has moved to Completed. + + Note that there is never a need for the answerer to request + confirmation of the connectivity precondition when using ICE: the + answerer can determine the status locally. Also note, that when ICE + is used to verify connectivity preconditions, the precondition is not + satisfied until connectivity has been verified for all the component + transport addresses used by the media stream. For example, with an + RTP-based media stream where RTCP is not suppressed, connectivity + MUST be ascertained for both RTP and RTCP. Finally, it should be + noted, that although connectivity has been ascertained, a new offer/ + answer exchange may be required before media can flow (per ICE). + + The above are merely examples of explicit connectivity verification + mechanisms. Other techniques can be used as well. It is however + RECOMMENDED that ICE be supported by entities that support + connectivity preconditions. Use of ICE has the benefit of working + for all media streams (not just RTP) as well as facilitating NAT and + firewall traversal, which may otherwise interfere with connectivity. + Furthermore, the ICE recommendation provides a baseline to ensure + + + + +Andreasen, et al. Standards Track [Page 8] + +RFC 5898 Connectivity Precondition July 2010 + + + that all entities that require probe traffic to support the + connectivity preconditions have a common way of ascertaining + connectivity. + +4.3. Verifying Connectivity for Connection-Oriented Transports + + Connection-oriented transport protocols generally provide an implicit + connectivity verification mechanism. Connection establishment + involves sending traffic in both directions thereby verifying + connectivity at the transport-protocol level. When a three-way (or + more) handshake for connection establishment succeeds, bi-directional + communication is confirmed and both the "send" and "recv" + preconditions are satisfied whether requested or not. In the case of + TCP for example, once the TCP three-way handshake has completed (SYN, + SYN-ACK, ACK), the TCP connection is established and data can be sent + and received by either party (i.e., both a send and a receive + connectivity precondition has been satisfied). SCTP (Stream Control + Transmission Protocol) [RFC4960] connections have similar semantics + as TCP and SHOULD be treated the same. + + When a connection-oriented transport is part of an offer, it may be + passive, active, or active/passive [RFC4145]. When it is passive, + the offerer expects the answerer to initiate the connection + establishment, and when it is active, the offerer wants to initiate + the connection establishment. When it is active/passive, the + answerer decides. As noted earlier, lack of a media-stream-to-dialog + correlation mechanism can make it difficult to guarantee with whom + connectivity has been ascertained. When the offerer takes on the + passive role, the offerer will not necessarily know which SIP dialog + originated an incoming connection request. If the offerer instead is + active, this problem is avoided. + +5. Connectivity and Other Precondition Types + + The role of a connectivity precondition is to ascertain media stream + connectivity before establishing or modifying a session. The + underlying intent is for the two parties to be able to exchange media + packets successfully. However, connectivity by itself may not fully + satisfy this. Quality of Service, for example, may be required for + the media stream; this can be addressed by use of the "qos" + precondition defined in RFC 3312 [RFC3312]. Similarly, successful + security parameter negotiation may be another prerequisite; this can + be addressed by use of the "sec" precondition defined in RFC 5027 + [RFC5027]. + + + + + + + +Andreasen, et al. Standards Track [Page 9] + +RFC 5898 Connectivity Precondition July 2010 + + +6. Examples + + The first example uses the connectivity precondition with TCP in the + context of a session involving a wireless access medium. Both UAs + use a radio access network that does not allow them to send any data + (not even a TCP SYN) until a radio bearer has been set up for the + connection. Figure 1 shows the message flow of this example (the + required PRACK transaction has been omitted for clarity -- see + [RFC3312] for details): + + A B + | INVITE | + | a=curr:conn e2e none | + | a=des:conn mandatory e2e sendrecv | + | a=setup:holdconn | + |----------------------------------->| + | | + | 183 Session Progress | + | a=curr:conn e2e none | + | a=des:conn mandatory e2e sendrecv | + | a=setup:holdconn | + |<-----------------------------------| + | | + | UPDATE | + | a=curr:conn e2e none | + | a=des:conn mandatory e2e sendrecv | + A's radio | a=setup:actpass | + bearer is +----------------------------------->| + up | | + | 200 OK | + | a=curr:conn e2e none | + | a=des:conn mandatory e2e sendrecv | + | a=setup:active | + |<-----------------------------------| + | | + | | + | | + | | B's radio + |<---TCP Connection Establishment--->+ bearer is up + | | B sends TCP SYN + | | + | | + | 180 Ringing | TCP connection + |<-----------------------------------+ is up + | | B alerts the user + | | + + Figure 1: Message Flow with Two Types of Preconditions + + + +Andreasen, et al. Standards Track [Page 10] + +RFC 5898 Connectivity Precondition July 2010 + + + A sends an INVITE requesting connection-establishment preconditions. + The setup attribute in the offer is set to holdconn [RFC4145] because + A cannot send or receive any data before setting up a radio bearer + for the connection. + + B agrees to use the connectivity precondition by sending a 183 + (Session Progress) response. The setup attribute in the answer is + also set to holdconn because B, like A, cannot send or receive any + data before setting up a radio bearer for the connection. + + When A's radio bearer is ready, A sends an UPDATE to B with a setup + attribute with a value of actpass. This attribute indicates that A + can perform an active or a passive TCP open. A is letting B choose + which endpoint will initiate the connection. + + Since B's radio bearer is not ready yet, B chooses to be the one + initiating the connection and indicates this with a setup attribute + with a value of active. At a later point, when B's radio bearer is + ready, B initiates the TCP connection towards A. + + Once the TCP connection is established successfully, B knows the + "sendrecv" precondition is satisfied, and B proceeds with the session + (i.e., alerts the Callee), and sends a 180 (Ringing) response. + + The second example shows a basic SIP session establishment using SDP + connectivity preconditions and ICE (the required PRACK transaction + and some SDP details have been omitted for clarity). The offerer (A) + is a full ICE implementation whereas the answerer (B) is a lite ICE + implementation. The message flow for this scenario is shown in + Figure 2 below. + + + + + + + + + + + + + + + + + + + + + +Andreasen, et al. Standards Track [Page 11] + +RFC 5898 Connectivity Precondition July 2010 + + + A B + + | | + |-------------(1) INVITE SDP1--------------->| + | | + |<------(2) 183 Session Progress SDP2--------| + | | + |~~~~~ Connectivity check to B ~~~~~~~~~~~~~>| + |<~~~~ Connectivity to B OK ~~~~~~~~~~~~~~~~~| + | | + |-------------(3) UPDATE SDP3--------------->| + | | + |<--------(4) 200 OK (UPDATE) SDP4-----------| + | | + |<-------------(5) 180 Ringing---------------| + | | + | | + + Figure 2: Connectivity Precondition with ICE Connectivity Checks + + SDP1: A includes a mandatory end-to-end connectivity precondition + with a desired status of "sendrecv"; this will ensure media stream + connectivity in both directions before continuing with the session + setup. Since media stream connectivity in either direction is + unknown at this point, the current status is set to "none". A's + local status table (see [RFC3312]) for the connectivity precondition + is as follows: + + Direction | Current | Desired Strength | Confirm + -----------+----------+------------------+---------- + send | no | mandatory | no + recv | no | mandatory | no + + and the resulting offer SDP is: + + a=ice-pwd:asd88fgpdd777uzjYhagZg + a=ice-ufrag:8hhY + m=audio 20000 RTP/AVP 0 + c=IN IP4 192.0.2.1 + a=rtcp:20001 + a=curr:conn e2e none + a=des:conn mandatory e2e sendrecv + a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host + + SDP2: When B receives the offer, B sees the mandatory sendrecv + connectivity precondition. B is a lite ICE implementation and hence + B can only ascertain "recv" connectivity (from B's point of view) + + + + +Andreasen, et al. Standards Track [Page 12] + +RFC 5898 Connectivity Precondition July 2010 + + + from A; thus, B wants A to inform it about connectivity in the other + direction ("send" from B's point of view). B's local status table + therefore looks as follows: + + Direction | Current | Desired Strength | Confirm + -----------+----------+------------------+---------- + send | no | mandatory | no + recv | no | mandatory | no + + Since B is a lite ICE implementation and B wants to ask A for + confirmation about the "send" (from B's point of view) connectivity + precondition, the resulting answer SDP becomes: + + a=ice-lite + a=ice-pwd:qrCA8800133321zF9AIj98 + a=ice-ufrag:H92p + m=audio 30000 RTP/AVP 0 + c=IN IP4 192.0.2.4 + a=rtcp:30001 + a=curr:conn e2e none + a=des:conn mandatory e2e sendrecv + a=conf:conn e2e send + a=candidate:1 1 UDP 2130706431 192.0.2.4 30000 typ host + + Since the "send" and the "recv" connectivity precondition (from B's + point of view) are still not satisfied, session establishment remains + suspended. + + SDP3: When A receives the answer SDP, A notes that B is a lite ICE + implementation and that confirmation was requested for B's "send" + connectivity precondition, which is the "recv" precondition from A's + point of view. A performs a successful send and recv connectivity + check to B by sending an ICE connectivity check to B and receiving + the corresponding response. A's local status table becomes: + + Direction | Current | Desired Strength | Confirm + -----------+----------+------------------+---------- + send | yes | mandatory | no + recv | yes | mandatory | yes + + whereas B's local status table becomes: + + Direction | Current | Desired Strength | Confirm + -----------+----------+------------------+---------- + send | no | mandatory | no + recv | yes | mandatory | no + + + + + +Andreasen, et al. Standards Track [Page 13] + +RFC 5898 Connectivity Precondition July 2010 + + + Since B asked for confirmation about the "recv" connectivity (from + A's point of view), A now sends an UPDATE (5) to B to confirm the + connectivity from A to B: + + a=ice-pwd:asd88fgpdd777uzjYhagZg + a=ice-ufrag:8hhY + m=audio 20000 RTP/AVP 0 + c=IN IP4 192.0.2.1 + a=rtcp:20001 + a=curr:conn e2e sendrecv + a=des:conn mandatory e2e sendrecv + a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host + + B knows it has recv connectivity (verified by ICE as well as A's + UPDATE) and send connectivity (confirmed by A's UPDATE) at this + point. B's local status table becomes: + + Direction | Current | Desired Strength | Confirm + -----------+----------+------------------+---------- + send | yes | mandatory | no + recv | yes | mandatory | no + + and the session can continue. + +7. Security Considerations + + General security considerations for preconditions are discussed in + RFC 3312 [RFC3312] and RFC 4032 [RFC4032]. As discussed in RFC 4032 + [RFC4032], it is strongly RECOMMENDED that S/MIME [RFC3853] integrity + protection be applied to the SDP session descriptions. When the user + agent provides identity services (rather than the proxy server), the + SIP identity mechanism specified in RFC 4474 [RFC4474] provides an + alternative end-to-end integrity protection. Additionally, the + following security issues relate specifically to connectivity + preconditions. + + Connectivity preconditions rely on mechanisms beyond SDP, such as TCP + [RFC0793] connection establishment or ICE connectivity checks + [RFC5245], to establish and verify connectivity between an offerer + and an answerer. An attacker that prevents those mechanisms from + succeeding (e.g., by keeping ICE connectivity checks from arriving at + their destination) can prevent media sessions from being established. + While this attack relates to connectivity preconditions, it is + actually an attack against the connection-establishment mechanisms + used by the endpoints. This attack can be performed in the presence + or in the absence of connectivity preconditions. In their presence, + the whole session setup will be disrupted. In their absence, only + the establishment of the particular stream under attack will be + + + +Andreasen, et al. Standards Track [Page 14] + +RFC 5898 Connectivity Precondition July 2010 + + + disrupted. This specification does not provide any mechanism against + attackers able to block traffic between the endpoints involved in the + session because such an attacker will always be able to launch DoS + (Denial-of-Service) attacks. + + Instead of blocking the connectivity checks, the attacker can + generate forged connectivity checks that would cause the endpoints to + assume that there was connectivity when there was actually no + connectivity. This attack would result in the user experience being + poor because the session would be established without all the media + streams being ready. The same attack can be used, regardless of + whether or not connectivity preconditions are used, to attempt to + hijack a connection. The forged connectivity checks would trick the + endpoints into sending media to the wrong direction. To prevent + these attacks, it is RECOMMENDED that the mechanisms used to check + connectivity are adequately secured by message authentication and + integrity protection. For example, Section 2.5 of [RFC5245] + discusses how message integrity and data origin authentication are + implemented in ICE connectivity checks. + +8. IANA Considerations + + IANA has registered a new precondition type under the Precondition + Types used with SIP subregistry, which is located under the Session + Initiation Protocol (SIP) Parameters registry. + + Precondition-Type Description Reference + ----------------- ----------------------------------- --------- + conn Connectivity precondition [RFC5898] + +9. References + +9.1. 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. + + [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, + "Integration of Resource Management and Session Initiation + Protocol (SIP)", RFC 3312, October 2002. + + + + + + +Andreasen, et al. Standards Track [Page 15] + +RFC 5898 Connectivity Precondition July 2010 + + + [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) + Requirement for the Session Initiation Protocol (SIP)", + RFC 3853, July 2004. + + [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session + Initiation Protocol (SIP) Preconditions Framework", + RFC 4032, March 2005. + + [RFC4474] Peterson, J. and C. Jennings, "Enhancements for + Authenticated Identity Management in the Session + Initiation Protocol (SIP)", RFC 4474, August 2006. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for + Session Description Protocol (SDP) Media Streams", + RFC 5027, October 2007. + + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", RFC 5245, + April 2010. + +9.2. Informative References + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in + the Session Description Protocol (SDP)", RFC 4145, + September 2005. + + [RFC4960] Stewart, R., "Stream Control Transmission Protocol", + RFC 4960, September 2007. + + [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error + Correction", RFC 5109, December 2007. + + [ICE-TCP] Perreault, S., Ed. and J. Rosenberg, "TCP Candidates with + Interactive Connectivity Establishment (ICE)", Work + in Progress, October 2009. + + + + + +Andreasen, et al. Standards Track [Page 16] + +RFC 5898 Connectivity Precondition July 2010 + + +Authors' Addresses + + Flemming Andreasen + Cisco Systems, Inc. + 499 Thornall Street, 8th Floor + Edison, NJ 08837 + USA + + EMail: fandreas@cisco.com + + + Gonzalo Camarillo + Ericsson + Hirsalantie 11 + Jorvas 02420 + Finland + + EMail: Gonzalo.Camarillo@ericsson.com + + + David Oran + Cisco Systems, Inc. + 7 Ladyslipper Lane + Acton, MA 01720 + USA + + EMail: oran@cisco.com + + + Dan Wing + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134 + USA + + EMail: dwing@cisco.com + + + + + + + + + + + + + + + +Andreasen, et al. Standards Track [Page 17] + |