Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket)

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 01 Nov 2011 08:55:21 -0500

On 10/31/2011 10:57 PM, Iñaki Baz Castillo wrote:
> Ok. IMHO "sips" is just impossible to work since a proxy adding a
> "sips" schema must use a domain in the Record-Route, and such domain
> could resolve to multiple NAPTR/SRV/A/AAAA records, so we loose the
> pach for in-dialog requests and that's critical when Outbound is being
> used.

Well, one could insert the FQDN of the proxy in the R-R set such
that rfc3263 resolution on that FQDN returns only one A/AAAA RR.
However, this means that the FQDN identity must be present in the
subjectAltName extension of the X.509 certificate for this to
work as expected.

Such "pinning" capability has been discussed before; see [1,2].
However, my impression is that most deployments use the generic
URI (sip:example.com) in the certificate and do not bother with
loading other identities (sip:p1.example.com, sip:p2.example.com,
...) in the certificate.

[1] Slide 7 in http://www.ietf.org/proceedings/65/slides/sip-5.pdf
[2] Slide 3 in http://www.ietf.org/proceedings/67/slides/sip-6.pdf

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 1 Nov 2011 15:24:13 +0100

> [2] Slide 3 in http://www.ietf.org/proceedings/67/slides/sip-6.pdf

Hi Vijay. Thanks a lot fot those links, they are very useful.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Nov 2011 10:45:30 -0400

Inline

On 10/31/11 11:57 PM, Iñaki Baz Castillo wrote:
> 2011/10/31 Paul Kyzivat<[email-masked]>:
>>> First of all let me say that I plan to remove "sips" schema from the
>>> draft (given the ammount of issues with "sips" mechanism).
>>
>> Well, if you remove the use of sips, then all issues related to use of sips
>> will go away. :-)
>>
>> But I got the impression that you wanted use of wss to force use of a
>> secured connection e2e. sips is the only thing we have that comes close to
>> providing that.
>
> Ok. So I will leave "sips" schema which in the context of WebSocket
> transport requires WebSocket over TLS ("wss" schema in the WebSocket
> URI connection of the client).

And adjust examples and rules to be compliant with sips usage.

> However, nobody prevents a WS client to establish a WSS connection but
> use "sip" schema on top of it (as RFC 5630 section-3.1.3 states).

Sure.

>>> However, the remote peer (using SIP over UDP so "sip" scheme) never
>>> contacts a SIP node speaking "sips", but "sip". The proxy adds two
>>> Record-Route, the the UDP peer always contacts the URI in the
>>> Record-Route with "sip" schema and UDP protocol.
>>
>> The intent of sips is that every hop, e2e, is sips over tls.
>> Double R-R doesn't eliminate that requirement.
>
> used. However this is another history out of the scope here.

Reports on problems trying to implement sips are welcome.

>> OK. If your intent is to require use of outbound then that answers a lot.
>> Then we will have to ensure that it all integrates with outbound.
>
> Sure :)
>
>
>>> I also have to add a modification to RFC 3261:
>>>
>>> When a proxy/server receives a request via WebSocket transport, it MAY
>>> choose not to add the ";received" param in the top Via. This is
>>> because WebSocket is supposed to use already existing infrastructure
>>> in which there can be certain number of HTTP or TCP load balancers
>>> between the client and HTTP/WebSocket server, so the server would
>>> write into ;received the IP of the load balancer in front of it. This
>>> would reveal the client the internal HTTP/TCP topology of the server
>>> which could be insecure.
>>>
>>> So adding ;received to Via would be a local policy decision.
>>
>> This seems like a real hack. If there is a problem to deal with here I hope
>> it can be abstracted.
>
> Let's assume that:
>
> - A SIP Websocket client is a real client (not a proxy or server).
> - The spec will require Outbound so ;received and ;rport is 100%
> useless (even more when the server cannot try the IP in
> ;received/;rport for sending a response in case the connection is
> closed since a WebSocket client does not listen for incoming
> connections).

I think you are saying that those are useless with outbound in general, 
so the remedy you are suggesting could be abstracted to all uses of 
outbound. Is that right?

