Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00)

From: Victor Pascual Avila <[email-masked]>
Date: Fri, 2 Dec 2011 16:33:29 +0100

The authors would appreciate any comments and suggestions on this new version.

Many thanks in advance,
-Victor

On Sun, Nov 27, 2011 at 2:07 PM, Iñaki Baz Castillo <[email-masked]> wrote:
> A new version of I-D, draft-ibc-sipcore-sip-websocket-00.txt has been
> successfully submitted by Iñaki Baz Castillo and posted to the IETF
> repository.
>
> Filename:        draft-ibc-sipcore-sip-websocket
> Revision:        00
> Title:           The WebSocket Protocol as a Transport for the Session
> Initiation Protocol (SIP)
> Creation date:   2011-11-24
> WG ID:           Individual Submission
> Number of pages: 27
>
> Abstract:
>  This document specifies a WebSocket Sub-Protocol for a new transport
>  in SIP (Session Initiation Protocol).  The WebSocket protocol enables
>  two-way realtime communication between clients and servers.
>
>
> http://www.ietf.org/id/draft-ibc-sipcore-sip-websocket-00.txt
> http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-00
>
>
> This draft is a new revision of the previously named
> draft-ibc-rtcweb-sip-websocket-00.
>
> Summary of main changes in this revision:
>
> - WebSocket background provided.
> - Scope not limited to web-browsers.
> - Outbound and GRUU usage described.
> - DNS NAPTR/SRV considerations included.
> - Added some clarifications and bug fixing.
>
>
> As usual, your comments are most appreciated.
>
>
> --
> Iñaki Baz Castillo
> <[email-masked]>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

-- 
Victor Pascual Ávila

---

From: "Gilad Shaham" <[email-masked]>
Date: Fri, 2 Dec 2011 18:15:56 +0200

Hi Victor,

I followed the previous draft and read this one. I know that from the last 
draft you would like to refrain from sips issues, but I would expect it to 
be mentioned at the very least in the security section (13.1). If I'm 
reading the examples correctly they mean - use TLS for WebSocket, but from 
there forward use any transport, even unencrypted. I'm not sure everyone 
would realize that and personally, I don't see a problem sending sips to 
indicate it should be secure end-to-end as defined by RFC 5630.

I'm also not so sure why the 'anonymous.invalid' strings are shown in this 
RFC for the Via and Contact headers. This usage is neither defined nor 
referenced anywhere other than the examples. If this specification doesn't 
mandate/recommend it I don't think it should be there, and if it does, it 
should be clearly defined (or reference another RFC that does).

Hope it helps,
Gilad

-----Original Message----- 
From: Victor Pascual Avila
Sent: Friday, December 02, 2011 5:33 PM
To: SIPCORE (Session Initiation Protocol Core) WG
Subject: Re: [sipcore] New Version Notification for 
draft-ibc-sipcore-sip-websocket-00 (previously 
draft-ibc-rtcweb-sip-websocket-00)

The authors would appreciate any comments and suggestions on this new 
version.

Many thanks in advance,
-Victor

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 2 Dec 2011 17:40:13 +0100

> indicate it should be secure end-to-end as defined by RFC 5630.

Hi Gilad. Indeed we have avoided mentioning sips stuff in the draft.
We consider that adding it won't help understanding the sips theory,
nor it will help understanding the SIP WebSocket transport proposed in
the draft. Personally I consider that the sips stuff should be
reworked.

Said that, what do you exactly miss (related to sips) in the draft?
maybe an example flow? or perhaps a consideration that "in presence of
a sips URI the WebSocket transport must be secure which means "wss"
URI in the WebSocket connection"?

> should be clearly defined (or reference another RFC that does).

As explained in the draft, the JavaScript stack in WebSocket capable
web browsers has no way to determine the source IP:port from which a
WebSocket connection has been established, this is, the SIP UA running
within a JavaScript application in a web does not know its local
address. Therefore we've chosen 'anonymous.invalid' for Via
sentby-host value and for Contact in the initial REGISTER (once the
registration is done, the SIP UA would know its GRUU addresses).
Regardless GRUU is implemented in the registrar, the usage of Outbound
(RFC 5626) makes unnecessary for the SIP UA to know its local address.

