idnits 2.17.1 draft-salgueiro-dispatch-websocket-sipclf-02.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 abstract seems to contain references ([RFC7118], [RFC6873]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document updates RFC6873, but the abstract doesn't seem to directly say this. It does mention RFC6873 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 171 has weird spacing: '...ple.com asd...' -- The document date (June 26, 2014) is 3592 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH Working Group G. Salgueiro 3 Internet-Draft Cisco 4 Updates: 6873 (if approved) V. Pascual 5 Intended status: Standards Track A. Roman 6 Expires: December 28, 2014 S. Garcia 7 Quobis 8 June 26, 2014 10 Indicating WebSocket Protocol as a Transport in the Session Initiation 11 Protocol (SIP) Common Log Format (CLF) 12 draft-salgueiro-dispatch-websocket-sipclf-02 14 Abstract 16 RFC 7118 [RFC7118] specifies a WebSocket sub-protocol as a reliable 17 real-time transport mechanism between SIP (Session Initiation 18 Protocol) entities to enable usage of SIP in web-oriented 19 deployments. This document updates the SIP Common Log Format (CLF), 20 defined in RFC 6873 [RFC6873], with a new "Transport Flag" for such 21 SIP WebSocket transport. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 28, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 60 4. Usage of the Websocket Transport Flag . . . . . . . . . . . . 3 61 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 5.1. SIP over WebSocket (WS) . . . . . . . . . . . . . . . . . 3 63 5.2. SIP over Secure WebSocket (WSS) . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 9.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 The WebSocket protocol [RFC6455] enables bi-directional message 75 exchange between clients and servers on top of a persistent TCP 76 connection (optionally secured with TLS [RFC5246]). The initial 77 protocol handshake makes use of HTTP [RFC7230] semantics, allowing 78 the WebSocket protocol to reuse existing transport connections. 80 RFC 7118 [RFC7118] defines a WebSocket sub-protocol for transporting 81 SIP messages between a WebSocket client and server. 83 SIP messages can be logged using the Common Log Format defined in RFC 84 6873 [RFC6873]. In order to make such SIP CLF logging possible for 85 SIP messages transported over the WebSocket protocol, a new WebSocket 86 "Transport Flag" ('W') must be added to the "Transport Flags" already 87 defined in RFC 6873 [RFC6873] (i.e., UDP, TCP and SCTP). 89 This document updates RFC 6873 [RFC6873] by defining a new SIP CLF 90 "Transport Flag" value for WebSocket. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Document Conventions 100 This document contains several examples of SIP CLF records showing 101 messages over plain and secure WebSocket connections. The formatting 102 described in this document does not permit the examples to be 103 unambiguously rendered due to the constraints imposed by the 104 formatting rules for RFCs. To avoid ambiguity and to meet the RFC 105 layout requirements, this document uses the markup 106 convention established in [RFC4475]. This markup convention is 107 described in detail in Section 3 of RFC 6873 [RFC6873] and used 108 throughout that document for representing the syntax of SIP CLF 109 records. 111 4. Usage of the Websocket Transport Flag 113 Section 4.2 of RFC6873 [RFC6873] specifies the mandatory fields in a 114 SIP CLF record. The fourth and fifth bytes of the five byte "Flags 115 Field" are the "Transport Flag" and the "Encryption Flag" 116 respectively. SIP messages transported over both a plain and secure 117 WebSocket connection can be clearly distinguished by appropriately 118 setting these two flag fields. 120 The currently registered values of the "Transport Flag" (Section 9.2 121 of RFC 6873) are [UDP ('U'), TCP ('T'), and SCTP ('S')]. This 122 document defines and registers a new "Transport Flag" value 'W' for 123 WebSocket transport of SIP messages and consequently updates RFC 6873 124 [RFC6873] and the IANA "SIP CLF Transport Flag Values" registry. 126 SIP CLF records of messages transported over a plain WebSocket 127 connection (WS) MUST set the "Transport Flag" to this new 'W' value 128 and the "Encryption Flag" value to 'U' (Unencrypted). SIP CLF 129 records of messages transported over a secure WebSocket (WSS) 130 connection (i.e. WS over TLS) MUST set the "Transport Flag" to this 131 new 'W' value and the "Encryption Flag" value to 'E' (Encrypted). 133 5. Examples 135 The following examples show sample SIP CLF records logged for SIP 136 messages transported over both plain and secure WebSocket 137 connections. 139 5.1. SIP over WebSocket (WS) 141 The following example represents a SIP INVITE request sent over a 142 plain WebSocket connection. For the sake of brevity, the Session 143 Description Protocol (SDP) [RFC4566] body is omitted. 145 INVITE sip:bob@example.com SIP/2.0 146 Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 147 From: sip:alice@example.com;tag=asdyka899 148 To: sip:bob@example.com 149 Call-ID: asidkj3ss 150 CSeq: 1 INVITE 151 Max-Forwards: 70 152 Date: Thu, 6 Feb 2014 15:02:03 GMT 153 Supported: path, outbound, gruu 154 Route: 155 Contact: 156 Content-Type: application/sdp 157 Content-Length: 418 159 Shown below is approximately how this message would appear as a 160 single record in a SIP CLF logging file if encoded according to the 161 syntax described in [RFC6873]. Due to RFC conventions, this log 162 entry has been split into five lines, instead of the two lines that 163 actually appear in a log file; and the Tab characters have been 164 padded out using spaces to simulate their appearance in a text 165 terminal. 167 A0000E7,0053005C005E00720080009200A600A800BE00C800D200DE00E7 168 169 1328821153.010 RORWU 1 INVITE - sip:bob@example.com 170 192.0.2.10:80 192.0.2.200:56485 sip:bob@example.com - 171 sip:alice@example.com asdyka899 asidkj3ss S1781761-88 172 C67651-11 173 175 A bit-exact version of the actual log entry is provided here, Base64 176 encoded [RFC4648], using the uuencode utility. 178 begin-base64 644 clf_ws_record 179 QTAwMDBFNywwMDUzMDA1QzAwNUUwMDcyMDA4MDAwOTIwMEE2MDBBODAwQkUwMEM4MDBE 180 MjAwREUwMEU3CjEzMjg4MjExNTMuMDEwCVJPUldVCTEgSU5WSVRFCS0Jc2lwOmJvYkBl 181 eGFtcGxlLmNvbQkxOTIuMC4yLjEwOjgwCTE5Mi4wLjIuMjAwOjU2NDg1CXNpcDpib2JA 182 ZXhhbXBsZS5jb20JLQlzaXA6YWxpY2VAZXhhbXBsZS5jb20JYXNkeWthODk5CWFzaWRr 183 ajNzcwlTMTc4MTc2MS04OAlDNjc2NTEtMTEKCg== 184 ==== 186 The original SIP CLF format can be obtained by reversing the effects 187 of uuencode by simply applying the uudecode transform. Additionally, 188 to recover the unencoded file, the Base64 text above may be passed as 189 input to the following perl script (the output should be redirected 190 to a file). 192 194 #!/usr/bin/perl 195 use strict; 196 my $bdata = ""; 197 use MIME::Base64; 198 while(<>) 199 { 200 if (/begin-base64 644 clf_ws_record/ .. /-- ==== --/) 201 { 202 if ( m/^\s*[^\s]+\s*$/) 203 { 204 $bdata = $bdata . $_; 205 } 206 } 207 } 208 print decode_base64($bdata); 210 212 5.2. SIP over Secure WebSocket (WSS) 214 The following example represents a SIP INVITE request sent over a 215 secure WebSocket connection (i.e., WebSocket over TLS [RFC5246]). 216 For the sake of brevity, the SDP body is omitted. 218 INVITE sip:bob@example.com SIP/2.0 219 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 220 From: sip:alice@example.com;tag=asdyka899 221 To: sip:bob@example.com 222 Call-ID: asidkj3ss 223 CSeq: 1 INVITE 224 Max-Forwards: 70 225 Date: Thu, 6 Feb 2014 15:02:03 GMT 226 Supported: path, outbound, gruu 227 Route: 228 Contact: 229 Content-Type: application/sdp 230 Content-Length: 439 232 Shown below is approximately how this message would appear as a 233 single record in a SIP CLF logging file if encoded according to the 234 syntax described in [RFC6873]. Due to RFC conventions, this log 235 entry has been split into five lines, instead of the two lines that 236 actually appear in a log file; and the Tab characters have been 237 padded out using spaces to simulate their appearance in a text 238 terminal. 240 A0000E8,0053005C005E00720081009300A700A900BF00C900D300DF00E8 241 242 1328821153.010 RORWE 1 INVITE - sip:bob@example.com 243 192.0.2.10:443 192.0.2.200:56485 sip:bob@example.com - 244 sip:alice@example.com:5060 asdyka899 asidkj3ss S1781761-88 245 C67651-11 246 248 A bit-exact version of the actual log entry is provided here, Base64 249 encoded. 251 begin-base64 644 clf_ws_record 252 QTAwMDBFOCwwMDUzMDA1QzAwNUUwMDcyMDA4MTAwOTMwMEE3MDBBOTAwQkYwMEM5MDBE 253 MzAwREYwMEU4CjEzMjg4MjExNTMuMDEwCVJPUldVCTEgSU5WSVRFCS0Jc2lwOmJvYkBl 254 eGFtcGxlLmNvbQkxOTIuMC4yLjEwOjQ0MwkxOTIuMC4yLjIwMDo1NjQ4NQlzaXA6Ym9i 255 QGV4YW1wbGUuY29tCS0Jc2lwOmFsaWNlQGV4YW1wbGUuY29tCWFzZHlrYTg5OQlhc2lk 256 a2ozc3MJUzE3ODE3NjEtODgJQzY3NjUxLTExCgo= 257 ==== 259 6. Security Considerations 261 This document merely adds a new "Transport Flag" value for the 262 WebSocket protocol. This value may be set in a SIP CLF record, but 263 its use does not intrinsically introduce and new security 264 considerations. When logging protocol information, such as with SIP 265 CLF, there are a myriad of security, privacy and data protection to 266 consider. These are exhaustively described in RFC 6872 [RFC6872] and 267 RFC 6873 [RFC6873]. 269 Any security considerations specific to the WebSocket protocol or its 270 application as a transport for SIP are detailed in the relevant 271 specifications (the WebSocket protocol [RFC6455] and SIP over 272 WebSockets [RFC7118]) and are considered outside the scope of this 273 document. 275 7. IANA Considerations 277 This document defines a new value ('W') for SIP CLF "Transport Flag" 278 and requests IANA to register this value in the registry titled "SIP 279 CLF Transport Flag Values", as shown in Table 1 below. 281 +-------+--------------------+------------------+ 282 | Value | Transport Protocol | Reference | 283 +-------+--------------------+------------------+ 284 | W | WebSocket | RFC7118, RFCXXXX | 285 +-------+--------------------+------------------+ 287 Table 1: IANA-Registered SIP CLF Transport Flag 289 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 290 this specification, and remove this paragraph on publication.]] 292 8. Acknowledgements 294 The authors would like to thank Vijay Gurbani for shepherding this 295 document and Area Director Richard Barnes for his sponsorship. This 296 work benefitted from the thorough review and constructive comments of 297 Richard Barnes, Barry Leiba, Benoit Claise, Pete Resnick, Stephen 298 Farrel and Vijay Gurbani. 300 9. References 302 9.1. Normative References 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 308 6455, December 2011. 310 [RFC6872] Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O. 311 Festor, "The Common Log Format (CLF) for the Session 312 Initiation Protocol (SIP): Framework and Information 313 Model", RFC 6872, February 2013. 315 [RFC6873] Salgueiro, G., Gurbani, V., and A. Roach, "Format for the 316 Session Initiation Protocol (SIP) Common Log Format 317 (CLF)", RFC 6873, February 2013. 319 [RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, 320 "The WebSocket Protocol as a Transport for the Session 321 Initiation Protocol (SIP)", RFC 7118, January 2014. 323 9.2. Informative References 325 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 326 and H. Schulzrinne, "Session Initiation Protocol (SIP) 327 Torture Test Messages", RFC 4475, May 2006. 329 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 330 Description Protocol", RFC 4566, July 2006. 332 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 333 Encodings", RFC 4648, October 2006. 335 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 336 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 338 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 339 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 340 2014. 342 Authors' Addresses 344 Gonzalo Salgueiro 345 Cisco Systems, Inc. 346 7200-12 Kit Creek Road 347 Research Triangle Park, NC 27709 348 US 350 Email: gsalguei@cisco.com 352 Victor Pascual 353 Quobis 355 Email: victor.pascual@quobis.com 357 Anton Roman 358 Quobis 360 Email: anton.roman@quobis.com 362 Sergio Garcia Ramos 363 Quobis 365 Email: sergio.garcia@quobis.com