Subject: [BEHAVE] Using TLS with a "turn:" URI [was Re: Opsdir Review of draft-ietf-behave-turn-uri-03.txt]

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 02 Nov 2009 12:25:46 -0800

Margaret Wasserman wrote:
> 
> Hi Marc,
> 
> On Oct 25, 2009, at 3:03 PM, Marc Petit-Huguenin wrote:
>>>
[...]
>> You are absolutely right, this is a bug in the spec, the ordered list
>> of TURN
>> transports should have been filtered by the <scheme> used.
>>
>> I propose to replace "...the TURN transports supported by the
>> application..." by
>> "...the filtered TURN transports supported by the application..." in
>> step #1 and
>> #2 and to add the following paragraph before paragraph 6:
>>
>> "After verifying the validity of the URI elements, the algorithm
>> filters the list of TURN transports supported by the application by
>> keeping only the UDP and TCP TURN transports if the <scheme> is
>> defined as "turn" and by keeping only the TLS TURN transport if the
>> <scheme> is defined as "turns".  If the list of TURN transports is
>> empty after this filtering, the resolution MUST stop with an error."

I think that this is not completely correct.

The reason to have TLS in the leg between the TURN client and the TURN server in
the first place was not for security reasons, but because this is the only way
to be sure that a NAT that knows about the XOR trick will not modify the IP
addresses in the TURN messages.  Because TURN is the lowest priority protocol in
ICE, it was designed in a way that it is always possible to find a path for the
media (This is why I think that do not make TLS mandatory in TURN was a mistake,
but that's another topic).

On the other hand, there is no security downside of "upgrading" a TURN
connection from TCP or UDP to TLS, so I think that a "turn:" URI should be able
to use a TLS connection if available.  The new text would become this:

"After verifying the validity of the URI elements, the algorithm
 filters the list of TURN transports supported by the application by
 removing the UDP and TCP TURN transport if the <scheme> is defined as
 "turns".  If the list of TURN transports is empty after this
 filtering, the resolution MUST stop with an error."

I am interested on feedback from the WG on this.  If there is no feedback by
November 9th, the next release will contain this text.

Thanks.

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 02 Nov 2009 12:49:45 -0800

Margaret Wasserman wrote:
>>> Were these tradeoffs discussed in the WG?
>>
>> No.
> 
> Do you think they should be?
>>
>>> What were the reasons for
>>> choosing the current implicit processing approach?
>>
>> This design is inspired by RFC 3263.  The idea is that domain
>> administrators can
>> choose to implement either A/AAAA or SRV+A/AAAA or NAPTR+SRV+A/AAAA as
>> they see
>> fit for their environment, but still use the same TURN URI.
> 
> I understand that the current mechanism supports this type of fallback,
> but you
> could allow this type of fallback without deciding whether or not to try
> the
> S-NAPTR or DNS SRV lookups based on the presence (or lack) of the <port>
> and <transport> fields in the URI.
> 
> For example, you could ignore the <port> and <transport> fields for the
> S-NAPTR
> lookup, and ignore the <transport> field for the DNS SRV lookup, and
> still fall back
> to using both them the (if present) when you do an A/AAAA lookup.  In
> that case, the
> administrator would have even more flexibility, because he could run his
> servers on
> a non-default port and/or specify a specific transport, without needing
> to change the
> configuration of the end-user devices to allow them to step up to DNS
> SRV and/or
> S-NAPTR.  At this point, the upgrade path you have described only works
> if the
> site is running TURN or TURNS on the default port.
> 
> There are a number of alternatives here, and it seems to me that the one
> chosen
> in the draft is the least flexible.  I am not saying that the choice in
> the draft is the
> wrong choice, because I don't know all of the tradeoffs that were
> considered, but
> this is something I definitely think would warrant some discussion in
> the WG, so
> that folks could reach informed consent on the right approach to use.

So let's start the discussion.  What does the WG think of the current implicit
processing, and if it is not correct, what should it be?

If I receive no response asking for a change before November 9th, the next
version will contain the same implicit processing.

Thanks.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 05 Nov 2009 14:41:12 -0800

Hi Margaret,

[...]

>> I still think that examples must not be added until the text is so
>> clear that
>> the examples are useless.
> 
> If no one else supports my position that example would be valuable, I will
> yield to your opinion on this point, as document editor.

I will add examples (it's easy as all the examples are automatically generated
by my reference implementation, to be sure that they are valid), but my point is
that the text should not rely on examples, as they are not normative.

[...]

>>>> this specification modifies the SRV algorithm by recommending an A
>>>> and AAAA query.  If the TURN client cannot contact a TURN server at
>>>> any of the IP address, port and transport tuples returned by the SRV
>>>> algorithm then the resolution MUST stop with an error."
>>>
>>> This has the same problem as the one you fixed in section 4.  We
>>> don't return an error if the SRV fails, only if both the SRV lookup
>>> and the subsequent A/AAAA lookup fail, right?
>>
>> I disagree here.  The text says "SRV algorithm" not "SRV query".  The
>> fallback
>> to A is part of the SRV algorithm, not something added by this text,
>> so the
>> tuples returned by the SRV algorithm eventually contains the result of
>> the A
>> query (and AAAA as modified by the text).
>>
>> And thinking of it, I am not sure I should have modified step 4, but
>> see below.
> 
> I understand what you are trying to say, but you haven't defined the
> term "SRV
> algorithm" (to include the A/AAAA lookup) anywhere, so it is my opinion
> that
> the meaning of this paragraph is still ambiguous.  This is the type of
> thing
> that I think could be made very clear by an example, but if you don't want
> to include examples, you need to be very clear about the step by step
> process in each of these paragraphs.

Here's the new proposed text:

"3.  If <host> is a domain name and <port> is not defined but
     <transport> is defined, then the SRV algorithm defined in
     [RFC2782] is used to generate a list of IP address and port
     tuples. <host> is used as Name, <scheme> as Service and
     <transport> as Protocol in the SRV algorithm. <scheme> and
     <transport> are converted to a TURN transport as specified in
     Table 1 and this transport is used with each tuple for contacting
     the TURN server.  The SRV algorithm recommends doing an A query
     if the SRV query returns an error or no SRV RR; in this case the
     default port declared in [I-D.ietf-behave-turn] for the SRV
     service name defined in <scheme> MUST be used for contacting the
     TURN server.  Also in this case, this specification modifies the
     SRV algorithm by recommending an A and AAAA query.  If the TURN
     client cannot contact a TURN server at any of the IP address and
     port tuples returned by the SRV algorithm with the transport
     converted from the <scheme> and <transport> then the resolution
     MUST stop with an error."

> I am not sure that it is valid to indicate that section 4 stops with an
> error,
> and then indicate that there are some cases where you would
> continue (presumably) without an error...
> 
> Maybe you should add a line to section 4, in the middle, indicating that
> if the NAPTR query returns an error, you should proceed to step 5?

Here's the new proposed text:

"4.  If <host> is a domain name and <port> and <transport> are not
     defined, then <host> is converted to an ordered list of IP
     address, port and transport tuples via the S-NAPTR algorithm
     defined in [RFC3958] by using <host> as the initial target domain
     name and "RELAY" as the Application Service Tag. The filtered
     list of TURN transports supported by the application are
     converted in Application Protocol Tags by using "turn.udp" if the
     TURN transport is UDP, "turn.tcp" if the TURN transport is TCP
     and "turn.tls" if the TURN transport is TLS.  The order to try
     the Application Protocol Tags is provided by the ranking of the
     first set of NAPTR records.  If multiple Application Protocol
     Tags have the same ranking, the preferred order set by the
     application is used.  If the first NAPTR query fails, the
     processing continues in step 5.  If the TURN client cannot
     contact a TURN server with any of the IP address, port and
     transport tuples returned by the S-NAPTR algorithm then the
     resolution MUST stop with an error.

 5.  If the first NAPTR query in the previous step does not return any
     result then the SRV algorithm defined in [RFC2782] is used to
     generate a list of IP address and port tuples.  The SRV algorithm
     is applied by using each transport in the filtered list of TURN
     transports supported by the application for the Protocol, <host>
     for the Name and <scheme> for the Service.  The same transport
     that was used to generate a list of tuples is used with each of
     this tuples for contacting the TURN server.  The SRV algorithm
     recommends doing an A query if the SRV query returns an error or
     no SRV RR; in this case the default port declared in
     [I-D.ietf-behave-turn] for the SRV service name defined in
     <scheme> MUST be used for contacting the TURN server.  Also in
     this case, this specification modifies the SRV algorithm by
     recommending an A and AAAA query.  If the TURN client cannot
     contact a TURN server at any of the IP address and port tuples
     returned by the SRV algorithm with the transports from the
     filtered list then the resolution MUST stop with an error."

> 
> Also, you mention "the first NAPTR query".  Will there be more than one?

NAPTR queries are recursive. See RFC 3958 section 2.2.3.

> If so, why and what will the subsequent queries contain?

RFC 3958 section 2.2.4 explains what to do if the subsequent NAPTR queries fails
(i.e. backtrack), this is why the turn-uri I-D explains only what should be done
when the first NAPTR query fails.

>>>
>>> It is still not clear to me, from your text, how the S-NAPTR lookup
>>> would be constructed, but that may reflect my limited understanding
>>> of S-NAPTR.
> 
> Could you give me an example of how the NAPTR query would be
> constructed from the URI?

for TURN URI "turn:example.org":

$host -t NAPTR example.org

example.org has NAPTR record 100 10 "" "RELAY:turn.udp" "" datagram.example.org.
example.org has NAPTR record 200 10 "" "RELAY:turn.tcp:turn.tls" ""
stream.example.org.

The Application Service Tag and Application Protocol Tags are used by the RFC
3958 algorithm, not to generate a NAPTR query.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 12 Nov 2009 12:44:49 +0900

Hi Marc,

> processing, and if it is not correct, what should it be?

I've been thinking about this...

My concern is not with the idea of multiple-step processing in  
general, it is with a specific property of the URI scheme described,  
and I want to make sure that the WG has considered this issue.  My  
concern is that the types of  DNS look up that will be performed is  
determined by the presence (or absence) of certain fields in the URI,  
not by an explicit indicator of what types of lookup are desired.   
This artificially limits the flexibility of the URI scheme.

With the URI scheme in the document as written, if I specify a port  
number in the URI, then there will be no NAPTR or SRV lookup.  So,  
there is no way for me to say "Perform all three types of lookup, but  
if you get to the A/AAAA lookup, use port NNNN to connect to the  
server.  So, if I want the algorithm to try S-NAPTR and/or SRV for  
possible later stages in the evolution of my deployment, I am  
precluded from using a non-default port during my first stage (A/AAAA  
records) of deployment.

There is a clear alternative to this, which is to allow the URI to  
specify the port and transport implementation in any use that  
information as a default when it is not provided by the lookup.  A  
different field could be used toindicate which lookup mechanisms (A/ 
AAAA, NAPTR and/or SRV records) should be tried.

Are there benefits to doing this the way it is described in the  
document?

Margaret

---

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

Hi Margaret,

Margaret Wasserman wrote:
> My concern is not with the idea of multiple-step processing in general,
> it is with a specific property of the URI scheme described, and I want
> to make sure that the WG has considered this issue.  My concern is that
> the types of  DNS look up that will be performed is determined by the
> presence (or absence) of certain fields in the URI, not by an explicit
> indicator of what types of lookup are desired.  This artificially limits
> the flexibility of the URI scheme.
> 
> number in the URI, then there will be no NAPTR or SRV lookup.  So, there
> is no way for me to say "Perform all three types of lookup, but if you
> get to the A/AAAA lookup, use port NNNN to connect to the server.  So,
> if I want the algorithm to try S-NAPTR and/or SRV for possible later
> stages in the evolution of my deployment, I am precluded from using a
> non-default port during my first stage (A/AAAA records) of deployment.
> 
> different field could be used toindicate which lookup mechanisms
> (A/AAAA, NAPTR and/or SRV records) should be tried.
> 
> Are there benefits to doing this the way it is described in the document?

I already explained my reasons for this, but let's hear from the WG if there is
a consensus to add this kind of choice.

Thanks.