Subject: [hybi] Detecting client address & port

From: "Bemmel, Jeroen Van (Jeroen Van)" <[email-masked]>
Date: Mon, 19 Sep 2011 00:10:20 +0200

All,

I was wondering if it has been considered to add a mechanism for detecting the client's address and port as part of the WebSocket base protocol.
One use for such a mechanism is highlighted in a draft on doing SIP-over-WebSocket (see http://tools.ietf.org/search/draft-ibc-rtcweb-sip-websocket-00)

A given WebSocket connection is uniquely identified by its 5-tuple, determining this information seems relevant. If the base protocol does not provide such a mechanism, you may end up with a number of sub protocols each implementing something different to achieve the same goal (e.g. the suggestion to use an OPTIONS request with rport in the above draft). Since the port is fixed during the lifetime of the connection, it seems most efficient to add any such mechanism to the initial handshake (e.g. server responding with a header containing this information)

Regards,
Jeroen

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 19 Sep 2011 06:24:07 +0200

Hi,

> A given WebSocket connection is uniquely identified by its 5-tuple, determining this information seems relevant. If the base protocol does not provide such a mechanism, you may end up with a number…

No, please never do that. This is what makes protocols hardly translatable
and relayable through proxies. HTTP passes everywhere precisely because
there is no such information. FTP, RPC, etc... is a lot harder to pass
because the IP:port information need to be snooped and transformed along
the path. Really, doing this nowadays should be considered a design fault.
If the other endpoint really needs the connection's information, it just
has to look at its socket.

And since WS is supposed to be relayed by HTTP proxies, there is no way
to ensure that the client's information brought to the server is still
valid. Additionally, this causes information leaks which are really not
desired in many enterprises !

Regards,
Willy

---

From: Bruce Atherton <[email-masked]>
Date: Mon, 19 Sep 2011 12:33:04 -0700

> desired in many enterprises !

Willy, the need that SIP is intended to address is quite different for 
those other protocols because the endpoints can change within a single 
communication. So Alice connects to a SIP server and asks to connect to 
Bob, and a direct connection between Alice and Bob is established 
without the SIP server being in the path. In order to accomplish that, 
the server needs to know how to let either Alice or Bob connect to the 
other. For this reason, SIP messages carry IP address and routing 
information.

This causes all kinds of problems, you are right. SIP is notorious for 
interacting poorly with NAT and firewalls, which is why there are all 
kinds of solutions like SIP-aware firewalls and SBCs, UPnP, STUN, TURN, 
and ICE. Given the problem it is addressing, though, this seems inevitable.

Having said that, I don't understand how this applies to SIP-over 
Websockets. Browsers cannot establish direct connections between one 
another (at least, not yet) so the only sensible way to establish a 
media channel is to use the Websockets server as a B2BUA, meaning that 
it stays in the path of the channel. Even if you assume the machine 
running the browser also has a softphone installed, you can't establish 
a direct connection between the browser machines without using one of 
the NAT/firewall traversal technologies previously mentioned. My home 
router is SIP-aware using SIP ALG, but it isn't going to recognize SIP 
packets that are in Websocket frames.

So I'm not sure I understand the point of the request. Even if there is 
a reason for requiring the IP and port in order to stay as compatible 
with SIP messages over UDP/TCP as possible, it applies at the SIP layer 
above Websockets and has nothing to do with the Websockets protocol itself.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 19 Sep 2011 22:33:30 +0200

Hi Bruce,

> and ICE. Given the problem it is addressing, though, this seems inevitable.

Thanks for the precisions.

> above Websockets and has nothing to do with the Websockets protocol itself.

100% agreed.

Best regards,
Willy

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Sep 2011 07:38:57 -0700

On Mon, Sep 19, 2011 at 12:33 PM, Bruce Atherton <[email-masked]> wrote:
>>> I was wondering if it has been considered to add a mechanism for
>>> detecting the client's address and port as part of the WebSocket base
>>> protocol.
>>> One use for such a mechanism is highlighted in a draft on doing
>>> SIP-over-WebSocket (see
>>> http://tools.ietf.org/search/draft-ibc-rtcweb-sip-websocket-00)
>>>
>>> A given WebSocket connection is uniquely identified by its 5-tuple,
>>> determining this information seems relevant. If the base protocol does not
>>> provide such a mechanism, you may end up with a number of sub protocols each
>>> implementing something different to achieve the same goal (e.g. the
>>> suggestion to use an OPTIONS request with rport in the above draft). Since
>>> the port is fixed during the lifetime of the connection, it seems most
>>> efficient to add any such mechanism to the initial handshake (e.g. server
>>> responding with a header containing this information)
>>
> Willy, the need that SIP is intended to address is quite different for those
> other protocols because the endpoints can change within a single
> communication. So Alice connects to a SIP server and asks to connect to Bob,
> and a direct connection between Alice and Bob is established without the SIP
> server being in the path. In order to accomplish that, the server needs to
> know how to let either Alice or Bob connect to the other. For this reason,
> SIP messages carry IP address and routing information.
>
> interacting poorly with NAT and firewalls, which is why there are all kinds
> of solutions like SIP-aware firewalls and SBCs, UPnP, STUN, TURN, and ICE.
> Given the problem it is addressing, though, this seems inevitable.
>
> Websockets. Browsers cannot establish direct connections between one another
> (at least, not yet) so the only sensible way to establish a media channel is
> to use the Websockets server as a B2BUA, meaning that it stays in the path
> of the channel.

Without commenting on this particular draft, being able to establish
direct connections
between the browsers (using ICE) is precisely what is intended.

http://tools.ietf.org/wg/rtcweb/

-Ekr

---

From: Bruce Atherton <[email-masked]>
Date: Thu, 22 Sep 2011 08:32:24 -0700

On 22/09/2011 7:38 AM, Eric Rescorla wrote:
> On Mon, Sep 19, 2011 at 12:33 PM, Bruce Atherton<[email-masked]>  wrote:

Ok, but is Websockets going to be used for rtcweb connections? That 
would require browsers to also act as Websocket servers. Is that what is 
intended?

I asked a long time ago whether Websockets was intended to be a 
peer-to-peer protocol and I was told that it was not, that the charter 
for the group specified it to be a client-server protocol. So it does 
not seem like a good match for rtcweb.

And again, even if browsers did intend to implement Websocket servers to 
support rtcweb Websocket connections, transmitting IP address and port 
information over a Websockets connection is the business of the SIP 
subprotocol, and has nothing to do with the Websockets layer itself.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 22 Sep 2011 17:52:10 +0200

> responding with a header containing this information)

Hi, the usage of OPTIONS is just a working approach which works well
with SIP protocol. However, as you said, implementing this in a custom
way is easy. For example, once the webbrowser is connected to the
websocket server, the server sends a WS message containing the IP and
port the connection is made from (such info can be sent in a JSON
struct for example). The client (JS code) parses it and after that
message exchange starts.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 22 Sep 2011 17:55:14 +0200

> to use the Websockets server as a B2BUA, meaning that it stays in the path

Just read the draft please:

  http://tools.ietf.org/search/draft-ibc-rtcweb-sip-websocket-00

As it says:

------------
   This document just covers SIP as a signalling protocol, leaving
   multimedia capabilities integration for a separate document once
   [RTC-Web] (Real Time Collaboration on the World Wide Web) becomes a
   standard.
------------

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Sep 2011 09:19:50 -0700

On Thu, Sep 22, 2011 at 8:32 AM, Bruce Atherton <[email-masked]> wrote:
>>> those
>>> Bob,
>>> kinds
>>> another
> Ok, but is Websockets going to be used for rtcweb connections? That would
> require browsers to also act as Websocket servers. Is that what is intended?

Sorry, I wasn't clear.

The assumption is that you would do the signaling via Websockets to
the signaling gateway... I.e., this is one of hte paradigmatic cases
where Websockets is used to carry protocol messages and notifications.

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 22 Sep 2011 20:18:08 +0200

> the path. Really, doing this nowadays should be considered a design fault.

Hi Willy. Some protocols (as SIP) needs the endpoint to know the
source IP and port the proxy/server has received the connection. This
is because SIP is a stateless protocol and the proxy needs such
information for properly routuing in-coming request within an
established dialog (as an incoming BYE).

I don't consider that a design fault. It's just not all is so "simple"
as HTTP, and there are things out there more powerful than HTTP.

> has to look at its socket.

Please let me know how the web browser can know the source IP and port
used for establishing a connection with a WebSocket server (no such
methods in the WS API). Also that becomes invalid if the browser is
behind NAT.

> valid.

In the case of SIP (and other protocols) the client needs to know the
IP and port the server has received the connection from. It does not
matter wheter it's the IP and port of the client's computer, the IP
and port a NAT router has mapped to, or the IP and port of an
intermediary HTTP proxy.

> Additionally, this causes information leaks which are really not

Could you describe such security leak please?

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

Regards.

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

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 22 Sep 2011 23:42:42 +0200

Hi Iñaki,

> as HTTP, and there are things out there more powerful than HTTP.

It's not a matter of being simple and I understand the need for some
peer-to-peer protocols. But peer-to-peer protocols cannot reliably be
implemented on top of client-server oriented protocols, or often need
an awful lot of hacks to work well.

For instance, contrary to a common belief, TCP is peer-to-peer. You
can connect two clients together without any server provided both
sides know the other ones' port. Still, TCP nowadays is mostly c->s
and its p2p nature has almost vanished when firewalls appeared. And
that's fortunate because it's prone to trivial DoSes.

Other protocols such as HTTP are purely C->S oriented and that
cannot be reverted.

Once a protocol is oriented, it's very hard to bend it to support other
modes. So sometimes people use hacks such as announcing the expected
endpoing in the protocol, but everything between both ends that is not
aware of this hack will break the end-to-end assumption.

> methods in the WS API). Also that becomes invalid if the browser is

