Subject: Re: [tram] Alexey Melnikov's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS)

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 6 Oct 2016 21:40:13 -0500

Hi, Alexey,

On Mon, Sep 5, 2016 at 9:05 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> > -----Original Message-----
> > From: Alexey Melnikov [mailto:[email-masked]]
> > Sent: Friday, September 2, 2016 2:02 PM
> > To: Tirumaleswar Reddy (tireddy) <[email-masked]>
> > Cc: The IESG <[email-masked]>; draft-ietf-tram-turn-server-di
> [email-masked];
> > Simon Perreault <[email-masked]>; [email-masked];
> [email-masked]
> > Subject: Re: Alexey Melnikov's Discuss on draft-ietf-tram-turn-server-
> > discovery-09: (with DISCUSS)
> >
> > Hi,
> >
> > On 2 Sep 2016, at 04:02, Tirumaleswar Reddy (tireddy) <[email-masked]
> >
> > wrote:
> >
> > >> -----Original Message-----
> > >> From: Alexey Melnikov [mailto:[email-masked]]
> > >> Sent: Thursday, September 1, 2016 12:49 PM
> > >> To: Tirumaleswar Reddy (tireddy) <[email-masked]>
> > >> Cc: The IESG <[email-masked]>;
> > >> [email-masked];
> > >> Simon Perreault <[email-masked]>; [email-masked];
> > >> [email-masked]
> > >> Subject: Re: Alexey Melnikov's Discuss on
> > >> draft-ietf-tram-turn-server-
> > >> discovery-09: (with DISCUSS)
> > >>
> > >> Hi,
> > >>
> > >> On 1 Sep 2016, at 04:48, Tirumaleswar Reddy (tireddy)
> > >> <[email-masked]>
> > >> wrote:
> > >>
> > >>>> -----Original Message-----
> > >>>> From: Alexey Melnikov [mailto:[email-masked]]
> > >>>> Sent: Wednesday, August 31, 2016 9:11 PM
> > >>>> To: The IESG <[email-masked]>
> > >>>> Cc: [email-masked]; Simon Perreault
> > >>>> <[email-masked]>; [email-masked]; [email-masked];
> > >>>> [email-masked]
> > >>>> Subject: Alexey Melnikov's Discuss on
> > >>>> draft-ietf-tram-turn-server-discovery-
> > >>>> 09: (with DISCUSS)
> > >>>>
> > >>>> Alexey Melnikov 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-discov
> > >>>> er
> > >>>> y/
> > >>>>
> > >>>>
> > >>>>
> > >>>> -------------------------------------------------------------------
> > >>>> --
> > >>>> -
> > >>>> DISCUSS:
> > >>>> -------------------------------------------------------------------
> > >>>> --
> > >>>> -
> > >>>>
> > >>>> In Section 9:
> > >>>>
> > >>>> o  For certificate-based authentication, a pre-populated trust
> anchor
> > >>>>     store [RFC6024] allows a TURN client to perform path validation
> > >>>>     for the server certificate obtained during the (D)TLS handshake.
> > >>>>
> > >>>>     If the client used a domain name to discover the TURN server,
> that
> > >>>>     domain name also provides a mechanism for validation of the TURN
> > >>>>     server.  The client MUST use the rules and guidelines given in
> > >>>>     section 6 of [RFC6125] to validate the TURN server identity.
> > >>>>
> > >>>> I am glad that you are referencing RFC 6125, but unfortunately you
> > >>>> don't provide enough details. Please add details as specified in
> > >>>> Section 3 of RFC
> > >>>> 6125 to your document.
> > >>>
> > >>> Sure, will add the following lines:
> > >>> Certification authorities that issue TURN server certificates SHOULD
> > >>> support
> > >> the DNS-ID and SRV-ID identifier types. TURN service providers SHOULD
> > >> include the DNS-ID and SRV-ID identifier types in certificate
> requests.
> > >>
> > >> What about use of CN-IDs and URI-IDs?
> > >
> > > Yes, added.
> >
> > Just to clarify: you can pick which ones of the 4 types you want to use,
> you can
> > disallow some. You just have to be explicit.
>
> Okay.
>
> > >
> > >> Wildcards ?
> > >
> > > I don't think wildcards are required.
> >
> > Please say so in the document.
>
> Sure, will update.
>
> -Tiru
>

It looks to me as if -10 should address your Discuss. Could you take a look
and confirm that?

Thanks!

Spencer

---

From: Karl Stahl <[email-masked]>
Date: Fri, 7 Oct 2016 15:58:44 +0200

Two things in this draft -10 needs to fixed!

1) As pointed out during the DISCUSS 

https://www.ietf.org/mail-archive/web/tram/current/msg02144.html 

and two times earlier (during WG discussions, but not addressed or responded to by the authors):

 <https://www.ietf.org/mail-archive/web/tram/current/msg02081.html> https://www.ietf.org/mail-archive/web/tram/current/msg02081.html and 

https://www.ietf.org/mail-archive/web/tram/current/msg01976.html 

The Anycast method does not work with RFC5766 TURN servers! That has not

been addressed at all.

A TURN server doesn't react one way (answering 300 Try Alternate) when

addressed by an anycast address and another way (accepting the Allocate

request) when addressed by its unicast address, does it? 

I suggested this modification:

"When a client requires TURN services, it sends a STUN binding request to

the assigned anycast address.  The STUN server

responds with a 300 (Try Alternate) error as described in [RFC5389];  The

response contains a unicast address in the ALTERNATE-SERVER attribute, which

the client compares with the source address of the response and if the

addresses are the same, it is an indication to use the TURN server at that

address. 

For subsequent communication with the TURN server, the client uses that

responding server's unicast address."

This proposed change has important advantages for security and usefulness

for draft-ietf-rtcweb-return-01 also.”

With the current text for the anycast method (and we do need an anycast method since it is the only method proposed that can be easily deployed and on any network), would the consequence not be that it has to be spelled out that *RFC5766 is updated* so that TURN servers to be provided by the network and discovered MUST respond with “300 Try Alternate” for an allocate request when addressed by the anycast address, (but NOT if addressed by its unicast addressed)?

2) The  introduction in this draft -10 of “I think we can mandate (D)TLS *if* STUN authentication or third-party authorization is not used” 

during the DISCUSS, was protested against (but has still been introduced). I said:

[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).

It seem like it is forgotten that a protocol like WebRTC (which really needs this specification to finally deal with the old NAT/Firewall traversal problem that has been plaguing the real-time communication over the Internet for 15 years now), provides security and trust in itself for the media exchanged between endpoints – It does not have to be added by the TURN server. And specifically, for the network provided TURN server, where the purpose of the TURN server is to offer a better working path for the real-time media than through the default gateway (where media otherwise has to pass) – you cannot/must not expect that it also gives you some higher trust or security level that when it goes through the default gateway. 

Also remember that DISCOVERY, in itself is about making  a service available to a client without the client having to be specifically configured for it – and we cannot then specify that it should do some authentication or validation based on password or certificate checking that has to be configured somehow.

Such idea blocks the very purpose of this draft, and has been discussed in various forms several times during the WG draft and can therefore *not be introduced now*. Again, it seems like the main use case for this draft - to be able to use good WebRTC communication wherever you can surf – is forgotten. 

I suggest everything related to “A TURN client MUST use (D)TLS in the absence of STUN long-term

   credential mechanism” under 9. Security Considerations is deleted.

If we really want anything of this in this specification, a compromise could be this change:

   A TURN client  NOT using encryption of the media stream that passes through the TURN server (WebRTC even mandates DTLS-SRPT) may 

 use (D)TLS in the absence of STUN long-term credential mechanism

/Karl

Från: tram [mailto:[email-masked]] För Spencer Dawkins at IETF
Skickat: den 7 oktober 2016 04:40
Till: Tirumaleswar Reddy (tireddy)
Kopia: [email-masked]; [email-masked]; Alexey Melnikov; [email-masked]; Simon Perreault; The IESG
Ämne: Re: [tram] Alexey Melnikov's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS)

