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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Simon Perreault [mailto:[e-mail]]
> Sent: Friday, February 3, 2017 7:13 PM
> To: Karl Stahl <[e-mail]>; 'Spencer Dawkins at IETF'
> <[e-mail]>
> Cc: [e-mail]; Tirumaleswar Reddy (tireddy) <[e-mail]>
> Subject: Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action:
> draft-ietf-tram-turn-server-discovery-12.txt
> 
> Karl,
> 
> There is no consensus in the working group behind this new anycast
> mechanism. Therefore it can not be added to the draft, and the mechanism
> defined in RFC 5766 remains.

Yup, https://tools.ietf.org/html/rfc7094#section-3.4 also discusses similar mechanism.
I don't see the need for a new anycast mechanism.

-Tiru

> 
> Thanks,
> Simon
> 
> Le 2017-02-02 à 18:23, Karl Stahl a écrit :
> > 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
> >
> >> 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-discov
> > ery-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"  isnothing 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-discov
> > ery-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]] *För *Spencer Dawkins at
> > IETF
> > *Skickat:* den 1 februari 2017 22:12
> > *Till:* Simon Perreault
> > *Kopia:* [e-mail] <mailto:[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 <[e-mail]
> > <mailto:[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)
> >> <[e-mail]
> >> <mailto:[e-mail]><mailto:[e-mail]
> > <mailto:[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
> >
> >
> >
> > _______________________________________________
> > tram mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tram
> >
> 
> 
> --
> Simon Perreault
> Director of Engineering, Platform | Jive Communications, Inc.
> https://jive.com | [phone] ext. 1241 | [e-mail]