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

[Paul Kyzivat <[e-mail]>]

Trimming

On 11/1/11 1:21 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. 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.

Sounds good.

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

I'll respond below.

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

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?

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

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.

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

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