It has been clearly stated that a WS server address is announced via
common name resolution techniques (ie: DNS) and that the port is either
explicit or the well known one. We cannot change that because WS uses
the HTTP handshake and that's how HTTP works.

If you need to dynamically guess a server IP:port, you need a reliable
way to advertise it, probably involving a protocol which is NAT-friendly
for such information. And still with this it's not always easy. FTP is
a good example of what happens when you announce addresses in the stream.
Firewalls have to take special care for it, there have been quite a large
number of security issues due to this (eg: opening dynamic rules by faking
a transfer). And there are still a number of components which do not always
get it right. Just check how fragmented packets and segmented streams are
handled by many NAT gateways when they need to rewrite the port, or how
they proceed when the packet is full and they need to extend it because
the translated address is larger than the original one.

> and port a NAT router has mapped to, or the IP and port of an

The issue is that when the server announces the address, it does not
necessarily know what address:port will be right at the border, after
NAT is performed. SIP is well-known for requiring specific handling
when NAT is involved, so basically a SIP-compatible NAT gateway will
get it right, a generic NAT gateway won't. At least you know that by
using SIP to announce your address, you're very likely to succeed.

> Could you describe such security leak please?

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.

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

What does the server see as the connection source here ? The one of
the last visible endpoint. I know some infrastructures where the
following pattern is very common on the last hop :

     [ rproxy ] ------ [ L4 LB ] -------- [ server ]

