draft-ietf-mmusic-connectivity-precon-06.txt   draft-ietf-mmusic-connectivity-precon-07.txt 
MMUSIC Working Group F. Andreasen MMUSIC Working Group F. Andreasen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track G. Camarillo Intended status: Standards Track G. Camarillo
Expires: September 10, 2009 Ericsson Expires: September 5, 2010 Ericsson
D. Oran D. Oran
D. Wing D. Wing
Cisco Systems Cisco Systems
March 9, 2009 March 4, 2010
Connectivity Preconditions for Session Description Protocol Media Connectivity Preconditions for Session Description Protocol (SDP) Media
Streams Streams
draft-ietf-mmusic-connectivity-precon-06 draft-ietf-mmusic-connectivity-precon-07.txt
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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on September 5, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract 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 BSD License.
This document defines a new connectivity precondition for the Session This document may contain material from IETF Documents or IETF
Description Protocol (SDP) precondition framework. A connectivity Contributions published or made publicly available before November
precondition can be used to delay session establishment or 10, 2008. The person(s) controlling the copyright in some of this
modification until media stream connectivity has been successfully material may not have granted the IETF Trust the right to allow
verified. The method of verification may vary depending on the type modifications of such material outside the IETF Standards Process.
of transport used for the media. For unreliable datagram transports Without obtaining an adequate license from the person(s) controlling
such as UDP, verification involves probing the stream with data or the copyright in such materials, this document may not be modified
control packets. For reliable connection-oriented transports such as outside the IETF Standards Process, and derivative works of it may
TCP, verification can be achieved simply by successful connection not be created outside the IETF Standards Process, except to format
establishment or by probing the connection with data or control it for publication as an RFC or to translate it into languages other
packets, depending on the situation. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Connectivity Precondition Definition . . . . . . . . . . . . . 4 3. Connectivity Precondition Definition . . . . . . . . . . . . . 4
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Operational Semantics . . . . . . . . . . . . . . . . . . 5 3.2. Operational Semantics . . . . . . . . . . . . . . . . . . 5
3.3. Status Type . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Status Type . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Direction Tag . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Direction Tag . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Precondition Strength . . . . . . . . . . . . . . . . . . 6 3.5. Precondition Strength . . . . . . . . . . . . . . . . . . 6
4. Verifying Connectivity . . . . . . . . . . . . . . . . . . . . 7 4. Verifying Connectivity . . . . . . . . . . . . . . . . . . . . 7
4.1. Media Stream to Dialog Correlation . . . . . . . . . . . . 7 4.1. Media Stream to Dialog Correlation . . . . . . . . . . . . 7
4.2. Explicit Connectivity Verification Mechanisms . . . . . . 8 4.2. Explicit Connectivity Verification Mechanisms . . . . . . 8
4.3. Verifying Connectivity for Connection-Oriented 4.3. Verifying Connectivity for Connection-Oriented
Transports . . . . . . . . . . . . . . . . . . . . . . . . 9 Transports . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Connectivity and Other Precondition Types . . . . . . . . . . 10 5. Connectivity and Other Precondition Types . . . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Changes since -05 . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Changes since -03 . . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
9.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 16
9.4. Changes since -01 . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The concept of a Session Description Protocol (SDP) [RFC4566] The concept of a Session Description Protocol (SDP) [RFC4566]
precondition in the Session Initiation Protocol (SIP) [RFC3261] is precondition in the Session Initiation Protocol (SIP) [RFC3261] is
defined in [RFC3312] (updated by [RFC4032]). A precondition is a defined in RFC 3312 [RFC3312] (updated by RFC 4032 [RFC4032]). A
condition that has to be satisfied for a given media stream in order precondition is a condition that has to be satisfied for a given
for session establishment or modification to proceed. When the media stream in order for session establishment or modification to
precondition is not met, session progress is delayed until the proceed. When the precondition is not met, session progress is
precondition is satisfied or the session establishment fails. For delayed until the precondition is satisfied or the session
example, [RFC3312] defines the Quality of Service precondition, which establishment fails. For example, RFC 3312 [RFC3312] defines the
is used to ensure availability of network resources prior to Quality of Service precondition, which is used to ensure availability
establishing a session (i.e., prior to starting alerting the callee). of network resources prior to establishing a session (i.e., prior to
starting alerting the callee).
SIP sessions are typically established in order to setup one or more SIP sessions are typically established in order to setup one or more
media streams. Even though a media stream may be negotiated media streams. Even though a media stream may be negotiated
successfully through an SDP offer-answer exchange, the actual media successfully through an SDP offer-answer exchange, the actual media
stream itself may fail. For example, when there is one or more stream itself may fail. For example, when there is one or more
Network Address Translators (NATs) or firewalls in the media path, 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 stream may not be received by the far end. In cases where
the media is carried over a connection-oriented transport such as TCP the media is carried over a connection-oriented transport such as TCP
[RFC0793], the connection-establishment procedures may fail. The [RFC0793], the connection-establishment procedures may fail. The
connectivity precondition defined in this document ensures that connectivity precondition defined in this document ensures that
session progress is delayed until media stream connectivity has been session progress is delayed until media stream connectivity has been
verified. verified.
The connectivity precondition type defined in this document follows The connectivity precondition type defined in this document follows
the guidelines provided in [RFC4032] to extend the SIP preconditions the guidelines provided in RFC 4032 [RFC4032] to extend the SIP
framework. preconditions framework.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Connectivity Precondition Definition 3. Connectivity Precondition Definition
3.1. Syntax 3.1. Syntax
The connectivity precondition type is defined by the string "conn" The connectivity precondition type is defined by the string "conn"
and hence we modify the grammar found in [RFC3312] as follows: and hence we modify the grammar found in RFC 3312 [RFC3312] and RFC
5027 [RFC5027] as follows:
precondition-type = "conn" / "qos" / token precondition-type = "conn" / "sec" / "qos" / token
This precondition tag is registered with the IANA in Section 8. This precondition tag is registered with the IANA in Section 8.
3.2. Operational Semantics 3.2. Operational Semantics
According to [RFC4032], documents defining new precondition types According to RFC 4032 [RFC4032], documents defining new precondition
need to describe the behavior of UAs (User Agents) from the moment types need to describe the behavior of UAs (User Agents) from the
session establishment is suspended due to a set of preconditions, moment session establishment is suspended due to a set of
until it is resumed when these preconditions are met. An entity that preconditions, until it is resumed when these preconditions are met.
wishes to delay session establishment or modification until media An entity that wishes to delay session establishment or modification
stream connectivity has been established uses this precondition-type until media stream connectivity has been established uses this
in an offer. When a mandatory connectivity precondition is received precondition-type in an offer. When a mandatory connectivity
in an offer, session establishment or modification is delayed until precondition is received in an offer, session establishment or
the connectivity precondition has been met (i.e., until media stream modification is delayed until the connectivity precondition has been
connectivity has been established in the desired direction or met (i.e., until media stream connectivity has been established in
directions). The delay of session establishment defined here implies the desired direction or directions). The delay of session
that alerting of the called party does not occur until the establishment defined here implies that alerting of the called party
precondition has been satisfied. does not occur until the precondition has been satisfied.
Packets may be both sent and received on the media streams in Packets may be both sent and received on the media streams in
question. However, such packets SHOULD be limited to packets that question. However, such packets SHOULD be limited to packets that
are necessary to verify connectivity between the two endpoints are necessary to verify connectivity between the two endpoints
involved on the media stream. That is, the underlying media stream involved on the media stream. That is, the underlying media stream
SHOULD NOT be cut through. For example, ICE connectivity checks SHOULD NOT be cut through. For example, ICE connectivity checks
[I-D.ietf-mmusic-ice] and TCP SYN and ACK packets can be exchanged on [I-D.ietf-mmusic-ice] and TCP SYN and ACK packets can be exchanged on
media streams that support them as a way of verifying connectivity. media streams that support them as a way of verifying connectivity.
Some media streams are described by a single 'm' line but, Some media streams are described by a single 'm' line but,
nevertheless, involve multiple addresses. For example, [RFC5109] nevertheless, involve multiple addresses. For example, RFC 5109
specifies how to send FEC (Forward Error Correction) information as a [RFC5109] specifies how to send FEC (Forward Error Correction)
separate stream (the address for the FEC stream is provided in an information as a separate stream (the address for the FEC stream is
'a=fmtp' line). When a media stream consists of multiple destination provided in an 'a=fmtp' line). When a media stream consists of
addresses, connectivity to all of them MUST be verified in order for multiple destination addresses, connectivity to all of them MUST be
the precondition to be met. In the case of RTP-based media streams, verified in order for the precondition to be met.
RTCP connectivity MAY be verified, but it is not a requirement.
3.3. Status Type 3.3. Status Type
[RFC3312] defines support for two kinds of status types, namely RFC 3312 [RFC3312] defines support for two kinds of status types,
segmented and end-to-end. The connectivity precondition-type defined namely segmented and end-to-end. The connectivity precondition-type
here MUST be used with the end-to-end status type; use of the defined here MUST be used with the end-to-end status type; use of the
segmented status type is undefined. segmented status type is undefined.
3.4. Direction Tag 3.4. Direction Tag
The direction attributes defined in [RFC3312] are interpreted as The direction attributes defined in RFC 3312 [RFC3312] are
follows: interpreted as follows:
o send: the party that generated the session description is sending o send: the party that generated the session description is sending
packets on the media stream to the other party, and the other packets on the media stream to the other party, and the other
party has received at least one of those packets. That is, there party has received at least one of those packets. That is, there
is connectivity in the forward (sending) direction. is connectivity in the forward (sending) direction.
o recv: the other party is sending packets on the media stream to o recv: the other party is sending packets on the media stream to
the party that generated the session description, and this party the party that generated the session description, and this party
has received at least one of those packets. That is, there is has received at least one of those packets. That is, there is
connectivity in the backwards (receiving) direction. connectivity in the backwards (receiving) direction.
skipping to change at page 6, line 33 skipping to change at page 6, line 33
3.5. Precondition Strength 3.5. Precondition Strength
Connectivity preconditions may have a strength-tag of either Connectivity preconditions may have a strength-tag of either
"mandatory" or "optional". "mandatory" or "optional".
When a mandatory connectivity precondition is offered and the When a mandatory connectivity precondition is offered and the
answerer cannot satisfy the connectivity precondition (e.g., because answerer cannot satisfy the connectivity precondition (e.g., because
the offer does not include parameters that enable connectivity to be the offer does not include parameters that enable connectivity to be
verified without media cut through) the offer MUST be rejected as verified without media cut through) the offer MUST be rejected as
described in [RFC3312]. described in RFC 3312 [RFC3312].
When an optional connectivity precondition is offered, the answerer When an optional connectivity precondition is offered, the answerer
MUST generate its answer SDP as soon as possible. Since session MUST generate its answer SDP as soon as possible. Since session
progress is not delayed in this case, it is not known whether the progress is not delayed in this case, it is not known whether the
associated media streams will have connectivity. If the answerer associated media streams will have connectivity. If the answerer
wants to delay session progress until connectivity has been verified, wants to delay session progress until connectivity has been verified,
the answerer MUST increase the strength of the connectivity the answerer MUST increase the strength of the connectivity
precondition by using a strength-tag of "mandatory" in the answer. precondition by using a strength-tag of "mandatory" in the answer.
Note that use of a "mandatory" precondition requires the presence of Note that use of a "mandatory" precondition requires the presence of
a SIP "Require" header with the option tag "precondition". Any SIP a SIP "Require" header with the option tag "precondition". Any SIP
UA that does not support a mandatory precondition will reject such UA that does not support a mandatory precondition will reject such
requests. To get around this issue, an optional connectivity requests. To get around this issue, an optional connectivity
precondition and the SIP "Supported" header with the option tag precondition and the SIP "Supported" header with the option tag
"precondition" can be used instead. "precondition" can be used instead.
Offers with connectivity preconditions in re-INVITEs or UPDATEs Offers with connectivity preconditions in re-INVITEs or UPDATEs
follow the rules given in Section 6 of [RFC3312]. That is: follow the rules given in Section 6 of RFC 3312 [RFC3312]. That is:
"Both user agents SHOULD continue using the old session parameters "Both user agents SHOULD continue using the old session parameters
until all the mandatory preconditions are met. At that moment, until all the mandatory preconditions are met. At that moment,
the user agents can begin using the new session parameters." the user agents can begin using the new session parameters."
4. Verifying Connectivity 4. Verifying Connectivity
Media stream connectivity is ascertained by use of a connectivity Media stream connectivity is ascertained by use of a connectivity
verification mechanism between the media endpoints. A connectivity verification mechanism between the media endpoints. A connectivity
verification mechanism may be an explicit mechanism, such as ICE verification mechanism may be an explicit mechanism, such as ICE
skipping to change at page 7, line 29 skipping to change at page 7, line 29
offer/answer exchange, however it is not identified explicitly. More offer/answer exchange, however it is not identified explicitly. More
than one mechanism may be negotiated, but the offerer and answerer than one mechanism may be negotiated, but the offerer and answerer
need not use the same. The following rules guide which connectivity need not use the same. The following rules guide which connectivity
verification mechanism to use: verification mechanism to use:
1. if an explicit connectivity verification mechanism (e.g., ICE) is 1. if an explicit connectivity verification mechanism (e.g., ICE) is
negotiated, the precondition is met when the mechanism verifies negotiated, the precondition is met when the mechanism verifies
connectivity successfully, otherwise connectivity successfully, otherwise
2. if a connection-oriented transport (e.g., TCP) is negotiated, the 2. if a connection-oriented transport (e.g., TCP) is negotiated, the
precondition is met when the connection is established. precondition is met when the connection is established, otherwise
3. in other cases, an implicit verification mechanism MAY be 3. if an implicit verification mechanism is provided by the
provided by the transport itself or the media stream data using transport itself or the media stream data using the transport,
the transport the precondition is met when the mechanism verifies connectivity
successfully, otherwise
4. if none of the above apply, connectivity cannot be verified 4. connectivity cannot be verified reliably and the connectivity
reliably and the connectivity precondition will never be precondition will never be satisfied if requested.
satisfied if requested.
This document does not mandate any particular connectivity This document does not mandate any particular connectivity
verification mechanism; however, in the following, we provide verification mechanism; however, in the following, we provide
additional considerations for verification mechanisms. additional considerations for verification mechanisms.
4.1. Media Stream to Dialog Correlation 4.1. Media Stream to Dialog Correlation
SIP and SDP do not provide any inherent capabilities for associating SIP and SDP do not provide any inherent capabilities for associating
an incoming media stream packet with a particular dialog. Thus, when an incoming media stream packet with a particular dialog. Thus, when
an offerer is trying to ascertain connectivity, and an incoming media an offerer is trying to ascertain connectivity, and an incoming media
skipping to change at page 10, line 21 skipping to change at page 10, line 21
active, this problem is avoided. active, this problem is avoided.
5. Connectivity and Other Precondition Types 5. Connectivity and Other Precondition Types
The role of a connectivity precondition is to ascertain media stream The role of a connectivity precondition is to ascertain media stream
connectivity before establishing or modifying a session. The connectivity before establishing or modifying a session. The
underlying intent is for the two parties to be able to exchange media underlying intent is for the two parties to be able to exchange media
packets successfully. Connectivity by itself however may not fully packets successfully. Connectivity by itself however may not fully
satisfy this. Quality of Service for example may be required for the satisfy this. Quality of Service for example may be required for the
media stream; this can be addressed by use of the "qos" precondition media stream; this can be addressed by use of the "qos" precondition
defined in [RFC3312]. Similarly, succesful security parameter defined in RFC 3312 [RFC3312]. Similarly, successful security
negotiation may be another prequisite; this can be addressed by use parameter negotiation may be another prerequisite; this can be
of the "sec" precondition defined in [RFC5027]. addressed by use of the "sec" precondition defined in RFC 5027
[RFC5027].
6. Examples 6. Examples
The first example uses the connectivity precondition with TCP in the The first example uses the connectivity precondition with TCP in the
context of a session involving a wireless access medium. Both UAs 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 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 setup for the (not even a TCP SYN) until a radio bearer has been setup for the
connection. Figure 1 shows the message flow of this example (the connection. Figure 1 shows the message flow of this example (the
required PRACK transaction has been omitted for clarity): required PRACK transaction has been omitted for clarity):
skipping to change at page 15, line 11 skipping to change at page 15, line 11
Since B asked for confirmation about the "send" connectivity (from Since B asked for confirmation about the "send" connectivity (from
A's point of view), A now sends an UPDATE (5) to B to confirm the A's point of view), A now sends an UPDATE (5) to B to confirm the
connectivity from A to B: connectivity from A to B:
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=curr:conn e2e send a=curr:conn e2e send
a=des:conn mandatory e2e sendrecv a=des:conn mandatory e2e sendrecv
a=des:conn mandatory e2e sendrecv
a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host
B has both send and recv connectivity confirmed at this point and the B has both send and recv connectivity confirmed at this point and the
session can continue. session can continue.
7. Security Considerations 7. Security Considerations
In addition to the general security considerations for preconditions General security considerations for preconditions are discussed in
provided in [RFC3312], the following security issues, which are RFC 3312 [RFC3312] and RFC 4032 [RFC4032]. As discussed in RFC 4032
specific to connectivity preconditions, should be considered. [RFC4032], it is strongly RECOMMENDED that integrity protection be
applied to the SDP session descriptions. S/MIME [RFC3853]
protection, as described in RFC 3261 [RFC3261]. 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 Connectivity preconditions rely on mechanisms beyond SDP such as TCP
TCP[RFC0793] connection establishment, or ICE connectivity checks [RFC0793] connection establishment, or ICE connectivity checks
[I-D.ietf-mmusic-ice] to establish and verify connectivity between an [I-D.ietf-mmusic-ice] to establish and verify connectivity between an
offerer and an answerer. An attacker that prevents those mechanism offerer and an answerer. An attacker that prevents those mechanisms
from succeeding can prevent media sessions from being established and from succeeding (e.g., by keeping ICE connectivity checks from
hence it is RECOMMENDED that such mechanisms are adequately secured arriving to their destination) can prevent media sessions from being
by message authentication and integrity protection. Also, the established. While this attack relates to connectivity
mechanisms SHOULD consider how to prevent denial of service attacks. preconditions, it is actually an attack against the connection
Similarly, an attacker that can forge packets for these mechanisms establishment mechanisms used by the endpoints. This attack can be
can enable sessions to be established when there in fact is no media performed in the presence or in the absence of connectivity
connectivity, which may lead to a poor user experience. preconditions. In their presence, the whole session setup will be
Authentication and integrity protection of such mechanisms can disrupted. In their absence, only the establishment of the
prevent this type of attacks and hence use of it is RECOMMENDED. particular stream under attack will be 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.
It is also strongly RECOMMENDED that integrity protection be applied Instead of blocking the connectivity checks, the attacker can
to the SDP session descriptions. S/MIME [RFC3853] provides such end- generate forged connectivity checks that would cause the endpoints to
to-end integrity protection, as described in [RFC3261]. assume that there was connectivity when there was actually no
connectivity. This attack would result in a poor user's experience
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
[I-D.ietf-mmusic-ice] discusses how message integrity and data origin
authentication are implemented in ICE connectivity checks.
8. IANA Considerations 8. IANA Considerations
IANA is hereby requested to register a new precondition type under IANA is hereby requested to register a new precondition type under
the Precondition Types used with SIP subregistry, which is located the Precondition Types used with SIP subregistry, which is located
under the Session Initiation Protocol (SIP) Parameters registry. under the Session Initiation Protocol (SIP) Parameters registry.
Precondition-Type Description Reference Precondition-Type Description Reference
----------------- ----------------------------------- --------- ----------------- ----------------------------------- ---------
conn Connectivity precondition [RFCxxxx] conn Connectivity precondition [RFCxxxx]
[Note to the RFC Editor: replace RFCxxxx with the number assigned to [Note to the RFC Editor: replace RFCxxxx with the number assigned to
this RFC.] this RFC.]
9. Change Log 9. References
9.1. Changes since -05
Removed RTP No-Op. Fixed ABNF.
9.2. Changes since -03
Minor fixes here and there.
9.3. Changes since -02
Connectivity preconditions are now mechanism agnostic. Clarified
when and how to use ICE, RTP No-Op, and connection establishment
procedures to check connectivity. Clarified relation with other
precondition types.
9.4. Changes since -01
There are no changes since the previous version of the document.
10. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation "Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
Requirement for the Session Initiation Protocol (SIP)", Requirement for the Session Initiation Protocol (SIP)",
RFC 3853, July 2004. RFC 3853, July 2004.
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session
Initiation Protocol (SIP) Preconditions Framework", Initiation Protocol (SIP) Preconditions Framework",
RFC 4032, March 2005. 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 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
10.2. Informative References [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for
Session Description Protocol (SDP) Media Streams",
RFC 5027, October 2007.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
9.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Session Description Protocol (SDP) Media Streams", Correction", RFC 5109, December 2007.
RFC 5027, October 2007.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-mmusic-ice-tcp] [I-D.ietf-mmusic-ice-tcp]
Rosenberg, J., "TCP Candidates with Interactive Perreault, S. and J. Rosenberg, "TCP Candidates with
Connectivity Establishment (ICE)", Interactive Connectivity Establishment (ICE)",
draft-ietf-mmusic-ice-tcp-07 (work in progress), draft-ietf-mmusic-ice-tcp-08 (work in progress),
July 2008. October 2009.
Authors' Addresses Authors' Addresses
Flemming Andreasen Flemming Andreasen
Cisco Systems, Inc. Cisco Systems, Inc.
499 Thornall Street, 8th Floor 499 Thornall Street, 8th Floor
Edison, NJ 08837 Edison, NJ 08837
USA USA
Email: fandreas@cisco.com Email: fandreas@cisco.com
 End of changes. 37 change blocks. 
152 lines changed or deleted 160 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/