Re: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery

[Brandon Williams <[e-mail]>]

+1

On 12/06/2016 11:17 PM, Tirumaleswar Reddy (tireddy) wrote:
> Karl Wrote:  Also, you said you were NOT interested in mandating D(TLS)
> for validation, which was the text thrown during  the discuss, and the
> only thing I have suggested to be removed.
>
>
>
> [Tiru]
>
> I can fix the following text to avoid the confusion that (D)TLS is
> mandatory but validating the TURN server identity is not mandatory:
>
>
>
> OLD:
>
> 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].
>
>
>
> NEW:
>
> 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
>
>
>
> *From:* Karl Stahl [mailto:[e-mail]]
> *Sent:* Wednesday, December 7, 2016 7:35 AM
> *To:* Tirumaleswar Reddy (tireddy) <[e-mail]>; 'tram mailing
> list' <[e-mail]>; 'Brandon Williams' <[e-mail]>
> *Cc:* Prashanth Patil (praspati) <[e-mail]>;
> [e-mail]; 'Dan Wing' <[e-mail]>; 'Spencer Dawkins at
> IETF' <[e-mail]>
> *Subject:* SV: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Tiru,
>
>
>
> Isn’t all of that in the draft since version -7 and no one has suggested
> to remove it:
>
> 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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=6aJ1JWFxE2YgbNJfXZnnIngnYbMdeK80XioPfnUwks4&e=>
> for more details.”
>
>
>
> “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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7435&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=o-ahnzvSKRMEYO1xIUtpMh0QBXqHdM5jncX_6SLG31k&e=>]
> 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.”
>
>
>
> Also, you said you were NOT interested in mandating D(TLS) for
> validation, which was the text thrown during  the discuss, and the only
> thing I have suggested to be removed.
>
>
>
> In addition to “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.” as compensation for the
> authentication downgrade from MUST, which also no one has suggested to
> be removed, I suggested that this sentence thrown in during the discuss,
> is removed:
>
>    “A TURN client MUST use (D)TLS in the absence of STUN long-term
>
>    credential mechanism [RFC5389
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5389&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=F4YughE0J_rmP7Ulo5T9IJB4Fu3W-JNMyoheE6iyek8&e=>]
> or STUN Extension for Third-Party
>
>    Authorization [RFC7635
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7635&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=MIL4juxvOv918XY6KGHPmqDeE7OJsySEhai5dbBIXMo&e=>].”
>
> And  this yellow (that Brandon wanted, but you were not interested in
> the validation) is still there in all versions from -7 to suggested -11.
>
>   “It is RECOMMENDED that the TURN client use
>
>    one of the following techniques with (D)TLS to validate the TURN
>
>    server:
>
>
>
>
>
> So I think we can keep the *(D)TLS consensus* that has been there since
> version -7 and remains in my suggested -11.
>
>
>
> /Karl
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> *Skickat:* den 6 december 2016 06:59
> *Till:* Karl Stahl; 'tram mailing list'; 'Brandon Williams'
> *Kopia:* Prashanth Patil (praspati); [e-mail]
> <mailto:[e-mail]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
> *Ämne:* RE: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Karl,
>
>
>
> Inside attacks are possible in local networks (e.g. Enterprise network).
>
>
>
> I will elaborate one of the attacks:
>
>
>
> a)Inside attacker passively monitors the TURN messages b/w the TURN
> client and TURN server, and learns the nonce value conveyed by the TURN
> server in Allocate response.
>
>
>
> b)Inside attacker spoofs a TURN request to the TURN server to close the
> allocation (lifetime set to zero). Attacker spoofs the source IP address
> of the TURN client and uses the nonce learned previously.
>
>
>
> c)TURN server checks if the nonce value is valid and successfully closes
> the allocation
>
>
>
> With opportunistic encryption, attacker will not see the nonce value
> sent by the TURN server to the TURN client and cannot close the allocation.
>
>
>
> -Tiru
>
>
>
> *From:* Karl Stahl [mailto:[e-mail]]
> *Sent:* Monday, December 5, 2016 9:44 PM
> *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
> <mailto:[e-mail]>>; 'tram mailing list' <[e-mail]
> <mailto:[e-mail]>>; 'Brandon Williams' <[e-mail]
> <mailto:[e-mail]>>
> *Cc:* 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:* SV: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Tiru,
>
>
>
> See previous:
>
> I think all you bring up, since version -7 of this draft, is already
> discussed in 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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=6aJ1JWFxE2YgbNJfXZnnIngnYbMdeK80XioPfnUwks4&e=>
> for more details.”
>
>
>
> /Karl
>
>
>
> PS: Yet some comments below
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> *Skickat:* den 4 december 2016 07:09
> *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
>
>
>
> No, Mandating (D)TLS does not mean forbidding TURN server usage in local
> (Enterprise) and access networks.
>
> --- See previous
>
> Opportunistic encryption protects the TURN client from the attacks I had
> discussed in the previous mail, attacker cannot see the TURN messages
> exchanged b/w the TURN client and TURN server,
>
> --- On local networks, you are among friends (or much worse than TURN
> server spoof attacks may happen)
>
> --- On access networks you are hopefully in cafe mode, not being in
> contact with the other users (seeing their TURN messages)
>
> and cannot spoof TURN messages.
>
> --- encryption does not hide source or destination ip addresses as far
> as I understand
>
> /Karl
>
> -Tiru
>
>
>
> *From:* Karl Stahl [mailto:[e-mail]]
> *Sent:* Friday, December 2, 2016 2:08 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,
>
>
>
> 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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=ZZ-_SMjOP8Ki9gZ6wzPjBywDoWtHtOREkDxWQHt0hA4&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=-mVAbbScCntQIQqG27WQgiJYDUnDrwrv3TooeaeW9WQ&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…
>
>
>
> 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..)
>
>
>
> cid:[e-mail]3EFEC0
>
>
>
> 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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=RoQksDYwTif8WcC7pu9mSw93lTpGv0PpvAVrBJmOqBE&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=HlFe94mDcpEMQcstYO_MnhU7YzYVgNNLj_zA6fKbQsw&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=MDJEF8Fm0L5d86VeSQoKznG8WMvrLGyL37ZlVoK7RbE&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=ZZ-_SMjOP8Ki9gZ6wzPjBywDoWtHtOREkDxWQHt0hA4&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=UQ8nxZHjChRSQF3sc2tbr82Vo2rwqxib6C1flqSTj0M&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=bEWAC26Xp-ZCCpWasI9Az-CSOA7wvnm9eja0udVuZrk&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=TR1caTM9QwgFaASc71-diTPehw0IpmP3MWC-Kv3ECEA&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=1K6T0yYhF7wHe5ZWa8i_FgptKRnKJPCrjulsFhA7ZiU&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=rAmhwLM0wIIegwZIGibns7sX1UArUnQPAKVg1lac1IM&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=n5wv4T-Romjuscl7TckqrB8HlLTNQQT2hhkbVLdC0nw&e=>l
>
>> > >>> and https://www.ietf.org/mail-
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2D&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=ngvMj_FO-lqDILKiWc_vhnRwu9uGvez69CcN3WT7tZk&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=RYHSesfqj7o8Z-N2Cf-bzialwIHWlsyrSz0xRmHzY4c&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=KHA3cB1EXSI0iHSKZJ2M35wFeNJlswYbPCeUR0bsAA8&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=_tS_buEDXuCbIC40GFNswK2X9uWoL1Whf5szrHEJDO4&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=O11Dc68fLCzyFKwE5uk4gGITttt8x4swXSiI2Rq1t-I&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=Z3119bHFcte36WxImltxLO6FN_1UkgzYWpoPYZDVzt4&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=DVGS9E_SiopOIRk_em6JrGzQfeEIFTKDaFuOyMBN88Y&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=m-0KDgh3LnSwNkYBXRZEvmD-6KbIBecTW_LVyOtpxKw&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=m-0KDgh3LnSwNkYBXRZEvmD-6KbIBecTW_LVyOtpxKw&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=m-0KDgh3LnSwNkYBXRZEvmD-6KbIBecTW_LVyOtpxKw&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=m-0KDgh3LnSwNkYBXRZEvmD-6KbIBecTW_LVyOtpxKw&e=>
>

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