The rproxy connects to a VIP on the L4 LB using its own address. The
L4 LB translates the destination address to the server's and in this
process, is forced to select a source port from a local table. The
server then receives a connection from the rproxy's IP with a new
source port that was replaced by the LB.

The information it gets in the connection it totally meaningless.

And WS works on top of that.

Now you may wonder why all of this is done with HTTP. Because it's
possible and serves a lot of purposes. So anything based on HTTP cannot
be reliably used to transport an IP:port because all the deployed
infrastructure is not prepared to suddenly have to apply magics on
the new information you want to add into the protocol.

Once again, *some* protocols are designed with this in mind. SIP is
one of them. And you probably don't see SIP infrastructures that look
like HTTP ones with many reverse proxies stacked on top of each other
with L7 and L4 load balancers everywhere along the path. And if these
exist, then they'll only involve components that are designed to do
this and will do it right. And all the chain will be built based on
the assumption that it must convey this specific traffic.

But on top of HTTP or even WS, you're screwed.

Regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 23 Sep 2011 00:39:55 +0200

> an awful lot of hacks to work well.

Well, I don't fully agree. Reliability can be implemented at
application level as well. SIP is reliable even when using UDP as the
protocol requires a response or a request retransmission if the
response does not arrive within an interval.

> aware of this hack will break the end-to-end assumption.

