MMUSIC J. Rosenberg Internet-Draft Cisco Intended status: Standards Track March 5, 2007 Expires: September 6, 2007 TCP Candidates with Interactive Connectivity Establishment (ICE draft-ietf-mmusic-ice-tcp-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Simple Traversal of UDP over NAT (STUN). ICE provides a general framework for describing alternates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, Rosenberg Expires September 6, 2007 [Page 1] Internet-Draft ICE March 2007 including the ability to offer a mix of TCP and UDP-based candidates for a single stream. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 3. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 5 3.1. Gathering Candidates . . . . . . . . . . . . . . . . . . . 5 3.2. Prioritization . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Choosing Default Candidates . . . . . . . . . . . . . . . 8 3.4. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 8 4. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 9 4.1. Forming the Check Lists . . . . . . . . . . . . . . . . . 9 5. Connectivity Checks . . . . . . . . . . . . . . . . . . . . . 9 5.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 9 5.1.1. Sending the Request . . . . . . . . . . . . . . . . . 9 5.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 10 6. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 10 7. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 11 7.1. ICE Restarts . . . . . . . . . . . . . . . . . . . . . . . 11 8. Media Handling . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 11 8.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 11 9. Connection Management . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Rosenberg Expires September 6, 2007 [Page 2] Internet-Draft ICE March 2007 1. Introduction Interactive Connectivity Establishment (ICE) [6] defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model [2] of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN) [1]. However, ICE only defines procedures for UDP-based transport protocols. There are many reasons why ICE support for TCP is important. Firstly, there are media protocols that only run over TCP. Examples of such protocols are web and application sharing and instant messaging [9]. For these protocols to work in the presence of NAT, unless they define their own NAT traversal mechanisms, ICE support for TCP is needed. In addition, RTP itself can run over TCP (without [4] and with TLS [5]). Typically, it is preferable to run RTP over UDP, and not TCP. However, in a variety of network environments, overly restrictive NAT and firewall devices prevent UDP-based communications altogether, but general TCP-based communications are permitted. In such environments, sending RTP over TCP, and thus establishing the media session, may be preferable to having it fail altogether. With ICE, agents can gather UDP and TCP candidates for an RTP-based stream, list the UDP ones with higher priority, and then only use the TCP-based ones if the UDP ones fail altogether. This provides a fallback mechanism that allows multimedia communications to be highly reliable. The usage of RTP over TCP is particularly useful when combined with the STUN relay usage [7]. In that usage, one of the agents would connect to its STUN relay server using TCP, and obtain a TCP-based relayed candidate. It would offer this to its peer agent as a candidate. The answerer would initiate a TCP connection towards the STUN relay server. When that connection is established, media can flow over the connections, through the relay. The benefit of this usage is that it only requires the agents to make outbound TCP connections to a server on the public network. This kind of operation is broadly interoperable through NAT and firewall devices. Since it is a goal of ICE and this extension to provide highly reliable communications that "just works" in as a broad a set of network deployments as possible, this usage is particularly important. The usage of RTP over TCP/TLS is also useful when communicating between single-user agents (such as a softphone or hardphone) and an agent run by a provider that is meant to service many users, such as a PSTN gateway. In such a deployment, the multi-user agent would act Rosenberg Expires September 6, 2007 [Page 3] Internet-Draft ICE March 2007 as the TLS server, and have a certificate. The single-user agent can then connect, validate the certificate, but offer none of its own (since its not likely to have one). STUN itself would then provide authentication of the softphone to the gateway, leveraging the exchange of a short term credential in the SIP signaling. This specification extends ICE by defining its usage with TCP candidates. This specification does so by following the outline of ICE itself, and calling out the additions and changes necessary in each section of ICE to support TCP candidates. 2. Overview of Operation The usage of ICE with TCP is relatively straightforward. The main area of specification is around how and when connections are opened, and how those connections relate to candidate pairs. When the agents perform address allocations to gather TCP-based candidates, three types of candidates can be obtained. These are active candidates, passive candidates, and simultaneous-open candidates. An active candidate is one for which the agent will attempt to open an outbound connection, but will not receive incoming connection requests. A passive candidate is one for which the agent will receive incoming connection attempts, but not attempt a connection. A simultaneous-open candidate is one for which the agent will attempt to open a connection simultaneously with its peer. Because this specification requires multiple candidates for a media stream, it is not compatible with ICE's lite implementation, and can only be used by full implementations. When gathering candidates from a host interface, the agent typically obtains an active, passive and simultaneous-open candidates. Similarly, communications with a STUN server will provide server reflexive and relayed versions of all three types. When encoding these candidates into offers and answers, the type of the candidate is signaled. In the case of active candidates, an IP address and port is present, but it is meaningless, as it is ignored by the peer. As a consequence, active candidates do not need to be physically allocated at the time of address gathering. Rather, the physical allocations, which occur as a consequence of a connection attempt, occur at the time of the connectivity checks. When the candidates are paired together, active candidates are always paired with passive, and simultaneous-open candidates with each other. When a connectivity check is to be made on a candidate pair, Rosenberg Expires September 6, 2007 [Page 4] Internet-Draft ICE March 2007 each agent determines whether it is to make a connection attempt for this pair. Why have both active and simultaneous-open candidates? Why not just simultaneous-open? The reason is that NAT treatment of simultaneous opens is currently not well defined, though specifications are being developed to address this [8]. Some NATs block the second TCP SYN packet or improperly process the subsequent SYNACK, which will cause the connection attempt to fail. Therefore, if only simultaneous opens are used, connections may often fail. Alternatively, using unidirectional opens (where one side is active and the other is passive) is more reliable, but will always require a relay if both sides are behind NAT. Therefore, in the spirit of the ICE philosophy, both are tried. Simultaneous-opens are preferred since, if it does work, it will not require a relay even when both sides are behind a different NAT. The actual processing of generating connectivity checks, managing the state of the check list, and updating the Valid list, work identically for TCP as they do for UDP. ICE requires an agent to demultiplex STUN and application layer traffic, since they appear on the same port. This demultiplexing is described by ICE, and is done using the magic cookie and other fields of the message. Stream-oriented transports introduce another wrinkle, since they require a way to frame the connection so that the application and STUN packets can be extracted in order to determine which is which. For this reason, TCP media streams utilizing ICE use the basic framing provided in RFC 4571 [4], even if the application layer protocol is not RTP. When an updated offer is generated by the controlling endpoint, the SDP extensions for connection oriented media [3] are used to signal that an existing connection should be used, rather than opening a new one. 3. Sending the Initial Offer The offerer MUST be a full ICE implementation. 3.1. Gathering Candidates For each TCP capable media stream the agent wishes to use (including ones, like RTP, which can either be UDP or TCP), the agent SHOULD obtain two host candidates for each component of the media stream on each interface that the host has - one for the simultaneous open, and Rosenberg Expires September 6, 2007 [Page 5] Internet-Draft ICE March 2007 one for the passive candidate. If an agent is not capable of acting in one of these modes (for example, the TCP connection is being used with TLS and the agent can only act as the client), it would omit those candidates. OPEN ISSUE: What happens with TLS and simultaneous opens? Who sends the ClientHello? > Providers of real-time communications services may decide that it is preferable to have no media at all than it is to have media over TCP. To allow for choice, it is RECOMMENDED that agents be configurable with whether they obtain TCP candidates for real time media. Having it be configurable, and then configuring it to be off, is far better than not having the capability at all. An important goal of this specification is to provide a single mechanism that can be used across all types of endpoints. As such, it is preferable to account for provider and network variation through configuration, instead of hard-coded limitations in an implementation. Furthermore, network characteristics and connectivity assumptions can, and will change over time. Just because a agent is communicating with a server on the public network today, doesn't mean that it won't need to communicate with one behind a NAT tomorrow. Just because a agent is behind a NAT with endpoint indpendent mapping today, doesn't mean that tomorrow they won't pick up their agent and take it to a public network access point where there is a NAT with address and port dependent mapping properties, or one that only allows outbound TCP. The way to handle these cases and build a reliable system is for agents to implement a diverse set of techniques for allocating addresses, so that at least one of them is almost certainly going to work in any situation. Implementors should consider very carefully any assumptions that they make about deployments before electing not to implement one of the mechanisms for address allocation. In particular, implementors should consider whether the elements in the system may be mobile, and connect through different networks with different connectivity. They should also consider whether endpoints which are under their control, in terms of location and network connectivity, would always be under their control. In environments where mobility and user control are possible, a multiplicity of techniques is essential for reliability. Each agent SHOULD "obtain" an active host candidate for each component of each TCP capable media stream on each interface that the host has. The agent does not have to actually allocate a port for these candidates. These candidates serve as a placeholder for the Rosenberg Expires September 6, 2007 [Page 6] Internet-Draft ICE March 2007 creation of the check lists. Using each simultaneous-open and passive host TCP candidate as a base, the agent SHOULD obtain server reflexive candidate. In addition, the agent SHOULD choose, amongst all host TCP candidates for a component that have the same foundation (there will typically be two - a passive and simultaneous-open), one of those candidates, and from it, obtain two server reflexive candidates - one that will be simultaneous-open, and one that will be passive. If an agent requires both a server reflexive and relayed candidate using a particular host candidate as a based, it SHOULD obtain both at the same time using a STUN Allocate request. Otherwise, if just a server reflexive candidate is required, the agent SHOULD use a STUN Binding Request. An agent MAY use an additional host TCP candidate to request a UDP- based candidate from the server. Usage of the UDP candidate from the relay follows the procedures defined in ICE for UDP candidates. Each agent SHOULD "obtain" an active relayed candidate for each component of each TCP capable media stream on each interface that the host has. The agent does not have to actually allocate a port for these candidates from the relay at this time. These candidates serve as a placeholder for the creation of the check lists. Like its UDP counterparts, TCP-based STUN transactions are paced out at one every Ta seconds. This pacing refers to the establishment of a TCP connection to the STUN server and the subsequent STUN request. That is, every Ta seconds, the agent will open a new TCP connection and send a STUN request, either an Allocate or Binding request. 3.2. Prioritization The transport protocol itself is a criteria for choosing one candidate over another. If a particular media stream can run over UDP or TCP, the UDP candidates might be preferred over the TCP candidates. This allows ICE to use the lower latency UDP connectivity if it exists, but fallback to TCP if UDP doesn't work. To accomplish this, the local preference SHOULD be defined as: local-preference = (2^12)*(transport-pref) + (2^9)*(direction-pref) + (2^0)*(other-pref) When this formulation is used, the transport-pref MUST be between 0 and 15, with 15 being the most preferred. The direction-pref MUST be Rosenberg Expires September 6, 2007 [Page 7] Internet-Draft ICE March 2007 between 0 and 7, with 7 being the most preferred. Other-pref MUST be between 0 and 511, with 511 being the most preferred. For RTP-based media streams, it is RECOMMENDED that UDP have a transport-pref of 15 and TCP of 6. It is RECOMMENDED that, for all connection-oriented media, simultaneous-open candidates have a direction-pref of 7, active of 5 and passive of 2. If any two candidates have the same type-preference, transport-pref, and direction-pref, they MUST have a unique other-pref. With this specification, the only way that can happen is with multi-homed hosts, in which case other-pref is a preference amongst interfaces. 3.3. Choosing Default Candidates The default candidate is chosen primarily based on the likelihood of it working with a non-ICE peer. When media streams supporting mixed modes (both TCP and UDP) are used with ICE, it is RECOMMENDED that, for real-time streams (such as RTP), the default candidates be UDP- based. However, the default SHOULD NOT be the simultaneous-open candidate. If a media stream is inherently TCP-based, the agent SHOULD NOT select the simultaneous-open candidate as default. 3.4. Encoding the SDP TCP-based candidates are encoded into a=candidate lines identically to the UDP encoding described in [6]. However, the transport protocol is set to "tcp-so" for TCP simultaneous-open candidates, "tcp-act" for TCP active candidates, and "tcp-pass" for TCP passive candidates. The addr and port encoded into the candidate attribute for active candidates MUST be set to IP address that will be used for the attempt, but the port MUST be set to 9 (i.e., Discard). For relayed candidates, the IP address that will be used for the attempt is the one from a passive or simultaneous-open candidate from the same STUN server. If the default candidate is TCP, the agent MUST include any SDP parameters required for establishing that TCP connection for that media stream, in case the peer is not ICE aware. For example, if a TCP-based media stream utilizes RFC 4145 [3], the agent MUST follow the procedures defined there for constructing an offer, as if ICE was not in use. For example, if an agent selects its passive candidate as default and the media stream utilizes RFC 4145, the agent MUST include an a=passive attribute. Note that these parameters are not used by ICE, they are only relevant for non-ICE entities. In addition, if a TCP-based candidate is offered, and the default candidate is UDP based, the SDP MUST include any parameters that Rosenberg Expires September 6, 2007 [Page 8] Internet-Draft ICE March 2007 would be required for the TCP stream to be utilized once set up, should it be selected by ICE. This excludes the connection parameters from RFC 4145, which are not utilized between ICE peers. However, if a TCP candidate was meant to be used for TLS, and the default candidate was UDP-based (and of course if it was TCP-based), the parameters of RFC 4572 [5] would need to be included in the SDP. This signals that the TCP candidate is to be used with TLS. 4. Receiving the Initial Offer 4.1. Forming the Check Lists When forming candidate pairs, the following types of candidates can be paired with each other: Local Remote Candidate Candidate ---------------------------- tcp-so tcp-so tcp-act tcp-pass tcp-pass tcp-act When the agent prunes the check list, it MUST also remove any pair for which the local candidate is tcp-pass. The remainder of check list processing works like the UDP case. 5. Connectivity Checks 5.1. Client Procedures 5.1.1. Sending the Request When an agent wants to send a TCP-based connectivity check, it first opens a TCP connection if none yet exists for the 5-tuple on which the check is to be sent. This connection is opened from the local candidate of the check to the remote candidate of the check. If the local candidate is tcp-act, the agent MUST open a connection from the interface associated with that local candidate. This connection MUST be opened from an unallocated port. For host candidates, this is readily done by connecting from the candidates interface. For relayed candidates, the agent uses the procedures in [7] to initiate a new connection from the specified interface on the relay. [[TODO: need to make sure this reconciles with latest TURN]]. Rosenberg Expires September 6, 2007 [Page 9] Internet-Draft ICE March 2007 If the offer/answer exchange, one completed, indicates that the TCP candidates for a media stream will utilize TLS (for example, as a consequence of the presence of the fingerprint attribute from RFC 4572), the agent that opened the connection MUST proceed with TLS handshakes to secure the link prior to proceeding with STUN checks. Once the TCP or TCP/TLS connection is established, connectivity checks are sent over the connection. The agent MUST use the framing defined in RFC 4571 [4], even though the data will include both media (possibly RTP) and STUN packets. This framing MUST be used for the lifetime of this connection. If the TCP connection cannot be established, or the TLS handshakes fail, the check is considered to have failed, and a full-mode agent MUST update the pair state to Failed in the check list. 5.2. Server Procedures An agent MUST be prepared to receive incoming TCP connection requests on any host or relayed TCP candidate that is simultaneous-open or passive. When the connection request is received, the agent MUST accept it. If the offer/answer exchange indicates that TLS is in use, the agent MUST be prepared for TLS negotiation, and complete that exchange prior to receiving STUN requests. The agent MUST use the framing defined in RFC 4571 [4], even though the data will include both media (possibly RTP) and STUN packets. This framing MUST be used for the lifetime of this connection. Once the connection is established, server procedures are identical to those for UDP candidates. Note that STUN requests received on a passive TCP or TCP/TLS candidate will typically produce a remote peer reflexive candidate. 6. Concluding ICE Processing If there are TCP candidates for a media stream, a controlling agent MUST use a regular selection algorithm. When ICE processing for a media stream completes, each agent SHOULD close all TCP connections except the one between the candidate pairs selected by ICE. These two rules are related; the closure of connection on completion of ICE implies that a regular selection algorithm has to be used. This is because aggressive selection might cause transient pairs to be selected. Once such a pair was selected, Rosenberg Expires September 6, 2007 [Page 10] Internet-Draft ICE March 2007 the agents would close the other connections, one of which may be about to be selected as a better choice. This race condition may result in TCP connections being accidentally closed for the pair that ICE selects. 7. Subsequent Offer/Answer Exchanges 7.1. ICE Restarts If an ICE restart occurs for a media stream with TCP candidate pairs that have been selected by ICE, the agents MUST NOT close the connections after the restart. In the offer or answer that causes the restart, an agent MAY include a simultaneous-open candidate whose transport address matches the previously selected candidate. If both agents do this, the result will be a simultaneous-open candidate pair matching an existing TCP connection. In this case, the agents MUST NOT attempt to open a new connection (or start new TLS procedures). Instead, that existing connection is reused and STUN checks are performed. Once the restart completes, if the selected pair does not match the previously selected pair, the TCP connection for the previously selected pair SHOULD be closed by the agent. 8. Media Handling 8.1. Sending Media When sending media, if the selected candidate pair matches an existing TCP connection, that connection MUST be used for sending media. The framing defined in RFC 4571 MUST be used when sending media. For media streams that are not RTP-based and do not normally use RFC 4571, the agent treats the media stream as a byte stream, and assumes that it has its own framing of some sort. It then takes an arbitrary number of bytes from the bytestream, and places that as a payload in the RFC 4571 frames, including the length. The recipient can extract the bytestream and apply the application-specific framing on it. 8.2. Receiving Media The framing defined in RFC 4571 MUST be used when receiving media. For media streams that are not RTP-based and do not normally use RFC 4571, the agent extracts the payload of each RFC 4571 frame, and determines if it is a STUN or an application layer data based on the Rosenberg Expires September 6, 2007 [Page 11] Internet-Draft ICE March 2007 procedures in [6]. If it is application layer data, the agent appends this to the ongoing bytestream collected from the frames. It then parses the bytestream as if it had been directly received over the TCP or TCP/TLS connection. This allows for ICE-tcp to work without regard to the framing mechanism used by the application layer protocol. 9. Connection Management Once a TCP or TCP/TLS connection is opened by ICE, its lifecycle depends on how it is used. If that candidate pair is selected by ICE for usage for media, an agent SHOULD keep the connection open until: o The session terminates o The media stream is removed o An ICE restart takes place, resulting in the selection of a different candidate pair. In these cases, the agent SHOULD close the connection when that event occurs. If a connection has been selected by ICE, an agent MAY close it anyway. As described in the next paragraph, this will cause it to be reopened almost immediately, and in the interim media cannot be sent. Consequently, such closures have a negative effect and are NOT RECOMMENDED. However, there may be cases where an agent needs to close a connection for some reason. If an agent needs to send media on the selected candidate pair, and its TCP connection has closed, either on purpose or due to some error, then: o If the agent's local candidate is tcp-act or tcp-so, it MUST reopen a connection to the remote candidate of the selected pair. o If the agent's local candidate is tcp-pass, the agent MUST await an incoming connection request, and consequently, will not be able to send media until it has been opened. If the TCP connection is established, and the SDP indicates that TLS is in use, the agents MUST redo the TLS handshakes. Once complete, the connection MAY be used for media; re-validation using STUN is not required. Rosenberg Expires September 6, 2007 [Page 12] Internet-Draft ICE March 2007 OPEN ISSUE: Can we use session resumption to avoid redoing this? If the TCP connection cannot be established, the controlling agent SHOULD restart ICE for this media stream. 10. Security Considerations The main threat in ICE is hijacking of connections for the purposes of directing media streams to DoS targets or to malicious users. ICE-tcp prevents that by only using TCP connections that have been validated. Validation requires a STUN transaction to take place over the connection. This transaction cannot complete without both participants knowing a shared secret exchanged in the rendezvous protocol used with ICE, such as SIP. This shared secret, in turn, is protected by that protocol exchange. In the case of SIP, the usage of the sips mechanism is RECOMMENDED. When this is done, an attacker, even if it knows or can guess the port on which an agent is listening for incoming TCP connections, will not be able to open a connection and send media to the agent. A more detailed analysis of this attack and the various ways ICE prevents it are described in [6]. Those considerations apply to this specification. 11. IANA Considerations There are no IANA considerations associated with this specification. 12. Acknowledgements The authors would like to thank Tim Moore, Francois Audet and Roni Even for the reviews and input on this document. 13. References 13.1. Normative References [1] Rosenberg, J., "Simple Traversal Underneath Network Address Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05 (work in progress), October 2006. [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. Rosenberg Expires September 6, 2007 [Page 13] Internet-Draft ICE March 2007 [3] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [4] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006. [5] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006. [6] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in progress), January 2007. [7] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in progress), October 2006. 13.2. Informative References [8] Guha, S., "NAT Behavioral Requirements for TCP", draft-ietf-behave-tcp-05 (work in progress), February 2007. [9] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-19 (work in progress), February 2007. Author's Address Jonathan Rosenberg Cisco Edison, NJ US Email: jdrosen@cisco.com URI: http://www.jdrosen.net Rosenberg Expires September 6, 2007 [Page 14] Internet-Draft ICE March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Rosenberg Expires September 6, 2007 [Page 15]