Internet DRAFT - draft-hansen-clue-protocol-choices-evaluation


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


   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

   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
   ( 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",
   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

   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

   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

   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

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


   Allyn Romanow
   Cisco Systems
   San Jose, CA  95134


Hansen & Romanow          Expires May 20, 2012                  [Page 8]