That depends on the application protocol. For example in SIP there are
clients, servers and proxies. Clients connects to proxies at
application level (regardless the layer 4 transport being used).

> the HTTP handshake and that's how HTTP works.

I didn't mean that at all. I said that, in SIP, usually is required
that the client knows the source address:port the proxy/server has
received the request from. So if for example a client is behind NAT
and sends a SIP request to a proxy in public Internet, the response to
the request will contain the public IP:port the server has received
the request from, so the client can know it by inspecting the response
sent from the server.

The very same could be applied to WebSocket HTTP handshake (the server
adds a header in the 101 telling the client the IP:port the server has
received the HTTP GET from).

> using SIP to announce your address, you're very likely to succeed.

As I said above, the server just needs to add in the SIP response the
source IP and port from which it has received the request from the
client. Of course this IP:port is not the private address of the
client computer. That's ok.

> reasons for this.

What I asked for is indeed the opposite: the client realizes of the
source IP:port the server received the request from.

> 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

Wrong (see above), I meant the *client's public IP:port* (or the
IP:port of a TCP intermediary).

> and the number of reverse-proxies.

What is that so hard? IMHO that is just security through obscurity.

> the assumption that it must convey this specific traffic.

In SIP such solutions (involving L4 load balancers) is not common as
they would break the SIP protocol. SIP is much more "pure" in this
aspect as the load balancing is defined at SIP level rather than being
"hidden" to the application level.

> But on top of HTTP or even WS, you're screwed.

I understand your rationale. Definitely it makes no sense to indicate
the source IP:port in the HTTP 101 response given the HTTP jungle
(i.e. reverse proxies behind the real servers).

However in SIP this information is required for the client, so also in
SIP over WebSocket (as well in the case there is a L4 load balancer
between WS client and WS server). See the example in:

  http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00#section-9.1

Thanks a lot for your response. Regards.

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

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 23 Sep 2011 07:38:03 +0200

> response does not arrive within an interval.

I was not discussing reliability of transmission but reliability of the
whole mechanism. Many protocols are reliable over UDP. But in parallel,
UDP is known to be more difficult to relay/nat/proxy. Check how many
systems are able to NAT tftp for instance ;-)

> application level (regardless the layer 4 transport being used).

That's why I'm insisting on knowing the lower layer's behaviours. SIP
supports clients, servers, proxies by design. But you can't blindly
assign these roles to HTTP components that are not aware of this. A
SIP proxy certainly knows it's a SIP proxy. An HTTP proxy certainly
does not know it's been used as a SIP over WS over HTTP proxy. And
it will surely not pass all the low-level information you need such
as connection IP addresses, or you won't be able to reliably use such
information because the way it is determined and propagated does not
follow the SIP rules.

> I said that, in SIP, usually is required

> received the HTTP GET from).

Except that the server's client might be anyone, including an SSL gateway,
a load balancer, a caching reverse-proxy, a compressing reverse-proxy, a
dual-NAT firewall or router, etc... There is no requirement in HTTP that
a component knows the IP of the client, so there is no reliable way to
pass this information to the server, as every component just applies some
component-specific or customer-specific rules. Even the "client" is a vague
notion. In your case, you suppose the "client" is the entity connected to
the internet end-point on the initiator's side, since you don't want the
user-agent's IP address to be passed but its proxy's. In order to have
your principle correctly working, you would have to apply SIP roles to
all of your HTTP component chain, except that you don't necessarily know
all of them.

