Subject: [secdir] End of Last Call for draft-ietf-behave-turn-uri

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 09 Nov 2009 10:29:51 -0800

I just released a new version of this I-D incorporating all the modifications
requested during Last Call:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-turn-uri-04

There was only one major modification in this new version, which is the
filtering of the list of preferred TURN transport when the scheme is "turns", to
prevent the use an UDP or TCP transport in this case.  The reference
implementation was updated to reflect this and is available here:

http://ietf.implementers.org/turn-uri-0.2.zip

I made some proposals during the discussion that were never acknowledged, so
here the list of them, this the modification made in the new version of the I-D:

- Ted Hardie found confusing to reuse elements from the hierarchical URI syntax
when the URI is opaque.  No more guidance was provided[1], so I just added a
sentence explaining this.

- In the same thread, Ted Hardie pointed out that the text didn't explained
clearly that the list of preferred transports was not an input for the TURN
parser but for the resolution algorithm.  The I-D was modified as proposed[1].

- Following the secdir review, Pasi Eronen requested some additional text to
deal with TLS.  The I-D was modified as proposed[2].

- Following the security bug discovered by Margaret Wasserman, I started a
discussion[3] on the BEHAVE mailing-list asking if it was OK to be able to use a
TLS transport even if a "turn:" scheme was used.  There was no subsequent
discussion on this, so the I-D now prevents to use a UDP or TCP transport if a
"turns:" scheme is used, but does not prevent using a TLS transport if a "turn:"
scheme is used.

- Following the ops-dir review by Margaret Wasserman, I started a discussion[4]
on the BEHAVE mailing-list for opinions on the implicit processing in the I-D.
There was no subsequent discussion on this, so the implicit processing was not
modified in the I-D.

- The last iteration of the modifications[5] for the algorithms steps were
integrated in the I-D.

Here's the full changelog:

   o  Improved the algorithm steps.
   o  It is possible to use a TLS transport event if the scheme is
      turn:.
   o  Clarified when to stop the resolution with an error in step 2.
   o  Added transport list filtering process.
   o  Improved security section following sec-dir review.
   o  Fixed nits reported by gen-art review.
   o  Added example for remote hosting.
   o  Removed URIs section.
   o  Editorial modification.

Many thanks to all the reviewers.

[1] http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=49076&tid=1257785026
[2] http://www.ietf.org/mail-archive/web/secdir/current/msg01205.html
[3] http://www.ietf.org/mail-archive/web/behave/current/msg07289.html
[4] http://www.ietf.org/mail-archive/web/behave/current/msg07292.html
[5] http://www.ietf.org/mail-archive/web/behave/current/msg07314.html

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Ted Hardie <[email-masked]>
Date: Mon, 9 Nov 2009 19:56:03 -0800

Hi Marc,

Thanks for the changes; I thought you had suggested using new
productions, rather than re-using the existing ones from the
hierarchical
URI mechanism.  Sorry if I did not reply on that--I think that would
be a good idea, but if there is rough consensus for the current approach,
I am happy to go along.

regards,

Ted Hardie

On Mon, Nov 9, 2009 at 10:29 AM, Marc Petit-Huguenin <[email-masked]> wrote:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 12 Nov 2009 09:57:17 -0800

Hi Ted,

> be a good idea, but if there is rough consensus for the current approach,

OK I'll replace the following text:

"  turnURI   = scheme ":" host [ ":" port ] [ "?transport=" transport ]
   scheme    = "turn" / "turns"
   transport = "udp" / "tcp" / transport-ext
   transport-ext = 1*unreserved

 <host>, <port> and <unreserved> are specified in [RFC3986].

 Note that the usage of components defined in the [RFC3986] as part of
 a generic hierarchical URI does not mean that a TURN/TURNS URI is
 hierarchical."

by this text:

"  turnURI   = scheme ":" host [ ":" port ] [ "?transport=" transport ]
   scheme        = "turn" / "turns"
   transport     = "udp" / "tcp" / transport-ext
   transport-ext = 1*unreserved
   host          = IP-literal / IPv4address / reg-name
   port          = *DIGIT
   IP-literal    = "[" ( IPv6address / IPvFuture  ) "]"
   IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
   IPv6address   =                            6( h16 ":" ) ls32
                 /                       "::" 5( h16 ":" ) ls32
                 / [               h16 ] "::" 4( h16 ":" ) ls32
                 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
                 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
                 / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
                 / [ *4( h16 ":" ) h16 ] "::"              ls32
                 / [ *5( h16 ":" ) h16 ] "::"              h16
                 / [ *6( h16 ":" ) h16 ] "::"
   h16           = 1*4HEXDIG
   ls32          = ( h16 ":" h16 ) / IPv4address
   IPv4address   = dec-octet "." dec-octet "." dec-octet "." dec-octet
   dec-octet     = DIGIT                 ; 0-9
                 / %x31-39 DIGIT         ; 10-99
                 / "1" 2DIGIT            ; 100-199
                 / "2" %x30-34 DIGIT     ; 200-249
                 / "25" %x30-35          ; 250-255
   reg-name      = *( unreserved / pct-encoded / sub-delims )

   <unreserved> <sub-delims> and <pct-encoded> are specified in
   [RFC3986]."

