MMUSIC Working Group A. Hutton
Internet-Draft J. Elwell
Intended status: Standards Track Siemens Enterprise Communications
Expires: April 24, 2011 October 21, 2010
A Mechanism for Conveying Alternate Addresses using ICE Syntax
draft-hutton-mmusic-icemicrolite-02
Abstract
This document proposes a mechanism for conveying multiple IP
addresses of different address families (e.g., IPv4, IPv6) for a
given medium, in the same Session Description Protocol (SDP) offer.
This proposed mechanism solves the backward compatibility which
exists with ANAT, due to its syntax, and provides a migration path
towards support for ICE. The proposed mechanism is significantly
less complex then ICE or ICE-Lite but uses ICE syntax. The mechanism
described in this document has been named ICE-microLite.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Hutton & Elwell Expires April 24, 2011 [Page 1]
Internet-Draft ICE-microLite October 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of ICE-microLite . . . . . . . . . . . . . . . . . . 4
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Sending Initial Offer . . . . . . . . . . . . . . . . . . 6
4.2. Receiving an SDP Offer . . . . . . . . . . . . . . . . . . 6
4.3. Sending an SDP Answer . . . . . . . . . . . . . . . . . . 6
4.4. Receiving an SDP Answer . . . . . . . . . . . . . . . . . 7
4.5. No requirement for an updated offer . . . . . . . . . . . 7
5. Compatibility with ICE and ICE-Lite . . . . . . . . . . . . . 7
6. Extension to ICE candidate attribute . . . . . . . . . . . . . 9
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Hutton & Elwell Expires April 24, 2011 [Page 2]
Internet-Draft ICE-microLite October 2010
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119] and
indicate requirement levels for compliant mechanisms.
2. Introduction
This document proposes a mechanism which allows the carriage of
multiple IP addresses, of different address families (e.g., IPv4,
IPv6) for a given medium, in the same Session Description Protocol
(SDP [RFC4566]) offer [RFC3264]. The proposed attribute solves the
backward compatibility problem which exists with the earlier ANAT
[RFC4091] mechanism, due to its syntax, and provides a migration path
towards support for ICE [RFC5245]. The proposed mechanism is
significantly less complex than ICE or ICE-Lite but uses ICE syntax.
The mechanism described in this document has been named ICE-
microLite. This mechanism should be considered as an alternative
mechanism to those described in [I-D.boucadair-mmusic-altc] and
[I-D.veikkolainen-mmusic-ice-suppress-checks].
2.1. Purpose
The purpose of this proposal is to provide a mechanism for conveying
multiple media connection addresses for a given medium in an SDP
offer in a way that is backwards compatible with existing SDP
implementations. The proposed mechanism allows the receiver of the
offer, if it understands the syntax, to select the media connection
address which it prefers. If the receiver of the offer does not
understand the proposed mechanism then it will use the SDP connection
data ("c=") and therefore fall back to the default address family as
preferred by the offerer, which for reasons of backwards
compatibility will normally be an IPv4 address.
Currently the IETF intended mechanism for providing an IPv4 to IPv6
transition mechanism for conveying multiple media addresses in SDP is
ICE acting as replacement for ANAT. However support for ICE or ICE-
Lite, which is a subset of ICE, is over complex for scenarios in
which a transition mechanism is needed without the need to use ICE
for NAT traversal and connectivity checking.
The mechanism proposed in this document does however make use of ICE
syntax, so providing the possibility for an implementation to be
enhanced to support ICE or ICE-Lite without having to use a
completely different syntax.
Hutton & Elwell Expires April 24, 2011 [Page 3]
Internet-Draft ICE-microLite October 2010
The proposed solution provides the following benefits:
o allows a UA to signal more than one IP address (type) for the same
medium in an SDP offer/answer;
o is backwards compatible with non-ICE implementations because it
uses the same backwards compatibility mechanism as ICE;
o it is a lightweight mechanism that uses ICE syntax but does not
require any of the complexities of ICE (e.g., Connectivity
checking etc.);
o by using ICE Syntax it provides a migration path towards support
for ICE-Lite or full ICE.
2.2. Scope
This document proposes a simplified ICE-like syntax to carry several
IP address types for the same medium in an SDP offer/answer while
preserving backward compatibility.
The scope of this proposal is the same as [I-D.boucadair-mmusic-altc]
and likewise does not include addressing at the SIP layer.
2.3. Use Cases
The use cases for this proposal are the same as the use cases
detailed in [I-D.boucadair-mmusic-altc].
3. Overview of ICE-microLite
ICE-microLite is a migration step towards introduction of ICE-Lite.
Compared to ICE-Lite, the functionality of an ICE-microLite
implementation is further reduced such that:
o an ICE-microLite implementation does not require a STUN server as
no connectivity checking is performed.
o an ICE-microLite implementation only provides candidates for a
single foundation (i.e., RTP Component and RTCP Component) in an
SDP answer.
o it is a lightweight mechanism which uses ICE syntax but does not
require any of the complexities of ICE (e.g., Connectivity
checking etc.)
Hutton & Elwell Expires April 24, 2011 [Page 4]
Internet-Draft ICE-microLite October 2010
o an ICE-microLite implementation uses dummy values for the STUN-
related ICE attributes since STUN is not used. The attributes are
still included to maintain compatibility with ICE.
o an ICE-microLite implementation sets the ice-options attribute to
"a=ice-options microlite".
o No updated offer/answer is required following completion of ICE-
microLite procedures.
An extension to the ICE a=candidate attribute provides the required
functionality. For example:
a=candidate:1 1 UDP 2130706431 192.0.2.1 0 typ host microliteport 3478
This extension does not use the port field of the regular a=candidate
attribute, but rather provides the port number in an extension called
microliteport. An ICE-microLite implementation will set the value of
the regular port field to "0". Consequently, implementations which
support ICE according to [RFC5245], but are not ICE-microLite aware
will not find a default candidate matching port and IP address in the
SDP's m/c-line, will detect an ICE mismatch and will fall-back to
default SDP processing.
An example of an SDP offer using this mechanism is as follows when
IPv6 is preferred but IPv4 is the fall back option.
v=0
o=test 2890844342 2890842164 IN IP4 192.0.2.2
c=IN IP4 192.0.2.2
t=0 0
a=ice-lite
a=ice-options microlite
a=ice-pwd:microlitemicrolitemicrolite
a=ice-ufrag:microlite
m=audio 3480 RTP/AVP 0
b=RS:0
b=RR:0
a=candidate:1 1 UDP 2130706431 2001:::1 0 typ host microliteport 3478
a=candidate:2 1 UDP 2130706430 192.0.2.2 0 typ host microliteport 3480
4. Procedures
Hutton & Elwell Expires April 24, 2011 [Page 5]
Internet-Draft ICE-microLite October 2010
4.1. Sending Initial Offer
The procedures for sending the initial SDP offer are the same as
specified for an ICE-lite implementation in [RFC5245] except for the
following:
o An ICE-microLite implementation is not required to use random
values for the a=ice-ufrag and the a=ice-pwd attributes. An ICE-
microLite implementation MUST use the following default values of
"a=ice-pwd:microlitemicrolitemicrolite" and "a=ice-
ufrag:microlite". These attributes are not actually required by
ICE-microLite but are maintained for compatibility with ICE
implementations.
o An ICE-microLite implementation MUST set the port field in ICE
a=candidate attribute to "0" and MUST include the local port of
the candidate in the microliteport field of the candidate.
4.2. Receiving an SDP Offer
An ICE-microLite SIP UA MUST ignore any candidate-types that are not
of type host.
If the a=candidate attributes for the host candidates in the received
SDP offer do not contain the microliteport field in the ICE
a=candidate attribute, the ICE-microLite SIP UA MUST ignore all other
ICE attributes and process the SDP based on normal [RFC3264]
procedures. Consequently, the SDP answer of the ICE-microLite SIP UA
MUST NOT contain any ICE attribute in this case. This means that
when the offer was generated by a UA which is not ICE-microLite aware
the result will be a fall-back to the default candidates and normal
SDP procedures.
If the a=candidate attributes for the host candidates in the received
SDP offer contains the microliteport field, the ICE-microLite SIP UA
MUST use that value as port number instead of using the value in the
port field.. An ICE-microLite SIP UA MUST ignore any port value
received in the regular port field of the a=candidate attribute.
4.3. Sending an SDP Answer
An ICE-microLite implementation is not required to send the SDP
answer in a 18x provisional response or send the response reliably as
recommended by [RFC5245]. This is because no connectivity checking
takes place.
An ICE-microLite implementation is not required to use random values
for the a=ice-ufrag and the a=ice-pwd attributes as specified in
Hutton & Elwell Expires April 24, 2011 [Page 6]
Internet-Draft ICE-microLite October 2010
[RFC5245]. An ICE-microLite implementation MUST use the following
default values of "a=ice-pwd:microlitemicrolitemicrolite" and "a=ice-
ufrag:microlite". These attributes are not actually required by ICE-
microLite but are maintained for compatability with ICE
implementations.
An ICE-microLite SIP UA generating an SDP Answer MUST set the port
field in the a=candidate attribute to "0" and MUST include the local
port of the candidate in the microliteport field.
An ICE-microLite SIP UA MUST select its preferred candidate (E.g.
based on IP address family) by listing only the selected candidate
foundation in its SDP answer.
4.4. Receiving an SDP Answer
An ICE-microLite SIP UA will receive an SDP answer with only a single
candidate pair per component from an ICE-microLite aware SIP UA
compliant to this specification.
An SDP answer received from a SIP UA that is not ICE, ICE-lite or
ICE-microLite will not contain ICE attributes other than
"a=icemismatch".
4.5. No requirement for an updated offer
Due to the fact that an ICE-microLite implementation will generate an
SDP answer containing a single candidate pair per component there is
no requirement for an updated offer to be generated. This simplifies
the implementation when compared to the ICE/ICE-Lite [RFC5245] case
when the offer/answer exchange results in more than one pair per
component and an updated offer/answer is required.
Not requiring an updated offer/answer exchange is advantages because
such an updated offer may clash with other requirements for updated
offers in for example 3PCC and Fax scenarios.
5. Compatibility with ICE and ICE-Lite
An ICE or ICE-Lite implementation that is not ICE-microLite aware
will detect an ice mismatch when receiving an ICE-microLite SDP offer
and fallback to normal SDP processing.
An ICE or ICE-Lite implementation that is ICE-microLite aware will be
aware that a received SDP offer is a ICE-microLite offer and respond
according to the procedures in this document.
Hutton & Elwell Expires April 24, 2011 [Page 7]
Internet-Draft ICE-microLite October 2010
An ICE-microLite implementation that receives an SDP offer from a
full ICE implementation will fallback to normal SDP processing.
An ICE-microLite implementation that receives an SDP offer from an
ICE-Lite implementation may respond with an ICE-Lite compatible
answer. This is safe because the ICE-lite client will never initiate
conectivity checking.
An ICE or ICE-Lite implementation that also supports ICE-microLite
can include in the offer the microliteport extension which would
allow an ICE-microLite implementation receiving the offer to generate
an SDP answer also containing the microliteport extension.
Hutton & Elwell Expires April 24, 2011 [Page 8]
Internet-Draft ICE-microLite October 2010
6. Extension to ICE candidate attribute
The ICE [RFC5245] a=candidate attribute is extended as follows:
candidate-attribute = "candidate" ":" foundation SP component-id SP
transport SP
priority SP
connection-address SP ;from RFC 4566
port ;port from RFC 4566
SP cand-type
[SP rel-addr]
[SP rel-port]
[SP microliteport]
*(SP extension-att-name SP
extension-att-value)
microliteport = "microliteport" SP port
7. IANA considerations
If this document moves forward, it requests a new extension attribute
"microliteport", to be defined for the ICE candidate-attribute and a
new ice-options attribute "microlite" to be reserved.
8. Security considerations
As with any SDP offer or answer, an attacker modifying the SDP can
mount a variety of attacks. To counter this, SDP should be integrity
protected by some means. Also an attacker eavesdropping on the SDP
can discover addresses and ports on which to mount attacks (e.g.,
denial of service). To counter this, SDP should be confidentiality
protected by some means. Such means will depend on the protocol used
to convey SDP. For example, the Session Initiation Protocol (SIP)
[RFC3261] can be transported over TLS or can protect SDP bodies using
S/MIME.
9. Acknowledgements
The authors would like to acknowledge the assistance of Heinrich
Haager, Thomas Stach and Ernst Horvath.
10. References
Hutton & Elwell Expires April 24, 2011 [Page 9]
Internet-Draft ICE-microLite October 2010
10.1. Normative References
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[I-D.boucadair-mmusic-altc]
Boucadair, M., Kaplan, H., Gilman, R., and S.
Veikkolainen, "Session Description Protocol (SDP)
Alternate Connectivity (ALTC) Attribute",
draft-boucadair-mmusic-altc-01 (work in progress),
September 2010.
[I-D.veikkolainen-mmusic-ice-suppress-checks]
Veikkolainen, S., "Interactive Connectivity Establishment
(ICE) extensions for suppressing connectivity checks",
draft-veikkolainen-mmusic-ice-suppress-checks-00 (work in
progress), October 2010.
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network
Address Types (ANAT) Semantics for the Session Description
Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
Hutton & Elwell Expires April 24, 2011 [Page 10]
Internet-Draft ICE-microLite October 2010
Authors' Addresses
Andrew Hutton
Siemens Enterprise Communications
Phone: +44 1908 817920
Email: andrew.hutton@siemens-enterprise.com
URI: http://www.siemens-enterprise.com
John Elwell
Siemens Enterprise Communications
Phone: +44 1908 817801
Email: john.elwell@siemens-enterprise.com
URI: http://www.siemens-enterprise.com
Hutton & Elwell Expires April 24, 2011 [Page 11]