> source IP:port the server received the request from.

No, it's not the opposite : if the server indicates the IP address of the
reverse-proxy it got the request from, it unveils internal addresses. You
could say that it is not the address you want, but by default it is the
address you will get since it is *its* client.

> IP:port of a TCP intermediary).

This information is undefined. This is why some products add an
"X-Forwarded-For" header (non-standard), other ones add X-Client-IP,
I even know one which alters Via to transport that information, there
are others who just send a log ID so that all components log the same
ID so that log correlation is easier, and most simply don't do anything
at all by default. There are many many many places where the server has
no way to tell what YOUR client's address is, and will pick the wrong
one.

> What is that so hard? IMHO that is just security through obscurity.

No, it's not security through obscurity, you're offering to a client
an information he's not interested in because it's the wrong one.
However the enterprise who owns this information certainly doesn't
want it to be shown. Look again with this example, this time I'm
adding addresses :

   [ client ]
       |   192.168.100.10:1234 -> 200.200.200.200:80
       |
       |   192.168.100.2:3128
   [ proxy ]
       |   192.168.100.2:4567 -> 200.200.200.200:80
       |
       |   192.168.100.1
  (NAT router)
       |   100.100.100.100:5678 (public address) -> 200.200.200.200:80
-------+------------------ client side
       |
  { internet }
       |
-------+------------------ server side
       |   200.200.200.200:80
  (NAT firewall)
       |   100.100.100.100:5678 -> 10.1.1.1:8080
       |
       |   10.1.1.1:8080
   [ L4 LB ]
       |   100.100.100.100:3456 -> 10.2.2.2:8080
       |
       |   10.2.2.2:8080
  [ caching rproxy ]
       |   10.2.2.2:2222 -> 10.3.3.3:8000
       |
       |   10.3.3.3:8000
  [ filtering rproxy ]
       |   10.3.3.3:3333 -> 10.4.4.4:7000
       |
       |   10.4.4.4:7000
  [ L7 load balancer ]
       |   10.4.4.4:4444 -> 10.5.5.5:7000
       |
       |   10.5.5.5:7000
  [ HTTP+WS server ]

This is a typical path a request follows many times a day, though
there are many variants, with more/less NAT, more/less rproxy layers,
etc, and with the WS endpoing being at different places or not.
Anyway, in this example, the server's connection source is the
L7 load balancer's address:port, which has nothing to do with what
you're looking for. In such infrastructures, servers don't need the
client's address because it's only needed when digging into logs,
and a request ID is passed instead. But even those which transport
the client's address in a header (such as X-Forwarded-For) along
the path will get the port wrong : we could assume that the first
level of rproxy takes the information to pass it to the rest of the
chain in a header (that's common too). But this header won't have
the port. And if it does, it passes the port as translated by the
L4 load balancer which itself saw the port translated by the NAT
firewall. So the client's port information is lost at the first
layer since it's useless.

The only piece of information you could use is the client's supposed
public address provided it's set by the first layer in a header and
is not altered by the rest of the chain. And you have to adapt to the
multiple formats in place (for instance I have a customer who uses
an hex-encoding of the IPv4 address to save space, and this info is
used as an ID and "just happens" to be the client's address but it's
not supposed to always be true).

> "hidden" to the application level.

That's precisely what I was saying : pure SIP is more reliable for
doing this because you know that the information is passed unaltered.
BTW, I suspect that the reason why you try to make it pass over WS is
to make it work at more places than pure SIP, but the reason why it's
so hard to deploy it at some places is not the protocol itself, but
the difficulty to adapt the information it transports. Putting another
layer below it will not change this requirement at all : instead of
requiring NAT devices to change the source address in the protocol,
you'll require NAT devices to change the source address in the WS
handshake. The issue remains.

> between WS client and WS server).

I think you have summarized in two sentences why SIP over WS is not
realistic at this point :-/

> See the example in:

