From nobody Mon Aug 3 04:25:35 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D601A8703 for ; Mon, 3 Aug 2015 04:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMgm6944_6P6 for ; Mon, 3 Aug 2015 04:25:30 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812831A8029 for ; Mon, 3 Aug 2015 04:25:28 -0700 (PDT) Received: from Kallei7 ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201508031325269728; Mon, 03 Aug 2015 13:25:26 +0200 From: "Karl Stahl" To: "'Bernard Aboba'" , "'Benjamin Schwartz'" , "'Tirumaleswar Reddy \(tireddy\)'" , "'Prashanth Patil \(praspati\)'" , References: In-Reply-To: Date: Mon, 3 Aug 2015 13:25:23 +0200 Message-ID: <0a8401d0cddf$171e57d0$455b0770$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A85_01D0CDEF.DAA727D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdDK9rkax3KdrsiJSNiapO8P3iLZWACxp9oQ Content-Language: sv Archived-At: Subject: Re: [tram] Review of draft-ietf-tram-turn-server-discovery-04 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 11:25:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0A85_01D0CDEF.DAA727D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable BA > =E2=80=9D=E2=80=A6 this document it was not clear to me how it was = intended=E2=80=9D =20 I agree and have made comments (that were not considered in the -04 = version since it came in parallel) at: http://www.ietf.org/mail-archive/web/rtcweb/current/msg14927.html=20 one thing being that the RETURN draft should be referenced. =20 In draft-ietf-rtcweb-return-00.txt the browser usage of a network = provided TURN server is made clear and that it effectively parallels the = default gateway path (that is to be avoided for real-time traffic when = blocking or don=E2=80=99t give quality). And I stated: We need this = draft implemented in WebRTC browsers as soon as possible, so we can get = good WebRTC in difficult places (for firewall traversal and for = quality). =20 I also commented on this thread, http://www.ietf.org/mail-archive/web/tram/current/msg01742.html=20 ending up in the following summary: =20 ... the anycast route to the server should only be available to the = inside (local, LAN side) of the default gateway (that a network provided = turn server parallels to get a good path for real-time traffic) =20 ...there seem to be a misunderstanding of why we need discovery of a = network provided turn server The very purpose of discovery is to find the turn server offered to = users of the particular network segment that it servs. =20 Simply put, that Cisco turn server should not authenticate Allocate = request from inside users. No credentials needed! =20 ... A network provided turn server has the same trust level as the = default gateway it is paralleling, so no problem is introduced.=20 =20 I think clarification of the above must go into the discovery-draft. In addition, the following should be added in relation to = =E2=80=9Cconfiguration=E2=80=9D and = =E2=80=9Ccredentials/authentication=E2=80=9D : =20 For use cases where manual configuration is wanted and possible, maybe = at an enterprise LAN, and for example where not all users should be = allowed to use the TURN server, the TURN server must be configured to = authenticate the users, and credentials then provided to the users. = However, for such (unusual) use cases, it is probably easier to also = provide the IP address of the TURN server, so discovery according to = this document will not be used. =20 =20 Regarding the DNS discovery methods outlined (and much discussed), it = must be made clear, that they only shall be deployed in local DNS, only = made available to the users that the TURN server is intended to serve = and made available for. For a WebRTC browser, I think the Anycast, and = possible the DHCP based methods are sufficient to use (thus not using = any of the DNS methods).=20 =20 Regarding Section 9.3 =20 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. =20 [BA] This seems like a crude tool at best=E2=80=A6.=20 =20 We shall notice that the TTL limitation is for the following purpose = (anycast in itself of course only routes to the deployed turn server): From: http://www.ietf.org/mail-archive/web/tram/current/msg01742.html=20 =20 Is the concern instead that, from a network segments NOT having a = properly configured and advertised network provided turn server, the = very discovery process of sending an Allocate request to the anycast = address, may reveal things to the outside or that a far away turn server = (not paralleling any of the default gateways that has to be passed) will = be used? =20 If so, the discovery draft under 9. Security Considerations, 9.3 Anycast = Suggests "...set an IP TTL on their TURN requests that limits how far = they can travel..." =20 Maybe this TTL setting can be guided by a trace route before, so that = the TURN requests intended for a network provided turn server never = reaches the public internet. =20 Is there such improvement of the anycast discovery process to be made? =20 /Karl =20 =20 Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Bernard Aboba Skickat: den 30 juli 2015 20:36 Till: Benjamin Schwartz Kopia: tram@ietf.org =C3=84mne: Re: [tram] Review of draft-ietf-tram-turn-server-discovery-04 =20 Benjamin said:=20 "In WebRTC scenarios, RETURN specifies the correct handling of = autodiscovered TURN servers. " =20 [BA] It seems like RETURN could be relevant beyond Web-based scenarios = (e.g. use in a mobile application). But the draft doesn't mention = RETURN at all. =20 =20 On Thu, Jul 30, 2015 at 11:31 AM, Benjamin Schwartz = wrote: On Thu, Jul 30, 2015 at 2:23 PM, Bernard Aboba = wrote: 1. Overall, in reading this document it was not clear to me how it was = intended to be applied to WebRTC scenarios where a TURN server is configured in = the JS.=20 =20 * Does TURN server discovery apply in this case, or is the JS-specified = TURN server considered "manual TURN configuration" ? =20 In WebRTC scenarios, RETURN specifies the correct handling of = autodiscovered TURN servers. The conclusion, roughly, is that = JS-specified TURN servers and autodiscovered TURN servers are configured = independently, and under various conditions the client may use both = simultaneously, neither, or either one of the two. =20 I agree that the autodiscovery draft could be clearer about its = interaction with WebRTC. =20 =20 * Where IdP is used, is the local IdP identity considered to consitute a = "domain name" per Section 4.1.2? =20 =20 2. In scenarios where TURN Server discovery does apply, what mechanisms = are to be used to authenticate or authorize the discovered TURN = Servers(s)? Using a configured domain name seems like a potentially = viable approach, but there are scenarios where that might not be = configured, or might not be secure (e.g. if the domain name were obtained from unauthenticated DHCP). =20 =20 Using the browser's configured trust anchor(s) doesn't seem like a good = idea, given that it would only be as secure as the least-secure trust = anchor.=20 =20 Specific comments:=20 =20 Section 3 =20 1. Local Configuration : Local or manual TURN configuration (i.e., TURN servers configured at the system level) should be tried first, as it may be an explicit preferred choice of a user. =20 [BA] Would TURN servers specified within a WebRTC JS application be = considered "local or manual" in this context? Also, shouldn't a = configured domain name (Section 4.1.2) be considered part of "local TURN = configuration"?=20 =20 IMHO, the configured domain name not only enables discovery as indicated in Section 4.2, but also provides a mechanism for validation of the TURN server discovered by other methods. =20 =20 The document does not prescribe a strict order that a client must follow for discovery. An implementation may choose to perform steps 2,3 and 4 in parallel for discovery OR choose to follow any desired order and stop the discovery procedure if a mechanism succeeds. =20 [BA] I am not sure I buy this. It is already stated that "local or = manual" configuration should be tried first, and I would considered a = configured domain name to be part of this, which would imply attempting = 2 first if that exists. =20 =20 Section 9.2 =20 For mDNS, in addition to what has been described above, a principal security threat is a security threat inherent to IP multicast routing and any application that runs on it. A rogue system can advertise that it is a TURN server. Discovery of such rogue systems as TURN servers, in itself, is not a security threat if there is a means for the TURN client to authenticate and authorize the discovered TURN servers. =20 [BA] In scenarios in which mDNS would be used, there typically will not = be a means for the TURN client to authentication and authorize the discovered TURN server. For example, a home router with a built-in TURN server is not likely to have a certificate chaining to a trust anchor. Also, the mDNS is not compatible with DNSSEC (e.g. there is no signer for the = .local domain). =20 =20 Section 9.3 =20 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. =20 [BA] This seems like a crude tool at best. If the goal is to provide = privacy, wouldn't use of encryption make more sense? This could include DNS = privacy, encryption of TURN traffic, etc.=20 =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 ------=_NextPart_000_0A85_01D0CDEF.DAA727D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

BA= > =E2=80=9D=E2=80=A6 this document it was = not clear to me how it was intended=E2= =80=9D

 

I = agree and have made comments (that were not considered in the -04 = version since it came in parallel) at:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg14927.html =

on= e thing being that the RETURN draft should be = referenced.

 

In= draft-ietf-rtcweb-return-00.txt th= e browser usage of a network provided TURN server is made clear and that = it effectively parallels the default gateway path (that is to be avoided = for real-time traffic when blocking or don=E2=80=99t give quality). And = I stated: We need this draft implemented in = WebRTC browsers as soon as possible, so we can get good WebRTC in = difficult places (for firewall traversal and for quality).

 

I = also commented on this thread,

= http://www.ietf.org/mail-archive/web/tram/current/msg01742.html =

en= ding up in the following summary:

 

... the =
anycast route to the server should only be available to the inside =
(local, LAN side) of the default gateway (that a network provided turn =
server parallels to get a good path for real-time =
traffic)
 

...there seem to be a misunderstanding of why we need discovery of = a network provided turn server

The very purpose of = discovery is to find the turn server offered to users of the particular = network segment that it servs.

 

Simply = put, that Cisco turn server should not authenticate Allocate request = from inside users. No credentials needed!

 

... A network =
provided turn server has the same trust level as the default gateway it =
is paralleling, so no problem is introduced.

 

I = think clarification of the above must go into the = discovery-draft.

In= addition, the following should be added in relation to = =E2=80=9Cconfiguration=E2=80=9D and = =E2=80=9Ccredentials/authentication=E2=80=9D :

 

For use = cases where manual configuration is wanted and possible, maybe at an = enterprise LAN, and for example where not all users should be allowed to = use the TURN server, the TURN server must be configured to authenticate = the users, and credentials then provided to the users. However, for such = (unusual) use cases, it is probably easier to also provide the IP = address of the TURN server, so discovery according to this document will = not be used.

 

 

Re= garding the DNS discovery methods outlined (and much discussed), it must = be made clear, that they only shall be deployed in local DNS, only made = available to the users that the TURN server is intended to serve and = made available for. For a WebRTC browser, I think the Anycast, and = possible the DHCP based methods are sufficient to use (thus not using = any of the DNS methods).

 

Re= garding Section 9.3

 

   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.

 

[BA] This seems like a crude tool at = best=E2=80=A6. 

 

We= shall notice that the TTL limitation is for the following purpose = (anycast in itself of course only routes to the deployed turn = server):

Fr= om: =C2=A0= http://www.ietf.org/mail-archive/web/tram/current/msg01742.html =

 

Is the concern instead =
that, from a network segments NOT having a properly configured and =
advertised network provided turn server, the very discovery process of =
sending an Allocate request to the anycast address, may reveal things to =
the outside or that a far away turn server (not paralleling any of the =
default gateways that has to be passed) will be =
used?
 
If =
so, the discovery draft under 9. Security Considerations, 9.3 Anycast =

Suggests "...set an =
IP TTL on their TURN requests that limits how far they can =
travel..."
 
Maybe =
this TTL setting can be guided by a trace route before, so that the TURN =
requests intended for a network provided turn server never reaches the =
public internet.
 
Is there such improvement of the anycast discovery =
process to be made?
 
/Karl

 

 

Fr=C3=A5n: tram = [mailto:tram-bounces@ietf.org] F=C3=B6r Bernard = Aboba
Skickat: den 30 juli 2015 20:36
Till: Benjamin = Schwartz
Kopia: tram@ietf.org
=C3=84mne: Re: [tram] = Review of = draft-ietf-tram-turn-server-discovery-04

 

Benjamin said: 

"In WebRTC = scenarios, RETURN specifies the correct handling of autodiscovered TURN = servers.  "

 

[BA] It seems like RETURN could be relevant beyond = Web-based scenarios (e.g. use in a mobile application).  But the = draft doesn't mention RETURN at all. =  

 

On Thu, = Jul 30, 2015 at 11:31 AM, Benjamin Schwartz <bemasc@webrtc.org> = wrote:

On Thu, Jul 30, = 2015 at 2:23 PM, Bernard Aboba <bernard.aboba@gmail.com> = wrote:

1. Overall, in = reading this document it was not clear to me how it was = intended

to be applied to = WebRTC scenarios where a TURN server is configured in the = JS. 

 

* = Does TURN server discovery apply in this case, or is the JS-specified = TURN server considered "manual TURN configuration" = ?

 

In WebRTC scenarios, RETURN specifies the correct = handling of autodiscovered TURN servers.  The conclusion, roughly, = is that JS-specified TURN servers and autodiscovered TURN servers are = configured independently, and under various conditions the client may = use both simultaneously, neither, or either one of the = two.

 

I = agree that the autodiscovery draft could be clearer about its = interaction with WebRTC.

 

 

* = Where IdP is used, is the local IdP identity considered to consitute a = "domain name" per Section 4.1.2? =  

 

2. In scenarios where TURN Server discovery does = apply, what mechanisms are to be used to authenticate or authorize the = discovered TURN Servers(s)?  Using a configured domain name seems = like a potentially viable approach, but there are scenarios where that = might not be configured, or might not be = secure

(e.g. if the domain = name were obtained from unauthenticated DHCP). =  

 

Using the browser's configured trust anchor(s) doesn't = seem like a good idea, given that it would only be as secure as the = least-secure trust anchor. 

 

Specific comments: 

 

Section 3

 

   1.  Local Configuration : Local or = manual TURN configuration (i.e.,

       TURN servers configured at = the system level) should be tried

       first, as it may be an = explicit preferred choice of a user.

 

[BA] Would TURN servers specified within a WebRTC JS = application be considered "local or manual" in this = context?  Also, shouldn't a configured domain name (Section 4.1.2) = be considered part of "local TURN = configuration"? 

 

IMHO, the configured domain name not only enables = discovery as indicated

in = Section 4.2, but also provides a mechanism for validation of = the

TURN server discovered = by other methods.   

 

   The document does not prescribe a strict = order that a client must

   follow for discovery.  An = implementation may choose to perform steps

   2,3 and 4 in parallel for discovery OR = choose to follow any desired

   order and stop the discovery procedure if = a mechanism succeeds.

 

[BA] I am not sure I buy this.  It is already = stated that "local or manual" configuration should be tried = first, and I would considered a configured domain name to be part of = this, which would imply attempting 2 first if that exists. =   

 

Section 9.2

 

   For mDNS, in addition to what has been = described above, a principal

   security threat is a security threat = inherent to IP multicast routing

   and any application that runs on = it.  A rogue system can advertise

   that it is a TURN server.  Discovery = of such rogue systems as TURN

   servers, in itself, is not a security = threat if there is a means for

   the TURN client to authenticate and = authorize the discovered TURN

   servers.

 

[BA] In scenarios in which mDNS would be used, there = typically will not be a

means for the TURN client to authentication and = authorize the discovered

TURN server. For example, a home router with a = built-in TURN server is

not likely to have a certificate chaining to a trust = anchor.  Also, the

mDNS is not compatible with DNSSEC (e.g. there is no = signer for the .local

domain).  

 

Section 9.3

 

   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.

 

[BA] This seems like a crude tool at best.  If = the goal is to provide privacy,

wouldn't use of encryption make more sense?  This = could include DNS privacy,

encryption of TURN traffic, = etc. 

 

__________________________________________= _____
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

 

------=_NextPart_000_0A85_01D0CDEF.DAA727D0-- From nobody Wed Aug 5 10:47:07 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D461A8919; Wed, 5 Aug 2015 10:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCLo4TLjYZm6; Wed, 5 Aug 2015 10:47:00 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0483F1A88FE; Wed, 5 Aug 2015 10:46:59 -0700 (PDT) Received: from [192.168.1.202] (71-94-211-114.static.knwc.wa.charter.com [71.94.211.114]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t75Hl6Nh022690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 5 Aug 2015 19:47:08 +0200 Message-ID: <55C24C09.8020404@goodadvice.pages.de> Date: Wed, 05 Aug 2015 10:46:49 -0700 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> In-Reply-To: <55C24293.5000603@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tram@ietf.org Subject: [tram] TURN permissions for private ips (was: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT)) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 17:47:05 -0000 Am 05.08.2015 um 10:06 schrieb Stephen Farrell: [...] > Part of my question > then is why exposing that additional meta-data to a server > that most users won't know exists, and that is likely > controlled by some entity the user has no clue is even > involved in their calls, is acceptable. There is an issue with TURN here, but it's not related to the consent freshness draft. If a peer sends candidates with IP addresses from the private space, permissions for those are created at the TURN server. Potentially not utilising transport encryption even. I doubt those candidates ever work, so from a privacy point of view it seems that clients should not create those permissions in the first place. And ICE should probably not try to create pairs. From nobody Wed Aug 5 11:33:07 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAC81B343B for ; Wed, 5 Aug 2015 11:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8TnaRFfIH1J for ; Wed, 5 Aug 2015 11:33:03 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F021B3444 for ; Wed, 5 Aug 2015 11:32:44 -0700 (PDT) Received: by oip136 with SMTP id 136so24979292oip.1 for ; Wed, 05 Aug 2015 11:32:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FGLOFRbYUJFVEPMzJkGE1j04ATEC0umTkvsqKe+mBpk=; b=KwCULMDLtJ8UdWAc5tX0uar2GkczdjtHuwRJlPie1q7uEPIhubbC0VuhWVcEjHZwP1 pPwYMkP4VzKgBAZ03hSx2Oe37fWp9RC15+nHwi0hZVcj995ASlFR0IrBo+bOSAb1luDh fRrK2rbjnRR2LsLgy+rw8KzXN9LmZqj8VZB6Nxu5ToRgJnKkDk5GXeLGkQDpmR2Vpc19 5vf0Ir68YhOyEGQQG8aupQW7m5UkvAAgIirwqyhsiM9JajNgyCDUXFPrB5Zdfu0Bdcev 2/939IAl28pv5ROlAJgFmMuhrZcyC1dfynLm/HkI0/6qI+HybeRe/pR5467NXivWh1Ef 8xjg== X-Gm-Message-State: ALoCoQmMB7Kca3OEkYLvdEsxSinkBgYdELl9aaTwJySi9O4MxQhfklqwsGxrd5U1ghoByiVgEaWz X-Received: by 10.202.71.6 with SMTP id u6mr9008045oia.36.1438799563755; Wed, 05 Aug 2015 11:32:43 -0700 (PDT) Received: from Simons-MacBook-Air.local ([24.53.47.130]) by smtp.googlemail.com with ESMTPSA id l5sm2158006oey.5.2015.08.05.11.32.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 11:32:43 -0700 (PDT) Message-ID: <55C256C8.80606@jive.com> Date: Wed, 05 Aug 2015 14:32:40 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Philipp Hancke , rtcweb@ietf.org References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> In-Reply-To: <55C24C09.8020404@goodadvice.pages.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram@ietf.org Subject: Re: [tram] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 18:33:04 -0000 Le 2015-08-05 13:46, Philipp Hancke a écrit : > If a peer sends candidates with IP addresses from the private space, > permissions for those are created at the TURN server. Potentially not > utilising transport encryption even. > > I doubt those candidates ever work, so from a privacy point of view it > seems that clients should not create those permissions in the first > place. And ICE should probably not try to create pairs. It's not up to the client to determine what addresses might not might not work for a given TURN server. There are lots of weird NAT configurations out there that play games with RFC1918 addresses and can easily trick clients into doing the wrong thing. Instead, the server should be the one doing that check because it only has access to reliable information. It should use the existing mechanism and return 403 Forbidden for addresses it doesn't like. See RFC 5766 section "9.2. Receiving a CreatePermission Request": The server MAY impose restrictions on the IP address allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server rejects the request with a 403 (Forbidden) error. Simon From nobody Wed Aug 5 14:36:17 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748BA1AC3C5 for ; Wed, 5 Aug 2015 14:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H17Xi8PAzqsr for ; Wed, 5 Aug 2015 14:36:13 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444631AC3C1 for ; Wed, 5 Aug 2015 14:36:13 -0700 (PDT) Received: by vkhl6 with SMTP id l6so20674636vkh.1 for ; Wed, 05 Aug 2015 14:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=b5tC5lHKMcItaxMryofU/y98YlarzuGyw1wx4eR3Ppk=; b=IG0xlO1C1gygvT7H9baDQF9f3SrutAkmEQI9vcmnLjo11woQhHu+AcJoH14DUCnaMM eYJdaxWGlQHUkZRlFerGBUDezSNnUz2pQo6y340dS5zT9mQFTLOziQvYsq11E+H3DJGU 4YTcqklFTMaNVy9O0MAi/kscPdLB8ZUglXd/8j8GcoY94h5mb0yj0ac/89jwm9b89RoC eq3u2SVJ4/EF2mjytTR5A9S1D883tX4W/IsB4rfDLWRzqXhwvX9OlfvV38HfdiCdVMLk lIANbCcY0xtKVEoxDxszcj6eCV3haPs+NrM21d5BFdpd+zHuwhBNmfQrzMc77Zxqptuh A5kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=b5tC5lHKMcItaxMryofU/y98YlarzuGyw1wx4eR3Ppk=; b=aMABkLcjNCnWcC7jCWkJHlwjn0VNFfT25A3AjqkdyR3ZRriwPk8WIs1/NRGCwMFDeL Py1GaSaWg+3LXcBKiFV4VZTrHxi7JQVF1EIz/V7qKscZ5zXoEHM7np1ccTEACoE0mLUC O8kB2uWfOx9xGEH/Q6sCes6WMBry9jmVRBvcOlza8LcCFeFs8OXTd/cXgFK0Epu1vfZH HV3O95Icj9eYz9dx2C5ej2KnbacmC44h4UmC3lXSHDBp/l89W/t0yVCXzoDfD3Ba8tPA Er5Vwo85tpYW/ZSE6Kdsgxp9hIx8u9tTciOir7piLXyS+UdvioDvZy9vFezr9NpPaFgt 8UqQ== X-Gm-Message-State: ALoCoQkycgC5/zMfkvXOodCNp5gkncLrotAnoRjOnhfQo8Whf6dPeTnTQmm0MWp4OFOx65tey9QW X-Received: by 10.52.163.50 with SMTP id yf18mr15407103vdb.93.1438810572398; Wed, 05 Aug 2015 14:36:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.87 with HTTP; Wed, 5 Aug 2015 14:35:52 -0700 (PDT) In-Reply-To: <55C256C8.80606@jive.com> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: Justin Uberti Date: Wed, 5 Aug 2015 14:35:52 -0700 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c2ce381161c7051c97316c Archived-At: Cc: Philipp Hancke , "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 21:36:14 -0000 --001a11c2ce381161c7051c97316c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault wrote: > Le 2015-08-05 13:46, Philipp Hancke a =C3=A9crit : > > If a peer sends candidates with IP addresses from the private space, > > permissions for those are created at the TURN server. Potentially not > > utilising transport encryption even. > > > > I doubt those candidates ever work, so from a privacy point of view it > > seems that clients should not create those permissions in the first > > place. And ICE should probably not try to create pairs. > > It's not up to the client to determine what addresses might not might > not work for a given TURN server. There are lots of weird NAT > configurations out there that play games with RFC1918 addresses and can > easily trick clients into doing the wrong thing. > I am somewhat sympathetic to that, but given that there is measurable downside here - extra candidate pairs that take time to check - can you supply a concrete example of where the client choosing not to pair a TURN candidate with a RFC1918 address would cause a problem? --001a11c2ce381161c7051c97316c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault <= sperreault@jive.co= m> wrote:
Le 2015-08-05 13:= 46, Philipp Hancke a =C3=A9crit :
> If a peer sends candidates with IP addresses from the private space, > permissions for those are created at the TURN server. Potentially not<= br> > utilising transport encryption even.
>
> I doubt those candidates ever work, so from a privacy point of view it=
> seems that clients should not create those permissions in the first > place. And ICE should probably not try to create pairs.

It's not up to the client to determine what addresses might not might not work for a given TURN server. There are lots of weird NAT
configurations out there that play games with RFC1918 addresses and can
easily trick clients into doing the wrong thing.

<= /div>
I am somewhat sympathetic to that, but given that there is measur= able downside here - extra candidate pairs that take time to check - can yo= u supply a concrete example of where the client choosing not to pair a TURN= candidate with a RFC1918 address would cause a problem?
<= /div> --001a11c2ce381161c7051c97316c-- From nobody Wed Aug 5 15:01:14 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDF11ACD4C for ; Wed, 5 Aug 2015 15:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEmHffV56P1V for ; Wed, 5 Aug 2015 15:01:11 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CDF1A01E7 for ; Wed, 5 Aug 2015 15:01:11 -0700 (PDT) Received: by qgeg42 with SMTP id g42so3858279qge.1 for ; Wed, 05 Aug 2015 15:01:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=m6ICfA/Dg3+j0wFcJY1BXxun9op/L4HqpmawJFHKsa4=; b=WulOeWRUZcz4L/3cZTMD1oUGH8vPaZ/FDZvvPo2UBGmH/XvSW4X8uoklzF2nLbDrLF Egk1JrzmEW50yGbvOUzVI5PoTq8K8VqatO+D/aCsFn6vDjYp/WyRO84zP5ADKFsZpulx +tNeG9TI3x9PhcO/qplVlz6QrbpNgvG5Pd8ozp8tW79EJ2dz10Lq9KOcD1pIShYWsBXV xewZtGZo9i4RJNEjtbsRuDRER8lFjnPnVeJ04JJHFC6qNnao/Nx/rWb2MziOE4PazSa/ yx1IUk6yr+GmHhoUJ5WpvQi3G9R7s9lar6dxd6tykkOvIr5iszk//BIUqhMHAw9Xk8b5 Q4QQ== X-Gm-Message-State: ALoCoQkJdydBE/sOuikgMQYfqq7Y711xE8wHc5HBmVdJqa2YC1EhOsK4TW2GlxphLQEoSN3HRjcD X-Received: by 10.140.145.16 with SMTP id 16mr9823082qhr.34.1438812070515; Wed, 05 Aug 2015 15:01:10 -0700 (PDT) Received: from Simons-MacBook-Air.local ([2607:fa48:6eca:f820:8866:e37:fd1c:e865]) by smtp.googlemail.com with ESMTPSA id 71sm2094225qhg.37.2015.08.05.15.01.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 15:01:09 -0700 (PDT) Message-ID: <55C287A4.8050600@jive.com> Date: Wed, 05 Aug 2015 18:01:08 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Justin Uberti References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Philipp Hancke , "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 22:01:12 -0000 Le 2015-08-05 17:35, Justin Uberti a écrit : > I am somewhat sympathetic to that, but given that there is measurable > downside here - extra candidate pairs that take time to check - can you > supply a concrete example of where the client choosing not to pair a > TURN candidate with a RFC1918 address would cause a problem? I can't! Philipp's proposal certainly does make practical sense when you consider it as an ugly optimization hack rather than something that is necessary to make things work. Phrase it so that this is clear and I'll be all for it. :) Simon From nobody Wed Aug 5 15:20:06 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE941ACDDF; Wed, 5 Aug 2015 15:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDSOyEcXksq1; Wed, 5 Aug 2015 15:20:03 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265501ACDDE; Wed, 5 Aug 2015 15:20:02 -0700 (PDT) Received: from [192.168.1.202] (71-94-211-114.static.knwc.wa.charter.com [71.94.211.114]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t75MKAHQ028790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 6 Aug 2015 00:20:13 +0200 Message-ID: <55C28C05.1000901@goodadvice.pages.de> Date: Wed, 05 Aug 2015 15:19:49 -0700 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Simon Perreault , Justin Uberti References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> <55C287A4.8050600@jive.com> In-Reply-To: <55C287A4.8050600@jive.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 22:20:05 -0000 Am 05.08.2015 um 15:01 schrieb Simon Perreault: > Le 2015-08-05 17:35, Justin Uberti a écrit : >> I am somewhat sympathetic to that, but given that there is measurable >> downside here - extra candidate pairs that take time to check - can you >> supply a concrete example of where the client choosing not to pair a >> TURN candidate with a RFC1918 address would cause a problem? > > I can't! > > Philipp's proposal certainly does make practical sense when you consider > it as an ugly optimization hack rather than something that is necessary > to make things work. Phrase it so that this is clear and I'll be all for > it. :) incidentally, that's how I came up with it a while back: https://code.google.com/p/webrtc/issues/detail?id=4634 :-) From nobody Thu Aug 6 02:58:42 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868451B2BD3 for ; Thu, 6 Aug 2015 02:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0aThQWr1lRt for ; Thu, 6 Aug 2015 02:58:32 -0700 (PDT) Received: from mailstore06.sysedata.no (b.mail.tornado.no [195.159.29.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2214D1B2BC9 for ; Thu, 6 Aug 2015 02:58:32 -0700 (PDT) Received: from [62.96.148.44] (helo=Alfreds-MacBook-Pro-2.local) by mailstore06.sysedata.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ZNHwT-0000bo-EJ; Thu, 06 Aug 2015 11:58:29 +0200 To: Justin Uberti , Simon Perreault References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: "Alfred E. Heggestad" Message-ID: <55C32FC4.9010909@db.org> Date: Thu, 6 Aug 2015 11:58:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 09:58:36 -0000 On 05/08/15 23:35, Justin Uberti wrote: > > > On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault > wrote: > > Le 2015-08-05 13:46, Philipp Hancke a écrit : > > If a peer sends candidates with IP addresses from the private space, > > permissions for those are created at the TURN server. Potentially not > > utilising transport encryption even. > > > > I doubt those candidates ever work, so from a privacy point of view it > > seems that clients should not create those permissions in the first > > place. And ICE should probably not try to create pairs. > > It's not up to the client to determine what addresses might not might > not work for a given TURN server. There are lots of weird NAT > configurations out there that play games with RFC1918 addresses and can > easily trick clients into doing the wrong thing. > > > I am somewhat sympathetic to that, but given that there is measurable downside here - extra candidate pairs that take time to check - can you supply a concrete > example of where the client choosing not to pair a TURN candidate with a RFC1918 address would cause a problem? > adding a TURN Permission to a private IP-address does not make sense. in some code I have this pseudo C-code: if (!ipv4_address_is_private(addr)) { turnc_add_perm(turnc, addr); } /alfred From nobody Thu Aug 6 06:36:24 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC0B1B2F88 for ; Thu, 6 Aug 2015 06:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMJ_JXYeGis6 for ; Thu, 6 Aug 2015 06:36:19 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EB41B2F7A for ; Thu, 6 Aug 2015 06:36:01 -0700 (PDT) Received: by oiev193 with SMTP id v193so8748841oie.3 for ; Thu, 06 Aug 2015 06:36:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PkYkEnHt7lF6AuxXEN7rKon6kZVltKpL8neOf7QJMoQ=; b=Y2RZOXZF75V2aROv7VjakouPKu7JB2LPYFk9b8D0vseBYEXKH5amoj6o9/sOWhl3SR 2FulPnTClpIDA9v+8+nWC6uTMOuCL2s2X0bVShnTHU1+wL23Oeg5XXOw3NE6Je3RJcoK xsKZ/edhbsC19dp+R8LIiK/FoSjDseE+UgzEbxpEYTTHGXpss6MVwhS558WlpGYwAumr aUet4oxZcTPVe+6Q3Tz71wW1OfkKi54CwYszyNV8L18vpYEx16OAdA3GSGB6NfnENL65 pAVWLFlKxlgXC8GNUzVvQjXWWwyIw7POoYRoMxAmEXvX8T7qyXB49QEj9qYMq3UqGZ8j hwqA== X-Gm-Message-State: ALoCoQkPn2hNFpn+p+2Eh1nAx++xQZvrbkBcDLwKVkR2UXby7Zd5Dj2H1kNoaFVUPZEb9RfwKdjJ X-Received: by 10.202.58.133 with SMTP id h127mr1452037oia.35.1438868160698; Thu, 06 Aug 2015 06:36:00 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com. [209.85.214.182]) by smtp.gmail.com with ESMTPSA id z19sm3861825obp.17.2015.08.06.06.35.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Aug 2015 06:35:57 -0700 (PDT) Received: by obbfr1 with SMTP id fr1so18951843obb.1 for ; Thu, 06 Aug 2015 06:35:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.78.230 with SMTP id e6mr1609742oex.24.1438868156469; Thu, 06 Aug 2015 06:35:56 -0700 (PDT) Received: by 10.76.83.167 with HTTP; Thu, 6 Aug 2015 06:35:56 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> Date: Thu, 6 Aug 2015 06:35:56 -0700 Message-ID: From: Emil Ivov To: Justin Uberti Content-Type: multipart/alternative; boundary=089e0111b2a258a449051ca4990e Archived-At: Cc: Simon Perreault , "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 13:36:22 -0000 --089e0111b2a258a449051ca4990e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, August 5, 2015, Justin Uberti wrote: > > > On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault > wrote: > >> Le 2015-08-05 13:46, Philipp Hancke a =C3=A9crit : >> > If a peer sends candidates with IP addresses from the private space, >> > permissions for those are created at the TURN server. Potentially not >> > utilising transport encryption even. >> > >> > I doubt those candidates ever work, so from a privacy point of view it >> > seems that clients should not create those permissions in the first >> > place. And ICE should probably not try to create pairs. >> >> It's not up to the client to determine what addresses might not might >> not work for a given TURN server. There are lots of weird NAT >> configurations out there that play games with RFC1918 addresses and can >> easily trick clients into doing the wrong thing. >> > > I am somewhat sympathetic to that, but given that there is measurable > downside here - extra candidate pairs that take time to check - can you > supply a concrete example of where the client choosing not to pair a TURN > candidate with a RFC1918 address would cause a problem? > Isn't it enough to just have a route on the TURN server to a 1918 network? I don't know why someone would do this and what sort of DMZed configuration it would be but if they could then I don't think clients should try to make assumptions about the practicality of such a configuration. It is clearly much easier for the TURN server to check whether or not it has such a route and refuse to add the permission. Emil --=20 sent from my mobile --089e0111b2a258a449051ca4990e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, August 5, 2015, Justin Uberti <juberti@google.com> wrote:


On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault <sperreault@jive.com> wro= te:
Le 2015-08-05 13:46, Philipp Hancke a= =C3=A9crit :
> If a peer sends candidates with IP addresses from the private space, > permissions for those are created at the TURN server. Potentially not<= br> > utilising transport encryption even.
>
> I doubt those candidates ever work, so from a privacy point of view it=
> seems that clients should not create those permissions in the first > place. And ICE should probably not try to create pairs.

It's not up to the client to determine what addresses might not might not work for a given TURN server. There are lots of weird NAT
configurations out there that play games with RFC1918 addresses and can
easily trick clients into doing the wrong thing.

<= /div>
I am somewhat sympathetic to that, but given that there is measur= able downside here - extra candidate pairs that take time to check - can yo= u supply a concrete example of where the client choosing not to pair a TURN= candidate with a RFC1918 address would cause a problem?
<= /div>

Isn't it enough to just have=C2= =A0a route on the TURN server to a 1918 network? I don't know why someo= ne would do this and what sort of DMZed configuration it would be=C2=A0but if they could then I don't think clients should try to mak= e assumptions about the practicality of such a configuration.
It is clearly much easier for the TURN server to check whether = or not it has such a route and refuse to add the permission.

=
Emil


--
sent from my mobile
--089e0111b2a258a449051ca4990e-- From nobody Thu Aug 6 07:15:15 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8485F1A0368; Thu, 6 Aug 2015 07:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLXjGNd_vlBb; Thu, 6 Aug 2015 07:15:07 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292F51A002C; Thu, 6 Aug 2015 07:15:07 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t76EAawV022509; Thu, 6 Aug 2015 10:15:01 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1w0h0utqxb-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 06 Aug 2015 10:15:00 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 6 Aug 2015 09:14:59 -0500 From: Jonathan Lennox To: Justin Uberti Thread-Topic: [tram] [rtcweb] TURN permissions for private ips Thread-Index: AQHQ0FCLNCYkZhS0BUWVw9lyF0GfpZ3/V78A Date: Thu, 6 Aug 2015 14:14:59 +0000 Message-ID: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.200.77.253] Content-Type: multipart/alternative; boundary="_000_F144FF61AAC64E0AB08E0E3F9B487F1Bvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-06_08:2015-08-06,2015-08-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1508060236 Archived-At: Cc: Simon Perreault , Philipp Hancke , "rtcweb@ietf.org" , "tram@ietf.org" , mmusic Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 14:15:10 -0000 --_000_F144FF61AAC64E0AB08E0E3F9B487F1Bvidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBBdWcgNSwgMjAxNSwgYXQgNTozNSBQTSwgSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29n bGUuY29tPG1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KT24gV2VkLCBBdWcg NSwgMjAxNSBhdCAxMTozMiBBTSwgU2ltb24gUGVycmVhdWx0IDxzcGVycmVhdWx0QGppdmUuY29t PG1haWx0bzpzcGVycmVhdWx0QGppdmUuY29tPj4gd3JvdGU6DQpMZSAyMDE1LTA4LTA1IDEzOjQ2 LCBQaGlsaXBwIEhhbmNrZSBhIMOpY3JpdCA6DQo+IElmIGEgcGVlciBzZW5kcyBjYW5kaWRhdGVz IHdpdGggSVAgYWRkcmVzc2VzIGZyb20gdGhlIHByaXZhdGUgc3BhY2UsDQo+IHBlcm1pc3Npb25z IGZvciB0aG9zZSBhcmUgY3JlYXRlZCBhdCB0aGUgVFVSTiBzZXJ2ZXIuIFBvdGVudGlhbGx5IG5v dA0KPiB1dGlsaXNpbmcgdHJhbnNwb3J0IGVuY3J5cHRpb24gZXZlbi4NCj4NCj4gSSBkb3VidCB0 aG9zZSBjYW5kaWRhdGVzIGV2ZXIgd29yaywgc28gZnJvbSBhIHByaXZhY3kgcG9pbnQgb2Ygdmll dyBpdA0KPiBzZWVtcyB0aGF0IGNsaWVudHMgc2hvdWxkIG5vdCBjcmVhdGUgdGhvc2UgcGVybWlz c2lvbnMgaW4gdGhlIGZpcnN0DQo+IHBsYWNlLiBBbmQgSUNFIHNob3VsZCBwcm9iYWJseSBub3Qg dHJ5IHRvIGNyZWF0ZSBwYWlycy4NCg0KSXQncyBub3QgdXAgdG8gdGhlIGNsaWVudCB0byBkZXRl cm1pbmUgd2hhdCBhZGRyZXNzZXMgbWlnaHQgbm90IG1pZ2h0DQpub3Qgd29yayBmb3IgYSBnaXZl biBUVVJOIHNlcnZlci4gVGhlcmUgYXJlIGxvdHMgb2Ygd2VpcmQgTkFUDQpjb25maWd1cmF0aW9u cyBvdXQgdGhlcmUgdGhhdCBwbGF5IGdhbWVzIHdpdGggUkZDMTkxOCBhZGRyZXNzZXMgYW5kIGNh bg0KZWFzaWx5IHRyaWNrIGNsaWVudHMgaW50byBkb2luZyB0aGUgd3JvbmcgdGhpbmcuDQoNCkkg YW0gc29tZXdoYXQgc3ltcGF0aGV0aWMgdG8gdGhhdCwgYnV0IGdpdmVuIHRoYXQgdGhlcmUgaXMg bWVhc3VyYWJsZSBkb3duc2lkZSBoZXJlIC0gZXh0cmEgY2FuZGlkYXRlIHBhaXJzIHRoYXQgdGFr ZSB0aW1lIHRvIGNoZWNrIC0gY2FuIHlvdSBzdXBwbHkgYSBjb25jcmV0ZSBleGFtcGxlIG9mIHdo ZXJlIHRoZSBjbGllbnQgY2hvb3Npbmcgbm90IHRvIHBhaXIgYSBUVVJOIGNhbmRpZGF0ZSB3aXRo IGEgUkZDMTkxOCBhZGRyZXNzIHdvdWxkIGNhdXNlIGEgcHJvYmxlbT8NCg0KVGhpcyBpcyByZWFs bHkgYW4gSUNFIHF1ZXN0aW9uLCBub3QgYSBUVVJOIHF1ZXN0aW9uLCBzbyBhZGRpbmcgTU1VU0lD Lg0KDQpDbGVhcmx5LCBpZiB5b3VyIFRVUk4gc2VydmVyIGlzIGFjdHVhbGx5IG9uIHRoZSBwdWJs aWMgaW50ZXJuZXQsIHBhaXJpbmcgUkZDMTkxOCBhZGRyZXNzIHdpdGggaXRzIGNhbmRpZGF0ZXMg d29u4oCZdCBkbyBhbnkgZ29vZC4gIEhvd2V2ZXIsIHRoZXJlIGNhbiBiZSBzY2VuYXJpb3Mgd2hl cmUgeW91IGhhdmUgYSBUVVJOIHNlcnZlciBzaXR0aW5nIGluIGEgRE1aIG9yIHRoZSBsaWtlLCB3 aGVyZSBpdCBjYW4gYWN0dWFsbHkgcm91dGUgdG8gUkZDIDE5MTggYWRkcmVzc2VzLiAgSSBzdXNw ZWN0IHRoaXMgd2lsbCBiZSByZWxldmFudCBpbiB0aGUgdmFyaW91cyBzY2VuYXJpb3Mgd2hlcmUg dGhlIFRVUk4gc2VydmVyIGlzIHRvcG9sb2dpY2FsbHkgZXF1aXZhbGVudCB0byBhIHdlYiBwcm94 eS4NCg0KQXMgSSByZWNhbGwgZnJvbSB0aGUgZGlzY3Vzc2lvbnMgYXJvdW5kIHRoZSBkZXZlbG9w bWVudCBvZiBJQ0UsIHRoZXJlIGFyZSBhY3R1YWxseSBhIGZhaXIgbnVtYmVyIG9mIG5ldHdvcmtz IG91dCB0aGVyZSB3aGljaCBoYXZlIHB1YmxpYyBJUHY0IGFuZCBSRkMxOTE4IGFkZHJlc3NlcyBk aXJlY3RseSByb3V0YWJsZSB0byBlYWNoIG90aGVyLiBUaGUgZXhhbXBsZXMgSSByZW1lbWJlciBj YW1lIGFib3V0IGFzIGEgcmVzdWx0IG9mIGNvcnBvcmF0ZSBtZXJnZXJzLCB3aGVyZSBvbmUgb2Yg dGhlIHByZS1tZXJnZXIgY29tcGFuaWVzIHdhcyB1c2luZyB0aGVpciBwdWJsaWMgYWRkcmVzcyBz cGFjZSBpbnRlcm5hbGx5LCBhbmQgdGhlIG90aGVyIHdhc27igJl0Lg0KDQoNCg== --_000_F144FF61AAC64E0AB08E0E3F9B487F1Bvidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <624D3DFFD369C44CA0966779E4E06CF4@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBdWcg NSwgMjAxNSwgYXQgNTozNSBQTSwgSnVzdGluIFViZXJ0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1 YmVydGlAZ29vZ2xlLmNvbSIgY2xhc3M9IiI+anViZXJ0aUBnb29nbGUuY29tPC9hPiZndDsgd3Jv dGU6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPk9uIFdlZCwgQXVnIDUsIDIwMTUgYXQgMTE6MzIgQU0sIFNpbW9uIFBlcnJlYXVsdCA8c3Bh biBkaXI9Imx0ciIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOnNwZXJyZWF1bHRAaml2 ZS5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5zcGVycmVhdWx0QGppdmUuY29tPC9hPiZn dDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KTGUgMjAxNS0wOC0wNSAxMzo0NiwgUGhpbGlwcCBIYW5ja2Ug YSDDqWNyaXQgOjxiciBjbGFzcz0iIj4NCiZndDsgSWYgYSBwZWVyIHNlbmRzIGNhbmRpZGF0ZXMg d2l0aCBJUCBhZGRyZXNzZXMgZnJvbSB0aGUgcHJpdmF0ZSBzcGFjZSw8YnIgY2xhc3M9IiI+DQom Z3Q7IHBlcm1pc3Npb25zIGZvciB0aG9zZSBhcmUgY3JlYXRlZCBhdCB0aGUgVFVSTiBzZXJ2ZXIu IFBvdGVudGlhbGx5IG5vdDxiciBjbGFzcz0iIj4NCiZndDsgdXRpbGlzaW5nIHRyYW5zcG9ydCBl bmNyeXB0aW9uIGV2ZW4uPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgSSBk b3VidCB0aG9zZSBjYW5kaWRhdGVzIGV2ZXIgd29yaywgc28gZnJvbSBhIHByaXZhY3kgcG9pbnQg b2YgdmlldyBpdDxiciBjbGFzcz0iIj4NCiZndDsgc2VlbXMgdGhhdCBjbGllbnRzIHNob3VsZCBu b3QgY3JlYXRlIHRob3NlIHBlcm1pc3Npb25zIGluIHRoZSBmaXJzdDxiciBjbGFzcz0iIj4NCiZn dDsgcGxhY2UuIEFuZCBJQ0Ugc2hvdWxkIHByb2JhYmx5IG5vdCB0cnkgdG8gY3JlYXRlIHBhaXJz LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkl0J3Mgbm90IHVwIHRvIHRoZSBjbGllbnQg dG8gZGV0ZXJtaW5lIHdoYXQgYWRkcmVzc2VzIG1pZ2h0IG5vdCBtaWdodDxiciBjbGFzcz0iIj4N Cm5vdCB3b3JrIGZvciBhIGdpdmVuIFRVUk4gc2VydmVyLiBUaGVyZSBhcmUgbG90cyBvZiB3ZWly ZCBOQVQ8YnIgY2xhc3M9IiI+DQpjb25maWd1cmF0aW9ucyBvdXQgdGhlcmUgdGhhdCBwbGF5IGdh bWVzIHdpdGggUkZDMTkxOCBhZGRyZXNzZXMgYW5kIGNhbjxiciBjbGFzcz0iIj4NCmVhc2lseSB0 cmljayBjbGllbnRzIGludG8gZG9pbmcgdGhlIHdyb25nIHRoaW5nLjxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkkgYW0gc29tZXdoYXQgc3ltcGF0aGV0aWMgdG8gdGhhdCwgYnV0IGdpdmVuIHRoYXQg dGhlcmUgaXMgbWVhc3VyYWJsZSBkb3duc2lkZSBoZXJlIC0gZXh0cmEgY2FuZGlkYXRlIHBhaXJz IHRoYXQgdGFrZSB0aW1lIHRvIGNoZWNrIC0gY2FuIHlvdSBzdXBwbHkgYSBjb25jcmV0ZSBleGFt cGxlIG9mIHdoZXJlIHRoZSBjbGllbnQgY2hvb3Npbmcgbm90IHRvIHBhaXIgYSBUVVJOIGNhbmRp ZGF0ZSB3aXRoIGEgUkZDMTkxOCBhZGRyZXNzDQogd291bGQgY2F1c2UgYSBwcm9ibGVtPzwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBpcyByZWFsbHkgYW4gSUNFIHF1ZXN0aW9uLCBub3Qg YSBUVVJOIHF1ZXN0aW9uLCBzbyBhZGRpbmcgTU1VU0lDLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXY+Q2xlYXJseSwgaWYgeW91ciBUVVJOIHNlcnZlciBpcyBhY3R1YWxs eSBvbiB0aGUgcHVibGljIGludGVybmV0LCBwYWlyaW5nIFJGQzE5MTggYWRkcmVzcyB3aXRoIGl0 cyBjYW5kaWRhdGVzIHdvbuKAmXQgZG8gYW55IGdvb2QuICZuYnNwO0hvd2V2ZXIsIHRoZXJlIGNh biBiZSBzY2VuYXJpb3Mgd2hlcmUgeW91IGhhdmUgYSBUVVJOIHNlcnZlciBzaXR0aW5nIGluIGEg RE1aIG9yIHRoZSBsaWtlLCB3aGVyZSBpdCBjYW4gYWN0dWFsbHkgcm91dGUgdG8gUkZDDQogMTkx OCBhZGRyZXNzZXMuICZuYnNwO0kgc3VzcGVjdCB0aGlzIHdpbGwgYmUgcmVsZXZhbnQgaW4gdGhl IHZhcmlvdXMgc2NlbmFyaW9zIHdoZXJlIHRoZSBUVVJOIHNlcnZlciBpcyB0b3BvbG9naWNhbGx5 IGVxdWl2YWxlbnQgdG8gYSB3ZWIgcHJveHkuJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdj5BcyBJIHJlY2FsbCBmcm9tIHRoZSBkaXNjdXNzaW9ucyBhcm91bmQg dGhlIGRldmVsb3BtZW50IG9mIElDRSwgdGhlcmUgYXJlIGFjdHVhbGx5IGEgZmFpciBudW1iZXIg b2YgbmV0d29ya3Mgb3V0IHRoZXJlIHdoaWNoIGhhdmUgcHVibGljIElQdjQgYW5kIFJGQzE5MTgg YWRkcmVzc2VzIGRpcmVjdGx5IHJvdXRhYmxlIHRvIGVhY2ggb3RoZXIuIFRoZSBleGFtcGxlcyBJ IHJlbWVtYmVyIGNhbWUgYWJvdXQgYXMgYSByZXN1bHQgb2YgY29ycG9yYXRlDQogbWVyZ2Vycywg d2hlcmUgb25lIG9mIHRoZSBwcmUtbWVyZ2VyIGNvbXBhbmllcyB3YXMgdXNpbmcgdGhlaXIgcHVi bGljIGFkZHJlc3Mgc3BhY2UgaW50ZXJuYWxseSwgYW5kIHRoZSBvdGhlciB3YXNu4oCZdC48L2Rp dj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F144FF61AAC64E0AB08E0E3F9B487F1Bvidyocom_-- From nobody Thu Aug 6 13:10:20 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C981B32F5 for ; Thu, 6 Aug 2015 13:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGm_2aAj6MAS for ; Thu, 6 Aug 2015 13:10:11 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4ABD1A8737 for ; Thu, 6 Aug 2015 13:08:43 -0700 (PDT) Received: by vkhg129 with SMTP id g129so31009989vkh.2 for ; Thu, 06 Aug 2015 13:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5JF2zEDoBMNncmCmEQZNbKUosIlo7/QbK9t7OhJdAMk=; b=jbeVQ94r7Q5Y0uqH/ecTCAOJDn3vJHcM/6Sjy3j9ZtbHlusnWGHBKKBzRjahSBMq06 Of0Dp5AuptNeDLj8U6/VPzu0xQVqd2Dm9yYO5upp9wSrFNoUqJritE21ukdoSE3oV/oj TihTktxxEOB9VrSfFL+pp2YvUtNTzKuSyEfbz6ECy6vbDtRFt3ybpcUC8y7PkoFNzKrX OlPGVRHCGQwTI5S37ImBYbJDnh5ZRga3NjIRvwiq88jaXBht3JHbrZTMpdR3dV+qO0SV OqZ27AB9R7tI6sJ3KsInUw8k83gp5Z25/0w6DBLH3sCLP8ym0EWu+tSo3p4dk16eboZ1 59DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5JF2zEDoBMNncmCmEQZNbKUosIlo7/QbK9t7OhJdAMk=; b=geBjJpxRRtTajhxRPAKtyQQ4i5zYMHev6j2HAZkgOVc00FeW2V1cRfy6JQr2Fdd+W1 xIZ3zE8S9LKc2Tm2gjOB7tFWQ9+v5wEkWvwSyoMHoUTcQHez7JHmBfhwxqkb8IL98tC4 6JTcp9JPM2d8CEeuJ5EOFxk6QTGz2t+AEv+glKLraLOTmT2N2nHzj/87LoQ8DeqL71Qv l5NYtpj/5tarDzR2bRD76cu+UkYOIgiz0LJ4so9Au01UuEz9X3JZ57K2ZJzchA68lf5S imEAEq2rM6yGmHWni9ExKPf8oHIubn0bcNCucyAxhrH4r9CfyPpSyZZq4/BeyUqgkcYz /cTQ== X-Gm-Message-State: ALoCoQngGo1DLOsszB96E2U12hFWy5X137Ug80wou8Hl7ukilRI8phPR5CLx3Cb1xbo2nn0VOiy3 X-Received: by 10.52.186.10 with SMTP id fg10mr4518513vdc.84.1438891722957; Thu, 06 Aug 2015 13:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.87 with HTTP; Thu, 6 Aug 2015 13:08:23 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: Justin Uberti Date: Thu, 6 Aug 2015 13:08:23 -0700 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=bcaec54864ba04a9a9051caa16bf Archived-At: Cc: Simon Perreault , Philipp Hancke , "rtcweb@ietf.org" , "tram@ietf.org" , mmusic Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 20:10:12 -0000 --bcaec54864ba04a9a9051caa16bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree regarding "proxy-like" border TURN servers. I think that a candidate obtained from this sort of TURN server should be paired with RFC 1918 addresses, but I think that we should be able to avoid pairing candidates obtained from application TURN servers with RFC 1918 addresses. The app/browser clearly knows which is which. On Thu, Aug 6, 2015 at 7:14 AM, Jonathan Lennox wrote: > > On Aug 5, 2015, at 5:35 PM, Justin Uberti wrote: > > On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault > wrote: > >> Le 2015-08-05 13:46, Philipp Hancke a =C3=A9crit : >> > If a peer sends candidates with IP addresses from the private space, >> > permissions for those are created at the TURN server. Potentially not >> > utilising transport encryption even. >> > >> > I doubt those candidates ever work, so from a privacy point of view it >> > seems that clients should not create those permissions in the first >> > place. And ICE should probably not try to create pairs. >> >> It's not up to the client to determine what addresses might not might >> not work for a given TURN server. There are lots of weird NAT >> configurations out there that play games with RFC1918 addresses and can >> easily trick clients into doing the wrong thing. >> > > I am somewhat sympathetic to that, but given that there is measurable > downside here - extra candidate pairs that take time to check - can you > supply a concrete example of where the client choosing not to pair a TURN > candidate with a RFC1918 address would cause a problem? > > > This is really an ICE question, not a TURN question, so adding MMUSIC. > > Clearly, if your TURN server is actually on the public internet, pairing > RFC1918 address with its candidates won=E2=80=99t do any good. However, = there can > be scenarios where you have a TURN server sitting in a DMZ or the like, > where it can actually route to RFC 1918 addresses. I suspect this will b= e > relevant in the various scenarios where the TURN server is topologically > equivalent to a web proxy. > > As I recall from the discussions around the development of ICE, there are > actually a fair number of networks out there which have public IPv4 and > RFC1918 addresses directly routable to each other. The examples I remembe= r > came about as a result of corporate mergers, where one of the pre-merger > companies was using their public address space internally, and the other > wasn=E2=80=99t. > > > --bcaec54864ba04a9a9051caa16bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree regarding "proxy-like" border TURN servers= . I think that a candidate obtained from this sort of TURN server should be= paired with RFC 1918 addresses, but I think that we should be able to avoi= d pairing candidates obtained from application TURN servers with RFC 1918 a= ddresses. The app/browser clearly knows which is which.

On Thu, Aug 6, 2015 at 7:14 AM,= Jonathan Lennox <jonathan@vidyo.com> wrote:

On Aug 5, 2015, at 5:35 PM, Justin Uberti <juberti@google.com> wrote:

On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault= <sperreault@jiv= e.com> wrote:
Le 2015-08-05 13:46, Philipp Hancke a =C3=A9crit :
> If a peer sends candidates with IP addresses from the private space, > permissions for those are created at the TURN server. Potentially not<= br> > utilising transport encryption even.
>
> I doubt those candidates ever work, so from a privacy point of view it=
> seems that clients should not create those permissions in the first > place. And ICE should probably not try to create pairs.

It's not up to the client to determine what addresses might not might not work for a given TURN server. There are lots of weird NAT
configurations out there that play games with RFC1918 addresses and can
easily trick clients into doing the wrong thing.

I am somewhat sympathetic to that, but given that there is measurable = downside here - extra candidate pairs that take time to check - can you sup= ply a concrete example of where the client choosing not to pair a TURN cand= idate with a RFC1918 address would cause a problem?

This is really an ICE question, not a TURN question, so ad= ding MMUSIC.

Clearly, if your TURN server is actually on the public internet, pairi= ng RFC1918 address with its candidates won=E2=80=99t do any good.=C2=A0 How= ever, there can be scenarios where you have a TURN server sitting in a DMZ = or the like, where it can actually route to RFC 1918 addresses.=C2=A0 I suspect this will be relevant in the various scena= rios where the TURN server is topologically equivalent to a web proxy.=C2= =A0

As I recall from the discussions around the development of ICE, there = are actually a fair number of networks out there which have public IPv4 and= RFC1918 addresses directly routable to each other. The examples I remember= came about as a result of corporate mergers, where one of the pre-merger companies was using their public addr= ess space internally, and the other wasn=E2=80=99t.



--bcaec54864ba04a9a9051caa16bf-- From nobody Thu Aug 6 13:51:58 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23081B32FA; Thu, 6 Aug 2015 13:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgvXOTimBOyS; Thu, 6 Aug 2015 13:51:52 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131B71B32FC; Thu, 6 Aug 2015 13:51:52 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so49857617lbb.0; Thu, 06 Aug 2015 13:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WB6o88qL/fXEOLZiSFomzUP+RsoPUgYwLUgic+aeQVU=; b=olEqV7g+1nJUAikCBdfcIfm3+V6J0bpa356buWsvAGBA8hweeE9Ohm1IXh0ZsbSJ0j TVLOh+m1T0Q8vwFYXWs2ipDbV3/kI7GzDhGTlXd2rsY1YORmqwf7fFgFK9aIFSa0O/tX sfwN3S5BjkSVJsFqRHuG1YRLlrhDI0735nbxQTg+mQJM0Kc/rteuguNtgqxz3159BTK8 BkRKtf4FgQDvuPtq+IYbtpJpfBVp7/skNGNgQETmNr0w1PSwU0b3PKd4ZZLh1Jyk6/sO QZlRG0dUPqPM4z8tQbEmxROVjxxxo89eHJlZpEnfUfgHAdfWCrwCWwjbbJLVDPYdWcoF BSBw== MIME-Version: 1.0 X-Received: by 10.152.179.42 with SMTP id dd10mr4233835lac.89.1438894310528; Thu, 06 Aug 2015 13:51:50 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Thu, 6 Aug 2015 13:51:50 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> Date: Thu, 6 Aug 2015 13:51:50 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jonathan Lennox , "rtcweb@ietf.org" , "tram@ietf.org" , mmusic Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 20:51:53 -0000 On 6 August 2015 at 13:08, Justin Uberti wrote: > I think that we should be able to avoid pairing candidates obtained from > application TURN servers with RFC 1918 addresses. The app/browser clearly > knows which is which. I'm concerned here that if we let the application choose, we lose the defence we were looking to gain. I think that perhaps 1918 pairing could be restricted to TURN servers that are configured/discovered, "proxy"-style. From nobody Thu Aug 6 14:09:05 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E851A8843; Thu, 6 Aug 2015 14:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2WZykYQ-I9N; Thu, 6 Aug 2015 14:09:00 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49191A87C7; Thu, 6 Aug 2015 14:09:00 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t76L6Jfk013010; Thu, 6 Aug 2015 17:08:56 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1w1e1wjchw-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 06 Aug 2015 17:08:56 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 6 Aug 2015 16:08:55 -0500 From: Jonathan Lennox To: Martin Thomson Thread-Topic: [rtcweb] [tram] TURN permissions for private ips Thread-Index: AQHQ0Im5K1zUyQsgpEy93n8RXczXUZ3/yvCA Date: Thu, 6 Aug 2015 21:08:55 +0000 Message-ID: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.200.77.253] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-06_11:2015-08-06,2015-08-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1508060327 Archived-At: Cc: mmusic , "rtcweb@ietf.org" , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 21:09:01 -0000 DQo+IE9uIEF1ZyA2LCAyMDE1LCBhdCA0OjUxIFBNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRo b21zb25AZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IE9uIDYgQXVndXN0IDIwMTUgYXQgMTM6MDgs IEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29vZ2xlLmNvbT4gd3JvdGU6DQo+PiBJIHRoaW5rIHRo YXQgd2Ugc2hvdWxkIGJlIGFibGUgdG8gYXZvaWQgcGFpcmluZyBjYW5kaWRhdGVzIG9idGFpbmVk IGZyb20NCj4+IGFwcGxpY2F0aW9uIFRVUk4gc2VydmVycyB3aXRoIFJGQyAxOTE4IGFkZHJlc3Nl cy4gVGhlIGFwcC9icm93c2VyIGNsZWFybHkNCj4+IGtub3dzIHdoaWNoIGlzIHdoaWNoLg0KPiAN Cj4gSSdtIGNvbmNlcm5lZCBoZXJlIHRoYXQgaWYgd2UgbGV0IHRoZSBhcHBsaWNhdGlvbiBjaG9v c2UsIHdlIGxvc2UgdGhlDQo+IGRlZmVuY2Ugd2Ugd2VyZSBsb29raW5nIHRvIGdhaW4uICBJIHRo aW5rIHRoYXQgcGVyaGFwcyAxOTE4IHBhaXJpbmcNCj4gY291bGQgYmUgcmVzdHJpY3RlZCB0byBU VVJOIHNlcnZlcnMgdGhhdCBhcmUgY29uZmlndXJlZC9kaXNjb3ZlcmVkLA0KPiAicHJveHkiLXN0 eWxlLg0KDQpXaGF0IGlzIHRoZSB0aHJlYXQgbW9kZWwvY29uY2VybiBoZXJlPyAgQXJlIHlvdSB0 cnlpbmcgdG8gc2F2ZSAyMCBtcyBmb3IgdGhlIGNvbm5lY3Rpdml0eSBjaGVjaywgb3IgYXJlIHlv dSBjb25jZXJuZWQgdGhhdCB0aGUgcmVtb3RlIGNhbmRpZGF0ZXMgYXJlIHZpc2libGUgb24gdGhl IHdpcmUgYW5kIHRvIHRoZSB0dXJuIHNlcnZlcj8NCg0KT2J2aW91c2x5LCBsb2NhbCBhbmQgcmVt b3RlIGNhbmRpZGF0ZXMgYXJlIGFsd2F5cyB2aXNpYmxlIHRvIGFuIGFwcGxpY2F0aW9uLCBzbyB0 aGlzIGlzbuKAmXQgYSBjaXJjdW1zdGFuY2Ugd2hlcmUgd29ycnlpbmcgYWJvdXQgaG9zdGlsZSBh cHBsaWNhdGlvbnMgaXMgcGFydGljdWxhcmx5IHJlbGV2YW50Lg0KDQpJIGNhbiBjZXJ0YWlubHkg aW1hZ2luZSBjb3Jwb3JhdGUgV2ViUlRDIGFwcGxpY2F0aW9ucyB3aXRoIGFuIGFwcGxpY2F0aW9u LWNvbmZpZ3VyZWQgVFVSTiBzZXJ2ZXIgaW4gYSBETVouICBBbm90aGVyIGV4YW1wbGUgbWlnaHQg YmUgYSBjbG91ZCBzZXJ2aWNlIHdoaWNoIHdhbnRzIGFsbCBpdHMgdHJhZmZpYyB0byBjb21lIGlu IHRocm91Z2ggYSBzaW5nbGUgcG9ydCwgc28gaXQgY29uZmlndXJlcyBhbGwgYXBwbGljYXRpb25z IHRvIGNvbm5lY3QgdG8gaXQgdGhyb3VnaCBhIFRVUk4gcG9ydCBhbmQgdXNlcyBSRkMgMTkxOCBh ZGRyZXNzZXMgaW50ZXJuYWxseS4= From nobody Thu Aug 6 14:36:38 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1751A894E; Thu, 6 Aug 2015 14:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jzt4Ho5fRqMO; Thu, 6 Aug 2015 14:36:34 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5F61A8951; Thu, 6 Aug 2015 14:36:34 -0700 (PDT) Received: by labjt7 with SMTP id jt7so39479784lab.0; Thu, 06 Aug 2015 14:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6oakczvHVMr/nD3LkUJmJrDW6l0K9fzkG/FFurHHiNk=; b=bm8j2EeTScXDjLzgHq+Wq4/Vd8YDdrRMVbPhlvcAdRhfLWiVmsKgMO9pi0rg80UtoS /V6Zp1EZK3Lk0GYH022BnoDwzphpYhRRmKV95Cbekfkt3oPPgTJ+UoTPigbl1FJXIjCr GGQsEjd/XKf4pDBw9pFILaSanu7BpH4lyrKoFkqLM3JGvokF9xpkJtqYm5CLur2++XuE MBrGKsVr78dYVWeFcl0MyAL6HoHAAZ2EhE1gMwuYhJTPQ/afSvyfGrWeykqLMeun4HU8 h2SMB0KODFeC2EtMV1kbcabJQ127onsUNseNwDeLcUlcdRlkSjMMIrfiaSrU8ssG42WO mPwQ== MIME-Version: 1.0 X-Received: by 10.152.121.4 with SMTP id lg4mr4374404lab.112.1438896989786; Thu, 06 Aug 2015 14:36:29 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Thu, 6 Aug 2015 14:36:29 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> Date: Thu, 6 Aug 2015 14:36:29 -0700 Message-ID: From: Martin Thomson To: Jonathan Lennox Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: mmusic , "rtcweb@ietf.org" , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 21:36:36 -0000 On 6 August 2015 at 14:08, Jonathan Lennox wrote: > What is the threat model/concern here? Are you trying to save 20 ms for the connectivity check, or are you concerned that the remote candidates are visible on the wire and to the turn server? Well, perhaps I'd missed the point of the thread, but my understanding was that attempting to pair TURN candidates with private address ranges had several negative characteristics: 1. they are unlikely to work 2. they expose the 1918 address to the TURN server 3. they expose the 1918 address to others (depending on whether DTLS is used to the TURN server and how far a check toward that address actually makes it through the network) 4. they consume a check slot Obviously, a lot of this hinges on the first point. If there is a reasonable chance that the pairing works, then maybe the other costs can be borne. From nobody Thu Aug 6 17:01:34 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364641B3D74 for ; Thu, 6 Aug 2015 17:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0tN6Oh1JpjH for ; Thu, 6 Aug 2015 17:01:25 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA5F1B3D7C for ; Thu, 6 Aug 2015 17:01:24 -0700 (PDT) Received: by vkci6 with SMTP id i6so33465275vkc.3 for ; Thu, 06 Aug 2015 17:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+jvOtPiCLesNSSM3LOjkJIqc2tv5/rdaGiTjAxd/OXQ=; b=Z12dJog1Bt5k4sEN9+FjGIcjd7bQHCSQb+RSOmLSVIzRXGaEBTEdB71HQX5Jtnt4JD rsoWu8GGRDLZ3GNONa2L0Cw+SC1YPMMKbGIXuQ2wnFPulbPIFX0ZWgHJUuRseLkwdOF4 i5gZTKJp+0+O5WWxqGk8beCxNwgT3W3nQQltST6qNrw9iPHQrRnQHCNENyGPCIDhyCG7 0A41bi1Ndx5oyuObGU/CQa6xjLWn3bcgPWxkURiX89vXrO3T4zninA3cY4IeRxqEt1Pt RvwuhLkcnSLSdfEXE+N5/QO6zcdtB5MwniJRHc5CVPc//TgcY6pg9Lk3Um/x2v2Sw8VI LSrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+jvOtPiCLesNSSM3LOjkJIqc2tv5/rdaGiTjAxd/OXQ=; b=iv7JbEbFmzmSAHsiSYRe/xkZnblSyHNAyQaBo5Dda3Muqww7evr9K9K8N9bc7+fnvr 66bDbe/h2JwsyypGX6N5XevdaZFhjGtLr7rW8xKK1gwdAoMO+3NNuKXuoz5+odTwji74 m98lLPQ2muKMwhKb2Qgn54Xee/tj0WIGLp60Fq9icXns5GJ/ApZlco0081/paS/ikFVz AuXnq1G2LPhCgQOuZKUYLCGR1ylcOmqBXaeM/7tYLK2ecXWJlf8z8Xyop8uImt0Gi5+E OEpowUbGSDsDStfY9Bqgtp2mXQz0kOY+nWqVADYT/bVw3Y5A+WAVo8stRy3y3aC2FFPh yFAA== X-Gm-Message-State: ALoCoQkXrLVeC1xYbTwsbO6Sbsdjwtdlh7uVikAA32ruMDXjmRHVNKDBA0gIJ+dByWP9pcRdsgBv X-Received: by 10.52.186.72 with SMTP id fi8mr5242407vdc.19.1438905683283; Thu, 06 Aug 2015 17:01:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.87 with HTTP; Thu, 6 Aug 2015 17:01:03 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: Justin Uberti Date: Thu, 6 Aug 2015 17:01:03 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=bcaec548a8211e4346051cad56b4 Archived-At: Cc: Jonathan Lennox , "rtcweb@ietf.org" , "tram@ietf.org" , mmusic Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 00:01:26 -0000 --bcaec548a8211e4346051cad56b4 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson wrote: > On 6 August 2015 at 13:08, Justin Uberti wrote: > > I think that we should be able to avoid pairing candidates obtained from > > application TURN servers with RFC 1918 addresses. The app/browser clearly > > knows which is which. > > I'm concerned here that if we let the application choose, we lose the > defence we were looking to gain. I think that perhaps 1918 pairing > could be restricted to TURN servers that are configured/discovered, > "proxy"-style. > Sorry, that is what I was trying to say. The browser knows which turn servers are "proxies" vs app servers, and can apply the 1918 filtering on the pairings from the candidates from the app TURN server. Agree with your enumeration of concerns as well. Also #5, they consume bandwidth (at least from client to TURN server), which affects maximum check rate in some cases. --bcaec548a8211e4346051cad56b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On 6 August 2015 at 13:08, Justin Uberti <juberti@google.com> wrote:
> I think that we should be able to avoid pairing candidates obtained fr= om
> application TURN servers with RFC 1918 addresses. The app/browser clea= rly
> knows which is which.

I'm concerned here that if we let the application choose, we los= e the
defence we were looking to gain.=C2=A0 I think that perhaps 1918 pairing could be restricted to TURN servers that are configured/discovered,
"proxy"-style.

Sorry, that is= what I was trying to say. The browser knows which turn servers are "p= roxies" vs app servers, and can apply the 1918 filtering on the pairin= gs from the candidates from the app TURN server.

A= gree with your enumeration of concerns as well. Also #5, they consume bandw= idth (at least from client to TURN server), which affects maximum check rat= e in some cases.

--bcaec548a8211e4346051cad56b4-- From nobody Thu Aug 6 17:12:20 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C383C1A1B51 for ; Thu, 6 Aug 2015 17:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4cokn0qOBkl for ; Thu, 6 Aug 2015 17:12:15 -0700 (PDT) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232CB1A1B5E for ; Thu, 6 Aug 2015 17:12:14 -0700 (PDT) Received: by obbop1 with SMTP id op1so68161242obb.2 for ; Thu, 06 Aug 2015 17:12:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Pxr/LuCD3rDOKSXP/EZUedVgPCzhxZ3Q6hpeb/ktcdk=; b=hl+1KiUmdZAWPnCDh0fDI/JjvEt94OhfaaS7YfjZjH8cqY5W4+U4YRhllV1NB8yLyL G19bkbLdG9+yOU5ikugaCNFaDhExHui2iB8+59d9bAjUlbV9F2lcJjePa/c8JF/OZ4yE dJmLjifN5hmrZAxncacFgwg7dnN67aYh23YEiCOLJBQt6Ah50qAB57MWKLd6oenWNy1p nQVcnrwIoXsmA52FwhDLjdwId4aLEqaQdz8op0D43ewiQYopqLgxUAgScDx6zIGofyIF /btUJ0lKi6+ERkn9i3HErOz9Vd8ZqT1IFjepUO3RfW/0EHTVksUKIHH72ZKb/edG1RB6 NDnA== X-Gm-Message-State: ALoCoQnPXmdxCxu6Yf3l9kKyp9BZiVhmPv3XdNrBH7fH+V+1irxs2N55Spjc/QShIht8f8U12ZAG X-Received: by 10.182.86.39 with SMTP id m7mr4273965obz.18.1438906333674; Thu, 06 Aug 2015 17:12:13 -0700 (PDT) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com. [209.85.214.170]) by smtp.gmail.com with ESMTPSA id f3sm4965097obm.18.2015.08.06.17.12.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Aug 2015 17:12:12 -0700 (PDT) Received: by obnw1 with SMTP id w1so67947848obn.3 for ; Thu, 06 Aug 2015 17:12:12 -0700 (PDT) X-Received: by 10.182.213.227 with SMTP id nv3mr4094704obc.10.1438906332349; Thu, 06 Aug 2015 17:12:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.83.167 with HTTP; Thu, 6 Aug 2015 17:11:52 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: Emil Ivov Date: Thu, 6 Aug 2015 17:11:52 -0700 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jonathan Lennox , mmusic , Martin Thomson , "tram@ietf.org" , "rtcweb@ietf.org" Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 00:12:16 -0000 On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti wrote: > > > On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson > wrote: >> >> On 6 August 2015 at 13:08, Justin Uberti wrote: >> > I think that we should be able to avoid pairing candidates obtained from >> > application TURN servers with RFC 1918 addresses. The app/browser >> > clearly >> > knows which is which. >> >> I'm concerned here that if we let the application choose, we lose the >> defence we were looking to gain. I think that perhaps 1918 pairing >> could be restricted to TURN servers that are configured/discovered, >> "proxy"-style. > > > Sorry, that is what I was trying to say. The browser knows which turn > servers are "proxies" vs app servers, and can apply the 1918 filtering on > the pairings from the candidates from the app TURN server. I don't think Jonathan's concerns only apply to proxies though. You can just as well have apps developed for specific networks and there is no reason to prevent those from working. > Agree with your enumeration of concerns as well. Also #5, they consume > bandwidth (at least from client to TURN server), which affects maximum check > rate in some cases. Why can't we address this by TURN servers simply refusing to create permissions for candidates they know they won't be able to reach? Emil -- https://jitsi.org From nobody Thu Aug 6 17:46:32 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5101ACDC0 for ; Thu, 6 Aug 2015 17:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvIqehe-0Rp5 for ; Thu, 6 Aug 2015 17:46:28 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4B51ACDBC for ; Thu, 6 Aug 2015 17:46:28 -0700 (PDT) Received: by vkhg129 with SMTP id g129so33033260vkh.2 for ; Thu, 06 Aug 2015 17:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SuIeVYvp28UUfKlQhc9k3RUSCYOQW2f6eFVKgdTRSs8=; b=nylZ7C2/lCD1DGh4b5rCaOVQoL6J4Zs2XNxYDlUGVP59e/YihsYX+gFTxTEZjKol82 zW/FINu7oTpJZ7Pq94YlPSfCC8JyEdaVYocqsJhUKhNK+U5S0IwEUfNuUvd5fqNOX0ab G1fHYbhwy2Zm/p7N7L4B2H22/6wnYyWfYQGe2Kwqq5SPbD8ypRyXZ8eY+BTGO3/GcYuM XZbS+gMo05vDnOiPJJcBaAMee9+vCNn0uCM6Gq0yq6T4BfoxOelDd60NWkSRt6iRIRFA Cwdp6s2k6sCUo7ll53JpHMBPqaa+cD5n6WlrvbZuVY8awKrQUfVUI78gcDLs8YS9+cQx 7jDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SuIeVYvp28UUfKlQhc9k3RUSCYOQW2f6eFVKgdTRSs8=; b=kR55GJGSBNNa6CLVDsMhwzcH0GrZI7OF7T09mFvZgc6mS13F0uZySh3Fr17D1nDZZF iQls+hRHl4xYKJTiqyjuZwiLbI4gzK7XOGs2cXYmMic+Fbqzy5y9Eih+EVjGzpoL51Ec hCwe7eV5N1sZKnwCXx61qTAL370DsO/q4o0v+8KdGA8LwFQCz0PlJ4/wtrxmF6UFz4Pp YcWg2HJW4MS2NsCID39kuHQyNc8W0zN4IJLL30AfDKKn+JR14wrwTw7dSOvUiv5IDxST TroBwBLOuW1FNY9Q68qh+xRgq6PWxrHJarWVUmhhlzo6N/FR1dAaf/d3LncFVDV3FnRF r1AQ== X-Gm-Message-State: ALoCoQnPsYodoVMxInl0oFRLItC0NNkhumUm179fUrgxYQxcPTIjbTjrUTpllw6tXwXOBcnvyr8e X-Received: by 10.52.186.72 with SMTP id fi8mr5393953vdc.19.1438908387526; Thu, 06 Aug 2015 17:46:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.87 with HTTP; Thu, 6 Aug 2015 17:46:08 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: Justin Uberti Date: Thu, 6 Aug 2015 17:46:08 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=bcaec548a8214dbe34051cadf779 Archived-At: Cc: Jonathan Lennox , mmusic , Martin Thomson , "tram@ietf.org" , "rtcweb@ietf.org" Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 00:46:30 -0000 --bcaec548a8214dbe34051cadf779 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 6, 2015 at 5:11 PM, Emil Ivov wrote: > On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti wrote: > > > > > > On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson > > > wrote: > >> > >> On 6 August 2015 at 13:08, Justin Uberti wrote: > >> > I think that we should be able to avoid pairing candidates obtained > from > >> > application TURN servers with RFC 1918 addresses. The app/browser > >> > clearly > >> > knows which is which. > >> > >> I'm concerned here that if we let the application choose, we lose the > >> defence we were looking to gain. I think that perhaps 1918 pairing > >> could be restricted to TURN servers that are configured/discovered, > >> "proxy"-style. > > > > > > Sorry, that is what I was trying to say. The browser knows which turn > > servers are "proxies" vs app servers, and can apply the 1918 filtering on > > the pairings from the candidates from the app TURN server. > > I don't think Jonathan's concerns only apply to proxies though. You > can just as well have apps developed for specific networks and there > is no reason to prevent those from working. > > > Agree with your enumeration of concerns as well. Also #5, they consume > > bandwidth (at least from client to TURN server), which affects maximum > check > > rate in some cases. > > Why can't we address this by TURN servers simply refusing to create > permissions for candidates they know they won't be able to reach? That is one potential solution, which would solve #1/#4/#5. --bcaec548a8214dbe34051cadf779 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 6, 2015 at 5:11 PM, Emil Ivov <emcho@jitsi.org> wrote:
On Thu, Aug 6, = 2015 at 5:01 PM, Justin Uberti <ju= berti@google.com> wrote:
>
>
> On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> On 6 August 2015 at 13:08, Justin Uberti <juberti@google.com> wrote:
>> > I think that we should be able to avoid pairing candidates ob= tained from
>> > application TURN servers with RFC 1918 addresses. The app/bro= wser
>> > clearly
>> > knows which is which.
>>
>> I'm concerned here that if we let the application choose, we l= ose the
>> defence we were looking to gain.=C2=A0 I think that perhaps 1918 p= airing
>> could be restricted to TURN servers that are configured/discovered= ,
>> "proxy"-style.
>
>
> Sorry, that is what I was trying to say. The browser knows which turn<= br> > servers are "proxies" vs app servers, and can apply the 1918= filtering on
> the pairings from the candidates from the app TURN server.

I don't think Jonathan's concerns only apply to proxies thou= gh. You
can just as well have apps developed for specific networks and there
is no reason to prevent those from working.

> Agree with your enumeration of concerns as well. Also #5, they consume=
> bandwidth (at least from client to TURN server), which affects maximum= check
> rate in some cases.

Why can't we address this by TURN servers simply refusing to cre= ate
permissions for candidates they know they won't be able to reach?

That is one potential solution, which would solv= e #1/#4/#5.
--bcaec548a8214dbe34051cadf779-- From nobody Thu Aug 6 19:25:22 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3F61B4069 for ; Thu, 6 Aug 2015 19:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ7UyE9Ru9Me for ; Thu, 6 Aug 2015 19:25:18 -0700 (PDT) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386F31B4065 for ; Thu, 6 Aug 2015 19:25:18 -0700 (PDT) Received: by obbfr1 with SMTP id fr1so33093303obb.1 for ; Thu, 06 Aug 2015 19:25:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bYdfo3I6vDImBvXmPvh2vGuDIbWwHwXpG6o3Aa7z7tU=; b=EXqTbj8h5Eh9g/k3sDbXg7cquXG5+IhrS+mnL9bBI5Pj8Zk5ktsm2klhD7KozbsNy4 rhPcVSOgh28r/5/Ir1pYrlZeFkYQ0jOGhKFwbxF+Pe6k9w+vcmh60OQBX1JZLj8ARyzb u0qopoDkAw35pdAtVusJqBWVUbjQMS2Peq2Z5UCx+bWTE8bFB4rhExxGTtgd9eYuVg2M oPbQYcYb8Xvzt8KElVeqeV3zlbwFDpz5ZlYWX8o2odPIxgelVkhT0IypeAEKjXPmRd1o t3T8P38OHNbNiy55DPI0+JuVPhIS3ju3xWaafAiJhUo73kZl6s2ZyJTEVHp6WBVTCaJl 09JQ== X-Gm-Message-State: ALoCoQlk2UzZJjl9Cc/t7ad8V6DUksgx2fRFVToFzI8yxOGtJcRNxjmLYqqU5lnlQLsoFmigTQBN X-Received: by 10.60.69.39 with SMTP id b7mr4406902oeu.51.1438914317738; Thu, 06 Aug 2015 19:25:17 -0700 (PDT) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com. [209.85.218.44]) by smtp.gmail.com with ESMTPSA id x10sm5262126oif.5.2015.08.06.19.25.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Aug 2015 19:25:17 -0700 (PDT) Received: by oiev193 with SMTP id v193so18887361oie.3 for ; Thu, 06 Aug 2015 19:25:16 -0700 (PDT) X-Received: by 10.202.77.144 with SMTP id a138mr4313768oib.32.1438914316644; Thu, 06 Aug 2015 19:25:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.83.167 with HTTP; Thu, 6 Aug 2015 19:24:57 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: Emil Ivov Date: Thu, 6 Aug 2015 19:24:57 -0700 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jonathan Lennox , mmusic , Martin Thomson , "tram@ietf.org" , "rtcweb@ietf.org" Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 02:25:20 -0000 On Thu, Aug 6, 2015 at 5:46 PM, Justin Uberti wrote: > > > On Thu, Aug 6, 2015 at 5:11 PM, Emil Ivov wrote: >> >> On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti wrote: >> > >> > >> > On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson >> > >> > wrote: >> >> >> >> On 6 August 2015 at 13:08, Justin Uberti wrote: >> >> > I think that we should be able to avoid pairing candidates obtained >> >> > from >> >> > application TURN servers with RFC 1918 addresses. The app/browser >> >> > clearly >> >> > knows which is which. >> >> >> >> I'm concerned here that if we let the application choose, we lose the >> >> defence we were looking to gain. I think that perhaps 1918 pairing >> >> could be restricted to TURN servers that are configured/discovered, >> >> "proxy"-style. >> > >> > >> > Sorry, that is what I was trying to say. The browser knows which turn >> > servers are "proxies" vs app servers, and can apply the 1918 filtering >> > on >> > the pairings from the candidates from the app TURN server. >> >> I don't think Jonathan's concerns only apply to proxies though. You >> can just as well have apps developed for specific networks and there >> is no reason to prevent those from working. >> >> > Agree with your enumeration of concerns as well. Also #5, they consume >> > bandwidth (at least from client to TURN server), which affects maximum >> > check >> > rate in some cases. >> >> Why can't we address this by TURN servers simply refusing to create >> permissions for candidates they know they won't be able to reach? > > > That is one potential solution, which would solve #1/#4/#5. So, let's say that Alice calls Bob using SuperApp. Alice sends her 10.0.0.1 address to SuperApp's server, which then sends it to Bob. So Bob and SuperApp now know about Alice's 10.0.0.1 but there's no way around this. Bob, could be in the same network as Alice so it has to try her private address. Next, Bob installs 10.0.0.1 on the TURN server provided by SuperApp, which also now learns about 10.0.0.1. As long as that server is hosted by the same people as SuperApp (which we can probably consider as the common case) then we haven't leaked anything. If the TURN server is hosted by a third party (SuperTURN) then SuperTURN do get to learn a little bit of extra information, namely that Alice's public address has a private network in the 10.0.0.0 range behind it and that 10.0.0.1 is being used by someone. That's all though. SuperTURN should have no other information regarding Alice and what little it just learned was not hard to guess any way. So I am not sure exactly what we are trying to solve here. Emil -- https://jitsi.org From nobody Fri Aug 7 00:47:41 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688A41B381E; Fri, 7 Aug 2015 00:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDPXeSSC28CL; Fri, 7 Aug 2015 00:47:36 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510961B3817; Fri, 7 Aug 2015 00:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24592; q=dns/txt; s=iport; t=1438933656; x=1440143256; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9N81s85Sn+NI7nU9oy8haMMLbh6itUeUvZTrZIxUceg=; b=c9pQG4SbdyfrCeGJKkk5eR+1hRwItCkVOj7fvEbkp8nND8VgOEvkXU0N gyZzYSuvyY4BdSmX0oKNMkD20u3w+tzkuLU2OTyvybvFtYcCwarFSGddD QvofPUn+S0gd3JLy3HVxX54RG+7ukR1oau7BGF+ajvKZDQGCZqu9N48cc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8BQAZYcRV/4QNJK1bgk5NVGkGgx26AYF6AQmFL0oCHIEkOhIBAQEBAQEBgQqEJAEBBAEBASBJAggDEAIBCA4qBwMCAgIfBgsUEQIEDgWIGQMSDbcqkHANhSwBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItPgk+Bb0cEB4JpL4EUBZUHAYR+hW+Ba4FHkHyDTYNkJoN9b4FIgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,628,1432598400"; d="scan'208,217";a="176330403" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP; 07 Aug 2015 07:47:35 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t777lZXI029690 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Aug 2015 07:47:35 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 7 Aug 2015 02:47:34 -0500 Received: from xhc-aln-x06.cisco.com (173.36.12.80) by xch-rcd-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 7 Aug 2015 02:47:34 -0500 Received: from xmb-rcd-x06.cisco.com ([169.254.6.133]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0248.002; Fri, 7 Aug 2015 02:47:34 -0500 From: "Pal Martinsen (palmarti)" To: Emil Ivov Thread-Topic: [rtcweb] [tram] TURN permissions for private ips Thread-Index: AQHQ0KQ4GdSUE5mBkES+Q0lZrOYQnJ3//dsAgAB/T4A= Date: Fri, 7 Aug 2015 07:47:33 +0000 Message-ID: <3F10035A-70A4-46AE-AB44-4499541AC7C6@cisco.com> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.23] Content-Type: multipart/alternative; boundary="_000_3F10035A70A446AEAB444499541AC7C6ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Jonathan Lennox , "rtcweb@ietf.org" , "tram@ietf.org" , mmusic , Justin Uberti Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 07:47:38 -0000 --_000_3F10035A70A446AEAB444499541AC7C6ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAwNyBBdWcgMjAxNSwgYXQgMDI6MTEsIEVtaWwgSXZvdiA8ZW1jaG9Aaml0c2kub3JnPG1h aWx0bzplbWNob0BqaXRzaS5vcmc+PiB3cm90ZToNCg0KT24gVGh1LCBBdWcgNiwgMjAxNSBhdCA1 OjAxIFBNLCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlA Z29vZ2xlLmNvbT4+IHdyb3RlOg0KDQoNCk9uIFRodSwgQXVnIDYsIDIwMTUgYXQgMTo1MSBQTSwg TWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRo b21zb25AZ21haWwuY29tPj4NCndyb3RlOg0KDQpPbiA2IEF1Z3VzdCAyMDE1IGF0IDEzOjA4LCBK dXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNv bT4+IHdyb3RlOg0KSSB0aGluayB0aGF0IHdlIHNob3VsZCBiZSBhYmxlIHRvIGF2b2lkIHBhaXJp bmcgY2FuZGlkYXRlcyBvYnRhaW5lZCBmcm9tDQphcHBsaWNhdGlvbiBUVVJOIHNlcnZlcnMgd2l0 aCBSRkMgMTkxOCBhZGRyZXNzZXMuIFRoZSBhcHAvYnJvd3Nlcg0KY2xlYXJseQ0Ka25vd3Mgd2hp Y2ggaXMgd2hpY2guDQoNCkknbSBjb25jZXJuZWQgaGVyZSB0aGF0IGlmIHdlIGxldCB0aGUgYXBw bGljYXRpb24gY2hvb3NlLCB3ZSBsb3NlIHRoZQ0KZGVmZW5jZSB3ZSB3ZXJlIGxvb2tpbmcgdG8g Z2Fpbi4gIEkgdGhpbmsgdGhhdCBwZXJoYXBzIDE5MTggcGFpcmluZw0KY291bGQgYmUgcmVzdHJp Y3RlZCB0byBUVVJOIHNlcnZlcnMgdGhhdCBhcmUgY29uZmlndXJlZC9kaXNjb3ZlcmVkLA0KInBy b3h5Ii1zdHlsZS4NCg0KDQpTb3JyeSwgdGhhdCBpcyB3aGF0IEkgd2FzIHRyeWluZyB0byBzYXku IFRoZSBicm93c2VyIGtub3dzIHdoaWNoIHR1cm4NCnNlcnZlcnMgYXJlICJwcm94aWVzIiB2cyBh cHAgc2VydmVycywgYW5kIGNhbiBhcHBseSB0aGUgMTkxOCBmaWx0ZXJpbmcgb24NCnRoZSBwYWly aW5ncyBmcm9tIHRoZSBjYW5kaWRhdGVzIGZyb20gdGhlIGFwcCBUVVJOIHNlcnZlci4NCg0KSSBk b24ndCB0aGluayBKb25hdGhhbidzIGNvbmNlcm5zIG9ubHkgYXBwbHkgdG8gcHJveGllcyB0aG91 Z2guIFlvdQ0KY2FuIGp1c3QgYXMgd2VsbCBoYXZlIGFwcHMgZGV2ZWxvcGVkIGZvciBzcGVjaWZp YyBuZXR3b3JrcyBhbmQgdGhlcmUNCmlzIG5vIHJlYXNvbiB0byBwcmV2ZW50IHRob3NlIGZyb20g d29ya2luZy4NCg0KQWdyZWUgd2l0aCB5b3VyIGVudW1lcmF0aW9uIG9mIGNvbmNlcm5zIGFzIHdl bGwuIEFsc28gIzUsIHRoZXkgY29uc3VtZQ0KYmFuZHdpZHRoIChhdCBsZWFzdCBmcm9tIGNsaWVu dCB0byBUVVJOIHNlcnZlciksIHdoaWNoIGFmZmVjdHMgbWF4aW11bSBjaGVjaw0KcmF0ZSBpbiBz b21lIGNhc2VzLg0KDQpXaHkgY2FuJ3Qgd2UgYWRkcmVzcyB0aGlzIGJ5IFRVUk4gc2VydmVycyBz aW1wbHkgcmVmdXNpbmcgdG8gY3JlYXRlDQpwZXJtaXNzaW9ucyBmb3IgY2FuZGlkYXRlcyB0aGV5 IGtub3cgdGhleSB3b24ndCBiZSBhYmxlIHRvIHJlYWNoPw0KDQpIb3cgZG8geW91IHJlbGlhYmx5 IGFuZCBzaW1wbHkgZG8gdGhhdCB3aXRob3V0IGEgY29ubmVjdGl2aXR5IGNoZWNrPw0KDQpJZiB0 aGUgbWFpbiBjb25jZXJuIGlzIGluZm9ybWF0aW9uIGxlYWthZ2UsIGlzbuKAmXQgdGhhdCB1cCB0 byB0aGUgY2xpZW50IHRvIGRlY2lkZSB3aGF0IGl0IHdhbnQgdG8gcmV2ZWFsIHRvIHRoZSBUVVJO IHNlcnZlciBhbmQgdGhlIHJlbW90ZSBjbGllbnQ/DQoNCkd1ZXNzIHdoYXQgSSBhbSBzYXlpbmcg aXMgdGhhdCBJIHRoaW5rIGl0IGlzIGEgZ29vZCB0aGluZyB0byBoYXZlIGEg4oCcdGhpY2vigJ0g Y2xpZW50IGFuZCByZWxhdGl2ZWx5IHNpbXBsZSBuZXR3b3JrIGNvbXBvbmVudHMuDQoNCi4tLg0K UMOlbC1FcmlrDQoNCg0KRW1pbA0KDQotLQ0KaHR0cHM6Ly9qaXRzaS5vcmc8aHR0cHM6Ly9qaXRz aS5vcmcvPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= --_000_3F10035A70A446AEAB444499541AC7C6ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAwNyBB dWcgMjAxNSwgYXQgMDI6MTEsIEVtaWwgSXZvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVtY2hvQGpp dHNpLm9yZyIgY2xhc3M9IiI+ZW1jaG9Aaml0c2kub3JnPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8 YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+T24NCiBUaHUsIEF1ZyA2LCAyMDE1IGF0IDU6MDEg UE0sIEp1c3RpbiBVYmVydGkgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29n bGUuY29tIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmp1YmVydGlA Z29vZ2xlLmNvbTwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6 IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Jmd0Ow0KIHdyb3Rl Ojwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiBUaHUsIEF1ZyA2LCAyMDE1 IGF0IDE6NTEgUE0sIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRo b21zb25AZ21haWwuY29tIiBjbGFzcz0iIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0 OzxiciBjbGFzcz0iIj4NCndyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCk9uIDYgQXVndXN0IDIwMTUgYXQgMTM6MDgsIEp1 c3RpbiBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIGNsYXNz PSIiPmp1YmVydGlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkkgdGhpbmsgdGhhdCB3ZSBzaG91bGQgYmUgYWJs ZSB0byBhdm9pZCBwYWlyaW5nIGNhbmRpZGF0ZXMgb2J0YWluZWQgZnJvbTxiciBjbGFzcz0iIj4N CmFwcGxpY2F0aW9uIFRVUk4gc2VydmVycyB3aXRoIFJGQyAxOTE4IGFkZHJlc3Nlcy4gVGhlIGFw cC9icm93c2VyPGJyIGNsYXNzPSIiPg0KY2xlYXJseTxiciBjbGFzcz0iIj4NCmtub3dzIHdoaWNo IGlzIHdoaWNoLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkkn bSBjb25jZXJuZWQgaGVyZSB0aGF0IGlmIHdlIGxldCB0aGUgYXBwbGljYXRpb24gY2hvb3NlLCB3 ZSBsb3NlIHRoZTxiciBjbGFzcz0iIj4NCmRlZmVuY2Ugd2Ugd2VyZSBsb29raW5nIHRvIGdhaW4u ICZuYnNwO0kgdGhpbmsgdGhhdCBwZXJoYXBzIDE5MTggcGFpcmluZzxiciBjbGFzcz0iIj4NCmNv dWxkIGJlIHJlc3RyaWN0ZWQgdG8gVFVSTiBzZXJ2ZXJzIHRoYXQgYXJlIGNvbmZpZ3VyZWQvZGlz Y292ZXJlZCw8YnIgY2xhc3M9IiI+DQomcXVvdDtwcm94eSZxdW90Oy1zdHlsZS48YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTb3JyeSwg dGhhdCBpcyB3aGF0IEkgd2FzIHRyeWluZyB0byBzYXkuIFRoZSBicm93c2VyIGtub3dzIHdoaWNo IHR1cm48YnIgY2xhc3M9IiI+DQpzZXJ2ZXJzIGFyZSAmcXVvdDtwcm94aWVzJnF1b3Q7IHZzIGFw cCBzZXJ2ZXJzLCBhbmQgY2FuIGFwcGx5IHRoZSAxOTE4IGZpbHRlcmluZyBvbjxiciBjbGFzcz0i Ij4NCnRoZSBwYWlyaW5ncyBmcm9tIHRoZSBjYW5kaWRhdGVzIGZyb20gdGhlIGFwcCBUVVJOIHNl cnZlci48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5J DQogZG9uJ3QgdGhpbmsgSm9uYXRoYW4ncyBjb25jZXJucyBvbmx5IGFwcGx5IHRvIHByb3hpZXMg dGhvdWdoLiBZb3U8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Y2FuDQoganVzdCBhcyB3ZWxs IGhhdmUgYXBwcyBkZXZlbG9wZWQgZm9yIHNwZWNpZmljIG5ldHdvcmtzIGFuZCB0aGVyZTwvc3Bh bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5pcw0KIG5vIHJlYXNvbiB0byBwcmV2ZW50IHRob3NlIGZy b20gd29ya2luZy48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQpBZ3JlZSB3aXRoIHlvdXIgZW51bWVyYXRpb24gb2YgY29uY2VybnMgYXMgd2VsbC4g QWxzbyAjNSwgdGhleSBjb25zdW1lPGJyIGNsYXNzPSIiPg0KYmFuZHdpZHRoIChhdCBsZWFzdCBm cm9tIGNsaWVudCB0byBUVVJOIHNlcnZlciksIHdoaWNoIGFmZmVjdHMgbWF4aW11bSBjaGVjazxi ciBjbGFzcz0iIj4NCnJhdGUgaW4gc29tZSBjYXNlcy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv dGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5s aW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5XaHkNCiBjYW4ndCB3ZSBhZGRyZXNzIHRoaXMgYnkg VFVSTiBzZXJ2ZXJzIHNpbXBseSByZWZ1c2luZyB0byBjcmVhdGU8L3NwYW4+PGJyIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg Y2xhc3M9IiI+cGVybWlzc2lvbnMNCiBmb3IgY2FuZGlkYXRlcyB0aGV5IGtub3cgdGhleSB3b24n dCBiZSBhYmxlIHRvIHJlYWNoPzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PkhvdyBkbyB5b3UgcmVsaWFibHkgYW5k IHNpbXBseSBkbyB0aGF0IHdpdGhvdXQgYSBjb25uZWN0aXZpdHkgY2hlY2s/PC9kaXY+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JZiB0aGUgbWFpbiBjb25jZXJuIGlzIGluZm9y bWF0aW9uIGxlYWthZ2UsIGlzbuKAmXQgdGhhdCB1cCB0byB0aGUgY2xpZW50IHRvIGRlY2lkZSB3 aGF0IGl0IHdhbnQgdG8gcmV2ZWFsIHRvIHRoZSBUVVJOIHNlcnZlciBhbmQgdGhlIHJlbW90ZSBj bGllbnQ/PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5HdWVzcyB3aGF0 IEkgYW0gc2F5aW5nIGlzIHRoYXQgSSB0aGluayBpdCBpcyBhIGdvb2QgdGhpbmcgdG8gaGF2ZSBh IOKAnHRoaWNr4oCdIGNsaWVudCBhbmQgcmVsYXRpdmVseSBzaW1wbGUgbmV0d29yayBjb21wb25l bnRzLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Li0uPC9kaXY+DQo8 ZGl2PlDDpWwtRXJpayZuYnNwOzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+RW1pbDwvc3Bhbj48YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi Pi0tPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9 Imh0dHBzOi8vaml0c2kub3JnLyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz cz0iIj5odHRwczovL2ppdHNpLm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnJ0 Y3dlYg0KIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+cnRjd2ViQGlldGYub3JnPC9hPjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWI8L2E+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3F10035A70A446AEAB444499541AC7C6ciscocom_-- From nobody Sun Aug 9 06:38:48 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378771B2CEC for ; Sun, 9 Aug 2015 06:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.764 X-Spam-Level: * X-Spam-Status: No, score=1.764 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuyI0aulyPYJ for ; Sun, 9 Aug 2015 06:38:44 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 709D11B2CEB for ; Sun, 9 Aug 2015 06:38:42 -0700 (PDT) Received: from [IPv6:2602:61:7515:ec00:b8f3:f1bd:b3e:81db] (unknown [IPv6:2602:61:7515:ec00:b8f3:f1bd:b3e:81db]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id DCC7020140; Sun, 9 Aug 2015 15:38:40 +0200 (CEST) To: =?UTF-8?Q?Stefan_M=c3=b6hl?= , "tram@ietf.org" References: From: Marc Petit-Huguenin X-Enigmail-Draft-Status: N1110 Message-ID: <55C757DE.0@acm.org> Date: Sun, 9 Aug 2015 07:38:38 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] TRAM, WebRTC and DHT X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 13:38:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Stephan, On 07/29/2015 08:53 AM, Stefan Möhl wrote: > If this is the wrong forum for my question, please accept my > apologies! > > If I understand things correctly, this IETF group is working on the > next-gen STUN/TURN protocol. There has also been some work on using > DHT, at least for STUN; see, i.e. > http://www.labri.fr/perso/tad/download/rapport_PFE_pierre.pdf or > https://www.google.se/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCEQFjAAahUKEwijo8OK3_vGAhXGXCwKHWVaDcg&url=http%3A%2F%2Fmaidsafe.net%2FWhitepapers%2Fpdf%2FDHTbasedNATTraversal.pdf&ei=1V22VePkNca5sQHltLXADA&usg=AFQjCNGh2Fv1ig5-gPEV6O_kGeDkb8CRdA&sig2=UCrPnRo64-TG5-3DgYclqQ&bvm=bv.98717601,d.bGg > > Since a strong motivation for TRAM, as I understand it, is the shift > towards using STUN/TURN for WebRTC, and the big value in WebRTC is > the almost serverless nature of WebRTC, I was wondering if this group > is taking DHT into consideration? I do not think that the big value in WebRTC is that it is serverless - it is not. The peer-to-peer nature of the media path between browsers is one of convenience, because using a centralized model requires resources and has qos consequences. The one and only reason for WebRTC is to not have to install additional software, but the underlying model is still the same than before. P2PSIP was an interesting approach to break that model, and we all know where it went. A long time ago I did some preliminary work on how to use WebRTC with RELOAD, but it is near impossible to get any funding in this area, so I had to give up. > If at least the signaling server > and the STUN server could be shifted to DHT, WebRTC could become > truly serverless for the majority of users that do not require a TURN > server, and thereby extremely resilient! P2PSIP did exactly that, by having TURN servers discoverable through a DHT (see RFC 6940 section 9). Perhaps that should be added to draft-ietf-tram-turn-server-discovery. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVx1feAAoJECnERZXWan7EqCMQAJskt0pN8/vrvv3VKkEHcaxE K84lmRxfVgxaG8QdutgMtsydbPo18lWiR5l8OBiYNWU/K0TmokUDgidVmkQGwRId a85FIwJhWHHiidqHAIEuSGCeV7zUAyRZ8jcrKvUFv0XoDdakPZSxdYjAWp4HLfSQ NWeGOH1PU85x5OO5YDxIm1/zm29Dzq9TL6eG940elv53dt1T0YAqOMBM8PWAbPYA 6WbDEcjsfC/70ErwSxI/ZMvIj1Bj4XD70EMIDvyldSp9jtbectgNIVvgqxxG7vJl 6Iqli6GyyIIUQR01nPZnEQs3ErL26O+36OaWY1KXlhyNEOU/09N1X7mZYbd+VoTW 6aejVKjt3Q3FtY1Zun8Ze6JCD9YWe0UapF4S24bffmaaQI4kmnpgezgMOCUkxI1+ UU/ZHJU+bRSz5q6sKo4nG2clF1m9paFlMqwOxi1VpY8TTnV1jwyJ0Pgsmb1GBM3x lhZHzIoA8dgzisCw93QXIUDRuW0c+mXIGD4Q2PHVYa5s7faYF1bEoMXN0t3x0n24 PAjW6LuY8fhbzDapqY9smqWnPNRyWUtSAoFOGF9tHD6+O6ROhtQp1hh0cGpdMPLS QuIuAWCcA0vWsV9x6/K8V1X57RBGiejc4Z7vtPIzRY/ihPb5r3znKARewvwM5F+K ELzU77wMeYt9HDjXLlbx =T/JO -----END PGP SIGNATURE----- From nobody Tue Aug 11 06:32:37 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461481A8A91 for ; Tue, 11 Aug 2015 06:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvhsifykOurZ for ; Tue, 11 Aug 2015 06:32:34 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AFB1A8A89 for ; Tue, 11 Aug 2015 06:32:33 -0700 (PDT) Received: by obnw1 with SMTP id w1so147738246obn.3 for ; Tue, 11 Aug 2015 06:32:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=oBog2TBuvP1PhJ8odLGCSgBFb7+sT5hGtDUVYq1FoOU=; b=inVWvNlvpljCrElkCpCzKa2KrQcmUrynOvuaP88FSbD/O0pKWw2uoKnt2P51nNcZ2m S0pDUZmfIIdjUTX1r1QJEZqYGwk8VNdam+bBoPvJLR+q6p+ov7xVDC+L/csFy1ANX1rE UWjpVD4XBUoSUAhkeUHpv/B8D1Qf45dO5w+ZU6f4/SW3f7vcvG39nu1ERJ0rE81zJ/9S N3TTXR9lslqHgSldtKM5hTttbrZkaQ/RkTEH65MegCd4Td5FKiaDZCOWejGg78qYy6Sb TibFZbTIS54FKMcK2lFkz2/cHni2zWiGBBX/SLnUlNafc2vKH1GyVeRjlbsvsxzU6I5g ad2w== X-Gm-Message-State: ALoCoQnCMlrS0Gcv4sRVx4fghyWmGnujY+ijmj+ZauZ7sm7i7RVL5KWjCm/41UJnrn/f/b5Rxr2m X-Received: by 10.60.52.110 with SMTP id s14mr13987390oeo.14.1439299952765; Tue, 11 Aug 2015 06:32:32 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com. [209.85.214.174]) by smtp.gmail.com with ESMTPSA id l5sm1620419oey.5.2015.08.11.06.32.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 06:32:31 -0700 (PDT) Received: by obbfr1 with SMTP id fr1so111098199obb.1 for ; Tue, 11 Aug 2015 06:32:30 -0700 (PDT) X-Received: by 10.182.215.226 with SMTP id ol2mr24296811obc.56.1439299950383; Tue, 11 Aug 2015 06:32:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.83.167 with HTTP; Tue, 11 Aug 2015 06:32:10 -0700 (PDT) In-Reply-To: <3F10035A-70A4-46AE-AB44-4499541AC7C6@cisco.com> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> <3F10035A-70A4-46AE-AB44-4499541AC7C6@cisco.com> From: Emil Ivov Date: Tue, 11 Aug 2015 08:32:10 -0500 Message-ID: To: "Pal Martinsen (palmarti)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jonathan Lennox , "rtcweb@ietf.org" , "tram@ietf.org" , mmusic , Justin Uberti Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 13:32:36 -0000 Hey Pal, On Fri, Aug 7, 2015 at 2:47 AM, Pal Martinsen (palmarti) wrote: > > On 07 Aug 2015, at 02:11, Emil Ivov wrote: > > On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti wrote: > > > > On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson > wrote: > > > On 6 August 2015 at 13:08, Justin Uberti wrote: > > I think that we should be able to avoid pairing candidates obtained from > application TURN servers with RFC 1918 addresses. The app/browser > clearly > knows which is which. > > > I'm concerned here that if we let the application choose, we lose the > defence we were looking to gain. I think that perhaps 1918 pairing > could be restricted to TURN servers that are configured/discovered, > "proxy"-style. > > > > Sorry, that is what I was trying to say. The browser knows which turn > servers are "proxies" vs app servers, and can apply the 1918 filtering on > the pairings from the candidates from the app TURN server. > > > I don't think Jonathan's concerns only apply to proxies though. You > can just as well have apps developed for specific networks and there > is no reason to prevent those from working. > > Agree with your enumeration of concerns as well. Also #5, they consume > bandwidth (at least from client to TURN server), which affects maximum ch= eck > rate in some cases. > > > Why can't we address this by TURN servers simply refusing to create > permissions for candidates they know they won't be able to reach? > > How do you reliably and simply do that without a connectivity check? There are a few ways a TURN server could be smart about this (e.g. checking the routing table for local interfaces for example, or looking into ARP tables) but ultimately they should allow for this to be configured. > If the main concern is information leakage, isn=E2=80=99t that up to the = client to > decide what it want to reveal to the TURN server and the remote client? I don't know that the main concern is leakage (see my previous mail). I don't see how an application can be worried that the TURN server it chose is going to find out that there's one of three NATed ranged behind a certain IP. The TURN server had a 1 in 4 chance of guessing that even without the app. That said, I am not opposed to giving JavaScript apps a way to explicitly signal the stack not to pair certain addresses with TURN. I just don't want the stack to assume this. Emil > Guess what I am saying is that I think it is a good thing to have a =E2= =80=9Cthick=E2=80=9D > client and relatively simple network components. > > .-. > P=C3=A5l-Erik > > > Emil > > -- > https://jitsi.org > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --=20 https://jitsi.org From nobody Thu Aug 13 16:22:59 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E7C1ACEBC for ; Thu, 13 Aug 2015 16:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAtY8exMxP_t for ; Thu, 13 Aug 2015 16:22:54 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779B01ACEB7 for ; Thu, 13 Aug 2015 16:22:54 -0700 (PDT) Received: by vkbg64 with SMTP id g64so10912324vkb.0 for ; Thu, 13 Aug 2015 16:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9+hGRRBfb5OinAaa5UBLca7nPDvPQquRQppVQGa8STw=; b=O2bNnwaRPqiv1SbpxmPS1psYgAbAaMPbMb6yk5sULP4gV5qLIv++ZYhLchha+cq4Wv c8uveFpH4nPDhYOTD3vQX8eK8vwU3DX3T7C7OY/Rs3O7c8zyaWgTk4rAcGo5mIkD/Kgg fKcjXq5HTxNFH4jWR2hhfDZK0ptIN62xHRIYIyI9UiMB6vyusmTukKa9k4aibQA6TcXz /ghd4e1GpRd/MOB61Z+FCPVn/7VRo2L2YcCXZk9EpIuB6ZB7FdOduzBD6VUfyxBY3YrX 5cTAKeqy60AK2pNzsBRuk+1iyLPi0opnwTUf1g/TdiyCCp3bavyrGgW74rx559JTgk9Q aVGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9+hGRRBfb5OinAaa5UBLca7nPDvPQquRQppVQGa8STw=; b=caZ1tPIauQpnLPXkTVlarORmVkXMoe0UACFuBVkmjTYLzVbiLI2ueogrIlNjcd1SlT 3Ch9TtcuU9YXkEk7cScbsoggzARo3q1jVdmNggYtbXZovJXew4Z66jBOhSjOqpSb1q89 HFOgbmihAcYnr1jKpJbkgvD5oY0qzFK1YsWYDmg9Ib9PzIv02p86KrvoiPXXtBA8u/sN T33gIypiFndqOfDhRvnh9JNxirJISJ2jjW6NfZRC51+hOCcW1gTERV9hNXd8B/Q9/PEd k5HZe+P47anvGLp0UqDki2nrXhlDYwEBqgneWTdBmbAv06tQpHVr+Q1iPQofn83It1Wu 9ELA== X-Gm-Message-State: ALoCoQkmuWDD42o0FOnJiHfgkH6KvN11hGDVy99EctsooovBjk4gACBkCCwvhpHq0N7UwRDi7U6J X-Received: by 10.52.116.67 with SMTP id ju3mr50119033vdb.66.1439508173584; Thu, 13 Aug 2015 16:22:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.87 with HTTP; Thu, 13 Aug 2015 16:22:34 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> <3F10035A-70A4-46AE-AB44-4499541AC7C6@cisco.com> From: Justin Uberti Date: Thu, 13 Aug 2015 16:22:34 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=bcaec548aa5956a37e051d399d4b Archived-At: Cc: Jonathan Lennox , "Pal Martinsen \(palmarti\)" , "rtcweb@ietf.org" , mmusic , "tram@ietf.org" Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 23:22:56 -0000 --bcaec548aa5956a37e051d399d4b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For now I think we will follow the suggestion of letting the server enforce this policy, and return 403 in the case where the target IP would be considered unreachable by the server. Chrome will also need to be updated to actually do the right thing on this 403... On Tue, Aug 11, 2015 at 6:32 AM, Emil Ivov wrote: > Hey Pal, > > On Fri, Aug 7, 2015 at 2:47 AM, Pal Martinsen (palmarti) > wrote: > > > > On 07 Aug 2015, at 02:11, Emil Ivov wrote: > > > > On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti > wrote: > > > > > > > > On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson > > > wrote: > > > > > > On 6 August 2015 at 13:08, Justin Uberti wrote: > > > > I think that we should be able to avoid pairing candidates obtained fro= m > > application TURN servers with RFC 1918 addresses. The app/browser > > clearly > > knows which is which. > > > > > > I'm concerned here that if we let the application choose, we lose the > > defence we were looking to gain. I think that perhaps 1918 pairing > > could be restricted to TURN servers that are configured/discovered, > > "proxy"-style. > > > > > > > > Sorry, that is what I was trying to say. The browser knows which turn > > servers are "proxies" vs app servers, and can apply the 1918 filtering = on > > the pairings from the candidates from the app TURN server. > > > > > > I don't think Jonathan's concerns only apply to proxies though. You > > can just as well have apps developed for specific networks and there > > is no reason to prevent those from working. > > > > Agree with your enumeration of concerns as well. Also #5, they consume > > bandwidth (at least from client to TURN server), which affects maximum > check > > rate in some cases. > > > > > > Why can't we address this by TURN servers simply refusing to create > > permissions for candidates they know they won't be able to reach? > > > > How do you reliably and simply do that without a connectivity check? > > There are a few ways a TURN server could be smart about this (e.g. > checking the routing table for local interfaces for example, or > looking into ARP tables) but ultimately they should allow for this to > be configured. > > > If the main concern is information leakage, isn=E2=80=99t that up to th= e client > to > > decide what it want to reveal to the TURN server and the remote client? > > I don't know that the main concern is leakage (see my previous mail). > I don't see how an application can be worried that the TURN server it > chose is going to find out that there's one of three NATed ranged > behind a certain IP. The TURN server had a 1 in 4 chance of guessing > that even without the app. > > That said, I am not opposed to giving JavaScript apps a way to > explicitly signal the stack not to pair certain addresses with TURN. > > I just don't want the stack to assume this. > > Emil > > > Guess what I am saying is that I think it is a good thing to have a > =E2=80=9Cthick=E2=80=9D > > client and relatively simple network components. > > > > .-. > > P=C3=A5l-Erik > > > > > > Emil > > > > -- > > https://jitsi.org > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > > -- > https://jitsi.org > --bcaec548aa5956a37e051d399d4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For now I think we will follow the suggestion of letting t= he server enforce this policy, and return 403 in the case where the target = IP would be considered unreachable by the server.

Chrome= will also need to be updated to actually do the right thing on this 403...=

On Tu= e, Aug 11, 2015 at 6:32 AM, Emil Ivov <emcho@jitsi.org> wrote:=
Hey Pal,

On Fri, Aug 7, 2015 at 2:47 AM, Pal Martinsen (palmarti)
<palmarti@cisco.com> wrote:=
>
> On 07 Aug 2015, at 02:11, Emil Ivov <emcho@jitsi.org> wrote:
>
> On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti <juberti@google.com> wrote:
>
>
>
> On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>
> On 6 August 2015 at 13:08, Justin Uberti <juberti@google.com> wrote:
>
> I think that we should be able to avoid pairing candidates obtained fr= om
> application TURN servers with RFC 1918 addresses. The app/browser
> clearly
> knows which is which.
>
>
> I'm concerned here that if we let the application choose, we lose = the
> defence we were looking to gain.=C2=A0 I think that perhaps 1918 pairi= ng
> could be restricted to TURN servers that are configured/discovered, > "proxy"-style.
>
>
>
> Sorry, that is what I was trying to say. The browser knows which turn<= br> > servers are "proxies" vs app servers, and can apply the 1918= filtering on
> the pairings from the candidates from the app TURN server.
>
>
> I don't think Jonathan's concerns only apply to proxies though= . You
> can just as well have apps developed for specific networks and there > is no reason to prevent those from working.
>
> Agree with your enumeration of concerns as well. Also #5, they consume=
> bandwidth (at least from client to TURN server), which affects maximum= check
> rate in some cases.
>
>
> Why can't we address this by TURN servers simply refusing to creat= e
> permissions for candidates they know they won't be able to reach?<= br> >
> How do you reliably and simply do that without a connectivity check?
There are a few ways a TURN server could be smart about this (e= .g.
checking the routing table for local interfaces for example, or
looking into ARP tables) but ultimately they should allow for this to
be configured.

> If the main concern is information leakage, isn=E2=80=99t that up to t= he client to
> decide what it want to reveal to the TURN server and the remote client= ?

I don't know that the main concern is leakage (see my previous m= ail).
I don't see how an application can be worried that the TURN server it chose is going to find out that there's one of three NATed ranged
behind a certain IP. The TURN server had a 1 in 4 chance of guessing
that even without the app.

That said, I am not opposed to giving JavaScript apps a way to
explicitly signal the stack not to pair certain addresses with TURN.

I just don't want the stack to assume this.

Emil

> Guess what I am saying is that I think it is a good thing to have a = =E2=80=9Cthick=E2=80=9D
> client and relatively simple network components.
>
> .-.
> P=C3=A5l-Erik
>
>
> Emil
>
> --
> htt= ps://jitsi.org
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >
>



--
https://= jitsi.org

--bcaec548aa5956a37e051d399d4b-- From nobody Thu Aug 13 17:06:55 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8275F1ACF6C for ; Thu, 13 Aug 2015 17:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMt7IioIFzoc for ; Thu, 13 Aug 2015 17:06:43 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7581AD049 for ; Thu, 13 Aug 2015 17:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=100170; q=dns/txt; s=iport; t=1439510803; x=1440720403; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wvT/PJIIHKvd4C7mbw01eQ0G86rKe9lImgX+5M7UC1c=; b=TGdb6CfBBiW5kZGpGM5UVgBOZbKZXq5URTfha+fqFvJhMfyWNqIzxktn mSHW8sC9CvV2C4uQ7Lj1x/p1/prbaWOv9KYbiI/kVj05S2W7gzga/Ag6t O2oVRSLvcVi3X3wLg2YvDjfKVY/8XOwXzMbD5XJN0h31CylsjnyYWV5J3 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DxBwCWL81V/5BdJa1TCoJOTVRpBr1Pgh8BCYJDgmxKAoFIOxEBAQEBAQEBgQqEJAEBBAEBARcBDAZBCxACAQg4AQYHJwsUEQIEAQ0FiC4N0GsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXilCBA4QmBgsBBkcEBgEJhCMFhxuGaocVAYUDgiiFQIFKRoNlgxmNL4NnERWCDhyBU3GBBwcXBxyBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,673,1432598400"; d="scan'208,217";a="178557086" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Aug 2015 00:06:41 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t7E06fP6030742 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2015 00:06:41 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 13 Aug 2015 19:06:39 -0500 Received: from xhc-rcd-x15.cisco.com (173.37.183.89) by xch-rcd-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 13 Aug 2015 19:06:39 -0500 Received: from xmb-rcd-x07.cisco.com ([169.254.7.106]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0248.002; Thu, 13 Aug 2015 19:06:39 -0500 From: "Prashanth Patil (praspati)" To: Karl Stahl , "Tirumaleswar Reddy (tireddy)" , "'Simon Perreault'" , "'Benjamin Schwartz'" , "Cullen Jennings (fluffy)" , "'Adam Roach'" Thread-Topic: [tram] last call on this draft: draft-ietf-tram-turn-server-discovery-03 Thread-Index: AQHQ1iUXJx1Ac0hIpUq+Zo9HYRlOvA== Date: Fri, 14 Aug 2015 00:06:39 +0000 Message-ID: References: <022601d0c251$9e1944a0$da4bcde0$@stahl@intertex.se> In-Reply-To: <022601d0c251$9e1944a0$da4bcde0$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [173.36.7.21] Content-Type: multipart/alternative; boundary="_000_D1F24F20AC72Dpraspaticiscocom_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] last call on this draft: draft-ietf-tram-turn-server-discovery-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 00:06:52 -0000 --_000_D1F24F20AC72Dpraspaticiscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Karl, Appreciate the review. Responses inline. On 7/19/15, 11:34 AM, "tram on behalf of Karl Stahl" on behalf of karl.stahl@intertex.se> wrote: I don=92t think draft-ietf-tram-turn-server-discovery-03 draft is not clear= enough yet. Hopefully the my suggestions below are non-controversial, only improvements= , so we can make this draft an RFC as soon as possible. The following should be read in the context of the email below to the RTCWE= B WG. 1) The result of the valid discussion/concerns Ending at: https://mailarchive.ietf.org/arch/msg/tram/W49pCoOHQu2mE-RxokMbq= 1FmpOg about how to achieve auto-configuration (e.g. necessary for good and secure= use of WebRTC on mobile devices) and the consequent necessity to be able t= o use the auto discovered TURN server without credentials, and further that= a locally placed turn can achieve this by being available only from a trus= ted network, should be clarified and for which discovery methods it is achieved. Sure, we could add some text around this, but I don=92t think we should get= into too much this. You could discover other TURN servers that may not req= uire credentials, from your ISP, perhaps. 2) Tiru, you and I have had some discussion a year ago or so about (From 1.= Introduction): =93The reason for providing multiple mechanisms is to maximize the opportun= ity for discovery, based on the network in which the TURN client finds itse= lf.=94 I questioned whether that goal really can be achieved unless we mandate (MU= ST implement) common methods, and whether it is up to this draft or some RT= CWEB draft to be responsible for that. With the appearance of draft-ietf-rtcweb-return-00 draft-jennings-behave-rtcweb-firewall-00 we now have a chance to clarify this. The latest draft states that a client SHOULD implement all methods for best= results. It is up to the client, really. And as you point out, based on ap= plication requirements, a client could implement all or prioritize one over= the others. I fully agree with the goal and necessity of this draft, but suggest some r= ephrasing of the Introduction: =93To allow TURN applications operate real-time traffic seamlessly across d= ifferent types of networks and encourage by the use of TURN without the nee= d for manual configuration, it is important that there exists an auto disco= very mechanism for TURN services. Real-time applications and specifically W= eb Real-Time Communication (WebRTC)[I-D.ietf-rtcweb-overview] usages and re= lated extensions, which are mostly based on web applications, need this imm= ediately. And that the =93multiple mechanism=94 sentence is replaced by: =93This document recommends multiple discovery mechanism, and advices about= security such as trust and privacy as well as deployment efforts. It is up= to the specific real-time application recommendation and its use case to s= elect from these recommendations and advices.=94 Sure, we'll add your recommended text in the draft. draft-ietf-rtcweb-return-00 can then specify how the browser shall implemen= t auto discovery for WebRTC and draft-jennings-behave-rtcweb-firewall-00 can then advice firewall vendo= rs how to achieve the goals of this draft Could you please comment on each draft separately? Tracking and following u= p becomes much simpler. 3) The concept of =93sealed=94, =93leaky=94 and =93exo-leaky=94 (see discus= sion below), the Recursively Encapsulated method and Border TURN server sho= uld be mentioned and conform with draft-ietf-rtcweb-return-00. 4) Explain that the leakiness for a discovered local TURN server can be aut= o configured. E.g.: =93The default gateway router/firewall can block STUN packets by looking fo= r the magic STUN cookie, by closing port 3478 or by closing all UDP traffic= , to enforce an exo-sealed configuration for a TURN client having a leaky d= efault configuration, thus improving security, while avoiding the overhead = of sending the real-time traffic through the TURN server (twice) with seale= d a TURN client configuration (as explained in draft-ietf-rtcweb-return-00)= . 5) After =936. Discovery using Anycast=94 section, add a variant: Implicit discovery by interception of TURN allocate requests at a default g= ateway An enterprise firewall or a network server provider=92s router at a default= gateway can intercept a TURN allocate request and respond with a 300 (Try = Alternate) just as described in the Anycast method above. The following pro= cedures and advantages are inherited from the anycast method. This variant adds the following features: - no separate deployment of discovery mechanism is required - no ANA allocated anycast address is required (works with any public ip ad= dress) - the default gateway router/firewall in charge of the local network respon= ds with the ip address of: (i) a Border TURN server (paralleling the default gateway), or (ii) a TURN server behind that firewall/default gateway and opens a path t= o that TURN server - if the intercepted allocate request was intended for an application provi= ded TURN server, the TURN client (e.g. WebRTC browser) on behalf of the use= r, can select to: (iii) only use the auto discovered TURN server (iv) honor an allocation request by really sending the real-time traffic t= o the Application Provided TURN server, using the Recursively Encapsulated = method, unless (v) the TURN server connected in (ii) already is the Application Provide= d TURN server Security wise, the right party is in charge in all cases. Not really, you=92re intercepting traffic not meant for you. Why can=92t th= e gateway router just listen on the designated anycast address instead? A TURN server pinpointed by a firewall/router at the default gateway should= always be trusted (no explicit authentication with credentials is needed) = and used. (We trust the default gateway with all our traffic anyway, and an= y evil intent to disturb real-time traffic can in such case be implemented = in a default gateway by easier means.) - the TURN server pinpointed by a default gateway shall always be trusted a= nd used and the security methods under 9.3 will not have to be applied. [Some of these features should be repeated under the Deployment and Securit= y sections] 6) Under =937. Deployment Considerations=94, the ease of the Anycast method= and suggested variant could be pointed out. Those methods can be used over= any network and by TURN clients under common operating systems. It should be adviced to configure discovered TURN servers to be allowed to = be used without credentials for the users that they are intended to serve, = to achieve the goal of this draft (simply by make the TURN server available= to allocate from, only on the network it is supposed to serve, thus no cre= dentials are needed to protect the TURN server resource as with the applica= tion provided TURN servers). What about the following text? NEW: Clients can use TURN servers provided by the local network or by the access= network without authenticating with the TURN server. It is recommended tha= t clients use (D)TLS with network provided TURN servers to authenticate and= prevent man-in-middle attacks. The DHCP method may also be easy to deploy where used (e.g. Enterprise, Hom= e and WiFi). However, with IPV6, RA (Router Advertisement) is often used in= stead of DHCP to hand out ip addresses. The important mobile world (3G/4G/L= TE) has its own methods, and there are still PPoE and PPoA in use, where DH= CP cannot be used. If a network service provides announces a TURN server us= ing DHCP, the following firewall needs to pick that up and advice that to t= he users on the LAN. DHCP may not be available on some operating systems wh= ere the TURN client, specifically the WebRTC device, should be able to be i= mplemented on. If DHCP cannot be used in a specific network then other discovery mechanism= s discussed in the draft should be used. 7)I don=92t understand the sentences under =939. Security Considerations= =94 =93In general, it is recommended that a TURN client authenticate with the T= URN server to identify a rouge server. [RFC7350] can be potentially used by= a client to validate a previously unknown server.=94 It must be explained and detailed, how and what is authenticated or validat= ed, for what purpose and how this may help to achieve the goals of this rec= ommendation, or these sentences should simply be deleted. Sure, we=92ll add more text around authentication. -Prashanth I hope this improves this necessary and good draft and that it quickly can = be adopted. /Karl Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Karl Stahl Skickat: den 19 juli 2015 20:23 Till: 'Benjamin Schwartz'; 'Cullen Jennings (fluffy)' Kopia: rtcweb@ietf.org; tram@ietf.org =C4mne: Re: [tram] [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Config= uration and TURN discovery: Benjamin =96 your concern is valid =96 I thought exo-sealed was easy to do = in the browser. Below I list a firewall configuration assisted method to address the TURN s= erver and bandwidth resource consumption problem for local WebRTC calls whe= n using the sealed configuration. I believe my suggestion also will meet al= l security/trust/privacy perspectives and give secure auto-configuration, s= o mobile devices can to be used with high-quality secure WebRTC communicati= on =93everywhere you can surf=94 through proper use of Border TURN servers= - which must be the (almost already achieved) purpose of this RETURN draft= . After some consideration, to achieve the preferred exo-sealed configuration= , the RETURN drafts already prescribes the best default configuration: =93l= eaky=94 ! :-) Explanations inline below --> Below are also some suggestions for inclusion in the drafts: draft-ietf-tram-turn-server-discovery-03 draft-jennings-behave-rtcweb-firewall-00 /Karl PS: Regarding the TURN Origin debate, I don=92t have a clear view, but am I= not right in the understanding that: * The purpose of the TURN Origin draft was to reduce the pain of WebRTC se= rvice providers having to deploy network hardware (the Application Provided= TURN server) to get their services used, by allowing the TURN server to se= rve many applications (through a third party). - The introduction of Border TURN servers releases WebRTC service provider= s of that pain (when commonly deployed) (and also put security back in the = right place) (Until deployed commonly, yes these SPs unfortunately have thi= s pain to =93fool their services=94 through users security devices =96 the = firewalls (something which the discussed 3 drafts now finally can remedy (w= ithout the use of Origin)) * However, the Application Provided TURN server may also be for (from the R= ETURN draft: 3 Goals, 3.2 independent path control): o improving quality of service by tunneling packets through a network t= hat is faster than the public internet, + monitoring the usage of UDP services, + troubleshooting and debugging problematic services, + logging connection metadata for legal or auditing reasons, + recording the entire contents of all connections, or - providing partial IP address anonymization (as described in [I-D.ietf= -rtcweb-security] Section 4.2.4). (+ and =96 indicates the conflicting impact the use Origin will bring for t= he listed purposes) The RETURN draft honors the application=92s efforts to enforce media throug= h such Application Provided TURN server (without judging the purpose) (by u= se of the Recursively Encapsulation mechanism). My advice now is just to not introduce the Origin discussion in these draft= s where we finally have to resolve the firewall traversal problem with real= -time traffic. We need these RFCs in place as soon as ever possible. I see = a risk in that draft-jennings-behave-rtcweb-firewall-00 starts discussing O= rigin/SNI in an effort to make a pretty secure WebRTC aware firewall somewh= at more secure, and think the draft can advice firewall vendors how to buil= d firewalls that are fully secure and allows real-time traffic and should a= lso be able to provide a quality pipe for the real-time traffic. Origin/SNI= is not required for that. The Border TURN server and this RETURN-draft wil= l make that possible. -- > Don=92t forget the inline below -- > Fr=E5n: Benjamin Schwartz [mailto:bemasc@webrtc.org] Skickat: den 14 juli 2015 03:16 Till: Karl Stahl Kopia: rtcweb@ietf.org; tram@ietf.org =C4mne: Re: [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Configuration= and TURN discovery: On Mon, Jul 13, 2015 at 6:19 PM, Karl Stahl > wrote: We need this draft implemented in WebRTC browsers as soon as possible, so w= e can get good WebRTC in difficult places (for firewall traversal and for quality). Is there any implementation e.g. in Chrome that can be tried? Now having stated that I am positive to this draft, I have some concerns/questions/suggestions: 1) We need more levels than sealed/leaky It is not acceptable that WebRTC traffic between parties on a typical LAN i= s forced through a TURN server, just because of a sealed configuration required for good WebRTC traffic over the WAN. This consequence is pointed out under "5.11. Reusing the same TURN server", but IS a problem even if i= t "work as expected". Such TURN resource consumption, waste of bandwidth and possible performance degradation do not happen today, and can easily be avoided. I realize this consequence of "sealed" is required to meet some of the requirements under "3.2. Independent Path Control", but we simply need an "exo-sealed" level, in addition to the proposed strictly sealed and leaky, allowing local endpoints to connect media directly, while external traffic is forced to use the TURN server (rather than STUN through the default gateway). [BS] How do you propose to tell what is "local"? I don't know how to defin= e that procedurally. [BS] I think my main concern here is that it requires us to "lie" to the re= mote party, by sending candidates that we may then refuse to use even if th= ey work. This seems very strange. [Karl] You are right. I assumed the preferred exo-sealed behavior could be = achieved as easily as we do it =93hardware wise=94 today on the inside of o= ur open test-site https://webrtc.ingate.com where we have a border placed T= URN server paralleling our firewall/default gateway. Our firewall looks for= the magic STUN cookie and discards all STUN packets from the LAN side. TUR= N is then automatically enforced and today=92s leaky WebRTC browsers automa= tically get the preferred exo-sealed behavior. (Just not using STUN in the browser, would have the same effect but not ful= ly, if there are more subnets on the LAN side. Crossing those subnets would= then take media through the dual trip via the TURN server that I want to a= void.) So, let=92s enforce the preferred exo-sealed configuration by configuration= of the firewall/default gateway (Security from this perspective is then al= so in the right hands - the network admin=92s): - Today=92s RETURN-draft=92s leaky default configuration is OK (since the f= irewalls discarding STUN automatically enforce the preferred exo-sealed beh= avior) - Recommend in the RETURN-draft (and in draft-jennings-behave-rtcweb-firewa= ll-00) that the network admin discards STUN packets from the LAN side thro= ugh the default gateway (consent STUNs will go OK through the TURN server),= by looking for the magic STUN cookie, by closing port 3478 or by closing a= ll UDP (the restrictive enterprise firewall can simply be left as it is) to= achieve exo-sealed leakiness. - The network admin offers a Border TURN server for its network users (LAN = side only) =96 no need for authentication (free to use from LAN side being = a Border TURN server configuration) - The Border TURN server is offered by the network you are using =96 Just u= se it! (should the network provider have evil intentions, he needs no TURN = server, he can simply close or destroy WebRTC in the firewall if he which, = which Cullen just exemplified in draft-jennings-behave-rtcweb-firewall-00) As you may have noticed, I stress that NO credentials should be needed for = using an auto discovered border TURN server. That is also the goal of TRAM= =92s discovery draft, but I have asked TRAM to clarify that achievement. I= f we don=92t fix that, we have failed to make WebRTC usable on mobile devic= es =96 or can anyone explain where we would get those credentials from when= we run around and have Web access here and there and the goal of WebRTC wa= s to use real-time communication, securely and with high quality, everywher= e we can surf, wasn=92t it? If anyone cries that we NEED AUTHENTICATION, they should remember the IP au= thentication (simply being on a certain network) is the most commonly used = =93authentication method=94 today and protecting huge values (almost the wh= ole telco industry) and also achieves privacy (through the use of firewalls= ). No individual user credentials which are impossible to handle must be re= quired. I will in next email propose this new variant of the Anycast method to TRA= M. It should work, shouldn=92t it? And does it provide the claimed advantages/features? =96 please check. Implicit discovery by interception of TURN allocate requests at a default g= ateway An enterprise firewall or a network server provider=92s router at a default= gateway can intercept a TURN allocate request and respond with a 300 (Try = Alternate) just as described in the Anycast method above. The following pro= cedures and advantages are inherited from the anycast method. This variant adds the following features: - no separate deployment of discovery mechanism is required - no ANA allocated anycast address is required (works with any public ip ad= dress) - the default gateway router/firewall in charge of the local network respon= ds with the ip address of: (i) a Border TURN server (paralleling the default gateway), or (ii) a TURN server behind that firewall/default gateway and opens a path t= o that TURN server - if the intercepted allocate request was intended for an application provi= ded TURN server, the TURN client (e.g. WebRTC browser) on behalf of the use= r, can select to: (iii) only use the auto discovered TURN server (iv) honor an allocation request by really sending the real-time traffic t= o the Application Provided TURN server, using the Recursively Encapsulated = method, unless (v) the TURN server connected in (ii) already is the Application Provide= d TURN server Security wise, the right party is in charge in all cases. A TURN server pinpointed by a firewall/router at the default gateway should= always be trusted (no explicit authentication with credentials is needed) = and used. (We trust the default gateway with all our traffic anyway, and an= y evil intent to disturb real-time traffic can in such case be implemented = in a default gateway by easier means.) Such "exo-sealed" configuration should be the default configuration if a network provided TURN server is made available for good (non-evil) purposes= . 2) Mobile devices need to work on various networks, without individual configuration I am not clear about the thoughts behind the "configuration" of sealed leve= l and requirements for authentication of the turn server, but if there are methods where an enterprise network (LAN) admin can provide credentials and force a certain sealed level upon the WebRTC-browser when used at that LAN, or if the user has the possibility to configure manually, I am OK with that this can and should OVERRIDE any default configuration or other configuration (on that particular network). However, for mobile devices - Don't we all happily connect our browsers via WiFi here and there? - there must be a way for a network provider with a good intent to offer an exo-sealed TURN server that automatically should be used, e.g. to achieve the purpose of offering better RTC quality than is available through the default gateway WAN path on that network. A network provided TURN-server can easily be made available ONLY to the network users that it is serving, so there is no need for authentication an= d credentials to protect against illegal usage of a valuable resource, like i= t is with the application provided turn server. Network provided TURN servers are simply deployed for the network users to be use without other authentication than being granted an IP address and a default gateway to us= e on that particular network in itself. The same goes for trusting the TURN server with our real-time traffic - If we would trust the same network provider with the same real-time traffic through the default gateway - we should also use the offered TURN server without other "authentication" than that it is available on our network: Data through the default gateway, RTC through the TURN path is why the TURN server is provided! But do we know that it is not someone with the evil purpose of stealing our (encrypted!) real time traffic that is offering the TURN server (instead of the network provider), which leads us to my point 3). (If we really think there is a risk of and danger with such attacks...) 3) Is it now good enough to simply use the auto discovered TURN server? Hop= e so! There has been some recent improvements to draft-ietf-tram-turn-server-discovery-03 and hopefully that is sufficient for assuming that the auto-discovered TURN server is offered by our network provider (a service provider or the enterprise itself) that we trust anyway= , and the TURN server then simply shall be used and considered exo-sealed. (The current RETURN draft says a non configured TURN server should be leaky.) The security considerations in that document suggest that not all discovery= mechanisms have equal additional exposure to local network interference. = I would appreciate clearer guidance on that front. It seems to me that DHC= P is the only listed mechanism that creates minimal additional exposure to = network interference. --- I am addressing TRAM about this and believe that the variant of the Any= cast method I suggest to be added, will fully resolve all security concerns= . I am also suggesting that it is up to this RTCWEB draft to select from TR= AM=92s methods and advices for the WebRTC application and its use cases. --- See my deployment concerns regarding DHCP put in front of TRAM. I think= that the Anycast method with a short TTL-limitation is good enough from th= e privacy aspect, when used to find Border TURN server. --- Even though the new variant I propose is more secure and even easier to= deploy, I suggest that this RETURN draft mandates the use of the both the = Anycast method and its new variant. The reason is that already today, all r= outers/firewalls at a default gateways can add the anycast route required f= or discovery, while intercepting the TURN allocate request and responding = with the Try Alternate server probably requires a software upgrade of insta= lled firewalls and routers with default gateways (a firewall in front of t= he default gateway can also do the interception and response). Some concerns regarding the DISCOVERY draft and whether these things should be specified in the RETURN document: - Is the above the case with all discovery methods proposed? Or shall the RETURN document make one method mandatory to implement? - Can that method then be the Anycast method (which by far seems to be the most convenient to deploy and to implement and should work for all network types and in all devices operating systems). I think what is said under "9.3. Anycast" under "9. Security Considerations" is sufficient for trusting such discovered TURN server. What should then go into the RETURN draft - or should the DISCOVERY draft be more specific? I don't fully understand the DISCOVERY draft's: "... three discovery mechanisms. The reason for providing multiple mechanisms is to maximize the opportunity for discovery," - Can we really put the burden upon all WebRTC devices to implement all methods and I doubt network providers will deploy more than one method. Tha= t seems risking rather than maximizing discovery... It is high time to get this done - can we? /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r internet-drafts@ietf.org Skickat: den 14 maj 2015 00:29 Till: i-d-announce@ietf.org Kopia: rtcweb@ietf.org =C4mne: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC Authors : Benjamin M. Schwartz Justin Uberti Filename : draft-ietf-rtcweb-return-00.txt Pages : 18 Date : 2015-05-13 Abstract: In the context of WebRTC, the concept of a local TURN proxy has been suggested, but not reviewed in detail. WebRTC applications are already using TURN to enhance connectivity and privacy. This document explains how local TURN proxies and WebRTC applications can work together. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-return-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_D1F24F20AC72Dpraspaticiscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8E8506D2EA5B6043B584EBBFB3E541BA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Karl,
Appreciate the review. Responses inline.

On 7/19/15, 11:34 AM, "tram on behalf of Karl Stahl" <tram-bounces@ietf.org on behalf o= f karl.stahl@intertex.se> wr= ote:

I don=92t think draft-ietf-tram-turn-server-discovery-03 draft is= not clear enough yet.

Hopefully the my suggestions below are non-controversial, only im= provements, so we can make this draft an RFC as soon as possible.

 

The following should be read in the context of the email below to= the RTCWEB WG.

 

1) The result of the valid discussion/concerns

Ending at: https://mailarchive.ietf.org/arch/msg/tram/W49pCoOHQu2mE-RxokMbq1FmpOg =

about how to achieve auto-configuration (e.g. necessary for good = and secure use of WebRTC on mobile devices) and the consequent necessity to= be able to use the auto discovered TURN server without credentials, and further that a locally placed turn can ach= ieve this by being available only from a trusted network,=

should be clarified and for which discovery methods it is achieve= d.


Sure, we could add some text around this, but I don=92t think we should get= into too much this. You could discover other TURN servers that may not req= uire credentials, from your ISP, perhaps.


 

2) Tiru, you and I have had some discussion a year ago or so abou= t (From 1.  Introduction):

=93The reason for providing multiple mechanisms is to maximize th= e opportunity for discovery, based on the network in which the TURN client = finds itself.=94

 

I questioned whether that goal really can be achieved unless we m= andate (MUST implement) common methods, and whether it is up to this draft = or some RTCWEB draft to be responsible for that. With the appearance of

draft-ietf-rtcweb-return-00

draft-jennings-behave-rtcweb-firewall-00

we now have a chance to clarify this.

The latest draft states that a client SHOULD implement all methods for best= results. It is up to the client, really. And as you point out, based on ap= plication requirements, a client could implement all or prioritize one over= the others.

 

I fully agree with the goal and necessity of this draft, but sugg= est some rephrasing of the Introduction:

=93To allow TURN applications operate real-time traffic seamlessly across= different types of networks and encourage by the use of TURN without the need for manual = configuration, it is important that there exists an auto discovery mechanis= m for TURN services. Real-time applications and specifically Web Real-Time Communication = (WebRTC)[I-D.ietf-rtcweb-overview] usages and related extensions, which are= mostly based on web applications, need this immediately.=

 

And that the =93multiple mechanism=94 sentence is replaced by:

=93This document recommends multiple discovery mechanism, and adv= ices about security such as trust and privacy as well as deployment efforts= . It is up to the specific real-time application recommendation and its use case to select from these recommendations and a= dvices.=94

Sure, we'll add your recommended text i= n the draft.

=

 

draft-ietf-rtcweb-return-00 can then = specify how the browser shall implement auto discovery for WebRTC

and draft-jennings-behave-rtcweb-firewall-00 can then = advice firewall vendors how to achieve the goals of this draft

Could you please comment on each draft s= eparately? Tracking and following up becomes much simpler.

 

3) The concept o= f =93sealed=94, =93leaky=94 and =93exo-leaky=94 (see discussion below), the= Recursively Encapsulated method and Border TURN server should be mentioned= and conform with draft-ietf-rtcweb-return-00.

 

4) Explain that = the leakiness for a discovered local TURN server can be auto configured. E.= g.:

=93The default g= ateway router/firewall can block STUN packets by looking for the magic STUN= cookie, by closing port 3478 or by closing all UDP traffic, to enforce an = exo-sealed configuration for a TURN client having a leaky default configuration, thus improving security, while avoid= ing the overhead of sending the real-time traffic through the TURN server (= twice) with sealed a TURN client configuration (as explained in draft-ietf-rtcweb-return-00).

 

5) After =936.&n= bsp; Discovery using Anycast=94 section, add a variant:

 

Implicit disc= overy by interception of TURN allocate requests at a default gateway

 

An enterprise fi= rewall or a network server provider=92s router at a default gateway can int= ercept a TURN allocate request and respond with a 300 (Try Alternate) just = as described in the Anycast method above. The following procedures and advantages are inherited from the anycast met= hod.

 

This variant add= s the following features:

- no separate de= ployment of discovery mechanism is required

- no ANA allocat= ed anycast address is required (works with any public ip address)

- the default ga= teway router/firewall in charge of the local network responds with the ip a= ddress of:

(i)   = a Border TURN server (paralleling the default gateway), or

(ii)  a TUR= N server behind that firewall/default gateway and opens a path to that TURN= server  

- if the interce= pted allocate request was intended for an application provided TURN server,= the TURN client (e.g. WebRTC browser) on behalf of the user, can select to= :

(iii) only use t= he auto discovered TURN server

(iv)  honor= an allocation request by really sending the real-time traffic to the Appli= cation Provided TURN server, using the Recursively Encapsulated method, unl= ess

(v)   = the TURN  server connected in (ii) already is the Application Provided= TURN server

 

Security wise, t= he right party is in charge in all cases.

Not really, you=92re intercepting traffi= c not meant for you. Why can=92t the gateway router just listen on the desi= gnated anycast address instead?


A TURN server pi= npointed by a firewall/router at the default gateway should always be trust= ed (no explicit authentication with credentials is needed) and used. (We tr= ust the default gateway with all our traffic anyway, and any evil intent to disturb real-time traffic can in su= ch case be implemented in a default gateway by easier means.)

 

- the TURN serve= r pinpointed by a default gateway shall always be trusted and used and the = security methods under 9.3 will not have to be applied.

 

[Some of these f= eatures should be repeated under the Deployment and Security sections]=

 

6) Under =937. D= eployment Considerations=94, the ease of the Anycast method and suggested v= ariant could be pointed out. Those methods can be used over any network and= by TURN clients under common operating systems.

 

It should be adv= iced to configure discovered TURN servers to be allowed to be used without = credentials for the users that they are intended to serve, to achieve the g= oal of this draft (simply by make the TURN server available to allocate from, only on the network it is supposed= to serve, thus no credentials are needed to protect the TURN server resour= ce as with the application provided TURN servers).

What about the following = text?

NEW:

Clients can use TURN serv= ers provided by the local network or by the access network without authenti= cating with the TURN server. It is recommended that clients use (D)TLS with= network provided TURN servers to authenticate and prevent man-in-middle attacks.


The DHCP method = may also be easy to deploy where used (e.g. Enterprise, Home and WiFi). How= ever, with IPV6, RA (Router Advertisement) is often used instead of DHCP to= hand out ip addresses. The important mobile world (3G/4G/LTE) has its own methods, and there are still PPoE and= PPoA in use, where DHCP cannot be used. If a network service provides anno= unces a TURN server using DHCP, the following firewall needs to pick that u= p and advice that to the users on the LAN. DHCP may not be available on some operating systems where the TUR= N client, specifically the WebRTC device, should be able to be implemented = on.

If DHCP cannot be used in= a specific network then other discovery mechanisms discussed in the draft = should be used.

 

7)I don=92t unde= rstand the sentences under =939.  Security Considerations=94

=93In general, i= t is recommended that a TURN client authenticate with the TURN server to id= entify a rouge server. [RFC7350] can be potentially used by a client to val= idate a previously unknown server.=94

It must be expla= ined and detailed, how and what is authenticated or validated, for what pur= pose and how this may help to achieve the goals of this recommendation, or = these sentences should simply be deleted.

Sure, we=92ll add more text around authent= ication.


-Prashanth=  = ;

 

I hope this impr= oves this necessary and good draft and that it quickly can be adopted.=

 

/Karl=

 

 

Fr=E5n: tram [mailto:tram-bounces@ietf.org= ] F=F6r Karl Stahl
Skickat: den 19 juli 2015 20:23
Till: 'Benjamin Schwartz'; 'Cullen Jennings (fluffy)'
Kopia: rtcweb@ietf.org; tram@ietf.org
=C4mne: Re: [tram] [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed,= Configuration and TURN discovery:

 

Benjamin =96 your concern is valid =96 I thought= exo-sealed was easy to do in the browser.

 

Below I list a firewall configuration assisted m= ethod to address the TURN server and bandwidth resource consumption problem for local WebRTC calls when using the sealed = configuration. I believe my suggestion also will meet all security/trust/pr= ivacy perspectives and give secure auto-configuration, so mobile devices ca= n to be used with high-quality secure WebRTC communication =93everywhere you can surf=94  through proper us= e of Border TURN servers - which must be the (almost already achieved) purp= ose of this RETURN draft.

 

After some consideration, to achieve the preferr= ed exo-sealed configuration, the RETURN drafts already prescribes the best default configuration: =93leaky=94 ! :-= )

Explanations inline below -->

 

Below are also some suggestions for inclusion in= the drafts:

draft-ietf-tram-turn-server-discovery-03

draft-jennings-behave-rtcweb-firewall-00

 

/Karl

 

PS: Regarding the TURN Origin debate, I don=92t = have a clear view, but am I not right in the understanding that:

* The purpose of the TURN Origin draft  was= to reduce the pain of WebRTC service providers having to deploy network hardware (the Application Provided TURN server) t= o get their services used, by allowing the TURN server to serve many applic= ations (through a third party).

 - The introduction of Border TURN servers = releases WebRTC service providers of that pain (when commonly deployed) (and also put security back in the right place) (= Until deployed commonly, yes these SPs unfortunately have this pain to =93f= ool their services=94 through users security devices =96 the firewalls (som= ething which the discussed 3 drafts now finally can remedy (without the use of Origin))

* However, the Application Provided TURN server = may also be for (from the RETURN draft: 3 Goals, 3.2 independent path control):

   o  improving quality of s= ervice by tunneling packets through a network that is faster than the public internet,

   +  monitoring the usage of= UDP services,

   +  troubleshooting and deb= ugging problematic services,

   +  logging connection meta= data for legal or auditing reasons,

   +  recording the entire co= ntents of all connections, or

   -  providing partial IP addres= s anonymization (as described in [I-D.ietf-rtcweb-security] Section 4.2.4).

(+ and =96 indicates the conflicting impact = the use Origin will bring for the listed purposes)

 

The RETURN draft honors the application=92s effo= rts to enforce media through such Application Provided TURN server (without judging the purpose) (by use of the Recursiv= ely Encapsulation mechanism).

 

My advice now is just to not introduce the Origi= n discussion in these drafts where we finally have to resolve the firewall traversal problem with real-time traffic. We = need these RFCs in place as soon as ever possible. I see a risk in that draft-jennings-behave-rtcweb-firewall-00 starts discussing Origin/SNI in an effort to make a pretty secure WebR= TC aware firewall somewhat more secure, and think the draft can advice firewall vendors how to build firewalls tha= t are fully secure and allows real-time traffic and should also be able to = provide a quality pipe for the real-time traffic. Origin/SNI is not require= d for that. The Border TURN server and this RETURN-draft will make that possible.

 

-- > Don=92t forget the inline below -- ><= o:p>

 

Fr=E5n: Benjamin Schwartz [mailto:bemasc@webrtc.org]
Skickat: den 14 juli 2015 03:16
Till: Karl Stahl
Kopia: rtcweb@ietf.org; tram@ietf.org
=C4mne: Re: [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Config= uration and TURN discovery:

 

On Mon, Jul 13, 2015 at 6:19 PM, Karl Stahl &= lt;karl.stahl@intertex.se> wrote:

We need this draft implemented in WebRTC brow= sers as soon as possible, so we
can get good WebRTC in difficult places (for firewall traversal and for
quality). Is there any implementation e.g. in Chrome that can be tried?

Now having stated that I am positive to this draft, I have some
concerns/questions/suggestions:

1) We need more levels than sealed/leaky

It is not acceptable that WebRTC traffic between parties on a typical LAN i= s
forced through a TURN server, just because of a sealed configuration
required for good WebRTC traffic over the WAN. This consequence is pointed<= br> out under "5.11.  Reusing the same TURN server", but IS a pr= oblem even if it
"work as expected".

Such TURN resource consumption, waste of bandwidth and possible performance=
degradation do not happen today, and can easily be avoided.

I realize this consequence of "sealed" is required to meet some o= f the
requirements under "3.2.  Independent Path Control", but we = simply need an
"exo-sealed" level, in addition to the proposed strictly sealed a= nd leaky,
allowing local endpoints to connect media directly, while external traffic<= br> is forced to use the TURN server (rather than STUN through the default
gateway).

 

[BS] How do you propose to tell what is "local&= quot;?  I don't know how to define that procedurally.

 

[BS] I think my main concern here is that it require= s us to "lie" to the remote party, by sending candidates that we = may then refuse to use even if they work.  This seems very strange.

 =

[Karl] You are right. I assumed the preferred ex= o-sealed behavior could be achieved as easily as we do it =93hardware wise=94 today on the inside of our open test-site = https://webrtc.ingate.com where we have a border placed TURN server par= alleling our firewall/default gateway. Our firewall looks for the magic STU= N cookie and discards all STUN packets from the LAN side. TURN is then auto= matically enforced and today=92s leaky WebRTC browsers automatically get the preferred exo-sealed behavior.<= /o:p>

 

(Just not using STUN in the browser, would have = the same effect but not fully, if there are more subnets on the LAN side. Crossing those subnets would then take m= edia through the dual trip via the TURN server that I want to avoid.)<= /o:p>

 

So, let=92s enforce the preferred exo-sealed con= figuration by configuration of the firewall/default gateway (Security from this perspective is then also in the right hands - = the network admin=92s):

- Today=92s RETURN-draft=92s leaky default confi= guration is OK (since the firewalls discarding STUN automatically enforce the preferred exo-sealed behavior)

- Recommend in the RETURN-draft (and in draft-jennings-behave-rtcweb-firewall-00)  that the network admin discards STUN packets from the LAN side = through the default gateway (consent STUNs will go OK through the TURN server), by looking for the magic STUN cookie,= by closing port 3478 or by closing all UDP (the restrictive enterprise fir= ewall can simply be left as it is) to achieve exo-sealed leakiness.

- The network admin offers a Border TURN server = for its network users (LAN side only) =96 no need for authentication (free to use from LAN side being a Border TURN = server configuration)

- The Border TURN server is offered by the netwo= rk you are using =96 Just use it! (should the network provider have evil intentions, he needs no TURN server, he can= simply close or destroy WebRTC in the firewall if he which,  which Cu= llen just exemplified in draft-jennings-behave-rtcweb-firewall-00)

 

As you may have noticed, I stress that NO creden= tials should be needed for using an auto discovered border TURN server. That is also the goal of TRAM=92s discovery= draft, but I have asked TRAM  to clarify that achievement. If we don= =92t fix that, we have failed to make WebRTC usable on mobile devices =96 o= r can anyone explain where we would get those credentials from when we run around and have Web access here and there and= the goal of WebRTC was to use real-time communication, securely and with h= igh quality, everywhere we can surf, wasn=92t it?

 

If anyone cries that we NEED AUTHENTICATION, the= y should remember the IP authentication (simply being on a certain network) is the most commonly used =93authentic= ation method=94 today and protecting huge values (almost the whole telco in= dustry) and also achieves privacy (through the use of firewalls). No indivi= dual user credentials which are impossible to handle must be required.

 

I will in next email propose this new variant of= the Anycast method  to TRAM. It should work, shouldn=92t it?

And does it provide the claimed advantages/featu= res? =96 please check.

 

Implicit disc= overy by interception of TURN allocate requests at a default gateway

 

An enterprise fi= rewall or a network server provider=92s router at a default gateway can int= ercept a TURN allocate request and respond with a 300 (Try Alternate) just = as described in the Anycast method above. The following procedures and advantages are inherited from the anycast met= hod.

 

This variant add= s the following features:

- no separate de= ployment of discovery mechanism is required

- no ANA allocat= ed anycast address is required (works with any public ip address)

- the default ga= teway router/firewall in charge of the local network responds with the ip a= ddress of:

(i)   = a Border TURN server (paralleling the default gateway), or

(ii)  a TUR= N server behind that firewall/default gateway and opens a path to that TURN= server  

- if the interce= pted allocate request was intended for an application provided TURN server,= the TURN client (e.g. WebRTC browser) on behalf of the user, can select to= :

(iii) only use t= he auto discovered TURN server

(iv)  honor= an allocation request by really sending the real-time traffic to the Appli= cation Provided TURN server, using the Recursively Encapsulated method, unl= ess

(v)   = the TURN  server connected in (ii) already is the Application Provided= TURN server

 

Security wise, t= he right party is in charge in all cases.

A TURN server pi= npointed by a firewall/router at the default gateway should always be trust= ed (no explicit authentication with credentials is needed) and used. (We tr= ust the default gateway with all our traffic anyway, and any evil intent to disturb real-time traffic can in su= ch case be implemented in a default gateway by easier means.)

 

 

Such "exo-sealed" configuration sho= uld be the default configuration if a
network provided TURN server is made available for good (non-evil) purposes= .


2) Mobile devices need to work on various networks, without individual
configuration

I am not clear about the thoughts behind the "configuration" of s= ealed level
and requirements for authentication of the turn server, but if there are methods where an enterprise network (LAN) admin can provide credentials and=
force a certain sealed level upon the WebRTC-browser when used at that LAN,=
or if the user has the possibility to configure manually, I am OK with that=
this can and should OVERRIDE any default configuration or other
configuration (on that particular network).

However, for mobile devices - Don't we all happily connect our browsers via=
WiFi here and there? - there must be a way for a network provider with a good intent to offer an exo-sealed TURN server that automatically should be=
used, e.g. to achieve the purpose of offering better RTC quality than is available through the default gateway WAN path on that network.

A network provided TURN-server can easily be made available ONLY to the
network users that it is serving, so there is no need for authentication an= d
credentials to protect against illegal usage of a valuable resource, like i= t
is with the application provided turn server. Network provided TURN servers=
are simply deployed for the network users to be use without other
authentication than being granted an IP address and a default gateway to us= e
on that particular network in itself.

The same goes for trusting the TURN server with our real-time traffic - If<= br> we would trust the same network provider with the same real-time traffic through the default gateway - we should also use the offered TURN server without other "authentication" than that it is available on our n= etwork:
Data through the default gateway, RTC through the TURN path is why the TURN=
server is provided!

But do we know that it is not someone with the evil purpose of stealing our=
(encrypted!) real time traffic that is offering the TURN server (instead of=
the network provider), which leads us to my point 3). (If we really think there is a risk of and danger with such attacks...)


3) Is it now good enough to simply use the auto discovered TURN server? Hop= e
so!

There has been some recent improvements to
draft-ietf-tram-turn-server-discovery-03 and hopefully that is sufficient for assuming that the auto-discovered TURN server is offered by our network=
provider (a service provider or the enterprise itself) that we trust anyway= ,
and the TURN server then simply shall be used and considered exo-sealed. (The current RETURN draft says a non configured TURN server should be
leaky.)

 

The security considerations in that document = suggest that not all discovery mechanisms have equal additional exposure to= local network interference.  I would appreciate clearer guidance on that front.  It seems to me that DHCP = is the only listed mechanism that creates minimal additional exposure to ne= twork interference.

 

--- I am addressing TRAM about this and believe = that the variant of the Anycast method I suggest to be added, will fully resolve all security concerns. I am also s= uggesting that it is up to this RTCWEB draft to select from TRAM=92s method= s and advices for the WebRTC application and its use cases.

 

--- See my deployment concerns regarding DHCP pu= t in front of TRAM. I think that the Anycast method with a short TTL-limitation is good enough from the privacy aspect,= when used to find Border TURN server.

 

--- Even though the new variant I propose is mor= e secure and even easier to deploy, I suggest that this RETURN draft mandates the use of the both the Anycast method and= its new variant. The reason is that already today, all routers/firewalls a= t a default gateways can add the anycast route required for discovery, whil= e intercepting the TURN  allocate request and responding with the Try Alternate server probably requires a s= oftware upgrade of installed  firewalls and routers with default gatew= ays (a firewall in front of the default gateway can also do the interceptio= n and response).

 

Some concerns regarding the DISCOVERY draft and whethe= r these things should
be specified in the RETURN document:

- Is the above the case with all discovery methods proposed? Or shall the RETURN document make one method mandatory to implement?

- Can that method then be the Anycast method (which by far seems to be the<= br> most convenient to deploy and to implement and should work for all network<= br> types and in all devices operating systems). I think what is said under
"9.3.  Anycast" under "9.  Security Considerations= " is sufficient for
trusting such discovered TURN server. What should then go into the RETURN draft - or should the DISCOVERY draft be more specific?

I don't fully understand the DISCOVERY draft's: "... three discovery mechanisms. The reason for providing multiple mechanisms is to maximize the=
opportunity for discovery,"

- Can we really put the burden upon all WebRTC devices to implement all
methods and I doubt network providers will deploy more than one method. Tha= t
seems risking rather than maximizing discovery...


It is high time to get this done - can we?

/Karl



-----Ursprungligt meddelande-----
Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r internet-drafts@ietf.org
Skickat: den 14 maj 2015 00:29
Till: i-d-announce@ietf.org
Kopia: rtcweb@ietf.org
=C4mne: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Real-Time Communication in WEB-brows= ers
Working Group of the IETF.

        Title           := Recursively Encapsulated TURN (RETURN) for
Connectivity and Privacy in WebRTC
        Authors         : Benj= amin M. Schwartz
                     = ;     Justin Uberti
        Filename        : draft-iet= f-rtcweb-return-00.txt
        Pages           := 18
        Date            := 2015-05-13

Abstract:
   In the context of WebRTC, the concept of a local TURN proxy ha= s been
   suggested, but not reviewed in detail.  WebRTC applicatio= ns are
   already using TURN to enhance connectivity and privacy.  = This
   document explains how local TURN proxies and WebRTC applicatio= ns can
   work together.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-rtcweb-return/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ie= tf-rtcweb-return-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

 

 

 

 --_000_D1F24F20AC72Dpraspaticiscocom_-- From nobody Fri Aug 14 08:39:47 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B6F1ACD3B for ; Fri, 14 Aug 2015 08:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm_yZxEOwhMw for ; Fri, 14 Aug 2015 08:39:42 -0700 (PDT) Received: from smtp88.ord1c.emailsrvr.com (smtp88.ord1c.emailsrvr.com [108.166.43.88]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7A81ACD21 for ; Fri, 14 Aug 2015 08:39:40 -0700 (PDT) Received: from smtp12.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp12.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 4B2AE380340; Fri, 14 Aug 2015 11:39:40 -0400 (EDT) Received: by smtp12.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A5A8E3803DA; Fri, 14 Aug 2015 11:39:38 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [172.20.10.2] ([UNAVAILABLE]. [209.52.88.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Fri, 14 Aug 2015 15:39:39 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=utf-8 From: Cullen Jennings In-Reply-To: Date: Fri, 14 Aug 2015 08:39:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.2102) Archived-At: Cc: mmusic , "rtcweb@ietf.org" , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 15:39:43 -0000 > On Aug 6, 2015, at 7:14 AM, Jonathan Lennox = wrote: >=20 >=20 >> On Aug 5, 2015, at 5:35 PM, Justin Uberti wrote: >>=20 >> On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault = wrote: >> Le 2015-08-05 13:46, Philipp Hancke a =C3=A9crit : >> > If a peer sends candidates with IP addresses from the private = space, >> > permissions for those are created at the TURN server. Potentially = not >> > utilising transport encryption even. >> > >> > I doubt those candidates ever work, so from a privacy point of view = it >> > seems that clients should not create those permissions in the first >> > place. And ICE should probably not try to create pairs. >>=20 >> It's not up to the client to determine what addresses might not might >> not work for a given TURN server. There are lots of weird NAT >> configurations out there that play games with RFC1918 addresses and = can >> easily trick clients into doing the wrong thing. >>=20 >> I am somewhat sympathetic to that, but given that there is measurable = downside here - extra candidate pairs that take time to check - can you = supply a concrete example of where the client choosing not to pair a = TURN candidate with a RFC1918 address would cause a problem? >=20 > This is really an ICE question, not a TURN question, so adding MMUSIC. >=20 > Clearly, if your TURN server is actually on the public internet, = pairing RFC1918 address with its candidates won=E2=80=99t do any good. = However, there can be scenarios where you have a TURN server sitting in = a DMZ or the like, where it can actually route to RFC 1918 addresses. I = suspect this will be relevant in the various scenarios where the TURN = server is topologically equivalent to a web proxy.=20 >=20 > As I recall from the discussions around the development of ICE, there = are actually a fair number of networks out there which have public IPv4 = and RFC1918 addresses directly routable to each other. The examples I = remember came about as a result of corporate mergers, where one of the = pre-merger companies was using their public address space internally, = and the other wasn=E2=80=99t. >=20 Some SPs are putting all their customers behind CGN (carrier grade NAT) = and then looking at running cloud data centers where other people can = rent servers (AWS style) where those servers have public IPs and at the = same time they are directly routable to the all the NATed clients. That = allows you to run media servers (STUN, TURN, Conferences MCU / Switches, = caches etc) that have a low latency connectivity to the SP's customers = endpoints. Note the customers's themselves often deploy an additional = layer of residential NAT.=20 So scenarios like this might be getting more common .... From nobody Fri Aug 14 13:41:35 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1878C1A8980 for ; Fri, 14 Aug 2015 13:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQeG3O1rKlkE for ; Fri, 14 Aug 2015 13:41:24 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE351A8971 for ; Fri, 14 Aug 2015 13:41:21 -0700 (PDT) Received: by vkfi73 with SMTP id i73so34683071vkf.2 for ; Fri, 14 Aug 2015 13:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5TEPXqy91DSOyt8m+GDlYRXKvLYN3rdin7uuqqIiOX0=; b=ZoyStcHF9dE9TnPxgoIdaxCQHgGwjzApozWHoKdJ6zWg54WGYiDNi1jXiSnQeTRtrR fFjZZK1+jAMaBtB+U7mh24mc4fX09y641Aalwmca595wQCvDqFzB2/trCIjXRL4crFDI F3XMFcd1MTbcjeShPrnkqIzkmKJX+MHZzelPhz9IgMK3MgEPqowP68atK4/TrsJtt38s Y/uSGe3rqBqO0cA2L0xJlrmPdss48gEtmW6I2eak70UcbX3hzZXu4zAy3nCpTt62SNnx qH8vJ5AdMV4Qz0BvY5TGV1J7oFl3VdbaY/jyHuvmzjOs19bMfOBYlA7FHCx+rHd7veUq Prog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5TEPXqy91DSOyt8m+GDlYRXKvLYN3rdin7uuqqIiOX0=; b=QEHJhCHVA9u+SnPhRZj79JyHK1YSOAkddwW8ky0dR2URcp/ePi8w/2D9DBKvvNi5hN 6N4sdHMImPQU/SVfImg90P4HNg4MxR/1P68rnsdKnLDFRaw8TiKJN3NQ422kfUFyXuD/ b00w94AyA9rhy/2cPUAQb3X/z0iLRhIajD8hP9HNMNzfISC7QAywI6n0GVs1O6Y5x09t DxP3PkYKf4wN8WFoG7X/oIiP8TvhGTyh6CqHHMUZteYfZRM1+fXK5WTRvZ9lgSPd7EXC L5XJyJbANm6dQ1viPOT/skH9IeERcsLChLmfdoJbnogKoWQtowrIYxcmzOSY2lNyo9SR x8mg== X-Gm-Message-State: ALoCoQmELT/NP2GS6Ito9KcDV4SW5i0SdXkHNQiVqk240rvjLQLSByYBwwLzYWRojI//TuZGKYR1 X-Received: by 10.52.186.72 with SMTP id fi8mr56186482vdc.19.1439584880597; Fri, 14 Aug 2015 13:41:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.87 with HTTP; Fri, 14 Aug 2015 13:41:00 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: Justin Uberti Date: Fri, 14 Aug 2015 13:41:00 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=bcaec548a8216eea60051d4b7941 Archived-At: Cc: Jonathan Lennox , "rtcweb@ietf.org" , "tram@ietf.org" , mmusic Subject: Re: [tram] [rtcweb] TURN permissions for private ips X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 20:41:26 -0000 --bcaec548a8216eea60051d4b7941 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Makes sense, although not sure that the apps will want to disclose the private IPs of the media servers to endpoints. Overall I think enough arguments have been made that it is safer for the server to enforce this policy than clients, since the TURN server should be more aware of the application topology. On Fri, Aug 14, 2015 at 8:39 AM, Cullen Jennings wrote: > > > On Aug 6, 2015, at 7:14 AM, Jonathan Lennox wrote: > > > > > >> On Aug 5, 2015, at 5:35 PM, Justin Uberti wrote: > >> > >> On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault > wrote: > >> Le 2015-08-05 13:46, Philipp Hancke a =C3=A9crit : > >> > If a peer sends candidates with IP addresses from the private space, > >> > permissions for those are created at the TURN server. Potentially no= t > >> > utilising transport encryption even. > >> > > >> > I doubt those candidates ever work, so from a privacy point of view = it > >> > seems that clients should not create those permissions in the first > >> > place. And ICE should probably not try to create pairs. > >> > >> It's not up to the client to determine what addresses might not might > >> not work for a given TURN server. There are lots of weird NAT > >> configurations out there that play games with RFC1918 addresses and ca= n > >> easily trick clients into doing the wrong thing. > >> > >> I am somewhat sympathetic to that, but given that there is measurable > downside here - extra candidate pairs that take time to check - can you > supply a concrete example of where the client choosing not to pair a TURN > candidate with a RFC1918 address would cause a problem? > > > > This is really an ICE question, not a TURN question, so adding MMUSIC. > > > > Clearly, if your TURN server is actually on the public internet, pairin= g > RFC1918 address with its candidates won=E2=80=99t do any good. However, = there can > be scenarios where you have a TURN server sitting in a DMZ or the like, > where it can actually route to RFC 1918 addresses. I suspect this will b= e > relevant in the various scenarios where the TURN server is topologically > equivalent to a web proxy. > > > > As I recall from the discussions around the development of ICE, there > are actually a fair number of networks out there which have public IPv4 a= nd > RFC1918 addresses directly routable to each other. The examples I remembe= r > came about as a result of corporate mergers, where one of the pre-merger > companies was using their public address space internally, and the other > wasn=E2=80=99t. > > > > Some SPs are putting all their customers behind CGN (carrier grade NAT) > and then looking at running cloud data centers where other people can ren= t > servers (AWS style) where those servers have public IPs and at the same > time they are directly routable to the all the NATed clients. That allows > you to run media servers (STUN, TURN, Conferences MCU / Switches, caches > etc) that have a low latency connectivity to the SP's customers endpoints= . > Note the customers's themselves often deploy an additional layer of > residential NAT. > > So scenarios like this might be getting more common .... > > > > > --bcaec548a8216eea60051d4b7941 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Makes sense, although not sure that the apps will want to = disclose the private IPs of the media servers to endpoints.

<= div>Overall I think enough arguments have been made that it is safer for th= e server to enforce this policy than clients, since the TURN server should = be more aware of the application topology.=C2=A0

<= br>

On= Fri, Aug 14, 2015 at 8:39 AM, Cullen Jennings <fluffy@iii.ca> w= rote:

> On Aug 6, 2015, at 7:14 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
>
>
>> On Aug 5, 2015, at 5:35 PM, Justin Uberti <juberti@google.com> wrote:
>>
>> On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault <sperreault@jive.com> wrote:
>> Le 2015-08-05 13:46, Philipp Hancke a =C3=A9crit :
>> > If a peer sends candidates with IP addresses from the private= space,
>> > permissions for those are created at the TURN server. Potenti= ally not
>> > utilising transport encryption even.
>> >
>> > I doubt those candidates ever work, so from a privacy point o= f view it
>> > seems that clients should not create those permissions in the= first
>> > place. And ICE should probably not try to create pairs.
>>
>> It's not up to the client to determine what addresses might no= t might
>> not work for a given TURN server. There are lots of weird NAT
>> configurations out there that play games with RFC1918 addresses an= d can
>> easily trick clients into doing the wrong thing.
>>
>> I am somewhat sympathetic to that, but given that there is measura= ble downside here - extra candidate pairs that take time to check - can you= supply a concrete example of where the client choosing not to pair a TURN = candidate with a RFC1918 address would cause a problem?
>
> This is really an ICE question, not a TURN question, so adding MMUSIC.=
>
> Clearly, if your TURN server is actually on the public internet, pairi= ng RFC1918 address with its candidates won=E2=80=99t do any good.=C2=A0 How= ever, there can be scenarios where you have a TURN server sitting in a DMZ = or the like, where it can actually route to RFC 1918 addresses.=C2=A0 I sus= pect this will be relevant in the various scenarios where the TURN server i= s topologically equivalent to a web proxy.
>
> As I recall from the discussions around the development of ICE, there = are actually a fair number of networks out there which have public IPv4 and= RFC1918 addresses directly routable to each other. The examples I remember= came about as a result of corporate mergers, where one of the pre-merger c= ompanies was using their public address space internally, and the other was= n=E2=80=99t.
>

Some SPs are putting all their customers behind CGN (carrier gr= ade NAT) and then looking at running cloud data centers where other people = can rent servers (AWS style) where those servers have public IPs and at the= same time they are directly routable to the all the NATed clients. That al= lows you to run media servers (STUN, TURN, Conferences MCU / Switches, cach= es etc) that have a low latency connectivity to the SP's customers endp= oints. Note the customers's themselves often deploy an additional layer= of residential NAT.

So scenarios like this might be getting more common ....





--bcaec548a8216eea60051d4b7941-- From nobody Mon Aug 17 05:52:38 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7421B2DAE for ; Mon, 17 Aug 2015 05:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.448 X-Spam-Level: ** X-Spam-Status: No, score=2.448 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tN8nmrwKMskU for ; Mon, 17 Aug 2015 05:52:16 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8E41B2DA4 for ; Mon, 17 Aug 2015 05:52:14 -0700 (PDT) Received: from Kallei7 ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201508171452128935; Mon, 17 Aug 2015 14:52:12 +0200 From: "Karl Stahl" To: "'Prashanth Patil \(praspati\)'" , "'Tirumaleswar Reddy \(tireddy\)'" , "'Simon Perreault'" , "'Benjamin Schwartz'" , "'Cullen Jennings \(fluffy\)'" , "'Adam Roach'" References: <022601d0c251$9e1944a0$da4bcde0$@stahl@intertex.se> In-Reply-To: Date: Mon, 17 Aug 2015 14:52:10 +0200 Message-ID: <00af01d0d8eb$88203270$98609750$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01D0D8FC.4BA90270" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQ1iUXJx1Ac0hIpUq+Zo9HYRlOvJ4LGOoQ Content-Language: sv Archived-At: Cc: tram@ietf.org Subject: Re: [tram] last call on this draft: draft-ietf-tram-turn-server-discovery-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 12:52:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B0_01D0D8FC.4BA90270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Prashanth, =20 See comments /explainations inline below. =20 Thanks, Karl =20 Fr=E5n: Prashanth Patil (praspati) [mailto:praspati@cisco.com]=20 Skickat: den 14 augusti 2015 02:07 Till: Karl Stahl; Tirumaleswar Reddy (tireddy); 'Simon Perreault'; = 'Benjamin Schwartz'; Cullen Jennings (fluffy); 'Adam Roach' Kopia: tram@ietf.org =C4mne: Re: [tram] last call on this draft: draft-ietf-tram-turn-server-discovery-03 =20 Hi Karl, Appreciate the review. Responses inline. =20 On 7/19/15, 11:34 AM, "tram on behalf of Karl Stahl" < tram-bounces@ietf.org on behalf of karl.stahl@intertex.se> wrote: =20 I don=92t think draft-ietf-tram-turn-server-discovery-03 draft is not = clear enough yet. Hopefully the my suggestions below are non-controversial, only = improvements, so we can make this draft an RFC as soon as possible. =20 The following should be read in the context of the email below to the = RTCWEB WG. =20 1) The result of the valid discussion/concerns=20 Ending at: https://mailarchive.ietf.org/arch/msg/tram/W49pCoOHQu2mE-RxokMbq1FmpOg=20 about how to achieve auto-configuration (e.g. necessary for good and = secure use of WebRTC on mobile devices) and the consequent necessity to be able = to use the auto discovered TURN server without credentials, and further = that a locally placed turn can achieve this by being available only from a = trusted network, should be clarified and for which discovery methods it is achieved.=20 =20 Sure, we could add some text around this, but I don=92t think we should = get into too much this.=20 [Karl] Did you also read: http://www.ietf.org/mail-archive/web/tram/current/msg01742.html and=20 http://www.ietf.org/mail-archive/web/tram/current/msg01747.html ? I think this discovery draft should get into this =93much enough=94 to = minimize confusions that came to light there. =20 You could discover other TURN servers that may not require credentials, = from your ISP, perhaps. [Karl] Yes, of course =96 that is the intention also =96 and this draft = should clear enough on that for others to use (e.g. the RETURN draft) =20 2) Tiru, you and I have had some discussion a year ago or so about (From = 1. Introduction):=20 =93The reason for providing multiple mechanisms is to maximize the = opportunity for discovery, based on the network in which the TURN client finds = itself.=94=20 =20 I questioned whether that goal really can be achieved unless we mandate (MUST implement) common methods, and whether it is up to this draft or = some RTCWEB draft to be responsible for that. With the appearance of=20 draft-ietf-rtcweb-return-00 draft-jennings-behave-rtcweb-firewall-00 we now have a chance to clarify this. =20 The latest draft states that a client SHOULD implement all methods for = best results. It is up to the client, really. And as you point out, based on application requirements, a client could implement all or prioritize one over the others. =20 I fully agree with the goal and necessity of this draft, but suggest = some rephrasing of the Introduction: =93To allow TURN applications operate real-time traffic seamlessly = across different types of networks and encourage by the use of TURN without the need for manual configuration, it is important that there exists an auto discovery mechanism for TURN services. Real-time applications and specifically Web Real-Time Communication = (WebRTC)[I-D.ietf-rtcweb-overview] usages and related extensions, which are mostly based on web = applications, need this immediately. =20 And that the =93multiple mechanism=94 sentence is replaced by: =93This document recommends multiple discovery mechanism, and advices = about security such as trust and privacy as well as deployment efforts. It is = up to the specific real-time application recommendation and its use case to select from these recommendations and advices.=94 =20 Sure, we'll add your recommended text in the draft. =20 draft-ietf-rtcweb-return-00 can then specify how the browser shall = implement auto discovery for WebRTC and draft-jennings-behave-rtcweb-firewall-00 can then advice firewall vendors how to achieve the goals of this draft =20 Could you please comment on each draft separately? Tracking and = following up becomes much simpler. [Karl] I have done that, but=85 =96 This was just a remark (why I wanted = this little rewrite that you just agreed to) =20 3) The concept of =93sealed=94, =93leaky=94 and =93exo-leaky=94 (see = discussion below), the Recursively=20 [Karl] Oops =96 meant =93exo sealed=94 (not =93exo-leaky=94) above Encapsulated method and Border TURN server should be mentioned and = conform with draft-ietf-rtcweb-return-00. =20 4) Explain that the leakiness for a discovered local TURN server can be = auto configured. E.g.: =93The default gateway router/firewall can block STUN packets by looking = for the magic STUN cookie, by closing port 3478 or by closing all UDP = traffic, to enforce an exo-sealed configuration for a TURN client having a leaky default configuration, thus improving security, while avoiding the = overhead of sending the real-time traffic through the TURN server (twice) with = sealed a TURN client configuration (as explained in = draft-ietf-rtcweb-return-00). =20 5) After =936. Discovery using Anycast=94 section, add a variant: =20 Implicit discovery by interception of TURN allocate requests at a = default gateway =20 An enterprise firewall or a network server provider=92s router at a = default gateway can intercept a TURN allocate request and respond with a 300 = (Try Alternate) just as described in the Anycast method above. The following procedures and advantages are inherited from the anycast method. =20 This variant adds the following features: - no separate deployment of discovery mechanism is required - no ANA allocated anycast address is required (works with any public ip address)=20 - the default gateway router/firewall in charge of the local network responds with the ip address of: (i) a Border TURN server (paralleling the default gateway), or=20 (ii) a TURN server behind that firewall/default gateway and opens a = path to that TURN server =20 - if the intercepted allocate request was intended for an application provided TURN server, the TURN client (e.g. WebRTC browser) on behalf of = the user, can select to: (iii) only use the auto discovered TURN server (iv) honor an allocation request by really sending the real-time = traffic to the Application Provided TURN server, using the Recursively Encapsulated method, unless (v) the TURN server connected in (ii) already is the Application = Provided TURN server =20 Security wise, the right party is in charge in all cases. =20 Not really, you=92re intercepting traffic not meant for you.=20 [Karl] Isn=92t that exactly what firewalls do? (and both of us, Cisco = and Ingate/Intertex are making such devices=85) Why can=92t the gateway router just listen on the designated anycast = address instead? [Karl] It does but must even then follow the same procedure of: open a = path to the TURN server behind the gateway! =20 =20 My suggestion to add this variant was because what is explained under 4) above: - by blocking STUN packets a gateway router/firewall can enforce an exo-sealed configuration for a TURN client having a leaky default configuration. If sealed configuration (by some yet unknown = configuration method) is done just in browser, it will have the unwanted overhead of sending local real-time traffic twice through the TURN server=20 =20 AND because of that the scenario of a the gateway router/firewall in = front of an ISP network provided TURN server, where both want a sealed configuration where real-time traffic does NOT go through their default gateways, was not outlined here or in the RETURN draft.=20 =20 The longer answer to your question: > Why can=92t the gateway router just listen on the designated anycast = address instead? is: =20 If such gateway router/firewall just would advise an OWN TURN server, = the browser would have to add yet another level of recursively encapsulating (for two network provided plus one application provided TURN server) - a complication we cannot impose. Instead such gateway, must react to an = TURN allocation (by opening a path to the ISP TURN server) =96 and *as a consequence* the specific anycast address is not needed. =20 The procedure suggested for the browser (and thus for the RETURN draft) = is to handle the situation where the gateway intercepts all TURN allocation requests =96 that procedure will *also* work if the firewall instead = only reacts to the anycast address and sets up a path (and allows the next = level to respond to it), while a thinner procedure in the browser may not = handle the case where the gateway answers all TURN allocation requests through = its default gateway. =20 So, by outlining this implicit discovery anycast variant, the RETURN = draft can recommend a procedure that will work for all cases (that the gateway router/firewall may choose to implement this =93kind of TURN allocation = proxy=94 needed when in front of an ISP TURN server.=20 =20 AND FURTHER, if we know the browser will follow a certain procedure, = such gateway router/firewall in front of an ISP TURN server, can auto = configure itself by following the TURN allocate requests and responses that passes = the gateway router/firewall. I don=92t mean it is time to specify such = behavior of such gateway router/firewall in any draft, but if we already now also outline the implicit discovery anycast variant (The method is only 3 = lines of text!) and have the browsers handle it =96 we have paved the way for = easy deployment of network provided TURN servers. =20 What about if this is explained in the document after those 3 lines = defining the implicit discovery anycast variant, like this: =93This is outlines a TURN allocate proxy behavior that a gateway router/firewall in front of an ISP provided TURN server may implement = (one of a few variants). If a real-time application like WebRTC defines the = usage of TURN for such configuration, it should be possible to work = generally.=94 =20 A TURN server pinpointed by a firewall/router at the default gateway = should always be trusted (no explicit authentication with credentials is = needed) and used. (We trust the default gateway with all our traffic anyway, and = any evil intent to disturb real-time traffic can in such case be implemented = in a default gateway by easier means.) =20 - the TURN server pinpointed by a default gateway shall always be = trusted and used and the security methods under 9.3 will not have to be applied. =20 [Some of these features should be repeated under the Deployment and = Security sections] =20 6) Under =937. Deployment Considerations=94, the ease of the Anycast = method and suggested variant could be pointed out. Those methods can be used over = any network and by TURN clients under common operating systems. =20 It should be adviced to configure discovered TURN servers to be allowed = to be used without credentials for the users that they are intended to = serve, to achieve the goal of this draft (simply by make the TURN server = available to allocate from, only on the network it is supposed to serve, thus no credentials are needed to protect the TURN server resource as with the application provided TURN servers). =20 What about the following text? NEW: Clients can use TURN servers provided by the local network or by the = access network without authenticating with the TURN server. It is recommended = that clients use (D)TLS with network provided TURN servers to authenticate = and prevent man-in-middle attacks. =20 [Karl] Now I think you hit a confusing point that is a source of the authenticate/authorize/credential issue popping up now and again = relating to this draft: Here you say =93use =85 without authentication=94 (meaning = that users need not have credentials) followed by =93to authenticate=94 (meaning = checking that the TURN server has a valid certificate) =20 =20 In http://www.ietf.org/mail-archive/web/tram/current/msg01747.html the question of =93authenticate and authorize the discovered TURN = server(s)=94 arose again. I think the full story must be spelled out clearly, e.g.: =93The purpose of discovery of a network provided TURN server is to find = a TURN server offered by a network provider or a network admin, to be used = for real-time traffic by the users on that network segment. For WebRTC usage =93everywhere you can surf=94, such TURN servers must be used without = requiring users to have credentials for responding to authentication challenges. Network provided TURN servers must therefore be configured to not = challenge allocation requests from the network segment that they serve and the = TURN server should only be available to and advertised to those users.=20 An advertised network provided TURN server, shall simply be interpreted = as an advice to use the TURN server path for real-time traffic, instead of using the default gateway path. The level of trust is the same for both paths (since both the default gateway and the TURN server are offered = and arranged by the network provider). A sealed configuration (as outlined = in draft-ietf-rtcweb-return) can be arranged by the network provider by blocking STUN packets in the default gateway. For use cases where individual user configuration is wanted and = possible, maybe at an enterprise LAN where not all users should be allowed to use = the TURN server, the TURN server must be configured to authenticate the = users, and credentials then be given to the users. However, for such (unusual) = use cases, it is probably easier and better to also give the IP address of = the TURN server itself to the users, so discovery according to this document would then not be used.=94 I think advice about usage of UPD/TCP/TLS/D(TLS) with the turn server is/shall be out of scope of this draft and left to ICE and the RETURN = draft procedures. In the case of WebRTC, encryption and man-in-the-middle-attacks are end-to-end (P2P) considerations and really not affected by the TURN transport. And if there was a successful attacker, probably smart enough = to buy a certificate for his =93smartattacker.com=94 domain name, how could (D)TLS=92s verification of that certificate help anything? =96 It will = not even be displayed to the browser user. Understanding that the network provided TURN server has the same level = of trust as the default gateway as it effectively parallels, there is no = reason for, and nothing good achieved by checking for certificates or similar = (you don=92t do that for using the default gateway) =96 It is not for this application. Instead, such statements would risks slow down/stop = deployment of network provided TURN servers (and the encryption would hinder the scenario above, with a gateway router/firewall in front of an ISP = network provided TURN server). =20 The DHCP method may also be easy to deploy where used (e.g. Enterprise, = Home and WiFi). However, with IPV6, RA (Router Advertisement) is often used instead of DHCP to hand out ip addresses. The important mobile world (3G/4G/LTE) has its own methods, and there are still PPoE and PPoA in = use, where DHCP cannot be used. If a network service provides announces a = TURN server using DHCP, the following firewall needs to pick that up and = advice that to the users on the LAN. DHCP may not be available on some = operating systems where the TURN client, specifically the WebRTC device, should be able to be implemented on. =20 If DHCP cannot be used in a specific network then other discovery = mechanisms discussed in the draft should be used. [Karl] Fully agree =96 my intention was only that this (and where it may apply) is pointed out more clearly in the document. =20 7)I don=92t understand the sentences under =939. Security = Considerations=94 =93In general, it is recommended that a TURN client authenticate with = the TURN server to identify a rouge server. [RFC7350] can be potentially used by = a client to validate a previously unknown server.=94 It must be explained and detailed, how and what is authenticated or validated, for what purpose and how this may help to achieve the goals = of this recommendation, or these sentences should simply be deleted. =20 Sure, we=92ll add more text around authentication. [Karl] Considering what I just wrote above, here is the place to put = usage of UPD/TCP/TLS/D(TLS) out of scope of this document, and/or clarify that D(TLS) is NOT for typical WebRTC usage.=20 =20 =20 -Prashanth=20 =20 I hope this improves this necessary and good draft and that it quickly = can be adopted. =20 /Karl =20 =20 Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Karl Stahl Skickat: den 19 juli 2015 20:23 Till: 'Benjamin Schwartz'; 'Cullen Jennings (fluffy)' Kopia: rtcweb@ietf.org; tram@ietf.org =C4mne: Re: [tram] [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN discovery: =20 Benjamin =96 your concern is valid =96 I thought exo-sealed was easy to = do in the browser. =20 Below I list a firewall configuration assisted method to address the = TURN server and bandwidth resource consumption problem for local WebRTC calls when using the sealed configuration. I believe my suggestion also will = meet all security/trust/privacy perspectives and give secure = auto-configuration, so mobile devices can to be used with high-quality secure WebRTC communication =93everywhere you can surf=94 through proper use of = Border TURN servers - which must be the (almost already achieved) purpose of this = RETURN draft. =20 After some consideration, to achieve the preferred exo-sealed = configuration, the RETURN drafts already prescribes the best default configuration: = =93leaky=94 ! :-)=20 Explanations inline below --> =20 Below are also some suggestions for inclusion in the drafts: draft-ietf-tram-turn-server-discovery-03 draft-jennings-behave-rtcweb-firewall-00 =20 /Karl =20 PS: Regarding the TURN Origin debate, I don=92t have a clear view, but = am I not right in the understanding that: * The purpose of the TURN Origin draft was to reduce the pain of WebRTC service providers having to deploy network hardware (the Application Provided TURN server) to get their services used, by allowing the TURN server to serve many applications (through a third party).=20 - The introduction of Border TURN servers releases WebRTC service = providers of that pain (when commonly deployed) (and also put security back in the right place) (Until deployed commonly, yes these SPs unfortunately have = this pain to =93fool their services=94 through users security devices =96 the = firewalls (something which the discussed 3 drafts now finally can remedy (without = the use of Origin)) * However, the Application Provided TURN server may also be for (from = the RETURN draft: 3 Goals, 3.2 independent path control):=20 o improving quality of service by tunneling packets through a = network that is faster than the public internet, + monitoring the usage of UDP services, + troubleshooting and debugging problematic services, + logging connection metadata for legal or auditing reasons, + recording the entire contents of all connections, or - providing partial IP address anonymization (as described in [I-D.ietf-rtcweb-security] Section 4.2.4). (+ and =96 indicates the conflicting impact the use Origin will bring = for the listed purposes) =20 The RETURN draft honors the application=92s efforts to enforce media = through such Application Provided TURN server (without judging the purpose) (by = use of the Recursively Encapsulation mechanism). =20 My advice now is just to not introduce the Origin discussion in these = drafts where we finally have to resolve the firewall traversal problem with real-time traffic. We need these RFCs in place as soon as ever possible. = I see a risk in that draft-jennings-behave-rtcweb-firewall-00 starts discussing Origin/SNI in an effort to make a pretty secure WebRTC aware firewall somewhat more secure, and think the draft can advice firewall vendors how to build firewalls that are fully secure and allows = real-time traffic and should also be able to provide a quality pipe for the = real-time traffic. Origin/SNI is not required for that. The Border TURN server and this RETURN-draft will make that possible. =20 -- > Don=92t forget the inline below -- > =20 Fr=E5n: Benjamin Schwartz [mailto:bemasc@webrtc.org]=20 Skickat: den 14 juli 2015 03:16 Till: Karl Stahl Kopia: rtcweb@ietf.org; tram@ietf.org =C4mne: Re: [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, = Configuration and TURN discovery: =20 On Mon, Jul 13, 2015 at 6:19 PM, Karl Stahl < karl.stahl@intertex.se> wrote: We need this draft implemented in WebRTC browsers as soon as possible, = so we can get good WebRTC in difficult places (for firewall traversal and for quality). Is there any implementation e.g. in Chrome that can be tried? Now having stated that I am positive to this draft, I have some concerns/questions/suggestions: 1) We need more levels than sealed/leaky It is not acceptable that WebRTC traffic between parties on a typical = LAN is forced through a TURN server, just because of a sealed configuration required for good WebRTC traffic over the WAN. This consequence is = pointed out under "5.11. Reusing the same TURN server", but IS a problem even = if it "work as expected". Such TURN resource consumption, waste of bandwidth and possible = performance degradation do not happen today, and can easily be avoided. I realize this consequence of "sealed" is required to meet some of the requirements under "3.2. Independent Path Control", but we simply need = an "exo-sealed" level, in addition to the proposed strictly sealed and = leaky, allowing local endpoints to connect media directly, while external = traffic is forced to use the TURN server (rather than STUN through the default gateway). =20 [BS] How do you propose to tell what is "local"? I don't know how to = define that procedurally. =20 [BS] I think my main concern here is that it requires us to "lie" to the remote party, by sending candidates that we may then refuse to use even = if they work. This seems very strange. =20 [Karl] You are right. I assumed the preferred exo-sealed behavior could = be achieved as easily as we do it =93hardware wise=94 today on the inside = of our open test-site https://webrtc.ingate.com where we have a border placed = TURN server paralleling our firewall/default gateway. Our firewall looks for = the magic STUN cookie and discards all STUN packets from the LAN side. TURN = is then automatically enforced and today=92s leaky WebRTC browsers = automatically get the preferred exo-sealed behavior. =20 (Just not using STUN in the browser, would have the same effect but not fully, if there are more subnets on the LAN side. Crossing those subnets would then take media through the dual trip via the TURN server that I = want to avoid.) =20 So, let=92s enforce the preferred exo-sealed configuration by = configuration of the firewall/default gateway (Security from this perspective is then = also in the right hands - the network admin=92s):=20 - Today=92s RETURN-draft=92s leaky default configuration is OK (since = the firewalls discarding STUN automatically enforce the preferred exo-sealed behavior) - Recommend in the RETURN-draft (and in draft-jennings-behave-rtcweb-firewall-00) that the network admin = discards STUN packets from the LAN side through the default gateway (consent = STUNs will go OK through the TURN server), by looking for the magic STUN = cookie, by closing port 3478 or by closing all UDP (the restrictive enterprise firewall can simply be left as it is) to achieve exo-sealed leakiness.=20 - The network admin offers a Border TURN server for its network users = (LAN side only) =96 no need for authentication (free to use from LAN side = being a Border TURN server configuration)=20 - The Border TURN server is offered by the network you are using =96 = Just use it! (should the network provider have evil intentions, he needs no TURN server, he can simply close or destroy WebRTC in the firewall if he = which, which Cullen just exemplified in = draft-jennings-behave-rtcweb-firewall-00) =20 As you may have noticed, I stress that NO credentials should be needed = for using an auto discovered border TURN server. That is also the goal of = TRAM=92s discovery draft, but I have asked TRAM to clarify that achievement. If = we don=92t fix that, we have failed to make WebRTC usable on mobile devices = =96 or can anyone explain where we would get those credentials from when we run around and have Web access here and there and the goal of WebRTC was to = use real-time communication, securely and with high quality, everywhere we = can surf, wasn=92t it?=20 =20 If anyone cries that we NEED AUTHENTICATION, they should remember the IP authentication (simply being on a certain network) is the most commonly = used =93authentication method=94 today and protecting huge values (almost the = whole telco industry) and also achieves privacy (through the use of = firewalls). No individual user credentials which are impossible to handle must be = required. =20 I will in next email propose this new variant of the Anycast method to TRAM. It should work, shouldn=92t it? And does it provide the claimed advantages/features? =96 please check. =20 Implicit discovery by interception of TURN allocate requests at a = default gateway =20 An enterprise firewall or a network server provider=92s router at a = default gateway can intercept a TURN allocate request and respond with a 300 = (Try Alternate) just as described in the Anycast method above. The following procedures and advantages are inherited from the anycast method. =20 This variant adds the following features: - no separate deployment of discovery mechanism is required - no ANA allocated anycast address is required (works with any public ip address)=20 - the default gateway router/firewall in charge of the local network responds with the ip address of: (i) a Border TURN server (paralleling the default gateway), or=20 (ii) a TURN server behind that firewall/default gateway and opens a = path to that TURN server =20 - if the intercepted allocate request was intended for an application provided TURN server, the TURN client (e.g. WebRTC browser) on behalf of = the user, can select to: (iii) only use the auto discovered TURN server (iv) honor an allocation request by really sending the real-time = traffic to the Application Provided TURN server, using the Recursively Encapsulated method, unless (v) the TURN server connected in (ii) already is the Application = Provided TURN server =20 Security wise, the right party is in charge in all cases. A TURN server pinpointed by a firewall/router at the default gateway = should always be trusted (no explicit authentication with credentials is = needed) and used. (We trust the default gateway with all our traffic anyway, and = any evil intent to disturb real-time traffic can in such case be implemented = in a default gateway by easier means.) =20 =20 Such "exo-sealed" configuration should be the default configuration if a network provided TURN server is made available for good (non-evil) = purposes. 2) Mobile devices need to work on various networks, without individual configuration I am not clear about the thoughts behind the "configuration" of sealed = level and requirements for authentication of the turn server, but if there are methods where an enterprise network (LAN) admin can provide credentials = and force a certain sealed level upon the WebRTC-browser when used at that = LAN, or if the user has the possibility to configure manually, I am OK with = that this can and should OVERRIDE any default configuration or other configuration (on that particular network). However, for mobile devices - Don't we all happily connect our browsers = via WiFi here and there? - there must be a way for a network provider with a good intent to offer an exo-sealed TURN server that automatically should = be used, e.g. to achieve the purpose of offering better RTC quality than is available through the default gateway WAN path on that network. A network provided TURN-server can easily be made available ONLY to the network users that it is serving, so there is no need for authentication = and credentials to protect against illegal usage of a valuable resource, = like it is with the application provided turn server. Network provided TURN = servers are simply deployed for the network users to be use without other authentication than being granted an IP address and a default gateway to = use on that particular network in itself. The same goes for trusting the TURN server with our real-time traffic - = If we would trust the same network provider with the same real-time traffic through the default gateway - we should also use the offered TURN server without other "authentication" than that it is available on our network: Data through the default gateway, RTC through the TURN path is why the = TURN server is provided! But do we know that it is not someone with the evil purpose of stealing = our (encrypted!) real time traffic that is offering the TURN server (instead = of the network provider), which leads us to my point 3). (If we really = think there is a risk of and danger with such attacks...) 3) Is it now good enough to simply use the auto discovered TURN server? = Hope so! There has been some recent improvements to draft-ietf-tram-turn-server-discovery-03 and hopefully that is = sufficient for assuming that the auto-discovered TURN server is offered by our = network provider (a service provider or the enterprise itself) that we trust = anyway, and the TURN server then simply shall be used and considered exo-sealed. (The current RETURN draft says a non configured TURN server should be leaky.) =20 The security considerations in that document suggest that not all = discovery mechanisms have equal additional exposure to local network interference. = I would appreciate clearer guidance on that front. It seems to me that = DHCP is the only listed mechanism that creates minimal additional exposure to network interference. =20 --- I am addressing TRAM about this and believe that the variant of the Anycast method I suggest to be added, will fully resolve all security concerns. I am also suggesting that it is up to this RTCWEB draft to = select from TRAM=92s methods and advices for the WebRTC application and its use cases. =20 --- See my deployment concerns regarding DHCP put in front of TRAM. I = think that the Anycast method with a short TTL-limitation is good enough from = the privacy aspect, when used to find Border TURN server. =20 --- Even though the new variant I propose is more secure and even easier = to deploy, I suggest that this RETURN draft mandates the use of the both = the Anycast method and its new variant. The reason is that already today, = all routers/firewalls at a default gateways can add the anycast route = required for discovery, while intercepting the TURN allocate request and = responding with the Try Alternate server probably requires a software upgrade of installed firewalls and routers with default gateways (a firewall in = front of the default gateway can also do the interception and response).=20 =20 Some concerns regarding the DISCOVERY draft and whether these things = should be specified in the RETURN document: - Is the above the case with all discovery methods proposed? Or shall = the RETURN document make one method mandatory to implement? - Can that method then be the Anycast method (which by far seems to be = the most convenient to deploy and to implement and should work for all = network types and in all devices operating systems). I think what is said under "9.3. Anycast" under "9. Security Considerations" is sufficient for trusting such discovered TURN server. What should then go into the = RETURN draft - or should the DISCOVERY draft be more specific? I don't fully understand the DISCOVERY draft's: "... three discovery mechanisms. The reason for providing multiple mechanisms is to maximize = the opportunity for discovery," - Can we really put the burden upon all WebRTC devices to implement all methods and I doubt network providers will deploy more than one method. = That seems risking rather than maximizing discovery... It is high time to get this done - can we? /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto: rtcweb-bounces@ietf.org] F=F6r internet-drafts@ietf.org Skickat: den 14 maj 2015 00:29 Till: i-d-announce@ietf.org Kopia: rtcweb@ietf.org =C4mne: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. Title : Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC Authors : Benjamin M. Schwartz Justin Uberti Filename : draft-ietf-rtcweb-return-00.txt Pages : 18 Date : 2015-05-13 Abstract: In the context of WebRTC, the concept of a local TURN proxy has been suggested, but not reviewed in detail. WebRTC applications are already using TURN to enhance connectivity and privacy. This document explains how local TURN proxies and WebRTC applications can work together. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-return-00 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: = ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 =20 =20 ------=_NextPart_000_00B0_01D0D8FC.4BA90270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi= Prashanth,

 

Se= e comments /explainations inline below.

 

Th= anks,

Ka= rl

 

Fr=E5n: Prashanth = Patil (praspati) [mailto:praspati@cisco.com] =
Skickat: den 14 augusti 2015 02:07
Till: Karl = Stahl; Tirumaleswar Reddy (tireddy); 'Simon Perreault'; 'Benjamin = Schwartz'; Cullen Jennings (fluffy); 'Adam Roach'
Kopia: tram@ietf.org
=C4mne: Re: = [tram] last call on this draft: = draft-ietf-tram-turn-server-discovery-03

 

Hi = Karl,

Appreciate the = review. Responses inline.

 

=

On 7/19/15, 11:34 AM, "tram = on behalf of Karl Stahl" <tram-bounces@ietf.org on behalf of karl.stahl@intertex.se> = wrote:

 

=

I don’t think = draft-ietf-tram-turn-server-discovery-03 draft is not clear enough = yet.

Hopefully the my suggestions below are = non-controversial, only improvements, so we can make this draft an RFC = as soon as possible.

 

The following should be read in the context of the = email below to the RTCWEB WG.

 

1) The result of the valid discussion/concerns =

Ending at: https://mailarchive.ietf.org/arch/msg/tram/W49pCoOHQu2mE-RxokMbq1F= mpOg

about how to achieve auto-configuration (e.g. = necessary for good and secure use of WebRTC on mobile devices) and the = consequent necessity to be able to use the auto discovered TURN server = without credentials, and further that a locally placed turn can achieve = this by being available only from a trusted network,

should be clarified and for which discovery methods it = is achieved.

 

=

Sure, we could add some text = around this, but I don’t think we should get into too much this. =

[K= arl] Did you also read: = http://www.ietf.org/mail-archive/web/tram/current/msg01742.html and =

= http://www.ietf.org/mail-archive/web/tram/current/msg01747.html = ?

I = think this discovery draft should get into this “much = enough” to minimize confusions that came to light = there.

 

You could discover other TURN = servers that may not require credentials, from your ISP, = perhaps.

[K= arl] Yes, of course – that is the intention also – and this = draft should clear enough on that for others to use (e.g. the RETURN = draft)

 

2) Tiru, you and I have had some discussion a year ago = or so about (From 1.  Introduction):

“The reason for providing multiple mechanisms is = to maximize the opportunity for discovery, based on the network in which = the TURN client finds itself.”

 

I questioned whether that goal really can be achieved = unless we mandate (MUST implement) common methods, and whether it is up = to this draft or some RTCWEB draft to be responsible for that. With the = appearance of

d= raft-ietf-rtcweb-return-00

d= raft-jennings-behave-rtcweb-firewall-00

we now have a chance to clarify this.

 

=

The latest draft states that a = client SHOULD implement all methods for best results. It is up to the = client, really. And as you point out, based on application requirements, = a client could implement all or prioritize one over the = others.

 

I fully agree with the goal and necessity of this = draft, but suggest some rephrasing of the Introduction:

“To allow TURN applications operate = real-time traffic seamlessly across different types of networks = and encourage by the use of TURN without the need for = manual configuration, it is important that there exists an auto = discovery mechanism for TURN services. Real-time applications and = specifically Web Real-Time Communication = (WebRTC)[I-D.ietf-rtcweb-overview] usages and related extensions, which = are mostly based on web applications, need this immediately.

 

And that the “multiple mechanism” sentence = is replaced by:

“This document recommends multiple discovery = mechanism, and advices about security such as trust and privacy as well = as deployment efforts. It is up to the specific real-time application = recommendation and its use case to select from these recommendations and = advices.”

 

=

Sure, we'll add your recommended = text in the draft.

 

d= raft-ietf-rtcweb-return-00 can = then specify how the browser shall implement auto discovery for = WebRTC

and = d= raft-jennings-behave-rtcweb-firewall-00 can = then advice firewall vendors how to achieve the goals of this = draft

 

=

Could you please comment on each = draft separately? Tracking and following up becomes much = simpler.

[K= arl] I have done that, but… – This was just a remark (why I = wanted this little rewrite that you just agreed = to)

 

3) The concept of = “sealed”, “leaky” and “exo-leaky” = (see discussion below), the Recursively

[K= arl] Oops – meant “exo sealed” (not = “exo-leaky”) above

Encapsulated method and Border TURN server should be = mentioned and conform with draft-ietf-rtcweb-return-00.

 

4) Explain that the = leakiness for a discovered local TURN server can be auto configured. = E.g.:

“The default = gateway router/firewall can block STUN packets by looking for the magic = STUN cookie, by closing port 3478 or by closing all UDP traffic, to = enforce an exo-sealed configuration for a TURN client having a leaky = default configuration, thus improving security, while avoiding the = overhead of sending the real-time traffic through the TURN server = (twice) with sealed a TURN client configuration (as explained in = d= raft-ietf-rtcweb-return-00).

 

5) After “6.  = Discovery using Anycast” section, add a variant:

 

Implicit discovery by = interception of TURN allocate requests at a default = gateway

 

An enterprise firewall = or a network server provider’s router at a default gateway can = intercept a TURN allocate request and respond with a 300 (Try Alternate) = just as described in the Anycast method above. The following procedures = and advantages are inherited from the anycast method.

 

This variant adds the = following features:

- no separate deployment = of discovery mechanism is required

- no ANA allocated = anycast address is required (works with any public ip address) =

- the default gateway = router/firewall in charge of the local network responds with the ip = address of:

(i)   a Border = TURN server (paralleling the default gateway), or

(ii)  a TURN server = behind that firewall/default gateway and opens a path to that TURN = server  

- if the intercepted = allocate request was intended for an application provided TURN server, = the TURN client (e.g. WebRTC browser) on behalf of the user, can select = to:

(iii) only use the auto = discovered TURN server

(iv)  honor an = allocation request by really sending the real-time traffic to the = Application Provided TURN server, using the Recursively Encapsulated = method, unless

(v)   the = TURN  server connected in (ii) already is the Application Provided = TURN server

 

Security wise, the right = party is in charge in all cases.

 

=

Not really, you’re = intercepting traffic not meant for you.

[K= arl] Isn’t that exactly what firewalls do? (and both of us, Cisco = and Ingate/Intertex are making such = devices…)

Why can’t the = gateway router just listen on the designated anycast address = instead?

[K= arl] It does but must even then follow the same procedure of:=A0 = open a path to the TURN server behind the = gateway!=A0= =A0=A0=A0=A0

 

My= suggestion to add this variant was because what is explained under 4) = above:

- by blocking STUN = packets a gateway router/firewall can enforce an exo-sealed = configuration for a TURN client having a leaky default configuration. If = sealed configuration (by some yet unknown configuration method) is done = just in browser, it will have the unwanted overhead of sending local = real-time traffic twice through the TURN server

 

AN= D because of that the scenario of a the gateway router/firewall in front = of an ISP network provided TURN server, where both want a sealed = configuration where real-time traffic does NOT go through their default = gateways, was not outlined here or in the RETURN draft. =

 

Th= e longer answer to your question:

&g= t; Why = can’t the gateway router just listen on the designated anycast = address instead?

is= :

 

If= such gateway router/firewall just would advise an OWN TURN server, the = browser would have to add yet another level of recursively encapsulating = (for two network provided plus one application provided TURN server) - a = complication we cannot impose. Instead such gateway, must react to an = TURN allocation (by opening a path to the ISP TURN server) – and = *as a consequence* the specific anycast address is not = needed.

 

Th= e procedure suggested for the browser (and thus for the RETURN draft) is = to handle the situation where the gateway intercepts all TURN allocation = requests – that procedure will *also* work if the firewall = instead only reacts to the anycast address and sets up a path (and = allows the next level to respond to it), while a thinner procedure in = the browser may not handle the case where the gateway answers all TURN = allocation requests through its default gateway.

 

So= , by outlining this implicit discovery anycast variant, the RETURN draft = can recommend a procedure that will work for all cases (that the gateway = router/firewall may choose to implement this “kind of TURN = allocation proxy” needed when in front of an ISP TURN server. =

 

AN= D FURTHER, if we know the browser will follow a certain procedure, such = gateway router/firewall in front of an ISP TURN server, can auto = configure itself by following the TURN allocate requests and responses = that passes the gateway router/firewall. I don’t mean it is time = to specify such behavior of such gateway router/firewall in any draft, = but if we already now also outline=A0 the implicit discovery anycast = variant=A0 (The method is only 3 lines of text!) and have the browsers = handle it – we have paved the way for easy deployment of network = provided TURN servers.

 

Wh= at about if this is explained in the document after those 3 lines = defining the implicit discovery anycast variant, like = this:

&#= 8220;This is outlines a TURN allocate proxy behavior that a gateway = router/firewall in front of an ISP provided TURN server may implement = (one of a few variants). If a real-time application like WebRTC defines = the usage of TURN for such configuration, it should be possible to work = generally.”

 

A TURN server pinpointed = by a firewall/router at the default gateway should always be trusted (no = explicit authentication with credentials is needed) and used. (We trust = the default gateway with all our traffic anyway, and any evil intent to = disturb real-time traffic can in such case be implemented in a default = gateway by easier means.)

 

- the TURN server = pinpointed by a default gateway shall always be trusted and used and the = security methods under 9.3 will not have to be applied.

 

[Some of these features = should be repeated under the Deployment and Security = sections]

 

6) Under “7. = Deployment Considerations”, the ease of the Anycast method and = suggested variant could be pointed out. Those methods can be used over = any network and by TURN clients under common operating = systems.

 

It should be adviced to = configure discovered TURN servers to be allowed to be used without = credentials for the users that they are intended to serve, to achieve = the goal of this draft (simply by make the TURN server available to = allocate from, only on the network it is supposed to serve, thus no = credentials are needed to protect the TURN server resource as with the = application provided TURN servers).

 

=

What about the following text?

NEW:

Clients can use TURN servers provided by the local network or by the = access network without authenticating with the TURN server. It is = recommended that clients use (D)TLS with network provided TURN servers = to authenticate and prevent man-in-middle = attacks.

 

[K= arl] Now I think you hit a confusing point that is a source of the = authenticate/authorize/credential issue popping up now and again = relating to this draft: Here you say “use … = without authentication” (meaning that = users need not have credentials) followed by “to = authenticate” (meaning checking that = the TURN server has a valid certificate)=A0 =

 

In= = http://www.ietf.org/mail-archive/web/tram/current/msg01747.html the = question of “authenticate and authorize the discovered TURN = server(s)” arose again.

I = think the full story must be spelled out clearly, = e.g.:

&#= 8220;The purpose of discovery of a network provided TURN server is to = find a TURN server offered by a network provider or a network admin, to = be used for real-time traffic by the users on that network segment. For = WebRTC usage “everywhere you can surf”, such TURN servers = must be used without requiring users to have credentials for responding = to authentication challenges. Network provided TURN servers must = therefore be configured to not challenge allocation requests from the = network segment that they serve and the TURN server should only be = available to and advertised to those users.

An= advertised network provided TURN server, shall simply be interpreted as = an advice to use the TURN server path for real-time traffic, instead of = using the default gateway path. The level of trust is the same for both = paths (since both the default gateway and the TURN server are offered = and arranged by the network provider). A sealed configuration (as = outlined in d= raft-ietf-rtcweb-return) = can be arranged by the network provider by blocking STUN packets in the = default gateway.

Fo= r use cases where individual user configuration is wanted and possible, = maybe at an enterprise LAN where not all users should be allowed to use = the TURN server, the TURN server must be configured to authenticate the = users, and credentials then be given to the users. However, for such = (unusual) use cases, it is probably easier and better to also give the = IP address of the TURN server itself to the users, so discovery = according to this document would then not be = used.”

I = think advice about usage of UPD/TCP/TLS/D(TLS) with the turn server = is/shall be out of scope of this draft and left to ICE and the RETURN = draft procedures.

In= the case of WebRTC, encryption and man-in-the-middle-attacks are = end-to-end (P2P) considerations and really not affected by the TURN = transport. And if there was a successful attacker, probably smart enough = to buy a certificate for his “smartattacker.com” domain = name, how could (D)TLS’s verification of that certificate help = anything? – It will not even be displayed to the browser = user.

Un= derstanding that the network provided TURN server has the same level of = trust as the default gateway as it effectively parallels, there is no = reason for, and nothing good achieved by checking for certificates or = similar (you don’t do that for using the default gateway) – = It is not for this application. Instead, such statements would risks = slow down/stop deployment of network provided TURN servers (and the = encryption would hinder the scenario above, with a ga= teway router/firewall in front of an ISP network provided TURN = server).

 

The DHCP method may also = be easy to deploy where used (e.g. Enterprise, Home and WiFi). However, = with IPV6, RA (Router Advertisement) is often used instead of DHCP to = hand out ip addresses. The important mobile world (3G/4G/LTE) has its = own methods, and there are still PPoE and PPoA in use, where DHCP cannot = be used. If a network service provides announces a TURN server using = DHCP, the following firewall needs to pick that up and advice that to = the users on the LAN. DHCP may not be available on some operating = systems where the TURN client, specifically the WebRTC device, should be = able to be implemented on.

 

=

If DHCP cannot = be used in a specific network then other discovery mechanisms discussed = in the draft should be used.

[K= arl] Fully agree – my intention was only that this (and where it = may apply) is pointed out more clearly in the = document.

 

7)I don’t = understand the sentences under “9.  Security = Considerations”

“In general, it is = recommended that a TURN client authenticate with the TURN server to = identify a rouge server. [RFC7350] can be potentially used by a client = to validate a previously unknown server.”

It must be explained and = detailed, how and what is authenticated or validated, for what purpose = and how this may help to achieve the goals of this recommendation, or = these sentences should simply be deleted.

 

=

Sure, = we’ll add more = text around authentication.

[Karl] = Considering what I just wrote above, here is the place to put = us= age of UPD/TCP/TLS/D(TLS) out of scope of this document, and/or clarify = that D(TLS) is NOT for typical WebRTC usage.

 

 

-Prashanth 

 

I hope this improves = this necessary and good draft and that it quickly can be = adopted.

 

/Karl

 

 

= Fr=E5n:= tram [mailto:tram-bounces@ietf.org] = F=F6r Karl Stahl
Skickat: den 19 juli 2015 = 20:23
Till: 'Benjamin Schwartz'; 'Cullen Jennings = (fluffy)'
Kopia: rtcweb@ietf.org; tram@ietf.org
=C4mne: Re: = [tram] [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Configuration = and TURN discovery:

 

Be= njamin – your concern is valid – I thought exo-sealed was = easy to do in the browser.

&n= bsp;

Be= low I list a firewall configuration assisted method to address the TURN = server and bandwidth resource consumption problem for local WebRTC calls = when using the sealed configuration. I believe my suggestion also will = meet all security/trust/privacy perspectives and give secure = auto-configuration, so mobile devices can to be used with high-quality = secure WebRTC communication “everywhere you can surf” =  through proper use of Border TURN servers - which must be the = (almost already achieved) purpose of this RETURN draft.

&n= bsp;

Af= ter some consideration, to achieve the preferred exo-sealed = configuration, the RETURN drafts already prescribes the best default = configuration: “leaky” ! :-)

Ex= planations inline below -->

&n= bsp;

Be= low are also some suggestions for inclusion in the drafts:

d= raft-ietf-tram-turn-server-discovery-03

d= raft-jennings-behave-rtcweb-firewall-00

&n= bsp;

/K= arl

&n= bsp;

PS= : Regarding the TURN Origin debate, I don’t have a clear view, but = am I not right in the understanding that:

* = The purpose of the TURN Origin draft  was to reduce the pain of = WebRTC service providers having to deploy network hardware (the = Application Provided TURN server) to get their services used, by = allowing the TURN server to serve many applications (through a third = party).

&n= bsp;- The introduction of Border TURN servers releases WebRTC service = providers of that pain (when commonly deployed) (and also put security = back in the right place) (Until deployed commonly, yes these SPs = unfortunately have this pain to “fool their services” = through users security devices – the firewalls (something which = the discussed 3 drafts now finally can remedy (without the use of = Origin))

* = However, the Application Provided TURN server may also be for (from the = RETURN draft: 3 Goals, 3.2 independent path control):

&n= bsp;  o  improving quality of service by tunneling = packets through a network that is faster than the public = internet,

&n= bsp;  +  monitoring the usage of UDP services,

&n= bsp;  +  troubleshooting and debugging problematic = services,

&n= bsp;  +  logging connection metadata for legal or auditing = reasons,

&n= bsp;  +  recording the entire contents of all connections, = or

&n= bsp;  -  providing partial IP address anonymization (as = described in [I-D.ietf-rtcweb-security] Section 4.2.4).

(+= and – indicates the conflicting impact the use Origin will bring = for the listed purposes)

&n= bsp;

Th= e RETURN draft honors the application’s efforts to enforce media = through such Application Provided TURN server (without judging the = purpose) (by use of the Recursively Encapsulation = mechanism).

&n= bsp;

My= advice now is just to not introduce the Origin discussion in these = drafts where we finally have to resolve the firewall traversal problem = with real-time traffic. We need these RFCs in place as soon as ever = possible. I see a risk in that d= raft-jennings-behave-rtcweb-firewall-00 sta= rts discussing Origin/SNI in an effort to make a pretty secure WebRTC = aware firewall somewhat more secure, and think the draft can advice = firewall vendors how to build firewalls that are fully secure and allows = real-time traffic and should also be able to provide a quality pipe for = the real-time traffic. Origin/SNI is not required for that. The Border = TURN server and this RETURN-draft will make that possible.

&n= bsp;

--= > Don’t forget the inline below -- >

&n= bsp;

= Fr=E5n:= Benjamin Schwartz [mailto:bemasc@webrtc.org] =
Skickat: den 14 juli 2015 03:16
Till: Karl = Stahl
Kopia: rtcweb@ietf.org; tram@ietf.org
=C4mne: Re: = [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN = discovery:

 

On Mon, Jul 13, 2015 at 6:19 PM, = Karl Stahl <karl.stahl@intertex.se> = wrote:

We need this draft implemented in = WebRTC browsers as soon as possible, so we
can get good WebRTC in = difficult places (for firewall traversal and for
quality). Is there = any implementation e.g. in Chrome that can be tried?

Now having = stated that I am positive to this draft, I have = some
concerns/questions/suggestions:

1) We need more levels = than sealed/leaky

It is not acceptable that WebRTC traffic = between parties on a typical LAN is
forced through a TURN server, = just because of a sealed configuration
required for good WebRTC = traffic over the WAN. This consequence is pointed
out under = "5.11.  Reusing the same TURN server", but IS a problem = even if it
"work as expected".

Such TURN resource = consumption, waste of bandwidth and possible performance
degradation = do not happen today, and can easily be avoided.

I realize this = consequence of "sealed" is required to meet some of = the
requirements under "3.2.  Independent Path = Control", but we simply need an
"exo-sealed" level, in = addition to the proposed strictly sealed and leaky,
allowing local = endpoints to connect media directly, while external traffic
is forced = to use the TURN server (rather than STUN through the = default
gateway).

 

[BS] How do you propose to tell what = is "local"?  I don't know how to define that = procedurally.

 

[BS] I think my main concern here is = that it requires us to "lie" to the remote party, by sending = candidates that we may then refuse to use even if they work.  This = seems very strange.

 

[K= arl] You are right. I assumed the preferred exo-sealed behavior could be = achieved as easily as we do it “hardware wise” today on the = inside of our open test-site https://webrtc.ingate.com where = we have a border placed TURN server paralleling our firewall/default = gateway. Our firewall looks for the magic STUN cookie and discards all = STUN packets from the LAN side. TURN is then automatically enforced and = today’s leaky WebRTC browsers automatically get the preferred = exo-sealed behavior.

&n= bsp;

(J= ust not using STUN in the browser, would have the same effect but not = fully, if there are more subnets on the LAN side. Crossing those subnets = would then take media through the dual trip via the TURN server that I = want to avoid.)

&n= bsp;

So= , let’s enforce the preferred exo-sealed configuration by = configuration of the firewall/default gateway (Security from this = perspective is then also in the right hands - the network = admin’s):

- = Today’s RETURN-draft’s leaky default configuration is OK = (since the firewalls discarding STUN automatically enforce the preferred = exo-sealed behavior)

- = Recommend in the RETURN-draft (and in d= raft-jennings-behave-rtcweb-firewall-00) =  that the network admin discards STUN packets from the LAN side = through the default gateway (consent STUNs will go OK through the TURN = server), by looking for the magic STUN cookie, by closing port 3478 or = by closing all UDP (the restrictive enterprise firewall can simply be = left as it is) to achieve exo-sealed leakiness.

- = The network admin offers a Border TURN server for its network users (LAN = side only) – no need for authentication (free to use from LAN side = being a Border TURN server configuration)

- = The Border TURN server is offered by the network you are using – = Just use it! (should the network provider have evil intentions, he needs = no TURN server, he can simply close or destroy WebRTC in the firewall if = he which,  which Cullen just exemplified in d= raft-jennings-behave-rtcweb-firewall-00)<= /span>

&n= bsp;

As= you may have noticed, I stress that NO credentials should be needed for = using an auto discovered border TURN server. That is also the goal of = TRAM’s discovery draft, but I have asked TRAM  to clarify = that achievement. If we don’t fix that, we have failed to make = WebRTC usable on mobile devices – or can anyone explain where we = would get those credentials from when we run around and have Web access = here and there and the goal of WebRTC was to use real-time = communication, securely and with high quality, everywhere we can surf, = wasn’t it?

&n= bsp;

If= anyone cries that we NEED AUTHENTICATION, they should remember the IP = authentication (simply being on a certain network) is the most commonly = used “authentication method” today and protecting huge = values (almost the whole telco industry) and also achieves privacy = (through the use of firewalls). No individual user credentials which are = impossible to handle must be required.

&n= bsp;

I = will in next email propose this new variant of the Anycast method =  to TRAM. It should work, shouldn’t it?

An= d does it provide the claimed advantages/features? – please = check.

&n= bsp;

Implicit discovery by interception of TURN allocate = requests at a default gateway

 

An enterprise firewall = or a network server provider’s router at a default gateway can = intercept a TURN allocate request and respond with a 300 (Try Alternate) = just as described in the Anycast method above. The following procedures = and advantages are inherited from the anycast method.

 

This variant adds the = following features:

- no separate deployment = of discovery mechanism is required

- no ANA allocated = anycast address is required (works with any public ip address) =

- the default gateway = router/firewall in charge of the local network responds with the ip = address of:

(i)   a Border = TURN server (paralleling the default gateway), or

(ii)  a TURN server = behind that firewall/default gateway and opens a path to that TURN = server  

- if the intercepted = allocate request was intended for an application provided TURN server, = the TURN client (e.g. WebRTC browser) on behalf of the user, can select = to:

(iii) only use the auto = discovered TURN server

(iv)  honor an = allocation request by really sending the real-time traffic to the = Application Provided TURN server, using the Recursively Encapsulated = method, unless

(v)   the = TURN  server connected in (ii) already is the Application Provided = TURN server

 

Security wise, the right = party is in charge in all cases.

A TURN server pinpointed = by a firewall/router at the default gateway should always be trusted (no = explicit authentication with credentials is needed) and used. (We trust = the default gateway with all our traffic anyway, and any evil intent to = disturb real-time traffic can in such case be implemented in a default = gateway by easier means.)

&n= bsp;

&n= bsp;

Such "exo-sealed" = configuration should be the default configuration if a
network = provided TURN server is made available for good (non-evil) = purposes.


2) Mobile devices need to work on various networks, = without individual
configuration

I am not clear about the = thoughts behind the "configuration" of sealed level
and = requirements for authentication of the turn server, but if there = are
methods where an enterprise network (LAN) admin can provide = credentials and
force a certain sealed level upon the WebRTC-browser = when used at that LAN,
or if the user has the possibility to = configure manually, I am OK with that
this can and should OVERRIDE = any default configuration or other
configuration (on that particular = network).

However, for mobile devices - Don't we all happily = connect our browsers via
WiFi here and there? - there must be a way = for a network provider with a
good intent to offer an exo-sealed TURN = server that automatically should be
used, e.g. to achieve the purpose = of offering better RTC quality than is
available through the default = gateway WAN path on that network.

A network provided TURN-server = can easily be made available ONLY to the
network users that it is = serving, so there is no need for authentication and
credentials to = protect against illegal usage of a valuable resource, like it
is with = the application provided turn server. Network provided TURN = servers
are simply deployed for the network users to be use without = other
authentication than being granted an IP address and a default = gateway to use
on that particular network in itself.

The same = goes for trusting the TURN server with our real-time traffic - If
we = would trust the same network provider with the same real-time = traffic
through the default gateway - we should also use the offered = TURN server
without other "authentication" than that it is = available on our network:
Data through the default gateway, RTC = through the TURN path is why the TURN
server is provided!

But = do we know that it is not someone with the evil purpose of stealing = our
(encrypted!) real time traffic that is offering the TURN server = (instead of
the network provider), which leads us to my point 3). (If = we really think
there is a risk of and danger with such = attacks...)


3) Is it now good enough to simply use the auto = discovered TURN server? Hope
so!

There has been some recent = improvements to
draft-ietf-tram-turn-server-discovery-03 and = hopefully that is sufficient
for assuming that the auto-discovered = TURN server is offered by our network
provider (a service provider or = the enterprise itself) that we trust anyway,
and the TURN server then = simply shall be used and considered exo-sealed.
(The current RETURN = draft says a non configured TURN server should = be
leaky.)

 

The security considerations in = that document suggest that not all discovery mechanisms have equal = additional exposure to local network interference.  I would = appreciate clearer guidance on that front.  It seems to me that = DHCP is the only listed mechanism that creates minimal additional = exposure to network interference.

&n= bsp;

--= - I am addressing TRAM about this and believe that the variant of the = Anycast method I suggest to be added, will fully resolve all security = concerns. I am also suggesting that it is up to this RTCWEB draft to = select from TRAM’s methods and advices for the WebRTC application = and its use cases.

&n= bsp;

--= - See my deployment concerns regarding DHCP put in front of TRAM. I = think that the Anycast method with a short TTL-limitation is good enough = from the privacy aspect, when used to find Border TURN = server.

&n= bsp;

--= - Even though the new variant I propose is more secure and even easier = to deploy, I suggest that this RETURN draft mandates the use of the both = the Anycast method and its new variant. The reason is that already = today, all routers/firewalls at a default gateways can add the anycast = route required for discovery, while intercepting the TURN  allocate = request and responding with the Try Alternate server probably requires a = software upgrade of installed  firewalls and routers with default = gateways (a firewall in front of the default gateway can also do the = interception and response).

&n= bsp;

Some concerns regarding the = DISCOVERY draft and whether these things should
be specified in the = RETURN document:

- Is the above the case with all discovery = methods proposed? Or shall the
RETURN document make one method = mandatory to implement?

- Can that method then be the Anycast = method (which by far seems to be the
most convenient to deploy and to = implement and should work for all network
types and in all devices = operating systems). I think what is said under
"9.3.  = Anycast" under "9.  Security Considerations" is = sufficient for
trusting such discovered TURN server. What should then = go into the RETURN
draft - or should the DISCOVERY draft be more = specific?

I don't fully understand the DISCOVERY draft's: = "... three discovery
mechanisms. The reason for providing = multiple mechanisms is to maximize the
opportunity for = discovery,"

- Can we really put the burden upon all WebRTC = devices to implement all
methods and I doubt network providers will = deploy more than one method. That
seems risking rather than = maximizing discovery...


It is high time to get this done - = can we?

/Karl



-----Ursprungligt = meddelande-----
Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r internet-drafts@ietf.org
Skickat: den 14 = maj 2015 00:29
Till: i-d-announce@ietf.org
Kopia: rtcweb@ietf.org
=C4mne: [rtcweb] I-D Action: = draft-ietf-rtcweb-return-00.txt


A New Internet-Draft is = available from the on-line Internet-Drafts
directories.
 This = draft is a work item of the Real-Time Communication in = WEB-browsers
Working Group of the IETF.

      =   Title           : Recursively = Encapsulated TURN (RETURN) for
Connectivity and Privacy in = WebRTC
        Authors        =  : Benjamin M. Schwartz
          =                 Justin = Uberti
        Filename      =   : draft-ietf-rtcweb-return-00.txt
        = Pages           : 18
    =     Date            : = 2015-05-13

Abstract:
   In the context of WebRTC, = the concept of a local TURN proxy has been
   suggested, = but not reviewed in detail.  WebRTC applications are
  =  already using TURN to enhance connectivity and privacy.  = This
   document explains how local TURN proxies and WebRTC = applications can
   work together.


The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/

There's also a htmlized = version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-return-00


Please note that it = may take a couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

__________________________= _____________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

 

 

 

------=_NextPart_000_00B0_01D0D8FC.4BA90270-- From nobody Mon Aug 24 18:45:18 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265B21ACF04 for ; Mon, 24 Aug 2015 18:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsAfW_MuCkSM for ; Mon, 24 Aug 2015 18:45:14 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C881ACF59 for ; Mon, 24 Aug 2015 18:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21248; q=dns/txt; s=iport; t=1440467113; x=1441676713; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=5D0VHHYYBduQX8CRGrUpw2260ttlLu9H0OCx3gzgf2A=; b=crhAc8ncW5jsoodiku8byPfR/mapDVXx5nATZIC+7IUvSOL4srx6M784 4qaL+6C0Qwpi9O8vPbaeiKcIF7kRqx6i02QaQ3OpkiSoebNqZ1yd8EuID ePfvYe31cv70aItO4eXH16j7xfvfk84T07LyHjvywOh4slX5rb6k6fKE3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CYAgBtyNtV/5NdJa1UCYJOTVRpBr1tAQmHcgKBMDgUAQEBAQEBAYEKhCQBAQSBCQIBCD8HIREUBwEGAwIEARKIGQMSwWQNhTcBAQEBAQUBAQEBAQEBARqLV4JPgV8RUoQsBYxphTaDFQGHcYMTgW2BSpBSeYNQg2omgg0dgVRxgQclHIEEAQEB X-IronPort-AV: E=Sophos;i="5.15,743,1432598400"; d="scan'208,217";a="181623333" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP; 25 Aug 2015 01:44:48 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t7P1ilTI031580 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Aug 2015 01:44:47 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 24 Aug 2015 20:44:47 -0500 Received: from xhc-aln-x14.cisco.com (173.36.12.88) by xch-rcd-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 24 Aug 2015 20:44:47 -0500 Received: from xmb-rcd-x07.cisco.com ([169.254.7.70]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0248.002; Mon, 24 Aug 2015 20:44:46 -0500 From: "Prashanth Patil (praspati)" To: Bernard Aboba , "tram@ietf.org" Thread-Topic: [tram] Review of draft-ietf-tram-turn-server-discovery-04 Thread-Index: AQHQ2DejsL2ieytYxUGpJUJvFE3w254b/s2A Date: Tue, 25 Aug 2015 01:44:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [173.36.7.17] Content-Type: multipart/alternative; boundary="_000_D200F0CEAE902praspaticiscocom_" MIME-Version: 1.0 Archived-At: Subject: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 01:45:17 -0000 --_000_D200F0CEAE902praspaticiscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bernard, On 7/30/15, 11:23 AM, "tram on behalf of Bernard Aboba" on behalf of bernard.aboba@gmail.com> wrote: 1. Overall, in reading this document it was not clear to me how it was inte= nded to be applied to WebRTC scenarios where a TURN server is configured in the = JS. * Does TURN server discovery apply in this case, or is the JS-specified TUR= N server considered "manual TURN configuration" ? Yes, JS-specified TURN server should be considered as auto-configuration. W= e=92ll update the draft accordingly. * Where IdP is used, is the local IdP identity considered to consitute a "d= omain name" per Section 4.1.2? Is there a need to make this explicit? The text in the draft is intentional= ly generic to leave the decision up to the application: "For a TURN client with an understanding of the protocol mechanics of calli= ng applications, the client may wish to extract the domain name from its ow= n identity" 2. In scenarios where TURN Server discovery does apply, what mechanisms are= to be used to authenticate or authorize the discovered TURN Servers(s)? U= sing a configured domain name seems like a potentially viable approach, but= there are scenarios where that might not be configured, or might not be se= cure (e.g. if the domain name were obtained from unauthenticated DHCP). We plan to add the following, does it address some of your concerns: TURN client can use the following techniques to validate a TURN server: o For certificate-based authentication, this includes a pre-populated trust anchor store [rfc6024] that allows the the TURN client to perform path validation for the server certificate= obtained during the (D)TLS handshake. The client MUST use the rules and guidel= ines given in section 6 of [RFC6125] to validate the TURN server identity. 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), the configured list of TURN servers can contain the Subject Public Key Info (SPKI) fingerprint of the TURN servers. The public ke= y is used for the same reasons HTTP pinning [RFC7469] uses the public key. o For raw public key-based authentication as defined in [RFC7250], this includes either the TURN server's public key or the hash of the server's public key. Using the browser's configured trust anchor(s) doesn't seem like a good ide= a, given that it would only be as secure as the least-secure trust anchor. Isn=92t that true with any server the client tries to validate using certif= icates? Specific comments: Section 3 1. Local Configuration : Local or manual TURN configuration (i.e., TURN servers configured at the system level) should be tried first, as it may be an explicit preferred choice of a user. [BA] Would TURN servers specified within a WebRTC JS application be conside= red "local or manual" in this context? Also, shouldn't a configured domain name (Section 4.1.2) be considered part= of "local TURN configuration"? Yes, configured domain name can be considered as local or auto-configuratio= n. IMHO, the configured domain name not only enables discovery as indicated in Section 4.2, but also provides a mechanism for validation of the TURN server discovered by other methods. Correct. We=92ll update the draft to highlight this point. The document does not prescribe a strict order that a client must follow for discovery. An implementation may choose to perform steps 2,3 and 4 in parallel for discovery OR choose to follow any desired order and stop the discovery procedure if a mechanism succeeds. [BA] I am not sure I buy this. It is already stated that "local or manual"= configuration should be tried first, and I would considered a configured d= omain name to be part of this, which would imply attempting 2 first if that= exists. Good point. A client should be able to perform discovery on all in parallel= (or in any order of choice), including manual/auto configuration. Section 9.2 For mDNS, in addition to what has been described above, a principal security threat is a security threat inherent to IP multicast routing and any application that runs on it. A rogue system can advertise that it is a TURN server. Discovery of such rogue systems as TURN servers, in itself, is not a security threat if there is a means for the TURN client to authenticate and authorize the discovered TURN servers. [BA] In scenarios in which mDNS would be used, there typically will not be = a means for the TURN client to authentication and authorize the discovered TURN server. For example, a home router with a built-in TURN server is not likely to have a certificate chaining to a trust anchor. If discovered in a local n/w, a client can be explicitly configured with th= e fingerprint of the server. Also, the mDNS is not compatible with DNSSEC (e.g. there is no signer for the .local domain). Same as above. A client, if configured with a fingerprint, could validate t= he server. Section 9.3 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. [BA] This seems like a crude tool at best. If the goal is to provide priva= cy, wouldn't use of encryption make more sense? This could include DNS privacy= , encryption of TURN traffic, etc. TURN encryption wouldn=92t be possible because the client is not aware of t= he TURN server it is trying to connect. The above is only a recommendation = if a client is concerned with anycast going out of a desired boundary. -Prashanth --_000_D200F0CEAE902praspaticiscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9D95666B717B5944BE029072B372B3EE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Bernard,

On 7/30/15, 11:23 AM, "tram on behalf of Bernard Aboba" <= tram-bounces@ietf.org on behal= f of bernard.aboba@gmail.com> = wrote:

1. Overall, in reading this document it was not clear to me how it was= intended
to be applied to WebRTC scenarios where a TURN server is configured in= the JS. 

* Does TURN server discovery apply in this case, or is the JS-specifie= d TURN server considered "manual TURN configuration" ? 

Yes, JS-specified TURN= server should be considered as auto-configuration. We=92ll update the draf= t accordingly.

* Where IdP is used, is the local IdP identity considered to consitute= a "domain name" per Section 4.1.2?  

Is there a need to mak= e this explicit? The text in the draft is intentionally generic to leave th= e decision up to the application:
"For a=
 TURN client with an understanding of the protocol mechanics of calling app=
lications, the client may wish to extract the domain name from its own iden=
tity"

2. In scenarios where TURN Server discovery does apply, what mechanism= s are to be used to authenticate or authorize the discovered TURN Servers(s= )?  Using a configured domain name seems like a potentially viable app= roach, but there are scenarios where that might not be configured, or might not be secure
(e.g. if the domain name were obtained from unauthenticated DHCP). &nb= sp;

We plan to add the fol= lowing, does it address some of your concerns:

TURN client can use the following techniques to validate a TURN server:

 

   o  For certificate-based authentication, this=

      includes a pre-populated trust anchor store= [rfc6024] that allows the

      the TURN client to perform path valida= tion for the server certificate obtained

      during the (D)TLS handshake. The client MUS= T use the rules and guidelines given in section 6 of

      [RFC6125] to validate the TURN server ident= ity.

 

   o  For TURN servers that don't have a certificate trust = chain

      (e.g., because they are on a home network o= r a corporate network),

      the configured list of TURN servers can con= tain the Subject

      Public Key Info (SPKI) fingerprint of the T= URN servers. The public key is

      used for the same reasons HTTP pinning [RFC= 7469] uses the public key.

 

   o  For raw public key-based authentication as defined in= [RFC7250], this

      includes either the TURN server's public ke= y or the hash of the

      server's public key.

Using the browser's configured trust anchor(s) doesn't seem like a goo= d idea, given that it would only be as secure as the least-secure trust anc= hor. 

Isn=92t that true with= any server the client tries to validate using certificates?

Specific comments: 

Section 3

   1.  Local Configuration : Local or manual TURN confi= guration (i.e.,
       TURN servers configured at the system level= ) should be tried
       first, as it may be an explicit preferred c= hoice of a user.

[BA] Would TURN servers specified within a WebRTC JS application be co= nsidered "local or manual" in this context? 

Also, shouldn't a configured domain name (Section 4.1.2) be considered= part of "local TURN configuration"? 

Yes, configured domain= name can be considered as local or auto-configuration.

IMHO, the configured domain name not only enables discovery as indicat= ed
in Section 4.2, but also provides a mechanism for validation of the
TURN server discovered by other methods.   

Correct. We=92ll updat= e the draft to highlight this point.

   The document does not prescribe a strict order that a cli= ent must
   follow for discovery.  An implementation may choose = to perform steps
   2,3 and 4 in parallel for discovery OR choose to follow a= ny desired
   order and stop the discovery procedure if a mechanism suc= ceeds.

[BA] I am not sure I buy this.  It is already stated that "l= ocal or manual" configuration should be tried first, and I would consi= dered a configured domain name to be part of this, which would imply attemp= ting 2 first if that exists.   

Good point. A client s= hould be able to perform discovery on all in parallel (or in any order of c= hoice), including manual/auto configuration.

Section 9.2

   For mDNS, in addition to what has been described above, a= principal
   security threat is a security threat inherent to IP multi= cast routing
   and any application that runs on it.  A rogue system= can advertise
   that it is a TURN server.  Discovery of such rogue s= ystems as TURN
   servers, in itself, is not a security threat if there is = a means for
   the TURN client to authenticate and authorize the discove= red TURN
   servers.

[BA] In scenarios in which mDNS would be used, there typically will no= t be a
means for the TURN client to authentication and authorize the discover= ed
TURN server. For example, a home router with a built-in TURN server is=
not likely to have a certificate chaining to a trust anchor.

If discovered in a loc= al n/w, a client can be explicitly configured with the fingerprint of the s= erver.

  Also, the
mDNS is not compatible with DNSSEC (e.g. there is no signer for the .l= ocal
domain).  

Same as above. A clien= t, if configured with a fingerprint, could validate the server.

Section 9.3

   Sensitive clients that do not wish to leak information ab= out their
   presence can set an IP TTL on their TURN requests that li= mits how far
   they can travel into the public Internet.

[BA] This seems like a crude tool at best.  If the goal is to pro= vide privacy,
wouldn't use of encryption make more sense?  This could include D= NS privacy,
encryption of TURN traffic, etc. 

TURN encryption wouldn= =92t be possible because the client is not aware of the TURN server it is t= rying to connect. The above is only a recommendation if a client is concern= ed with anycast going out of a desired boundary.

-Prashanth
 --_000_D200F0CEAE902praspaticiscocom_-- From nobody Mon Aug 24 18:47:44 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20E11A1BCD for ; Mon, 24 Aug 2015 18:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqX6G4YX9S_d for ; Mon, 24 Aug 2015 18:47:39 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD0A1A1A67 for ; Mon, 24 Aug 2015 18:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44292; q=dns/txt; s=iport; t=1440467257; x=1441676857; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=MnGdg5BeZBpFQ1zon+oLyZma6rL960DclssWucThv34=; b=jlMD6j1gPrng7BHWhef4B6OL8WuSq71oOCBN5IEs0jMQqY0HoGFKwDDS V5uw+0u8Qd7JbAxd+nnVBYS54vCWprYqNELzVoTVfW1ANsmXTyCUnjIUo umiFC8CUi4VJfukJqGEFjiKJVtgcjwqEzJDC1PtSpc+/0Ng1JIn3qC7Uh s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CZAgBtyNtV/5RdJa1UAwaCTk1UaQa9bQEJgXeFewKBMDgUAQEBAQEBAYEKhCQBAQMBLVELAgEIOAEGBzIUEQIEARIJEogLCA3HGwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLV4QuBAYBAQUISQGELAEEgVCLGYhLAYxxgUqVG4NqJoINHYFUcQGBBQEHFwccgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,743,1432598400"; d="scan'208,217";a="181590286" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP; 25 Aug 2015 01:47:36 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t7P1la3X016105 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Aug 2015 01:47:36 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 24 Aug 2015 20:47:35 -0500 Received: from xhc-rcd-x03.cisco.com (173.37.183.77) by xch-aln-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 24 Aug 2015 20:47:35 -0500 Received: from xmb-rcd-x07.cisco.com ([169.254.7.70]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0248.002; Mon, 24 Aug 2015 20:47:35 -0500 From: "Prashanth Patil (praspati)" To: Karl Stahl , "tram@ietf.org" Thread-Topic: [tram] last call on this draft: draft-ietf-tram-turn-server-discovery-03 Thread-Index: AQHQ1iUXmVhXf6BkRV6lqyfks2yLHZ4LGOoQgAUSOoCAC9iUgA== Date: Tue, 25 Aug 2015 01:47:34 +0000 Message-ID: References: <022601d0c251$9e1944a0$da4bcde0$@stahl@intertex.se> <00c401d0d8eb$db633310$92299930$@com> In-Reply-To: <00c401d0d8eb$db633310$92299930$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [173.37.102.22] Content-Type: multipart/alternative; boundary="_000_D1FF9373AE6AFpraspaticiscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [tram] last call on this draft: draft-ietf-tram-turn-server-discovery-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 01:47:43 -0000 --_000_D1FF9373AE6AFpraspaticiscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Karl, On 8/17/15, 5:54 AM, "Karl Stahl" >= wrote: Hi Prashanth, See comments /explainations inline below. Thanks, Karl Fr=E5n: Prashanth Patil (praspati) [mailto:praspati@cisco.com] Skickat: den 14 augusti 2015 02:07 Till: Karl Stahl; Tirumaleswar Reddy (tireddy); 'Simon Perreault'; 'Benjami= n Schwartz'; Cullen Jennings (fluffy); 'Adam Roach' Kopia: tram@ietf.org =C4mne: Re: [tram] last call on this draft: draft-ietf-tram-turn-server-dis= covery-03 Hi Karl, Appreciate the review. Responses inline. On 7/19/15, 11:34 AM, "tram on behalf of Karl Stahl" on behalf of karl.stahl@intertex.se> wrote Not really, you=92re intercepting traffic not meant for you. [Karl] Isn=92t that exactly what firewalls do? (and both of us, Cisco and I= ngate/Intertex are making such devices=85) Why can=92t the gateway router just listen on the designated anycast addres= s instead? [Karl] It does but must even then follow the same procedure of: open a pat= h to the TURN server behind the gateway! My suggestion to add this variant was because what is explained under 4) ab= ove: - by blocking STUN packets a gateway router/firewall can enforce an exo-sea= led configuration for a TURN client having a leaky default configuration. I= f sealed configuration (by some yet unknown configuration method) is done j= ust in browser, it will have the unwanted overhead of sending local real-ti= me traffic twice through the TURN server AND because of that the scenario of a the gateway router/firewall in front = of an ISP network provided TURN server, where both want a sealed configurat= ion where real-time traffic does NOT go through their default gateways, was= not outlined here or in the RETURN draft. The longer answer to your question: > Why can=92t the gateway router just listen on the designated anycast addr= ess instead? is: If such gateway router/firewall just would advise an OWN TURN server, the b= rowser would have to add yet another level of recursively encapsulating (fo= r two network provided plus one application provided TURN server) - a compl= ication we cannot impose. Instead such gateway, must react to an TURN alloc= ation (by opening a path to the ISP TURN server) =96 and *as a consequence*= the specific anycast address is not needed. The procedure suggested for the browser (and thus for the RETURN draft) is = to handle the situation where the gateway intercepts all TURN allocation re= quests =96 that procedure will *also* work if the firewall instead only rea= cts to the anycast address and sets up a path (and allows the next level to= respond to it), while a thinner procedure in the browser may not handle th= e case where the gateway answers all TURN allocation requests through its d= efault gateway. So, by outlining this implicit discovery anycast variant, the RETURN draft = can recommend a procedure that will work for all cases (that the gateway ro= uter/firewall may choose to implement this =93kind of TURN allocation proxy= =94 needed when in front of an ISP TURN server. AND FURTHER, if we know the browser will follow a certain procedure, such g= ateway router/firewall in front of an ISP TURN server, can auto configure i= tself by following the TURN allocate requests and responses that passes the= gateway router/firewall. I don=92t mean it is time to specify such behavio= r of such gateway router/firewall in any draft, but if we already now also = outline the implicit discovery anycast variant (The method is only 3 line= s of text!) and have the browsers handle it =96 we have paved the way for e= asy deployment of network provided TURN servers. What about if this is explained in the document after those 3 lines definin= g the implicit discovery anycast variant, like this: =93This is outlines a TURN allocate proxy behavior that a gateway router/fi= rewall in front of an ISP provided TURN server may implement (one of a few = variants). If a real-time application like WebRTC defines the usage of TURN= for such configuration, it should be possible to work generally.=94 I still don=92t understand why a GW cannot listen on anycast and return a 3= 00 Try Alternate =96 you achieve the same thing as intercepting anycast req= uests flowing through the device. In any case, I don=92t think this draft should deal with this; we should li= mit discussion to discovering TURN servers. This seems like something that = should go into a use-cases/solution guide draft. What about the following text? NEW: Clients can use TURN servers provided by the local network or by the access= network without authenticating with the TURN server. It is recommended tha= t clients use (D)TLS with network provided TURN servers to authenticate and= prevent man-in-middle attacks. [Karl] Now I think you hit a confusing point that is a source of the authen= ticate/authorize/credential issue popping up now and again relating to this= draft: Here you say =93use =85 without authentication=94 (meaning that use= rs need not have credentials) followed by =93to authenticate=94 (meaning ch= ecking that the TURN server has a valid certificate) We=92ll reword to =93validate the the TURN server=94. In http://www.ietf.org/mail-archive/web/tram/current/msg01747.html the ques= tion of =93authenticate and authorize the discovered TURN server(s)=94 aros= e again. I think the full story must be spelled out clearly, e.g.: =93The purpose of discovery of a network provided TURN server is to find a = TURN server offered by a network provider or a network admin, to be used fo= r real-time traffic by the users on that network segment. For WebRTC usage = =93everywhere you can surf=94, such TURN servers must be used without requi= ring users to have credentials for responding to authentication challenges.= Network provided TURN servers must therefore be configured to not challeng= e allocation requests from the network segment that they serve and the TURN= server should only be available to and advertised to those users. An advertised network provided TURN server, shall simply be interpreted as = an advice to use the TURN server path for real-time traffic, instead of usi= ng the default gateway path. The level of trust is the same for both paths = (since both the default gateway and the TURN server are offered and arrange= d by the network provider). A sealed configuration (as outlined in draft-ie= tf-rtcweb-return) can be arranged by the network provider by blocking STUN = packets in the default gateway. For use cases where individual user configuration is wanted and possible, m= aybe at an enterprise LAN where not all users should be allowed to use the = TURN server, the TURN server must be configured to authenticate the users, = and credentials then be given to the users. However, for such (unusual) use= cases, it is probably easier and better to also give the IP address of the= TURN server itself to the users, so discovery according to this document w= ould then not be used.=94 I think advice about usage of UPD/TCP/TLS/D(TLS) with the turn server is/sh= all be out of scope of this draft and left to ICE and the RETURN draft proc= edures. We=92re talking of (D)TLS in the context of TURN communication, don=92t bel= ieve it is out of scope. If a TURN client and server do not use long-term credentials for authentica= tion or third-party authorization, (D)TLS can to be used to validate the TU= RN server. It also addresses the problem of MIM modifying TURN messages. TURN client can use the following techniques to validate a TURN server: o For certificate-based authentication, this includes a pre-populated trust anchor store [rfc6024] that allows the the TURN client to perform path validation for the server certificate= obtained during the (D)TLS handshake. The client MUST use the rules and guidel= ines given in section 6 of [RFC6125] to validate the TURN server identity. 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), the configured list of TURN servers can contain the Subject Public Key Info (SPKI) fingerprint of the TURN servers. The public ke= y is used for the same reasons HTTP pinning [RFC7469] uses the public key. o For raw public key-based authentication as defined in [RFC7250], this includes either the TURN server's public key or the hash of the server's public key. In the case of WebRTC, encryption and man-in-the-middle-attacks are end-to-= end (P2P) considerations and really not affected by the TURN transport. And= if there was a successful attacker, probably smart enough to buy a certifi= cate for his =93smartattacker.com=94 domain name, how could (D)TLS=92s veri= fication of that certificate help anything? =96 It will not even be display= ed to the browser user. That is true with any protocol relying on TLS. Certificate validation (from= a trusted CA, or a configured fingerprint) is a legitimate means of determ= ining the authenticity of the server. Understanding that the network provided TURN server has the same level of t= rust as the default gateway as it effectively parallels, there is no reason= for, and nothing good achieved by checking for certificates or similar (yo= u don=92t do that for using the default gateway) =96 It is not for this app= lication. Instead, such statements would risks slow down/stop deployment of= network provided TURN servers (and the encryption would hinder the scenari= o above, with a gateway router/firewall in front of an ISP network provided= TURN server). No, I don=92t think it should be seen as something that hinders deployment.= Security and privacy are important considerations. A client, that doesn=92= t care about these, can choose to ignore server validation or exchange mess= ages over plain text. -Prashanth --_000_D1FF9373AE6AFpraspaticiscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Karl,

On 8/17/15, 5:54 AM, "Karl Stahl" <karl@ingate.com> wrote:

Hi Pr= ashanth,

=  

See comments /explainations inline below.

 

Thanks,

Karl

 

Fr=E5n: Prashanth Patil (praspati) [mailto:praspati@cisco.com]
Skickat: den 14 augusti 2015 02:07
Till: Karl Stahl; Tirumaleswar Reddy (tireddy); 'Simon Perreault'; '= Benjamin Schwartz'; Cullen Jennings (fluffy); 'Adam Roach'
Kopia: tram@ietf.org
=C4mne: Re: [tram] last call on this draft: draft-ietf-tram-turn-ser= ver-discovery-03

&nb= sp;

Hi Karl,

Appreciate the review. Responses inline.

 

On 7/19/15, 11:34 AM, "tram on behalf of Karl Stahl" <= tram-bounces@ietf.org on behalf of karl.stahl@intertex= .se> wrote

 <= /span>

<snip>

 

Not really, you=92re intercepting traffic not meant for you.

[Karl] Isn=92t that exactly what f= irewalls do? (and both of us, Cisco and Ingate/Intertex are making such dev= ices=85)

Why can=92t the gateway router just listen on the designated anycas= t address instead?

[Karl] It does but must even then = follow the same procedure of:  open a path to the TURN server behind the gateway!     

 

My suggestion to add this variant = was because what is explained under 4) above:

- by blocking STUN packets a gateway router/firewal= l can enforce an exo-sealed configuration for a TURN client having a leaky = default configuration. If sealed configuration (by some yet unknown configuration method) is done just in browser, it wil= l have the unwanted overhead of sending local real-time traffic twice throu= gh the TURN server

 

AND because of that the scenario o= f a the gateway router/firewall in front of an ISP network provided TURN se= rver, where both want a sealed configuration where real-time traffic does NOT go through their default gateways, was no= t outlined here or in the RETURN draft.

 

The longer answer to your question= :

> Why can= =92t the gateway router just listen on the designated anycast address inste= ad?

is:

 

If such gateway router/firewall ju= st would advise an OWN TURN server, the browser would have to add yet anoth= er level of recursively encapsulating (for two network provided plus one application provided TURN server) - a c= omplication we cannot impose. Instead such gateway, must react to an TURN a= llocation (by opening a path to the ISP TURN server) =96 and *as a conse= quence* the specific anycast address is not needed.

 

The procedure suggested for the br= owser (and thus for the RETURN draft) is to handle the situation where the = gateway intercepts all TURN allocation requests =96 that procedure will *also* work if the firewall instea= d only reacts to the anycast address and sets up a path (and allows the nex= t level to respond to it), while a thinner procedure in the browser may not= handle the case where the gateway answers all TURN allocation requests through its default gateway.

 

So, by outlining this implicit dis= covery anycast variant, the RETURN draft can recommend a procedure that wil= l work for all cases (that the gateway router/firewall may choose to implement this =93kind of TURN allocation pr= oxy=94 needed when in front of an ISP TURN server.

 

AND FURTHER, if we know the browse= r will follow a certain procedure, such gateway router/firewall in front of= an ISP TURN server, can auto configure itself by following the TURN allocate requests and responses that passes t= he gateway router/firewall. I don=92t mean it is time to specify such behav= ior of such gateway router/firewall in any draft, but if we already now als= o outline  the implicit discovery anycast variant  (The method is only 3 lines of text!) and have the b= rowsers handle it =96 we have paved the way for easy deployment of network = provided TURN servers.

 

What about if this is explained in= the document after those 3 lines defining the implicit discovery anycast v= ariant, like this:

=93This is outlines a TURN allocat= e proxy behavior that a gateway router/firewall in front of an ISP provided= TURN server may implement (one of a few variants). If a real-time application like WebRTC defines the usage of TUR= N for such configuration, it should be possible to work generally.=94

I still don=92t understand why a GW cannot listen on anycast and return a 3= 00 Try Alternate =96 you achieve the same thing as intercepting anycast req= uests flowing through the device.
In any case, I don=92t think this draft should deal with this; we should li= mit discussion to discovering TURN servers. This seems like something that = should go into a use-cases/solution guide draft.

 

<snip>

 

What about the following t= ext?

NEW:

Clients can use TURN serve= rs provided by the local network or by the access network without authentic= ating with the TURN server. It is recommended that clients use (D)TLS with network provided TURN servers to authenticate= and prevent man-in-middle attacks.

 

[Karl] Now I think you hit a co= nfusing point that is a source of the authenticate/authorize/credential iss= ue popping up now and again relating to this draft: Here you say =93use =85 without authentication=94 (meaning that users need not have credentials) f= ollowed by =93to authenticate=94 (meaning checking that the TURN server has a valid certificate) 

We=92ll reword to =93validate the the TURN server=94. 

 

In http://www.ietf.org/mail-archive/web/tram/current/msg01747.html the qu= estion of =93authenticate and authorize the discovered TURN server(s)=94 ar= ose again.

I think the full story must be spelled out clear= ly, e.g.:

=93The purpose of discovery of a network provide= d TURN server is to find a TURN server offered by a network provider or a network admin, to be used for real-time traffic= by the users on that network segment. For WebRTC usage =93everywhere you c= an surf=94, such TURN servers must be used without requiring users to have = credentials for responding to authentication challenges. Network provided TURN servers must therefore be configured to = not challenge allocation requests from the network segment that they serve = and the TURN server should only be available to and advertised to those use= rs.

An advertised network provided TURN server, shal= l simply be interpreted as an advice to use the TURN server path for real-time traffic, instead of using the defau= lt gateway path. The level of trust is the same for both paths (since both = the default gateway and the TURN server are offered and arranged by the net= work provider). A sealed configuration (as outlined in draft-ietf-rtcweb-return<= span lang=3D"EN-US" style=3D"font-size: 12pt; font-family: Arial, sans-seri= f; color: blue;">) can be arranged by the network provider by blocking STUN packets in the default gateway.

For use cases where individual user configuratio= n is wanted and possible, maybe at an enterprise LAN where not all users should be allowed to use the TURN server, the TURN= server must be configured to authenticate the users, and credentials then = be given to the users. However, for such (unusual) use cases, it is probabl= y easier and better to also give the IP address of the TURN server itself to the users, so discovery accord= ing to this document would then not be used.=94

I think advice about usage of UPD/TCP/TLS/D(TLS)= with the turn server is/shall be out of scope of this draft and left to ICE and the RETURN draft procedures.

We=92re talking of (D)TL= S in the context of TURN communication, don=92t believe it is out= of scope. 

If a T= URN client and server do not use long-term credentials for authentication o= r third-party authorization, (D)TLS can to be used to validate the TURN ser= ver. It also addresses the problem of MIM modifying TURN messages.

 

TURN client can use the following techniques to validate a= TURN server:

 

   o  For certificate-based authentication,= this

      includes a pre-populated tr= ust anchor store [rfc6024] that allows the

      the TURN client to per= form path validation for the server certificate obtained<= /p>

      during the (D)TLS handshake= . The client MUST use the rules and guidelines given in section 6 of

      [RFC6125] to validate the T= URN server identity.

 

   o  For TURN servers that don't have a ce= rtificate trust chain

      (e.g., because they are on = a home network or a corporate network),

      the configured list of TURN= servers can contain the Subject

      Public Key Info (SPKI) fing= erprint of the TURN servers. The public key is

      used for the same reasons H= TTP pinning [RFC7469] uses the public key.

 

   o  For raw public key-based authenticati= on as defined in [RFC7250], this

      includes either the TURN se= rver's public key or the hash of the

      server's public key.=


In the case of WebRTC, encryption and man-in-the= -middle-attacks are end-to-end (P2P) considerations and really not affected by the TURN transport. And if there was a successf= ul attacker, probably smart enough to buy a certificate for his =93smartatt= acker.com=94 domain name, how could (D)TLS=92s verification of that certifi= cate help anything? =96 It will not even be displayed to the browser user.

That is true with any protocol relying on TLS. Certificate validation (from= a trusted CA, or a configured fingerprint) is a legitimate means of determ= ining the authenticity of the server.

Understanding that the network provided TURN server has the sam= e level of trust as the default gateway as it effectively parallels, there is no reason for, and nothing good achi= eved by checking for certificates or similar (you don=92t do that for using= the default gateway) =96 It is not for this application. Instead, such sta= tements would risks slow down/stop deployment of network provided TURN servers (and the encryption would hinder the scen= ario above, with a gateway router/firewall in front of an ISP network provi= ded TURN server).

No, I don=92t think it should be seen as something that hinders deployment.= Security and privacy are important considerations. A client, that doesn=92= t care about these, can choose to ignore server validation or exchange mess= ages over plain text.

-Prashanth


 


 --_000_D1FF9373AE6AFpraspaticiscocom_-- From nobody Tue Aug 25 12:57:44 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B051A010E for ; Tue, 25 Aug 2015 12:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9lUNor0Szlt for ; Tue, 25 Aug 2015 12:57:41 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 516E51A87D9 for ; Tue, 25 Aug 2015 12:57:41 -0700 (PDT) Received: by iodv127 with SMTP id v127so200383979iod.3 for ; Tue, 25 Aug 2015 12:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=zMSpGtbFyW3pl+Khl0uhW+i8zzEwiK89qC8RNEoFhm0=; b=VszVz3Dkn5vjLBKsU73YZep8idqzZMFNH43u9psXQ2HEqNt62YoGK73cyguewav8IK GExbJuqACDPtk0q3UCI9lLGHmfm9CHAXMpuuIzxyVYTIYQOp8jtxAJiXp8TE8L4QheVi JSXKyq0nZcz+4LH7DykgeS1XutqkLBnjmMkZeZ8JFJ6xo3s8OCkZfBc7NPPqBQn5lFJG HJglAKMZkFAEwS4ooeAg0CWsonFPJC3UJR9RhlTkO12qzNOFvRHNbQgO4PrPMiSm7djh 7JpBGhhf97B4o2WKqL80i+q4CcI5gql3CL8hX+BoKrCwDDKuC+uCRnLDdgsxDO2KF62Y vL7w== MIME-Version: 1.0 X-Received: by 10.107.11.29 with SMTP id v29mr27083797ioi.186.1440532660611; Tue, 25 Aug 2015 12:57:40 -0700 (PDT) Received: by 10.79.32.86 with HTTP; Tue, 25 Aug 2015 12:57:40 -0700 (PDT) Date: Tue, 25 Aug 2015 14:57:40 -0500 Message-ID: From: Alan Johnston To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=001a113e059685f3ff051e28258b Archived-At: Cc: "draft-ietf-tram-stun-origin@tools.ietf.org" Subject: [tram] Path Forward for STUN ORIGIN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 19:57:43 -0000 --001a113e059685f3ff051e28258b Content-Type: text/plain; charset=UTF-8 All, Based on feedback during IETF-93 in Prague, the authors of draft-ietf-stun-origin are looking for feedback on a possible path forward to solve the privacy/meta data issues and clear the DISCUSSes (see https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ballot/). There are two areas of feedback: Use Cases and Proposed Solution. Use Cases ======== First, we want to be sure that we are considering all the use cases for STUN ORIGIN. In the draft, three are described: 1. Logging of usage of STUN/TURN server. An operator of a STUN or TURN server would learn the Origin of the web, SIP, and XMPP users. 2. REALM selection for multi-tenanted TURN server. This avoids having to run multiple instances on different ports or IP addresses when more than one REALM is in use. 3. Service determination after authentication. Bandwidth or QoS policy can be applied, after authentication, based on the Origin. Also, the following use cases have also been discussed but are not in the draft 4. Authorization at border TURN server after authentication. An enterprise border TURN server can apply policy and allow usage for certain Origins (whitelist) or block usage of others (blacklist). 5. draft-jennings-behave-rtcweb-firewall-01 discusses how a firewall with STUN server could use ORIGIN in authorization decisions. Are there any other use cases we should consider? Possible Solution ============= The solution that was discussed in Prague that seems to be the best tradeoff between privacy and functionality is to only include ORIGIN information in a STUN or TURN request if the domain of the Origin matches the domain of the STUN or TURN server in the STUN or TURN URI. Since web and STUN and TURN run on different ports, and often will resolve to different IP addresses, a full host comparison is not possible. This proposal is not perfect: it does not provide perfect privacy for subdomains (e.g. sub1.example.com and sub2.example.com will match with this rule, even if they are separate entities. Of course, subdomain users could always register a new domain and point DNS records to their sub hoster.) In comparing this solution against the use cases above: 1. Allows logging of your own users on your own TURN server (or one that you setup DNS SRV records to point towards). Other users of your STUN or TURN server will not be identified by an Origin, but you will at least know if others are using your server. 2. Works for REALM selection as long as you use your own TURN server (or one that you setup DNS SRV records to point towards). 3. Again, works for service determination as long as you use your own TURN server (or one that you setup DNS SRV records to point towards). Having service-specific TURN credentials is another solution that doesn't rely on ORIGIN. 4. & 5. Does not seem provide a good solution for these use cases. Does this analysis make sense? Feedback most welcome so we can move forward with this draft. - Alan - --001a113e059685f3ff051e28258b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Based on feedback during IETF-93 i= n Prague, the authors of draft-ietf-stun-origin are looking for feedback on= a possible path forward to solve the privacy/meta data issues and clear th= e DISCUSSes (see https://datatracker.ietf.org/doc/draft-ietf-tram-stu= n-origin/ballot/).=C2=A0 There are two areas of feedback: Use Cases and= Proposed Solution.

Use Cases
=3D=3D=3D= =3D=3D=3D=3D=3D

First, we want to be sure that we = are considering all the use cases for STUN ORIGIN.=C2=A0 In the draft, thre= e are described:

1.=C2=A0 Logging of usage of= STUN/TURN server. An operator of a STUN or TURN server would learn the Ori= gin of the web, SIP, and XMPP users. =C2=A0

2.=C2= =A0 REALM selection for multi-tenanted TURN server. This avoids having to r= un multiple instances on different ports or IP addresses when more than one= REALM is in use.

3.=C2=A0 Service determination a= fter authentication.=C2=A0 Bandwidth or QoS policy can be applied, after au= thentication, based on the Origin.

Also, the= following use cases have also been discussed but are not in the draft

4.=C2=A0 Authorization at border TURN server after aut= hentication.=C2=A0 An enterprise border TURN server can apply policy and al= low usage for certain Origins (whitelist) or block usage of others (blackli= st).

5. draft-jennings-behave-rtcweb-firewall-01 d= iscusses how a firewall with STUN server could use ORIGIN in authorization = decisions.

Are there any other use cases we should= consider?

Possible Solution
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The soluti= on that was discussed in Prague that seems to be the best tradeoff between = privacy and functionality is to only include ORIGIN information in a STUN o= r TURN request if the domain of the Origin matches the domain of the STUN o= r TURN server in the STUN or TURN URI.=C2=A0 Since web and STUN and TURN ru= n on different ports, and often will resolve to different IP addresses, a f= ull host comparison is not possible.=C2=A0 This proposal is not perfect: it= does not provide perfect privacy for subdomains (e.g. sub1.example.com and sub2.example.com will match with this rule, even if they are separate= entities.=C2=A0 Of course, subdomain users could always register a new dom= ain and point DNS records to their sub hoster.)

In= comparing this solution against the use cases above:

<= div>1. Allows logging of your own users on your own TURN server (or one tha= t you setup DNS SRV records to point towards).=C2=A0 Other users of your ST= UN or TURN server will not be identified by an Origin, but you will at leas= t know if others are using your server.

2. Works f= or REALM selection as long as you use your own TURN server (or one that you= setup DNS SRV records to point towards).

3. Again= , works for service determination as long as you use your own TURN server (= or one that you setup DNS SRV records to point towards).=C2=A0 Having servi= ce-specific TURN credentials is another solution that doesn't rely on O= RIGIN.

4. & 5. Does not seem provide a good so= lution for these use cases.

Does this analysis mak= e sense?

Feedback most welcome so we can move forw= ard with this draft.

- Alan -

=

--001a113e059685f3ff051e28258b-- From nobody Tue Aug 25 13:41:12 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0351B2F0A for ; Tue, 25 Aug 2015 13:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jsvltyhf4dk0 for ; Tue, 25 Aug 2015 13:41:03 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9D81B2F0D for ; Tue, 25 Aug 2015 13:41:03 -0700 (PDT) Received: by ykdt205 with SMTP id t205so168167435ykd.1 for ; Tue, 25 Aug 2015 13:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E/zcErtF/2yxqxkOOAxZSpESi7S25tpL6Qh19VMmaq0=; b=FfDPaCctAFYKEQuDPoXGgG1USl8CqSyiTZEfoa4rmmEBb80PqYROHi70nQFeCiDx6w OuW3uBZMXjSqMiA9jYzQgN+rdgE7EOuLycJdCu4vQllXQTtxVhxgwxqEPhB49Ifrl1lO cZ9bF9duT7gy6rcCKSW4lcnE+phqPT67YYzo5PXXoUp53nOtCplK1hC0INShFDJr9S1g jIX87mZe2/5rmY1l5yPL2aai0/dkSlcuF73uGqk60dbAaauIq3KqhojTY2Y7IwXrMeal mUHPH6a0zv0ruhYw2Yx7aJSWRfVCSZuvqBP1KiMsMrLR5JlFc4IpYtqWtVZdnUSOdVbT lkyA== MIME-Version: 1.0 X-Received: by 10.170.199.7 with SMTP id q7mr10589292yke.57.1440535262851; Tue, 25 Aug 2015 13:41:02 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Tue, 25 Aug 2015 13:41:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Aug 2015 13:41:02 -0700 Message-ID: From: Martin Thomson To: Alan Johnston Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tram@ietf.org" , "draft-ietf-tram-stun-origin@tools.ietf.org" Subject: Re: [tram] Path Forward for STUN ORIGIN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 20:41:07 -0000 I'm wondering here whether this might be advised by similar work in the area. ORIGIN is analogous to the HTTP Referer [sic] header field. There, the damage was done long ago, and we aren't sure that it can be fixed. After several attempts to reduce the information that we expose by default, I think that browser vendors are basically resigned to status quo (at least for now). That's the cautionary aspect of this discussion that we have to be aware of. However, what advises this is the secondary controls browsers are providing for controlling use of Referer. See referrer policy [1]. All this is driven by a simple principle: if we see an explicit signal that a site wants to share Referer, then we include it for them. This is based on the realization that if we don't do this, they will find another way to exfiltrate the data. Usernames and passwords being the obvious channels available for TURN, but I'll observe that there are no winners if you force people to resort to hacks to get the information they need or think they need. Maybe all we need to do here is recognize that we need to provide adequate controls. Make it clear that you expect someone else (hello browser vendors) to apply the policies. If a TURN server is configured with a special flag (call it "includeOrigin" for argument's sake), then we might send the ORIGIN attribute. Then, I think that the concerns raised around privacy can be addressed by having ORIGIN omitted by default. Privacy-preserving by default is perhaps the most relevant concern here. I realize that this might be less than ideal for you because it means talking to a whole new set of people over @w3.org, but I think that option is likely to be less cumbersome than your proposed solution. [1] http://w3c.github.io/webappsec/specs/referrer-policy/ On 25 August 2015 at 12:57, Alan Johnston wrote: > All, > > Based on feedback during IETF-93 in Prague, the authors of > draft-ietf-stun-origin are looking for feedback on a possible path forward > to solve the privacy/meta data issues and clear the DISCUSSes (see > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ballot/). > There are two areas of feedback: Use Cases and Proposed Solution. > > Use Cases > ======== > > First, we want to be sure that we are considering all the use cases for STUN > ORIGIN. In the draft, three are described: > > 1. Logging of usage of STUN/TURN server. An operator of a STUN or TURN > server would learn the Origin of the web, SIP, and XMPP users. > > 2. REALM selection for multi-tenanted TURN server. This avoids having to > run multiple instances on different ports or IP addresses when more than one > REALM is in use. > > 3. Service determination after authentication. Bandwidth or QoS policy can > be applied, after authentication, based on the Origin. > > Also, the following use cases have also been discussed but are not in the > draft > > 4. Authorization at border TURN server after authentication. An enterprise > border TURN server can apply policy and allow usage for certain Origins > (whitelist) or block usage of others (blacklist). > > 5. draft-jennings-behave-rtcweb-firewall-01 discusses how a firewall with > STUN server could use ORIGIN in authorization decisions. > > Are there any other use cases we should consider? > > Possible Solution > ============= > > The solution that was discussed in Prague that seems to be the best tradeoff > between privacy and functionality is to only include ORIGIN information in a > STUN or TURN request if the domain of the Origin matches the domain of the > STUN or TURN server in the STUN or TURN URI. Since web and STUN and TURN > run on different ports, and often will resolve to different IP addresses, a > full host comparison is not possible. This proposal is not perfect: it does > not provide perfect privacy for subdomains (e.g. sub1.example.com and > sub2.example.com will match with this rule, even if they are separate > entities. Of course, subdomain users could always register a new domain and > point DNS records to their sub hoster.) > > In comparing this solution against the use cases above: > > 1. Allows logging of your own users on your own TURN server (or one that you > setup DNS SRV records to point towards). Other users of your STUN or TURN > server will not be identified by an Origin, but you will at least know if > others are using your server. > > 2. Works for REALM selection as long as you use your own TURN server (or one > that you setup DNS SRV records to point towards). > > 3. Again, works for service determination as long as you use your own TURN > server (or one that you setup DNS SRV records to point towards). Having > service-specific TURN credentials is another solution that doesn't rely on > ORIGIN. > > 4. & 5. Does not seem provide a good solution for these use cases. > > Does this analysis make sense? > > Feedback most welcome so we can move forward with this draft. > > - Alan - > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Wed Aug 26 02:56:54 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70301B2A66 for ; Wed, 26 Aug 2015 02:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sov1ttMujOC9 for ; Wed, 26 Aug 2015 02:56:51 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6EED51B2A62 for ; Wed, 26 Aug 2015 02:56:51 -0700 (PDT) Received: from [IPv6:2602:61:7515:ec00:e15b:f468:d1b9:1432] (unknown [IPv6:2602:61:7515:ec00:e15b:f468:d1b9:1432]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id F283F2025B for ; Wed, 26 Aug 2015 11:56:49 +0200 (CEST) References: <20150720180753.18424.83272.idtracker@ietfa.amsl.com> To: tram@ietf.org From: Marc Petit-Huguenin Message-ID: <55DD8D5F.4020106@acm.org> Date: Wed, 26 Aug 2015 03:56:47 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150720180753.18424.83272.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-04.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 09:56:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I think that retrieving a TURN server IP address from a DHT (i.e. using RFC 6940 section 9) should be added to the list of mechanisms. I can send text. Thanks. On 07/20/2015 12:07 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TURN Revised and Modernized Working Group of the IETF. > > Title : TURN Server Auto Discovery > Authors : Prashanth Patil > Tirumaleswar Reddy > Dan Wing > Filename : draft-ietf-tram-turn-server-discovery-04.txt > Pages : 14 > Date : 2015-07-20 > > Abstract: > Current Traversal Using Relays around NAT (TURN) server discovery > mechanisms are relatively static and limited to explicit > configuration. These are usually under the administrative control of > the application or TURN service provider, and not the enterprise, > ISP, or the network in which the client is located. Enterprises and > ISPs wishing to provide their own TURN servers need auto discovery > mechanisms that a TURN client could use with no or minimal > configuration. This document describes three such mechanisms for > TURN server discovery. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-server-discovery-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV3Y1fAAoJECnERZXWan7Eqa4QAN3Y6p29P6wCake9C2OGcBvK D7gHMSlHgWMKnt1L6XQmxVCP23QagqQEMHeXSA2zWsYLl+u7DTzwyROWa2PDrRIj INsosmK66gqWTY2czfXs/WGL7X/+ZR6vq9VpmJm0UkyHrKCnD3LvYPpeIIq8Bvj+ Yd+Oi6tBBT2nEzq3G1huKCwPnoxRgzTRGc7yIFm9xs/PO0Ar6GVLv4urKyLOWqVc R0w/54TaL2OWHVvYPV9o+DdRG57b+J6jZFujvcmSAzVi7NR5FURVvJD6l/Pl8wtZ 7QyJDDB8q4CyN+58XdfJXUptGPT0co2u90M4LL5dYgldSVZNWr8yev24UGt6U3eN jJ2bohz57kJ5TyAKm6pN4CSs4pvUKyZQshRu5VltWv6JsTuPe2WyxYvOF2F1BzFK 0UDycIJOhZRUA3JKPhp2KF5CodsFeaIkugvAT7PBXu1vWN9fxY4firfDj3STax7F RoLf9H0zMzwmDemIFmC1q1rof0/3zQs/FNBOz2rZSyh8VwEFFK8Heiy0EFLhBrZ0 LUID19e6LtM7sNn8npGHo4zHLHKEEOBWPY82k+hxvF1bFSwmFwswQx22+zhD0Egw ueE4SJQSWitBvqs/F9BHPK/r0qIiADwDpep6oKNQT/gh7LbA2+9wQlgVy8u8zR9S fqKBsm5PinzVJqI5VJoy =kbH6 -----END PGP SIGNATURE----- From nobody Wed Aug 26 03:29:24 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEBA1A8932 for ; Wed, 26 Aug 2015 03:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pyc0U0dFr1vo for ; Wed, 26 Aug 2015 03:29:22 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 50CAC1A8745 for ; Wed, 26 Aug 2015 03:29:22 -0700 (PDT) Received: from [IPv6:2602:61:7515:ec00:e15b:f468:d1b9:1432] (unknown [IPv6:2602:61:7515:ec00:e15b:f468:d1b9:1432]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 52FF22025B for ; Wed, 26 Aug 2015 12:29:21 +0200 (CEST) To: "tram@ietf.org" From: Marc Petit-Huguenin X-Enigmail-Draft-Status: N1110 Message-ID: <55DD94FF.7080400@acm.org> Date: Wed, 26 Aug 2015 04:29:19 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [tram] Transport of ICMP errors in TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 10:29:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 During the presentation of the Path MTU Discovery Using STUN draft in Prague, there was some discussion on how ICMP can be received by the client when the PMTUD probes are sent through a TURN server. Which reminded me that I worked on that problem when I proposed PMTUD over STUN, back in 2008. That was the case, according to my notes, but in fact the idea of tunneling the ICMP packets through the TURN server was proposed the year before, but for a different reason: https://mailarchive.ietf.org/arch/msg/behave/76pAtymXlAtF5SoD0rgoFECf2Fg So my proposal is to add this into turnbis. I can provide text. Thanks. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV3ZT+AAoJECnERZXWan7E0JoQAILKCgPBsAbm5YbcIGnQWtC8 xfi5j0lFXNtJvtVSKpC9MypTsusP7se2b/TDLzVMk02plduxmtIGw5LAlNhnosK8 AhL2O3vJ1oZ7Nxyw10OXARbsY04XsWu9dLPxHpA+gs7r/IZFBMtMOJtGXZH3MGdQ lKvU30wSpVOTf6Fi5mTQePBPi1rDQd6tK++1jSehl1iqVgsAOTAGOwgN8jZTqGpi azFJzbAEqjd8q8Zj+PtGkQlK1A2YxRpLRaRVWChzef89iMwQiAktG7SsgYCbsYor GMdkpQCKZ/NEeDeVKld3OUyFh+MzQ5sUniqbQa3+LRIJ1p2/+QU9nti3kjLuvmb8 jYnmOQKNS/jXkdZBvmmLtdZvg2ytYhjYZMEDQR5bVHhHNOQBZcCmnLtotoBONaUs yyMOh/m7+ub0GFrfyF1oRZm9Jy5/4Z45GLGEZla4YmSxkUDPiVkyEPXz3LFdJdzo YXDYSzt+ryrG8ZSZIlNUTO0vK0NDwe5n7zApXlL5L6JnLLr3Eg3984SCNnJG6l8e nTdvL8aBg0ixsny0rmjOzwKRTrXXut/QrIuW5MLiQLWIDxuaFRuQlkoNxnVR2+VU UVbf2JoFLXFTskgf6kL4+LwVE/Z1mbf5v4Xj2upWWvG6KnFEVgsswwkxsgnlslAo AsZutBz1M7gIvw8UbJem =1Ku/ -----END PGP SIGNATURE----- From nobody Wed Aug 26 05:29:46 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9631A88C3 for ; Wed, 26 Aug 2015 05:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYJe36PEgIGf for ; Wed, 26 Aug 2015 05:29:43 -0700 (PDT) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C861A87D7 for ; Wed, 26 Aug 2015 05:29:43 -0700 (PDT) Received: by oiey141 with SMTP id y141so120103212oie.1 for ; Wed, 26 Aug 2015 05:29:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=alUZVbBro3oSlJ4unuxRHqBmsEqaE4Q4AkNOHRAqdL0=; b=EBnXpdlSF1+IWD6rdRoCfy6JtEMV0AOv0MNMZ/JwiOHd9FNsnqJhR+niorigfxEI0q Ol45ukXfpFlW4M1INopKMjD9KK2p12WWhtFp9eTTQbodYDiteYir0DuDZGHrTaU7lJcC IUWO+xGQXpMrSTUV6PV/y/jL4gi+5vQa2zY4ETPSV8EuTJjZ9DFsQNuXSBlaKnK4ZH1t v4h8yLn7pLVIElAlATHpJzyastHV4R9792sZk5UQjafXvClo/alvlgEttEKAbjkn/aQm qtF8o3s3/CazCuzU0ENt8a280k9AfkrqQAFq9KrwnsOebrENLPpou6NIJcOST/IMKCl+ wxaA== X-Gm-Message-State: ALoCoQlFY9A2SnqoaWuwLhvOkWad3EqTbFT50UDdfBs00YJSm5uUMyoVJvg9N1UJXgw3Q5F7TjZE X-Received: by 10.202.176.136 with SMTP id z130mr7170598oie.42.1440592182700; Wed, 26 Aug 2015 05:29:42 -0700 (PDT) Received: from [192.168.1.44] (modemcable164.157-22-96.mc.videotron.ca. [96.22.157.164]) by smtp.googlemail.com with ESMTPSA id l128sm14275045oig.12.2015.08.26.05.29.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Aug 2015 05:29:41 -0700 (PDT) To: Marc Petit-Huguenin , "tram@ietf.org" References: <55DD94FF.7080400@acm.org> From: Simon Perreault X-Enigmail-Draft-Status: N1010 Message-ID: <55DDB133.6090608@jive.com> Date: Wed, 26 Aug 2015 08:29:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55DD94FF.7080400@acm.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] Transport of ICMP errors in TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 12:29:45 -0000 Le 2015-08-26 06:29, Marc Petit-Huguenin a écrit : > During the presentation of the Path MTU Discovery Using STUN draft in Prague, there was some discussion on how ICMP can be received by the client when the PMTUD probes are sent through a TURN server. Which reminded me that I worked on that problem when I proposed PMTUD over STUN, back in 2008. That was the case, according to my notes, but in fact the idea of tunneling the ICMP packets through the TURN server was proposed the year before, but for a different reason: > > https://mailarchive.ietf.org/arch/msg/behave/76pAtymXlAtF5SoD0rgoFECf2Fg > > So my proposal is to add this into turnbis. I can provide text. RFC 5766 section 2.6 explains that ICMP not being relayed was a design decision to make it possible to run a TURN server as an unprivileged user. That conclusion is wrong for two reasons: - With the BSD sockets API, some ICMP errors are translated into recv() error codes. This means that it is always possible to relay at least some subset of ICMP errors. (Not sure for TCP or IPv6, I'd need to check.) - On Linux, which dominates the market of TURN server, one can receive all ICMP errors as an unprivileged user with the IP(V6)_RECVERR socket option. So my conclusion is: yes, please. :) Simon From nobody Wed Aug 26 13:59:11 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989791B2F00 for ; Wed, 26 Aug 2015 13:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BFax0SXcf-i for ; Wed, 26 Aug 2015 13:59:07 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2911B2FE1 for ; Wed, 26 Aug 2015 13:59:07 -0700 (PDT) Received: by vkd66 with SMTP id 66so95633614vkd.0 for ; Wed, 26 Aug 2015 13:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7oxQi9Mm2ULFQj4t1g8LyvisTjkAHI26TSm7jVvM5kc=; b=OfhatbFGloGu2Drkfd8TXrDO9PMH9hA03nLFi22Qgx0P57Xo1PgiojjT8jx6Fr3i6w WF0JDGcg0tCISr3JYLH8RxH3CAYPnL6IVOAhigdcqitQ5RJHU3IglOjdVM8JQXU93C9T 5WoG7/WK31xWuglEgNfEk+Rsq4TGgmBBNXIbybjhZ0aMzJRJ6ZRC3sHEgA0/y+P29sm+ pfxQJNsIB0T0fMnAA6YDZ6ByeRv1zOs7t/Hfac+H+bhjlVLuPmvWL5NRHPgKrgs/9eTl 71mwf1ZNM+J18IxneD9o8HGP4K/wOQfiZm8BUvXKTboEVatgyvIshl5P3dhKHKVam8qY rvYA== MIME-Version: 1.0 X-Received: by 10.52.227.73 with SMTP id ry9mr776780vdc.82.1440622746386; Wed, 26 Aug 2015 13:59:06 -0700 (PDT) Received: by 10.31.153.206 with HTTP; Wed, 26 Aug 2015 13:59:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Aug 2015 15:59:06 -0500 Message-ID: From: Alan Johnston To: Martin Thomson Content-Type: multipart/alternative; boundary=089e01176cf30dc92e051e3d1f2c Archived-At: Cc: "tram@ietf.org" , "draft-ietf-tram-stun-origin@tools.ietf.org" Subject: Re: [tram] Path Forward for STUN ORIGIN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 20:59:10 -0000 --089e01176cf30dc92e051e3d1f2c Content-Type: text/plain; charset=UTF-8 Hi Martin, This is a very interesting idea - thanks for raising it. Looking at the referrer-policy document, the proposal here is essentially a default global policy of "origin-only" except not quite as strict. The idea of the STUN or TURN URI suggesting the policy which would be enforced by the browser is an interesting one. Since the application STUN or TURN server is provided by the JavaScript, it effectively means the WebRTC web page would set the policy for inclusion of ORIGIN. I'm trying to think if this makes sense or not in this context. I guess the privacy leakage goes both ways - the STUN or TURN server operator learns about the WebRTC site that the user is using, and it also learns which WebRTC sites are being used. We have mainly been thinking about privacy for the first case, not the second case. Having the WebRTC application decide if ORIGIN should be shared with the STUN or TURN server does provide privacy for the second case Having user agent (i.e. browser user interface) controls for ORIGIN would provide privacy for the first case. Of course, there is still the issue of what to do if the STUN TURN server requires ORIGIN but the user doesn't provide it. The referrer-policy document doesn't make any judgements on the various policy levels it defines. Is the "origin-only" policy considered privacy friendly in HTTP, or is it considered harmful? Do any browsers provide referrer-policy user interface controls? If so, I wonder what the default setting would be? But if the HTTP experience is that the Referrer header field was just that it was a bad idea to begin with, then perhaps we should pay attention to that... - Alan - On Tue, Aug 25, 2015 at 3:41 PM, Martin Thomson wrote: > I'm wondering here whether this might be advised by similar work in the > area. > > ORIGIN is analogous to the HTTP Referer [sic] header field. There, > the damage was done long ago, and we aren't sure that it can be fixed. > After several attempts to reduce the information that we expose by > default, I think that browser vendors are basically resigned to status > quo (at least for now). That's the cautionary aspect of this > discussion that we have to be aware of. > > However, what advises this is the secondary controls browsers are > providing for controlling use of Referer. See referrer policy [1]. > All this is driven by a simple principle: if we see an explicit signal > that a site wants to share Referer, then we include it for them. This > is based on the realization that if we don't do this, they will find > another way to exfiltrate the data. Usernames and passwords being the > obvious channels available for TURN, but I'll observe that there are > no winners if you force people to resort to hacks to get the > information they need or think they need. > > Maybe all we need to do here is recognize that we need to provide > adequate controls. Make it clear that you expect someone else (hello > browser vendors) to apply the policies. If a TURN server is > configured with a special flag (call it "includeOrigin" for argument's > sake), then we might send the ORIGIN attribute. Then, I think that > the concerns raised around privacy can be addressed by having ORIGIN > omitted by default. Privacy-preserving by default is perhaps the most > relevant concern here. > > I realize that this might be less than ideal for you because it means > talking to a whole new set of people over @w3.org, but I think that > option is likely to be less cumbersome than your proposed solution. > > [1] http://w3c.github.io/webappsec/specs/referrer-policy/ > > On 25 August 2015 at 12:57, Alan Johnston > wrote: > > All, > > > > Based on feedback during IETF-93 in Prague, the authors of > > draft-ietf-stun-origin are looking for feedback on a possible path > forward > > to solve the privacy/meta data issues and clear the DISCUSSes (see > > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ballot/). > > There are two areas of feedback: Use Cases and Proposed Solution. > > > > Use Cases > > ======== > > > > First, we want to be sure that we are considering all the use cases for > STUN > > ORIGIN. In the draft, three are described: > > > > 1. Logging of usage of STUN/TURN server. An operator of a STUN or TURN > > server would learn the Origin of the web, SIP, and XMPP users. > > > > 2. REALM selection for multi-tenanted TURN server. This avoids having to > > run multiple instances on different ports or IP addresses when more than > one > > REALM is in use. > > > > 3. Service determination after authentication. Bandwidth or QoS policy > can > > be applied, after authentication, based on the Origin. > > > > Also, the following use cases have also been discussed but are not in the > > draft > > > > 4. Authorization at border TURN server after authentication. An > enterprise > > border TURN server can apply policy and allow usage for certain Origins > > (whitelist) or block usage of others (blacklist). > > > > 5. draft-jennings-behave-rtcweb-firewall-01 discusses how a firewall with > > STUN server could use ORIGIN in authorization decisions. > > > > Are there any other use cases we should consider? > > > > Possible Solution > > ============= > > > > The solution that was discussed in Prague that seems to be the best > tradeoff > > between privacy and functionality is to only include ORIGIN information > in a > > STUN or TURN request if the domain of the Origin matches the domain of > the > > STUN or TURN server in the STUN or TURN URI. Since web and STUN and TURN > > run on different ports, and often will resolve to different IP > addresses, a > > full host comparison is not possible. This proposal is not perfect: it > does > > not provide perfect privacy for subdomains (e.g. sub1.example.com and > > sub2.example.com will match with this rule, even if they are separate > > entities. Of course, subdomain users could always register a new domain > and > > point DNS records to their sub hoster.) > > > > In comparing this solution against the use cases above: > > > > 1. Allows logging of your own users on your own TURN server (or one that > you > > setup DNS SRV records to point towards). Other users of your STUN or > TURN > > server will not be identified by an Origin, but you will at least know if > > others are using your server. > > > > 2. Works for REALM selection as long as you use your own TURN server (or > one > > that you setup DNS SRV records to point towards). > > > > 3. Again, works for service determination as long as you use your own > TURN > > server (or one that you setup DNS SRV records to point towards). Having > > service-specific TURN credentials is another solution that doesn't rely > on > > ORIGIN. > > > > 4. & 5. Does not seem provide a good solution for these use cases. > > > > Does this analysis make sense? > > > > Feedback most welcome so we can move forward with this draft. > > > > - Alan - > > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > > --089e01176cf30dc92e051e3d1f2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin,

This is a very interesting i= dea - thanks for raising it.

Looking at the referr= er-policy document, the proposal here is essentially a default global polic= y of "origin-only" except not quite as strict.

The idea of the STUN or TURN URI suggesting the policy which would b= e enforced by the browser is an interesting one.=C2=A0 Since the applicatio= n STUN or TURN server is provided by the JavaScript, it effectively means t= he WebRTC web page would set the policy for inclusion of ORIGIN.=C2=A0 I= 9;m trying to think if this makes sense or not in this context.=C2=A0 I gue= ss the privacy leakage goes both ways - the STUN or TURN server operator le= arns about the WebRTC site that the user is using, and it also learns which= WebRTC sites are being used.=C2=A0 We have mainly been thinking about priv= acy for the first case, not the second case.=C2=A0 Having the WebRTC applic= ation decide if ORIGIN should be shared with the STUN or TURN server does p= rovide privacy for the second case =C2=A0Having user agent (i.e. browser us= er interface) controls for ORIGIN would provide privacy for the first case.= =C2=A0 Of course, there is still the issue of what to do if the STUN TURN s= erver requires ORIGIN but the user doesn't provide it.

The referrer-policy document doesn't make any judgements on th= e various policy levels it defines. Is the "origin-only" policy c= onsidered privacy friendly in HTTP, or is it considered harmful?
<= div>
Do any browsers provide referrer-policy user interface c= ontrols?=C2=A0 If so, I wonder what the default setting would be?=C2=A0

But if the HTTP experience is that the Referrer heade= r field was just that it was a bad idea to begin with, then perhaps we shou= ld pay attention to that...

- Alan -

On Tue, Aug 25, 2015 at 3= :41 PM, Martin Thomson <martin.thomson@gmail.com> wro= te:
I'm wondering here whether this m= ight be advised by similar work in the area.

ORIGIN is analogous to the HTTP Referer [sic] header field.=C2=A0 There, the damage was done long ago, and we aren't sure that it can be fixed.<= br> After several attempts to reduce the information that we expose by
default, I think that browser vendors are basically resigned to status
quo (at least for now).=C2=A0 That's the cautionary aspect of this
discussion that we have to be aware of.

However, what advises this is the secondary controls browsers are
providing for controlling use of Referer.=C2=A0 See referrer policy [1]. All this is driven by a simple principle: if we see an explicit signal
that a site wants to share Referer, then we include it for them.=C2=A0 This=
is based on the realization that if we don't do this, they will find another way to exfiltrate the data.=C2=A0 Usernames and passwords being the=
obvious channels available for TURN, but I'll observe that there are no winners if you force people to resort to hacks to get the
information they need or think they need.

Maybe all we need to do here is recognize that we need to provide
adequate controls.=C2=A0 Make it clear that you expect someone else (hello<= br> browser vendors) to apply the policies.=C2=A0 If a TURN server is
configured with a special flag (call it "includeOrigin" for argum= ent's
sake), then we might send the ORIGIN attribute.=C2=A0 Then, I think that the concerns raised around privacy can be addressed by having ORIGIN
omitted by default.=C2=A0 Privacy-preserving by default is perhaps the most=
relevant concern here.

I realize that this might be less than ideal for you because it means
talking to a whole new set of people over @w3.org, but I think that
option is likely to be less cumbersome than your proposed solution.

[1] http://w3c.github.io/webappsec/specs/refe= rrer-policy/

On 25 August 2015 at 12:57, Alan Johnston <alan.b.johnston@gmail.com> wrote:
> All,
>
> Based on feedback during IETF-93 in Prague, the authors of
> draft-ietf-stun-origin are looking for feedback on a possible path for= ward
> to solve the privacy/meta data issues and clear the DISCUSSes (see
> https://datatracker.ietf.or= g/doc/draft-ietf-tram-stun-origin/ballot/).
> There are two areas of feedback: Use Cases and Proposed Solution.
>
> Use Cases
> =3D=3D=3D=3D=3D=3D=3D=3D
>
> First, we want to be sure that we are considering all the use cases fo= r STUN
> ORIGIN.=C2=A0 In the draft, three are described:
>
> 1.=C2=A0 Logging of usage of STUN/TURN server. An operator of a STUN o= r TURN
> server would learn the Origin of the web, SIP, and XMPP users.
>
> 2.=C2=A0 REALM selection for multi-tenanted TURN server. This avoids h= aving to
> run multiple instances on different ports or IP addresses when more th= an one
> REALM is in use.
>
> 3.=C2=A0 Service determination after authentication.=C2=A0 Bandwidth o= r QoS policy can
> be applied, after authentication, based on the Origin.
>
> Also, the following use cases have also been discussed but are not in = the
> draft
>
> 4.=C2=A0 Authorization at border TURN server after authentication.=C2= =A0 An enterprise
> border TURN server can apply policy and allow usage for certain Origin= s
> (whitelist) or block usage of others (blacklist).
>
> 5. draft-jennings-behave-rtcweb-firewall-01 discusses how a firewall w= ith
> STUN server could use ORIGIN in authorization decisions.
>
> Are there any other use cases we should consider?
>
> Possible Solution
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The solution that was discussed in Prague that seems to be the best tr= adeoff
> between privacy and functionality is to only include ORIGIN informatio= n in a
> STUN or TURN request if the domain of the Origin matches the domain of= the
> STUN or TURN server in the STUN or TURN URI.=C2=A0 Since web and STUN = and TURN
> run on different ports, and often will resolve to different IP address= es, a
> full host comparison is not possible.=C2=A0 This proposal is not perfe= ct: it does
> not provide perfect privacy for subdomains (e.g. sub1.example.com an= d
> sub2.example.com will match with this rule, even if they are separat= e
> entities.=C2=A0 Of course, subdomain users could always register a new= domain and
> point DNS records to their sub hoster.)
>
> In comparing this solution against the use cases above:
>
> 1. Allows logging of your own users on your own TURN server (or one th= at you
> setup DNS SRV records to point towards).=C2=A0 Other users of your STU= N or TURN
> server will not be identified by an Origin, but you will at least know= if
> others are using your server.
>
> 2. Works for REALM selection as long as you use your own TURN server (= or one
> that you setup DNS SRV records to point towards).
>
> 3. Again, works for service determination as long as you use your own = TURN
> server (or one that you setup DNS SRV records to point towards).=C2=A0= Having
> service-specific TURN credentials is another solution that doesn't= rely on
> ORIGIN.
>
> 4. & 5. Does not seem provide a good solution for these use cases.=
>
> Does this analysis make sense?
>
> Feedback most welcome so we can move forward with this draft.
>
> - Alan -
>
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>

--089e01176cf30dc92e051e3d1f2c-- From nobody Wed Aug 26 14:07:11 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156351A8A66 for ; Wed, 26 Aug 2015 14:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNPujNb8EYWg for ; Wed, 26 Aug 2015 14:07:07 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283F91A888E for ; Wed, 26 Aug 2015 14:07:07 -0700 (PDT) Received: by vkm66 with SMTP id 66so95692641vkm.1 for ; Wed, 26 Aug 2015 14:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NCzOo/UtrhE23YWN8OZTdzq3tTPdA9rY7y8mvTN2sDU=; b=yJpvOmIJuhHSpgL4+tMEBx4is6Pmizbf/Z28kn/wuKFpAx8f29qYky/5CXQVPQ1N8c 4xG4Q3wxrg8t02yv0QLugPqYzHc/1v0QuBZH6DiTfOJbE5RyDottFKfshjIxM1u+02OI EKy4sAXAQko3QShJmfE5EPS1HBkUaYA0zgTaMDEMqUAd4q/UqXD7oOzZHWXCyjlRZJG8 uBIn0sZkLd76Tz/nAf5v0pGC/gO/54hw6Ww+i+PB3Qfc2UBIDU03HfPSbF+EJxRQmEaZ UUOYbpig6EkB8ZzoLzYUn8aMLBtsJr05sqUlEdHFieLRlaunM9OWh14q0WPA1jK72QGj zAQQ== MIME-Version: 1.0 X-Received: by 10.52.187.196 with SMTP id fu4mr818250vdc.33.1440623226418; Wed, 26 Aug 2015 14:07:06 -0700 (PDT) Received: by 10.31.153.206 with HTTP; Wed, 26 Aug 2015 14:07:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Aug 2015 16:07:06 -0500 Message-ID: From: Alan Johnston To: Justin Uberti Content-Type: multipart/alternative; boundary=bcaec548a4e9aa7b19051e3d3bcd Archived-At: Cc: "tram@ietf.org" , "draft-ietf-tram-stun-origin@tools.ietf.org" Subject: Re: [tram] Path Forward for STUN ORIGIN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 21:07:10 -0000 --bcaec548a4e9aa7b19051e3d3bcd Content-Type: text/plain; charset=UTF-8 Justin, It is an important question for the WG on whether ORIGIN is a useful solution to the use cases. Hopefully we'll get more feedback on this. Your comments seem mainly directed towards a solution for use case #2 below (REALM selection for TURN authentication), right? I'm not sure if use case #3 applies or not. I don't think OAuth helps with #1 or #4 or #5. I know we have discussed it before, but I also don't think that everyone believes that OAuth means that ORIGIN is no longer needed. There have been suggestions that a multi-tenanted TURN server using OAuth might still use ORIGIN. And using domain-specific USERNAME attributes sounds a bit like the problem that Martin mentioned of simply working around the approach. - Alan - On Tue, Aug 25, 2015 at 3:50 PM, Justin Uberti wrote: > Overall, I think most/all of the goals that ORIGIN is trying to accomplish > would be better handled by STUN OAuth ( > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/) > > Generally, it's not clear that ORIGIN is a great solution for any of the > use cases listed. > 1) is easily accomplished via oauth, without any of the restrictions > present here > 2) can be dealt with using other means (e.g. oauth, or supplying domain > info in USERNAME) > 3) is fairly weak control, and can be done better through oauth, or > domained USERNAMEs > > Of course, as noted by others, use of domained USERNAMEs creates a > quasi-ORIGIN value within the USERNAME attribute, which makes OAuth more > attractive. > > On Tue, Aug 25, 2015 at 12:57 PM Alan Johnston > wrote: > >> All, >> >> Based on feedback during IETF-93 in Prague, the authors of >> draft-ietf-stun-origin are looking for feedback on a possible path forward >> to solve the privacy/meta data issues and clear the DISCUSSes (see >> https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ballot/). >> There are two areas of feedback: Use Cases and Proposed Solution. >> >> Use Cases >> ======== >> >> First, we want to be sure that we are considering all the use cases for >> STUN ORIGIN. In the draft, three are described: >> >> 1. Logging of usage of STUN/TURN server. An operator of a STUN or TURN >> server would learn the Origin of the web, SIP, and XMPP users. >> >> 2. REALM selection for multi-tenanted TURN server. This avoids having to >> run multiple instances on different ports or IP addresses when more than >> one REALM is in use. >> >> 3. Service determination after authentication. Bandwidth or QoS policy >> can be applied, after authentication, based on the Origin. >> >> Also, the following use cases have also been discussed but are not in the >> draft >> >> 4. Authorization at border TURN server after authentication. An >> enterprise border TURN server can apply policy and allow usage for certain >> Origins (whitelist) or block usage of others (blacklist). >> >> 5. draft-jennings-behave-rtcweb-firewall-01 discusses how a firewall with >> STUN server could use ORIGIN in authorization decisions. >> >> Are there any other use cases we should consider? >> >> Possible Solution >> ============= >> >> The solution that was discussed in Prague that seems to be the best >> tradeoff between privacy and functionality is to only include ORIGIN >> information in a STUN or TURN request if the domain of the Origin matches >> the domain of the STUN or TURN server in the STUN or TURN URI. Since web >> and STUN and TURN run on different ports, and often will resolve to >> different IP addresses, a full host comparison is not possible. This >> proposal is not perfect: it does not provide perfect privacy for subdomains >> (e.g. sub1.example.com and sub2.example.com will match with this rule, >> even if they are separate entities. Of course, subdomain users could >> always register a new domain and point DNS records to their sub hoster.) >> >> In comparing this solution against the use cases above: >> >> 1. Allows logging of your own users on your own TURN server (or one that >> you setup DNS SRV records to point towards). Other users of your STUN or >> TURN server will not be identified by an Origin, but you will at least know >> if others are using your server. >> >> 2. Works for REALM selection as long as you use your own TURN server (or >> one that you setup DNS SRV records to point towards). >> >> 3. Again, works for service determination as long as you use your own >> TURN server (or one that you setup DNS SRV records to point towards). >> Having service-specific TURN credentials is another solution that doesn't >> rely on ORIGIN. >> >> 4. & 5. Does not seem provide a good solution for these use cases. >> >> Does this analysis make sense? >> >> Feedback most welcome so we can move forward with this draft. >> >> - Alan - >> >> >> --bcaec548a4e9aa7b19051e3d3bcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Justin,

It is an important question for= the WG on whether ORIGIN is a useful solution to the use cases.=C2=A0 Hope= fully we'll get more feedback on this.=C2=A0

Y= our comments seem mainly directed towards a solution for use case #2 below = (REALM selection for TURN authentication), right?=C2=A0 I'm not sure if= use case #3 applies or not.=C2=A0 I don't think OAuth helps with #1 or= #4 or #5.

I know we have discussed it before, but= I also don't think that everyone believes that OAuth means that ORIGIN= is no longer needed. There have been suggestions that a multi-tenanted TUR= N server using OAuth might still use ORIGIN.

And u= sing domain-specific USERNAME attributes sounds a bit like the problem that= Martin mentioned of simply working around the approach.

- Alan -

On Tue, Aug 25, 2015 at 3:50 PM, Justin Uberti <justin@uberti.name> wrote:
Over= all, I think most/all of the goals that ORIGIN is trying to accomplish woul= d be better handled by STUN OAuth (https://data= tracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/)

<= /div>
Generally, it&= #39;s not clear that ORIGIN is a great solution for any of the use cases li= sted.
1) is easily accomplished via oauth, = without any of the restrictions present here
2) can be dealt with using other means (e.g. oauth, or supplying dom= ain info in USERNAME)
3) is fairly wea= k control, and can be done better through oauth, or domained USERNAMEs

= Of course, as noted by others, use of domained USERNAMEs creates a quasi-OR= IGIN value within the USERNAME attribute, which makes OAuth more attractive= .

On Tue, Aug 2= 5, 2015 at 12:57 PM Alan Johnston <alan.b.johnston@gmail.com> wrote:
All,

Ba= sed on feedback during IETF-93 in Prague, the authors of draft-ietf-stun-or= igin are looking for feedback on a possible path forward to solve the priva= cy/meta data issues and clear the DISCUSSes (see ht= tps://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ballot/).=C2= =A0 There are two areas of feedback: Use Cases and Proposed Solution.
=

Use Cases
=3D=3D=3D=3D=3D=3D=3D=3D
=
First, we want to be sure that we are considering all the us= e cases for STUN ORIGIN.=C2=A0 In the draft, three are described:

1.=C2=A0 Logging of usage of STUN/TURN server. An oper= ator of a STUN or TURN server would learn the Origin of the web, SIP, and X= MPP users. =C2=A0

2.=C2=A0 REALM selection for mul= ti-tenanted TURN server. This avoids having to run multiple instances on di= fferent ports or IP addresses when more than one REALM is in use.

3.=C2=A0 Service determination after authentication.=C2=A0 = Bandwidth or QoS policy can be applied, after authentication, based on the = Origin.

Also, the following use cases have a= lso been discussed but are not in the draft

4.=C2= =A0 Authorization at border TURN server after authentication.=C2=A0 An ente= rprise border TURN server can apply policy and allow usage for certain Orig= ins (whitelist) or block usage of others (blacklist).

<= div>5. draft-jennings-behave-rtcweb-firewall-01 discusses how a firewall wi= th STUN server could use ORIGIN in authorization decisions.

<= /div>
Are there any other use cases we should consider?

<= /div>
Possible Solution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

The solution that was discussed in= Prague that seems to be the best tradeoff between privacy and functionalit= y is to only include ORIGIN information in a STUN or TURN request if the do= main of the Origin matches the domain of the STUN or TURN server in the STU= N or TURN URI.=C2=A0 Since web and STUN and TURN run on different ports, an= d often will resolve to different IP addresses, a full host comparison is n= ot possible.=C2=A0 This proposal is not perfect: it does not provide perfec= t privacy for subdomains (e.g. sub1.example.com and sub2.example.com will match with this rule, even if the= y are separate entities.=C2=A0 Of course, subdomain users could always regi= ster a new domain and point DNS records to their sub hoster.)
In comparing this solution against the use cases above:

1. Allows logging of your own users on your own TURN serv= er (or one that you setup DNS SRV records to point towards).=C2=A0 Other us= ers of your STUN or TURN server will not be identified by an Origin, but yo= u will at least know if others are using your server.

<= div>2. Works for REALM selection as long as you use your own TURN server (o= r one that you setup DNS SRV records to point towards).

3. Again, works for service determination as long as you use your own= TURN server (or one that you setup DNS SRV records to point towards).=C2= =A0 Having service-specific TURN credentials is another solution that doesn= 't rely on ORIGIN.

4. & 5. Does not seem p= rovide a good solution for these use cases.

Does t= his analysis make sense?

Feedback most welcome so = we can move forward with this draft.

<= /div>
- Alan -



--bcaec548a4e9aa7b19051e3d3bcd-- From nobody Wed Aug 26 15:50:45 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A91D1B3524 for ; Wed, 26 Aug 2015 15:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_56=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVdlq4X7WO4N for ; Wed, 26 Aug 2015 15:50:43 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7991B3525 for ; Wed, 26 Aug 2015 15:50:41 -0700 (PDT) Received: by ykll84 with SMTP id l84so2278961ykl.0 for ; Wed, 26 Aug 2015 15:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8/QhgDce+Tcg9cQwa2P3wOc8bQsd7OFxwtK5XoXd9qg=; b=n4A4AW+pVoCwJcfO2Dmb9YGDnEnt6IPXRvViToEPRzxeO5CqtMB6lBi79JFufdwa7s m7mXsTowhj8QBha1CUPLcveQVE5tXXC53od/supl7RscAqq17qOzBO/IKyAMmwdp5IwV x/ZY1pPr7NmPFE0TlIEEk1yfMNXY1qPLvcyT+MeN/OY8kjmz1h/0umzvXOOkaWHKMV/p b28mSuXEPBy2PFSEv4f+55W2S4yY8VMPCdqoHzDvj4I1ez6ITtoCIFTnzVfXPZYAGtep aP5+T66BpS3yJciVvXM8Uhhtvm0G1XOTyS2PWL/NwCKYxLp2nST9o8AvLz5RERO1CFNu ok3Q== MIME-Version: 1.0 X-Received: by 10.129.103.5 with SMTP id b5mr881755ywc.55.1440629441082; Wed, 26 Aug 2015 15:50:41 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Wed, 26 Aug 2015 15:50:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Aug 2015 15:50:41 -0700 Message-ID: From: Martin Thomson To: Alan Johnston Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tram@ietf.org" , "draft-ietf-tram-stun-origin@tools.ietf.org" Subject: Re: [tram] Path Forward for STUN ORIGIN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 22:50:44 -0000 On 26 August 2015 at 13:59, Alan Johnston wrote: > Hi Martin, > > This is a very interesting idea - thanks for raising it. > > Looking at the referrer-policy document, the proposal here is essentially a > default global policy of "origin-only" except not quite as strict. I was actually going to suggest that no-referrer be the default. It's the policy a lot of us wish we had for Referer. Some of us configure our browsers to do just that. > The idea of the STUN or TURN URI suggesting the policy which would be > enforced by the browser is an interesting one. I wasn't suggesting that it be baked into the URI, but it is an option. Though in the same way that we no longer like to put usernames and passwords in URIs, I don't think that including this origin-policy attribute in there. I was actually thinking that you would have an option on RTCPeerConnection that set the policy. > The referrer-policy document doesn't make any judgements on the various > policy levels it defines. Is the "origin-only" policy considered privacy > friendly in HTTP, or is it considered harmful? That very much depends on where you stand. "origin-only" is not sufficient for some use cases, but is also too much information for others. > Do any browsers provide referrer-policy user interface controls? If so, I > wonder what the default setting would be? Firefox provides control through about:config only, and in the most obtuse fashion imaginable (you have to know what a value of 3 means). The default policies vary depending on the different origins involved, and whether they are secure (i.e.,https://) or not. The defaults we *want* are somewhat different to the ones that we *have* though. > But if the HTTP experience is that the Referrer header field was just that > it was a bad idea to begin with, then perhaps we should pay attention to > that... As I said, it is mixed. Hence the suggestion to allow a measure of control. From nobody Wed Aug 26 18:15:11 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41E11B3863 for ; Wed, 26 Aug 2015 18:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvjxWC8vzOj0 for ; Wed, 26 Aug 2015 18:15:07 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBCFE1B3861 for ; Wed, 26 Aug 2015 18:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25198; q=dns/txt; s=iport; t=1440638107; x=1441847707; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GgltgKzoruQXASnoF6f/DeBepaQB0PfmYtApEnoSUZM=; b=ffy9aBUXJk+JrK+QK0qGcBwBlUzohYEjQICRpUEU8AG0iUuA0K2QbsSR qvei8jTUTnu3EasF5BYaJ0jzJ4VAZ9t5ldj3nYRACP/At/GCzsblSMKV4 vQCD5mxlxkkiPP4oOkIk1tH5Lb2MnzjLXMTZsjEPOYGBaXDxcMtzg74RJ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DJBAAqZN5V/49dJa1dgk5NVGkGgx26JSoBCYF6hXkCHIEaOBQBAQEBAQEBgQqEIwEBAQICIwpMEAIBCBEEAQELHQMCAgIfERQJCAIEAQ0FCBOHfgMSDbN6j0UNhTABAQEBAQEBAQEBAQEBAQEBAQEBAQEXiliBA4I9EoFwGi0EBgEJgmAvgRQFjGyIUAGFBYV/gzdGkRODUINrERWDf3EBgUeBBQEBAQ X-IronPort-AV: E=Sophos; i="5.17,420,1437436800"; d="scan'208,217"; a="27490567" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP; 27 Aug 2015 01:15:06 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t7R1F5Cp008198 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2015 01:15:05 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 26 Aug 2015 20:15:04 -0500 Received: from xhc-rcd-x02.cisco.com (173.37.183.76) by xch-rcd-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 26 Aug 2015 20:15:04 -0500 Received: from xmb-rcd-x10.cisco.com ([169.254.15.53]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0248.002; Wed, 26 Aug 2015 20:15:04 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alan Johnston , Justin Uberti Thread-Topic: [tram] Path Forward for STUN ORIGIN Thread-Index: AQHQ33BbHdq2UKCT/kKmaQfeZhVABZ4ex3+7gABCZKA= Date: Thu, 27 Aug 2015 01:15:03 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478C77E6@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.53.75] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A478C77E6xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" , "draft-ietf-tram-stun-origin@tools.ietf.org" Subject: Re: [tram] Path Forward for STUN ORIGIN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 01:15:09 -0000 --_000_913383AAA69FF945B8F946018B75898A478C77E6xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxhbiwNCg0KT0F1dGggc29sdmVzIGFsbCB0aGUgYmVsb3cgdXNlIGNhc2VzLCAjNCBhbmQg IzUgaXMgZGlzY3Vzc2VkIGluIGh0dHBzOi8vd3d3LmlhYi5vcmcvd3AtY29udGVudC9JQUItdXBs b2Fkcy8yMDE1LzAxL3NlbWkyMDE1X3JlZGR5LnBkZi4NCg0KLVRpcnUNCg0KRnJvbTogdHJhbSBb bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsYW4gSm9obnN0b24N ClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjcsIDIwMTUgMjozNyBBTQ0KVG86IEp1c3RpbiBVYmVy dGkNCkNjOiB0cmFtQGlldGYub3JnOyBkcmFmdC1pZXRmLXRyYW0tc3R1bi1vcmlnaW5AdG9vbHMu aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJhbV0gUGF0aCBGb3J3YXJkIGZvciBTVFVOIE9SSUdJ Tg0KDQpKdXN0aW4sDQoNCkl0IGlzIGFuIGltcG9ydGFudCBxdWVzdGlvbiBmb3IgdGhlIFdHIG9u IHdoZXRoZXIgT1JJR0lOIGlzIGEgdXNlZnVsIHNvbHV0aW9uIHRvIHRoZSB1c2UgY2FzZXMuICBI b3BlZnVsbHkgd2UnbGwgZ2V0IG1vcmUgZmVlZGJhY2sgb24gdGhpcy4NCg0KWW91ciBjb21tZW50 cyBzZWVtIG1haW5seSBkaXJlY3RlZCB0b3dhcmRzIGEgc29sdXRpb24gZm9yIHVzZSBjYXNlICMy IGJlbG93IChSRUFMTSBzZWxlY3Rpb24gZm9yIFRVUk4gYXV0aGVudGljYXRpb24pLCByaWdodD8g IEknbSBub3Qgc3VyZSBpZiB1c2UgY2FzZSAjMyBhcHBsaWVzIG9yIG5vdC4gIEkgZG9uJ3QgdGhp bmsgT0F1dGggaGVscHMgd2l0aCAjMSBvciAjNCBvciAjNS4NCg0KSSBrbm93IHdlIGhhdmUgZGlz Y3Vzc2VkIGl0IGJlZm9yZSwgYnV0IEkgYWxzbyBkb24ndCB0aGluayB0aGF0IGV2ZXJ5b25lIGJl bGlldmVzIHRoYXQgT0F1dGggbWVhbnMgdGhhdCBPUklHSU4gaXMgbm8gbG9uZ2VyIG5lZWRlZC4g VGhlcmUgaGF2ZSBiZWVuIHN1Z2dlc3Rpb25zIHRoYXQgYSBtdWx0aS10ZW5hbnRlZCBUVVJOIHNl cnZlciB1c2luZyBPQXV0aCBtaWdodCBzdGlsbCB1c2UgT1JJR0lOLg0KDQpBbmQgdXNpbmcgZG9t YWluLXNwZWNpZmljIFVTRVJOQU1FIGF0dHJpYnV0ZXMgc291bmRzIGEgYml0IGxpa2UgdGhlIHBy b2JsZW0gdGhhdCBNYXJ0aW4gbWVudGlvbmVkIG9mIHNpbXBseSB3b3JraW5nIGFyb3VuZCB0aGUg YXBwcm9hY2guDQoNCi0gQWxhbiAtDQoNCk9uIFR1ZSwgQXVnIDI1LCAyMDE1IGF0IDM6NTAgUE0s IEp1c3RpbiBVYmVydGkgPGp1c3RpbkB1YmVydGkubmFtZTxtYWlsdG86anVzdGluQHViZXJ0aS5u YW1lPj4gd3JvdGU6DQpPdmVyYWxsLCBJIHRoaW5rIG1vc3QvYWxsIG9mIHRoZSBnb2FscyB0aGF0 IE9SSUdJTiBpcyB0cnlpbmcgdG8gYWNjb21wbGlzaCB3b3VsZCBiZSBiZXR0ZXIgaGFuZGxlZCBi eSBTVFVOIE9BdXRoIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei8pDQoNCkdlbmVyYWxseSwgaXQncyBub3QgY2xl YXIgdGhhdCBPUklHSU4gaXMgYSBncmVhdCBzb2x1dGlvbiBmb3IgYW55IG9mIHRoZSB1c2UgY2Fz ZXMgbGlzdGVkLg0KMSkgaXMgZWFzaWx5IGFjY29tcGxpc2hlZCB2aWEgb2F1dGgsIHdpdGhvdXQg YW55IG9mIHRoZSByZXN0cmljdGlvbnMgcHJlc2VudCBoZXJlDQoyKSBjYW4gYmUgZGVhbHQgd2l0 aCB1c2luZyBvdGhlciBtZWFucyAoZS5nLiBvYXV0aCwgb3Igc3VwcGx5aW5nIGRvbWFpbiBpbmZv IGluIFVTRVJOQU1FKQ0KMykgaXMgZmFpcmx5IHdlYWsgY29udHJvbCwgYW5kIGNhbiBiZSBkb25l IGJldHRlciB0aHJvdWdoIG9hdXRoLCBvciBkb21haW5lZCBVU0VSTkFNRXMNCg0KT2YgY291cnNl LCBhcyBub3RlZCBieSBvdGhlcnMsIHVzZSBvZiBkb21haW5lZCBVU0VSTkFNRXMgY3JlYXRlcyBh IHF1YXNpLU9SSUdJTiB2YWx1ZSB3aXRoaW4gdGhlIFVTRVJOQU1FIGF0dHJpYnV0ZSwgd2hpY2gg bWFrZXMgT0F1dGggbW9yZSBhdHRyYWN0aXZlLg0KDQpPbiBUdWUsIEF1ZyAyNSwgMjAxNSBhdCAx Mjo1NyBQTSBBbGFuIEpvaG5zdG9uIDxhbGFuLmIuam9obnN0b25AZ21haWwuY29tPG1haWx0bzph bGFuLmIuam9obnN0b25AZ21haWwuY29tPj4gd3JvdGU6DQpBbGwsDQoNCkJhc2VkIG9uIGZlZWRi YWNrIGR1cmluZyBJRVRGLTkzIGluIFByYWd1ZSwgdGhlIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1z dHVuLW9yaWdpbiBhcmUgbG9va2luZyBmb3IgZmVlZGJhY2sgb24gYSBwb3NzaWJsZSBwYXRoIGZv cndhcmQgdG8gc29sdmUgdGhlIHByaXZhY3kvbWV0YSBkYXRhIGlzc3VlcyBhbmQgY2xlYXIgdGhl IERJU0NVU1NlcyAoc2VlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtdHJhbS1zdHVuLW9yaWdpbi9iYWxsb3QvKS4gIFRoZXJlIGFyZSB0d28gYXJlYXMgb2YgZmVl ZGJhY2s6IFVzZSBDYXNlcyBhbmQgUHJvcG9zZWQgU29sdXRpb24uDQoNClVzZSBDYXNlcw0KPT09 PT09PT0NCg0KRmlyc3QsIHdlIHdhbnQgdG8gYmUgc3VyZSB0aGF0IHdlIGFyZSBjb25zaWRlcmlu ZyBhbGwgdGhlIHVzZSBjYXNlcyBmb3IgU1RVTiBPUklHSU4uICBJbiB0aGUgZHJhZnQsIHRocmVl IGFyZSBkZXNjcmliZWQ6DQoNCjEuICBMb2dnaW5nIG9mIHVzYWdlIG9mIFNUVU4vVFVSTiBzZXJ2 ZXIuIEFuIG9wZXJhdG9yIG9mIGEgU1RVTiBvciBUVVJOIHNlcnZlciB3b3VsZCBsZWFybiB0aGUg T3JpZ2luIG9mIHRoZSB3ZWIsIFNJUCwgYW5kIFhNUFAgdXNlcnMuDQoNCjIuICBSRUFMTSBzZWxl Y3Rpb24gZm9yIG11bHRpLXRlbmFudGVkIFRVUk4gc2VydmVyLiBUaGlzIGF2b2lkcyBoYXZpbmcg dG8gcnVuIG11bHRpcGxlIGluc3RhbmNlcyBvbiBkaWZmZXJlbnQgcG9ydHMgb3IgSVAgYWRkcmVz c2VzIHdoZW4gbW9yZSB0aGFuIG9uZSBSRUFMTSBpcyBpbiB1c2UuDQoNCjMuICBTZXJ2aWNlIGRl dGVybWluYXRpb24gYWZ0ZXIgYXV0aGVudGljYXRpb24uICBCYW5kd2lkdGggb3IgUW9TIHBvbGlj eSBjYW4gYmUgYXBwbGllZCwgYWZ0ZXIgYXV0aGVudGljYXRpb24sIGJhc2VkIG9uIHRoZSBPcmln aW4uDQoNCkFsc28sIHRoZSBmb2xsb3dpbmcgdXNlIGNhc2VzIGhhdmUgYWxzbyBiZWVuIGRpc2N1 c3NlZCBidXQgYXJlIG5vdCBpbiB0aGUgZHJhZnQNCg0KNC4gIEF1dGhvcml6YXRpb24gYXQgYm9y ZGVyIFRVUk4gc2VydmVyIGFmdGVyIGF1dGhlbnRpY2F0aW9uLiAgQW4gZW50ZXJwcmlzZSBib3Jk ZXIgVFVSTiBzZXJ2ZXIgY2FuIGFwcGx5IHBvbGljeSBhbmQgYWxsb3cgdXNhZ2UgZm9yIGNlcnRh aW4gT3JpZ2lucyAod2hpdGVsaXN0KSBvciBibG9jayB1c2FnZSBvZiBvdGhlcnMgKGJsYWNrbGlz dCkuDQoNCjUuIGRyYWZ0LWplbm5pbmdzLWJlaGF2ZS1ydGN3ZWItZmlyZXdhbGwtMDEgZGlzY3Vz c2VzIGhvdyBhIGZpcmV3YWxsIHdpdGggU1RVTiBzZXJ2ZXIgY291bGQgdXNlIE9SSUdJTiBpbiBh dXRob3JpemF0aW9uIGRlY2lzaW9ucy4NCg0KQXJlIHRoZXJlIGFueSBvdGhlciB1c2UgY2FzZXMg d2Ugc2hvdWxkIGNvbnNpZGVyPw0KDQpQb3NzaWJsZSBTb2x1dGlvbg0KPT09PT09PT09PT09PQ0K DQpUaGUgc29sdXRpb24gdGhhdCB3YXMgZGlzY3Vzc2VkIGluIFByYWd1ZSB0aGF0IHNlZW1zIHRv IGJlIHRoZSBiZXN0IHRyYWRlb2ZmIGJldHdlZW4gcHJpdmFjeSBhbmQgZnVuY3Rpb25hbGl0eSBp cyB0byBvbmx5IGluY2x1ZGUgT1JJR0lOIGluZm9ybWF0aW9uIGluIGEgU1RVTiBvciBUVVJOIHJl cXVlc3QgaWYgdGhlIGRvbWFpbiBvZiB0aGUgT3JpZ2luIG1hdGNoZXMgdGhlIGRvbWFpbiBvZiB0 aGUgU1RVTiBvciBUVVJOIHNlcnZlciBpbiB0aGUgU1RVTiBvciBUVVJOIFVSSS4gIFNpbmNlIHdl YiBhbmQgU1RVTiBhbmQgVFVSTiBydW4gb24gZGlmZmVyZW50IHBvcnRzLCBhbmQgb2Z0ZW4gd2ls bCByZXNvbHZlIHRvIGRpZmZlcmVudCBJUCBhZGRyZXNzZXMsIGEgZnVsbCBob3N0IGNvbXBhcmlz b24gaXMgbm90IHBvc3NpYmxlLiAgVGhpcyBwcm9wb3NhbCBpcyBub3QgcGVyZmVjdDogaXQgZG9l cyBub3QgcHJvdmlkZSBwZXJmZWN0IHByaXZhY3kgZm9yIHN1YmRvbWFpbnMgKGUuZy4gc3ViMS5l eGFtcGxlLmNvbTxodHRwOi8vc3ViMS5leGFtcGxlLmNvbT4gYW5kIHN1YjIuZXhhbXBsZS5jb208 aHR0cDovL3N1YjIuZXhhbXBsZS5jb20+IHdpbGwgbWF0Y2ggd2l0aCB0aGlzIHJ1bGUsIGV2ZW4g aWYgdGhleSBhcmUgc2VwYXJhdGUgZW50aXRpZXMuICBPZiBjb3Vyc2UsIHN1YmRvbWFpbiB1c2Vy cyBjb3VsZCBhbHdheXMgcmVnaXN0ZXIgYSBuZXcgZG9tYWluIGFuZCBwb2ludCBETlMgcmVjb3Jk cyB0byB0aGVpciBzdWIgaG9zdGVyLikNCg0KSW4gY29tcGFyaW5nIHRoaXMgc29sdXRpb24gYWdh aW5zdCB0aGUgdXNlIGNhc2VzIGFib3ZlOg0KDQoxLiBBbGxvd3MgbG9nZ2luZyBvZiB5b3VyIG93 biB1c2VycyBvbiB5b3VyIG93biBUVVJOIHNlcnZlciAob3Igb25lIHRoYXQgeW91IHNldHVwIERO UyBTUlYgcmVjb3JkcyB0byBwb2ludCB0b3dhcmRzKS4gIE90aGVyIHVzZXJzIG9mIHlvdXIgU1RV TiBvciBUVVJOIHNlcnZlciB3aWxsIG5vdCBiZSBpZGVudGlmaWVkIGJ5IGFuIE9yaWdpbiwgYnV0 IHlvdSB3aWxsIGF0IGxlYXN0IGtub3cgaWYgb3RoZXJzIGFyZSB1c2luZyB5b3VyIHNlcnZlci4N Cg0KMi4gV29ya3MgZm9yIFJFQUxNIHNlbGVjdGlvbiBhcyBsb25nIGFzIHlvdSB1c2UgeW91ciBv d24gVFVSTiBzZXJ2ZXIgKG9yIG9uZSB0aGF0IHlvdSBzZXR1cCBETlMgU1JWIHJlY29yZHMgdG8g cG9pbnQgdG93YXJkcykuDQoNCjMuIEFnYWluLCB3b3JrcyBmb3Igc2VydmljZSBkZXRlcm1pbmF0 aW9uIGFzIGxvbmcgYXMgeW91IHVzZSB5b3VyIG93biBUVVJOIHNlcnZlciAob3Igb25lIHRoYXQg eW91IHNldHVwIEROUyBTUlYgcmVjb3JkcyB0byBwb2ludCB0b3dhcmRzKS4gIEhhdmluZyBzZXJ2 aWNlLXNwZWNpZmljIFRVUk4gY3JlZGVudGlhbHMgaXMgYW5vdGhlciBzb2x1dGlvbiB0aGF0IGRv ZXNuJ3QgcmVseSBvbiBPUklHSU4uDQoNCjQuICYgNS4gRG9lcyBub3Qgc2VlbSBwcm92aWRlIGEg Z29vZCBzb2x1dGlvbiBmb3IgdGhlc2UgdXNlIGNhc2VzLg0KDQpEb2VzIHRoaXMgYW5hbHlzaXMg bWFrZSBzZW5zZT8NCg0KRmVlZGJhY2sgbW9zdCB3ZWxjb21lIHNvIHdlIGNhbiBtb3ZlIGZvcndh cmQgd2l0aCB0aGlzIGRyYWZ0Lg0KDQotIEFsYW4gLQ0KDQoNCg0K --_000_913383AAA69FF945B8F946018B75898A478C77E6xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgQWxhbiw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPk9BdXRoIHNvbHZlcyBhbGwgdGhlIGJlbG93IHVzZSBjYXNlcywgIzQgYW5kICM1IGlzIGRp c2N1c3NlZCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWFiLm9yZy93cC1jb250ZW50L0lBQi11 cGxvYWRzLzIwMTUvMDEvc2VtaTIwMTVfcmVkZHkucGRmIj5odHRwczovL3d3dy5pYWIub3JnL3dw LWNvbnRlbnQvSUFCLXVwbG9hZHMvMjAxNS8wMS9zZW1pMjAxNV9yZWRkeS5wZGY8L2E+LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g dHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ QWxhbiBKb2huc3Rvbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDI3LCAyMDE1 IDI6MzcgQU08YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBVYmVydGk8YnI+DQo8Yj5DYzo8L2I+IHRy YW1AaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdHJhbS1zdHVuLW9yaWdpbkB0b29scy5pZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RyYW1dIFBhdGggRm9yd2FyZCBmb3IgU1RVTiBPUklH SU48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SnVzdGluLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQg aXMgYW4gaW1wb3J0YW50IHF1ZXN0aW9uIGZvciB0aGUgV0cgb24gd2hldGhlciBPUklHSU4gaXMg YSB1c2VmdWwgc29sdXRpb24gdG8gdGhlIHVzZSBjYXNlcy4mbmJzcDsgSG9wZWZ1bGx5IHdlJ2xs IGdldCBtb3JlIGZlZWRiYWNrIG9uIHRoaXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdXIgY29tbWVudHMgc2VlbSBtYWlubHkg ZGlyZWN0ZWQgdG93YXJkcyBhIHNvbHV0aW9uIGZvciB1c2UgY2FzZSAjMiBiZWxvdyAoUkVBTE0g c2VsZWN0aW9uIGZvciBUVVJOIGF1dGhlbnRpY2F0aW9uKSwgcmlnaHQ/Jm5ic3A7IEknbSBub3Qg c3VyZSBpZiB1c2UgY2FzZSAjMyBhcHBsaWVzIG9yIG5vdC4mbmJzcDsgSSBkb24ndCB0aGluayBP QXV0aCBoZWxwcyB3aXRoICMxIG9yICM0IG9yICM1LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGtub3cgd2UgaGF2ZSBkaXNjdXNzZWQgaXQg YmVmb3JlLCBidXQgSSBhbHNvIGRvbid0IHRoaW5rIHRoYXQgZXZlcnlvbmUgYmVsaWV2ZXMgdGhh dCBPQXV0aCBtZWFucyB0aGF0IE9SSUdJTiBpcyBubyBsb25nZXIgbmVlZGVkLiBUaGVyZSBoYXZl IGJlZW4gc3VnZ2VzdGlvbnMgdGhhdCBhIG11bHRpLXRlbmFudGVkIFRVUk4gc2VydmVyIHVzaW5n IE9BdXRoIG1pZ2h0IHN0aWxsIHVzZSBPUklHSU4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB1c2luZyBkb21haW4tc3BlY2lmaWMgVVNF Uk5BTUUgYXR0cmlidXRlcyBzb3VuZHMgYSBiaXQgbGlrZSB0aGUgcHJvYmxlbSB0aGF0IE1hcnRp biBtZW50aW9uZWQgb2Ygc2ltcGx5IHdvcmtpbmcgYXJvdW5kIHRoZSBhcHByb2FjaC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBBbGFuIC08 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXVn IDI1LCAyMDE1IGF0IDM6NTAgUE0sIEp1c3RpbiBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpq dXN0aW5AdWJlcnRpLm5hbWUiIHRhcmdldD0iX2JsYW5rIj5qdXN0aW5AdWJlcnRpLm5hbWU8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P dmVyYWxsLCBJIHRoaW5rIG1vc3QvYWxsIG9mIHRoZSBnb2FscyB0aGF0IE9SSUdJTiBpcyB0cnlp bmcgdG8gYWNjb21wbGlzaCB3b3VsZCBiZSBiZXR0ZXIgaGFuZGxlZCBieSBTVFVOIE9BdXRoICg8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRyYW0t dHVybi10aGlyZC1wYXJ0eS1hdXRoei8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei88 L2E+KTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxNC44NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+R2VuZXJhbGx5LCBpdCdzIG5vdCBjbGVhciB0aGF0IE9SSUdJTiBpcyBhIGdyZWF0IHNvbHV0 aW9uIGZvciBhbnkgb2YgdGhlIHVzZSBjYXNlcyBsaXN0ZWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE0Ljg1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4xKSBpcyBlYXNpbHkgYWNj b21wbGlzaGVkIHZpYSBvYXV0aCwgd2l0aG91dCBhbnkgb2YgdGhlIHJlc3RyaWN0aW9ucyBwcmVz ZW50IGhlcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuODVwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPjIpIGNhbiBiZSBkZWFsdCB3aXRoIHVzaW5nIG90aGVyIG1lYW5zIChlLmcu IG9hdXRoLCBvciBzdXBwbHlpbmcgZG9tYWluIGluZm8gaW4gVVNFUk5BTUUpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE0Ljg1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4zKSBpcyBm YWlybHkgd2VhayBjb250cm9sLCBhbmQgY2FuIGJlIGRvbmUgYmV0dGVyIHRocm91Z2ggb2F1dGgs IG9yIGRvbWFpbmVkIFVTRVJOQU1FczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNC44NXB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0 Ljg1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5PZiBjb3Vyc2UsIGFzIG5vdGVk IGJ5IG90aGVycywgdXNlIG9mIGRvbWFpbmVkIFVTRVJOQU1FcyBjcmVhdGVzIGEgcXVhc2ktT1JJ R0lOIHZhbHVlIHdpdGhpbiB0aGUgVVNFUk5BTUUgYXR0cmlidXRlLCB3aGljaCBtYWtlcyBPQXV0 aCBtb3JlIGF0dHJhY3RpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBdWcgMjUsIDIwMTUgYXQgMTI6NTcgUE0gQWxhbiBKb2hu c3RvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsYW4uYi5qb2huc3RvbkBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5hbGFuLmIuam9obnN0b25AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QWxsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFz ZWQgb24gZmVlZGJhY2sgZHVyaW5nIElFVEYtOTMgaW4gUHJhZ3VlLCB0aGUgYXV0aG9ycyBvZiBk cmFmdC1pZXRmLXN0dW4tb3JpZ2luIGFyZSBsb29raW5nIGZvciBmZWVkYmFjayBvbiBhIHBvc3Np YmxlIHBhdGggZm9yd2FyZCB0byBzb2x2ZSB0aGUgcHJpdmFjeS9tZXRhIGRhdGEgaXNzdWVzIGFu ZCBjbGVhciB0aGUgRElTQ1VTU2VzIChzZWUNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS1zdHVuLW9yaWdpbi9iYWxsb3QvIiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRy YW0tc3R1bi1vcmlnaW4vYmFsbG90LzwvYT4pLiZuYnNwOyBUaGVyZSBhcmUgdHdvIGFyZWFzIG9m IGZlZWRiYWNrOiBVc2UgQ2FzZXMgYW5kIFByb3Bvc2VkIFNvbHV0aW9uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Vc2UgQ2FzZXM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPj09PT09PT09PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpcnN0 LCB3ZSB3YW50IHRvIGJlIHN1cmUgdGhhdCB3ZSBhcmUgY29uc2lkZXJpbmcgYWxsIHRoZSB1c2Ug Y2FzZXMgZm9yIFNUVU4gT1JJR0lOLiZuYnNwOyBJbiB0aGUgZHJhZnQsIHRocmVlIGFyZSBkZXNj cmliZWQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4xLiZuYnNwOyBMb2dnaW5nIG9mIHVzYWdlIG9mIFNUVU4vVFVSTiBzZXJ2ZXIu IEFuIG9wZXJhdG9yIG9mIGEgU1RVTiBvciBUVVJOIHNlcnZlciB3b3VsZCBsZWFybiB0aGUgT3Jp Z2luIG9mIHRoZSB3ZWIsIFNJUCwgYW5kIFhNUFAgdXNlcnMuICZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiZuYnNwOyBSRUFMTSBz ZWxlY3Rpb24gZm9yIG11bHRpLXRlbmFudGVkIFRVUk4gc2VydmVyLiBUaGlzIGF2b2lkcyBoYXZp bmcgdG8gcnVuIG11bHRpcGxlIGluc3RhbmNlcyBvbiBkaWZmZXJlbnQgcG9ydHMgb3IgSVAgYWRk cmVzc2VzIHdoZW4gbW9yZSB0aGFuIG9uZSBSRUFMTSBpcyBpbiB1c2UuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuJm5ic3A7IFNlcnZpY2Ug ZGV0ZXJtaW5hdGlvbiBhZnRlciBhdXRoZW50aWNhdGlvbi4mbmJzcDsgQmFuZHdpZHRoIG9yIFFv UyBwb2xpY3kgY2FuIGJlIGFwcGxpZWQsIGFmdGVyIGF1dGhlbnRpY2F0aW9uLCBiYXNlZCBvbiB0 aGUgT3JpZ2luLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFsc28sIHRoZSBmb2xsb3dpbmcgdXNlIGNhc2VzIGhhdmUgYWxzbyBi ZWVuIGRpc2N1c3NlZCBidXQgYXJlIG5vdCBpbiB0aGUgZHJhZnQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NC4mbmJzcDsgQXV0aG9yaXphdGlv biBhdCBib3JkZXIgVFVSTiBzZXJ2ZXIgYWZ0ZXIgYXV0aGVudGljYXRpb24uJm5ic3A7IEFuIGVu dGVycHJpc2UgYm9yZGVyIFRVUk4gc2VydmVyIGNhbiBhcHBseSBwb2xpY3kgYW5kIGFsbG93IHVz YWdlIGZvciBjZXJ0YWluIE9yaWdpbnMgKHdoaXRlbGlzdCkgb3IgYmxvY2sgdXNhZ2Ugb2Ygb3Ro ZXJzIChibGFja2xpc3QpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj41LiBkcmFmdC1qZW5uaW5ncy1iZWhhdmUtcnRjd2ViLWZpcmV3YWxsLTAx IGRpc2N1c3NlcyBob3cgYSBmaXJld2FsbCB3aXRoIFNUVU4gc2VydmVyIGNvdWxkIHVzZSBPUklH SU4gaW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFyZSB0aGVyZSBhbnkgb3RoZXIgdXNlIGNhc2Vz IHdlIHNob3VsZCBjb25zaWRlcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBvc3NpYmxlIFNvbHV0aW9uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj49PT09PT09PT09PT09PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIHNvbHV0aW9uIHRoYXQgd2FzIGRpc2N1c3NlZCBpbiBQcmFndWUgdGhhdCBzZWVtcyB0byBi ZSB0aGUgYmVzdCB0cmFkZW9mZiBiZXR3ZWVuIHByaXZhY3kgYW5kIGZ1bmN0aW9uYWxpdHkgaXMg dG8gb25seSBpbmNsdWRlIE9SSUdJTiBpbmZvcm1hdGlvbiBpbiBhIFNUVU4gb3IgVFVSTiByZXF1 ZXN0IGlmIHRoZSBkb21haW4gb2YgdGhlIE9yaWdpbiBtYXRjaGVzIHRoZSBkb21haW4gb2YgdGhl IFNUVU4gb3INCiBUVVJOIHNlcnZlciBpbiB0aGUgU1RVTiBvciBUVVJOIFVSSS4mbmJzcDsgU2lu Y2Ugd2ViIGFuZCBTVFVOIGFuZCBUVVJOIHJ1biBvbiBkaWZmZXJlbnQgcG9ydHMsIGFuZCBvZnRl biB3aWxsIHJlc29sdmUgdG8gZGlmZmVyZW50IElQIGFkZHJlc3NlcywgYSBmdWxsIGhvc3QgY29t cGFyaXNvbiBpcyBub3QgcG9zc2libGUuJm5ic3A7IFRoaXMgcHJvcG9zYWwgaXMgbm90IHBlcmZl Y3Q6IGl0IGRvZXMgbm90IHByb3ZpZGUgcGVyZmVjdCBwcml2YWN5IGZvciBzdWJkb21haW5zDQog KGUuZy4gPGEgaHJlZj0iaHR0cDovL3N1YjEuZXhhbXBsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5z dWIxLmV4YW1wbGUuY29tPC9hPiBhbmQNCjxhIGhyZWY9Imh0dHA6Ly9zdWIyLmV4YW1wbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+c3ViMi5leGFtcGxlLmNvbTwvYT4gd2lsbCBtYXRjaCB3aXRoIHRo aXMgcnVsZSwgZXZlbiBpZiB0aGV5IGFyZSBzZXBhcmF0ZSBlbnRpdGllcy4mbmJzcDsgT2YgY291 cnNlLCBzdWJkb21haW4gdXNlcnMgY291bGQgYWx3YXlzIHJlZ2lzdGVyIGEgbmV3IGRvbWFpbiBh bmQgcG9pbnQgRE5TIHJlY29yZHMgdG8gdGhlaXIgc3ViIGhvc3Rlci4pPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGNvbXBhcmluZyB0aGlz IHNvbHV0aW9uIGFnYWluc3QgdGhlIHVzZSBjYXNlcyBhYm92ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gQWxsb3dzIGxvZ2dpbmcgb2Yg eW91ciBvd24gdXNlcnMgb24geW91ciBvd24gVFVSTiBzZXJ2ZXIgKG9yIG9uZSB0aGF0IHlvdSBz ZXR1cCBETlMgU1JWIHJlY29yZHMgdG8gcG9pbnQgdG93YXJkcykuJm5ic3A7IE90aGVyIHVzZXJz IG9mIHlvdXIgU1RVTiBvciBUVVJOIHNlcnZlciB3aWxsIG5vdCBiZSBpZGVudGlmaWVkIGJ5IGFu IE9yaWdpbiwgYnV0IHlvdSB3aWxsIGF0IGxlYXN0IGtub3cgaWYgb3RoZXJzIGFyZQ0KIHVzaW5n IHlvdXIgc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4yLiBXb3JrcyBmb3IgUkVBTE0gc2VsZWN0aW9uIGFzIGxvbmcgYXMgeW91IHVz ZSB5b3VyIG93biBUVVJOIHNlcnZlciAob3Igb25lIHRoYXQgeW91IHNldHVwIEROUyBTUlYgcmVj b3JkcyB0byBwb2ludCB0b3dhcmRzKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gQWdhaW4sIHdvcmtzIGZvciBzZXJ2aWNlIGRldGVybWlu YXRpb24gYXMgbG9uZyBhcyB5b3UgdXNlIHlvdXIgb3duIFRVUk4gc2VydmVyIChvciBvbmUgdGhh dCB5b3Ugc2V0dXAgRE5TIFNSViByZWNvcmRzIHRvIHBvaW50IHRvd2FyZHMpLiZuYnNwOyBIYXZp bmcgc2VydmljZS1zcGVjaWZpYyBUVVJOIGNyZWRlbnRpYWxzIGlzIGFub3RoZXIgc29sdXRpb24g dGhhdCBkb2Vzbid0IHJlbHkgb24gT1JJR0lOLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LiAmYW1wOyA1LiBEb2VzIG5vdCBzZWVtIHByb3Zp ZGUgYSBnb29kIHNvbHV0aW9uIGZvciB0aGVzZSB1c2UgY2FzZXMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgdGhpcyBhbmFseXNpcyBt YWtlIHNlbnNlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5GZWVkYmFjayBtb3N0IHdlbGNvbWUgc28gd2UgY2FuIG1vdmUgZm9yd2FyZCB3aXRo IHRoaXMgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gQWxhbiAtPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A478C77E6xmbrcdx10ciscoc_-- From nobody Wed Aug 26 19:56:11 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787811A86E3; Wed, 26 Aug 2015 19:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjXMq2pS_KTO; Wed, 26 Aug 2015 19:56:07 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 868191A8A8B; Wed, 26 Aug 2015 19:56:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 75926180476; Wed, 26 Aug 2015 19:55:48 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150827025548.75926180476@rfc-editor.org> Date: Wed, 26 Aug 2015 19:55:48 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, tram@ietf.org, rfc-editor@rfc-editor.org Subject: [tram] RFC 7635 on Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 02:56:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7635 Title: Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization Author: T. Reddy, P. Patil, R. Ravindranath, J. Uberti Status: Standards Track Stream: IETF Date: August 2015 Mailbox: tireddy@cisco.com, praspati@cisco.com, rmohanr@cisco.com, justin@uberti.name Pages: 24 Characters: 51753 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tram-turn-third-party-authz-16.txt URL: https://www.rfc-editor.org/info/rfc7635 DOI: http://dx.doi.org/10.17487/RFC7635 This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised. This document is a product of the TURN Revised and Modernized Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Aug 27 00:50:24 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65FF1B33C6 for ; Thu, 27 Aug 2015 00:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rNLN08Yq3Ne for ; Thu, 27 Aug 2015 00:50:21 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A851B3645 for ; Thu, 27 Aug 2015 00:50:21 -0700 (PDT) Received: by igcse8 with SMTP id se8so61025380igc.1 for ; Thu, 27 Aug 2015 00:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=A9dlKbVFA2X1DXcqwT5PGxb1ApXYTXrVoXD8wgLf258=; b=cu7VisFZL36Ms4+apR747IxL0LNdql5UkA64R+QMLLyO2zAuit8JnXIZrZE5k6IDtk ZpzTERWw/vJwpKpkpc8a9atIjOgGbEk+cBM9/G8dMW8N/VppzzBelZK2ld7Em/c9Gy7E jO8iBD7X14FHmt3sguqV0h4+/lDcypL86MkRoCSfIeDCSi1I3FdrZi8A4OEahZMjHZzY ubI3EfIyd81e1a7AGxbkeJL2Inb+kM53I0wQ8yY2xQfz2wrmlkR/vDQp9Z5Vnld7OXvm vPTcg/2anUbwq62TdBTCwF9AYLUEJ82AlpsHSMiGDf2q6vxfKVAXMyN3FNee591XaSqh n4XA== MIME-Version: 1.0 X-Received: by 10.50.60.100 with SMTP id g4mr14477078igr.41.1440661820791; Thu, 27 Aug 2015 00:50:20 -0700 (PDT) Received: by 10.50.171.68 with HTTP; Thu, 27 Aug 2015 00:50:20 -0700 (PDT) In-Reply-To: <20150827025548.75926180476@rfc-editor.org> References: <20150827025548.75926180476@rfc-editor.org> Date: Thu, 27 Aug 2015 00:50:20 -0700 Message-ID: From: Oleg Moskalenko To: "tram@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tram] RFC 7635 on Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 07:50:22 -0000 With this RFC 7635 issued, we now have a conflict with STUN attributes in different documents. RFC 7635 suggest 0x802E attribute for THIRD-PARTY-AUTHORIZATION. The same value is used for MOBILITY-TICKET in TURN-mobility draft: https://tools.ietf.org/html/draft-wing-tram-turn-mobility-03 That has to be fixed. Thanks Oleg On Wed, Aug 26, 2015 at 7:55 PM, wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 7635 > > Title: Session Traversal Utilities for NAT > (STUN) Extension for Third-Party Authorization > Author: T. Reddy, P. Patil, > R. Ravindranath, J. Uberti > Status: Standards Track > Stream: IETF > Date: August 2015 > Mailbox: tireddy@cisco.com, > praspati@cisco.com, > rmohanr@cisco.com, > justin@uberti.name > Pages: 24 > Characters: 51753 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-tram-turn-third-party-authz-16.txt > > URL: https://www.rfc-editor.org/info/rfc7635 > > DOI: http://dx.doi.org/10.17487/RFC7635 > > This document proposes the use of OAuth 2.0 to obtain and validate > ephemeral tokens that can be used for Session Traversal Utilities for > NAT (STUN) authentication. The usage of ephemeral tokens ensures > that access to a STUN server can be controlled even if the tokens are > compromised. > > This document is a product of the TURN Revised and Modernized Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for the > standardization state and status of this protocol. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Aug 27 02:06:00 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CD71B2AEE for ; Thu, 27 Aug 2015 02:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzrXbDPV5CE4 for ; Thu, 27 Aug 2015 02:05:58 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FBC1A8784 for ; Thu, 27 Aug 2015 02:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3650; q=dns/txt; s=iport; t=1440666358; x=1441875958; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CMyJwVoHH/tmtCDwqyrbpQCrNXiRfR2pwLLo+4BOD0E=; b=ZD95jING3rB1hqAS4CMVI0l5czBudjj8YFhrOvTB+vtfpyZ6jPSG+oxk 3XvQeuDj7TaNlHoo/Ggd10o+NU+tz7TbW3zcTArQ1uHywbZdbfxLs62c2 b4UTUAtADfGxCKvmBKGsvy+AzcG9mw9SONuGwPZv1yfiyGC0lhB7gZEoc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CmAgBQ0t5V/4sNJK1dgxtUaQa9bwEJgW4KhXsCgS84FAEBAQEBAQGBCoQjAQEBAwEBAQE3FCAXBAIBCA4DAwEBAQEKAhIFBAcnCgEUCQgCBAESCAwHAgSIBQgNyEQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi2GBPYJ6CQYUMwUGgxKBFAWMbIhRAYUFiTeEMpRkJoJBgT5xAYEGBxcHHIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,421,1437436800"; d="scan'208";a="22075098" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP; 27 Aug 2015 09:05:57 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7R95vjl004595 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2015 09:05:57 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 27 Aug 2015 04:05:56 -0500 Received: from xhc-rcd-x13.cisco.com (173.37.183.87) by xch-rcd-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 27 Aug 2015 04:05:56 -0500 Received: from xmb-rcd-x10.cisco.com ([169.254.15.53]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0248.002; Thu, 27 Aug 2015 04:05:56 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , "tram@ietf.org" Thread-Topic: [tram] RFC 7635 on Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization Thread-Index: AQHQ4HQDWZi7uzWPSki5TrhC6SIUVZ4fzPQA//+62ZA= Date: Thu, 27 Aug 2015 09:05:55 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478C7AF6@xmb-rcd-x10.cisco.com> References: <20150827025548.75926180476@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.60.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] RFC 7635 on Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 09:06:00 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko > Sent: Thursday, August 27, 2015 1:20 PM > To: tram@ietf.org > Subject: Re: [tram] RFC 7635 on Session Traversal Utilities for NAT (STUN= ) > Extension for Third-Party Authorization >=20 > With this RFC 7635 issued, we now have a conflict with STUN attributes in > different documents. >=20 > RFC 7635 suggest 0x802E attribute for THIRD-PARTY-AUTHORIZATION. >=20 > The same value is used for MOBILITY-TICKET in TURN-mobility draft: >=20 > https://tools.ietf.org/html/draft-wing-tram-turn-mobility-03 >=20 > That has to be fixed. Yes, fixed in my local copy (assigned 0x802F). -Tiru >=20 > Thanks > Oleg >=20 >=20 > On Wed, Aug 26, 2015 at 7:55 PM, wrote: > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 7635 > > > > Title: Session Traversal Utilities for NAT > > (STUN) Extension for Third-Party Authorization > > Author: T. Reddy, P. Patil, > > R. Ravindranath, J. Uberti > > Status: Standards Track > > Stream: IETF > > Date: August 2015 > > Mailbox: tireddy@cisco.com, > > praspati@cisco.com, > > rmohanr@cisco.com, > > justin@uberti.name > > Pages: 24 > > Characters: 51753 > > Updates/Obsoletes/SeeAlso: None > > > > I-D Tag: draft-ietf-tram-turn-third-party-authz-16.txt > > > > URL: https://www.rfc-editor.org/info/rfc7635 > > > > DOI: http://dx.doi.org/10.17487/RFC7635 > > > > This document proposes the use of OAuth 2.0 to obtain and validate > > ephemeral tokens that can be used for Session Traversal Utilities for > > NAT (STUN) authentication. The usage of ephemeral tokens ensures that > > access to a STUN server can be controlled even if the tokens are > > compromised. > > > > This document is a product of the TURN Revised and Modernized Working > Group of the IETF. > > > > This is now a Proposed Standard. > > > > STANDARDS TRACK: This document specifies an Internet Standards Track > > protocol for the Internet community, and requests discussion and > > suggestions for improvements. Please refer to the current edition of > > the Official Internet Protocol Standards > > (https://www.rfc-editor.org/standards) for the standardization state > > and status of this protocol. Distribution of this memo is unlimited. > > > > This announcement is sent to the IETF-Announce and rfc-dist lists. > > To subscribe or unsubscribe, see > > https://www.ietf.org/mailman/listinfo/ietf-announce > > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > > > For searching the RFC series, see https://www.rfc-editor.org/search > > For downloading RFCs, see https://www.rfc-editor.org/rfc.html > > > > Requests for special distribution should be addressed to either the > > author of the RFC in question, or to rfc-editor@rfc-editor.org. > > Unless specifically noted otherwise on the RFC itself, all RFCs are > > for unlimited distribution. > > > > > > The RFC Editor Team > > Association Management Solutions, LLC > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Aug 27 03:29:41 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C1B1ACE4C for ; Thu, 27 Aug 2015 03:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYiAKuaOpFy2 for ; Thu, 27 Aug 2015 03:29:37 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A47F1A8991 for ; Thu, 27 Aug 2015 03:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7765; q=dns/txt; s=iport; t=1440671378; x=1441880978; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+rnBEfe+oq6Q6qWvZJss4I7ub1WjlbqvE5VyEJBIHCA=; b=OreAdGsJ++W2wzrZ4h449kQYi1lLrz4S5yudSeQtDDiJDUzgTqO8XUCL 3mrWZ9wvbLKKaM9VEjfe+GcpXchwe8iVWvRih3vpYciKS855KjnS3oR2X a5NK6e2E0bmYX0DPUJYCi2Jn3syhp1CoX6hcQLXvpCNzgW6c9iQwFG8qK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CmAgCP5d5V/4UNJK1dgxtUaQa9cQEJgW4BC4V5AoEwOBQBAQEBAQEBgQqEJAEBBAEBAWsLEAIBCA4xBycLFBECBA4FiC4NA8gWAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSIeIJphEBHBAeDGIEUBZU9AYUFh22BSoQylGQmg39xAYFHgQUBAQE X-IronPort-AV: E=Sophos; i="5.17,422,1437436800"; d="scan'208,217"; a="23987862" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP; 27 Aug 2015 10:29:37 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t7RATaCU007313 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2015 10:29:36 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 27 Aug 2015 05:29:35 -0500 Received: from xhc-rcd-x11.cisco.com (173.37.183.85) by xch-rcd-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 27 Aug 2015 05:29:35 -0500 Received: from xmb-rcd-x06.cisco.com ([169.254.6.133]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0248.002; Thu, 27 Aug 2015 05:29:35 -0500 From: "Pal Martinsen (palmarti)" To: Simon Perreault Thread-Topic: [tram] Transport of ICMP errors in TURN Thread-Index: AQHQ3+oWUq4elx0VKUWmZ9u5ZuMizJ4eib2AgAFwzIA= Date: Thu, 27 Aug 2015 10:29:35 +0000 Message-ID: References: <55DD94FF.7080400@acm.org> <55DDB133.6090608@jive.com> In-Reply-To: <55DDB133.6090608@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.18] Content-Type: multipart/alternative; boundary="_000_A8F8D0A4C8474F3EB5A345DA47CB95D9ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Marc Petit-Huguenin , "tram@ietf.org" Subject: Re: [tram] Transport of ICMP errors in TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 10:29:39 -0000 --_000_A8F8D0A4C8474F3EB5A345DA47CB95D9ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 26 Aug 2015, at 14:29, Simon Perreault > wrote: Le 2015-08-26 06:29, Marc Petit-Huguenin a =E9crit : During the presentation of the Path MTU Discovery Using STUN draft in Pragu= e, there was some discussion on how ICMP can be received by the client when= the PMTUD probes are sent through a TURN server. Which reminded me that I= worked on that problem when I proposed PMTUD over STUN, back in 2008. Tha= t was the case, according to my notes, but in fact the idea of tunneling th= e ICMP packets through the TURN server was proposed the year before, but fo= r a different reason: https://mailarchive.ietf.org/arch/msg/behave/76pAtymXlAtF5SoD0rgoFECf2Fg So my proposal is to add this into turnbis. I can provide text. RFC 5766 section 2.6 explains that ICMP not being relayed was a design decision to make it possible to run a TURN server as an unprivileged user. That conclusion is wrong for two reasons: - With the BSD sockets API, some ICMP errors are translated into recv() error codes. This means that it is always possible to relay at least some subset of ICMP errors. (Not sure for TCP or IPv6, I=92d need to check.) It is possible by creating a new listen socket. See: https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix= -A.2 The code described in that ID works well and we have implemented it in most= of our hard and soft clients. Not sure about any performance issues when doing this on the server side th= ough. The STUNTrace ID is not a TRAM draft anymore. We will ask for it to be AD s= ponsored, just need to have some more discussion in the security section re= garding information leakage. This is particular hard in the intersection ne= twork troubleshooting and end user privacy. If you got any concerns or idea= s please ping me. (Or maybe we can have chair approval to have the discussi= on on this list? If any that is..) - On Linux, which dominates the market of TURN server, one can receive all ICMP errors as an unprivileged user with the IP(V6)_RECVERR socket option. So my conclusion is: yes, please. :) +1 But we need to carefully describe the security pitfalls. Some people might = already be using a TURN server as mean to hide their =93true=94 IP address.= Any changes in the TURN spec that introduces a change in the server behavi= our that affects the privacy aspect might potentially be risk to some users= . .-. P=E5l-Erik Simon _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_A8F8D0A4C8474F3EB5A345DA47CB95D9ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2C8206A5A104FC4F8CF2325B3E5473DA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 26 Aug 2015, at 14:29, Simon Perreault <sperreault@jive.com> wrote:
Le 2015-08-26 06:29, Marc Petit-Huguenin a =E9crit :
During the presentation of the Path MT= U Discovery Using STUN draft in Prague, there was some discussion on how IC= MP can be received by the client when the PMTUD probes are sent through a T= URN server.  Which reminded me that I worked on that problem when I proposed PMTUD over STUN, back in 2008. &n= bsp;That was the case, according to my notes, but in fact the idea of tunne= ling the ICMP packets through the TURN server was proposed the year before,= but for a different reason:

https://mailarchive.ietf.org/arch/msg/behave/76pAtymXl= AtF5SoD0rgoFECf2Fg

So my proposal is to add this into turnbis.  I can provide text.

RFC 5766 section 2.6 <https://tools.ietf.org/html/rfc5766#section-2.6>= ;
explains that ICMP not being relayed was a design decision to make it
possible to run a TURN server as an unprivileged user. That conclusion
is wrong for two reasons:

- With the BSD sockets API, some ICMP errors are translated into recv()
error codes. This means that it is always possible to relay at least
some subset of ICMP errors. (Not sure for TCP or IPv6, I=92d
need to check.)


It is possible by creating a new listen socket.


The code described in that ID works well and we have implemented it in= most of our hard and soft clients.
Not sure about any performance issues when doing this on the server si= de though.

The STUNTrace ID is not a TRAM draft anymore. We will ask for it to be= AD sponsored, just need to have some more discussion in the security secti= on regarding information leakage. This is particular hard in the intersecti= on network troubleshooting and end user privacy. If you got any concerns or ideas please ping me. (Or maybe w= e can have chair approval to have the discussion on this list? If any that = is..)


- On Linux, which dominates the market of TURN server, one = can receive
all ICMP errors as an unprivileged user with the IP(V6)_RECVERR socket
option.

So my conclusion is: yes, please. :)

+1

But we need to carefully describe the security pitfalls. Some people m= ight already be using a TURN server as mean to hide their =93true=94 IP add= ress. Any changes in the TURN spec that introduces a change in the server b= ehaviour that affects the privacy aspect might potentially be risk to some users.  

.-.
P=E5l-Erik

Simon

_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

--_000_A8F8D0A4C8474F3EB5A345DA47CB95D9ciscocom_-- From nobody Thu Aug 27 04:36:06 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B301B3B80 for ; Thu, 27 Aug 2015 04:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhMWcotrhhbt for ; Thu, 27 Aug 2015 04:36:04 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 048931B3B7C for ; Thu, 27 Aug 2015 04:36:04 -0700 (PDT) Received: from [IPv6:2602:61:7515:ec00:4cc7:99e8:efbc:2ca9] (unknown [IPv6:2602:61:7515:ec00:4cc7:99e8:efbc:2ca9]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 63AF920415; Thu, 27 Aug 2015 13:36:02 +0200 (CEST) To: "Pal Martinsen (palmarti)" , Simon Perreault References: <55DD94FF.7080400@acm.org> <55DDB133.6090608@jive.com> From: Marc Petit-Huguenin X-Enigmail-Draft-Status: N1110 Message-ID: <55DEF61F.8070809@acm.org> Date: Thu, 27 Aug 2015 05:35:59 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Transport of ICMP errors in TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 11:36:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/27/2015 04:29 AM, Pal Martinsen (palmarti) wrote: > > On 26 Aug 2015, at 14:29, Simon Perreault > > wrote: > > Le 2015-08-26 06:29, Marc Petit-Huguenin a écrit : During the > presentation of the Path MTU Discovery Using STUN draft in Prague, > there was some discussion on how ICMP can be received by the client > when the PMTUD probes are sent through a TURN server. Which reminded > me that I worked on that problem when I proposed PMTUD over STUN, > back in 2008. That was the case, according to my notes, but in fact > the idea of tunneling the ICMP packets through the TURN server was > proposed the year before, but for a different reason: > > https://mailarchive.ietf.org/arch/msg/behave/76pAtymXlAtF5SoD0rgoFECf2Fg > > So my proposal is to add this into turnbis. I can provide text. > > RFC 5766 section 2.6 > explains that ICMP > not being relayed was a design decision to make it possible to run a > TURN server as an unprivileged user. That conclusion is wrong for two > reasons: > > - With the BSD sockets API, some ICMP errors are translated into > recv() error codes. This means that it is always possible to relay at > least some subset of ICMP errors. (Not sure for TCP or IPv6, I’d need > to check.) > > > It is possible by creating a new listen socket. > > See: > https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2 > > The code described in that ID works well and we have implemented it > in most of our hard and soft clients. Not sure about any performance > issues when doing this on the server side though. > > The STUNTrace ID is not a TRAM draft anymore. We will ask for it to > be AD sponsored, just need to have some more discussion in the > security section regarding information leakage. This is particular > hard in the intersection network troubleshooting and end user > privacy. If you got any concerns or ideas please ping me. (Or maybe > we can have chair approval to have the discussion on this list? If > any that is..) > > > - On Linux, which dominates the market of TURN server, one can > receive all ICMP errors as an unprivileged user with the > IP(V6)_RECVERR socket option. > > So my conclusion is: yes, please. :) > > +1 > > But we need to carefully describe the security pitfalls. Some people > might already be using a TURN server as mean to hide their “true†IP > address. Any changes in the TURN spec that introduces a change in the > server behaviour that affects the privacy aspect might potentially be > risk to some users. > Can you elaborate on this? The proposed extension is to have the server send to the client an indication message that wraps the information for ICMP packets received by the server with only type 3, and perhaps type 12 for ICMPv4 and 1, 2 and 3 for ICMPv6, and that match a permission and contain an UDP header. This indication message will contain a XOR-MAPPED-ADDRESS attribute that contains the same IP address/port that was in the CreatePermission/Send messages sent by the client (or in the CHANNEL-BIND request if channels are used). There is no additional information leaked here. Then the indication message should also contain a new attribute that contains the ICMP error. That also does not reveal anything about the identity of the sender of the packet that triggered this ICMP packet. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV3vYaAAoJECnERZXWan7E+3MQAJiJa8dF1LLFw9edwiGE6jX6 EIDiXOcTQIc6UBB9t+JTJcKPaSFD28khEenOY6fMCG9b3VDKuFWxEKi6d8yWTUp5 Ijhr50sugfmLiS53+jAQEM5RiffJD+3pCcktRJn2Hjy2TNOu1ouPOhXtq/+EQXlX PC3j+qFoIYK1OM0cJiRH3DkGPgjNjgy0mQzOfoaSVC2AbCz8swbgj2rwuywyRy42 cfIuqmUhD5lfp52Gt7pRI8aKlKeN3CKGQOf4LViO0JT+pi9Z50QKI/0hwOmF0Pz1 I79iT1wt6V4JP7lCatdUk0r5zteXJIO/sUJXWvgmUtv/ginI1i9sV3GwcSBrYBP9 O0NhEhRho/RIK+v4HvbHoUWn9Wr606rh44gVgDyoIYv04Yvte0i/wt/6UPSh5XeZ pMhBKcs8vsdhT6Q4fFE45IFtRDCVrhCT/hC6CRDvSCGkw0VW+98eZdsOJGuLTKan e6DWcHFV7tB1/aOr8jDsIyDjNnY4FGN1BfYtF7LqGdE+jNkSkCiDDV7Hd9QeG9vu VUlm5D9z6LBuHGbmuNHOmrZP8zi858XQa9Ta/3UKbotO8XErgEGv+dzRKXp/KpaI pTf2xry4tWNBdpiar3L9uG1qaUQRW47lk22N/XQvQJAGIPAuPxoAWSiGIMNp2jPu 803fI2FWofeSyGmPpUN9 =OkNS -----END PGP SIGNATURE----- From nobody Thu Aug 27 05:07:32 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC8F1ACE02 for ; Thu, 27 Aug 2015 05:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVJpmtvdMhLu for ; Thu, 27 Aug 2015 05:07:28 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30A81A21C4 for ; Thu, 27 Aug 2015 05:07:28 -0700 (PDT) Received: by igbjg10 with SMTP id jg10so65066167igb.0 for ; Thu, 27 Aug 2015 05:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/izUuJbJZHYDQhmDcEEx61+CEFyc59Rk5FI9v4yks5w=; b=tAgjk+Gj963L/KD9sPLjCTJZbwCqSHrYVNoIQxK/e5ZB0VmhyhUUFbez4RmdJv6BK4 GozPx6Yh+0cy6z2LIJ3e9hS/ybwxO2xeLCC6YVM2S/b63GiAKGvm8toWrVSFm3Jq4JsH UjU+PnY7Ko9DV38Mdgm8j27k/H9kPZPUI4i5THYGfj6sgKO23c7Cx8edSb6pdisMNSF4 VPOxbCOv2ZzdEdarojvflbEQYhecTo3hPBJGgnkd509MWVC1jH2BAXUbqQOEKBCSWNJR GNn9WAUayq79vNh9H+7ByP2AUiHps49T/uvCBGKxkBj4nXGHMtRnJNROyiTEn9IscSir +COA== MIME-Version: 1.0 X-Received: by 10.50.142.98 with SMTP id rv2mr8702596igb.41.1440677248099; Thu, 27 Aug 2015 05:07:28 -0700 (PDT) Received: by 10.50.171.68 with HTTP; Thu, 27 Aug 2015 05:07:28 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A478C7AF6@xmb-rcd-x10.cisco.com> References: <20150827025548.75926180476@rfc-editor.org> <913383AAA69FF945B8F946018B75898A478C7AF6@xmb-rcd-x10.cisco.com> Date: Thu, 27 Aug 2015 05:07:28 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] RFC 7635 on Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 12:07:30 -0000 Tiru, thanks for the fix (I suppose that the new Mobility document, version 04 to be published). But in the coturn server, I still have a conflict problem. It is implementing the ORIGIN draft, too; and for the ORIGIN attribute, I currently have 0x802F tentatively assigned. I understand that we do not know when and if IANA will ever assign real numbers for those attributes because I am not sure which one document will ever become an RFC. I know that there are people who are using implementation of those drafts for experimental purposes. Can we avoid that new conflict ? Could you please assign a different number to MIBILITY-TICKET ? I suppose that any number is going to be temporary, anyway, and everything has to go through the normal IANA application etc. In coturn, I have 0x8030 available - can we use that for MIBILITY-TICKET ? Thanks ! Oleg On Thu, Aug 27, 2015 at 2:05 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko >> Sent: Thursday, August 27, 2015 1:20 PM >> To: tram@ietf.org >> Subject: Re: [tram] RFC 7635 on Session Traversal Utilities for NAT (STUN) >> Extension for Third-Party Authorization >> >> With this RFC 7635 issued, we now have a conflict with STUN attributes in >> different documents. >> >> RFC 7635 suggest 0x802E attribute for THIRD-PARTY-AUTHORIZATION. >> >> The same value is used for MOBILITY-TICKET in TURN-mobility draft: >> >> https://tools.ietf.org/html/draft-wing-tram-turn-mobility-03 >> >> That has to be fixed. > > Yes, fixed in my local copy (assigned 0x802F). > > -Tiru > >> >> Thanks >> Oleg >> >> >> On Wed, Aug 26, 2015 at 7:55 PM, wrote: >> > A new Request for Comments is now available in online RFC libraries. >> > >> > >> > RFC 7635 >> > >> > Title: Session Traversal Utilities for NAT >> > (STUN) Extension for Third-Party Authorization >> > Author: T. Reddy, P. Patil, >> > R. Ravindranath, J. Uberti >> > Status: Standards Track >> > Stream: IETF >> > Date: August 2015 >> > Mailbox: tireddy@cisco.com, >> > praspati@cisco.com, >> > rmohanr@cisco.com, >> > justin@uberti.name >> > Pages: 24 >> > Characters: 51753 >> > Updates/Obsoletes/SeeAlso: None >> > >> > I-D Tag: draft-ietf-tram-turn-third-party-authz-16.txt >> > >> > URL: https://www.rfc-editor.org/info/rfc7635 >> > >> > DOI: http://dx.doi.org/10.17487/RFC7635 >> > >> > This document proposes the use of OAuth 2.0 to obtain and validate >> > ephemeral tokens that can be used for Session Traversal Utilities for >> > NAT (STUN) authentication. The usage of ephemeral tokens ensures that >> > access to a STUN server can be controlled even if the tokens are >> > compromised. >> > >> > This document is a product of the TURN Revised and Modernized Working >> Group of the IETF. >> > >> > This is now a Proposed Standard. >> > >> > STANDARDS TRACK: This document specifies an Internet Standards Track >> > protocol for the Internet community, and requests discussion and >> > suggestions for improvements. Please refer to the current edition of >> > the Official Internet Protocol Standards >> > (https://www.rfc-editor.org/standards) for the standardization state >> > and status of this protocol. Distribution of this memo is unlimited. >> > >> > This announcement is sent to the IETF-Announce and rfc-dist lists. >> > To subscribe or unsubscribe, see >> > https://www.ietf.org/mailman/listinfo/ietf-announce >> > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >> > >> > For searching the RFC series, see https://www.rfc-editor.org/search >> > For downloading RFCs, see https://www.rfc-editor.org/rfc.html >> > >> > Requests for special distribution should be addressed to either the >> > author of the RFC in question, or to rfc-editor@rfc-editor.org. >> > Unless specifically noted otherwise on the RFC itself, all RFCs are >> > for unlimited distribution. >> > >> > >> > The RFC Editor Team >> > Association Management Solutions, LLC >> > >> > >> > _______________________________________________ >> > tram mailing list >> > tram@ietf.org >> > https://www.ietf.org/mailman/listinfo/tram >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram From nobody Thu Aug 27 05:13:18 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BBB1B2BBA for ; Thu, 27 Aug 2015 05:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MSila8WS7BE for ; Thu, 27 Aug 2015 05:13:14 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327571A8AC4 for ; Thu, 27 Aug 2015 05:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7250; q=dns/txt; s=iport; t=1440677594; x=1441887194; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wGzjAAsyUaykKZCDHsBuG7wYTr80MoK0JUsWmqbpcNY=; b=PILty3+rO5gHsHXc0oqiXaDM+9LySH04wqzqwZwuM3lSiZe86qqjUUcU WAcWBCfcrErsuqGjGYgY/GhlMPEX1nnmjSuskYCXi7GEC3Lbndt+Qamtu JGLglXWq/ozeLjlJhybeVD4Wp9+BGEQ3di12SRwh6tvdekQE8YSbbGsUH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DEAgC4/d5V/4ENJK1dgxtUaQaDHbpUAQmBbgqFewIcgRc4FAEBAQEBAQGBCoQjAQEBAwEBAQEgERogCwUHBAIBCA4DAwEBAQECAgYCFwQDAgICHwYKARQBCAgCBA4FCAwHAgSHeAMKCA2zGI9TDYUvAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Eiij+BPYESgWgJBhQxBwaCYy+BFAWMbIhRAYUFhgCDN4QyjSmHOyaCQYE+cQGBBAIHFwQDHIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,422,1437436800"; d="scan'208";a="182433496" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP; 27 Aug 2015 12:13:13 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t7RCDDFe023205 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2015 12:13:13 GMT Received: from xch-rcd-018.cisco.com (173.37.102.28) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 27 Aug 2015 07:13:12 -0500 Received: from xhc-aln-x07.cisco.com (173.36.12.81) by xch-rcd-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 27 Aug 2015 07:13:12 -0500 Received: from xmb-rcd-x10.cisco.com ([169.254.15.53]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0248.002; Thu, 27 Aug 2015 07:13:12 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] RFC 7635 on Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization Thread-Index: AQHQ4HQDWZi7uzWPSki5TrhC6SIUVZ4fzPQA//+62ZCAAIz/AP//ragw Date: Thu, 27 Aug 2015 12:13:11 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478C7C3E@xmb-rcd-x10.cisco.com> References: <20150827025548.75926180476@rfc-editor.org> <913383AAA69FF945B8F946018B75898A478C7AF6@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.60.108] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] RFC 7635 on Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 12:13:17 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPbGVnIE1vc2thbGVua28gW21h aWx0bzptb20wNDAyNjdAZ21haWwuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDI3LCAy MDE1IDU6MzcgUE0NCj4gVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4gQ2M6IHRy YW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt0cmFtXSBSRkMgNzYzNSBvbiBTZXNzaW9uIFRy YXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikNCj4gRXh0ZW5zaW9uIGZvciBUaGlyZC1Q YXJ0eSBBdXRob3JpemF0aW9uDQo+IA0KPiBUaXJ1LCB0aGFua3MgZm9yIHRoZSBmaXggKEkgc3Vw cG9zZSB0aGF0IHRoZSBuZXcgTW9iaWxpdHkgZG9jdW1lbnQsIHZlcnNpb24gMDQNCj4gdG8gYmUg cHVibGlzaGVkKS4NCj4gDQo+IEJ1dCBpbiB0aGUgY290dXJuIHNlcnZlciwgSSBzdGlsbCBoYXZl IGEgY29uZmxpY3QgcHJvYmxlbS4gSXQgaXMgaW1wbGVtZW50aW5nIHRoZQ0KPiBPUklHSU4gZHJh ZnQsIHRvbzsgYW5kIGZvciB0aGUgT1JJR0lOIGF0dHJpYnV0ZSwgSSBjdXJyZW50bHkgaGF2ZSAw eDgwMkYNCj4gdGVudGF0aXZlbHkgYXNzaWduZWQuDQo+IA0KPiBJIHVuZGVyc3RhbmQgdGhhdCB3 ZSBkbyBub3Qga25vdyB3aGVuIGFuZCBpZiBJQU5BIHdpbGwgZXZlciBhc3NpZ24gcmVhbA0KPiBu dW1iZXJzIGZvciB0aG9zZSBhdHRyaWJ1dGVzIGJlY2F1c2UgSSBhbSBub3Qgc3VyZSB3aGljaCBv bmUgZG9jdW1lbnQgd2lsbA0KPiBldmVyIGJlY29tZSBhbiBSRkMuDQo+IA0KPiBJIGtub3cgdGhh dCB0aGVyZSBhcmUgcGVvcGxlIHdobyBhcmUgdXNpbmcgaW1wbGVtZW50YXRpb24gb2YgdGhvc2Ug ZHJhZnRzDQo+IGZvciBleHBlcmltZW50YWwgcHVycG9zZXMuIENhbiB3ZSBhdm9pZCB0aGF0IG5l dyBjb25mbGljdCA/DQo+IENvdWxkIHlvdSBwbGVhc2UgYXNzaWduIGEgZGlmZmVyZW50IG51bWJl ciB0byBNSUJJTElUWS1USUNLRVQgPyBJIHN1cHBvc2UNCj4gdGhhdCBhbnkgbnVtYmVyIGlzIGdv aW5nIHRvIGJlIHRlbXBvcmFyeSwgYW55d2F5LCBhbmQgZXZlcnl0aGluZyBoYXMgdG8gZ28NCj4g dGhyb3VnaCB0aGUgbm9ybWFsIElBTkEgYXBwbGljYXRpb24gZXRjLiBJbiBjb3R1cm4sIEkgaGF2 ZSAweDgwMzAgYXZhaWxhYmxlIC0NCj4gY2FuIHdlIHVzZSB0aGF0IGZvciBNSUJJTElUWS1USUNL RVQgPw0KDQpZZXMsIHVwZGF0ZWQgZHJhZnQuDQoNCi1UaXJ1DQoNCj4gDQo+IFRoYW5rcyAhDQo+ IE9sZWcNCj4gDQo+IA0KPiBPbiBUaHUsIEF1ZyAyNywgMjAxNSBhdCAyOjA1IEFNLCBUaXJ1bWFs ZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+IDx0aXJlZGR5QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IHRyYW0gW21haWx0bzp0cmFt LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBPbGVnDQo+ID4+IE1vc2thbGVua28NCj4g Pj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyNywgMjAxNSAxOjIwIFBNDQo+ID4+IFRvOiB0cmFt QGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbdHJhbV0gUkZDIDc2MzUgb24gU2Vzc2lvbiBU cmF2ZXJzYWwgVXRpbGl0aWVzIGZvciBOQVQNCj4gPj4gKFNUVU4pIEV4dGVuc2lvbiBmb3IgVGhp cmQtUGFydHkgQXV0aG9yaXphdGlvbg0KPiA+Pg0KPiA+PiBXaXRoIHRoaXMgUkZDIDc2MzUgaXNz dWVkLCB3ZSBub3cgaGF2ZSBhIGNvbmZsaWN0IHdpdGggU1RVTg0KPiA+PiBhdHRyaWJ1dGVzIGlu IGRpZmZlcmVudCBkb2N1bWVudHMuDQo+ID4+DQo+ID4+IFJGQyA3NjM1IHN1Z2dlc3QgMHg4MDJF IGF0dHJpYnV0ZSBmb3IgVEhJUkQtUEFSVFktQVVUSE9SSVpBVElPTi4NCj4gPj4NCj4gPj4gVGhl IHNhbWUgdmFsdWUgaXMgdXNlZCBmb3IgTU9CSUxJVFktVElDS0VUIGluIFRVUk4tbW9iaWxpdHkg ZHJhZnQ6DQo+ID4+DQo+ID4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aW5n LXRyYW0tdHVybi1tb2JpbGl0eS0wMw0KPiA+Pg0KPiA+PiBUaGF0IGhhcyB0byBiZSBmaXhlZC4N Cj4gPg0KPiA+IFllcywgZml4ZWQgaW4gbXkgbG9jYWwgY29weSAoYXNzaWduZWQgMHg4MDJGKS4N Cj4gPg0KPiA+IC1UaXJ1DQo+ID4NCj4gPj4NCj4gPj4gVGhhbmtzDQo+ID4+IE9sZWcNCj4gPj4N Cj4gPj4NCj4gPj4gT24gV2VkLCBBdWcgMjYsIDIwMTUgYXQgNzo1NSBQTSwgIDxyZmMtZWRpdG9y QHJmYy1lZGl0b3Iub3JnPiB3cm90ZToNCj4gPj4gPiBBIG5ldyBSZXF1ZXN0IGZvciBDb21tZW50 cyBpcyBub3cgYXZhaWxhYmxlIGluIG9ubGluZSBSRkMgbGlicmFyaWVzLg0KPiA+PiA+DQo+ID4+ ID4NCj4gPj4gPiAgICAgICAgIFJGQyA3NjM1DQo+ID4+ID4NCj4gPj4gPiAgICAgICAgIFRpdGxl OiAgICAgIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUDQo+ID4+ID4gICAgICAg ICAgICAgICAgICAgICAoU1RVTikgRXh0ZW5zaW9uIGZvciBUaGlyZC1QYXJ0eSBBdXRob3JpemF0 aW9uDQo+ID4+ID4gICAgICAgICBBdXRob3I6ICAgICBULiBSZWRkeSwgUC4gUGF0aWwsDQo+ID4+ ID4gICAgICAgICAgICAgICAgICAgICBSLiBSYXZpbmRyYW5hdGgsIEouIFViZXJ0aQ0KPiA+PiA+ ICAgICAgICAgU3RhdHVzOiAgICAgU3RhbmRhcmRzIFRyYWNrDQo+ID4+ID4gICAgICAgICBTdHJl YW06ICAgICBJRVRGDQo+ID4+ID4gICAgICAgICBEYXRlOiAgICAgICBBdWd1c3QgMjAxNQ0KPiA+ PiA+ICAgICAgICAgTWFpbGJveDogICAgdGlyZWRkeUBjaXNjby5jb20sDQo+ID4+ID4gICAgICAg ICAgICAgICAgICAgICBwcmFzcGF0aUBjaXNjby5jb20sDQo+ID4+ID4gICAgICAgICAgICAgICAg ICAgICBybW9oYW5yQGNpc2NvLmNvbSwNCj4gPj4gPiAgICAgICAgICAgICAgICAgICAgIGp1c3Rp bkB1YmVydGkubmFtZQ0KPiA+PiA+ICAgICAgICAgUGFnZXM6ICAgICAgMjQNCj4gPj4gPiAgICAg ICAgIENoYXJhY3RlcnM6IDUxNzUzDQo+ID4+ID4gICAgICAgICBVcGRhdGVzL09ic29sZXRlcy9T ZWVBbHNvOiAgIE5vbmUNCj4gPj4gPg0KPiA+PiA+ICAgICAgICAgSS1EIFRhZzogICAgZHJhZnQt aWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMTYudHh0DQo+ID4+ID4NCj4gPj4gPiAg ICAgICAgIFVSTDogICAgICAgIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzYz NQ0KPiA+PiA+DQo+ID4+ID4gICAgICAgICBET0k6ICAgICAgICBodHRwOi8vZHguZG9pLm9yZy8x MC4xNzQ4Ny9SRkM3NjM1DQo+ID4+ID4NCj4gPj4gPiBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIHRo ZSB1c2Ugb2YgT0F1dGggMi4wIHRvIG9idGFpbiBhbmQgdmFsaWRhdGUNCj4gPj4gPiBlcGhlbWVy YWwgdG9rZW5zIHRoYXQgY2FuIGJlIHVzZWQgZm9yIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGll cw0KPiA+PiA+IGZvciBOQVQgKFNUVU4pIGF1dGhlbnRpY2F0aW9uLiAgVGhlIHVzYWdlIG9mIGVw aGVtZXJhbCB0b2tlbnMNCj4gPj4gPiBlbnN1cmVzIHRoYXQgYWNjZXNzIHRvIGEgU1RVTiBzZXJ2 ZXIgY2FuIGJlIGNvbnRyb2xsZWQgZXZlbiBpZiB0aGUNCj4gPj4gPiB0b2tlbnMgYXJlIGNvbXBy b21pc2VkLg0KPiA+PiA+DQo+ID4+ID4gVGhpcyBkb2N1bWVudCBpcyBhIHByb2R1Y3Qgb2YgdGhl IFRVUk4gUmV2aXNlZCBhbmQgTW9kZXJuaXplZA0KPiA+PiA+IFdvcmtpbmcNCj4gPj4gR3JvdXAg b2YgdGhlIElFVEYuDQo+ID4+ID4NCj4gPj4gPiBUaGlzIGlzIG5vdyBhIFByb3Bvc2VkIFN0YW5k YXJkLg0KPiA+PiA+DQo+ID4+ID4gU1RBTkRBUkRTIFRSQUNLOiBUaGlzIGRvY3VtZW50IHNwZWNp ZmllcyBhbiBJbnRlcm5ldCBTdGFuZGFyZHMNCj4gPj4gPiBUcmFjayBwcm90b2NvbCBmb3IgdGhl IEludGVybmV0IGNvbW11bml0eSwgYW5kIHJlcXVlc3RzIGRpc2N1c3Npb24NCj4gPj4gPiBhbmQg c3VnZ2VzdGlvbnMgZm9yIGltcHJvdmVtZW50cy4gIFBsZWFzZSByZWZlciB0byB0aGUgY3VycmVu dA0KPiA+PiA+IGVkaXRpb24gb2YgdGhlIE9mZmljaWFsIEludGVybmV0IFByb3RvY29sIFN0YW5k YXJkcw0KPiA+PiA+IChodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9zdGFuZGFyZHMpIGZvciB0 aGUgc3RhbmRhcmRpemF0aW9uDQo+ID4+ID4gc3RhdGUgYW5kIHN0YXR1cyBvZiB0aGlzIHByb3Rv Y29sLiAgRGlzdHJpYnV0aW9uIG9mIHRoaXMgbWVtbyBpcyB1bmxpbWl0ZWQuDQo+ID4+ID4NCj4g Pj4gPiBUaGlzIGFubm91bmNlbWVudCBpcyBzZW50IHRvIHRoZSBJRVRGLUFubm91bmNlIGFuZCBy ZmMtZGlzdCBsaXN0cy4NCj4gPj4gPiBUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUsIHNlZQ0K PiA+PiA+ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91 bmNlDQo+ID4+ID4gICBodHRwczovL21haWxtYW4ucmZjLWVkaXRvci5vcmcvbWFpbG1hbi9saXN0 aW5mby9yZmMtZGlzdA0KPiA+PiA+DQo+ID4+ID4gRm9yIHNlYXJjaGluZyB0aGUgUkZDIHNlcmll cywgc2VlIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3NlYXJjaA0KPiA+PiA+IEZvciBkb3du bG9hZGluZyBSRkNzLCBzZWUgaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjLmh0bWwNCj4g Pj4gPg0KPiA+PiA+IFJlcXVlc3RzIGZvciBzcGVjaWFsIGRpc3RyaWJ1dGlvbiBzaG91bGQgYmUg YWRkcmVzc2VkIHRvIGVpdGhlciB0aGUNCj4gPj4gPiBhdXRob3Igb2YgdGhlIFJGQyBpbiBxdWVz dGlvbiwgb3IgdG8gcmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZy4NCj4gPj4gPiBVbmxlc3Mgc3Bl Y2lmaWNhbGx5IG5vdGVkIG90aGVyd2lzZSBvbiB0aGUgUkZDIGl0c2VsZiwgYWxsIFJGQ3MgYXJl DQo+ID4+ID4gZm9yIHVubGltaXRlZCBkaXN0cmlidXRpb24uDQo+ID4+ID4NCj4gPj4gPg0KPiA+ PiA+IFRoZSBSRkMgRWRpdG9yIFRlYW0NCj4gPj4gPiBBc3NvY2lhdGlvbiBNYW5hZ2VtZW50IFNv bHV0aW9ucywgTExDDQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4gdHJhbSBtYWlsaW5nIGxpc3QNCj4g Pj4gPiB0cmFtQGlldGYub3JnDQo+ID4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90cmFtDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4+IHRyYW0gbWFpbGluZyBsaXN0DQo+ID4+IHRyYW1AaWV0Zi5v cmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQo= From nobody Thu Aug 27 05:18:54 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47901A1A1B for ; Thu, 27 Aug 2015 05:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uA3jdVPRLZOr for ; Thu, 27 Aug 2015 05:18:51 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22C91A19E5 for ; Thu, 27 Aug 2015 05:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2256; q=dns/txt; s=iport; t=1440677931; x=1441887531; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fpWvmcLs0yNtZp56oxj+31W/TprEw1ZN6vgXrni8kRU=; b=HSzABuk6yhvVqh5+3BggtQ+rUpvqe6U6yMjjFDatH3+kvTO1qSrpqhy2 uTgXmci+ui5HwqeZra/9Prle6xUnBcegxa5EzYpZEBwuwnRePN49DC1Xh YHWMTpSMMHqtXKXqhw0sOEBAIh3t82xFTbMdocv2wH3CihXMYagpiS4FA E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CmAgCa/95V/49dJa1dgxtUaQa9cQEJgW4KhXsCgTM4FAEBAQEBAQGBCoQjAQEBAwEBAQE3NBAHBAIBCBEEAQELFAkHJwsUCQgCBAESCIgeCA0DyCcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi2GCQIFoEQEGGjgGgxKBFAWSJYMYAYUFiTdGkByINCaCDh2BVHEBgQ06gQUBAQE X-IronPort-AV: E=Sophos;i="5.17,422,1437436800"; d="scan'208";a="27425812" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP; 27 Aug 2015 12:18:50 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t7RCIojs025645 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2015 12:18:50 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 27 Aug 2015 07:18:49 -0500 Received: from xhc-aln-x14.cisco.com (173.36.12.88) by xch-rcd-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 27 Aug 2015 07:18:49 -0500 Received: from xmb-rcd-x10.cisco.com ([169.254.15.53]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0248.002; Thu, 27 Aug 2015 07:18:49 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Marc Petit-Huguenin , "tram@ietf.org" Thread-Topic: [tram] Transport of ICMP errors in TURN Thread-Index: AQHQ3+oWiqNpL/187kKBSDQiZTGJUZ4fxFPw Date: Thu, 27 Aug 2015 12:18:49 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478C7C5A@xmb-rcd-x10.cisco.com> References: <55DD94FF.7080400@acm.org> In-Reply-To: <55DD94FF.7080400@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.60.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Transport of ICMP errors in TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 12:18:53 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Marc Petit- > Huguenin > Sent: Wednesday, August 26, 2015 3:59 PM > To: tram@ietf.org > Subject: [tram] Transport of ICMP errors in TURN >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > During the presentation of the Path MTU Discovery Using STUN draft in > Prague, there was some discussion on how ICMP can be received by the > client when the PMTUD probes are sent through a TURN server. Which > reminded me that I worked on that problem when I proposed PMTUD over > STUN, back in 2008. That was the case, according to my notes, but in fac= t the > idea of tunneling the ICMP packets through the TURN server was proposed > the year before, but for a different reason: >=20 > https://mailarchive.ietf.org/arch/msg/behave/76pAtymXlAtF5SoD0rgoFECf2F > g >=20 > So my proposal is to add this into turnbis. =20 The proposal looks good to me. > I can provide text. Thanks, will update the draft. -Tiru >=20 > Thanks. >=20 > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 >=20 > iQIcBAEBCAAGBQJV3ZT+AAoJECnERZXWan7E0JoQAILKCgPBsAbm5YbcIGnQW > tC8 > xfi5j0lFXNtJvtVSKpC9MypTsusP7se2b/TDLzVMk02plduxmtIGw5LAlNhnosK8 > AhL2O3vJ1oZ7Nxyw10OXARbsY04XsWu9dLPxHpA+gs7r/IZFBMtMOJtGXZH3M > GdQ > lKvU30wSpVOTf6Fi5mTQePBPi1rDQd6tK++1jSehl1iqVgsAOTAGOwgN8jZTqGpi > azFJzbAEqjd8q8Zj+PtGkQlK1A2YxRpLRaRVWChzef89iMwQiAktG7SsgYCbsYor > GMdkpQCKZ/NEeDeVKld3OUyFh+MzQ5sUniqbQa3+LRIJ1p2/+QU9nti3kjLuvm > b8 > jYnmOQKNS/jXkdZBvmmLtdZvg2ytYhjYZMEDQR5bVHhHNOQBZcCmnLtotoBO > NaUs > yyMOh/m7+ub0GFrfyF1oRZm9Jy5/4Z45GLGEZla4YmSxkUDPiVkyEPXz3LFdJdz > o > YXDYSzt+ryrG8ZSZIlNUTO0vK0NDwe5n7zApXlL5L6JnLLr3Eg3984SCNnJG6l8e > nTdvL8aBg0ixsny0rmjOzwKRTrXXut/QrIuW5MLiQLWIDxuaFRuQlkoNxnVR2+V > U > UVbf2JoFLXFTskgf6kL4+LwVE/Z1mbf5v4Xj2upWWvG6KnFEVgsswwkxsgnlslAo > AsZutBz1M7gIvw8UbJem > =3D1Ku/ > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Aug 27 05:19:20 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13211A8A65 for ; Thu, 27 Aug 2015 05:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdJaKwXxAy0z for ; Thu, 27 Aug 2015 05:19:17 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66EB1A19E5 for ; Thu, 27 Aug 2015 05:19:16 -0700 (PDT) Received: by iodv127 with SMTP id v127so54365316iod.3 for ; Thu, 27 Aug 2015 05:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qtu6ojONaq6GQ0FfG7eSgqpaEgcvZ96taCXW/Cjz1Tw=; b=wKV7vAy7oiaUw8PJeN37i8KptZ/0irj99+1Z1Wwaddkr6aWa2+hD12tGMALvxVYn+N n/JQE1GOlcERM8okSxD+Kw94Oaeu/aoR42als3gpbXmvCj8wAWPUp3UqZa4j+aWm/Xu5 DczBKlvsiWBR8hyU7j18u4oU0kDx6cpMkACHSQ3Hf3AwbMJ0BwvVwLXmu1J2uToN0Smp TUY/eNnPwCPurEbx9dy8hQkWi3yoK7KxH0OLDVOKWTECvkqxmQlbyX0EK6MW6q5auSgf Uciq7XOZe5ZMj6RNti/C/1x1DtRqbaI9QFG0xWtj7hVi2mJD8mrL1D0+HfiplrlttCxi 5UfQ== MIME-Version: 1.0 X-Received: by 10.107.165.202 with SMTP id o193mr8879381ioe.179.1440677956262; Thu, 27 Aug 2015 05:19:16 -0700 (PDT) Received: by 10.50.171.68 with HTTP; Thu, 27 Aug 2015 05:19:16 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A478C7C3E@xmb-rcd-x10.cisco.com> References: <20150827025548.75926180476@rfc-editor.org> <913383AAA69FF945B8F946018B75898A478C7AF6@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A478C7C3E@xmb-rcd-x10.cisco.com> Date: Thu, 27 Aug 2015 05:19:16 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] RFC 7635 on Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 12:19:19 -0000 cool, thanks ! Oleg On Thu, Aug 27, 2015 at 5:13 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Oleg Moskalenko [mailto:mom040267@gmail.com] >> Sent: Thursday, August 27, 2015 5:37 PM >> To: Tirumaleswar Reddy (tireddy) >> Cc: tram@ietf.org >> Subject: Re: [tram] RFC 7635 on Session Traversal Utilities for NAT (STUN) >> Extension for Third-Party Authorization >> >> Tiru, thanks for the fix (I suppose that the new Mobility document, version 04 >> to be published). >> >> But in the coturn server, I still have a conflict problem. It is implementing the >> ORIGIN draft, too; and for the ORIGIN attribute, I currently have 0x802F >> tentatively assigned. >> >> I understand that we do not know when and if IANA will ever assign real >> numbers for those attributes because I am not sure which one document will >> ever become an RFC. >> >> I know that there are people who are using implementation of those drafts >> for experimental purposes. Can we avoid that new conflict ? >> Could you please assign a different number to MIBILITY-TICKET ? I suppose >> that any number is going to be temporary, anyway, and everything has to go >> through the normal IANA application etc. In coturn, I have 0x8030 available - >> can we use that for MIBILITY-TICKET ? > > Yes, updated draft. > > -Tiru > >> >> Thanks ! >> Oleg >> >> >> On Thu, Aug 27, 2015 at 2:05 AM, Tirumaleswar Reddy (tireddy) >> wrote: >> >> -----Original Message----- >> >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg >> >> Moskalenko >> >> Sent: Thursday, August 27, 2015 1:20 PM >> >> To: tram@ietf.org >> >> Subject: Re: [tram] RFC 7635 on Session Traversal Utilities for NAT >> >> (STUN) Extension for Third-Party Authorization >> >> >> >> With this RFC 7635 issued, we now have a conflict with STUN >> >> attributes in different documents. >> >> >> >> RFC 7635 suggest 0x802E attribute for THIRD-PARTY-AUTHORIZATION. >> >> >> >> The same value is used for MOBILITY-TICKET in TURN-mobility draft: >> >> >> >> https://tools.ietf.org/html/draft-wing-tram-turn-mobility-03 >> >> >> >> That has to be fixed. >> > >> > Yes, fixed in my local copy (assigned 0x802F). >> > >> > -Tiru >> > >> >> >> >> Thanks >> >> Oleg >> >> >> >> >> >> On Wed, Aug 26, 2015 at 7:55 PM, wrote: >> >> > A new Request for Comments is now available in online RFC libraries. >> >> > >> >> > >> >> > RFC 7635 >> >> > >> >> > Title: Session Traversal Utilities for NAT >> >> > (STUN) Extension for Third-Party Authorization >> >> > Author: T. Reddy, P. Patil, >> >> > R. Ravindranath, J. Uberti >> >> > Status: Standards Track >> >> > Stream: IETF >> >> > Date: August 2015 >> >> > Mailbox: tireddy@cisco.com, >> >> > praspati@cisco.com, >> >> > rmohanr@cisco.com, >> >> > justin@uberti.name >> >> > Pages: 24 >> >> > Characters: 51753 >> >> > Updates/Obsoletes/SeeAlso: None >> >> > >> >> > I-D Tag: draft-ietf-tram-turn-third-party-authz-16.txt >> >> > >> >> > URL: https://www.rfc-editor.org/info/rfc7635 >> >> > >> >> > DOI: http://dx.doi.org/10.17487/RFC7635 >> >> > >> >> > This document proposes the use of OAuth 2.0 to obtain and validate >> >> > ephemeral tokens that can be used for Session Traversal Utilities >> >> > for NAT (STUN) authentication. The usage of ephemeral tokens >> >> > ensures that access to a STUN server can be controlled even if the >> >> > tokens are compromised. >> >> > >> >> > This document is a product of the TURN Revised and Modernized >> >> > Working >> >> Group of the IETF. >> >> > >> >> > This is now a Proposed Standard. >> >> > >> >> > STANDARDS TRACK: This document specifies an Internet Standards >> >> > Track protocol for the Internet community, and requests discussion >> >> > and suggestions for improvements. Please refer to the current >> >> > edition of the Official Internet Protocol Standards >> >> > (https://www.rfc-editor.org/standards) for the standardization >> >> > state and status of this protocol. Distribution of this memo is unlimited. >> >> > >> >> > This announcement is sent to the IETF-Announce and rfc-dist lists. >> >> > To subscribe or unsubscribe, see >> >> > https://www.ietf.org/mailman/listinfo/ietf-announce >> >> > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >> >> > >> >> > For searching the RFC series, see https://www.rfc-editor.org/search >> >> > For downloading RFCs, see https://www.rfc-editor.org/rfc.html >> >> > >> >> > Requests for special distribution should be addressed to either the >> >> > author of the RFC in question, or to rfc-editor@rfc-editor.org. >> >> > Unless specifically noted otherwise on the RFC itself, all RFCs are >> >> > for unlimited distribution. >> >> > >> >> > >> >> > The RFC Editor Team >> >> > Association Management Solutions, LLC >> >> > >> >> > >> >> > _______________________________________________ >> >> > tram mailing list >> >> > tram@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/tram >> >> >> >> _______________________________________________ >> >> tram mailing list >> >> tram@ietf.org >> >> https://www.ietf.org/mailman/listinfo/tram From nobody Thu Aug 27 05:21:08 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0298F1B30D3 for ; Thu, 27 Aug 2015 05:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chXDWIgdoflT for ; Thu, 27 Aug 2015 05:21:04 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E303F1A0277 for ; Thu, 27 Aug 2015 05:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11409; q=dns/txt; s=iport; t=1440678063; x=1441887663; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mevqvAP0qEQP9j3L6k6mI0zIP8HsEC7Kbl7ZWZSVRfM=; b=YVkuHxYN8L8tPWNR5+wBQiK9d7Vs4Uuzr6y6LESNBmUG420OZN3yKrEb qCxovgNRTJeTp3QBa42oD7H5mP7Nq99izEU0J7mlnpn1LmYwoRbacu2eB m4Amce1FXo9z3tkgiJ7rbRbDSDDbCfs9s3sKU1WJwF2rcmkwfBJ/18hu4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnAgAPAN9V/4oNJK1dgk5NVGkGvXEBCYFuAQuFeQKBMzgUAQEBAQEBAYEKhCMBAQEEAQEBKkELEAIBCBEEAQELHQcnCxQJCAIEAQ0FCIgmDQPIJwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi2GEQBotBAYBgxiBFAWNJYgYAYUFiTeEMpRkJoN/cQGBR4EFAQEB X-IronPort-AV: E=Sophos; i="5.17,422,1437436800"; d="scan'208,217"; a="22131675" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP; 27 Aug 2015 12:21:00 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t7RCL0hF005815 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2015 12:21:00 GMT Received: from xch-rcd-018.cisco.com (173.37.102.28) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 27 Aug 2015 07:20:59 -0500 Received: from xhc-aln-x03.cisco.com (173.36.12.77) by xch-rcd-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 27 Aug 2015 07:20:59 -0500 Received: from xmb-rcd-x10.cisco.com ([169.254.15.53]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0248.002; Thu, 27 Aug 2015 07:20:59 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Pal Martinsen (palmarti)" , Simon Perreault Thread-Topic: [tram] Transport of ICMP errors in TURN Thread-Index: AQHQ3+oWiqNpL/187kKBSDQiZTGJUZ4eib2AgAFwyYD//8rPoA== Date: Thu, 27 Aug 2015 12:20:59 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478C7C70@xmb-rcd-x10.cisco.com> References: <55DD94FF.7080400@acm.org> <55DDB133.6090608@jive.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.60.108] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A478C7C70xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Marc Petit-Huguenin , "tram@ietf.org" Subject: Re: [tram] Transport of ICMP errors in TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 12:21:07 -0000 --_000_913383AAA69FF945B8F946018B75898A478C7C70xmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't see a privacy problem with the proposal of Marc. -Tiru From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen (palma= rti) Sent: Thursday, August 27, 2015 4:00 PM To: Simon Perreault Cc: Marc Petit-Huguenin; tram@ietf.org Subject: Re: [tram] Transport of ICMP errors in TURN On 26 Aug 2015, at 14:29, Simon Perreault > wrote: Le 2015-08-26 06:29, Marc Petit-Huguenin a =E9crit : During the presentation of the Path MTU Discovery Using STUN draft in Pragu= e, there was some discussion on how ICMP can be received by the client when= the PMTUD probes are sent through a TURN server. Which reminded me that I= worked on that problem when I proposed PMTUD over STUN, back in 2008. Tha= t was the case, according to my notes, but in fact the idea of tunneling th= e ICMP packets through the TURN server was proposed the year before, but fo= r a different reason: https://mailarchive.ietf.org/arch/msg/behave/76pAtymXlAtF5SoD0rgoFECf2Fg So my proposal is to add this into turnbis. I can provide text. RFC 5766 section 2.6 explains that ICMP not being relayed was a design decision to make it possible to run a TURN server as an unprivileged user. That conclusion is wrong for two reasons: - With the BSD sockets API, some ICMP errors are translated into recv() error codes. This means that it is always possible to relay at least some subset of ICMP errors. (Not sure for TCP or IPv6, I'd need to check.) It is possible by creating a new listen socket. See: https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix= -A.2 The code described in that ID works well and we have implemented it in most= of our hard and soft clients. Not sure about any performance issues when doing this on the server side th= ough. The STUNTrace ID is not a TRAM draft anymore. We will ask for it to be AD s= ponsored, just need to have some more discussion in the security section re= garding information leakage. This is particular hard in the intersection ne= twork troubleshooting and end user privacy. If you got any concerns or idea= s please ping me. (Or maybe we can have chair approval to have the discussi= on on this list? If any that is..) - On Linux, which dominates the market of TURN server, one can receive all ICMP errors as an unprivileged user with the IP(V6)_RECVERR socket option. So my conclusion is: yes, please. :) +1 But we need to carefully describe the security pitfalls. Some people might = already be using a TURN server as mean to hide their "true" IP address. Any= changes in the TURN spec that introduces a change in the server behaviour = that affects the privacy aspect might potentially be risk to some users. .-. P=E5l-Erik Simon _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_913383AAA69FF945B8F946018B75898A478C7C70xmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I don’t see a priva= cy problem with the proposal of Marc.

 <= /p>

-Tiru

From: tram [ma= ilto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen (palmarti)
Sent: Thursday, August 27, 2015 4:00 PM
To: Simon Perreault
Cc: Marc Petit-Huguenin; tram@ietf.org
Subject: Re: [tram] Transport of ICMP errors in TURN

 

 

On 26 Aug 2015, at 14:29, Simon Perreault <sperreault@jive.com> wrote:

 

Le 2015-08-26 06:29, Marc Petit-Huguenin a =E9crit :=

During the presentation of the Path MTU Discovery Us= ing STUN draft in Prague, there was some discussion on how ICMP can be rece= ived by the client when the PMTUD probes are sent through a TURN server. &n= bsp;Which reminded me that I worked on that problem when I proposed PMTUD over STUN, back in 2008.  That was= the case, according to my notes, but in fact the idea of tunneling the ICM= P packets through the TURN server was proposed the year before, but for a d= ifferent reason:

https://mailarchive.ietf.org/arch/msg/behave/76pAtymXlAtF5SoD0rgo= FECf2Fg

So my proposal is to add this into turnbis.  I can provide text.<= /o:p>


RFC 5766 section 2.6 <https://tools.ietf.org/html/rfc5766#section-2.6>
explains that ICMP not being relayed was a design decision to make it
possible to run a TURN server as an unprivileged user. That conclusion
is wrong for two reasons:

- With the BSD sockets API, some ICMP errors are translated into recv()
error codes. This means that it is always possible to relay at least
some subset of ICMP errors. (Not sure for TCP or IPv6, I’d=

need to check.)<= /o:p>

 

It is possible by creating a new listen socket.=

 

 

The code described in that ID works well and we have= implemented it in most of our hard and soft clients.

Not sure about any performance issues when doing thi= s on the server side though.

 

The STUNTrace ID is not a TRAM draft anymore. We wil= l ask for it to be AD sponsored, just need to have some more discussion in = the security section regarding information leakage. This is particular hard= in the intersection network troubleshooting and end user privacy. If you got any concerns or ideas please ping me. (Or= maybe we can have chair approval to have the discussion on this list? If a= ny that is..)

 

 

- On Linux, which dom= inates the market of TURN server, one can receive
all ICMP errors as an unprivileged user with the IP(V6)_RECVERR socket
option.

So my conclusion is: yes, please. :)

+1

 

But we need to carefully describe the security pitfa= lls. Some people might already be using a TURN server as mean to hide their= “true” IP address. Any changes in the TURN spec that introduce= s a change in the server behaviour that affects the privacy aspect might potentially be risk to some users.  

 

.-.

P=E5l-Erik



Simon

_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org= /mailman/listinfo/tram

 

--_000_913383AAA69FF945B8F946018B75898A478C7C70xmbrcdx10ciscoc_-- From nobody Thu Aug 27 06:01:56 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7A11B3403 for ; Thu, 27 Aug 2015 06:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPCal7p5NwWd for ; Thu, 27 Aug 2015 06:01:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E878E1B36CC for ; Thu, 27 Aug 2015 06:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7308; q=dns/txt; s=iport; t=1440680464; x=1441890064; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+3/2PSqC1aCwG8/2l9MJrxS+aOLksAR+NGjmXSh8Sfg=; b=HDE5FMKhB76rutNHMhaSqyQAuRpfipV2q7swU9o/crJjEvrOjFhBTLzE LW9xHyPKhkrbhSwGpKRIei/uBUN5O3YipzwOWL8dnt4Lyv+2Gy88e/4zj zL03PN0gl10DYm52TOn+U2TgCmIsUICHFLIYouunz8zdQ0eTCrdhAtXUb k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DDAgBuCd9V/4sNJK1UCYMbVGkGgx26VAEJgW4MhXkCHIEXOBQBAQEBAQEBgQqEIwEBAQMBAQEBIBE6CwULAgEIGAICIwMCAgIlCxQBEAIEDgWIJggNA7MRlREBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSKHVoJpgkCBaAcEBgEGGBgbB4JpL4EUBZU9AYUFh22BSkaDbJRkJoIOARyBVHEBgQUIFyOBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,422,1437436800"; d="scan'208";a="22133251" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP; 27 Aug 2015 13:01:03 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7RD13KK023218 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2015 13:01:03 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 27 Aug 2015 08:01:02 -0500 Received: from xhc-rcd-x01.cisco.com (173.37.183.75) by xch-rcd-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 27 Aug 2015 08:01:02 -0500 Received: from xmb-rcd-x06.cisco.com ([169.254.6.133]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0248.002; Thu, 27 Aug 2015 08:01:02 -0500 From: "Pal Martinsen (palmarti)" To: Marc Petit-Huguenin Thread-Topic: [tram] Transport of ICMP errors in TURN Thread-Index: AQHQ3+oWUq4elx0VKUWmZ9u5ZuMizJ4eib2AgAFwzICAABKLgIAAF8UA Date: Thu, 27 Aug 2015 13:01:02 +0000 Message-ID: <82CC0777-152C-4741-9BCF-DF08CF2CC8DA@cisco.com> References: <55DD94FF.7080400@acm.org> <55DDB133.6090608@jive.com> <55DEF61F.8070809@acm.org> In-Reply-To: <55DEF61F.8070809@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.22] Content-Type: text/plain; charset="utf-8" Content-ID: <48FD65150ADE7B45A896C0AAC58CA592@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Transport of ICMP errors in TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 13:01:56 -0000 DQo+IE9uIDI3IEF1ZyAyMDE1LCBhdCAxMzozNSwgTWFyYyBQZXRpdC1IdWd1ZW5pbiA8cGV0aXRo dWdAYWNtLm9yZz4gd3JvdGU6DQo+IA0KPiAtLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0t LS0tDQo+IEhhc2g6IFNIQTI1Ng0KPiANCj4gT24gMDgvMjcvMjAxNSAwNDoyOSBBTSwgUGFsIE1h cnRpbnNlbiAocGFsbWFydGkpIHdyb3RlOg0KPj4gDQo+PiBPbiAyNiBBdWcgMjAxNSwgYXQgMTQ6 MjksIFNpbW9uIFBlcnJlYXVsdA0KPj4gPHNwZXJyZWF1bHRAaml2ZS5jb208bWFpbHRvOnNwZXJy ZWF1bHRAaml2ZS5jb20+PiB3cm90ZToNCj4+IA0KPj4gTGUgMjAxNS0wOC0yNiAwNjoyOSwgTWFy YyBQZXRpdC1IdWd1ZW5pbiBhIMOpY3JpdCA6IER1cmluZyB0aGUNCj4+IHByZXNlbnRhdGlvbiBv ZiB0aGUgUGF0aCBNVFUgRGlzY292ZXJ5IFVzaW5nIFNUVU4gZHJhZnQgaW4gUHJhZ3VlLA0KPj4g dGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lvbiBvbiBob3cgSUNNUCBjYW4gYmUgcmVjZWl2ZWQgYnkg dGhlIGNsaWVudA0KPj4gd2hlbiB0aGUgUE1UVUQgcHJvYmVzIGFyZSBzZW50IHRocm91Z2ggYSBU VVJOIHNlcnZlci4gIFdoaWNoIHJlbWluZGVkDQo+PiBtZSB0aGF0IEkgd29ya2VkIG9uIHRoYXQg cHJvYmxlbSB3aGVuIEkgcHJvcG9zZWQgUE1UVUQgb3ZlciBTVFVOLA0KPj4gYmFjayBpbiAyMDA4 LiAgVGhhdCB3YXMgdGhlIGNhc2UsIGFjY29yZGluZyB0byBteSBub3RlcywgYnV0IGluIGZhY3QN Cj4+IHRoZSBpZGVhIG9mIHR1bm5lbGluZyB0aGUgSUNNUCBwYWNrZXRzIHRocm91Z2ggdGhlIFRV Uk4gc2VydmVyIHdhcw0KPj4gcHJvcG9zZWQgdGhlIHllYXIgYmVmb3JlLCBidXQgZm9yIGEgZGlm ZmVyZW50IHJlYXNvbjoNCj4+IA0KPj4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo L21zZy9iZWhhdmUvNzZwQXR5bVhsQXRGNVNvRDByZ29GRUNmMkZnDQo+PiANCj4+IFNvIG15IHBy b3Bvc2FsIGlzIHRvIGFkZCB0aGlzIGludG8gdHVybmJpcy4gIEkgY2FuIHByb3ZpZGUgdGV4dC4N Cj4+IA0KPj4gUkZDIDU3NjYgc2VjdGlvbiAyLjYNCj4+IDxodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNTc2NiNzZWN0aW9uLTIuNj4gZXhwbGFpbnMgdGhhdCBJQ01QDQo+PiBub3QgYmVp bmcgcmVsYXllZCB3YXMgYSBkZXNpZ24gZGVjaXNpb24gdG8gbWFrZSBpdCBwb3NzaWJsZSB0byBy dW4gYQ0KPj4gVFVSTiBzZXJ2ZXIgYXMgYW4gdW5wcml2aWxlZ2VkIHVzZXIuIFRoYXQgY29uY2x1 c2lvbiBpcyB3cm9uZyBmb3IgdHdvDQo+PiByZWFzb25zOg0KPj4gDQo+PiAtIFdpdGggdGhlIEJT RCBzb2NrZXRzIEFQSSwgc29tZSBJQ01QIGVycm9ycyBhcmUgdHJhbnNsYXRlZCBpbnRvDQo+PiBy ZWN2KCkgZXJyb3IgY29kZXMuIFRoaXMgbWVhbnMgdGhhdCBpdCBpcyBhbHdheXMgcG9zc2libGUg dG8gcmVsYXkgYXQNCj4+IGxlYXN0IHNvbWUgc3Vic2V0IG9mIElDTVAgZXJyb3JzLiAoTm90IHN1 cmUgZm9yIFRDUCBvciBJUHY2LCBJ4oCZZCBuZWVkDQo+PiB0byBjaGVjay4pDQo+PiANCj4+IA0K Pj4gSXQgaXMgcG9zc2libGUgYnkgY3JlYXRpbmcgYSBuZXcgbGlzdGVuIHNvY2tldC4NCj4+IA0K Pj4gU2VlOg0KPj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hcnRpbnNlbi10 cmFtLXN0dW50cmFjZS0wMSNhcHBlbmRpeC1BLjINCj4+IA0KPj4gVGhlIGNvZGUgZGVzY3JpYmVk IGluIHRoYXQgSUQgd29ya3Mgd2VsbCBhbmQgd2UgaGF2ZSBpbXBsZW1lbnRlZCBpdA0KPj4gaW4g bW9zdCBvZiBvdXIgaGFyZCBhbmQgc29mdCBjbGllbnRzLiBOb3Qgc3VyZSBhYm91dCBhbnkgcGVy Zm9ybWFuY2UNCj4+IGlzc3VlcyB3aGVuIGRvaW5nIHRoaXMgb24gdGhlIHNlcnZlciBzaWRlIHRo b3VnaC4NCj4+IA0KPj4gVGhlIFNUVU5UcmFjZSBJRCBpcyBub3QgYSBUUkFNIGRyYWZ0IGFueW1v cmUuIFdlIHdpbGwgYXNrIGZvciBpdCB0bw0KPj4gYmUgQUQgc3BvbnNvcmVkLCBqdXN0IG5lZWQg dG8gaGF2ZSBzb21lIG1vcmUgZGlzY3Vzc2lvbiBpbiB0aGUNCj4+IHNlY3VyaXR5IHNlY3Rpb24g cmVnYXJkaW5nIGluZm9ybWF0aW9uIGxlYWthZ2UuIFRoaXMgaXMgcGFydGljdWxhcg0KPj4gaGFy ZCBpbiB0aGUgaW50ZXJzZWN0aW9uIG5ldHdvcmsgdHJvdWJsZXNob290aW5nIGFuZCBlbmQgdXNl cg0KPj4gcHJpdmFjeS4gSWYgeW91IGdvdCBhbnkgY29uY2VybnMgb3IgaWRlYXMgcGxlYXNlIHBp bmcgbWUuIChPciBtYXliZQ0KPj4gd2UgY2FuIGhhdmUgY2hhaXIgYXBwcm92YWwgdG8gaGF2ZSB0 aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIGxpc3Q/IElmDQo+PiBhbnkgdGhhdCBpcy4uKQ0KPj4gDQo+ PiANCj4+IC0gT24gTGludXgsIHdoaWNoIGRvbWluYXRlcyB0aGUgbWFya2V0IG9mIFRVUk4gc2Vy dmVyLCBvbmUgY2FuDQo+PiByZWNlaXZlIGFsbCBJQ01QIGVycm9ycyBhcyBhbiB1bnByaXZpbGVn ZWQgdXNlciB3aXRoIHRoZQ0KPj4gSVAoVjYpX1JFQ1ZFUlIgc29ja2V0IG9wdGlvbi4NCj4+IA0K Pj4gU28gbXkgY29uY2x1c2lvbiBpczogeWVzLCBwbGVhc2UuIDopDQo+PiANCj4+ICsxDQo+PiAN Cj4+IEJ1dCB3ZSBuZWVkIHRvIGNhcmVmdWxseSBkZXNjcmliZSB0aGUgc2VjdXJpdHkgcGl0ZmFs bHMuIFNvbWUgcGVvcGxlDQo+PiBtaWdodCBhbHJlYWR5IGJlIHVzaW5nIGEgVFVSTiBzZXJ2ZXIg YXMgbWVhbiB0byBoaWRlIHRoZWlyIOKAnHRydWXigJ0gSVANCj4+IGFkZHJlc3MuIEFueSBjaGFu Z2VzIGluIHRoZSBUVVJOIHNwZWMgdGhhdCBpbnRyb2R1Y2VzIGEgY2hhbmdlIGluIHRoZQ0KPj4g c2VydmVyIGJlaGF2aW91ciB0aGF0IGFmZmVjdHMgdGhlIHByaXZhY3kgYXNwZWN0IG1pZ2h0IHBv dGVudGlhbGx5IGJlDQo+PiByaXNrIHRvIHNvbWUgdXNlcnMuDQo+PiANCj4gDQo+IENhbiB5b3Ug ZWxhYm9yYXRlIG9uIHRoaXM/IFRoZSBwcm9wb3NlZCBleHRlbnNpb24gaXMgdG8gaGF2ZSB0aGUg c2VydmVyIHNlbmQgdG8gdGhlIGNsaWVudCBhbiBpbmRpY2F0aW9uIG1lc3NhZ2UgdGhhdCB3cmFw cyB0aGUgaW5mb3JtYXRpb24gZm9yIElDTVAgcGFja2V0cyByZWNlaXZlZCBieSB0aGUgc2VydmVy IHdpdGggb25seSB0eXBlIDMsIGFuZCBwZXJoYXBzIHR5cGUgMTIgZm9yIElDTVB2NCBhbmQgMSwg MiBhbmQgMyBmb3IgSUNNUHY2LCBhbmQgdGhhdCBtYXRjaCBhIHBlcm1pc3Npb24gYW5kIGNvbnRh aW4gYW4gVURQIGhlYWRlci4NCj4gDQo+IFRoaXMgaW5kaWNhdGlvbiBtZXNzYWdlIHdpbGwgY29u dGFpbiBhIFhPUi1NQVBQRUQtQUREUkVTUyBhdHRyaWJ1dGUgdGhhdCBjb250YWlucyB0aGUgc2Ft ZSBJUCBhZGRyZXNzL3BvcnQgdGhhdCB3YXMgaW4gdGhlIENyZWF0ZVBlcm1pc3Npb24vU2VuZCBt ZXNzYWdlcyBzZW50IGJ5IHRoZSBjbGllbnQgKG9yIGluIHRoZSBDSEFOTkVMLUJJTkQgcmVxdWVz dCBpZiBjaGFubmVscyBhcmUgdXNlZCkuICBUaGVyZSBpcyBubyBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uIGxlYWtlZCBoZXJlLg0KPiANCj4gVGhlbiB0aGUgaW5kaWNhdGlvbiBtZXNzYWdlIHNob3Vs ZCBhbHNvIGNvbnRhaW4gYSBuZXcgYXR0cmlidXRlIHRoYXQgY29udGFpbnMgdGhlIElDTVAgZXJy b3IuICBUaGF0IGFsc28gZG9lcyBub3QgcmV2ZWFsIGFueXRoaW5nIGFib3V0IHRoZSBpZGVudGl0 eSBvZiB0aGUgc2VuZGVyIG9mIHRoZSBwYWNrZXQgdGhhdCB0cmlnZ2VyZWQgdGhpcyBJQ01QIHBh Y2tldC4NCj4gDQoNCklmIHdlIGxpbWl0IHRoaXMgdG8gZGVhbCB3aXRoIGhvc3QgdW5yZWFjaGFi bGUgYW5kIHJlbGF0ZWQgcHJvYmxlbXMgSSBhbSBmaW5lIHdpdGggdGhpcy4gSGF2aW5nIHRoZSBh cmd1bWVudGF0aW9uIHlvdSBqdXN0IGRpZCBpbiB0aGUgc3BlYyBpcyB1c2VmdWwuIA0KDQpNeSBt YWluIGNvbmNlcm4gd2FzIGlmIHdlIHdhbnRlZCB0byB0dXJuIHRoZSBUVVJOIHNlcnZlciBpbnRv IHNvbWUgc29ydCBvZiBJQ01QIGdhdGV3YXkgYW5kIGFsbG93IHRoZSBjbGllbnQgdG8gdHJpZ2dl ciBhbGwgc29ydCBvZiBuZXR3b3JrIHdlaXJkbmVzcyBvbiB0aGUgcHVibGljIHNpZGUuIA0KDQpT b3JyeSBhYm91dCB3ZWFyaW5nIHRoZSBwYXJhbm9pYSBoYXQsIGp1c3Qgd2FudGVkIHRvIG1ha2Ug c3VyZSB0aGlzIHdhcyB1bmRlcnN0b29kIGFuZCBkaXNjdXNzZWQuDQoNCi4tLg0KUMOlbC1Fcmlr DQoNCg0KDQo+IC0gLS0gDQo+IE1hcmMgUGV0aXQtSHVndWVuaW4NCj4gRW1haWw6IG1hcmNAcGV0 aXQtaHVndWVuaW4ub3JnDQo+IEJsb2c6IGh0dHA6Ly9ibG9nLm1hcmMucGV0aXQtaHVndWVuaW4u b3JnDQo+IFByb2ZpbGU6IGh0dHA6Ly93d3cubGlua2VkaW4uY29tL2luL3BldGl0aHVnDQo+IC0t LS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQo+IFZlcnNpb246IEdudVBHIHYyDQo+IA0KPiBp UUljQkFFQkNBQUdCUUpWM3ZZYUFBb0pFQ25FUlpYV2FuN0UrM01RQUppSmE4ZEYxTExGdzllZHdp R0U2alg2DQo+IEVJRGlYT2NUUUljNlVCQjl0K0pUSmNLUGFTRkQyOGtoRWVuT1k2Zk1DRzliM1ZE S3VGV3hFS2k2ZDh5V1RVcDUNCj4gSWpocjUwc3VnZm1MaVM1MytqQVFFTTVSaWZmSkQrM3BDY2t0 UkpuMkhqeTJUTk91MW91UE9oWHRxLytFUVhsWA0KPiBQQzNqK3FGb0lZSzFPTTBjSmlSSDNEa0dQ Z2pOamd5MG1Rek9mb2FTVkMyQWJDejhzd2JnajJyd3V5d3lSeTQyDQo+IGNmSXVxbVVoRDVsZnA1 Mkd0N3BSSThhS2xLZU4zQ0tHUU9mNExWaU8wSlQrcGk5WjUwUUtJLzBod09tRjBQejENCj4gSTc5 aVQxd3Q2VjRKUDdsQ2F0ZFVrMHI1enRlWEpJTy9zVUpYV3ZnbVV0di9naW5JMWk5c1YzR3djU0Jy WUJQOQ0KPiBPME5oRWhSaG8vUklLK3Y0SHZiSG9VV245V3I2MDZyaDQ0Z1ZnRHlvSVl2MDRZdnRl MGkvd3QvNlVQU2g1WGVaDQo+IHBNaEJLY3M4dnNkaFQ2UTRmRkU0NUlGdFJEQ1ZyaENUL2hDNkNS RHZTQ0drdzBWVys5OGVaZHNPSkd1TFRLYW4NCj4gZTZEV2NIRlY3dEIxL2FPcjhqRHNJeURqTm5Z NEZHTjFCZll0RjdMcUdkRStqTmtTa0NpRERWN0hkOVFlRzl2dQ0KPiBWVWxtNUQ5ejZMQnVIR2Jt dU5IT21yWlA4emk4NThYUWE5VGEvM1VLYm90TzhYRXJnRUd2K2R6UktYcC9LcGFJDQo+IHBUZjJ4 cnk0dFdOQmRwaWFyM0w5dUcxcWFVUVJXNDdsazIyTi9YUXZRSkFHSVBBdVB4b0FXU2lHSU1OcDJq UHUNCj4gODAzZkkyRldvZmVTeUdtUHBVTjkNCj4gPU9rTlMNCj4gLS0tLS1FTkQgUEdQIFNJR05B VFVSRS0tLS0tDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiB0cmFtIG1haWxpbmcgbGlzdA0KPiB0cmFtQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQo= From nobody Thu Aug 27 06:41:23 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7BC1B3ACB for ; Thu, 27 Aug 2015 06:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1DJmt0jjcPL for ; Thu, 27 Aug 2015 06:41:20 -0700 (PDT) Received: from smtp64.ord1c.emailsrvr.com (smtp64.ord1c.emailsrvr.com [108.166.43.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD971B3B7F for ; Thu, 27 Aug 2015 06:41:18 -0700 (PDT) Received: from smtp1.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 2CB21380529; Thu, 27 Aug 2015 09:41:18 -0400 (EDT) Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5005B38049A; Thu, 27 Aug 2015 09:41:17 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Thu, 27 Aug 2015 13:41:18 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Cullen Jennings In-Reply-To: Date: Thu, 27 Aug 2015 07:41:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <86104CAD-44A6-4C33-BA62-DF15AEE844B5@iii.ca> References: To: Martin Thomson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Alan Johnston , "tram@ietf.org" Subject: Re: [tram] Path Forward for STUN ORIGIN - refer policy X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 13:41:22 -0000 Martin,=20 The solution you are proposing puts the control of if the information is = shared in the hands of the website. I'm pretty sure man websites will = choose "yep, share the origin". The privacy issue raised was more about = if the protecting the interests of the user of the browser and not so = concerned with what the website wanted.=20 I think what was proposed in the meeting is a good compromise but I = don't think having the JS indicate if the origin is shared or not really = addresses the problem we were trying to solve. It might be a good idea = to do this sort of control surface as well as what Alan is proposing.=20 Cullen=20 > On Aug 25, 2015, at 2:41 PM, Martin Thomson = wrote: >=20 > I'm wondering here whether this might be advised by similar work in = the area. >=20 > ORIGIN is analogous to the HTTP Referer [sic] header field. There, > the damage was done long ago, and we aren't sure that it can be fixed. > After several attempts to reduce the information that we expose by > default, I think that browser vendors are basically resigned to status > quo (at least for now). That's the cautionary aspect of this > discussion that we have to be aware of. >=20 > However, what advises this is the secondary controls browsers are > providing for controlling use of Referer. See referrer policy [1]. > All this is driven by a simple principle: if we see an explicit signal > that a site wants to share Referer, then we include it for them. This > is based on the realization that if we don't do this, they will find > another way to exfiltrate the data. Usernames and passwords being the > obvious channels available for TURN, but I'll observe that there are > no winners if you force people to resort to hacks to get the > information they need or think they need. >=20 > Maybe all we need to do here is recognize that we need to provide > adequate controls. Make it clear that you expect someone else (hello > browser vendors) to apply the policies. If a TURN server is > configured with a special flag (call it "includeOrigin" for argument's > sake), then we might send the ORIGIN attribute. Then, I think that > the concerns raised around privacy can be addressed by having ORIGIN > omitted by default. Privacy-preserving by default is perhaps the most > relevant concern here. >=20 > I realize that this might be less than ideal for you because it means > talking to a whole new set of people over @w3.org, but I think that > option is likely to be less cumbersome than your proposed solution. >=20 > [1] http://w3c.github.io/webappsec/specs/referrer-policy/ >=20 > On 25 August 2015 at 12:57, Alan Johnston = wrote: >> All, >>=20 >> Based on feedback during IETF-93 in Prague, the authors of >> draft-ietf-stun-origin are looking for feedback on a possible path = forward >> to solve the privacy/meta data issues and clear the DISCUSSes (see >> = https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ballot/). >> There are two areas of feedback: Use Cases and Proposed Solution. >>=20 >> Use Cases >> =3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> First, we want to be sure that we are considering all the use cases = for STUN >> ORIGIN. In the draft, three are described: >>=20 >> 1. Logging of usage of STUN/TURN server. An operator of a STUN or = TURN >> server would learn the Origin of the web, SIP, and XMPP users. >>=20 >> 2. REALM selection for multi-tenanted TURN server. This avoids = having to >> run multiple instances on different ports or IP addresses when more = than one >> REALM is in use. >>=20 >> 3. Service determination after authentication. Bandwidth or QoS = policy can >> be applied, after authentication, based on the Origin. >>=20 >> Also, the following use cases have also been discussed but are not in = the >> draft >>=20 >> 4. Authorization at border TURN server after authentication. An = enterprise >> border TURN server can apply policy and allow usage for certain = Origins >> (whitelist) or block usage of others (blacklist). >>=20 >> 5. draft-jennings-behave-rtcweb-firewall-01 discusses how a firewall = with >> STUN server could use ORIGIN in authorization decisions. >>=20 >> Are there any other use cases we should consider? >>=20 >> Possible Solution >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> The solution that was discussed in Prague that seems to be the best = tradeoff >> between privacy and functionality is to only include ORIGIN = information in a >> STUN or TURN request if the domain of the Origin matches the domain = of the >> STUN or TURN server in the STUN or TURN URI. Since web and STUN and = TURN >> run on different ports, and often will resolve to different IP = addresses, a >> full host comparison is not possible. This proposal is not perfect: = it does >> not provide perfect privacy for subdomains (e.g. sub1.example.com and >> sub2.example.com will match with this rule, even if they are separate >> entities. Of course, subdomain users could always register a new = domain and >> point DNS records to their sub hoster.) >>=20 >> In comparing this solution against the use cases above: >>=20 >> 1. Allows logging of your own users on your own TURN server (or one = that you >> setup DNS SRV records to point towards). Other users of your STUN or = TURN >> server will not be identified by an Origin, but you will at least = know if >> others are using your server. >>=20 >> 2. Works for REALM selection as long as you use your own TURN server = (or one >> that you setup DNS SRV records to point towards). >>=20 >> 3. Again, works for service determination as long as you use your own = TURN >> server (or one that you setup DNS SRV records to point towards). = Having >> service-specific TURN credentials is another solution that doesn't = rely on >> ORIGIN. >>=20 >> 4. & 5. Does not seem provide a good solution for these use cases. >>=20 >> Does this analysis make sense? >>=20 >> Feedback most welcome so we can move forward with this draft. >>=20 >> - Alan - >>=20 >>=20 >>=20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >>=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Aug 27 06:44:01 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C0B1A1B6A for ; Thu, 27 Aug 2015 06:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCM4H6J2DWPk for ; Thu, 27 Aug 2015 06:43:58 -0700 (PDT) Received: from smtp80.ord1c.emailsrvr.com (smtp80.ord1c.emailsrvr.com [108.166.43.80]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4871A9008 for ; Thu, 27 Aug 2015 06:43:58 -0700 (PDT) Received: from smtp27.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp27.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 0DEC13801E9; Thu, 27 Aug 2015 09:43:58 -0400 (EDT) Received: by smtp27.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5797E380318; Thu, 27 Aug 2015 09:43:57 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Thu, 27 Aug 2015 13:43:58 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Cullen Jennings In-Reply-To: Date: Thu, 27 Aug 2015 07:43:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <481CA2CB-22F9-4E75-837E-E03C8CB27EF5@iii.ca> References: To: Alan Johnston X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Path Forward for STUN ORIGIN - analysis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 13:44:00 -0000 more or the analysis of cases 4 and 5=20 > On Aug 25, 2015, at 1:57 PM, Alan Johnston = wrote: >=20 >=20 > 4. Authorization at border TURN server after authentication. An = enterprise border TURN server can apply policy and allow usage for = certain Origins (whitelist) or block usage of others (blacklist). >=20 > 5. draft-jennings-behave-rtcweb-firewall-01 discusses how a firewall = with STUN server could use ORIGIN in authorization decisions. >=20 ... >=20 > In comparing this solution against the use cases above: >=20 > 4. & 5. Does not seem provide a good solution for these use cases. >=20 I think the solution here does meet the most important pats of use case = 4 and 5... let me explain.=20 For case 5 ... For applications that care about working in network = environments that require the ORIGIN, they will have to add a DNS entry = to point at the turn server they want to use. Note they don't have to = run their own TURN or STUN server, they just have to have a DNS entry = that points at the one they use then use the DNS name that matches their = website in the javascript. The -02 firewall draft is updated to assume a = solution like this.=20 For case 4 ... I'm not seeing the problem. The DNS name of the TURN = server would have been provided along with credential s by whatever = discover / configuration mechanisms gave it to the browser so it would = match and would be provided.=20 From nobody Thu Aug 27 06:49:43 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6FC1B2E38 for ; Thu, 27 Aug 2015 06:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXtnc5b3YlMO for ; Thu, 27 Aug 2015 06:49:34 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9F31B2CF8 for ; Thu, 27 Aug 2015 06:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4078; q=dns/txt; s=iport; t=1440683371; x=1441892971; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vosxB8TcwCO5Dgz6226oahepk3l7H4sCCJ1ad3zm2Wc=; b=Dd8kX0DvjYLsirVTGoD/JJvbLz7Lq1GLY46vgb7NJkix9t/EvHeMdeyC LctYwAzvLV5hC+MJ8K1epNrZMmTYRFl8j7kqPqwJrv0IUN9ILrelujpwE t4fouq0ltVhfpPknGLpJgtVDhdOTSXhKsSii7cnXZGr1jWIGtlY+wy6d1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CmAgBeFN9V/4sNJK1dgxtUWg8GvXEBCYFuDIV5AoEvOBQBAQEBAQEBgQqEIwEBAQMBAQEBawsFCwIBCBEEAQEBJwcnCxQJCAIEDgWIJggNA8gzAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSIeIJphEAYMweDGIEUBZU9AYUFh22BSoQylGQmg39xAYEEBzyBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,422,1437436800"; d="scan'208";a="182622189" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP; 27 Aug 2015 13:49:30 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7RDnU7S023693 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2015 13:49:30 GMT Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 27 Aug 2015 08:49:29 -0500 Received: from xhc-aln-x09.cisco.com (173.36.12.83) by xch-rcd-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 27 Aug 2015 08:49:29 -0500 Received: from xmb-aln-x02.cisco.com ([169.254.5.3]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0248.002; Thu, 27 Aug 2015 08:49:29 -0500 From: "Cullen Jennings (fluffy)" To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] Transport of ICMP errors in TURN Thread-Index: AQHQ3+oWETbZM/WfLU6J25V188icC54eib2AgAFwyYCAAB8ggIAAGLcA Date: Thu, 27 Aug 2015 13:49:28 +0000 Message-ID: <44C024B4-CAC6-4E3A-A812-793809449E10@cisco.com> References: <55DD94FF.7080400@acm.org> <55DDB133.6090608@jive.com> <913383AAA69FF945B8F946018B75898A478C7C70@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A478C7C70@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.13] Content-Type: text/plain; charset="Windows-1252" Content-ID: <181F75591718234E941274FA5FB8D44F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , Marc Petit-Huguenin Subject: Re: [tram] Transport of ICMP errors in TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 13:49:36 -0000 A key part of TURN design was that it was not usable for running general pu= rpose server that accepted traffic from anyone without first identifying wh= o it is that you want to get the traffic from. So the client has to tell th= e TURN server which external hosts can send it traffic.=20 Receiving ICMP violates this because you would need to accept stuff from so= urces you had not given permission to send you stuff. That allows TURN to b= e used to build generic servers which allows it to circumvent firewall poli= cy. One of the reasons we invented TURN instead of using one of the other t= unnel protocols was to not have this problem.=20 > On Aug 27, 2015, at 6:20 AM, Tirumaleswar Reddy (tireddy) wrote: >=20 > I don=92t see a privacy problem with the proposal of Marc. > =20 > -Tiru > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen (pal= marti) > Sent: Thursday, August 27, 2015 4:00 PM > To: Simon Perreault > Cc: Marc Petit-Huguenin; tram@ietf.org > Subject: Re: [tram] Transport of ICMP errors in TURN > =20 > =20 > On 26 Aug 2015, at 14:29, Simon Perreault wrote: > =20 > Le 2015-08-26 06:29, Marc Petit-Huguenin a =E9crit : >=20 > During the presentation of the Path MTU Discovery Using STUN draft in Pra= gue, there was some discussion on how ICMP can be received by the client wh= en the PMTUD probes are sent through a TURN server. Which reminded me that= I worked on that problem when I proposed PMTUD over STUN, back in 2008. T= hat was the case, according to my notes, but in fact the idea of tunneling = the ICMP packets through the TURN server was proposed the year before, but = for a different reason: >=20 > https://mailarchive.ietf.org/arch/msg/behave/76pAtymXlAtF5SoD0rgoFECf2Fg >=20 > So my proposal is to add this into turnbis. I can provide text. >=20 > RFC 5766 section 2.6 > explains that ICMP not being relayed was a design decision to make it > possible to run a TURN server as an unprivileged user. That conclusion > is wrong for two reasons: >=20 > - With the BSD sockets API, some ICMP errors are translated into recv() > error codes. This means that it is always possible to relay at least > some subset of ICMP errors. (Not sure for TCP or IPv6, I=92d > need to check.) >=20 > =20 > It is possible by creating a new listen socket. > =20 > See: https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#append= ix-A.2 > =20 > The code described in that ID works well and we have implemented it in mo= st of our hard and soft clients. > Not sure about any performance issues when doing this on the server side = though. > =20 > The STUNTrace ID is not a TRAM draft anymore. We will ask for it to be AD= sponsored, just need to have some more discussion in the security section = regarding information leakage. This is particular hard in the intersection = network troubleshooting and end user privacy. If you got any concerns or id= eas please ping me. (Or maybe we can have chair approval to have the discus= sion on this list? If any that is..) > =20 > =20 > - On Linux, which dominates the market of TURN server, one can receive > all ICMP errors as an unprivileged user with the IP(V6)_RECVERR socket > option. >=20 > So my conclusion is: yes, please. :) >=20 > +1 > =20 > But we need to carefully describe the security pitfalls. Some people migh= t already be using a TURN server as mean to hide their =93true=94 IP addres= s. Any changes in the TURN spec that introduces a change in the server beha= viour that affects the privacy aspect might potentially be risk to some use= rs. =20 > =20 > .-. > P=E5l-Erik >=20 >=20 > Simon >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > =20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Aug 27 06:49:45 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DB91B2CF8 for ; Thu, 27 Aug 2015 06:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA9gSsR2Qu8h for ; Thu, 27 Aug 2015 06:49:34 -0700 (PDT) Received: from smtp72.ord1c.emailsrvr.com (smtp72.ord1c.emailsrvr.com [108.166.43.72]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981BA1ACEFE for ; Thu, 27 Aug 2015 06:49:33 -0700 (PDT) Received: from smtp26.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp26.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 1A000380258; Thu, 27 Aug 2015 09:49:33 -0400 (EDT) Received: by smtp26.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9834D3801A5; Thu, 27 Aug 2015 09:49:32 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Thu, 27 Aug 2015 13:49:33 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Cullen Jennings In-Reply-To: Date: Thu, 27 Aug 2015 07:49:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <042FB94E-E3B7-431C-9EC7-D9DF7406756E@iii.ca> References: To: Alan Johnston X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Path Forward for STUN ORIGIN - how to match X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 13:49:37 -0000 I think this is close to the right solution but it is different than = what I thought we talking about in the room. So I'm basically on board = with this approach but think it needs a bit of tweaking ... More inline = ... > On Aug 25, 2015, at 1:57 PM, Alan Johnston = wrote: >=20 >=20 > Possible Solution > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The solution that was discussed in Prague that seems to be the best = tradeoff between privacy and functionality is to only include ORIGIN = information in a STUN or TURN request if the domain of the Origin = matches the domain of the STUN or TURN server in the STUN or TURN URI. = Since web and STUN and TURN run on different ports, and often will = resolve to different IP addresses, a full host comparison is not = possible. This proposal is not perfect: it does not provide perfect = privacy for subdomains (e.g. sub1.example.com and sub2.example.com will = match with this rule, even if they are separate entities. Of course, = subdomain users could always register a new domain and point DNS records = to their sub hoster.) >=20 I think we are having some confusions over what we mean by domain in = this context. So lets say the TURN URL is turn:acme.example.com In the meeting when people said domain, I was thinking acme.example.com = and I think you were thinking example.com. =20 Probably the word we should use is "host" as defined in RFC 7065 to mean = acme.example.com. Let me define "label" as the things between the . in = the host. So the above example is a list of three labels, acme, example, = com with the com being called the "top" end of the list and the acme = being the "last" end of the list.=20 I think there are three match policies people might argue for A) match only the top two labels B) match all the the labels except the last=20 C) match all the labels So in the A case, if the browser was at a web site acme.example.com, the = origin would be sent if the stun/turn server was stun.examle.com but not = if it was stun.org. The problem with this is that if website is = facebook.com.uk and the stun / turn server is anything in com.uk, then = the origin is sent and that is not really what we wanted.=20 So in the B case, if the website is example.com, then we match any stun = server in .com which is probably not what we wanted.=20 In the case of C, imagine a website called example.com that wants to run = it's TURN and STUN and web on different servers. It would configure an = DNS SRV record to point at it STUN server, another for the TURN server = and perhaps a CNAME to point at the the web server. It might even be = outsourcing the TURN server to some other provider that provides TURN = for lots of domains on the same server. The only thing this domain needs = to do to outsource it is provide the DNS entry.=20 I could live with A,B, or C, but I think that C provides the best = privacy, is the easiest to understand, and meets the requirements so I = favor a match rule where we match the whole host found in the TURN or = STUN URI to the host part of the HTTP ORIGIN. I don't care about = matching if the origin is secure or not or ports.=20 From nobody Thu Aug 27 07:23:15 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657721B2BB7 for ; Thu, 27 Aug 2015 07:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpTXkZHr2mvY for ; Thu, 27 Aug 2015 07:23:13 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCA51ACD1D for ; Thu, 27 Aug 2015 07:23:13 -0700 (PDT) Received: by oigk185 with SMTP id k185so6460000oig.2 for ; Thu, 27 Aug 2015 07:23:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=K1+bha6X8HPLMe6QuxwPI72sEdzUXZS4fTMmXoKslPU=; b=HRHd/Yr0bgu0KeuCdH5oDFHG1tyoINi21m61tB/iwIbLRhczLXNWKIyzWyhiHGyY9b ljb8WBVluuBZMc6+Z+3rjJW8wt8B8UgMH6E7MHNjUYOoDBWNRCvi9OM/ek6qh4M9DOmR J1fTeokZRSoowWuciq5qPjSYp7RB7dFYYls6vAwWgYSpVH1ijIx+bf7ANPP8FSBZl6Yw eJcCJjZGQ889sq67lQIhFwcHWNPqiSpltN+BZcMyLohVwkKpvx9DegB5+K4YpW+dMkx9 HNBm9PtnlYQeW4r3Sz08HXLAimcdJTXU28yf8cWv8H84DP7BmFBsfAz8LAsOc10idNWt c2RA== X-Gm-Message-State: ALoCoQns7BUBE92IGwLK0viZU5cE7sgmTjImOs9MOfLvlOFzcKACNmfxiI9dk2bQyGjqkbAtVuLc X-Received: by 10.202.62.215 with SMTP id l206mr2801535oia.8.1440685392652; Thu, 27 Aug 2015 07:23:12 -0700 (PDT) Received: from [192.168.1.44] (modemcable164.157-22-96.mc.videotron.ca. [96.22.157.164]) by smtp.googlemail.com with ESMTPSA id cn5sm1376392obb.26.2015.08.27.07.23.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Aug 2015 07:23:11 -0700 (PDT) To: "Cullen Jennings (fluffy)" , "Tirumaleswar Reddy (tireddy)" References: <55DD94FF.7080400@acm.org> <55DDB133.6090608@jive.com> <913383AAA69FF945B8F946018B75898A478C7C70@xmb-rcd-x10.cisco.com> <44C024B4-CAC6-4E3A-A812-793809449E10@cisco.com> From: Simon Perreault Message-ID: <55DF1D4D.7010000@jive.com> Date: Thu, 27 Aug 2015 10:23:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <44C024B4-CAC6-4E3A-A812-793809449E10@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Marc Petit-Huguenin , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] Transport of ICMP errors in TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 14:23:14 -0000 Le 2015-08-27 09:49, Cullen Jennings (fluffy) a écrit : > > A key part of TURN design was that it was not usable for running > general purpose server that accepted traffic from anyone without > first identifying who it is that you want to get the traffic from. So > the client has to tell the TURN server which external hosts can send > it traffic. > > Receiving ICMP violates this because you would need to accept stuff > from sources you had not given permission to send you stuff. That > allows TURN to be used to build generic servers which allows it to > circumvent firewall policy. One of the reasons we invented TURN > instead of using one of the other tunnel protocols was to not have > this problem. Good point. That is easily solved by having the TURN server enforce permissions on the 5-tuple of the ICMP error's encapsulated original packet. Exactly the same way stateful firewalls do it. Simon From nobody Thu Aug 27 07:33:52 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1811A000A for ; Thu, 27 Aug 2015 07:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owpmoUZSApkj for ; Thu, 27 Aug 2015 07:33:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC031A89A8 for ; Thu, 27 Aug 2015 07:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1334; q=dns/txt; s=iport; t=1440686030; x=1441895630; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NA5jqhS36eU3hfRKx9xTt2uU/Pgp9wgUgl83P0DpA5g=; b=LbONrVY6MhighIOJLaexjIsPVWS6ewoprBWmiWf0obqA7L1bHe7lVm0s 44kw5FMpFi5XxINLlyACd50alrd6crlRKb8vyKKits2Ni/YHRagqgYdAQ 2AXz+2kHShWI0pAFuw3A+8BVarzA33AtqvhNEy4LfEtHp2a/Hn7cfVJL6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BdBQDFHt9V/5JdJa1dgxuBPQbFbgKBLzsRAQEBAQEBAYEKhCMBAQEDAXkFCwIBCA4KLjIlAgQOBYgmCMhKAQEBAQEBAQEBAQEBAQEBAQEBAQEYiHiCaYQyDhgzB4MYgRQBBJU9AYxymmAmg39xgQUHPIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,422,1437436800"; d="scan'208";a="22171339" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP; 27 Aug 2015 14:33:49 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t7REXnD7014023 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2015 14:33:49 GMT Received: from xch-aln-019.cisco.com (173.36.7.29) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 27 Aug 2015 09:33:48 -0500 Received: from xhc-rcd-x12.cisco.com (173.37.183.86) by xch-aln-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 27 Aug 2015 09:33:48 -0500 Received: from xmb-aln-x02.cisco.com ([169.254.5.3]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0248.002; Thu, 27 Aug 2015 09:33:47 -0500 From: "Cullen Jennings (fluffy)" To: Simon Perreault Thread-Topic: [tram] Transport of ICMP errors in TURN Thread-Index: AQHQ3+oWETbZM/WfLU6J25V188icC54eib2AgAFwyYCAAB8ggIAAGLcAgAAJa4CAAAL3gA== Date: Thu, 27 Aug 2015 14:33:47 +0000 Message-ID: <72AD57D8-AF37-4F06-9A3C-848C53B4640D@cisco.com> References: <55DD94FF.7080400@acm.org> <55DDB133.6090608@jive.com> <913383AAA69FF945B8F946018B75898A478C7C70@xmb-rcd-x10.cisco.com> <44C024B4-CAC6-4E3A-A812-793809449E10@cisco.com> <55DF1D4D.7010000@jive.com> In-Reply-To: <55DF1D4D.7010000@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.19] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4AA27CDC86B3534993DD6899602CBED1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Marc Petit-Huguenin , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] Transport of ICMP errors in TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 14:33:52 -0000 > On Aug 27, 2015, at 8:23 AM, Simon Perreault wrote: >=20 > Le 2015-08-27 09:49, Cullen Jennings (fluffy) a =E9crit : >>=20 >> A key part of TURN design was that it was not usable for running >> general purpose server that accepted traffic from anyone without >> first identifying who it is that you want to get the traffic from. So >> the client has to tell the TURN server which external hosts can send >> it traffic. >>=20 >> Receiving ICMP violates this because you would need to accept stuff >> from sources you had not given permission to send you stuff. That >> allows TURN to be used to build generic servers which allows it to >> circumvent firewall policy. One of the reasons we invented TURN >> instead of using one of the other tunnel protocols was to not have >> this problem. >=20 > Good point. >=20 > That is easily solved by having the TURN server enforce permissions on > the 5-tuple of the ICMP error's encapsulated original packet. Exactly > the same way stateful firewalls do it. >=20 > Simon Yep, with that change it would be OK. I find that many networks block ICMP for one reason or another thus one can= not count on it working most of the time so it has really limited value fo= r applications as they end up using a method that works all the time. = From nobody Thu Aug 27 07:39:03 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C861A0302 for ; Thu, 27 Aug 2015 07:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-ao1OkLd79o for ; Thu, 27 Aug 2015 07:39:00 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE101A1AC9 for ; Thu, 27 Aug 2015 07:39:00 -0700 (PDT) Received: from [IPv6:2602:61:7515:ec00:6c4a:517e:21cb:6368] (unknown [IPv6:2602:61:7515:ec00:6c4a:517e:21cb:6368]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id DA91920415; Thu, 27 Aug 2015 16:38:58 +0200 (CEST) To: "Tirumaleswar Reddy (tireddy)" , "tram@ietf.org" References: <55DD94FF.7080400@acm.org> <913383AAA69FF945B8F946018B75898A478C7C5A@xmb-rcd-x10.cisco.com> From: Marc Petit-Huguenin X-Enigmail-Draft-Status: N1110 Message-ID: <55DF2100.1080707@acm.org> Date: Thu, 27 Aug 2015 08:38:56 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.1.0 MIME-Version: 1.0 In-Reply-To: <913383AAA69FF945B8F946018B75898A478C7C5A@xmb-rcd-x10.cisco.com> Content-Type: multipart/mixed; boundary="------------050509040409080504030509" Archived-At: Subject: Re: [tram] Transport of ICMP errors in TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 14:39:03 -0000 This is a multi-part message in MIME format. --------------050509040409080504030509 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/27/2015 06:18 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Marc Petit- >> Huguenin >> Sent: Wednesday, August 26, 2015 3:59 PM >> To: tram@ietf.org >> Subject: [tram] Transport of ICMP errors in TURN >> > During the presentation of the Path MTU Discovery Using STUN draft in > Prague, there was some discussion on how ICMP can be received by the > client when the PMTUD probes are sent through a TURN server. Which > reminded me that I worked on that problem when I proposed PMTUD over > STUN, back in 2008. That was the case, according to my notes, but in fact the > idea of tunneling the ICMP packets through the TURN server was proposed > the year before, but for a different reason: > > https://mailarchive.ietf.org/arch/msg/behave/76pAtymXlAtF5SoD0rgoFECf2F > g > > So my proposal is to add this into turnbis. > >> The proposal looks good to me. > > I can provide text. > >> Thanks, will update the draft. > First patch attached. There is more modifications needed in section 12, but that's a good start to discuss that feature. Thanks. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV3yEAAAoJECnERZXWan7EFcAQAKTfWaaP2QFi3DqwzE/ODN8S cke84KFU3F1Q0EhiQfTK0lTtGJhEJiOTzFffU6ec2zKn16UmTfxtUapmp1WV7ymh ZnfffMBvdiYmpkFa17JBXE0PXwwYCcKBPYe4+woO50tjzRKtaiW7c16IWfgSP2zL pTyOYcFhbP+GeKHmlg1iPGa2Ff9GyCFYLgZ9Dm3gsnQ6RrccTIsypjDTCH7ZkdKb d7wud69DXQNh0AQkWD24pq7eINoMnbNLDZGzcw1CNyjr9Kc/8xG1d9vIDAJLUoZq fE9nxhF4efjMA2MyVBAS+qWSPy2cTKnueO8JjqDt5q31knlHR9wY0+mZJj7hkUHZ I6XhrMP2IrWNpmMefmnKU0Aurs4cXW+9BtDAVFX1HIG4i1/2RIfbsN/JEMD3UEYq AQV1AJ6yj/q0nNEvC/4QqAUZtq9Iu8RBe9j8PWukrP7+ZIE8f3I6bT5zY/CXRlPk mX8f8XH2YtvTUZzavFIo7zLhUnTzTp71zIdRjHQy6xi3AfA/Obe8NRx5ho1jqpQ5 L7REMuoi7nj4cja0QaTthoXXPNkOuaQMFaoLBU9XfAyBKQ5J215D6SiVvnizKygt nxfxBupen7VAz0DIsnKMmDDtlcwtyRglEKLkz2K+M2AdUxJAGqWL7PupSHFIjwDM opnsadWMAms/tgRHWnoh =b97Y -----END PGP SIGNATURE----- --------------050509040409080504030509 Content-Type: text/x-patch; name="0001-Add-support-for-ICMP-packets.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-Add-support-for-ICMP-packets.patch" =46rom 7c6f26be7ca8740ae3bc9f9a87a8e201f0985917 Mon Sep 17 00:00:00 2001 From: Marc Petit-Huguenin Date: Thu, 27 Aug 2015 08:34:43 -0600 Subject: [PATCH] Add support for ICMP packets. Change-Id: Ib55e6fe8e42ea53677281c1f3e2bd75dc80f488e --- turnbis/turnbis.xml | 115 +++++++++++++++++++++++++++++++++++++++++++++-= ------ 1 file changed, 100 insertions(+), 15 deletions(-) diff --git a/turnbis/turnbis.xml b/turnbis/turnbis.xml index af1a504..435c0ca 100644 --- a/turnbis/turnbis.xml +++ b/turnbis/turnbis.xml @@ -548,6 +548,13 @@ client server = A B transport address uniquely identified the allocation, the server= knows which client should receive the data. =20 + Some ICMP packets arriving at the relayed transport address o= n the + TURN server may be converted into SendError indications and sent= to + the client, with the transport address of the peer included in a= n + XOR-PEER-ADDRESS attribute and the ICMP type and subtype in a IC= MP + attribute. SendError indications are also send when using the c= hannel + machanism. + Send and Data indications cannot be authenticated, since the long-term credential mechanism of STUN does not support authenti= cating indications. This is not as big an issue as it might first appea= r, @@ -758,23 +765,25 @@ client server = A B the maximum amount of application data that can be sent without fragmentation. =20 - Unfortunately, because servers implementing this version of T= URN do - not relay ICMP messages, the classic path MTU discovery algorith= m - defined in is not able to disco= ver the - MTU of the transmission path between the client and the peer. (E= ven if - they did relay ICMP messages, the algorithm would not always wor= k - since ICMP messages are often filtered out by combined NAT/firew= all - devices). + Unfortunately, because servers implementing this version of T= URN + are not required to relay ICMP messages, the classic path MTU di= scovery + algorithm defined in is not abl= e to + always discover the MTU of the transmission path between the cli= ent and + the peer. =20 So the client and server need to use a path MTU discovery alg= orithm that does not require ICMP messages. The Packetized Path MTU Dis= covery algorithm defined in is one suc= h - algorithm. - - The details of how to use the algorithm of with TURN are still under investigati= on. - However, as a step towards this goal, this version of TURN suppo= rts a - DONT-FRAGMENT attribute. When the client includes this attribute= in a + algorithm. + is an implementation of RFC4821 that is using STUN to discover t= he + PMTUD, and so may be a suitable approach to be used in conjuncti= on + with a TURN server. + + + is an implementation of RFC4821 that is using STUN to discover t= he + PMTUD, and so may be a suitable approach to be used in conjuncti= on + with a TURN server, together with the DONT-FRAGMENT attribute. = When + the client includes this attribute in a Send indication, this tells the server to set the DF bit in the resulting UDP datagram that it sends to the peer. Since some ser= vers may be unable to set the DF bit, the client should also include = this @@ -1759,7 +1768,7 @@ client server = A B =20 -
= +
TURN supports two mechanisms for sending and receiving data fro= m peers. This section describes the use of the Send and Data mechani= sms, while describes the use of t= he @@ -1875,6 +1884,48 @@ client server = A B with an indication that they were received from the peer whose transport address is given by the XOR-PEER-ADDRESS attribute.
+ +
+ When the server receives an ICMP packet at a currently alloca= ted + relayed transport address, the server verifies that the type + are either 3, 11 or 12 for an ICMPv4 packet or either 1, 2, or 3= for + an ICMPv6 packet. It also verifies that the IP packet in the ICM= P + packet payload contain an UDP header. If one of these condition= s + fails, then the ICMP packet is slently dropped. + + The server looks up the allocation associated with the relaye= d + transport address. The server then checks to see whether the set= of + permissions for the allocation allow the relaying of the ICMP pa= cket + as described in . + + If relaying is permitted then the server forms and sends a + SendError indication. The SendError indication MUST contain both= an + XOR-PEER-ADDRESS and an ICMP attribute. The ICMP attribute is se= t to + the value of type and code fields from the ICMP packet, and the + XOR-PEER-ADDRESS attribute is set to the IP address in the IP he= ader + and to the ports in the UDP header, both found in the ICMP packe= t + payload. The SendError indication is then sent on the 5-tuple + associated with the allocation. +
+ +
+ When the client receives a SendError indication, it checks th= at + the SendError indication contains both an XOR-PEER-ADDRESS and a= n + ICMP attribute, and discards the indication if it does not. The = client + SHOULD also check that the XOR-PEER-ADDRESS attribute value cont= ains + an IP address with which the client believes there is an active + permission, and discard the SendError indication otherwise. + + If the SendError indication passes the above checks, the clie= nt + signals the application of the error condition, along + with an indication that twas received from the peer whose + transport address is given by the XOR-PEER-ADDRESS attribute. + + The application can make sense of the meaning of the type an= d code + values in the ICMP attribute by using the family field in the + XOR-PEER-ADDRESS attributes, +
=20 @@ -2459,6 +2510,7 @@ client server = A B 0x007 : Data (only indication semantics defined) 0x008 : CreatePermission (only request/response semantics defined 0x009 : ChannelBind (only request/response semantics defined) + TBD : SendError (only indication semantics defined) =20 ]]> @@ -2483,7 +2535,8 @@ client server = A B 0x0021: Reserved (was TIMER-VAL) 0x0022: RESERVATION-TOKEN =20 TBD-CA: ADDITIONAL-ADDRESS-FAMILY =20 - TBD-CA: ADDRESS-ERROR-CODE]]> + TBD-CA: ADDRESS-ERROR-CODE + TBD : ICMP]]> =20 @@ -2727,6 +2780,34 @@ client server = A B The ADDRESS-ERROR-CODE attribute MAY only be present in Alloc= ate responses. + +
+ This attribute is used by servers to signal the reason an UDP= packet + was dropped. The following is the format of the ICMP attribute.<= /t> + +
+ +
+ + + This field MUST be set to 0 when s= ent, + and MUST be ignored when received. + + The field contains the value in the IC= MP type. + Its interpretation depends wether the ICMP was received = over IPv4 + or IPv6 + + The field contains the value in the IC= MP code. + Its interpretation depends wether the ICMP was received = over IPv4 + or IPv6 + +
=20
@@ -3612,6 +3693,8 @@ client server = A B DTLS support. =20 More detail on packet translations. + + Add support for receiving ICMP packets.
=20 @@ -3691,6 +3774,8 @@ client server = A B =20 =20 + + --=20 2.5.0 --------------050509040409080504030509-- From nobody Thu Aug 27 07:45:18 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1326C1A894B for ; Thu, 27 Aug 2015 07:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yP5qZwc6sW1l for ; Thu, 27 Aug 2015 07:45:11 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 5F00A1A88C5 for ; Thu, 27 Aug 2015 07:45:11 -0700 (PDT) Received: from [IPv6:2602:61:7515:ec00:6c4a:517e:21cb:6368] (unknown [IPv6:2602:61:7515:ec00:6c4a:517e:21cb:6368]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 1936020415; Thu, 27 Aug 2015 16:45:09 +0200 (CEST) To: "Pal Martinsen (palmarti)" References: <55DD94FF.7080400@acm.org> <55DDB133.6090608@jive.com> <55DEF61F.8070809@acm.org> <82CC0777-152C-4741-9BCF-DF08CF2CC8DA@cisco.com> From: Marc Petit-Huguenin Message-ID: <55DF226E.4020708@acm.org> Date: Thu, 27 Aug 2015 08:45:02 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.1.0 MIME-Version: 1.0 In-Reply-To: <82CC0777-152C-4741-9BCF-DF08CF2CC8DA@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Transport of ICMP errors in TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 14:45:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/27/2015 07:01 AM, Pal Martinsen (palmarti) wrote: > >> On 27 Aug 2015, at 13:35, Marc Petit-Huguenin wrote: >> > On 08/27/2015 04:29 AM, Pal Martinsen (palmarti) wrote: >>>> >>>> On 26 Aug 2015, at 14:29, Simon Perreault >>>> > wrote: >>>> >>>> Le 2015-08-26 06:29, Marc Petit-Huguenin a écrit : During the >>>> presentation of the Path MTU Discovery Using STUN draft in Prague, >>>> there was some discussion on how ICMP can be received by the client >>>> when the PMTUD probes are sent through a TURN server. Which reminded >>>> me that I worked on that problem when I proposed PMTUD over STUN, >>>> back in 2008. That was the case, according to my notes, but in fact >>>> the idea of tunneling the ICMP packets through the TURN server was >>>> proposed the year before, but for a different reason: >>>> >>>> https://mailarchive.ietf.org/arch/msg/behave/76pAtymXlAtF5SoD0rgoFECf2Fg >>>> >>>> So my proposal is to add this into turnbis. I can provide text. >>>> >>>> RFC 5766 section 2.6 >>>> explains that ICMP >>>> not being relayed was a design decision to make it possible to run a >>>> TURN server as an unprivileged user. That conclusion is wrong for two >>>> reasons: >>>> >>>> - With the BSD sockets API, some ICMP errors are translated into >>>> recv() error codes. This means that it is always possible to relay at >>>> least some subset of ICMP errors. (Not sure for TCP or IPv6, I’d need >>>> to check.) >>>> >>>> >>>> It is possible by creating a new listen socket. >>>> >>>> See: >>>> https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2 >>>> >>>> The code described in that ID works well and we have implemented it >>>> in most of our hard and soft clients. Not sure about any performance >>>> issues when doing this on the server side though. >>>> >>>> The STUNTrace ID is not a TRAM draft anymore. We will ask for it to >>>> be AD sponsored, just need to have some more discussion in the >>>> security section regarding information leakage. This is particular >>>> hard in the intersection network troubleshooting and end user >>>> privacy. If you got any concerns or ideas please ping me. (Or maybe >>>> we can have chair approval to have the discussion on this list? If >>>> any that is..) >>>> >>>> >>>> - On Linux, which dominates the market of TURN server, one can >>>> receive all ICMP errors as an unprivileged user with the >>>> IP(V6)_RECVERR socket option. >>>> >>>> So my conclusion is: yes, please. :) >>>> >>>> +1 >>>> >>>> But we need to carefully describe the security pitfalls. Some people >>>> might already be using a TURN server as mean to hide their “true†IP >>>> address. Any changes in the TURN spec that introduces a change in the >>>> server behaviour that affects the privacy aspect might potentially be >>>> risk to some users. >>>> > > Can you elaborate on this? The proposed extension is to have the server send to the client an indication message that wraps the information for ICMP packets received by the server with only type 3, and perhaps type 12 for ICMPv4 and 1, 2 and 3 for ICMPv6, and that match a permission and contain an UDP header. > > This indication message will contain a XOR-MAPPED-ADDRESS attribute that contains the same IP address/port that was in the CreatePermission/Send messages sent by the client (or in the CHANNEL-BIND request if channels are used). There is no additional information leaked here. > > Then the indication message should also contain a new attribute that contains the ICMP error. That also does not reveal anything about the identity of the sender of the packet that triggered this ICMP packet. > > >> If we limit this to deal with host unreachable and related problems I am fine with this. Having the argumentation you just did in the spec is useful. OK, I'll propose text for the security consideration section > >> My main concern was if we wanted to turn the TURN server into some sort of ICMP gateway and allow the client to trigger all sort of network weirdness on the public side. No. Only error ICMP are to be translated. See the patch I just sent. > >> Sorry about wearing the paranoia hat, just wanted to make sure this was understood and discussed. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV3yJtAAoJECnERZXWan7EkecP/3g04DXkXoaYX13uEa670buf MidwaB6M3ZtfSVLUg8Ogga96ceAPbeJqhmTc9IS7yaYZ1aKwwdJxfvNb4kkVaN9T K/8GN+gT9qgtRldTOBkuiah1c6CcduKQqY/0NZVlL5Uv8csQE5rDBA+d1MyKYyEc oIvSHhapnKfHDMJwlRtWMl50HECtAKNrtvbL+jpsi4zErXSYJPTS40GAnBKAyGSn QhWNaqhcqmAkEWvTrhSkkRVOZFS/VUGsHaIpSSm3MrR/HcgH9V2jIgXy9M4RZwmk YHHJJ7+oqAKBm/ftij1ZJiJkHRrO+fA+56p3G4wRBtL90jddCgRFv4kv6YNpXmGK kzAj3jzbvKOwnogAKv+LI3HPyk6fVBQEhF0O3fU8Vy8bJHpB0LaX3ZrsnMZFB5FW HYPk+DgtlZHg4M4X5smxk6vp7MFQaDTBMmHMxqtPAiiVwypze9OHaAPG6B7EX5oY BeF0SXedQmZshCSSGvDgYdrmNl1s2Dte+wBiHlA/iXbKkRR3pBLHGWAf+MpbHbAQ cokI8VdcQZqQ3pPZgrk5FBpMyJHImJT4EM2ozwHo9uiU09ZxbUAm5ebKHrlv/JxH fmCCdwZkaATvXi64bIwkXEvf3ZLZzE6NIr5jSgsXnoO/Nc7ja6lZkvDOq2Y/mVpd pHjog+8vP58T1Wa9oE+9 =CbBc -----END PGP SIGNATURE----- From nobody Thu Aug 27 07:49:55 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262E91A9147 for ; Thu, 27 Aug 2015 07:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLQdM3ue5oDs for ; Thu, 27 Aug 2015 07:49:53 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id DB3691A8BC0 for ; Thu, 27 Aug 2015 07:49:52 -0700 (PDT) Received: from [IPv6:2602:61:7515:ec00:6c4a:517e:21cb:6368] (unknown [IPv6:2602:61:7515:ec00:6c4a:517e:21cb:6368]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id E85A020415; Thu, 27 Aug 2015 16:49:51 +0200 (CEST) To: "Cullen Jennings (fluffy)" , Simon Perreault References: <55DD94FF.7080400@acm.org> <55DDB133.6090608@jive.com> <913383AAA69FF945B8F946018B75898A478C7C70@xmb-rcd-x10.cisco.com> <44C024B4-CAC6-4E3A-A812-793809449E10@cisco.com> <55DF1D4D.7010000@jive.com> <72AD57D8-AF37-4F06-9A3C-848C53B4640D@cisco.com> From: Marc Petit-Huguenin Message-ID: <55DF238E.7030400@acm.org> Date: Thu, 27 Aug 2015 08:49:50 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.1.0 MIME-Version: 1.0 In-Reply-To: <72AD57D8-AF37-4F06-9A3C-848C53B4640D@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] Transport of ICMP errors in TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 14:49:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/27/2015 08:33 AM, Cullen Jennings (fluffy) wrote: > >> On Aug 27, 2015, at 8:23 AM, Simon Perreault wrote: >> >> Le 2015-08-27 09:49, Cullen Jennings (fluffy) a écrit : >>> >>> A key part of TURN design was that it was not usable for running >>> general purpose server that accepted traffic from anyone without >>> first identifying who it is that you want to get the traffic from. So >>> the client has to tell the TURN server which external hosts can send >>> it traffic. >>> >>> Receiving ICMP violates this because you would need to accept stuff >>> from sources you had not given permission to send you stuff. That >>> allows TURN to be used to build generic servers which allows it to >>> circumvent firewall policy. One of the reasons we invented TURN >>> instead of using one of the other tunnel protocols was to not have >>> this problem. >> >> Good point. >> >> That is easily solved by having the TURN server enforce permissions on >> the 5-tuple of the ICMP error's encapsulated original packet. Exactly >> the same way stateful firewalls do it. >> >> Simon > > Yep, with that change it would be OK. I believe that the text in the patch I just sent does that. > > I find that many networks block ICMP for one reason or another thus one can not count on it working most of the time so it has really limited value for applications as they end up using a method that works all the time. Yes, and that's OK - both ICE and PMTUD are designed to work without receiving ICMP, but work better if they do. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV3yONAAoJECnERZXWan7E/MEP/iMhsPf2+UOtWxJbanHsqvs8 wstZUctFVtEyx2/dUnSP/zXfzGpDhnnGXZXdxqisqOrf+42/itP0CbCufvIzu9ZD DuRdy6TEY7MTzYHTI3cGBByL6J6RbkZF8ytymND0h2EP2gk284PZkM6O3hKoZVYF ZUCM3BB3vWOphrZVescHn2ulYkjZFfUgyEpnPShKi5xaYYlu+e56wVouZn8653n3 wUZA5e5QEZgV5vgzFpbOLt6ZW0EorWFqgoGOj2Qb0h925PwadNFqLnnOQF7Pf+yT stect5QQtiNI1NdQSy0vp/IzEUn9EWTi2NXfTYqD9sA0GCGDQCiabVUjTx0DXgU4 I+WXqXFUesm9zi6SS+SB4f67zhUH37zMhwkngbyd6NTfaoHUVLVdaXNQU8MzZDHs sQPStzn24GLSsUB5W/gsrSwq/c3s/60vFcZ/2mT8jDRErHpeTmz/ose8OYFfUGTL QIFS28m2W2VrkPOegw04vIiGAroeo+MgFkLok99M+IHzJdM2O7BL4vAS7Qp8Lh4F YaEkKQrlAFtff+asqwOdZr7pH9mif2eloBaghaoN0rEi51D88HnRgalY+ZguhwES TiNwTlfJzGWGdozBDvPWcwGlB+oFmPGOoGXeNKvPrvE3UFDc69bM0/nAUTOSrx6m 3ExRElqHwELyyZ3dV1gu =LI7w -----END PGP SIGNATURE----- From nobody Thu Aug 27 11:52:07 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D781A0276 for ; Thu, 27 Aug 2015 11:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0tAOy16gDZa for ; Thu, 27 Aug 2015 11:52:02 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2141A00E4 for ; Thu, 27 Aug 2015 11:52:02 -0700 (PDT) Received: by ykbi184 with SMTP id i184so30088540ykb.2 for ; Thu, 27 Aug 2015 11:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EIoFwZENqHzmGx973G6MV3ip2b6iqOngrxGg5pws1to=; b=qPPwYmd7E6CVAYBMnljYscxl6dxMfw09sB/clX6rR1mqqCw88Xnel7CBTyQAfnTS1S CIcUECbceS32AzP2TI2MT5rMwaxsvpHGjIOOI3fGgxaGZdACJDZM/PCaGmW3UmuWUEYB uh/+4Q3P10mI88axbzhIXOxBirC5sh+y/ZdmJELJjK4/4YhbRQBp+Etcnn+oVo0sTbIu DtEaz9pPHo2sqF4lieEVN0Vy5FBGGOpmW1FbxMkcRNb1Q8m4c3iMmonVDiu3lQUy7djP m5x3pPYDVY9xnfzetp3bd0mt2+MlrMScJHS2S/NTth5qrYuri5iLzayV9jFpRGIK34xl Ud5Q== MIME-Version: 1.0 X-Received: by 10.170.57.202 with SMTP id 193mr4750828ykz.118.1440701521983; Thu, 27 Aug 2015 11:52:01 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Thu, 27 Aug 2015 11:52:01 -0700 (PDT) In-Reply-To: <86104CAD-44A6-4C33-BA62-DF15AEE844B5@iii.ca> References: <86104CAD-44A6-4C33-BA62-DF15AEE844B5@iii.ca> Date: Thu, 27 Aug 2015 11:52:01 -0700 Message-ID: From: Martin Thomson To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Alan Johnston , "tram@ietf.org" Subject: Re: [tram] Path Forward for STUN ORIGIN - refer policy X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 18:52:04 -0000 On 27 August 2015 at 06:41, Cullen Jennings wrote: > The solution you are proposing puts the control of if the information is = shared in the hands of the website. I'm pretty sure man websites will choos= e "yep, share the origin". The privacy issue raised was more about if the p= rotecting the interests of the user of the browser and not so concerned wit= h what the website wanted. I think that you are mischaracterizing it. I'm asking sites that want to share this information to go out of their way to do so. Just not a lot out of their way - which isn't that hard in practice. I don't want this to be exposed by default, if that wasn't already clear. Also, I didn't think of it before, but the proposal that Alan made doesn't work if you are authenticating the TURN server. From nobody Thu Aug 27 11:54:58 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317731B3C50 for ; Thu, 27 Aug 2015 11:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUt7KkRAcGs2 for ; Thu, 27 Aug 2015 11:54:56 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2121D1B3C3C for ; Thu, 27 Aug 2015 11:54:43 -0700 (PDT) Received: by ykll84 with SMTP id l84so30219001ykl.0 for ; Thu, 27 Aug 2015 11:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kL10HS5SEp4s6B0SjNBlDOQS4t70kIPV8u/HigkVHpM=; b=dus8IG32HUSQu+OBagU7mGdf70iEbtQ5p+QAj/YxpTwP6TqHB1AxrgGzfFnO+TTHUc N4deqLUM3FZr4EUbj9aBQPrHStPp7OBJt46zHiScbbucw07i4Rz92GtR01hX64GWbcRq +9ORM/Kc5I5ZpSiZAOdyvAaByuLC2J5adj4UizXKQWbLvIf9jraR2vIVfCcSN+7LV3xE CR0mi0wmUZ9Q08PdDO7Iku2QtxaV/Gb0VGmJ1IHGq2sWq6UIYPEF0nelNACN1I/csv+s DdrBt10Goiry5VpzkL2p4H353zrtJLPaPfOMpsKFSL8Ef57kQoWVp3zQTq/S3aDoSOEb gp3g== MIME-Version: 1.0 X-Received: by 10.129.49.200 with SMTP id x191mr4890917ywx.56.1440701682384; Thu, 27 Aug 2015 11:54:42 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Thu, 27 Aug 2015 11:54:42 -0700 (PDT) In-Reply-To: <042FB94E-E3B7-431C-9EC7-D9DF7406756E@iii.ca> References: <042FB94E-E3B7-431C-9EC7-D9DF7406756E@iii.ca> Date: Thu, 27 Aug 2015 11:54:42 -0700 Message-ID: From: Martin Thomson To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Alan Johnston , "tram@ietf.org" Subject: Re: [tram] Path Forward for STUN ORIGIN - how to match X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 18:54:57 -0000 On 27 August 2015 at 06:49, Cullen Jennings wrote: > I could live with A,B, or C, but I think that C provides the best privacy= , is the easiest to understand, and meets the requirements so I favor a mat= ch rule where we match the whole host found in the TURN or STUN URI to the = host part of the HTTP ORIGIN. I don't care about matching if the origin is = secure or not or ports. If this is the path chosen, I agree that C is best. (We don't match certificates on port numbers, so I see no point in greater granularity here either). From nobody Thu Aug 27 12:06:10 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC66B1B302A for ; Thu, 27 Aug 2015 12:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aReNxW40rhJC for ; Thu, 27 Aug 2015 12:06:08 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E061B301F for ; Thu, 27 Aug 2015 12:06:08 -0700 (PDT) Received: by iodt126 with SMTP id t126so68743162iod.2 for ; Thu, 27 Aug 2015 12:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gWMB3Y+pEAkLJL67afW/93O3fKLpNbpyADu3WOpkbCE=; b=BImvO3rABN0kri5i/tLiGlkGLEwBlrMkM4aG3fdnXhf/ZQVoo0E7t7DmI9MPXsPoY3 okAqegGZwE9y7FiAJAFKw3Z8oyikMdyYT41Yt9W7FwXefKBck7urkCpsMKKsWCf2Qu4I UfMBetuNtudbJPbxec1+oliAEaEIsaGXljDchOO89eIcZSdRryibU8vjSrjSHVAU2jyR Cij6C/d+T+7Vs+c5VO4R+Jl8rB6f8Qrf+HfERDumgW3bHCjswGHJ+RPD5i0VRv0ez+w7 6NeKswzv4IkAIJcLNbnBFCZC6qIIvPXadfP8I3zWOQMleqlW+PgDsT23w6b0qo0gBdM2 8ong== MIME-Version: 1.0 X-Received: by 10.107.128.83 with SMTP id b80mr11165576iod.84.1440702367680; Thu, 27 Aug 2015 12:06:07 -0700 (PDT) Received: by 10.79.32.86 with HTTP; Thu, 27 Aug 2015 12:06:07 -0700 (PDT) In-Reply-To: References: <042FB94E-E3B7-431C-9EC7-D9DF7406756E@iii.ca> Date: Thu, 27 Aug 2015 14:06:07 -0500 Message-ID: From: Alan Johnston To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113de4a8da4f89051e4fa88d Archived-At: Cc: "tram@ietf.org" , Cullen Jennings Subject: Re: [tram] Path Forward for STUN ORIGIN - how to match X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 19:06:09 -0000 --001a113de4a8da4f89051e4fa88d Content-Type: text/plain; charset=UTF-8 Cullen, You are completely right - we need to match on hostname, ignoring port and scheme. So C is the right approach for this proposal. - Alan - On Thu, Aug 27, 2015 at 1:54 PM, Martin Thomson wrote: > On 27 August 2015 at 06:49, Cullen Jennings wrote: > > I could live with A,B, or C, but I think that C provides the best > privacy, is the easiest to understand, and meets the requirements so I > favor a match rule where we match the whole host found in the TURN or STUN > URI to the host part of the HTTP ORIGIN. I don't care about matching if the > origin is secure or not or ports. > > > If this is the path chosen, I agree that C is best. (We don't match > certificates on port numbers, so I see no point in greater granularity > here either). > --001a113de4a8da4f89051e4fa88d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cullen,

You are completely right - we n= eed to match on hostname, ignoring port and scheme.=C2=A0 So C is the right= approach for this proposal.

- Alan -
<= div class=3D"gmail_extra">
On Thu, Aug 27, 20= 15 at 1:54 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 27 August 2015 at 06:49, Cu= llen Jennings <fluffy@iii.ca> wr= ote:
> I could live with A,B, or C, but I think that C provides the best priv= acy, is the easiest to understand, and meets the requirements so I favor a = match rule where we match the whole host found in the TURN or STUN URI to t= he host part of the HTTP ORIGIN. I don't care about matching if the ori= gin is secure or not or ports.


If this is the path chosen, I agree that C is best.=C2=A0 (We don't mat= ch
certificates on port numbers, so I see no point in greater granularity
here either).

--001a113de4a8da4f89051e4fa88d-- From nobody Fri Aug 28 03:25:05 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1FC1AD087 for ; Fri, 28 Aug 2015 03:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF8G6tNo_RSn for ; Fri, 28 Aug 2015 03:24:55 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47011ACE1C for ; Fri, 28 Aug 2015 03:24:52 -0700 (PDT) Received: from Kallei7 ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201508281224520184; Fri, 28 Aug 2015 12:24:52 +0200 From: "Karl Stahl" To: "'Prashanth Patil \(praspati\)'" , References: <022601d0c251$9e1944a0$da4bcde0$@stahl@intertex.se> <00c401d0d8eb$db633310$92299930$@com> In-Reply-To: Date: Fri, 28 Aug 2015 12:24:47 +0200 Message-ID: <07c001d0e17b$c4198c20$4c4ca460$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07C1_01D0E18C.87A25C20" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQ1iUXmVhXf6BkRV6lqyfks2yLHZ4LGOoQgAUSOoCAC9iUgIAFBpRw Content-Language: sv Archived-At: Subject: Re: [tram] last call on this draft: draft-ietf-tram-turn-server-discovery-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 10:25:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_07C1_01D0E18C.87A25C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Prashanth, =20 Please see inline below and also next email (on the Review of draft-ietf-tram-turn-server-discovery-04 thread) =20 Thanks, Karl =20 Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil = (praspati) Skickat: den 25 augusti 2015 03:48 Till: Karl Stahl; tram@ietf.org =C4mne: Re: [tram] last call on this draft: draft-ietf-tram-turn-server-discovery-03 =20 Karl, =20 On 8/17/15, 5:54 AM, "Karl Stahl" wrote: =20 Hi Prashanth, =20 See comments /explainations inline below. =20 Thanks, Karl =20 Fr=E5n: Prashanth Patil (praspati) [mailto:praspati@cisco.com]=20 Skickat: den 14 augusti 2015 02:07 Till: Karl Stahl; Tirumaleswar Reddy (tireddy); 'Simon Perreault'; = 'Benjamin Schwartz'; Cullen Jennings (fluffy); 'Adam Roach' Kopia: tram@ietf.org =C4mne: Re: [tram] last call on this draft: draft-ietf-tram-turn-server-discovery-03 =20 Hi Karl, Appreciate the review. Responses inline. =20 On 7/19/15, 11:34 AM, "tram on behalf of Karl Stahl" < tram-bounces@ietf.org on behalf of karl.stahl@intertex.se> wrote =20 =20 Not really, you=92re intercepting traffic not meant for you.=20 [Karl] Isn=92t that exactly what firewalls do? (and both of us, Cisco = and Ingate/Intertex are making such devices=85) Why can=92t the gateway router just listen on the designated anycast = address instead? [Karl] It does but must even then follow the same procedure of: open a = path to the TURN server behind the gateway! =20 =20 My suggestion to add this variant was because what is explained under 4) above: - by blocking STUN packets a gateway router/firewall can enforce an exo-sealed configuration for a TURN client having a leaky default configuration. If sealed configuration (by some yet unknown = configuration method) is done just in browser, it will have the unwanted overhead of sending local real-time traffic twice through the TURN server=20 =20 AND because of that the scenario of a the gateway router/firewall in = front of an ISP network provided TURN server, where both want a sealed configuration where real-time traffic does NOT go through their default gateways, was not outlined here or in the RETURN draft.=20 =20 The longer answer to your question: > Why can=92t the gateway router just listen on the designated anycast = address instead? is: =20 If such gateway router/firewall just would advise an OWN TURN server, = the browser would have to add yet another level of recursively encapsulating (for two network provided plus one application provided TURN server) - a complication we cannot impose. Instead such gateway, must react to an = TURN allocation (by opening a path to the ISP TURN server) =96 and *as a consequence* the specific anycast address is not needed. =20 The procedure suggested for the browser (and thus for the RETURN draft) = is to handle the situation where the gateway intercepts all TURN allocation requests =96 that procedure will *also* work if the firewall instead = only reacts to the anycast address and sets up a path (and allows the next = level to respond to it), while a thinner procedure in the browser may not = handle the case where the gateway answers all TURN allocation requests through = its default gateway. =20 So, by outlining this implicit discovery anycast variant, the RETURN = draft can recommend a procedure that will work for all cases (that the gateway router/firewall may choose to implement this =93kind of TURN allocation = proxy=94 needed when in front of an ISP TURN server.=20 =20 AND FURTHER, if we know the browser will follow a certain procedure, = such gateway router/firewall in front of an ISP TURN server, can auto = configure itself by following the TURN allocate requests and responses that passes = the gateway router/firewall. I don=92t mean it is time to specify such = behavior of such gateway router/firewall in any draft, but if we already now also outline the implicit discovery anycast variant (The method is only 3 = lines of text!) and have the browsers handle it =96 we have paved the way for = easy deployment of network provided TURN servers. =20 What about if this is explained in the document after those 3 lines = defining the implicit discovery anycast variant, like this: =93This is outlines a TURN allocate proxy behavior that a gateway router/firewall in front of an ISP provided TURN server may implement = (one of a few variants). If a real-time application like WebRTC defines the = usage of TURN for such configuration, it should be possible to work = generally.=94 =20 I still don=92t understand why a GW cannot listen on anycast and return = a 300 Try Alternate =96 you achieve the same thing as intercepting anycast = requests flowing through the device. In any case, I don=92t think this draft should deal with this; we should = limit discussion to discovering TURN servers. This seems like something that should go into a use-cases/solution guide draft. =20 [Karl 2] The positive thing you achieve by adding this variant is that = it opens and prepares for an easy and better deployment of network provided TURN servers (e.g. as part of firewalls products), especially when a = sealed configuration is required (the only good way of achieving this is to = impose such configuration this in the firewall). With this variant outlined in = this draft, recommendations like the RETURN-draft can get the WebRTC usage = of the network provided TURN server right now. I see no drawback whatsoever = of outlining this variant, and the positive things I have already listed. =20 I am NOT saying this is required for the anycast method to work (which = your comment seems to imply). It works as described already =20 What about the following text? NEW: Clients can use TURN servers provided by the local network or by the = access network without authenticating with the TURN server. It is recommended = that clients use (D)TLS with network provided TURN servers to authenticate = and prevent man-in-middle attacks. =20 [Karl] Now I think you hit a confusing point that is a source of the authenticate/authorize/credential issue popping up now and again = relating to this draft: Here you say =93use =85 without authentication=94 (meaning = that users need not have credentials) followed by =93to authenticate=94 (meaning = checking that the TURN server has a valid certificate)=20 =20 We=92ll reword to =93validate the the TURN server=94.=20 [Karl 2] That does not remove the confusion and you are adding wrong implications by here suggested texts. See below and next email. =20 In http://www.ietf.org/mail-archive/web/tram/current/msg01747.html the question of =93authenticate and authorize the discovered TURN = server(s)=94 arose again. I think the full story must be spelled out clearly, e.g.: =93The purpose of discovery of a network provided TURN server is to find = a TURN server offered by a network provider or a network admin, to be used = for real-time traffic by the users on that network segment. For WebRTC usage =93everywhere you can surf=94, such TURN servers must be used without = requiring users to have credentials for responding to authentication challenges. Network provided TURN servers must therefore be configured to not = challenge allocation requests from the network segment that they serve and the = TURN server should only be available to and advertised to those users.=20 An advertised network provided TURN server, shall simply be interpreted = as an advice to use the TURN server path for real-time traffic, instead of using the default gateway path. The level of trust is the same for both paths (since both the default gateway and the TURN server are offered = and arranged by the network provider). A sealed configuration (as outlined = in draft-ietf-rtcweb-return) can be arranged by the network provider by blocking STUN packets in the default gateway. For use cases where individual user configuration is wanted and = possible, maybe at an enterprise LAN where not all users should be allowed to use = the TURN server, the TURN server must be configured to authenticate the = users, and credentials then be given to the users. However, for such (unusual) = use cases, it is probably easier and better to also give the IP address of = the TURN server itself to the users, so discovery according to this document would then not be used.=94 I think advice about usage of UPD/TCP/TLS/D(TLS) with the turn server is/shall be out of scope of this draft and left to ICE and the RETURN = draft procedures. =20 We=92re talking of (D)TLS in the context of TURN communication, don=92t = believe it is out of scope.=20 If a TURN client and server do not use long-term credentials for authentication or third-party authorization, (D)TLS can to be used to validate the TURN server. It also addresses the problem of MIM modifying TURN messages. =20 [Karl 2] In the text below, you must believe that you can achieve and = are achieving something positive in the direction of =93Security and privacy = are important considerations.=94 (as you say below), by introducing validation of TURN server=92s = certificate or fingerprint for a network provided TURN server in the context of = WebRTC usage. Your are NOT! See further below and next email. TURN client can use the following techniques to validate a TURN server: =20 o For certificate-based authentication, this includes a pre-populated trust anchor store [rfc6024] that allows = the the TURN client to perform path validation for the server = certificate obtained during the (D)TLS handshake. The client MUST use the rules and guidelines given in section 6 of [RFC6125] to validate the TURN server identity. =20 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), the configured list of TURN servers can contain the Subject Public Key Info (SPKI) fingerprint of the TURN servers. The public = key is used for the same reasons HTTP pinning [RFC7469] uses the public = key. =20 o For raw public key-based authentication as defined in [RFC7250], = this includes either the TURN server's public key or the hash of the server's public key. =20 In the case of WebRTC, encryption and man-in-the-middle-attacks are end-to-end (P2P) considerations and really not affected by the TURN transport. And if there was a successful attacker, probably smart enough = to buy a certificate for his =93smartattacker.com=94 domain name, how could (D)TLS=92s verification of that certificate help anything? =96 It will = not even be displayed to the browser user. =20 That is true with any protocol relying on TLS. Certificate validation = (from a trusted CA, or a configured fingerprint) is a legitimate means of determining the authenticity of the server. [Karl 2] The trusted CA doesn=92t know anything about whether a certain = TURN server is good or evil or whether the owner of the domain name (whether = it is goodturnserverprovider.com or evilmimattacker.com) has good or evil intentions and even less about whether the TURN server fulfills any = security or privacy requirement. =20 [Karl 2] There is no such regulation, testing, certification, register = to achieve anything like this. =20 [Karl 2] The security improvement we get by accessing a website with = https rather than with http is (in addition to the encryption) ONLY that the = user can be sure of that when he surfs to www.goodcompany.com, he can be sure that what he gets in his browser actually comes from the owner of the goodcompany.com domain name. Understanding that the network provided TURN server has the same level = of trust as the default gateway as it effectively parallels, there is no = reason for, and nothing good achieved by checking for certificates or similar = (you don=92t do that for using the default gateway) =96 It is not for this application. Instead, such statements would risks slow down/stop = deployment of network provided TURN servers (and the encryption would hinder the scenario above, with a gateway router/firewall in front of an ISP = network provided TURN server). =20 No, I don=92t think it should be seen as something that hinders = deployment. Security and privacy are important considerations. A client, that = doesn=92t care about these, can choose to ignore server validation or exchange messages over plain text. =20 [Karl 2] No.=20 The security ambition level of this draft must stop at providing a recommendation that: > network provided TURN server has the same level of trust as the = default gateway as it effectively parallels Improvements beyond that is NOT in what you suggest, and I believe also = out of scope for this recommendation. =20 -Prashanth =20 =20 =20 ------=_NextPart_000_07C1_01D0E18C.87A25C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi= Prashanth,

 

Pl= ease see inline below and also next email (on the Review of = draft-ietf-tram-turn-server-discovery-04 thread)

 

Th= anks,

Ka= rl

 

Fr=E5n: tram = [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil = (praspati)
Skickat: den 25 augusti 2015 03:48
Till: = Karl Stahl; tram@ietf.org
=C4mne: Re: [tram] last call on this = draft: = draft-ietf-tram-turn-server-discovery-03

 

Karl,

<= blockquote style=3D'margin-left:30.0pt;margin-right:0cm'>

 

=

On = 8/17/15, 5:54 AM, "Karl Stahl" <karl@ingate.com> = wrote:

 

=

Hi= Prashanth,

&n= bsp;

Se= e comments /explainations inline below.

&n= bsp;

Th= anks,

Ka= rl

&n= bsp;

= Fr=E5n:= Prashanth Patil (praspati) [mailto:praspati@cisco.com] =
Skickat: den 14 augusti 2015 02:07
Till: Karl = Stahl; Tirumaleswar Reddy (tireddy); 'Simon Perreault'; 'Benjamin = Schwartz'; Cullen Jennings (fluffy); 'Adam Roach'
Kopia: tram@ietf.org
=C4mne: Re: = [tram] last call on this draft: = draft-ietf-tram-turn-server-discovery-03

 

Hi Karl,

Appreciate the review. Responses = inline.

 

On 7/19/15, 11:34 AM, "tram = on behalf of Karl Stahl" <tram-bounces@ietf.org on behalf of karl.stahl@intertex.se> wrote

 

<snip>

 

Not really, you’re = intercepting traffic not meant for you.

[K= arl] Isn’t that exactly what firewalls do? (and both of us, Cisco = and Ingate/Intertex are making such devices…)

Why can’t the = gateway router just listen on the designated anycast address = instead?

[K= arl] It does but must even then follow the same procedure of:  = open a path to the TURN server behind the = gateway!&n= bsp;    

&n= bsp;

My= suggestion to add this variant was because what is explained under 4) = above:

- by blocking STUN packets a gateway router/firewall = can enforce an exo-sealed configuration for a TURN client having a leaky = default configuration. If sealed configuration (by some yet unknown = configuration method) is done just in browser, it will have the unwanted = overhead of sending local real-time traffic twice through the TURN = server

&n= bsp;

AN= D because of that the scenario of a the gateway router/firewall in front = of an ISP network provided TURN server, where both want a sealed = configuration where real-time traffic does NOT go through their default = gateways, was not outlined here or in the RETURN draft.

&n= bsp;

Th= e longer answer to your question:

&g= t; Why = can’t the gateway router just listen on the designated anycast = address instead?

is= :

&n= bsp;

If= such gateway router/firewall just would advise an OWN TURN server, the = browser would have to add yet another level of recursively encapsulating = (for two network provided plus one application provided TURN server) - a = complication we cannot impose. Instead such gateway, must react to an = TURN allocation (by opening a path to the ISP TURN server) – and = *as a consequence* the specific anycast address is not = needed.

&n= bsp;

Th= e procedure suggested for the browser (and thus for the RETURN draft) is = to handle the situation where the gateway intercepts all TURN allocation = requests – that procedure will *also* work if the firewall = instead only reacts to the anycast address and sets up a path (and = allows the next level to respond to it), while a thinner procedure in = the browser may not handle the case where the gateway answers all TURN = allocation requests through its default gateway.

&n= bsp;

So= , by outlining this implicit discovery anycast variant, the RETURN draft = can recommend a procedure that will work for all cases (that the gateway = router/firewall may choose to implement this “kind of TURN = allocation proxy” needed when in front of an ISP TURN server. =

&n= bsp;

AN= D FURTHER, if we know the browser will follow a certain procedure, such = gateway router/firewall in front of an ISP TURN server, can auto = configure itself by following the TURN allocate requests and responses = that passes the gateway router/firewall. I don’t mean it is time = to specify such behavior of such gateway router/firewall in any draft, = but if we already now also outline  the implicit discovery anycast = variant  (The method is only 3 lines of text!) and have the = browsers handle it – we have paved the way for easy deployment of = network provided TURN servers.

&n= bsp;

Wh= at about if this is explained in the document after those 3 lines = defining the implicit discovery anycast variant, like this:

&#= 8220;This is outlines a TURN allocate proxy behavior that a gateway = router/firewall in front of an ISP provided TURN server may implement = (one of a few variants). If a real-time application like WebRTC defines = the usage of TURN for such configuration, it should be possible to work = generally.”

 

=

I = still don’t understand why a GW cannot listen on anycast and = return a 300 Try Alternate – you achieve the same thing as = intercepting anycast requests flowing through the = device.

In any case, I don’t think = this draft should deal with this; we should limit discussion to = discovering TURN servers. This seems like something that should go into = a use-cases/solution guide = draft.

 

[K= arl 2] The positive thing you achieve by adding this variant is that it = opens and prepares for an easy and better deployment of network = provided TURN servers (e.g. as part of firewalls products), = especially when a sealed configuration is required (the only good way of = achieving this is to impose such configuration this in the firewall). = With this variant outlined in this draft, recommendations =A0like the = RETURN-draft can get the WebRTC usage of the network provided TURN = server right now. I see no drawback whatsoever of outlining this = variant, and the positive things I have already = listed.

 

I = am NOT saying this is required for the anycast method to work (which = your comment seems to imply). It works as described = already

<snip>

 

What about the following text?

NEW:

Clients can use TURN servers provided by the local network or by the = access network without authenticating with the TURN server. It is = recommended that clients use (D)TLS with network provided TURN servers = to authenticate and prevent man-in-middle attacks.

&n= bsp;

[K= arl] Now I think you hit a confusing point that is a source of the = authenticate/authorize/credential issue popping up now and again = relating to this draft: Here you say “u= se … without authentication&#= 8221; (meaning that users need not have credentials) followed by = “t= o authenticate&#= 8221; (meaning checking that the TURN server has a valid = certificate) 

 

=

We’ll reword to = “validate the the TURN = server”. 

[K= arl 2] That does not remove the confusion and you are adding wrong = implications by here suggested texts. See below and next = email.

&n= bsp;

In= = http://www.ietf.org/mail-archive/web/tram/current/msg01747.html the = question of “authenticate and authorize the discovered TURN = server(s)” arose again.

I = think the full story must be spelled out clearly, e.g.:

&#= 8220;The purpose of discovery of a network provided TURN server is to = find a TURN server offered by a network provider or a network admin, to = be used for real-time traffic by the users on that network segment. For = WebRTC usage “everywhere you can surf”, such TURN servers = must be used without requiring users to have credentials for responding = to authentication challenges. Network provided TURN servers must = therefore be configured to not challenge allocation requests from the = network segment that they serve and the TURN server should only be = available to and advertised to those users.

An= advertised network provided TURN server, shall simply be interpreted as = an advice to use the TURN server path for real-time traffic, instead of = using the default gateway path. The level of trust is the same for both = paths (since both the default gateway and the TURN server are offered = and arranged by the network provider). A sealed configuration (as = outlined in d= raft-ietf-rtcweb-return) = can be arranged by the network provider by blocking STUN packets in the = default gateway.

Fo= r use cases where individual user configuration is wanted and possible, = maybe at an enterprise LAN where not all users should be allowed to use = the TURN server, the TURN server must be configured to authenticate the = users, and credentials then be given to the users. However, for such = (unusual) use cases, it is probably easier and better to also give the = IP address of the TURN server itself to the users, so discovery = according to this document would then not be used.”

I = think advice about usage of UPD/TCP/TLS/D(TLS) with the turn server = is/shall be out of scope of this draft and left to ICE and the RETURN = draft procedures.

 

=

We’re talking of (D)TLS in = the context of TURN communication, don’t believe it is = out of scope. 

If a TURN client and server do = not use long-term credentials for authentication or third-party = authorization, (D)TLS can to be used to validate the TURN server. It = also addresses the problem of MIM modifying TURN = messages.

 

[K= arl 2] In the text below, you must believe that you can achieve and are = achieving something positive in the direction of “Security and privacy = are important considerations.”

(as you say below), by introducing = validation of TURN server’s certificate or fingerprint for a = network provided TURN server in the context of WebRTC = usage.

Your are NOT! See further below = and next email.

TURN client can use the following = techniques to validate a TURN server:

 

   o  For certificate-based = authentication, this

      = includes a pre-populated trust anchor store [rfc6024] that allows = the

     &nbs= p;the TURN client to perform path validation for the server certificate = obtained

      = during the (D)TLS handshake. The client MUST use the rules and = guidelines given in section 6 of

      = [RFC6125] to validate the TURN server identity.

 

   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),

      = the configured list of TURN servers can contain the Subject

      = Public Key Info (SPKI) fingerprint of the TURN servers. The public key = is

      = used for the same reasons HTTP pinning [RFC7469] uses the public = key.

 

   o  For raw = public key-based authentication as defined in [RFC7250], = this

      = includes either the TURN server's public key or the hash of = the

      = server's public key.

 

=

In= the case of WebRTC, encryption and man-in-the-middle-attacks are = end-to-end (P2P) considerations and really not affected by the TURN = transport. And if there was a successful attacker, probably smart enough = to buy a certificate for his “smartattacker.com” domain = name, how could (D)TLS’s verification of that certificate help = anything? – It will not even be displayed to the browser = user.

 

=

That is true with any protocol = relying on TLS. Certificate validation (from a trusted CA, or a = configured fingerprint) is a legitimate means of determining the = authenticity of the server.

[K= arl 2] The trusted CA doesn’t know anything about whether a = certain TURN server is good or evil or whether the owner of the domain = name (whether it is goodturnserverprovider.com or evilmimattacker.com) = has good or evil intentions and even less about whether the TURN server = fulfills any security or privacy requirement.

 

[K= arl 2] There is no such regulation, testing, certification, register to = achieve anything like this.

 

[K= arl 2] The security improvement we get by accessing a website with https = rather than with http is (in addition to the encryption) ONLY that the = user can be sure of that when he surfs to www.goodcompany.com, he can be = sure that what he gets in his browser actually comes from the owner of = the goodcompany.com domain name.

<= blockquote style=3D'margin-left:30.0pt;margin-right:0cm'>

Un= derstanding that the network provided TURN server has the same level of = trust as the default gateway as it effectively parallels, there is no = reason for, and nothing good achieved by checking for certificates or = similar (you don’t do that for using the default gateway) – = It is not for this application. Instead, such statements would risks = slow down/stop deployment of network provided TURN servers (and the = encryption would hinder the scenario above, with a gateway = router/firewall in front of an ISP network provided TURN = server).

 

=

No, I don’t think it should = be seen as something that hinders deployment. Security and privacy are = important considerations. A client, that doesn’t care about these, = can choose to ignore server validation or exchange messages over plain = text.

 

[K= arl 2] No= .

Th= e security ambition level of this draft must stop at providing a = recommendation that:

&g= t; = network provided TURN server has the same level of trust as the default = gateway as it effectively parallels

Im= provements beyond that is NOT in what you suggest, and I believe also = out of scope for this recommendation.

 

-Prashanth

 

 

 

------=_NextPart_000_07C1_01D0E18C.87A25C20-- From nobody Fri Aug 28 03:46:53 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4917F1B2FFF for ; Fri, 28 Aug 2015 03:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNWdZjI1WYo7 for ; Fri, 28 Aug 2015 03:46:46 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD7081B2FCE for ; Fri, 28 Aug 2015 03:46:44 -0700 (PDT) Received: from Kallei7 ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201508281246454804; Fri, 28 Aug 2015 12:46:45 +0200 From: "Karl Stahl" To: "'Prashanth Patil \(praspati\)'" , References: In-Reply-To: Date: Fri, 28 Aug 2015 12:46:40 +0200 Message-ID: <07fe01d0e17e$d2c85e60$78591b20$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07FF_01D0E18F.96512E60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQ2DejsL2ieytYxUGpJUJvFE3w254b/s2AgAUHs5A= Content-Language: sv Archived-At: Cc: 'Bernard Aboba' Subject: Re: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 10:46:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_07FF_01D0E18F.96512E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Prashanth, =20 What you propose below is in no way acceptable, and adds to, rather than remedies the confusion this draft is introducing in its current form. =20 Please understand that: =20 1) Checking the validity of a certificate does not in itself or automatically help =93Security and privacy are important = considerations=94 as you state in your answer in the previous email. The security improvement = we get by accessing a website with https rather than http is (in addition = to the encryption) ONLY that the user can be sure of that when he surfs to www.goodcompany.com, he can be sure that what he gets in his browser actually comes from the owner of the goodcompany.com domain name. =20 2) In the context of WebRTC usage, you do not achieve anything by = checking a certificate for a discovered TURN server. The validation in itself = does not guarantee anything about whether the TURN server is good or bad or = evil. Further, the certificate for the TURN server will not even be presented = to the user to give him the (impossible) task of judging whether to trust a transport, based on the domain name validation (if that is the thought behind introducing this).=20 =20 3) If you don=92t have another purpose with this draft than (copied from = the previous email): =93The purpose of discovery of a network provided TURN server is to find = a TURN server offered by a network provider or a network admin, to be used = for real-time traffic by the users on that network segment.=94=20 please also understand (copied from the previous email): =93An advertised network provided TURN server, shall simply be = interpreted as an advice to use the TURN server path for real-time traffic, instead of using the default gateway path. The level of trust is the same for both paths (since both the default gateway and the TURN server are offered = and arranged by the network provider). A sealed configuration (as outlined = in draft-ietf-rtcweb-return) can be arranged by the network provider by blocking STUN packets in the default gateway.=94 It not up to this discovery draft to specify or to =93try to invent=94 = higher trust levels.=20 =20 And it must not be up to this draft to recommend about the transport = (you are here suggesting (D)TLS), and especially not with a motivation that = does not achieve anything positive in the context of WebRTC usage. For = WebRTC, there are the RTCWEB WG=92s TRANSPORT, RETURN and possible other = documents where transports are being specified. =20 /Karl =20 PS For further details, see previous email on the =93last call on this = draft: draft-ietf-tram-turn-server-discovery-03=94 thread=20 =20 Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil = (praspati) Skickat: den 25 augusti 2015 03:45 Till: Bernard Aboba; tram@ietf.org =C4mne: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04 =20 Hi Bernard, =20 On 7/30/15, 11:23 AM, "tram on behalf of Bernard Aboba" wrote: =20 1. Overall, in reading this document it was not clear to me how it was intended to be applied to WebRTC scenarios where a TURN server is configured in = the JS.=20 =20 * Does TURN server discovery apply in this case, or is the JS-specified = TURN server considered "manual TURN configuration" ?=20 =20 Yes, JS-specified TURN server should be considered as = auto-configuration. We=92ll update the draft accordingly. =20 * Where IdP is used, is the local IdP identity considered to consitute a "domain name" per Section 4.1.2? =20 =20 Is there a need to make this explicit? The text in the draft is intentionally generic to leave the decision up to the application: "For a TURN client with an understanding of the protocol mechanics of calling applications, the client may wish to extract the domain name = from its own identity" =20 2. In scenarios where TURN Server discovery does apply, what mechanisms = are to be used to authenticate or authorize the discovered TURN Servers(s)? Using a configured domain name seems like a potentially viable approach, = but there are scenarios where that might not be configured, or might not be secure (e.g. if the domain name were obtained from unauthenticated DHCP). =20 =20 We plan to add the following, does it address some of your concerns: TURN client can use the following techniques to validate a TURN server: =20 o For certificate-based authentication, this includes a pre-populated trust anchor store [rfc6024] that allows = the the TURN client to perform path validation for the server = certificate obtained during the (D)TLS handshake. The client MUST use the rules and guidelines given in section 6 of [RFC6125] to validate the TURN server identity. =20 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), the configured list of TURN servers can contain the Subject Public Key Info (SPKI) fingerprint of the TURN servers. The public = key is used for the same reasons HTTP pinning [RFC7469] uses the public = key. =20 o For raw public key-based authentication as defined in [RFC7250], = this includes either the TURN server's public key or the hash of the server's public key. =20 Using the browser's configured trust anchor(s) doesn't seem like a good idea, given that it would only be as secure as the least-secure trust anchor.=20 =20 Isn=92t that true with any server the client tries to validate using certificates? =20 Specific comments:=20 =20 Section 3 =20 1. Local Configuration : Local or manual TURN configuration (i.e., TURN servers configured at the system level) should be tried first, as it may be an explicit preferred choice of a user. =20 [BA] Would TURN servers specified within a WebRTC JS application be considered "local or manual" in this context?=20 =20 Also, shouldn't a configured domain name (Section 4.1.2) be considered = part of "local TURN configuration"?=20 =20 Yes, configured domain name can be considered as local or auto-configuration. =20 IMHO, the configured domain name not only enables discovery as indicated in Section 4.2, but also provides a mechanism for validation of the TURN server discovered by other methods. =20 =20 Correct. We=92ll update the draft to highlight this point. =20 The document does not prescribe a strict order that a client must follow for discovery. An implementation may choose to perform steps 2,3 and 4 in parallel for discovery OR choose to follow any desired order and stop the discovery procedure if a mechanism succeeds. =20 [BA] I am not sure I buy this. It is already stated that "local or = manual" configuration should be tried first, and I would considered a configured domain name to be part of this, which would imply attempting 2 first if = that exists. =20 =20 Good point. A client should be able to perform discovery on all in = parallel (or in any order of choice), including manual/auto configuration. =20 Section 9.2 =20 For mDNS, in addition to what has been described above, a principal security threat is a security threat inherent to IP multicast routing and any application that runs on it. A rogue system can advertise that it is a TURN server. Discovery of such rogue systems as TURN servers, in itself, is not a security threat if there is a means for the TURN client to authenticate and authorize the discovered TURN servers. =20 [BA] In scenarios in which mDNS would be used, there typically will not = be a means for the TURN client to authentication and authorize the discovered TURN server. For example, a home router with a built-in TURN server is not likely to have a certificate chaining to a trust anchor. =20 If discovered in a local n/w, a client can be explicitly configured with = the fingerprint of the server. =20 Also, the mDNS is not compatible with DNSSEC (e.g. there is no signer for the = .local domain). =20 =20 Same as above. A client, if configured with a fingerprint, could = validate the server. =20 Section 9.3 =20 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. =20 [BA] This seems like a crude tool at best. If the goal is to provide privacy, wouldn't use of encryption make more sense? This could include DNS = privacy, encryption of TURN traffic, etc.=20 =20 TURN encryption wouldn=92t be possible because the client is not aware = of the TURN server it is trying to connect. The above is only a recommendation = if a client is concerned with anycast going out of a desired boundary. =20 -Prashanth ------=_NextPart_000_07FF_01D0E18F.96512E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi= Prashanth,

 

Wh= at you propose below is in no way acceptable, and adds to, rather than = remedies the confusion this draft is introducing in its current = form.

 

Pl= ease understand that:

 

1)= Checking the validity of a certificate does not in itself or = automatically help “Security and privacy are = important considerations&#= 8221; as you state in your answer in the previous email. The security = improvement we get by accessing a website with https rather than http is = (in addition to the encryption) ONLY that the user can be sure of that = when he surfs to www.goodcompany.com, he can be sure that what he gets = in his browser actually comes from the owner of the goodcompany.com = domain name.

 

2)= =A0In the context of WebRTC usage, you do not achieve anything by = checking a certificate for a discovered TURN server. The validation in = itself does not guarantee anything about whether the TURN server is good = or bad or evil. Further, the certificate for the TURN server will not = even be presented to the user to give him the (impossible) task of = judging whether to trust a transport, based on the domain name = validation (if that is the thought behind introducing this). =

 

3)= If you don’t have another purpose with this draft than (copied = from the previous email):

“The = purpose of discovery of a network provided TURN server is to find a TURN = server offered by a network provider or a network admin, to be used for = real-time traffic by the users on that network segment.” =

pl= ease also understand (copied from the previous email):<= /p>

“An = advertised network provided TURN server, shall simply be interpreted as = an advice to use the TURN server path for real-time traffic, instead of = using the default gateway path. The level of trust is the same for both = paths (since both the default gateway and the TURN server are offered = and arranged by the network provider). A sealed configuration (as = outlined in draft-ietf-rtcweb-return) can be arranged by the network = provider by blocking STUN packets in the default = gateway.”

It= not up to this discovery draft to specify or to “try to = invent” higher trust levels.

 

An= d it must not be up to this draft to recommend about the transport (you = are here suggesting (D)TLS), and especially not with a motivation that = does not achieve anything positive in the context of WebRTC usage. For = WebRTC, there are the RTCWEB WG’s TRANSPORT, RETURN and possible = other documents where transports are being = specified.

 

/K= arl

 

PS= For further details, see previous email on the “last call on this = draft: draft-ietf-tram-turn-server-discovery-03” thread =

 

Fr=E5n: tram = [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil = (praspati)
Skickat: den 25 augusti 2015 03:45
Till: = Bernard Aboba; tram@ietf.org
=C4mne: [tram] FW: Review of = draft-ietf-tram-turn-server-discovery-04

 

Hi Bernard,

 

On 7/30/15, 11:23 AM, "tram on behalf of Bernard Aboba" = <tram-bounces@ietf.org = on behalf of bernard.aboba@gmail.com> = wrote:

 

1. Overall, in reading this document it was not clear to me how it was = intended

to be applied to WebRTC scenarios where a TURN server is configured in = the JS. 

 

* Does TURN server discovery apply in this case, or is the JS-specified = TURN server considered "manual TURN configuration" = ? 

 

Yes, JS-specified TURN server should be considered as = auto-configuration. We’ll update the draft = accordingly.

 

* Where IdP is used, is the local IdP identity considered to consitute = a "domain name" per Section 4.1.2? =  

 

Is there a need to make this explicit? The text in the draft is = intentionally generic to leave the decision up to the = application:

"For a TURN client with an understanding of =
the protocol mechanics of calling applications, the client may wish to =
extract the domain name from its own =
identity"

 

2. In scenarios where TURN Server discovery does apply, what mechanisms = are to be used to authenticate or authorize the discovered TURN = Servers(s)?  Using a configured domain name seems like a = potentially viable approach, but there are scenarios where that might = not be configured, or might not be = secure

(e.g. if the domain name were obtained from unauthenticated DHCP). =  

 

We plan to add the following, does it address some of your = concerns:

TURN client can use the following techniques to = validate a TURN server:

 

   o  For = certificate-based authentication, this

      includes a = pre-populated trust anchor store [rfc6024] that allows = the

      the TURN = client to perform path validation for the server certificate = obtained

      during the (D)TLS = handshake. The client MUST use the rules and guidelines given in section = 6 of

      [RFC6125] to = validate the TURN server identity.

 

   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),

      the configured list = of TURN servers can contain the Subject

      Public Key Info = (SPKI) fingerprint of the TURN servers. The public key = is

      used for the same = reasons HTTP pinning [RFC7469] uses the public = key.

 

   o  For = raw public key-based authentication as defined in [RFC7250], = this

      includes either the = TURN server's public key or the hash of the

      server's public = key.

 

Using the browser's configured trust anchor(s) doesn't seem like a good = idea, given that it would only be as secure as the least-secure trust = anchor. 

<= blockquote style=3D'margin-left:30.0pt;margin-right:0cm'>

 

Isn’t that true with any server the client tries to validate = using = certificates?

 

Specific comments: 

 

Section 3

 

   1.  Local Configuration : Local or manual TURN = configuration (i.e.,

       TURN servers configured at the system level) = should be tried

       first, as it may be an explicit preferred = choice of a user.

 

[BA] Would TURN servers specified within a WebRTC JS application be = considered "local or manual" in this = context? 

=

 

Also, shouldn't a configured domain name (Section 4.1.2) be considered = part of "local TURN = configuration"? 

=

 

Yes, configured domain name can be considered as local or = auto-configuration.

 

IMHO, the configured domain name not only enables discovery as = indicated

in Section 4.2, but also provides a mechanism for validation of = the

TURN server discovered by other methods. =   

 

Correct. We’ll update the draft to highlight this = point.

 

   The document does not prescribe a strict order that a = client must

   follow for discovery.  An implementation may choose = to perform steps

   2,3 and 4 in parallel for discovery OR choose to follow = any desired

   order and stop the discovery procedure if a mechanism = succeeds.

 

[BA] I am not sure I buy this.  It is already stated that = "local or manual" configuration should be tried first, and I = would considered a configured domain name to be part of this, which = would imply attempting 2 first if that exists. =   

 

Good point. A client should be able to perform discovery on all in = parallel (or in any order of choice), including manual/auto = configuration.

 

Section 9.2

 

   For mDNS, in addition to what has been described above, a = principal

   security threat is a security threat inherent to IP = multicast routing

   and any application that runs on it.  A rogue system = can advertise

   that it is a TURN server.  Discovery of such rogue = systems as TURN

   servers, in itself, is not a security threat if there is a = means for

   the TURN client to authenticate and authorize the = discovered TURN

   servers.

 

[BA] In scenarios in which mDNS would be used, there typically will not = be a

means for the TURN client to authentication and authorize the = discovered

TURN server. For example, a home router with a built-in TURN server = is

not likely to have a certificate chaining to a trust = anchor.

 

If discovered in a local n/w, a client can be explicitly configured = with the fingerprint of the server.

 

  Also, the

mDNS is not compatible with DNSSEC (e.g. there is no signer for the = .local

domain). =  

 

Same as above. A client, if configured with a fingerprint, could = validate the = server.

 

Section 9.3

 

   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.

 

[BA] This seems like a crude tool at best.  If the goal is to = provide privacy,

wouldn't use of encryption make more sense?  This could include = DNS privacy,

encryption of TURN traffic, = etc. 

 

TURN encryption wouldn’t be possible because the client is not = aware of the TURN server it is trying to connect. The above is only a = recommendation if a client is concerned with anycast going out of a = desired boundary.

 

-Prashanth

------=_NextPart_000_07FF_01D0E18F.96512E60-- From nobody Fri Aug 28 09:42:20 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204031A1BC2 for ; Fri, 28 Aug 2015 09:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlckDs8rx6X1 for ; Fri, 28 Aug 2015 09:42:12 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C7B71A7D83 for ; Fri, 28 Aug 2015 09:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48667; q=dns/txt; s=iport; t=1440780132; x=1441989732; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gtGcybBD4XakkNkzLvHdToT+OSVQ2Gj1ZSKReZjlqDg=; b=NBOVlcfsgKbMAf2G19VVAihbvmVkSrnEFd5C7bWJSChypujsJfc4ixJV TpGW1Ld7RooVdt7kEVhTfjat9vi3mNo/phPQm1OrNIqTVAYyKvWU2FoJc JwKL6DdfBTS+uYnRWa4GQT1JqqjGhn0uci+cKD9qiiZOgO5tUHyZ3mwdr Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BlBQAMjuBV/40NJK1VCYJOTVRpBr4FgXSFfwKBPDoSAQEBAQEBAYEKhCMBAQEELRwwEAIBCBEEAQELFgEGByERFAgBCAIEAQ0FCIgRAxK/PA2FHwEBAQEBAQEBAQEBAQEBAQEBAQEBAReGbYR1gk+BTwoHCgEGGjEGAQmDD4EUBYxuOYUAgxgBhQWCbYMTgzdGg2yMNnmDUINsJoIOHYFUcYEHBxcHHIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,425,1437436800"; d="scan'208,217";a="183039425" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP; 28 Aug 2015 16:42:10 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t7SGgAd0014397 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2015 16:42:10 GMT Received: from xch-aln-012.cisco.com (173.36.7.22) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 28 Aug 2015 11:42:09 -0500 Received: from xhc-rcd-x09.cisco.com (173.37.183.83) by xch-aln-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 28 Aug 2015 11:42:09 -0500 Received: from xmb-rcd-x10.cisco.com ([169.254.15.53]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0248.002; Fri, 28 Aug 2015 11:42:09 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Karl Stahl , "Prashanth Patil (praspati)" , "tram@ietf.org" Thread-Topic: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04 Thread-Index: AQHQ3te5ncVDPQtDL06JLXh/TKKDdZ4hk8YAgAAF/tA= Date: Fri, 28 Aug 2015 16:42:08 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478C981E@xmb-rcd-x10.cisco.com> References: <07fe01d0e17e$d2c85e60$78591b20$@stahl@intertex.se> In-Reply-To: <07fe01d0e17e$d2c85e60$78591b20$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.46.125] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A478C981Exmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: 'Bernard Aboba' Subject: Re: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 16:42:19 -0000 --_000_913383AAA69FF945B8F946018B75898A478C981Exmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If TURN client and TURN server are not using long-term credentials or third= -party authorization then (D)TLS is the only way to authenticate the TURN s= erver, and it also solves the problem of MIM attacker modifying TURN messag= es, passive attacker deleting existing allocations etc. (D)TLS for TURN is = already defined in RFC 5766 and RFC 7350. -Tiru From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl Sent: Friday, August 28, 2015 4:17 PM To: Prashanth Patil (praspati); tram@ietf.org Cc: 'Bernard Aboba' Subject: Re: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04 Hi Prashanth, What you propose below is in no way acceptable, and adds to, rather than re= medies the confusion this draft is introducing in its current form. Please understand that: 1) Checking the validity of a certificate does not in itself or automatical= ly help "Security and privacy are important considerations" as you state in= your answer in the previous email. The security improvement we get by acce= ssing a website with https rather than http is (in addition to the encrypti= on) ONLY that the user can be sure of that when he surfs to www.goodcompany= .com, he can be sure that what he gets in his b= rowser actually comes from the owner of the goodcompany.com domain name. 2) In the context of WebRTC usage, you do not achieve anything by checking= a certificate for a discovered TURN server. The validation in itself does = not guarantee anything about whether the TURN server is good or bad or evil= . Further, the certificate for the TURN server will not even be presented t= o the user to give him the (impossible) task of judging whether to trust a = transport, based on the domain name validation (if that is the thought behi= nd introducing this). 3) If you don't have another purpose with this draft than (copied from the = previous email): "The purpose of discovery of a network provided TURN server is to find a TU= RN server offered by a network provider or a network admin, to be used for = real-time traffic by the users on that network segment." please also understand (copied from the previous email): "An advertised network provided TURN server, shall simply be interpreted as= an advice to use the TURN server path for real-time traffic, instead of us= ing the default gateway path. The level of trust is the same for both paths= (since both the default gateway and the TURN server are offered and arrang= ed by the network provider). A sealed configuration (as outlined in draft-i= etf-rtcweb-return) can be arranged by the network provider by blocking STUN= packets in the default gateway." It not up to this discovery draft to specify or to "try to invent" higher t= rust levels. And it must not be up to this draft to recommend about the transport (you a= re here suggesting (D)TLS), and especially not with a motivation that does = not achieve anything positive in the context of WebRTC usage. For WebRTC, t= here are the RTCWEB WG's TRANSPORT, RETURN and possible other documents whe= re transports are being specified. /Karl PS For further details, see previous email on the "last call on this draft:= draft-ietf-tram-turn-server-discovery-03" thread Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil (praspati= ) Skickat: den 25 augusti 2015 03:45 Till: Bernard Aboba; tram@ietf.org =C4mne: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04 Hi Bernard, On 7/30/15, 11:23 AM, "tram on behalf of Bernard Aboba" on behalf of bernard.aboba@gmail.com> wrote: 1. Overall, in reading this document it was not clear to me how it was inte= nded to be applied to WebRTC scenarios where a TURN server is configured in the = JS. * Does TURN server discovery apply in this case, or is the JS-specified TUR= N server considered "manual TURN configuration" ? Yes, JS-specified TURN server should be considered as auto-configuration. W= e'll update the draft accordingly. * Where IdP is used, is the local IdP identity considered to consitute a "d= omain name" per Section 4.1.2? Is there a need to make this explicit? The text in the draft is intentional= ly generic to leave the decision up to the application: "For a TURN client with an understanding of the protocol mechanics of calli= ng applications, the client may wish to extract the domain name from its ow= n identity" 2. In scenarios where TURN Server discovery does apply, what mechanisms are= to be used to authenticate or authorize the discovered TURN Servers(s)? U= sing a configured domain name seems like a potentially viable approach, but= there are scenarios where that might not be configured, or might not be se= cure (e.g. if the domain name were obtained from unauthenticated DHCP). We plan to add the following, does it address some of your concerns: TURN client can use the following techniques to validate a TURN server: o For certificate-based authentication, this includes a pre-populated trust anchor store [rfc6024] that allows the the TURN client to perform path validation for the server certificate= obtained during the (D)TLS handshake. The client MUST use the rules and guidel= ines given in section 6 of [RFC6125] to validate the TURN server identity. 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), the configured list of TURN servers can contain the Subject Public Key Info (SPKI) fingerprint of the TURN servers. The public ke= y is used for the same reasons HTTP pinning [RFC7469] uses the public key. o For raw public key-based authentication as defined in [RFC7250], this includes either the TURN server's public key or the hash of the server's public key. Using the browser's configured trust anchor(s) doesn't seem like a good ide= a, given that it would only be as secure as the least-secure trust anchor. Isn't that true with any server the client tries to validate using certific= ates? Specific comments: Section 3 1. Local Configuration : Local or manual TURN configuration (i.e., TURN servers configured at the system level) should be tried first, as it may be an explicit preferred choice of a user. [BA] Would TURN servers specified within a WebRTC JS application be conside= red "local or manual" in this context? Also, shouldn't a configured domain name (Section 4.1.2) be considered part= of "local TURN configuration"? Yes, configured domain name can be considered as local or auto-configuratio= n. IMHO, the configured domain name not only enables discovery as indicated in Section 4.2, but also provides a mechanism for validation of the TURN server discovered by other methods. Correct. We'll update the draft to highlight this point. The document does not prescribe a strict order that a client must follow for discovery. An implementation may choose to perform steps 2,3 and 4 in parallel for discovery OR choose to follow any desired order and stop the discovery procedure if a mechanism succeeds. [BA] I am not sure I buy this. It is already stated that "local or manual"= configuration should be tried first, and I would considered a configured d= omain name to be part of this, which would imply attempting 2 first if that= exists. Good point. A client should be able to perform discovery on all in parallel= (or in any order of choice), including manual/auto configuration. Section 9.2 For mDNS, in addition to what has been described above, a principal security threat is a security threat inherent to IP multicast routing and any application that runs on it. A rogue system can advertise that it is a TURN server. Discovery of such rogue systems as TURN servers, in itself, is not a security threat if there is a means for the TURN client to authenticate and authorize the discovered TURN servers. [BA] In scenarios in which mDNS would be used, there typically will not be = a means for the TURN client to authentication and authorize the discovered TURN server. For example, a home router with a built-in TURN server is not likely to have a certificate chaining to a trust anchor. If discovered in a local n/w, a client can be explicitly configured with th= e fingerprint of the server. Also, the mDNS is not compatible with DNSSEC (e.g. there is no signer for the .local domain). Same as above. A client, if configured with a fingerprint, could validate t= he server. Section 9.3 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. [BA] This seems like a crude tool at best. If the goal is to provide priva= cy, wouldn't use of encryption make more sense? This could include DNS privacy= , encryption of TURN traffic, etc. TURN encryption wouldn't be possible because the client is not aware of the= TURN server it is trying to connect. The above is only a recommendation if= a client is concerned with anycast going out of a desired boundary. -Prashanth --_000_913383AAA69FF945B8F946018B75898A478C981Exmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If TURN client and TURN s= erver are not using long-term credentials or third-party authorization then= (D)TLS is the only way to authenticate the TURN server, and it also solves the problem of MIM attacker modifying TURN messages, pa= ssive attacker deleting existing allocations etc. (D)TLS for TURN is alread= y defined in RFC 5766 and RFC 7350.

 <= /p>

-Tiru

 <= /p>

From: tram [ma= ilto:tram-bounces@ietf.org] On Behalf Of Karl Stahl
Sent: Friday, August 28, 2015 4:17 PM
To: Prashanth Patil (praspati); tram@ietf.org
Cc: 'Bernard Aboba'
Subject: Re: [tram] FW: Review of draft-ietf-tram-turn-server-discov= ery-04

 

Hi Prashanth,

 

What you propose below is in n= o way acceptable, and adds to, rather than remedies the confusion this draf= t is introducing in its current form.

 

Please understand that:

 

1) Checking the validity of a = certificate does not in itself or automatically help “Security and privacy are important considerations” as you state in your an= swer in the previous email. The security improvement we get by accessing a = website with https rather than http is (in addition to the encryption) ONLY that the user can be sure of that when he surfs to www.goodcompany.com, he can be sure that what he gets in his browser ac= tually comes from the owner of the goodcompany.com domain name.<= /span>

 

2)  In the context of Web= RTC usage, you do not achieve anything by checking a certificate for a disc= overed TURN server. The validation in itself does not guarantee anything about whether the TURN server is good or bad or evil. Further, th= e certificate for the TURN server will not even be presented to the user to= give him the (impossible) task of judging whether to trust a transport, ba= sed on the domain name validation (if that is the thought behind introducing this).

 

3) If you don’t have ano= ther purpose with this draft than (copied from the previous email):

“The purpose of discovery of a network provided T= URN server is to find a TURN server offered by a network provider or a network admin, to be used for real-time traffic by the users on that = network segment.”

please also understand (copied from the prev= ious email):

“An advertised network provided TURN server, shal= l simply be interpreted as an advice to use the TURN server path for real-time traffic, instead of using the default gateway path. The leve= l of trust is the same for both paths (since both the default gateway and t= he TURN server are offered and arranged by the network provider). A sealed = configuration (as outlined in draft-ietf-rtcweb-return) can be arranged by the network provider by blocking STUN packets in the de= fault gateway.”

It not up to this discovery dr= aft to specify or to “try to invent” higher trust levels.

 

And it must not be up to this = draft to recommend about the transport (you are here suggesting (D)TLS), an= d especially not with a motivation that does not achieve anything positive in the context of WebRTC usage. For WebRTC, there are th= e RTCWEB WG’s TRANSPORT, RETURN and possible other documents where tr= ansports are being specified.

 

/Karl

 

PS For further details, see pr= evious email on the “last call on this draft: draft-ietf-tram-turn-se= rver-discovery-03” thread

 

Fr=E5n: tram [mailto:tra= m-bounces@ietf.org] F=F6r Prashanth Patil (praspati)
Skickat: den 25 augusti 2015 03:45
Till: Bernard Aboba; tram@ietf.org<= /a>
=C4mne: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-0= 4

 

Hi Bernard,

 

 

1. Overall, in = reading this document it was not clear to me how it was intended=

to be applied t= o WebRTC scenarios where a TURN server is configured in the JS. <= /o:p>

 

* Does TURN ser= ver discovery apply in this case, or is the JS-specified TURN server consid= ered "manual TURN configuration" ? 

 

Yes, JS-specifi= ed TURN server should be considered as auto-configuration. We’ll upda= te the draft accordingly.

 

* Where IdP is = used, is the local IdP identity considered to consitute a "domain name= " per Section 4.1.2?  

 

Is there a need= to make this explicit? The text in the draft is intentionally generic to l= eave the decision up to the application:

"For a TURN client with an understanding of the proto=
col mechanics of calling applications, the client may wish to extract the d=
omain name from its own identity"

 

2. In scenarios= where TURN Server discovery does apply, what mechanisms are to be used to = authenticate or authorize the discovered TURN Servers(s)?  Using a configured domain name seems like a potentially viable approach, b= ut there are scenarios where that might not be configured, or might not be = secure

(e.g. if the do= main name were obtained from unauthenticated DHCP).  

 

We plan to add = the following, does it address some of your concerns:

TURN client = can use the following techniques to validate a TURN server:

 <= /o:p>

  = o  For certificate-based authentication, this

  =     includes a pre-populated trust anchor store [rfc6024] th= at allows the

  =     the TURN client to perform path validation for the = server certificate obtained

  =     during the (D)TLS handshake. The client MUST use the rul= es and guidelines given in section 6 of

  =     [RFC6125] to validate the TURN server identity.

 <= /o:p>

  = 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),

  =     the configured list of TURN servers can contain the Subj= ect

  =     Public Key Info (SPKI) fingerprint of the TURN servers. = The public key is

  =     used for the same reasons HTTP pinning [RFC7469] uses th= e public key.

 <= /o:p>

  = o  For raw public key-based authentication as defined in [RFC7250], t= his

  =     includes either the TURN server's public key or the hash= of the

  =     server's public key.

 

Using the brows= er's configured trust anchor(s) doesn't seem like a good idea, given that i= t would only be as secure as the least-secure trust anchor. 

 

Isn’t tha= t true with any server the client tries to validate using certificates?

 

Specific commen= ts: 

 

Section 3<= /o:p>

 

   1.=   Local Configuration : Local or manual TURN configuration (i.e.,=

    &= nbsp;  TURN servers configured at the system level) should be tried

    &= nbsp;  first, as it may be an explicit preferred choice of a user.

 

[BA] Would TURN= servers specified within a WebRTC JS application be considered "local= or manual" in this context? 

 

Also, shouldn't= a configured domain name (Section 4.1.2) be considered part of "local= TURN configuration"? 

 

Yes, configured= domain name can be considered as local or auto-configuration.

 

IMHO, the confi= gured domain name not only enables discovery as indicated=

in Section 4.2,= but also provides a mechanism for validation of the

TURN server dis= covered by other methods.   

 

Correct. WeR= 17;ll update the draft to highlight this point.

 

   Th= e document does not prescribe a strict order that a client must<= /span>

   fo= llow for discovery.  An implementation may choose to perform steps

   2,= 3 and 4 in parallel for discovery OR choose to follow any desired

   or= der and stop the discovery procedure if a mechanism succeeds.

 

[BA] I am not s= ure I buy this.  It is already stated that "local or manual"= configuration should be tried first, and I would considered a configured domain name to be part of this, which would imply attempting 2 first if th= at exists.   

 

Good point. A c= lient should be able to perform discovery on all in parallel (or in any ord= er of choice), including manual/auto configuration.

 

Section 9.2

 

   Fo= r mDNS, in addition to what has been described above, a principal

   se= curity threat is a security threat inherent to IP multicast routing

   an= d any application that runs on it.  A rogue system can advertise<= /o:p>

   th= at it is a TURN server.  Discovery of such rogue systems as TURN<= /o:p>

   se= rvers, in itself, is not a security threat if there is a means for

   th= e TURN client to authenticate and authorize the discovered TURN<= /span>

   se= rvers.

 

[BA] In scenari= os in which mDNS would be used, there typically will not be a

means for the T= URN client to authentication and authorize the discovered=

TURN server. Fo= r example, a home router with a built-in TURN server is

not likely to h= ave a certificate chaining to a trust anchor.

 

If discovered i= n a local n/w, a client can be explicitly configured with the fingerprint o= f the server.

 

  Also, th= e

mDNS is not com= patible with DNSSEC (e.g. there is no signer for the .local

domain).  =

 

Same as above. = A client, if configured with a fingerprint, could validate the server.=

 

Section 9.3

 

   Se= nsitive clients that do not wish to leak information about their=

   pr= esence can set an IP TTL on their TURN requests that limits how far

   th= ey can travel into the public Internet.

 

[BA] This seems= like a crude tool at best.  If the goal is to provide privacy,

wouldn't use of= encryption make more sense?  This could include DNS privacy,

encryption of T= URN traffic, etc. 

 

TURN encryption= wouldn’t be possible because the client is not aware of the TURN ser= ver it is trying to connect. The above is only a recommendation if a client is concerned with anycast going out of a desired boundary.

 

-Prashanth=

--_000_913383AAA69FF945B8F946018B75898A478C981Exmbrcdx10ciscoc_-- From nobody Fri Aug 28 21:45:53 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856171B399B for ; Fri, 28 Aug 2015 21:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKYocmaiR7Q0 for ; Fri, 28 Aug 2015 21:45:50 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAE01B3979 for ; Fri, 28 Aug 2015 21:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2752; q=dns/txt; s=iport; t=1440823549; x=1442033149; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=91PIjMpzdE04XGD6WMTWgKpVH6v47spKQcCMsFvDYTs=; b=WCKDAribKwZDxCMu+u235Mu1WoF2hPKBP68CbDZL0npMvdCOa7u8U7lP Xsa5TlahF5tvdSelhTmTAZYdejauw8Nu4pafjqMNU37GD4m5MC7g/Ukrq CkagWE/kt2d+R7/V3FNnqu9YKQtEpMbvt/doVtv9lLPm2ZYx7MaUgaffe c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C+AgCkOOFV/5ldJa1dgxtUaQaDHbpjAQmBeoV5AhyBFzgUAQEBAQEBAX8LhCMBAQEEIxFDDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwiIJg2wQJRlAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EihU6Ee4RAGhYiBoJjL4EUBYxviFIBhQWJN0aDbJRuJoN/cQGBR4EFAQEB X-IronPort-AV: E=Sophos;i="5.17,429,1437436800"; d="scan'208";a="27921859" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 29 Aug 2015 04:45:26 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t7T4jQVj016394 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 29 Aug 2015 04:45:26 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 28 Aug 2015 23:45:25 -0500 Received: from xhc-aln-x06.cisco.com (173.36.12.80) by xch-aln-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 28 Aug 2015 23:45:25 -0500 Received: from xmb-rcd-x10.cisco.com ([169.254.15.53]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0248.002; Fri, 28 Aug 2015 23:45:25 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-reddy-tram-token-metadata-00.txt Thread-Index: AQHQ4hSgxVbhACOMZ0CMqS4EyMF9YZ4iZptg Date: Sat, 29 Aug 2015 04:45:24 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478C9ED0@xmb-rcd-x10.cisco.com> References: <20150829043855.4377.59029.idtracker@ietfa.amsl.com> In-Reply-To: <20150829043855.4377.59029.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.34.78] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [tram] FW: New Version Notification for draft-reddy-tram-token-metadata-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 04:45:51 -0000 VGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIG1lY2hhbmlzbSBmb3IgdGhlIFRVUk4gc2VydmVyIHRv IGludHJvc3BlY3QgdGhlIGFjY2VzcyB0b2tlbiB0byByZXRyaWV2ZSBhbnkgcG9saWN5IHJlc3Ry aWN0aW9ucyBpbXBvc2VkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBvbiB0aGUgVFVSTiBz ZXJ2ZXIgcmVzb3VyY2VzIGFzc2lnbmVkIHRvIHRoZSBjbGllbnQuIENvbW1lbnRzIGFuZCBzdWdn ZXN0aW9ucyBhcmUgd2VsY29tZS4NCg0KLVRpcnUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQpTZW50OiBTYXR1cmRheSwgQXVndXN0IDI5LCAyMDE1IDEwOjA5IEFNDQpU bzogQnJhbmRvbiBXaWxsaWFtczsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgRGFuIFdp bmcgKGR3aW5nKTsgRGFuIFdpbmcgKGR3aW5nKTsgU3VoYXMgTmFuZGFrdW1hciAoc25hbmRha3Up OyBTdWhhcyBOYW5kYWt1bWFyIChzbmFuZGFrdSk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRk eSk7IEJyYW5kb24gV2lsbGlhbXMNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtcmVkZHktdHJhbS10b2tlbi1tZXRhZGF0YS0wMC50eHQNCg0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtcmVkZHktdHJhbS10b2tlbi1tZXRhZGF0YS0wMC50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGlydW1hbGVzd2FyIFJlZGR5IGFuZCBwb3N0 ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1yZWRkeS10cmFtLXRv a2VuLW1ldGFkYXRhDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJTWV0YWRhdGEgZGlzY292ZXJ5IGZv ciB0aGlyZCBwYXJ0eSBhdXRob3JpemVkIFRVUk4gc2Vzc2lvbg0KRG9jdW1lbnQgZGF0ZToJMjAx NS0wOC0yOA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJOQ0KVVJMOiAg ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRk eS10cmFtLXRva2VuLW1ldGFkYXRhLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlZGR5LXRyYW0tdG9rZW4tbWV0YWRhdGEvDQpI dG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5LXRy YW0tdG9rZW4tbWV0YWRhdGEtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoZSBvcGVyYXRvciBvZiB0 aGUgVFVSTiBzZXJ2ZXIgbWlnaHQgd2FudCB0byBoYXZlIGZpbmUgZ3JhaW5lZA0KICAgY29udHJv bCBvbiB0aGUgY2xpZW50cyB1c2FnZSBvZiB0aGUgc2VydmVyIHJlc291cmNlcyBmb3IgcHJvdmlk aW5nDQogICBmZWF0dXJlcyBzdWNoIGFzIGxpbWl0aW5nIHRoZSBiYW5kd2l0aCB1c2FnZSwgbnVt YmVyIG9mIGFsbG9jYXRpb25zDQogICBhbmQgc28gb24uICBUaGlzIGRvY3VtZW50IHByb3Bvc2Vz IGEgZ2VuZXJpYyBtZWNoYW5pc20gZm9yIHRoZQ0KICAgb3BlcmF0b3IgdG8gaW50cm9zcGVjdCB0 aGUgYWNjZXNzIHRva2VuIHRvIHJldHJpZXZlIGFueSBwb2xpY3kNCiAgIHJlc3RyaWN0aW9ucyBp bXBvc2VkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBvbiB0aGUgVFVSTiBzZXJ2ZXINCiAg IHJlc291cmNlcyBhc3NpZ25lZCB0byB0aGUgY2xpZW50Lg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0K From nobody Mon Aug 31 06:09:45 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7022C1A89A7 for ; Mon, 31 Aug 2015 06:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_019c6n-S-E for ; Mon, 31 Aug 2015 06:09:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047051B3C8F for ; Mon, 31 Aug 2015 06:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2804; q=dns/txt; s=iport; t=1441026579; x=1442236179; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=+Z9azeA8S6S7tBtjVRny2axRPppgzOzAeSVmNNZb7aA=; b=H+b4HtLzhZWRv8YkvtwMiT7ScB/3K/Yo6UssecpkoDIhhkThhM567jDR 1xQr1DAb/rQnX6fJJcUr/eHfw3DoYRBSLx2d2sjU0kQyPffXL7X2PLWye 2oMIo5oEYYhV5E6bYr0hSx4IxUqhq9yv2CkI/CZS8gH//P9QSfkHHU7Pk A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B5AgBVUeRV/4ENJK1egxtUaQa+IAEJgW0MhXkCgSM4FAEBAQEBAQGBCoQjAQEBBAEBATc0CQ4GAQgRAwEBAR8JLgsUCAEKBAESiC4NxA0BAQEBAQEBAQEBAQEBAQEBAQEBARiGcYR6hEBYhCYFjG+IUgGFBodtgUpGg2yUbiaCQYE+cQGBR4EFAQEB X-IronPort-AV: E=Sophos;i="5.17,440,1437436800"; d="scan'208";a="24949383" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP; 31 Aug 2015 13:09:38 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t7VD9chN012400 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 31 Aug 2015 13:09:38 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 31 Aug 2015 08:09:37 -0500 Received: from xhc-aln-x05.cisco.com (173.36.12.79) by xch-aln-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 31 Aug 2015 08:09:37 -0500 Received: from xmb-aln-x05.cisco.com ([169.254.11.9]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0248.002; Mon, 31 Aug 2015 08:09:35 -0500 From: "Ram Mohan R (rmohanr)" To: "Tirumaleswar Reddy (tireddy)" , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-token-metadata-00.txt Thread-Index: AQHQ4+5FDuKKuqCjDkWQIHZecHYg9g== Date: Mon, 31 Aug 2015 13:09:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [64.101.220.150] Content-Type: text/plain; charset="us-ascii" Content-ID: <863F338DC8EBA148A637637A74B1E30A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-token-metadata-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 13:09:44 -0000 I took a quick look at the document and it looks good. One comment at this time. -A diagram showing the sequence of messages between TURN Client, TURN server and Introspection endpoint ( Authorization Server) will be useful. For example, the flow can show TURN client can use RFC 7635 and this works together. Regards, Ram -----Original Message----- From: tram on behalf of "Tirumaleswar Reddy (tireddy)" Date: Saturday, 29 August 2015 10:15 am To: "tram@ietf.org" Subject: [tram] FW: New Version Notification for draft-reddy-tram-token-metadata-00.txt >This document proposes a mechanism for the TURN server to introspect the >access token to retrieve any policy restrictions imposed by the >authorization server on the TURN server resources assigned to the client. >Comments and suggestions are welcome. > >-Tiru > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Saturday, August 29, 2015 10:09 AM >To: Brandon Williams; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Dan >Wing (dwing); Suhas Nandakumar (snandaku); Suhas Nandakumar (snandaku); >Tirumaleswar Reddy (tireddy); Brandon Williams >Subject: New Version Notification for >draft-reddy-tram-token-metadata-00.txt > > >A new version of I-D, draft-reddy-tram-token-metadata-00.txt >has been successfully submitted by Tirumaleswar Reddy and posted to the >IETF repository. > >Name: draft-reddy-tram-token-metadata >Revision: 00 >Title: Metadata discovery for third party authorized TURN session >Document date: 2015-08-28 >Group: Individual Submission >Pages: 9 >URL: =20 >https://www.ietf.org/internet-drafts/draft-reddy-tram-token-metadata-00.tx >t >Status: =20 >https://datatracker.ietf.org/doc/draft-reddy-tram-token-metadata/ >Htmlized: =20 >https://tools.ietf.org/html/draft-reddy-tram-token-metadata-00 > > >Abstract: > The operator of the TURN server might want to have fine grained > control on the clients usage of the server resources for providing > features such as limiting the bandwith usage, number of allocations > and so on. This document proposes a generic mechanism for the > operator to introspect the access token to retrieve any policy > restrictions imposed by the authorization server on the TURN server > resources assigned to the client. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Mon Aug 31 08:39:11 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF581B5058 for ; Mon, 31 Aug 2015 08:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28pZKx-897mN for ; Mon, 31 Aug 2015 08:39:04 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E59E1B2F1E for ; Mon, 31 Aug 2015 08:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3250; q=dns/txt; s=iport; t=1441035513; x=1442245113; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8uEBpgAnntRtc8jZz70hRMjzZbGELnvWT8kGOT4QUSw=; b=V+egoUuP9FMewt2H2PZIMYgNTOSmcyMN99l6cnC5bCfUsQSWMZ7IOlzS B7Hp+TFPF6EGZtn196OuwrT24n3FKDZ13z65I1Gei5Dvi3sfl4HhlLcUO IIiuQfIVzp7otxqMZDh6cefb4cCAfYS0BQcx9gXgq6A1cJyTLzHGoHZBl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B5AgD/c+RV/4gNJK1dgxtUaQa+IQEJgW0KhXsCgSg4FAEBAQEBAQGBCoQjAQEBBAEBATc0CQ4EAgEIEQMBAQELFAkHJwsUCAEIAgQBEgiIJg3GGwEBAQEBAQEBAQEBAQEBAQEBAQEBAReGcIR7hEAaOAaDEoEUBYxviFIBhQaJN0aDbJRuJoJBgT5xgUiBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,441,1437436800"; d="scan'208";a="183641340" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP; 31 Aug 2015 15:38:32 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t7VFcWDi031195 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 31 Aug 2015 15:38:32 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 31 Aug 2015 10:38:31 -0500 Received: from xhc-aln-x11.cisco.com (173.36.12.85) by xch-aln-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 31 Aug 2015 10:38:31 -0500 Received: from xmb-rcd-x10.cisco.com ([169.254.15.53]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0248.002; Mon, 31 Aug 2015 10:38:31 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Ram Mohan R (rmohanr)" , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-token-metadata-00.txt Thread-Index: AQHQ4+5FDuKKuqCjDkWQIHZecHYg9p4mPSTg Date: Mon, 31 Aug 2015 15:38:30 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478CA5EE@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-token-metadata-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 15:39:10 -0000 > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Monday, August 31, 2015 6:40 PM > To: Tirumaleswar Reddy (tireddy); tram@ietf.org > Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-tok= en- > metadata-00.txt >=20 > I took a quick look at the document and it looks good. One comment at thi= s > time. >=20 > -A diagram showing the sequence of messages between TURN Client, TURN > server and Introspection endpoint ( Authorization Server) will be useful. > For example, the flow can show TURN client can use RFC 7635 and this work= s > together. Okay, will add diagram in the next revision. Cheers, -Tiru >=20 > Regards, >=20 > Ram >=20 > -----Original Message----- > From: tram on behalf of "Tirumaleswar Reddy > (tireddy)" > Date: Saturday, 29 August 2015 10:15 am > To: "tram@ietf.org" > Subject: [tram] FW: New Version Notification for draft-reddy-tram-token- > metadata-00.txt >=20 > >This document proposes a mechanism for the TURN server to introspect > >the access token to retrieve any policy restrictions imposed by the > >authorization server on the TURN server resources assigned to the client= . > >Comments and suggestions are welcome. > > > >-Tiru > > > >-----Original Message----- > >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >Sent: Saturday, August 29, 2015 10:09 AM > >To: Brandon Williams; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); > >Dan Wing (dwing); Suhas Nandakumar (snandaku); Suhas Nandakumar > >(snandaku); Tirumaleswar Reddy (tireddy); Brandon Williams > >Subject: New Version Notification for > >draft-reddy-tram-token-metadata-00.txt > > > > > >A new version of I-D, draft-reddy-tram-token-metadata-00.txt > >has been successfully submitted by Tirumaleswar Reddy and posted to the > >IETF repository. > > > >Name: draft-reddy-tram-token-metadata > >Revision: 00 > >Title: Metadata discovery for third party authorized TURN session > >Document date: 2015-08-28 > >Group: Individual Submission > >Pages: 9 > >URL: > >https://www.ietf.org/internet-drafts/draft-reddy-tram-token-metadata-00 > >.tx > >t > >Status: > >https://datatracker.ietf.org/doc/draft-reddy-tram-token-metadata/ > >Htmlized: > >https://tools.ietf.org/html/draft-reddy-tram-token-metadata-00 > > > > > >Abstract: > > The operator of the TURN server might want to have fine grained > > control on the clients usage of the server resources for providing > > features such as limiting the bandwith usage, number of allocations > > and so on. This document proposes a generic mechanism for the > > operator to introspect the access token to retrieve any policy > > restrictions imposed by the authorization server on the TURN server > > resources assigned to the client. > > > > > > > > > > > >Please note that it may take a couple of minutes from the time of > >submission until the htmlized version and diff are available at > >tools.ietf.org. > > > >The IETF Secretariat > > > >_______________________________________________ > >tram mailing list > >tram@ietf.org > >https://www.ietf.org/mailman/listinfo/tram From nobody Mon Aug 31 13:13:04 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D6A1B5EAB for ; Mon, 31 Aug 2015 13:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9MqfO0jCQ8j for ; Mon, 31 Aug 2015 13:12:50 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1FCF1B5EA8 for ; Mon, 31 Aug 2015 13:12:47 -0700 (PDT) Received: from KalleAC ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201508312212464346; Mon, 31 Aug 2015 22:12:46 +0200 From: "Karl Stahl" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Prashanth Patil \(praspati\)'" , References: <07fe01d0e17e$d2c85e60$78591b20$@stahl@intertex.se> <913383AAA69FF945B8F946018B75898A478C981E@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A478C981E@xmb-rcd-x10.cisco.com> Date: Mon, 31 Aug 2015 22:12:43 +0200 Message-ID: <000001d0e429$656b0950$30411bf0$@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D0E43A.28FDC460" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHQ3te5ncVDPQtDL06JLXh/TKKDdZ4hk8YAgAAF/tCABNvzMA== Content-Language: sv Archived-At: Cc: 'Bernard Aboba' Subject: Re: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 20:13:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D0E43A.28FDC460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 Even if your statement is correct =96 does it apply to this discovery of network provided TURN server draft? =20 The =93long-term credentials or third-party authorization=93 you are = mentioning are used to assure that only users of the web application (no other) consumes the TURN server resource. That is NOT a problem to solve in the this discovery draft. Here, the discovered TURN server is provided by = the network admin for the purpose of being used by the users of his network. = The TURN server resource is not available nor advertised to others, so it = should simply be used (This TURN server does NOT need protection against unauthorized usage). =20 Did you read the thread ending at: https://mailarchive.ietf.org/arch/msg/tram/W49pCoOHQu2mE-RxokMbq1FmpOg =20 OR DO YOU MEAN=85 that any of the discovery methods (which?) you are suggesting in the = draft have a security flaw (which)? Is it worse to send the (encrypted) = real-time traffic through the discovered TURN server than through the default = gateway? Then explain why and how any Authentication/Validation/Authorization, = (D)TLS or something else could help that and what it actually does and = resolves. =20 OR DO YOU MEAN =93the authentication talk=94 can/are creating a BETTER = trust level when sending real-time traffic through the discovered TURN server = than through the default gateway of the network? Then I still question = whether such improvement belongs to this draft (the purpose of the discovered = TURN server was to get real-time traffic firewall traversal or at better = quality) , but I am interested to understand how you think you can achieve this = and whether there are any bad consequences or limitations attached. =20 =20 Otherwise, as I have pointed out, simply clarify what this draft is = about, and remove the confusing parts. =20 /Karl =20 Fr=E5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Skickat: den 28 augusti 2015 18:42 Till: Karl Stahl ; Prashanth Patil (praspati) ; tram@ietf.org Kopia: 'Bernard Aboba' =C4mne: RE: [tram] FW: Review of = draft-ietf-tram-turn-server-discovery-04 =20 If TURN client and TURN server are not using long-term credentials or third-party authorization then (D)TLS is the only way to authenticate = the TURN server, and it also solves the problem of MIM attacker modifying = TURN messages, passive attacker deleting existing allocations etc. (D)TLS for TURN is already defined in RFC 5766 and RFC 7350. =20 -Tiru =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl Sent: Friday, August 28, 2015 4:17 PM To: Prashanth Patil (praspati); tram@ietf.org =20 Cc: 'Bernard Aboba' Subject: Re: [tram] FW: Review of = draft-ietf-tram-turn-server-discovery-04 =20 Hi Prashanth, =20 What you propose below is in no way acceptable, and adds to, rather than remedies the confusion this draft is introducing in its current form. =20 Please understand that: =20 1) Checking the validity of a certificate does not in itself or automatically help =93Security and privacy are important = considerations=94 as you state in your answer in the previous email. The security improvement = we get by accessing a website with https rather than http is (in addition = to the encryption) ONLY that the user can be sure of that when he surfs to www.goodcompany.com , he can be sure that = what he gets in his browser actually comes from the owner of the = goodcompany.com domain name. =20 2) In the context of WebRTC usage, you do not achieve anything by = checking a certificate for a discovered TURN server. The validation in itself = does not guarantee anything about whether the TURN server is good or bad or = evil. Further, the certificate for the TURN server will not even be presented = to the user to give him the (impossible) task of judging whether to trust a transport, based on the domain name validation (if that is the thought behind introducing this).=20 =20 3) If you don=92t have another purpose with this draft than (copied from = the previous email): =93The purpose of discovery of a network provided TURN server is to find = a TURN server offered by a network provider or a network admin, to be used = for real-time traffic by the users on that network segment.=94=20 please also understand (copied from the previous email): =93An advertised network provided TURN server, shall simply be = interpreted as an advice to use the TURN server path for real-time traffic, instead of using the default gateway path. The level of trust is the same for both paths (since both the default gateway and the TURN server are offered = and arranged by the network provider). A sealed configuration (as outlined = in draft-ietf-rtcweb-return) can be arranged by the network provider by blocking STUN packets in the default gateway.=94 It not up to this discovery draft to specify or to =93try to invent=94 = higher trust levels.=20 =20 And it must not be up to this draft to recommend about the transport = (you are here suggesting (D)TLS), and especially not with a motivation that = does not achieve anything positive in the context of WebRTC usage. For = WebRTC, there are the RTCWEB WG=92s TRANSPORT, RETURN and possible other = documents where transports are being specified. =20 /Karl =20 PS For further details, see previous email on the =93last call on this = draft: draft-ietf-tram-turn-server-discovery-03=94 thread=20 =20 Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil = (praspati) Skickat: den 25 augusti 2015 03:45 Till: Bernard Aboba; tram@ietf.org =20 =C4mne: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04 =20 Hi Bernard, =20 On 7/30/15, 11:23 AM, "tram on behalf of Bernard Aboba" on behalf of bernard.aboba@gmail.com > wrote: =20 1. Overall, in reading this document it was not clear to me how it was intended to be applied to WebRTC scenarios where a TURN server is configured in = the JS.=20 =20 * Does TURN server discovery apply in this case, or is the JS-specified = TURN server considered "manual TURN configuration" ?=20 =20 Yes, JS-specified TURN server should be considered as = auto-configuration. We=92ll update the draft accordingly. =20 * Where IdP is used, is the local IdP identity considered to consitute a "domain name" per Section 4.1.2? =20 =20 Is there a need to make this explicit? The text in the draft is intentionally generic to leave the decision up to the application: "For a TURN client with an understanding of the protocol mechanics of calling applications, the client may wish to extract the domain name = from its own identity" =20 2. In scenarios where TURN Server discovery does apply, what mechanisms = are to be used to authenticate or authorize the discovered TURN Servers(s)? Using a configured domain name seems like a potentially viable approach, = but there are scenarios where that might not be configured, or might not be secure (e.g. if the domain name were obtained from unauthenticated DHCP). =20 =20 We plan to add the following, does it address some of your concerns: TURN client can use the following techniques to validate a TURN server: =20 o For certificate-based authentication, this includes a pre-populated trust anchor store [rfc6024] that allows = the the TURN client to perform path validation for the server = certificate obtained during the (D)TLS handshake. The client MUST use the rules and guidelines given in section 6 of [RFC6125] to validate the TURN server identity. =20 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), the configured list of TURN servers can contain the Subject Public Key Info (SPKI) fingerprint of the TURN servers. The public = key is used for the same reasons HTTP pinning [RFC7469] uses the public = key. =20 o For raw public key-based authentication as defined in [RFC7250], = this includes either the TURN server's public key or the hash of the server's public key. =20 Using the browser's configured trust anchor(s) doesn't seem like a good idea, given that it would only be as secure as the least-secure trust anchor.=20 =20 Isn=92t that true with any server the client tries to validate using certificates? =20 Specific comments:=20 =20 Section 3 =20 1. Local Configuration : Local or manual TURN configuration (i.e., TURN servers configured at the system level) should be tried first, as it may be an explicit preferred choice of a user. =20 [BA] Would TURN servers specified within a WebRTC JS application be considered "local or manual" in this context?=20 =20 Also, shouldn't a configured domain name (Section 4.1.2) be considered = part of "local TURN configuration"?=20 =20 Yes, configured domain name can be considered as local or auto-configuration. =20 IMHO, the configured domain name not only enables discovery as indicated in Section 4.2, but also provides a mechanism for validation of the TURN server discovered by other methods. =20 =20 Correct. We=92ll update the draft to highlight this point. =20 The document does not prescribe a strict order that a client must follow for discovery. An implementation may choose to perform steps 2,3 and 4 in parallel for discovery OR choose to follow any desired order and stop the discovery procedure if a mechanism succeeds. =20 [BA] I am not sure I buy this. It is already stated that "local or = manual" configuration should be tried first, and I would considered a configured domain name to be part of this, which would imply attempting 2 first if = that exists. =20 =20 Good point. A client should be able to perform discovery on all in = parallel (or in any order of choice), including manual/auto configuration. =20 Section 9.2 =20 For mDNS, in addition to what has been described above, a principal security threat is a security threat inherent to IP multicast routing and any application that runs on it. A rogue system can advertise that it is a TURN server. Discovery of such rogue systems as TURN servers, in itself, is not a security threat if there is a means for the TURN client to authenticate and authorize the discovered TURN servers. =20 [BA] In scenarios in which mDNS would be used, there typically will not = be a means for the TURN client to authentication and authorize the discovered TURN server. For example, a home router with a built-in TURN server is not likely to have a certificate chaining to a trust anchor. =20 If discovered in a local n/w, a client can be explicitly configured with = the fingerprint of the server. =20 Also, the mDNS is not compatible with DNSSEC (e.g. there is no signer for the = .local domain). =20 =20 Same as above. A client, if configured with a fingerprint, could = validate the server. =20 Section 9.3 =20 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. =20 [BA] This seems like a crude tool at best. If the goal is to provide privacy, wouldn't use of encryption make more sense? This could include DNS = privacy, encryption of TURN traffic, etc.=20 =20 TURN encryption wouldn=92t be possible because the client is not aware = of the TURN server it is trying to connect. The above is only a recommendation = if a client is concerned with anycast going out of a desired boundary. =20 -Prashanth ------=_NextPart_000_0001_01D0E43A.28FDC460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Even if your statement is correct – = does it apply to this discovery of network provided TURN server = draft?

 

The “long-term credentials or third-party authorization“ you are mentioning are used to = assure that only users of the web application (no other) consumes the = TURN server resource. That is NOT a problem to solve in the this = discovery draft. Here, the discovered TURN server is provided by the = network admin for the purpose of being used by the users of his network. = The TURN server resource is not available nor advertised to others, so = it should simply be used (This TURN server does NOT need protection = against unauthorized usage).

 

Did you read the thread ending at: https://mailarchive.ietf.org/arch/msg/tram/W49pCoOHQu2mE-RxokMbq1F= mpOg

 

OR DO YOU = MEAN…

that any of the discovery methods (which?) = you are suggesting in the draft have a security flaw (which)? Is it = worse to send the (encrypted) real-time traffic through the discovered = TURN server than through the default gateway? Then explain why and how = any Authentication/Validation/Authorization, (D)TLS or something else = could help that and what it actually does and = resolves.

 

OR DO YOU MEAN “the authentication = talk” can/are creating a BETTER trust level when sending real-time = traffic through the discovered TURN server than through the default = gateway of the network? Then I still question whether such improvement = belongs to this draft (the purpose of the discovered TURN server was to = get real-time traffic firewall traversal or at better quality) , but I = am interested to understand how you think you can achieve this and = whether there are any bad consequences or limitations attached. = =A0=A0

 

Otherwise, as I have pointed out, simply = clarify what this draft is about, and remove the confusing = parts.

 

/Karl

 

Fr=E5n: = Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] =
Skickat: den 28 augusti 2015 18:42
Till: Karl Stahl = <karl.stahl@intertex.se>; Prashanth Patil (praspati) = <praspati@cisco.com>; tram@ietf.org
Kopia: 'Bernard = Aboba' <bernard.aboba@gmail.com>
=C4mne: RE: [tram] FW: = Review of = draft-ietf-tram-turn-server-discovery-04

 

If TURN client and TURN server are not using long-term credentials or = third-party authorization then (D)TLS is the only way to authenticate = the TURN server, and it also solves the problem of MIM attacker = modifying TURN messages, passive attacker deleting existing allocations = etc. (D)TLS for TURN is already defined in RFC 5766 and RFC = 7350.

 

-Tiru

 

From: tram [mailto:tram-bounces@ietf.org] = On Behalf Of Karl Stahl
Sent: Friday, August 28, 2015 = 4:17 PM
To: Prashanth Patil (praspati); tram@ietf.org
Cc: 'Bernard = Aboba'
Subject: Re: [tram] FW: Review of = draft-ietf-tram-turn-server-discovery-04

 

Hi = Prashanth,

 

What= you propose below is in no way acceptable, and adds to, rather than = remedies the confusion this draft is introducing in its current = form.

 

Plea= se understand that:

 

1) = Checking the validity of a certificate does not in itself or = automatically help “Security and privacy are = important considerationsR= 21; as you state in your answer in the previous email. The security = improvement we get by accessing a website with https rather than http is = (in addition to the encryption) ONLY that the user can be sure of that = when he surfs to www.goodcompany.com, he can be = sure that what he gets in his browser actually comes from the owner of = the goodcompany.com domain name.

 

2) =  In the context of WebRTC usage, you do not achieve anything by = checking a certificate for a discovered TURN server. The validation in = itself does not guarantee anything about whether the TURN server is good = or bad or evil. Further, the certificate for the TURN server will not = even be presented to the user to give him the (impossible) task of = judging whether to trust a transport, based on the domain name = validation (if that is the thought behind introducing this). =

 

3) = If you don’t have another purpose with this draft than (copied = from the previous email):

“The = purpose of discovery of a network provided TURN server is to find a TURN = server offered by a network provider or a network admin, to be used for = real-time traffic by the users on that network segment.” =

plea= se also understand (copied from the previous email):

“An = advertised network provided TURN server, shall simply be interpreted as = an advice to use the TURN server path for real-time traffic, instead of = using the default gateway path. The level of trust is the same for both = paths (since both the default gateway and the TURN server are offered = and arranged by the network provider). A sealed configuration (as = outlined in draft-ietf-rtcweb-return) can be arranged by the network = provider by blocking STUN packets in the default = gateway.”

It = not up to this discovery draft to specify or to “try to = invent” higher trust levels.

 

And = it must not be up to this draft to recommend about the transport (you = are here suggesting (D)TLS), and especially not with a motivation that = does not achieve anything positive in the context of WebRTC usage. For = WebRTC, there are the RTCWEB WG’s TRANSPORT, RETURN and possible = other documents where transports are being = specified.

 

/Kar= l

 

PS = For further details, see previous email on the “last call on this = draft: draft-ietf-tram-turn-server-discovery-03” thread =

 

Fr=E5n:= = tram [mailto:tram-bounces@ietf.org] = F=F6r Prashanth Patil (praspati)
Skickat: den 25 = augusti 2015 03:45
Till: Bernard Aboba; tram@ietf.org
=C4mne: [tram] = FW: Review of = draft-ietf-tram-turn-server-discovery-04

 

H= i Bernard,

<= o:p> 

O= n 7/30/15, 11:23 AM, "tram on behalf of Bernard Aboba" <tram-bounces@ietf.org on = behalf of bernard.aboba@gmail.com> = wrote:

<= o:p> 

1= . Overall, in reading this document it was not clear to me how it was = intended

t= o be applied to WebRTC scenarios where a TURN server is configured in = the JS. 

<= o:p> 

*= Does TURN server discovery apply in this case, or is the JS-specified = TURN server considered "manual TURN configuration" = ? 

<= o:p> 

Y= es, JS-specified TURN server should be considered as auto-configuration. = We’ll update the draft = accordingly.

<= o:p> 

*= Where IdP is used, is the local IdP identity considered to consitute a = "domain name" per Section 4.1.2? =  

<= o:p> 

I= s there a need to make this explicit? The text in the draft is = intentionally generic to leave the decision up to the = application:

"For a TURN client with an understanding of the =
protocol mechanics of calling applications, the client may wish to =
extract the domain name from its own =
identity"

<= o:p> 

2= . In scenarios where TURN Server discovery does apply, what mechanisms = are to be used to authenticate or authorize the discovered TURN = Servers(s)?  Using a configured domain name seems like a = potentially viable approach, but there are scenarios where that might = not be configured, or might not be = secure

(= e.g. if the domain name were obtained from unauthenticated DHCP). =  

<= o:p> 

W= e plan to add the following, does it address some of your = concerns:

TURN client can use the following techniques to = validate a TURN server:

 

   o  For = certificate-based authentication, this

      includes a = pre-populated trust anchor store [rfc6024] that allows = the

      the TURN = client to perform path validation for the server certificate = obtained

      during the (D)TLS = handshake. The client MUST use the rules and guidelines given in section = 6 of

      [RFC6125] to = validate the TURN server identity.

 

   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),

      the configured list = of TURN servers can contain the Subject

      Public Key Info = (SPKI) fingerprint of the TURN servers. The public key = is

      used for the same = reasons HTTP pinning [RFC7469] uses the public = key.

 

   o  For = raw public key-based authentication as defined in [RFC7250], = this

      includes either the = TURN server's public key or the hash of the

      server's public = key.

<= o:p> 

U= sing the browser's configured trust anchor(s) doesn't seem like a good = idea, given that it would only be as secure as the least-secure trust = anchor. 

<= blockquote = style=3D'margin-left:30.0pt;margin-top:5.0pt;margin-right:0cm;margin-bott= om:5.0pt'>

<= o:p> 

I= sn’t that true with any server the client tries to validate using = certificates?

<= o:p> 

S= pecific comments: 

<= o:p> 

S= ection 3

<= o:p> 

&= nbsp;  1.  Local Configuration : Local or manual TURN = configuration (i.e.,

&= nbsp;      TURN servers configured at the system level) = should be tried

&= nbsp;      first, as it may be an explicit preferred = choice of a user.

<= o:p> 

[= BA] Would TURN servers specified within a WebRTC JS application be = considered "local or manual" in this = context? 

=

<= o:p> 

A= lso, shouldn't a configured domain name (Section 4.1.2) be considered = part of "local TURN = configuration"? 

=

<= o:p> 

Y= es, configured domain name can be considered as local or = auto-configuration.

<= o:p> 

I= MHO, the configured domain name not only enables discovery as = indicated

i= n Section 4.2, but also provides a mechanism for validation of = the

T= URN server discovered by other methods. =   

<= o:p> 

C= orrect. We’ll update the draft to highlight this = point.

<= o:p> 

&= nbsp;  The document does not prescribe a strict order that a client = must

&= nbsp;  follow for discovery.  An implementation may choose to = perform steps

&= nbsp;  2,3 and 4 in parallel for discovery OR choose to follow any = desired

&= nbsp;  order and stop the discovery procedure if a mechanism = succeeds.

<= o:p> 

[= BA] I am not sure I buy this.  It is already stated that = "local or manual" configuration should be tried first, and I = would considered a configured domain name to be part of this, which = would imply attempting 2 first if that exists. =   

<= o:p> 

G= ood point. A client should be able to perform discovery on all in = parallel (or in any order of choice), including manual/auto = configuration.

<= o:p> 

S= ection 9.2

<= o:p> 

&= nbsp;  For mDNS, in addition to what has been described above, a = principal

&= nbsp;  security threat is a security threat inherent to IP = multicast routing

&= nbsp;  and any application that runs on it.  A rogue system = can advertise

&= nbsp;  that it is a TURN server.  Discovery of such rogue = systems as TURN

&= nbsp;  servers, in itself, is not a security threat if there is a = means for

&= nbsp;  the TURN client to authenticate and authorize the discovered = TURN

&= nbsp;  servers.

<= o:p> 

[= BA] In scenarios in which mDNS would be used, there typically will not = be a

m= eans for the TURN client to authentication and authorize the = discovered

T= URN server. For example, a home router with a built-in TURN server = is

n= ot likely to have a certificate chaining to a trust = anchor.

<= o:p> 

I= f discovered in a local n/w, a client can be explicitly configured with = the fingerprint of the server.

<= o:p> 

&= nbsp; Also, the

m= DNS is not compatible with DNSSEC (e.g. there is no signer for the = .local

d= omain). =  

<= o:p> 

S= ame as above. A client, if configured with a fingerprint, could validate = the server.

<= o:p> 

S= ection 9.3

<= o:p> 

&= nbsp;  Sensitive clients that do not wish to leak information about = their

&= nbsp;  presence can set an IP TTL on their TURN requests that = limits how far

&= nbsp;  they can travel into the public = Internet.

<= o:p> 

[= BA] This seems like a crude tool at best.  If the goal is to = provide privacy,

w= ouldn't use of encryption make more sense?  This could include DNS = privacy,

e= ncryption of TURN traffic, = etc. 

<= o:p> 

T= URN encryption wouldn’t be possible because the client is not = aware of the TURN server it is trying to connect. The above is only a = recommendation if a client is concerned with anycast going out of a = desired boundary.

<= o:p> 

-= Prashanth

------=_NextPart_000_0001_01D0E43A.28FDC460--