CLUE R. Hansen Internet-Draft A. Romanow Intended status: Informational Cisco Systems Expires: May 20, 2012 November 17, 2011 Evaluation of using SIP or an independent protocol for CLUE messaging draft-hansen-clue-protocol-choices-evaluation-00 Abstract This document evaluates the advantages and disadvantages of using SIP or an independent protocol for conveying CLUE messages/ Status of this Memo This Internet-Draft is submitted 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 May 20, 2012. Copyright Notice Copyright (c) 2011 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 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. Hansen & Romanow Expires May 20, 2012 [Page 1] Internet-Draft Evaluation of CLUE messaging choices November 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol negotiation and establishment . . . . . . . . . . . . 3 4. Interoperability and Extensibility . . . . . . . . . . . . . . 4 5. Development workload . . . . . . . . . . . . . . . . . . . . . 5 6. Message fragmentation . . . . . . . . . . . . . . . . . . . . . 5 7. Message routing and intermediary devices . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Hansen & Romanow Expires May 20, 2012 [Page 2] Internet-Draft Evaluation of CLUE messaging choices November 2011 1. Introduction This note considers draft-wenger-clue-transport-01 and gives an evaluation of the choices for conveying the CLUE messages. It does not address the rest of the document (method of encoding the CLUE information, etc). The note primarily compares the trade-offs between conveying CLUE messages using SIP, and using an independent protocol negotiated via SIP. /> 2. 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 RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. 3. Protocol negotiation and establishment If SIP is being used to transport the CLUE messages then, by definition, once the call is in progress a SIP session will already be established - unless a separate session needs to be established (the case if SUBSCRIBE/NOTIFY is used) sending and receiving CLUE messages can be done via this pre-established session. Designed for extensibility, SIP also has mechanisms for notifying the far end of its capabilities and requirements for new messages, packages, etc, which would allow CLUE messages to be added relatively easily. If an independent protocol is used it should be negotiated as a separate media stream in the SDP. This allows connection details to be exchanged along with any other details that need to be worked out prior to establishment (for instance, in circumstances where one side connects while the other listens for a connection this can be negotiated as part of the SDP offer/answer exchange as per RFC 4145 [RFC4145]). There is ample precedent for independent control protocols being negotiated in the SIP SDP (BFCP, H.224, etc), and as such the risks and effort of adding a new media session to negotiation a new protocol are limited. Routing an independent protocol can be more difficult - in complicated organisation-to-organisation calls establishing a connection between the two endpoints may require complicated firewall and NAT traversal. Experience has shown that in such situations it can in practice be challenging to establish a TCP connection; the adoption of ICE-TCP is much more limited than the UDP variant, and firewalls and session border controllers seem much less willing to allow TCP traffic. Further, for the call to be at all successful it Hansen & Romanow Expires May 20, 2012 [Page 3] Internet-Draft Evaluation of CLUE messaging choices November 2011 must be possible to route UDP traffic in the form of audio and video packets bidirectionally between both ends. For these reasons we would recommend using UDP over TCP for an independent protocol - a lesson hard-learned with BFCP (originally implemented in TCP, but which many customer setups were unable to route, it was redesigned and reimplemented in UDP). 4. Interoperability and Extensibility If SIP is used to transport CLUE messages it effectively limits the adoption of CLUE to SIP-SIP calls. If there is ever demand for CLUE over H.323, XMPP, or any other call protocol, it would be necessary to begin the specification process again to establish how it could be transported in the new protocols. Further, interworked calls would have to translate between the two sets of messages; this is not always something that can be done cleanly without discarding information that can't be easily translated between the different specifications or requirements of the call protocols. In contrast, an independent protocol is agnostic to the choice of call protocol - if an independent CLUE protocol were used then adding CLUE support to new call protocols, such as H.323 or XMPP, only requires negotiation for the CLUE protocol to be added to the call protocol. On interworked calls the CLUE protocol would still connect end-to-end just like in a standard call with no need for message translation. Extending the protocol is also less challenging and constrainted with an independent protocol; with full control over the protocol if new behaviour is required then the protocol can be redesigned to meet these requirements, versioned, and with fallback to older behaviour if required. SIP would also allow some degree of versioning but there is the potential risk that even if suitable for current CLUE messaging using SIP might restrict later development of the CLUE protocol. In addition the messaging overhead associated with SIP would also be a limitation if CLUE were to ever include smaller, more frequent messages such as indicating information on loudest speaker or focused participants (which would potentially change on a second-by-second basis); a SIP message is hundreds of bytes long, which leads to an extremely high overhead if the protocol ever calls for sending small snippets of information. Hansen & Romanow Expires May 20, 2012 [Page 4] Internet-Draft Evaluation of CLUE messaging choices November 2011 5. Development workload From the design point of view there is likely more work in designing a new, independent CLUE protocol than in extending SIP to include CLUE messages, though the actual message-passing section of the CLUE protocol should be relatively straightforward. In contrast, while it will vary from vendor to vendor, the implementation workload of adding the protocol to SIP is actually likely to be larger than that of using an independent protocol: for an independent protocol standard libraries can be used for the transport protocol, and it would even be possible to create a CLUE protocol library that could then be distributed, making adoption very straightforward. In contrast, the variety of SIP stacks means that adding CLUE support to SIP will need to be done independently by each vendor. Note that even if using an independent protocol some minor changes will need to be made to SIP stacks to add support for the negotiation of the protocol. 6. Message fragmentation CLUE messages may in certain circumstances need to convey information on numerous endpoints, resulting in messages thousands or even tens of thousands of bytes long, particularly if more verbose message formats such as XML are chosen. This means the eventual protocol will have to deal with significant fragmentation issues. SIP itself doesn't have any provision for dealing with packet fragmentation, instead relying on the underlying transport protocols to reassemble the SIP message. For large SIP messages RFC 3261 [RFC3261] actually mandates against the use of UDP (see section 18.1.1) - "If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [RFC2914] congestion controlled transport protocol, such as TCP". In practice, however, many implementations are transport-agnostic and do send SIP messages that require fragmentation over UDP. Without TCP's resend mechanism if any fragment of the packet is lost the entire message must be resent using SIP's in-built much slower resend mechanism. With potentially extremely large SIP messages fragmented across numerous UDP packets, if using CLUE via SIP then TCP For an independent protocol,even if based on UDP then the transport protocol on top that adds reliability (such as TCP over UDP, STCP, UDT etc) will either take care of fragmentation itself, or be Hansen & Romanow Expires May 20, 2012 [Page 5] Internet-Draft Evaluation of CLUE messaging choices November 2011 configurable to run in stream mode such that the sender can easily chunk the data and avoid fragmentation that way. 7. Message routing and intermediary devices SIP messages travel hop-by-hop, with most proxies remaining in the call path once the call is established, while media protocols are end-to-end, generally travelling directly from endpoint to endpoint (though session border controllers or ICE requirements may mean that in more complex setups they too may have an intermediary hop or two). The traditional issue with the SIP hop-by-hop route is the increase in latency, but CLUE's latency requirements are at least an order of magnitude less sensitive than real-time media and thus can be safely disregarded, at least for current messaging requirements. Security is a second issue - while SIP messages can be secured with TLS they are decoded and re-encoded at each hop, and thus potentially expose the contents of the CLUE messages to intermediary devices. On the other hand, even if an independent protocol is routed via an SBC or STUN server there is no normal need for the intermediary devices to be able to decrypt the packets. How serious an exposure this is is debatable, as a chain of trust can be built up via TLS certificate exchange to authenticate the intermediary devices and it is possible that the information contained in the CLUE messages is on par with the media information conveyed in SDP. This hop-by-hop decoding does have one advantage: it allows potential modification of the contents of the CLUE messages by CLUE-aware intermediary devices. Administrators wishing to set CLUE restrictions or policies could thus do so much more neatly at the server level rather than that of the individual endpoints. One final issue with using SIP, potentially the most troublesome, is the need for intermediary devices to either be CLUE-aware or pass the contents of the CLUE messages transparently. SIP devices that act as back-to-back user agents (many session border controllers and some PBX-style servers) act to terminate the SIP calls and generate new ones, rather than passing the existing messages. Such devices can be notoriously problematic for slowing the rate at which some setups can adopt new SIP functionality as an intermediary B2BUA doesn't understand the new functionality, and effectively strips it during transmission. SBCs in particular can be restrictive of what they re- encode (as they also provide security). This is even a potential problem for a stand-alone CLUE protocol, as it would need to be negotiated in SIP (though B2BUAs are often, or can usually be configured to be, more transparent to SDP contents). Hansen & Romanow Expires May 20, 2012 [Page 6] Internet-Draft Evaluation of CLUE messaging choices November 2011 8. Security Considerations Setting aside leaking data to an intermediary device, both using SIP for transport or using an independent protocol allow for security; in SIP the messages will be protected by the standard SIP TLS authentication/encryption, while an independent protocol, if stream- based, also allows TLS to be used. If the protocol is not stream- based, or there is some concern about exposing the transport protocol built on top of UDP, then a method such as DTLS can be used to encrypt the entire UDP channel. In the independent case authentication can be verified by certificate exchange alone if both endpoints have valid trust chains for the other's certificate, or via fingerprints included as part of the SIP negotiation for the protocol (assuming the SIP link itself is secured and authenticated). If based on RTP, the independent protocol could instead use SRTP. As such there is little to choose between the levels of security provided - the end to end nature of an independent protocol can allow authentication when there isn't an unbroken encrypted and authenticated chain across SIP TLS if both sides can validate the other's certificates (relatively straightforward for calls within an organisation, generally impractical for calls between organisations). Indeed, if using TLS or DTLS an independent CLUE protocol could be encrypted and potentially authenticated even if SIP was being used without encryption. The only trade-off is that while TLS (and SRTP) are widely deployed and hence should be usable across an independent link with little development work if it is decided to use different encryption method (such as DTLS) then additional work will be required. 9. Recommendations There is clearly no obvious "right answer" here - both methods (using SIP or an independent protocol) have advantages and disadvantages. SIP is manifestly the 'simpler' answer: it provides a pre-existing reliable channel, includes support for encryption and authentication, and allows negotiation of new packages such as CLUE. However, it also sets constraints on what the CLUE protocol must be: CLUE won't be usable in H.323 or other protocols other than SIP, and the CLUE messages and how they are exchanged will need to fit into the SIP mechanisms. The latency and messaging overheads of SIP are not currently a problem, but were CLUE to ever want to include the capability for sending small, frequent updates then they could become problematic or prohibitive. Hansen & Romanow Expires May 20, 2012 [Page 7] Internet-Draft Evaluation of CLUE messaging choices November 2011 If we were in a position of choosing, on balance we would choose to use an independent protocol: while more work would be required up- front for the development, there would be more control over what the protocol is and how it could be extended in the future. It wouldn't limit things down the line to SIP, and it would potentially speed adoption by allowing implementers to use existing transport protocol stacks (or even a complete CLUE protocol library for all the signaling and messaging). 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [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. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. Authors' Addresses Robert Hansen Cisco Systems Langely, England Email: rohanse2@cisco.com Allyn Romanow Cisco Systems San Jose, CA 95134 USA Email: allyn@cisco.com Hansen & Romanow Expires May 20, 2012 [Page 8]