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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/13/2013 12:14 AM, Graham Klyne wrote:
From: The IESG <iesg-secretary@xxxxxxxx>
To: IETF-Announce <ietf-announce@xxxxxxxx>
Reply-To: ietf@xxxxxxxx
Sender: <iesg-secretary@xxxxxxxx>
Subject: Last Call: <draft-nandakumar-rtcweb-stun-uri-05.txt> (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol'
  <draft-nandakumar-rtcweb-stun-uri-05.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2013-08-16. Exceptionally, comments may be
sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document is the specification of the syntax and semantics of the
  Uniform Resource Identifier (URI) scheme for the Session Traversal
  Utilities for NAT (STUN) protocol.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-nandakumar-rtcweb-stun-uri/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-nandakumar-rtcweb-stun-uri/ballot/


No IPR declarations have been submitted directly on this I-D.

As IANA designated expert for reviewing URI scheme registrations, I've been asked to approve this scheme for registration. If there is IETF consensus to publish this document, it is clear to me that the scheme should be registered.

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.



...

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.



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]