Anycast discovery explained in the draft does not update RFC5766, https://tools.ietf.org/html/rfc5766#section-2.9 already discusses about anycast discovery and re-direction of an alternate server (following the guidence given in https://tools.ietf.org/html/rfc7094#section-3.4)). 

-Tiru


> -----Original Message-----
> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl
> Sent: Monday, November 14, 2016 1:38 PM
> To: 'Brandon Williams' <brandon.williams@akamai.com>; Prashanth Patil
> (praspati) <praspati@cisco.com>; tram@ietf.org
> Cc: tram-chairs@ietf.org; 'Dan Wing' <dan@danwing.org>; 'Spencer Dawkins
> at IETF' <spencerdawkins.ietf@gmail.com>; Tirumaleswar Reddy (tireddy)
> <tireddy@cisco.com>
> Subject: Re: [tram] draft-ietf-tram-turn-server-discovery
> 
> Hi Brandon,
> 
> In this draft, you have been pushing for "validation" of the discovered TURN
> server by using DTLS. The use case for that has not been spelled out, but the
> use case of "TURN servers *provided by* the local network or by the access
> network", really needs to be clarified in this draft. For this use case, clearance
> from authentication and validation was made in version -07 of the draft
> already.
> 
> Regarding your comment below, it is not clear which use case YOU NOW are
> considering.
> 
> Further, DISCOVERY and USAGE are not the same in this discussion. You mix
> that, especially regarding the anycast method. No one is suggesting that the
> TURN server is USED when addressed by anycast. There is only ONE packet
> addressed by anycast and sent to the STUN/TURN server and that is for
> DISCOVERING it.
> 
> See further inline below.
> 
> Thanks,
> Karl
> 
> -----Ursprungligt meddelande-----
> Från: Brandon Williams [mailto:brandon.williams@akamai.com]
> Skickat: den 11 november 2016 19:08
> Till: Karl Stahl; 'Prashanth Patil (praspati)'; tram@ietf.org
> Kopia: tram-chairs@ietf.org; 'Dan Wing'; 'Spencer Dawkins at IETF';
> 'Tirumaleswar Reddy (tireddy)'
> Ämne: Re: [tram] draft-ietf-tram-turn-server-discovery
> 
> (1) I agree with Karl that the MUST for (D)TLS or STUN auth should revert to a
> SHOULD or a RECOMMENDED, given that network perimeter control is called
> out with MUST (note that there are a few "must" to "MUST" edits required in
> that text). Although I would disagree with an enterprise network admin who
> chooses not to do one of those two things (see my comments about (3)/(4)
> below), I think there's room for difference of opinion there, so MUST is
> unlikely to be complied with anyway.
> 
> [Karl] Good that you agree the MUST (thrown-in during discuss) must go away,
> but for the use case of "TURN servers *provided by* the local network or by
> the access network." there should not even be SHOULD or RECOMMEND.
> Your are relating to TURN servers *provided by* (and maintained by?) some
> "trust anchor store [RFC6024] allows a TURN client ..." or by  "Certification
> authorities that issue TURN server certificates" that *provide TURN servers
> with their certificates in* that you expect to be discovered and where the
> TURN client (the WebRTC browser) must be equipped to accept those
> certificates. That is NOT FOR "the TURN servers *provided by* the local
> network or by the access network" that is being discussed here.
> 
> 
> (2) I disagree with Karl about anycast. A server that properly supports anycast
> [Karl] What is "a server that properly supports anycast"? It is certainly NOT A
> [RFC5766] TURN server that is supposed to be discovered by this draft.
> Also notice that we are talking about one anycast packet FOR DISCOVERY,
> NOT USAGE (relaying traffic) with anycast adressing.
> (I asked that the confusing "supports anycast" statement is removed from the
> beginning of the draft.)
> 
> will indeed treat incoming requests differently depending upon whether they
> arrive on the anycast address or the unicast address. I strongly disagree with
> the idea of using Try Alternate on the binding request, because you want
> redirect for the long-lived allocate request, not for the query-response binding
> request.
> [Karl] With a TURN server provided by the local or access network, STUN is
> NOT USED for setting up any binding and no subsequent traffic. The STUN
> binding response 300 Try Alternate (statically configured) in my proposed
> text, is only an indication used at DISCOVERY, that a network provided TURN
> server is there and should be used at its unicast address revealed in the
> 300 response. The long-lived TURN allocate IS USED for the traffic. The STUN
> server portion of the TURN server paralleling the default gateway router is
> never used for any binding.
> 
> Part of my reason for this is that good (by my definition) TURN server
> distribution is broader than is reasonable for anycast address management,
> and determining a redirect address to be delivered increases the cost of
> handling the STUN bind request. It is desirable for that cost to scale with the
> TURN allocate load, not the STUN bind load.
> [Karl] You just add a static route in you access router for the anycast address
> to point to your TURN server!
> 
> I don't oppose supporting both in the spec if someone wants to propose
> language for that, but it would add burden to client implementations because
> they would be required to support both even though the server could use
> either. On the other hand, the currently defined method shouldn't require
> changes to clients at all.
> [Karl] ?! But it does not find [RFC5766] TURN servers...
> 
> (3)/(4) I disagree with Karl's assessment of the deployment considerations,
> especially the conclusion that anycast is the better path for local/access
> networks.
> [Karl] If you mean traffic paths (like I did), "paths" are for USAGE and no one is
> suggesting anycast for that.
> Independent of how discovered (by anycast or any of the DNS methods) ALL
> USAGE through paths is by unicast addressing.
> 
> It might be better for the server
> implementer, but not for the the client, because I think it's particularly difficult
> for a client to determine whether it's network is "sealed".
> [Karl] No, not at all. Blocking STUN packets at the default gateway is the way
> to "network wise" seal the local network (and only allow the parallel TURN
> path)! That is easily detected by a TURN client.
> 
> The client has to trust that the network is properly sealed, since it's difficult (at
> least) for the client to verify. Also, I think that the DNS and DHCP methods are
> likely to be easier for enterprise and access networks to implement, since they
> will have the necessary systems in place already. Even a home network
> gateway appliance will already have both integrate DNS and integrate DHCP,
> so I suspect that a small local network will have an easier time with these than
> you suggest as well.
> 
> [Karl] So you agree that for a TURN server in a local network, its address shall
> only be deployed in local DNS - I think the draft should say that also.
> 
> Despite the fact that I disagree with the assessment, I don't run a local
> network or an access network and would not expect to deploy relays meant to
> function in that mode, so I will not have strong objections to including that
> language if there is broad support within the WG for Karl's framing.
> 
> --Brandon
> 
> On 11/10/2016 05:48 PM, Karl Stahl wrote:
> > (1) The downgrade of the MUST level requirement for authentication
> > defined
> in [RFC5766] was "rightly" (to use the term from below) introduced and made
> OPTIONAL for TURN servers provided by the local or access network.
> >
> > HOWEVER, Prashanth's: "I think we can mandate (D)TLS *if* STUN
> authentication or third-party authorization is not used." thrown-in during the
> DISCUSS, must be deleted from the -10 version of this discovery since it
> BLOCKs the usage and deployment of network provided TURN servers, which
> was the main purpose of this discovery draft. (Also, Authors's did not follow
> Ben Campbell's: "I saw a comment on my DISCUSS email thread from Karl
> Stahl, stating that DTLS could not be mandated. Has that input been
> considered?")
> >
> > The thrown-in addition in version -10 (not shown in full below)
> > highlights
> this:
> >
> >    A TURN client MUST use (D)TLS ... in the absence of STUN long-term
> >    credential mechanism [RFC5389] or STUN Extension for Third-Party
> >    Authorization [RFC7635].  ...
> >
> >    o  For certificate-based authentication, a pre-populated trust anchor
> >       store [RFC6024] allows a TURN client ...
> >
> >    o  Certification authorities that issue TURN server certificates
> >       ...
> >
> >    o  For TURN servers that don't have a certificate trust chain (e.g.,
> >       because they are on a home network or a corporate network), a
> >       configured list of TURN servers can contain the Subject Public Key
> >       Info (SPKI) fingerprint of the TURN servers... etc.
> >
> > What does the Authors have in mind - a regulated network of TURN
> > servers,
> when the purpose was for everyone to be able to use good WebRTC
> everywhere you can surf, including behind your home Best Buy bought WiFi
> router (which we can hope, some day, will include a default configured, ready
> to use, TURN server path paralleling its default gateway path (i.e. the
> NAT/firewall/access router/default gateway)?
> >
> > This specification shall (at least) specify discovery of network
> > provided
> TURN servers to allow real-time communication, in situations where it
> otherwise is not possible or bad:
> > - to meet the auto configuration of RFC 7478 (Web Real-Time
> > Communication
> Use Cases and Requirements) 2.3.5.1.
> > - providing a discovery method suitable for
> > draft-ietf-rtcweb-return-01
> >
> > The above has already been discussed many times in this WG:
> > https://www.ietf.org/mail-archive/web/tram/current/msg01319.html
> > https://www.ietf.org/mail-archive/web/tram/current/msg01742.html
> > https://www.ietf.org/mail-archive/web/tram/current/msg02191.html
> >
> > Just as credentials for authentication cannot be expected to be
> > available
> for this general usage, nor can we impose that certificates should be used.
> For the network provided TURN server, we should not/must not expect some
> higher level of trust or security when the real-time media flows through the
> TURN server than when it goes through the default gateway!
> >
> > The use of (D)TLS has been discussed intensively in the -04 version of
> > the
> draft
> > https://www.ietf.org/mail-archive/web/tram/current/msg01821.html
> > and was NOT mandated for the TURN server provided by the local or
> > access
> network. It cannot be thrown-in now again!
> >
> > Any arguments against have been of type: We need security in itself -
> protect this and that - do every authentication/validation in the book
> (whether needed or not) etc., which only leads to responses like I had to bring
> up during the discuss:
> > [Karl] Do you think we need to discover TURN servers for the pleasure
> > of
> doing "security that deal directly with TURN messages" in itself, and not for
> what they are supposed to do (relay "application data") and do you also think
> that is why a network provider will deploy such TURN server for his users?
> Please do not stop the purpose (by such phrases)!
> > (Also, encryption and protection against man-in-the-middle attacks,
> > for
> the payload (real-time traffic) are for the endpoints to do - like with WebRTC,
> mandating DTLS-SRTP media - it should not be expected to be done by a TURN
> server, especially when not always used.)
> >
> >
> > (2) Also as pointed out during the DISCUSS
> > https://www.ietf.org/mail-archive/web/tram/current/msg02144.html
> > and two times earlier (during WG discussions, but not addressed or
> responded to by the Authors):
> > https://www.ietf.org/mail-archive/web/tram/current/msg02081.htm l and
> > https://www.ietf.org/mail-archive/web/tram/current/msg01976.html
> >
> > The anycast method does not work with RFC5766 TURN servers! That has
> > not
> been addressed at all.
> >
> > A TURN server doesn't react one way (answering 300 Try Alternate) when
> addressed by an anycast address and another way (accepting the Allocate
> request) when addressed by its unicast address, does it?
> >
> > Author's (during the DISCUSS): "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];"
> > does not help and I responded: [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? What are these
> things?
> >
> > I have proposed this modification of the anycast method, which is
> > better
> (in several aspects) and doesn't need to update RFC5766:
> >
> > "When a client requires TURN services, it sends a STUN binding request
> > to
> the assigned anycast address.  The STUN server
> > responds with a 300 (Try Alternate) error as described in [RFC5389];
> > The
> response contains a unicast address in the ALTERNATE-SERVER attribute,
> which the client compares with the source address of the response and if the
> > addresses are the same, it is an indication to use the TURN server at
> > that
> address.
> >
> > For subsequent communication with the TURN server, the client uses
> > that
> responding server's unicast address."
> >
> > The sentence in the -10 draft under "3 Discovery Procedure": "not all
> > TURN
> servers may support anycast" can then be removed.
> >
> >
> > (3) I cannot see this -10 draft telling which discovery method that is
> > fit
> for the TURN servers provided by the local or access network (the network
> provided TURN server). However, there are confusing client behavior
> recommendations, like the sentences in the draft under "3 Discovery
> Procedure": "For best results, a client SHOULD implement all discovery
> mechanisms described above." and under "1 Introduction": "three discovery
> mechanisms, so as to maximize opportunity for discovery, based on the
> network in which the TURN client finds itself."
> >
> > A network provided TURN server is only meant for the users on the
> > specific
> network - others should not be able to use such TURN server, and it would
> then be preferred that it is only advertized and discovered at that local
> network - which is badly described by "maximize opportunity for discovery".
> >
> > If a DNS method would be used to discover the network provided TURN
> server, its private address should only be configured in private (local) DNS (we
> don't like to put our private IP addresses in public DNS), but I see no such
> recommendation. Further, the DNS methods are complex and expensive to
> deploy and one of them depends on DHCP that is not available on all access
> networks. That makes (a working) anycast discovery method the clear choice
> for a TURN server provided by the local or access network.
> >
> > Network provided TURN servers paralleling a NAT/firewall/access
> router/default gateway is a new concept that came up during WebRTC
> standardization work to deal with traversal and quality problems of real-time
> traffic. However, this draft give little or no guidance for deployment and I
> therefore suggest that a separate section is added, that spells out the
> deployment considerations for TURN servers provided by the local or access
> network (which now is missing, but I propose the following
> text):
> >
> >
> > (4) "Deployment Considerations for TURN Servers Provided by the Local
> > or
> Access Network"
> > (Suggested text for an additional section)
> >
> > The concept of paralleling a NAT/firewall/access-router/default
> > gateway at
> the local or access network with a TURN server, to deal with traversal and
> quality problems of real-time traffic, is new and came up during the WebRTC
> standardization work.
> >
> > Such network provided TURN servers, only accessible by the users on
> > the
> local or access network, must be automatically discovered and used, without
> specific configuration or having credentials for authentication or certificates
> for validation, to be useful for e.g. a WebRTC browsers to allow quality media
> traffic "everywhere you can surf".
> >
> > Just as for the Internet access itself, the TURN server is offered by
> > the
> network provider and there is no change in the trust or security level (which
> should not be expected) when real-time traffic flows through the TURN server
> path, than through the default gateway path. (The purpose of the network
> provided turn server is to allow traversal of real-time media traffic in
> environments with restrictive NAT/firewalls closed for UDP traffic and/or to
> allow better quality through the often data congested router at the default
> gateway.)
> >
> > The discovery of the network provided TURN server should meet the auto
> configuration of RFC 7478 (Web Real-Time Communication Use Cases and
> Requirements) 2.3.5.1. and draft-ietf-rtcweb-return-01 is defining the TURN
> client behavior for WebRTC browsers.
> >
> > For quality reasons, a sealed network configuration - i.e. the media
> > has
> to go through the TURN server, not through the default gateway (by using
> STUN instead of TURN) - is the typical intention when a TURN server is
> deployed in the local or access network. The sealed configuration can be
> enforced and signaled to the TURN client by the network provider blocking
> STUN packets at the default gateway.
> >
> > A network configuration enforcing sealed behavior, has the good effect
> > of
> allowing the TURN client (e.g. a WebRTC browser) in itself to have a non-
> sealed default configuration. (ietf-rtcweb-return-01 explains that a sealed
> default configuration in the browser itself, would result in that media between
> local clients would have to pass the TURN server, which is not
> desirable.)
> >
> > The above assumes that the TURN client using a TURN server in the
> > local or
> access network shall use unencrypted STUN/TURN (over UDP for best quality)
> so the STUN cookie can be detected and stopped in the default gateway.
> >
> > A TURN server included in the router at the default gateway, that
> intercepts and responds to an allocate request, should   be treated as a
> discovered network provided sealed TURN server configuration by a TURN
> client (without having to review any 300 Try Alternate response as outlined in
> anycast method description) allowing for tolerant and secure deployment.
> >
> > A web application that wants to try the default gateway path instead
> > of
> the TURN server path (in spite of a sealed network configuration) can suggest
> encrypted (D)TLS STUN and TURN candidates that will not be blocked by STUN
> cookie recognition at the default gateway. It is then up to application's TURN
> client whether to try the default gateway path.
> >
> > A further advantage of detecting a sealed network configuration, is
> > that a
> TURN client can select to *only in a sealed network configuration* look for a
> TURN server by the anycast method for discovery, thus eliminating the
> leakage risk mentioned under 9.3. Further, there will be no risk that a far away
> TURN server will be discovered and used and there will be no need for the TTL
> limitation suggested under 9.3.
> >
> > The anycast discovery method, combined with the above recommendations,
> allow for an easy and robust deployment of network provided TURN servers,
> fitting all types of local and access networks.
> >
> > The DNS based methods of this specification are more complex and
> > expensive
> to deploy and one of them depends on DHCP that is not available on all access
> networks. If any of the DNS based methods is used to advertize and discover a
> TURN in the local or access network, its private addresses should only be
> configured in private (local) DNS and not be published publicly, which adds
> further to the complexity and cost of deployment.
> >
> >
> > (5) Most (all?) of what is considered and summed up under (4) (the
> suggested additional text), has been brought forward on the TRAM WG list
> before, but not brought into the current -10 draft, see:
> > https://www.ietf.org/mail-archive/web/tram/current/msg00132.html
> > https://www.ietf.org/mail-archive/web/tram/current/msg00138.html
> > https://www.ietf.org/mail-archive/web/tram/current/msg01721.html
> > https://www.ietf.org/mail-archive/web/tram/current/msg01745.html
> > The links given under (1) and (2) above
> > https://www.ietf.org/mail-archive/web/tram/current/msg02155.html
> >
> > /Karl
> >
> >
> > -----Ursprungligt meddelande-----
> > Från: tram [mailto:tram-bounces@ietf.org] För Prashanth Patil
> > (praspati)
> > Skickat: den 2 november 2016 22:18
> > Till: tram@ietf.org
> > Kopia: tram-chairs@ietf.org; Dan Wing; Spencer Dawkins at IETF;
> Tirumaleswar Reddy (tireddy)
> > Ämne: [tram] draft-ietf-tram-turn-server-discovery
> >
> > The TURN discovery draft originally suggested that STUN authentication
> > be
> relaxed and made OPTIONAL for TURN servers provided by the local or access
> network. The intention was to allow new/guest users (who do not necessarily
> possess long term credentials for STUN authentication) in the network to
> discover and use TURN services offered by the network.
> > Ben Campbell raised an objection during IESG evaluation that we
> > clearly
> indicate that this is a downgrade of a MUST level requirement defined in
> [RFC5766] and explain its consequences. It was also rightly suggested that we
> mandate the use of (D)TLS in the absence of STUN authentication for
> protection against a variety of attacks; the draft now makes it a MUST that
> TURN servers use (D)TLS in the absence of STUN authentication.
> >
> > To put it simply, the draft mandates that TURN servers in a local or
> access network do at least one of (D)TLS or STUN authentication. If you have
> an opinion about this change, please let the working group know on the
> mailing list before the end of IETF 97.
> >
> > See below for snippets of what changed.
> >
> > Excerpt from Security Considerations of
> draft-ietf-tram-turn-server-discovery-09:
> >
> >    "Use of Session Traversal Utilities for NAT (STUN) [RFC5389]
> >    authentication is OPTIONAL for TURN servers provided by the local
> >    network or by the access network.  A network provided TURN server MAY
> >    be configured to accept Allocation requests without STUN
> >    authentication, and a TURN client MAY be configured to accept
> >    Allocation success responses without STUN authentication from a
> >    network provided TURN server.  In order to protect against man-in-
> >    the-middle attacks when accepting a TURN allocation response without
> >    STUN authentication, it is RECOMMENDED that the TURN client use one
> >    of the following techniques with (D)TLS to validate the TURN server"
> >
> >
> > Updated text in Security Considerations of
> draft-ietf-tram-turn-server-discovery-10:
> >
> >    "Use of Session Traversal Utilities for NAT (STUN) [RFC5389]
> >    authentication is OPTIONAL for TURN servers provided by the local
> >    network or by the access network.  A network provided TURN server MAY
> >    be configured to accept Allocation requests without STUN
> >    authentication, and a TURN client MAY be configured to accept
> >    Allocation success responses without STUN authentication from a
> >    network provided TURN server.
> >
> >    Making STUN authentication OPTIONAL is a downgrade of a MUST level
> >    requirement defined in [RFC5766].  The downgrade allows TURN servers
> >    provided by local or access network to accept Allocation requests
> >    from new and/or guest users in the network who do not necessarily
> >    possess long term credentials for STUN authentication.  The
> >    intention, in such deployments, being to provide TURN services to all
> >    users in the local or access network.  However, this opens up a TURN
> >    server to a variety of attacks described in Section 17 of [RFC5766].
> >    A TURN server in such cases must be configured to only process STUN
> >    requests from the trusted local network or subscribers of the access
> >    network.  Operational measures must be taken in order protect the
> >    TURN server; some of these measures include, but not limited to,
> >    access control by means of access-lists, firewalls, subscriber quota
> >    limits, ingress filtering etc.
> >
> >    A TURN client MUST use (D)TLS in the absence of STUN long-term
> >    credential mechanism [RFC5389] or STUN Extension for Third-Party
> >    Authorization [RFC7635]."
> >
> > Please refer
> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-10#section
> -9 for more details.
> >
> > Thanks,
> > Authors
> >
> > _______________________________________________
> > tram mailing list
> > tram@ietf.org
> > https://www.ietf.org/mailman/listinfo/tram
> >
> > _______________________________________________
> > tram mailing list
> > tram@ietf.org
> > https://www.ietf.org/mailman/listinfo/tram
> >
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram