MMUSIC Working Group A. Hutton
Internet-Draft J. Elwell
Intended status: Standards Track Siemens Enterprise Communications
Expires: September 9, 2010 March 8, 2010
A mechanism for conveying alternate addresses using ICE syntax
draft-hutton-mmusic-icemicrolite-01
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hutton & Elwell Expires September 9, 2010 [Page 1]
Internet-Draft ICE-microLite March 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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 the initial Offer . . . . . . . . . . . . . . . . . 5
4.2. Receiving an SDP Offer . . . . . . . . . . . . . . . . . . 6
4.3. Sending an SDP Answer . . . . . . . . . . . . . . . . . . . 6
4.4. Receiving an SDP Answer . . . . . . . . . . . . . . . . . . 7
5. Compatibility with ICE and ICE-Lite . . . . . . . . . . . . . . 7
6. Extension to ICE candidate attribute . . . . . . . . . . . . . 8
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Security considerations . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Hutton & Elwell Expires September 9, 2010 [Page 2]
Internet-Draft ICE-microLite March 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 [I-D.ietf-mmusic-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. This mechanism should be considered as an alternative
mechanism to that described in [I-D.boucadair-mmusic-altc].
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 replacemant 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.
The proposed solution provides the following benefits:
Hutton & Elwell Expires September 9, 2010 [Page 3]
Internet-Draft ICE-microLite March 2010
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 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.)
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.
Hutton & Elwell Expires September 9, 2010 [Page 4]
Internet-Draft ICE-microLite March 2010
o an ICE-microLite implementation sets the ice-options attribute to
"a=ice-options microlite".
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 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 [I-D.ietf-mmusic-ice], 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
4.1. Sending the initial Offer
The procedures for sending the initial offer are the same as
specified for a an ICE-lite implementation in [I-D.ietf-mmusic-ice]
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
Hutton & Elwell Expires September 9, 2010 [Page 5]
Internet-Draft ICE-microLite March 2010
"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.
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 [I-D.ietf-mmusic-ice]. 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
[I-D.ietf-mmusic-ice]. 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.
Hutton & Elwell Expires September 9, 2010 [Page 6]
Internet-Draft ICE-microLite March 2010
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".
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.
An ICE-microLite implementation that receives an SDP offer from a
full ICE implementation will fallback to normal SDP processing.
An ICE-microLite implementatin 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 September 9, 2010 [Page 7]
Internet-Draft ICE-microLite March 2010
6. Extension to ICE candidate attribute
The ICE [I-D.ietf-mmusic-ice] 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.
Hutton & Elwell Expires September 9, 2010 [Page 8]
Internet-Draft ICE-microLite March 2010
10. References
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.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[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-00 (work in progress),
February 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.
Authors' Addresses
Andrew Hutton
Siemens Enterprise Communications
Phone: +44 1908 855395
Email: andrew.hutton@siemens-enterprise.com
URI: http://www.siemens-enterprise.com
Hutton & Elwell Expires September 9, 2010 [Page 9]
Internet-Draft ICE-microLite March 2010
John Elwell
Siemens Enterprise Communications
Phone: +44 1908 855608
Email: john.elwell@siemens-enterprise.com
URI: http://www.siemens-enterprise.com
Hutton & Elwell Expires September 9, 2010 [Page 10]