> So IMHO it's clear that ;received is useless in SIP over WebSocket,
> and it can reveal server internal infrastructure to the client. So,
> what can we do here? IMHO the SIP WebSocket server/proxy should be
> able not to set the ;received param given the above rationale.

Why is this internal structure more important to hide in the websocket 
case than in other cases? Is this just for the paranoid?

One of the justifications for SBCs is so that they can do "topology 
hiding". Are you just asking for a special case of this?

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 1 Nov 2011 18:21:29 +0100

Sure.

> Reports on problems trying to implement sips are welcome.

Yes, sorry, let's discuss about it in a new future thread.

> I think you are saying that those are useless with outbound in general, so
> the remedy you are suggesting could be abstracted to all uses of outbound.
> Is that right?

Well, in case of SIP over UDP/TCP/TLS usage of ;received param is
indeed useless. But in case of SIP over WebSocket is not just useless
but also dangerous as it reveals to the WS client the IP of a possible
TCP/HTTP load-balancer before the WebSocket SIP server. Such internal
IP is hidden for the WS client during the WebSocket handshake (an HTTP
GET request + 101 response).

> Why is this internal structure more important to hide in the websocket case
> than in other cases? Is this just for the paranoid?

I'm not involved in HTTP scenarios but I got some interesting replies
about this subject in Hyby WG (WebSocket WG):

  http://www.ietf.org/mail-archive/web/hybi/current/msg09091.html

Some text in that thread:
------------------------------
Yes, the problem comes from the fact that a protocol that is used across
a number of intermediaries would suddenly transport sensible information.
Internal IP addresses *are* sensible information to a number of companies.
Whether this makes sense or not is not our problem, these companies don't
want their internal networks to be unveiled to outers and they have their
reasons for this. Now if your usual WS server emits its address in every
response and the reverse-proxy that is placed in front of it does not
change it, all of your clients will get this information they don't need.

> BTW it would be really great a simple "Connection-Source" header in
> the HTTP 101 response during the WS handshake. Examples:
>
>   Connetion-Source: 34.67.123.94:26745
>
>   Connection-Source: [20a:12::3dde:190:ed5]:19443

Same problem, you'll divulgate the IP:port of the reverse-proxy to clients
and the number of reverse-proxies. It can even be used by attackers to
detect that they managed to crash one of them because after a specific
request, they use another one.

An HTTP chain very commonly involves these components :

  [client]----[proxy]-------//// net ////-------[rproxy]------[server]

The proxy commonly is on the client's network in enterprises, or at
the ISP's for home or mobile users. The "net" may involve a number of
transparent intermediaries, but that's not that much common though.
The reverse proxy (rproxy) generally is on the server side. It's in
fact common to see a long chain of many of them. 3-5 are not uncommon
these days, though some of them may be transparent. I have not even
represented NAT devices such as firewalls or some L4 load balancers
which often don't rewrite the source IP but change the source port.
------------------------------

> One of the justifications for SBCs is so that they can do "topology hiding".
> Are you just asking for a special case of this?

Well, IMHO "topolgy hiding" means that the SBC hides leg-A details into leg-B.
What I'm suggesting is that the server (the SIP WebSocket server)
should not reveal to the client sensible information about internal IP
addresses of the provider TCP/HTTP load-balancers located in server
side. IMHO the thread above (the link) justifies that with good
rationale.

However I don't think that omitting the ;received stuff in the SIP
WebSocket server is something critical. As said before, ;received is
useless in SIP over WebSocket: it's a connection oriented protocol so
responses are sent using the same connection, and in case such
connection is closed responses cannot be sent to the WS client since
the WS client does not liste for incoming connections. The same occurs
with SIP TCP natted clients, but in this last case revealing the
;received IP is not a risk.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Tue, 1 Nov 2011 18:53:53 +0000

Dale,

>
>It sounds like WebSocket paths are effectively a variant of the
>connection between the UA and the Edge Proxy in SIP Outbound (RFC
>5626), and what they need is a "flow token" (defined by the edge
>proxy), not a new Via transport value (standardized).
>