Of course, in case there is a hostname more appropriate than
'anonymous.invalid' then we could propose it. Is there?

Thanks a lot for your comments.

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

---

From: Gilad Shaham <[email-masked]>
Date: Fri, 2 Dec 2011 20:48:03 +0200

On Fri, Dec 2, 2011 at 6:40 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> If using sips in the examples has a negative effect on clarity I
understand, but it is a bcp and a recommendation, is it not? It should be
clear that implementors would not rely solely on 'wss' for
end-to-end-encryption, but rather use sips URI for that purpose, especially
since the draft does recommend securing the traffic. In other words, I
believe there should be at the very least text explaining that in the
security considerations section.

> 'anonymous.invalid' then we could propose it. Is there?
The string did reminded me of the privacy extensions, since it's used in
the From header, but I was more concerned there is something unspecified.
Outbound still mandates a URI since the authoritative proxy will store that
value to form the target set and therefore it seems as if the UA should be
prepared to receive anonymous.invalid as target URI. Should that be the
case or should the UA generate some kind of URI? It's just an example and
it's possible it's easy to explain how it works, but my point is that this
seems undefined.

I agree that the URI should not be mandatory since it is due to javascript
security limitations and it's certainly possible this transport would be
used outside the browser. If you are looking for alternative hostnames,
'localhost' comes to mind, but I didn't really consider whether it's
better, worse or equivalent.

Thanks,
Gilad

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Sat, 3 Dec 2011 02:57:20 +0800

Hi Gilad

Actually websockets have security option in wss:// option. Could that be used for ensuring security? 

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gilad Shaham
Sent: Friday, December 02, 2011 9:46 PM
To: Victor Pascual Avila; SIPCORE (Session Initiation Protocol Core) WG
Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00)

Hi Victor,

I followed the previous draft and read this one. I know that from the last draft you would like to refrain from sips issues, but I would expect it to be mentioned at the very least in the security section (13.1). If I'm reading the examples correctly they mean - use TLS for WebSocket, but from there forward use any transport, even unencrypted. I'm not sure everyone would realize that and personally, I don't see a problem sending sips to indicate it should be secure end-to-end as defined by RFC 5630.

I'm also not so sure why the 'anonymous.invalid' strings are shown in this RFC for the Via and Contact headers. This usage is neither defined nor referenced anywhere other than the examples. If this specification doesn't mandate/recommend it I don't think it should be there, and if it does, it should be clearly defined (or reference another RFC that does).

Hope it helps,
Gilad

-----Original Message-----
From: Victor Pascual Avila
Sent: Friday, December 02, 2011 5:33 PM
To: SIPCORE (Session Initiation Protocol Core) WG
Subject: Re: [sipcore] New Version Notification for

Many thanks in advance,
-Victor

---

From: Gilad Shaham <[email-masked]>
Date: Fri, 2 Dec 2011 21:11:34 +0200

wss is used to secure a single hop, it does not ensure, at least based on
existing sip routing rules, that it will remain secure for the next hops.
My point is exactly this, it should be clear wss is not enough.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 04 Dec 2011 03:51:58 +0800

Section 7:

Since you are mostly trying to avoid interactions with sips, why is it 
that you use SIPS+D2W to resolve wss URIs? That seems to imply some 
relationship to sips that is not intended.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 5 Dec 2011 09:31:52 +0100

2011/12/2 Gilad Shaham <[email-masked]>:
> If using sips in the examples has a negative effect on clarity I understand,
> but it is a bcp and a recommendation, is it not? It should be clear that
> implementors would not rely solely on 'wss' for end-to-end-encryption, but
> rather use sips URI for that purpose, especially since the draft does
> recommend securing the traffic. In other words, I believe there should be at
> the very least text explaining that in the security considerations section.

Ok, it makes sense. We will add a text under the Security section
about the relationship between SIPS usage and WSS transport
requirement.

> The string did reminded me of the privacy extensions, since it's used in the
> From header, but I was more concerned there is something unspecified.
> prepared to receive anonymous.invalid as target URI. Should that be the case
> or should the UA generate some kind of URI? It's just an example and it's
> possible it's easy to explain how it works, but my point is that this seems
> undefined.
>
> 'localhost' comes to mind, but I didn't really consider whether it's better,
> worse or equivalent.

