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