Subject: Re: [tram] Ben Campbell's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS and COMMENT)

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 8 Sep 2016 03:22:38 +0000

Hi Ben,
Apologies for the delay. Please see inline..

On 8/31/16, 6:24 PM, "Ben Campbell" <[email-masked]> wrote:

>Ben Campbell has entered the following ballot position for
>draft-ietf-tram-turn-server-discovery-09: Discuss
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>-9, first paragraph says:
>
> "Use of Session Traversal Utilities for NAT (STUN) [RFC5389]
>   authentication is OPTIONAL for TURN servers provided by the local
>   network or by the access network.  A network provided TURN server MAY
>   be configured to accept Allocation requests without STUN
>   authentication, and a TURN client MAY be configured to accept
>   Allocation success responses without STUN authentication from a
>   network provided TURN server. "
>
>This seems to relax the MUST level requirement in RFC 5766 that says TURN
>MUST use STUN long-term credential authentication, or use some other
>equally strong mechanism. From a purely process perpective, this would
>either require an update to 5766, or it would require an argument that
>the local/access network is somehow equally protected. I think the latter
>would only be true if the access network has some sort of protection
>beyond just being the access network (e.g. a vpn, ipsec, or physical
>isolation.)  I don't recall seeing text that suggested any of those.

Tiru and Kathleen have discussed this in another thread. We intend to add
text around the following:

"will add more details that TURN servers deployed in DMZ must only process
STUN requests from a trusted network and not from external networks.
Similarly TURN servers in access networks must only process STUN requests
from its subscribers. Access control can be provided by access-control
lists, firewalls and/or by user authentication to the TURN server. We can
also discuss other recommendations like per-subscriber quota limit,
ingress filtering.²

Would this address your concern?

>
>But in any case, I think relaxing that requirement needs some discussion
>about how the server or client can be sure that all communication is in
>fact constrained to the local network.
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>Substantive:
>
>- general: I agree with the DISCUSS positions from Terry, Alexey, and
>Kathleen.
>
>-3, paragraph 1: Are the MUST and MAY in this paragraph _new_
>requirements, or just statements of fact about previously existing
>requirements? If the latter, they should not use 2119 keywords.

These are new requirements.

> 
>
>-4.1.2, first paragraph: It would be helpful to have a discussion about
>clients that may support multiple users, potentially with different
>domains, or for a single user to use different domains for different
>services.

Sure. Would it suffice if we included the following text:

"A client may support multiple users, potentially with different
   domains, or for a single user to use different domains for different
   services.  The means to choose and extract the desired domain name may
be
   different based on the type of identifier, service being used etc
   which are outside the scope of this document."

>
>-4.2, general: Do I correctly understand that most of this section
>describes the results of applying RFC 5928 procedures to the extracted
>domain name?

Yes, the section does exactly that.

> If so, is it not enough reference 5928 and leave it at that?

Sure. We can certainly remove the example.

>
>-4.2, last paragraph, last sentence: Is this requirement new to this
>draft, or something from 5928? If the latter, please use descriptive
>language.

It is not explicitly stated in 5928 but yes, it should be descriptive.

>
>-9, paragraph 5: "Any discovered TURN server outside the criteria is
>considered untrusted and is not used for privacy sensitive
>communication."
>
>It seems like this needs stronger guidance, maybe even "MUST NOT be
>used..."

Sure. 

>
>- Informational References:
>I-D.ietf-rtcweb-return and RFC 6125 are cited as part of normative
>requirements, which makes them by definition need to be normative
>references. I-D.ietf-tram-turn-mobility, RFC6024, and RFC7250 are
>borderline; I think one could make an argument that one needs to read
>them to fully understand this draft.

We'll update the draft to cite these as non-normative.

>
>Editorial:
>
>-3, last paragraph: "MAY optionally" is redundant.

Fixed.

>
>-5.1, first paragraph, first sentence: I got lost in the nested ³or²s.
>Please consider breaking this up into a few simpler sentences.

Fixed.

>
>- Figure 1: Why merge the query and reply for the A/AAAA query but not
>the other queries?

There was another comment that suggested that we refer to RFC 6762 and RFC
6763. We¹ll end up removing the figure then.

>
>-6, first paragraph, last sentence: I'm not sure what that sentence
>means.

It was meant to indicate that a client could choose to send out every
*new* TURN request on the anycast address to discover the most optimal
unicast address for each request. We could reword the sentence to make the
intent more obvious.

-Prashanth

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 08 Sep 2016 15:48:16 -0500

Hi, thanks for the response. Some more comments inline (I removed 
sections that do not seem to need further discussion.).

Thanks!

Ben.

> On 8/31/16, 6:24 PM, "Ben Campbell" <[email-masked]> wrote:

