Re: [tram] Anycast discovery, was: draft-ietf-tram-turn-server-discovery

["Karl Stahl" <[e-mail]>]

Hi Simon,

Sorry for late reply, I wanted to connect that Linksys router again to see
if I had missed something in the GUI (I actually had - I admit), so detail
argumentation may hide the more general points I am trying to
convey/exemplify.

I also want to avoid confusion that may arise from that I wrote "> resolve
the NAT/Firewall traversal problem
that has plagued real-time communication since SIP was introduced in early
2000" (that was a very general overview comment" which is NOT the same NAT
thing you are commenting as "Why would you want to use port forwarding and
have to deal with NAT issues" (here I think you relate to a "NAT issue" of
getting the anycast Allocate packet to the correct IP address of that
special TWO LAN IP TURN server so it can respond with the 300 error, while
using the anycast Binding request instead, there is no  such "NAT issue" to
resolve - Just get the anycast packet to *the TURN server* (no matter how)
and you will get the unicast address of "the TURN server" to USE in the 300
error response.

I am (trying to) exemplify/clarify the high level (important) points why we
need/want anycast discovery by saying Binding instead of Allocate. These
points are:

(A) We need an anycast discovery method for auto-discovering "a TURN server"
(not some special TURN server or arrangement of TURN servers "invented" for
being discoverable by a certain method)

(B) We need an anycast discovery method for a TURN server that is
setup/installed/configured for its USAGE (which is relaying traffic) - not
requiring a special network configuration just for being discoverable. (And
more widely, it must be the goal of this specification to provide at least
one discovery method that works for ALL network types and configurations,
where a network provided TURN server may be useful - I see only anycast
using Binding for querying *the TURN server's* unicast address fulfilling
this.)  

(C) Robust (tolerant) deployment is highly preferable.

(D) Ease of deployment is highly preferable.

Saying Binding instead Allocate, is nessesary to achieve (A) and (B), and
improves (C) and (D). 

Both the requirements RFC https://tools.ietf.org/html/rfc7478 "straddle" (in
"deploy a TURN server that straddles the boundary between the internal and
the external network. *The firewall* will block all attempts to use STUN
with an external destination unless they go to the enterprise auditing TURN
server." and the return draft's
https://tools.ietf.org/html/draft-ietf-rtcweb-return-01 "firewall
configuration" (in "This TURN server may be placed inside the network, with
*a firewall configuration* allowing it to communicate with the public
internet, or it may be operated by a third party outside the network, with a
firewall configuration that allows hosts inside the network to communicate
with it.") assumes (or at least implies/allows/suggest) network
configurations that should works if we say Binding, but not if we say
Allocate. These are not shoot-yourself-in-the-foot deployment scenarios, but
real ones that this draft shall support: Point (A) and (B) fails when saying
Allocate in the anycast method. 

