[tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt

[Karl Stahl <[e-mail]>]

The -12 version of the draft does not include major remedies of flaws that were un-addressed long before the DISCUSS, nor the latest regarding the possible use of (D)TLS for auto discovered turn servers provided the local or access network administrator, see

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

 

For the latest discussed, see

 

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

>> However, I think we need agreement on the justification for such a

> change.

> [Karl] Justification is in the (A), (B), (C) and (D) of

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

> where saying Binding instead Allocate, is necessary to achieve (A) and (B), and improves (C) and (D).

 

Brandon> It is true that you have provided a justification for the change.

 

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

The (D)TLS mandating was Author's idea to throw into version -10 during the discuss and remains in this version -11, breaking the consensus text since version -7.

 

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

STUN dummy authentication instead of (D)TLS as suggested by Oleg Moskalenko

 

 

I have inserted my (now edited and adopted to the latest) redlining, removal of blue options etc. into the -12 draft text as attached, for the author to copy from and paste.

 

Without my red lining, current version -12 is in conflict with RFC7478 (Web Real-Time Communication Use Cases and Requirements)  and does not meet the need of [I-D.ietf-rtcweb-return] (Recursively Encapsulated TURN) (see under redlined 7.2)

and it does not do what was set out in the Charter and “Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs”

 

Further, the authors have in version -12 (compared to from before DISCUSS)  changed the text “  6.  Discovery using Anycast “ to:

 <https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discovery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt> https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discovery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt

“IP anycast can also be used for TURN service discovery.  A packet

   sent to an anycast address is delivered to the "topologically

   nearest" network interface with the anycast address.  Using the TURN

   anycast address, the only two things that need to be deployed in the

   network for discovery are the two things that actually use TURN.

 

   When a client requires TURN services, it sends a TURN allocate

   request to the assigned anycast address.  A TURN anycast server

   performs checks 1 to 7 discussed in Section 6.2 of [RFC5766].  If all

   checks pass, the TURN anycast server MUST respond with a 300 (Try

   Alternate) error as described in Section 2.9 of [RFC5766]; The

   response contains the TURN unicast address in the ALTERNATE-SERVER

   attribute.  For subsequent communication with the TURN server, the

   client uses the responding server's unicast address.  This has to be

   done because two packets addressed to an anycast address may reach

   two different anycast servers.  The client, thus, also needs to

   ensure that the initial request fits in a single packet.  An

   implementation may choose to send out every new TURN Allocation

   request to the anycast address to discover the closest and the most

   optimal unicast address for the TURN server.”

 

The highlighted “A TURN anycast server”  is nothing known nor described (in fact there would have to be TWO TURN servers, one deployed at the anycast address and another TURN server deployed at the unicast address, reacting differently to the Allocation request) for this to work as clarified in WG discussions with Simon). 

 

The last sentence “An  implementation may choose to send out every new TURN Allocation request to the anycast address to discover the closest and the most optimal unicast address for the TURN server.” violates security and deployment considerations (see red lined considerations in attached).

 

Further, the authors have in version -12 (compared to from before DISCUSS)  changed the text “7.2.  Recursively Encapsulated TURN “ to:

 <https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discovery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt> https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discovery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt

“WebRTC endpoints SHOULD treat any TURN server discovered through the

   mechanisms described in this specification as an enterprise/gateway

   or access network server, in accordance with Recursively Encapsulated

   TURN [I-D.ietf-rtcweb-return].”

 

The text is a contradiction, since the return draft deals with TURN servers provided by the local or access network, not other TURN servers discovered by this draft.

 

Current -12 draft cannot be considered to be an RFC!

 

I suggest the redline version of draft -12 attached is chimed into now and quickly merged into a version -13, so we can avoid the "Conflict Resolution and Appeals" process hinted about in

https://www.ietf.org/mail-archive/web/tram/current/msg02202.html, further delaying what is needed for Internet real-time communication and especially for WebRTC.

 

/Karl 

 

Från: tram [ <mailto:[e-mail]> mailto:[e-mail]] För Spencer Dawkins at IETF
Skickat: den 1 februari 2017 22:12
Till: Simon Perreault
Kopia:  <mailto:[e-mail]> [e-mail]; Tirumaleswar Reddy (tireddy)
Ämne: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-12.txt

 

Hi, Simon,

 

On Thu, Feb 2, 2017 at 6:00 AM, Simon Perreault < <mailto:[e-mail]> [e-mail]> wrote:

Le 2017-02-01 à 15:37, Spencer Dawkins at IETF a écrit :
> Dear TRAMsters,
>
> On Fri, Jan 13, 2017 at 12:59 PM, Tirumaleswar Reddy (tireddy)
> < <mailto:[e-mail]> [e-mail] <mailto: <mailto:[e-mail]> [e-mail]>> wrote:
>
>     This revision addresses comments from Brandon.
>
>     -Tiru
>
>
> How close are we to asking Terry to clear the (last remaining) DISCUSS?

Thanks for the reminder.

If my co-chair and the authors have no objection, I think we're ready.

 

I'll give this 24 hours for people to chime in, but I do want to ping Terry. 

 

It's a little-appreciated thing, but AD ballot positions go away when ADs go away; this document has 12 yes/no objections now, and you need 10 for approval, and three are from ADs who are stepping down in March ;-)

 

Spencer