draft-ietf-sipcore-sip-websocket-02.txt   draft-ietf-sipcore-sip-websocket-03.txt 
SIPCORE Working Group I. Baz Castillo SIPCORE Working Group I. Baz Castillo
Internet-Draft J. Millan Villegas Internet-Draft J. Millan Villegas
Intended status: Standards Track Unaffiliated Intended status: Standards Track Unaffiliated
Expires: January 31, 2013 V. Pascual Expires: March 11, 2013 V. Pascual
Acme Packet Acme Packet
July 30, 2012 September 7, 2012
The WebSocket Protocol as a Transport for the Session Initiation The WebSocket Protocol as a Transport for the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sipcore-sip-websocket-02 draft-ietf-sipcore-sip-websocket-03
Abstract Abstract
The WebSocket protocol enables two-way realtime communication between The WebSocket protocol enables two-way realtime communication between
clients and servers. This document specifies a new WebSocket sub- clients and servers. This document specifies a new WebSocket sub-
protocol as a reliable transport mechanism between SIP (Session protocol as a reliable transport mechanism between SIP (Session
Initiation Protocol) entities to enable usage of SIP in new Initiation Protocol) entities to enable usage of SIP in new
scenarios. scenarios.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 31, 2013. This Internet-Draft will expire on March 11, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 3 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 3
4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 4 4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 4
4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. SIP encoding . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. SIP encoding . . . . . . . . . . . . . . . . . . . . . . . 5
5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . 6 5.2. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . 6
5.2.1. Via Transport Parameter . . . . . . . . . . . . . . . 6 5.2.1. Via Transport Parameter . . . . . . . . . . . . . . . 6
5.2.2. SIP URI Transport Parameter . . . . . . . . . . . . . 6 5.2.2. SIP URI Transport Parameter . . . . . . . . . . . . . 6
5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 7 5.2.3. Via received parameter . . . . . . . . . . . . . . . . 7
6. Connection Keep Alive . . . . . . . . . . . . . . . . . . . . 7 5.2.4. SIP transport implementation requirements . . . . . . 7
7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 8
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Connection Keep Alive . . . . . . . . . . . . . . . . . . . . 8
8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 8 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 10 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 15 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 15
9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 15 9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 15 10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 16
10.2. Registration of new NAPTR service field values . . . . . . 15 10.2. Registration of new NAPTR service field values . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 17 Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 18
A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 18 A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 19
A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 19 A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 20
Appendix B. HTTP Topology Hiding . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The WebSocket [RFC6455] protocol enables message exchange between The WebSocket [RFC6455] protocol enables message exchange between
clients and servers on top of a persistent TCP connection (optionally clients and servers on top of a persistent TCP connection (optionally
secured with TLS [RFC5246]). The initial protocol handshake makes secured with TLS [RFC5246]). The initial protocol handshake makes
use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to
reuse existing HTTP infrastructure. reuse existing HTTP infrastructure.
skipping to change at page 7, line 9 skipping to change at page 7, line 9
protocol as transport. protocol as transport.
The updated augmented BNF (Backus-Naur Form) for this parameter is The updated augmented BNF (Backus-Naur Form) for this parameter is
the following (the original BNF for this parameter can be found in the following (the original BNF for this parameter can be found in
[RFC3261], which was then updated by [RFC4168]): [RFC3261], which was then updated by [RFC4168]):
transport-param = "transport=" transport-param = "transport="
( "udp" / "tcp" / "sctp" / "tls" / "ws" ( "udp" / "tcp" / "sctp" / "tls" / "ws"
/ other-transport ) / other-transport )
5.2.3. Via received parameter
[RFC3261] section 18.2.1 "Receiving Requests" states the following:
When the server transport receives a request over any transport,
it MUST examine the value of the "sent-by" parameter in the top
Via header field value. If the host portion of the "sent-by"
field contains a domain name, or if it contains an IP address that
differs from the packet source address, the server MUST add a
"received" parameter to that Via header field value. This
parameter MUST contain the source address from which the packet
was received.
The requirement of adding the "received" parameter does not fit well
into the WebSocket protocol design. The WebSocket connection
handshake reuses existing HTTP infrastructure in which there could be
an unknown number of HTTP proxies and/or TCP load balancers between
the SIP WebSocket Client and Server, so the source address the server
would write into the Via "received" parameter would be the address of
the HTTP/TCP intermediary in front of it. This could reveal
sensitive information about the internal topology of the Server's
network to the Client.
Given the fact that SIP responses can only be sent over the existing
WebSocket connection, the Via "received" parameter is of little use.
Therefore, in order to allow hiding possible sensitive information
about the SIP WebSocket Server's network, this document updates
[RFC3261] section 18.2.1 by stating:
When a SIP WebSocket Server receives a request it MAY decide not
to add a "received" parameter to the top Via header. Therefore
SIP WebSocket Clients MUST accept responses without such a
parameter in the top Via header regardless the Via "sent-by" field
contains a domain name.
5.2.4. SIP transport implementation requirements
[RFC3261] section 18 "Transport" states the following:
All SIP elements MUST implement UDP and TCP. SIP elements MAY
implement other protocols.
The specification of this new transport enables SIP to be used as a
session establishment protocol in scenarios where none of other
transport protocols defined for SIP can be used. Since some
environments do not enable SIP elements to use UDP and TCP as SIP
transport protocols, a SIP element acting as a SIP WebSocket Client
is not mandated to implement support of UDP and TCP and thus MAY just
implement the WebSocket transport defined by this specification.
5.3. Locating a SIP Server 5.3. Locating a SIP Server
[RFC3263] specifies the procedures which should be followed by SIP [RFC3263] specifies the procedures which should be followed by SIP
entities for locating SIP servers. This specification defines the entities for locating SIP servers. This specification defines the
NAPTR service value "SIP+D2W" for SIP WebSocket Servers that support NAPTR service value "SIP+D2W" for SIP WebSocket Servers that support
plain WebSocket connections and "SIPS+D2W" for SIP WebSocket Servers plain WebSocket connections and "SIPS+D2W" for SIP WebSocket Servers
that support secure WebSocket connections. that support secure WebSocket connections.
At the time this document was written, DNS NAPTR/SRV queries could At the time this document was written, DNS NAPTR/SRV queries could
not be performed by commonly available WebSocket client stacks (in not be performed by commonly available WebSocket client stacks (in
skipping to change at page 9, line 26 skipping to change at page 10, line 26
Alice loads a web page using her web browser and retrieves JavaScript Alice loads a web page using her web browser and retrieves JavaScript
code implementing the WebSocket SIP sub-protocol defined in this code implementing the WebSocket SIP sub-protocol defined in this
document. The JavaScript code (a SIP WebSocket Client) establishes a document. The JavaScript code (a SIP WebSocket Client) establishes a
secure WebSocket connection with a SIP proxy/registrar (a SIP secure WebSocket connection with a SIP proxy/registrar (a SIP
WebSocket Server) at proxy.atlanta.com. Upon WebSocket connection, WebSocket Server) at proxy.atlanta.com. Upon WebSocket connection,
Alice constructs and sends a SIP REGISTER request including Outbound Alice constructs and sends a SIP REGISTER request including Outbound
and GRUU support. Since the JavaScript stack in a browser has no way and GRUU support. Since the JavaScript stack in a browser has no way
to determine the local address from which the WebSocket connection to determine the local address from which the WebSocket connection
was made, this implementation uses a random ".invalid" domain name was made, this implementation uses a random ".invalid" domain name
for the Via header sent-by parameter and for the hostpart of the URI for the Via header sent-by parameter and for the hostport of the URI
in the Contact header (see Appendix A.1). in the Contact header (see Appendix A.1).
Message details (authentication and SDP bodies are omitted for Message details (authentication and SDP bodies are omitted for
simplicity): simplicity):
F1 HTTP GET (WS handshake) Alice -> proxy.atlanta.com (TLS) F1 HTTP GET (WS handshake) Alice -> proxy.atlanta.com (TLS)
GET / HTTP/1.1 GET / HTTP/1.1
Host: proxy.atlanta.com Host: proxy.atlanta.com
Upgrade: websocket Upgrade: websocket
skipping to change at page 12, line 42 skipping to change at page 13, line 42
Max-Forwards: 69 Max-Forwards: 69
Supported: path, outbound, gruu Supported: path, outbound, gruu
Contact: <sip:alice@atlanta.com Contact: <sip:alice@atlanta.com
;gr=urn:uuid:f81-7dec-14a06cf1;ob> ;gr=urn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp Content-Type: application/sdp
F4 200 OK Bob -> proxy.atlanta.com (transport UDP) F4 200 OK Bob -> proxy.atlanta.com (transport UDP)
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.atlanta.com;branch=z9hG4bKhjhjqw32c Via: SIP/2.0/UDP proxy.atlanta.com;branch=z9hG4bKhjhjqw32c
;received=192.0.2.10
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sip:proxy.atlanta.com;transport=udp;lr>, Record-Route: <sip:proxy.atlanta.com;transport=udp;lr>,
<sip:h7kjh12s@proxy.atlanta.com:443;transport=ws;lr> <sip:h7kjh12s@proxy.atlanta.com:443;transport=ws;lr>
From: sip:alice@atlanta.com;tag=asdyka899 From: sip:alice@atlanta.com;tag=asdyka899
To: sip:bob@atlanta.com;tag=bmqkjhsd To: sip:bob@atlanta.com;tag=bmqkjhsd
Call-ID: asidkj3ss Call-ID: asidkj3ss
CSeq: 1 INVITE CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sip:bob@203.0.113.22:5060;transport=udp> Contact: <sip:bob@203.0.113.22:5060;transport=udp>
Content-Type: application/sdp Content-Type: application/sdp
F5 200 OK proxy.atlanta.com -> Alice (transport WSS) F5 200 OK proxy.atlanta.com -> Alice (transport WSS)
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sip:proxy.atlanta.com;transport=udp;lr>, Record-Route: <sip:proxy.atlanta.com;transport=udp;lr>,
<sip:h7kjh12s@proxy.atlanta.com:443;transport=ws;lr> <sip:h7kjh12s@proxy.atlanta.com:443;transport=ws;lr>
From: sip:alice@atlanta.com;tag=asdyka899 From: sip:alice@atlanta.com;tag=asdyka899
To: sip:bob@atlanta.com;tag=bmqkjhsd To: sip:bob@atlanta.com;tag=bmqkjhsd
Call-ID: asidkj3ss Call-ID: asidkj3ss
CSeq: 1 INVITE CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sip:bob@203.0.113.22:5060;transport=udp> Contact: <sip:bob@203.0.113.22:5060;transport=udp>
Content-Type: application/sdp Content-Type: application/sdp
F6 ACK Alice -> proxy.atlanta.com (transport WSS) F6 ACK Alice -> proxy.atlanta.com (transport WSS)
ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
Route: <sip:h7kjh12s@proxy.atlanta.com:443;transport=ws;lr>, Route: <sip:h7kjh12s@proxy.atlanta.com:443;transport=ws;lr>,
<sip:proxy.atlanta.com;transport=udp;lr>, <sip:proxy.atlanta.com;transport=udp;lr>,
From: sip:alice@atlanta.com;tag=asdyka899 From: sip:alice@atlanta.com;tag=asdyka899
skipping to change at page 18, line 50 skipping to change at page 19, line 46
The JavaScript stack in web browsers does not have the ability to The JavaScript stack in web browsers does not have the ability to
discover the local transport address used for originating WebSocket discover the local transport address used for originating WebSocket
connections. Therefore the SIP WebSocket Client constructs a domain connections. Therefore the SIP WebSocket Client constructs a domain
name consisting of a random token followed by the ".invalid" top- name consisting of a random token followed by the ".invalid" top-
level domain name, as stated in [RFC2606], and uses it within its Via level domain name, as stated in [RFC2606], and uses it within its Via
and Contact headers. and Contact headers.
The Contact URI provided by SIP UAs requesting (and receiving) The Contact URI provided by SIP UAs requesting (and receiving)
Outbound support is not used for routing requests to those UAs, Outbound support is not used for routing requests to those UAs,
thus it is safe to set a random domain in the Contact URI thus it is safe to set a random domain in the Contact URI
hostpart. hostport.
Both the Outbound and GRUU specifications require a SIP UA to include Both the Outbound and GRUU specifications require a SIP UA to include
a Uniform Resource Name (URN) in a "+sip.instance" parameter of the a Uniform Resource Name (URN) in a "+sip.instance" parameter of the
Contact header they include their SIP REGISTER requests. The client Contact header they include their SIP REGISTER requests. The client
device is responsible for generating or collecting a suitable value device is responsible for generating or collecting a suitable value
for this purpose. for this purpose.
In web browsers it is difficult to generate or collect a suitable In web browsers it is difficult to generate or collect a suitable
value to be used as a URN value from the browser itself. This value to be used as a URN value from the browser itself. This
scenario suggests that value is generated according to [RFC5626] scenario suggests that value is generated according to [RFC5626]
skipping to change at page 19, line 29 skipping to change at page 20, line 24
The SIP WebSocket Server in this scenario behaves as a SIP Outbound The SIP WebSocket Server in this scenario behaves as a SIP Outbound
Edge Proxy, which involves support for Outbound [RFC5626] and Path Edge Proxy, which involves support for Outbound [RFC5626] and Path
[RFC3327]. [RFC3327].
The proxy performs Loose Routing and remains in the path of dialogs The proxy performs Loose Routing and remains in the path of dialogs
as specified in [RFC3261]. If it did not do this, in-dialog requests as specified in [RFC3261]. If it did not do this, in-dialog requests
would fail since SIP WebSocket Clients make use of their SIP would fail since SIP WebSocket Clients make use of their SIP
WebSocket Server in order to send and receive SIP messages. WebSocket Server in order to send and receive SIP messages.
Appendix B. HTTP Topology Hiding
_This section is non-normative._
[RFC3261] section 18.2.1 "Receiving Requests" states the following:
When the server transport receives a request over any transport,
it MUST examine the value of the "sent-by" parameter in the top
Via header field value. If the host portion of the "sent-by"
parameter contains a domain name, or if it contains an IP address
that differs from the packet source address, the server MUST add a
"received" parameter to that Via header field value. This
parameter MUST contain the source address from which the packet
was received.
The requirement of adding the "received" parameter does not fit well
into the WebSocket protocol design. The WebSocket handshake
connection reuses existing HTTP infrastructure in which there could
be an unknown number of HTTP proxies and/or TCP load balancers
between the SIP WebSocket Client and Server, so the source address
the server would write into the Via "received" parameter would be the
address of the HTTP/TCP intermediary in front of it. This could
reveal sensitive information about the internal topology of the
Server's network to the Client.
Given the fact that SIP responses can only be sent over the existing
WebSocket connection, the Via "received" parameter is of little use.
Therefore, in order to allow hiding possible sensitive information
about the SIP WebSocket Server's network, the implementor could
decide not to satisfy the requirement in [RFC3261] section 18.2.1
"Receiving Requests" and not add the "received" parameter to the Via
header.
Keep in mind that this would make the SIP WebSocket Server non-
compliant with [RFC3261].
Authors' Addresses Authors' Addresses
Inaki Baz Castillo Inaki Baz Castillo
Unaffiliated Unaffiliated
Barakaldo, Basque Country Barakaldo, Basque Country
Spain Spain
Email: ibc@aliax.net Email: ibc@aliax.net
Jose Luis Millan Villegas Jose Luis Millan Villegas
 End of changes. 13 change blocks. 
63 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/