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

[Iñaki Baz Castillo <[e-mail]>]

2011/11/1 Paul Kyzivat <[e-mail]>:
>> 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.

Sure.



>> 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. However this is another history out of the scope here.
>
> Reports on problems trying to implement sips are welcome.

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




>> 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?

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).



>> 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?

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
<[e-mail]>