Yes, using localhost would be another option, but it has a drawback in
case the WebSocket SIP UA does not use GRUU: in that case a remote
peer would see "localhost" as the target of of WS UA. If it sends a
REFER to a third participant containing "Refer-To:
<sip:alice@localhost;transport=ws>" then the third participant would
try to open a WS connection to itself. Well, as the draft states, GRUU
is required for SIP UA's using WebSocket transport, at least in web
browsers.

So I'm not sure wheter using "localhost" is better than using
"anonymous.invalid". Maybe it is better to use "invalid.domain"?

Thanks a lot.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 5 Dec 2011 09:37:36 +0100

2011/12/3 Paul Kyzivat <[email-masked]>:
> Section 7:
>
> Since you are mostly trying to avoid interactions with sips, why is it that
> you use SIPS+D2W to resolve wss URIs? That seems to imply some relationship
> to sips that is not intended.

Well, we didn't try to discourage the interaction with SIPS, we just
tryed to avoid too much text about SIPS since, IMHO, it adds some
complexity which is not very clear currently.

But as said in other mail, we will add a text under the "Security"
section describing the requirement of using secure WebSocket transport
("wss" schema in the WS URI) when SIPS is used.

Regards.

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

---

From: Gilad Shaham <[email-masked]>
Date: Mon, 5 Dec 2011 11:35:54 +0200

On Mon, Dec 5, 2011 at 10:31 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> understand,
> Great, then I'll look for it in the next draft.

> the
> case
> So, if we were to have normative text that defines this, it would probably
explain why localhost or any routable domain name is a bad choice as
opposed to a non-routable domain. Should a UA be free to choose based on a
set of rules or are we defining one host part for all? Should it generate
parts or all of this domain dynamically to assist with matching incoming
requests? Is one free to use an invalid IP (such as the infamous 0.0.0.0)?

And most importantly, do others believe this requires normative text or not?

Thanks,
Gilad

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 5 Dec 2011 10:51:19 +0100

2011/12/5 Gilad Shaham <[email-masked]>:
> explain why localhost or any routable domain name is a bad choice as opposed
> to a non-routable domain. Should a UA be free to choose based on a set of
> rules or are we defining one host part for all? Should it generate parts or
> all of this domain dynamically to assist with matching incoming requests? Is
> one free to use an invalid IP (such as the infamous 0.0.0.0)?

Take into account that when a JavaScript code (running in a web
browser) open a WebSocket connection given a WS URI with domain, the
JavaScript code is not aware of the resulting IP nor the IP family
(IPv4 or IPv6). So IMHO using a IP address in Via/Contact is a bad
idea.

Assuming that a domain is used, I think that which one to set should
not be normative, for the following reasons:

1) If Outbound is being used (and it's a MUST for these kind of SIP
endpoints) the host in Via and Contact does not matter (for
registration or dialogs).

2) If GRUU is used, the host in Contact would be a globally routable
URI. If GRUU is not used, then there is no way  at all for SIP REFER
mechanism to work (since a SIP WebSocket client can only be contacted
via the WS connection it has opened with the WS server). So the domain
in Contact does not matter (with GRUU it will always work, without
GRUU it will never work).

> And most importantly, do others believe this requires normative text or not?

I consider that this should be an informative text, maybe by
suggesting the usage of "invalid.domain" or "any non routable domain".

Regards.

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

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 05 Dec 2011 07:34:16 -0600

On 12/05/2011 03:51 AM, Iñaki Baz Castillo wrote:
> 2011/12/5 Gilad Shaham<[email-masked]>:

"invalid.domain" is not a guaranteed-to-be-unassigned domain; 
"domain.invalid" is. There is an RFC defining such 'invalid' and 
'example' domain names: RFC2606/BCP32.

It would probably be best if your draft included the logic you've 
written above as the rationale for the use of a purposefully-invalid 
domain name, and then included a reference to RFC2606 so that readers 
will know why "domain.invalid" is in fact invalid.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 5 Dec 2011 14:37:30 +0100