[...]

> Would this address your concern?

It helps, but if I understand the intend correctly, it doesn't entirely 
address my concern.

This draft seems to relax the "MUST" level requirement to use stun 
authentication (or something equally strong) to an effective "MAY", 
without any real explanation of why, and without really exploring the 
security implications. Do you assume that a TURN server used in this 
context is using "something equally strong"? A number of the security 
considerations in RFC 5766 are mitigated by the assumption of stun 
authentication. How are they impacted by this relaxation? Does the lack 
of authentication lead to a risk of allocation-hijacking? (especially if 
combined with turn mobility?)

So I guess I would like to see some text that explains why this change 
is made, and why it's okay, and warning about related risks.

Finally, I still think this sort of normative change warrants an 
"UPDATES RFC 5766" label.

> These are new requirements.

I find that confusing, because it seems like the paragraph is describing 
the state of affairs that this draft seeks to improve. Also, the "For 
example," in front of a sentence with a 2119 keyword is confusing if the 
purpose is to define a new requirement.

>    which are outside the scope of this document."

Yes, thanks.

> Sure. We can certainly remove the example.

On reflection, I will leave that to your discretion.

[...]

> We'll update the draft to cite these as non-normative.

It may not be that simple. Normative language around a citation is a 
clue that a reference needs to be normative. But lack of it does not 
necessarily prove the opposite. The test is whether someone could fully 
understand and implement this draft without reading the referenced 
document.

[...]

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 14 Sep 2016 03:31:09 +0000

Hi Ben,

>combined with turn mobility?)

We’ll try and add some text for explanation. The reason for adding ‘MAY’
was that in some cases, eg guest networks, the client may not know how to
authenticate with the turn server in the local/access network. Making it a
must would limit discovery and use of turn servers offered by access
networks. 

>is made, and why it's okay, and warning about related risks.

Sure, we’ll add more text around risks or reorganize a little bit; we’ve
discussed risks in paragraphs 2&3 of Security Considerations.
 
>purpose is to define a new requirement.

These are new requirements in that ‘if' a client is chooses to
auto-discover TURN servers, the client MUST consider application config as
local config and proceed with other discovery mechanisms described in the
draft. The draft does not impose application config and hence the MAY
after that. MAY can be removed, perhaps.

How about rewording to the following to avoid confusion:

"TURN clients, by default, discover TURN server(s) by means of local
   or manual TURN configuration (i.e., TURN servers configured at the
   system level).  Configuration discovered from an application, eg a
   Java Script specified TURN server for Web Real-Time Communication
   (WebRTC) [I-D.ietf-rtcweb-overview] usages and related extensions,
   MUST be considered as local configuration.  An implementation may
   give the user an opportunity (e.g., by means of configuration file
options or menu items) to specify a TURN server for each address…"

Sure.

The draft describes mechanisms for general TURN server discovery. One only
needs to read I-D.ietf-rtcweb-return for WebRTC related use cases;
similarly I-D.ietf-tram-turn-mobility is only interesting if you wanted to
address mobility. These should be non-normative.
RFC6024, and RFC7250 are borderline but given that these are do with
security considerations, we could make them normative.

Thanks,
Prashanth

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 14 Sep 2016 11:40:26 -0400

On 13 Sep 2016, at 23:31, Prashanth Patil (praspati) wrote:

>>>> This seems to relax the MUST level requirement in RFC 5766 that 
>>>> says
>>>> TURN
>>> Tiru and Kathleen have discussed this in another thread. We intend 
>>> to
>>> add
>>> lists, firewalls and/or by user authentication to the TURN server. 
>>> We
>>> can

I'm curious why this is special for discovered TURN servers vs TURN 
servers in general. Isn't equally likely that a non-discovered server 
might want to allow credential free operation?

Also, doesn't this create a situation where a client that would prefer 
to authenticate for some reason cannot do so? (That is, the client's 
only option would be to operate without authentication or choose not to 
communicate.)

> discussed risks in paragraphs 2&3 of Security Considerations.

To be clear, I think that discussion is incomplete. RFC 5766 discusses 
several security considerations that explicitly mention authentication 
as a mitigating factor. For example, 17.1.1, 17.1.3, 17.1.7, and 17.2.1.

Those paragraphs (and the bullet list before them) also seem to depend 
on (D)TLS to mitigate some of the issues. But even that is only a 
SHOULD.

Additionally, now that I've looked more closely at the TLS language in 
those paragraphs, I have a concern about the statement that 
communication SHOULD fall back to non-authenticated TLS if 
authentication fails. I think it's reasonable to allow that, but it 
should be a very clear administrator choice. That is, there should never 
be a situation where the administrator (and user) think they have 
authenticated TLS when they do not. This interacts with RFC 5766 section 
17.1.5.

