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: tram [mailto:[e-mail]] On Behalf Of Karl Stahl
> Sent: Tuesday, February 7, 2017 4:02 PM
> To: Tirumaleswar Reddy (tireddy) <[e-mail]>; 'Simon Perreault'
> <[e-mail]>; 'Spencer Dawkins at IETF'
> <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action:
> draft-ietf-tram-turn-server-discovery-12.txt
> 
> Tiru,
> 
> That does not make the version -12 text in the draft any clearer about what
> the draft's anycast method actually is. I am asking you the same question as I
> asked Simon before (and only he answered):

I agree with the responses Simon has already provided to all the below questions. Further, I also don't see the need to discuss the below questions in the draft because they are only operational considerations (and have no impact on the actual protocol).

-Tiru

> 
> Does the draft assume:
> 
> (A) a TURN server listening to TWO IP addresses (that are at different
> subnets) that can respond error 300 or make an allocation, distinguished by
> whether the request was received on its anycast address or its unicast
> address, OR
> 
> (B) we really have TWO TURN servers to play with (the one at the anycast
> address being configured to respond with the error 300, OR
> 
> (C) the FIRST Allocate is responded to with error 300 and SUBSEQUENT
> Allocates actually are making TURN allocations.
> 
> 
> We cannot have an RFC, not even being clear about the method specified.
> 
> /Karl
> 
> 
> -----Ursprungligt meddelande-----
> Från: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> Skickat: den 7 februari 2017 07:18
> Till: Simon Perreault; Karl Stahl; 'Spencer Dawkins at IETF'
> Kopia: [e-mail]
> Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D Action:
> draft-ietf-tram-turn-server-discovery-12.txt
> 
> > -----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-disc
> > > ov 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-disc
> > > ov 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]
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram