Re: [tram] Maybe we have (D)TLS consensus; WAS: draft-ietf-tram-turn-server-discovery

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

Hi Brandon, Tiru, Pål-Erik,

I've read up on your discussions during Christmas and want to convey the following (hoping we now better can understand each other's points and get to a good consensus and text for this draft to hopefully become an RFC soon. Further down I will point out relevant things that Oleg Moskalenko suggested already in March 2014, but I think none of us fully understood at that time. 

I still mean this DISCOVERY draft cannot mandate (no MUST requirements) USAGE of TURN servers. See just sent email about the version -11 text also.

Your technical points first though:

[Pål-Erik +Brandon] > Can the client use (D)TLS only during discovery and auth phases?
--- NOT at all possible for the DISCOVERY phase. Neither DHCP, DNS, nor anycast can use (D)TLS - There is not even any such option for the discovery phase, is there?
Discovery just gives as an IP address to the TURN server.
It is with usage of the TURN server that the transport method (here UDP versus (D)TLS) comes in.
(And notice, for application provided TURN servers, there is no (D)TLS mandate.)


[Tiru] > What is the downside if (D)TLS is mandated ?
[Brandon] > I'd like to hear Karl's thoughts on that. I agree that unauthenticated 
(D)TLS would be the more reliable way to get the required mitigation, 
but if it is reasonable to say that some networks don't require it, why 
should we mandate the overhead of (D)TLS?
[Pål-Erik] > We do have some hardware that might have problems doing both (D)DTLS and SRTP on the amount of packets they are producing.
(--- Hope we are clear that Tiru's MUST (D)TLS request now is only for self signed certificates, since "Trust Anchors" for a TURN servers provided by the local or access network do not exist (or rather is the network administrator himself). 

First: --- I have earlier pointed out that self signed certificates are not liked by our WebRTC Browser making friends that we hope will use this discovery draft...

Second: --- The "S" in (D)TLS (and in TLS, HTTPS, WSS also) is very CPU power hungry. (Self experienced details: Using RSA of SSL-init with 2048 bit certificates takes about 25ms for one x86 3GHz CPU, limiting initializing such to only 40 per second.) This comes from the "Validation" and the (extra) encryption initialization that we are not really interested in here. Actually, such CPU hunger increases DOS/DDOS risks.) 
--- Also see: (D)TLS ... "is like 100 or 1000 times more calculation-heavy than sending thousands similar initial ALLOCATION requests" from Oleg's discussion of this in 2014: https://www.ietf.org/mail-archive/web/tram/current/msg00453.html 

