Internet DRAFT - draft-hansen-clue-protocol-choices-evaluation
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
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]