Agree with you. In fact, I got the same answer for not choosing SIP as RTCWeb signaling protocol because SIP outbound(RFC 5626) is addressed in part of RFC 3261 and the same NAT issue is addressed in websocket base protocol itself.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Worley, Dale R (Dale)
>Sent: Tuesday, November 01, 2011 1:07 AM
>To: [email-masked]
>Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket)
>
>> From: Iñaki Baz Castillo [[email-masked]]
>>
>> Well, honestly I see no use case for using WebSocket transport between
>> SIP proxies/servers. WebSocket is clearly a transport for web browsers
>> and also for client applications. There is no advantage in using
>> WebSocket between other SIP nodes.
>
>It sounds like WebSocket paths are effectively a variant of the
>connection between the UA and the Edge Proxy in SIP Outbound (RFC
>5626), and what they need is a "flow token" (defined by the edge
>proxy), not a new Via transport value (standardized).
>
>> From: Hadriel Kaplan [[email-masked]]
>>
>> 2) Since websocket can cross even restrictive firewalls, you could use
>> a piece of proxy-ish software on your laptop like SER or Asterix or
>> SipXecs or whatever.  I have no idea why you'd want to run those from
>> behind a restrictive firewall, or why you couldn't configure the
>> firewall to let you do it, instead of using websocket; but if you
>> needed to, you could use websocket.
>
>Isn't there an RFC (around 1 April 1988?) detailing encapsulating IP
>packets in HTTP requests/responses as a way to get through restrictive
>firewalls?
>
>Dale
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Tue, 1 Nov 2011 19:08:13 +0000

Typo - because SIP outbound(RFC 5626) is "not" addressed as

>Behalf Of Ravindran Parthasarathi
>Sent: Wednesday, November 02, 2011 12:24 AM
>To: Worley, Dale R (Dale); [email-masked]
>Agree with you. In fact, I got the same answer for not choosing SIP as
>RTCWeb signaling protocol because SIP outbound(RFC 5626) is not addressed as
>part of RFC 3261 and the same NAT issue is addressed in websocket base
>protocol itself.
>
>Thanks
>Partha
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Nov 2011 11:14:54 -0400

Trimming

> Yes, sorry, let's discuss about it in a new future thread.

Sounds good.

> GET request + 101 response).

I'll respond below.

> Some text in that thread:

This above seems to describe exactly the same issues that I hear 
advanced as reasons for topology hiding in SIP.

Hadriel - can you confirm that?

> side. IMHO the thread above (the link) justifies that with good

I don't think its leg-A vs. leg-B.
Rather its potentially anywhere there is an administrative boundary 
where one side doesn't trust the other side.

> ;received IP is not a risk.

IMO this isn't something that it makes sense to deal with piecemeal.
If a case can be made that this sort of privacy is important enough to 
introduce architectural changes in protocols, then we should be talking 
about that in general.

(But I suspect this will continue to be politically incorrect.)

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 3 Nov 2011 16:30:25 +0100

> introduce architectural changes in protocols, then we should be talking

Hi Paul. I see a bit difference here:

In SIP we all assume that an element in the path of a SIP
communication is a IP layer box (a router) or a SIP box (a SIP
proxy/B2BUA/SBC). Let's forget NAT routers for now.

But in HTTP world is very common to have TCP/HTTP load balancers in
the path (while in SIP we use SIP proxies for balancing). Those
elements alter the received IP:port in the HTTP server but nobody
cares since such information is never told to the HTTP client. This is
not true in SIP since Via ;received / ;rport are supposed to reveal to
the client the source IP:port from which the server has received the
request.

In the case of WebSocket, the WS connection is made using an HTTP GET
replied with an HTTP 101. And then we have a TCP connection in which
both the WS client and WS server can send data by encapsulating it
over WebSocket frames.

Since we are defining here WebSocket as a transport for SIP, IMHO it
should not matter the TCP/HTTP load balancers in the path. Those are
in a layer below the WebSocket communication. The link I pasted in my
previous mail clearly shows how the received IP:port can be totally
useless for a WebSocket server.

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 15 Nov 2011 11:02:33 +0100

FYI: We're planning to submit a new revision of the draft (addressing
the feedback received so far) during the next couple of weeks