I will also add this in the Acknowledgments section:

"The <port> and <host> ABNF productions have been copied from
 [RFC3986]."

If I do not receive any subsequent comment on this, this text will be in the
next revision of the document, to be released Tuesday 17th.

Thanks.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 12 Nov 2009 19:31:40 -0800

> "The <port> and <host> ABNF productions have been copied from

Umm, why don't you just use the RFC3986 ABNF directly, make it
a normative dependency, and not recreate that which is already
a standard?

While you are at it, please redesign the URI to be hierarchical.
The proposed syntax goes out of its way to create arbitrary
differences from STD66.

Transport does not belong as a query parameter.  Transports are
a fundamental part of authority management.  The traditional way
of handling multiple transports is to provide a unique scheme for
each one, since that is how clients will determine which identifier
to use on the basis of whether they support the different transports.
TLS is a transport.

In other words:

 turnURI = "turn" [ "." transport ] "://" authority
 transport = "tls" / "udp" / "sctp"        ; TCP is the default
 authority = <authority, as defined in STD66>

I would also suggest appending path-abempty [ "?" query ]
as well, if there is any chance (no matter how remote) that
you might find a use for path or query information in the future.

Cheers,

Roy T. Fielding
Chief Scientist, Day Software

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 12 Nov 2009 23:11:50 -0800

Hi Roy,

> a normative dependency, and not recreate that which is already

Ted Hardie suggested the exact opposite.

> The proposed syntax goes out of its way to create arbitrary

Your advice contradicts RFC 4395 section 2.2:

"Avoid improper use of "//".  The use of double slashes in the first
 part of a URI is not an artistic indicator that what follows is a
 URI: Double slashes are used ONLY when the syntax of the URI's
 <scheme-specific-part> contains a hierarchical structure as described
 in RFC 3986.  In URIs from such schemes, the use of double slashes
 indicates that what follows is the top hierarchical element for a
 naming authority.  (See Section 3.2 of RFC 3986 for more details.)
 URI schemes that do not contain a conformant hierarchical structure
 in their <scheme-specific-part> SHOULD NOT use double slashes
 following the "<scheme>:" string."

> to use on the basis of whether they support the different transports.

Can you please provide the RFC # and section that says this?  I was not able to
find it.  Thanks.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 16 Nov 2009 09:40:14 -0800

> Ted Hardie suggested the exact opposite.

Howdy,

Sorry for the episodic nature of these comments; jet-lag combined with
day-job issues have really taken their toll on my response time.  My apologies
especially that I wasn't able to discuss this in person in Hiroshima with
any of the relevant folks--I had to leave early.

The thrust of my list comment was intended to find some way of distinguishing
the way this URI scheme uses its components.  Using new ABNF productions
was one fairly low-impact way of signaling these were different, but I believe
that re-using the same names and copying the ABNF doesn't really qualify
as new productions.  At the very least, I think you'd need new names that
highlighted the roles these play; even that is not much of a signal
once these are
in the wild.

As you recall, I'd originally suggested that the URI mailing list be
cc'ed for ideas
on other approaches, and Roy is certainly one of the folks that I'd hoped would
review it there.  If I can help by setting up a conference call or
otherwise getting
some more real-time communication going, please let me know.  I remain hopeful
that we can find some way of approaching the problem that doesn't involve
a complete pushback.  I apologize again for any delay my own response time has
induced.

regards,

Ted Hardie

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 16 Nov 2009 12:38:13 -0800

>>> On Nov 12, 2009, at 9:57 AM, Marc Petit-Huguenin wrote:

[...]

> a complete pushback.  I apologize again for any delay my own response time has

Well, I had other private discussions about this, and I am now seriously
considering dropping the TURN/TURNS URI and just keeping the resolution
mechanism.  The only purpose of the URI is to carry the 3 pieces of information
needed for the resolution algorithm (host/IP address, port and TURN transport),
but this 3 pieces of information can be stored in the client configuration
individually.  That is not as neat as having one, single character string, but
seeing all the difficulties in having the syntax approved, this is probably the
best solution.  I used RFC 4501 as a guideline for this design, but now people
are telling me that a DNS URI was a bad idea...

So unless someone objects to this, the next version (probably released Monday
23rd) will be without the URI stuff.

The only problem is that the name of the I-D (draft-ietf-turn-uri) will no
longer reflect the content.  Dan, any suggestion here?

Thanks.