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

[Gilad Shaham <[e-mail]>]

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

> 2011/12/2 Gilad Shaham <[e-mail]>:
> > 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.
>
> 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"?
>
> 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.

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