-Victor

On Fri, Oct 28, 2011 at 2:42 PM, Iñaki Baz Castillo <[email-masked]> wrote:
> A draft describing a mechanism for usage of WebSocket protocol as a
> new transport between SIP entities was submitted to rtcweb WG on 13
> Sep 2011. However the discussions on that list seemed to conclude that
> the draft was interesting but outside the scope of rtcweb. Since the
> draft describes a new transport for SIP it makes more sense to propose
> it in SIPCORE WG. Therefore we ask the SIPCORE WG to discuss whether
> the proposed draft could fit well in this WG.
>
> There are some aspects of the draft that will be addressed in a new
> revision (as mandating Outbound support given the nature of the
> WebSocket protocol). The first revision of the draft can be found at:
>
> http://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/
>
> --------------------------------
> Abstract
>
>   This document specifies a WebSocket subprotocol for a new transport
>  in SIP (Session Initiation Protocol).  The WebSocket protocol enables
>  two-way realtime communication between clients (typically web-based
>  applications) and servers.  The main goal of this specification is to
>  integrate the SIP protocol within web
>  applications.
> This new SIP transport could fit well within a RTCweb architecture
> (since RTCweb does not mandate the in-the-wire protocol nor the format
> of the messages exchanged between RTCweb clients and servers). This is
> just a use case, a future revision of the draft could incorporate more
> use cases.
>
>
> A presentation of the proposed specification (including a video with
> running code) can be found at:
>
> http://sip-on-the-web.aliax.net/
>
> -------------------------------
> Introduction
>
>  The aim of this presentation is to show the SIP protocol working
>  within a web browser and interoperating with any SIP network.
>
>   After some slides describing the used technology there is a
>  signaling flowchart and a video showing a real implementation.
> -------------------------------
>
>
> Please let us know whether this draft would fit well in SIPCORE or may
> be we would do better by proposing it in DISPATCH.
>
> Thanks a lot.
>
>
> --
> Iñaki Baz Castillo
> <[email-masked]>

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Tue, 15 Nov 2011 18:10:20 +0800

Hi Victor

One comment - the proposal of SIP as a new WebSocket sub protocol is not very clear in ur draft. So you could add an example for it.
E.g.  Sec-WebSocket-Protocol: sip  (is this what you intend to propose?).

Also add a section on how SIP as a WebSocket sub protocol is negotiated as part of client/server handshake procedure.

Thanks

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Pascual Avila
Sent: Tuesday, November 15, 2011 3:33 PM
To: SIPCORE (Session Initiation Protocol Core) WG
Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket)

-Victor

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 15 Nov 2011 11:18:30 +0100

> Also add a section on how SIP as a WebSocket sub protocol is negotiated as part of client/server handshake procedure.

Hi,

AFAIK there is not yet a official registry for WebSocket subprotocols.
We could propose it anyway in the draft. We'll address it.

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Nov 2011 18:25:46 +0800

> We could propose it anyway in the draft. We'll address it.

http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 15 Nov 2011 11:35:10 +0100

> http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name

Good news :)

Thanks, then we will propose "sip" WebSocke Subprotocol.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Tue, 15 Nov 2011 18:38:47 +0800

Also add a section on Websocket client/server handshake so that it indicates that "sip" is negotiated as signaling protocol over WebSockets. 

Regards
Ranjit

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: Tuesday, November 15, 2011 4:05 PM
To: Marc Petit-Huguenin
Cc: Avasarala, Ranjit; SIPCORE (Session Initiation Protocol Core) WG
Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket)

Good news :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 15 Nov 2011 11:46:11 +0100

Sure.

Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 24 Nov 2011 06:43:24 -0700

Be nice if you said a bit more about how this works with DNS SRV and NAPTR resolution ...

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 24 Nov 2011 15:27:38 +0100

> Be nice if you said a bit more about how this works with DNS SRV and NAPTR resolution ...

Hi Cullen, NAPTR and SRV is addressed in the new revision of the draft
which will be submitted soon.

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Sun, 27 Nov 2011 18:40:21 -0500

http://jsondns.org/

</sarcasm>