Subject: [tram] turn-server-discovery and return

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 8 Feb 2016 12:01:17 +0000

In the latest update of the discovery draft (https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-06#section-7.2) the following text was added.

>7.2.  Recursively Encapsulated TURN
>
>   A TURN client could attempt to discover multiple TURN servers so as
>   to use recursively encapsulated TURN, as described in
>   [I-D.ietf-rtcweb-return], to route traffic through multiple TURN
>   servers for privacy.

I don't think this is correct as the discovery mechanisms described in the draft will not be used to discover multiple TURN servers. In the -rtcweb-return- case the discovery mechanisms is used to discover the return proxy and the application will provide the application specific TURN server. 
I suggest the following text for this section:

"The TURN server discovery may result in the discovery of an enterprise/local TURN server being discovered and therefore in the case where a WebRTC application also provides a TURN server the use of Recursively Encapsulated TURN, as described in [I-D.ietf-rtcweb-return]."  

Regards
Andy

---

From: Benjamin Schwartz <[email-masked]>
Date: Mon, 8 Feb 2016 11:09:49 -0500

I think _all_ TURN servers identified by autodiscovery are
enterprise/local, by definition.

How about
"WebRTC endpoints SHOULD treat any TURN server discovered through this
process as an enterprise/gateway server, in accordance with Recursively
Encapsulated TURN [I-D.ietf-rtcweb-return]."

On Mon, Feb 8, 2016 at 7:01 AM, Hutton, Andrew <[email-masked]>
wrote:

> In the latest update of the discovery draft (
> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-06#section-7.2)
> the following text was added.
>
>
> I don't think this is correct as the discovery mechanisms described in the
> draft will not be used to discover multiple TURN servers. In the
> -rtcweb-return- case the discovery mechanisms is used to discover the
> return proxy and the application will provide the application specific TURN
> server.
> "The TURN server discovery may result in the discovery of an
> enterprise/local TURN server being discovered and therefore in the case
> where a WebRTC application also provides a TURN server the use of
> Recursively Encapsulated TURN, as described in [I-D.ietf-rtcweb-return]."
>
>
> Regards
> Andy
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 8 Feb 2016 16:32:47 +0000

Works for me.

Andy

From: Benjamin Schwartz [mailto:[email-masked]]
Sent: 08 February 2016 16:10
To: Hutton, Andrew
Cc: Prashanth Patil (praspati); [email-masked]
Subject: Re: [tram] turn-server-discovery and return

I think _all_ TURN servers identified by autodiscovery are enterprise/local, by definition.

How about
"WebRTC endpoints SHOULD treat any TURN server discovered through this process as an enterprise/gateway server, in accordance with Recursively Encapsulated TURN [I-D.ietf-rtcweb-return]."

On Mon, Feb 8, 2016 at 7:01 AM, Hutton, Andrew <[email-masked]<mailto:[email-masked]>> wrote:
In the latest update of the discovery draft (https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-06#section-7.2) the following text was added.

Regards
Andy

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 8 Feb 2016 16:49:56 +0000

Yup, will update draft.

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Monday, February 08, 2016 10:03 PM
To: Benjamin Schwartz
Cc: Prashanth Patil (praspati); [email-masked]
Subject: Re: [tram] turn-server-discovery and return

Works for me.

Andy

How about

Regards
Andy

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 10 Feb 2016 10:34:46 +0100

I am also positive to the update below.

Further, 

6.  Discovery using Anycast needs improvement. 

It has two flaws that easily can be remedied: 

Current method : 

“When a client requires TURN services, it sends a TURN allocate request to the assigned anycast address.  The TURN anycast server responds with a 300 (Try Alternate) error as described in [RFC5766];  The response contains the TURN unicast address in the ALTERNATE-SERVER attribute.  For subsequent communication with the TURN server, the client uses the responding server's unicast address.”

Flaw 1: Turn servers do not respond differently (Try alternate or OK) dependent on how they are addressed (by an anycast address or by a unicast address), do they?

Flaw 2: As already pointed out under  9.  Security Considerations, 9.3.  Anycast

“In a network without any TURN server that is aware of the TURN anycast address, outgoing TURN requests could leak out onto the external Internet, possibly revealing information. (I would also add that a far away bad TURN server might be used)... Sensitive clients that do not wish to leak information about their presence can set an IP TTL on their TURN requests that limits how far they can travel into the public Internet.”

It would be better, not to have to rely on the TTL limitation.

Considering that a TURN server also includes a STUN server (when using the binding request) and that the STUN server also can respond with 300 Try alternate, I suggest the following modified method:

“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.”

Or simply, a STUN server pointing out it’s own IP address as the alternate server, means that server it is a network provided TURN server that should be used.

Flaw 1 does not occur.

Flaw 2 is completely avoided if  the client only tries this method when the enterprise/ISP enforces a sealed configuration (according to [I-D.ietf-rtcweb-return]) by stopping STUN packets in the router/firewall/default gateway by detecting the STUN cookie.

In [I-D.ietf-rtcweb-return], the WebRTC endpoint could then maintain its default leaky behavior, but be signaled by the local TURN server deployment (stopping STUN packets) to behave sealed, and only in such case try the (modified) anycast method for TURN discovery. Thus, TURN requests will never leak out of the local network.

We have verified that common rule based firewalls (at least Linux netfilter/IPtables based) can be configured to route the anycast STUN packet, while still stopping other packets containing the STUN cookie. 

Considering that the anycast method works on all network types, and it allows the TURN server network deployment to automatically signal sealed behavior to a leaky WebRTC endpoint (by stopping STUN packets),  this should be the preferred discovery method for WebRTC endpoints. A web application that wish to bypass usage of the network provided TURN server, can propose a DTLS-encrypted STUN address (which will not be stopped since the STUN cookie will not be detected).

/Karl

Från: tram [ <mailto:[email-masked]> mailto:[email-masked]] För Tirumaleswar Reddy (tireddy)
Skickat: den 8 februari 2016 17:50
Till: Hutton, Andrew; Benjamin Schwartz
Kopia: Prashanth Patil (praspati); [email-masked]
Ämne: Re: [tram] turn-server-discovery and return

Yup, will update draft.

-Tiru

Works for me.

Andy

How about

On Mon, Feb 8, 2016 at 7:01 AM, Hutton, Andrew <[email-masked]> wrote:

Regards
Andy

---

From: Brandon Williams <[email-masked]>
Date: Wed, 10 Feb 2016 11:43:53 -0500

Hi Karl,

I don't think I agree with your "Flaw 1" and the associated proposed 
change. Maybe I'm just not understanding your point.

There is no reason why a TURN server can't check the destination address 
for the connection/packet when it arrives and take different action 
based on that. Also, most STUN binding messages will be unauthenticated, 
so an on-path attacker could easily redirect the client to an untrusted 
relay. On the other hand, using the TURN allocation for redirect 
purposes allows the TURN server to send the Try Alternate error in an 
authenticated response. I think it's better for the client to establish 
trust before being redirected, and requiring the client/server to use 
auth for STUN binding requests would be a bigger change than requiring a 
TURN server with anycast to check the destination address.

Regarding your "flaw 2", I agree that that TTL should not be relied on 
as a security mechanism. There is no reasonable way for the client to 
determine an acceptable TTL to use for its current environment. That 
said, I also don't think it's reasonable to expect the client to know 
that the ISP has a sealed network configuration or to trust that the ISP 
has correctly implemented its sealed config. I also don't think it can 
trust the relay to tell it if the relay itself isn't already trusted, in 
which case the concern doesn't apply anyway.

--Brandon

On 02/10/2016 04:34 AM, Karl Stahl wrote:
> “When a client requires TURN services, it sends a TURN allocate request
> to the assigned anycast address.  The TURN anycast server responds with
> a 300 (Try Alternate) error as described in [RFC5766];  The response
> contains the TURN unicast address in the ALTERNATE-SERVER attribute.
> For subsequent communication with the TURN server, the client uses the
> responding server's unicast address.”
>
> Flaw 1: Turn servers do not respond differently (Try alternate or OK)
> dependent on how they are addressed (by an anycast address or by a
> unicast address), do they?
>
> “In a network without any TURN server that is aware of the TURN anycast
> address, outgoing TURN requests could leak out onto the external
> Internet, possibly revealing information. (I would also add that a far
> away bad TURN server might be used)... Sensitive clients that do not
> wish to leak information about their presence can set an IP TTL on their
> TURN requests that limits how far they can travel into the public Internet.”
>
> Considering that a TURN server also includes a STUN server (when using
> the binding request) and that the STUN server also can respond with 300
> Try alternate, I suggest the following modified method:
>
> “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.”
>
> Or simply, a STUN server pointing out it’s own IP address as the
> alternate server, means that server it is a network provided TURN server
> that should be used.
>
> Flaw 1 does not occur.
>
> Flaw 2 is completely avoided if  the client only tries this method when
> the enterprise/ISP enforces a sealed configuration (according to
> [I-D.ietf-rtcweb-return]) by stopping STUN packets in the
> router/firewall/default gateway by detecting the STUN cookie.
>
> In [I-D.ietf-rtcweb-return], the WebRTC endpoint could then maintain its
> default leaky behavior, but be signaled by the local TURN server
> deployment (stopping STUN packets) to behave sealed, and only in such
> case try the (modified) anycast method for TURN discovery. Thus, TURN
> requests will never leak out of the local network.
>
> We have verified that common rule based firewalls (at least Linux
> netfilter/IPtables based) can be configured to route the anycast STUN
> packet, while still stopping other packets containing the STUN cookie.
>
> Considering that the anycast method works on all network types, and it
> allows the TURN server network deployment to automatically signal sealed
> behavior to a leaky WebRTC endpoint (by stopping STUN packets),  this
> should be the preferred discovery method for WebRTC endpoints. A web
> application that wish to bypass usage of the network provided TURN
> server, can propose a DTLS-encrypted STUN address (which will not be
> stopped since the STUN cookie will not be detected).
>
> /Karl
>
> *Från:*tram [mailto:[email-masked]] *För *Tirumaleswar Reddy
> (tireddy)
> *Skickat:* den 8 februari 2016 17:50
> *Till:* Hutton, Andrew; Benjamin Schwartz
> *Kopia:* Prashanth Patil (praspati); [email-masked] <mailto:[email-masked]>
> *Ämne:* Re: [tram] turn-server-discovery and return
>
> Yup, will update draft.
>
> -Tiru
>
> *From:*tram [mailto:[email-masked]] *On Behalf Of *Hutton, Andrew
> *Sent:* Monday, February 08, 2016 10:03 PM
> *To:* Benjamin Schwartz
> *Cc:* Prashanth Patil (praspati); [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [tram] turn-server-discovery and return
>
> Works for me.
>
> Andy
>
> *From:*Benjamin Schwartz [mailto:[email-masked]]
> *Sent:* 08 February 2016 16:10
> *To:* Hutton, Andrew
> *Cc:* Prashanth Patil (praspati); [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [tram] turn-server-discovery and return
>
> In the latest update of the discovery draft
> (https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-06#section-7.2
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D06-23section-2D7.2&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=aE1HJYzmrPJyAVYgX-2Or-R6ZgrmBpeOZwf5h3I1z3U&s=cHnQcFQoFVxObJ2b-bAUJ1GaoQi_HmjU1kfjT97qLRk&e=>)
> I don't think this is correct as the discovery mechanisms described in
> the draft will not be used to discover multiple TURN servers. In the
> return proxy and the application will provide the application specific
> TURN server.
> [email-masked] <mailto:[email-masked]>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=aE1HJYzmrPJyAVYgX-2Or-R6ZgrmBpeOZwf5h3I1z3U&s=pYowzt90bQR3ruGnbzI21HRwXyslfnr6j0LzRts3Uzs&e=>
>
>
>

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 11 Feb 2016 13:52:43 +0100

Hi Brandon,

You are bringing up a use case of a “better authenticated TURN server 

network” that we may hope is possible to implement in addition to 

what we first of all need achieve “being able to use good WebRTC 

everywhere we can surf” (which I thought was the purpose of this 

DISCOVERY draft and of the RETURN draft). 

If your use case also needs auto discovery, can’t it use the same, 

most optimal discovery method for the TURN server, and thereafter 

do whatever authentication method(s) you want and need? 

I actually think it can.

Short questions (after you read the inline below): Does my suggested 

modified anycast method in any way disturb the use case you have in mind?

Aren’t removal of “Flaw 1” (or whatever we chose to call it) and Flaw 2, 

also positive to your use case?

Or at least, it does not make things worse for you, does it?

(If it does make things worse, I believe both anycast methods could live 

in parallel and use the same IANA TURN server discovery address. 

In the end – both anycast methods only address the network provided TURN 

server with its unicast address and the 300 Try Alternate could come 

both from the binding and allocate request.)

Would it really help to keep both methods (for your use case and the 

general use case)? 

I hope we can focus and get this draft approved with at least one 

reasonably useful and widely and easily deployable and safe/secure enough 

DISCOVERY method. And it would be helpful if we now also can get that 

IANA allocated TURN server anycast address, so we can use/try the simple 

anycast method IRL.

/Karl 

-----Ursprungligt meddelande-----
Från: Brandon Williams [mailto:[email-masked]] 
Skickat: den 10 februari 2016 17:44
Till: Karl Stahl; 'Tirumaleswar Reddy (tireddy)'; 'Hutton, Andrew';
'Benjamin Schwartz'
Kopia: 'Prashanth Patil (praspati)'; [email-masked]
Ämne: Re: [tram] turn-server-discovery and return

Hi Karl,

based on that. 

--- Of course such behavior can be specified and implemented, but isn’t 

it better if we don’t have to take such efforts?

Also, most STUN binding messages will be unauthenticated, 

authenticated response. 

--- But there is nothing stopping “to send the Try Alternate error in an 

Authenticated” binding response, is there? 

to establish 

--- isn’t that already in the standards (binding is not excluded from 

auth is it)?

that the ISP has a sealed network configuration 

--- The big advantage with the suggested usage is, that while a 

WebRTC browser by default assumes a leaky configuration (see the 

RETURN draft), the suggested deployment by blocking STUN packets 

through the default gateway, signals to the browser: “Please look 

for a network provided TURN server paralleling the firewall here” 

(In this way we get a good way for the network provider to enforce

sealed usage here instead of leaky AND the huge benefit that local 

call media does not have to go twice around in the TURN server, which 

otherwise will happen if a sealed configuration is enforced generally 

from the WebRTC browser side. See the RETURN draft.) 

or to trust that the ISP 

--- We have to start with that we have a certain trust level from the 

network provider we choose to use – the same for both data and 

real-time traffic, good or bad. Thereafter, you can add your authentication
stuff 

for your “better TURN server network” for your use case – I don’t see

that the modified anycast method do other than positive things also 

for your use case. (And we need the improvements for the general

WebRTC browser use case – where your type of authentication will not 

be used.) 

--Brandon

> Flaw 2: As already pointed out under 9.  Security Considerations, 9.3.

> Anycast

> *Från:*tram [ <mailto:[email-masked]> mailto:[email-masked]]
*För *Tirumaleswar Reddy

> *Kopia:* Prashanth Patil (praspati);  <mailto:[email-masked]> [email-masked]
< <mailto:[email-masked]> mailto:[email-masked]>

> *From:*tram [ <mailto:[email-masked]> mailto:[email-masked]]
*On Behalf Of *Hutton, Andrew

> *Cc:* Prashanth Patil (praspati);  <mailto:[email-masked]> [email-masked] <
<mailto:[email-masked]> mailto:[email-masked]>

> *From:*Benjamin Schwartz [ <mailto:[email-masked]>
mailto:[email-masked]]

> *Cc:* Prashanth Patil (praspati);  <mailto:[email-masked]> [email-masked] <
<mailto:[email-masked]> mailto:[email-masked]>

> On Mon, Feb 8, 2016 at 7:01 AM, Hutton, Andrew <[email-masked]

> < <mailto:[email-masked]> mailto:[email-masked]>> wrote:

> (
<https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-06#sectio
n-7.2>
https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-06#section
-7.2

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_dr
aft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D06-23section-2D7.2&d=CwMFaQ&
c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=aE1
HJYzmrPJyAVYgX-2Or-R6ZgrmBpeOZwf5h3I1z3U&s=cHnQcFQoFVxObJ2b-bAUJ1GaoQi_HmjU1
kfjT97qLRk&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_dra
ft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D06-23section-2D7.2&d=CwMFaQ&c
=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=aE1H
JYzmrPJyAVYgX-2Or-R6ZgrmBpeOZwf5h3I1z3U&s=cHnQcFQoFVxObJ2b-bAUJ1GaoQi_HmjU1k
fjT97qLRk&e=>)

>  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]>
mailto:[email-masked]>

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

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_l
istinfo_tram&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgw
bBVUJa4mZfmEIBXg&m=aE1HJYzmrPJyAVYgX-2Or-R6ZgrmBpeOZwf5h3I1z3U&s=pYowzt90bQR
3ruGnbzI21HRwXyslfnr6j0LzRts3Uzs&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_li
stinfo_tram&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwb
BVUJa4mZfmEIBXg&m=aE1HJYzmrPJyAVYgX-2Or-R6ZgrmBpeOZwf5h3I1z3U&s=pYowzt90bQR3
ruGnbzI21HRwXyslfnr6j0LzRts3Uzs&e=>

>  <mailto:[email-masked]> [email-masked]

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

---

From: Brandon Williams <[email-masked]>
Date: Thu, 11 Feb 2016 15:08:21 -0500

Hi Karl,

I'm a bit confused by your response. I don't think I'm describing a use 
case for a "better authenticated TURN server". I'm describing how 
authentication works today if you follow the recommendations from the 
STUN and TURN RFCs.

The STUN RFC says that Binding requests SHOULD NOT use authentication 
and SHOULD NOT return alternate-server. You are suggesting either 
changing these recommendations or just ignoring the security risk 
associated with accepting an unauthenticated TryAlternate error. My 
suggestion is that we stick as close to the existing specifications as 
possible, not that we create some new authentication model. I think the 
current text sticks closer to the existing specifications than your 
proposal does.

I do think that the idea of having a method for the client to determine 
whether it's in a sealed config could be a good idea to allow it to 
figure out whether it should look for a return server. I'm not sure we 
necessarily want to require sealed config before falling back to an 
auto-discovered relay, though. I'm also not sure whether it's good 
enough just to look at whether your STUN requests are getting dropped, 
since you can't know where they're being dropped. Someone who is in a 
position to hijack the anycast address may well be in a position to drop 
your requests and force you to try the anycast address.

I think I've hit your high level questions here and in my inline 
responses below (look for "[bw]").

--Brandon

> do whatever authentication method(s) you want and need?

[bw] My use case cannot use the method you describe because (1) I don't 
consider it reasonable to add authentication to binding requests because 
it will add delay to reflexive address discovery and (2) I also don't 
think it's reasonable to ask the client to accept an unauthenticated 
TryAlternate error response (especially not if it contains an 
ALTERNATE-DOMAIN attribute).

> modified anycast method in any way disturb the use case you have in mind?

[bw] See above. I can't use the method you describe. As long as that's 
not the only documented method and neither method is required, then I 
think it meets both of our needs. I'm not usually supportive of specs 
providing multiple ways to handle something and not requiring either, 
though, because it adds significant interop risk. That's why my 
preference is to stick as close to what we already have as we can.

> Would it really help to keep both methods (for your use case and the

[bw] See above. IMO, "my" use case _is_ the "general" use case. I don't 
think we need to change the basics of STUN and TURN in order to get what 
we need for redirect, and I think sticking as close to the existing 
specs as possible is the best way to end up with something that is 
widely/easily deployable.

> Kopia: 'Prashanth Patil (praspati)'; [email-masked] <mailto:[email-masked]>
> real-time traffic, good or bad. Thereafter, you can add your
> authentication stuff
>
>  > *Kopia:* Prashanth Patil (praspati); [email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]>
>
>  > *Cc:* Prashanth Patil (praspati); [email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]>
>
>  > *Cc:* Prashanth Patil (praspati); [email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]>
>
>  > <mailto:[email-masked]>> wrote:
>
>  >
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D06-23section-2D7.2&d=CwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=oXMPx_JT_PJo88F8clbE07s7CW9Cvq5R3rq3gEGb2rs&s=53_OkXg-LGL4Ft-1o4Cy1o0KcZ7dMcPpD-Wn76vW-EQ&e=>
>
>  >
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=CwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=oXMPx_JT_PJo88F8clbE07s7CW9Cvq5R3rq3gEGb2rs&s=v3ob4BUh4Ghu7rH01aRttE22J_JkMBLcKVKe3MpAr7s&e=>
>
>  >
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=CwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=oXMPx_JT_PJo88F8clbE07s7CW9Cvq5R3rq3gEGb2rs&s=v3ob4BUh4Ghu7rH01aRttE22J_JkMBLcKVKe3MpAr7s&e=>
>
>  >
>

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.