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

[Karl Stahl <[e-mail]>]

Simon,

 

There is no consensus yet whatsoever regarding any anycast mechanism, but we
have a chance getting consensus of a working anycast mechanism, that works
for all cases, which no one has disputed as working and that is technically
superior. 

 

Further, it does not exist such "mechanism defined in RFC 5766" and what is
in current version -12 text is still undefined and interpreted radically
different by participating WG individuals.

 

Only Tiru, during the DISCUSS, after version -10 (
<https://www.ietf.org/mail-archive/web/tram/current/msg02219.html>
https://www.ietf.org/mail-archive/web/tram/current/msg02219.html) 

referenced  <https://tools.ietf.org/html/rfc5766#section-2.9>
https://tools.ietf.org/html/rfc5766#section-2.9, which says:

"This version of TURN has been designed to *permit the future specification
of a method* of doing anycast discovery of a TURN server over UDP.

 

Previous to my redlined "say Binding instead of Allocate to
discover"-method, I questioned version -08 of the draft (before the DISCUSS)
(in August,
<https://www.ietf.org/mail-archive/web/tram/current/msg02081.html>
https://www.ietf.org/mail-archive/web/tram/current/msg02081.html) but that
was not responded to by the authors (only Branded responded, but from an
authentication point of view, as if the method meant a mixture of discovery
and usage, which was confusing). 

 

During the DISCUSS, in response to my request to fix, Prashanth only said:
We intend to add the following to explain server behavior a little better:

“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 [RFC5766]”

[Karl] That must be an update of RFC5766. Or does “TURN anycast server”
imply that there ALSO is a “TURN unicast server” at the same interface
accepting the Allocate request?  

 

That was never responded to and in your discussion with me:

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

[Karl]> (I think Brandon assumes a TURN server listening to TWO IP addresses
that

> can respond error 300 or make an allocation, distinguished by whether the

> request was received on its anycast address or its unicast address,

 

[Simon] Correct.

 

[Karl]> and I

> think Prashanth using the term "TURN anycast server" means we really have

> TWO TURN servers to play with,

 

[Simon] That would be an equally valid deployment scenario.

 

[Karl]> and I think others interpret the draft -10

> text as if the FIRST Allocate is responded to with error 300 and
SUBSEQUENT

> Allocates actually are making allocations.

 

[Simon] No, that would be wrong.

 

NOW, reverse engineering the current -12 text to understand what may be in
the author’s mind (which they strangely enough never have spelled out), it
is NOT the “TWO LAN IP TURN servers” but the “No, that would be
wrong.”-method that is intended, see these highlights in the -12 text!

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 [Karl: Nearest cannot be two] 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]
<https://tools.ietf.org/id/draft-ietf-tram-turn-server-discovery-12.html#RFC
5766> . If all checks pass, the TURN anycast server MUST respond with a 300
(Try Alternate) error as described in Section 2.9 of [RFC5766]
<https://tools.ietf.org/id/draft-ietf-tram-turn-server-discovery-12.html#RFC
5766> ; 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.

I think other participants in the discussion, also interpret the -12 text as
the “that would be wrong”-variant, or even worse, a mixture of discovery and
usage authentication (where (D)TLS might come in
(https://www.ietf.org/mail-archive/web/tram/current/msg02297.html )). 

 

So, current version -12 meaning of text is probably not only “wrong”, but
does not work (in addition to being undefined). Version -12 can have no
consensus, nor can that be brought into an RFC.

 

 

In order to NOW ease to get consensus for a defined and working anycast
mechanism (my redlining of the -12 text), that works for all cases (which no
one has disputed), I have just made an IPR declaration “in Alan Johnston /
Avaya style (compare https://datatracker.ietf.org/ipr/2555)” where any party
can use the proposed anycast method (for which patent was provisionally
applied for October 21, 2013) free of royalty as long as not asserting a
patent right of its owns against us. My IPR Declaration related to this I-D
should appear in day (said when submitting).

 

/Karl

 

-----Ursprungligt meddelande-----
Från: Simon Perreault [mailto:[e-mail]] 
Skickat: den 3 februari 2017 14:43
Till: Karl Stahl; 'Spencer Dawkins at IETF'
Kopia: [e-mail]; 'Tirumaleswar Reddy (tireddy)'
Ämne: 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.

 

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>
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>
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>
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>
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-0
9.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”  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-discovery-0
9.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>
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] < <mailto:[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]> 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)

>> < <mailto:[e-mail]%20%3cmailto:[e-mail]>
[e-mail] <mailto:[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

>  <mailto:[e-mail]> [e-mail]

>  <https://www.ietf.org/mailman/listinfo/tram>
https://www.ietf.org/mailman/listinfo/tram

> 

 

 

-- 

Simon Perreault

Director of Engineering, Platform | Jive Communications, Inc.

 <https://jive.com> https://jive.com | [phone] ext. 1241 |
<mailto:[e-mail]> [e-mail]