2011/12/5 Kevin P. Fleming <[email-masked]>:
> "domain.invalid" is. There is an RFC defining such 'invalid' and 'example'
> domain names: RFC2606/BCP32.
>
> It would probably be best if your draft included the logic you've written
> above as the rationale for the use of a purposefully-invalid domain name,
> and then included a reference to RFC2606 so that readers will know why
> "domain.invalid" is in fact invalid.

Great, it will be added in a new revision.

Thanks a lot.

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

---

From: Gilad Shaham <[email-masked]>
Date: Mon, 5 Dec 2011 16:16:49 +0200

On Mon, Dec 5, 2011 at 11:51 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> opposed
I agree the later messages should not try to resolve an IP address, but I
still don't see why it's that much different to have an invalid IP rather
than an invalid domain. The advantage of an IP is that you are sure no one
would try to resolve it, although it's true you would have no idea whether
to place IPv4 or IPv6 in there and you'd just have to choose one of them.
So it's not that I think one is better than the other, but some may ask for
this option from compatibility point of view - I assume some
implementations were never built with domain name in Contact header or in
Via header in mind, although this is perfectly legitimate to do so. Anyway,
if you strongly object to IP, domain is good too.

> Seems right. So we are saying a UA MAY include an invalid host part in the
registration Contact header and any request top Via header. The UA MUST
support Outbound and SHOULD (or MUST) support GRUU.
Actually, there is good reason to consider mandating GRUU for this
scenario. The reason is that suppose 2 different users named Alice register
to 2 different AORs. Both Alice users go through the same proxy (named P1)
that supports websockets and it forwards the requests to the different
registrars. When an incoming request to one of the Alices comes in, a proxy
will forward the request to alice@<invalid host> through P1, but P1 cannot
distinguish the two and they are in fact different users. I also believe
UAs should be encouraged to compare the instance id of incoming requests.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 5 Dec 2011 15:27:30 +0100

2011/12/5 Gilad Shaham <[email-masked]>:
> to place IPv4 or IPv6 in there and you'd just have to choose one of them. So
> it's not that I think one is better than the other, but some may ask for
> this option from compatibility point of view - I assume some implementations
> were never built with domain name in Contact header or in Via header in
> mind, although this is perfectly legitimate to do so. Anyway, if you
> strongly object to IP, domain is good too.

Hi, I strongly expect that any SIP implementation must accept a
hostname in the Via sentby-host, if not the problem is not here :)

And about a hostname in the Contact URI, GRUU already does it so if we
enforce GRUU we do require that remote peers must allow a Contact URI
with hostname. If not, the problem is not here again :)

IMHO "domain.invalid" is the best choice, as it is an "standard"
unresolvable domain according to RFC 2606 section 2:

      ".invalid" is intended for use in online construction of domain
      names that are sure to be invalid and which it is obvious at a
      glance are invalid.

> Actually, there is good reason to consider mandating GRUU for this scenario.
> The reason is that suppose 2 different users named Alice register to 2
> different AORs. Both Alice users go through the same proxy (named P1) that
> supports websockets and it forwards the requests to the different
> distinguish the two and they are in fact different users. I also believe UAs
> should be encouraged to compare the instance id of incoming requests.

In the scenario you describe Outbound must take place (the registrar
can only send incoming requests to the users via their outbound SIP
EDGE proxy implementing WebSocket transport). So the Path header the
EDGE proxy adds to the REGISTER includes a flow token (RFC 5626),
probably in the URI username part.

When the registrar routes an incoming request to a registration
binding of one of those WS clients, such request will contain a Route
header with same value as the Path header during registration, and the
EDGE proxy will associate the flow token in such Route URI to the
corresponding WebSocket connection. This is, the Outbound EDGE proxy
does not inspect the request URI for incoming requets, but just the
Route URI and the Outbound flow token in it.

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

---

From: Gilad Shaham <[email-masked]>
Date: Mon, 5 Dec 2011 16:38:08 +0200

On Mon, Dec 5, 2011 at 4:27 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> scenario.
> UAs
> Right, I ignored that path is there, so it also seems correct that GRUU is
a SHOULD

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 12 Dec 2011 23:12:00 +0100

Hi, the WebSocket protocol is now approved as the RFC 6455:

  http://tools.ietf.org/html/rfc6455

This is interesting since it makes the WebSocket Transport for SIP no
longer to depend on a non finished draft.

Best regards.

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