Hi, Alexey,

> Cc: The IESG <[email-masked]>; [email-masked];
> Simon Perreault <[email-masked]>; [email-masked]; [email-masked]
> On 2 Sep 2016, at 04:02, Tirumaleswar Reddy (tireddy) <[email-masked]>
> wrote:
>
> >>>> o  For certificate-based authentication, a pre-populated trust anchor
> >>>>     If the client used a domain name to discover the TURN server, that
> >> include the DNS-ID and SRV-ID identifier types in certificate requests.
> >>
> Just to clarify: you can pick which ones of the 4 types you want to use, you can

Okay.

Sure, will update.

-Tiru

It looks to me as if -10 should address your Discuss. Could you take a look and confirm that?

Thanks!

Spencer

---

From: Karl Stahl <[email-masked]>
Date: Mon, 17 Oct 2016 10:15:30 +0200

Spencer,

Can the authors of this discovery draft “be ordered” to address the two points below?

Point 2) was (unnecessarily) introduced during the DISCUSS

(I just highlighted to the WG list that it is NOT addressed, in spite of what is said by an author.)

Point 1) has repeatedly been pointed out on this WG list since version -06 of the draft, but ignored by the authors.  

As the text is in this version -10 of the draft now is, it does NOT fulfill its purpose to discover a network provided TURN server to allow real-time communication, in situations where it otherwise is not possible or bad.

- It does not provide a method suitable for draft-ietf-rtcweb-return-01

- It does not meet the autoconfiguration of RFC 7478 (Web Real-Time Communication Use Cases and Requirements) 2.3.5.1. 

More generally (regarding the mandating of (D)TLS, suddenly introduced during the DISCUSS):

We should be able to use WebRTC everywhere we can and do surf, and for firewall/NAT traversal and quality it is in many cases necessary to parallel the local firewall/access router/default gateway with a TURN server, to get a good media path. The automatic discovery of such network provided turn server should be given by this draft, but it should NOT set up restrictions for it usage (especially when it is unnecessary and blocks the general usage e.g. such as specified in draft-ietf-rtcweb-return-01). 

The authors of this draft seem to have some other use case in mind, but that must not block the usage for which this discovery specification was required. 

As written in this version -10 of the draft, it is a showstopper.

/Karl

Från: tram [mailto:[email-masked]] För Karl Stahl
Skickat: den 7 oktober 2016 15:59
Till: 'Spencer Dawkins at IETF'; 'Tirumaleswar Reddy (tireddy)'
Kopia: [email-masked]; [email-masked]; 'Alexey Melnikov'; [email-masked]; 'Simon Perreault'; 'The IESG'
Ämne: [tram] Need to be fixed! Discuss on draft-ietf-tram-turn-server-discovery-10: (with DISCUSS)
Prioritet: Hög

been addressed at all.

address. 

 

/Karl

Hi, Alexey,

Okay.

Sure, will update.

-Tiru

Thanks!

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 17 Oct 2016 21:16:52 -0500

Hi, Karl,

On Mon, Oct 17, 2016 at 3:15 AM, Karl Stahl <[email-masked]> wrote:

> Point 1) has repeatedly been pointed out on this WG list since version -06
> of the draft, but ignored by the authors.
>

Just so you know, I've added this draft to the IESG informal telechat
agenda for this week, to talk about what we should do next.

Ideally, that resolution will make sense to you. Just in case it doesn't,
you might want to take a look at
https://tools.ietf.org/html/rfc2026#section-6.5 on "Conflict Resolution and
Appeals".

Given that we're still talking about how to handle the draft, my suggestion
is to wait until some version is actually approved, which is an action you
can actually appeal.

We're in the part of the process that's rather formal now. We'll all need
to follow the steps defined in IETF consensus BCPs so that what we do next
isn't the subject of a successful appeal (which gets us right back here,
after wasting time).

Thanks for your understanding and patience.

Spencer

