ietf
[Top] [All Lists]

Re: Last Call: <draft-nandakumar-rtcweb-stun-uri-05.txt> (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard

2013-08-15 08:17:26
I agree with Harald.

Both the STUN and TURN URIs really do represent what we traditionally use URIs 
for: they identify a physical resource, a protocol for accessing the resource, 
etc.  Unlike a data URL, the STUN/TURN URI is not locally/directly 
self-contained data - it's a resource identifier, only meaningful when resolved 
and accessed using the scheme's protocol and host address, with whatever 
attributes are encoded in the URI.

Today only W3C has an immediate need for it, for the Javascript API for WebRTC, 
but one can envision this might be used by others as well in the future:

1) SIP might use this in a UA-config profile to tell a SIP client what 
STUN/TURN resources to use, or even in a REGISTER response someday.

2) XMPP might use this someday to indicate to clients what STUN/TURN servers to 
use for Jingle/etc.  Today it's done with a 'services' element I think, but it 
could be changed in the future.

3) BEHAVE WG might define a new DHCP option to tell DHCP clients a STUN/TURN 
server to use, in which case they could use this URI for that. (I don't know if 
BEHAVE's already done that, or decided not to do such a thing, but just sayin' 
it's another potential use-case)

It's possible other protocols might use this as well someday, for example RTSP 
or H.323.  I'm not saying any of them *will*, but it's possible.

-hadriel



On Aug 15, 2013, at 6:04 AM, Harald Alvestrand 
<harald(_at_)alvestrand(_dot_)no> wrote:

On 08/15/2013 11:04 AM, Graham Klyne wrote:
Hi Harald, 

On 14/08/2013 19:49, Harald Alvestrand wrote: 
On 08/13/2013 12:14 AM, Graham Klyne wrote: 
[...] 
But, in a personal capacity, not as designated reviewer, I have to ask 
*why* 
this needs to be a URI.  As far as I can tell, it is intended for use only 
in 
very constrained environments, where there seems to be little value in 
having 
an identifier that can appear in all the contexts where a URI may be 
recognized. 

The criteria for new URI schemes in http://tools.ietf.org/html/rfc4395 
include: 

"New URI schemes SHOULD have clear utility to the broad Internet 
community, 
beyond that available with already registered URI schemes." 
-- http://tools.ietf.org/html/rfc4395#section-2.1 

This "utility to the broader community" is not clear to me, but I don't 
fully 
understand the intended scope of this protocol, so I could be missing 
something.  So, in declaring consensus for this specification, I would 
request 
that this aspect at least be considered. 

I can only give  my personal opinion.... 

1) This is a format for a piece of data. This data cannot be expressed 
using any 
existing URI scheme - indeed, I don't think there exists another 
well-defined 
textual representation of this piece of data. 

1) This is defining an identifier that will be used in W3C-defined APIs. 
W3C 
tends to use URIs every time they want a self-defining piece of data with a 
clearly defined structure. 
In the particular API where this is wanted, one wants to have STUN URIs, 
TURNS 
URIs and TURN URIs passed over the same interface. Thus, keeping with the 
W3C 
tradition of URIs seems reasonable. 

I think this answers the question about "utility to the broader community" 
to my 
satisfaction - your mileage may differ, of course. 

Some thoughts occur to me: 

1. My reading was that this is a generic NAT traversal protocol, so the 
requirement here is not Web/W3C specific.  But you do say "used in 
W3C-defined APIs"... 

Truth in advertising: One W3C-defined API.
The specific reference:

http://dev.w3.org/2011/webrtc/editor/webrtc.html#dictionary-rtciceserver-members


2. If this is being driven by W3C activities, this should probably be 
flagged with W3C TAG.  I'll raise it there. 

3. URIs are not generally used as *data* formats, but rather as identifiers 
for resources.  Web architecture and REST principles tend to discourage 
information encoded in URIs in favour of data representation formats.  Cf. 
http://www.w3.org/TR/webarch/#uri-opacity, 
http://www.w3.org/2001/tag/doc/metaDataInURI-31.html 

Well, it is. The data encoded is the identification of a STUN server, which 
is a resource.


4. If the purpose here is simply to encode data, then there does already 
exist a suitable URI scheme, viz data:.  A new content type can be defined 
to actually encode the required data, and the whole be wrapped in a data: 
URI.  This approach has the advantage that alternative mechanisms (other 
than URIs) can be used to transfer the traversal data if required (though 
that may be moot in the very restricted intended scope of deployment for 
stun:, etc.) 

Yes, but why?



... 

Further, according to http://tools.ietf.org/html/rfc5389 it appears that 
there 
are security considerations with regard to the STUN protocol that it 
should 
not be used in isolation: 
[[ 
   Classic STUN also had a security vulnerability -- attackers could 
   provide the client with incorrect mapped addresses under certain 
   topologies and constraints, and this was fundamentally not solvable 
   through any cryptographic means.  Though this problem remains with 
   this specification, those attacks are now mitigated through the use 
   of more complete solutions that make use of STUN. 

   For these reasons, this specification obsoletes RFC 3489, and instead 
   describes STUN as a tool that is utilized as part of a complete NAT 
   traversal solution. 
]] 
-- http://tools.ietf.org/html/rfc5389#section-2 

It seems to me that creating a URI for STUN could encourage its use in 
environments outside the "more complete solutions that make use of STUN". 
This seems to be further reason that STUN[S] should not be a URI scheme. 

I have also suggested that, if registered, the URI scheme registration 
should 
carries a "health warning" to this effect, and that it is not suitable for 
general use that is not part of a "complete NAT traversal solution".  But 
I 
also recognize that I do not fully grasp the security implications, and 
that 
if those that do know better can agree that there is no potential for 
creating 
security risks here, this suggestion may be unnecessary. 

This URI scheme does not represent STUN. It represents configuration data 
that 
is used to initialize a protocol machine that utilizes STUN. 

This configuration data has to be passed no matter what the format of the 
data 
is - whether it be URI or not. 

Thus, I do not think the argument raised is really relevant to the context. 
The 
data will be passed, and registering an URI scheme will cause no more and 
no 
less data to be passed. 

Again, my opinion. 


If the URI is used only in very constrained contexts, then I agree. 

But the whole point of using a URI is that, due to URI opacity, it can be 
used a a range of contexts where URIs are used.  If it cannot properly be 
used in those other contexts, I have to question if it really is a URI, as 
opposed to a string that happens to look like a URI. 

The subject of "if it really is an URI" has plagued the whole URI space since 
day one. My current opinion is that if it looks like an URI, and parses 
according to the URI spec, it should probably be called an URI.

So far, we know of one context where we need this (RTCWEB). It's the first 
context I know of where the Web and STUN intersect. It's not certain that 
it'll be the last one.


I also note that this looks as if it may fall foul of the "confidential 
metadata" practice noted in the W3C TAG finding about metadata in URIs 
(http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#hideforsecurity) 

That's why we took the "credentials" part out of the URI scheme.


<Prev in Thread] Current Thread [Next in Thread>