draft-ietf-mmusic-ice-sip-sdp-38.txt   draft-ietf-mmusic-ice-sip-sdp-39.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: February 9, 2020 A. Keranen Expires: February 14, 2020 C. Holmberg
A. Keranen
Ericsson Ericsson
R. Shpount R. Shpount
TurboBridge TurboBridge
C. Holmberg August 13, 2019
Ericsson
August 8, 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-38 draft-ietf-mmusic-ice-sip-sdp-39
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.
This document obsoletes RFC 5245. This document obsoletes RFC 5245.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 41
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 February 9, 2020. This Internet-Draft will expire on February 14, 2020.
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 48 skipping to change at page 2, line 45
4.2.4. STUN Considerations . . . . . . . . . . . . . . . . . 6 4.2.4. STUN Considerations . . . . . . . . . . . . . . . . . 6
4.2.5. Verifying ICE Support Procedures . . . . . . . . . . 7 4.2.5. Verifying ICE Support Procedures . . . . . . . . . . 7
4.2.6. SDP Example . . . . . . . . . . . . . . . . . . . . . 8 4.2.6. SDP Example . . . . . . . . . . . . . . . . . . . . . 8
4.3. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 8 4.3. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 8
4.3.1. Sending the Initial Offer . . . . . . . . . . . . . . 8 4.3.1. Sending the Initial Offer . . . . . . . . . . . . . . 8
4.3.2. Sending the Initial Answer . . . . . . . . . . . . . 9 4.3.2. Sending the Initial Answer . . . . . . . . . . . . . 9
4.3.3. Receiving the Initial Answer . . . . . . . . . . . . 10 4.3.3. Receiving the Initial Answer . . . . . . . . . . . . 10
4.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 10 4.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 10
4.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 11 4.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 11
4.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 11 4.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 11
4.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 13 4.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 14
4.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 16 4.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 16
5. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 18 5.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 18
5.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 20 5.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 20
5.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 20 5.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 21
5.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 21 5.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 21
5.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 22 5.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 22
5.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 22 5.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 22
6. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 23
7. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 23
7.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 23 7.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 23
7.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 23 7.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 24
7.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 24 7.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 25
7.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 25 7.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 25
7.3. Interactions with Forking . . . . . . . . . . . . . . . . 25 7.3. Interactions with Forking . . . . . . . . . . . . . . . . 25
7.4. Interactions with Preconditions . . . . . . . . . . . . . 25 7.4. Interactions with Preconditions . . . . . . . . . . . . . 25
7.5. Interactions with Third Party Call Control . . . . . . . 26 7.5. Interactions with Third Party Call Control . . . . . . . 26
8. Interactions with Application Layer Gateways and SIP . . . . 26 8. Interactions with Application Layer Gateways and SIP . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 27 9.1. IP Address Privacy . . . . . . . . . . . . . . . . . . . 28
9.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 28 9.2. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 28
9.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 28 9.3. The Voice Hammer Attack . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 28 10.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 29
10.1.1. candidate Attribute . . . . . . . . . . . . . . . . 29 10.1.1. candidate Attribute . . . . . . . . . . . . . . . . 29
10.1.2. remote-candidates Attribute . . . . . . . . . . . . 29 10.1.2. remote-candidates Attribute . . . . . . . . . . . . 29
10.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 30 10.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 30
10.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 30 10.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 30
10.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . 31 10.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . 31
10.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . 31 10.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . 31
10.1.7. ice-options Attribute . . . . . . . . . . . . . . . 32 10.1.7. ice-options Attribute . . . . . . . . . . . . . . . 32
10.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 32 10.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 32
10.2. Interactive Connectivity Establishment (ICE) Options 10.2. Interactive Connectivity Establishment (ICE) Options
Registry . . . . . . . . . . . . . . . . . . . . . . . . 33 Registry . . . . . . . . . . . . . . . . . . . . . . . . 33
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 10.3. Candidate Attribute Extension Subregistry Establishment 33
12. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 33 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
12. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . 36 13.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 37
Appendix B. The remote-candidates Attribute . . . . . . . . . . 38 Appendix B. The remote-candidates Attribute . . . . . . . . . . 39
Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 39 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 40
Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 40 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 41
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 41 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
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.
This document obsoletes RFC 5245. This document obsoletes RFC 5245.
skipping to change at page 6, line 28 skipping to change at page 6, line 23
If the port value associated with an "m=" section is set to zero If the port value associated with an "m=" section is set to zero
(implying a disabled stream) as defined in section 8.2 of [RFC3264], (implying a disabled stream) as defined in section 8.2 of [RFC3264],
the agent SHOULD NOT include ICE-related SDP candidate attributes in the agent SHOULD NOT include ICE-related SDP candidate attributes in
that "m=" section, unless an SDP extension specifying otherwise is that "m=" section, unless an SDP extension specifying otherwise is
used. used.
4.2.2. RTP/RTCP Considerations 4.2.2. RTP/RTCP Considerations
If an agent utilizes both RTP and RTCP, and separate ports are used If an agent utilizes both RTP and RTCP, and separate ports are used
for RTP and RTCP, the agent MUST include SDP candidate attributes for for RTP and RTCP, the agent MUST include SDP candidate attributes for
both the RTP and RTCP components and SDP rtcp attribute SHOULD be both the RTP and RTCP components.
included in the "m=" section, as described in [RFC3605]
In the cases where the port number for the RTCP is one higher than The agent includes an SDP rtcp attribute following the procedures in
the RTP port and the RTCP component address is the same as the [RFC3605]. Hence, in the cases where the RTCP port value is one
address of the RTP component, the SDP rtcp attribute MAY be omitted. higher than the RTP port value and the RTCP component address the
same as the address of the RTP component, the SDP rtcp attribute
might be omitted.
NOTE: [RFC5245] required that an agent always includes the SDP rtcp
attribute, even if the RTCP port value was one higher than the RTP
port value. This specification aligns the rtcp attribute procedures
with [RFC3605].
If the agent does not utilize RTCP, it indicates that by including If the agent does not utilize RTCP, it indicates that by including
b=RS:0 and b=RR:0 SDP attributes, as described in [RFC3556]. b=RS:0 and b=RR:0 SDP attributes, as described in [RFC3556].
4.2.3. Determining Role 4.2.3. Determining Role
The offerer acts as the Initiating agent. The answerer acts as the The offerer acts as the Initiating agent. The answerer acts as the
Responding agent. The ICE roles (controlling and controlled) are Responding agent. The ICE roles (controlling and controlled) are
determined using the procedures in [RFC8445]. determined using the procedures in [RFC8445].
4.2.4. STUN Considerations 4.2.4. STUN Considerations
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.
4.2.5. Verifying ICE Support Procedures 4.2.5. Verifying ICE Support Procedures
An ICE agent is considered to indicate support of ICE by including at
least the SDP ice-pwd and ice-ufrag attributes in an offer or answer.
An ICE agent compliant with this specification MUST also include an
SDP ice-options attribute with an "ice2" attribute value.
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 connection address, port, and transport protocol in the "c=" RTP, the connection address, port, and transport protocol in the "c="
and "m=" lines, respectively, appear in a candidate attribute and the and "m=" lines, respectively, appear in a candidate attribute and the
value in the rtcp attribute appears in a candidate attribute. value in the rtcp attribute appears in a candidate attribute.
This specification provides no guidance on how an agent should This specification provides no guidance on how an agent should
proceed in the cases where the above condition is not met with the proceed in the cases where the above condition is not met with the
skipping to change at page 9, line 41 skipping to change at page 9, line 46
attributes and with default destination set to the IP address values attributes and with default destination set to the IP address values
"0.0.0.0"/"::" and port value of "9". This implies that the "0.0.0.0"/"::" and port value of "9". This implies that the
answering agent is only going to use peer reflexive candidates or answering agent is only going to use peer reflexive candidates or
that additional candidates would be provided in subsequent signaling that additional candidates would be provided in subsequent signaling
messages. messages.
Once the answerer has sent the answer, it can start performing Once the answerer has sent the answer, it can start performing
connectivity checks towards the peer candidates that were provided in connectivity checks towards the peer candidates that were provided in
the offer. the offer.
If the offer does not indicate support of ICE, the answerer MUST NOT If the offer does not indicate support of ICE Section 4.2.5, the
accept the usage of ICE. If the answerer still accepts the offer, answerer MUST NOT accept the usage of ICE. If the answerer still
the answerer MUST NOT include any ICE-related SDP attributes in the accepts the offer, the answerer MUST NOT include any ICE-related SDP
answer. Instead the answerer will generate the answer according to attributes in the answer. Instead the answerer will generate the
normal offer/answer procedures [RFC3264]. answer according to normal offer/answer procedures [RFC3264].
If the answerer detects a possibility of an ICE mismatch, procedures If the answerer detects a possibility of an ICE mismatch, procedures
described in Section 4.2.5 are followed. described in Section 4.2.5 are followed.
4.3.3. Receiving the Initial Answer 4.3.3. Receiving the Initial Answer
When an offerer receives an initial answer that indicates that the When an offerer receives an initial answer that indicates that the
answerer supports ICE, it can start performing connectivity checks answerer supports ICE, it can start performing connectivity checks
towards the peer candidates that were provided in the answer. towards the peer candidates that were provided in the answer.
skipping to change at page 18, line 19 skipping to change at page 18, line 22
checks. checks.
candidate-attribute = "candidate" ":" foundation SP component-id SP candidate-attribute = "candidate" ":" foundation SP component-id SP
transport SP transport SP
priority SP priority SP
connection-address SP ;from RFC 4566 connection-address SP ;from RFC 4566
port ;port from RFC 4566 port ;port from RFC 4566
SP cand-type SP cand-type
[SP rel-addr] [SP rel-addr]
[SP rel-port] [SP rel-port]
*(SP extension-att-name SP *(SP cand-extension)
extension-att-value)
foundation = 1*32ice-char foundation = 1*32ice-char
component-id = 1*3DIGIT component-id = 1*3DIGIT
transport = "UDP" / transport-extension transport = "UDP" / transport-extension
transport-extension = token ; from RFC 3261 transport-extension = token ; from RFC 3261
priority = 1*10DIGIT priority = 1*10DIGIT
cand-type = "typ" SP candidate-types cand-type = "typ" SP candidate-types
candidate-types = "host" / "srflx" / "prflx" / "relay" / token candidate-types = "host" / "srflx" / "prflx" / "relay" / token
rel-addr = "raddr" SP connection-address rel-addr = "raddr" SP connection-address
rel-port = "rport" SP port rel-port = "rport" SP port
cand-extension = extension-att-name SP extension-att-value
extension-att-name = token extension-att-name = token
extension-att-value = *VCHAR extension-att-value = *VCHAR
ice-char = ALPHA / DIGIT / "+" / "/" ice-char = ALPHA / DIGIT / "+" / "/"
This grammar encodes the primary information about a candidate: its This grammar encodes the primary information about a candidate: its
IP address, port and transport protocol, and its properties: the IP address, port and transport protocol, and its properties: the
foundation, component ID, priority, type, and related transport foundation, component ID, priority, type, and related transport
address: address:
<connection-address>: is taken from RFC 4566 [RFC4566]. It is the <connection-address>: is taken from RFC 4566 [RFC4566]. It is the
skipping to change at page 20, line 8 skipping to change at page 20, line 10
for that server or peer reflexive candidate. If the candidate is for that server or peer reflexive candidate. If the candidate is
relayed, <rel-addr> and <rel-port> are equal to the mapped address relayed, <rel-addr> and <rel-port> are equal to the mapped address
in the Allocate response that provided the client with that in the Allocate response that provided the client with that
relayed candidate (see Appendix B.3 of [RFC8445] for a discussion relayed candidate (see Appendix B.3 of [RFC8445] for a discussion
of its purpose). If the candidate is a host candidate, <rel-addr> of its purpose). If the candidate is a host candidate, <rel-addr>
and <rel-port> MUST be omitted. and <rel-port> MUST be omitted.
In some cases, e.g., for privacy reasons, an agent may not want to In some cases, e.g., for privacy reasons, an agent may not want to
reveal the related address and port. In this case the address reveal the related address and port. In this case the address
MUST be set to "0.0.0.0" (for IPv4 candidates) or "::" (for IPv6 MUST be set to "0.0.0.0" (for IPv4 candidates) or "::" (for IPv6
candidates) and the port to zero. candidates) and the port to '9'.
The candidate attribute can itself be extended. The grammar allows The candidate attribute can itself be extended. The grammar allows
for new name/value pairs to be added at the end of the attribute. for new name/value pairs to be added at the end of the attribute.
Such extensions MUST be made through IETF Review or IESG Approval Such extensions MUST be made through IETF Review or IESG Approval
[RFC8126] and the assignments MUST contain the specific extension and [RFC8126] and the assignments MUST contain the specific extension and
a reference to the document defining the usage of the extension. a reference to the document defining the usage of the extension.
An implementation MUST ignore any name/value pairs it doesn't An implementation MUST ignore any name/value pairs it doesn't
understand. understand.
skipping to change at page 22, line 38 skipping to change at page 22, line 42
Example shows an ice-pacing SDP line with value '50': Example shows an ice-pacing SDP line with value '50':
a=ice-pacing:50 a=ice-pacing:50
5.6. "ice-options" Attribute 5.6. "ice-options" Attribute
The "ice-options" attribute is a session- and media-level attribute. The "ice-options" attribute is a session- and media-level attribute.
It contains a series of tokens that identify the options supported by It contains a series of tokens that identify the options supported by
the agent. Its grammar is: the agent. Its grammar is:
ice-options = "ice-options:" ice-option-tag ice-options = "ice-options:" ice-option-tag
0*(SP ice-option-tag) *(SP ice-option-tag)
ice-option-tag = 1*ice-char ice-option-tag = 1*ice-char
The existence of an ice-option in an offer indicates that a certain The existence of an ice-option in an offer indicates that a certain
extension is supported by the agent and it is willing to use it, if extension is supported by the agent and it is willing to use it, if
the peer agent also includes the same extension in the answer. There the peer agent also includes the same extension in the answer. There
might be further extension specific negotiation needed between the might be further extension specific negotiation needed between the
agents that determine how the extension gets used in a given session. agents that determine how the extension gets used in a given session.
The details of the negotiation procedures, if present, MUST be The details of the negotiation procedures, if present, MUST be
defined by the specification defining the extension (Section 10.2). defined by the specification defining the extension (Section 10.2).
Example shows an ice-options SDP line with 'ice2' and 'rtp+ecn' [RFC6679] values: Example shows an ice-options SDP line with 'ice2' and 'rtp+ecn' [RFC6679] values:
a=ice-options:ice2,rtp+ecn a=ice-options:ice2 rtp+ecn
6. Keepalives 6. Keepalives
All the ICE agents MUST follow the procedures defined in section 11 All the ICE agents MUST follow the procedures defined in section 11
of [RFC8445] for sending keepalives. The keepalives MUST be sent of [RFC8445] for sending keepalives. The keepalives MUST be sent
regardless of whether the data stream is currently inactive, regardless of whether the data stream is currently inactive,
sendonly, recvonly, or sendrecv, and regardless of the presence or sendonly, recvonly, or sendrecv, and regardless of the presence or
value of the bandwidth attribute. An agent can determine that its value of the bandwidth attribute. An agent can determine that its
peer supports ICE by the presence of "a=candidate" attributes for peer supports ICE by the presence of "a=candidate" attributes for
each media session. each media session.
skipping to change at page 27, line 37 skipping to change at page 27, line 49
through the SBC, if the SBC has requested it. If, however, the SBC through the SBC, if the SBC has requested it. If, however, the SBC
passes the ICE attributes without modification, yet modifies the passes the ICE attributes without modification, yet modifies the
default destination for media (contained in the "m=" and "c=" lines default destination for media (contained in the "m=" and "c=" lines
and rtcp attribute), this will be detected as an ICE mismatch, and and rtcp attribute), this will be detected as an ICE mismatch, and
ICE processing is aborted for the call. It is outside of the scope ICE processing is aborted for the call. It is outside of the scope
of ICE for it to act as a tool for "working around" SBCs. If one is of ICE for it to act as a tool for "working around" SBCs. If one is
present, ICE will not be used and the SBC techniques take precedence. present, ICE will not be used and the SBC techniques take precedence.
9. Security Considerations 9. Security Considerations
9.1. Attacks on the Offer/Answer Exchanges The generic ICE security considerations are defined in [RFC8445], and
the generic SDP offer/answer security considerations are defined in
[RFC3264]. These security considerations also apply to
implementations of this document.
9.1. IP Address Privacy
In some cases, e.g., for privacy reasons, an agent may not want to
reveal the related address and port. In this case the address MUST
be set to "0.0.0.0" (for IPv4 candidates) or "::" (for IPv6
candidates) and the port to '9'.
9.2. Attacks on the Offer/Answer Exchanges
An attacker that can modify or disrupt the offer/answer exchanges An attacker that can modify or disrupt the offer/answer exchanges
themselves can readily launch a variety of attacks with ICE. They themselves can readily launch a variety of attacks with ICE. They
could direct media to a target of a DoS attack, they could insert could direct media to a target of a DoS attack, they could insert
themselves into the data stream, and so on. These are similar to the themselves into the data stream, and so on. These are similar to the
general security considerations for offer/answer exchanges, and the general security considerations for offer/answer exchanges, and the
security considerations in [RFC3264] apply. These require techniques security considerations in [RFC3264] apply. These require techniques
for message integrity and encryption for offers and answers, which for message integrity and encryption for offers and answers, which
are satisfied by the TLS mechanism [RFC3261] when SIP is used. As are satisfied by the TLS mechanism [RFC3261] when SIP is used. As
such, the usage of TLS with ICE is RECOMMENDED. such, the usage of TLS with ICE is RECOMMENDED.
9.2. Insider Attacks 9.3. The Voice Hammer Attack
In addition to attacks where the attacker is a third party trying to
insert fake offers, answers, or STUN messages, there are several
attacks possible with ICE when the attacker is an authenticated and
valid participant in the ICE exchange.
9.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, and can be
the attacker initiates sessions to other agents, and maliciously triggered even if the attacker is an authenticated and valid
includes the connection address and port of a DoS target as the participant in a session. In this attack, the attacker initiates
destination for media traffic signaled in the SDP. This causes sessions to other agents, and maliciously includes the connection
substantial amplification; a single offer/answer exchange can create address and port of a DoS target as the destination for media traffic
a continuing flood of media packets, possibly at high rates (consider signaled in the SDP. This causes substantial amplification; a single
video sources). This attack is not specific to ICE, but ICE can help offer/answer exchange can create a continuing flood of media packets,
provide remediation. possibly at high rates (consider video sources). The use of ICE can
help to prevent against this attack.
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
limited to ones that support ICE, the server can reject any offers or limited to ones that support ICE, the server can reject any offers or
skipping to change at page 33, line 25 skipping to change at page 33, line 26
A registration request MUST include the following information: A registration request MUST include the following information:
o The ICE option identifier to be registered o The ICE option identifier to be registered
o Short description of the ICE extension to which the option relates o Short description of the ICE extension to which the option relates
o Reference(s) to the specification defining the ICE option and the o Reference(s) to the specification defining the ICE option and the
related extensions related extensions
10.3. Candidate Attribute Extension Subregistry Establishment
This section creates a new sub-registry, "Candidate Attribute
Extensions", under the sdp-parameters registry:
http://www.iana.org/assignments/sdp-parameters.
The purpose of the sub-registry is to register SDP candidate
attribute extensions.
When a candidate extension is registered in the sub-registry, it
needs to meet the "Specification Required" policies defined in
[RFC8126].
Candidate attribute extensions MUST follow the 'cand-extension'
syntax. The attribute extension name MUST follow the 'extension-att-
name' syntax, and the attribute extension value MUST follow the
'extension-att-value' syntax.
A registration request MUST include the following information:
o The name of the attribute extension.
o A short description of the attribute extension.
o A reference to a specification that describes the semantics, usage
and possible values of the attribute extension.
11. Acknowledgments 11. Acknowledgments
A large part of the text in this document was taken from [RFC5245], A large part of the text in this document was taken from [RFC5245],
authored by Jonathan Rosenberg. authored by Jonathan Rosenberg.
Some of the text in this document was taken from [RFC6336], authored Some of the text in this document was taken from [RFC6336], authored
by Magnus Westerlund and Colin Perkins. by Magnus Westerlund and Colin Perkins.
Many thanks to Flemming Andreasen for shepherd review feedback. Many thanks to Flemming Andreasen for shepherd review feedback.
skipping to change at page 34, line 33 skipping to change at page 35, line 14
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002,
<http://www.rfc-editor.org/info/rfc3262>. <https://www.rfc-editor.org/info/rfc3262>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
[RFC3312] Camarillo, G., Ed., Marshall, W., Ed., and J. Rosenberg, [RFC3312] Camarillo, G., Ed., Marshall, W., Ed., and J. Rosenberg,
"Integration of Resource Management and Session Initiation "Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, DOI 10.17487/RFC3312, October Protocol (SIP)", RFC 3312, DOI 10.17487/RFC3312, October
2002, <http://www.rfc-editor.org/info/rfc3312>. 2002, <https://www.rfc-editor.org/info/rfc3312>.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", Modifiers for RTP Control Protocol (RTCP) Bandwidth",
RFC 3556, DOI 10.17487/RFC3556, July 2003, RFC 3556, DOI 10.17487/RFC3556, July 2003,
<http://www.rfc-editor.org/info/rfc3556>. <https://www.rfc-editor.org/info/rfc3556>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC3605, October 2003, DOI 10.17487/RFC3605, October 2003,
<http://www.rfc-editor.org/info/rfc3605>. <https://www.rfc-editor.org/info/rfc3605>.
[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, DOI 10.17487/RFC4032, March 2005, RFC 4032, DOI 10.17487/RFC4032, March 2005,
<http://www.rfc-editor.org/info/rfc4032>. <https://www.rfc-editor.org/info/rfc4032>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5768] Rosenberg, J., "Indicating Support for Interactive [RFC5768] Rosenberg, J., "Indicating Support for Interactive
Connectivity Establishment (ICE) in the Session Initiation Connectivity Establishment (ICE) in the Session Initiation
Protocol (SIP)", RFC 5768, DOI 10.17487/RFC5768, April Protocol (SIP)", RFC 5768, DOI 10.17487/RFC5768, April
2010, <http://www.rfc-editor.org/info/rfc5768>. 2010, <https://www.rfc-editor.org/info/rfc5768>.
[RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for
Interactive Connectivity Establishment (ICE) Options", Interactive Connectivity Establishment (ICE) Options",
RFC 6336, April 2010, RFC 6336, DOI 10.17487/RFC6336, July 2011,
<http://www.rfc-editor.org/info/rfc6336>. <https://www.rfc-editor.org/info/rfc6336>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<http://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<http://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
13.2. Informative References 13.2. Informative References
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)", Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
<http://www.rfc-editor.org/info/rfc3725>. <https://www.rfc-editor.org/info/rfc3725>.
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
Tone Generation in the Session Initiation Protocol (SIP)", Tone Generation in the Session Initiation Protocol (SIP)",
RFC 3960, DOI 10.17487/RFC3960, December 2004, RFC 3960, DOI 10.17487/RFC3960, December 2004,
<http://www.rfc-editor.org/info/rfc3960>. <https://www.rfc-editor.org/info/rfc3960>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010, DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>. <https://www.rfc-editor.org/info/rfc5245>.
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
"Managing Client-Initiated Connections in the Session "Managing Client-Initiated Connections in the Session
Initiation Protocol (SIP)", RFC 5626, Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009, DOI 10.17487/RFC5626, October 2009,
<http://www.rfc-editor.org/info/rfc5626>. <https://www.rfc-editor.org/info/rfc5626>.
[RFC5898] Andreasen, F., Camarillo, G., Oran, D., and D. Wing, [RFC5898] Andreasen, F., Camarillo, G., Oran, D., and D. Wing,
"Connectivity Preconditions for Session Description "Connectivity Preconditions for Session Description
Protocol (SDP) Media Streams", RFC 5898, Protocol (SDP) Media Streams", RFC 5898,
DOI 10.17487/RFC5898, July 2010, DOI 10.17487/RFC5898, July 2010,
<http://www.rfc-editor.org/info/rfc5898>. <https://www.rfc-editor.org/info/rfc5898>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, August 2012, for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
<http://www.rfc-editor.org/info/rfc6679>. 2012, <https://www.rfc-editor.org/info/rfc6679>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Examples Appendix A. Examples
For the example shown in section 15 of [RFC8445] the resulting offer For the example shown in section 15 of [RFC8445] the resulting offer
(message 5) encoded in SDP looks like: (message 5) encoded in SDP looks like:
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP6 $L-PRIV-1.IP o=jdoe 2890844526 2890842807 IN IP6 $L-PRIV-1.IP
s= s=
c=IN IP6 $NAT-PUB-1.IP c=IN IP6 $NAT-PUB-1.IP
skipping to change at page 41, line 36 skipping to change at page 42, line 36
Email: marc@petit-huguenin.org Email: marc@petit-huguenin.org
Suhas Nandakumar Suhas Nandakumar
Cisco Systems Cisco Systems
707 Tasman Dr 707 Tasman Dr
Milpitas, CA 95035 Milpitas, CA 95035
USA USA
Email: snandaku@cisco.com Email: snandaku@cisco.com
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Ari Keranen Ari Keranen
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: ari.keranen@ericsson.com Email: ari.keranen@ericsson.com
Roman Shpount Roman Shpount
TurboBridge TurboBridge
4905 Del Ray Avenue, Suite 300 4905 Del Ray Avenue, Suite 300
Bethesda, MD 20814 Bethesda, MD 20814
USA USA
Phone: +1 (240) 292-6632 Phone: +1 (240) 292-6632
Email: rshpount@turbobridge.com Email: rshpount@turbobridge.com
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
 End of changes. 45 change blocks. 
81 lines changed or deleted 134 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/