And generally, saying Binding works in All cases where saying Allocate CAN
work (There are no drawbacks). Saying Binding results in more robust
configuration and more ways how to deploy (never less). In addition,
changing to Binding from Allocate, is the fastest/easiest way to clarify the
draft (in addition to clarify what that TWO LAN IP TURN "anycast server"
actually is, we have the lack of distinction between discovery and usage,
and even the confusion around the authentication/DTLS discussion that has
nothing to do with the discovery method (It only applies to usage).   


Regarding the points below in my exemplification, starting with where we
agree:

> Note however that the preferred deployment scenario here would be to
have the TURN server be embedded on the home router 
[Karl] Fully agree 
so as to have one leg on the LAN and another on the WAN 
[Karl] Fully agree
and thus avoid NAT. 
[Karl] ?? Don't follow
No need for manual routing setup in this case, and the current anycast
discovery
method would work perfectly.
[Karl] Fully agree and understand, and the same applies if you say Binding
instead of Allocate. In addition, by saying Binding, you get the advantage
of an easier implementation with ONE TURN server instead of TWO embedded in
the home router (the second only adds the limited function of responding
with the 300 response to an Allocate request).  
But, yes, BOTH works - and hides the complication from saying Allocate and
having to be concerned about anycast routing setup.

[Karl] Further, an embedded TURN server AT the default gateway address may
be an even more preferred deployment scenario, and easier implementation and
will work is saying Binding but not if saying Allocate... 

Further in-line below --> 

/Karl

-----Ursprungligt meddelande-----
Från: Simon Perreault [mailto:[e-mail]] 
Skickat: den 28 november 2016 14:31
Till: Karl Stahl; 'Tirumaleswar Reddy (tireddy)'; 'Brandon Williams';
'Prashanth Patil (praspati)'; [e-mail]
Kopia: [e-mail]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: Re: SV: SV: SV: SV: [tram] Anycast discovery, was:
draft-ietf-tram-turn-server-discovery

Le 2016-11-27 à 15:00, Karl Stahl a écrit :
> I just looked into the GUI of a Cisco 14890/Linksys EA2700 WiFi Router
> having a single subnet for wireless and its 4 LAN ports. In a data crowded
> environment it is in need of a paralleled TURN server for a path to the
high
> quality voip pipe in my triple play network access, especially with WebRTC
> voice+video wanting 2.5 mbps through the access for one session.
> 
> Finding "Single Port Forwarding" in the router GUI, it should be able to
> forward all STUN and TURN packets to a TURN server at the LAN,

I'm not following, sorry. Why would you want to use port forwarding and
have to deal with NAT issues, 
[Karl] ?? With the Binding variant, there is no "NAT issue" to deal with!
Port forwarding was just to get the anycast packet to *the TURN server*. 
while there are much simpler mechanisms available to you?
[Karl] What could possibly be simpler? With this port forwarding I assure
that the anycast packet arrives at *the TURN server* and also seals the
network (in a way that the TURN client can detect)

[Karl] And by this trivial UDP port 3478 forwarding to *the TURN server* I
both fix the routing to the TURN server and seal the network (STUN request
don't go out) (which the TURN client can detect and use sealed behavior). 

(Maybe you only have "pure IP routing" in mind, but routing based on port or
application, or quality needs is very common in triple play broadband access
networks that I am familiar with - Here I have one LAN but 4 WAN pipes
(Surf, Voice, IP-TV, TR069-managent) over my copper ADSL phone line and
routing involves even more "obscure" criteria than port-based, e.g. knowing
whether the application is SIP trunking to a certain SP, to enforce usage of
the Priority Voice pipe for a specific SIP service. And you typically have
classifiers, e.g. selecting a port range to have DSCP bits sets AND to route
to a special network. So I would say this kind of routing is not at all
unusual, especially when it comes to real-time communications.) 


> but I could
> not find the routing table for adding a static anycast route, nor could I
> find a way to create an extra subnet on the LAN side (or at all).

http://www.linksys.com/us/support-article?articleNum=135048
Step 5 shows how to configure static routing table entries.
[Karl] You are correct, I missed that under "Advanced Routing" when I looked
in the GUI...

This is a super common feature on home routers. As another example, I'm
currently using an Asus RT-AC66U and it also has that feature:

http://www.asus.com/us/support/FAQ/1011706/
[Karl] Probably fully correct, but IF/WHEN missing, saying Binding will
work, saying Allocate will not work.  

Note however that the preferred deployment scenario here would be to
have the TURN server be embedded on the home router so as to have one
leg on the LAN and another on the WAN and thus avoid NAT. No need for
manual routing setup in this case, and the current anycast discovery
method would work perfectly.
[Karl] Yes correct, but saying Binding give even further advantages, see
above

> The
> Binding anycast discovery method should work, but not the discussed
> separating between TWO TURN addresses.

See above. In addition, your proposed alternative would require NAT,
which is a non-starter.
[Karl] ?? Now I don't follow. The only requirement is that the anycast
Binding request goes to *the TURN server* (NAT or no NAT, however you do
it).


> And thinking further, will we not just delay this highly needed RFC
further
> by more demonstrations?...

(This discussion is not delaying anything. The DTLS one is.)

I will not respond to the paragraphs below because they ask questions
that are premature. Again with my chair hat on, problems with the
current mechanism need to be demonstrated before a solution can be
proposed. This has not yet happened.

Simon

> The more I look into this, and even if I would agree to all your
> comments/answers below, we cannot accept a discovery draft that is highly
> unclear, on what it is we are able to discover (TWO TURN servers or
combined
> into ONE, listening to TWO IP addresses, not described here or in RFC5766
> (TURN protocol not being changed is no excuse)) and with a method
> description that even qualified members of this WG have discussed in terms
> of using DTLS for the anycast-addressed Allocate or Binding request
packets
> (anycast packets *are over UPD*) and similarly confused by the lack of
> distinction between discovery and usage in the draft.
> 
> I understand and share the opinion that it is urgent to now finally get
this
> draft into place, but accepting the anycast method as it is in this
version,
> may add another decade to finally resolve the NAT/Firewall traversal
problem
> that has plagued real-time communication since SIP was introduced in early
> 2000, when we now are about to complete the ICE/STUN/TURN suit into
> something deployable (as we know, instead of ICE, SBCs are still what is
> used for NAT/Firewall traversal - we make them :-) - but SBCs are not
usable
> with WebRTC. 
> 
> The magic of exchanging the anycast addressed Allocate request to a
Binding
> request for getting the IP address of *the TURN server* is a resolution,
and
> the text for that update is already suggested. This method was proposed
> already in October 2013 after detailed discussion on the RTCWEB list after
> which the TRAM WG was formed
> https://www.ietf.org/mail-archive/web/tram/current/msg00132.html
> You Simon, already then, pointed out the two relevant issues/problems, 
> https://www.ietf.org/mail-archive/web/tram/current/msg00138.html 
> which I also in the suggested "Deployment Considerations for TURN Servers
> Provided by the Local or Access Network" to be added, now have spelled out
> the full solutions to (including the "leakage-problem" that is related to
> your second issue raised at that time).
> 
> So, I think we safely and quickly can fix up this draft for becoming the
> long awaited RFC that gets us an anycast method that at least works for
> detecting "a TURN server" (OK, not "ordinary TURN server" and absolutely
not
> un-described "anycast TURN server"). And without having to bother about
how
> the then anycast addressed Binding arrives at *the TURN server*, we can
> remove the "not all TURN servers may support anycast" under section 3 and
> have no worries over that ">Anycast *is* difficult to implement in many
> real-world scenarios,".
> 
> /Karl
> 
> PS: I don't agree to the "you'd be shooting yourself in the foot" comment,
> which you made on a quote from draft-ietf-rtcweb-return-00, which this
> specification should service with a working and deployable discovery
method
> (which I believe will be done by the changes suggested). Then there will
be
> no need to ">NAT to a different UDP port, so that you are able to
> differentiate unicast and anycast traffic". I said something about
"robust"
> in my suggested deployment considerations to add to this draft -
Robustness
> must also be a goal for successful deployment and for this draft.
> 
> And, since the configuration described in draft-ietf-rtcweb-return-00, is
> for USAGE of the TURN server paralleling the default gateway, those
authors
> could/should not foresee that we come up with a DISCOVERY method that will
> complicate deployment configuration by requiring an extra subnet on the
LAN
> side (that may not be supported by the default gateway router). Using DHCP
> for discovery, one would not have thought of this as a
> shoot-yourself-in-the-foot deployment.
> 
> But DHCP is unfortunately not commonly available on many of the access
> networks we use today (LTE.., IPv6) (and the DHCP discovery is also
> unnecessarily complicated by going via domain name + DNS rather than
> defining a new IANA DHCP option (but I not going to request such change
:-)
> since we cannot use DHCP discovery on all networks a WebRTC browser is
> commonly used from anyway). We simply need the anycast discovery method
for
> WebRTC browsers' general usage.
> 
> The anycast discovery method must be clear, well defined and understood by
> readers of the draft, and with the aim to work in all deployment scenarios
> (for USAGE of such TURN server) and to be as robust and tolerant as
> possible.
> 
> Let's do it! That is also faster and simpler than just making current
method
> clearly defined and understood.
> (We are just making a small change to the method: Allocate -> Binding in
the
> DISCOVERY package to get all these advantages.)

-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | [phone] ext. 1241 | [e-mail]