idnits 2.17.1 draft-hansen-clue-protocol-choices-evaluation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 17, 2011) is 4542 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CLUE R. Hansen 3 Internet-Draft A. Romanow 4 Intended status: Informational Cisco Systems 5 Expires: May 20, 2012 November 17, 2011 7 Evaluation of using SIP or an independent protocol for CLUE messaging 8 draft-hansen-clue-protocol-choices-evaluation-00 10 Abstract 12 This document evaluates the advantages and disadvantages of using SIP 13 or an independent protocol for conveying CLUE messages/ 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on May 20, 2012. 32 Copyright Notice 34 Copyright (c) 2011 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Protocol negotiation and establishment . . . . . . . . . . . . 3 52 4. Interoperability and Extensibility . . . . . . . . . . . . . . 4 53 5. Development workload . . . . . . . . . . . . . . . . . . . . . 5 54 6. Message fragmentation . . . . . . . . . . . . . . . . . . . . . 5 55 7. Message routing and intermediary devices . . . . . . . . . . . 6 56 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 57 9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 7 58 10. Normative References . . . . . . . . . . . . . . . . . . . . . 8 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 61 1. Introduction 63 This note considers draft-wenger-clue-transport-01 and gives an 64 evaluation of the choices for conveying the CLUE messages. It does 65 not address the rest of the document (method of encoding the CLUE 66 information, etc). The note primarily compares the trade-offs 67 between conveying CLUE messages using SIP, and using an independent 68 protocol negotiated via SIP. /> 70 2. Terminology 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [RFC2119] and 75 indicate requirement levels for compliant implementations. 77 3. Protocol negotiation and establishment 79 If SIP is being used to transport the CLUE messages then, by 80 definition, once the call is in progress a SIP session will already 81 be established - unless a separate session needs to be established 82 (the case if SUBSCRIBE/NOTIFY is used) sending and receiving CLUE 83 messages can be done via this pre-established session. Designed for 84 extensibility, SIP also has mechanisms for notifying the far end of 85 its capabilities and requirements for new messages, packages, etc, 86 which would allow CLUE messages to be added relatively easily. 88 If an independent protocol is used it should be negotiated as a 89 separate media stream in the SDP. This allows connection details to 90 be exchanged along with any other details that need to be worked out 91 prior to establishment (for instance, in circumstances where one side 92 connects while the other listens for a connection this can be 93 negotiated as part of the SDP offer/answer exchange as per RFC 4145 94 [RFC4145]). There is ample precedent for independent control 95 protocols being negotiated in the SIP SDP (BFCP, H.224, etc), and as 96 such the risks and effort of adding a new media session to 97 negotiation a new protocol are limited. 99 Routing an independent protocol can be more difficult - in 100 complicated organisation-to-organisation calls establishing a 101 connection between the two endpoints may require complicated firewall 102 and NAT traversal. Experience has shown that in such situations it 103 can in practice be challenging to establish a TCP connection; the 104 adoption of ICE-TCP is much more limited than the UDP variant, and 105 firewalls and session border controllers seem much less willing to 106 allow TCP traffic. Further, for the call to be at all successful it 107 must be possible to route UDP traffic in the form of audio and video 108 packets bidirectionally between both ends. For these reasons we 109 would recommend using UDP over TCP for an independent protocol - a 110 lesson hard-learned with BFCP (originally implemented in TCP, but 111 which many customer setups were unable to route, it was redesigned 112 and reimplemented in UDP). 114 4. Interoperability and Extensibility 116 If SIP is used to transport CLUE messages it effectively limits the 117 adoption of CLUE to SIP-SIP calls. If there is ever demand for CLUE 118 over H.323, XMPP, or any other call protocol, it would be necessary 119 to begin the specification process again to establish how it could be 120 transported in the new protocols. Further, interworked calls would 121 have to translate between the two sets of messages; this is not 122 always something that can be done cleanly without discarding 123 information that can't be easily translated between the different 124 specifications or requirements of the call protocols. 126 In contrast, an independent protocol is agnostic to the choice of 127 call protocol - if an independent CLUE protocol were used then adding 128 CLUE support to new call protocols, such as H.323 or XMPP, only 129 requires negotiation for the CLUE protocol to be added to the call 130 protocol. On interworked calls the CLUE protocol would still connect 131 end-to-end just like in a standard call with no need for message 132 translation. 134 Extending the protocol is also less challenging and constrainted with 135 an independent protocol; with full control over the protocol if new 136 behaviour is required then the protocol can be redesigned to meet 137 these requirements, versioned, and with fallback to older behaviour 138 if required. SIP would also allow some degree of versioning but 139 there is the potential risk that even if suitable for current CLUE 140 messaging using SIP might restrict later development of the CLUE 141 protocol. 143 In addition the messaging overhead associated with SIP would also be 144 a limitation if CLUE were to ever include smaller, more frequent 145 messages such as indicating information on loudest speaker or focused 146 participants (which would potentially change on a second-by-second 147 basis); a SIP message is hundreds of bytes long, which leads to an 148 extremely high overhead if the protocol ever calls for sending small 149 snippets of information. 151 5. Development workload 153 From the design point of view there is likely more work in designing 154 a new, independent CLUE protocol than in extending SIP to include 155 CLUE messages, though the actual message-passing section of the CLUE 156 protocol should be relatively straightforward. 158 In contrast, while it will vary from vendor to vendor, the 159 implementation workload of adding the protocol to SIP is actually 160 likely to be larger than that of using an independent protocol: for 161 an independent protocol standard libraries can be used for the 162 transport protocol, and it would even be possible to create a CLUE 163 protocol library that could then be distributed, making adoption very 164 straightforward. In contrast, the variety of SIP stacks means that 165 adding CLUE support to SIP will need to be done independently by each 166 vendor. 168 Note that even if using an independent protocol some minor changes 169 will need to be made to SIP stacks to add support for the negotiation 170 of the protocol. 172 6. Message fragmentation 174 CLUE messages may in certain circumstances need to convey information 175 on numerous endpoints, resulting in messages thousands or even tens 176 of thousands of bytes long, particularly if more verbose message 177 formats such as XML are chosen. This means the eventual protocol 178 will have to deal with significant fragmentation issues. 180 SIP itself doesn't have any provision for dealing with packet 181 fragmentation, instead relying on the underlying transport protocols 182 to reassemble the SIP message. For large SIP messages RFC 3261 183 [RFC3261] actually mandates against the use of UDP (see section 184 18.1.1) - "If a request is within 200 bytes of the path MTU, or if it 185 is larger than 1300 bytes and the path MTU is unknown, the request 186 MUST be sent using an RFC 2914 [RFC2914] congestion controlled 187 transport protocol, such as TCP". In practice, however, many 188 implementations are transport-agnostic and do send SIP messages that 189 require fragmentation over UDP. Without TCP's resend mechanism if 190 any fragment of the packet is lost the entire message must be resent 191 using SIP's in-built much slower resend mechanism. With potentially 192 extremely large SIP messages fragmented across numerous UDP packets, 193 if using CLUE via SIP then TCP 195 For an independent protocol,even if based on UDP then the transport 196 protocol on top that adds reliability (such as TCP over UDP, STCP, 197 UDT etc) will either take care of fragmentation itself, or be 198 configurable to run in stream mode such that the sender can easily 199 chunk the data and avoid fragmentation that way. 201 7. Message routing and intermediary devices 203 SIP messages travel hop-by-hop, with most proxies remaining in the 204 call path once the call is established, while media protocols are 205 end-to-end, generally travelling directly from endpoint to endpoint 206 (though session border controllers or ICE requirements may mean that 207 in more complex setups they too may have an intermediary hop or two). 208 The traditional issue with the SIP hop-by-hop route is the increase 209 in latency, but CLUE's latency requirements are at least an order of 210 magnitude less sensitive than real-time media and thus can be safely 211 disregarded, at least for current messaging requirements. 213 Security is a second issue - while SIP messages can be secured with 214 TLS they are decoded and re-encoded at each hop, and thus potentially 215 expose the contents of the CLUE messages to intermediary devices. On 216 the other hand, even if an independent protocol is routed via an SBC 217 or STUN server there is no normal need for the intermediary devices 218 to be able to decrypt the packets. How serious an exposure this is 219 is debatable, as a chain of trust can be built up via TLS certificate 220 exchange to authenticate the intermediary devices and it is possible 221 that the information contained in the CLUE messages is on par with 222 the media information conveyed in SDP. 224 This hop-by-hop decoding does have one advantage: it allows potential 225 modification of the contents of the CLUE messages by CLUE-aware 226 intermediary devices. Administrators wishing to set CLUE 227 restrictions or policies could thus do so much more neatly at the 228 server level rather than that of the individual endpoints. 230 One final issue with using SIP, potentially the most troublesome, is 231 the need for intermediary devices to either be CLUE-aware or pass the 232 contents of the CLUE messages transparently. SIP devices that act as 233 back-to-back user agents (many session border controllers and some 234 PBX-style servers) act to terminate the SIP calls and generate new 235 ones, rather than passing the existing messages. Such devices can be 236 notoriously problematic for slowing the rate at which some setups can 237 adopt new SIP functionality as an intermediary B2BUA doesn't 238 understand the new functionality, and effectively strips it during 239 transmission. SBCs in particular can be restrictive of what they re- 240 encode (as they also provide security). This is even a potential 241 problem for a stand-alone CLUE protocol, as it would need to be 242 negotiated in SIP (though B2BUAs are often, or can usually be 243 configured to be, more transparent to SDP contents). 245 8. Security Considerations 247 Setting aside leaking data to an intermediary device, both using SIP 248 for transport or using an independent protocol allow for security; in 249 SIP the messages will be protected by the standard SIP TLS 250 authentication/encryption, while an independent protocol, if stream- 251 based, also allows TLS to be used. If the protocol is not stream- 252 based, or there is some concern about exposing the transport protocol 253 built on top of UDP, then a method such as DTLS can be used to 254 encrypt the entire UDP channel. In the independent case 255 authentication can be verified by certificate exchange alone if both 256 endpoints have valid trust chains for the other's certificate, or via 257 fingerprints included as part of the SIP negotiation for the protocol 258 (assuming the SIP link itself is secured and authenticated). If 259 based on RTP, the independent protocol could instead use SRTP. 261 As such there is little to choose between the levels of security 262 provided - the end to end nature of an independent protocol can allow 263 authentication when there isn't an unbroken encrypted and 264 authenticated chain across SIP TLS if both sides can validate the 265 other's certificates (relatively straightforward for calls within an 266 organisation, generally impractical for calls between organisations). 267 Indeed, if using TLS or DTLS an independent CLUE protocol could be 268 encrypted and potentially authenticated even if SIP was being used 269 without encryption. The only trade-off is that while TLS (and SRTP) 270 are widely deployed and hence should be usable across an independent 271 link with little development work if it is decided to use different 272 encryption method (such as DTLS) then additional work will be 273 required. 275 9. Recommendations 277 There is clearly no obvious "right answer" here - both methods (using 278 SIP or an independent protocol) have advantages and disadvantages. 280 SIP is manifestly the 'simpler' answer: it provides a pre-existing 281 reliable channel, includes support for encryption and authentication, 282 and allows negotiation of new packages such as CLUE. 284 However, it also sets constraints on what the CLUE protocol must be: 285 CLUE won't be usable in H.323 or other protocols other than SIP, and 286 the CLUE messages and how they are exchanged will need to fit into 287 the SIP mechanisms. The latency and messaging overheads of SIP are 288 not currently a problem, but were CLUE to ever want to include the 289 capability for sending small, frequent updates then they could become 290 problematic or prohibitive. 292 If we were in a position of choosing, on balance we would choose to 293 use an independent protocol: while more work would be required up- 294 front for the development, there would be more control over what the 295 protocol is and how it could be extended in the future. It wouldn't 296 limit things down the line to SIP, and it would potentially speed 297 adoption by allowing implementers to use existing transport protocol 298 stacks (or even a complete CLUE protocol library for all the 299 signaling and messaging). 301 10. Normative References 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, March 1997. 306 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 307 RFC 2914, September 2000. 309 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 310 A., Peterson, J., Sparks, R., Handley, M., and E. 311 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 312 June 2002. 314 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 315 the Session Description Protocol (SDP)", RFC 4145, 316 September 2005. 318 Authors' Addresses 320 Robert Hansen 321 Cisco Systems 322 Langely, 323 England 325 Email: rohanse2@cisco.com 327 Allyn Romanow 328 Cisco Systems 329 San Jose, CA 95134 330 USA 332 Email: allyn@cisco.com