I've checked it, but it only assumes the basic cases (eg: one client, one
server, two proxies) where each component knows its role and expects to
be directly connected to the next and previous hops (so that connection
address can be trusted).

Best regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 23 Sep 2011 10:52:12 +0200

> address you will get since it is *its* client.

Hi Willy, I should insist on this:

Let's suppose this scenario:

6) Real WebSocket server
5) Reverse HTTP Proxy
4) L4 (whatever stuff)
3) HTTP Proxy
2) NAT router
1) WebClient (SIP over WS)

When the client connects to the WS server, the source IP:port the
server will get is the IP of the reverse HTTP proxy. And *that* is the
IP:port the server must indicate to the client in response to any SIP
request (over WebSocket protocol of course).

That's *correct*, really. The client does NOT need to know the IP of
1), neither 2), 3) or 4).

> want it to be shown. Look again with this example, this time I'm

Good to know :)

> the difficulty to adapt the information it transports.

Well, it's already working and very well :)

I'll show a video demonstration soon.

> realistic at this point :-/

mmm.... it is working in my prototype, fully, and it interoperates
perfectly with any SIP network out there. As stated in the draft I
wrote, SIP over WebSocket just adds the WebSocket transport to the SIP
protocol, no more, the SIP proxy (and WS server) it's not an
application-protocol-gateway. It's just a pure SIP proxy that
implements SIP over WebSocket (as server side). Video soon.

> be directly connected to the next and previous hops (so that connection

The only constrain is that the WebSocket SIP client must be connected
to a given WS server (which would be its outbound SIP proxy or
server). That is not hard at all. In pure SIP networks (SIP over
UDP/TCP/TLS/SCTP) it's really common to use an outbound SIP proxy so
clients connect to it and send requests to it regardless the real
destination of the request, and the outbound proxy routes the request
based on the request URI.

The very same in SIP over WebSocket.

Regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 23 Sep 2011 11:01:04 +0200

2011/9/23 Bemmel, Jeroen Van (Jeroen Van)
<[email-masked]>:
> Considering my original post, I am now wondering if it would really be necessary for a hypothetical SIP-over-WS Javascript client to know/discover its IP/port address. Since there would be no server socket listening anyway, there would be little point in sharing this information with other systems, and indeed in some contexts organizations might object to this information being shared.
>
> Rather, the WS server / gateway that such a client would connect to, is the only one who can send it messages over WS. It does not matter what remote IP address / port belongs to the connection, or how many intermediate systems are involved. The gateway only needs to keep a mapping between user identities and connections.

If the WS server acts as a SIP proxy and receives a BYE for a dialog
established from a WebSocket client, such BYE must contain in the
Request-URI the Contact URI of the initial INVITE. If such Contact URI
does not contain the source IP:port of the client connection, how
would the SIP proxy know where to route the BYE request? Note that I'm
speaking about a just-transaction-stateful proxy, not dialog-aware.

>
> For SIP, there already exists RFCs:
> * RFC5626 (Outbound) http://tools.ietf.org/html/rfc5626

Probably this would help, but I think it's too much complex adding all
this stuff in SIP over WebSocket, as the only requirement for the
client is to know the source IP:port the WS server has received the
connection from, no more.

> So in conclusion, my view is now that there is no need for WS to support client address & port detection. Moreover, application protocols running on top of WS shouldn't need this either.

Let's imagine this scenario:

   WS-Client     WS-Server + SIP-Proxy      SIP-Registrar

The WS-Client sends a REGISTER, the SIP-Proxy acts Path header and
routes it to the SIP-Registrar. It's obvious that the Contact URI in
such REGISTER arriving to the SIP-Registrar MUST be the source IP:port
the WS-Server receives the client connection from, right? So the
client must realize of it some how (sending an OPTIONS before
registration is a simple way).

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

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 23 Sep 2011 11:33:08 +0200

> 1), neither 2), 3) or 4).

Certainly not. The client has no use at all from this IP which is on the
server side and is private. Not only this address is not reachable to it,
but even knowing it is totally useless because it does not know the
server-side architecture. There are a lot of places where this IP address
will change for every request.