As the text is in this version -10 of the draft now is, it does NOT fulfill
> its purpose to discover a network provided TURN server to allow real-time
> communication, in situations where it otherwise is not possible or bad.
>
> - It does not meet the autoconfiguration of RFC 7478 (Web Real-Time
> Communication Use Cases and Requirements) 2.3.5.1.
>
>
>
> We should be able to use WebRTC everywhere we can and do surf, and for
> firewall/NAT traversal and quality it is in many cases necessary to
> parallel the local firewall/access router/default gateway with a TURN
> server, to get a good media path. The automatic discovery of such network
> provided turn server should be given by this draft, but it should NOT set
> up restrictions for it usage (especially when it is unnecessary and blocks
> the general usage e.g. such as specified in draft-ietf-rtcweb-return-01).
>
>
>
> The authors of this draft seem to have some other use case in mind, but
> that must not block the usage for which this discovery specification was
> required.
>
> *Från:* tram [mailto:[email-masked]] *För *Karl Stahl
> *Skickat:* den 7 oktober 2016 15:59
> *Till:* 'Spencer Dawkins at IETF'; 'Tirumaleswar Reddy (tireddy)'
> *Kopia:* [email-masked]; [email-masked]; 'Alexey Melnikov';
> [email-masked]; 'Simon Perreault'; 'The
> IESG'
> *Ämne:* [tram] Need to be fixed! Discuss on draft-ietf-tram-turn-server-discovery-10:
> (with DISCUSS)
> *Prioritet:* Hög
>
>
>
> https://www.ietf.org/mail-archive/web/tram/current/msg02081.html and
>
> With the current text for the anycast method (and we do need an anycast
> method since it is the only method proposed that can be easily deployed and
> on any network), would the consequence not be that it has to be spelled out
> that *RFC5766 is updated* so that TURN servers to be provided by the
> network and discovered MUST respond with “300 Try Alternate” for an
> allocate request when addressed by the anycast address, (but NOT if
> addressed by its unicast addressed)?
>
>
>
>
>
> 2) The  introduction in this draft -10 of “I think we can mandate (D)TLS
> *if* STUN authentication or third-party authorization is not used”
>
> [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.
>
>
>
> 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.
>
>
>
> “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).
>
>
>
> It seem like it is forgotten that a protocol like WebRTC (which really
> needs this specification to finally deal with the old NAT/Firewall
> traversal problem that has been plaguing the real-time communication over
> the Internet for 15 years now), provides security and trust in itself for
> the media exchanged between endpoints – It does not have to be added by the
> TURN server. And specifically, for the network provided TURN server, where
> the purpose of the TURN server is to offer a better working path for the
> real-time media than through the default gateway (where media otherwise has
> to pass) – you cannot/must not expect that it also gives you some higher
> trust or security level that when it goes through the default gateway.
>
>
>
> Also remember that DISCOVERY, in itself is about making  a service
> available to a client without the client having to be specifically
> configured for it – and we cannot then specify that it should do some
> authentication or validation based on password or certificate checking that
> has to be configured somehow.
>
>
>
> Such idea blocks the very purpose of this draft, and has been discussed in
> various forms several times during the WG draft and can therefore *not be
> introduced now*. Again, it seems like the main use case for this draft - to
> be able to use good WebRTC communication wherever you can surf – is
> forgotten.
>
>
>
>    A TURN client  NOT using encryption of the media stream that passes
> through the TURN server (WebRTC even mandates DTLS-SRPT) may
>
> *Från:* tram [mailto:[email-masked] <[email-masked]>] *För *Spencer
> Dawkins at IETF
> *Skickat:* den 7 oktober 2016 04:40
> *Till:* Tirumaleswar Reddy (tireddy)
> *Kopia:* [email-masked]; [email-masked]; Alexey Melnikov;
> [email-masked]; Simon Perreault; The IESG
> *Ämne:* Re: [tram] Alexey Melnikov's Discuss on
> draft-ietf-tram-turn-server-discovery-09: (with DISCUSS)
>
>
>
> Hi, Alexey,
>
>
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>
>