Third: --- What Tiru wants, as I understand it (and I don't disagree), is to limit the spoofing (and maybe DOS, DDOS) attack risks (when you don’t have password authentication), in case you have ATTACKERS ON YOUR LOCAL OR ACCESS network. However, that is better achieved by CONTINUING doing AUTHENTICATION, DUMMY or "bogus authentication" (by the TURN server accepting password=user) as Oleg suggested 2014: https://www.ietf.org/mail-archive/web/tram/current/msg00427.html 
--- The (main) technical background, I simply would say, is that an attacker can spoof (if the network access allows the attacker to show someone else's source IP address) if a TURN Allocation is set up by just one single UDP packet, but an attacker CANNOT SPOOF if more packets are needed (as with (D)TLS or any Authentication) (packets then also have to go back to the spoofer - which fails). It is not the validation, encryption nor double encryption (of (D)TLS) that we want.

--- Oleg's "bogus authentication" also opens up for a valuable feature:
What about signaling in the realm if there is any cost for the user associated with using network provided TURN server, by  having realms like: FreeToUse, 3xCost, 3xCostButFreeVoice? (GoGo WiFi or similar can be expected to take more of our minutes or Gigs for providing a pipe for a videoconference e.g. and the TURN client/application/user may be interested to know.) I am NOT meaning this should be specified in this discovery draft though, but we could SUGGEST such an idea for other drafts to take it further.  

[In this context, this by Brandon should also be considered] 
My point is that the client might not require such protection in 
all cases and it should be up to the client to make that determination. 
For example, if both the client and the server are on my home network, I 
don't really need the protection that (D)TLS provides. The server must 
support whatever security posture the client requires, but the server 
should not require the client to protect itself in a particular way.


Isn't the above sufficient to agree on a text where we totally remove the thrown-in (D)TLS mandate (that is in versions -10 and -11 of the draft), and RECOMMENDS (no MUST) that when spoof attack risks exist, TURN servers in the local or access not using STUN authentication SHOULD use STUN dummy authentication?

(Notice the logic in putting a form of STUN authentication back (after spelling out the Authentication downgrade that caused this discussion) and that there already is "IP authentication" in the draft through the text: "Making STUN authentication OPTIONAL is a downgrade of a MUST level... 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." (The Firewall only allowing local users to use the discovered TURN server, is IP address Authentication.)

(D)TLS with self signed certificates is CPU hungry, complex and (consider just sent email) hard to understand how to use. Should it even be mentioned as an alternative? 

If Brandon's fallback mechanism requirements should be in the text, it can be written without any MUST (since it also relates to usage, not to discovery).

/Karl  


-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]] 
Skickat: den 4 januari 2017 14:31
Till: Brandon Williams; Karl Stahl; Pal Martinsen (palmarti)
Kopia: Prashanth Patil (praspati); [e-mail]; 'Spencer Dawkins at IETF'; [e-mail]; Dan Wing ([e-mail])
Ämne: RE: SV: [tram] Maybe we have (D)TLS consensus; WAS: draft-ietf-tram-turn-server-discovery

> -----Original Message-----
> From: Brandon Williams [mailto:[e-mail]]
> Sent: Wednesday, January 4, 2017 6:28 PM
> To: Tirumaleswar Reddy (tireddy) <[e-mail]>; Karl Stahl
> <[e-mail]>; Pal Martinsen (palmarti) <[e-mail]>
> Cc: Prashanth Patil (praspati) <[e-mail]>; [e-mail];
> 'Spencer Dawkins at IETF' <[e-mail]>; [e-mail];
> Dan Wing ([e-mail]) <[e-mail]>
> Subject: Re: SV: [tram] Maybe we have (D)TLS consensus; WAS: draft-ietf-
> tram-turn-server-discovery
> 
> Hi Tiru,
> 
>  >
>  > Yes, these attacks may not happen in a home network. But we cannot
>  > expect the roaming client to keep changing the security posture as
>  > the device attaches to different networks. An average user may not be
>  > even aware of the security risks when (D)TLS is disabled.
>  >
>  > What is the downside if (D)TLS is mandated ?
>  >
> 
> I'd like to hear Karl's thoughts on that. I agree that unauthenticated
> (D)TLS would be the more reliable way to get the required mitigation,
> but if it is reasonable to say that some networks don't require it, why
> should we mandate the overhead of (D)TLS?

RFC5766 mandates STUN authentication though in some networks TURN client and server may not suffer the attacks discussed in the above RFC. This draft has already downgraded security by making TURN client and server authentication optional. Even a simple spoofed attack to close the allocation cannot be defended without (D)TLS.

I don't think protocols should make security optional just because in some networks attacks may not happen  (just like WebRTC mandates SRTP but in networks that use MACsec encrypting media may not be required when both the peers are in the same network). These attacks may not happen today but may happen in future, targeted attacks are increasing day by day, and I see growing number of internal attacks. 

-Tiru

> 
>  > I understand, I can add the following new lines:
>  >
>  > In order to allow the TURN client to select fallback to (D)TLS as
>  > described above, a TURN server that does not require either STUN long
>  > term authentication [RFC5389] or STUN Extension for Third Party
>  > Authorization [RFC7635] MUST support (D)TLS. Such a TURN server MAY
>  > allow fallback to clear text but fallback to clear text is NOT
>  > RECOMMENDED because it makes the client more susceptible to
>  > man-in-the-middle attacks and on-path packet injection.
>  >
> 
> That looks fine to me, but my proposed edits were really an attempt to
> address Karl's concerns, so let's see if we hear from him.
> 
> --Brandon
> 
> On 01/02/2017 10:14 AM, Tirumaleswar Reddy (tireddy) wrote:
> > Hi Brandon,
> >
> > Please see inline
> >
> >> -----Original Message-----
> >> From: Brandon Williams [mailto:[e-mail]]
> >> Sent: Wednesday, December 28, 2016 1:14 AM
> >> To: Tirumaleswar Reddy (tireddy) <[e-mail]>; Karl Stahl
> >> <[e-mail]>; Pal Martinsen (palmarti) <[e-mail]>
> >> Cc: Prashanth Patil (praspati) <[e-mail]>; [e-mail];
> >> 'Dan Wing' <[e-mail]>; 'Spencer Dawkins at IETF'
> >> <[e-mail]>; [e-mail]
> >> Subject: Re: SV: [tram] Maybe we have (D)TLS consensus; WAS: draft-ietf-
> >> tram-turn-server-discovery
> >>
> >> The original I responded to didn't have the tram list CCed. Apologies to
> >> those who receive duplicates.
> >>
> >> --
> >>
> >> Hi Tiru,
> >>
> >> Sorry about the delayed response.
> >>
> >> I understand that the requirements you propose are to protect the
> >> client. My point is that the client might not require such protection in
> >> all cases and it should be up to the client to make that determination.
> >> For example, if both the client and the server are on my home network, I
> >> don't really need the protection that (D)TLS provides.
> c
> >> The server must
> >> support whatever security posture the client requires, but the server
> >> should not require the client to protect itself in a particular way.
> >
> > The TURN server bypasses the Enterprise firewall security and allows traffic
> from outside to inside. As you already know, TURN permissions mimic the
> address-restricted filtering mechanism of NAT, and if the client were to choose
> security posture that does not offer any security to TURN message (because of
> bad user configuration or a malware client on the endpoint), it just renders the
> client to become a victim of DDOS attack (an attacker can sends faked
> permissions to the TURN server to launch attack (DOS or DDOS) on the TURN
> client and it nullifies the security benefits offered by CreatePermission).
> >
> > If the TURN server mandates (D)TLS then the above attack is not possible and
> would protect even a compromised/mis-configured client from DDOS attacks.
> In short, why would an Enterprise network administrator want to configure
> TURN server to be used in this mode in which clients can be subjected to
> DDOS attacks and the TURN server and Enterprise firewall cannot do anything
> to protect the client.
> >
> >>
> >> This is the foundation for my proposed edits.
> >
> c>
> > -Tiru
> >
> >>
> >> --Brandon
> >>
> >> On 12/13/2016 12:14 AM, Tirumaleswar Reddy (tireddy) wrote:
> >>> Hi Brandon,
> >>>
> >>> Thanks for the feedback. Please see inline
> >>>
> >>>> -----Original Message-----
> >>>> From: Brandon Williams [mailto:[e-mail]]
> >>>> Sent: Saturday, December 10, 2016 10:13 PM
> >>>> To: Karl Stahl <[e-mail]>; Tirumaleswar Reddy (tireddy)
> >>>> <[e-mail]>; Pal Martinsen (palmarti) <[e-mail]>
> >>>> Cc: Prashanth Patil (praspati) <[e-mail]>; tram-
> [e-mail];
> >>>> 'Dan Wing' <[e-mail]>; 'Spencer Dawkins at IETF'
> >>>> <[e-mail]>
> >>>> Subject: Re: SV: [tram] Maybe we have (D)TLS consensus; WAS: draft-ietf-
> >>>> tram-turn-server-discovery
> >>>>
> >>>> I'm not sure we're quite at consensus yet Karl, but I think we're close.
> >>>>
> >>>> I agree that the text you quote from the doc covers the client side
> >>>> considerations, and that framing it as recommendations rather than
> >>>> requirements still makes sense. It's up to the client to decide which
> >>>> security elements are required for the application use case, and that
> >>>> text was intended to provide guidance without trying to force a security
> >>>> posture that is more complicated than the use case requires.
> >>>
> >>> The requirements are to protect the client from various attacks.
> >>>
> >>>>
> >>>> For the server side, in order to allow the client to fall back to
> >>>> (D)TLS, the TURN server MUST support (D)TLS at least for opportunistic
> >>>> privacy. This doesn't mean that the server has to require (D)TLS. It can
> >>>> still allow fallback to cleartext if the client so chooses.
> >>>>
> >>>> So, I agree with you on reverting the MUST for the client, as long as we
> >>>> continue to strongly recommend (D)TLS as the fallback. If we do that
> >>>> though, I think we need to make it clear that a TURN server configured
> >>>> to allow sessions without STUN auth MUST support (D)TLS so that the
> >>>> client has the option of (D)TLS fallback.
> >>>>
> >>>> I think we are agreeing to this change.
> >>>>
> >>>> OLD:
> >>>>
> >>>> "A TURN client MUST use (D)TLS in the absence of ..."
> >>>>
> >>>> NEW:
> >>>>
> >>>> "A TURN client SHOULD use (D)TLS in the absence of ..."
> >>>>
> >>>> And I am proposing the addition of this paragraph at the end of the
> >>>> section 9, just before section 9.1.
> >>>>
> >>>> "In order to allow the TURN client to select fallback to (D)TLS as
> >>>> described above, a TURN server that does not require either STUN long
> >>>> term authentication [RFC5389] or STUN Extension for Third Party
> >>>> Authorization [RFC7635] MUST support (D)TLS. Such a TURN server MAY
> >> also
> >>>> allow fallback to clear text."
> >>>
> >>> [1] I agree with the above text except for the last line in the above
> >> paragraph. If the TURN server allows fallback to clear text then the attacker
> >> can subject the TURN client to various attacks. For example, attacker sends
> >> faked permissions to the TURN server to launch attack (DOS or DDOS) on
> the
> >> TURN client and it nullifies the security benefits offered by
> CreatePermission.
> >> The victim in this mode is the TURN client and not the TURN server, and
> hence
> >> it is more important for the client to use (D)TLS to protect itself from
> attacks.
> >>>
> >>> When there is a possibility that in clear text mode the TURN clients can be
> >> subjected to various attacks, why would an TURN server administrator want
> to
> >> allow fallback to clear text  ?
> >>>
> >>> [2] And what problems do you see with the following new proposed text ?
> >>> "In the absence of STUN long-term credential mechanism [RFC5389] or
> STUN
> >> Extension for Third-Party Authorization [RFC7635], a TURN client MUST use
> >> (D)TLS and if (D)TLS authentication to validate the TURN server identity is
> not
> >> possible then the TURN client MUST fallback to encryption-only (D)TLS."
> >>>
> >>> -Tiru
> >>>
> >>>>
> >>>> --Brandon
> >>>>
> >>>> On 12/05/2016 11:59 AM, Karl Stahl wrote:
> >>>>> All I want to do in the (D)TLS discussion is to delete the sentence “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].” under 9.  Security Considerationsthat was thrown-into
> >>>>> version -10 during the discuss.
> >>>>>
> >>>>>
> >>>>>
> >>>>> **We leave all the rest regarding (D)TLS as it has been since version -7
> >>>>> of this draft.**
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Brandon,
> >>>>>
> >>>>>
> >>>>>
> >>>>> I see there already are the (general) SHOULD or RECOMMEND that you
> >>>>> wanted (I did not suggest to change those – they are there since version
> >>>>> -7 I believe): “It is RECOMMENDED that the TURN client use one of the
> >>>>> following techniques with (D)TLS to validate the TURN server:” and
> >> further…
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> for Tiru, this is already in the draft since -7 and I am not suggesting
> >>>>> to change that:
> >>>>>
> >>>>>
> >>>>>
> >>>>> “   An auto-discovered TURN server is considered to be only as trusted
> as
> >>>>>
> >>>>>    the path between the client and the TURN server.  In order to safely
> >>>>>
> >>>>>    use auto-discovered TURN servers for sessions with 'strict privacy'
> >>>>>
> >>>>>    requirements, the user needs to be able to define privacy criteria
> >>>>>
> >>>>>    (e.g.  a trusted list of servers, networks, or domains) that are
> >>>>>
> >>>>>    considered acceptable for such traffic.  Any discovered TURN server
> >>>>>
> >>>>>    outside the criteria is considered untrusted and therefore MUST NOT
> >>>>>
> >>>>>    be used for privacy sensitive communication.
> >>>>>
> >>>>>
> >>>>>
> >>>>>    In some auto-discovery scenarios, it might not be possible for the
> >>>>>
> >>>>>    TURN client to use (D)TLS authentication to validate the TURN server.
> >>>>>
> >>>>>    However, fall-back to clear text in such cases could leave the TURN
> >>>>>
> >>>>>    client open to on-path injection of spoofed TURN messages.  Instead,
> >>>>>
> >>>>>    with an explicit administrator choice, a TURN client SHOULD fall-back
> >>>>>
> >>>>>    to encryption-only (D)TLS when (D)TLS authentication is not
> >>>>>
> >>>>>    available.  Another reason to fall-back to encryption-only is for
> >>>>>
> >>>>>    privacy, which is analogous to SMTP opportunistic encryption
> >>>>>
> >>>>>    [RFC7435] where one does not require privacy but one desires privacy
> >>>>>
> >>>>>    when possible.
> >>>>>
> >>>>>
> >>>>>
> >>>>>    It is suggested that a TURN client attempt (D)TLS with authentication
> >>>>>
> >>>>>    and encryption, falling back to encryption-only if the TURN server
> >>>>>
> >>>>>    cannot be authenticated via (D)TLS.  A TURN client could fall back to
> >>>>>
> >>>>>    clear text, with an explicit administrator choice, if it does not
> >>>>>
> >>>>>    support unauthenticated (D)TLS, but fallback to clear text is NOT
> >>>>>
> >>>>>    RECOMMENDED because it makes the client more susceptible to man-
> >> in-
> >>>>>
> >>>>>    the-middle attacks and on-path packet injection.
> >>>>>
> >>>>> ”
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> **Tiru – Below you are pointing at the -10 version changes that WE ARE
> >>>>> discussing here.**
> >>>>>
> >>>>>
> >>>>>
> >>>>> Praspanth put them on the table again and I brought up that the
> >>>>>
> >>>>> “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].”
> >>>>>
> >>>>> must go away (leave the rest), since it effectively forbids TURN servers
> >>>>> provided by the local and access network.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Brandon had agreed that MUST should go away, when you jumped in
> with
> >>>> the
> >>>>> attacks arguments, when we were discussing whether there should still
> be
> >>>>> a SHOULD or RECOMMEND. – Then you got me (and others?) lost,
> and….
> >>>>>
> >>>>>
> >>>>>
> >>>>> So catch up from point (1) of my:
> >>>>>
> >>>>> https://www.ietf.org/mail-archive/web/tram/current/msg02216.html
> >>>>> <https://urldefense.proofpoint.com/v2/url?u=https-
> >> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg02216.html&d=DgMFaQ&c=96ZbZZcaMF4
> >>>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=NtRZwrmn2K-
> >>>> WUI_QN5k_yHlAN-uzhoQU8bs2yA_RBP8&e=>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> And you may notice that in
> >>>>>
> >> https://mailarchive.ietf.org/arch/msg/tram/3svO9djFxeZyTtNsgqQf8zCTiVY
> >>>>> <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>>
> >>
> 3A__mailarchive.ietf.org_arch_msg_tram_3svO9djFxeZyTtNsgqQf8zCTiVY&d=
> >>>> DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=SLjyswdn-
> >>>> oZ_aev0pRxD3h6c4aKbEQZ3c_kL9_ccHGM&e=>
> >>>>> that you referred to
> >>>>>
> >>>>> “Making STUN authentication OPTIONAL”
> >>>>>
> >>>>> is ALREADY COMPENSATED for by “IP address authentication” (the
> >>>>> foundation of today’s IP telephony authentication):
> >>>>>
> >>>>> “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.”
> >>>>>
> >>>>> where ”firewalls” specifically applies to TURN servers that local or
> >>>>> access network providers allow only their own users to access.
> >>>>>
> >>>>>
> >>>>>
> >>>>> And Author’s: “Please refer
> >>>>> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-
> >> 10#section-
> >>>> 9
> >>>>> <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__tools.ietf.org_html_draft-2Dietf-2Dtram-2Dturn-2Dserver-
> >> 2Ddiscovery-
> >>>> 2D10-23section-2D9&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
> >>>> nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=b0fJ1ANqhE8C2BrlnGY3iW
> >>>> CwVEr2OhYyFlE__oOHtSE&e=>for
> >>>>> more details.”
> >>>>>
> >>>>> already (since version -7 I think) in detail discusses the (D)TLS
> >>>>> implications in this context (that you are redoing).
> >>>>>
> >>>>>
> >>>>>
> >>>>> Please, again, let us stay with the consensus since version -7 of this
> >>>>> draft: No (D)TLS mandate.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Karl
> >>>>>
> >>>>>
> >>>>>
> >>>>> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> >>>>> *Skickat:* den 4 december 2016 08:33
> >>>>> *Till:* Pal Martinsen (palmarti); Karl Stahl; tram mailing list
> >>>>> *Kopia:* Brandon Williams; Prashanth Patil (praspati);
> >>>>> [e-mail] <mailto:[e-mail]>; Dan Wing; Spencer
> >>>>> Dawkins at IETF
> >>>>> *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
> >>>>>
> >>>>>
> >>>>>
> >>>>> Prashanth has already summarized the changes done to draft during
> ISEG
> >>>>> review in
> >>>>>
> >> https://mailarchive.ietf.org/arch/msg/tram/3svO9djFxeZyTtNsgqQf8zCTiVY
> >>>>> <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>>
> >>
> 3A__mailarchive.ietf.org_arch_msg_tram_3svO9djFxeZyTtNsgqQf8zCTiVY&d=
> >>>> DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=SLjyswdn-
> >>>> oZ_aev0pRxD3h6c4aKbEQZ3c_kL9_ccHGM&e=>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Karl’s comment is to not mandate (D)TLS, and we don’t agree with him.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Request you, WG members, WG chairs and AD to share their thoughts
> on
> >>>>> mandating the use of (D)TLS when STUN authentication is not used to
> >>>>> handle the threats discussed in RFC5766.
> >>>>>
> >>>>>
> >>>>>
> >>>>> -Tiru
> >>>>>
> >>>>>
> >>>>>
> >>>>> *From:*Pal Martinsen (palmarti)
> >>>>> *Sent:* Friday, December 2, 2016 11:27 PM
> >>>>> *To:* Karl Stahl <[e-mail]
> <mailto:[e-mail]>>;
> >>>>> tram mailing list <[e-mail] <mailto:[e-mail]>>
> >>>>> *Cc:* Tirumaleswar Reddy (tireddy) <[e-mail]
> >>>>> <mailto:[e-mail]>>; Brandon Williams
> >>>>> <[e-mail]
> >> <mailto:[e-mail]>>;
> >>>>> Prashanth Patil (praspati) <[e-mail]
> >>>>> <mailto:[e-mail]>>; [e-mail]
> >>>>> <mailto:[e-mail]>; Dan Wing <[e-mail]
> >>>>> <mailto:[e-mail]>>; Spencer Dawkins at IETF
> >>>>> <[e-mail]
> >>>> <mailto:[e-mail]>>
> >>>>> *Subject:* Re: [tram] draft-ietf-tram-turn-server-discovery
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hi Karl (and tramsters),
> >>>>>
> >>>>>
> >>>>>
> >>>>> I am sympathetic to your arguments but they might have been lost
> >>>>> somewhere in the email thread (A mix of quoting, repeating and inline
> >>>>> commenting have at least made my email client somewhat confused.)
> >>>>>
> >>>>>
> >>>>>
> >>>>> The best thing you can do at this moment is to provide text. I suggest
> >>>>> you write up a draft as a counter proposal and submit it. In that way
> >>>>> the WG members can read through and comment.
> >>>>>
> >>>>>
> >>>>>
> >>>>> I encourage the WG chairs to give Karl enough time to write this up,
> >>>>> before progressing the other draft.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> .-.
> >>>>>
> >>>>> Pål-Erik
> >>>>>
> >>>>>
> >>>>>
> >>>>>     On 2 Dec 2016, at 09:38, Karl Stahl <[e-mail]
> >>>>>     <mailto:[e-mail]>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Hi Tiru,
> >>>>>
> >>>>>
> >>>>>
> >>>>>     I am trying to make the point that there is no option for this
> >>>>>     draft, supposed to fulfill:
> >>>>>
> >>>>>     *[tram] Milestone 3: TURN server auto-discovery mechanism for
> >>>>>     enterprise and ISPs*
> >>>>>
> >>>>>     to result in: “We forbid usage of such (yellow) network provided
> >>>>>     TURN servers (use gray or grayish TURN servers instead)”,  which is
> >>>>>     the consequence of mandating (D)TLS.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Simply leave the consensus since version -7 of this draft by
> >>>>>     removing the (D)TLS mandating for TURN servers provided by  the
> >>>>>     local or access network thrown-in during the discuss.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     /Karl
> >>>>>
> >>>>>
> >>>>>
> >>>>>     PS: I believe the attack discussion below is already done, and that
> >>>>>     you are wrong in thinking that authentication which protects against
> >>>>>     spoof attacks can be exchanged for encryption, and that any of these
> >>>>>     things protects against DDOS attacks . These security things address
> >>>>>     different things and are not interchangeable, nor are they universal
> >>>>>     means against attacks of various kinds.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     And the outcome of any such discussion doesn’t change the above.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Please note (sorry to repeat)  that for the purpose of getting a
> >>>>>     better path for real-time traffic than through the default gateway
> >>>>>     path, we cannot expect to also get a higher security or trust level,
> >>>>>     nor to resolve every problem in the world.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     *Från:* Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> >>>>>     *Skickat:* den 28 november 2016 10:53
> >>>>>     *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil
> >>>>>     (praspati); [e-mail] <mailto:[e-mail]>
> >>>>>     *Kopia:* [e-mail] <mailto:[e-mail]>; 'Dan
> >>>>>     Wing'; 'Spencer Dawkins at IETF'
> >>>>>     *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Hi Karl,
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Yes, I am discussing TURN servers provided by local or access
> >>>>>     networks, referring to inside attacks launched by attackers inside
> >>>>>     the local or access network.
> >>>>>
> >>>>>     a)An inside attacker sends faked permissions to the TURN server to
> >>>>>     launch attack (DOS or DDOS) on the victim (TURN client).
> >>>>>
> >>>>>     b)An inside attacker sends spoofed TURN requests to the TURN server
> >>>>>     to close allocations.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Both above attacks can be prevented by using opportunistic
> >>>>>     encryption with (D)TLS.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     -Tiru
> >>>>>
> >>>>>
> >>>>>
> >>>>>     *From:* tram [mailto:[e-mail]] *On Behalf Of *Karl
> Stahl
> >>>>>     *Sent:* Monday, November 28, 2016 2:49 PM
> >>>>>     *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
> >>>>>     <mailto:[e-mail]>>; 'Brandon Williams'
> >>>>>     <[e-mail]
> >>>> <mailto:[e-mail]>>;
> >>>>>     Prashanth Patil (praspati) <[e-mail]
> >>>>>     <mailto:[e-mail]>>; [e-mail]
> <mailto:[e-mail]>
> >>>>>     *Cc:* [e-mail] <mailto:[e-mail]>; 'Dan Wing'
> >>>>>     <[e-mail] <mailto:[e-mail]>>; 'Spencer Dawkins
> at
> >>>>>     IETF' <[e-mail]
> >>>>>     <mailto:[e-mail]>>
> >>>>>     *Subject:* Re: [tram] draft-ietf-tram-turn-server-discovery
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Hi Tiru,
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Now I don’t know where you are again.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Are you discussing TURN servers provided by the local or access
> >>>>>     network (the yellow TURN servers), that are released from
> >>>>>     authentication (no dispute there), but for which (D)TLS mandate was
> >>>>>     thrown in-during the discuss (making them gray)? That is the
> >>>>>     showstopper that must go away.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Some comments below. Hope we agree  the below does not relate to
> >> the
> >>>>>     yellow TURN server.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     /Karl
> >>>>>
> >>>>>
> >>>>>
> >>>>>     *Från:* Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> >>>>>     *Skickat:* den 28 november 2016 04:02
> >>>>>     *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil
> >>>>>     (praspati); [e-mail] <mailto:[e-mail]>
> >>>>>     *Kopia:* [e-mail] <mailto:[e-mail]>; 'Dan
> >>>>>     Wing'; 'Spencer Dawkins at IETF'
> >>>>>     *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Hi Karl,
> >>>>>
> >>>>>
> >>>>>
> >>>>>     No, I don’t agree that (D)TLS is not mandatory. Opportunistic
> >>>>>     encryption is not new. It’s discussed in RFC7435, and used in TCP
> >>>>>     increased security (TCPINC WG) and DNS privacy exchange (DPRIVE
> >> WG).
> >>>>>
> >>>>>
> >>>>>
> >>>>>     How do you propose to handle the following passive attacks without
> >>>>>     (D)TLS or STUN authentication ?
> >>>>>
> >>>>>
> >>>>>
> >>>>>     a) https://tools.ietf.org/html/rfc5766#section-17.2.1
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__tools.ietf.org_html_rfc5766-23section-
> >>>> 2D17.2.1&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
> >>>> nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=yTTYKgor2_ajHe7KP_4Bznl
> >>>> G1EamuIy_K7ak0U40RbM&e=>,
> >>>>>     where attacker sends faked permissions to the TURN server to launch
> >>>>>     attack (DOS or DDOS) on the victim (TURN client).
> >>>>>
> >>>>>     > Since the _TURN server sits outside_ the firewall, at attacker outside
> >> the
> >>>>>     firewall can now send a
> >>>>>
> >>>>>     --- A TURN server provided by local or access network, shall only be
> >>>>>     accessible by users inside the firewall.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     b) https://tools.ietf.org/html/rfc5766#section-17.3.3
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__tools.ietf.org_html_rfc5766-23section-
> >>>> 2D17.3.3&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
> >>>> nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=eH-
> >>>> u5a6yq0GxTqHFJMTssCJefcXLrMGLQdz-7MK_l7c&e=>,
> >>>>>     attacker sends spoofed TURN requests to the TURN server to close
> >>>>>     allocations.
> >>>>>
> >>>>>     --- I don’t think (D)TLS helps if you can spoof and have such
> >>>>>     attackers inside your network. (that paragraph says:  TURN prevents
> >>>>>     this by requiring that the credentials used”) meaning authentication
> >>>>>     (not certificate checking, nor encryption).
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     -Tiru
> >>>>>
> >>>>>
> >>>>>
> >>>>>     *From:* tram [mailto:[e-mail]] *On Behalf Of *Karl
> Stahl
> >>>>>     *Sent:* Monday, November 28, 2016 1:39 AM
> >>>>>     *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
> >>>>>     <mailto:[e-mail]>>; 'Brandon Williams'
> >>>>>     <[e-mail]
> >>>> <mailto:[e-mail]>>;
> >>>>>     Prashanth Patil (praspati) <[e-mail]
> >>>>>     <mailto:[e-mail]>>; [e-mail]
> <mailto:[e-mail]>
> >>>>>     *Cc:* [e-mail] <mailto:[e-mail]>; 'Dan Wing'
> >>>>>     <[e-mail] <mailto:[e-mail]>>; 'Spencer Dawkins
> at
> >>>>>     IETF' <[e-mail]
> >>>>>     <mailto:[e-mail]>>
> >>>>>     *Subject:* Re: [tram] draft-ietf-tram-turn-server-discovery
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Hi Tiru,
> >>>>>
> >>>>>
> >>>>>
> >>>>>     So we agree that the (D)TLS mandate thrown-in during the discuss
> >>>>>     (making yellow TURN servers gray) shall go away and we are back to
> >>>>>     what was consensus since version -7 of the draft. I think the
> >>>>>     attacks you are discussing now have been listed already and for TURN
> >>>>>     servers in a local or access network (no change since version -7),
> >>>>>     we should not expect a higher security or trust level when sending
> >>>>>     our real-time traffic through another path than the through default
> >>>>>     gateway, both paths are provided by the same network provider.
> >>>>>
> >>>>>     * *
> >>>>>
> >>>>>     If “protects the client from various attacks discussed in previous
> >>>>>     mails” related to discovery of TURN servers, really is possible by
> >>>>>     introducing something (why reopen that now?), we have to be careful
> >>>>>     not to make yellow TURN servers grayish, which I am afraid self
> >>>>>     signed certificates might do, and further, does this belong in a
> >>>>>     discovery draft, risking to pick a fight with the WebRTC browser
> >>>>>     makers supposed to use this specification. We know they don’t fancy
> >>>>>     self signed certificates…
> >>>>>
> >>>>>     <image002.jpg>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Isn’t it specifications for some specific usage/application (like
> >>>>>     the return draft for WebRTC browsers) that should consider such
> >>>>>     things (not this draft), without any recommendation from this
> >>>>>     specification?
> >>>>>
> >>>>>
> >>>>>
> >>>>>     /Karl
> >>>>>
> >>>>>
> >>>>>
> >>>>>     *Från:* Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> >>>>>     *Skickat:* den 23 november 2016 04:15
> >>>>>     *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil
> >>>>>     (praspati); [e-mail] <mailto:[e-mail]>
> >>>>>     *Kopia:* [e-mail] <mailto:[e-mail]>; 'Dan
> >>>>>     Wing'; 'Spencer Dawkins at IETF'
> >>>>>     *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
> >>>>>
> >>>>>
> >>>>>
> >>>>>     I am not suggesting that authentication is mandatory for TURN
> >>>>>     servers provided by local or access networks using (D)TLS but use of
> >>>>>     (D)TLS [Karl: “these become gray not yellow” or are you suggesting
> >>>>>     certificated signed by the network provider]
> >>>>>
> >>>>>
> >>>>>
> >>>>>     [TR] No, they are yellow and not grey; clients will use (D)TLS but
> >>>>>     do not validate the TURN server certificate (referred to as
> >>>>>     Opportunistic security in the draft).
> >>>>>
> >>>>>
> >>>>>
> >>>>>     [Karl: Seems like you are suggesting self signed certificates to
> >>>>>     just get the encryption (again – also discussed)]
> >>>>>
> >>>>>
> >>>>>
> >>>>>     [TR] Yes, that’s one possible option to mandate (D)TLS. Client
> >>>>>     cannot validate the TURN server certificate but use encryption-only
> >>>>>     (D)TLS and protects the client from various attacks discussed in
> >>>>>     previous mails.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     -Tiru
> >>>>>
> >>>>>
> >>>>>
> >>>>>     *From:* Karl Stahl [mailto:[e-mail]]
> >>>>>     *Sent:* Tuesday, November 22, 2016 11:12 PM
> >>>>>     *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
> >>>>>     <mailto:[e-mail]>>; 'Brandon Williams'
> >>>>>     <[e-mail]
> >>>> <mailto:[e-mail]>>;
> >>>>>     Prashanth Patil (praspati) <[e-mail]
> >>>>>     <mailto:[e-mail]>>; [e-mail]
> <mailto:[e-mail]>
> >>>>>     *Cc:* [e-mail] <mailto:[e-mail]>; 'Dan Wing'
> >>>>>     <[e-mail] <mailto:[e-mail]>>; 'Spencer Dawkins
> at
> >>>>>     IETF' <[e-mail]
> >>>>>     <mailto:[e-mail]>>
> >>>>>     *Subject:* SV: [tram] draft-ietf-tram-turn-server-discovery
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Hi Tiru,
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Please understand that in this context:
> >>>>>
> >>>>>     - Authentication is to only allow certain users to use the TURN
> >>>>>     server resource
> >>>>>
> >>>>>     - Certificate checking as when using (D)TLS is to assure the user is
> >>>>>     using a trusted TURN server (and further is sets up an encrypted
> >>>>>     channel).
> >>>>>
> >>>>>
> >>>>>
> >>>>>     These things are not interchangeable or do the same things or
> >>>>>     achieves the same, which has been discussed over and over again in
> >>>>>     this draft already.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Let it rest with that we cannot/should not expect a higher trust or
> >>>>>     security level when sending our real-time traffic through the TURN
> >>>>>     server path, than trough the default gateway path. You simply have
> >>>>>     to trust the access from the network provider you select to connect
> >>>>>     to, or refrain from using it.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Please also understand that “the gray TURN servers” are provided by
> >>>>>     others than the local or access network, and you chose to trust them
> >>>>>     with your real-time traffic based on checking their certificate (Who
> >>>>>     configures which to allow into the WebRTC browser?).
> >>>>>
> >>>>>
> >>>>>
> >>>>>     In a specification which main purpose is to auto discover TURN
> >>>>>     servers provided by the local or access network (“the yellow ones”),
> >>>>>     you CANNOT LOGICALLY end up with saying you MUST/SHOULD or
> are
> >>>>>     RECOMMENDED to use “the gray ones” instead, provided by some
> >>>>>     authority or Brandon maybe (which are meant for other purposes).
> >>>>>     Then you have not delivered the specification we need = The
> >> showstopper.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     /Karl
> >>>>>
> >>>>>
> >>>>>
> >>>>>     PS: Some comments below.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     *Från:* Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> >>>>>     *Skickat:* den 22 november 2016 04:31
> >>>>>     *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil
> >>>>>     (praspati); [e-mail] <mailto:[e-mail]>
> >>>>>     *Kopia:* [e-mail] <mailto:[e-mail]>; 'Dan
> >>>>>     Wing'; 'Spencer Dawkins at IETF'
> >>>>>     *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Hi Karl,
> >>>>>
> >>>>>
> >>>>>
> >>>>>     I am not suggesting that authentication is mandatory for TURN
> >>>>>     servers provided by local or access networks using (D)TLS but use of
> >>>>>     (D)TLS [Karl: “these become gray not yellow” or are you suggesting
> >>>>>     certificated signed by the network provider] without authenticating
> >>>>>     the TURN server is mandatory to avoid various attacks listed in
> >>>>>     previous mails.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     In short, the TURN servers provided by local or access networks must
> >>>>>     use (D)TLS but it’s not mandatory for these TURN servers to get
> >>>>>     certificates from CA or any explicit configuration is required on
> >>>>>     the client to trust the TURN server. [Karl: Seems like you are
> >>>>>     suggesting self signed certificates to just get the encryption
> >>>>>     (again – also discussed)]
> >>>>>
> >>>>>
> >>>>>
> >>>>>     -Tiru
> >>>>>
> >>>>>
> >>>>>
> >>>>>     *From:* Karl Stahl [mailto:[e-mail]]
> >>>>>     *Sent:* Monday, November 21, 2016 2:10 AM
> >>>>>     *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
> >>>>>     <mailto:[e-mail]>>; 'Brandon Williams'
> >>>>>     <[e-mail]
> >>>> <mailto:[e-mail]>>;
> >>>>>     Prashanth Patil (praspati) <[e-mail]
> >>>>>     <mailto:[e-mail]>>; [e-mail]
> <mailto:[e-mail]>
> >>>>>     *Cc:* [e-mail] <mailto:[e-mail]>; 'Dan Wing'
> >>>>>     <[e-mail] <mailto:[e-mail]>>; 'Spencer Dawkins
> at
> >>>>>     IETF' <[e-mail]
> >>>>>     <mailto:[e-mail]>>
> >>>>>     *Subject:* SV: [tram] draft-ietf-tram-turn-server-discovery
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Hi Tiru,
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Trying to clarify as you request: I have lost track of in which
> >>>>>     context you are when you are "discussing various attacks" and what
> >>>>>     you mean with the ?? I marked below.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     My concern was whether this may again lead to that WE
> >>>>>     HAVE *_NO_* TURN SERVERS in the yellow area below resulting from
> >> the
> >>>>>     (D)TLS mandating that was thrown-in into version -10 during the
> >>>>>     discuss (=the showstopping), since TURN servers with
> >>>>>     certificates are NOT provided by the local or access network (those
> >>>>>     are provided by some "trust anchor store [RFC6024] allows a TURN
> >>>>>     client ..." or by "Certification authorities that issue TURN server
> >>>>>     certificates" etc..)
> >>>>>
> >>>>>
> >>>>>
> >>>>>     <image004.png>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     So, just let me rest with that your discussion does not take away
> >>>>>     the allowance to use TURN servers provided by the local or access
> >>>>>     network without authentication that was re-introduced in version -7
> >>>>>     of the draft (after long discussions, including with you Tiru).
> >>>>>     Remember, _those yellow TURN servers were the requirement of this
> >>>>>     draft to auto discover_ so they can be used by the WebRTC browsers
> –
> >>>>>     Usage cannot be forbidden (or un-recommended as Brandon
> suggests,
> >>>>>     although Brandon is agreeing to that the (D)TLS mandate must vanish
> >>>>>     for the yellow TURN servers).
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     FURTHER JUST TO REMIND AUTHORS of what is needed to be
> addresses
> >> in
> >>>>>     this draft; it is found in
> >>>>>
> >>>>>     https://www.ietf.org/mail-archive/web/tram/current/msg02216.html
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg02216.html&d=DgMFaQ&c=96ZbZZcaMF4
> >>>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=NtRZwrmn2K-
> >>>> WUI_QN5k_yHlAN-uzhoQU8bs2yA_RBP8&e=>
> >>>>>
> >>>>>     and the contradiction in section 7.2 as said in
> >>>>>
> >>>>>     https://www.ietf.org/mail-archive/web/tram/current/msg02226.html
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg02226.html&d=DgMFaQ&c=96ZbZZcaMF4
> >>>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=EtiuiVt5Mnjbw9WsDtmjiu2l
> >>>> -dv1RoHVpdAlTXtgZIQ&e=>
> >>>>>
> >>>>>     while this discussion with Author Tiru and >“I don't run a local
> >>>>>     network or an access network and would not expect to deploy relays
> >>>>>     meant to function in that mode“ Brandon*, has been on more or less
> >>>>>     deviated subjects, or repeating what we already have been through
> >>>>>     earlier (PS: Notice that Author Prashanth already listed/discussed
> >>>>>     the attack stuff during the discuss. I feared you were redoing that.)
> >>>>>
> >>>>>
> >>>>>
> >>>>>     /Karl
> >>>>>
> >>>>>
> >>>>>
> >>>>>     * https://www.ietf.org/mail-
> archive/web/tram/current/msg02217.html
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg02217.html&d=DgMFaQ&c=96ZbZZcaMF4
> >>>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=glxP3ovYX7Cd4f12zIILJhbTc
> >>>> EJ0ViqVgJQySQkJHYQ&e=>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     -----Ursprungligt meddelande-----
> >>>>>     Från: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> >>>>>     Skickat: den 18 november 2016 04:00
> >>>>>     Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil
> >>>>>     (praspati); [e-mail] <mailto:[e-mail]>
> >>>>>     Kopia: [e-mail] <mailto:[e-mail]>; 'Dan
> >>>>>     Wing'; 'Spencer Dawkins at IETF'
> >>>>>     Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Hi Karl,
> >>>>>
> >>>>>
> >>>>>
> >>>>>     I don't understand your concerns, please clarify. The draft mandates
> >>>>>     (D)TLS but does not mandate TURN server validation.
> >>>>>
> >>>>>     We are discussing various attacks possbile for the WG to decide if
> >>>>>     (D)TLS is a MUST or SHOULD.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     -Tiru
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     > -----Original Message-----
> >>>>>
> >>>>>     > From: Karl Stahl [mailto:[e-mail]]
> >>>>>
> >>>>>     > Sent: Friday, November 18, 2016 2:11 AM
> >>>>>
> >>>>>     > To: Tirumaleswar Reddy (tireddy) <[e-mail]
> >>>> <mailto:[e-mail]>>; 'Brandon Williams'
> >>>>>
> >>>>>     > <[e-mail]
> >>>> <mailto:[e-mail]>>;
> >>>>>     Prashanth Patil (praspati)
> >>>>>
> >>>>>     > <[e-mail] <mailto:[e-mail]>>;
> [e-mail]
> >>>>>     <mailto:[e-mail]>
> >>>>>
> >>>>>     > Cc: [e-mail] <mailto:[e-mail]>; 'Dan Wing'
> >>>>>     <[e-mail] <mailto:[e-mail]>>; 'Spencer Dawkins
> >>>>>
> >>>>>     > at IETF' <[e-mail]
> >>>> <mailto:[e-mail]>>
> >>>>>
> >>>>>     > Subject: SV: [tram] draft-ietf-tram-turn-server-discovery
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > Continuing the thread of this subject with the view that it should be
> >>>> about the
> >>>>>
> >>>>>     > MUST/SHOULD/RECOMMEND discussion regarding D(TLS) for the
> >> USAGE
> >>>> of
> >>>>>
> >>>>>     > an already discovered TURN server, which must be totally
> >> independent
> >>>> of the
> >>>>>
> >>>>>     > method used for discovery.
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > I can't say I understand where Brandon's/Tiru's discussion fits in and
> >>>> whether
> >>>>>
> >>>>>     > are right things are said and are in the right context:
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > ?? > > The draft mandates (D)TLS but does not mandate TURN
> server
> >>>>>
> >>>>>     > validation.
> >>>>>
> >>>>>     > ?? (D)TLS helps avoid various attacks, like attacker sending spoofed
> >>>> TURN
> >>>>>
> >>>>>     > messages ??  We should discuss all such possible attacks, before we
> >>>> decide to
> >>>>>
> >>>>>     > go with MUST or SHOULD.
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > Where are we know?
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > Please, just keep the clearance from authentication as it was from
> >>>> version
> >>>>>
> >>>>>     > -07 of the draft already, until the D(TLS) mandate was thrown in
> >> during
> >>>> the
> >>>>>
> >>>>>     > DISCUSS.
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > Simply, logically:
> >>>>>
> >>>>>     > > >> 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"
> >>>>>
> >>>>>     > are NOT under the clearance discussed, which is for "TURN servers
> >>>> *provided
> >>>>>
> >>>>>     > by* the local network or by the access network".
> >>>>>
> >>>>>     > so a SHOULD or RECOMMENDED of D(TLS) does not even belong
> >> under
> >>>> the
> >>>>>
> >>>>>     > clearance discussed.
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > FURTHER, When I read:
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > 7.2.  Recursively Encapsulated TURN
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     >    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].
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > Isn't that "any" in total contradiction to the clearance being
> discussed?
> >>>>>
> >>>>>     > I thought: "enterprise/gateway or access network" was the same as
> >> your
> >>>>>
> >>>>>     > "local or access network" and that for OTHER discovered TURN
> servers
> >>>>>
> >>>>>     > (outside the local or access network), it must be the application that
> >>>> instructs
> >>>>>
> >>>>>     > the TURN client how to use.
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > I suggest the 7.2 section is replaced with my:
> >>>>>
> >>>>>     > > >>> (4) "Deployment Considerations for TURN Servers Provided by
> >> the
> >>>>>
> >>>>>     > > >>> Local or
> >>>>>
> >>>>>     > > >> Access Network"
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > which mentions Recursively Encapsulated TURN [I-D.ietf-rtcweb-
> >> return].
> >>>>>
> >>>>>     > (you can spell it out like that)
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > /Karl
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > -----Ursprungligt meddelande-----
> >>>>>
> >>>>>     > Från: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> >>>>>
> >>>>>     > Skickat: den 15 november 2016 05:01
> >>>>>
> >>>>>     > Till: Brandon Williams; Karl Stahl; Prashanth Patil (praspati);
> >>>> [e-mail] <mailto:[e-mail]>
> >>>>>
> >>>>>     > Kopia: [e-mail] <mailto:[e-mail]>; 'Dan
> >> Wing';
> >>>>>     'Spencer Dawkins at IETF'
> >>>>>
> >>>>>     > Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > Hi Brandon,
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > I just listed one possible attack, there could be various other attacks
> >> like
> >>>> the
> >>>>>
> >>>>>     > one discussed in https://tools.ietf.org/html/rfc5766#section-17.2.1
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__tools.ietf.org_html_rfc5766-23section-
> >>>> 2D17.2.1&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
> >>>> nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=yTTYKgor2_ajHe7KP_4Bznl
> >>>> G1EamuIy_K7ak0U40RbM&e=>,
> >>>>>
> >>>>>     > where attacker sends faked permissions to the TURN server to
> launch
> >>>> attack
> >>>>>
> >>>>>     > (DOS or DDOS) on the victim (TURN client).
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > We should discuss all such possible attacks, before we decide to go
> >> with
> >>>>>
> >>>>>     > MUST or SHOULD.
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > -Tiru
> >>>>>
> >>>>>     >
> >>>>>
> >>>>>     > > -----Original Message-----
> >>>>>
> >>>>>     > > From: tram [mailto:[e-mail]] On Behalf Of Brandon
> >>>>>
> >>>>>     > > Williams
> >>>>>
> >>>>>     > > Sent: Monday, November 14, 2016 7:31 PM
> >>>>>
> >>>>>     > > To: Tirumaleswar Reddy (tireddy) <[e-mail]
> >>>> <mailto:[e-mail]>>; Karl Stahl
> >>>>>
> >>>>>     > > <[e-mail] <mailto:[e-mail]>>;
> Prashanth
> >>>>>     Patil (praspati)
> >>>>>
> >>>>>     > > <[e-mail] <mailto:[e-mail]>>;
> [e-mail]
> >>>>>     <mailto:[e-mail]>
> >>>>>
> >>>>>     > > Cc: [e-mail] <mailto:[e-mail]>; 'Dan
> Wing'
> >>>>>     <[e-mail] <mailto:[e-mail]>>; 'Spencer
> >>>>>
> >>>>>     > > Dawkins at IETF' <[e-mail]
> >>>> <mailto:[e-mail]>>
> >>>>>
> >>>>>     > > Subject: Re: [tram] draft-ietf-tram-turn-server-discovery
> >>>>>
> >>>>>     > >
> >>>>>
> >>>>>     > > +1 on the rationale. It makes almost no difference how you secure
> >> the
> >>>>>
> >>>>>     > > local or access network at the border, it's still possible that there
> >>>>>
> >>>>>     > > are
> >>>>>
> >>>>>     > on-path
> >>>>>
> >>>>>     > > adversaries, and using some type of authentication (either (D)TLS
> or
> >>>>>
> >>>>>     > > STUN) helps to protect against them.
> >>>>>
> >>>>>     > >
> >>>>>
> >>>>>     > > I still agree with Karl on downgrading the MUST back to SHOULD
> or
> >>>>>
> >>>>>     > > RECOMMENDED, since I think there's room for disagreement
> about
> >>>> how
> >>>>>
> >>>>>     > > critical it is to mitigate against that attack. Ease-of-use might win
> >>>>>
> >>>>>     > > out
> >>>>>
> >>>>>     > for some
> >>>>>
> >>>>>     > > networks provided they have other protection mechanisms at
> either
> >>>> the
> >>>>>
> >>>>>     > > network or datalink layer. I don't think it should drop below the
> >>>>>
> >>>>>     > > recommendation level though, because most network will not
> have
> >>>> such
> >>>>>
> >>>>>     > > mechanisms in place.
> >>>>>
> >>>>>     > >
> >>>>>
> >>>>>     > > --Brandon
> >>>>>
> >>>>>     > >
> >>>>>
> >>>>>     > > On 11/14/2016 06:36 AM, Tirumaleswar Reddy (tireddy) wrote:
> >>>>>
> >>>>>     > > > There seems to be confusion why (D)TLS is mandated in the
> draft.
> >>>>>
> >>>>>     > > >
> >>>>>
> >>>>>     > > > The draft mandates (D)TLS but does not mandate TURN server
> >>>> validation.
> >>>>>
> >>>>>     > In
> >>>>>
> >>>>>     > > scenarios where the TURN client cannot validate the TURN server,
> >>>>>
> >>>>>     > > (D)TLS helps avoid various attacks, like attacker sending spoofed
> >> TURN
> >>>>>
> >>>>>     > > messages
> >>>>>
> >>>>>     > to
> >>>>>
> >>>>>     > > TURN client and server. For example, when (D)TLS is not used,
> >> attacker
> >>>>>
> >>>>>     > > can send spoofed TURN requests to the TURN server to close
> >>>> allocations.
> >>>>>
> >>>>>     > > >
> >>>>>
> >>>>>     > > > The above attack is possible when TURN servers are provided by
> >>>>>
> >>>>>     > > > either
> >>>>>
> >>>>>     > local
> >>>>>
> >>>>>     > > or access networks.
> >>>>>
> >>>>>     > > >
> >>>>>
> >>>>>     > > > -Tiru
> >>>>>
> >>>>>     > > >
> >>>>>
> >>>>>     > > >> -----Original Message-----
> >>>>>
> >>>>>     > > >> From: tram [mailto:[e-mail]] On Behalf Of Karl
> >> Stahl
> >>>>>
> >>>>>     > > >> Sent: Monday, November 14, 2016 1:38 PM
> >>>>>
> >>>>>     > > >> To: 'Brandon Williams' <[e-mail]
> >>>> <mailto:[e-mail]>>;
> >>>>>     Prashanth
> >>>>>
> >>>>>     > > >> Patil
> >>>>>
> >>>>>     > > >> (praspati) <[e-mail]
> <mailto:[e-mail]>>;
> >>>> [e-mail]
> >>>>>     <mailto:[e-mail]>
> >>>>>
> >>>>>     > > >> Cc: [e-mail] <mailto:[e-mail]>; 'Dan
> >> Wing'
> >>>>>     <[e-mail] <mailto:[e-mail]>>; 'Spencer
> >>>>>
> >>>>>     > > >> Dawkins at IETF' <[e-mail]
> >>>>>     <mailto:[e-mail]>>; Tirumaleswar
> >>>>>
> >>>>>     > > >> Reddy
> >>>>>
> >>>>>     > > >> (tireddy) <[e-mail] <mailto:[e-mail]>>
> >>>>>
> >>>>>     > > >> 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:[e-mail]]
> >>>>>
> >>>>>     > > >> Skickat: den 11 november 2016 19:08
> >>>>>
> >>>>>     > > >> Till: Karl Stahl; 'Prashanth Patil (praspati)'; [e-mail]
> >>>> <mailto:[e-mail]>
> >>>>>
> >>>>>     > > >> Kopia: [e-mail] <mailto:[e-mail]>;
> '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://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg01319.html&d=DgMFaQ&c=96ZbZZcaMF4
> >>>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=Osl0dTxisM85YhdJ__0idlm
> >>>> EuHZDO94zeETh0KuWOUg&e=>
> >>>>>
> >>>>>     > > >>> https://www.ietf.org/mail-
> >>>> archive/web/tram/current/msg01742.html
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg01742.html&d=DgMFaQ&c=96ZbZZcaMF4
> >>>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ovkKpAFtadl_tW-
> >>>> sGE9lKBidFiJ9DwAxrKyC-KgdC6w&e=>
> >>>>>
> >>>>>     > > >>> https://www.ietf.org/mail-
> >>>> archive/web/tram/current/msg02191.html
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg02191.html&d=DgMFaQ&c=96ZbZZcaMF4
> >>>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=6qTmzqnEW5fWRDNt6JT9R
> >>>> WtnkKecOUYG8OyPtBVY9Ek&e=>
> >>>>>
> >>>>>     > > >>>
> >>>>>
> >>>>>     > > >>> 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
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg01821.html&d=DgMFaQ&c=96ZbZZcaMF4
> >>>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=JJm49cE6V10iisqHp3jNeSn
> >>>> qE7wHzDtSrIhsQU8Sx3A&e=>
> >>>>>
> >>>>>     > > >>> 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
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg02144.html&d=DgMFaQ&c=96ZbZZcaMF4
> >>>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=hti885FH0I_-
> >>>> 3z7dolfYCAia4FX3i12sUCWsGesND6s&e=>
> >>>>>
> >>>>>     > > >>> 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
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg02081.htm&d=DgMFaQ&c=96ZbZZcaMF4w
> >>>> 0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=f-
> >>>> GzOTsPm86NUqzFXyjAgPz6x-BiA-buLhIFPt9QfEg&e=> l
> >>>>>
> >>>>>     > > >>> and https://www.ietf.org/mail-
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>> 2D&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
> >> nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=Sa3jwtA2TFtNAIAnfTem32v
> >>>> W9jIfcBlsUwxIBelblDs&e=>
> >>>>>
> >>>>>     > > 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://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg00132.html&d=DgMFaQ&c=96ZbZZcaMF4
> >>>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=I4tX_vQd-
> >>>> ANV8cBjPGlHlFIVEUZ-3lYmVI6GbGtjxvc&e=>
> >>>>>
> >>>>>     > > >>> https://www.ietf.org/mail-
> >>>> archive/web/tram/current/msg00138.html
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg00138.html&d=DgMFaQ&c=96ZbZZcaMF4
> >>>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=JJWVyPhhTbhTpkcOmQRdB
> >>>> 49hx2gOMNKOL7qMT3bq630&e=>
> >>>>>
> >>>>>     > > >>> https://www.ietf.org/mail-
> >>>> archive/web/tram/current/msg01721.html
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg01721.html&d=DgMFaQ&c=96ZbZZcaMF4
> >>>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=QnbJOsYAvuDWr9YyEGsxU
> >>>> Ov8S1ha8ow9Do5VDOq6Gs0&e=>
> >>>>>
> >>>>>     > > >>> https://www.ietf.org/mail-
> >>>> archive/web/tram/current/msg01745.html
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg01745.html&d=DgMFaQ&c=96ZbZZcaMF4
> >>>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=duED3YRw_gPiLwPnjC7zgW
> >>>> 0KbQXqQBjN-BJC4bzmt44&e=>
> >>>>>
> >>>>>     > > >>> The links given under (1) and (2) above
> >>>>>
> >>>>>     > > >>> https://www.ietf.org/mail-
> >>>> archive/web/tram/current/msg02155.html
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__www.ietf.org_mail-
> >>>>
> >>
> 2Darchive_web_tram_current_msg02155.html&d=DgMFaQ&c=96ZbZZcaMF4
> >>>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >>>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=5fxjtRf2Ndt9R-
> >>>> RDwWpgG0d7mctpUT2lUZrKGaThZ40&e=>
> >>>>>
> >>>>>     > > >>>
> >>>>>
> >>>>>     > > >>> /Karl
> >>>>>
> >>>>>     > > >>>
> >>>>>
> >>>>>     > > >>>
> >>>>>
> >>>>>     > > >>> -----Ursprungligt meddelande-----
> >>>>>
> >>>>>     > > >>> Från: tram [mailto:[e-mail]] För Prashanth
> Patil
> >>>>>
> >>>>>     > > >>> (praspati)
> >>>>>
> >>>>>     > > >>> Skickat: den 2 november 2016 22:18
> >>>>>
> >>>>>     > > >>> Till: [e-mail] <mailto:[e-mail]>
> >>>>>
> >>>>>     > > >>> Kopia: [e-mail] <mailto:[e-mail]>;
> 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-
> >> 1
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 3A__tools.ietf.org_html_draft-2Dietf-2Dtram-2Dturn-2Dserver-
> >> 2Ddiscovery-
> >>>> 2D1&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
> >>>> nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=--B-
> >>>> kAp9De1f6HhRKLEtD1bVS33BpG2S5MYzWBQ_YDI&e=>
> >>>>>
> >>>>>     > > >> 0#
> >>>>>
> >>>>>     > > >> section
> >>>>>
> >>>>>     > > >> -9 for more details.
> >>>>>
> >>>>>     > > >>>
> >>>>>
> >>>>>     > > >>> Thanks,
> >>>>>
> >>>>>     > > >>> Authors
> >>>>>
> >>>>>     > > >>>
> >>>>>
> >>>>>     > > >>> _______________________________________________
> >>>>>
> >>>>>     > > >>> tram mailing list
> >>>>>
> >>>>>     > > >>> [e-mail] <mailto:[e-mail]>
> >>>>>
> >>>>>     > > >>> https://www.ietf.org/mailman/listinfo/tram
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>>
> >>
> 3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4j
> >>>> pN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086
> >>>> nBuC6-cz9H7GKY_0EV8s&e=>
> >>>>>
> >>>>>     > > >>>
> >>>>>
> >>>>>     > > >>> _______________________________________________
> >>>>>
> >>>>>     > > >>> tram mailing list
> >>>>>
> >>>>>     > > >>> [e-mail] <mailto:[e-mail]>
> >>>>>
> >>>>>     > > >>> https://www.ietf.org/mailman/listinfo/tram
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>>
> >>
> 3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4j
> >>>> pN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086
> >>>> nBuC6-cz9H7GKY_0EV8s&e=>
> >>>>>
> >>>>>     > > >>>
> >>>>>
> >>>>>     > > >>
> >>>>>
> >>>>>     > > >> _______________________________________________
> >>>>>
> >>>>>     > > >> tram mailing list
> >>>>>
> >>>>>     > > >> [e-mail] <mailto:[e-mail]>
> >>>>>
> >>>>>     > > >> https://www.ietf.org/mailman/listinfo/tram
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>>
> >>
> 3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4j
> >>>> pN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086
> >>>> nBuC6-cz9H7GKY_0EV8s&e=>
> >>>>>
> >>>>>     > >
> >>>>>
> >>>>>     > > _______________________________________________
> >>>>>
> >>>>>     > > tram mailing list
> >>>>>
> >>>>>     > > [e-mail] <mailto:[e-mail]>
> >>>>>
> >>>>>     > > https://www.ietf.org/mailman/listinfo/tram
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>>
> >>
> 3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4j
> >>>> pN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086
> >>>> nBuC6-cz9H7GKY_0EV8s&e=>
> >>>>>
> >>>>>     _______________________________________________
> >>>>>     tram mailing list
> >>>>>     [e-mail] <mailto:[e-mail]>
> >>>>>     https://www.ietf.org/mailman/listinfo/tram
> >>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
> >>>>
> >>
> 3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4j
> >>>> pN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> >> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
> >>>>
> >>
> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086
> >>>> nBuC6-cz9H7GKY_0EV8s&e=>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Brandon Williams; Chief Architect
> >>>> Cloud Networking; Akamai Technologies Inc.
> >>
> >> --
> >> Brandon Williams; Chief Architect
> >> Cloud Networking; Akamai Technologies Inc.
> 
> --
> Brandon Williams; Chief Architect
> Cloud Networking; Akamai Technologies Inc.