On your example above, I assume the internet is between 3 and 4, so the
only address the client could have been interested in is #3 as seen from
#4 since this *is* the client's address when he connects to the net.

(...)
> protocol, no more,

By adding this, you add a level of obfuscation which prevents the server
from knowing the real client address. That's what I'm trying to explain
from the beginning. Just install a reverse-proxy and a load balancer in
front of your WS server and observe how this works.

> server). That is not hard at all.

I don't follow you there. The point precisely is that you don't control
whom connects to whom because you're relying on a hop-by-hop HTTP
infrastructure where inserting any intermediary anywhere is permitted.

> In pure SIP networks (SIP over

But this is different, as SIP is aware of the client's address along
the whole chain. Everyone takes care of this precious information,
including proxies.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 23 Sep 2011 11:43:11 +0200

On Fri, Sep 23, 2011 at 11:01:04AM +0200, Iñaki Baz Castillo wrote:
> the WS-Server receives the client connection from, right?

It depends where you observe the WS-Client. For instance, at some places
I configure my browser's proxy to route via a local SSH tunnel which ends 
at another place's proxy. My local WS-client is 127.0.0.1.:someport. At
the other end of the tunnel, my WS-client will appear either as the IP
address of the SSH endpoint or as 127.0.0.1 too if I bounce to the proxy
itself. Then after this point, my WS client will appear as the proxy's
LAN address. Then past the NAT firewall, it will appear as my company's
public address, and so on.

> So the

What you apparently need is a unique connection identifier which will
be reported by the server to the client and presented by the client
when necessary. You're trying to use a meaningless IP:port to make it
look like normal SIP, but in normal SIP, this information is meaningful,
while in WS/HTTP environments, it's meaningless.

Just have your WS server/SIP client invent a site-unique ID that it
passes on to the client and that's all. Just don't rely on a useless
information that can be source of conflicts or that can unveil internal
information.

Regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 23 Sep 2011 12:15:53 +0200

2011/9/23 Willy Tarreau <[email-masked]>:

> when necessary.

Yeah! :)

> You're trying to use a meaningless IP:port to make it

I agree, yes.

> information that can be source of conflicts or that can unveil internal

But such new mechanism (the unique ID) would become an addition to the
SIP protocol and I want to avoid that.

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

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 23 Sep 2011 12:21:32 +0200

> SIP protocol and I want to avoid that.

No, you can specify that the client's IP:port field is used to store this
unique ID. What's the problem of telling the client that its ip:port is
0.0.0.1:1234 after all if he does not use it ? With IPv4, you have 48 bits
to store a unique connection ID, you're free to decide how to use them.

Regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 23 Sep 2011 12:23:58 +0200

> to store a unique connection ID, you're free to decide how to use them.

If two WebSocket clients use the same ID such ID is not unique, so
when an incoming request containing that ID arrives via SIP (over UDP)
to the WS Server (a SIP proxy) then the proxy does not know which user
to route it.

If the ID is the source IP:port the WS server receives, that ID is
always *unique* per WS connection so no conflict.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 23 Sep 2011 13:10:45 +0200

2011/9/23 Bemmel, Jeroen Van (Jeroen Van)
<[email-masked]>:
> It would be trivial for a SIP-WS-client to generate a unique connection identifier. If you make sure it conforms to the syntax of the hostname in a SIP Via header, you don't have to change the SIP protocol for that.
>
> Via: SIP/2.0/WS id.jhsad78834.invalid;branch=...

The hostname in Via header is not so important (assuming that the
proxy is transaction stateful). I mean the URI in the Contact.

Regards.

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

---

From: "Bemmel, Jeroen Van (Jeroen Van)" <[email-masked]>
Date: Fri, 23 Sep 2011 08:49:08 +0200

Willy, Iñaki,

Thank you for your inputs.

For SIP, there already exists RFCs:
* RFC5626 (Outbound) http://tools.ietf.org/html/rfc5626
* RFC5627 (GRUU) http://www.packetizer.com/rfc/rfc5627/ 
which provide the necessary functionality.