>> "UPDATES RFC 5766" label.

I didn't see a response to this comment. Does that mean you agree? To 
put a finer point on this, I don't think the current draft makes it 
sufficiently obvious that it is removing an existing normative 
requirement to authenticate, and I am concerned that people reviewing 
the draft during IETF last call may not have noticed that.

So to be clear, what I'd like to see is an "Updates RFC 5766" header and 
text that explicitly calls out that the "OPTIONAL" is a downgrade of a 
MUST level authentication requirement in 5766. Once those are in place, 
I think we should consider repeating the IETF last call.

>>>> about how the server or client can be sure that all communication 
>>>> is
>>>> in

What are the practical implications of considering things as "local 
configuration"? (Since it's in the predicate of a MUST...)

[...]

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 15 Sep 2016 18:07:06 +0000

Hi Ben,

>only option would be to operate without authentication or choose not to

It’s special for discovered TURN servers in that discovery is for relay
provided by either the local or the access network. We’re not mandating
that this should be relaxed for all TURN servers, at least that’s not the
intention.
 
But yes, it is a limitation. We do go on to clarify that a client MAY be
configured to accept Allocation success responses without STUN
authentication.

There has been discussion in the WG to make this optional.
 
>on (D)TLS to mitigate some of the issues. But even that is only a

Right, I think we can mandate (D)TLS *if* STUN authentication or
third-party authorization is not used.

>should be a very clear administrator choice.

Fallback to unauthenticated (D)TLS should only happen if the user opts for
opportunistic-encryption. Would you prefer we add a line highlighting this
fact?

>That is, there should never

Sure, we’ll make this update.

-Prashanth

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 20 Sep 2016 17:21:13 -0500

Hi,

Some responses below.

Thanks!

Ben.

On 15 Sep 2016, at 13:07, Prashanth Patil (praspati) wrote:

[...]

>>> was that in some cases, eg guest networks, the client may not know 
>>> how
>>> to
>>> authenticate with the turn server in the local/access network. 
>>> Making
>>> it a

That sort of reasserts the question. Do people think that TURN servers 
that are not "discovered" will not reasonably need the same relaxation? 
(e.g. Maybe I want to widely publish the fact that I run a TURN server 
that anyone can use?)

> third-party authorization is not used.

I think that would help.

> opportunistic-encryption. Would you prefer we add a line highlighting 

Yes. Maybe I read things wrong, but I _thought_ I read the text to say 
you unconditionally SHOULD fallback.

Thanks!

[...]

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 20 Sep 2016 17:30:26 -0500

>> third-party authorization is not used.

Oops, I meant to type a bit more...

Even with that addition, I still think the draft needs to address the 
impact on the issues discussed in the aforementioned sections of 5766. 
If (D)TLS solves the same issues, it would be good to say that. If there 
are things not addressed by TLS (likely true for some of the issues 
mitigated by knowing the client identity), then the draft should mention 
those, too.

Thanks!

Ben.

---

From: Karl Stahl <[email-masked]>
Date: Fri, 23 Sep 2016 13:22:09 +0200

Regarding (from below):
Prashanth> Right, I think we can mandate (D)TLS *if* STUN authentication or
> third-party authorization is not used.

Ben> I think that would help.

[Karl] We cannot mandate a higher security or trust level for a TURN server provided by the network, paralleling the firewall/access router/default gateway, when the client want to place its real-time traffic through the turn server path, than through the default gateway path.

And, shall this *discovery* specification really mandate *usage*?
I am e.g. thinking about the WebRTC browser use case of draft-ietf-rtcweb-return-01. It must be up to that RETURN draft to define the *usage*, not up to a discovery draft.

The use cases I have in mind (and I don't see that TURN D(TLS) can fit) are:
The "autoconfiguration" of RFC 7478 (Web Real-Time Communication Use
Cases and Requirements) 2.3.5.1. or more generally:
“You need be able to use WebRTC everywhere you can surf and for firewall traversal and quality, you need to parallel the local firewall/access router/default gateway with a TURN server”

This must work generally (for all services) on a LAN, Internet Café or GoGo WiFi, where the network provider offers us a better path for real-time traffic (through the TURN server).

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Ben Campbell
Skickat: den 21 september 2016 00:21
Till: Prashanth Patil
Kopia: The IESG; [email-masked]; [email-masked]; [email-masked]; Simon Perreault
Ämne: Re: [tram] Ben Campbell's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS and COMMENT)

Hi,

Some responses below.

Thanks!

Ben.

[...]

I think that would help.

[Karl] See above! 

Thanks!

[...]

_______________________________________________
tram mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tram