draft-ietf-mmusic-ice-sip-sdp-26.txt   draft-ietf-mmusic-ice-sip-sdp-27.txt 
MMUSIC M. Petit-Huguenin MMUSIC M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Obsoletes: 5245 (if approved) S. Nandakumar Obsoletes: 5245 (if approved) S. Nandakumar
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: November 18, 2019 A. Keranen Expires: November 19, 2019 A. Keranen
Ericsson Ericsson
May 17, 2019 May 18, 2019
Session Description Protocol (SDP) Offer/Answer procedures for Session Description Protocol (SDP) Offer/Answer procedures for
Interactive Connectivity Establishment (ICE) Interactive Connectivity Establishment (ICE)
draft-ietf-mmusic-ice-sip-sdp-26 draft-ietf-mmusic-ice-sip-sdp-27
Abstract Abstract
This document describes Session Description Protocol (SDP) Offer/ This document describes Session Description Protocol (SDP) Offer/
Answer procedures for carrying out Interactive Connectivity Answer procedures for carrying out Interactive Connectivity
Establishment (ICE) between the agents. Establishment (ICE) between the agents.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 18, 2019. This Internet-Draft will expire on November 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
3.3.1. Sending the Initial Offer . . . . . . . . . . . . . . 7 3.3.1. Sending the Initial Offer . . . . . . . . . . . . . . 7
3.3.2. Sending the Initial Answer . . . . . . . . . . . . . 8 3.3.2. Sending the Initial Answer . . . . . . . . . . . . . 8
3.3.3. Receiving the Initial Answer . . . . . . . . . . . . 9 3.3.3. Receiving the Initial Answer . . . . . . . . . . . . 9
3.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 9 3.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 9
3.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10 3.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10
3.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 10 3.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 10
3.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 12 3.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 12
3.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 14 3.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 14
4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 16 4.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 16
4.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 18 4.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 19
4.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 19 4.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 19
4.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 19 4.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 20
4.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 20 4.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 21
4.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 21 4.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 21
5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 22
6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 22 6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 22
6.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 22 6.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 23
6.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 23 6.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 24
6.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 24 6.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 24
6.3. Interactions with Forking . . . . . . . . . . . . . . . . 24 6.3. Interactions with Forking . . . . . . . . . . . . . . . . 24
6.4. Interactions with Preconditions . . . . . . . . . . . . . 24 6.4. Interactions with Preconditions . . . . . . . . . . . . . 25
6.5. Interactions with Third Party Call Control . . . . . . . 24 6.5. Interactions with Third Party Call Control . . . . . . . 25
7. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 25 7. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 25 8.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 26
8.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 25 8.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 26
8.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 26 8.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 26
8.2.2. Interactions with Application Layer Gateways and SIP 26 8.2.2. Interactions with Application Layer Gateways and SIP 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 27 9.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 28
9.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 28 9.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 28
9.1.2. remote-candidates Attribute . . . . . . . . . . . . . 28 9.1.2. remote-candidates Attribute . . . . . . . . . . . . . 29
9.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 29 9.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 29
9.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 29 9.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 30
9.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 30 9.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 30
9.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 30 9.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 31
9.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 31 9.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 31
9.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 31 9.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 32
9.2. Interactive Connectivity Establishment (ICE) Options 9.2. Interactive Connectivity Establishment (ICE) Options
Registry . . . . . . . . . . . . . . . . . . . . . . . . 32 Registry . . . . . . . . . . . . . . . . . . . . . . . . 32
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . 35
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. The remote-candidates Attribute . . . . . . . . . . 38 Appendix B. The remote-candidates Attribute . . . . . . . . . . 38
Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 38 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 39
Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 39 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 40
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 40 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This document describes how Interactive Connectivity Establishment This document describes how Interactive Connectivity Establishment
(ICE) is used with Session Description Protocol (SDP) offer/answer (ICE) is used with Session Description Protocol (SDP) offer/answer
[RFC3264]. The ICE specification [RFC8445] describes procedures that [RFC3264]. The ICE specification [RFC8445] describes procedures that
are common to all usages of ICE and this document gives the are common to all usages of ICE and this document gives the
additional details needed to use ICE with SDP offer/answer. additional details needed to use ICE with SDP offer/answer.
2. Terminology 2. Terminology
skipping to change at page 4, line 15 skipping to change at page 4, line 15
2119 [RFC2119]. 2119 [RFC2119].
Readers should be familiar with the terminology defined in [RFC3264], Readers should be familiar with the terminology defined in [RFC3264],
in [RFC8445] and the following: in [RFC8445] and the following:
Default Destination/Candidate: The default destination for a Default Destination/Candidate: The default destination for a
component of a data stream is the transport address that would be component of a data stream is the transport address that would be
used by an agent that is not ICE aware. A default candidate for a used by an agent that is not ICE aware. A default candidate for a
component is one whose transport address matches the default component is one whose transport address matches the default
destination for that component. For the RTP component, the destination for that component. For the RTP component, the
default IP address is in the "c=" line of the SDP, and the port is default connection address is in the "c=" line of the SDP, and the
in the "m=" line. For the RTCP component, the address and port port and transport protocol are in the "m=" line. For the RTCP
are indicated using the "a=rtcp" attribute defined in [RFC3605], component, the address and port are indicated using the "a=rtcp"
if present; otherwise, the RTCP component address is same as the attribute defined in [RFC3605], if present; otherwise, the RTCP
address of the RTP component, and its port is one greater than the component address is same as the address of the RTP component, and
port of the RTP component. its port is one greater than the port of the RTP component.
3. SDP Offer/Answer Procedures 3. SDP Offer/Answer Procedures
3.1. Introduction 3.1. Introduction
[RFC8445] defines ICE candidate exchange as the process for ICE [RFC8445] defines ICE candidate exchange as the process for ICE
agents (Initiator and Responder) to exchange their candidate agents (Initiator and Responder) to exchange their candidate
information required for ICE processing at the agents. For the information required for ICE processing at the agents. For the
purposes of this specification, the candidate exchange process purposes of this specification, the candidate exchange process
corresponds to the [RFC3264] Offer/Answer protocol and the corresponds to the [RFC3264] Offer/Answer protocol and the
skipping to change at page 5, line 12 skipping to change at page 5, line 12
Each data stream [RFC8445] is represented by an SDP media description Each data stream [RFC8445] is represented by an SDP media description
("m=" section). ("m=" section).
3.2.1.2. Candidates 3.2.1.2. Candidates
With in a "m=" section, each candidate (including the default With in a "m=" section, each candidate (including the default
candidate) associated with the data stream is represented by an SDP candidate) associated with the data stream is represented by an SDP
candidate attribute. candidate attribute.
Prior to nomination, the "c=" line associated with an "m=" section Prior to nomination, the "c=" line associated with an "m=" section
contains the IP address of the default candidate, while the "m=" line contains the connection address of the default candidate, while the
contains the port and transport of the default candidate for that "m=" line contains the port and transport protocol of the default
"m=" section. candidate for that "m=" section.
After nomination, the "c=" line for a given "m=" section contains the After nomination, the "c=" line for a given "m=" section contains the
IP address of the nominated candidate (the local candidate of the connection address of the nominated candidate (the local candidate of
nominated candidate pair) and the "m=" line contains the port and the nominated candidate pair) and the "m=" line contains the port and
transport corresponding to the nominated candidate for that "m=" transport protocol corresponding to the nominated candidate for that
section. "m=" section.
3.2.1.3. Username and Password 3.2.1.3. Username and Password
The ICE username is represented by an SDP ice-ufrag attribute and the The ICE username is represented by an SDP ice-ufrag attribute and the
ICE password is represented by an SDP ice-pwd attribute. ICE password is represented by an SDP ice-pwd attribute.
3.2.1.4. Lite Implementations 3.2.1.4. Lite Implementations
An ICE lite implementation [RFC8445] MUST include an SDP ice-lite An ICE lite implementation [RFC8445] MUST include an SDP ice-lite
attribute. A full implementation MUST NOT include that attribute. attribute. A full implementation MUST NOT include that attribute.
skipping to change at page 6, line 39 skipping to change at page 6, line 39
Once an agent has provided its local candidates to its peer in an SDP Once an agent has provided its local candidates to its peer in an SDP
offer or answer, the agent MUST be prepared to receive STUN offer or answer, the agent MUST be prepared to receive STUN
connectivity check Binding requests on those candidates. connectivity check Binding requests on those candidates.
3.2.5. Verifying ICE Support Procedures 3.2.5. Verifying ICE Support Procedures
The agents will proceed with the ICE procedures defined in [RFC8445] The agents will proceed with the ICE procedures defined in [RFC8445]
and this specification if, for each data stream in the SDP it and this specification if, for each data stream in the SDP it
received, the default destination for each component of that data received, the default destination for each component of that data
stream appears in a candidate attribute. For example, in the case of stream appears in a candidate attribute. For example, in the case of
RTP, the IP address and port in the "c=" and "m=" lines, RTP, the connection address, port and transport protocol are in the
respectively, appear in a candidate attribute and the value in the "c=" and "m=" lines, respectively, appear in a candidate attribute
rtcp attribute appears in a candidate attribute. and the value in the rtcp attribute appears in a candidate attribute.
If this condition is not met, the agents MUST process the SDP based If this condition is not met, the agents MUST process the SDP based
on normal [RFC3264] procedures, without using any of the ICE on normal [RFC3264] procedures, without using any of the ICE
mechanisms described in the remainder of this specification with the mechanisms described in the remainder of this specification with the
few exceptions noted below: few exceptions noted below:
1. The presence of certain application layer gateways MAY modify the 1. The presence of certain application layer gateways MAY modify the
transport address information as described in Section 8.2.2. The transport address information as described in Section 8.2.2. The
behavior of the responding agent in such a situation is behavior of the responding agent in such a situation is
implementation defined. Informally, the responding agent MAY implementation defined. Informally, the responding agent MAY
skipping to change at page 7, line 16 skipping to change at page 7, line 16
processing with that transport address included. Alternatively, processing with that transport address included. Alternatively,
the responding agent MAY include an "a=ice-mismatch" attribute in the responding agent MAY include an "a=ice-mismatch" attribute in
its answer and MAY also omit a=candidate attributes for such data its answer and MAY also omit a=candidate attributes for such data
streams. streams.
2. The transport address from the peer for the default destination 2. The transport address from the peer for the default destination
correspond to IP address values "0.0.0.0"/"::" and port value of correspond to IP address values "0.0.0.0"/"::" and port value of
"9". This MUST not be considered as a ICE failure by the peer "9". This MUST not be considered as a ICE failure by the peer
agent and the ICE processing MUST continue as usual. agent and the ICE processing MUST continue as usual.
Also to note, this specification provides no guidance on how an In some cases, controlling/initiator agent may receive the SDP answer
controlling/initiator agent should proceed in scenarios where the the that may omit "a=candidate" attributes for the media streams, and
SDP answer includes "a=ice-mismatch" from the peer. instead include a session level "a=ice-mismatch" attribute. This
signals to the offerer that the answerer supports ICE, but that ICE
processing was not used for this session. This specification
provides no guidance on how an agent should proceed in such a failure
case.
3.2.6. SDP Example 3.2.6. SDP Example
The following is an example SDP message that includes ICE attributes The following is an example SDP message that includes ICE attributes
(lines folded for readability): (lines folded for readability):
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s= s=
c=IN IP4 192.0.2.3 c=IN IP4 192.0.2.3
skipping to change at page 9, line 42 skipping to change at page 9, line 46
specification. specification.
3.3.4. Concluding ICE 3.3.4. Concluding ICE
Once the state of each check list is Completed, and if the agent is Once the state of each check list is Completed, and if the agent is
the controlling agent, it nominates a candidate pair [RFC8445] and the controlling agent, it nominates a candidate pair [RFC8445] and
checks for each data stream whether the nominated pair matches the checks for each data stream whether the nominated pair matches the
default candidate pair. If there are one or more data streams with a default candidate pair. If there are one or more data streams with a
match, and the peer did not indicate support for the 'ice2' ice- match, and the peer did not indicate support for the 'ice2' ice-
option, the controlling agent MUST generate a subsequent offer option, the controlling agent MUST generate a subsequent offer
(Section 3.4.1), in which the IP address, port and transport in the (Section 3.4.1), in which the connection address, port and transport
"c=" and "m=" lines associated with each data stream match the protocol in the "c=" and "m=" lines associated with each data stream
corresponding local information of the nominated pair for that data match the corresponding local information of the nominated pair for
stream. that data stream.
However, If the support for 'ice2' ice-option is in use, the However, If the support for 'ice2' ice-option is in use, the
nominated candidate is noted and sent in the subsequent offer/answer nominated candidate is noted and sent in the subsequent offer/answer
exchange as the default candidate and no updated offer is needed to exchange as the default candidate and no updated offer is needed to
fix the default candidate. fix the default candidate.
Also as described in [RFC8445], once the controlling agent has Also as described in [RFC8445], once the controlling agent has
nominated a candidate pair for a data stream, the agent MUST NOT nominated a candidate pair for a data stream, the agent MUST NOT
nominate another pair for that data stream during the lifetime of the nominate another pair for that data stream during the lifetime of the
ICE session (i.e. until ICE is restarted). ICE session (i.e. until ICE is restarted).
skipping to change at page 10, line 28 skipping to change at page 10, line 33
3.4.1. Sending Subsequent Offer 3.4.1. Sending Subsequent Offer
3.4.1.1. Procedures for All Implementations 3.4.1.1. Procedures for All Implementations
3.4.1.1.1. ICE Restarts 3.4.1.1.1. ICE Restarts
An agent MAY restart ICE processing for an existing data stream An agent MAY restart ICE processing for an existing data stream
[RFC8445]. [RFC8445].
The rules governing the ICE restart imply that setting the IP address The rules governing the ICE restart imply that setting the connection
in the "c=" line to 0.0.0.0 (for IPv4)/ :: (for IPv6) will cause an address in the "c=" line to 0.0.0.0 (for IPv4)/ :: (for IPv6) will
ICE restart. Consequently, ICE implementations MUST NOT utilize this cause an ICE restart. Consequently, ICE implementations MUST NOT
mechanism for call hold, and instead MUST use a=inactive and utilize this mechanism for call hold, and instead MUST use a=inactive
a=sendonly as described in [RFC3264]. and a=sendonly as described in [RFC3264].
To restart ICE, an agent MUST change both the ice-pwd and the ice- To restart ICE, an agent MUST change both the ice-pwd and the ice-
ufrag for the data stream in an offer. However, it is permissible to ufrag for the data stream in an offer. However, it is permissible to
use a session-level attribute in one offer, but to provide the same use a session-level attribute in one offer, but to provide the same
ice-pwd or ice-ufrag as a media-level attribute in a subsequent ice-pwd or ice-ufrag as a media-level attribute in a subsequent
offer. This MUST NOT be considered as ICE restart. offer. This MUST NOT be considered as ICE restart.
An agent sets the rest of the ice related fields in the SDP for this An agent sets the rest of the ice related fields in the SDP for this
data stream as it would in an initial offer of this data stream (see data stream as it would in an initial offer of this data stream (see
Section 3.2.1). Consequently, the set of candidates MAY include Section 3.2.1). Consequently, the set of candidates MAY include
skipping to change at page 11, line 33 skipping to change at page 11, line 40
additional candidates it did not offer previously, but which it has additional candidates it did not offer previously, but which it has
gathered since the last offer/ answer exchange, including peer gathered since the last offer/ answer exchange, including peer
reflexive candidates. reflexive candidates.
The agent MAY change the default destination for media. As with The agent MAY change the default destination for media. As with
initial offers, there MUST be a set of candidate attributes in the initial offers, there MUST be a set of candidate attributes in the
offer matching this default destination. offer matching this default destination.
3.4.1.2.2. After Nomination 3.4.1.2.2. After Nomination
Once a candidate pair has been nominated for a data stream, the IP Once a candidate pair has been nominated for a data stream, the
address, port and transport in each "c=" and "m=" line associated connection address, port and transport protocol in each "c=" and "m="
with that data stream MUST match the data associated with the line associated with that data stream MUST match the data associated
nominated pair for that data stream. In addition, the offerer only with the nominated pair for that data stream. In addition, the
includes SDP candidates representing the local candidates of the offerer only includes SDP candidates representing the local
nominated candidate pair. The offerer MUST NOT include any other SDP candidates of the nominated candidate pair. The offerer MUST NOT
candidate attributes in the subsequent offer. include any other SDP candidate attributes in the subsequent offer.
In addition, if the agent is controlling, it MUST include the In addition, if the agent is controlling, it MUST include the
a=remote-candidates attribute for each data stream whose check list a=remote-candidates attribute for each data stream whose check list
is in the completed state. The attribute contains the remote is in the completed state. The attribute contains the remote
candidates corresponding to the nominated pair in the valid list for candidates corresponding to the nominated pair in the valid list for
each component of that data stream. It is needed to avoid a race each component of that data stream. It is needed to avoid a race
condition whereby the controlling agent chooses its pairs, but the condition whereby the controlling agent chooses its pairs, but the
updated offer beats the connectivity checks to the controlled agent, updated offer beats the connectivity checks to the controlled agent,
which doesn't even know these pairs are valid, let alone selected. which doesn't even know these pairs are valid, let alone selected.
See Appendix B for elaboration on this race condition. See Appendix B for elaboration on this race condition.
skipping to change at page 26, line 9 skipping to change at page 26, line 37
In addition to attacks where the attacker is a third party trying to In addition to attacks where the attacker is a third party trying to
insert fake offers, answers, or STUN messages, there are several insert fake offers, answers, or STUN messages, there are several
attacks possible with ICE when the attacker is an authenticated and attacks possible with ICE when the attacker is an authenticated and
valid participant in the ICE exchange. valid participant in the ICE exchange.
8.2.1. The Voice Hammer Attack 8.2.1. The Voice Hammer Attack
The voice hammer attack is an amplification attack. In this attack, The voice hammer attack is an amplification attack. In this attack,
the attacker initiates sessions to other agents, and maliciously the attacker initiates sessions to other agents, and maliciously
includes the IP address and port of a DoS target as the destination includes the connection address and port of a DoS target as the
for media traffic signaled in the SDP. This causes substantial destination for media traffic signaled in the SDP. This causes
amplification; a single offer/answer exchange can create a continuing substantial amplification; a single offer/answer exchange can create
flood of media packets, possibly at high rates (consider video a continuing flood of media packets, possibly at high rates (consider
sources). This attack is not specific to ICE, but ICE can help video sources). This attack is not specific to ICE, but ICE can help
provide remediation. provide remediation.
Specifically, if ICE is used, the agent receiving the malicious SDP Specifically, if ICE is used, the agent receiving the malicious SDP
will first perform connectivity checks to the target of media before will first perform connectivity checks to the target of media before
sending media there. If this target is a third-party host, the sending media there. If this target is a third-party host, the
checks will not succeed, and media is never sent. checks will not succeed, and media is never sent.
Unfortunately, ICE doesn't help if it's not used, in which case an Unfortunately, ICE doesn't help if it's not used, in which case an
attacker could simply send the offer without the ICE parameters. attacker could simply send the offer without the ICE parameters.
However, in environments where the set of clients is known, and is However, in environments where the set of clients is known, and is
skipping to change at page 27, line 6 skipping to change at page 27, line 34
long as the ALG correctly modifies the SDP. A correct ALG long as the ALG correctly modifies the SDP. A correct ALG
implementation behaves as follows: implementation behaves as follows:
o The ALG does not modify the "m=" and "c=" lines or the rtcp o The ALG does not modify the "m=" and "c=" lines or the rtcp
attribute if they contain external addresses. attribute if they contain external addresses.
o If the "m=" and "c=" lines contain internal addresses, the o If the "m=" and "c=" lines contain internal addresses, the
modification depends on the state of the ALG: modification depends on the state of the ALG:
* If the ALG already has a binding established that maps an * If the ALG already has a binding established that maps an
external port to an internal IP address and port matching the external port to an internal connection address and port
values in the "m=" and "c=" lines or rtcp attribute, the ALG matching the values in the "m=" and "c=" lines or rtcp
uses that binding instead of creating a new one. attribute, the ALG uses that binding instead of creating a new
one.
* If the ALG does not already have a binding, it creates a new * If the ALG does not already have a binding, it creates a new
one and modifies the SDP, rewriting the "m=" and "c=" lines and one and modifies the SDP, rewriting the "m=" and "c=" lines and
rtcp attribute. rtcp attribute.
Unfortunately, many ALGs are known to work poorly in these corner Unfortunately, many ALGs are known to work poorly in these corner
cases. ICE does not try to work around broken ALGs, as this is cases. ICE does not try to work around broken ALGs, as this is
outside the scope of its functionality. ICE can help diagnose these outside the scope of its functionality. ICE can help diagnose these
conditions, which often show up as a mismatch between the set of conditions, which often show up as a mismatch between the set of
candidates and the "m=" and "c=" lines and rtcp attributes. The ice- candidates and the "m=" and "c=" lines and rtcp attributes. The ice-
 End of changes. 28 change blocks. 
73 lines changed or deleted 78 lines changed or added

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