Regards,
Jeroen
-----Original Message-----
From: Willy Tarreau [mailto:[email-masked]] 
Sent: vrijdag 23 september 2011 7:38
To: Iñaki Baz Castillo
Cc: Bemmel, Jeroen Van (Jeroen Van); [email-masked]
Subject: Re: [hybi] Detecting client address & port

   [ client ]

Best regards,
Willy

---

From: "Bemmel, Jeroen Van (Jeroen Van)" <[email-masked]>
Date: Fri, 23 Sep 2011 13:08:20 +0200

Regards,
Jeroen

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: vrijdag 23 september 2011 12:24
To: Willy Tarreau
Cc: Bemmel, Jeroen Van (Jeroen Van); [email-masked]
Subject: Re: [hybi] Detecting client address & port

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

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 23 Sep 2011 14:42:24 +0200

> to the WS Server (a SIP proxy) then the proxy does not know which user

They should not use the same ID as the server would assign it for them.
For instance, you could use 16 bit as the server number and 32 as the
connection counter.

> always *unique* per WS connection so no conflict.

Precisely not. I know some people who deal with far more than 64k
concurrent connections on a server behind a proxy. And for this,
they bind multiple addresses on the server, and the proxy reuses
the same IP:port tuples to connect to various IP:port tuples on the
server. So you have this :

   Client 1 --> [proxy] 1.1.1.10:12345 ----> 1.1.1.1:80 [server1]
   Client 2 --> [proxy] 1.1.1.10:12345 ----> 1.1.1.2:80 [server1]
   Client 3 --> [proxy] 1.1.1.10:12345 ----> 1.1.1.3:80 [server1]
   Client 4 --> [proxy] 1.1.1.10:12345 ----> 1.1.1.4:80 [server1]

So let me insist on this point : the IP:port tuple that connects to
the server is *not* unique and is private.

Regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 23 Sep 2011 18:08:05 +0200

> the server is *not* unique and is private.

Good point. Thanks for the explanation. Definitely this must be
addressed and the client should NOT know the source IP:port from which
the WS server  has received the HTTP GET.

Thanks.

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

---

From: Bruce Atherton <[email-masked]>
Date: Fri, 23 Sep 2011 10:04:18 -0700

On 22/09/2011 9:19 AM, Eric Rescorla wrote:
> On Thu, Sep 22, 2011 at 8:32 AM, Bruce Atherton<[email-masked]>  wrote:

Got it. So Alice's browser using SIP over Websockets would signal 
through the WS server to the SIP server (could the the same instance) 
that it wants to talk to Bob's browser and would pass candidate IP 
addresses to try. Then some future magic allows the browsers to talk to 
each other.

What I don't understand, though, is why this has anything to do with 
Websockets. ICE requires participation from the Agent, and Websockets 
doesn't speak ICE. It can't speak STUN. It doesn't know how to gather 
candidate addresses together.

No matter how you slice it, I don't see the point in Websockets 
mentioning its local IP address, and there is actually harm in doing so 
since many enterprises do not want any clues given away about their 
internal network structure.

BTW, I agree that this is a paradigmatic case. That is why I am 
implementing the B2BUA solution over Websockets.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Sep 2011 10:39:26 -0700

On Fri, Sep 23, 2011 at 10:04 AM, Bruce Atherton <[email-masked]> wrote:
> Got it. So Alice's browser using SIP over Websockets would signal through
> the WS server to the SIP server (could the the same instance) that it wants
> to talk to Bob's browser and would pass candidate IP addresses to try. Then
> some future magic allows the browsers to talk to each other.
>
> No matter how you slice it, I don't see the point in Websockets mentioning
> its local IP address, and there is actually harm in doing so since many
> enterprises do not want any clues given away about their internal network
> structure.

Right, and I'm not necessarily endorsing this....

Best,
-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 23 Sep 2011 19:41:07 +0200

> Right, and I'm not necessarily endorsing this....

We are already covering this in the draft about SIP over WebSocket.

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