I agree with the changes.

Thanks !

Oleg

On Tue, Sep 2, 2014 at 5:33 AM, Prashanth Patil (praspati) <pras= pati@cisco.com> wrote:

Hi Oleg,

Please see inline..=C2=A0

From: Oleg Moskalenko <mom040267@gmail.com&g= t;
Date: Monday, September 1, 2014 1:0= 2 PM
To: "Tirumaleswar Reddy (tired= dy)" <tiredd= y@cisco.com>
Cc: "oauth-ext-review@ietf.org" &= lt;oauth-ext= -review@ietf.org>, "Hannes.Tschofenig@gmx.net" <Hannes.= Tschofenig@gmx.net>, "tram@ietf.org" <tram@ietf.org>
Subject: Re: [tram] I-D Action: dra= ft-ietf-tram-turn-third-party-authz-02.txt

I have more comments on the document:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Section 6.2. ACCESS-TOKEN

The token is structured as follows:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ushort key_le= ngth;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque mac_ke= y[key_length];
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque timest= amp[8];
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0long =C2=A0 l= ifetime;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} encrypted_block;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque mac[mac_length];
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} token;
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I'd suggest the following:

1) ushort and long are values of unknown length. I understand that the auth= ors meant "2-bytes unsigned integer" and "4-bytes integer&qu= ot; but it is true only for 32-bits Unixes (and even for them it is not 100= % true). Use the exact POSIX-style type names with definite size - like uint16_t and uint32_t. Or just say that it is a 2-bytes and 4-= bytes unsigned integers.

PRA: Yes, we've updated with uintN_t wherever applicable.

2) The lifetime cannot be negative, so it must be an unsigned value.

PRA: Yes.

3) It is worth mentioning that all numbers are in network byte order.

PRA: Sure.

4) The timestamp definition is unnecessary complex. Why would we need anyth= ing else than seconds since 1970 ? That's not a realtime milliseconds-p= recision value.

PRA: A lot of specifications define timestamp this way. See=C2=A0http://tools.ietf.org/html/rfc3971#section-5.3.1. Also,=C2=A0linux=C2=A0gettimeofday() function gets the current time, expressed in seconds and=C2=A0microseconds since midnight (0 hour), January 1, 1970 UTC (http://linux= .die.net/man/2/gettimeofday)=C2=A0=E2=80=94=C2=A0making things easier for developers.

I'd re-wrote the whole structure as:

=C2=A0struct {

=C2=A0 =C2=A0 struct {

=C2=A0 =C2=A0 =C2=A0=C2=A0 uint16_t key_lengt= h;
=C2=A0 =C2=A0 =C2=A0=C2=A0 uint8_t mac_key[key_length];
=C2=A0 =C2=A0 =C2=A0=C2=A0 uint64_t timestamp;
=C2=A0 =C2=A0 =C2=A0=C2=A0 uint32_t lifetime;
=C2=A0 =C2=A0 } encrypted_block;
=C2=A0 =C2=A0 uint8_t mac[mac_length];
=C2=A0} token;

5) I did not get the exact token encryption p= rocedure. I think that I understand what was the intended procedure but the= wording is just not clear and inaccurate. It says that "The token MUS= T be encoded as defined in = Section=C2=A04 of [RFC4648] and then encrypted using the symmetric long= -term key established between the resource server and the authorization ser= ver,". Why we need Base64 here ?

PRA: This is to ensure that data remains intact without mod= ification during transport. It is common practice to encode binary data in = ASCII string format when sending over HTTP.

What exactly has to be base64-processed here (the encrypted_block befo= re the encryption) ?

PRA: The entire token i.e. 'encrypted_block' and th= e 'mac' is to be base64 encoded.

The current wording is impossible because the whole structure is the t= oken. So you cannot refer to the encrypted portion as a token per se. Pleas= e clarify and put more detailed steps what exactly has to be processed and = how. And, may be, it all has to be Base64-ed AFTER the encryption and signing ? (current wording suggest t= o base64 the data BEFORE the encryption).

PRA: You're right, the current wording is quite confusi= ng. Please see attached diffs for updated text. Let us know if the updates = are fine.

-Prashanth

Thanks !
Oleg

On Wed, Aug 27, 2014 at 3:37 AM, Tirumaleswar Re= ddy (tireddy) <tireddy@cisco.com> wrote:

This version addresses comments from Hannes and Oleg.

-Tiru

> -----Original Message-----
> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Wednesday, August 27, 2014 3:19 PM
> To: i-d-ann= ounce@ietf.org
> Cc: tram@ietf.org
> Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.= txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>=C2=A0 This draft is a work item of the TURN Revised and Modernized Wor= king
> Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: TURN Extension for Third Party Authorization
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Tirumaleswar Reddy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Prashanth Patil
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Ram Mohan Ravindranath
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Justin Uberti
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tram-turn-third-party-authz-02.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 16
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2014-08-27
>
> Abstract:
>=C2=A0 =C2=A0 This document proposes the use of OAuth to obtain and val= idate
>=C2=A0 =C2=A0 ephemeral tokens that can be used for TURN authentication= .=C2=A0 The usage
>=C2=A0 =C2=A0 of ephemeral tokens ensure that access to a TURN server c= an be
>=C2=A0 =C2=A0 controlled even if the tokens are compromised.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-02 >
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-third-party-authz-0= 2
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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

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

--f46d04428f16befc5b0502178205-- From nobody Tue Sep 2 12:14:04 2014 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 DF3531A0687 for ; Tue, 2 Sep 2014 12:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 FDG_FQgaYUoM for ; Tue, 2 Sep 2014 12:13:52 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 59C281A0673 for ; Tue, 2 Sep 2014 12:13:51 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DF95B28654; Tue, 2 Sep 2014 19:13:50 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id CC4582863F; Tue, 2 Sep 2014 19:13:50 +0000 (GMT) Received: from [172.28.115.172] (unknown [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id C35DE8004A; Tue, 2 Sep 2014 19:13:50 +0000 (GMT) Message-ID: <540616EE.70601@akamai.com> Date: Tue, 02 Sep 2014 15:13:50 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A2831E164@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2831E164@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/sq-GOmX9uhmYAWQ72LrybtByL98 Subject: Re: [tram] DNS-based relay selection, ALTERNATE-SERVER, and CHECK-ALTERNATE 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, 02 Sep 2014 19:13:58 -0000 See inline. On 08/31/2014 12:20 AM, Tirumaleswar Reddy (tireddy) wrote: > Hi Brandon, > > Please see inline > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Saturday, August 30, 2014 12:20 AM >> To: tram@ietf.org >> Subject: [tram] DNS-based relay selection, ALTERNATE-SERVER, and CHECK- >> ALTERNATE >> >> Hi all, >> >> In working through some relay server selection issues with a customer, we >> began discussing some corner cases related to server redirection via the TRY- >> ALTERNATE error response for allocate requests. We also discussed the >> impact on call setup time. I'd like to get some feedback from the list on the >> issue. >> >> Here's the basic problem. For a 3rd party TURN service that uses DNS to >> select from among multiple candidate relay servers, the location of the >> requester will often be determined using the source IP address of the DNS >> request. This will typically be the client's configured DNS server, not the client >> itself. Some public DNS servers support end-user identification in the DNS >> request, but it's not common and it requires a trust relationship between the >> client's DNS server and the relay provider's DNS server. > > Few questions > 1) Is trust relationship mandatory ? > I don't see any such discussion in http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-01#section-9 Section 9.3 of the edns I.D. refers to limits that could be imposed by an authoritative nameserver to protect against problems that can result when false information is provided in the edns-client-subnet option. Requiring a trust relationship is one method used to mitigate the risks associated with bad use of the option. > 2) Is end-user identification required or just detecting user's geolocation sufficient ? > The reason for the question is in CDN, identifying user's geolocation is sufficient for DNS based redirection (http://tools.ietf.org/html/rfc7336#section-2.1.1) End-user identification is not required. > 3)If Google/OpenDNS public DNS servers already support edns-client-subnet then what is the problem ? > Not everyone uses Google/OpenDNS :-) Many corporate environments require their users to use corporate nameservers, and these are often centrally located. >> There are two >> problems (at least) with this approach: >> >> 1. The DNS server is not geolocated with the client, so a bad relay >> is returned. >> >> 2. The DNS server is shared by multiple clients, making it more >> difficult to load balance the clients across multiple relays. >> >> Each of these can be resolved by sending a TRY-ALTERNATE error to the client >> on the allocate request, but this also has some issues, mostly relating to call >> setup time. > > Is it mandatory for the endpoints in the Enterprise network to use the 3rd party TURN service ? > I mean if firewall is configured to permit media sessions to any external peer only through the 3rd party TURN service, it may help if client only advertises relayed candidates. > This way ICE can be concluded faster. > I'm not sure how this question relates to the DNS problem. Also, I don't think the question is easy to answer. There are cases where use of the 3rd party relay could be optional, but there are also cases where its use is mandated by either the enterprise or the app vendor. >> >> Even one redirection can noticeably extend call setup delays. > > It will be useful if you can share the numbers on the call setup delay noticed. > I'll try to look into that. I'm not sure if I'll be able to do it, though, because the numbers come from a customer, not from us. The delays have to do with how the connectivity information is exchanged -- out-of-band via a centralized address registry. >> If the initial >> relay server selection is horrible (e.g. because the DNS server is located very >> far away from the client), this is worth the tradeoff, but in cases where the >> initial selection is suboptimal but still reasonable, it may be preferable to >> continue call setup using the initial relay server selection while waiting for the >> new relay allocation. > > So the idea is that the client will trigger ICE restart later using the new relay allocation. Yes. Something like that. > >> If there is some bad luck and the client receives multiple >> TRY-ALTERNATE error responses, the negative impact on call setup could be >> quite substantial. >> >> So, similar to the case described in the peer-specific redirection I.D., in some >> cases, it may be useful for the client to indicate to the server whether it >> would like performance-based redirection and also what type of response >> (success or error) it would like to receive in that case. >> What I am discussing with this customer is the idea of using the CHECK- >> ALTERNATE attribute defined in the peer-specific redirection draft for >> allocate requests. The value for the attribute would be one of: >> noredirect, senderror, or sendsuccess. This would allow the client to optimize >> call setup and also to mitigate the risk of redirection loops. >> >> Is anyone else interested in this idea? > > Yes, once you convince that there is a problem :) > I'm quite confident that there's a problem, but I'm not sure that it's a problem that's broadly applicable. --Brandon > Cheers, > -Tiru > >> I.e. would it be worthwhile for me to >> write up a short I.D.? Does anyone have ideas for a better way to handle the >> same problem that I should consider instead? >> >> Thanks, >> --Brandon >> >> PS: I know that at least the geolocation problem could be mostly resolved >> using anycast addresses. Experience suggests that anycast addresses are >> unsuitable for broad deployments with lots of POPs, frequently preventing >> deployments in some areas due to management burden. They usually >> require the use of fallback to unicast, and so become an optimization, not a >> full solution. >> >> -- >> Brandon Williams; Senior Principal Software Engineer Emerging Products >> Engineering; Akamai Technologies Inc. >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Sep 3 03:50:19 2014 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 73E181A0267 for ; Wed, 3 Sep 2014 03:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 VcudOh4N_0QX for ; Wed, 3 Sep 2014 03:50:16 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6661A02BC for ; Wed, 3 Sep 2014 03:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7417; q=dns/txt; s=iport; t=1409741416; x=1410951016; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=l0qFXf0TSs+cG7m5SdMz6Z2dpJMt//FRc09q7lvOB3M=; b=gRoCzb04NH0RKBkN3hJDD/TcofjEFVAAovRojn036Afp2dEZ71h5Z6eC 0mv42onq3/BXW0PiTCmonb1MozFF2tRnVa+tp3lR0sGy+hDzLFRoNGYO8 H5xqk+AhwnJmkaxwF/gtfWKDmFk0heBsoXCNt0b6x9+XNE6mhklTbTfhq U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAOvxBlStJV2d/2dsb2JhbABagw1TVwTIPgqHTAGBERZ3hAMBAQEDAQEBAQssKwkEEwQCAQgRBAEBAQoUCQcnCxQJCAEBBAESCBOIHwgNvScBF48cOAaDKYEdBYUFAooWghSELohYij6JBYNhbAEBgUaBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,456,1406592000"; d="scan'208";a="74516994" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 03 Sep 2014 10:50:15 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s83AoFME012914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Sep 2014 10:50:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 05:50:15 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] DNS-based relay selection, ALTERNATE-SERVER, and CHECK-ALTERNATE Thread-Index: Ac/E0vKrX2PzBon2S3OFvz2IGk0m3gCOP00AABVpKUA= Date: Wed, 3 Sep 2014 10:50:14 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28320AE6@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2831E164@xmb-rcd-x10.cisco.com> <540616EE.70601@akamai.com> In-Reply-To: <540616EE.70601@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/mrLG1BHkVNiUbjDtuMTfztXWwks Subject: Re: [tram] DNS-based relay selection, ALTERNATE-SERVER, and CHECK-ALTERNATE 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, 03 Sep 2014 10:50:18 -0000 > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Wednesday, September 03, 2014 12:44 AM > To: Tirumaleswar Reddy (tireddy); tram@ietf.org > Subject: Re: [tram] DNS-based relay selection, ALTERNATE-SERVER, and > CHECK-ALTERNATE >=20 > See inline. >=20 > On 08/31/2014 12:20 AM, Tirumaleswar Reddy (tireddy) wrote: > > Hi Brandon, > > > > Please see inline > > > >> -----Original Message----- > >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon > >> Williams > >> Sent: Saturday, August 30, 2014 12:20 AM > >> To: tram@ietf.org > >> Subject: [tram] DNS-based relay selection, ALTERNATE-SERVER, and > >> CHECK- ALTERNATE > >> > >> Hi all, > >> > >> In working through some relay server selection issues with a > >> customer, we began discussing some corner cases related to server > >> redirection via the TRY- ALTERNATE error response for allocate > >> requests. We also discussed the impact on call setup time. I'd like > >> to get some feedback from the list on the issue. > >> > >> Here's the basic problem. For a 3rd party TURN service that uses DNS > >> to select from among multiple candidate relay servers, the location > >> of the requester will often be determined using the source IP address > >> of the DNS request. This will typically be the client's configured > >> DNS server, not the client itself. Some public DNS servers support > >> end-user identification in the DNS request, but it's not common and > >> it requires a trust relationship between the client's DNS server and t= he > relay provider's DNS server. > > > > Few questions > > 1) Is trust relationship mandatory ? > > I don't see any such discussion in > > http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-01#sec > > tion-9 >=20 > Section 9.3 of the edns I.D. refers to limits that could be imposed by an > authoritative nameserver to protect against problems that can result when > false information is provided in the edns-client-subnet option. > Requiring a trust relationship is one method used to mitigate the risks > associated with bad use of the option. Okay. >=20 > > 2) Is end-user identification required or just detecting user's geoloca= tion > sufficient ? > > The reason for the question is in CDN, identifying user's geolocation > > is sufficient for DNS based redirection > > (http://tools.ietf.org/html/rfc7336#section-2.1.1) >=20 > End-user identification is not required. >=20 > > 3)If Google/OpenDNS public DNS servers already support edns-client- > subnet then what is the problem ? > > >=20 > Not everyone uses Google/OpenDNS :-) Many corporate environments > require their users to use corporate nameservers, and these are often > centrally located. Got it. It's not a problem in an Enterprise network that uses split tunneli= ng and split DNS.=20 >=20 > >> There are two > >> problems (at least) with this approach: > >> > >> 1. The DNS server is not geolocated with the client, so a bad rela= y > >> is returned. > >> > >> 2. The DNS server is shared by multiple clients, making it more > >> difficult to load balance the clients across multiple relays. > >> > >> Each of these can be resolved by sending a TRY-ALTERNATE error to the > >> client on the allocate request, but this also has some issues, mostly > >> relating to call setup time. > > > > Is it mandatory for the endpoints in the Enterprise network to use the = 3rd > party TURN service ? > > I mean if firewall is configured to permit media sessions to any extern= al > peer only through the 3rd party TURN service, it may help if client only > advertises relayed candidates. > > This way ICE can be concluded faster. > > >=20 > I'm not sure how this question relates to the DNS problem. Also, I don't = think > the question is easy to answer. There are cases where use of the 3rd part= y > relay could be optional, but there are also cases where its use is mandat= ed > by either the enterprise or the app vendor. Ok. >=20 > >> > >> Even one redirection can noticeably extend call setup delays. > > > > It will be useful if you can share the numbers on the call setup delay > noticed. > > >=20 > I'll try to look into that. I'm not sure if I'll be able to do it, > though, because the numbers come from a customer, not from us. The > delays have to do with how the connectivity information is exchanged -- > out-of-band via a centralized address registry. >=20 > >> If the initial > >> relay server selection is horrible (e.g. because the DNS server is loc= ated > very > >> far away from the client), this is worth the tradeoff, but in cases wh= ere the > >> initial selection is suboptimal but still reasonable, it may be prefer= able to > >> continue call setup using the initial relay server selection while wai= ting for > the > >> new relay allocation. > > > > So the idea is that the client will trigger ICE restart later using the= new relay > allocation. >=20 > Yes. Something like that. >=20 > > > >> If there is some bad luck and the client receives multiple > >> TRY-ALTERNATE error responses, the negative impact on call setup could > be > >> quite substantial. > >> > >> So, similar to the case described in the peer-specific redirection I.D= ., in > some > >> cases, it may be useful for the client to indicate to the server wheth= er it > >> would like performance-based redirection and also what type of respons= e > >> (success or error) it would like to receive in that case. > >> What I am discussing with this customer is the idea of using the CHECK= - > >> ALTERNATE attribute defined in the peer-specific redirection draft for > >> allocate requests. The value for the attribute would be one of: > >> noredirect, senderror, or sendsuccess. This would allow the client to > optimize > >> call setup and also to mitigate the risk of redirection loops. > >> > >> Is anyone else interested in this idea? > > > > Yes, once you convince that there is a problem :) > > >=20 > I'm quite confident that there's a problem, but I'm not sure that it's > a problem that's broadly applicable. Agreed that it's a problem. -Tiru >=20 > --Brandon >=20 > > Cheers, > > -Tiru > > > >> I.e. would it be worthwhile for me to > >> write up a short I.D.? Does anyone have ideas for a better way to hand= le > the > >> same problem that I should consider instead? > >> > >> Thanks, > >> --Brandon > >> > >> PS: I know that at least the geolocation problem could be mostly resol= ved > >> using anycast addresses. Experience suggests that anycast addresses ar= e > >> unsuitable for broad deployments with lots of POPs, frequently prevent= ing > >> deployments in some areas due to management burden. They usually > >> require the use of fallback to unicast, and so become an optimization,= not > a > >> full solution. > >> > >> -- > >> Brandon Williams; Senior Principal Software Engineer Emerging Products > >> Engineering; Akamai Technologies Inc. > >> > >> _______________________________________________ > >> tram mailing list > >> tram@ietf.org > >> https://www.ietf.org/mailman/listinfo/tram >=20 > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Sep 3 06:31:46 2014 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 6375D1A02D8; Wed, 3 Sep 2014 06:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 XjR4K58POu36; Wed, 3 Sep 2014 06:31:42 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 754FC1A02C1; Wed, 3 Sep 2014 06:31:42 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D7ACF476A6; Wed, 3 Sep 2014 13:31:41 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id D51744769B; Wed, 3 Sep 2014 13:31:41 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id D16952029; Wed, 3 Sep 2014 13:31:41 +0000 (GMT) Message-ID: <5407183D.2090909@akamai.com> Date: Wed, 03 Sep 2014 09:31:41 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" References: <20140724132129.8722.55066.idtracker@ietfa.amsl.com> In-Reply-To: <20140724132129.8722.55066.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/lQvzVQ5njwC4csYd0kbbLh4Bh5Q Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-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: Wed, 03 Sep 2014 13:31:44 -0000 I've read over the latest draft, and I think it's looking good re: the discovery mechanisms. The only comment I had about that on the original draft was resolved (i.e. sending "Try Alternate" error for allocate requests to an anycast address). I would still like to see some discussion in "Security Considerations" about the use of (D)TLS in the context of auto-discovered relay servers, especially those that use the global anycast address. It's important to make sure that client implementers carefully consider what degree of privacy their users are getting from (D)TLS. There was a fair amount of on-list discussion about this back in late March, and I think it would be good to capture some of the outcomes from that thread in the draft. --Brandon On 07/24/2014 09:21 AM, 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-00.txt > Pages : 11 > Date : 2014-07-24 > > 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 or > the ISP, 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 two 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: > http://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-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/ > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Sep 3 06:39:38 2014 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 A0E341A02E5 for ; Wed, 3 Sep 2014 06:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 4iX27oWIrX8z for ; Wed, 3 Sep 2014 06:39:33 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2611A02A0 for ; Wed, 3 Sep 2014 06:39:33 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BE1924757C; Wed, 3 Sep 2014 13:39:32 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B0B8447597; Wed, 3 Sep 2014 13:39:32 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id ACD888003C; Wed, 3 Sep 2014 13:39:32 +0000 (GMT) Message-ID: <54071A14.6030402@akamai.com> Date: Wed, 03 Sep 2014 09:39:32 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Simon Perreault , "Duckworth, Mark" , "tram@ietf.org" References: <5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B28C@CRPMBOXPRD08.polycom.com> <53CFBD2B.8040304@jive.com> <913383AAA69FF945B8F946018B75898A282F9782@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A282F9782@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/eBZz_5cXAZV3vbiayEqIfKsnVyQ Subject: Re: [tram] Questions on STUN credentials and MD5 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, 03 Sep 2014 13:39:34 -0000 On 07/23/2014 09:51 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault >> Sent: Wednesday, July 23, 2014 7:18 PM >> To: Duckworth, Mark; tram@ietf.org >> Subject: Re: [tram] Questions on STUN credentials and MD5 >> >> Le 2014-07-23 08:58, Duckworth, Mark a �crit : >>> Hello, >>> >>> I am a complete beginner regarding STUN and TURN, but I'm interested >>> in one of the issues in draft-ietf-tram-auth-problems-02. Section 4 >>> paragraph 2 describes the problem with using MD5 for STUN long term >>> credentials. A few questions about that - >>> >>> 1. Does draft-ietf-tram-turn-third-party-authz solve the problem, >>> because it provides a different way to do authentication which does >>> not require MD5, and which can be FIPS 140-2 compliant? > > Yup, draft-ietf-tram-turn-third-party-authz does not have this problem. > It's correct that the proposed 3rd party auth mechanism doesn't have this problem. That said, I don't think this means the draft solves the problem. It's probably also important to move away from MD5 for the other auth methods. --Brandon > >> >> I'll let the authors respond to that. >> >>> 2. There was previous discussion about replacing MD5, possibly >>> with SHA256, for the key calculation and storage. >>> http://www.ietf.org/mail-archive/web/tram/current/msg00466.html. Is >>> that still a possibility, or did the group decide against that? >> >> I think that this is something that will need to go into STUN-bis. We currently >> don't have an editor for that. All we need is a volunteer with time to do the >> work... >> >>> 3. At first I thought maybe draft-ietf-tram-stun-dtls could also >>> solve the problem, because the hashed key would be further protected >>> by DTLS. But that wouldn't help with the issue of storing the MD5 >>> hashed keys on the TURN server side, would it? Do I understand correctly? >> >> You're correct. >> >> Simon >> >> _______________________________________________ >> 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 > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Sep 3 06:43:34 2014 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 857081A031D for ; Wed, 3 Sep 2014 06:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 CQOthwgompXt for ; Wed, 3 Sep 2014 06:43:26 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 55CA01A031C for ; Wed, 3 Sep 2014 06:43:26 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id EA9244769D; Wed, 3 Sep 2014 13:43:25 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id DE0EB47699; Wed, 3 Sep 2014 13:43:25 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id DB05680047; Wed, 3 Sep 2014 13:43:25 +0000 (GMT) Message-ID: <54071AFD.4060502@akamai.com> Date: Wed, 03 Sep 2014 09:43:25 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Simon Perreault , "Duckworth, Mark" , "tram@ietf.org" References: <5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B28C@CRPMBOXPRD08.polycom.com> <53CFBD2B.8040304@jive.com> In-Reply-To: <53CFBD2B.8040304@jive.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ClxBiN7cXy3c_RcTc1zM4VzpX3g Subject: Re: [tram] Questions on STUN credentials and MD5 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, 03 Sep 2014 13:43:32 -0000 On 07/23/2014 09:48 AM, Simon Perreault wrote: > Le 2014-07-23 08:58, Duckworth, Mark a �crit : >> Hello, >> >> I am a complete beginner regarding STUN and TURN, but I�m interested in >> one of the issues in draft-ietf-tram-auth-problems-02. Section 4 >> paragraph 2 describes the problem with using MD5 for STUN long term >> credentials. A few questions about that � >> >> 1. Does draft-ietf-tram-turn-third-party-authz solve the problem, >> because it provides a different way to do authentication which does not >> require MD5, and which can be FIPS 140-2 compliant? > > I'll let the authors respond to that. > >> 2. There was previous discussion about replacing MD5, possibly >> with SHA256, for the key calculation and storage. >> http://www.ietf.org/mail-archive/web/tram/current/msg00466.html. Is >> that still a possibility, or did the group decide against that? > > I think that this is something that will need to go into STUN-bis. We > currently don't have an editor for that. All we need is a volunteer with > time to do the work... > Should there be a ticket for this in the issues tracker? And what about a ticket for MESSAGE-INTEGRITY hash agility? --Brandon >> 3. At first I thought maybe draft-ietf-tram-stun-dtls could also >> solve the problem, because the hashed key would be further protected by >> DTLS. But that wouldn�t help with the issue of storing the MD5 hashed >> keys on the TURN server side, would it? Do I understand correctly? > > You're correct. > > Simon > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Sep 3 06:51:45 2014 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 E4E791A0306 for ; Wed, 3 Sep 2014 06:51:42 -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 q3WXLDGMxzaU for ; Wed, 3 Sep 2014 06:51:38 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FAAF1A030C for ; Wed, 3 Sep 2014 06:51:37 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id n15so433502lbi.33 for ; Wed, 03 Sep 2014 06:51:36 -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=TuTZe46cgv8E//NKqLf9CjVlNrkuNZqfMsqMMcDBcAk=; b=fV8TPuUHiEAzsnA9zg+2kW4Hxdl8TgAniZxm3gR0vGRc1sd28JlJVwR8yIsB3OMFIn AqyO3lW9b8a5+rZnQI2N26SE1nNgRiojz2c/SJSFDRJzfthc3WirA1CnfmQW6kaU9fG2 pTsMzCKA4yjUumvg6tQS5rrWrHiqISCUozpDpeTnmw+lUvUht7t8k7moIj0UFHXOaeWv 2VkWMqoDn2bW6bSghCqBcVlwwwdmfJeBecggiXAZgfb6TAu3IQS3oiauJRBNnRE0+7Hy Mru6qEDsPG4a9eTt7/MgozXMrPPW+jPSdSzwOcraHHyc2TeRfeGISt4n2n8GyoCGHPsY EsYA== X-Gm-Message-State: ALoCoQkSNUD66GZ1BdTvb51njzI1Vi/KcIU+x+FMlODt1daxOrNmg/vgkOjbvZymIsX+exDCObn3 MIME-Version: 1.0 X-Received: by 10.112.150.106 with SMTP id uh10mr39182557lbb.11.1409752295918; Wed, 03 Sep 2014 06:51:35 -0700 (PDT) Received: by 10.25.137.6 with HTTP; Wed, 3 Sep 2014 06:51:35 -0700 (PDT) In-Reply-To: <54071AFD.4060502@akamai.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B28C@CRPMBOXPRD08.polycom.com> <53CFBD2B.8040304@jive.com> <54071AFD.4060502@akamai.com> Date: Wed, 3 Sep 2014 09:51:35 -0400 Message-ID: From: Simon Perreault To: Brandon Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/lO-FErYZi9ffVrsK4BKUe5NNZ60 Cc: "Duckworth, Mark" , "tram@ietf.org" Subject: Re: [tram] Questions on STUN credentials and MD5 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, 03 Sep 2014 13:51:43 -0000 On Wed, Sep 3, 2014 at 9:43 AM, Brandon Williams wrote: >>> 2. There was previous discussion about replacing MD5, possibly >>> with SHA256, for the key calculation and storage. >>> http://www.ietf.org/mail-archive/web/tram/current/msg00466.html. Is >>> that still a possibility, or did the group decide against that? >> >> >> I think that this is something that will need to go into STUN-bis. We >> currently don't have an editor for that. All we need is a volunteer with >> time to do the work... >> > > Should there be a ticket for this in the issues tracker? And what about a > ticket for MESSAGE-INTEGRITY hash agility? Sure, if I can find my Trac password... ;) In the end I think we all agree it is something for STUN-bis. Simon From nobody Wed Sep 3 07:14:56 2014 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 2F6591A032F for ; Wed, 3 Sep 2014 07:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 UC7CJ1yoaVE9 for ; Wed, 3 Sep 2014 07:14:52 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id BFD611A031F for ; Wed, 3 Sep 2014 07:14:52 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0C85A285F0; Wed, 3 Sep 2014 14:14:52 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id C8B8E285C3; Wed, 3 Sep 2014 14:14:51 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 485452029; Wed, 3 Sep 2014 14:14:51 +0000 (GMT) Message-ID: <5407225B.5020005@akamai.com> Date: Wed, 03 Sep 2014 10:14:51 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "tram@ietf.org" References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/JsG0e1z25S0TjnJA3AZc_34H1z4 Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 03 Sep 2014 14:14:55 -0000 I see this new text in the draft. "To accommodate for loss of Refresh responses, a server must retain the old STUN MOBILITY-TICKET attribute for a period of at least 30 seconds to be able recognize a retransmission of Refresh request with the old STUN MOBILITY-TICKET attribute from the client." Do you mean that the old ticket will be stored along with the new ticket in the allocation record? and that a refresh request with a mobility ticket that doesn't match the current ticket will have the ticket matched against the old ticket? That makes sense to me. I just think it would be good to directly state the intended use. On a separate note, why wouldn't the server just hold onto the old ticket until it receives a valid refresh request that contains the new ticket? If there are memory space concerns related to the size of the ticket, then perhaps the client could immediately send a refresh request with new ticket as confirmation that it was received and that the old ticket can be discarded. Regarding construction of the ticket, the draft currently states: "TURN server can store system internal data into the ticket that is encrypted by a key known only to the TURN server and sends the ticket in the STUN MOBILITY-TICKET attribute as part of Allocate success response. The ticket is opaque to the client, so the structure is not subject to interoperability concerns, and implementations may diverge from this format. TURN Allocation state information is encrypted using 128-bit key for Advance Encryption Standard (AES) and 256-bit key for HMAC-SHA-256 for integrity protection." I think it might be good for the document to be more explicit about the minimum content that is required in ticket for it to fulfill its purpose. This includes the client-side tuple for the turn allocation (required for lookup) and it might need a source of entropy to prevent replay of the token, though maybe the MESSAGE-INTEGRITY attribute on the STUN message serves that purpose well enough. What else do you envision being contained in the token? --Brandon On 08/25/2014 12:43 PM, Prashanth Patil (praspati) wrote: > All, > We've submitted a revision of the 'Mobility with TURN' draft. The update > addresses comments raised by Brandon during IETF-90 regarding TURN client > and server behavior when a STUN refresh message carrying MOBILITY-TICKET > attribute is lost. > > Comments welcome. > > Thanks, > Prashanth > > > On 8/25/14 6:26 PM, "internet-drafts@ietf.org" > wrote: > >> >> A new version of I-D, draft-wing-tram-turn-mobility-01.txt >> has been successfully submitted by Prashanth Patil and posted to the >> IETF repository. >> >> Name: draft-wing-tram-turn-mobility >> Revision: 01 >> Title: Mobility with TURN >> Document date: 2014-08-25 >> Group: Individual Submission >> Pages: 10 >> URL: >> http://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobility-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-wing-tram-turn-mobility/ >> Htmlized: >> http://tools.ietf.org/html/draft-wing-tram-turn-mobility-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-wing-tram-turn-mobility-01 >> >> Abstract: >> It is desirable to minimize traffic disruption caused by changing IP >> address during a mobility event. One mechanism to minimize >> disruption is to expose a shorter network path to the mobility event >> so only the local network elements are aware of the changed IP >> address but the remote peer is unaware of the changed IP address. >> >> This draft provides such an IP address mobility solution using TURN. >> This is achieved by allowing a client to retain an allocation on the >> TURN server when the IP address of the client changes. >> >> >> >> >> >> 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 > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Sep 3 07:31:26 2014 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 DA3901A0334; Wed, 3 Sep 2014 07:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 XxZ8erB_gjYb; Wed, 3 Sep 2014 07:31:23 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id C7B2C1A0344; Wed, 3 Sep 2014 07:31:22 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 64EA32852B; Wed, 3 Sep 2014 14:31:21 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 4792128504; Wed, 3 Sep 2014 14:31:21 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 406D480113; Wed, 3 Sep 2014 14:31:21 +0000 (GMT) Message-ID: <54072639.6030809@akamai.com> Date: Wed, 03 Sep 2014 10:31:21 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" References: <20140827094830.9888.36362.idtracker@ietfa.amsl.com> In-Reply-To: <20140827094830.9888.36362.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/r3IjliYYCLJmKLjsi3nkEo9aT64 Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.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, 03 Sep 2014 14:31:25 -0000 I see the following new text related to hash algorithm agility in the new draft. "Discussion: When STUN supports HMAC algorithms other than HMAC-SHA-1 then client will convey the algorithm negotiated with the TURN server to the authorization server in the value of 'alg' parameter defined in [I-D.ietf-oauth-pop-key-distribution]. Authorization server determines length of the mac_key based on the HMAC algorithm conveyed by the client." I've got two concerns about this, which are both just reiterations of things I've mentioned previously on the list. First, I think it may be premature to say anything about hash agility in this draft until we've settled the question more broadly in stunbis. Second, I think the OAuth server must be in a position to enforce policy on the minimum acceptable hash algorithm, and so allowing the client to pick one makes the mechanism more fragile. It may be preferable for the client to signal it's full list of capabilities in the request and for the server to signal its selection from among the options (or an error if nothing from the client's list is considered acceptable). On a separate note, I was reminded by the meeting notes that I promised to send some comments to the list about resource utilization. Customers of a 3rd party service will often have contracts that limit resource utilization. There may be limits in terms of the total number of concurrent end-to-end streams, aggregate bandwidth, etc. Considering this, it may be necessary for the OAuth server to authorize the client for a certain maximum utilization to be associated with the ACCESS-TOKEN. Although it could make the token larger, I think it may be important to include this authorized utilization information within the token. Does anyone have any thoughts about this? Perhaps an alternate way to handle the same concern? --Brandon On 08/27/2014 05:48 AM, 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 Extension for Third Party Authorization > Authors : Tirumaleswar Reddy > Prashanth Patil > Ram Mohan Ravindranath > Justin Uberti > Filename : draft-ietf-tram-turn-third-party-authz-02.txt > Pages : 16 > Date : 2014-08-27 > > Abstract: > This document proposes the use of OAuth to obtain and validate > ephemeral tokens that can be used for TURN authentication. The usage > of ephemeral tokens ensure that access to a TURN server can be > controlled even if the tokens are compromised. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-02 > > > 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 > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Sep 3 08:26:23 2014 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 0B0F61A03F0 for ; Wed, 3 Sep 2014 08:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=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 TShrIa1aM-Ae for ; Wed, 3 Sep 2014 08:26:20 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41E91A039A for ; Wed, 3 Sep 2014 08:24:45 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so8777821wgg.32 for ; Wed, 03 Sep 2014 08:24:44 -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=Ih3h8qduIaOTmsV2HrD0ESIE4vlg3aKY42rTNuOujmE=; b=OOi5jfRCY3g3kaGG38K8L/wJEXJRPxuZATv01tW5jk3WrfzX7irHq1LYThZfkRCLip 7SeDO6gr5oCY53TbUP+Yp84jDQjVsEzqO4TldXmBwOx+Brgb/lI9tVCVYB9winw7ig4n /1XVWFR1JDWa6pfbWxfr1gBWuGjn57zbJn0VZa+KYGFrgHoQG/RCWMnGtDIuKG2Gl76H wFL/JCoCmk8gZDTHdA4uFjsCcCBNJ2Noh/pF7uQYF2u8pUc+U2po8ba7qMEY5s5whPek sWVxwI+16kOSMJdCpT0vsvx2yI41IcITp7/uKLQ5DkkMuUK9FQOroWktAlTv28vOGQdP jVgg== MIME-Version: 1.0 X-Received: by 10.194.5.234 with SMTP id v10mr47346870wjv.45.1409757884309; Wed, 03 Sep 2014 08:24:44 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Wed, 3 Sep 2014 08:24:44 -0700 (PDT) In-Reply-To: <5407225B.5020005@akamai.com> References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <5407225B.5020005@akamai.com> Date: Wed, 3 Sep 2014 08:24:44 -0700 Message-ID: From: Oleg Moskalenko To: Brandon Williams Content-Type: multipart/alternative; boundary=047d7b5d2fdee9e96b05022ad5e3 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/DoqXVrq232onStlpVP_JMVQg2hU Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 03 Sep 2014 15:26:22 -0000 --047d7b5d2fdee9e96b05022ad5e3 Content-Type: text/plain; charset=UTF-8 see in the text: On Wed, Sep 3, 2014 at 7:14 AM, Brandon Williams < brandon.williams@akamai.com> wrote: > I see this new text in the draft. > > "To accommodate for loss of Refresh responses, a server must retain > the old STUN MOBILITY-TICKET attribute for a period of at least 30 > seconds to be able recognize a retransmission of Refresh request with > the old STUN MOBILITY-TICKET attribute from the client." > > Do you mean that the old ticket will be stored along with the new ticket > in the allocation record? and that a refresh request with a mobility ticket > that doesn't match the current ticket will have the ticket matched against > the old ticket? No, the meaning is slightly different. For an unreliable protocol, the client may not receive the refresh response. The client may re-transmit the REFRESH request from the same network endpoint. And the client will receive the same refresh response (with the same new ticket inside) because the server will recognize the refresh request retransmission (because the server stores the old ticket associated with the TURN session). On the other hand, if the client sends the REFRESH request (with old ticket) from a DIFFERENT network endpoint then the client will receive a sort of "unknown mobile ticket" error because the old ticket has already been "used" for the session relocation. The old ticket can only be used for the retransmission purpose. It cannot be used for the session relocation because it would lead to uncontrolled resource leakage. > That makes sense to me. I just think it would be good to directly state > the intended use. > I agree that a clarification would be proper. > > On a separate note, why wouldn't the server just hold onto the old ticket > until it receives a valid refresh request that contains the new ticket? If > there are memory space concerns related to the size of the ticket, then > perhaps the client could immediately send a refresh request with new ticket > as confirmation that it was received and that the old ticket can be > discarded. > > Regarding construction of the ticket, the draft currently states: "TURN > server can store system internal data into the ticket that is encrypted by > a key known only to the TURN server and sends the ticket in the STUN > MOBILITY-TICKET attribute as part of Allocate success response. The ticket > is opaque to the client, so the structure is not subject to > interoperability concerns, and implementations may diverge from this > format. TURN Allocation state information is encrypted using 128-bit key > for Advance Encryption Standard (AES) and 256-bit key for HMAC-SHA-256 for > integrity protection." > > I think it might be good for the document to be more explicit about the > minimum content that is required in ticket for it to fulfill its purpose. > This includes the client-side tuple for the turn allocation (required for > lookup) and it might need a source of entropy to prevent replay of the > token, though maybe the MESSAGE-INTEGRITY attribute on the STUN message > serves that purpose well enough. What else do you envision being contained > in the token? > I do not think that the document must specify what the ticket content is. The ticket content may be totally opaque and meaningless - that's up to server what to do about the ticket. The server may store all meaningful information in its database, and the ticket is just a sequence of random symbols. For the purpose of this specification, I see no reason why the ticket content is of any interest. Thanks Oleg > > --Brandon > > > On 08/25/2014 12:43 PM, Prashanth Patil (praspati) wrote: > >> All, >> We've submitted a revision of the 'Mobility with TURN' draft. The update >> addresses comments raised by Brandon during IETF-90 regarding TURN client >> and server behavior when a STUN refresh message carrying MOBILITY-TICKET >> attribute is lost. >> >> Comments welcome. >> >> Thanks, >> Prashanth >> >> >> On 8/25/14 6:26 PM, "internet-drafts@ietf.org" >> wrote: >> >> >>> A new version of I-D, draft-wing-tram-turn-mobility-01.txt >>> has been successfully submitted by Prashanth Patil and posted to the >>> IETF repository. >>> >>> Name: draft-wing-tram-turn-mobility >>> Revision: 01 >>> Title: Mobility with TURN >>> Document date: 2014-08-25 >>> Group: Individual Submission >>> Pages: 10 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobility-01.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-wing-tram-turn-mobility/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-wing-tram-turn-mobility-01 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-wing-tram-turn-mobility-01 >>> >>> Abstract: >>> It is desirable to minimize traffic disruption caused by changing IP >>> address during a mobility event. One mechanism to minimize >>> disruption is to expose a shorter network path to the mobility event >>> so only the local network elements are aware of the changed IP >>> address but the remote peer is unaware of the changed IP address. >>> >>> This draft provides such an IP address mobility solution using TURN. >>> This is achieved by allowing a client to retain an allocation on the >>> TURN server when the IP address of the client changes. >>> >>> >>> >>> >>> >>> 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 >> >> > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b5d2fdee9e96b05022ad5e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

see in the text:

On Wed, Sep 3, 2014 at 7:14 AM, Brandon Williams <brandon.williams@akamai.com> wrote:

I see this new text in the draft.

"To accommodate for loss of Refresh responses, a server must retain the old STUN MOBILITY-TICKET attribute for a period of at least 30
seconds to be able recognize a retransmission of Refresh request with
the old STUN MOBILITY-TICKET attribute from the client."

Do you mean that the old ticket will be stored along with the new ticket in= the allocation record? and that a refresh request with a mobility ticket t= hat doesn't match the current ticket will have the ticket matched again= st the old ticket?

No, the meaning is slightly different. For an unreliabl= e protocol, the client may not receive the refresh response. The client may= re-transmit the REFRESH request from the same network endpoint. And the cl= ient will receive the same refresh response (with the same new ticket insid= e) because the server will recognize the refresh request retransmission (be= cause the server stores the old ticket associated with the TURN session).

On the other hand, if the client sends the REFRESH requ= est (with old ticket) from a DIFFERENT network endpoint then the client wil= l receive a sort of "unknown mobile ticket" error because the old= ticket has already been "used" for the session relocation. The o= ld ticket can only be used for the retransmission purpose. It cannot be use= d for the session relocation because it would lead to uncontrolled resource= leakage.

=C2=A0

That makes sense to me. I j= ust think it would be good to directly state the intended use.

I agree that a clarification would be proper.=
=C2=A0

On a separate note, why wouldn't the server just hold onto the old tick= et until it receives a valid refresh request that contains the new ticket? = If there are memory space concerns related to the size of the ticket, then = perhaps the client could immediately send a refresh request with new ticket= as confirmation that it was received and that the old ticket can be discar= ded.

Regarding construction of the ticket, the draft currently states: "TUR= N server can store system internal data into the ticket that is encrypted b= y a key known only to the TURN server and sends the ticket in the STUN MOBI= LITY-TICKET attribute as part of Allocate success response. The ticket is o= paque to the client, so the structure is not subject to interoperability co= ncerns, and implementations may diverge from this format. TURN Allocation s= tate information is encrypted using 128-bit key for Advance Encryption Stan= dard (AES) and 256-bit key for HMAC-SHA-256 for integrity protection."=

I think it might be good for the document to be more explicit about the min= imum content that is required in ticket for it to fulfill its purpose. This= includes the client-side tuple for the turn allocation (required for looku= p) and it might need a source of entropy to prevent replay of the token, th= ough maybe the MESSAGE-INTEGRITY attribute on the STUN message serves that = purpose well enough. What else do you envision being contained in the token= ?

I do not think that the doc= ument must specify what the ticket content is. The ticket content may be to= tally opaque and meaningless - that's up to server what to do about the= ticket. The server may store all meaningful information in its database, a= nd the ticket is just a sequence of random symbols. For the purpose of this= specification, I see no reason why the ticket content is of any interest.<= /div>

Thanks
Oleg

=C2=A0

--Brandon

On 08/25/2014 12:43 PM, Prashanth Patil (praspati) wrote:

All,
We've submitted a revision of the 'Mobility with TURN' draft. T= he update
addresses comments raised by Brandon during IETF-90 regarding TURN client and server behavior when a STUN refresh message carrying MOBILITY-TICKET attribute is lost.

Comments welcome.

Thanks,
Prashanth

On 8/25/14 6:26 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

A new version of I-D, draft-wing-tram-turn-mobility-01.txt
has been successfully submitted by Prashanth Patil and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-wing-tram-turn-mobility=
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mobility with TURN
Document date:=C2=A0 2014-08-25
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:
http://www.ietf.org/internet-drafts/draf= t-wing-tram-turn-mobility-01.txt
Status:
https://datatracker.ietf.org/doc/draft-wing-tram-= turn-mobility/
Htmlized:
http://tools.ietf.org/html/draft-wing-tram-turn-mobil= ity-01
Diff:
http://www.ietf.org/rfcdiff?url2=3Ddraft-wing= -tram-turn-mobility-01

Abstract:
=C2=A0 =C2=A0It is desirable to minimize traffic disruption caused by chang= ing IP
=C2=A0 =C2=A0address during a mobility event.=C2=A0 One mechanism to minimi= ze
=C2=A0 =C2=A0disruption is to expose a shorter network path to the mobility= event
=C2=A0 =C2=A0so only the local network elements are aware of the changed IP=
=C2=A0 =C2=A0address but the remote peer is unaware of the changed IP addre= ss.

=C2=A0 =C2=A0This draft provides such an IP address mobility solution using= TURN.
=C2=A0 =C2=A0This is achieved by allowing a client to retain an allocation = on the
=C2=A0 =C2=A0TURN server when the IP address of the client changes.

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
ht= tps://www.ietf.org/mailman/listinfo/tram

--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

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

--047d7b5d2fdee9e96b05022ad5e3-- From nobody Wed Sep 3 09:01:42 2014 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 5155D1A8A7F for ; Wed, 3 Sep 2014 09:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 VMAiZBv3iJEo for ; Wed, 3 Sep 2014 09:01:24 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 908051A8A5F for ; Wed, 3 Sep 2014 09:00:57 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8F908285B3; Wed, 3 Sep 2014 16:00:56 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 71F5B2850C; Wed, 3 Sep 2014 16:00:56 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 6B3858003C; Wed, 3 Sep 2014 16:00:56 +0000 (GMT) Message-ID: <54073B38.7020705@akamai.com> Date: Wed, 03 Sep 2014 12:00:56 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A2831D2DB@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2831D2DB@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/HWKCpdTlQ8QoKdfo2dVwwqcOOnE Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-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: Wed, 03 Sep 2014 16:01:29 -0000 On 08/28/2014 04:53 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Brandon Williams [mailto:brandon.williams@akamai.com] >> Sent: Wednesday, August 27, 2014 12:00 AM >> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko >> Cc: tram@ietf.org >> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 >> >> I don't think that it's reasonable for the client to select a single auth algorithm >> from a list of those supported by the relay server, because there is a risk that >> it will select one that doesn't meet the policy requirements being enforced by >> the oauth server. > > Why should the policy requirements enforced by the authorization server care about the algorithm used by the client and TURN server to integrity protect messages ? > In a 3rd party relay server scenario, the owner of the OAuth server is probably a customer of the owner of relay server, not the client, so the owner of the OAuth server has a business interest in securing access to the resources that it is paying for. For this reason, the owner of the OAuth server will likely desire to impose requirements on the hash algorithm used. The owner of the OAuth server is also the one who has to fulfill regulatory requirements if/when they apply. --Brandon >> >> In addition, I think the oauth administrator has to know the algorithms >> supported by the relay server in order to configure a reasonable policy. > > As part of communication between authorization server and resource server to establish a long-term symmetric key, resource server can inform the algorithms it supports. > But what I don't understand is why should authorization server know the algorithms supported by the resource or relay server ? > Do you see some attack or security hole because of which you are suggesting this approach ? > >> I don't think the policy configuration requirement can be met with in-band >> communication of the supported algorithms. >> >> I agree that the client and the oauth server have to agree on the algorithm in >> order for the oauth server to send an appropriately sized key. > > Okay. > >> I'm suggesting >> that the algorithm should be selected by the oauth server from among the >> union of the set supported by the client and the algorithm supported by the >> relay server. I'm also suggesting that the client should not be allowed to >> declare what the union set is, which is a shortcoming of delivering the >> information in-band. >> >> All of the above having been said, I think that we may be getting ahead of the >> discussion. Is there general agreement that we need to come up with a new >> hash agility approach for STUN? > > I think STUNbis will provide hash agility support. http://www.ietf.org/mail-archive/web/tram/current/msg00000.html charter proposal mentions supporting hash agility. > >> And if so, has someone actually taken that >> on? What we come up with on hash agility for 3rd party auth may depend >> upon how hash agility is resolved for STUN in general. > > -Tiru > >> >> --Brandon >> >> On 08/26/2014 02:19 AM, Tirumaleswar Reddy (tireddy) wrote: >>>> -----Original Message----- >>>> From: Brandon Williams [mailto:brandon.williams@akamai.com] >>>> Sent: Monday, August 25, 2014 11:20 PM >>>> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko >>>> Cc: tram@ietf.org >>>> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 >>>> >>>> Why should it be necessary for the TURN server to send a list? Can't >>>> the list of supported auth algorithms be agreed upon between the >>>> relay and oauth servers out-of-band like the other security >>>> parameters? And how is this better than a more typical model wherein >>>> the client advertises its capabilities and the server enforces its policy? >>> >>> Both models will work and even in the above case client will have to signal >> the algorithm to the authorization server so as to get key with correct length. >> In the below proposal, there is no need for list of supported authentication >> algorithms to be agreed upon between the RS and AS servers. >>> >>> -Tiru >>> >>>> >>>> --Brandon >>>> >>>> On 08/25/2014 01:27 PM, Tirumaleswar Reddy (tireddy) wrote: >>>>>> -----Original Message----- >>>>>> From: Brandon Williams [mailto:brandon.williams@akamai.com] >>>>>> Sent: Monday, August 25, 2014 10:40 PM >>>>>> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko >>>>>> Cc: tram@ietf.org >>>>>> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 >>>>>> >>>>>> I don't think that the client will be (or can safely be allow to >>>>>> be) responsible for selecting the algorithm. Somehow, this decision >>>>>> must be up to the OAuth server. The most that I think the client >>>>>> can do is send a list of what it supports, which will allow the >>>>>> server to select the best of the bunch (or reject if none are good >> enough). >>>>> >>>>> I am thinking other way around. TURN server sends lists of HMAC >>>> algorithms it supports, client picks the algorithm it would like to >>>> use and conveys it to the authorization server. OAuth has already defined >> 'alg' >>>> parameter for the client to signal the algorithm to the authorization >> server. >>>>> >>>>> -Tiru >>>>> >>>>>> >>>>>> I haven't read the referenced draft or your proposed changes so it >>>>>> may be that you've already dealt with this part of the problem. >>>>>> >>>>>> --Brandon >>>>>> >>>>>> On 08/25/2014 12:50 PM, Tirumaleswar Reddy (tireddy) wrote: >>>>>>>> -----Original Message----- >>>>>>>> From: Brandon Williams [mailto:brandon.williams@akamai.com] >>>>>>>> Sent: Monday, August 25, 2014 8:06 PM >>>>>>>> To: Oleg Moskalenko; Tirumaleswar Reddy (tireddy) >>>>>>>> Cc: tram@ietf.org >>>>>>>> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 >>>>>>>> >>>>>>>> I agree that the 5389 hash agility plan seems problematic and >>>>>>>> should be replaced with something more suitable to the stated >>>>>>>> purpose. That should probably be part of the stun-bis effort, or >>>>>>>> at happen concurrently so that stun-bis can reference the >>>>>>>> relevant >>>> document. >>>>>>>> Completion of this effort might be a requirement for publishing >>>>>>>> the 3rd party auth draft, because we don't want to end up >>>>>>>> publishing a draft that requires an immediate update in order to >>>>>>>> satisfy a >>>>>>>> not-yet- >>>>>> written hash agility requirement. >>>>>>>> >>>>>>>> The area that I think is most likely to be challenging with the >>>>>>>> current 3rd party auth draft is algorithm identification. It will >>>>>>>> be necessary at some point in the future for the TURN server to >>>>>>>> select from among multiple supported auth algorithms, but there >>>>>>>> is no obvious way at the moment for the auth algorithm to be >>>>>>>> communicated from the auth server to either the client or the >>>>>>>> TURN server. The only value that could currently be used to guess >>>>>>>> the auth algorithm is the key_length in the token, but using >>>>>>>> key_length as an algorithm identifier seems risky, even if it >>>>>>>> would work with the most likely >>>>>> candidates today. >>>>>>> >>>>>>> I have updated the draft to address the problem in the following way: >>>>>>> When STUN supports HMAC algorithms other than HMAC-SHA-1 then >>>> client >>>>>>> will convey the algorithm negotiated with the TURN server to the >>>>>> authorization server in the value of 'alg' parameter defined in >>>>>> [I-D.ietf-oauth- pop-key-distribution]. Authorization server >>>>>> determines length of the mac_key based on the HMAC algorithm >>>> conveyed by the client. >>>>>>> >>>>>>> -Tiru >>>>>>> >>>>>>>> >>>>>>>> --Brandon >>>>>>>> >>>>>>>> On 08/23/2014 02:47 AM, Oleg Moskalenko wrote: >>>>>>>>> Another problem is that I am not sure that the hash agility plan >>>>>>>>> idea described in RFC5389 is still valid. I am afraid that it is >>>>>>>>> unnecessary complicated and outdated, taking into account the >>>>>>>>> current level of >>>>>>>>> SHA-256 adoption. The plan was designed to support, >>>>>>>>> "transparently", the old TURN servers. But in these specs, we do >>>>>>>>> not necessary have to support the "old" servers with HMAC-SHA-1 >>>>>>>>> only implementations; as we are writing a new oAuth procedure, >>>>>>>>> there >>>> will be only "new" >>>>>>>>> servers supporting the draft specs, anyway. The "old" servers >>>>>>>>> will not be able to use the oAuth specs. SO we can design a >>>>>>>>> cleaner simpler hash agility procedure. >>>>>>>> >>>>>>>> -- >>>>>>>> Brandon Williams; Senior Principal Software Engineer Emerging >>>>>>>> Products Engineering; Akamai Technologies Inc. >>>>>> >>>>>> -- >>>>>> Brandon Williams; Senior Principal Software Engineer Emerging >>>>>> Products Engineering; Akamai Technologies Inc. >>>> >>>> -- >>>> Brandon Williams; Senior Principal Software Engineer Emerging >>>> Products Engineering; Akamai Technologies Inc. >> >> -- >> Brandon Williams; Senior Principal Software Engineer Emerging Products >> Engineering; Akamai Technologies Inc. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Sep 3 09:26:53 2014 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 E09121A000E for ; Wed, 3 Sep 2014 09:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 WEDVth_MW6sz for ; Wed, 3 Sep 2014 09:26:50 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 521481A0002 for ; Wed, 3 Sep 2014 09:26:50 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 82318476A1; Wed, 3 Sep 2014 16:26:49 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 88A08476C2; Wed, 3 Sep 2014 16:26:47 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 82FC82029; Wed, 3 Sep 2014 16:26:47 +0000 (GMT) Message-ID: <54074147.1000507@akamai.com> Date: Wed, 03 Sep 2014 12:26:47 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <5407225B.5020005@akamai.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/gdikptOu1dSlBfF7XSdJEOySwAc Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 03 Sep 2014 16:26:53 -0000 On 09/03/2014 11:24 AM, Oleg Moskalenko wrote: > see in the text: > > > On Wed, Sep 3, 2014 at 7:14 AM, Brandon Williams > > wrote: > > I see this new text in the draft. > > "To accommodate for loss of Refresh responses, a server must retain > the old STUN MOBILITY-TICKET attribute for a period of at least 30 > seconds to be able recognize a retransmission of Refresh request with > the old STUN MOBILITY-TICKET attribute from the client." > > Do you mean that the old ticket will be stored along with the new > ticket in the allocation record? and that a refresh request with a > mobility ticket that doesn't match the current ticket will have the > ticket matched against the old ticket? > > > No, the meaning is slightly different. For an unreliable protocol, the > client may not receive the refresh response. The client may re-transmit > the REFRESH request from the same network endpoint. And the client will > receive the same refresh response (with the same new ticket inside) > because the server will recognize the refresh request retransmission > (because the server stores the old ticket associated with the TURN session). This sounds like the operation I was talking about. > > On the other hand, if the client sends the REFRESH request (with old > ticket) from a DIFFERENT network endpoint then the client will receive a > sort of "unknown mobile ticket" error because the old ticket has already > been "used" for the session relocation. The old ticket can only be used > for the retransmission purpose. It cannot be used for the session > relocation because it would lead to uncontrolled resource leakage. So you're suggesting that server should not support mobility in this case. If that's true, then the document should definitely state that, and also make clear why this restriction is important. > > That makes sense to me. I just think it would be good to directly > state the intended use. > > > > I agree that a clarification would be proper. > > > On a separate note, why wouldn't the server just hold onto the old > ticket until it receives a valid refresh request that contains the > new ticket? If there are memory space concerns related to the size > of the ticket, then perhaps the client could immediately send a > refresh request with new ticket as confirmation that it was received > and that the old ticket can be discarded. > > Regarding construction of the ticket, the draft currently states: > "TURN server can store system internal data into the ticket that is > encrypted by a key known only to the TURN server and sends the > ticket in the STUN MOBILITY-TICKET attribute as part of Allocate > success response. The ticket is opaque to the client, so the > structure is not subject to interoperability concerns, and > implementations may diverge from this format. TURN Allocation state > information is encrypted using 128-bit key for Advance Encryption > Standard (AES) and 256-bit key for HMAC-SHA-256 for integrity > protection." > > I think it might be good for the document to be more explicit about > the minimum content that is required in ticket for it to fulfill its > purpose. This includes the client-side tuple for the turn allocation > (required for lookup) and it might need a source of entropy to > prevent replay of the token, though maybe the MESSAGE-INTEGRITY > attribute on the STUN message serves that purpose well enough. What > else do you envision being contained in the token? > > > > I do not think that the document must specify what the ticket content > is. The ticket content may be totally opaque and meaningless - that's up > to server what to do about the ticket. The server may store all > meaningful information in its database, and the ticket is just a > sequence of random symbols. For the purpose of this specification, I see > no reason why the ticket content is of any interest. Some examples might be helpful to implementers, especially to help them get the security aspects of the token right. For example, if there's no source of entropy, then the encrypt and auth results may be problematic. Your example of a random series of bytes is fine in this regard, but if someone where to do what the spec appears to be suggesting and nothing more, that would not be particularly good. --Brandon > > Thanks > Oleg > > > --Brandon > > > On 08/25/2014 12:43 PM, Prashanth Patil (praspati) wrote: > > All, > We've submitted a revision of the 'Mobility with TURN' draft. > The update > addresses comments raised by Brandon during IETF-90 regarding > TURN client > and server behavior when a STUN refresh message carrying > MOBILITY-TICKET > attribute is lost. > > Comments welcome. > > Thanks, > Prashanth > > > On 8/25/14 6:26 PM, "internet-drafts@ietf.org > "

> > wrote: > > > A new version of I-D, draft-wing-tram-turn-mobility-__01.txt > has been successfully submitted by Prashanth Patil and > posted to the > IETF repository. > > Name: draft-wing-tram-turn-mobility > Revision: 01 > Title: Mobility with TURN > Document date: 2014-08-25 > Group: Individual Submission > Pages: 10 > URL: > http://www.ietf.org/internet-__drafts/draft-wing-tram-turn-__mobility-01.txt > > Status: > https://datatracker.ietf.org/__doc/draft-wing-tram-turn-__mobility/ > > Htmlized: > http://tools.ietf.org/html/__draft-wing-tram-turn-mobility-__01 > > Diff: > http://www.ietf.org/rfcdiff?__url2=draft-wing-tram-turn-__mobility-01 > > > Abstract: > It is desirable to minimize traffic disruption caused by > changing IP > address during a mobility event. One mechanism to minimize > disruption is to expose a shorter network path to the > mobility event > so only the local network elements are aware of the > changed IP > address but the remote peer is unaware of the changed IP > address. > > This draft provides such an IP address mobility solution > using TURN. > This is achieved by allowing a client to retain an > allocation on the > TURN server when the IP address of the client changes. > > > > > > 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 > > > > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > > > _________________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/__listinfo/tram > > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Sep 3 09:56:06 2014 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 719241A0353 for ; Wed, 3 Sep 2014 09:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=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 uLhCdF18aqEO for ; Wed, 3 Sep 2014 09:56:01 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F421A035E for ; Wed, 3 Sep 2014 09:55:57 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id e4so10245571wiv.2 for ; Wed, 03 Sep 2014 09:55:56 -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=Z5uB8cmLBCqJv9QpEQwCq/cXmVPdULF9bQX4B/qT9hY=; b=xn4zimH3J5oa65DqHWm1MmKlKMGnqbNB3H1s6Jj6wLrjz00pV0ZRZF0KdlbteHSo+8 PJiloY5Oi9djY2CkvcR52ZWQebPoBzct4YNdY5VuMj1DXF2CEZ69uF+Ivzj/N8CUh7KQ IeUszRZJvLjiZejKpdhAZvvQYjq9O4OLfSKR9QSrtKKwH1dRocOb1CVsPmRWWjL/wOW5 v6YzF9+KV6A8TDNLYiowMjUPpUR/tRuLttigSaoVcKobAa57XLm1pOcKwHQeK8nN+j45 vnoMXWL6CR6D0bYys+H9cly3OpIGaHhOx8Y2AJE2aIN8qOBudIuEfP+H9ZWNphuAKFuf hh4w== MIME-Version: 1.0 X-Received: by 10.194.236.132 with SMTP id uu4mr5098995wjc.108.1409763356256; Wed, 03 Sep 2014 09:55:56 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Wed, 3 Sep 2014 09:55:56 -0700 (PDT) In-Reply-To: <54074147.1000507@akamai.com> References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <5407225B.5020005@akamai.com> <54074147.1000507@akamai.com> Date: Wed, 3 Sep 2014 09:55:56 -0700 Message-ID: From: Oleg Moskalenko To: Brandon Williams Content-Type: multipart/alternative; boundary=089e0149418611392205022c1c42 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/G3beWseQJqoK95Ms3eyK5CtOCR0 Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 03 Sep 2014 16:56:03 -0000 --089e0149418611392205022c1c42 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 3, 2014 at 9:26 AM, Brandon Williams < brandon.williams@akamai.com> wrote: > > > On 09/03/2014 11:24 AM, Oleg Moskalenko wrote: > >> see in the text: >> >> >> On Wed, Sep 3, 2014 at 7:14 AM, Brandon Williams >> > wrote: >> >> I see this new text in the draft. >> >> "To accommodate for loss of Refresh responses, a server must retain >> the old STUN MOBILITY-TICKET attribute for a period of at least 30 >> seconds to be able recognize a retransmission of Refresh request with >> the old STUN MOBILITY-TICKET attribute from the client." >> >> Do you mean that the old ticket will be stored along with the new >> ticket in the allocation record? and that a refresh request with a >> mobility ticket that doesn't match the current ticket will have the >> ticket matched against the old ticket? >> >> >> No, the meaning is slightly different. For an unreliable protocol, the >> client may not receive the refresh response. The client may re-transmit >> the REFRESH request from the same network endpoint. And the client will >> receive the same refresh response (with the same new ticket inside) >> because the server will recognize the refresh request retransmission >> (because the server stores the old ticket associated with the TURN >> session). >> > > This sounds like the operation I was talking about. OK > > > >> On the other hand, if the client sends the REFRESH request (with old >> ticket) from a DIFFERENT network endpoint then the client will receive a >> sort of "unknown mobile ticket" error because the old ticket has already >> been "used" for the session relocation. The old ticket can only be used >> for the retransmission purpose. It cannot be used for the session >> relocation because it would lead to uncontrolled resource leakage. >> > > So you're suggesting that server should not support mobility in this case. > If that's true, then the document should definitely state that, and also > make clear why this restriction is important. Yes, I think that this can be clarified in the document. > > > >> That makes sense to me. I just think it would be good to directly >> state the intended use. >> >> >> >> I agree that a clarification would be proper. >> >> >> On a separate note, why wouldn't the server just hold onto the old >> ticket until it receives a valid refresh request that contains the >> new ticket? If there are memory space concerns related to the size >> of the ticket, then perhaps the client could immediately send a >> refresh request with new ticket as confirmation that it was received >> and that the old ticket can be discarded. >> >> Regarding construction of the ticket, the draft currently states: >> "TURN server can store system internal data into the ticket that is >> encrypted by a key known only to the TURN server and sends the >> ticket in the STUN MOBILITY-TICKET attribute as part of Allocate >> success response. The ticket is opaque to the client, so the >> structure is not subject to interoperability concerns, and >> implementations may diverge from this format. TURN Allocation state >> information is encrypted using 128-bit key for Advance Encryption >> Standard (AES) and 256-bit key for HMAC-SHA-256 for integrity >> protection." >> >> I think it might be good for the document to be more explicit about >> the minimum content that is required in ticket for it to fulfill its >> purpose. This includes the client-side tuple for the turn allocation >> (required for lookup) and it might need a source of entropy to >> prevent replay of the token, though maybe the MESSAGE-INTEGRITY >> attribute on the STUN message serves that purpose well enough. What >> else do you envision being contained in the token? >> >> >> >> I do not think that the document must specify what the ticket content >> is. The ticket content may be totally opaque and meaningless - that's up >> to server what to do about the ticket. The server may store all >> meaningful information in its database, and the ticket is just a >> sequence of random symbols. For the purpose of this specification, I see >> no reason why the ticket content is of any interest. >> > > Some examples might be helpful to implementers, especially to help them > get the security aspects of the token right. For example, if there's no > source of entropy, then the encrypt and auth results may be problematic. > Your example of a random series of bytes is fine in this regard, but if > someone where to do what the spec appears to be suggesting and nothing > more, that would not be particularly good. > I'd leave that to the implementation completely - we can just impose a requirement that the token's meaning must be known only to the server. How it is achieved - by using random string of bytes or by using really good encryption - let the implementation to decide. I personally think that the means of hiding information are not relevant in this context because there are no parties in the information exchange - the information is going from server to the same server; we do not have to set standards when we do not have interacting parties. That's up to the server what to do with its own information. If the server implementation is bad and it cannot hide its own information - well, then it means that this is a bad program. Let's not set standards when they do not have a useful purpose. > > --Brandon > > >> Thanks >> Oleg >> >> >> --Brandon >> >> >> On 08/25/2014 12:43 PM, Prashanth Patil (praspati) wrote: >> >> All, >> We've submitted a revision of the 'Mobility with TURN' draft. >> The update >> addresses comments raised by Brandon during IETF-90 regarding >> TURN client >> and server behavior when a STUN refresh message carrying >> MOBILITY-TICKET >> attribute is lost. >> >> Comments welcome. >> >> Thanks, >> Prashanth >> >> >> On 8/25/14 6:26 PM, "internet-drafts@ietf.org >> " > > >> wrote: >> >> >> A new version of I-D, draft-wing-tram-turn-mobility-__01.txt >> >> has been successfully submitted by Prashanth Patil and >> posted to the >> IETF repository. >> >> Name: draft-wing-tram-turn-mobility >> Revision: 01 >> Title: Mobility with TURN >> Document date: 2014-08-25 >> Group: Individual Submission >> Pages: 10 >> URL: >> http://www.ietf.org/internet-__drafts/draft-wing-tram-turn-_ >> _mobility-01.txt >> > mobility-01.txt> >> Status: >> https://datatracker.ietf.org/__doc/draft-wing-tram-turn-__ >> mobility/ >> > mobility/> >> Htmlized: >> http://tools.ietf.org/html/__draft-wing-tram-turn-mobility- >> __01 >> >> Diff: >> http://www.ietf.org/rfcdiff?__url2=draft-wing-tram-turn-__ >> mobility-01 >> >> > mobility-01> >> >> Abstract: >> It is desirable to minimize traffic disruption caused by >> changing IP >> address during a mobility event. One mechanism to >> minimize >> disruption is to expose a shorter network path to the >> mobility event >> so only the local network elements are aware of the >> changed IP >> address but the remote peer is unaware of the changed IP >> address. >> >> This draft provides such an IP address mobility solution >> using TURN. >> This is achieved by allowing a client to retain an >> allocation on the >> TURN server when the IP address of the client changes. >> >> >> >> >> >> 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 >> >> >> >> >> -- >> Brandon Williams; Senior Principal Software Engineer >> Emerging Products Engineering; Akamai Technologies Inc. >> >> >> _________________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/__listinfo/tram >> >> >> >> > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --089e0149418611392205022c1c42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Sep 3, 2014 at 9:26 AM, Brandon Williams = <brando= n.williams@akamai.com> wrote:

On 09/03/2014 11:24 AM, Oleg Moskalenko wrote:

see in the text:

On Wed, Sep 3, 2014 at 7:14 AM, Brandon Williams
<brando= n.williams@akamai.com <mailto:brandon.williams@akamai.com>> w= rote:

=C2=A0 =C2=A0 I see this new text in the draft.

=C2=A0 =C2=A0 "To accommodate for loss of Refresh responses, a server = must retain
=C2=A0 =C2=A0 the old STUN MOBILITY-TICKET attribute for a period of at lea= st 30
=C2=A0 =C2=A0 seconds to be able recognize a retransmission of Refresh requ= est with
=C2=A0 =C2=A0 the old STUN MOBILITY-TICKET attribute from the client."=

=C2=A0 =C2=A0 Do you mean that the old ticket will be stored along with the= new
=C2=A0 =C2=A0 ticket in the allocation record? and that a refresh request w= ith a
=C2=A0 =C2=A0 mobility ticket that doesn't match the current ticket wil= l have the
=C2=A0 =C2=A0 ticket matched against the old ticket?

No, the meaning is slightly different. For an unreliable protocol, the
client may not receive the refresh response. The client may re-transmit
the REFRESH request from the same network endpoint. And the client will
receive the same refresh response (with the same new ticket inside)
because the server will recognize the refresh request retransmission
(because the server stores the old ticket associated with the TURN session)= .

This sounds like the operation I was talking about.

=C2=A0

On the other hand, if the client sends the REFRESH request (with old
ticket) from a DIFFERENT network endpoint then the client will receive a sort of "unknown mobile ticket" error because the old ticket has = already
been "used" for the session relocation. The old ticket can only b= e used
for the retransmission purpose. It cannot be used for the session
relocation because it would lead to uncontrolled resource leakage.

So you're suggesting that server should not support mobility in this ca= se. If that's true, then the document should definitely state that, and= also make clear why this restriction is important.

Yes, I think that this can be clarified in the document.

=C2=A0

=C2=A0 =C2=A0 That makes sense to me. I just think it would be good to dire= ctly
=C2=A0 =C2=A0 state the intended use.

I agree that a clarification would be proper.

=C2=A0 =C2=A0 On a separate note, why wouldn't the server just hold ont= o the old
=C2=A0 =C2=A0 ticket until it receives a valid refresh request that contain= s the
=C2=A0 =C2=A0 new ticket? If there are memory space concerns related to the= size
=C2=A0 =C2=A0 of the ticket, then perhaps the client could immediately send= a
=C2=A0 =C2=A0 refresh request with new ticket as confirmation that it was r= eceived
=C2=A0 =C2=A0 and that the old ticket can be discarded.

=C2=A0 =C2=A0 Regarding construction of the ticket, the draft currently sta= tes:
=C2=A0 =C2=A0 "TURN server can store system internal data into the tic= ket that is
=C2=A0 =C2=A0 encrypted by a key known only to the TURN server and sends th= e
=C2=A0 =C2=A0 ticket in the STUN MOBILITY-TICKET attribute as part of Alloc= ate
=C2=A0 =C2=A0 success response. The ticket is opaque to the client, so the<= br> =C2=A0 =C2=A0 structure is not subject to interoperability concerns, and =C2=A0 =C2=A0 implementations may diverge from this format. TURN Allocation= state
=C2=A0 =C2=A0 information is encrypted using 128-bit key for Advance Encryp= tion
=C2=A0 =C2=A0 Standard (AES) and 256-bit key for HMAC-SHA-256 for integrity=
=C2=A0 =C2=A0 protection."

=C2=A0 =C2=A0 I think it might be good for the document to be more explicit= about
=C2=A0 =C2=A0 the minimum content that is required in ticket for it to fulf= ill its
=C2=A0 =C2=A0 purpose. This includes the client-side tuple for the turn all= ocation
=C2=A0 =C2=A0 (required for lookup) and it might need a source of entropy t= o
=C2=A0 =C2=A0 prevent replay of the token, though maybe the MESSAGE-INTEGRI= TY
=C2=A0 =C2=A0 attribute on the STUN message serves that purpose well enough= . What
=C2=A0 =C2=A0 else do you envision being contained in the token?

I do not think that the document must specify what the ticket content
is. The ticket content may be totally opaque and meaningless - that's u= p
to server what to do about the ticket. The server may store all
meaningful information in its database, and the ticket is just a
sequence of random symbols. For the purpose of this specification, I see no reason why the ticket content is of any interest.

Some examples might be helpful to implementers, especially to help them get= the security aspects of the token right. For example, if there's no so= urce of entropy, then the encrypt and auth results may be problematic. Your= example of a random series of bytes is fine in this regard, but if someone= where to do what the spec appears to be suggesting and nothing more, that = would not be particularly good.

I'd leave that to the implementation c= ompletely - we can just impose a requirement that the token's meaning m= ust be known only to the server. How it is achieved - by using random strin= g of bytes or by using really good encryption - let the implementation to d= ecide. I personally think that the means of hiding information are not rele= vant in this context because there are no parties in the information exchan= ge - the information is going from server to the same server; we do not hav= e to set standards when we do not have interacting parties. That's up t= o the server what to do with its own information. If the server implementat= ion is bad and it cannot hide its own information - well, then it means tha= t this is a bad program.

Let's not set standards when they do not have a use= ful purpose.

=C2=A0

--Brandon

Thanks
Oleg

=C2=A0 =C2=A0 --Brandon

=C2=A0 =C2=A0 On 08/25/2014 12:43 PM, Prashanth Patil (praspati) wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 All,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 We've submitted a revision of the 'Mobi= lity with TURN' draft.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The update
=C2=A0 =C2=A0 =C2=A0 =C2=A0 addresses comments raised by Brandon during IET= F-90 regarding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TURN client
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and server behavior when a STUN refresh message= carrying
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MOBILITY-TICKET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 attribute is lost.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Comments welcome.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Prashanth

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 8/25/14 6:26 PM, "internet-drafts@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:internet-drafts@ietf.org>" <= ;internet-dra= fts@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:internet-drafts@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A new version of I-D, draft-wing-= tram-turn-mobility-__01.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 has been successfully submitted b= y Prashanth Patil and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 posted to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF repository.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0draft-wing-tram-turn-mobility
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Revision:=C2=A0 =C2=A0 =C2=A0 =C2= =A001
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 Mobility with TURN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Document date:=C2=A0 2014-08-25 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 Individual Submission
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttp://www.ietf.org/internet-__drafts/draft-wing-tram-turn-__m= obility-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <h= ttp://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobil= ity-01.txt>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://da= tatracker.ietf.org/__doc/draft-wing-tram-turn-__mobility/=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://da= tatracker.ietf.org/doc/draft-wing-tram-turn-mobility/>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Htmlized:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://tools.i= etf.org/html/__draft-wing-tram-turn-mobility-__01
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://tools.i= etf.org/html/draft-wing-tram-turn-mobility-01>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Diff:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http:/= /www.ietf.org/rfcdiff?__url2=3Ddraft-wing-tram-turn-__mobilit= y-01

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http:/= /www.ietf.org/rfcdiff?url2=3Ddraft-wing-tram-turn-mobility-01= >

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 It is desirable to = minimize traffic disruption caused by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 changing IP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address during a mo= bility event.=C2=A0 One mechanism to minimize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 disruption is to ex= pose a shorter network path to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mobility event
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 so only the local n= etwork elements are aware of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 changed IP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address but the rem= ote peer is unaware of the changed IP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This draft provides= such an IP address mobility solution
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 using TURN.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is achieved by= allowing a client to retain an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 allocation on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TURN server when th= e IP address of the client changes.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Please note that it may take a co= uple of minutes from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 time of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 submission
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 until the htmlized version and di= ff are available at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tools.ietf.org <http://tools.ietf.org>.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The IETF Secretariat

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ________________________________________= _________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 tram mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 tram@ietf.org <mailto:tram@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/__listinfo/= tram

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

=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 Brandon Williams; Senior Principal Software Engineer
=C2=A0 =C2=A0 Emerging Products Engineering; Akamai Technologies Inc.

=C2=A0 =C2=A0 _________________________________________________
=C2=A0 =C2=A0 tram mailing list
=C2=A0 =C2=A0 tram@ietf.= org <mailto:tram@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/__listinfo/tram
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/tram>

--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

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

--089e0149418611392205022c1c42-- From nobody Wed Sep 3 10:11:03 2014 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 864341A039F for ; Wed, 3 Sep 2014 10:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 Fc4nTpQhmZTf for ; Wed, 3 Sep 2014 10:10:36 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDCA1A0359 for ; Wed, 3 Sep 2014 10:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14460; q=dns/txt; s=iport; t=1409764214; x=1410973814; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VbwH0DfCdT8TrXH/NoTFpgRzwOjdpFZ31mSIpM5WVdo=; b=Og3JpL4S+/8B3zUqZ5P5I3+bCVUpsaFYnZ6Zq6Cggd5kRrDlIlfEIaaC tPan9XWrnMXqhOF5vtdN09/sZxi61Gi5cHqxGlhJMxlSJAN1rbnA03m/l gYWJEW/7Uhia6Aa4qYy6a/xH/PiJIKPiBx20M6vYgXyA2KDSyxRK5JwaH 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAEZKB1StJA2B/2dsb2JhbABZgw1TUwQEgnjFT4dQARl0FneEAwEBAQQjEUUMBAIBCBEEAQEBAgIGCxIDAgICMBQBCAgBAQQBDQUIAYg5CKhBlXQBF4EsiFSEfAEBHhYbBwYEgm82gR0FkTKGaJMthjSBZQQcgVxsgQ85gQcBAQE X-IronPort-AV: E=Sophos;i="5.04,458,1406592000"; d="scan'208";a="74629229" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP; 03 Sep 2014 17:10:12 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s83HACmn027406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Sep 2014 17:10:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 12:10:11 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Oleg Moskalenko Thread-Topic: [tram] draft-ietf-tram-turn-third-party-authz-03 Thread-Index: Ac/CnY2TUvE2dNeVQDqXwzAVxiaxZwFHJoQAAAiTSGA= Date: Wed, 3 Sep 2014 17:10:11 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28320FB9@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2831D2DB@xmb-rcd-x10.cisco.com> <54073B38.7020705@akamai.com> In-Reply-To: <54073B38.7020705@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.50.189] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/MiQ7Dp_tzwi7y55NkmeSYQsbVzk Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-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: Wed, 03 Sep 2014 17:10:56 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFtt YWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIFNl cHRlbWJlciAwMywgMjAxNCA5OjMxIFBNDQo+IFRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVk ZHkpOyBPbGVnIE1vc2thbGVua28NCj4gQ2M6IHRyYW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFt0cmFtXSBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMw0KPiANCj4g T24gMDgvMjgvMjAxNCAwNDo1MyBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSB3cm90 ZToNCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogQnJhbmRvbiBX aWxsaWFtcyBbbWFpbHRvOmJyYW5kb24ud2lsbGlhbXNAYWthbWFpLmNvbV0NCj4gPj4gU2VudDog V2VkbmVzZGF5LCBBdWd1c3QgMjcsIDIwMTQgMTI6MDAgQU0NCj4gPj4gVG86IFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSk7IE9sZWcgTW9za2FsZW5rbw0KPiA+PiBDYzogdHJhbUBpZXRmLm9y Zw0KPiA+PiBTdWJqZWN0OiBSZTogW3RyYW1dIGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBh cnR5LWF1dGh6LTAzDQo+ID4+DQo+ID4+IEkgZG9uJ3QgdGhpbmsgdGhhdCBpdCdzIHJlYXNvbmFi bGUgZm9yIHRoZSBjbGllbnQgdG8gc2VsZWN0IGEgc2luZ2xlDQo+ID4+IGF1dGggYWxnb3JpdGht IGZyb20gYSBsaXN0IG9mIHRob3NlIHN1cHBvcnRlZCBieSB0aGUgcmVsYXkgc2VydmVyLA0KPiA+ PiBiZWNhdXNlIHRoZXJlIGlzIGEgcmlzayB0aGF0IGl0IHdpbGwgc2VsZWN0IG9uZSB0aGF0IGRv ZXNuJ3QgbWVldCB0aGUNCj4gPj4gcG9saWN5IHJlcXVpcmVtZW50cyBiZWluZyBlbmZvcmNlZCBi eSB0aGUgb2F1dGggc2VydmVyLg0KPiA+DQo+ID4gV2h5IHNob3VsZCB0aGUgcG9saWN5IHJlcXVp cmVtZW50cyBlbmZvcmNlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXINCj4gY2FyZSBhYm91 dCB0aGUgYWxnb3JpdGhtIHVzZWQgYnkgdGhlIGNsaWVudCBhbmQgVFVSTiBzZXJ2ZXIgdG8gaW50 ZWdyaXR5DQo+IHByb3RlY3QgbWVzc2FnZXMgPw0KPiA+DQo+IA0KPiBJbiBhIDNyZCBwYXJ0eSBy ZWxheSBzZXJ2ZXIgc2NlbmFyaW8sIHRoZSBvd25lciBvZiB0aGUgT0F1dGggc2VydmVyIGlzDQo+ IHByb2JhYmx5IGEgY3VzdG9tZXIgb2YgdGhlIG93bmVyIG9mIHJlbGF5IHNlcnZlciwgbm90IHRo ZSBjbGllbnQsIHNvIHRoZQ0KPiBvd25lciBvZiB0aGUgT0F1dGggc2VydmVyIGhhcyBhIGJ1c2lu ZXNzIGludGVyZXN0IGluIHNlY3VyaW5nIGFjY2VzcyB0byB0aGUNCj4gcmVzb3VyY2VzIHRoYXQg aXQgaXMgcGF5aW5nIGZvci4gRm9yIHRoaXMgcmVhc29uLCB0aGUgb3duZXIgb2YgdGhlIE9BdXRo IHNlcnZlcg0KPiB3aWxsIGxpa2VseSBkZXNpcmUgdG8gaW1wb3NlIHJlcXVpcmVtZW50cyBvbiB0 aGUgaGFzaCBhbGdvcml0aG0gdXNlZC4gVGhlDQo+IG93bmVyIG9mIHRoZSBPQXV0aCBzZXJ2ZXIg aXMgYWxzbyB0aGUgb25lIHdobyBoYXMgdG8gZnVsZmlsbCByZWd1bGF0b3J5DQo+IHJlcXVpcmVt ZW50cyBpZi93aGVuIHRoZXkgYXBwbHkuDQoNCk9rYXksIGJ1dCB0aGUgVFVSTiBzZXJ2ZXIgY2Fu IGFsd2F5cyBtYWtlIHN1cmUgdGhhdCB0aGUgY2xpZW50IHBpY2tzIGFuIGFjY2VwdGFibGUgaGFz aCBhbGdvcml0aG0uIFRoZSBUVVJOIHNlcnZlciBhbHNvIGhhcyBhIHNlY3VyaXR5IGludGVyZXN0 IHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBjbGllbnQgZG9lcyBub3QgcGljayBzb21lIGluZmVyaW9y IGFsZ29yaXRobSB0aGF0IGlzIHN1c2NlcHRpYmxlIHRvIGF0dGFja3MuIFRoaXMgd2F5IGNsaWVu dCBjYW4gb25seSBzaWduYWwgdGhlIGhhc2ggYWxnb3JpdGhtIGZpbmFsaXplZCB3aXRoIHRoZSBU VVJOIHNlcnZlciB0byB0aGUgQXV0aG9yaXphdGlvbiBzZXJ2ZXIuICANCg0KSWYgeW91IGNvdWxk IGV4cGxhaW4gYXR0YWNrcyBwb3NzaWJsZSB3aXRoIHRoaXMgYXBwcm9hY2ggdGhlbiBpdCB3aWxs IGhlbHAgdGhlIGRpc2N1c3Npb24uDQoNCi1UaXJ1DQoNCj4gDQo+IC0tQnJhbmRvbg0KPiANCj4g Pj4NCj4gPj4gSW4gYWRkaXRpb24sIEkgdGhpbmsgdGhlIG9hdXRoIGFkbWluaXN0cmF0b3IgaGFz IHRvIGtub3cgdGhlDQo+ID4+IGFsZ29yaXRobXMgc3VwcG9ydGVkIGJ5IHRoZSByZWxheSBzZXJ2 ZXIgaW4gb3JkZXIgdG8gY29uZmlndXJlIGENCj4gcmVhc29uYWJsZSBwb2xpY3kuDQo+ID4NCj4g PiBBcyBwYXJ0IG9mIGNvbW11bmljYXRpb24gYmV0d2VlbiBhdXRob3JpemF0aW9uIHNlcnZlciBh bmQgcmVzb3VyY2UNCj4gc2VydmVyIHRvIGVzdGFibGlzaCBhIGxvbmctdGVybSBzeW1tZXRyaWMg a2V5LCByZXNvdXJjZSBzZXJ2ZXIgY2FuIGluZm9ybSB0aGUNCj4gYWxnb3JpdGhtcyBpdCBzdXBw b3J0cy4NCj4gPiBCdXQgd2hhdCBJIGRvbid0IHVuZGVyc3RhbmQgaXMgd2h5IHNob3VsZCBhdXRo b3JpemF0aW9uIHNlcnZlciBrbm93IHRoZQ0KPiBhbGdvcml0aG1zIHN1cHBvcnRlZCBieSB0aGUg cmVzb3VyY2Ugb3IgcmVsYXkgc2VydmVyID8NCj4gPiBEbyB5b3Ugc2VlIHNvbWUgYXR0YWNrIG9y IHNlY3VyaXR5IGhvbGUgYmVjYXVzZSBvZiB3aGljaCB5b3UgYXJlDQo+IHN1Z2dlc3RpbmcgdGhp cyBhcHByb2FjaCA/DQo+ID4NCj4gPj4gSSBkb24ndCB0aGluayB0aGUgcG9saWN5IGNvbmZpZ3Vy YXRpb24gcmVxdWlyZW1lbnQgY2FuIGJlIG1ldCB3aXRoDQo+ID4+IGluLWJhbmQgY29tbXVuaWNh dGlvbiBvZiB0aGUgc3VwcG9ydGVkIGFsZ29yaXRobXMuDQo+ID4+DQo+ID4+IEkgYWdyZWUgdGhh dCB0aGUgY2xpZW50IGFuZCB0aGUgb2F1dGggc2VydmVyIGhhdmUgdG8gYWdyZWUgb24gdGhlDQo+ ID4+IGFsZ29yaXRobSBpbiBvcmRlciBmb3IgdGhlIG9hdXRoIHNlcnZlciB0byBzZW5kIGFuIGFw cHJvcHJpYXRlbHkgc2l6ZWQga2V5Lg0KPiA+DQo+ID4gT2theS4NCj4gPg0KPiA+PiBJJ20gc3Vn Z2VzdGluZw0KPiA+PiB0aGF0IHRoZSBhbGdvcml0aG0gc2hvdWxkIGJlIHNlbGVjdGVkIGJ5IHRo ZSBvYXV0aCBzZXJ2ZXIgZnJvbSBhbW9uZw0KPiA+PiB0aGUgdW5pb24gb2YgdGhlIHNldCBzdXBw b3J0ZWQgYnkgdGhlIGNsaWVudCBhbmQgdGhlIGFsZ29yaXRobQ0KPiA+PiBzdXBwb3J0ZWQgYnkg dGhlIHJlbGF5IHNlcnZlci4gSSdtIGFsc28gc3VnZ2VzdGluZyB0aGF0IHRoZSBjbGllbnQNCj4g Pj4gc2hvdWxkIG5vdCBiZSBhbGxvd2VkIHRvIGRlY2xhcmUgd2hhdCB0aGUgdW5pb24gc2V0IGlz LCB3aGljaCBpcyBhDQo+ID4+IHNob3J0Y29taW5nIG9mIGRlbGl2ZXJpbmcgdGhlIGluZm9ybWF0 aW9uIGluLWJhbmQuDQo+ID4+DQo+ID4+IEFsbCBvZiB0aGUgYWJvdmUgaGF2aW5nIGJlZW4gc2Fp ZCwgSSB0aGluayB0aGF0IHdlIG1heSBiZSBnZXR0aW5nDQo+ID4+IGFoZWFkIG9mIHRoZSBkaXNj dXNzaW9uLiBJcyB0aGVyZSBnZW5lcmFsIGFncmVlbWVudCB0aGF0IHdlIG5lZWQgdG8NCj4gPj4g Y29tZSB1cCB3aXRoIGEgbmV3IGhhc2ggYWdpbGl0eSBhcHByb2FjaCBmb3IgU1RVTj8NCj4gPg0K PiA+IEkgdGhpbmsgU1RVTmJpcyB3aWxsIHByb3ZpZGUgaGFzaCBhZ2lsaXR5IHN1cHBvcnQuIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC0NCj4gYXJjaGl2ZS93ZWIvdHJhbS9jdXJyZW50L21zZzAw MDAwLmh0bWwgY2hhcnRlciBwcm9wb3NhbCBtZW50aW9ucw0KPiBzdXBwb3J0aW5nIGhhc2ggYWdp bGl0eS4NCj4gPg0KPiA+PiBBbmQgaWYgc28sIGhhcyBzb21lb25lIGFjdHVhbGx5IHRha2VuIHRo YXQgb24/IFdoYXQgd2UgY29tZSB1cCB3aXRoDQo+ID4+IG9uIGhhc2ggYWdpbGl0eSBmb3IgM3Jk IHBhcnR5IGF1dGggbWF5IGRlcGVuZCB1cG9uIGhvdyBoYXNoIGFnaWxpdHkNCj4gPj4gaXMgcmVz b2x2ZWQgZm9yIFNUVU4gaW4gZ2VuZXJhbC4NCj4gPg0KPiA+IC1UaXJ1DQo+ID4NCj4gPj4NCj4g Pj4gLS1CcmFuZG9uDQo+ID4+DQo+ID4+IE9uIDA4LzI2LzIwMTQgMDI6MTkgQU0sIFRpcnVtYWxl c3dhciBSZWRkeSAodGlyZWRkeSkgd3JvdGU6DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4+PiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFttYWlsdG86YnJhbmRvbi53aWxs aWFtc0Bha2FtYWkuY29tXQ0KPiA+Pj4+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDI1LCAyMDE0IDEx OjIwIFBNDQo+ID4+Pj4gVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IE9sZWcgTW9z a2FsZW5rbw0KPiA+Pj4+IENjOiB0cmFtQGlldGYub3JnDQo+ID4+Pj4gU3ViamVjdDogUmU6IFt0 cmFtXSBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMw0KPiA+Pj4+DQo+ ID4+Pj4gV2h5IHNob3VsZCBpdCBiZSBuZWNlc3NhcnkgZm9yIHRoZSBUVVJOIHNlcnZlciB0byBz ZW5kIGEgbGlzdD8NCj4gPj4+PiBDYW4ndCB0aGUgbGlzdCBvZiBzdXBwb3J0ZWQgYXV0aCBhbGdv cml0aG1zIGJlIGFncmVlZCB1cG9uIGJldHdlZW4NCj4gPj4+PiB0aGUgcmVsYXkgYW5kIG9hdXRo IHNlcnZlcnMgb3V0LW9mLWJhbmQgbGlrZSB0aGUgb3RoZXIgc2VjdXJpdHkNCj4gPj4+PiBwYXJh bWV0ZXJzPyBBbmQgaG93IGlzIHRoaXMgYmV0dGVyIHRoYW4gYSBtb3JlIHR5cGljYWwgbW9kZWwN Cj4gPj4+PiB3aGVyZWluIHRoZSBjbGllbnQgYWR2ZXJ0aXNlcyBpdHMgY2FwYWJpbGl0aWVzIGFu ZCB0aGUgc2VydmVyIGVuZm9yY2VzIGl0cw0KPiBwb2xpY3k/DQo+ID4+Pg0KPiA+Pj4gQm90aCBt b2RlbHMgd2lsbCB3b3JrIGFuZCBldmVuIGluIHRoZSBhYm92ZSBjYXNlIGNsaWVudCB3aWxsIGhh dmUgdG8NCj4gPj4+IHNpZ25hbA0KPiA+PiB0aGUgYWxnb3JpdGhtIHRvIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBzbyBhcyB0byBnZXQga2V5IHdpdGggY29ycmVjdA0KPiBsZW5ndGguDQo+ID4+ IEluIHRoZSBiZWxvdyBwcm9wb3NhbCwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgbGlzdCBvZiBzdXBw b3J0ZWQNCj4gPj4gYXV0aGVudGljYXRpb24gYWxnb3JpdGhtcyB0byBiZSBhZ3JlZWQgdXBvbiBi ZXR3ZWVuIHRoZSBSUyBhbmQgQVMNCj4gc2VydmVycy4NCj4gPj4+DQo+ID4+PiAtVGlydQ0KPiA+ Pj4NCj4gPj4+Pg0KPiA+Pj4+IC0tQnJhbmRvbg0KPiA+Pj4+DQo+ID4+Pj4gT24gMDgvMjUvMjAx NCAwMToyNyBQTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSB3cm90ZToNCj4gPj4+Pj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+PiBGcm9tOiBCcmFuZG9uIFdpbGxp YW1zIFttYWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPiA+Pj4+Pj4gU2VudDog TW9uZGF5LCBBdWd1c3QgMjUsIDIwMTQgMTA6NDAgUE0NCj4gPj4+Pj4+IFRvOiBUaXJ1bWFsZXN3 YXIgUmVkZHkgKHRpcmVkZHkpOyBPbGVnIE1vc2thbGVua28NCj4gPj4+Pj4+IENjOiB0cmFtQGll dGYub3JnDQo+ID4+Pj4+PiBTdWJqZWN0OiBSZTogW3RyYW1dIGRyYWZ0LWlldGYtdHJhbS10dXJu LXRoaXJkLXBhcnR5LWF1dGh6LTAzDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSSBkb24ndCB0aGluayB0 aGF0IHRoZSBjbGllbnQgd2lsbCBiZSAob3IgY2FuIHNhZmVseSBiZSBhbGxvdyB0bw0KPiA+Pj4+ Pj4gYmUpIHJlc3BvbnNpYmxlIGZvciBzZWxlY3RpbmcgdGhlIGFsZ29yaXRobS4gU29tZWhvdywg dGhpcw0KPiA+Pj4+Pj4gZGVjaXNpb24gbXVzdCBiZSB1cCB0byB0aGUgT0F1dGggc2VydmVyLiBU aGUgbW9zdCB0aGF0IEkgdGhpbmsNCj4gPj4+Pj4+IHRoZSBjbGllbnQgY2FuIGRvIGlzIHNlbmQg YSBsaXN0IG9mIHdoYXQgaXQgc3VwcG9ydHMsIHdoaWNoIHdpbGwNCj4gPj4+Pj4+IGFsbG93IHRo ZSBzZXJ2ZXIgdG8gc2VsZWN0IHRoZSBiZXN0IG9mIHRoZSBidW5jaCAob3IgcmVqZWN0IGlmDQo+ ID4+Pj4+PiBub25lIGFyZSBnb29kDQo+ID4+IGVub3VnaCkuDQo+ID4+Pj4+DQo+ID4+Pj4+IEkg YW0gdGhpbmtpbmcgb3RoZXIgd2F5IGFyb3VuZC4gVFVSTiBzZXJ2ZXIgc2VuZHMgbGlzdHMgb2Yg SE1BQw0KPiA+Pj4+IGFsZ29yaXRobXMgaXQgc3VwcG9ydHMsIGNsaWVudCBwaWNrcyB0aGUgYWxn b3JpdGhtIGl0IHdvdWxkIGxpa2UgdG8NCj4gPj4+PiB1c2UgYW5kIGNvbnZleXMgaXQgdG8gdGhl IGF1dGhvcml6YXRpb24gc2VydmVyLiBPQXV0aCBoYXMgYWxyZWFkeQ0KPiA+Pj4+IGRlZmluZWQN Cj4gPj4gJ2FsZycNCj4gPj4+PiBwYXJhbWV0ZXIgZm9yIHRoZSBjbGllbnQgdG8gc2lnbmFsIHRo ZSBhbGdvcml0aG0gdG8gdGhlDQo+ID4+Pj4gYXV0aG9yaXphdGlvbg0KPiA+PiBzZXJ2ZXIuDQo+ ID4+Pj4+DQo+ID4+Pj4+IC1UaXJ1DQo+ID4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSSBoYXZl bid0IHJlYWQgdGhlIHJlZmVyZW5jZWQgZHJhZnQgb3IgeW91ciBwcm9wb3NlZCBjaGFuZ2VzIHNv DQo+ID4+Pj4+PiBpdCBtYXkgYmUgdGhhdCB5b3UndmUgYWxyZWFkeSBkZWFsdCB3aXRoIHRoaXMg cGFydCBvZiB0aGUgcHJvYmxlbS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAtLUJyYW5kb24NCj4gPj4+ Pj4+DQo+ID4+Pj4+PiBPbiAwOC8yNS8yMDE0IDEyOjUwIFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkg KHRpcmVkZHkpIHdyb3RlOg0KPiA+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+Pj4+Pj4+PiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFttYWlsdG86YnJhbmRvbi53aWxsaWFt c0Bha2FtYWkuY29tXQ0KPiA+Pj4+Pj4+PiBTZW50OiBNb25kYXksIEF1Z3VzdCAyNSwgMjAxNCA4 OjA2IFBNDQo+ID4+Pj4+Pj4+IFRvOiBPbGVnIE1vc2thbGVua287IFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkNCj4gPj4+Pj4+Pj4gQ2M6IHRyYW1AaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4gU3Vi amVjdDogUmU6IFt0cmFtXSBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0w Mw0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBJIGFncmVlIHRoYXQgdGhlIDUzODkgaGFzaCBhZ2ls aXR5IHBsYW4gc2VlbXMgcHJvYmxlbWF0aWMgYW5kDQo+ID4+Pj4+Pj4+IHNob3VsZCBiZSByZXBs YWNlZCB3aXRoIHNvbWV0aGluZyBtb3JlIHN1aXRhYmxlIHRvIHRoZSBzdGF0ZWQNCj4gPj4+Pj4+ Pj4gcHVycG9zZS4gVGhhdCBzaG91bGQgcHJvYmFibHkgYmUgcGFydCBvZiB0aGUgc3R1bi1iaXMg ZWZmb3J0LA0KPiA+Pj4+Pj4+PiBvciBhdCBoYXBwZW4gY29uY3VycmVudGx5IHNvIHRoYXQgc3R1 bi1iaXMgY2FuIHJlZmVyZW5jZSB0aGUNCj4gPj4+Pj4+Pj4gcmVsZXZhbnQNCj4gPj4+PiBkb2N1 bWVudC4NCj4gPj4+Pj4+Pj4gQ29tcGxldGlvbiBvZiB0aGlzIGVmZm9ydCBtaWdodCBiZSBhIHJl cXVpcmVtZW50IGZvciBwdWJsaXNoaW5nDQo+ID4+Pj4+Pj4+IHRoZSAzcmQgcGFydHkgYXV0aCBk cmFmdCwgYmVjYXVzZSB3ZSBkb24ndCB3YW50IHRvIGVuZCB1cA0KPiA+Pj4+Pj4+PiBwdWJsaXNo aW5nIGEgZHJhZnQgdGhhdCByZXF1aXJlcyBhbiBpbW1lZGlhdGUgdXBkYXRlIGluIG9yZGVyDQo+ ID4+Pj4+Pj4+IHRvIHNhdGlzZnkgYQ0KPiA+Pj4+Pj4+PiBub3QteWV0LQ0KPiA+Pj4+Pj4gd3Jp dHRlbiBoYXNoIGFnaWxpdHkgcmVxdWlyZW1lbnQuDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IFRo ZSBhcmVhIHRoYXQgSSB0aGluayBpcyBtb3N0IGxpa2VseSB0byBiZSBjaGFsbGVuZ2luZyB3aXRo IHRoZQ0KPiA+Pj4+Pj4+PiBjdXJyZW50IDNyZCBwYXJ0eSBhdXRoIGRyYWZ0IGlzIGFsZ29yaXRo bSBpZGVudGlmaWNhdGlvbi4gSXQNCj4gPj4+Pj4+Pj4gd2lsbCBiZSBuZWNlc3NhcnkgYXQgc29t ZSBwb2ludCBpbiB0aGUgZnV0dXJlIGZvciB0aGUgVFVSTg0KPiA+Pj4+Pj4+PiBzZXJ2ZXIgdG8g c2VsZWN0IGZyb20gYW1vbmcgbXVsdGlwbGUgc3VwcG9ydGVkIGF1dGggYWxnb3JpdGhtcywNCj4g Pj4+Pj4+Pj4gYnV0IHRoZXJlIGlzIG5vIG9idmlvdXMgd2F5IGF0IHRoZSBtb21lbnQgZm9yIHRo ZSBhdXRoDQo+ID4+Pj4+Pj4+IGFsZ29yaXRobSB0byBiZSBjb21tdW5pY2F0ZWQgZnJvbSB0aGUg YXV0aCBzZXJ2ZXIgdG8gZWl0aGVyIHRoZQ0KPiA+Pj4+Pj4+PiBjbGllbnQgb3IgdGhlIFRVUk4g c2VydmVyLiBUaGUgb25seSB2YWx1ZSB0aGF0IGNvdWxkIGN1cnJlbnRseQ0KPiA+Pj4+Pj4+PiBi ZSB1c2VkIHRvIGd1ZXNzIHRoZSBhdXRoIGFsZ29yaXRobSBpcyB0aGUga2V5X2xlbmd0aCBpbiB0 aGUNCj4gPj4+Pj4+Pj4gdG9rZW4sIGJ1dCB1c2luZyBrZXlfbGVuZ3RoIGFzIGFuIGFsZ29yaXRo bSBpZGVudGlmaWVyIHNlZW1zDQo+ID4+Pj4+Pj4+IHJpc2t5LCBldmVuIGlmIGl0IHdvdWxkIHdv cmsgd2l0aCB0aGUgbW9zdCBsaWtlbHkNCj4gPj4+Pj4+IGNhbmRpZGF0ZXMgdG9kYXkuDQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+PiBJIGhhdmUgdXBkYXRlZCB0aGUgZHJhZnQgdG8gYWRkcmVzcyB0aGUg cHJvYmxlbSBpbiB0aGUgZm9sbG93aW5nDQo+IHdheToNCj4gPj4+Pj4+PiBXaGVuIFNUVU4gc3Vw cG9ydHMgSE1BQyBhbGdvcml0aG1zIG90aGVyIHRoYW4gSE1BQy1TSEEtMQ0KPiB0aGVuDQo+ID4+ Pj4gY2xpZW50DQo+ID4+Pj4+Pj4gd2lsbCBjb252ZXkgdGhlIGFsZ29yaXRobSBuZWdvdGlhdGVk IHdpdGggdGhlIFRVUk4gc2VydmVyIHRvDQo+ID4+Pj4+Pj4gdGhlDQo+ID4+Pj4+PiBhdXRob3Jp emF0aW9uIHNlcnZlciBpbiB0aGUgdmFsdWUgb2YgJ2FsZycgcGFyYW1ldGVyIGRlZmluZWQgaW4N Cj4gPj4+Pj4+IFtJLUQuaWV0Zi1vYXV0aC0gcG9wLWtleS1kaXN0cmlidXRpb25dLiAgQXV0aG9y aXphdGlvbiBzZXJ2ZXINCj4gPj4+Pj4+IGRldGVybWluZXMgbGVuZ3RoIG9mIHRoZSBtYWNfa2V5 IGJhc2VkIG9uIHRoZSBITUFDIGFsZ29yaXRobQ0KPiA+Pj4+IGNvbnZleWVkIGJ5IHRoZSBjbGll bnQuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAtVGlydQ0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+IC0tQnJhbmRvbg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBPbiAwOC8yMy8yMDE0 IDAyOjQ3IEFNLCBPbGVnIE1vc2thbGVua28gd3JvdGU6DQo+ID4+Pj4+Pj4+PiBBbm90aGVyIHBy b2JsZW0gaXMgdGhhdCBJIGFtIG5vdCBzdXJlIHRoYXQgdGhlIGhhc2ggYWdpbGl0eQ0KPiA+Pj4+ Pj4+Pj4gcGxhbiBpZGVhIGRlc2NyaWJlZCBpbiBSRkM1Mzg5IGlzIHN0aWxsIHZhbGlkLiBJIGFt IGFmcmFpZA0KPiA+Pj4+Pj4+Pj4gdGhhdCBpdCBpcyB1bm5lY2Vzc2FyeSBjb21wbGljYXRlZCBh bmQgb3V0ZGF0ZWQsIHRha2luZyBpbnRvDQo+ID4+Pj4+Pj4+PiBhY2NvdW50IHRoZSBjdXJyZW50 IGxldmVsIG9mDQo+ID4+Pj4+Pj4+PiBTSEEtMjU2IGFkb3B0aW9uLiBUaGUgcGxhbiB3YXMgZGVz aWduZWQgdG8gc3VwcG9ydCwNCj4gPj4+Pj4+Pj4+ICJ0cmFuc3BhcmVudGx5IiwgdGhlIG9sZCBU VVJOIHNlcnZlcnMuIEJ1dCBpbiB0aGVzZSBzcGVjcywgd2UNCj4gPj4+Pj4+Pj4+IGRvIG5vdCBu ZWNlc3NhcnkgaGF2ZSB0byBzdXBwb3J0IHRoZSAib2xkIiBzZXJ2ZXJzIHdpdGgNCj4gPj4+Pj4+ Pj4+IEhNQUMtU0hBLTEgb25seSBpbXBsZW1lbnRhdGlvbnM7IGFzIHdlIGFyZSB3cml0aW5nIGEg bmV3DQo+IG9BdXRoDQo+ID4+Pj4+Pj4+PiBwcm9jZWR1cmUsIHRoZXJlDQo+ID4+Pj4gd2lsbCBi ZSBvbmx5ICJuZXciDQo+ID4+Pj4+Pj4+PiBzZXJ2ZXJzIHN1cHBvcnRpbmcgdGhlIGRyYWZ0IHNw ZWNzLCBhbnl3YXkuIFRoZSAib2xkIiBzZXJ2ZXJzDQo+ID4+Pj4+Pj4+PiB3aWxsIG5vdCBiZSBh YmxlIHRvIHVzZSB0aGUgb0F1dGggc3BlY3MuIFNPIHdlIGNhbiBkZXNpZ24gYQ0KPiA+Pj4+Pj4+ Pj4gY2xlYW5lciBzaW1wbGVyIGhhc2ggYWdpbGl0eSBwcm9jZWR1cmUuDQo+ID4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+IC0tDQo+ID4+Pj4+Pj4+IEJyYW5kb24gV2lsbGlhbXM7IFNlbmlvciBQcmluY2lw YWwgU29mdHdhcmUgRW5naW5lZXIgRW1lcmdpbmcNCj4gPj4+Pj4+Pj4gUHJvZHVjdHMgRW5naW5l ZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IC0tDQo+ ID4+Pj4+PiBCcmFuZG9uIFdpbGxpYW1zOyBTZW5pb3IgUHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2lu ZWVyIEVtZXJnaW5nDQo+ID4+Pj4+PiBQcm9kdWN0cyBFbmdpbmVlcmluZzsgQWthbWFpIFRlY2hu b2xvZ2llcyBJbmMuDQo+ID4+Pj4NCj4gPj4+PiAtLQ0KPiA+Pj4+IEJyYW5kb24gV2lsbGlhbXM7 IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXIgRW1lcmdpbmcNCj4gPj4+PiBQcm9k dWN0cyBFbmdpbmVlcmluZzsgQWthbWFpIFRlY2hub2xvZ2llcyBJbmMuDQo+ID4+DQo+ID4+IC0t DQo+ID4+IEJyYW5kb24gV2lsbGlhbXM7IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5l ZXIgRW1lcmdpbmcNCj4gPj4gUHJvZHVjdHMgRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dp ZXMgSW5jLg0KPiANCj4gLS0NCj4gQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBhbCBT b2Z0d2FyZSBFbmdpbmVlciBFbWVyZ2luZyBQcm9kdWN0cw0KPiBFbmdpbmVlcmluZzsgQWthbWFp IFRlY2hub2xvZ2llcyBJbmMuDQo= From nobody Wed Sep 3 10:41:07 2014 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 161FE1A03B7; Wed, 3 Sep 2014 10:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 1iX16cgQYVnP; Wed, 3 Sep 2014 10:40:52 -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 928D81A03BC; Wed, 3 Sep 2014 10:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5037; q=dns/txt; s=iport; t=1409766048; x=1410975648; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=58DiwpXQ+oUV0JUWXaOwTJIBg2PCuyGlytfA2A5R66o=; b=bgeug+V5iafkABj9g6WrdzGMCLfaswwLMH5SGFsexmm90xrstQZ78oMS 5PZwpQFfgwVE3O1YmBtOi+kIZTNmyJYTgc2l8GyH0d/sNKj3jxMeJds1J 8VVoGQfrBWwI4RZzoHJSWnrXEOHGekhEfulIO79q+jRV+yRvU5AQ1xMWS 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAABSB1StJA2E/2dsb2JhbABZgw1TUwQEyEEMh0oBgQ0Wd4QDAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCAGIMQgIBb42AReOdgYBAR4xBwaDKYEdBZEyhC6IWJNDgWkcgVxsAYEGAQcXBhyBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,458,1406592000"; d="scan'208";a="74583111" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP; 03 Sep 2014 17:40:47 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s83Hel1Q001238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Sep 2014 17:40:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 12:40:47 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.txt Thread-Index: AQHPwdwflerwR/6zbESoNvi+uBdM05vv14+A///Y59A= Date: Wed, 3 Sep 2014 17:40:47 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A283220C0@xmb-rcd-x10.cisco.com> References: <20140827094830.9888.36362.idtracker@ietfa.amsl.com> <54072639.6030809@akamai.com> In-Reply-To: <54072639.6030809@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.50.189] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/J4sWqWDU4BB69oYa7gsYicUk_JY Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.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, 03 Sep 2014 17:40:55 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Wednesday, September 03, 2014 8:01 PM > To: internet-drafts@ietf.org; i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02= .txt >=20 > I see the following new text related to hash algorithm agility in the new= draft. >=20 > "Discussion: When STUN supports HMAC algorithms other than HMAC-SHA-1 > then client will convey the algorithm negotiated with the TURN server to = the > authorization server in the value of 'alg' parameter defined in [I-D.ietf= -oauth- > pop-key-distribution]. Authorization server determines length of the > mac_key based on the HMAC algorithm conveyed by the client." >=20 > I've got two concerns about this, which are both just reiterations of thi= ngs > I've mentioned previously on the list. First, I think it may be premature= to say > anything about hash agility in this draft until we've settled the questio= n more > broadly in stunbis.=20 The questions before us are: Do we want to stall progress on this draft till hash agility is finalized i= n STUNbis OR=20 Have a discussion right now, finalize the behavior and update the draft OR Don't discuss about hash agility in the draft and take it forward ? > Second, I think the OAuth server must be in a position to > enforce policy on the minimum acceptable hash algorithm, and so allowing > the client to pick one makes the mechanism more fragile. It may be > preferable for the client to signal it's full list of capabilities in the= request and > for the server to signal its selection from among the options (or an erro= r if > nothing from the client's list is considered acceptable). I have responded to the above suggestion in another mail thread. >=20 > On a separate note, I was reminded by the meeting notes that I promised t= o > send some comments to the list about resource utilization. Customers of a > 3rd party service will often have contracts that limit resource utilizati= on. > There may be limits in terms of the total number of concurrent end-to-end > streams, aggregate bandwidth, etc. Considering this, it may be necessary = for > the OAuth server to authorize the client for a certain maximum utilizatio= n to > be associated with the ACCESS-TOKEN. Although it could make the token > larger, I think it may be important to include this authorized utilizatio= n > information within the token. Does anyone have any thoughts about this? > Perhaps an alternate way to handle the same concern ? The two possible approaches for solving the problem are discussed in http:/= /tools.ietf.org/html/draft-hardjono-oauth-umacore-10#section-3.3 and I don'= t think we should complicate the draft with token profile. Probably take up= this effort as a separate draft. -Tiru >=20 > --Brandon >=20 > On 08/27/2014 05:48 AM, 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 Extension for Third Party Authorization > > Authors : Tirumaleswar Reddy > > Prashanth Patil > > Ram Mohan Ravindranath > > Justin Uberti > > Filename : draft-ietf-tram-turn-third-party-authz-02.txt > > Pages : 16 > > Date : 2014-08-27 > > > > Abstract: > > This document proposes the use of OAuth to obtain and validate > > ephemeral tokens that can be used for TURN authentication. The usa= ge > > of ephemeral tokens ensure that access to a TURN server can be > > controlled even if the tokens are compromised. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz= / > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-third-party-aut= hz-02 > > > > > > 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 > > >=20 > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Sep 3 10:46:38 2014 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 393A51A03B4 for ; Wed, 3 Sep 2014 10:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 syAav0pPPrU7 for ; Wed, 3 Sep 2014 10:46:33 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 798741A02DB for ; Wed, 3 Sep 2014 10:46:33 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DF90A47699; Wed, 3 Sep 2014 17:46:32 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id D3B504756F; Wed, 3 Sep 2014 17:46:32 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 74C0380048; Wed, 3 Sep 2014 17:46:32 +0000 (GMT) Message-ID: <540753F8.6020700@akamai.com> Date: Wed, 03 Sep 2014 13:46:32 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <5407225B.5020005@akamai.com> <54074147.1000507@akamai.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/W8UAAXfqIsj51OP__D7ID4Jz6xs Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 03 Sep 2014 17:46:35 -0000 On 09/03/2014 12:55 PM, Oleg Moskalenko wrote: [snip] > Some examples might be helpful to implementers, especially to help > them get the security aspects of the token right. For example, if > there's no source of entropy, then the encrypt and auth results may > be problematic. Your example of a random series of bytes is fine in > this regard, but if someone where to do what the spec appears to be > suggesting and nothing more, that would not be particularly good. > > > I'd leave that to the implementation completely - we can just impose a > requirement that the token's meaning must be known only to the server. > How it is achieved - by using random string of bytes or by using really > good encryption - let the implementation to decide. I personally think > that the means of hiding information are not relevant in this context > because there are no parties in the information exchange - the > information is going from server to the same server; we do not have to > set standards when we do not have interacting parties. That's up to the > server what to do with its own information. If the server implementation > is bad and it cannot hide its own information - well, then it means that > this is a bad program. > > Let's not set standards when they do not have a useful purpose. The security considerations section of the document currently states "TURN server MUST use strong encryption and integrity protection for the ticket", so simply using a random string of bytes for the ticket, as you seem to be suggesting, is not allowed by the current draft. I think my primary point is that the security considerations section needs more work. It's not enough to just use strong encryption and integrity protection algorithms. It's also important to ensure that the resulting encrypted token is not easily predictable (and therefore easily reusable), which is why a source of entropy is important. --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Sep 3 10:54:44 2014 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 D107A1A040F for ; Wed, 3 Sep 2014 10:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 NrTGnseOYiHM for ; Wed, 3 Sep 2014 10:54:39 -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 918F11A0475 for ; Wed, 3 Sep 2014 10:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1770; q=dns/txt; s=iport; t=1409766879; x=1410976479; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dFUQ72FUzWY+6Yo2X+xrhyN4hMHWPL8kXRz8+cNYe+M=; b=U6/O4aWGy4Djf7SGByMCMPJYTCnBqLpkNply1p7EcoGDEzogwarOtwaf TCIufDLNpLsQi3sP7RRjLTZLLqS1yFW34eYOpIgyIp2/XOrcGY1jh25xQ ZvWw+wufrWjqAXX4kNHaGszVGHBb9/cwKZE5ptN6xG95K9lz5FuTJnrkV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAJZUB1StJA2G/2dsb2JhbABZgw2BIAoE0BcBgQ0Wd4QDAQEBBDo/DAQCAQgRBAEBHwkHMhQJCAIEDgWIQr5TARePGjMHBoMpgR0BBJEyiyuVHoFpHIFcbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,459,1406592000"; d="scan'208";a="74634823" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 03 Sep 2014 17:54:39 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s83HscAG027365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Sep 2014 17:54:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.173]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 12:54:38 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.txt Thread-Index: AQHPwdwflerwR/6zbESoNvi+uBdM05vv14+A///Y59CAAF/kgA== Date: Wed, 3 Sep 2014 17:54:38 +0000 Message-ID: <00212B0F-6421-4FA2-B6E0-980E11154957@cisco.com> References: <20140827094830.9888.36362.idtracker@ietfa.amsl.com> <54072639.6030809@akamai.com> <913383AAA69FF945B8F946018B75898A283220C0@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A283220C0@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.154.216] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/au68GUMFHkWPgJKvtkAh1wqTS48 Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.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, 03 Sep 2014 17:54:42 -0000 On Sep 3, 2014, at 1:40 PM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Wednesday, September 03, 2014 8:01 PM >> To: internet-drafts@ietf.org; i-d-announce@ietf.org >> Cc: tram@ietf.org >> Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-0= 2.txt >>=20 >> I see the following new text related to hash algorithm agility in the ne= w draft. >>=20 >> "Discussion: When STUN supports HMAC algorithms other than HMAC-SHA-1 >> then client will convey the algorithm negotiated with the TURN server to= the >> authorization server in the value of 'alg' parameter defined in [I-D.iet= f-oauth- >> pop-key-distribution]. Authorization server determines length of the >> mac_key based on the HMAC algorithm conveyed by the client." >>=20 >> I've got two concerns about this, which are both just reiterations of th= ings >> I've mentioned previously on the list. First, I think it may be prematur= e to say >> anything about hash agility in this draft until we've settled the questi= on more >> broadly in stunbis.=20 >=20 > The questions before us are: > Do we want to stall progress on this draft till hash agility is finalized= in STUNbis OR=20 > Have a discussion right now, finalize the behavior and update the draft O= R > Don't discuss about hash agility in the draft and take it forward ? My preference is we have the discussion and let the results of that feed in= to STUNbis. The draft can refer to STUNbis for all things hash agility. W= e have this on the list and plan to produce a version very soon, so I don't= expect long delays to this work. Cheers, Gonzalo From nobody Wed Sep 3 11:17:23 2014 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 D04DF1A0484 for ; Wed, 3 Sep 2014 11:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 aFNF4oy9LLQi for ; Wed, 3 Sep 2014 11:17:18 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id B24B51A047E for ; Wed, 3 Sep 2014 11:17:18 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 07A3E2859B; Wed, 3 Sep 2014 18:17:18 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id F399928576; Wed, 3 Sep 2014 18:17:17 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id EC76180048; Wed, 3 Sep 2014 18:17:17 +0000 (GMT) Message-ID: <54075B2D.9060806@akamai.com> Date: Wed, 03 Sep 2014 14:17:17 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A2831D2DB@xmb-rcd-x10.cisco.com> <54073B38.7020705@akamai.com> <913383AAA69FF945B8F946018B75898A28320FB9@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A28320FB9@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/nW33qRi1wTzj4EmCB2ZU14C34KY Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-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: Wed, 03 Sep 2014 18:17:22 -0000 On 09/03/2014 01:10 PM, Tirumaleswar Reddy (tireddy) wrote: [snip] >> In a 3rd party relay server scenario, the owner of the OAuth server is >> probably a customer of the owner of relay server, not the client, so the >> owner of the OAuth server has a business interest in securing access to the >> resources that it is paying for. For this reason, the owner of the OAuth server >> will likely desire to impose requirements on the hash algorithm used. The >> owner of the OAuth server is also the one who has to fulfill regulatory >> requirements if/when they apply. > > Okay, but the TURN server can always make sure that the client picks an acceptable hash algorithm. The TURN server also has a security interest to make sure that the client does not pick some inferior algorithm that is susceptible to attacks. This way client can only signal the hash algorithm finalized with the TURN server to the Authorization server. > > If you could explain attacks possible with this approach then it will help the discussion. > At a high level, what I have to do is tell my customers the list of supported algorithms and let them decide which ones make the most sense for them. It certainly is possible for the customer to tell me which algorithm they want to use ahead of time, in which case the TURN server can make the decision on their behalf. However, this is not ideal, because it requires the customer to interact directly with both my system (to make their selection) and their own system (to validate the selection). It is simpler for the customer if they only have to interact with their own system if they want to change security requirements. It is important for the TURN server to only have one algorithm that it could possibly select for the customer and for the customer to verify that this is the algorithm selected. If not, the system is susceptible to an algorithm downgrade by the client, since there is nothing that requires the client to signal the same algorithm to the OAuth server that it received from the TURN server. This is the attack vector that I would be concerned about. --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Sep 3 11:25:21 2014 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 569201A04B0 for ; Wed, 3 Sep 2014 11:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 vIfaSxIYHXIG for ; Wed, 3 Sep 2014 11:25:17 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id A26901A047B for ; Wed, 3 Sep 2014 11:25:17 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C658F47508; Wed, 3 Sep 2014 18:25:16 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id BAECE47500; Wed, 3 Sep 2014 18:25:16 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 95B7880052; Wed, 3 Sep 2014 18:25:16 +0000 (GMT) Message-ID: <54075D0C.3080608@akamai.com> Date: Wed, 03 Sep 2014 14:25:16 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" , "Tirumaleswar Reddy (tireddy)" References: <20140827094830.9888.36362.idtracker@ietfa.amsl.com> <54072639.6030809@akamai.com> <913383AAA69FF945B8F946018B75898A283220C0@xmb-rcd-x10.cisco.com> <00212B0F-6421-4FA2-B6E0-980E11154957@cisco.com> In-Reply-To: <00212B0F-6421-4FA2-B6E0-980E11154957@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/W1tr-OxH52l6iKaIvV0X8TcZQGk Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.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, 03 Sep 2014 18:25:19 -0000 Agreed. We don't have to have a finalized stunbis. We just need to have a reasonable idea what the mechanism will look like. --Brandon On 09/03/2014 01:54 PM, Gonzalo Salgueiro (gsalguei) wrote: > > On Sep 3, 2014, at 1:40 PM, Tirumaleswar Reddy (tireddy) wrote: > >>> -----Original Message----- >>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >>> Sent: Wednesday, September 03, 2014 8:01 PM >>> To: internet-drafts@ietf.org; i-d-announce@ietf.org >>> Cc: tram@ietf.org >>> Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.txt >>> >>> I see the following new text related to hash algorithm agility in the new draft. >>> >>> "Discussion: When STUN supports HMAC algorithms other than HMAC-SHA-1 >>> then client will convey the algorithm negotiated with the TURN server to the >>> authorization server in the value of 'alg' parameter defined in [I-D.ietf-oauth- >>> pop-key-distribution]. Authorization server determines length of the >>> mac_key based on the HMAC algorithm conveyed by the client." >>> >>> I've got two concerns about this, which are both just reiterations of things >>> I've mentioned previously on the list. First, I think it may be premature to say >>> anything about hash agility in this draft until we've settled the question more >>> broadly in stunbis. >> >> The questions before us are: >> Do we want to stall progress on this draft till hash agility is finalized in STUNbis OR >> Have a discussion right now, finalize the behavior and update the draft OR >> Don't discuss about hash agility in the draft and take it forward ? > > My preference is we have the discussion and let the results of that feed into STUNbis. The draft can refer to STUNbis for all things hash agility. We have this on the list and plan to produce a version very soon, so I don't expect long delays to this work. > > Cheers, > > Gonzalo > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Sep 3 11:48:18 2014 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 38C591A06D1 for ; Wed, 3 Sep 2014 11:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=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 dTQBigQGoqFE for ; Wed, 3 Sep 2014 11:48:05 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143991A0689 for ; Wed, 3 Sep 2014 11:48:04 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id ex7so10434274wid.1 for ; Wed, 03 Sep 2014 11:48: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=deixfEzuZXA9j3ZbHixZb9pKFq0ieu8f9gP01KKPNno=; b=QFfHHVj8eocLM5Uoh/zDlx5cQ/bvydogTUfb/V9AH+4UYLpl1dfFJvOvpt6zRXJ30A 6XHsyf0rL3wVtCD8OVDUrOWFRPDT4ADsET2Q6hcmaAPXDQRWjoRWnqVK2Y7m6TZJi32j GWrWC1NDQgVGTRSMMLDydd+MjgxUXFRTrTxo50C9EFOSCbxzWNHw8WjtQXfQgzZgSISp RhHkPwPnQMdhd2m6kELPZv0Z8VoUsjEjfq56n8bXx5X4cLIEA2MX1UWTnx4+HpqfZSls OabLGs/0CPDN+hkac5OUb1eqV/U7Ey4fiWclE0PBCZ321k3XaMwMLWaSiTL60d1EVMmH PPqA== MIME-Version: 1.0 X-Received: by 10.194.5.234 with SMTP id v10mr48925545wjv.45.1409770083649; Wed, 03 Sep 2014 11:48:03 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Wed, 3 Sep 2014 11:48:03 -0700 (PDT) In-Reply-To: <540753F8.6020700@akamai.com> References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <5407225B.5020005@akamai.com> <54074147.1000507@akamai.com> <540753F8.6020700@akamai.com> Date: Wed, 3 Sep 2014 11:48:03 -0700 Message-ID: From: Oleg Moskalenko To: Brandon Williams Content-Type: multipart/alternative; boundary=047d7b5d2fde0d10cc05022dad1f Archived-At: http://mailarchive.ietf.org/arch/msg/tram/_6Ae1aHU9RFl80BFWLrtHW1pxIM Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 03 Sep 2014 18:48:07 -0000 --047d7b5d2fde0d10cc05022dad1f Content-Type: text/plain; charset=UTF-8 On Wed, Sep 3, 2014 at 10:46 AM, Brandon Williams < brandon.williams@akamai.com> wrote: > On 09/03/2014 12:55 PM, Oleg Moskalenko wrote: > > [snip] > > > Some examples might be helpful to implementers, especially to help >> them get the security aspects of the token right. For example, if >> there's no source of entropy, then the encrypt and auth results may >> be problematic. Your example of a random series of bytes is fine in >> this regard, but if someone where to do what the spec appears to be >> suggesting and nothing more, that would not be particularly good. >> >> >> I'd leave that to the implementation completely - we can just impose a >> requirement that the token's meaning must be known only to the server. >> How it is achieved - by using random string of bytes or by using really >> good encryption - let the implementation to decide. I personally think >> that the means of hiding information are not relevant in this context >> because there are no parties in the information exchange - the >> information is going from server to the same server; we do not have to >> set standards when we do not have interacting parties. That's up to the >> server what to do with its own information. If the server implementation >> is bad and it cannot hide its own information - well, then it means that >> this is a bad program. >> >> Let's not set standards when they do not have a useful purpose. >> > > The security considerations section of the document currently states "TURN > server MUST use strong encryption and integrity protection for the ticket", > so simply using a random string of bytes for the ticket, as you seem to be > suggesting, is not allowed by the current draft. > You are not right. A random unique string of bytes, with the right degree of the entropy, is the ultimate form of encryption - when the information is hidden so that only the right entity can decrypt it. An encryption algorithm is useful when a stateless server implementation is used and some meaningful information is hidden in the ticket. But when the server is stateful, then a totally random unique bytes can be used - and the server can keep the information inside it, and the ticket is only a pointer to that information inside the server - so no information leak is possible. > > I think my primary point is that the security considerations section needs > more work. It's not enough to just use strong encryption and integrity > protection algorithms. It's also important to ensure that the resulting > encrypted token is not easily predictable (and therefore easily reusable), > which is why a source of entropy is important. > You are mixing two valid (but different) approaches to tickets. Let's not create a mess. If you are using a stateless server, and you are hiding information inside the ticket, then you have to use the encryption and integrity protection algorithm of good strengths. Then the entropy is NOT relevant at all in this case - because there is no randomness in the ticket. On the other hand, if you are using a stateful server, and no information is hidden inside the ticket, then indeed the server must use the proper ticket generation algorithm, so it would be difficult to predict. I think that the security section must mention these two approaches. > > --Brandon > > > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > --047d7b5d2fde0d10cc05022dad1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Sep 3, 2014 at 10:46 AM, Brandon Williams <brand= on.williams@akamai.com> wrote:

On 09/03/2014 12:55 PM, Oleg Moskalenko wrot= e:

[snip]

=C2=A0 =C2=A0 Some examples might be helpful to implementers, especially to= help
=C2=A0 =C2=A0 them get the security aspects of the token right. For example= , if
=C2=A0 =C2=A0 there's no source of entropy, then the encrypt and auth r= esults may
=C2=A0 =C2=A0 be problematic. Your example of a random series of bytes is f= ine in
=C2=A0 =C2=A0 this regard, but if someone where to do what the spec appears= to be
=C2=A0 =C2=A0 suggesting and nothing more, that would not be particularly g= ood.

I'd leave that to the implementation completely - we can just impose a<= br> requirement that the token's meaning must be known only to the server.<= br> How it is achieved - by using random string of bytes or by using really
good encryption - let the implementation to decide. I personally think
that the means of hiding information are not relevant in this context
because there are no parties in the information exchange - the
information is going from server to the same server; we do not have to
set standards when we do not have interacting parties. That's up to the=
server what to do with its own information. If the server implementation is bad and it cannot hide its own information - well, then it means that this is a bad program.

Let's not set standards when they do not have a useful purpose.

The security considerations section of the document currently states "= TURN server MUST use strong encryption and integrity protection for the tic= ket", so simply using a random string of bytes for the ticket, as you = seem to be suggesting, is not allowed by the current draft.

You are not right. A random unique string = of bytes, with the right degree of the entropy, is the ultimate form of enc= ryption - when the information is hidden so that only the right entity can = decrypt it. An encryption algorithm is useful when a stateless server imple= mentation is used and some meaningful information is hidden in the ticket. = But when the server is stateful, then a totally random unique bytes can be = used - and the server can keep the information inside it, and the ticket is= only a pointer to that information inside the server - so no information l= eak is possible.

=C2=A0

I think my primary point is that the security considerations section needs = more work. It's not enough to just use strong encryption and integrity = protection algorithms. It's also important to ensure that the resulting= encrypted token is not easily predictable (and therefore easily reusable),= which is why a source of entropy is important.

You are mixing two valid (bu= t different) approaches to tickets. Let's not create a mess.

If you are using a stateless server, and you are hiding information= inside the ticket, then you have to use the encryption and integrity prote= ction algorithm of good strengths. Then the entropy is NOT relevant at all = in this case - because there is no randomness in the ticket.

On the other hand, if you are using a stateful server, and n= o information is hidden inside the ticket, then indeed the server must use = the proper ticket generation algorithm, so it would be difficult to predict= .

I think that the security section must mention these two app= roaches.

=C2=A0

--Brandon

--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

--047d7b5d2fde0d10cc05022dad1f-- From nobody Wed Sep 3 14:12:16 2014 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 3A4521A884B for ; Wed, 3 Sep 2014 14:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 6lcQ1Vt6KYoq for ; Wed, 3 Sep 2014 14:12:13 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id F0AC61A8894 for ; Wed, 3 Sep 2014 14:04:23 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6F63247694; Wed, 3 Sep 2014 21:04:23 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 62DB247678; Wed, 3 Sep 2014 21:04:23 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 58B858004B; Wed, 3 Sep 2014 21:04:23 +0000 (GMT) Message-ID: <54078257.2090206@akamai.com> Date: Wed, 03 Sep 2014 17:04:23 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <5407225B.5020005@akamai.com> <54074147.1000507@akamai.com> <540753F8.6020700@akamai.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/jUzaOBGbshw6fnlFBqlPgcrMvRw Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 03 Sep 2014 21:12:15 -0000 On 09/03/2014 02:48 PM, Oleg Moskalenko wrote: > > > > On Wed, Sep 3, 2014 at 10:46 AM, Brandon Williams > > wrote: > > On 09/03/2014 12:55 PM, Oleg Moskalenko wrote: > > [snip] > > > Some examples might be helpful to implementers, especially > to help > them get the security aspects of the token right. For > example, if > there's no source of entropy, then the encrypt and auth > results may > be problematic. Your example of a random series of bytes is > fine in > this regard, but if someone where to do what the spec > appears to be > suggesting and nothing more, that would not be particularly > good. > > > I'd leave that to the implementation completely - we can just > impose a > requirement that the token's meaning must be known only to the > server. > How it is achieved - by using random string of bytes or by using > really > good encryption - let the implementation to decide. I personally > think > that the means of hiding information are not relevant in this > context > because there are no parties in the information exchange - the > information is going from server to the same server; we do not > have to > set standards when we do not have interacting parties. That's up > to the > server what to do with its own information. If the server > implementation > is bad and it cannot hide its own information - well, then it > means that > this is a bad program. > > Let's not set standards when they do not have a useful purpose. > > > The security considerations section of the document currently states > "TURN server MUST use strong encryption and integrity protection for > the ticket", so simply using a random string of bytes for the > ticket, as you seem to be suggesting, is not allowed by the current > draft. > > > You are not right. A random unique string of bytes, with the right > degree of the entropy, is the ultimate form of encryption - when the > information is hidden so that only the right entity can decrypt it. An > encryption algorithm is useful when a stateless server implementation is > used and some meaningful information is hidden in the ticket. But when > the server is stateful, then a totally random unique bytes can be used - > and the server can keep the information inside it, and the ticket is > only a pointer to that information inside the server - so no information > leak is possible. The question of whether a random string of bytes can be considered encryption has a lot to do with what that random string of bytes gives you access to. Providing that there are enough mechanisms in place to prevent me from doing anything useful with the random string of bytes (e.g. cut off access to a legitimate user by sending the token as if it were mine), then I agree with you that it can be considered a form of encryption because getting access to the raw token gives me nothing of value. That said, the same argument can be made for a token that contains encrypted TURN Allocation state information, in that the encryption only prevents you from seeing the state information. If you can get something useful simply by knowing the encrypted version of the token then there is something wrong with the way the token is being generated. I think it would be useful for the security considerations section of the document to make the argument that the token has no value of its own and to highlight the internal requirements of the TURN server implementation that ensure this will be true. > > I think my primary point is that the security considerations section > needs more work. It's not enough to just use strong encryption and > integrity protection algorithms. It's also important to ensure that > the resulting encrypted token is not easily predictable (and > therefore easily reusable), which is why a source of entropy is > important. > > > You are mixing two valid (but different) approaches to tickets. Let's > not create a mess. > > If you are using a stateless server, and you are hiding information > inside the ticket, then you have to use the encryption and integrity > protection algorithm of good strengths. Then the entropy is NOT relevant > at all in this case - because there is no randomness in the ticket. I disagree. If there is no source of entropy, then I can learn something from the ticket based on its encrypted form. For example, if I can see that every connection with the same client-side tuple ends up with exactly the same ticket, then I have most likely learned something about the unencrypted form of the ticket that will help me to crack the keys used to construct the ticket. If the source of entropy is built into the algorithm, then you're right that a good algorithm is good enough. However, some common encryption algorithms require the user to provide such entropy (e.g. via a random initialization vector). --Brandon > > On the other hand, if you are using a stateful server, and no > information is hidden inside the ticket, then indeed the server must use > the proper ticket generation algorithm, so it would be difficult to predict. > > I think that the security section must mention these two approaches. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Sep 3 14:32:43 2014 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 7B0861A6FCA for ; Wed, 3 Sep 2014 14:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=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 lLyePyy3Dx65 for ; Wed, 3 Sep 2014 14:32:40 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07961A6FD2 for ; Wed, 3 Sep 2014 14:29:13 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so1748830wiv.7 for ; Wed, 03 Sep 2014 14:29:11 -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=tEMEZMh65OD7xkF5IaMpczZdLcqOonvgQyHmMxqq/VI=; b=Ct/KTvnTj9JROfn6aoP01xjX394ZEbfjYiwXM9MpRmGM/Evwb1CWQ0ayx6wU5fpTiu 1mIFLvWbQxczC/EvIQT+y97tiB/Wc3npZ93uoKl33KwOm5qkQSv/UbQkepKX607lFB8y AZnPXDGLOvaegKrKRg8503zXnHpCXjeygPQ4yiU3VVQPpT18hPP0EaYC3CL+gCnUkUb5 pNZFdbx1jRePSwuXYhmZQoTWsrWZtgto6RlTmPhCUELTn9ioUC0snpIOvd5qwdEE8E+K pxRGHgzWrzA0KBWQEW1KNJvtLUgPTs/OPl5GeKuH1gGFRu+HK6K+/HB8MVrJs6/91qpB Nc2w== MIME-Version: 1.0 X-Received: by 10.180.103.234 with SMTP id fz10mr103529wib.76.1409779751678; Wed, 03 Sep 2014 14:29:11 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Wed, 3 Sep 2014 14:29:11 -0700 (PDT) In-Reply-To: <54078257.2090206@akamai.com> References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <5407225B.5020005@akamai.com> <54074147.1000507@akamai.com> <540753F8.6020700@akamai.com> <54078257.2090206@akamai.com> Date: Wed, 3 Sep 2014 14:29:11 -0700 Message-ID: From: Oleg Moskalenko To: Brandon Williams Content-Type: multipart/alternative; boundary=f46d04428f164f7ceb05022fede1 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/tiidgBP0ZGJDijseGUMkZzUUfck Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 03 Sep 2014 21:32:41 -0000 --f46d04428f164f7ceb05022fede1 Content-Type: text/plain; charset=UTF-8 please see below: On Wed, Sep 3, 2014 at 2:04 PM, Brandon Williams < brandon.williams@akamai.com> wrote: > On 09/03/2014 02:48 PM, Oleg Moskalenko wrote: > >> >> The security considerations section of the document currently states >> "TURN server MUST use strong encryption and integrity protection for >> the ticket", so simply using a random string of bytes for the >> ticket, as you seem to be suggesting, is not allowed by the current >> draft. >> >> >> You are not right. A random unique string of bytes, with the right >> degree of the entropy, is the ultimate form of encryption - when the >> information is hidden so that only the right entity can decrypt it. An >> encryption algorithm is useful when a stateless server implementation is >> used and some meaningful information is hidden in the ticket. But when >> the server is stateful, then a totally random unique bytes can be used - >> and the server can keep the information inside it, and the ticket is >> only a pointer to that information inside the server - so no information >> leak is possible. >> > > The question of whether a random string of bytes can be considered > encryption has a lot to do with what that random string of bytes gives you > access to. Providing that there are enough mechanisms in place to prevent > me from doing anything useful with the random string of bytes (e.g. cut off > access to a legitimate user by sending the token as if it were mine), then > I agree with you that it can be considered a form of encryption because > getting access to the raw token gives me nothing of value. > > That said, the same argument can be made for a token that contains > encrypted TURN Allocation state information, in that the encryption only > prevents you from seeing the state information. If you can get something > useful simply by knowing the encrypted version of the token then there is > something wrong with the way the token is being generated. > > I think it would be useful for the security considerations section of the > document to make the argument that the token has no value of its own and to > highlight the internal requirements of the TURN server implementation that > ensure this will be true. The normal user authentication is still in the picture. So if a wrong user uses the token that was granted to a different legitimate user, then the request will be rejected and the wrong user (that cannot authenticate itself as the original user) will not benefit by snooping the token. May be it is worth mentioning in the security section. > > > >> I think my primary point is that the security considerations section >> needs more work. It's not enough to just use strong encryption and >> integrity protection algorithms. It's also important to ensure that >> the resulting encrypted token is not easily predictable (and >> therefore easily reusable), which is why a source of entropy is >> important. >> >> >> You are mixing two valid (but different) approaches to tickets. Let's >> not create a mess. >> >> If you are using a stateless server, and you are hiding information >> inside the ticket, then you have to use the encryption and integrity >> protection algorithm of good strengths. Then the entropy is NOT relevant >> at all in this case - because there is no randomness in the ticket. >> > > I disagree. If there is no source of entropy, then I can learn something > from the ticket based on its encrypted form. For example, if I can see that > every connection with the same client-side tuple ends up with exactly the > same ticket, then I have most likely learned something about the > unencrypted form of the ticket that will help me to crack the keys used to > construct the ticket. If the source of entropy is built into the algorithm, > then you're right that a good algorithm is good enough. However, some > common encryption algorithms require the user to provide such entropy (e.g. > via a random initialization vector). > That's right, I agree with that part. > > --Brandon > > > >> On the other hand, if you are using a stateful server, and no >> information is hidden inside the ticket, then indeed the server must use >> the proper ticket generation algorithm, so it would be difficult to >> predict. >> >> I think that the security section must mention these two approaches. >> > > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > --f46d04428f164f7ceb05022fede1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

please see below:

<= br>

On Wed, Sep 3, 2014 at 2:04 PM, Brandon Willi= ams <brandon.williams@akamai.com> wrote:

On 09/03/2014 02:48 PM, Oleg= Moskalenko wrote:

=C2=A0 =C2=A0 The security considerations section of the document currently= states
=C2=A0 =C2=A0 "TURN server MUST use strong encryption and integrity pr= otection for
=C2=A0 =C2=A0 the ticket", so simply using a random string of bytes fo= r the
=C2=A0 =C2=A0 ticket, as you seem to be suggesting, is not allowed by the c= urrent
=C2=A0 =C2=A0 draft.

You are not right. A random unique string of bytes, with the right
degree of the entropy, is the ultimate form of encryption - when the
information is hidden so that only the right entity can decrypt it. An
encryption algorithm is useful when a stateless server implementation is used and some meaningful information is hidden in the ticket. But when
the server is stateful, then a totally random unique bytes can be used - and the server can keep the information inside it, and the ticket is
only a pointer to that information inside the server - so no information leak is possible.

The question of whether a random string of bytes can be considered encrypti= on has a lot to do with what that random string of bytes gives you access t= o. Providing that there are enough mechanisms in place to prevent me from d= oing anything useful with the random string of bytes (e.g. cut off access t= o a legitimate user by sending the token as if it were mine), then I agree = with you that it can be considered a form of encryption because getting acc= ess to the raw token gives me nothing of value.

That said, the same argument can be made for a token that contains encrypte= d TURN Allocation state information, in that the encryption only prevents y= ou from seeing the state information. If you can get something useful simpl= y by knowing the encrypted version of the token then there is something wro= ng with the way the token is being generated.

I think it would be useful for the security considerations section of the d= ocument to make the argument that the token has no value of its own and to = highlight the internal requirements of the TURN server implementation that = ensure this will be true.

The normal user authentication is still in the picture.= So if a wrong user uses the token that was granted to a different legitima= te user, then the request will be rejected and the wrong user (that cannot = authenticate itself as the original user) will not benefit by snooping the = token. May be it is worth mentioning in the security section.

=C2=A0

=C2=A0 =C2=A0 I think my primary point is that the security considerations = section
=C2=A0 =C2=A0 needs more work. It's not enough to just use strong encry= ption and
=C2=A0 =C2=A0 integrity protection algorithms. It's also important to e= nsure that
=C2=A0 =C2=A0 the resulting encrypted token is not easily predictable (and<= br> =C2=A0 =C2=A0 therefore easily reusable), which is why a source of entropy = is
=C2=A0 =C2=A0 important.

You are mixing two valid (but different) approaches to tickets. Let's not create a mess.

If you are using a stateless server, and you are hiding information
inside the ticket, then you have to use the encryption and integrity
protection algorithm of good strengths. Then the entropy is NOT relevant at all in this case - because there is no randomness in the ticket.

I disagree. If there is no source of entropy, then I can learn something fr= om the ticket based on its encrypted form. For example, if I can see that e= very connection with the same client-side tuple ends up with exactly the sa= me ticket, then I have most likely learned something about the unencrypted = form of the ticket that will help me to crack the keys used to construct th= e ticket. If the source of entropy is built into the algorithm, then you= 9;re right that a good algorithm is good enough. However, some common encry= ption algorithms require the user to provide such entropy (e.g. via a rando= m initialization vector).

That's right, I agree wi= th that part.

=C2=A0

--Brandon

On the other hand, if you are using a stateful server, and no
information is hidden inside the ticket, then indeed the server must use the proper ticket generation algorithm, so it would be difficult to predict= .

I think that the security section must mention these two approaches.

--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

--f46d04428f164f7ceb05022fede1-- From nobody Thu Sep 4 03:25:53 2014 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 63CDE1A019C for ; Thu, 4 Sep 2014 03:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 KemrybhfV9p8 for ; Thu, 4 Sep 2014 03:25:49 -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 061391A00F1 for ; Thu, 4 Sep 2014 03:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4796; q=dns/txt; s=iport; t=1409826349; x=1411035949; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=7CrZqWkZDYC4tlThRVJX5gVyLOkRsnYlFlrnSVgmOQw=; b=ZOfnx5QM4zrNGt0HDSqH3vIWk+cCAyffIk6JSs/F5tsl3DnYf8T1mvpJ Y8OyjGrejR96O8b3y1RXfXevPGF7i1J5SrFb2WOvnY5eB1WCOLuzyzJok c2ucN+hlgwx5QEll8e0WnwFUltF8mJo5TSydpPv7xMScQaYe+Sa26LmD2 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAMo9CFStJV2T/2dsb2JhbABZgw2BLoJ4zHkBGXEWd4QDAQEBAwEjEUUFBwYBCBEEAQEBAgIGHQMCBDAUAQgJAQQBDQUIiDIIqQSVSQEXgSyNcBYbDYJzNoEdBZE+hiCaMIFpHIFcbIEIJByBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,465,1406592000"; d="scan'208";a="74872207" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP; 04 Sep 2014 10:25:48 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s84APmep005184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Sep 2014 10:25:48 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 05:25:47 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Oleg Moskalenko Thread-Topic: [tram] draft-ietf-tram-turn-third-party-authz-03 Thread-Index: Ac/IKpTN7Qaf3b2sR2Kl7bgUvdCfUQ== Date: Thu, 4 Sep 2014 10:25:47 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28322894@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.39.65.80] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/0mnE39jYpMZOnSWxbgqvpSwPNL0 Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-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: Thu, 04 Sep 2014 10:25:50 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFtt YWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIFNl cHRlbWJlciAwMywgMjAxNCAxMTo0NyBQTQ0KPiBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJl ZGR5KTsgT2xlZyBNb3NrYWxlbmtvDQo+IENjOiB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbdHJhbV0gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDMNCj4gDQo+ IE9uIDA5LzAzLzIwMTQgMDE6MTAgUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgd3Jv dGU6DQo+IA0KPiBbc25pcF0NCj4gDQo+ID4+IEluIGEgM3JkIHBhcnR5IHJlbGF5IHNlcnZlciBz Y2VuYXJpbywgdGhlIG93bmVyIG9mIHRoZSBPQXV0aCBzZXJ2ZXINCj4gPj4gaXMgcHJvYmFibHkg YSBjdXN0b21lciBvZiB0aGUgb3duZXIgb2YgcmVsYXkgc2VydmVyLCBub3QgdGhlIGNsaWVudCwN Cj4gPj4gc28gdGhlIG93bmVyIG9mIHRoZSBPQXV0aCBzZXJ2ZXIgaGFzIGEgYnVzaW5lc3MgaW50 ZXJlc3QgaW4gc2VjdXJpbmcNCj4gPj4gYWNjZXNzIHRvIHRoZSByZXNvdXJjZXMgdGhhdCBpdCBp cyBwYXlpbmcgZm9yLiBGb3IgdGhpcyByZWFzb24sIHRoZQ0KPiA+PiBvd25lciBvZiB0aGUgT0F1 dGggc2VydmVyIHdpbGwgbGlrZWx5IGRlc2lyZSB0byBpbXBvc2UgcmVxdWlyZW1lbnRzDQo+ID4+ IG9uIHRoZSBoYXNoIGFsZ29yaXRobSB1c2VkLiBUaGUgb3duZXIgb2YgdGhlIE9BdXRoIHNlcnZl ciBpcyBhbHNvIHRoZQ0KPiA+PiBvbmUgd2hvIGhhcyB0byBmdWxmaWxsIHJlZ3VsYXRvcnkgcmVx dWlyZW1lbnRzIGlmL3doZW4gdGhleSBhcHBseS4NCj4gPg0KPiA+IE9rYXksIGJ1dCB0aGUgVFVS TiBzZXJ2ZXIgY2FuIGFsd2F5cyBtYWtlIHN1cmUgdGhhdCB0aGUgY2xpZW50IHBpY2tzIGFuDQo+ IGFjY2VwdGFibGUgaGFzaCBhbGdvcml0aG0uIFRoZSBUVVJOIHNlcnZlciBhbHNvIGhhcyBhIHNl Y3VyaXR5IGludGVyZXN0IHRvDQo+IG1ha2Ugc3VyZSB0aGF0IHRoZSBjbGllbnQgZG9lcyBub3Qg cGljayBzb21lIGluZmVyaW9yIGFsZ29yaXRobSB0aGF0IGlzDQo+IHN1c2NlcHRpYmxlIHRvIGF0 dGFja3MuIFRoaXMgd2F5IGNsaWVudCBjYW4gb25seSBzaWduYWwgdGhlIGhhc2ggYWxnb3JpdGht DQo+IGZpbmFsaXplZCB3aXRoIHRoZSBUVVJOIHNlcnZlciB0byB0aGUgQXV0aG9yaXphdGlvbiBz ZXJ2ZXIuDQo+ID4NCj4gPiBJZiB5b3UgY291bGQgZXhwbGFpbiBhdHRhY2tzIHBvc3NpYmxlIHdp dGggdGhpcyBhcHByb2FjaCB0aGVuIGl0IHdpbGwgaGVscCB0aGUNCj4gZGlzY3Vzc2lvbi4NCj4g Pg0KPiANCj4gQXQgYSBoaWdoIGxldmVsLCB3aGF0IEkgaGF2ZSB0byBkbyBpcyB0ZWxsIG15IGN1 c3RvbWVycyB0aGUgbGlzdCBvZiBzdXBwb3J0ZWQNCj4gYWxnb3JpdGhtcyBhbmQgbGV0IHRoZW0g ZGVjaWRlIHdoaWNoIG9uZXMgbWFrZSB0aGUgbW9zdCBzZW5zZSBmb3IgdGhlbS4gSXQNCj4gY2Vy dGFpbmx5IGlzIHBvc3NpYmxlIGZvciB0aGUgY3VzdG9tZXIgdG8gdGVsbCBtZSB3aGljaCBhbGdv cml0aG0gdGhleSB3YW50IHRvDQo+IHVzZSBhaGVhZCBvZiB0aW1lLCBpbiB3aGljaCBjYXNlIHRo ZSBUVVJOIHNlcnZlciBjYW4gbWFrZSB0aGUgZGVjaXNpb24gb24NCj4gdGhlaXIgYmVoYWxmLiBI b3dldmVyLCB0aGlzIGlzIG5vdCBpZGVhbCwgYmVjYXVzZSBpdCByZXF1aXJlcyB0aGUgY3VzdG9t ZXIgdG8NCj4gaW50ZXJhY3QgZGlyZWN0bHkgd2l0aCBib3RoIG15IHN5c3RlbSAodG8gbWFrZSB0 aGVpciBzZWxlY3Rpb24pIGFuZCB0aGVpciBvd24NCj4gc3lzdGVtICh0byB2YWxpZGF0ZSB0aGUg c2VsZWN0aW9uKS4gSXQgaXMgc2ltcGxlciBmb3IgdGhlIGN1c3RvbWVyIGlmIHRoZXkgb25seQ0K PiBoYXZlIHRvIGludGVyYWN0IHdpdGggdGhlaXIgb3duIHN5c3RlbSBpZiB0aGV5IHdhbnQgdG8g Y2hhbmdlIHNlY3VyaXR5DQo+IHJlcXVpcmVtZW50cy4NCg0KQXV0aG9yaXphdGlvbiBzZXJ2ZXIg Y2Fubm90IGltcGxpY2l0bHkgbWFrZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGFsZ29yaXRobSBpdCB3 YW50cyBpcyBzdXBwb3J0ZWQgYnkgYm90aCBjbGllbnQgYW5kIFRVUk4gc2VydmVyLiANCg0KPiBJ dCBpcyBpbXBvcnRhbnQgZm9yIHRoZSBUVVJOIHNlcnZlciB0byBvbmx5IGhhdmUgb25lIGFsZ29y aXRobSB0aGF0IGl0IGNvdWxkDQo+IHBvc3NpYmx5IHNlbGVjdCBmb3IgdGhlIGN1c3RvbWVyIGFu ZCBmb3IgdGhlIGN1c3RvbWVyIHRvIHZlcmlmeSB0aGF0IHRoaXMgaXMgdGhlDQo+IGFsZ29yaXRo bSBzZWxlY3RlZC4gSWYgbm90LCB0aGUgc3lzdGVtIGlzIHN1c2NlcHRpYmxlIHRvIGFuIGFsZ29y aXRobQ0KPiBkb3duZ3JhZGUgYnkgdGhlIGNsaWVudCwgc2luY2UgdGhlcmUgaXMgbm90aGluZyB0 aGF0IHJlcXVpcmVzIHRoZSBjbGllbnQgdG8NCj4gc2lnbmFsIHRoZSBzYW1lIGFsZ29yaXRobSB0 byB0aGUgT0F1dGggc2VydmVyIHRoYXQgaXQgcmVjZWl2ZWQgZnJvbSB0aGUgVFVSTg0KPiBzZXJ2 ZXIuIFRoaXMgaXMgdGhlIGF0dGFjayB2ZWN0b3IgdGhhdCBJIHdvdWxkIGJlIGNvbmNlcm5lZCBh Ym91dC4NCg0KSWYgdGhlIGNsaWVudCBhbmQgVFVSTiBzZXJ2ZXIgaGFkIG5lZ290aWF0ZWQgbGV0 J3Mgc2F5IGFsZ29yaXRobSBYIGJ1dCBjbGllbnQgc2lnbmFscyBpbmZlcmlvciBhbGdvcml0aG0g WSBhbmQgbGV0J3Mgc2F5IEF1dGhvcml6YXRpb24gc2VydmVyIHByb3ZpZGVzIHRoZSBrZXkuIEJ1 dCB0aGUgY2xpZW50IGNhbm5vdCBmb3JjZSB0aGUgVFVSTiBzZXJ2ZXIgdG8gZG93bmdyYWRlIHRv IHVzZSBhbGdvcml0aG0gWS4gSSBzdGlsbCBkb24ndCBzZWUgYSBwb3NzaWJsZSBhdHRhY2suDQoN ClRoZSBvdGhlciB3YXkgb2Ygc29sdmluZyB0aGUgcHJvYmxlbSBjb3VsZCBiZToNCg0KMSlBdXRo b3JpemF0aW9uIHNlcnZlciBhbmQgVFVSTiBzZXJ2ZXIgYXMgcGFydCBvZiBsb25nIHRlcm0ga2V5 IGVzdGFibGlzaG1lbnQgZmluYWxpemUgdGhlIGxpc3Qgb2YgaGFzaCBhbGdvcml0aG1zLg0KMilJ ZiB0aGUgY2xpZW50IHNlbmRzIGFuIGhhc2ggYWxnb3JpdGhtIHRvIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciB3aGljaCBpcyBub3QgZmluYWxpemVkIGluIHN0ZXAgMSB0aGVuIGF1dGhvcml6YXRp b24gc2VydmVyIHJlc3BvbmRzIHdpdGggYW4gZXJyb3IgdG8gdGhlIGNsaWVudCB0byBzZWxlY3Qg YW1vbmcgdGhlIGxpc3Qgb2YgaGFzaCBhbGdvcml0aG1zIHRoYXQgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgYW5kIFRVUk4gc2VydmVyIGhhZCBwcmV2aW91c2x5IGFncmVlZC4NCiANCi1UaXJ1DQoNCj4g DQo+IC0tQnJhbmRvbg0KPiANCj4gLS0NCj4gQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5j aXBhbCBTb2Z0d2FyZSBFbmdpbmVlciBFbWVyZ2luZyBQcm9kdWN0cw0KPiBFbmdpbmVlcmluZzsg QWthbWFpIFRlY2hub2xvZ2llcyBJbmMuDQo= From nobody Thu Sep 4 03:37:36 2014 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 786721A6F27 for ; Thu, 4 Sep 2014 03:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 JoXuEvXGz9iY for ; Thu, 4 Sep 2014 03:37:33 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA1F1A01D5 for ; Thu, 4 Sep 2014 03:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11494; q=dns/txt; s=iport; t=1409827053; x=1411036653; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=s9AYewcPfHPfp5k7cRaJK3CpcAdz4ZrQvWhOAIbh7qQ=; b=DgMVL51mFLRmHqoxzhmQDUhnGF5ZvsLyXd2v68Dibl42f0onWqjUiyuT +TNfq63tuTOY6hm1pg4/TR/kSpQ1mkBdUHj/8q+YNjGDH09PY///Z1v8D pzOqgearxEMiSNTXhsKPzUn4m2wUakRRPns+cZ+kMirO9AXyw8sVotRtO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowGADlACFStJA2J/2dsb2JhbABPCoJHRlNYA4J4w0SBaYdMARlxFneEBAEBBCMKSgIQAgEIDhQgAgICMBwJAgQBDQ2IOg2ofpVKAReOcRcUMQeCeTaBHQWRPoQwiFmTR4IbgUaBdCQcgQcBAQE X-IronPort-AV: E=Sophos; i="5.04,465,1406592000"; d="scan'208,217"; a="74863319" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP; 04 Sep 2014 10:37:32 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s84AbWl5014085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Sep 2014 10:37:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 05:37:32 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , Brandon Williams Thread-Topic: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt Thread-Index: AQHPx4F++C74cYigpkyfKBx45aAoF5vv2y8AgAARVoCAAAglAIAADiMAgAARMICAACYXgIAABu6AgACGTcA= Date: Thu, 4 Sep 2014 10:37:32 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A283228D5@xmb-rcd-x10.cisco.com> References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <5407225B.5020005@akamai.com> <54074147.1000507@akamai.com> <540753F8.6020700@akamai.com> <54078257.2090206@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.65.80] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A283228D5xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/vIFAH5648-O6D7nBGVsR695BgNE Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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: Thu, 04 Sep 2014 10:37:35 -0000 --_000_913383AAA69FF945B8F946018B75898A283228D5xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2xlZyBXcm90ZToNCkkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIGZvciB0aGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvZiB0aGUgZG9jdW1lbnQgdG8gbWFrZSB0aGUgYXJndW1l bnQgdGhhdCB0aGUgdG9rZW4gaGFzIG5vIHZhbHVlIG9mIGl0cyBvd24gYW5kIHRvIGhpZ2hsaWdo dCB0aGUgaW50ZXJuYWwgcmVxdWlyZW1lbnRzIG9mIHRoZSBUVVJOIHNlcnZlciBpbXBsZW1lbnRh dGlvbiB0aGF0IGVuc3VyZSB0aGlzIHdpbGwgYmUgdHJ1ZS4NCg0KVGhlIG5vcm1hbCB1c2VyIGF1 dGhlbnRpY2F0aW9uIGlzIHN0aWxsIGluIHRoZSBwaWN0dXJlLiBTbyBpZiBhIHdyb25nIHVzZXIg dXNlcyB0aGUgdG9rZW4gdGhhdCB3YXMgZ3JhbnRlZCB0byBhIGRpZmZlcmVudCBsZWdpdGltYXRl IHVzZXIsIHRoZW4gdGhlIHJlcXVlc3Qgd2lsbCBiZSByZWplY3RlZCBhbmQgdGhlIHdyb25nIHVz ZXIgKHRoYXQgY2Fubm90IGF1dGhlbnRpY2F0ZSBpdHNlbGYgYXMgdGhlIG9yaWdpbmFsIHVzZXIp IHdpbGwgbm90IGJlbmVmaXQgYnkgc25vb3BpbmcgdGhlIHRva2VuLiBNYXkgYmUgaXQgaXMgd29y dGggbWVudGlvbmluZyBpbiB0aGUgc2VjdXJpdHkgc2VjdGlvbi4NCg0KW1RSXSBJdOKAmXMgYWxy ZWFkeSBkaXNjdXNzZWQgaW4gdGhlIGRyYWZ0LiBTZWN0aW9uIDMuMi4yDQo8c25pcD4NCiAgIElm IHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBhbmQgcG9ydCBvZiB0aGUgUmVmcmVzaCBSZXF1ZXN0IGlz IGRpZmZlcmVudA0KICAgZnJvbSB0aGUgc3RvcmVkIDUtdHVwbGUgYWxsb2NhdGlvbiwgdGhlIFRV Uk4gc2VydmVyIHByb2NlZWRzIHdpdGgNCiAgIE1FU1NBR0UtSU5URUdSSVRZIHZhbGlkYXRpb24g dG8gaWRlbnRpZnkgdGhlIHRoYXQgaXQgaXMgdGhlIHNhbWUgdXNlcg0KICAgd2hpY2ggaGFkIHBy ZXZpb3VzbHkgY3JlYXRlZCB0aGUgVFVSTiBhbGxvY2F0aW9uLiAgSWYgdGhlIGFib3ZlDQogICBj aGVja3MgYXJlIG5vdCBzdWNjZXNzZnVsIHRoZW4gc2VydmVyIE1VU1QgcmVqZWN0IHRoZSByZXF1 ZXN0IHdpdGggYQ0KICAgNDQxIChXcm9uZyBDcmVkZW50aWFscykgZXJyb3IuDQo8L3NuaXA+DQoN CkJyYW5kb24gV3JvdGU6DQpJIGRpc2FncmVlLiBJZiB0aGVyZSBpcyBubyBzb3VyY2Ugb2YgZW50 cm9weSwgdGhlbiBJIGNhbiBsZWFybiBzb21ldGhpbmcgZnJvbSB0aGUgdGlja2V0IGJhc2VkIG9u IGl0cyBlbmNyeXB0ZWQgZm9ybS4gRm9yIGV4YW1wbGUsIGlmIEkgY2FuIHNlZSB0aGF0IGV2ZXJ5 IGNvbm5lY3Rpb24gd2l0aCB0aGUgc2FtZSBjbGllbnQtc2lkZSB0dXBsZSBlbmRzIHVwIHdpdGgg ZXhhY3RseSB0aGUgc2FtZSB0aWNrZXQsIHRoZW4gSSBoYXZlIG1vc3QgbGlrZWx5IGxlYXJuZWQg c29tZXRoaW5nIGFib3V0IHRoZSB1bmVuY3J5cHRlZCBmb3JtIG9mIHRoZSB0aWNrZXQgdGhhdCB3 aWxsIGhlbHAgbWUgdG8gY3JhY2sgdGhlIGtleXMgdXNlZCB0byBjb25zdHJ1Y3QgdGhlIHRpY2tl dC4gSWYgdGhlIHNvdXJjZSBvZiBlbnRyb3B5IGlzIGJ1aWx0IGludG8gdGhlIGFsZ29yaXRobSwg dGhlbiB5b3UncmUgcmlnaHQgdGhhdCBhIGdvb2QgYWxnb3JpdGhtIGlzIGdvb2QgZW5vdWdoLiBI b3dldmVyLCBzb21lIGNvbW1vbiBlbmNyeXB0aW9uIGFsZ29yaXRobXMgcmVxdWlyZSB0aGUgdXNl ciB0byBwcm92aWRlIHN1Y2ggZW50cm9weSAoZS5nLiB2aWEgYSByYW5kb20gaW5pdGlhbGl6YXRp b24gdmVjdG9yKS4NCg0KW1RSXSBBZ3JlZWQuIFdlIGNhbiBhZGQgYSByZWNvbW1lbmRhdGlvbiBv ZiBjb25zdHJ1Y3RpbmcgdGhlIHRva2VuIGp1c3QgbGlrZSBpdOKAmXMgZG9uZSBpbiBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NTA3I3NlY3Rpb24tNA0KDQotVGlydQ0KDQo= --_000_913383AAA69FF945B8F946018B75898A283228D5xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T2xlZyBXcm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIGZvciB0aGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgc2VjdGlvbiBvZiB0aGUgZG9jdW1lbnQgdG8gbWFrZSB0aGUgYXJndW1lbnQgdGhhdCB0 aGUgdG9rZW4gaGFzIG5vIHZhbHVlIG9mIGl0cyBvd24gYW5kIHRvIGhpZ2hsaWdodCB0aGUgaW50 ZXJuYWwgcmVxdWlyZW1lbnRzIG9mIHRoZSBUVVJOIHNlcnZlciBpbXBsZW1lbnRhdGlvbiB0aGF0 IGVuc3VyZSB0aGlzDQogd2lsbCBiZSB0cnVlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg bm9ybWFsIHVzZXIgYXV0aGVudGljYXRpb24gaXMgc3RpbGwgaW4gdGhlIHBpY3R1cmUuIFNvIGlm IGEgd3JvbmcgdXNlciB1c2VzIHRoZSB0b2tlbiB0aGF0IHdhcyBncmFudGVkIHRvIGEgZGlmZmVy ZW50IGxlZ2l0aW1hdGUgdXNlciwgdGhlbiB0aGUgcmVxdWVzdCB3aWxsIGJlIHJlamVjdGVkIGFu ZCB0aGUgd3JvbmcgdXNlciAodGhhdCBjYW5ub3QgYXV0aGVudGljYXRlIGl0c2VsZiBhcyB0aGUg b3JpZ2luYWwNCiB1c2VyKSB3aWxsIG5vdCBiZW5lZml0IGJ5IHNub29waW5nIHRoZSB0b2tlbi4g TWF5IGJlIGl0IGlzIHdvcnRoIG1lbnRpb25pbmcgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PltUUl0gSXTigJlzIGFscmVhZHkgZGlzY3Vzc2VkIGluIHRoZSBkcmFmdC4gU2VjdGlvbiAzLjIu MjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7c25pcCZndDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IElm IHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBhbmQgcG9ydCBvZiB0aGUgUmVmcmVzaCBSZXF1ZXN0IGlz IGRpZmZlcmVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZnJvbSB0aGUgc3RvcmVkIDUtdHVwbGUgYWxsb2NhdGlvbiwg dGhlIFRVUk4gc2VydmVyIHByb2NlZWRzIHdpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IE1FU1NBR0UtSU5URUdSSVRZ IHZhbGlkYXRpb24gdG8gaWRlbnRpZnkgdGhlIHRoYXQgaXQgaXMgdGhlIHNhbWUgdXNlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgd2hpY2ggaGFkIHByZXZpb3VzbHkgY3JlYXRlZCB0aGUgVFVSTiBhbGxvY2F0aW9uLiZu YnNwOyBJZiB0aGUgYWJvdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNoZWNrcyBhcmUgbm90IHN1Y2Nlc3NmdWwgdGhl biBzZXJ2ZXIgTVVTVCByZWplY3QgdGhlIHJlcXVlc3Qgd2l0aCBhPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyA0NDEgKFdy b25nIENyZWRlbnRpYWxzKSBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0 Oy9zbmlwJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QnJhbmRvbiBXcm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRpc2FncmVlLiBJZiB0aGVyZSBpcyBubyBzb3VyY2Ug b2YgZW50cm9weSwgdGhlbiBJIGNhbiBsZWFybiBzb21ldGhpbmcgZnJvbSB0aGUgdGlja2V0IGJh c2VkIG9uIGl0cyBlbmNyeXB0ZWQgZm9ybS4gRm9yIGV4YW1wbGUsIGlmIEkgY2FuIHNlZSB0aGF0 IGV2ZXJ5IGNvbm5lY3Rpb24gd2l0aCB0aGUgc2FtZSBjbGllbnQtc2lkZSB0dXBsZSBlbmRzIHVw IHdpdGggZXhhY3RseSB0aGUgc2FtZSB0aWNrZXQsDQogdGhlbiBJIGhhdmUgbW9zdCBsaWtlbHkg bGVhcm5lZCBzb21ldGhpbmcgYWJvdXQgdGhlIHVuZW5jcnlwdGVkIGZvcm0gb2YgdGhlIHRpY2tl dCB0aGF0IHdpbGwgaGVscCBtZSB0byBjcmFjayB0aGUga2V5cyB1c2VkIHRvIGNvbnN0cnVjdCB0 aGUgdGlja2V0LiBJZiB0aGUgc291cmNlIG9mIGVudHJvcHkgaXMgYnVpbHQgaW50byB0aGUgYWxn b3JpdGhtLCB0aGVuIHlvdSdyZSByaWdodCB0aGF0IGEgZ29vZCBhbGdvcml0aG0gaXMgZ29vZCBl bm91Z2guDQogSG93ZXZlciwgc29tZSBjb21tb24gZW5jcnlwdGlvbiBhbGdvcml0aG1zIHJlcXVp cmUgdGhlIHVzZXIgdG8gcHJvdmlkZSBzdWNoIGVudHJvcHkgKGUuZy4gdmlhIGEgcmFuZG9tIGlu aXRpYWxpemF0aW9uIHZlY3RvcikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFJdIEFncmVlZC4gV2UgY2FuIGFkZCBh IHJlY29tbWVuZGF0aW9uIG9mIGNvbnN0cnVjdGluZyB0aGUgdG9rZW4ganVzdCBsaWtlIGl04oCZ cyBkb25lIGluDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NTA3I3Nl Y3Rpb24tNCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDUwNyNzZWN0aW9uLTQ8L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A283228D5xmbrcdx10ciscoc_-- From nobody Thu Sep 4 05:54:13 2014 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 023891A88A3; Thu, 4 Sep 2014 05:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 qlOmvtNBeIeE; Thu, 4 Sep 2014 05:54:10 -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 281171A88A2; Thu, 4 Sep 2014 05:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3438; q=dns/txt; s=iport; t=1409835251; x=1411044851; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gthNSzV2MOcT7lKnUeOOTLzpMtRns+hlk1uQy56S594=; b=YOTUbGh9mgQOYQbALDLG3HhgNlmhH7oq5luyDqLw1hHgOBXeprS6eCaL DQ+fFrsUXLL/ArceygbcumbOR9nWAemahIbHOYp3gSBOkNYsi/A4ZDoRX 0ECzFqBYXVQpUyOHj2YAEq31FukWp4ldNFhdgVbCjlkwjNBTfztaReJiI 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAMRfCFStJV2Y/2dsb2JhbABZgw1TW8gdCodMAYEGFneEBAEBBAEBATc0CxACAQgYHhAnCyUCBAENBYhCDbxoAReOdVgHhEwFkT6EMIFwhQ6BW5NHg2FsgQZCgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,465,1406592000"; d="scan'208";a="352511527" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 04 Sep 2014 12:54:10 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s84Cs9Bl010551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Sep 2014 12:54:09 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.38]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 07:54:08 -0500 From: "Prashanth Patil (praspati)" To: Brandon Williams , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-00.txt Thread-Index: AQHPyD9RveKx1xexBkuf8QiHxVQ+yw== Date: Thu, 4 Sep 2014 12:54:08 +0000 Message-ID: References: <20140724132129.8722.55066.idtracker@ietfa.amsl.com> <5407183D.2090909@akamai.com> In-Reply-To: <5407183D.2090909@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [173.39.64.33] Content-Type: text/plain; charset="us-ascii" Content-ID: <08B0DE5CAEBAE544813C3126E1084D3C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/lzwjVBgM0ee22wfSZHrLnjqR5xw Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-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: Thu, 04 Sep 2014 12:54:12 -0000 Hi Brandon, On 9/3/14 7:01 PM, "Brandon Williams" wrote: >I've read over the latest draft, and I think it's looking good re: the >discovery mechanisms. The only comment I had about that on the original >draft was resolved (i.e. sending "Try Alternate" error for allocate >requests to an anycast address). > >I would still like to see some discussion in "Security Considerations" >about the use of (D)TLS in the context of auto-discovered relay servers, >especially those that use the global anycast address. It's important to >make sure that client implementers carefully consider what degree of >privacy their users are getting from (D)TLS. There was a fair amount of >on-list discussion about this back in late March, and I think it would >be good to capture some of the outcomes from that thread in the draft. Should details regarding degree of privacy obtained from (D)TLS have been captured in RFC 7350 instead? Since the intention of the draft was to only describe means to discover TURN servers, 'Security Considerations' only discusses security aspects of those means. Having said that, we could certainly add some text in security considerations based on discussion on the list. -Prashanth > >--Brandon > >On 07/24/2014 09:21 AM, 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-00.txt >> Pages : 11 >> Date : 2014-07-24 >> >> 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 or >> the ISP, 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 two 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: >> http://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-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/ >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> > >--=20 >Brandon Williams; Senior Principal Software Engineer >Emerging Products Engineering; Akamai Technologies Inc. > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Thu Sep 4 05:57:24 2014 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 08F521A889F for ; Thu, 4 Sep 2014 05:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 NqfHu4zt77-G for ; Thu, 4 Sep 2014 05:57:17 -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 B1E901A8874 for ; Thu, 4 Sep 2014 05:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9560; q=dns/txt; s=iport; t=1409835437; x=1411045037; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=d2YLkdwy28iwI/XBP/wQbSk2r0/vzPTa0lazPF81Wmc=; b=bHnjNsfSCphRn0Hh8J6UG/3qTjCt5ByjTMVLJme0faGe/8yljg26OFF0 3dm/pe3XUQHU4HE4K274Ud22C/hWXdpTm3l3Q4udDt0TO/u95p4e6dVEs 5BIMtHhL32AqnG4GUE4OvLjelidz2+emOmc1nFy76j7Qc0VSvdAJwYUFg Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAPVgCFStJA2L/2dsb2JhbABZgw1TUwjIHQyHSgGBBhZ3hAMBAQEEAQEBNzQJAhACAQgYHgkHJwsUCAkCBAENBQkSiCcIBbxrAReOfAEBCkUHhEwFkT6EMIZ+gVuTR4FnHhaBRmwBgQ45gQcBAQE X-IronPort-AV: E=Sophos;i="5.04,465,1406592000"; d="scan'208";a="352512123" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP; 04 Sep 2014 12:57:16 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s84CvGIL017196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Sep 2014 12:57:16 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.38]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 07:57:16 -0500 From: "Prashanth Patil (praspati)" To: Brandon Williams , Oleg Moskalenko Thread-Topic: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt Thread-Index: AQHPwGQHc9Rg7Ez/10eWiCShwyNsvJvvghWrgABnVQCAABFWgIABtByA Date: Thu, 4 Sep 2014 12:57:16 +0000 Message-ID: References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <5407225B.5020005@akamai.com> <54074147.1000507@akamai.com> In-Reply-To: <54074147.1000507@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [173.39.64.33] Content-Type: text/plain; charset="us-ascii" Content-ID: <4BEB53BEB5AA594F9E93B4F9F08C84AB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/xjzR2kzG1gF_NkMBm7eJioRbNd0 Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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: Thu, 04 Sep 2014 12:57:23 -0000 On 9/3/14 9:56 PM, "Brandon Williams" wrote: > > >On 09/03/2014 11:24 AM, Oleg Moskalenko wrote: >> see in the text: >> >> >> On Wed, Sep 3, 2014 at 7:14 AM, Brandon Williams >> > >>wrote: >> >> I see this new text in the draft. >> >> "To accommodate for loss of Refresh responses, a server must retain >> the old STUN MOBILITY-TICKET attribute for a period of at least 30 >> seconds to be able recognize a retransmission of Refresh request >>with >> the old STUN MOBILITY-TICKET attribute from the client." >> >> Do you mean that the old ticket will be stored along with the new >> ticket in the allocation record? and that a refresh request with a >> mobility ticket that doesn't match the current ticket will have the >> ticket matched against the old ticket? >> >> >> No, the meaning is slightly different. For an unreliable protocol, the >> client may not receive the refresh response. The client may re-transmit >> the REFRESH request from the same network endpoint. And the client will >> receive the same refresh response (with the same new ticket inside) >> because the server will recognize the refresh request retransmission >> (because the server stores the old ticket associated with the TURN >>session). > >This sounds like the operation I was talking about. Yes, this is the intention of the text in the draft. Does it need rewording? > >> >> On the other hand, if the client sends the REFRESH request (with old >> ticket) from a DIFFERENT network endpoint then the client will receive a >> sort of "unknown mobile ticket" error because the old ticket has already >> been "used" for the session relocation. The old ticket can only be used >> for the retransmission purpose. It cannot be used for the session >> relocation because it would lead to uncontrolled resource leakage. > >So you're suggesting that server should not support mobility in this >case. If that's true, then the document should definitely state that, >and also make clear why this restriction is important. We'll spell this out in the next revision. > >> >> That makes sense to me. I just think it would be good to directly >> state the intended use. >> >> >> >> I agree that a clarification would be proper. >> >> >> On a separate note, why wouldn't the server just hold onto the old >> ticket until it receives a valid refresh request that contains the >> new ticket? If there are memory space concerns related to the size >> of the ticket, then perhaps the client could immediately send a >> refresh request with new ticket as confirmation that it was received >> and that the old ticket can be discarded. >> >> Regarding construction of the ticket, the draft currently states: >> "TURN server can store system internal data into the ticket that is >> encrypted by a key known only to the TURN server and sends the >> ticket in the STUN MOBILITY-TICKET attribute as part of Allocate >> success response. The ticket is opaque to the client, so the >> structure is not subject to interoperability concerns, and >> implementations may diverge from this format. TURN Allocation state >> information is encrypted using 128-bit key for Advance Encryption >> Standard (AES) and 256-bit key for HMAC-SHA-256 for integrity >> protection." >> >> I think it might be good for the document to be more explicit about >> the minimum content that is required in ticket for it to fulfill its >> purpose. This includes the client-side tuple for the turn allocation >> (required for lookup) and it might need a source of entropy to >> prevent replay of the token, though maybe the MESSAGE-INTEGRITY >> attribute on the STUN message serves that purpose well enough. What >> else do you envision being contained in the token? >> >> >> >> I do not think that the document must specify what the ticket content >> is. The ticket content may be totally opaque and meaningless - that's up >> to server what to do about the ticket. The server may store all >> meaningful information in its database, and the ticket is just a >> sequence of random symbols. For the purpose of this specification, I see >> no reason why the ticket content is of any interest. I agree. Construction of the ticket and the fact that the server is stateful or stateless is an implementation detail. The ticket is an opaque object as far as the client is concerned and is only meaningful to the server. The standard should hence not dictate the means to generate/construct this ticket. We could maybe add a recommendation in the appendix for ticket construction as Tiru suggests in another mail, if that is useful. We need text under security considerations that highlights the need for strong entropy to ensure nothing can be gleaned by looking at the ticket alone. We'll add text around this in the next revision. -Prashanth =20 > >Some examples might be helpful to implementers, especially to help them >get the security aspects of the token right. For example, if there's no >source of entropy, then the encrypt and auth results may be problematic. >Your example of a random series of bytes is fine in this regard, but if >someone where to do what the spec appears to be suggesting and nothing >more, that would not be particularly good. > >--Brandon > >> >> Thanks >> Oleg >> >> >> --Brandon >> >> >> On 08/25/2014 12:43 PM, Prashanth Patil (praspati) wrote: >> >> All, >> We've submitted a revision of the 'Mobility with TURN' draft. >> The update >> addresses comments raised by Brandon during IETF-90 regarding >> TURN client >> and server behavior when a STUN refresh message carrying >> MOBILITY-TICKET >> attribute is lost. >> >> Comments welcome. >> >> Thanks, >> Prashanth >> >> >> On 8/25/14 6:26 PM, "internet-drafts@ietf.org >> " > > >> wrote: >> >> >> A new version of I-D, draft-wing-tram-turn-mobility-__01.txt >> has been successfully submitted by Prashanth Patil and >> posted to the >> IETF repository. >> >> Name: draft-wing-tram-turn-mobility >> Revision: 01 >> Title: Mobility with TURN >> Document date: 2014-08-25 >> Group: Individual Submission >> Pages: 10 >> URL: >> =20 >>http://www.ietf.org/internet-__drafts/draft-wing-tram-turn-__mobility-01. >>txt >> =20 >>>> >> Status: >> =20 >>https://datatracker.ietf.org/__doc/draft-wing-tram-turn-__mobility/ >> =20 >> >> Htmlized: >> =20 >>http://tools.ietf.org/html/__draft-wing-tram-turn-mobility-__01 >> =20 >> >> Diff: >> =20 >>http://www.ietf.org/rfcdiff?__url2=3Ddraft-wing-tram-turn-__mobility-01 >> =20 >> >> >> Abstract: >> It is desirable to minimize traffic disruption caused by >> changing IP >> address during a mobility event. One mechanism to >>minimize >> disruption is to expose a shorter network path to the >> mobility event >> so only the local network elements are aware of the >> changed IP >> address but the remote peer is unaware of the changed IP >> address. >> >> This draft provides such an IP address mobility solution >> using TURN. >> This is achieved by allowing a client to retain an >> allocation on the >> TURN server when the IP address of the client changes. >> >> >> >> >> >> 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 >> >> >> >> -- >> Brandon Williams; Senior Principal Software Engineer >> Emerging Products Engineering; Akamai Technologies Inc. >> >> >> _________________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/__listinfo/tram >> >> >> > >--=20 >Brandon Williams; Senior Principal Software Engineer >Emerging Products Engineering; Akamai Technologies Inc. From nobody Thu Sep 4 06:08:44 2014 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 4860F1A88A0 for ; Thu, 4 Sep 2014 06:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 EgOhDtQ2mItt for ; Thu, 4 Sep 2014 06:08:27 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id B8E221A8874 for ; Thu, 4 Sep 2014 06:08:27 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 314DB28667; Thu, 4 Sep 2014 13:08:27 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 1D69828666; Thu, 4 Sep 2014 13:08:27 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 16DDE2027; Thu, 4 Sep 2014 13:08:27 +0000 (GMT) Message-ID: <5408644B.50501@akamai.com> Date: Thu, 04 Sep 2014 09:08:27 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A28322894@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A28322894@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/tuLcTjz6WGRNpDQQZmp5IZrwBW4 Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-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: Thu, 04 Sep 2014 13:08:38 -0000 On 09/04/2014 06:25 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Brandon Williams [mailto:brandon.williams@akamai.com] >> Sent: Wednesday, September 03, 2014 11:47 PM >> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko >> Cc: tram@ietf.org >> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 >> >> On 09/03/2014 01:10 PM, Tirumaleswar Reddy (tireddy) wrote: >> >> [snip] >> >>>> In a 3rd party relay server scenario, the owner of the OAuth server >>>> is probably a customer of the owner of relay server, not the client, >>>> so the owner of the OAuth server has a business interest in securing >>>> access to the resources that it is paying for. For this reason, the >>>> owner of the OAuth server will likely desire to impose requirements >>>> on the hash algorithm used. The owner of the OAuth server is also the >>>> one who has to fulfill regulatory requirements if/when they apply. >>> >>> Okay, but the TURN server can always make sure that the client picks an >> acceptable hash algorithm. The TURN server also has a security interest to >> make sure that the client does not pick some inferior algorithm that is >> susceptible to attacks. This way client can only signal the hash algorithm >> finalized with the TURN server to the Authorization server. >>> >>> If you could explain attacks possible with this approach then it will help the >> discussion. >>> >> >> At a high level, what I have to do is tell my customers the list of supported >> algorithms and let them decide which ones make the most sense for them. It >> certainly is possible for the customer to tell me which algorithm they want to >> use ahead of time, in which case the TURN server can make the decision on >> their behalf. However, this is not ideal, because it requires the customer to >> interact directly with both my system (to make their selection) and their own >> system (to validate the selection). It is simpler for the customer if they only >> have to interact with their own system if they want to change security >> requirements. > > Authorization server cannot implicitly make assumption that the algorithm it wants is supported by both client and TURN server. > Correct, and that works both ways. Neither side can pick a single algorithm to be used without knowing the set of algorithms the other side supports. My argument is that it is better for the relay service provider to allow the auth server provider to control the selection. That's certainly the model that our customers will want. >> It is important for the TURN server to only have one algorithm that it could >> possibly select for the customer and for the customer to verify that this is the >> algorithm selected. If not, the system is susceptible to an algorithm >> downgrade by the client, since there is nothing that requires the client to >> signal the same algorithm to the OAuth server that it received from the TURN >> server. This is the attack vector that I would be concerned about. > > If the client and TURN server had negotiated let's say algorithm X but client signals inferior algorithm Y and let's say Authorization server provides the key. But the client cannot force the TURN server to downgrade to use algorithm Y. I still don't see a possible attack. > You're right that the client is in a position to force the session to use the lowest security algorithm supported by the union of those supported by both the relay server and the oauth server. I guess there's really no way to prevent that without ensuring that there is only one algorithm that could possibly be selected by both the relay server and the auth server. If there's no attack vector that can be avoided, then it's just about which method will provide better algorithm selection semantics. > The other way of solving the problem could be: > > 1)Authorization server and TURN server as part of long term key establishment finalize the list of hash algorithms. This is what I meant by "tell my customers the list of supported algorithms". > 2)If the client sends an hash algorithm to the authorization server which is not finalized in step 1 then authorization server responds with an error to the client to select among the list of hash algorithms that authorization server and TURN server had previously agreed. This is fine, but suboptimal. The client doesn't have to probe to figure out which algorithm will be considered OK. The negotiation can be completed in a single step without the need for an error return if the clients sends its list of supported algorithms and the auth server sends a key for the algorithm that it picked. This will most likely be what is required for algorithm selection between the client and the relay server outside of the 3rd party context, too. Here are the ideas running through my head at the moment. The algorithm to use for standard STUN authentication could be selected in one of the two following ways (assuming that the client can't be pre-configured to know the algorithm in advance). Standard STUN Auth option 1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ * client sends algorithm list in initial allocation request * relay server selects an algorithm and send that in the allocation error response * client sends allocation request with message integrity using selected algorithm Standard STUN Auth option 2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ * client sends initial allocation request as per existing spec * relay server sends a list of supported algorithms in the allocation error response * client selects an algorithm from the list and uses it to generate message integrity for the new allocation request I like option 2 better because I think it works better with 3rd party auth by allowing for indirect in-band negotiation between the relay and auth servers as well as out-of-band negotiation, while at the same time not requiring the client to be pre-configured in either case. 3rd Party Auth with initial relay server exchange ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * no out-of-band algorithm exchange required between relay server and oauth server * client sends initial allocation request as per existing spec * relay server sends a list of supported algorithms in the allocation error response * client sends token request to oauth with the union set of algorithms supported by the client and the turn server * oauth server selects an algorithm from the list and sends an appropriate key in the token * client sends allocation request with message integrity using selected algorithm 3rd Party Auth without initial relay server exchange ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * relay server provides oauth server with list of supported algorithms via out-of-band mechanism * client sends token request to oauth with the list of algorithms supported by the client * oauth server selects an algorithm from the set of algorithms supported by both the client and the relay server, and it sends an appropriate key in the token * client sends allocation request with message integrity using selected algorithm What are your thoughts on the above? --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Thu Sep 4 06:25:59 2014 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 21BCA1A88BB; Thu, 4 Sep 2014 06:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 C2QY7S5hqULd; Thu, 4 Sep 2014 06:25:43 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 703A91A88B5; Thu, 4 Sep 2014 06:25:42 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E252347548; Thu, 4 Sep 2014 13:25:41 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id CC7AA4750F; Thu, 4 Sep 2014 13:25:41 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id C40E42029; Thu, 4 Sep 2014 13:25:41 +0000 (GMT) Message-ID: <54086855.8050803@akamai.com> Date: Thu, 04 Sep 2014 09:25:41 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" References: <20140724132129.8722.55066.idtracker@ietfa.amsl.com> <5407183D.2090909@akamai.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/CDhZu4SSKahD5HJ0nCZZF2DA78E Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-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: Thu, 04 Sep 2014 13:25:53 -0000 I think security considerations that really only apply to cases where auto-discovery is used would be good to call out in the auto-discovery draft, especially considering the fact that the drafts related to (D)TLS are already published as RFCs. --Brandon On 09/04/2014 08:54 AM, Prashanth Patil (praspati) wrote: > Hi Brandon, > > On 9/3/14 7:01 PM, "Brandon Williams" wrote: > >> I've read over the latest draft, and I think it's looking good re: the >> discovery mechanisms. The only comment I had about that on the original >> draft was resolved (i.e. sending "Try Alternate" error for allocate >> requests to an anycast address). >> >> I would still like to see some discussion in "Security Considerations" >> about the use of (D)TLS in the context of auto-discovered relay servers, >> especially those that use the global anycast address. It's important to >> make sure that client implementers carefully consider what degree of >> privacy their users are getting from (D)TLS. There was a fair amount of >> on-list discussion about this back in late March, and I think it would >> be good to capture some of the outcomes from that thread in the draft. > > Should details regarding degree of privacy obtained from (D)TLS have been > captured in RFC 7350 instead? > > Since the intention of the draft was to only describe means to discover > TURN servers, 'Security Considerations' only discusses security aspects of > those means. > > Having said that, we could certainly add some text in security > considerations based on discussion on the list. > > -Prashanth > > >> >> --Brandon >> >> On 07/24/2014 09:21 AM, 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-00.txt >>> Pages : 11 >>> Date : 2014-07-24 >>> >>> 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 or >>> the ISP, 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 two 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: >>> http://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-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/ >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>> >> >> -- >> Brandon Williams; Senior Principal Software Engineer >> Emerging Products Engineering; Akamai Technologies Inc. >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Thu Sep 4 06:53:00 2014 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 E46681A02FC for ; Thu, 4 Sep 2014 06:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 pIzUFAc6pJhq for ; Thu, 4 Sep 2014 06:52:55 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6E51B1A88BF for ; Thu, 4 Sep 2014 06:52:55 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BD29C28665; Thu, 4 Sep 2014 13:52:54 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id A773128662; Thu, 4 Sep 2014 13:52:54 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 5F7DA2027; Thu, 4 Sep 2014 13:52:54 +0000 (GMT) Message-ID: <54086EB6.5060002@akamai.com> Date: Thu, 04 Sep 2014 09:52:54 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "tram@ietf.org" References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/umzqCesG063TbLq_g0_W8Ib9T_c Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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: Thu, 04 Sep 2014 13:52:58 -0000 I had one other thought on this one ... For a large distributed system that selects the relay server for best performance, I think that support for redirection via the response to the mobility refresh request is important. When the client changes its IP address, this will often mean there was a significant change to its network geography as well. For example, when moving from a 3G address to a wifi address, continuing to use the same relay server will be good for short term connection continuity, but could be generally bad for call quality. Having the capability to signal that the client should attempt to shift its flows to another relay would be beneficial. This capability could be handled via updated channel bind / permission requests using the mechanism from the peer-redirect draft, though allowing the redirect in the refresh response itself would be preferable I think. --Brandon On 08/25/2014 12:43 PM, Prashanth Patil (praspati) wrote: > All, > We've submitted a revision of the 'Mobility with TURN' draft. The update > addresses comments raised by Brandon during IETF-90 regarding TURN client > and server behavior when a STUN refresh message carrying MOBILITY-TICKET > attribute is lost. > > Comments welcome. > > Thanks, > Prashanth > > > On 8/25/14 6:26 PM, "internet-drafts@ietf.org" > wrote: > >> >> A new version of I-D, draft-wing-tram-turn-mobility-01.txt >> has been successfully submitted by Prashanth Patil and posted to the >> IETF repository. >> >> Name: draft-wing-tram-turn-mobility >> Revision: 01 >> Title: Mobility with TURN >> Document date: 2014-08-25 >> Group: Individual Submission >> Pages: 10 >> URL: >> http://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobility-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-wing-tram-turn-mobility/ >> Htmlized: >> http://tools.ietf.org/html/draft-wing-tram-turn-mobility-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-wing-tram-turn-mobility-01 >> >> Abstract: >> It is desirable to minimize traffic disruption caused by changing IP >> address during a mobility event. One mechanism to minimize >> disruption is to expose a shorter network path to the mobility event >> so only the local network elements are aware of the changed IP >> address but the remote peer is unaware of the changed IP address. >> >> This draft provides such an IP address mobility solution using TURN. >> This is achieved by allowing a client to retain an allocation on the >> TURN server when the IP address of the client changes. >> >> >> >> >> >> 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 > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Sep 5 04:21:59 2014 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 340351A06D1 for ; Fri, 5 Sep 2014 04:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 Yylb8Orv2ZzV for ; Fri, 5 Sep 2014 04:21:54 -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 718781A06CA for ; Fri, 5 Sep 2014 04:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8411; q=dns/txt; s=iport; t=1409916114; x=1411125714; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=HkiBnnoQGPPmfvzfbkHkTC3K6rsiQ+fhAqUzVYiCOYs=; b=lpYQZNdtFtrr0g+7zrdiaeNmijgz/p//BIasXwYacSEZo775Lz/vv6ZA T+qCq0VKu1i2CqC7WJpY1LlFxLefbyJI9JzJRZgaXOn27HV18zNtahgU8 P4Ux2lIbRXrbx4oaGHfT0rFBksHU4Jl5gc3KC+RkhmWXDau7SFB7DukNG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAAacCVStJV2Y/2dsb2JhbABZgw1TVwTIfgqHTAGBCxZ3hAMBAQEDAQEBATc0CwUHBgEIEQQBAQEKFAkuCxQJCQEEAQ0FCIgyCA2+BQETBI8cMQ2DKYEdBY8pghWGIJo0gWkcgVxsgQgkHIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,472,1406592000"; d="scan'208";a="352853745" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 05 Sep 2014 11:21:50 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s85BLojg025205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Sep 2014 11:21:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 06:21:50 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Oleg Moskalenko Thread-Topic: [tram] draft-ietf-tram-turn-third-party-authz-03 Thread-Index: Ac/I+4vxiuZIpgjgQr6TbZpjg7kexA== Date: Fri, 5 Sep 2014 11:21:50 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A283245D5@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.39.65.158] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/DqXKBaxjhe5xi5xdh64_QMWRlUI Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-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, 05 Sep 2014 11:21:57 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Thursday, September 04, 2014 6:38 PM > To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko > Cc: tram@ietf.org > Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 >=20 > On 09/04/2014 06:25 AM, Tirumaleswar Reddy (tireddy) wrote: > >> -----Original Message----- > >> From: Brandon Williams [mailto:brandon.williams@akamai.com] > >> Sent: Wednesday, September 03, 2014 11:47 PM > >> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko > >> Cc: tram@ietf.org > >> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 > >> > >> On 09/03/2014 01:10 PM, Tirumaleswar Reddy (tireddy) wrote: > >> > >> [snip] > >> > >>>> In a 3rd party relay server scenario, the owner of the OAuth server > >>>> is probably a customer of the owner of relay server, not the > >>>> client, so the owner of the OAuth server has a business interest in > >>>> securing access to the resources that it is paying for. For this > >>>> reason, the owner of the OAuth server will likely desire to impose > >>>> requirements on the hash algorithm used. The owner of the OAuth > >>>> server is also the one who has to fulfill regulatory requirements if= /when > they apply. > >>> > >>> Okay, but the TURN server can always make sure that the client picks > >>> an > >> acceptable hash algorithm. The TURN server also has a security > >> interest to make sure that the client does not pick some inferior > >> algorithm that is susceptible to attacks. This way client can only > >> signal the hash algorithm finalized with the TURN server to the > Authorization server. > >>> > >>> If you could explain attacks possible with this approach then it > >>> will help the > >> discussion. > >>> > >> > >> At a high level, what I have to do is tell my customers the list of > >> supported algorithms and let them decide which ones make the most > >> sense for them. It certainly is possible for the customer to tell me > >> which algorithm they want to use ahead of time, in which case the > >> TURN server can make the decision on their behalf. However, this is > >> not ideal, because it requires the customer to interact directly with > >> both my system (to make their selection) and their own system (to > >> validate the selection). It is simpler for the customer if they only > >> have to interact with their own system if they want to change security > requirements. > > > > Authorization server cannot implicitly make assumption that the algorit= hm > it wants is supported by both client and TURN server. > > >=20 > Correct, and that works both ways. Neither side can pick a single algorit= hm to > be used without knowing the set of algorithms the other side supports. My > argument is that it is better for the relay service provider to allow the= auth > server provider to control the selection. > That's certainly the model that our customers will want. >=20 > >> It is important for the TURN server to only have one algorithm that > >> it could possibly select for the customer and for the customer to > >> verify that this is the algorithm selected. If not, the system is > >> susceptible to an algorithm downgrade by the client, since there is > >> nothing that requires the client to signal the same algorithm to the > >> OAuth server that it received from the TURN server. This is the attack > vector that I would be concerned about. > > > > If the client and TURN server had negotiated let's say algorithm X but = client > signals inferior algorithm Y and let's say Authorization server provides = the > key. But the client cannot force the TURN server to downgrade to use > algorithm Y. I still don't see a possible attack. > > >=20 > You're right that the client is in a position to force the session to use= the > lowest security algorithm supported by the union of those supported by bo= th > the relay server and the oauth server. I guess there's really no way to p= revent > that without ensuring that there is only one algorithm that could possibl= y be > selected by both the relay server and the auth server. >=20 > If there's no attack vector that can be avoided, then it's just about whi= ch > method will provide better algorithm selection semantics. >=20 > > The other way of solving the problem could be: > > > > 1)Authorization server and TURN server as part of long term key > establishment finalize the list of hash algorithms. >=20 > This is what I meant by "tell my customers the list of supported algorith= ms". Okay. >=20 > > 2)If the client sends an hash algorithm to the authorization server whi= ch is > not finalized in step 1 then authorization server responds with an error = to > the client to select among the list of hash algorithms that authorization > server and TURN server had previously agreed. >=20 > This is fine, but suboptimal. The client doesn't have to probe to figure = out > which algorithm will be considered OK. The negotiation can be completed i= n > a single step without the need for an error return if the clients sends i= ts list of > supported algorithms and the auth server sends a key for the algorithm th= at > it picked. This will most likely be what is required for algorithm select= ion > between the client and the relay server outside of the 3rd party context,= too. >=20 > Here are the ideas running through my head at the moment. The algorithm > to use for standard STUN authentication could be selected in one of the t= wo > following ways (assuming that the client can't be pre-configured to know = the > algorithm in advance). >=20 > Standard STUN Auth option 1 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > * client sends algorithm list in initial allocation request > * relay server selects an algorithm and send that in the allocation error > response > * client sends allocation request with message integrity using selected > algorithm >=20 > Standard STUN Auth option 2 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > * client sends initial allocation request as per existing spec > * relay server sends a list of supported algorithms in the allocation err= or > response > * client selects an algorithm from the list and uses it to generate messa= ge > integrity for the new allocation request >=20 > I like option 2 better because I think it works better with 3rd party aut= h by > allowing for indirect in-band negotiation between the relay and auth serv= ers > as well as out-of-band negotiation, while at the same time not requiring = the > client to be pre-configured in either case. Yes, option 2 is more suitable. >=20 > 3rd Party Auth with initial relay server exchange > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > * no out-of-band algorithm exchange required between relay server and > oauth server > * client sends initial allocation request as per existing spec > * relay server sends a list of supported algorithms in the allocation err= or > response > * client sends token request to oauth with the union set of algorithms > supported by the client and the turn server I think you mean intersection. =20 > * oauth server selects an algorithm from the list and sends an appropriat= e > key in the token > * client sends allocation request with message integrity using selected > algorithm This approach looks good. -Tiru >=20 > 3rd Party Auth without initial relay server exchange > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > * relay server provides oauth server with list of supported algorithms vi= a out- > of-band mechanism > * client sends token request to oauth with the list of algorithms support= ed by > the client > * oauth server selects an algorithm from the set of algorithms supported = by > both the client and the relay server, and it sends an appropriate key in = the > token > * client sends allocation request with message integrity using selected > algorithm >=20 >=20 > What are your thoughts on the above? >=20 > --Brandon >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri Sep 5 06:27:11 2014 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 31B921A06B5 for ; Fri, 5 Sep 2014 06:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 iqa929rr0o59 for ; Fri, 5 Sep 2014 06:27:07 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id C63E41A06B0 for ; Fri, 5 Sep 2014 06:27:07 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9688647522; Fri, 5 Sep 2014 13:27:06 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 7AEBC4750F; Fri, 5 Sep 2014 13:27:06 +0000 (GMT) Received: from [172.28.115.172] (unknown [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 6600D8004F; Fri, 5 Sep 2014 13:27:06 +0000 (GMT) Message-ID: <5409BA2A.9050106@akamai.com> Date: Fri, 05 Sep 2014 09:27:06 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A283245D5@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A283245D5@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/a7phZlEcM0Iv5tDCN0EIjdtCCSg Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-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, 05 Sep 2014 13:27:10 -0000 On 09/05/2014 07:21 AM, Tirumaleswar Reddy (tireddy) wrote: [snip] >> -----Original Message----- >> From: Brandon Williams [mailto:brandon.williams@akamai.com] >> Here are the ideas running through my head at the moment. The algorithm >> to use for standard STUN authentication could be selected in one of the two >> following ways (assuming that the client can't be pre-configured to know the >> algorithm in advance). >> >> Standard STUN Auth option 1 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> * client sends algorithm list in initial allocation request >> * relay server selects an algorithm and send that in the allocation error >> response >> * client sends allocation request with message integrity using selected >> algorithm >> >> Standard STUN Auth option 2 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> * client sends initial allocation request as per existing spec >> * relay server sends a list of supported algorithms in the allocation error >> response >> * client selects an algorithm from the list and uses it to generate message >> integrity for the new allocation request >> >> I like option 2 better because I think it works better with 3rd party auth by >> allowing for indirect in-band negotiation between the relay and auth servers >> as well as out-of-band negotiation, while at the same time not requiring the >> client to be pre-configured in either case. > > Yes, option 2 is more suitable. > >> >> 3rd Party Auth with initial relay server exchange >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> * no out-of-band algorithm exchange required between relay server and >> oauth server >> * client sends initial allocation request as per existing spec >> * relay server sends a list of supported algorithms in the allocation error >> response >> * client sends token request to oauth with the union set of algorithms >> supported by the client and the turn server > > I think you mean intersection. > Oops, yes, I was thinks intersection throughout the earlier e-mail and writing union. Guess I should have waited until after that second cup of coffee. >> * oauth server selects an algorithm from the list and sends an appropriate >> key in the token >> * client sends allocation request with message integrity using selected >> algorithm > > This approach looks good. > OK. So, if we go with this model, then in the 3rd party draft, the the OAuth request would specify a list of supported algorithms, and the OAuth response would specify the selected algorithm. For now, the only valid value in each direction would be "hmac-sha1" or something similar. In the future, after hash agility and the list of must/should algorithms have been specified, other algorithm specifiers can be added. Does that sound reasonable? --Brandon > -Tiru > >> >> 3rd Party Auth without initial relay server exchange >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> * relay server provides oauth server with list of supported algorithms via out- >> of-band mechanism >> * client sends token request to oauth with the list of algorithms supported by >> the client >> * oauth server selects an algorithm from the set of algorithms supported by >> both the client and the relay server, and it sends an appropriate key in the >> token >> * client sends allocation request with message integrity using selected >> algorithm >> >> >> What are your thoughts on the above? >> >> --Brandon >> >> -- >> Brandon Williams; Senior Principal Software Engineer Emerging Products >> Engineering; Akamai Technologies Inc. >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Sep 5 06:45:12 2014 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 D79EC1A06BC for ; Fri, 5 Sep 2014 06:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 ivd5t6cxhNqg for ; Fri, 5 Sep 2014 06:45:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 99CD61A068C for ; Fri, 5 Sep 2014 06:45:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E9420474DE; Fri, 5 Sep 2014 13:45:07 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id D30314746B; Fri, 5 Sep 2014 13:45:07 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 3AE072039; Fri, 5 Sep 2014 13:45:07 +0000 (GMT) Message-ID: <5409BE63.10505@akamai.com> Date: Fri, 05 Sep 2014 09:45:07 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Oleg Moskalenko References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <5407225B.5020005@akamai.com> <54074147.1000507@akamai.com> <540753F8.6020700@akamai.com> <54078257.2090206@akamai.com> <913383AAA69FF945B8F946018B75898A283228D5@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A283228D5@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/b0MiRuyJdnr3CoCT-bfc51VYRj4 Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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: Fri, 05 Sep 2014 13:45:11 -0000 On 09/04/2014 06:37 AM, Tirumaleswar Reddy (tireddy) wrote: > Oleg Wrote: > > I think it would be useful for the security considerations section of > the document to make the argument that the token has no value of its own > and to highlight the internal requirements of the TURN server > implementation that ensure this will be true. > > The normal user authentication is still in the picture. So if a wrong > user uses the token that was granted to a different legitimate user, > then the request will be rejected and the wrong user (that cannot > authenticate itself as the original user) will not benefit by snooping > the token. May be it is worth mentioning in the security section. > > [TR] It’s already discussed in the draft. Section 3.2.2 > > > > If the source IP address and port of the Refresh Request is different > > from the stored 5-tuple allocation, the TURN server proceeds with > > MESSAGE-INTEGRITY validation to identify the that it is the same user > > which had previously created the TURN allocation. If the above > > checks are not successful then server MUST reject the request with a > > 441 (Wrong Credentials) error. > > Agreed. The validation described here is adequate to ensure that a snooped token is not useful all by itself. Without a reference in the security considerations section, it didn't occur to me to go back through the rest of the document looking for something intended to meet this security requirement. > > Brandon Wrote: > > I disagree. If there is no source of entropy, then I can learn something > from the ticket based on its encrypted form. For example, if I can see > that every connection with the same client-side tuple ends up with > exactly the same ticket, then I have most likely learned something about > the unencrypted form of the ticket that will help me to crack the keys > used to construct the ticket. If the source of entropy is built into the > algorithm, then you're right that a good algorithm is good enough. > However, some common encryption algorithms require the user to provide > such entropy (e.g. via a random initialization vector). > > [TR] Agreed. We can add a recommendation of constructing the token just > like it’s done in http://tools.ietf.org/html/rfc4507#section-4 I get the impression that Oleg prefers a mobility ticket that is just a random string of bytes without any encoded meaning. Based on the discussion in this thread, I think that both approaches are reasonable and that the most important thing is for the security considerations section to describe the privacy protection requirement. The two approaches to token generation could be provided as examples of how to meet the privacy requirement in order to help make it clear. --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Sep 5 07:33:58 2014 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 8780E1A0702 for ; Fri, 5 Sep 2014 07:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 mrHkGuVpRpWB for ; Fri, 5 Sep 2014 07:33:53 -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 A47B61A06F6 for ; Fri, 5 Sep 2014 07:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3491; q=dns/txt; s=iport; t=1409927634; x=1411137234; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=poPHYUeOiR5aqbAegUq/pCLB1le+m0I9RAs/BKeBfso=; b=RZlH3N4xCC1WqMfYy5yRoksG/ZEytpyLBGAGGsy3myu5Yn+liYlLM01x Y/ImMdxw12sQ1qrf2hN+PDjNQBnCt+tUPBmyv4rwxSypeHQLwwb6ld2Lj PGsTWcMcqyRdceldpF6utdj9WjzY0I9YxJQTMaVeSnWzVqhcH6jyNcJu+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFACzJCVStJV2Q/2dsb2JhbABZgw1TUwQEyH4Mh0oBgQgWd4QDAQEBBAEBATc0CRICAQgYHhAnCxwJAgQBEgkSiCcIBb5RAReKAIUITIRMBZE+hDCGfoFck0qCG4FGbAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,473,1406592000"; d="scan'208";a="75298490" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP; 05 Sep 2014 14:33:53 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s85EXqLA001248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Sep 2014 14:33:52 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.38]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 09:33:52 -0500 From: "Prashanth Patil (praspati)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt Thread-Index: AQHPwGQHc9Rg7Ez/10eWiCShwyNsvJvxDkj6gAJN64A= Date: Fri, 5 Sep 2014 14:33:51 +0000 Message-ID: References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> In-Reply-To: <54086EB6.5060002@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.65.61.13] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/OSvH8SWlLHGK_jkfV35I1OMvylc Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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: Fri, 05 Sep 2014 14:33:56 -0000 On 9/4/14 7:22 PM, "Brandon Williams" wrote: >I had one other thought on this one ... > >For a large distributed system that selects the relay server for best >performance, I think that support for redirection via the response to >the mobility refresh request is important. When the client changes its >IP address, this will often mean there was a significant change to its >network geography as well. For example, when moving from a 3G address to >a wifi address, continuing to use the same relay server will be good for >short term connection continuity, but could be generally bad for call >quality. Having the capability to signal that the client should attempt >to shift its flows to another relay would be beneficial. Bad quality, if so, would probably be due to the new link. The host isn't roaming across large boundaries that a new relay server would provide significantly better quality. -Prashanth > >This capability could be handled via updated channel bind / permission >requests using the mechanism from the peer-redirect draft, though >allowing the redirect in the refresh response itself would be preferable >I think. > >--Brandon > >On 08/25/2014 12:43 PM, Prashanth Patil (praspati) wrote: >> All, >> We've submitted a revision of the 'Mobility with TURN' draft. The update >> addresses comments raised by Brandon during IETF-90 regarding TURN >>client >> and server behavior when a STUN refresh message carrying MOBILITY-TICKET >> attribute is lost. >> >> Comments welcome. >> >> Thanks, >> Prashanth >> >> >> On 8/25/14 6:26 PM, "internet-drafts@ietf.org" >> >> wrote: >> >>> >>> A new version of I-D, draft-wing-tram-turn-mobility-01.txt >>> has been successfully submitted by Prashanth Patil and posted to the >>> IETF repository. >>> >>> Name: draft-wing-tram-turn-mobility >>> Revision: 01 >>> Title: Mobility with TURN >>> Document date: 2014-08-25 >>> Group: Individual Submission >>> Pages: 10 >>> URL: >>>=20 >>>http://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobility-01.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-wing-tram-turn-mobility/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-wing-tram-turn-mobility-01 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-tram-turn-mobility-01 >>> >>> Abstract: >>> It is desirable to minimize traffic disruption caused by changing IP >>> address during a mobility event. One mechanism to minimize >>> disruption is to expose a shorter network path to the mobility event >>> so only the local network elements are aware of the changed IP >>> address but the remote peer is unaware of the changed IP address. >>> >>> This draft provides such an IP address mobility solution using TURN. >>> This is achieved by allowing a client to retain an allocation on the >>> TURN server when the IP address of the client changes. >>> >>> >>> >>> >>> >>> 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 >> > >--=20 >Brandon Williams; Senior Principal Software Engineer >Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Sep 5 08:13:41 2014 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 6588A1A0711 for ; Fri, 5 Sep 2014 08:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 IWVaWje_IkQg for ; Fri, 5 Sep 2014 08:13:36 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 99D091A06F6 for ; Fri, 5 Sep 2014 08:13:36 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 280DD4765C; Fri, 5 Sep 2014 15:13:36 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 12CF647650; Fri, 5 Sep 2014 15:13:36 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 0EE1A2029; Fri, 5 Sep 2014 15:13:36 +0000 (GMT) Message-ID: <5409D31F.9070003@akamai.com> Date: Fri, 05 Sep 2014 11:13:35 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "tram@ietf.org" References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/VTTyl1FmaIbi9zmzn10G99amTXY Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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: Fri, 05 Sep 2014 15:13:38 -0000 On 09/05/2014 10:33 AM, Prashanth Patil (praspati) wrote: > > > On 9/4/14 7:22 PM, "Brandon Williams" wrote: > >> I had one other thought on this one ... >> >> For a large distributed system that selects the relay server for best >> performance, I think that support for redirection via the response to >> the mobility refresh request is important. When the client changes its >> IP address, this will often mean there was a significant change to its >> network geography as well. For example, when moving from a 3G address to >> a wifi address, continuing to use the same relay server will be good for >> short term connection continuity, but could be generally bad for call >> quality. Having the capability to signal that the client should attempt >> to shift its flows to another relay would be beneficial. > > Bad quality, if so, would probably be due to the new link. The host isn't > roaming across large boundaries that a new relay server would provide > significantly better quality. > Do you mean that you specifically don't expect mobility tickets to be used in the case that I describe (going from a 3G address to a wifi address)? If that's not what you mean, then I don't understand your point. It would be quite common for the optimal relay to change when you change service providers, which you're probably doing when you change from 3G to wifi. This would be substantially less likely to be true (though not impossible) if you're just changing 3G access points. --Brandon > -Prashanth > > >> >> This capability could be handled via updated channel bind / permission >> requests using the mechanism from the peer-redirect draft, though >> allowing the redirect in the refresh response itself would be preferable >> I think. >> >> --Brandon >> >> On 08/25/2014 12:43 PM, Prashanth Patil (praspati) wrote: >>> All, >>> We've submitted a revision of the 'Mobility with TURN' draft. The update >>> addresses comments raised by Brandon during IETF-90 regarding TURN >>> client >>> and server behavior when a STUN refresh message carrying MOBILITY-TICKET >>> attribute is lost. >>> >>> Comments welcome. >>> >>> Thanks, >>> Prashanth >>> >>> >>> On 8/25/14 6:26 PM, "internet-drafts@ietf.org" >>> >>> wrote: >>> >>>> >>>> A new version of I-D, draft-wing-tram-turn-mobility-01.txt >>>> has been successfully submitted by Prashanth Patil and posted to the >>>> IETF repository. >>>> >>>> Name: draft-wing-tram-turn-mobility >>>> Revision: 01 >>>> Title: Mobility with TURN >>>> Document date: 2014-08-25 >>>> Group: Individual Submission >>>> Pages: 10 >>>> URL: >>>> >>>> http://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobility-01.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-wing-tram-turn-mobility/ >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-wing-tram-turn-mobility-01 >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-wing-tram-turn-mobility-01 >>>> >>>> Abstract: >>>> It is desirable to minimize traffic disruption caused by changing IP >>>> address during a mobility event. One mechanism to minimize >>>> disruption is to expose a shorter network path to the mobility event >>>> so only the local network elements are aware of the changed IP >>>> address but the remote peer is unaware of the changed IP address. >>>> >>>> This draft provides such an IP address mobility solution using TURN. >>>> This is achieved by allowing a client to retain an allocation on the >>>> TURN server when the IP address of the client changes. >>>> >>>> >>>> >>>> >>>> >>>> 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 >>> >> >> -- >> Brandon Williams; Senior Principal Software Engineer >> Emerging Products Engineering; Akamai Technologies Inc. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Sep 5 09:45:42 2014 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 6DEFC1A0AF0 for ; Fri, 5 Sep 2014 09:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 GWDX1pl3cIRU for ; Fri, 5 Sep 2014 09:45:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7142D1A0AD9 for ; Fri, 5 Sep 2014 09:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5016; q=dns/txt; s=iport; t=1409935536; x=1411145136; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=eScVLvLVJ6MCxXbYtwWyN0TgoQoCgQ0XoRcR3g26E5I=; b=feFHVHGdnX+8AZnWm0C3y/Bd/cGc6zP8R5oqodcVjHdIepLz6sS5TMw+ o+nXYZNH/nlec/4NjITRzKxWm8v581M/MEp/HnoLYc3ihfcMSoWdfl97D z5g8GjJrd01JVuPJrvB/hHORB5Pt635qcv8XW6teB6TiBAsmKCg88M9KN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAGvnCVStJV2Z/2dsb2JhbABagw1TUwQEyH8Kh0wBgQgWd4QDAQEBAwEBAQE3NAkHCwIBCBgeECcLHAkCBAESCRKIHwgIBb8RAReKAIUITIRMBZE+hDCGfoFck0qCG4FGbAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,474,1406592000"; d="scan'208";a="352935623" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 05 Sep 2014 16:45:35 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s85GjZ2g030021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Sep 2014 16:45:35 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.38]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 11:45:35 -0500 From: "Prashanth Patil (praspati)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt Thread-Index: AQHPwGQHc9Rg7Ez/10eWiCShwyNsvJvxDkj6gAGo4oqAAMnWAA== Date: Fri, 5 Sep 2014 16:45:34 +0000 Message-ID: References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> <5409D31F.9070003@akamai.com> In-Reply-To: <5409D31F.9070003@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.65.59.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/G-Wus5oKFHXjqWCHLAL1791S0Z0 Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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: Fri, 05 Sep 2014 16:45:38 -0000 On 9/5/14 8:43 PM, "Brandon Williams" wrote: >On 09/05/2014 10:33 AM, Prashanth Patil (praspati) wrote: >> >> >> On 9/4/14 7:22 PM, "Brandon Williams" >>wrote: >> >>> I had one other thought on this one ... >>> >>> For a large distributed system that selects the relay server for best >>> performance, I think that support for redirection via the response to >>> the mobility refresh request is important. When the client changes its >>> IP address, this will often mean there was a significant change to its >>> network geography as well. For example, when moving from a 3G address >>>to >>> a wifi address, continuing to use the same relay server will be good >>>for >>> short term connection continuity, but could be generally bad for call >>> quality. Having the capability to signal that the client should attempt >>> to shift its flows to another relay would be beneficial. >> >> Bad quality, if so, would probably be due to the new link. The host >>isn't >> roaming across large boundaries that a new relay server would provide >> significantly better quality. >> > >Do you mean that you specifically don't expect mobility tickets to be >used in the case that I describe (going from a 3G address to a wifi >address)? If that's not what you mean, then I don't understand your >point. It would be quite common for the optimal relay to change when you >change service providers, which you're probably doing when you change >from 3G to wifi. I could be mistaken but it seems to me that even if you changed service providers, the likelihood of change in quality would not be significant enough for a client to shift relays. Shifting relays would result in session re-establishment with impact on the remote peer. -Prashanth > This would be substantially less likely to be true >(though not impossible) if you're just changing 3G access points. > >--Brandon > >> -Prashanth >> >> >>> >>> This capability could be handled via updated channel bind / permission >>> requests using the mechanism from the peer-redirect draft, though >>> allowing the redirect in the refresh response itself would be >>>preferable >>> I think. >>> >>> --Brandon >>> >>> On 08/25/2014 12:43 PM, Prashanth Patil (praspati) wrote: >>>> All, >>>> We've submitted a revision of the 'Mobility with TURN' draft. The >>>>update >>>> addresses comments raised by Brandon during IETF-90 regarding TURN >>>> client >>>> and server behavior when a STUN refresh message carrying >>>>MOBILITY-TICKET >>>> attribute is lost. >>>> >>>> Comments welcome. >>>> >>>> Thanks, >>>> Prashanth >>>> >>>> >>>> On 8/25/14 6:26 PM, "internet-drafts@ietf.org" >>>> >>>> wrote: >>>> >>>>> >>>>> A new version of I-D, draft-wing-tram-turn-mobility-01.txt >>>>> has been successfully submitted by Prashanth Patil and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-wing-tram-turn-mobility >>>>> Revision: 01 >>>>> Title: Mobility with TURN >>>>> Document date: 2014-08-25 >>>>> Group: Individual Submission >>>>> Pages: 10 >>>>> URL: >>>>> >>>>>=20 >>>>>http://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobility-01.t >>>>>xt >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-wing-tram-turn-mobility/ >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-wing-tram-turn-mobility-01 >>>>> Diff: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-tram-turn-mobility-01 >>>>> >>>>> Abstract: >>>>> It is desirable to minimize traffic disruption caused by >>>>>changing IP >>>>> address during a mobility event. One mechanism to minimize >>>>> disruption is to expose a shorter network path to the mobility >>>>>event >>>>> so only the local network elements are aware of the changed IP >>>>> address but the remote peer is unaware of the changed IP address. >>>>> >>>>> This draft provides such an IP address mobility solution using >>>>>TURN. >>>>> This is achieved by allowing a client to retain an allocation on >>>>>the >>>>> TURN server when the IP address of the client changes. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 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 >>>> >>> >>> -- >>> Brandon Williams; Senior Principal Software Engineer >>> Emerging Products Engineering; Akamai Technologies Inc. >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> > >--=20 >Brandon Williams; Senior Principal Software Engineer >Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Sep 5 10:01:19 2014 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 822B21A0B08 for ; Fri, 5 Sep 2014 10:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.558 X-Spam-Level: X-Spam-Status: No, score=-14.558 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, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, T_HTML_ATTACH=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 TQYNvx1NVSya for ; Fri, 5 Sep 2014 10:01:09 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482721A0AE8 for ; Fri, 5 Sep 2014 10:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=108236; q=dns/txt; s=iport; t=1409936467; x=1411146067; h=from:to:cc:subject:date:message-id:mime-version; bh=V1dF4iabBE8DWMoBmRRxv1uNdECJ3bV5ZNSMAOTDAP0=; b=TTMGdIw7HAKrTzWdUo2EOnaBm8cgsrJguvGdrfsvSvfsTnr8fK47Sl9y dCGXpwC8NbBEdHoZVh43UTwlFekfN17C1KwIKfZPVGbNpMHfBxHSDdyxR LCFHCVwSPNbBpta2eGYtX5ew7mxTvY2TPy76Yd9faYOWKI/4omVteVkGS k=; X-Files: wdiff draft-ietf-tram-turn-third-party-authz-02.txt draft-ietf-tram-turn-third-party-authz-03.txt.htm : 75197 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFACjrCVStJV2a/2dsb2JhbABagw1TVwTIfwEJh0wBgQgWd4QDAQEBBAEBARcBDAY/AggDDAYBCBEBAwEBAQoLAwgBBgklCxQDBgkBBAENBQgBBQ2IJw2/HgEXjSuBNQsKBwELDwULCxYFDQMBDoMXgR0BBIUKAoEOiySCBoIqgjuBcoQHJpNKgWcCAhqBXGyBBgIHFwYcgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,474,1406592000"; d="htm'217?scan'217,208,217";a="75343135" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 05 Sep 2014 17:01:04 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s85H13mg006237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Sep 2014 17:01:03 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 12:01:03 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Oleg Moskalenko Thread-Topic: [tram] draft-ietf-tram-turn-third-party-authz-03 Thread-Index: Ac/JKvGcbv7VIcRBRjSPFW0PEduTFg== Date: Fri, 5 Sep 2014 17:01:02 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A283248B6@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.45.66] Content-Type: multipart/mixed; boundary="_002_913383AAA69FF945B8F946018B75898A283248B6xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/xbJ5_7iLYg3EfCQ5r4msQA5qKG4 Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-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, 05 Sep 2014 17:01:16 -0000 --_002_913383AAA69FF945B8F946018B75898A283248B6xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Friday, September 05, 2014 6:57 PM > To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko > Cc: tram@ietf.org > Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 >=20 > On 09/05/2014 07:21 AM, Tirumaleswar Reddy (tireddy) wrote: >=20 > [snip] >=20 > >> -----Original Message----- > >> From: Brandon Williams [mailto:brandon.williams@akamai.com] > >> Here are the ideas running through my head at the moment. The > >> algorithm to use for standard STUN authentication could be selected > >> in one of the two following ways (assuming that the client can't be > >> pre-configured to know the algorithm in advance). > >> > >> Standard STUN Auth option 1 > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> * client sends algorithm list in initial allocation request > >> * relay server selects an algorithm and send that in the allocation > >> error response > >> * client sends allocation request with message integrity using > >> selected algorithm > >> > >> Standard STUN Auth option 2 > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> * client sends initial allocation request as per existing spec > >> * relay server sends a list of supported algorithms in the allocation > >> error response > >> * client selects an algorithm from the list and uses it to generate > >> message integrity for the new allocation request > >> > >> I like option 2 better because I think it works better with 3rd party > >> auth by allowing for indirect in-band negotiation between the relay > >> and auth servers as well as out-of-band negotiation, while at the > >> same time not requiring the client to be pre-configured in either case= . > > > > Yes, option 2 is more suitable. > > > >> > >> 3rd Party Auth with initial relay server exchange > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> * no out-of-band algorithm exchange required between relay server and > >> oauth server > >> * client sends initial allocation request as per existing spec > >> * relay server sends a list of supported algorithms in the allocation > >> error response > >> * client sends token request to oauth with the union set of > >> algorithms supported by the client and the turn server > > > > I think you mean intersection. > > >=20 > Oops, yes, I was thinks intersection throughout the earlier e-mail and wr= iting > union. Guess I should have waited until after that second cup of coffee. >=20 > >> * oauth server selects an algorithm from the list and sends an > >> appropriate key in the token > >> * client sends allocation request with message integrity using > >> selected algorithm > > > > This approach looks good. > > >=20 > OK. So, if we go with this model, then in the 3rd party draft, the the OA= uth > request would specify a list of supported algorithms, and the OAuth > response would specify the selected algorithm. For now, the only valid va= lue > in each direction would be "hmac-sha1" or something similar. > In the future, after hash agility and the list of must/should algorithms = have > been specified, other algorithm specifiers can be added. >=20 > Does that sound reasonable ? Yes. Updated draft and attached the diff, please have a look. Cheers, -Tiru >=20 > --Brandon >=20 > > -Tiru > > > >> > >> 3rd Party Auth without initial relay server exchange > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> * relay server provides oauth server with list of supported > >> algorithms via out- of-band mechanism > >> * client sends token request to oauth with the list of algorithms > >> supported by the client > >> * oauth server selects an algorithm from the set of algorithms > >> supported by both the client and the relay server, and it sends an > >> appropriate key in the token > >> * client sends allocation request with message integrity using > >> selected algorithm > >> > >> > >> What are your thoughts on the above? > >> > >> --Brandon > >> > >> -- > >> Brandon Williams; Senior Principal Software Engineer Emerging > >> Products Engineering; Akamai Technologies Inc. > >> > >> _______________________________________________ > >> tram mailing list > >> tram@ietf.org > >> https://www.ietf.org/mailman/listinfo/tram >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. --_002_913383AAA69FF945B8F946018B75898A283248B6xmbrcdx10ciscoc_ Content-Type: text/html; name="wdiff draft-ietf-tram-turn-third-party-authz-02.txt draft-ietf-tram-turn-third-party-authz-03.txt.htm" Content-Description: wdiff draft-ietf-tram-turn-third-party-authz-02.txt draft-ietf-tram-turn-third-party-authz-03.txt.htm Content-Disposition: attachment; filename="wdiff draft-ietf-tram-turn-third-party-authz-02.txt draft-ietf-tram-turn-third-party-authz-03.txt.htm"; size=75197; creation-date="Mon, 01 Sep 2014 16:39:51 GMT"; modification-date="Fri, 05 Sep 2014 16:53:21 GMT" Content-Transfer-Encoding: base64 CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0 eS1hdXRoei0wMi50eHQgZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDMu dHh0PC90aXRsZT48L2hlYWQ+PGJvZHk+CjxwcmU+CgpUUkFNICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gUmVkZHkKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFAu IFBhdGlsCkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAg ICAgICAgIFIuIFJhdmluZHJhbmF0aApFeHBpcmVzOiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQn ID5GZWJydWFyeSAyOCw8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVu JyA+TWFyY2ggOSw8L2ZvbnQ+PC9zdHJvbmc+IDIwMTUgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBDaXNjbwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKLiBVYmVydGkKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR29vZ2xl CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPkF1Z3VzdCAyNyw8L2ZvbnQ+PC9zdHJpa2U+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3Ry b25nPjxmb250IGNvbG9yPSdncmVlbicgPlNlcHRlbWJlciA1LDwvZm9udD48L3N0cm9uZz4gMjAx NAoKICAgICAgICAgICAgICBUVVJOIEV4dGVuc2lvbiBmb3IgVGhpcmQgUGFydHkgQXV0aG9yaXph dGlvbgogICAgICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5kcmFmdC1pZXRm LXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMjwvZm9udD48L3N0cmlrZT4KICAgICAgICAg ICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5kcmFmdC1pZXRmLXRyYW0tdHVybi10 aGlyZC1wYXJ0eS1hdXRoei0wMzwvZm9udD48L3N0cm9uZz4KCkFic3RyYWN0CgogICBUaGlzIGRv Y3VtZW50IHByb3Bvc2VzIHRoZSB1c2Ugb2YgT0F1dGggdG8gb2J0YWluIGFuZCB2YWxpZGF0ZQog ICBlcGhlbWVyYWwgdG9rZW5zIHRoYXQgY2FuIGJlIHVzZWQgZm9yIFRVUk4gYXV0aGVudGljYXRp b24uICBUaGUgdXNhZ2UKICAgb2YgZXBoZW1lcmFsIHRva2VucyBlbnN1cmUgdGhhdCBhY2Nlc3Mg dG8gYSBUVVJOIHNlcnZlciBjYW4gYmUKICAgY29udHJvbGxlZCBldmVuIGlmIHRoZSB0b2tlbnMg YXJlIGNvbXByb21pc2VkLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1E cmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNp b25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5n IGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVU RikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl cm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMv Y3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBm b3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNl ZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlz IGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0 ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoK ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiA8c3RyaWtlPjxmb250IGNvbG9y PSdyZWQnID5GZWJydWFyeSAyOCw8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9 J2dyZWVuJyA+TWFyY2ggOSw8L2ZvbnQ+PC9zdHJvbmc+IDIwMTUuCgpDb3B5cmlnaHQgTm90aWNl CgogICBDb3B5cmlnaHQgKGMpIDIwMTQgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRp ZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgog ICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdz IExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6 Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9m CiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRv Y3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJl c3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9u ZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlm aWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRo ZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50 eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgpUYWJsZSBv ZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgIDIuICBUZXJtaW5vbG9neSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAzLiAgU29sdXRp b24gT3ZlcnZpZXcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDMKICAgNC4gIE9idGFpbmluZyBhIFRva2VuIFVzaW5nIE9BdXRoIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID41PC9mb250Pjwvc3Ry aWtlPiAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+NjwvZm9udD48L3N0cm9uZz4KICAg ICA0LjEuICBLZXkgRXN0YWJsaXNobWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA3CiAgICAgICA0LjEuMS4gIERTS1BQIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOAogICAgICAgNC4xLjIuICBIVFRQIGludGVyYWN0 aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgKICAgICAgIDQuMS4z LiAgTWFudWFsIHByb3Zpc2lvbmluZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA5CiAgIDUuICBGb3JtaW5nIGEgUmVxdWVzdCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxMAogICA2LiAgU1RVTiBBdHRyaWJ1dGVzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTAKICAgICA2LjEuICBUSElSRC1QQVJU WS1BVVRIT1JJWkFUSU9OIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwCiAgICAg Ni4yLiAgQUNDRVNTLVRPS0VOICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxMAogICA3LiAgUmVjZWl2aW5nIGEgcmVxdWVzdCB3aXRoIEFDQ0VTUy1UT0tFTiBh dHRyaWJ1dGUgLiAuIC4gLiAuIC4gLiAgMTIKICAgOC4gIENoYW5nZXMgdG8gVFVSTiBDbGllbnQg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEzCiAgIDkuICBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx MwogICAxMC4gSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTQKICAgMTEuIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0CiAgIDEyLiBSZWZlcmVuY2VzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNAogICAgIDEy LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTQKICAgICAxMi4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1CiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNQoKMS4gIEludHJvZHVjdGlv bgoKICAgVHJhdmVyc2FsIFVzaW5nIFJlbGF5IE5BVCAoVFVSTikgVFVSTiBbUkZDNTc2Nl0gaXMg YSBwcm90b2NvbCB0aGF0IGlzCiAgIG9mdGVuIHVzZWQgdG8gaW1wcm92ZSB0aGUgY29ubmVjdGl2 aXR5IG9mIFAyUCBhcHBsaWNhdGlvbnMuICBCeQogICBwcm92aWRpbmcgYSBjbG91ZC1iYXNlZCBy ZWxheSBzZXJ2aWNlLCBUVVJOIGVuc3VyZXMgdGhhdCBhIGNvbm5lY3Rpb24KICAgY2FuIGJlIGVz dGFibGlzaGVkIGV2ZW4gd2hlbiBvbmUgb3IgYm90aCBzaWRlcyBpcyBpbmNhcGFibGUgb2YgYQog ICBkaXJlY3QgUDJQIGNvbm5lY3Rpb24uICBIb3dldmVyLCBhcyBhIHJlbGF5IHNlcnZpY2UsIGl0 IGltcG9zZXMgYQogICBub250cml2aWFsIGNvc3Qgb24gdGhlIHNlcnZpY2UgcHJvdmlkZXIuICBU aGVyZWZvcmUsIGFjY2VzcyB0byBhIFRVUk4KICAgc2VydmljZSBpcyBhbG1vc3QgYWx3YXlzIGFj Y2Vzcy1jb250cm9sbGVkLgoKICAgVFVSTiBwcm92aWRlcyBhIG1lY2hhbmlzbSB0byBjb250cm9s IGFjY2VzcyB2aWEgImxvbmctdGVybSIgdXNlcm5hbWUvCiAgIHBhc3N3b3JkIGNyZWRlbnRpYWxz IHRoYXQgYXJlIHByb3ZpZGVkIGFzIHBhcnQgb2YgdGhlIFRVUk4gcHJvdG9jb2wuCiAgIEl0IGlz IGV4cGVjdGVkIHRoYXQgdGhlc2UgY3JlZGVudGlhbHMgd2lsbCBiZSBrZXB0IHNlY3JldDsgaWYg dGhlCiAgIGNyZWRlbnRpYWxzIGFyZSBkaXNjb3ZlcmVkLCB0aGUgVFVSTiBzZXJ2ZXIgY291bGQg YmUgdXNlZCBieQogICB1bmF1dGhvcml6ZWQgdXNlcnMgb3IgYXBwbGljYXRpb25zLiAgSG93ZXZl ciwgaW4gd2ViIGFwcGxpY2F0aW9ucywKICAgZW5zdXJpbmcgdGhpcyBzZWNyZWN5IGlzIHR5cGlj YWxseSBpbXBvc3NpYmxlLiAgVG8gYWRkcmVzcyB0aGlzCiAgIHByb2JsZW0gYW5kIHRoZSBvbmVz IGRlc2NyaWJlZCBpbiBbSS1ELmlldGYtdHJhbS1hdXRoLXByb2JsZW1zXSwgdGhpcwogICBkb2N1 bWVudCBwcm9wb3NlcyB0aGUgdXNlIG9mIHRoaXJkIHBhcnR5IGF1dGhvcml6YXRpb24gdXNpbmcg T0F1dGgKICAgZm9yIFRVUk4uCgogICBUbyBhY2hpZXZlIHRoaXJkIHBhcnR5IGF1dGhvcml6YXRp b24sIGEgcmVzb3VyY2Ugb3duZXIgZS5nLiAgV2ViUlRDCiAgIHNlcnZlciwgYXV0aG9yaXplcyBh IFRVUk4gY2xpZW50IHRvIGFjY2VzcyByZXNvdXJjZXMgb24gdGhlIFRVUk4KICAgc2VydmVyLgoK ICAgVXNpbmcgT0F1dGgsIGEgY2xpZW50IG9idGFpbnMgYW4gZXBoZW1lcmFsIHRva2VuIGZyb20g YW4KICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZS5nLiAgV2ViUlRDIHNlcnZlciwgYW5kIHRoZSB0 b2tlbiBpcyBwcmVzZW50ZWQKICAgdG8gdGhlIFRVUk4gc2VydmVyIGluc3RlYWQgb2YgdGhlIHRy YWRpdGlvbmFsIG1lY2hhbmlzbSBvZiBwcmVzZW50aW5nCiAgIHVzZXJuYW1lL3Bhc3N3b3JkIGNy ZWRlbnRpYWxzLiAgVGhlIFRVUk4gc2VydmVyIHZhbGlkYXRlcyB0aGUKICAgYXV0aGVudGljaXR5 IG9mIHRoZSB0b2tlbiBhbmQgcHJvdmlkZXMgcmVxdWlyZWQgc2VydmljZXMuCgoyLiAgVGVybWlu b2xvZ3kKCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAi U0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVO REVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJl IGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uCgogICBvICBXZWJSVEMgU2Vy dmVyOiBBIHdlYiBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyBXZWJSVEMKICAgICAgW0ktRC5pZXRmLXJ0 Y3dlYi1vdmVydmlld10uCgogICBvICBBY2Nlc3MgVG9rZW46IE9BdXRoIDIuMCBhY2Nlc3MgdG9r ZW4uCgogICBvICBtYWNfa2V5OiBUaGUgc2Vzc2lvbiBrZXkgZ2VuZXJhdGVkIGJ5IHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlci4KICAgICAgVGhpcyBzZXNzaW9uIGtleSBoYXMgYSBsaWZldGltZSB0 aGF0IGNvcnJlc3BvbmRzIHRvIHRoZSBsaWZldGltZQogICAgICBvZiB0aGUgYWNjZXNzIHRva2Vu LCBpcyBnZW5lcmF0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZAogICAgICBib3Vu ZCB0byB0aGUgYWNjZXNzIHRva2VuLgoKICAgbyAga2lkOiBBbiBlcGhlbWVyYWwgYW5kIHVuaXF1 ZSBrZXkgaWRlbnRpZmllci4gIFRoZSBraWQgYWxzbyBhbGxvd3MKICAgICAgdGhlIHJlc291cmNl IHNlcnZlciB0byBzZWxlY3QgdGhlIGFwcHJvcHJpYXRlIGtleWluZyBtYXRlcmlhbCBmb3IKICAg ICAgZGVjcnlwdGlvbi4KCjMuICBTb2x1dGlvbiBPdmVydmlldwoKICAgVGhpcyBzcGVjaWZpY2F0 aW9uIHVzZXMgdGhlIHRva2VuIHR5cGUgJ0Fzc2VydGlvbicgKGFrYSBzZWxmLQogICBjb250YWlu ZWQgdG9rZW4pIGRlc2NyaWJlZCBpbiBbUkZDNjgxOV0gd2hlcmUgYWxsIHRoZSBpbmZvcm1hdGlv bgogICBuZWNlc3NhcnkgdG8gYXV0aGVudGljYXRlIHRoZSB2YWxpZGl0eSBvZiB0aGUgdG9rZW4g aXMgY29udGFpbmVkCiAgIHdpdGhpbiB0aGUgdG9rZW4gaXRzZWxmLiAgVGhpcyBhcHByb2FjaCBo YXMgdGhlIGJlbmVmaXQgb2YgYXZvaWRpbmcgYQogICBwcm90b2NvbCBiZXR3ZWVuIHRoZSBUVVJO IHNlcnZlciBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGZvcgogICB0b2tlbiB2YWxpZGF0 aW9uLCB0aHVzIHJlZHVjaW5nIGxhdGVuY3kuICBUaGUgZXhhY3QgbWVjaGFuaXNtIHVzZWQgYnkK ICAgYSBjbGllbnQgdG8gb2J0YWluIGEgdG9rZW4gZnJvbSB0aGUgT0F1dGggYXV0aG9yaXphdGlv biBzZXJ2ZXIgaXMKICAgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gIEZvciBl eGFtcGxlLCBhIGNsaWVudCBjb3VsZCBtYWtlCiAgIGFuIEhUVFAgcmVxdWVzdCB0byBhbiBhdXRo b3JpemF0aW9uIHNlcnZlciB0byBvYnRhaW4gYSB0b2tlbiB0aGF0IGNhbgogICBiZSB1c2VkIHRv IGF2YWlsIFRVUk4gc2VydmljZXMuICBUaGUgVFVSTiB0b2tlbiBpcyByZXR1cm5lZCBpbiBKU09O LAogICBhbG9uZyB3aXRoIG90aGVyIE9BdXRoIFBhcmFtZXRlcnMgbGlrZSB0b2tlbiB0eXBlLCBt YWNfa2V5LCBraWQsCiAgIHRva2VuIGxpZmV0aW1lIGV0Yy4gIFRoZSBjbGllbnQgaXMgb2JsaXZp b3VzIHRvIHRoZSBjb250ZW50IG9mIHRoZQogICB0b2tlbi4gIFRoZSB0b2tlbiBpcyBlbWJlZGRl ZCB3aXRoaW4gYSBUVVJOIHJlcXVlc3Qgc2VudCB0byB0aGUgVFVSTgogICBzZXJ2ZXIuICBPbmNl IHRoZSBUVVJOIHNlcnZlciBoYXMgZGV0ZXJtaW5lZCB0aGUgdG9rZW4gaXMgdmFsaWQsIFRVUk4K ICAgc2VydmljZXMgYXJlIG9mZmVyZWQgZm9yIGEgZGV0ZXJtaW5lZCBwZXJpb2Qgb2YgdGltZS4K CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0rICArLS0tLS0tLS0tKwogICB8IC4uLi4uLi4uLiAgVFVSTiAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgVFVSTiAgfCAgfCAgV2ViUlRDIHwKICAgfCAuV2ViUlRDIC4gIENsaWVudCB8 ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgIHwgICAgICAgICB8CiAgIHwgLkNs aWVudCAuICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8IFNlcnZlciB8ICB8ICBT ZXJ2ZXIgfAogICB8IC4uLi4uLi4uLiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgfCAgfCAgICAgICAgIHwKICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAg ICAgICAgICAgICAgICAgICstLS0tLS0tLSsgICstLS0tLS0tLS0rCiAgICAgfCAgICAgICB8ICAg ICAgICAgICBBbGxvY2F0ZSByZXF1ZXN0ICAgICAgICAgICAgICAgIHwgICAgICAgICB8CiAgICAg fCAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wg ICAgICAgICB8CiAgICAgfCAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICB8CiAgICAgfCAgICAgICB8ICAgICAgICAgQWxsb2NhdGUgZXJy b3IgcmVzcG9uc2UgICAgICAgICAgIHwgICAgICAgICB8CiAgICAgfCAgICAgICB8Jmx0Oy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwgICAgICAgICB8CiAgICAgfCAg ICAgICB8ICAgICAgICAgVEhJUkQtUEFSVFktQVVUSE9SSVpBVElPTiAgICAgICAgIHwgICAgICAg ICB8CiAgICAgfCAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICB8CiAgICAgfCAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICB8CiAgICAgfCAgICAgICB8ICAgICAgSFRUUCBSZXF1 ZXN0IGZvciB0b2tlbiAgICAgICAgICAgICAgIHwgICAgICAgICB8CiAgICAgfC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8CiAg ICAgfCAgICAgICB8ICAgICAgSFRUUCBSZXNwb25zZSB3aXRoIHRva2VuIHBhcmFtZXRlcnMgIHwg ICAgICAgICB8CiAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18CiAgICAgfE9BdXRoICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICB8CiAgICAgIEF0dHJpYnV0ZXMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICB8CiAgICAgfC0t LS0tLSZndDt8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICB8CiAgICAgfCAgICAgICB8ICAgIEFsbG9jYXRlIHJlcXVlc3QgQUNDRVNTLVRPS0VOICAg ICAgICAgIHwgICAgICAgICB8CiAgICAgfCAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgICAgICAgICB8CiAgICAgfCAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICB8CiAgICAgfCAgICAg ICB8ICAgICAgICAgQWxsb2NhdGUgc3VjY2VzcyByZXNwb25zZSAgICAgICAgIHwgICAgICAgICB8 CiAgICAgfCAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLXwgICAgICAgICB8CiAgICAgfCAgICAgICB8ICAgICAgICAgICAgIFRVUk4gTWVzc2FnZXMg ICAgICAgICAgICAgICAgIHwgICAgICAgICB8CiAgICAgfCAgICAgICB8ICAgICAgLy8vLy8vIGlu dGVncml0eSBwcm90ZWN0ZWQgLy8vLy8vICAgIHwgICAgICAgICB8CiAgICAgfCAgICAgICB8ICAg ICAgLy8vLy8vIGludGVncml0eSBwcm90ZWN0ZWQgLy8vLy8vICAgIHwgICAgICAgICB8CiAgICAg fCAgICAgICB8ICAgICAgLy8vLy8vIGludGVncml0eSBwcm90ZWN0ZWQgLy8vLy8vICAgIHwgICAg ICAgICB8CgogICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBUVVJOIFRoaXJkIFBhcnR5IEF1dGhv cml6YXRpb24KCiAgIE5vdGUgOiBBbiBpbXBsZW1lbnRhdGlvbiBtYXkgY2hvb3NlIHRvIGNvbnRh Y3QgdGhlIFdlYlJUQyBzZXJ2ZXIgdG8KICAgb2J0YWluIGEgdG9rZW4gZXZlbiBiZWZvcmUgaXQg bWFrZXMgYW4gYWxsb2NhdGUgcmVxdWVzdCwgaWYgaXQga25vd3MKICAgdGhlIHNlcnZlciBkZXRh aWxzIGJlZm9yZSBoYW5kLiAgRm9yIGV4YW1wbGUsIG9uY2UgYSBjbGllbnQgaGFzCiAgIGxlYXJu dCB0aGF0IGEgVFVSTiBzZXJ2ZXIgc3VwcG9ydHMgVGhpcmQgUGFydHkgYXV0aG9yaXphdGlvbiBm cm9tIGEKICAgV2ViUlRDIHNlcnZlciwgdGhlIGNsaWVudCBjYW4gb2J0YWluIHRoZSB0b2tlbiBi ZWZvcmUgbWFraW5nCiAgIHN1YnNlcXVlbnQgYWxsb2NhdGUgcmVxdWVzdHMuCgogICBbSS1ELmll dGYtb2F1dGgtcG9wLWtleS1kaXN0cmlidXRpb25dIGRlc2NyaWJlcyB0aGUgaW50ZXJhY3Rpb24K ICAgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuICBGb3Ig ZXhhbXBsZSwgdGhlCiAgIGNsaWVudCBsZWFybnMgdGhlIFRVUk4gc2VydmVyIG5hbWUgInR1cm4x QGV4YW1wbGUuY29tIiBmcm9tIFRISVJELQogICBQQVJUWS1BVVRIT1JJWkFUSU9OIGF0dHJpYnV0 ZSB2YWx1ZSBhbmQgbWFrZXMgdGhlIGZvbGxvd2luZyBIVFRQCiAgIHJlcXVlc3QgZm9yIHRoZSBh Y2Nlc3MgdG9rZW4gdXNpbmcgdHJhbnNwb3J0LWxheWVyIHNlY3VyaXR5ICh3aXRoCiAgIGV4dHJh IGxpbmUgYnJlYWtzIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOgoKICAgICAgICBQT1NUIC9v L29hdXRoMi90b2tlbiBIVFRQLzEuMQogICAgICAgIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQog ICAgICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkCiAg ICAgICAgYXVkPXR1cm4xQGV4YW1wbGUuY29tCiAgICAgICAgdGltZXN0YW1wPTEzNjE0NzE2MjkK ICAgICAgICBncmFudF90eXBlPWltcGxpY2l0CiAgICAgICAgdG9rZW5fdHlwZT1wb3AKICAgICAg ICBhbGc9SE1BQy1TSEEtMSA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPkhNQUMtU0hBLTI1 Ni0xMjg8L2ZvbnQ+PC9zdHJvbmc+CgogICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3Vy ZSAyOiBSZXF1ZXN0CgogICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5EaXNjdXNzaW9uOjwv Zm9udD48L3N0cmlrZT4KCiAgIFdoZW4gU1RVTiBzdXBwb3J0cyA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbicgPmhhc2ggYWdpbGl0eSB0aGVuIFRVUk4gc2VydmVyIGFsb25nIHdpdGggdGhlIGVy cm9yCiAgIHJlc3BvbnNlIGNvbnZleXMgdGhlPC9mb250Pjwvc3Ryb25nPiBITUFDIGFsZ29yaXRo bXMgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+b3RoZXIgdGhhbiBITUFDLVNIQS0xCiAgIHRo ZW48L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+aXQgc3VwcG9y dHMgaW4gcmVzcG9uc2UgdG8gdGhlCiAgIGluaXRpYWwgQWxsb2NhdGUgcmVxdWVzdC4gIFRoZTwv Zm9udD48L3N0cm9uZz4gY2xpZW50IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPndpbGwgY29u dmV5PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPnRoZW4gc2ln bmFsczwvZm9udD48L3N0cm9uZz4gdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPmFsZ29y aXRobSBuZWdvdGlhdGVkIHdpdGg8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9 J2dyZWVuJyA+aW50ZXJzZWN0aW9uLQogICBzZXQgb2YgYWxnb3JpdGhtcyBzdXBwb3J0ZWQgYnkg aXQgYW5kPC9mb250Pjwvc3Ryb25nPiB0aGUgVFVSTiBzZXJ2ZXIgdG8gdGhlCiAgIGF1dGhvcml6 YXRpb24gc2VydmVyIGluIHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID52YWx1ZSBvZjwv Zm9udD48L3N0cmlrZT4gJ2FsZycgcGFyYW1ldGVyIGRlZmluZWQgaW4KICAgW0ktRC5pZXRmLW9h dXRoLXBvcC1rZXktZGlzdHJpYnV0aW9uXS4gIEF1dGhvcml6YXRpb24gc2VydmVyIDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJyA+c2VsZWN0cwogICBhbiBITUFDIGFsZ29yaXRobSBmcm9tIHRo ZSBsaXN0IG9mIGFsZ29yaXRobXMgY2xpZW50IGhhZCBwcm92aWRlZCBhbmQ8L2ZvbnQ+PC9zdHJv bmc+CiAgIGRldGVybWluZXMgbGVuZ3RoIG9mIHRoZSBtYWNfa2V5IGJhc2VkIG9uIHRoZSA8c3Ry b25nPjxmb250IGNvbG9yPSdncmVlbicgPnNlbGVjdGVkPC9mb250Pjwvc3Ryb25nPiBITUFDCiAg IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+YWxnb3JpdGhtLiAgTm90ZSB0aGF0IHVudGls IFNUVU4gc3VwcG9ydHMgaGFzaCBhZ2lsaXR5IEhNQUMtU0hBMSBpcwogICB0aGUgb25seSB2YWxp ZCBoYXNoPC9mb250Pjwvc3Ryb25nPiBhbGdvcml0aG0gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVk JyA+Y29udmV5ZWQKICAgYnk8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dy ZWVuJyA+dGhhdCBjbGllbnQgY2FuIHNpZ25hbCB0bzwvZm9udD48L3N0cm9uZz4gdGhlIDxzdHJp a2U+PGZvbnQgY29sb3I9J3JlZCcgPmNsaWVudC48L2ZvbnQ+PC9zdHJpa2U+CiAgIDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJyA+YXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHZpY2UtdmVyc2Eu PC9mb250Pjwvc3Ryb25nPgoKICAgSWYgdGhlIGNsaWVudCBpcyBhdXRob3JpemVkIHRoZW4gdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyBhbgogICBhY2Nlc3MgdG9rZW4uICBBbiBleGFt cGxlIG9mIHN1Y2Nlc3NmdWwgcmVzcG9uc2U6CgogICAgICAgIEhUVFAvMS4xIDIwMCBPSwogICAg ICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbgogICAgICAgIENhY2hlLUNvbnRyb2w6 IG5vLXN0b3JlCgogICAgICAgIHsKICAgICAgICAgICJhY2Nlc3NfdG9rZW4iOgogICAiVTJGc2RH VmtYMThxSksva2tXbVJjbmZIZ2xyVlRKU3BTNnlVMzJrbUhtT3JmR3lJM20xZ1FqMWpSUHNyMHVC YgogICBIY3R1eWNBZ3NmUlg3bkpXMkJkdWtHeUtNWFNpTkdObkJ6aWdrQW9mUDYrWjN2a0oxUTVw V2JmU1Jyb09rV0JuIiwKICAgICAgICAgICJ0b2tlbl90eXBlIjoicG9wIiwKICAgICAgICAgICJl eHBpcmVzX2luIjoxODAwLAogICAgICAgICAgImtpZCI6IjIyQklqeFU5M2gvSWd3RWIiLAogICAg ICAgICAgIm1hY19rZXkiOiJ2NTFONjJPTTY1a3lNdmZUSTA4TyIKICAgICAgICAgIDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJyA+ImFsZyI6SE1BQy1TSEEtMjU2LTEyODwvZm9udD48L3N0cm9u Zz4KICAgICAgICB9CgogICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDM6IFJlc3Bv bnNlCgogICBBY2Nlc3MgdG9rZW4gYW5kIG90aGVyIGF0dHJpYnV0ZXMgaXNzdWVkIGJ5IHRoZSBh dXRob3JpemF0aW9uIHNlcnZlcgogICBhcmUgZXhwbGFpbmVkIGluIFNlY3Rpb24gNi4yLgoKNC4g IE9idGFpbmluZyBhIFRva2VuIFVzaW5nIE9BdXRoCgogICBBIFRVUk4gY2xpZW50IHNob3VsZCBr bm93IHRoZSBhdXRoZW50aWNhdGlvbiBjYXBhYmlsaXR5IG9mIHRoZSBUVVJOCiAgIHNlcnZlciBi ZWZvcmUgZGVjaWRpbmcgdG8gdXNlIHRoaXJkIHBhcnR5IGF1dGhvcml6YXRpb24gd2l0aCBpdC4g IEEKICAgVFVSTiBjbGllbnQgaW5pdGlhbGx5IG1ha2VzIGEgcmVxdWVzdCB3aXRob3V0IGFueSBh dXRob3JpemF0aW9uLiAgSWYKICAgdGhlIFRVUk4gc2VydmVyIHN1cHBvcnRzIG9yIG1hbmRhdGVz IHRoaXJkIHBhcnR5IGF1dGhvcml6YXRpb24sIGl0CiAgIHdpbGwgcmV0dXJuIGFuIGVycm9yIG1l c3NhZ2UgaW5kaWNhdGluZyBzdXBwb3J0IGZvciB0aGlyZCBwYXJ0eQogICBhdXRob3JpemF0aW9u LiAgVGhlIFRVUk4gc2VydmVyIGluY2x1ZGVzIGFuIEVSUk9SLUNPREUgYXR0cmlidXRlIHdpdGgK ICAgYSB2YWx1ZSBvZiA0MDEgKFVuYXV0aG9yaXplZCksIGEgbm9uY2UgdmFsdWUgaW4gYSBOT05D RSBhdHRyaWJ1dGUgYW5kCiAgIGEgU09GVFdBUkUgYXR0cmlidXRlIHRoYXQgZ2l2ZXMgaW5mb3Jt YXRpb24gYWJvdXQgdGhlIFRVUk4gc2VydmVyJ3MKICAgc29mdHdhcmUuICBUaGUgVFVSTiBzZXJ2 ZXJzIGFsc28gaW5jbHVkZXMgYWRkaXRpb25hbCBTVFVOIGF0dHJpYnV0ZQogICBUSElSRC1QQVJU WS1BVVRIT1JJWkFUSU9OIHNpZ25hbGluZyB0aGUgVFVSTiBjbGllbnQgdGhhdCB0aGUgVFVSTgog ICBzZXJ2ZXIgc3VwcG9ydHMgdGhpcmQgcGFydHkgYXV0aG9yaXphdGlvbi4KCiAgIFRoZSBmb2xs b3dpbmcgbWFwcGluZyBvZiBPQXV0aCBjb25jZXB0cyB0byBXZWJSVEMgaXMgdXNlZCA6CgogICAg ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgfCAgICAgICAgIE9BdXRoICAgICAgICB8ICAgICAg ICAgICAgV2ViUlRDICAgICAgICAgIHwKICAgICAgICAgICAgICAgICArPT09PT09PT09PT09PT09 PT09PT09PSs9PT09PT09PT09PT09PT09PT09PT09PT09PT09KwogICAgICAgICAgICAgICAgIHwg Q2xpZW50ICAgICAgICAgICAgICAgfCBXZWJSVEMgY2xpZW50ICAgICAgICAgICAgICB8CiAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsKICAgICAgICAgICAgICAgICB8IFJlc291cmNlIG93bmVyICAgICAgIHwgV2ViUlRD IHNlcnZlciAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgfCBB dXRob3JpemF0aW9uIHNlcnZlciB8IEF1dGhvcml6YXRpb24gc2VydmVyICAgICAgIHwKICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKwogICAgICAgICAgICAgICAgIHwgUmVzb3VyY2Ugc2VydmVyICAgICAgfCBUVVJOIFNl cnZlciAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCiAgICAgICAgIEZpZ3VyZSA0OiBP QXV0aCB0ZXJtaW5vbG9neSBtYXBwZWQgdG8gV2ViUlRDIHRlcm1pbm9sb2d5CgogICBVc2luZyB0 aGUgT0F1dGggMi4wIGF1dGhvcml6YXRpb24gZnJhbWV3b3JrLCBhIFdlYlJUQyBjbGllbnQgKHRo aXJkLQogICBwYXJ0eSBhcHBsaWNhdGlvbikgb2J0YWlucyBsaW1pdGVkIGFjY2VzcyB0byBhIFRV Uk4gKHJlc291cmNlIHNlcnZlcikKICAgb24gYmVoYWxmIG9mIHRoZSBXZWJSVEMgc2VydmVyIChy ZXNvdXJjZSBvd25lciBvciBhdXRob3JpemF0aW9uCiAgIHNlcnZlcikuICBUaGUgV2ViUlRDIGNs aWVudCByZXF1ZXN0cyBhY2Nlc3MgdG8gcmVzb3VyY2VzIGNvbnRyb2xsZWQKICAgYnkgdGhlIHJl c291cmNlIG93bmVyIChXZWJSVEMgc2VydmVyKSBhbmQgaG9zdGVkIGJ5IHRoZSByZXNvdXJjZQog ICBzZXJ2ZXIgKFRVUk4gc2VydmVyKS4gIFRoZSBXZWJSVEMgY2xpZW50IG9idGFpbnMgYWNjZXNz IHRva2VuLAogICBsaWZldGltZSwgc2Vzc2lvbiBrZXkgKGluIHRoZSBtYWNfa2V5IHBhcmFtZXRl cikgYW5kIGtleSBpZCAoa2lkKS4KICAgVGhlIFRVUk4gY2xpZW50IGNvbnZleXMgdGhlIGFjY2Vz cyB0b2tlbiBhbmQgb3RoZXIgT0F1dGggcGFyYW1ldGVycwogICBsZWFybnQgZnJvbSB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgdG8gdGhlIHJlc291cmNlIHNlcnZlciAoVFVSTgogICBzZXJ2ZXIp LiAgVGhlIFRVUk4gc2VydmVyIG9idGFpbnMgdGhlIHNlc3Npb24ga2V5IGZyb20gdGhlIGFjY2Vz cwogICB0b2tlbi4gIFRoZSBUVVJOIHNlcnZlciB2YWxpZGF0ZXMgdGhlIHRva2VuLCBjb21wdXRl cyB0aGUgbWVzc2FnZQogICBpbnRlZ3JpdHkgb2YgdGhlIHJlcXVlc3QgYW5kIHRha2VzIGFwcHJv cHJpYXRlIGFjdGlvbiBpLmUgcGVybWl0cyB0aGUKICAgVFVSTiBjbGllbnQgdG8gY3JlYXRlIGFs bG9jYXRpb25zLiAgVGhpcyBpcyBzaG93biBpbiBhbiBhYnN0cmFjdCB3YXkKICAgaW4gRmlndXJl IDUuCgogICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgKyZsdDsqKioqKiorCiAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tJmd0O3wgQXV0aG9yaXphdGlvbiB8ICAgICAgICoKICAgICAgICAg ICAgfCAgICAgICAgICAgICAgfCBTZXJ2ZXIgICAgICAgIHwgICAgICAgKgogICAgICAgICAgICB8 ICAgKy0tLS0tLS0tLS18KFdlYlJUQyBTZXJ2ZXIpfCAgICAgICAqICBBUy1SUywKICAgICAgICAg ICAgfCAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgKiAgQVVUSCBrZXlzCiAg ICgyKSAgICAgIHwgICB8ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICogICAoMSkK ICAgQWNjZXNzICAgfCAgIHwgICgzKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKgogICBU b2tlbiAgICB8ICAgfCBBY2Nlc3MgVG9rZW4gICAgICAgICAgICAgICAgICAgICAqCiAgIFJlcXVl c3QgIHwgICB8ICAgICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoKICAgICAgICAgICAg fCAgIHwgU2Vzc2lvbiBLZXkgICAgICAgICAgICAgICAgICAgICAgKgogICAgICAgICAgICB8ICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqCiAgICAgICAgICAgIHwgICBWICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFYKICAgICAgICArLS0tLS0tLSstLS0rICAg ICAgICAgICAgICAgICAgICAgICArLSstLS0tPS0tLS0tKwogICAgICAgIHwgICAgICAgICAgIHwg ICAgICAgICAoNCkgICAgICAgICAgIHwgICAgICAgICAgICB8CiAgICAgICAgfCAgICAgICAgICAg fCBUVVJOIFJlcXVlc3QgKyBBY2Nlc3MgfCAgICAgICAgICAgIHwKICAgICAgICB8IFdlYlJUQyAg ICB8IFRva2VuICAgICAgICAgICAgICAgICB8IFRVUk4gICAgICAgfAogICAgICAgIHwgQ2xpZW50 ICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgU2VydmVyICAgICB8CiAgICAgICAgfCAo QWxpY2UpICAgfCBBbGxvY2F0ZSBSZXNwb25zZSAoNSkgfCAgICAgICAgICAgIHwKICAgICAgICB8 ICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgfAogICAg ICAgICstLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0rCgog ICBVc2VyIDogQWxpY2UKICAgKioqKjogT3V0LW9mLUJhbmQgTG9uZy1UZXJtIEtleSBFc3RhYmxp c2htZW50CgogICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA1OiBJbnRlcmFjdGlvbnMK CiAgIE9BdXRoIGluIFtSRkM2NzQ5XSBkZWZpbmVzIGZvdXIgZ3JhbnQgdHlwZXMuICBUaGlzIHNw ZWNpZmljYXRpb24gdXNlcwogICB0aGUgT0F1dGggZ3JhbnQgdHlwZSAiSW1wbGljaXQiIGV4cGxh aW5lZCBpbiBzZWN0aW9uIDEuMy4yIG9mCiAgIFtSRkM2NzQ5XSB3aGVyZSB0aGUgV2ViUlRDIGNs aWVudCBpcyBpc3N1ZWQgYW4gYWNjZXNzIHRva2VuIGRpcmVjdGx5LgogICBUaGUgdmFsdWUgb2Yg dGhlIHNjb3BlIHBhcmFtZXRlciBleHBsYWluZWQgaW4gc2VjdGlvbiAzLjMgb2YKICAgW1JGQzY3 NDldIE1VU1QgYmUgJ3R1cm4nIHN0cmluZy4KCjQuMS4gIEtleSBFc3RhYmxpc2htZW50CgogICBU aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc2hhcmVzIGEgbG9uZy10ZXJtIHNlY3JldCAobGlrZSBh c3ltbWV0cmljCiAgIGNyZWRlbnRpYWxzKSB3aXRoIHRoZSByZXNvdXJjZSBzZXJ2ZXIgZm9yIG11 dHVhbCBhdXRoZW50aWNhdGlvbi4gIFRoZQogICBUVVJOIGFuZCBhdXRob3JpemF0aW9uIHNlcnZl cnMgTVVTVCBlc3RhYmxpc2ggYSBzeW1tZXRyaWMga2V5IChLKSwKICAgdXNpbmcgYW4gb3V0IG9m IGJhbmQgbWVjaGFuaXNtLiAgU3ltbWV0cmljIGtleSBNVVNUIGJlIGNob3NlbiB0bwogICBlbnN1 cmUgdGhhdCB0aGUgc2l6ZSBvZiBlbmNyeXB0ZWQgdG9rZW4gaXMgbm90IGxhcmdlIGJlY2F1c2Ug dXNhZ2Ugb2YKICAgYXN5bW1ldHJpYyBrZXlzIHdpbGwgcmVzdWx0IGluIGxhcmdlIGVuY3J5cHRl ZCB0b2tlbnMgd2hpY2ggbWF5IG5vdAogICBmaXQgaW50byBhIHNpbmdsZSBTVFVOIG1lc3NhZ2Uu ICBUaGUgQVMtUlMsIEFVVEgga2V5cyB3aWxsIGJlIGRlcml2ZWQKICAgZnJvbSBLLiAgQVMtUlMg a2V5IGlzIHVzZWQgZm9yIGVuY3J5cHRpbmcgdGhlIHNlbGYtY29udGFpbmVkIHRva2VuCiAgIGFu ZCBtZXNzYWdlIGludGVncml0eSBvZiB0aGUgZW5jcnlwdGVkIHRva2VuIGlzIGNhbGN1bGF0ZWQg dXNpbmcgdGhlCiAgIEFVVEgga2V5LiAgVGhlIFRVUk4gYW5kIGF1dGhvcml6YXRpb24gc2VydmVy cyBNVVNUIGVzdGFibGlzaCB0aGUKICAgc3ltbWV0cmljIGtleSBvdmVyIGFuIGF1dGhlbnRpY2F0 ZWQgc2VjdXJlIGNoYW5uZWwuICBUaGUKICAgZXN0YWJsaXNobWVudCBvZiBzeW1tZXRyaWMga2V5 IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMKICAgc3BlY2lmaWNhdGlvbi4gIEZvciBleGFt cGxlLCBpbXBsZW1lbnRhdGlvbnMgY291bGQgdXNlIG9uZSBvZiB0aGUKICAgZm9sbG93aW5nIG1l Y2hhbmlzbXMgaW4gdG8gZXN0YWJsaXNoIGEgc3ltbWV0cmljIGtleS4KCjQuMS4xLiAgRFNLUFAK CiAgIFRoZSB0d28gc2VydmVycyBjb3VsZCBjaG9vc2UgdG8gdXNlIER5bmFtaWMgU3ltbWV0cmlj IEtleQogICBQcm92aXNpb25pbmcgUHJvdG9jb2wgKERTS1BQKSBbUkZDNjA2M10gdG8gZXN0YWJs aXNoIGEgc3ltbWV0cmljIGtleQogICAoSykuICBUaGUgZW5jcnlwdGlvbiBhbmQgTUFDIGFsZ29y aXRobXMgd2lsbCBiZSBuZWdvdGlhdGVkIHVzaW5nIHRoZQogICBLZXlQcm92Q2xpZW50SGVsbG8s IEtleVByb3ZTZXJ2ZXJIZWxsbyBtZXNzYWdlcy4gIEEgdW5pcXVlIGtleQogICBpZGVudGlmaWVy IChyZWZlcnJlZCB0byBhcyBLZXlJRCkgZm9yIHRoZSBzeW1tZXRyaWMga2V5IGlzIGdlbmVyYXRl ZAogICBieSB0aGUgRFNLUFAgc2VydmVyIChpLmUuICBBdXRob3JpemF0aW9uIHNlcnZlcikgYW5k IHNpZ25hbGxlZCB0byB0aGUKICAgRFNLUFAgY2xpZW50IChpLmUgVFVSTiBzZXJ2ZXIpIHdoaWNo IGlzIGVxdWl2YWxlbnQgdG8gdGhlIGtpZCBkZWZpbmVkCiAgIGluIHRoaXMgc3BlY2lmaWNhdGlv bi4gIFRoZSBBUy1SUywgQVVUSCBrZXlzIHdvdWxkIGJlIGRlcml2ZWQgZnJvbQogICB0aGUgc3lt bWV0cmljIGtleSB1c2luZyAoSE1BQyktYmFzZWQga2V5IGRlcml2YXRpb24gZnVuY3Rpb24gKEhL REYpCiAgIFtSRkM1ODY5XSBhbmQgdGhlIGRlZmF1bHQgaGFzaCBmdW5jdGlvbiBpcyBTSEEtMjU2 LiAgRm9yIGV4YW1wbGUgaWYKICAgdGhlIGlucHV0IHN5bW1ldHJpYyBrZXkgKEspIGlzIDMyIG9j dGV0cyBsZW5ndGgsIGVuY3J5cHRpb24gYWxnb3JpdGhtCiAgIGlzIEFFU18yNTZfQ0JDIGFuZCBI TUFDIGFsZ29yaXRobSBpcyBITUFDLVNIQS0yNTYtMTI4IHRoZW4gdGhlCiAgIHNlY29uZGFyeSBr ZXlzIEFTLVJTLCBBVVRIIGFyZSBnZW5lcmF0ZWQgZnJvbSB0aGUgaW5wdXQga2V5IEsgYXMKICAg Zm9sbG93cwoKICAgMS4gIEhLREYtRXh0cmFjdCh6ZXJvLCBLKSAtJmd0OyBQUksKCiAgIDIuICBI S0RGLUV4cGFuZChQUkssIHplcm8sIDMyKSAtJmd0OyBBUy1SUyBrZXkKCiAgIDMuICBIS0RGLUV4 cGFuZChQUkssIHplcm8sIDMyKSAtJmd0OyBBVVRIIGtleQoKICAgSWYgQXV0aGVudGljYXRlZCBF bmNyeXB0aW9uIHdpdGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKSBhbGdvcml0aG0KICAgZGVmaW5l ZCBpbiBbUkZDNTExNl0gaXMgdXNlZCB0aGVuIHRoZXJlIGlzIG5vIG5lZWQgdG8gZ2VuZXJhdGUg dGhlCiAgIEFVVEgga2V5LgoKNC4xLjIuICBIVFRQIGludGVyYWN0aW9ucwoKICAgVGhlIHR3byBz ZXJ2ZXJzIGNvdWxkIGNob29zZSB0byB1c2UgUkVTVCBBUEkgdG8gZXN0YWJsaXNoIGEgc3ltbWV0 cmljCiAgIGtleS4gIFRvIHJldHJpZXZlIGEgbmV3IHN5bW1ldHJpYyBrZXksIHRoZSBUVVJOIHNl cnZlciBtYWtlcyBhbiBIVFRQCiAgIEdFVCByZXF1ZXN0IHRvIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciwgc3BlY2lmeWluZyBUVVJOIGFzIHRoZQogICBzZXJ2aWNlIHRvIGFsbG9jYXRlIHRoZSBz eW1tZXRyaWMga2V5cyBmb3IsIGFuZCBzcGVjaWZ5aW5nIHRoZSBuYW1lCiAgIG9mIHRoZSBUVVJO IHNlcnZlci4gIFRoZSByZXNwb25zZSBpcyByZXR1cm5lZCB3aXRoIGNvbnRlbnQtdHlwZQogICAi YXBwbGljYXRpb24vanNvbiIsIGFuZCBjb25zaXN0cyBvZiBhIEpTT04gb2JqZWN0IGNvbnRhaW5p bmcgdGhlCiAgIHN5bW1ldHJpYyBrZXkuCgogICBSZXF1ZXN0CiAgIC0tLS0tLS0KCiAgIHNlcnZp Y2UgLSBzcGVjaWZpZXMgdGhlIGRlc2lyZWQgc2VydmljZSAodHVybikKICAgbmFtZSAgICAtICBU VVJOIHNlcnZlciBuYW1lIGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUga2V5CgogICBleGFtcGxlOiBH RVQgLz9zZXJ2aWNlPXR1cm4mYW1wO25hbWU9dHVybjFAZXhhbXBsZS5jb20KCiAgIFJlc3BvbnNl CiAgIC0tLS0tLS0tCgogICBrZXkgLSBMb25nLXRlcm0ga2V5IChLKQogICB0dGwgLSB0aGUgZHVy YXRpb24gZm9yIHdoaWNoIHRoZSBrZXkgaXMgdmFsaWQsIGluIHNlY29uZHMuCgogICBleGFtcGxl OgogICB7CiAgICAgICJrZXkiIDoKICAgIkVTSXpSRlZtZDRpWkFCRWlNMFJWWmdLbjZXakxhVEMx RlhBZ2hSTVZUemtCR05hYU40OTY1MjNXSUlTS2VyTGkiLAogICAgICAidHRsIiA6IDg2NDAwLAog ICAgICAia2lkIiA6IjIyQklqeFU5M2gvSWd3RWIiCiAgICAgfQoKICAgVGhlIEFTLVJTLCBBVVRI IGtleXMgYXJlIGRlcml2ZWQgZnJvbSBLIHVzaW5nIEhLREYgYXMgZGlzY3Vzc2VkIGluCiAgIFNl Y3Rpb24gNC4xLjEuICBBdXRob3JpemF0aW9uIHNlcnZlciBtdXN0IGFsc28gc2lnbmFsIGEgdW5p cXVlIGtleQogICBpZGVudGlmaWVyIChraWQpIHRvIHRoZSBUVVJOIHNlcnZlciB3aGljaCB3aWxs IGJlIHVzZWQgdG8gc2VsZWN0IHRoZQogICBhcHByb3ByaWF0ZSBrZXlpbmcgbWF0ZXJpYWwgZm9y IGRlY3J5cHRpb24uICBUaGUgZGVmYXVsdCBlbmNyeXB0aW9uCiAgIGFsZ29yaXRobSB0byBlbmNy eXB0IHRoZSBzZWxmLWNvbnRhaW5lZCB0b2tlbiBjb3VsZCBiZSBBZHZhbmNlZAogICBFbmNyeXB0 aW9uIFN0YW5kYXJkIChBRVMpIGluIENpcGhlciBCbG9jayBDaGFpbmluZyAoQ0JDKSBtb2RlCiAg IChBRVNfMjU2X0NCQykuICBUaGUgZGVmYXVsdCBITUFDIGFsZ29yaXRobSB0byBjYWxjdWxhdGUg dGhlIGludGVncml0eQogICBvZiB0aGUgdG9rZW4gY291bGQgYmUgSE1BQy1TSEEtMjU2LTEyOC4g IEluIHRoaXMgY2FzZSBBUy1SUyBrZXkKICAgbGVuZ3RoIG11c3QgYmUgMjU2LWJpdCwgQVVUSCBr ZXkgbGVuZ3RoIG11c3QgYmUgMjU2LWJpdCAoc2VjdGlvbiAyLjYKICAgb2YgW1JGQzQ4NjhdKS4K CjQuMS4zLiAgTWFudWFsIHByb3Zpc2lvbmluZwoKICAgVFVSTiBhbmQgYXV0aG9yaXphdGlvbiBz ZXJ2ZXJzIGNvdWxkIGJlIG1hbnVhbGx5IGNvbmZpZ3VyZWQgd2l0aCBhCiAgIHN5bW1ldHJpYyBr ZXkgKEspIGFuZCBraWQuICBUaGUgZGVmYXVsdCBlbmNyeXB0aW9uIGFuZCBITUFDCiAgIGFsZ29y aXRobXMgY291bGQgYmUgQUVTXzI1Nl9DQkMsIEhNQUMtU0hBLTI1Ni0xMjguCgogICBOb3RlIDog VGhlIG1lY2hhbmlzbXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gNC4xLjIgU2VjdGlvbiA0LjEuMyBh cmUKICAgZWFzeSB0byBpbXBsZW1lbnQgYW5kIGRlcGxveSBjb21wYXJlZCB0byBEU0tQUCBidXQg bGFjayBlbmNyeXB0aW9uCiAgIGFuZCBITUFDIGFsZ29yaXRobSBhZ2lsaXR5LgoKNS4gIEZvcm1p bmcgYSBSZXF1ZXN0CgogICBXaGVuIGEgVFVSTiBzZXJ2ZXIgcmVzcG9uZHMgdGhhdCB0aGlyZCBw YXJ0eSBhdXRob3JpemF0aW9uIGlzCiAgIHJlcXVpcmVkLCBhIFRVUk4gY2xpZW50IHJlLWF0dGVt cHRzIHRoZSByZXF1ZXN0LCB0aGlzIHRpbWUgaW5jbHVkaW5nCiAgIGFjY2VzcyB0b2tlbiBhbmQg a2lkIHZhbHVlcyBpbiBBQ0NFU1MtVE9LRU4gYW5kIFVTRVJOQU1FIFNUVU4KICAgYXR0cmlidXRl cy4gIFRoZSBUVVJOIGNsaWVudCBpbmNsdWRlcyBhIE1FU1NBR0UtSU5URUdSSVRZIGF0dHJpYnV0 ZQogICBhcyB0aGUgbGFzdCBhdHRyaWJ1dGUgaW4gdGhlIG1lc3NhZ2Ugb3ZlciB0aGUgY29udGVu dHMgb2YgdGhlIFRVUk4KICAgbWVzc2FnZS4gIFRoZSBITUFDIGZvciB0aGUgTUVTU0FHRS1JTlRF R1JJVFkgYXR0cmlidXRlIGlzIGNvbXB1dGVkIGFzCiAgIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDE1 LjQgb2YgW1JGQzUzODldIHdoZXJlIHRoZSBtYWNfa2V5IGlzIHVzZWQgYXMKICAgdGhlIGlucHV0 IGtleSBmb3IgdGhlIEhNQUMgY29tcHV0YXRpb24uICBUaGUgVFVSTiBjbGllbnQgYW5kIHNlcnZl cgogICB3aWxsIHVzZSB0aGUgbWFjX2tleSB0byBjb21wdXRlIHRoZSBtZXNzYWdlIGludGVncml0 eSBhbmQgZG9lc24ndAogICBoYXZlIHRvIHBlcmZvcm0gTUQ1IGhhc2ggb24gdGhlIGNyZWRlbnRp YWxzLgoKNi4gIFNUVU4gQXR0cmlidXRlcwoKICAgVGhlIGZvbGxvd2luZyBuZXcgU1RVTiBhdHRy aWJ1dGVzIGFyZSBpbnRyb2R1Y2VkIGJ5IHRoaXMKICAgc3BlY2lmaWNhdGlvbiB0byBhY2NvbXBs aXNoIHRoaXJkIHBhcnR5IGF1dGhvcml6YXRpb24uCgo2LjEuICBUSElSRC1QQVJUWS1BVVRIT1JJ WkFUSU9OCgogICBUaGlzIGF0dHJpYnV0ZSBpcyB1c2VkIGJ5IHRoZSBUVVJOIHNlcnZlciB0byBp bmZvcm0gdGhlIGNsaWVudCB0aGF0CiAgIGl0IHN1cHBvcnRzIHRoaXJkIHBhcnR5IGF1dGhvcml6 YXRpb24uICBUaGlzIGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlucwogICB0aGUgVFVSTiBzZXJ2ZXIg bmFtZS4gIFRoZSBUVVJOIHNlcnZlciBtYXkgaGF2ZSB0aWUtdXAgd2l0aCBtdWx0aXBsZQogICBh dXRob3JpemF0aW9uIHNlcnZlcnMgYW5kIHZpY2UgdmVyc2EsIHNvIHRoZSBjbGllbnQgTVVTVCBw cm92aWRlIHRoZQogICBUVVJOIHNlcnZlciBuYW1lIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBzbyB0aGF0IGl0IGNhbiBzZWxlY3QKICAgdGhlIGFwcHJvcHJpYXRlIGtleWluZyBtYXRlcmlh bCB0byBnZW5lcmF0ZSB0aGUgc2VsZi1jb250YWluZWQgdG9rZW4uCiAgIFRoZSBUSElSRC1QQVJU WS1BVVRIT1JJWkFUSU9OIGF0dHJpYnV0ZSBpcyBhIGNvbXByZWhlbnNpb24tb3B0aW9uYWwKICAg YXR0cmlidXRlIChzZWUgU2VjdGlvbiAxNSBmcm9tIFtSRkM1Mzg5XSkuCgo2LjIuICBBQ0NFU1Mt VE9LRU4KCiAgIFRoZSBhY2Nlc3MgdG9rZW4gaXMgaXNzdWVkIGJ5IHRoZSBhdXRob3JpemF0aW9u IHNlcnZlci4gIE9BdXRoIGRvZXMKICAgbm90IGltcG9zZSBhbnkgbGltaXRhdGlvbiBvbiB0aGUg bGVuZ3RoIG9mIHRoZSBhY2Nlc3MgdG9rZW4gYnV0IGlmCiAgIHBhdGggTVRVIGlzIHVua25vd24g dGhlbiBTVFVOIG1lc3NhZ2VzIG92ZXIgSVB2NCB3b3VsZCBuZWVkIHRvIGJlCiAgIGxlc3MgdGhh biA1NDggYnl0ZXMgKFNlY3Rpb24gNy4xIG9mIFtSRkM1Mzg5XSksIGFjY2VzcyB0b2tlbiBsZW5n dGgKICAgbmVlZHMgdG8gYmUgcmVzdHJpY3RlZCB0byBmaXQgd2l0aGluIHRoZSBtYXhpbXVtIFNU VU4gbWVzc2FnZSBzaXplLgogICBOb3RlIHRoYXQgdGhlIHNlbGYtY29udGFpbmVkIHRva2VuIGlz IG9wYXF1ZSB0byB0aGUgY2xpZW50IGFuZCBpdAogICBNVVNUIE5PVCBleGFtaW5lIHRoZSB0aWNr ZXQuICBUaGUgQUNDRVNTLVRPS0VOIGF0dHJpYnV0ZSBpcyBhCiAgIGNvbXByZWhlbnNpb24tb3B0 aW9uYWwgYXR0cmlidXRlIChzZWUgU2VjdGlvbiAxNSBmcm9tIFtSRkM1Mzg5XSkuCgogICBUaGUg dG9rZW4gaXMgc3RydWN0dXJlZCBhcyBmb2xsb3dzOgoKICAgICAgICAgc3RydWN0IHsKICAgICAg ICAgICAgIG9wYXF1ZSB7CiAgICAgICAgICAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVk JyA+dXNob3J0PC9mb250Pjwvc3RyaWtlPgogICAgICAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQg Y29sb3I9J2dyZWVuJyA+dWludDE2X3Q8L2ZvbnQ+PC9zdHJvbmc+IGtleV9sZW5ndGg7CiAgICAg ICAgICAgICAgICAgb3BhcXVlIG1hY19rZXlba2V5X2xlbmd0aF07CiAgICAgICAgICAgICAgICAg PHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+b3BhcXVlIHRpbWVzdGFtcFs4XTsKICAgICAgICAg ICAgICAgICBsb25nPC9mb250Pjwvc3RyaWtlPgogICAgICAgICAgICAgICAgIDxzdHJvbmc+PGZv bnQgY29sb3I9J2dyZWVuJyA+dWludDY0X3QgdGltZXN0YW1wOwogICAgICAgICAgICAgICAgIHVp bnQzMl90PC9mb250Pjwvc3Ryb25nPiBsaWZldGltZTsKICAgICAgICAgICAgIH0gZW5jcnlwdGVk X2Jsb2NrOwogICAgICAgICAgICAgb3BhcXVlIG1hY1ttYWNfbGVuZ3RoXTsKICAgICAgICAgfSB0 b2tlbjsKCiAgICAgICAgICAgICAgICAgICBGaWd1cmUgNjogU2VsZi1jb250YWluZWQgdG9rZW4g Zm9ybWF0CgogICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPk5vdGU6IHVpbnROX3QgbWVh bnMgYW4gdW5zaWduZWQgaW50ZWdlciBvZiBleGFjdGx5IE4gYml0cy4gIFNpbmdsZS0KICAgYnl0 ZSBlbnRpdGllcyBjb250YWluaW5nIHVuaW50ZXJwcmV0ZWQgZGF0YSBhcmUgb2YgdHlwZSBvcGFx dWUuICBBbGwKICAgdmFsdWVzIGluIHRoZSB0b2tlbiBhcmUgc3RvcmVkIGluIG5ldHdvcmsgYnl0 ZSBvcmRlci48L2ZvbnQ+PC9zdHJvbmc+CgogICBUaGUgZmllbGRzIGFyZSBkZXNjcmliZWQgYmVs b3c6CgogICBrZXlfbGVuZ3RoOiAgTGVuZ3RoIG9mIHRoZSBzZXNzaW9uIGtleS4gIEtleSBsZW5n dGggb2YgMTYwLWJpdHMgTVVTVAogICAgICBiZSBzdXBwb3J0ZWQgKGkuZSBvbmx5IDE2MC1iaXQg a2V5IGlzIHVzZWQgYnkgSE1BQy1TSEEtMSBmb3IKICAgICAgbWVzc2FnZSBpbnRlZ3JpdHkgb2Yg U1RVTiBtZXNzYWdlKS4gIFRoZSBrZXkgbGVuZ3RoIGZhY2lsaXRhdGVzCiAgICAgIHRoZSBoYXNo IGFnaWxpdHkgcGxhbiBkaXNjdXNzZWQgaW4gc2VjdGlvbiAxNi4zIG9mIFtSRkM1Mzg5XS4KCiAg IG1hY19rZXk6ICBUaGUgc2Vzc2lvbiBrZXkgZ2VuZXJhdGVkIGJ5IHRoZSBhdXRob3JpemF0aW9u IHNlcnZlci4KCiAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPlRpbWVzdGFtcDo8L2ZvbnQ+ PC9zdHJpa2U+CgogICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPnRpbWVzdGFtcDo8L2Zv bnQ+PC9zdHJvbmc+ICA2NC1iaXQgdW5zaWduZWQgaW50ZWdlciBmaWVsZCBjb250YWluaW5nIGEg dGltZXN0YW1wLgogICAgICBUaGUgdmFsdWUgaW5kaWNhdGVzIHRoZSB0aW1lIHNpbmNlIEphbnVh cnkgMSwgMTk3MCwgMDA6MDAgVVRDLCBieQogICAgICB1c2luZyBhIGZpeGVkIHBvaW50IGZvcm1h dC4gIEluIHRoaXMgZm9ybWF0LCB0aGUgaW50ZWdlciBudW1iZXIgb2YKICAgICAgc2Vjb25kcyBp cyBjb250YWluZWQgaW4gdGhlIGZpcnN0IDQ4IGJpdHMgb2YgdGhlIGZpZWxkLCBhbmQgdGhlCiAg ICAgIHJlbWFpbmluZyAxNiBiaXRzIGluZGljYXRlIHRoZSBudW1iZXIgb2YgMS82NEsgZnJhY3Rp b25zIG9mIGEKICAgICAgc2Vjb25kIChOYXRpdmUgZm9ybWF0IC0gVW5peCkuCgogICA8c3RyaWtl Pjxmb250IGNvbG9yPSdyZWQnID5MaWZldGltZTo8L2ZvbnQ+PC9zdHJpa2U+CgogICA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbicgPmxpZmV0aW1lOjwvZm9udD48L3N0cm9uZz4gIFRoZSBsaWZl dGltZSBvZiB0aGUgYWNjZXNzIHRva2VuLCBpbiBzZWNvbmRzLiAgRm9yCiAgICAgIGV4YW1wbGUs IHRoZSB2YWx1ZSAzNjAwIGluZGljYXRlcyBvbmUgaG91ci4gIFRoZSBMaWZldGltZSB2YWx1ZQog ICAgICBTSE9VTEQgYmUgZXF1YWwgdG8gdGhlICJleHBpcmVzX2luIiBwYXJhbWV0ZXIgZGVmaW5l ZCBpbiBzZWN0aW9uCiAgICAgIDQuMi4yIG9mIFtSRkM2NzQ5XS4KCiAgIDxzdHJvbmc+PGZvbnQg Y29sb3I9J2dyZWVuJyA+ZW5jcnlwdGVkX2Jsb2NrOiAgVGhlIGVuY3J5cHRlZF9ibG9jayBpcyBl bmNyeXB0ZWQgdXNpbmcgdGhlCiAgICAgIHN5bW1ldHJpYyBsb25nLXRlcm0ga2V5IGVzdGFibGlz aGVkIGJldHdlZW4gdGhlIHJlc291cmNlIHNlcnZlcgogICAgICBhbmQgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyLiAgU2hvd24gaW4gRmlndXJlIDUgYXMgQVMtUlMga2V5LjwvZm9udD48L3N0cm9u Zz4KCiAgIG1hYzogIFRoZSBIYXNoZWQgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiBDb2RlIChITUFD KSBpcyBjYWxjdWxhdGVkCiAgICAgIHdpdGggPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID50 aGU8L2ZvbnQ+PC9zdHJvbmc+IEFVVEgga2V5IG92ZXIgdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9 J3JlZCcgPmVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSB0b2tlbjwvZm9udD48L3N0cmlrZT4gPHN0 cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID4nZW5jcnlwdGVkX2Jsb2NrJzwvZm9udD48L3N0cm9u Zz4gYW5kIHRoZSBUVVJOIHNlcnZlcgogICAgICBuYW1lIChOKSBjb252ZXllZCBpbiB0aGUgVEhJ UkQtUEFSVFktQVVUSE9SSVpBVElPTiByZXNwb25zZS4gIDxzdHJpa2U+PGZvbnQgY29sb3I9J3Jl ZCcgPkVuY3J5cHRpb24gaXMgYXBwbGllZCBiZWZvcmUgYXV0aGVudGljYXRpb24gb248L2ZvbnQ+ PC9zdHJpa2U+ICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPlRoaXMKICAgICAgZW5zdXJl cyB0aGF0PC9mb250Pjwvc3Ryb25nPiB0aGUKICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVk JyA+c2VuZGVyIHNpZGUgYW5kIGNvbnZlcnNlbHkgb248L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJyA+Y2xpZW50IGRvZXMgbm90IHVzZTwvZm9udD48L3N0cm9uZz4g dGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPnJlY2VpdmVyIHNpZGUuPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPnNhbWUgdG9rZW4gdG8gZ2FpbgogICAg ICBpbGxlZ2FsIGFjY2VzcyB0byBvdGhlciBUVVJOIHNlcnZlcnMgcHJvdmlkZWQgYnkgdGhlIHNh bWUKICAgICAgYWRtaW5pc3RyYXRpdmUgZG9tYWluIGkuZS4sIHdoZW4gbXVsdGlwbGUgVFVSTiBz ZXJ2ZXJzIGluIGEgc2luZ2xlCiAgICAgIGFkbWluaXN0cmF0aXZlIGRvbWFpbiBzaGFyZSB0aGUg c2FtZSBzeW1tZXRyaWMga2V5IHdpdGggYW4KICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuPC9m b250Pjwvc3Ryb25nPiAgVGhlIGxlbmd0aCBvZiB0aGUgbWFjIGZpZWxkIGlzIGtub3duIHRvIHRo ZQogICAgICBUVVJOIGFuZCBhdXRob3JpemF0aW9uIHNlcnZlciBiYXNlZCBvbiB0aGUgbmVnb3Rp YXRlZCBNQUMKICAgICAgYWxnb3JpdGhtLgoKICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+ Rm9yPC9mb250Pjwvc3RyaWtlPgoKICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5Bbjwv Zm9udD48L3N0cm9uZz4gZXhhbXBsZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID50aGU8L2Zv bnQ+PC9zdHJpa2U+IGVuY3J5cHRpb24gcHJvY2VzcyA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQn ID5jYW4gYmU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+aXM8 L2ZvbnQ+PC9zdHJvbmc+IGlsbHVzdHJhdGVkIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPmFz IGZvbGxvd3MuPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPmJl bG93LjwvZm9udD48L3N0cm9uZz4gIEhlcmUgQywgTiBkZW5vdGUgPHN0cmlrZT48Zm9udCBjb2xv cj0ncmVkJyA+dGhlIGNpcGhlcnRleHQ8L2ZvbnQ+PC9zdHJpa2U+CiAgIDxzdHJvbmc+PGZvbnQg Y29sb3I9J2dyZWVuJyA+Q2lwaGVydGV4dDwvZm9udD48L3N0cm9uZz4gYW5kIFRVUk4gc2VydmVy IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPm5hbWUuPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbicgPm5hbWUgcmVzcGVjdGl2ZWx5LjwvZm9udD48L3N0cm9uZz4K CiAgIG8gIEMgPSBBRVNfMjU2X0NCQyhBUy1SUywgZW5jcnlwdGVkX2Jsb2NrKQoKICAgbyAgbWFj ID0gSE1BQy1TSEEtMjU2LTEyOChBVVRILCBDIHwgfCBOKQogICA8c3RyaWtlPjxmb250IGNvbG9y PSdyZWQnID5UaGUgdG9rZW4gTVVTVCBiZSBlbmNvZGVkIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA0 IG9mIFtSRkM0NjQ4XTwvZm9udD48L3N0cmlrZT4KCiAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dy ZWVuJyA+RW5jcnlwdGlvbiBpcyBhcHBsaWVkIGJlZm9yZSBtZXNzYWdlIGF1dGhlbnRpY2F0aW9u IG9uIHRoZSBzZW5kZXIKICAgc2lkZTwvZm9udD48L3N0cm9uZz4gYW5kCiAgIDxzdHJpa2U+PGZv bnQgY29sb3I9J3JlZCcgPnRoZW4gZW5jcnlwdGVkIHVzaW5nPC9mb250Pjwvc3RyaWtlPiA8c3Ry b25nPjxmb250IGNvbG9yPSdncmVlbicgPmNvbnZlcnNlbHkgb248L2ZvbnQ+PC9zdHJvbmc+IHRo ZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5zeW1tZXRyaWMgbG9uZy10ZXJtIGtleSBlc3Rh Ymxpc2hlZCBiZXR3ZWVuPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVl bicgPnJlY2VpdmVyIHNpZGUuICBUaGUgZW50aXJlIHRva2VuIGkuZS4sPC9mb250Pjwvc3Ryb25n PiB0aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+cmVzb3VyY2Ugc2VydmVyPC9mb250Pjwv c3RyaWtlPgogICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPidlbmNyeXB0ZWRfYmxvY2sn PC9mb250Pjwvc3Ryb25nPiBhbmQgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+dGhlIGF1dGhv cml6YXRpb24gc2VydmVyLCBhcyBzaG93biBpbgogICBGaWd1cmUgNSBhcyBBUy1SUyBrZXkuICBI TUFDPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPidtYWMnPC9m b250Pjwvc3Ryb25nPiBpcyA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5jb21wdXRlZCB1c2lu ZyB0aGUgZW5jcnlwdGVkIHBvcnRpb248L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29s b3I9J2dyZWVuJyA+YmFzZTY0IGVuY29kZWQgKHNlZSBzZWN0aW9uIDQ8L2ZvbnQ+PC9zdHJvbmc+ IG9mIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPnRoZSB0b2tlbjwvZm9udD48L3N0cmlrZT4K ICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5bUkZDNDY0OF0pPC9mb250Pjwvc3Ryb25n PiBhbmQgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+VFVSTiBzZXJ2ZXIgbmFtZSB0byBlbnN1 cmUgdGhhdDwvZm9udD48L3N0cmlrZT4gdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPmNs aWVudCBkb2VzIG5vdAogICB1c2UgdGhlIHNhbWUgdG9rZW4gdG8gZ2FpbiBpbGxlZ2FsPC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPnJlc3VsdGluZzwvZm9udD48 L3N0cm9uZz4gYWNjZXNzIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPnRvIG90aGVyIFRVUk4g c2VydmVycwogICBwcm92aWRlZCBieSB0aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4uICBU aGlzIGF0dGFjazwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID50 b2tlbjwvZm9udD48L3N0cm9uZz4gaXMgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+cG9zc2li bGUKICAgd2hlbiBtdWx0aXBsZSBUVVJOIHNlcnZlcnMgaW4gYSBzaW5nbGUgYWRtaW5pc3RyYXRp dmUgZG9tYWluIHNoYXJlCiAgIHRoZSBzYW1lIHN5bW1ldHJpYyBrZXkgd2l0aDwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5zaWduYWxlZCB0bzwvZm9udD48L3N0 cm9uZz4gdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPmF1dGhvcml6YXRpb24gc2VydmVy LjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5jbGllbnQuPC9m b250Pjwvc3Ryb25nPgogICBTaW5jZSB0aGUgYWNjZXNzIHRva2VuIGlzIDxzdHJvbmc+PGZvbnQg Y29sb3I9J2dyZWVuJyA+b25seTwvZm9udD48L3N0cm9uZz4gdmFsaWQgZm9yIGEgc3BlY2lmaWMg cGVyaW9kIG9mIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPnRpbWU8L2ZvbnQ+PC9zdHJpa2U+ IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+dGltZSw8L2ZvbnQ+PC9zdHJvbmc+CiAgIHRo ZSByZXNvdXJjZSBzZXJ2ZXIgTVVTVCBjYWNoZSBpdCBzbyB0aGF0IGl0IG5lZWQgbm90IHRvIGJl IHByb3ZpZGVkCiAgIGluIGV2ZXJ5IHJlcXVlc3Qgd2l0aGluIGFuIGV4aXN0aW5nIGFsbG9jYXRp b24uICBUaGUgYWNjZXNzIHRva2VuIGNhbgogICBiZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQn ID5yZS0KICAgdXNlZDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4n ID5yZXVzZWQ8L2ZvbnQ+PC9zdHJvbmc+IGZvciBtdWx0aXBsZSBBbGxvY2F0ZSByZXF1ZXN0cyB0 byB0aGUgc2FtZSBUVVJOIHNlcnZlci4KICAgVGhlIFRVUk4gY2xpZW50IE1VU1QgaW5jbHVkZSB0 aGUgQUNDRVNTLVRPS0VOIGF0dHJpYnV0ZSBvbmx5IGluCiAgIEFsbG9jYXRlIGFuZCBSZWZyZXNo IHJlcXVlc3RzLiAgSWYgQUVBRCBhbGdvcml0aG0gaXMgdXNlZCB0aGVuIHRoZXJlCiAgIGlzIG5v IG5lZWQgdG8gZXhwbGljaXRseSBjb21wdXRlIEhNQUMsIHRoZSBhc3NvY2lhdGVkIGRhdGEgTVVT VCBiZQogICB0aGUgVFVSTiBzZXJ2ZXIgbmFtZSAoTikgYW5kIHRoZSBtYWMgZmllbGQgTVVTVCBj YXJyeSB0aGUgbm9uY2UuICBUaGUKICAgbGVuZ3RoIG9mIG5vbmNlIE1VU1QgYmUgMTIgb2N0ZXRz LgoKNy4gIFJlY2VpdmluZyBhIHJlcXVlc3Qgd2l0aCBBQ0NFU1MtVE9LRU4gYXR0cmlidXRlCgog ICBUaGUgVFVSTiBzZXJ2ZXIsIG9uIHJlY2VpdmluZyBhIHJlcXVlc3Qgd2l0aCBBQ0NFU1MtVE9L RU4gYXR0cmlidXRlLAogICBwZXJmb3JtcyBjaGVja3MgbGlzdGVkIGluIHNlY3Rpb24gMTAuMi4y IG9mIFtSRkM1Mzg5XSBpbiBhZGRpdGlvbiB0bwogICB0aGUgZm9sbG93aW5nIHN0ZXBzIHRvIHZl cmlmeSB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gaXMgdmFsaWQ6CgogICBvICBUVVJOIHNlcnZlciBz ZWxlY3RzIHRoZSBrZXlpbmcgbWF0ZXJpYWwgYmFzZWQgb24ga2lkIHNpZ25hbGxlZCBpbgogICAg ICB0aGUgVVNFUk5BTUUgYXR0cmlidXRlLgoKICAgbyAgSXQgcGVyZm9ybXMgdGhlIHZlcmlmaWNh dGlvbiBvZiB0aGUgdG9rZW4gbWVzc2FnZSBpbnRlZ3JpdHkgYnkKICAgICAgY2FsY3VsYXRpbmcg SE1BQyBvdmVyIHRoZSBlbmNyeXB0ZWQgcG9ydGlvbiBpbiB0aGUgc2VsZi1jb250YWluZWQKICAg ICAgdG9rZW4gYW5kIFRVUk4gc2VydmVyIG5hbWUgdXNpbmcgQVVUSCBrZXkgYW5kIGlmIHRoZSBy ZXN1bHRpbmcKICAgICAgdmFsdWUgZG9lcyBub3QgbWF0Y2ggdGhlIG1hYyBmaWVsZCBpbiB0aGUg c2VsZi1jb250YWluZWQgdG9rZW4KICAgICAgdGhlbiBpdCByZWplY3RzIHRoZSByZXF1ZXN0IHdp dGggYW4gZXJyb3IgcmVzcG9uc2UgNDAxCiAgICAgIChVbmF1dGhvcml6ZWQpLiAgSWYgQUVBRCBh bGdvcml0aG0gaXMgdXNlZCB0aGVuIGl0IGhhcyBvbmx5IGEKICAgICAgc2luZ2xlIG91dHB1dCwg ZWl0aGVyIGEgcGxhaW50ZXh0IG9yIGEgc3BlY2lhbCBzeW1ib2wgRkFJTCB0aGF0CiAgICAgIGlu ZGljYXRlcyB0aGF0IHRoZSBpbnB1dHMgYXJlIG5vdCBhdXRoZW50aWMuCgogICBvICBUVVJOIHNl cnZlciBvYnRhaW5zIHRoZSBtYWNfa2V5IGJ5IHJldHJpZXZpbmcgdGhlIGNvbnRlbnQgb2YgdGhl CiAgICAgIGFjY2VzcyB0b2tlbiAod2hpY2ggcmVxdWlyZXMgZGVjcnlwdGlvbiBvZiB0aGUgc2Vs Zi1jb250YWluZWQKICAgICAgdG9rZW4gdXNpbmcgdGhlIEFTLVJTIGtleSkuCgogICBvICBUaGUg VFVSTiBzZXJ2ZXIgdmVyaWZpZXMgdGhhdCBubyByZXBsYXkgdG9vayBwbGFjZSBieSBwZXJmb3Jt aW5nCiAgICAgIHRoZSBmb2xsb3dpbmcgY2hlY2s6CgogICAgICAqICBUaGUgYWNjZXNzIHRva2Vu IGlzIGFjY2VwdGVkIGlmIHRoZSB0aW1lc3RhbXAgZmllbGQgKFRTKSBpbiB0aGUKICAgICAgICAg c2VsZi1jb250YWluZWQgdG9rZW4gaXMgcmVjZW50IGVub3VnaCB0byB0aGUgcmVjZXB0aW9uIHRp bWUgb2YKICAgICAgICAgdGhlIFRVUk4gcmVxdWVzdCAoUkRuZXcpIHVzaW5nIHRoZSBmb2xsb3dp bmcgZm9ybXVsYTogTGlmZXRpbWUKICAgICAgICAgKyBEZWx0YSAmZ3Q7IGFicyhSRG5ldyAtIFRT KS4gIFRoZSBSRUNPTU1FTkRFRCB2YWx1ZSBmb3IgdGhlCiAgICAgICAgIGFsbG93ZWQgRGVsdGEg aXMgNSBzZWNvbmRzLiAgSWYgdGhlIHRpbWVzdGFtcCBpcyBOT1Qgd2l0aGluIHRoZQogICAgICAg ICBib3VuZGFyaWVzIHRoZW4gdGhlIFRVUk4gc2VydmVyIGRpc2NhcmRzIHRoZSByZXF1ZXN0IHdp dGggZXJyb3IKICAgICAgICAgcmVzcG9uc2UgNDAxIChVbmF1dGhvcml6ZWQpLgoKICAgbyAgVGhl IFRVUk4gc2VydmVyIHVzZXMgdGhlIG1hY19rZXkgdG8gY29tcHV0ZSB0aGUgbWVzc2FnZSBpbnRl Z3JpdHkKICAgICAgb3ZlciB0aGUgcmVxdWVzdCBhbmQgaWYgdGhlIHJlc3VsdGluZyB2YWx1ZSBk b2VzIG5vdCBtYXRjaCB0aGUKICAgICAgY29udGVudHMgb2YgdGhlIE1FU1NBR0UtSU5URUdSSVRZ IGF0dHJpYnV0ZSB0aGVuIGl0IHJlamVjdHMgdGhlCiAgICAgIHJlcXVlc3Qgd2l0aCBhbiBlcnJv ciByZXNwb25zZSA0MDEgKFVuYXV0aG9yaXplZCkuCgogICBvICBJZiBhbGwgdGhlIGNoZWNrcyBw YXNzLCB0aGUgVFVSTiBzZXJ2ZXIgY29udGludWVzIHRvIHByb2Nlc3MgdGhlCiAgICAgIHJlcXVl c3QuICBBbnkgcmVzcG9uc2UgZ2VuZXJhdGVkIGJ5IHRoZSBzZXJ2ZXIgTVVTVCBpbmNsdWRlIHRo ZQogICAgICBNRVNTQUdFLUlOVEVHUklUWSBhdHRyaWJ1dGUsIGNvbXB1dGVkIHVzaW5nIHRoZSBt YWNfa2V5LgoKICAgVGhlIGxpZmV0aW1lIHByb3ZpZGVkIGJ5IHRoZSBUVVJOIHNlcnZlciBpbiB0 aGUgQWxsb2NhdGUgYW5kIFJlZnJlc2gKICAgcmVzcG9uc2VzIE1VU1QgYmUgbGVzcyB0aGFuIG9y IGVxdWFsIHRvIHRoZSBsaWZldGltZSBvZiB0aGUgdG9rZW4uCgo4LiAgQ2hhbmdlcyB0byBUVVJO IENsaWVudAoKICAgbyAgQSBUVVJOIHJlc3BvbnNlIGlzIGRpc2NhcmRlZCBieSB0aGUgY2xpZW50 IGlmIHRoZSB2YWx1ZSBjb21wdXRlZAogICAgICBmb3IgbWVzc2FnZSBpbnRlZ3JpdHkgdXNpbmcg bWFjX2tleSBkb2VzIG5vdCBtYXRjaCB0aGUgY29udGVudHMgb2YKICAgICAgdGhlIE1FU1NBR0Ut SU5URUdSSVRZIGF0dHJpYnV0ZS4KCiAgIG8gIElmIHRoZSBhY2Nlc3MgdG9rZW4gZXhwaXJlcyB0 aGVuIHRoZSBjbGllbnQgTVVTVCBvYnRhaW4gYSBuZXcKICAgICAgdG9rZW4gZnJvbSB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHVzZSBpdCBmb3IgbmV3CiAgICAgIGFsbG9jYXRpb25zLiAg VGhlIGNsaWVudCBNVVNUIGFsc28gdXNlIHRoZSBuZXcgdG9rZW4gdG8gcmVmcmVzaAogICAgICBl eGlzdGluZyBhbGxvY2F0aW9ucy4gIFRoaXMgd2F5IGNsaWVudCBoYXMgdG8gbWFpbnRhaW4gb25s eSBvbmUKICAgICAgdG9rZW4gcGVyIFRVUk4gc2VydmVyLgoKOS4gIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zCgogICBXaGVuIE9BdXRoIGlzIHVzZWQgdGhlIGludGVyYWN0aW9uIGJldHdlZW4gdGhl IGNsaWVudCBhbmQgdGhlCiAgIGF1dGhvcml6YXRpb24gc2VydmVyIHJlcXVpcmVzIFRyYW5zcG9y dCBMYXllciBTZWN1cml0eSAoVExTKSB3aXRoIGEKICAgY2lwaGVyc3VpdGUgb2ZmZXJpbmcgY29u ZmlkZW50aWFsaXR5IHByb3RlY3Rpb24uICBUaGUgc2Vzc2lvbiBrZXkKICAgTVVTVCBOT1QgYmUg dHJhbnNtaXR0ZWQgaW4gY2xlYXIgc2luY2UgdGhpcyB3b3VsZCBjb21wbGV0ZWx5IGRlc3Ryb3kK ICAgdGhlIHNlY3VyaXR5IGJlbmVmaXRzIG9mIHRoZSBwcm9wb3NlZCBzY2hlbWUuICBJZiBhbiBh dHRhY2tlciB0cmllcwogICB0byByZXBsYXkgbWVzc2FnZSB3aXRoIEFDQ0VTUy1UT0tFTiBhdHRy aWJ1dGUgdGhlbiB0aGUgc2VydmVyIGNhbgogICBkZXRlY3QgdGhhdCB0aGUgdHJhbnNhY3Rpb24g SUQgYXMgdXNlZCBmb3IgYW4gb2xkIHJlcXVlc3QgYW5kIHRodXMKICAgcHJldmVudCB0aGUgcmVw bGF5IGF0dGFjay4KCiAgIFRocmVhdCBtaXRpZ2F0aW9uIGRpc2N1c3NlZCBpbiBzZWN0aW9uIDUg b2YKICAgW0ktRC5pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmVdIGFuZCBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBpbgogICBbUkZDNTc2Nl0gYXJlIHRvIGJlIHRha2VuIGludG8gYWNjb3VudC4K CjEwLiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gYWRkIHRo ZSBmb2xsb3dpbmcgYXR0cmlidXRlcyB0byB0aGUgU1RVTgogICBhdHRyaWJ1dGUgcmVnaXN0cnkg W2lhbmEtc3R1bl0sCgogICBvICBUSElSRC1QQVJUWS1BVVRIT1JJWkFUSU9OCgogICBvICBBQ0NF U1MtVE9LRU4KCjExLiAgQWNrbm93bGVkZ2VtZW50cwoKICAgQXV0aG9ycyB3b3VsZCBsaWtlIHRv IHRoYW5rIERhbiBXaW5nLCBQYWwgTWFydGluc2VuLCBPbGVnIE1vc2thbGVua28sCiAgIENoYXJs ZXMgRWNrZWwgYW5kIEhhbm5lcyBUc2Nob2ZlbmlnIGZvciBjb21tZW50cyBhbmQgcmV2aWV3LiAg VGhlCiAgIGF1dGhvcnMgd291bGQgbGlrZSB0byBnaXZlIHNwZWNpYWwgdGhhbmtzIHRvIEJyYW5k b24gV2lsbGlhbXMgZm9yIGhpcwogICBoZWxwLgoKMTIuICBSZWZlcmVuY2VzCgoxMi4xLiAgTm9y bWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMg Zm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2 ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtSRkM0NjQ4XSAgSm9zZWZz c29uLCBTLiwgIlRoZSBCYXNlMTYsIEJhc2UzMiwgYW5kIEJhc2U2NCBEYXRhCiAgICAgICAgICAg ICAgRW5jb2RpbmdzIiwgUkZDIDQ2NDgsIE9jdG9iZXIgMjAwNi4KCiAgIFtSRkM0ODY4XSAgS2Vs bHksIFMuIGFuZCBTLiBGcmFua2VsLCAiVXNpbmcgSE1BQy1TSEEtMjU2LCBITUFDLVNIQS0KICAg ICAgICAgICAgICAzODQsIGFuZCBITUFDLVNIQS01MTIgd2l0aCBJUHNlYyIsIFJGQyA0ODY4LCBN YXkgMjAwNy4KCiAgIFtSRkM1MTE2XSAgTWNHcmV3LCBELiwgIkFuIEludGVyZmFjZSBhbmQgQWxn b3JpdGhtcyBmb3IgQXV0aGVudGljYXRlZAogICAgICAgICAgICAgIEVuY3J5cHRpb24iLCBSRkMg NTExNiwgSmFudWFyeSAyMDA4LgoKICAgW1JGQzUzODldICBSb3NlbmJlcmcsIEouLCBNYWh5LCBS LiwgTWF0dGhld3MsIFAuLCBhbmQgRC4gV2luZywKICAgICAgICAgICAgICAiU2Vzc2lvbiBUcmF2 ZXJzYWwgVXRpbGl0aWVzIGZvciBOQVQgKFNUVU4pIiwgUkZDIDUzODksCiAgICAgICAgICAgICAg T2N0b2JlciAyMDA4LgoKICAgW1JGQzY3NDldICBIYXJkdCwgRC4sICJUaGUgT0F1dGggMi4wIEF1 dGhvcml6YXRpb24gRnJhbWV3b3JrIiwgUkZDCiAgICAgICAgICAgICAgNjc0OSwgT2N0b2JlciAy MDEyLgoKICAgW2lhbmEtc3R1bl0KICAgICAgICAgICAgICBJQU5BLCAsICJJQU5BOiBTVFVOIEF0 dHJpYnV0ZXMiLCBBcHJpbCAyMDExLAogICAgICAgICAgICAgICZsdDtodHRwOi8vd3d3LmlhbmEu b3JnL2Fzc2lnbm1lbnRzL3N0dW4tcGFyYW1ldGVycy9zdHVuLXBhCiAgICAgICAgICAgICAgcmFt ZXRlcnMueG1sJmd0Oy4KCjEyLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbSS1ELmll dGYtb2F1dGgtcG9wLWFyY2hpdGVjdHVyZV0KICAgICAgICAgICAgICBIdW50LCBQLiwgUmljaGVy LCBKLiwgTWlsbHMsIFcuLCBNaXNocmEsIFAuLCBhbmQgSC4KICAgICAgICAgICAgICBUc2Nob2Zl bmlnLCAiT0F1dGggMi4wIFByb29mLW9mLVBvc3Nlc3Npb24gKFBvUCkgU2VjdXJpdHkKICAgICAg ICAgICAgICBBcmNoaXRlY3R1cmUiLCBkcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUt MDAgKHdvcmsKICAgICAgICAgICAgICBpbiBwcm9ncmVzcyksIEp1bHkgMjAxNC4KCiAgIFtJLUQu aWV0Zi1vYXV0aC1wb3Ata2V5LWRpc3RyaWJ1dGlvbl0KICAgICAgICAgICAgICBCcmFkbGV5LCBK LiwgSHVudCwgUC4sIEpvbmVzLCBNLiwgYW5kIEguIFRzY2hvZmVuaWcsCiAgICAgICAgICAgICAg Ik9BdXRoIDIuMCBQcm9vZi1vZi1Qb3NzZXNzaW9uOiBBdXRob3JpemF0aW9uIFNlcnZlciB0bwog ICAgICAgICAgICAgIENsaWVudCBLZXkgRGlzdHJpYnV0aW9uIiwgZHJhZnQtaWV0Zi1vYXV0aC1w b3Ata2V5LQogICAgICAgICAgICAgIGRpc3RyaWJ1dGlvbi0wMCAod29yayBpbiBwcm9ncmVzcyks IEp1bHkgMjAxNC4KCiAgIFtJLUQuaWV0Zi1ydGN3ZWItb3ZlcnZpZXddCiAgICAgICAgICAgICAg QWx2ZXN0cmFuZCwgSC4sICJPdmVydmlldzogUmVhbCBUaW1lIFByb3RvY29scyBmb3IKICAgICAg ICAgICAgICBCcm93c2VyLWJhc2VkIEFwcGxpY2F0aW9ucyIsIGRyYWZ0LWlldGYtcnRjd2ViLW92 ZXJ2aWV3LTExCiAgICAgICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBBdWd1c3QgMjAxNC4K CiAgIFtJLUQuaWV0Zi10cmFtLWF1dGgtcHJvYmxlbXNdCiAgICAgICAgICAgICAgUmVkZHksIFQu LCBSLCBSLiwgUGVydW1hbCwgTS4sIGFuZCBBLiBZZWdpbiwgIlByb2JsZW1zCiAgICAgICAgICAg ICAgd2l0aCBTVFVOIGxvbmctdGVybSBBdXRoZW50aWNhdGlvbiBmb3IgVFVSTiIsIGRyYWZ0LWll dGYtCiAgICAgICAgICAgICAgdHJhbS1hdXRoLXByb2JsZW1zLTA1ICh3b3JrIGluIHByb2dyZXNz KSwgQXVndXN0IDIwMTQuCgogICBbUkZDNTc2Nl0gIE1haHksIFIuLCBNYXR0aGV3cywgUC4sIGFu ZCBKLiBSb3NlbmJlcmcsICJUcmF2ZXJzYWwgVXNpbmcKICAgICAgICAgICAgICBSZWxheXMgYXJv dW5kIE5BVCAoVFVSTik6IFJlbGF5IEV4dGVuc2lvbnMgdG8gU2Vzc2lvbgogICAgICAgICAgICAg IFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikiLCBSRkMgNTc2NiwgQXByaWwgMjAx MC4KCiAgIFtSRkM1ODY5XSAgS3Jhd2N6eWssIEguIGFuZCBQLiBFcm9uZW4sICJITUFDLWJhc2Vk IEV4dHJhY3QtYW5kLUV4cGFuZAogICAgICAgICAgICAgIEtleSBEZXJpdmF0aW9uIEZ1bmN0aW9u IChIS0RGKSIsIFJGQyA1ODY5LCBNYXkgMjAxMC4KCiAgIFtSRkM2MDYzXSAgRG9oZXJ0eSwgQS4s IFBlaSwgTS4sIE1hY2hhbmksIFMuLCBhbmQgTS4gTnlzdHJvbSwKICAgICAgICAgICAgICAiRHlu YW1pYyBTeW1tZXRyaWMgS2V5IFByb3Zpc2lvbmluZyBQcm90b2NvbCAoRFNLUFApIiwgUkZDCiAg ICAgICAgICAgICAgNjA2MywgRGVjZW1iZXIgMjAxMC4KCiAgIFtSRkM2ODE5XSAgTG9kZGVyc3Rl ZHQsIFQuLCBNY0dsb2luLCBNLiwgYW5kIFAuIEh1bnQsICJPQXV0aCAyLjAKICAgICAgICAgICAg ICBUaHJlYXQgTW9kZWwgYW5kIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIiwgUkZDIDY4MTksCiAg ICAgICAgICAgICAgSmFudWFyeSAyMDEzLgoKQXV0aG9ycycgQWRkcmVzc2VzCiAgIFRpcnVtYWxl c3dhciBSZWRkeQogICBDaXNjbyBTeXN0ZW1zLCBJbmMuCiAgIENlc3NuYSBCdXNpbmVzcyBQYXJr LCBWYXJ0aHVyIEhvYmxpCiAgIFNhcmphcHVyIE1hcmF0aGFsbGkgT3V0ZXIgUmluZyBSb2FkCiAg IEJhbmdhbG9yZSwgS2FybmF0YWthICA1NjAxMDMKICAgSW5kaWEKCiAgIEVtYWlsOiB0aXJlZGR5 QGNpc2NvLmNvbQoKICAgUHJhc2hhbnRoIFBhdGlsCiAgIENpc2NvIFN5c3RlbXMsIEluYy4KICAg QmFuZ2Fsb3JlCiAgIEluZGlhCgogICBFbWFpbDogcHJhc3BhdGlAY2lzY28uY29tCgogICBSYW0g TW9oYW4gUmF2aW5kcmFuYXRoCiAgIENpc2NvIFN5c3RlbXMsIEluYy4KICAgQ2Vzc25hIEJ1c2lu ZXNzIFBhcmssCiAgIEthZGFiZWVzYW5haGFsbGkgVmlsbGFnZSwgVmFydGh1ciBIb2JsaSwKICAg U2FyamFwdXItTWFyYXRoYWhhbGxpIE91dGVyIFJpbmcgUm9hZAogICBCYW5nYWxvcmUsIEthcm5h dGFrYSAgNTYwMTAzCiAgIEluZGlhCgogICBFbWFpbDogcm1vaGFuckBjaXNjby5jb20KCiAgIEp1 c3RpbiBVYmVydGkKICAgR29vZ2xlCiAgIDc0NyA2dGggQXZlIFMKICAgS2lya2xhbmQsIFdBCiAg IDk4MDMzCiAgIFVTQQoKICAgRW1haWw6IGp1c3RpbkB1YmVydGkubmFtZQo8L3ByZT4KPC9ib2R5 PjwvaHRtbD4KWC1HZW5lcmF0b3I6IHB5aHQgMC4zNQoKPCEtLSBhcmdzOiB7Jy0tb2xkY29sb3Vy JzogJ3JlZCcsICctLXdpZHRoJzogJycsICdkaWZmdHlwZSc6ICctLWh3ZGlmZicsICdmaWxlbmFt ZTInOiAnXG5cblxuXG5UUkFNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgVC4gUmVkZHlcbkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQLiBQYXRpbFxuSW50ZW5kZWQg c3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgUi4gUmF2aW5k cmFuYXRoXG5FeHBpcmVzOiBNYXJjaCA5LCAyMDE1ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQ2lzY29cbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEouIFViZXJ0aVxuICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR29vZ2xl XG4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg U2VwdGVtYmVyIDUsIDIwMTRcblxuXG4gICAgICAgICAgICAgIFRVUk4gRXh0ZW5zaW9uIGZvciBU aGlyZCBQYXJ0eSBBdXRob3JpemF0aW9uXG4gICAgICAgICAgICAgICBkcmFmdC1pZXRmLXRyYW0t dHVybi10aGlyZC1wYXJ0eS1hdXRoei0wM1xuXG5BYnN0cmFjdFxuXG4gICBUaGlzIGRvY3VtZW50 IHByb3Bvc2VzIHRoZSB1c2Ugb2YgT0F1dGggdG8gb2J0YWluIGFuZCB2YWxpZGF0ZVxuICAgZXBo ZW1lcmFsIHRva2VucyB0aGF0IGNhbiBiZSB1c2VkIGZvciBUVVJOIGF1dGhlbnRpY2F0aW9uLiAg VGhlIHVzYWdlXG4gICBvZiBlcGhlbWVyYWwgdG9rZW5zIGVuc3VyZSB0aGF0IGFjY2VzcyB0byBh IFRVUk4gc2VydmVyIGNhbiBiZVxuICAgY29udHJvbGxlZCBldmVuIGlmIHRoZSB0b2tlbnMgYXJl IGNvbXByb21pc2VkLlxuXG5TdGF0dXMgb2YgVGhpcyBNZW1vXG5cbiAgIFRoaXMgSW50ZXJuZXQt RHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGVcbiAgIHByb3Zp c2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuXG5cbiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29y a2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nXG4gICBUYXNrIEZvcmNl IChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZVxuICAg d29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVu dCBJbnRlcm5ldC1cbiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZHJhZnRzL2N1cnJlbnQvLlxuXG4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50 cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHNcbiAgIGFuZCBtYXkgYmUgdXBkYXRl ZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55XG4gICB0 aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVy ZW5jZVxuICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4g cHJvZ3Jlc3MuIlxuXG4gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1hcmNo IDksIDIwMTUuXG5cbkNvcHlyaWdodCBOb3RpY2VcblxuICAgQ29weXJpZ2h0IChjKSAyMDE0IElF VEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlXG4gICBkb2N1bWVudCBh dXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC5cblxuICAgVGhpcyBkb2N1bWVudCBpcyBzdWJq ZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3RcJ3MgTGVnYWxcbiAgIFByb3Zpc2lvbnMg UmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHNcbiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9s aWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZlxuICAgcHVibGljYXRpb24gb2Yg dGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzXG4gICBjYXJlZnVs bHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJl c3BlY3RcbiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZy b20gdGhpcyBkb2N1bWVudCBtdXN0XG4gICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2Ug dGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2ZcblxuXG5cblJlZGR5LCBldCBhbC4g ICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCA5LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAx XVxuX1xuSW50ZXJuZXQtRHJhZnQgICAgICBUVVJOIGZvciAzcmQgcGFydHkgQXV0aG9yaXphdGlv biAgICAgIFNlcHRlbWJlciAyMDE0XG5cblxuICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMg YW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzXG4gICBkZXNjcmliZWQgaW4gdGhl IFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuXG5cblRhYmxlIG9mIENvbnRlbnRzXG5cbiAgIDEuICBJ bnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgMlxuICAgMi4gIFRlcm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzXG4gICAzLiAgU29sdXRpb24gT3ZlcnZpZXcgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDNcbiAgIDQuICBPYnRhaW5p bmcgYSBUb2tlbiBVc2luZyBPQXV0aCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg NlxuICAgICA0LjEuICBLZXkgRXN0YWJsaXNobWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA3XG4gICAgICAgNC4xLjEuICBEU0tQUCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDhcbiAgICAgICA0LjEuMi4gIEhUVFAg aW50ZXJhY3Rpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOFxuICAg ICAgIDQuMS4zLiAgTWFudWFsIHByb3Zpc2lvbmluZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA5XG4gICA1LiAgRm9ybWluZyBhIFJlcXVlc3QgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTBcbiAgIDYuICBTVFVOIEF0dHJpYnV0ZXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMFxuICAgICA2LjEu ICBUSElSRC1QQVJUWS1BVVRIT1JJWkFUSU9OIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDEwXG4gICAgIDYuMi4gIEFDQ0VTUy1UT0tFTiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMTBcbiAgIDcuICBSZWNlaXZpbmcgYSByZXF1ZXN0IHdpdGgg QUNDRVNTLVRPS0VOIGF0dHJpYnV0ZSAuIC4gLiAuIC4gLiAuICAxMlxuICAgOC4gIENoYW5nZXMg dG8gVFVSTiBDbGllbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEz XG4gICA5LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTNcbiAgIDEwLiBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNFxuICAgMTEuIEFja25vd2xlZGdlbWVu dHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0XG4gICAx Mi4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMTRcbiAgICAgMTIuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNFxuICAgICAxMi4yLiAgSW5mb3JtYXRpdmUgUmVm ZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1XG4gICBBdXRob3Jz XCcgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDE1XG5cbjEuICBJbnRyb2R1Y3Rpb25cblxuICAgVHJhdmVyc2FsIFVzaW5nIFJlbGF5IE5B VCAoVFVSTikgVFVSTiBbUkZDNTc2Nl0gaXMgYSBwcm90b2NvbCB0aGF0IGlzXG4gICBvZnRlbiB1 c2VkIHRvIGltcHJvdmUgdGhlIGNvbm5lY3Rpdml0eSBvZiBQMlAgYXBwbGljYXRpb25zLiAgQnlc biAgIHByb3ZpZGluZyBhIGNsb3VkLWJhc2VkIHJlbGF5IHNlcnZpY2UsIFRVUk4gZW5zdXJlcyB0 aGF0IGEgY29ubmVjdGlvblxuICAgY2FuIGJlIGVzdGFibGlzaGVkIGV2ZW4gd2hlbiBvbmUgb3Ig Ym90aCBzaWRlcyBpcyBpbmNhcGFibGUgb2YgYVxuICAgZGlyZWN0IFAyUCBjb25uZWN0aW9uLiAg SG93ZXZlciwgYXMgYSByZWxheSBzZXJ2aWNlLCBpdCBpbXBvc2VzIGFcbiAgIG5vbnRyaXZpYWwg Y29zdCBvbiB0aGUgc2VydmljZSBwcm92aWRlci4gIFRoZXJlZm9yZSwgYWNjZXNzIHRvIGEgVFVS TlxuICAgc2VydmljZSBpcyBhbG1vc3QgYWx3YXlzIGFjY2Vzcy1jb250cm9sbGVkLlxuXG4gICBU VVJOIHByb3ZpZGVzIGEgbWVjaGFuaXNtIHRvIGNvbnRyb2wgYWNjZXNzIHZpYSAibG9uZy10ZXJt IiB1c2VybmFtZS9cbiAgIHBhc3N3b3JkIGNyZWRlbnRpYWxzIHRoYXQgYXJlIHByb3ZpZGVkIGFz IHBhcnQgb2YgdGhlIFRVUk4gcHJvdG9jb2wuXG4gICBJdCBpcyBleHBlY3RlZCB0aGF0IHRoZXNl IGNyZWRlbnRpYWxzIHdpbGwgYmUga2VwdCBzZWNyZXQ7IGlmIHRoZVxuICAgY3JlZGVudGlhbHMg YXJlIGRpc2NvdmVyZWQsIHRoZSBUVVJOIHNlcnZlciBjb3VsZCBiZSB1c2VkIGJ5XG4gICB1bmF1 dGhvcml6ZWQgdXNlcnMgb3IgYXBwbGljYXRpb25zLiAgSG93ZXZlciwgaW4gd2ViIGFwcGxpY2F0 aW9ucyxcbiAgIGVuc3VyaW5nIHRoaXMgc2VjcmVjeSBpcyB0eXBpY2FsbHkgaW1wb3NzaWJsZS4g IFRvIGFkZHJlc3MgdGhpc1xuICAgcHJvYmxlbSBhbmQgdGhlIG9uZXMgZGVzY3JpYmVkIGluIFtJ LUQuaWV0Zi10cmFtLWF1dGgtcHJvYmxlbXNdLCB0aGlzXG4gICBkb2N1bWVudCBwcm9wb3NlcyB0 aGUgdXNlIG9mIHRoaXJkIHBhcnR5IGF1dGhvcml6YXRpb24gdXNpbmcgT0F1dGhcbiAgIGZvciBU VVJOLlxuXG5cblxuXG5cblJlZGR5LCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCA5 LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAyXVxuX1xuSW50ZXJuZXQtRHJhZnQgICAgICBU VVJOIGZvciAzcmQgcGFydHkgQXV0aG9yaXphdGlvbiAgICAgIFNlcHRlbWJlciAyMDE0XG5cblxu ICAgVG8gYWNoaWV2ZSB0aGlyZCBwYXJ0eSBhdXRob3JpemF0aW9uLCBhIHJlc291cmNlIG93bmVy IGUuZy4gIFdlYlJUQ1xuICAgc2VydmVyLCBhdXRob3JpemVzIGEgVFVSTiBjbGllbnQgdG8gYWNj ZXNzIHJlc291cmNlcyBvbiB0aGUgVFVSTlxuICAgc2VydmVyLlxuXG4gICBVc2luZyBPQXV0aCwg YSBjbGllbnQgb2J0YWlucyBhbiBlcGhlbWVyYWwgdG9rZW4gZnJvbSBhblxuICAgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgZS5nLiAgV2ViUlRDIHNlcnZlciwgYW5kIHRoZSB0b2tlbiBpcyBwcmVzZW50 ZWRcbiAgIHRvIHRoZSBUVVJOIHNlcnZlciBpbnN0ZWFkIG9mIHRoZSB0cmFkaXRpb25hbCBtZWNo YW5pc20gb2YgcHJlc2VudGluZ1xuICAgdXNlcm5hbWUvcGFzc3dvcmQgY3JlZGVudGlhbHMuICBU aGUgVFVSTiBzZXJ2ZXIgdmFsaWRhdGVzIHRoZVxuICAgYXV0aGVudGljaXR5IG9mIHRoZSB0b2tl biBhbmQgcHJvdmlkZXMgcmVxdWlyZWQgc2VydmljZXMuXG5cbjIuICBUZXJtaW5vbG9neVxuXG4g ICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwg IlNIQUxMIE5PVCIsXG4gICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAi TUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpc1xuICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVy cHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uXG5cbiAgIG8gIFdlYlJUQyBTZXJ2ZXI6 IEEgd2ViIHNlcnZlciB0aGF0IHN1cHBvcnRzIFdlYlJUQ1xuICAgICAgW0ktRC5pZXRmLXJ0Y3dl Yi1vdmVydmlld10uXG5cbiAgIG8gIEFjY2VzcyBUb2tlbjogT0F1dGggMi4wIGFjY2VzcyB0b2tl bi5cblxuICAgbyAgbWFjX2tleTogVGhlIHNlc3Npb24ga2V5IGdlbmVyYXRlZCBieSB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIuXG4gICAgICBUaGlzIHNlc3Npb24ga2V5IGhhcyBhIGxpZmV0aW1l IHRoYXQgY29ycmVzcG9uZHMgdG8gdGhlIGxpZmV0aW1lXG4gICAgICBvZiB0aGUgYWNjZXNzIHRv a2VuLCBpcyBnZW5lcmF0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZFxuICAgICAg Ym91bmQgdG8gdGhlIGFjY2VzcyB0b2tlbi5cblxuICAgbyAga2lkOiBBbiBlcGhlbWVyYWwgYW5k IHVuaXF1ZSBrZXkgaWRlbnRpZmllci4gIFRoZSBraWQgYWxzbyBhbGxvd3NcbiAgICAgIHRoZSBy ZXNvdXJjZSBzZXJ2ZXIgdG8gc2VsZWN0IHRoZSBhcHByb3ByaWF0ZSBrZXlpbmcgbWF0ZXJpYWwg Zm9yXG4gICAgICBkZWNyeXB0aW9uLlxuXG4zLiAgU29sdXRpb24gT3ZlcnZpZXdcblxuICAgVGhp cyBzcGVjaWZpY2F0aW9uIHVzZXMgdGhlIHRva2VuIHR5cGUgXCdBc3NlcnRpb25cJyAoYWthIHNl bGYtXG4gICBjb250YWluZWQgdG9rZW4pIGRlc2NyaWJlZCBpbiBbUkZDNjgxOV0gd2hlcmUgYWxs IHRoZSBpbmZvcm1hdGlvblxuICAgbmVjZXNzYXJ5IHRvIGF1dGhlbnRpY2F0ZSB0aGUgdmFsaWRp dHkgb2YgdGhlIHRva2VuIGlzIGNvbnRhaW5lZFxuICAgd2l0aGluIHRoZSB0b2tlbiBpdHNlbGYu ICBUaGlzIGFwcHJvYWNoIGhhcyB0aGUgYmVuZWZpdCBvZiBhdm9pZGluZyBhXG4gICBwcm90b2Nv bCBiZXR3ZWVuIHRoZSBUVVJOIHNlcnZlciBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGZv clxuICAgdG9rZW4gdmFsaWRhdGlvbiwgdGh1cyByZWR1Y2luZyBsYXRlbmN5LiAgVGhlIGV4YWN0 IG1lY2hhbmlzbSB1c2VkIGJ5XG4gICBhIGNsaWVudCB0byBvYnRhaW4gYSB0b2tlbiBmcm9tIHRo ZSBPQXV0aCBhdXRob3JpemF0aW9uIHNlcnZlciBpc1xuICAgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhpcyBkb2N1bWVudC4gIEZvciBleGFtcGxlLCBhIGNsaWVudCBjb3VsZCBtYWtlXG4gICBhbiBI VFRQIHJlcXVlc3QgdG8gYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gb2J0YWluIGEgdG9rZW4g dGhhdCBjYW5cbiAgIGJlIHVzZWQgdG8gYXZhaWwgVFVSTiBzZXJ2aWNlcy4gIFRoZSBUVVJOIHRv a2VuIGlzIHJldHVybmVkIGluIEpTT04sXG4gICBhbG9uZyB3aXRoIG90aGVyIE9BdXRoIFBhcmFt ZXRlcnMgbGlrZSB0b2tlbiB0eXBlLCBtYWNfa2V5LCBraWQsXG4gICB0b2tlbiBsaWZldGltZSBl dGMuICBUaGUgY2xpZW50IGlzIG9ibGl2aW91cyB0byB0aGUgY29udGVudCBvZiB0aGVcbiAgIHRv a2VuLiAgVGhlIHRva2VuIGlzIGVtYmVkZGVkIHdpdGhpbiBhIFRVUk4gcmVxdWVzdCBzZW50IHRv IHRoZSBUVVJOXG4gICBzZXJ2ZXIuICBPbmNlIHRoZSBUVVJOIHNlcnZlciBoYXMgZGV0ZXJtaW5l ZCB0aGUgdG9rZW4gaXMgdmFsaWQsIFRVUk5cbiAgIHNlcnZpY2VzIGFyZSBvZmZlcmVkIGZvciBh IGRldGVybWluZWQgcGVyaW9kIG9mIHRpbWUuXG5cblxuXG5cblJlZGR5LCBldCBhbC4gICAgICAg ICAgICAgRXhwaXJlcyBNYXJjaCA5LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAzXVxuX1xu SW50ZXJuZXQtRHJhZnQgICAgICBUVVJOIGZvciAzcmQgcGFydHkgQXV0aG9yaXphdGlvbiAgICAg IFNlcHRlbWJlciAyMDE0XG5cblxuICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAg ICAgICAgICAgICAgICstLS0tLS0tLSsgICstLS0tLS0tLS0rXG4gICBfIC4uLi4uLi4uLiAgVFVS TiAgIF8gICAgICAgICAgICAgICAgICAgICAgICAgXyAgVFVSTiAgXyAgXyAgV2ViUlRDIF9cbiAg IF8gLldlYlJUQyAuICBDbGllbnQgXyAgICAgICAgICAgICAgICAgICAgICAgICBfICAgICAgICBf ICBfICAgICAgICAgX1xuICAgXyAuQ2xpZW50IC4gICAgICAgICBfICAgICAgICAgICAgICAgICAg ICAgICAgIF8gU2VydmVyIF8gIF8gIFNlcnZlciBfXG4gICBfIC4uLi4uLi4uLiAgICAgICAgIF8g ICAgICAgICAgICAgICAgICAgICAgICAgXyAgICAgICAgXyAgXyAgICAgICAgIF9cbiAgICstLS0t LS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0rICArLS0t LS0tLS0tK1xuICAgICBfICAgICAgIF8gICAgICAgICAgIEFsbG9jYXRlIHJlcXVlc3QgICAgICAg ICAgICAgICAgXyAgICAgICAgIF9cbiAgICAgXyAgICAgICBfLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tX18gICAgICAgICBfXG4gICAgIF8gICAgICAgXyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfICAgICAgICAgX1xuICAgICBfICAg ICAgIF8gICAgICAgICBBbGxvY2F0ZSBlcnJvciByZXNwb25zZSAgICAgICAgICAgXyAgICAgICAg IF9cbiAgICAgXyAgICAgICBfXy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLV8gICAgICAgICBfXG4gICAgIF8gICAgICAgXyAgICAgICAgIFRISVJELVBBUlRZLUFVVEhP UklaQVRJT04gICAgICAgICBfICAgICAgICAgX1xuICAgICBfICAgICAgIF8gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXyAgICAgICAgIF9cbiAgICAgXyAgICAgICBf ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF8gICAgICAgICBfXG4g ICAgIF8gICAgICAgXyAgICAgIEhUVFAgUmVxdWVzdCBmb3IgdG9rZW4gICAgICAgICAgICAgICBf ICAgICAgICAgX1xuICAgICBfLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tX19cbiAgICAgXyAgICAgICBfICAgICAgSFRUUCBSZXNwb25z ZSB3aXRoIHRva2VuIHBhcmFtZXRlcnMgIF8gICAgICAgICBfXG4gICAgIF9fLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tX1xuICAgICBf T0F1dGggIF8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXyAgICAg ICAgIF9cbiAgICAgIEF0dHJpYnV0ZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIF8gICAgICAgICBfXG4gICAgIF8tLS0tLS1fXyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBfICAgICAgICAgX1xuICAgICBfICAgICAgIF8gICAgQWxsb2Nh dGUgcmVxdWVzdCBBQ0NFU1MtVE9LRU4gICAgICAgICAgXyAgICAgICAgIF9cbiAgICAgXyAgICAg ICBfLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tX18gICAgICAgICBf XG4gICAgIF8gICAgICAgXyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBfICAgICAgICAgX1xuICAgICBfICAgICAgIF8gICAgICAgICBBbGxvY2F0ZSBzdWNjZXNzIHJl c3BvbnNlICAgICAgICAgXyAgICAgICAgIF9cbiAgICAgXyAgICAgICBfXy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLV8gICAgICAgICBfXG4gICAgIF8gICAgICAgXyAg ICAgICAgICAgICBUVVJOIE1lc3NhZ2VzICAgICAgICAgICAgICAgICBfICAgICAgICAgX1xuICAg ICBfICAgICAgIF8gICAgICAvLy8vLy8gaW50ZWdyaXR5IHByb3RlY3RlZCAvLy8vLy8gICAgXyAg ICAgICAgIF9cbiAgICAgXyAgICAgICBfICAgICAgLy8vLy8vIGludGVncml0eSBwcm90ZWN0ZWQg Ly8vLy8vICAgIF8gICAgICAgICBfXG4gICAgIF8gICAgICAgXyAgICAgIC8vLy8vLyBpbnRlZ3Jp dHkgcHJvdGVjdGVkIC8vLy8vLyAgICBfICAgICAgICAgX1xuXG4gICAgICAgICAgICAgICAgIEZp Z3VyZSAxOiBUVVJOIFRoaXJkIFBhcnR5IEF1dGhvcml6YXRpb25cblxuICAgTm90ZSA6IEFuIGlt cGxlbWVudGF0aW9uIG1heSBjaG9vc2UgdG8gY29udGFjdCB0aGUgV2ViUlRDIHNlcnZlciB0b1xu ICAgb2J0YWluIGEgdG9rZW4gZXZlbiBiZWZvcmUgaXQgbWFrZXMgYW4gYWxsb2NhdGUgcmVxdWVz dCwgaWYgaXQga25vd3NcbiAgIHRoZSBzZXJ2ZXIgZGV0YWlscyBiZWZvcmUgaGFuZC4gIEZvciBl eGFtcGxlLCBvbmNlIGEgY2xpZW50IGhhc1xuICAgbGVhcm50IHRoYXQgYSBUVVJOIHNlcnZlciBz dXBwb3J0cyBUaGlyZCBQYXJ0eSBhdXRob3JpemF0aW9uIGZyb20gYVxuICAgV2ViUlRDIHNlcnZl ciwgdGhlIGNsaWVudCBjYW4gb2J0YWluIHRoZSB0b2tlbiBiZWZvcmUgbWFraW5nXG4gICBzdWJz ZXF1ZW50IGFsbG9jYXRlIHJlcXVlc3RzLlxuXG4gICBbSS1ELmlldGYtb2F1dGgtcG9wLWtleS1k aXN0cmlidXRpb25dIGRlc2NyaWJlcyB0aGUgaW50ZXJhY3Rpb25cbiAgIGJldHdlZW4gdGhlIGNs aWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiAgRm9yIGV4YW1wbGUsIHRoZVxuICAg Y2xpZW50IGxlYXJucyB0aGUgVFVSTiBzZXJ2ZXIgbmFtZSAidHVybjFAZXhhbXBsZS5jb20iIGZy b20gVEhJUkQtXG4gICBQQVJUWS1BVVRIT1JJWkFUSU9OIGF0dHJpYnV0ZSB2YWx1ZSBhbmQgbWFr ZXMgdGhlIGZvbGxvd2luZyBIVFRQXG4gICByZXF1ZXN0IGZvciB0aGUgYWNjZXNzIHRva2VuIHVz aW5nIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eSAod2l0aFxuICAgZXh0cmEgbGluZSBicmVha3Mg Zm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6XG5cblxuXG5cblxuUmVkZHksIGV0IGFsLiAgICAg ICAgICAgICBFeHBpcmVzIE1hcmNoIDksIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDRdXG5f XG5JbnRlcm5ldC1EcmFmdCAgICAgIFRVUk4gZm9yIDNyZCBwYXJ0eSBBdXRob3JpemF0aW9uICAg ICAgU2VwdGVtYmVyIDIwMTRcblxuXG4gICAgICAgIFBPU1QgL28vb2F1dGgyL3Rva2VuIEhUVFAv MS4xXG4gICAgICAgIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbVxuICAgICAgICBDb250ZW50LVR5 cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZFxuICAgICAgICBhdWQ9dHVybjFA ZXhhbXBsZS5jb21cbiAgICAgICAgdGltZXN0YW1wPTEzNjE0NzE2MjlcbiAgICAgICAgZ3JhbnRf dHlwZT1pbXBsaWNpdFxuICAgICAgICB0b2tlbl90eXBlPXBvcFxuICAgICAgICBhbGc9SE1BQy1T SEEtMSBITUFDLVNIQS0yNTYtMTI4XG5cbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmln dXJlIDI6IFJlcXVlc3RcblxuICAgV2hlbiBTVFVOIHN1cHBvcnRzIGhhc2ggYWdpbGl0eSB0aGVu IFRVUk4gc2VydmVyIGFsb25nIHdpdGggdGhlIGVycm9yXG4gICByZXNwb25zZSBjb252ZXlzIHRo ZSBITUFDIGFsZ29yaXRobXMgaXQgc3VwcG9ydHMgaW4gcmVzcG9uc2UgdG8gdGhlXG4gICBpbml0 aWFsIEFsbG9jYXRlIHJlcXVlc3QuICBUaGUgY2xpZW50IHRoZW4gc2lnbmFscyB0aGUgaW50ZXJz ZWN0aW9uLVxuICAgc2V0IG9mIGFsZ29yaXRobXMgc3VwcG9ydGVkIGJ5IGl0IGFuZCB0aGUgVFVS TiBzZXJ2ZXIgdG8gdGhlXG4gICBhdXRob3JpemF0aW9uIHNlcnZlciBpbiB0aGUgXCdhbGdcJyBw YXJhbWV0ZXIgZGVmaW5lZCBpblxuICAgW0ktRC5pZXRmLW9hdXRoLXBvcC1rZXktZGlzdHJpYnV0 aW9uXS4gIEF1dGhvcml6YXRpb24gc2VydmVyIHNlbGVjdHNcbiAgIGFuIEhNQUMgYWxnb3JpdGht IGZyb20gdGhlIGxpc3Qgb2YgYWxnb3JpdGhtcyBjbGllbnQgaGFkIHByb3ZpZGVkIGFuZFxuICAg ZGV0ZXJtaW5lcyBsZW5ndGggb2YgdGhlIG1hY19rZXkgYmFzZWQgb24gdGhlIHNlbGVjdGVkIEhN QUNcbiAgIGFsZ29yaXRobS4gIE5vdGUgdGhhdCB1bnRpbCBTVFVOIHN1cHBvcnRzIGhhc2ggYWdp bGl0eSBITUFDLVNIQTEgaXNcbiAgIHRoZSBvbmx5IHZhbGlkIGhhc2ggYWxnb3JpdGhtIHRoYXQg Y2xpZW50IGNhbiBzaWduYWwgdG8gdGhlXG4gICBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgdmlj ZS12ZXJzYS5cblxuICAgSWYgdGhlIGNsaWVudCBpcyBhdXRob3JpemVkIHRoZW4gdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGlzc3VlcyBhblxuICAgYWNjZXNzIHRva2VuLiAgQW4gZXhhbXBsZSBv ZiBzdWNjZXNzZnVsIHJlc3BvbnNlOlxuXG4gICAgICAgIEhUVFAvMS4xIDIwMCBPS1xuICAgICAg ICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb25cbiAgICAgICAgQ2FjaGUtQ29udHJvbDog bm8tc3RvcmVcblxuICAgICAgICB7XG4gICAgICAgICAgImFjY2Vzc190b2tlbiI6XG4gICAiVTJG c2RHVmtYMThxSksva2tXbVJjbmZIZ2xyVlRKU3BTNnlVMzJrbUhtT3JmR3lJM20xZ1FqMWpSUHNy MHVCYlxuICAgSGN0dXljQWdzZlJYN25KVzJCZHVrR3lLTVhTaU5HTm5Cemlna0FvZlA2K1ozdmtK MVE1cFdiZlNScm9Pa1dCbiIsXG4gICAgICAgICAgInRva2VuX3R5cGUiOiJwb3AiLFxuICAgICAg ICAgICJleHBpcmVzX2luIjoxODAwLFxuICAgICAgICAgICJraWQiOiIyMkJJanhVOTNoL0lnd0Vi IixcbiAgICAgICAgICAibWFjX2tleSI6InY1MU42Mk9NNjVreU12ZlRJMDhPIlxuICAgICAgICAg ICJhbGciOkhNQUMtU0hBLTI1Ni0xMjhcbiAgICAgICAgfVxuXG4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgRmlndXJlIDM6IFJlc3BvbnNlXG5cbiAgIEFjY2VzcyB0b2tlbiBhbmQgb3RoZXIg YXR0cmlidXRlcyBpc3N1ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyXG4gICBhcmUgZXhw bGFpbmVkIGluIFNlY3Rpb24gNi4yLlxuXG5cblxuXG5cblxuUmVkZHksIGV0IGFsLiAgICAgICAg ICAgICBFeHBpcmVzIE1hcmNoIDksIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDVdXG5fXG5J bnRlcm5ldC1EcmFmdCAgICAgIFRVUk4gZm9yIDNyZCBwYXJ0eSBBdXRob3JpemF0aW9uICAgICAg U2VwdGVtYmVyIDIwMTRcblxuXG40LiAgT2J0YWluaW5nIGEgVG9rZW4gVXNpbmcgT0F1dGhcblxu ICAgQSBUVVJOIGNsaWVudCBzaG91bGQga25vdyB0aGUgYXV0aGVudGljYXRpb24gY2FwYWJpbGl0 eSBvZiB0aGUgVFVSTlxuICAgc2VydmVyIGJlZm9yZSBkZWNpZGluZyB0byB1c2UgdGhpcmQgcGFy dHkgYXV0aG9yaXphdGlvbiB3aXRoIGl0LiAgQVxuICAgVFVSTiBjbGllbnQgaW5pdGlhbGx5IG1h a2VzIGEgcmVxdWVzdCB3aXRob3V0IGFueSBhdXRob3JpemF0aW9uLiAgSWZcbiAgIHRoZSBUVVJO IHNlcnZlciBzdXBwb3J0cyBvciBtYW5kYXRlcyB0aGlyZCBwYXJ0eSBhdXRob3JpemF0aW9uLCBp dFxuICAgd2lsbCByZXR1cm4gYW4gZXJyb3IgbWVzc2FnZSBpbmRpY2F0aW5nIHN1cHBvcnQgZm9y IHRoaXJkIHBhcnR5XG4gICBhdXRob3JpemF0aW9uLiAgVGhlIFRVUk4gc2VydmVyIGluY2x1ZGVz IGFuIEVSUk9SLUNPREUgYXR0cmlidXRlIHdpdGhcbiAgIGEgdmFsdWUgb2YgNDAxIChVbmF1dGhv cml6ZWQpLCBhIG5vbmNlIHZhbHVlIGluIGEgTk9OQ0UgYXR0cmlidXRlIGFuZFxuICAgYSBTT0ZU V0FSRSBhdHRyaWJ1dGUgdGhhdCBnaXZlcyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgVFVSTiBzZXJ2 ZXJcJ3NcbiAgIHNvZnR3YXJlLiAgVGhlIFRVUk4gc2VydmVycyBhbHNvIGluY2x1ZGVzIGFkZGl0 aW9uYWwgU1RVTiBhdHRyaWJ1dGVcbiAgIFRISVJELVBBUlRZLUFVVEhPUklaQVRJT04gc2lnbmFs aW5nIHRoZSBUVVJOIGNsaWVudCB0aGF0IHRoZSBUVVJOXG4gICBzZXJ2ZXIgc3VwcG9ydHMgdGhp cmQgcGFydHkgYXV0aG9yaXphdGlvbi5cblxuICAgVGhlIGZvbGxvd2luZyBtYXBwaW5nIG9mIE9B dXRoIGNvbmNlcHRzIHRvIFdlYlJUQyBpcyB1c2VkIDpcblxuICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tK1xuICAgICAg ICAgICAgICAgICBfICAgICAgICAgT0F1dGggICAgICAgIF8gICAgICAgICAgICBXZWJSVEMgICAg ICAgICAgX1xuICAgICAgICAgICAgICAgICArPT09PT09PT09PT09PT09PT09PT09PSs9PT09PT09 PT09PT09PT09PT09PT09PT09PT09K1xuICAgICAgICAgICAgICAgICBfIENsaWVudCAgICAgICAg ICAgICAgIF8gV2ViUlRDIGNsaWVudCAgICAgICAgICAgICAgX1xuICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tK1xuICAg ICAgICAgICAgICAgICBfIFJlc291cmNlIG93bmVyICAgICAgIF8gV2ViUlRDIHNlcnZlciAgICAg ICAgICAgICAgX1xuICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tK1xuICAgICAgICAgICAgICAgICBfIEF1dGhvcml6YXRp b24gc2VydmVyIF8gQXV0aG9yaXphdGlvbiBzZXJ2ZXIgICAgICAgX1xuICAgICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tK1xu ICAgICAgICAgICAgICAgICBfIFJlc291cmNlIHNlcnZlciAgICAgIF8gVFVSTiBTZXJ2ZXIgICAg ICAgICAgICAgICAgX1xuICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tK1xuXG4gICAgICAgICBGaWd1cmUgNDogT0F1dGgg dGVybWlub2xvZ3kgbWFwcGVkIHRvIFdlYlJUQyB0ZXJtaW5vbG9neVxuXG4gICBVc2luZyB0aGUg T0F1dGggMi4wIGF1dGhvcml6YXRpb24gZnJhbWV3b3JrLCBhIFdlYlJUQyBjbGllbnQgKHRoaXJk LVxuICAgcGFydHkgYXBwbGljYXRpb24pIG9idGFpbnMgbGltaXRlZCBhY2Nlc3MgdG8gYSBUVVJO IChyZXNvdXJjZSBzZXJ2ZXIpXG4gICBvbiBiZWhhbGYgb2YgdGhlIFdlYlJUQyBzZXJ2ZXIgKHJl c291cmNlIG93bmVyIG9yIGF1dGhvcml6YXRpb25cbiAgIHNlcnZlcikuICBUaGUgV2ViUlRDIGNs aWVudCByZXF1ZXN0cyBhY2Nlc3MgdG8gcmVzb3VyY2VzIGNvbnRyb2xsZWRcbiAgIGJ5IHRoZSBy ZXNvdXJjZSBvd25lciAoV2ViUlRDIHNlcnZlcikgYW5kIGhvc3RlZCBieSB0aGUgcmVzb3VyY2Vc biAgIHNlcnZlciAoVFVSTiBzZXJ2ZXIpLiAgVGhlIFdlYlJUQyBjbGllbnQgb2J0YWlucyBhY2Nl c3MgdG9rZW4sXG4gICBsaWZldGltZSwgc2Vzc2lvbiBrZXkgKGluIHRoZSBtYWNfa2V5IHBhcmFt ZXRlcikgYW5kIGtleSBpZCAoa2lkKS5cbiAgIFRoZSBUVVJOIGNsaWVudCBjb252ZXlzIHRoZSBh Y2Nlc3MgdG9rZW4gYW5kIG90aGVyIE9BdXRoIHBhcmFtZXRlcnNcbiAgIGxlYXJudCBmcm9tIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byB0aGUgcmVzb3VyY2Ugc2VydmVyIChUVVJOXG4gICBz ZXJ2ZXIpLiAgVGhlIFRVUk4gc2VydmVyIG9idGFpbnMgdGhlIHNlc3Npb24ga2V5IGZyb20gdGhl IGFjY2Vzc1xuICAgdG9rZW4uICBUaGUgVFVSTiBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSB0b2tlbiwg Y29tcHV0ZXMgdGhlIG1lc3NhZ2VcbiAgIGludGVncml0eSBvZiB0aGUgcmVxdWVzdCBhbmQgdGFr ZXMgYXBwcm9wcmlhdGUgYWN0aW9uIGkuZSBwZXJtaXRzIHRoZVxuICAgVFVSTiBjbGllbnQgdG8g Y3JlYXRlIGFsbG9jYXRpb25zLiAgVGhpcyBpcyBzaG93biBpbiBhbiBhYnN0cmFjdCB3YXlcbiAg IGluIEZpZ3VyZSA1LlxuXG5cblxuXG5cblxuXG5SZWRkeSwgZXQgYWwuICAgICAgICAgICAgIEV4 cGlyZXMgTWFyY2ggOSwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgNl1cbl9cbkludGVybmV0 LURyYWZ0ICAgICAgVFVSTiBmb3IgM3JkIHBhcnR5IEF1dGhvcml6YXRpb24gICAgICBTZXB0ZW1i ZXIgMjAxNFxuXG5cbiAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0r XG4gICAgICAgICAgICAgICAgICAgICAgICAgICBfICAgICAgICAgICAgICAgK18qKioqKiorXG4g ICAgICAgICAgICArLS0tLS0tLS0tLS0tLV9fIEF1dGhvcml6YXRpb24gXyAgICAgICAqXG4gICAg ICAgICAgICBfICAgICAgICAgICAgICBfIFNlcnZlciAgICAgICAgXyAgICAgICAqXG4gICAgICAg ICAgICBfICAgKy0tLS0tLS0tLS1fKFdlYlJUQyBTZXJ2ZXIpXyAgICAgICAqICBBUy1SUyxcbiAg ICAgICAgICAgIF8gICBfICAgICAgICAgIF8gICAgICAgICAgICAgICBfICAgICAgICogIEFVVEgg a2V5c1xuICAgKDIpICAgICAgXyAgIF8gICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAg KiAgICgxKVxuICAgQWNjZXNzICAgXyAgIF8gICgzKSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKlxuICAgVG9rZW4gICAgXyAgIF8gQWNjZXNzIFRva2VuICAgICAgICAgICAgICAgICAgICAg KlxuICAgUmVxdWVzdCAgXyAgIF8gICAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKlxu ICAgICAgICAgICAgXyAgIF8gU2Vzc2lvbiBLZXkgICAgICAgICAgICAgICAgICAgICAgKlxuICAg ICAgICAgICAgXyAgIF8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKlxuICAgICAg ICAgICAgXyAgIFYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVlxuICAgICAgICAr LS0tLS0tLSstLS0rICAgICAgICAgICAgICAgICAgICAgICArLSstLS0tPS0tLS0tK1xuICAgICAg ICBfICAgICAgICAgICBfICAgICAgICAgKDQpICAgICAgICAgICBfICAgICAgICAgICAgX1xuICAg ICAgICBfICAgICAgICAgICBfIFRVUk4gUmVxdWVzdCArIEFjY2VzcyBfICAgICAgICAgICAgX1xu ICAgICAgICBfIFdlYlJUQyAgICBfIFRva2VuICAgICAgICAgICAgICAgICBfIFRVUk4gICAgICAg X1xuICAgICAgICBfIENsaWVudCAgICBfLS0tLS0tLS0tLS0tLS0tLS0tLS0tLV9fIFNlcnZlciAg ICAgX1xuICAgICAgICBfIChBbGljZSkgICBfIEFsbG9jYXRlIFJlc3BvbnNlICg1KSBfICAgICAg ICAgICAgX1xuICAgICAgICBfICAgICAgICAgICBfXy0tLS0tLS0tLS0tLS0tLS0tLS0tLS1fICAg ICAgICAgICAgX1xuICAgICAgICArLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tK1xuXG4gICBVc2VyIDogQWxpY2VcbiAgICoqKio6IE91dC1vZi1CYW5kIExv bmctVGVybSBLZXkgRXN0YWJsaXNobWVudFxuXG4gICAgICAgICAgICAgICAgICAgICAgICAgIEZp Z3VyZSA1OiBJbnRlcmFjdGlvbnNcblxuICAgT0F1dGggaW4gW1JGQzY3NDldIGRlZmluZXMgZm91 ciBncmFudCB0eXBlcy4gIFRoaXMgc3BlY2lmaWNhdGlvbiB1c2VzXG4gICB0aGUgT0F1dGggZ3Jh bnQgdHlwZSAiSW1wbGljaXQiIGV4cGxhaW5lZCBpbiBzZWN0aW9uIDEuMy4yIG9mXG4gICBbUkZD Njc0OV0gd2hlcmUgdGhlIFdlYlJUQyBjbGllbnQgaXMgaXNzdWVkIGFuIGFjY2VzcyB0b2tlbiBk aXJlY3RseS5cbiAgIFRoZSB2YWx1ZSBvZiB0aGUgc2NvcGUgcGFyYW1ldGVyIGV4cGxhaW5lZCBp biBzZWN0aW9uIDMuMyBvZlxuICAgW1JGQzY3NDldIE1VU1QgYmUgXCd0dXJuXCcgc3RyaW5nLlxu XG40LjEuICBLZXkgRXN0YWJsaXNobWVudFxuXG4gICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg c2hhcmVzIGEgbG9uZy10ZXJtIHNlY3JldCAobGlrZSBhc3ltbWV0cmljXG4gICBjcmVkZW50aWFs cykgd2l0aCB0aGUgcmVzb3VyY2Ugc2VydmVyIGZvciBtdXR1YWwgYXV0aGVudGljYXRpb24uICBU aGVcbiAgIFRVUk4gYW5kIGF1dGhvcml6YXRpb24gc2VydmVycyBNVVNUIGVzdGFibGlzaCBhIHN5 bW1ldHJpYyBrZXkgKEspLFxuICAgdXNpbmcgYW4gb3V0IG9mIGJhbmQgbWVjaGFuaXNtLiAgU3lt bWV0cmljIGtleSBNVVNUIGJlIGNob3NlbiB0b1xuICAgZW5zdXJlIHRoYXQgdGhlIHNpemUgb2Yg ZW5jcnlwdGVkIHRva2VuIGlzIG5vdCBsYXJnZSBiZWNhdXNlIHVzYWdlIG9mXG4gICBhc3ltbWV0 cmljIGtleXMgd2lsbCByZXN1bHQgaW4gbGFyZ2UgZW5jcnlwdGVkIHRva2VucyB3aGljaCBtYXkg bm90XG4gICBmaXQgaW50byBhIHNpbmdsZSBTVFVOIG1lc3NhZ2UuICBUaGUgQVMtUlMsIEFVVEgg a2V5cyB3aWxsIGJlIGRlcml2ZWRcbiAgIGZyb20gSy4gIEFTLVJTIGtleSBpcyB1c2VkIGZvciBl bmNyeXB0aW5nIHRoZSBzZWxmLWNvbnRhaW5lZCB0b2tlblxuICAgYW5kIG1lc3NhZ2UgaW50ZWdy aXR5IG9mIHRoZSBlbmNyeXB0ZWQgdG9rZW4gaXMgY2FsY3VsYXRlZCB1c2luZyB0aGVcbiAgIEFV VEgga2V5LiAgVGhlIFRVUk4gYW5kIGF1dGhvcml6YXRpb24gc2VydmVycyBNVVNUIGVzdGFibGlz aCB0aGVcbiAgIHN5bW1ldHJpYyBrZXkgb3ZlciBhbiBhdXRoZW50aWNhdGVkIHNlY3VyZSBjaGFu bmVsLiAgVGhlXG4gICBlc3RhYmxpc2htZW50IG9mIHN5bW1ldHJpYyBrZXkgaXMgb3V0c2lkZSB0 aGUgc2NvcGUgb2YgdGhpc1xuXG5cblxuXG5SZWRkeSwgZXQgYWwuICAgICAgICAgICAgIEV4cGly ZXMgTWFyY2ggOSwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgN11cbl9cbkludGVybmV0LURy YWZ0ICAgICAgVFVSTiBmb3IgM3JkIHBhcnR5IEF1dGhvcml6YXRpb24gICAgICBTZXB0ZW1iZXIg MjAxNFxuXG5cbiAgIHNwZWNpZmljYXRpb24uICBGb3IgZXhhbXBsZSwgaW1wbGVtZW50YXRpb25z IGNvdWxkIHVzZSBvbmUgb2YgdGhlXG4gICBmb2xsb3dpbmcgbWVjaGFuaXNtcyBpbiB0byBlc3Rh Ymxpc2ggYSBzeW1tZXRyaWMga2V5LlxuXG40LjEuMS4gIERTS1BQXG5cbiAgIFRoZSB0d28gc2Vy dmVycyBjb3VsZCBjaG9vc2UgdG8gdXNlIER5bmFtaWMgU3ltbWV0cmljIEtleVxuICAgUHJvdmlz aW9uaW5nIFByb3RvY29sIChEU0tQUCkgW1JGQzYwNjNdIHRvIGVzdGFibGlzaCBhIHN5bW1ldHJp YyBrZXlcbiAgIChLKS4gIFRoZSBlbmNyeXB0aW9uIGFuZCBNQUMgYWxnb3JpdGhtcyB3aWxsIGJl IG5lZ290aWF0ZWQgdXNpbmcgdGhlXG4gICBLZXlQcm92Q2xpZW50SGVsbG8sIEtleVByb3ZTZXJ2 ZXJIZWxsbyBtZXNzYWdlcy4gIEEgdW5pcXVlIGtleVxuICAgaWRlbnRpZmllciAocmVmZXJyZWQg dG8gYXMgS2V5SUQpIGZvciB0aGUgc3ltbWV0cmljIGtleSBpcyBnZW5lcmF0ZWRcbiAgIGJ5IHRo ZSBEU0tQUCBzZXJ2ZXIgKGkuZS4gIEF1dGhvcml6YXRpb24gc2VydmVyKSBhbmQgc2lnbmFsbGVk IHRvIHRoZVxuICAgRFNLUFAgY2xpZW50IChpLmUgVFVSTiBzZXJ2ZXIpIHdoaWNoIGlzIGVxdWl2 YWxlbnQgdG8gdGhlIGtpZCBkZWZpbmVkXG4gICBpbiB0aGlzIHNwZWNpZmljYXRpb24uICBUaGUg QVMtUlMsIEFVVEgga2V5cyB3b3VsZCBiZSBkZXJpdmVkIGZyb21cbiAgIHRoZSBzeW1tZXRyaWMg a2V5IHVzaW5nIChITUFDKS1iYXNlZCBrZXkgZGVyaXZhdGlvbiBmdW5jdGlvbiAoSEtERilcbiAg IFtSRkM1ODY5XSBhbmQgdGhlIGRlZmF1bHQgaGFzaCBmdW5jdGlvbiBpcyBTSEEtMjU2LiAgRm9y IGV4YW1wbGUgaWZcbiAgIHRoZSBpbnB1dCBzeW1tZXRyaWMga2V5IChLKSBpcyAzMiBvY3RldHMg bGVuZ3RoLCBlbmNyeXB0aW9uIGFsZ29yaXRobVxuICAgaXMgQUVTXzI1Nl9DQkMgYW5kIEhNQUMg YWxnb3JpdGhtIGlzIEhNQUMtU0hBLTI1Ni0xMjggdGhlbiB0aGVcbiAgIHNlY29uZGFyeSBrZXlz IEFTLVJTLCBBVVRIIGFyZSBnZW5lcmF0ZWQgZnJvbSB0aGUgaW5wdXQga2V5IEsgYXNcbiAgIGZv bGxvd3NcblxuICAgMS4gIEhLREYtRXh0cmFjdCh6ZXJvLCBLKSAtXyBQUktcblxuICAgMi4gIEhL REYtRXhwYW5kKFBSSywgemVybywgMzIpIC1fIEFTLVJTIGtleVxuXG4gICAzLiAgSEtERi1FeHBh bmQoUFJLLCB6ZXJvLCAzMikgLV8gQVVUSCBrZXlcblxuICAgSWYgQXV0aGVudGljYXRlZCBFbmNy eXB0aW9uIHdpdGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKSBhbGdvcml0aG1cbiAgIGRlZmluZWQg aW4gW1JGQzUxMTZdIGlzIHVzZWQgdGhlbiB0aGVyZSBpcyBubyBuZWVkIHRvIGdlbmVyYXRlIHRo ZVxuICAgQVVUSCBrZXkuXG5cbjQuMS4yLiAgSFRUUCBpbnRlcmFjdGlvbnNcblxuICAgVGhlIHR3 byBzZXJ2ZXJzIGNvdWxkIGNob29zZSB0byB1c2UgUkVTVCBBUEkgdG8gZXN0YWJsaXNoIGEgc3lt bWV0cmljXG4gICBrZXkuICBUbyByZXRyaWV2ZSBhIG5ldyBzeW1tZXRyaWMga2V5LCB0aGUgVFVS TiBzZXJ2ZXIgbWFrZXMgYW4gSFRUUFxuICAgR0VUIHJlcXVlc3QgdG8gdGhlIGF1dGhvcml6YXRp b24gc2VydmVyLCBzcGVjaWZ5aW5nIFRVUk4gYXMgdGhlXG4gICBzZXJ2aWNlIHRvIGFsbG9jYXRl IHRoZSBzeW1tZXRyaWMga2V5cyBmb3IsIGFuZCBzcGVjaWZ5aW5nIHRoZSBuYW1lXG4gICBvZiB0 aGUgVFVSTiBzZXJ2ZXIuICBUaGUgcmVzcG9uc2UgaXMgcmV0dXJuZWQgd2l0aCBjb250ZW50LXR5 cGVcbiAgICJhcHBsaWNhdGlvbi9qc29uIiwgYW5kIGNvbnNpc3RzIG9mIGEgSlNPTiBvYmplY3Qg Y29udGFpbmluZyB0aGVcbiAgIHN5bW1ldHJpYyBrZXkuXG5cblxuXG5cblxuXG5cblxuXG5cblxu XG5SZWRkeSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggOSwgMjAxNSAgICAgICAg ICAgICAgICAgW1BhZ2UgOF1cbl9cbkludGVybmV0LURyYWZ0ICAgICAgVFVSTiBmb3IgM3JkIHBh cnR5IEF1dGhvcml6YXRpb24gICAgICBTZXB0ZW1iZXIgMjAxNFxuXG5cbiAgIFJlcXVlc3RcbiAg IC0tLS0tLS1cblxuICAgc2VydmljZSAtIHNwZWNpZmllcyB0aGUgZGVzaXJlZCBzZXJ2aWNlICh0 dXJuKVxuICAgbmFtZSAgICAtICBUVVJOIHNlcnZlciBuYW1lIGJlIGFzc29jaWF0ZWQgd2l0aCB0 aGUga2V5XG5cbiAgIGV4YW1wbGU6IEdFVCAvP3NlcnZpY2U9dHVybl9uYW1lPXR1cm4xQGV4YW1w bGUuY29tXG5cblxuICAgUmVzcG9uc2VcbiAgIC0tLS0tLS0tXG5cbiAgIGtleSAtIExvbmctdGVy bSBrZXkgKEspXG4gICB0dGwgLSB0aGUgZHVyYXRpb24gZm9yIHdoaWNoIHRoZSBrZXkgaXMgdmFs aWQsIGluIHNlY29uZHMuXG5cbiAgIGV4YW1wbGU6XG4gICB7XG4gICAgICAia2V5IiA6XG4gICAi RVNJelJGVm1kNGlaQUJFaU0wUlZaZ0tuNldqTGFUQzFGWEFnaFJNVlR6a0JHTmFhTjQ5NjUyM1dJ SVNLZXJMaSIsXG4gICAgICAidHRsIiA6IDg2NDAwLFxuICAgICAgImtpZCIgOiIyMkJJanhVOTNo L0lnd0ViIlxuICAgICB9XG5cbiAgIFRoZSBBUy1SUywgQVVUSCBrZXlzIGFyZSBkZXJpdmVkIGZy b20gSyB1c2luZyBIS0RGIGFzIGRpc2N1c3NlZCBpblxuICAgU2VjdGlvbiA0LjEuMS4gIEF1dGhv cml6YXRpb24gc2VydmVyIG11c3QgYWxzbyBzaWduYWwgYSB1bmlxdWUga2V5XG4gICBpZGVudGlm aWVyIChraWQpIHRvIHRoZSBUVVJOIHNlcnZlciB3aGljaCB3aWxsIGJlIHVzZWQgdG8gc2VsZWN0 IHRoZVxuICAgYXBwcm9wcmlhdGUga2V5aW5nIG1hdGVyaWFsIGZvciBkZWNyeXB0aW9uLiAgVGhl IGRlZmF1bHQgZW5jcnlwdGlvblxuICAgYWxnb3JpdGhtIHRvIGVuY3J5cHQgdGhlIHNlbGYtY29u dGFpbmVkIHRva2VuIGNvdWxkIGJlIEFkdmFuY2VkXG4gICBFbmNyeXB0aW9uIFN0YW5kYXJkIChB RVMpIGluIENpcGhlciBCbG9jayBDaGFpbmluZyAoQ0JDKSBtb2RlXG4gICAoQUVTXzI1Nl9DQkMp LiAgVGhlIGRlZmF1bHQgSE1BQyBhbGdvcml0aG0gdG8gY2FsY3VsYXRlIHRoZSBpbnRlZ3JpdHlc biAgIG9mIHRoZSB0b2tlbiBjb3VsZCBiZSBITUFDLVNIQS0yNTYtMTI4LiAgSW4gdGhpcyBjYXNl IEFTLVJTIGtleVxuICAgbGVuZ3RoIG11c3QgYmUgMjU2LWJpdCwgQVVUSCBrZXkgbGVuZ3RoIG11 c3QgYmUgMjU2LWJpdCAoc2VjdGlvbiAyLjZcbiAgIG9mIFtSRkM0ODY4XSkuXG5cbjQuMS4zLiAg TWFudWFsIHByb3Zpc2lvbmluZ1xuXG4gICBUVVJOIGFuZCBhdXRob3JpemF0aW9uIHNlcnZlcnMg Y291bGQgYmUgbWFudWFsbHkgY29uZmlndXJlZCB3aXRoIGFcbiAgIHN5bW1ldHJpYyBrZXkgKEsp IGFuZCBraWQuICBUaGUgZGVmYXVsdCBlbmNyeXB0aW9uIGFuZCBITUFDXG4gICBhbGdvcml0aG1z IGNvdWxkIGJlIEFFU18yNTZfQ0JDLCBITUFDLVNIQS0yNTYtMTI4LlxuXG4gICBOb3RlIDogVGhl IG1lY2hhbmlzbXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gNC4xLjIgU2VjdGlvbiA0LjEuMyBhcmVc biAgIGVhc3kgdG8gaW1wbGVtZW50IGFuZCBkZXBsb3kgY29tcGFyZWQgdG8gRFNLUFAgYnV0IGxh Y2sgZW5jcnlwdGlvblxuICAgYW5kIEhNQUMgYWxnb3JpdGhtIGFnaWxpdHkuXG5cblxuXG5cblxu XG5cblxuUmVkZHksIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDksIDIwMTUgICAg ICAgICAgICAgICAgIFtQYWdlIDldXG5fXG5JbnRlcm5ldC1EcmFmdCAgICAgIFRVUk4gZm9yIDNy ZCBwYXJ0eSBBdXRob3JpemF0aW9uICAgICAgU2VwdGVtYmVyIDIwMTRcblxuXG41LiAgRm9ybWlu ZyBhIFJlcXVlc3RcblxuICAgV2hlbiBhIFRVUk4gc2VydmVyIHJlc3BvbmRzIHRoYXQgdGhpcmQg cGFydHkgYXV0aG9yaXphdGlvbiBpc1xuICAgcmVxdWlyZWQsIGEgVFVSTiBjbGllbnQgcmUtYXR0 ZW1wdHMgdGhlIHJlcXVlc3QsIHRoaXMgdGltZSBpbmNsdWRpbmdcbiAgIGFjY2VzcyB0b2tlbiBh bmQga2lkIHZhbHVlcyBpbiBBQ0NFU1MtVE9LRU4gYW5kIFVTRVJOQU1FIFNUVU5cbiAgIGF0dHJp YnV0ZXMuICBUaGUgVFVSTiBjbGllbnQgaW5jbHVkZXMgYSBNRVNTQUdFLUlOVEVHUklUWSBhdHRy aWJ1dGVcbiAgIGFzIHRoZSBsYXN0IGF0dHJpYnV0ZSBpbiB0aGUgbWVzc2FnZSBvdmVyIHRoZSBj b250ZW50cyBvZiB0aGUgVFVSTlxuICAgbWVzc2FnZS4gIFRoZSBITUFDIGZvciB0aGUgTUVTU0FH RS1JTlRFR1JJVFkgYXR0cmlidXRlIGlzIGNvbXB1dGVkIGFzXG4gICBkZXNjcmliZWQgaW4gc2Vj dGlvbiAxNS40IG9mIFtSRkM1Mzg5XSB3aGVyZSB0aGUgbWFjX2tleSBpcyB1c2VkIGFzXG4gICB0 aGUgaW5wdXQga2V5IGZvciB0aGUgSE1BQyBjb21wdXRhdGlvbi4gIFRoZSBUVVJOIGNsaWVudCBh bmQgc2VydmVyXG4gICB3aWxsIHVzZSB0aGUgbWFjX2tleSB0byBjb21wdXRlIHRoZSBtZXNzYWdl IGludGVncml0eSBhbmQgZG9lc25cJ3RcbiAgIGhhdmUgdG8gcGVyZm9ybSBNRDUgaGFzaCBvbiB0 aGUgY3JlZGVudGlhbHMuXG5cbjYuICBTVFVOIEF0dHJpYnV0ZXNcblxuICAgVGhlIGZvbGxvd2lu ZyBuZXcgU1RVTiBhdHRyaWJ1dGVzIGFyZSBpbnRyb2R1Y2VkIGJ5IHRoaXNcbiAgIHNwZWNpZmlj YXRpb24gdG8gYWNjb21wbGlzaCB0aGlyZCBwYXJ0eSBhdXRob3JpemF0aW9uLlxuXG42LjEuICBU SElSRC1QQVJUWS1BVVRIT1JJWkFUSU9OXG5cbiAgIFRoaXMgYXR0cmlidXRlIGlzIHVzZWQgYnkg dGhlIFRVUk4gc2VydmVyIHRvIGluZm9ybSB0aGUgY2xpZW50IHRoYXRcbiAgIGl0IHN1cHBvcnRz IHRoaXJkIHBhcnR5IGF1dGhvcml6YXRpb24uICBUaGlzIGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlu c1xuICAgdGhlIFRVUk4gc2VydmVyIG5hbWUuICBUaGUgVFVSTiBzZXJ2ZXIgbWF5IGhhdmUgdGll LXVwIHdpdGggbXVsdGlwbGVcbiAgIGF1dGhvcml6YXRpb24gc2VydmVycyBhbmQgdmljZSB2ZXJz YSwgc28gdGhlIGNsaWVudCBNVVNUIHByb3ZpZGUgdGhlXG4gICBUVVJOIHNlcnZlciBuYW1lIHRv IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzbyB0aGF0IGl0IGNhbiBzZWxlY3RcbiAgIHRoZSBh cHByb3ByaWF0ZSBrZXlpbmcgbWF0ZXJpYWwgdG8gZ2VuZXJhdGUgdGhlIHNlbGYtY29udGFpbmVk IHRva2VuLlxuICAgVGhlIFRISVJELVBBUlRZLUFVVEhPUklaQVRJT04gYXR0cmlidXRlIGlzIGEg Y29tcHJlaGVuc2lvbi1vcHRpb25hbFxuICAgYXR0cmlidXRlIChzZWUgU2VjdGlvbiAxNSBmcm9t IFtSRkM1Mzg5XSkuXG5cbjYuMi4gIEFDQ0VTUy1UT0tFTlxuXG4gICBUaGUgYWNjZXNzIHRva2Vu IGlzIGlzc3VlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuICBPQXV0aCBkb2VzXG4gICBu b3QgaW1wb3NlIGFueSBsaW1pdGF0aW9uIG9uIHRoZSBsZW5ndGggb2YgdGhlIGFjY2VzcyB0b2tl biBidXQgaWZcbiAgIHBhdGggTVRVIGlzIHVua25vd24gdGhlbiBTVFVOIG1lc3NhZ2VzIG92ZXIg SVB2NCB3b3VsZCBuZWVkIHRvIGJlXG4gICBsZXNzIHRoYW4gNTQ4IGJ5dGVzIChTZWN0aW9uIDcu MSBvZiBbUkZDNTM4OV0pLCBhY2Nlc3MgdG9rZW4gbGVuZ3RoXG4gICBuZWVkcyB0byBiZSByZXN0 cmljdGVkIHRvIGZpdCB3aXRoaW4gdGhlIG1heGltdW0gU1RVTiBtZXNzYWdlIHNpemUuXG4gICBO b3RlIHRoYXQgdGhlIHNlbGYtY29udGFpbmVkIHRva2VuIGlzIG9wYXF1ZSB0byB0aGUgY2xpZW50 IGFuZCBpdFxuICAgTVVTVCBOT1QgZXhhbWluZSB0aGUgdGlja2V0LiAgVGhlIEFDQ0VTUy1UT0tF TiBhdHRyaWJ1dGUgaXMgYVxuICAgY29tcHJlaGVuc2lvbi1vcHRpb25hbCBhdHRyaWJ1dGUgKHNl ZSBTZWN0aW9uIDE1IGZyb20gW1JGQzUzODldKS5cblxuICAgVGhlIHRva2VuIGlzIHN0cnVjdHVy ZWQgYXMgZm9sbG93czpcblxuXG5cblxuXG5cblxuXG5cblxuUmVkZHksIGV0IGFsLiAgICAgICAg ICAgICBFeHBpcmVzIE1hcmNoIDksIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgMTBdXG5fXG5J bnRlcm5ldC1EcmFmdCAgICAgIFRVUk4gZm9yIDNyZCBwYXJ0eSBBdXRob3JpemF0aW9uICAgICAg U2VwdGVtYmVyIDIwMTRcblxuXG4gICAgICAgICBzdHJ1Y3Qge1xuICAgICAgICAgICAgIG9wYXF1 ZSB7XG4gICAgICAgICAgICAgICAgIHVpbnQxNl90IGtleV9sZW5ndGg7XG4gICAgICAgICAgICAg ICAgIG9wYXF1ZSBtYWNfa2V5W2tleV9sZW5ndGhdO1xuICAgICAgICAgICAgICAgICB1aW50NjRf dCB0aW1lc3RhbXA7XG4gICAgICAgICAgICAgICAgIHVpbnQzMl90IGxpZmV0aW1lO1xuICAgICAg ICAgICAgIH0gZW5jcnlwdGVkX2Jsb2NrO1xuICAgICAgICAgICAgIG9wYXF1ZSBtYWNbbWFjX2xl bmd0aF07XG4gICAgICAgICB9IHRva2VuO1xuXG4gICAgICAgICAgICAgICAgICAgRmlndXJlIDY6 IFNlbGYtY29udGFpbmVkIHRva2VuIGZvcm1hdFxuXG4gICBOb3RlOiB1aW50Tl90IG1lYW5zIGFu IHVuc2lnbmVkIGludGVnZXIgb2YgZXhhY3RseSBOIGJpdHMuICBTaW5nbGUtXG4gICBieXRlIGVu dGl0aWVzIGNvbnRhaW5pbmcgdW5pbnRlcnByZXRlZCBkYXRhIGFyZSBvZiB0eXBlIG9wYXF1ZS4g IEFsbFxuICAgdmFsdWVzIGluIHRoZSB0b2tlbiBhcmUgc3RvcmVkIGluIG5ldHdvcmsgYnl0ZSBv cmRlci5cblxuICAgVGhlIGZpZWxkcyBhcmUgZGVzY3JpYmVkIGJlbG93OlxuXG4gICBrZXlfbGVu Z3RoOiAgTGVuZ3RoIG9mIHRoZSBzZXNzaW9uIGtleS4gIEtleSBsZW5ndGggb2YgMTYwLWJpdHMg TVVTVFxuICAgICAgYmUgc3VwcG9ydGVkIChpLmUgb25seSAxNjAtYml0IGtleSBpcyB1c2VkIGJ5 IEhNQUMtU0hBLTEgZm9yXG4gICAgICBtZXNzYWdlIGludGVncml0eSBvZiBTVFVOIG1lc3NhZ2Up LiAgVGhlIGtleSBsZW5ndGggZmFjaWxpdGF0ZXNcbiAgICAgIHRoZSBoYXNoIGFnaWxpdHkgcGxh biBkaXNjdXNzZWQgaW4gc2VjdGlvbiAxNi4zIG9mIFtSRkM1Mzg5XS5cblxuICAgbWFjX2tleTog IFRoZSBzZXNzaW9uIGtleSBnZW5lcmF0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLlxu XG4gICB0aW1lc3RhbXA6ICA2NC1iaXQgdW5zaWduZWQgaW50ZWdlciBmaWVsZCBjb250YWluaW5n IGEgdGltZXN0YW1wLlxuICAgICAgVGhlIHZhbHVlIGluZGljYXRlcyB0aGUgdGltZSBzaW5jZSBK YW51YXJ5IDEsIDE5NzAsIDAwOjAwIFVUQywgYnlcbiAgICAgIHVzaW5nIGEgZml4ZWQgcG9pbnQg Zm9ybWF0LiAgSW4gdGhpcyBmb3JtYXQsIHRoZSBpbnRlZ2VyIG51bWJlciBvZlxuICAgICAgc2Vj b25kcyBpcyBjb250YWluZWQgaW4gdGhlIGZpcnN0IDQ4IGJpdHMgb2YgdGhlIGZpZWxkLCBhbmQg dGhlXG4gICAgICByZW1haW5pbmcgMTYgYml0cyBpbmRpY2F0ZSB0aGUgbnVtYmVyIG9mIDEvNjRL IGZyYWN0aW9ucyBvZiBhXG4gICAgICBzZWNvbmQgKE5hdGl2ZSBmb3JtYXQgLSBVbml4KS5cblxu ICAgbGlmZXRpbWU6ICBUaGUgbGlmZXRpbWUgb2YgdGhlIGFjY2VzcyB0b2tlbiwgaW4gc2Vjb25k cy4gIEZvclxuICAgICAgZXhhbXBsZSwgdGhlIHZhbHVlIDM2MDAgaW5kaWNhdGVzIG9uZSBob3Vy LiAgVGhlIExpZmV0aW1lIHZhbHVlXG4gICAgICBTSE9VTEQgYmUgZXF1YWwgdG8gdGhlICJleHBp cmVzX2luIiBwYXJhbWV0ZXIgZGVmaW5lZCBpbiBzZWN0aW9uXG4gICAgICA0LjIuMiBvZiBbUkZD Njc0OV0uXG5cbiAgIGVuY3J5cHRlZF9ibG9jazogIFRoZSBlbmNyeXB0ZWRfYmxvY2sgaXMgZW5j cnlwdGVkIHVzaW5nIHRoZVxuICAgICAgc3ltbWV0cmljIGxvbmctdGVybSBrZXkgZXN0YWJsaXNo ZWQgYmV0d2VlbiB0aGUgcmVzb3VyY2Ugc2VydmVyXG4gICAgICBhbmQgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyLiAgU2hvd24gaW4gRmlndXJlIDUgYXMgQVMtUlMga2V5LlxuXG4gICBtYWM6ICBU aGUgSGFzaGVkIE1lc3NhZ2UgQXV0aGVudGljYXRpb24gQ29kZSAoSE1BQykgaXMgY2FsY3VsYXRl ZFxuICAgICAgd2l0aCB0aGUgQVVUSCBrZXkgb3ZlciB0aGUgXCdlbmNyeXB0ZWRfYmxvY2tcJyBh bmQgdGhlIFRVUk4gc2VydmVyXG4gICAgICBuYW1lIChOKSBjb252ZXllZCBpbiB0aGUgVEhJUkQt UEFSVFktQVVUSE9SSVpBVElPTiByZXNwb25zZS4gIFRoaXNcbiAgICAgIGVuc3VyZXMgdGhhdCB0 aGUgY2xpZW50IGRvZXMgbm90IHVzZSB0aGUgc2FtZSB0b2tlbiB0byBnYWluXG4gICAgICBpbGxl Z2FsIGFjY2VzcyB0byBvdGhlciBUVVJOIHNlcnZlcnMgcHJvdmlkZWQgYnkgdGhlIHNhbWVcbiAg ICAgIGFkbWluaXN0cmF0aXZlIGRvbWFpbiBpLmUuLCB3aGVuIG11bHRpcGxlIFRVUk4gc2VydmVy cyBpbiBhIHNpbmdsZVxuICAgICAgYWRtaW5pc3RyYXRpdmUgZG9tYWluIHNoYXJlIHRoZSBzYW1l IHN5bW1ldHJpYyBrZXkgd2l0aCBhblxuXG5cblxuUmVkZHksIGV0IGFsLiAgICAgICAgICAgICBF eHBpcmVzIE1hcmNoIDksIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgMTFdXG5fXG5JbnRlcm5l dC1EcmFmdCAgICAgIFRVUk4gZm9yIDNyZCBwYXJ0eSBBdXRob3JpemF0aW9uICAgICAgU2VwdGVt YmVyIDIwMTRcblxuXG4gICAgICBhdXRob3JpemF0aW9uIHNlcnZlci4gIFRoZSBsZW5ndGggb2Yg dGhlIG1hYyBmaWVsZCBpcyBrbm93biB0byB0aGVcbiAgICAgIFRVUk4gYW5kIGF1dGhvcml6YXRp b24gc2VydmVyIGJhc2VkIG9uIHRoZSBuZWdvdGlhdGVkIE1BQ1xuICAgICAgYWxnb3JpdGhtLlxu XG4gICBBbiBleGFtcGxlIGVuY3J5cHRpb24gcHJvY2VzcyBpcyBpbGx1c3RyYXRlZCBiZWxvdy4g IEhlcmUgQywgTiBkZW5vdGVcbiAgIENpcGhlcnRleHQgYW5kIFRVUk4gc2VydmVyIG5hbWUgcmVz cGVjdGl2ZWx5LlxuXG4gICBvICBDID0gQUVTXzI1Nl9DQkMoQVMtUlMsIGVuY3J5cHRlZF9ibG9j aylcblxuICAgbyAgbWFjID0gSE1BQy1TSEEtMjU2LTEyOChBVVRILCBDIF8gXyBOKVxuXG4gICBF bmNyeXB0aW9uIGlzIGFwcGxpZWQgYmVmb3JlIG1lc3NhZ2UgYXV0aGVudGljYXRpb24gb24gdGhl IHNlbmRlclxuICAgc2lkZSBhbmQgY29udmVyc2VseSBvbiB0aGUgcmVjZWl2ZXIgc2lkZS4gIFRo ZSBlbnRpcmUgdG9rZW4gaS5lLiwgdGhlXG4gICBcJ2VuY3J5cHRlZF9ibG9ja1wnIGFuZCBcJ21h Y1wnIGlzIGJhc2U2NCBlbmNvZGVkIChzZWUgc2VjdGlvbiA0IG9mXG4gICBbUkZDNDY0OF0pIGFu ZCB0aGUgcmVzdWx0aW5nIGFjY2VzcyB0b2tlbiBpcyBzaWduYWxlZCB0byB0aGUgY2xpZW50Llxu ICAgU2luY2UgdGhlIGFjY2VzcyB0b2tlbiBpcyBvbmx5IHZhbGlkIGZvciBhIHNwZWNpZmljIHBl cmlvZCBvZiB0aW1lLFxuICAgdGhlIHJlc291cmNlIHNlcnZlciBNVVNUIGNhY2hlIGl0IHNvIHRo YXQgaXQgbmVlZCBub3QgdG8gYmUgcHJvdmlkZWRcbiAgIGluIGV2ZXJ5IHJlcXVlc3Qgd2l0aGlu IGFuIGV4aXN0aW5nIGFsbG9jYXRpb24uICBUaGUgYWNjZXNzIHRva2VuIGNhblxuICAgYmUgcmV1 c2VkIGZvciBtdWx0aXBsZSBBbGxvY2F0ZSByZXF1ZXN0cyB0byB0aGUgc2FtZSBUVVJOIHNlcnZl ci5cbiAgIFRoZSBUVVJOIGNsaWVudCBNVVNUIGluY2x1ZGUgdGhlIEFDQ0VTUy1UT0tFTiBhdHRy aWJ1dGUgb25seSBpblxuICAgQWxsb2NhdGUgYW5kIFJlZnJlc2ggcmVxdWVzdHMuICBJZiBBRUFE IGFsZ29yaXRobSBpcyB1c2VkIHRoZW4gdGhlcmVcbiAgIGlzIG5vIG5lZWQgdG8gZXhwbGljaXRs eSBjb21wdXRlIEhNQUMsIHRoZSBhc3NvY2lhdGVkIGRhdGEgTVVTVCBiZVxuICAgdGhlIFRVUk4g c2VydmVyIG5hbWUgKE4pIGFuZCB0aGUgbWFjIGZpZWxkIE1VU1QgY2FycnkgdGhlIG5vbmNlLiAg VGhlXG4gICBsZW5ndGggb2Ygbm9uY2UgTVVTVCBiZSAxMiBvY3RldHMuXG5cbjcuICBSZWNlaXZp bmcgYSByZXF1ZXN0IHdpdGggQUNDRVNTLVRPS0VOIGF0dHJpYnV0ZVxuXG4gICBUaGUgVFVSTiBz ZXJ2ZXIsIG9uIHJlY2VpdmluZyBhIHJlcXVlc3Qgd2l0aCBBQ0NFU1MtVE9LRU4gYXR0cmlidXRl LFxuICAgcGVyZm9ybXMgY2hlY2tzIGxpc3RlZCBpbiBzZWN0aW9uIDEwLjIuMiBvZiBbUkZDNTM4 OV0gaW4gYWRkaXRpb24gdG9cbiAgIHRoZSBmb2xsb3dpbmcgc3RlcHMgdG8gdmVyaWZ5IHRoYXQg dGhlIGFjY2VzcyB0b2tlbiBpcyB2YWxpZDpcblxuICAgbyAgVFVSTiBzZXJ2ZXIgc2VsZWN0cyB0 aGUga2V5aW5nIG1hdGVyaWFsIGJhc2VkIG9uIGtpZCBzaWduYWxsZWQgaW5cbiAgICAgIHRoZSBV U0VSTkFNRSBhdHRyaWJ1dGUuXG5cbiAgIG8gIEl0IHBlcmZvcm1zIHRoZSB2ZXJpZmljYXRpb24g b2YgdGhlIHRva2VuIG1lc3NhZ2UgaW50ZWdyaXR5IGJ5XG4gICAgICBjYWxjdWxhdGluZyBITUFD IG92ZXIgdGhlIGVuY3J5cHRlZCBwb3J0aW9uIGluIHRoZSBzZWxmLWNvbnRhaW5lZFxuICAgICAg dG9rZW4gYW5kIFRVUk4gc2VydmVyIG5hbWUgdXNpbmcgQVVUSCBrZXkgYW5kIGlmIHRoZSByZXN1 bHRpbmdcbiAgICAgIHZhbHVlIGRvZXMgbm90IG1hdGNoIHRoZSBtYWMgZmllbGQgaW4gdGhlIHNl bGYtY29udGFpbmVkIHRva2VuXG4gICAgICB0aGVuIGl0IHJlamVjdHMgdGhlIHJlcXVlc3Qgd2l0 aCBhbiBlcnJvciByZXNwb25zZSA0MDFcbiAgICAgIChVbmF1dGhvcml6ZWQpLiAgSWYgQUVBRCBh bGdvcml0aG0gaXMgdXNlZCB0aGVuIGl0IGhhcyBvbmx5IGFcbiAgICAgIHNpbmdsZSBvdXRwdXQs IGVpdGhlciBhIHBsYWludGV4dCBvciBhIHNwZWNpYWwgc3ltYm9sIEZBSUwgdGhhdFxuICAgICAg aW5kaWNhdGVzIHRoYXQgdGhlIGlucHV0cyBhcmUgbm90IGF1dGhlbnRpYy5cblxuICAgbyAgVFVS TiBzZXJ2ZXIgb2J0YWlucyB0aGUgbWFjX2tleSBieSByZXRyaWV2aW5nIHRoZSBjb250ZW50IG9m IHRoZVxuICAgICAgYWNjZXNzIHRva2VuICh3aGljaCByZXF1aXJlcyBkZWNyeXB0aW9uIG9mIHRo ZSBzZWxmLWNvbnRhaW5lZFxuICAgICAgdG9rZW4gdXNpbmcgdGhlIEFTLVJTIGtleSkuXG5cblxu XG5cblxuUmVkZHksIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDksIDIwMTUgICAg ICAgICAgICAgICAgW1BhZ2UgMTJdXG5fXG5JbnRlcm5ldC1EcmFmdCAgICAgIFRVUk4gZm9yIDNy ZCBwYXJ0eSBBdXRob3JpemF0aW9uICAgICAgU2VwdGVtYmVyIDIwMTRcblxuXG4gICBvICBUaGUg VFVSTiBzZXJ2ZXIgdmVyaWZpZXMgdGhhdCBubyByZXBsYXkgdG9vayBwbGFjZSBieSBwZXJmb3Jt aW5nXG4gICAgICB0aGUgZm9sbG93aW5nIGNoZWNrOlxuXG4gICAgICAqICBUaGUgYWNjZXNzIHRv a2VuIGlzIGFjY2VwdGVkIGlmIHRoZSB0aW1lc3RhbXAgZmllbGQgKFRTKSBpbiB0aGVcbiAgICAg ICAgIHNlbGYtY29udGFpbmVkIHRva2VuIGlzIHJlY2VudCBlbm91Z2ggdG8gdGhlIHJlY2VwdGlv biB0aW1lIG9mXG4gICAgICAgICB0aGUgVFVSTiByZXF1ZXN0IChSRG5ldykgdXNpbmcgdGhlIGZv bGxvd2luZyBmb3JtdWxhOiBMaWZldGltZVxuICAgICAgICAgKyBEZWx0YSBfIGFicyhSRG5ldyAt IFRTKS4gIFRoZSBSRUNPTU1FTkRFRCB2YWx1ZSBmb3IgdGhlXG4gICAgICAgICBhbGxvd2VkIERl bHRhIGlzIDUgc2Vjb25kcy4gIElmIHRoZSB0aW1lc3RhbXAgaXMgTk9UIHdpdGhpbiB0aGVcbiAg ICAgICAgIGJvdW5kYXJpZXMgdGhlbiB0aGUgVFVSTiBzZXJ2ZXIgZGlzY2FyZHMgdGhlIHJlcXVl c3Qgd2l0aCBlcnJvclxuICAgICAgICAgcmVzcG9uc2UgNDAxIChVbmF1dGhvcml6ZWQpLlxuXG4g ICBvICBUaGUgVFVSTiBzZXJ2ZXIgdXNlcyB0aGUgbWFjX2tleSB0byBjb21wdXRlIHRoZSBtZXNz YWdlIGludGVncml0eVxuICAgICAgb3ZlciB0aGUgcmVxdWVzdCBhbmQgaWYgdGhlIHJlc3VsdGlu ZyB2YWx1ZSBkb2VzIG5vdCBtYXRjaCB0aGVcbiAgICAgIGNvbnRlbnRzIG9mIHRoZSBNRVNTQUdF LUlOVEVHUklUWSBhdHRyaWJ1dGUgdGhlbiBpdCByZWplY3RzIHRoZVxuICAgICAgcmVxdWVzdCB3 aXRoIGFuIGVycm9yIHJlc3BvbnNlIDQwMSAoVW5hdXRob3JpemVkKS5cblxuICAgbyAgSWYgYWxs IHRoZSBjaGVja3MgcGFzcywgdGhlIFRVUk4gc2VydmVyIGNvbnRpbnVlcyB0byBwcm9jZXNzIHRo ZVxuICAgICAgcmVxdWVzdC4gIEFueSByZXNwb25zZSBnZW5lcmF0ZWQgYnkgdGhlIHNlcnZlciBN VVNUIGluY2x1ZGUgdGhlXG4gICAgICBNRVNTQUdFLUlOVEVHUklUWSBhdHRyaWJ1dGUsIGNvbXB1 dGVkIHVzaW5nIHRoZSBtYWNfa2V5LlxuXG4gICBUaGUgbGlmZXRpbWUgcHJvdmlkZWQgYnkgdGhl IFRVUk4gc2VydmVyIGluIHRoZSBBbGxvY2F0ZSBhbmQgUmVmcmVzaFxuICAgcmVzcG9uc2VzIE1V U1QgYmUgbGVzcyB0aGFuIG9yIGVxdWFsIHRvIHRoZSBsaWZldGltZSBvZiB0aGUgdG9rZW4uXG5c bjguICBDaGFuZ2VzIHRvIFRVUk4gQ2xpZW50XG5cbiAgIG8gIEEgVFVSTiByZXNwb25zZSBpcyBk aXNjYXJkZWQgYnkgdGhlIGNsaWVudCBpZiB0aGUgdmFsdWUgY29tcHV0ZWRcbiAgICAgIGZvciBt ZXNzYWdlIGludGVncml0eSB1c2luZyBtYWNfa2V5IGRvZXMgbm90IG1hdGNoIHRoZSBjb250ZW50 cyBvZlxuICAgICAgdGhlIE1FU1NBR0UtSU5URUdSSVRZIGF0dHJpYnV0ZS5cblxuICAgbyAgSWYg dGhlIGFjY2VzcyB0b2tlbiBleHBpcmVzIHRoZW4gdGhlIGNsaWVudCBNVVNUIG9idGFpbiBhIG5l d1xuICAgICAgdG9rZW4gZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHVzZSBpdCBm b3IgbmV3XG4gICAgICBhbGxvY2F0aW9ucy4gIFRoZSBjbGllbnQgTVVTVCBhbHNvIHVzZSB0aGUg bmV3IHRva2VuIHRvIHJlZnJlc2hcbiAgICAgIGV4aXN0aW5nIGFsbG9jYXRpb25zLiAgVGhpcyB3 YXkgY2xpZW50IGhhcyB0byBtYWludGFpbiBvbmx5IG9uZVxuICAgICAgdG9rZW4gcGVyIFRVUk4g c2VydmVyLlxuXG45LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnNcblxuICAgV2hlbiBPQXV0aCBp cyB1c2VkIHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZVxuICAgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgcmVxdWlyZXMgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMp IHdpdGggYVxuICAgY2lwaGVyc3VpdGUgb2ZmZXJpbmcgY29uZmlkZW50aWFsaXR5IHByb3RlY3Rp b24uICBUaGUgc2Vzc2lvbiBrZXlcbiAgIE1VU1QgTk9UIGJlIHRyYW5zbWl0dGVkIGluIGNsZWFy IHNpbmNlIHRoaXMgd291bGQgY29tcGxldGVseSBkZXN0cm95XG4gICB0aGUgc2VjdXJpdHkgYmVu ZWZpdHMgb2YgdGhlIHByb3Bvc2VkIHNjaGVtZS4gIElmIGFuIGF0dGFja2VyIHRyaWVzXG4gICB0 byByZXBsYXkgbWVzc2FnZSB3aXRoIEFDQ0VTUy1UT0tFTiBhdHRyaWJ1dGUgdGhlbiB0aGUgc2Vy dmVyIGNhblxuICAgZGV0ZWN0IHRoYXQgdGhlIHRyYW5zYWN0aW9uIElEIGFzIHVzZWQgZm9yIGFu IG9sZCByZXF1ZXN0IGFuZCB0aHVzXG4gICBwcmV2ZW50IHRoZSByZXBsYXkgYXR0YWNrLlxuXG5c blxuXG5cblxuUmVkZHksIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDksIDIwMTUg ICAgICAgICAgICAgICAgW1BhZ2UgMTNdXG5fXG5JbnRlcm5ldC1EcmFmdCAgICAgIFRVUk4gZm9y IDNyZCBwYXJ0eSBBdXRob3JpemF0aW9uICAgICAgU2VwdGVtYmVyIDIwMTRcblxuXG4gICBUaHJl YXQgbWl0aWdhdGlvbiBkaXNjdXNzZWQgaW4gc2VjdGlvbiA1IG9mXG4gICBbSS1ELmlldGYtb2F1 dGgtcG9wLWFyY2hpdGVjdHVyZV0gYW5kIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluXG4gICBb UkZDNTc2Nl0gYXJlIHRvIGJlIHRha2VuIGludG8gYWNjb3VudC5cblxuMTAuICBJQU5BIENvbnNp ZGVyYXRpb25zXG5cbiAgIElBTkEgaXMgcmVxdWVzdGVkIHRvIGFkZCB0aGUgZm9sbG93aW5nIGF0 dHJpYnV0ZXMgdG8gdGhlIFNUVU5cbiAgIGF0dHJpYnV0ZSByZWdpc3RyeSBbaWFuYS1zdHVuXSxc blxuICAgbyAgVEhJUkQtUEFSVFktQVVUSE9SSVpBVElPTlxuXG4gICBvICBBQ0NFU1MtVE9LRU5c blxuMTEuICBBY2tub3dsZWRnZW1lbnRzXG5cbiAgIEF1dGhvcnMgd291bGQgbGlrZSB0byB0aGFu ayBEYW4gV2luZywgUGFsIE1hcnRpbnNlbiwgT2xlZyBNb3NrYWxlbmtvLFxuICAgQ2hhcmxlcyBF Y2tlbCBhbmQgSGFubmVzIFRzY2hvZmVuaWcgZm9yIGNvbW1lbnRzIGFuZCByZXZpZXcuICBUaGVc biAgIGF1dGhvcnMgd291bGQgbGlrZSB0byBnaXZlIHNwZWNpYWwgdGhhbmtzIHRvIEJyYW5kb24g V2lsbGlhbXMgZm9yIGhpc1xuICAgaGVscC5cblxuMTIuICBSZWZlcmVuY2VzXG5cbjEyLjEuICBO b3JtYXRpdmUgUmVmZXJlbmNlc1xuXG4gICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdv cmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZVxuICAgICAgICAgICAgICBSZXF1aXJlbWVu dCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LlxuXG4gICBbUkZDNDY0OF0g IEpvc2Vmc3NvbiwgUy4sICJUaGUgQmFzZTE2LCBCYXNlMzIsIGFuZCBCYXNlNjQgRGF0YVxuICAg ICAgICAgICAgICBFbmNvZGluZ3MiLCBSRkMgNDY0OCwgT2N0b2JlciAyMDA2LlxuXG4gICBbUkZD NDg2OF0gIEtlbGx5LCBTLiBhbmQgUy4gRnJhbmtlbCwgIlVzaW5nIEhNQUMtU0hBLTI1NiwgSE1B Qy1TSEEtXG4gICAgICAgICAgICAgIDM4NCwgYW5kIEhNQUMtU0hBLTUxMiB3aXRoIElQc2VjIiwg UkZDIDQ4NjgsIE1heSAyMDA3LlxuXG4gICBbUkZDNTExNl0gIE1jR3JldywgRC4sICJBbiBJbnRl cmZhY2UgYW5kIEFsZ29yaXRobXMgZm9yIEF1dGhlbnRpY2F0ZWRcbiAgICAgICAgICAgICAgRW5j cnlwdGlvbiIsIFJGQyA1MTE2LCBKYW51YXJ5IDIwMDguXG5cbiAgIFtSRkM1Mzg5XSAgUm9zZW5i ZXJnLCBKLiwgTWFoeSwgUi4sIE1hdHRoZXdzLCBQLiwgYW5kIEQuIFdpbmcsXG4gICAgICAgICAg ICAgICJTZXNzaW9uIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikiLCBSRkMgNTM4 OSxcbiAgICAgICAgICAgICAgT2N0b2JlciAyMDA4LlxuXG4gICBbUkZDNjc0OV0gIEhhcmR0LCBE LiwgIlRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsiLCBSRkNcbiAgICAgICAg ICAgICAgNjc0OSwgT2N0b2JlciAyMDEyLlxuXG4gICBbaWFuYS1zdHVuXVxuICAgICAgICAgICAg ICBJQU5BLCAsICJJQU5BOiBTVFVOIEF0dHJpYnV0ZXMiLCBBcHJpbCAyMDExLFxuICAgICAgICAg ICAgICBfaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9zdHVuLXBhcmFtZXRlcnMvc3R1 bi1wYVxuICAgICAgICAgICAgICByYW1ldGVycy54bWxfLlxuXG5cblxuXG5SZWRkeSwgZXQgYWwu ICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggOSwgMjAxNSAgICAgICAgICAgICAgICBbUGFnZSAx NF1cbl9cbkludGVybmV0LURyYWZ0ICAgICAgVFVSTiBmb3IgM3JkIHBhcnR5IEF1dGhvcml6YXRp b24gICAgICBTZXB0ZW1iZXIgMjAxNFxuXG5cbjEyLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2Vz XG5cbiAgIFtJLUQuaWV0Zi1vYXV0aC1wb3AtYXJjaGl0ZWN0dXJlXVxuICAgICAgICAgICAgICBI dW50LCBQLiwgUmljaGVyLCBKLiwgTWlsbHMsIFcuLCBNaXNocmEsIFAuLCBhbmQgSC5cbiAgICAg ICAgICAgICAgVHNjaG9mZW5pZywgIk9BdXRoIDIuMCBQcm9vZi1vZi1Qb3NzZXNzaW9uIChQb1Ap IFNlY3VyaXR5XG4gICAgICAgICAgICAgIEFyY2hpdGVjdHVyZSIsIGRyYWZ0LWlldGYtb2F1dGgt cG9wLWFyY2hpdGVjdHVyZS0wMCAod29ya1xuICAgICAgICAgICAgICBpbiBwcm9ncmVzcyksIEp1 bHkgMjAxNC5cblxuICAgW0ktRC5pZXRmLW9hdXRoLXBvcC1rZXktZGlzdHJpYnV0aW9uXVxuICAg ICAgICAgICAgICBCcmFkbGV5LCBKLiwgSHVudCwgUC4sIEpvbmVzLCBNLiwgYW5kIEguIFRzY2hv ZmVuaWcsXG4gICAgICAgICAgICAgICJPQXV0aCAyLjAgUHJvb2Ytb2YtUG9zc2Vzc2lvbjogQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgdG9cbiAgICAgICAgICAgICAgQ2xpZW50IEtleSBEaXN0cmlidXRp b24iLCBkcmFmdC1pZXRmLW9hdXRoLXBvcC1rZXktXG4gICAgICAgICAgICAgIGRpc3RyaWJ1dGlv bi0wMCAod29yayBpbiBwcm9ncmVzcyksIEp1bHkgMjAxNC5cblxuICAgW0ktRC5pZXRmLXJ0Y3dl Yi1vdmVydmlld11cbiAgICAgICAgICAgICAgQWx2ZXN0cmFuZCwgSC4sICJPdmVydmlldzogUmVh bCBUaW1lIFByb3RvY29scyBmb3JcbiAgICAgICAgICAgICAgQnJvd3Nlci1iYXNlZCBBcHBsaWNh dGlvbnMiLCBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldy0xMVxuICAgICAgICAgICAgICAod29y ayBpbiBwcm9ncmVzcyksIEF1Z3VzdCAyMDE0LlxuXG4gICBbSS1ELmlldGYtdHJhbS1hdXRoLXBy b2JsZW1zXVxuICAgICAgICAgICAgICBSZWRkeSwgVC4sIFIsIFIuLCBQZXJ1bWFsLCBNLiwgYW5k IEEuIFllZ2luLCAiUHJvYmxlbXNcbiAgICAgICAgICAgICAgd2l0aCBTVFVOIGxvbmctdGVybSBB dXRoZW50aWNhdGlvbiBmb3IgVFVSTiIsIGRyYWZ0LWlldGYtXG4gICAgICAgICAgICAgIHRyYW0t YXV0aC1wcm9ibGVtcy0wNSAod29yayBpbiBwcm9ncmVzcyksIEF1Z3VzdCAyMDE0LlxuXG4gICBb UkZDNTc2Nl0gIE1haHksIFIuLCBNYXR0aGV3cywgUC4sIGFuZCBKLiBSb3NlbmJlcmcsICJUcmF2 ZXJzYWwgVXNpbmdcbiAgICAgICAgICAgICAgUmVsYXlzIGFyb3VuZCBOQVQgKFRVUk4pOiBSZWxh eSBFeHRlbnNpb25zIHRvIFNlc3Npb25cbiAgICAgICAgICAgICAgVHJhdmVyc2FsIFV0aWxpdGll cyBmb3IgTkFUIChTVFVOKSIsIFJGQyA1NzY2LCBBcHJpbCAyMDEwLlxuXG4gICBbUkZDNTg2OV0g IEtyYXdjenlrLCBILiBhbmQgUC4gRXJvbmVuLCAiSE1BQy1iYXNlZCBFeHRyYWN0LWFuZC1FeHBh bmRcbiAgICAgICAgICAgICAgS2V5IERlcml2YXRpb24gRnVuY3Rpb24gKEhLREYpIiwgUkZDIDU4 NjksIE1heSAyMDEwLlxuXG4gICBbUkZDNjA2M10gIERvaGVydHksIEEuLCBQZWksIE0uLCBNYWNo YW5pLCBTLiwgYW5kIE0uIE55c3Ryb20sXG4gICAgICAgICAgICAgICJEeW5hbWljIFN5bW1ldHJp YyBLZXkgUHJvdmlzaW9uaW5nIFByb3RvY29sIChEU0tQUCkiLCBSRkNcbiAgICAgICAgICAgICAg NjA2MywgRGVjZW1iZXIgMjAxMC5cblxuICAgW1JGQzY4MTldICBMb2RkZXJzdGVkdCwgVC4sIE1j R2xvaW4sIE0uLCBhbmQgUC4gSHVudCwgIk9BdXRoIDIuMFxuICAgICAgICAgICAgICBUaHJlYXQg TW9kZWwgYW5kIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIiwgUkZDIDY4MTksXG4gICAgICAgICAg ICAgIEphbnVhcnkgMjAxMy5cblxuQXV0aG9yc1wnIEFkZHJlc3Nlc1xuXG5cblxuXG5cblxuXG5c blxuXG5cblJlZGR5LCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCA5LCAyMDE1ICAg ICAgICAgICAgICAgIFtQYWdlIDE1XVxuX1xuSW50ZXJuZXQtRHJhZnQgICAgICBUVVJOIGZvciAz cmQgcGFydHkgQXV0aG9yaXphdGlvbiAgICAgIFNlcHRlbWJlciAyMDE0XG5cblxuICAgVGlydW1h bGVzd2FyIFJlZGR5XG4gICBDaXNjbyBTeXN0ZW1zLCBJbmMuXG4gICBDZXNzbmEgQnVzaW5lc3Mg UGFyaywgVmFydGh1ciBIb2JsaVxuICAgU2FyamFwdXIgTWFyYXRoYWxsaSBPdXRlciBSaW5nIFJv YWRcbiAgIEJhbmdhbG9yZSwgS2FybmF0YWthICA1NjAxMDNcbiAgIEluZGlhXG5cbiAgIEVtYWls OiB0aXJlZGR5QGNpc2NvLmNvbVxuXG5cbiAgIFByYXNoYW50aCBQYXRpbFxuICAgQ2lzY28gU3lz dGVtcywgSW5jLlxuICAgQmFuZ2Fsb3JlXG4gICBJbmRpYVxuXG4gICBFbWFpbDogcHJhc3BhdGlA Y2lzY28uY29tXG5cblxuICAgUmFtIE1vaGFuIFJhdmluZHJhbmF0aFxuICAgQ2lzY28gU3lzdGVt cywgSW5jLlxuICAgQ2Vzc25hIEJ1c2luZXNzIFBhcmssXG4gICBLYWRhYmVlc2FuYWhhbGxpIFZp bGxhZ2UsIFZhcnRodXIgSG9ibGksXG4gICBTYXJqYXB1ci1NYXJhdGhhaGFsbGkgT3V0ZXIgUmlu ZyBSb2FkXG4gICBCYW5nYWxvcmUsIEthcm5hdGFrYSAgNTYwMTAzXG4gICBJbmRpYVxuXG4gICBF bWFpbDogcm1vaGFuckBjaXNjby5jb21cblxuXG4gICBKdXN0aW4gVWJlcnRpXG4gICBHb29nbGVc biAgIDc0NyA2dGggQXZlIFNcbiAgIEtpcmtsYW5kLCBXQVxuICAgOTgwMzNcbiAgIFVTQVxuXG4g ICBFbWFpbDoganVzdGluQHViZXJ0aS5uYW1lXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxu UmVkZHksIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDksIDIwMTUgICAgICAgICAg ICAgICAgW1BhZ2UgMTZdXG4nLCAnZmlsZW5hbWUxJzogJycsICd1cmwxJzogJ2h0dHA6Ly90b29s cy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMi50 eHQnLCAnc3VibWl0JzogJ0dlbmVyYXRlIGRpZmYnLCAndXJsMic6ICcnLCAnLS1uZXdjb2xvdXIn OiAnZ3JlZW4nfSAtLT4= --_002_913383AAA69FF945B8F946018B75898A283248B6xmbrcdx10ciscoc_-- From nobody Fri Sep 5 10:17:58 2014 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 023CF1A0479 for ; Fri, 5 Sep 2014 10:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=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 cyIoMq4YLys3 for ; Fri, 5 Sep 2014 10:17:55 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3751A0AE2 for ; Fri, 5 Sep 2014 10:17:54 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so125808wib.0 for ; Fri, 05 Sep 2014 10:17:53 -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=YYkPg79Fx4rz6vArG+H3DirvZxqkc+sjbSV+tnzdEok=; b=uI3d95TXB3BVQvJr5weXFvlPvzuA6DXzR6Z000mIwupLjLN+QutbhyhvVHajEqd8Ni kNSxnh8PTe+6kZhn4dVM9Kf9IKiJ5s2d4bcNcXXKaEvUBb4MbljbFdCVeTFtSkiumu9k kjIfgwlUxp4qpZpbwDTZLTnz+JeJ9y9W3bAdS2/ngPC315nepnCxDtl/Olitx7AlAqhA MqucAmN3PB29M8oc49H1juXc8SR/h/0uy2Y85Z42fZq1VYfmmMhtZcGJIU/Pwia+b3aG KvRdckTElkLmHB+N8eJenRvPgfcscECdvl5zDTvd33le2SPbBK9W9wHT59ZU0wjBudsg ZN6g== MIME-Version: 1.0 X-Received: by 10.180.182.67 with SMTP id ec3mr5346667wic.21.1409937473202; Fri, 05 Sep 2014 10:17:53 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Fri, 5 Sep 2014 10:17:53 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A283248B6@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A283248B6@xmb-rcd-x10.cisco.com> Date: Fri, 5 Sep 2014 10:17:53 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b5dbcda3ef37b050254a63e Archived-At: http://mailarchive.ietf.org/arch/msg/tram/W1H2bY7Xmgzkg5sAJ8L3rNIjyIQ Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-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, 05 Sep 2014 17:17:57 -0000 --047d7b5dbcda3ef37b050254a63e Content-Type: text/plain; charset=UTF-8 I agree with the changes. Thanks Oleg On Fri, Sep 5, 2014 at 10:01 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > > -----Original Message----- > > From: Brandon Williams [mailto:brandon.williams@akamai.com] > > Sent: Friday, September 05, 2014 6:57 PM > > To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko > > Cc: tram@ietf.org > > Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 > > > > On 09/05/2014 07:21 AM, Tirumaleswar Reddy (tireddy) wrote: > > > > [snip] > > > > >> -----Original Message----- > > >> From: Brandon Williams [mailto:brandon.williams@akamai.com] > > >> Here are the ideas running through my head at the moment. The > > >> algorithm to use for standard STUN authentication could be selected > > >> in one of the two following ways (assuming that the client can't be > > >> pre-configured to know the algorithm in advance). > > >> > > >> Standard STUN Auth option 1 > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> * client sends algorithm list in initial allocation request > > >> * relay server selects an algorithm and send that in the allocation > > >> error response > > >> * client sends allocation request with message integrity using > > >> selected algorithm > > >> > > >> Standard STUN Auth option 2 > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> * client sends initial allocation request as per existing spec > > >> * relay server sends a list of supported algorithms in the allocation > > >> error response > > >> * client selects an algorithm from the list and uses it to generate > > >> message integrity for the new allocation request > > >> > > >> I like option 2 better because I think it works better with 3rd party > > >> auth by allowing for indirect in-band negotiation between the relay > > >> and auth servers as well as out-of-band negotiation, while at the > > >> same time not requiring the client to be pre-configured in either > case. > > > > > > Yes, option 2 is more suitable. > > > > > >> > > >> 3rd Party Auth with initial relay server exchange > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> * no out-of-band algorithm exchange required between relay server and > > >> oauth server > > >> * client sends initial allocation request as per existing spec > > >> * relay server sends a list of supported algorithms in the allocation > > >> error response > > >> * client sends token request to oauth with the union set of > > >> algorithms supported by the client and the turn server > > > > > > I think you mean intersection. > > > > > > > Oops, yes, I was thinks intersection throughout the earlier e-mail and > writing > > union. Guess I should have waited until after that second cup of coffee. > > > > >> * oauth server selects an algorithm from the list and sends an > > >> appropriate key in the token > > >> * client sends allocation request with message integrity using > > >> selected algorithm > > > > > > This approach looks good. > > > > > > > OK. So, if we go with this model, then in the 3rd party draft, the the > OAuth > > request would specify a list of supported algorithms, and the OAuth > > response would specify the selected algorithm. For now, the only valid > value > > in each direction would be "hmac-sha1" or something similar. > > In the future, after hash agility and the list of must/should algorithms > have > > been specified, other algorithm specifiers can be added. > > > > Does that sound reasonable ? > > Yes. Updated draft and attached the diff, please have a look. > > Cheers, > -Tiru > > > > > --Brandon > > > > > -Tiru > > > > > >> > > >> 3rd Party Auth without initial relay server exchange > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> * relay server provides oauth server with list of supported > > >> algorithms via out- of-band mechanism > > >> * client sends token request to oauth with the list of algorithms > > >> supported by the client > > >> * oauth server selects an algorithm from the set of algorithms > > >> supported by both the client and the relay server, and it sends an > > >> appropriate key in the token > > >> * client sends allocation request with message integrity using > > >> selected algorithm > > >> > > >> > > >> What are your thoughts on the above? > > >> > > >> --Brandon > > >> > > >> -- > > >> Brandon Williams; Senior Principal Software Engineer Emerging > > >> Products Engineering; Akamai Technologies Inc. > > >> > > >> _______________________________________________ > > >> tram mailing list > > >> tram@ietf.org > > >> https://www.ietf.org/mailman/listinfo/tram > > > > -- > > Brandon Williams; Senior Principal Software Engineer Emerging Products > > Engineering; Akamai Technologies Inc. > --047d7b5dbcda3ef37b050254a63e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I agree with the changes.

Thanks

<= div>Oleg

On Fri, Sep 5, 2014 at 10:01 AM, Tirumaleswar Reddy (tireddy) <tire= ddy@cisco.com> wrote:

> -----Original Message-----
> From: Brandon Williams [mailto:brandon.williams@akamai.com]
> Sent: Friday, September 05, 2014 6:57 PM
> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko
> Cc: tram@ietf.org
> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03
>

> On 09/05/2014 07:21 AM, Tirumaleswar Red= dy (tireddy) wrote:
>
> [snip]
>
> >> -----Original Message-----
> >> From: Brandon Williams [mailto:brandon.williams@akamai.com]
> >> Here are the ideas running through my head at the moment. The=
> >> algorithm to use for standard STUN authentication could be se= lected
> >> in one of the two following ways (assuming that the client ca= n't be
> >> pre-configured to know the algorithm in advance).
> >>
> >> Standard STUN Auth option 1
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> * client sends algorithm list in initial allocation request > >> * relay server selects an algorithm and send that in the allo= cation
> >> error response
> >> * client sends allocation request with message integrity usin= g
> >> selected algorithm
> >>
> >> Standard STUN Auth option 2
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> * client sends initial allocation request as per existing spe= c
> >> * relay server sends a list of supported algorithms in the al= location
> >> error response
> >> * client selects an algorithm from the list and uses it to ge= nerate
> >> message integrity for the new allocation request
> >>
> >> I like option 2 better because I think it works better with 3= rd party
> >> auth by allowing for indirect in-band negotiation between the= relay
> >> and auth servers as well as out-of-band negotiation, while at= the
> >> same time not requiring the client to be pre-configured in ei= ther case.
> >
> > Yes, option 2 is more suitable.
> >
> >>
> >> 3rd Party Auth with initial relay server exchange
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> * no out-of-band algorithm exchange required between relay se= rver and
> >> oauth server
> >> * client sends initial allocation request as per existing spe= c
> >> * relay server sends a list of supported algorithms in the al= location
> >> error response
> >> * client sends token request to oauth with the union set of > >> algorithms supported by the client and the turn server
> >
> > I think you mean intersection.
> >
>
> Oops, yes, I was thinks intersection throughout the earlier e-mail and= writing
> union. Guess I should have waited until after that second cup of coffe= e.
>
> >> * oauth server selects an algorithm from the list and sends a= n
> >> appropriate key in the token
> >> * client sends allocation request with message integrity usin= g
> >> selected algorithm
> >
> > This approach looks good.
> >
>
> OK. So, if we go with this model, then in the 3rd party draft, the the= OAuth
> request would specify a list of supported algorithms, and the OAuth > response would specify the selected algorithm. For now, the only valid= value
> in each direction would be "hmac-sha1" or something similar.=
> In the future, after hash agility and the list of must/should algorith= ms have
> been specified, other algorithm specifiers can be added.
>
> Does that sound reasonable ?

Yes. Updated draft and attached the diff, please have a look.
Cheers,
-Tiru

>
> --Brandon
>
> > -Tiru
> >
> >>
> >> 3rd Party Auth without initial relay server exchange
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> * relay server provides oauth server with list of supported > >> algorithms via out- of-band mechanism
> >> * client sends token request to oauth with the list of algori= thms
> >> supported by the client
> >> * oauth server selects an algorithm from the set of algorithm= s
> >> supported by both the client and the relay server, and it sen= ds an
> >> appropriate key in the token
> >> * client sends allocation request with message integrity usin= g
> >> selected algorithm
> >>
> >>
> >> What are your thoughts on the above?
> >>
> >> --Brandon
> >>
> >> --
> >> Brandon Williams; Senior Principal Software Engineer Emerging=
> >> Products Engineering; Akamai Technologies Inc.
> >>
> >> _______________________________________________
> >> tram mailing list
> >> tram@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tram
>
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products=
> Engineering; Akamai Technologies Inc.

--047d7b5dbcda3ef37b050254a63e-- From nobody Fri Sep 5 10:23:51 2014 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 228EF1A0ADB for ; Fri, 5 Sep 2014 10:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=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 y-kaEtc8jg7d for ; Fri, 5 Sep 2014 10:23:48 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013501A071F for ; Fri, 5 Sep 2014 10:23:47 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cc10so1122683wib.3 for ; Fri, 05 Sep 2014 10:23:46 -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=MXbDoHdCkXZmQodesLOZ8/mN/QoAvc1SVfjBf1PT1xo=; b=M7h6SFE3eWxT6Hb3zCuLcPeKVgzomcm/llVHyH5fOI/KUfUMHonwThqyOjPs5cHUYX 1TYRbLuJHVxIA7LwO5hxmdHWtlFO5itcfzoYbJUBGzTZMevZmHkz9X8mywKHYg09u0Mu qQyvQuTK5CGoooVsXzLCwSFBT7yVs2RFjCH8KOu6wWz+zUpVLKhar1GHoBBIiz0Vi8Ct EGk8AfXH7Q9P52f/skyNhdhPmOGifNjZaU+9i/s/wXpkGiYpc47nOqSO3c0jGWPXDK2h dTCUBWMln7hXUEKIzj20bRVJ3C7mMsTcBnY5hbW+aEvR4He0qT3Spd5syz0IgZINd2gF pWjA== MIME-Version: 1.0 X-Received: by 10.194.5.234 with SMTP id v10mr16262238wjv.45.1409937826613; Fri, 05 Sep 2014 10:23:46 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Fri, 5 Sep 2014 10:23:46 -0700 (PDT) In-Reply-To: References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> <5409D31F.9070003@akamai.com> Date: Fri, 5 Sep 2014 10:23:46 -0700 Message-ID: From: Oleg Moskalenko To: "Prashanth Patil (praspati)" Content-Type: multipart/alternative; boundary=047d7b5d2fde4f9036050254bbd3 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Q3VuMSM2DRqDPgmlQJ2sN6SeHLM Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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: Fri, 05 Sep 2014 17:23:49 -0000 --047d7b5d2fde4f9036050254bbd3 Content-Type: text/plain; charset=UTF-8 > > > > >Do you mean that you specifically don't expect mobility tickets to be > >used in the case that I describe (going from a 3G address to a wifi > >address)? If that's not what you mean, then I don't understand your > >point. It would be quite common for the optimal relay to change when you > >change service providers, which you're probably doing when you change > >from 3G to wifi. > > I could be mistaken but it seems to me that even if you changed service > providers, the likelihood of change in quality would not be significant > enough for a client to shift relays. Shifting relays would result in > session re-establishment with impact on the remote peer. > > -Prashanth > > > I had an impression that a relay change is beyond the scope of this document. And I also do not understand why we would need a session mobility if we change the relay - we would just establish a new session with the new relay server. Another point is that the MICE is about changing the client endpoint without changing the relay endpoint - the relay endpoint stays the same. Well, if we change the relay server, it becomes impossible. The nature of TCP/IP protocol does not allow shifting network endpoints from one server to another, especially if they are in different regions. So I do not understand why shifting relays is relevant in the context of this discussion. Thank Oleg --047d7b5d2fde4f9036050254bbd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

>
>Do you mean that you specifically don't expect mobility tickets to = be
>used in the case that I describe (going from a 3G address to a wifi
>address)? If that's not what you mean, then I don't understand = your
>point. It would be quite common for the optimal relay to change when yo= u
>change service providers, which you're probably doing when you chan= ge
>from 3G to wifi.

I could be mistaken but it seems to me that even if you changed= service
providers, the likelihood of change in quality would not be significant
enough for a client to shift relays. Shifting relays would result in
session re-establishment with impact on the remote peer.

-Prashanth

<= /blockquote>

I had an impression that a relay change is = beyond the scope of this document. =C2=A0And I also do not understand why w= e would need a session mobility if we change the relay - we would just esta= blish a new session with the new relay server.

Ano= ther point is that the MICE is about changing the client endpoint without c= hanging the relay endpoint - the relay endpoint stays the same. Well, if we= change the relay server, it becomes impossible. The nature of TCP/IP proto= col does not allow shifting network endpoints from one server to another, e= specially if they are in different regions.

So I d= o not understand why shifting relays is relevant in the context of this dis= cussion.

Thank
Oleg

=

--047d7b5d2fde4f9036050254bbd3-- From nobody Fri Sep 5 10:25:11 2014 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 4E06C1A071F for ; Fri, 5 Sep 2014 10:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 kLFJJspaXLPO for ; Fri, 5 Sep 2014 10:25:08 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id E49D21A0386 for ; Fri, 5 Sep 2014 10:25:07 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3728B284DE; Fri, 5 Sep 2014 17:25:05 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 22F89284CF; Fri, 5 Sep 2014 17:25:05 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 1BC472029; Fri, 5 Sep 2014 17:25:05 +0000 (GMT) Message-ID: <5409F1F1.6090808@akamai.com> Date: Fri, 05 Sep 2014 13:25:05 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Oleg Moskalenko , "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A283248B6@xmb-rcd-x10.cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/_Ys1s83Ucgg0jse_NYaMmInLcSw Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-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, 05 Sep 2014 17:25:10 -0000 Looks good to me too. --Brandon On 09/05/2014 01:17 PM, Oleg Moskalenko wrote: > I agree with the changes. > > Thanks > Oleg > > > On Fri, Sep 5, 2014 at 10:01 AM, Tirumaleswar Reddy (tireddy) > > wrote: > > > -----Original Message----- > > From: Brandon Williams [mailto:brandon.williams@akamai.com ] > > Sent: Friday, September 05, 2014 6:57 PM > > To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko > > Cc:tram@ietf.org > > Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 > > > > On 09/05/2014 07:21 AM, Tirumaleswar Reddy (tireddy) wrote: > > > > [snip] > > > > >> -----Original Message----- > > >> From: Brandon Williams [mailto:brandon.williams@akamai.com > ] > > >> Here are the ideas running through my head at the moment. The > > >> algorithm to use for standard STUN authentication could be > selected > > >> in one of the two following ways (assuming that the client > can't be > > >> pre-configured to know the algorithm in advance). > > >> > > >> Standard STUN Auth option 1 > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> * client sends algorithm list in initial allocation request > > >> * relay server selects an algorithm and send that in the > allocation > > >> error response > > >> * client sends allocation request with message integrity using > > >> selected algorithm > > >> > > >> Standard STUN Auth option 2 > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> * client sends initial allocation request as per existing spec > > >> * relay server sends a list of supported algorithms in the > allocation > > >> error response > > >> * client selects an algorithm from the list and uses it to > generate > > >> message integrity for the new allocation request > > >> > > >> I like option 2 better because I think it works better with > 3rd party > > >> auth by allowing for indirect in-band negotiation between the > relay > > >> and auth servers as well as out-of-band negotiation, while at the > > >> same time not requiring the client to be pre-configured in > either case. > > > > > > Yes, option 2 is more suitable. > > > > > >> > > >> 3rd Party Auth with initial relay server exchange > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> * no out-of-band algorithm exchange required between relay > server and > > >> oauth server > > >> * client sends initial allocation request as per existing spec > > >> * relay server sends a list of supported algorithms in the > allocation > > >> error response > > >> * client sends token request to oauth with the union set of > > >> algorithms supported by the client and the turn server > > > > > > I think you mean intersection. > > > > > > > Oops, yes, I was thinks intersection throughout the earlier > e-mail and writing > > union. Guess I should have waited until after that second cup of > coffee. > > > > >> * oauth server selects an algorithm from the list and sends an > > >> appropriate key in the token > > >> * client sends allocation request with message integrity using > > >> selected algorithm > > > > > > This approach looks good. > > > > > > > OK. So, if we go with this model, then in the 3rd party draft, > the the OAuth > > request would specify a list of supported algorithms, and the OAuth > > response would specify the selected algorithm. For now, the only > valid value > > in each direction would be "hmac-sha1" or something similar. > > In the future, after hash agility and the list of must/should > algorithms have > > been specified, other algorithm specifiers can be added. > > > > Does that sound reasonable ? > > Yes. Updated draft and attached the diff, please have a look. > > Cheers, > -Tiru > > > > > --Brandon > > > > > -Tiru > > > > > >> > > >> 3rd Party Auth without initial relay server exchange > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> * relay server provides oauth server with list of supported > > >> algorithms via out- of-band mechanism > > >> * client sends token request to oauth with the list of algorithms > > >> supported by the client > > >> * oauth server selects an algorithm from the set of algorithms > > >> supported by both the client and the relay server, and it sends an > > >> appropriate key in the token > > >> * client sends allocation request with message integrity using > > >> selected algorithm > > >> > > >> > > >> What are your thoughts on the above? > > >> > > >> --Brandon > > >> > > >> -- > > >> Brandon Williams; Senior Principal Software Engineer Emerging > > >> Products Engineering; Akamai Technologies Inc. > > >> > > >> _______________________________________________ > > >> tram mailing list > > >> tram@ietf.org > > >> https://www.ietf.org/mailman/listinfo/tram > > > > -- > > Brandon Williams; Senior Principal Software Engineer Emerging > Products > > Engineering; Akamai Technologies Inc. > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Sep 5 10:54:46 2014 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 B27F71A0120 for ; Fri, 5 Sep 2014 10:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 c4EG_kWLEe6r for ; Fri, 5 Sep 2014 10:54:42 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id CA6A71A0027 for ; Fri, 5 Sep 2014 10:54:41 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 423B42865D; Fri, 5 Sep 2014 17:54:41 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 23CD628656; Fri, 5 Sep 2014 17:54:41 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 1DE362029; Fri, 5 Sep 2014 17:54:41 +0000 (GMT) Message-ID: <5409F8E1.90302@akamai.com> Date: Fri, 05 Sep 2014 13:54:41 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Oleg Moskalenko , "Prashanth Patil (praspati)" References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> <5409D31F.9070003@akamai.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/bShPfcFXGeehRQPXiJM9EOAv570 Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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: Fri, 05 Sep 2014 17:54:43 -0000 On 09/05/2014 01:23 PM, Oleg Moskalenko wrote: > > >Do you mean that you specifically don't expect mobility tickets to be > >used in the case that I describe (going from a 3G address to a wifi > >address)? If that's not what you mean, then I don't understand your > >point. It would be quite common for the optimal relay to change > when you > >change service providers, which you're probably doing when you change > >from 3G to wifi. > > I could be mistaken but it seems to me that even if you changed service > providers, the likelihood of change in quality would not be significant > enough for a client to shift relays. Shifting relays would result in > session re-establishment with impact on the remote peer. > > -Prashanth > > > > I had an impression that a relay change is beyond the scope of this > document. And I also do not understand why we would need a session > mobility if we change the relay - we would just establish a new session > with the new relay server. I'm not suggesting that the ticket would be used to change the relay. I'm suggesting that the ticket functionality is of limited value for a system that does performance based relay selection unless the refresh response gives the client some indication that shifting the flow to another relay would be beneficial. The client would get the benefit of the ticket (maintaining the session across an address change), while at the same time getting the benefit of performance based relay selection. > Another point is that the MICE is about changing the client endpoint > without changing the relay endpoint - the relay endpoint stays the same. > Well, if we change the relay server, it becomes impossible. The nature > of TCP/IP protocol does not allow shifting network endpoints from one > server to another, especially if they are in different regions. I'm confused about how TCP/IP comes into this. Since TURN only supports TCP/IP between the client endpoint and the relay server (turnbis still says that UDP is the only allowed REQUESTED-TRANSPORT value), what makes TCP/IP semantics relevant? I'm not particularly familiar with MICE, so maybe the answer to my question is there and I just need to read up on it. > So I do not understand why shifting relays is relevant in the context of > this discussion. > Just to be clear, I'm not suggesting any changes to how the ticket mechanism works or the conditions under which it would be used. I'm just suggesting that the mobility ticket use case creates a new situation where a try-alternate hint in a success response would be valuable to the client, helping it to provide better session quality. --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Sep 5 11:27:40 2014 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 C40151A6F2D for ; Fri, 5 Sep 2014 11:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 slX7ZPQW1gIG for ; Fri, 5 Sep 2014 11:27:28 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 9C51C1A6F10 for ; Fri, 5 Sep 2014 11:27:28 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B1AEC47656; Fri, 5 Sep 2014 18:27:27 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A64024764A; Fri, 5 Sep 2014 18:27:27 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id A25DA2027; Fri, 5 Sep 2014 18:27:27 +0000 (GMT) Message-ID: <540A008F.10600@akamai.com> Date: Fri, 05 Sep 2014 14:27:27 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "tram@ietf.org" References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> <5409D31F.9070003@akamai.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/W4lxn5fMHxVaJkrWz1bN4FJua_M Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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: Fri, 05 Sep 2014 18:27:32 -0000 On 09/05/2014 12:45 PM, Prashanth Patil (praspati) wrote: > On 9/5/14 8:43 PM, "Brandon Williams" wrote: [snip] >> Do you mean that you specifically don't expect mobility tickets to be >> used in the case that I describe (going from a 3G address to a wifi >> address)? If that's not what you mean, then I don't understand your >> point. It would be quite common for the optimal relay to change when you >> change service providers, which you're probably doing when you change >>from 3G to wifi. > > I could be mistaken but it seems to me that even if you changed service > providers, the likelihood of change in quality would not be significant > enough for a client to shift relays. Shifting relays would result in > session re-establishment with impact on the remote peer. > Change in service provider can be one of the most significant factors influencing connection quality, because the peering relationships between providers are so important. If the peering relationships for the new provider are distinctly different than the peering relationships for the previous, that could be enough to make the relay server a very bad choice in some cases. It could be the case that the relationship between the relay server and the carrier that it's on prevents it from being used by off-network clients, but in that case, it should not have handed back a mobility ticket in the first place. It might be a good idea to point that out in the draft. That's a little bit off the current topic though. --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Sep 5 11:37:35 2014 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 BC7F11A01E2 for ; Fri, 5 Sep 2014 11:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 Mw0ivJHKjiUg for ; Fri, 5 Sep 2014 11:37:32 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2A52B1A01E0 for ; Fri, 5 Sep 2014 11:37:31 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4F0C728649; Fri, 5 Sep 2014 18:37:31 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 392FA28644; Fri, 5 Sep 2014 18:37:31 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 35C922027; Fri, 5 Sep 2014 18:37:31 +0000 (GMT) Message-ID: <540A02EB.4060205@akamai.com> Date: Fri, 05 Sep 2014 14:37:31 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "tram@ietf.org" References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> <5409D31F.9070003@akamai.com> <540A008F.10600@akamai.com> In-Reply-To: <540A008F.10600@akamai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BfPcN_iIPQwQhDSJqbte3KKN9JY Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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: Fri, 05 Sep 2014 18:37:33 -0000 On 09/05/2014 02:27 PM, Brandon Williams wrote: > It could be the case that the relationship between the relay server and > the carrier that it's on prevents it from being used by off-network > clients, but in that case, it should not have handed back a mobility > ticket in the first place. It might be a good idea to point that out in > the draft. That's a little bit off the current topic though. This is just wrong. Of course it would hand out mobility tickets to support changing address without changing provider. Under these conditions, the relay server should reject the mobility ticket with an error message that clearly indicates the reason if the new client address is not believed to be on the same provider. --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Sep 5 11:52:06 2014 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 EF82D1A0B77 for ; Fri, 5 Sep 2014 11:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=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 qElvSrRFjFBy for ; Fri, 5 Sep 2014 11:51:51 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57191A014E for ; Fri, 5 Sep 2014 11:51:50 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id q5so252617wiv.6 for ; Fri, 05 Sep 2014 11:51:49 -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=Y1M+qKY36yY0IHrvASdhjD6hEV/i7abwdEWsP9eTOOs=; b=lK++X39mEofqJ/uUr+7IDbhcWzciQJQV8Mhr4pnpAR3fq59LYo1gyXLh1MeKRlMXqR g8TezYlaCRI+YDnITu92OAxGMFxZjSaZpvvrDXc+SHNLmtF11gMV2vxWrp8zeytJsgIi ocLbjeY3i0yTMSQ07B/3M3YJxDuABjedBFVR6gmaKZLXS0+4rMXD2tDKpNbzaDBcUB9D 8nX3sdQN1PSVGmQNqjrV4zpolMqO/TSE1xKoaQ0A3cb6KPh91O5sxFuHa8h/OLHvS/H2 GmQhIZNnECdSQaGjCs6eR5aML5PVRF00djvgEQx2IrkTH9u22xq/NxgNSINp1GwQywnj 6eqQ== MIME-Version: 1.0 X-Received: by 10.194.5.234 with SMTP id v10mr16648256wjv.45.1409943109556; Fri, 05 Sep 2014 11:51:49 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Fri, 5 Sep 2014 11:51:49 -0700 (PDT) In-Reply-To: <5409F8E1.90302@akamai.com> References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> <5409D31F.9070003@akamai.com> <5409F8E1.90302@akamai.com> Date: Fri, 5 Sep 2014 11:51:49 -0700 Message-ID: From: Oleg Moskalenko To: Brandon Williams Content-Type: multipart/alternative; boundary=047d7b5d2fde32e129050255f6f0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Jx1Bo22fMQlvZYKmMwR1kypM9Gc Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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: Fri, 05 Sep 2014 18:51:53 -0000 --047d7b5d2fde32e129050255f6f0 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 5, 2014 at 10:54 AM, Brandon Williams < brandon.williams@akamai.com> wrote: > > Another point is that the MICE is about changing the client endpoint >> without changing the relay endpoint - the relay endpoint stays the same. >> Well, if we change the relay server, it becomes impossible. The nature >> of TCP/IP protocol does not allow shifting network endpoints from one >> server to another, especially if they are in different regions. >> > > I'm confused about how TCP/IP comes into this. Since TURN only supports > TCP/IP between the client endpoint and the relay server (turnbis still says > that UDP is the only allowed REQUESTED-TRANSPORT value), what makes TCP/IP > semantics relevant? I'm not particularly familiar with MICE, so maybe the > answer to my question is there and I just need to read up on it. > > In the common terminology, there is "TCP protocol", "UDP protocol" and "TCP/IP stack of protocols". The "UDP protocol" is a part of the "TCP/IP stack of protocols". TCP relay (when TCP is used by the relay endpoints, too) is described in RFC 6062. MICE and RFC 6062 do not contradict each other, so we assume that the session mobility must be applicable to the TCP relay, too. Either way, UDP or TCP, we cannot shift the relay endpoints from one relay server to another. Oleg --047d7b5d2fde32e129050255f6f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 5, 2014 at 10:54 AM, Brandon Williams <brand= on.williams@akamai.com> wrote:

Another point is that the MICE is about changing the client endpoint
without changing the relay endpoint - the relay endpoint stays the same. Well, if we change the relay server, it becomes impossible. The nature
of TCP/IP protocol does not allow shifting network endpoints from one
server to another, especially if they are in different regions.

I'm confused about how TCP/IP comes into this. Since TURN only supports= TCP/IP between the client endpoint and the relay server (turnbis still say= s that UDP is the only allowed REQUESTED-TRANSPORT value), what makes TCP/I= P semantics relevant? I'm not particularly familiar with MICE, so maybe= the answer to my question is there and I just need to read up on it.

In the c= ommon terminology, there is "TCP protocol", "UDP protocol&qu= ot; and "TCP/IP stack of protocols". The "UDP protocol"= is a part of the "TCP/IP stack of protocols".

TCP relay (when TCP is used by the relay endpoints, t= oo) is described in RFC 6062. MICE and RFC 6062 do not contradict each othe= r, so we assume that the session mobility must be applicable to the TCP rel= ay, too.

Either way, UDP or TCP, we cannot shift the relay endpoints from one= relay server to another.

Oleg
<= br>

--047d7b5d2fde32e129050255f6f0-- From nobody Fri Sep 5 12:41:08 2014 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 281341A0060 for ; Fri, 5 Sep 2014 12:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 TSicyd7p6k6h for ; Fri, 5 Sep 2014 12:41:04 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 92D131A0041 for ; Fri, 5 Sep 2014 12:41:04 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CD2F747590; Fri, 5 Sep 2014 19:41:03 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A67C44752D; Fri, 5 Sep 2014 19:41:03 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 981B62029; Fri, 5 Sep 2014 19:41:03 +0000 (GMT) Message-ID: <540A11CF.5020707@akamai.com> Date: Fri, 05 Sep 2014 15:41:03 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> <5409D31F.9070003@akamai.com> <5409F8E1.90302@akamai.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/2eUajVyZJX2PLnU8TBW-9ywmQIo Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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: Fri, 05 Sep 2014 19:41:07 -0000 Ah. "TCP/IP protocol" isn't commonly used as shorthand for "TCP/IP stack of protocols". The "s" on the end of "protocols" is probably key there. Anyway, thanks for the clarification. Your point that it's not possible to serve a unicast relay endpoint address out of multiple relay server locations is of course correct. As per my previous message, I wasn't indicating anything of the sort. --Brandon On 09/05/2014 02:51 PM, Oleg Moskalenko wrote: > > > > On Fri, Sep 5, 2014 at 10:54 AM, Brandon Williams > > wrote: > > > > Another point is that the MICE is about changing the client endpoint > without changing the relay endpoint - the relay endpoint stays > the same. > Well, if we change the relay server, it becomes impossible. The > nature > of TCP/IP protocol does not allow shifting network endpoints > from one > server to another, especially if they are in different regions. > > > I'm confused about how TCP/IP comes into this. Since TURN only > supports TCP/IP between the client endpoint and the relay server > (turnbis still says that UDP is the only allowed REQUESTED-TRANSPORT > value), what makes TCP/IP semantics relevant? I'm not particularly > familiar with MICE, so maybe the answer to my question is there and > I just need to read up on it. > > > In the common terminology, there is "TCP protocol", "UDP protocol" and > "TCP/IP stack of protocols". The "UDP protocol" is a part of the "TCP/IP > stack of protocols". > > TCP relay (when TCP is used by the relay endpoints, too) is described in > RFC 6062. MICE and RFC 6062 do not contradict each other, so we assume > that the session mobility must be applicable to the TCP relay, too. > > Either way, UDP or TCP, we cannot shift the relay endpoints from one > relay server to another. > > Oleg > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Sep 5 19:13:57 2014 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 937201A046D; Fri, 5 Sep 2014 19:13:55 -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 0q7W-InCF9W3; Fri, 5 Sep 2014 19:13:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 356FD1A0408; Fri, 5 Sep 2014 19:13:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140906021354.8198.26391.idtracker@ietfa.amsl.com> Date: Fri, 05 Sep 2014 19:13:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/JiESVevolDt-6edS6YU8mbmDTgk Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-03.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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, 06 Sep 2014 02:13:56 -0000 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 Extension for Third Party Authorization Authors : Tirumaleswar Reddy Prashanth Patil Ram Mohan Ravindranath Justin Uberti Filename : draft-ietf-tram-turn-third-party-authz-03.txt Pages : 16 Date : 2014-09-05 Abstract: This document proposes the use of OAuth to obtain and validate ephemeral tokens that can be used for TURN authentication. The usage of ephemeral tokens ensure that access to a TURN server can be controlled even if the tokens are compromised. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-03 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/ From nobody Fri Sep 5 19:22:06 2014 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 845AA1A0473 for ; Fri, 5 Sep 2014 19:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 u2BopAjtcA_7 for ; Fri, 5 Sep 2014 19:22: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 C62C11A02A0 for ; Fri, 5 Sep 2014 19:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6665; q=dns/txt; s=iport; t=1409970123; x=1411179723; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6l1HL5TpK7lyAPXJJmFROlWoWgaMCTvsEkHlRHqGZMI=; b=idH2wtIVY55QuCZtyVk2McRFEzFcghdJr1K/N+EpmIGhR7BVoyuTpttT xHXlJW9m1t6VPV24PZUiFOLZZh7sEusXcRiLsAy4qNtcQ97alWRZYIhAp eRc6m8TE7XJqpcZ5ZTiMiIn8mnm/GcyA3F6pyMvmNJOnewC2nBGQ0zyJG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAOhuClStJA2K/2dsb2JhbABagw1TVwTJEwqHTAGBBBZ3hAMBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAEBBAENBQiIOg2/OQETBI8cMQcGgymBHQWRPqBUgWkcgVxsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,477,1406592000"; d="scan'208";a="353002851" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP; 06 Sep 2014 02:22:02 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s862M1f8030561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Sep 2014 02:22:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 21:22:01 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Oleg Moskalenko Thread-Topic: [tram] draft-ietf-tram-turn-third-party-authz-03 Thread-Index: Ac/JKvGcbv7VIcRBRjSPFW0PEduTFgALErOAAABAYIAACCua0A== Date: Sat, 6 Sep 2014 02:22:01 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28324ABA@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A283248B6@xmb-rcd-x10.cisco.com> <5409F1F1.6090808@akamai.com> In-Reply-To: <5409F1F1.6090808@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/U3h49S-RjN8xKus68HLN7YGrpnM Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-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: Sat, 06 Sep 2014 02:22:05 -0000 Thanks Oleg and Brandon for the review. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Friday, September 05, 2014 10:55 PM > To: Oleg Moskalenko; Tirumaleswar Reddy (tireddy) > Cc: tram@ietf.org > Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 >=20 > Looks good to me too. >=20 > --Brandon >=20 > On 09/05/2014 01:17 PM, Oleg Moskalenko wrote: > > I agree with the changes. > > > > Thanks > > Oleg > > > > > > On Fri, Sep 5, 2014 at 10:01 AM, Tirumaleswar Reddy (tireddy) > > > wrote: > > > > > -----Original Message----- > > > From: Brandon Williams [mailto:brandon.williams@akamai.com > ] > > > Sent: Friday, September 05, 2014 6:57 PM > > > To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko > > > Cc:tram@ietf.org > > > Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 > > > > > > On 09/05/2014 07:21 AM, Tirumaleswar Reddy (tireddy) wrote: > > > > > > [snip] > > > > > > >> -----Original Message----- > > > >> From: Brandon Williams [mailto:brandon.williams@akamai.com > > ] > > > >> Here are the ideas running through my head at the moment. The > > > >> algorithm to use for standard STUN authentication could be > > selected > > > >> in one of the two following ways (assuming that the client > > can't be > > > >> pre-configured to know the algorithm in advance). > > > >> > > > >> Standard STUN Auth option 1 > > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > >> * client sends algorithm list in initial allocation request > > > >> * relay server selects an algorithm and send that in the > > allocation > > > >> error response > > > >> * client sends allocation request with message integrity usin= g > > > >> selected algorithm > > > >> > > > >> Standard STUN Auth option 2 > > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > >> * client sends initial allocation request as per existing spe= c > > > >> * relay server sends a list of supported algorithms in the > > allocation > > > >> error response > > > >> * client selects an algorithm from the list and uses it to > > generate > > > >> message integrity for the new allocation request > > > >> > > > >> I like option 2 better because I think it works better with > > 3rd party > > > >> auth by allowing for indirect in-band negotiation between the > > relay > > > >> and auth servers as well as out-of-band negotiation, while at= the > > > >> same time not requiring the client to be pre-configured in > > either case. > > > > > > > > Yes, option 2 is more suitable. > > > > > > > >> > > > >> 3rd Party Auth with initial relay server exchange > > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > >> * no out-of-band algorithm exchange required between relay > > server and > > > >> oauth server > > > >> * client sends initial allocation request as per existing spe= c > > > >> * relay server sends a list of supported algorithms in the > > allocation > > > >> error response > > > >> * client sends token request to oauth with the union set of > > > >> algorithms supported by the client and the turn server > > > > > > > > I think you mean intersection. > > > > > > > > > > Oops, yes, I was thinks intersection throughout the earlier > > e-mail and writing > > > union. Guess I should have waited until after that second cup of > > coffee. > > > > > > >> * oauth server selects an algorithm from the list and sends a= n > > > >> appropriate key in the token > > > >> * client sends allocation request with message integrity usin= g > > > >> selected algorithm > > > > > > > > This approach looks good. > > > > > > > > > > OK. So, if we go with this model, then in the 3rd party draft, > > the the OAuth > > > request would specify a list of supported algorithms, and the OA= uth > > > response would specify the selected algorithm. For now, the only > > valid value > > > in each direction would be "hmac-sha1" or something similar. > > > In the future, after hash agility and the list of must/should > > algorithms have > > > been specified, other algorithm specifiers can be added. > > > > > > Does that sound reasonable ? > > > > Yes. Updated draft and attached the diff, please have a look. > > > > Cheers, > > -Tiru > > > > > > > > --Brandon > > > > > > > -Tiru > > > > > > > >> > > > >> 3rd Party Auth without initial relay server exchange > > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > >> * relay server provides oauth server with list of supported > > > >> algorithms via out- of-band mechanism > > > >> * client sends token request to oauth with the list of algori= thms > > > >> supported by the client > > > >> * oauth server selects an algorithm from the set of algorithm= s > > > >> supported by both the client and the relay server, and it sen= ds an > > > >> appropriate key in the token > > > >> * client sends allocation request with message integrity usin= g > > > >> selected algorithm > > > >> > > > >> > > > >> What are your thoughts on the above? > > > >> > > > >> --Brandon > > > >> > > > >> -- > > > >> Brandon Williams; Senior Principal Software Engineer Emerging > > > >> Products Engineering; Akamai Technologies Inc. > > > >> > > > >> _______________________________________________ > > > >> tram mailing list > > > >> tram@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/tram > > > > > > -- > > > Brandon Williams; Senior Principal Software Engineer Emerging > > Products > > > Engineering; Akamai Technologies Inc. > > > > >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri Sep 5 19:22:49 2014 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 7D4731A0473 for ; Fri, 5 Sep 2014 19:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 h3Za4PHTBicc for ; Fri, 5 Sep 2014 19:22:45 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6351A02A0 for ; Fri, 5 Sep 2014 19:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2124; q=dns/txt; s=iport; t=1409970165; x=1411179765; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dpVci6s4oMS92oqULvv46Cud5jrDnQiMg94QrSaXya8=; b=QEtTNyyzmGcMu0iYH+0Zn5D2DFyc7eW8DppiLYPsy3Y+I+XEGri5+xRD jsw4zn6GXjsFOB5f8L379IhDXvB0oqJqbi+iecO53kMKW0T2AeFktbJuD t0MOO+kP6xVh4FXd4J6D5bAdTFlXgy+HfbyiHYYWguNwN0SkUUeoRwWxz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAL5uClStJV2d/2dsb2JhbABagw1TUwQEyRMMh0oBgQQWd4QDAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQTCAGIOQgFvzkBF48cOAaDKYEdBZE+hDCIWpNKgWkcgVxsgQgkHIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,477,1406592000"; d="scan'208";a="75463819" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 06 Sep 2014 02:22:44 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s862MiWY024277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 6 Sep 2014 02:22:44 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 21:22:44 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-03.txt Thread-Index: AQHPyXg8PA32jxFo5ku1O26SF/lSM5vzXbdQ Date: Sat, 6 Sep 2014 02:22:43 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28324ACB@xmb-rcd-x10.cisco.com> References: <20140906021354.8198.26391.idtracker@ietfa.amsl.com> In-Reply-To: <20140906021354.8198.26391.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.55.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/wVFILS_LR3n3-aHDxcKSky9FH14 Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-03.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, 06 Sep 2014 02:22:48 -0000 This version addresses comments from Oleg and includes hash agility details= based on discussion with Brandon.=20 Cheers, -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Saturday, September 06, 2014 7:44 AM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized Working > Group of the IETF. >=20 > Title : TURN Extension for Third Party Authorization > Authors : Tirumaleswar Reddy > Prashanth Patil > Ram Mohan Ravindranath > Justin Uberti > Filename : draft-ietf-tram-turn-third-party-authz-03.txt > Pages : 16 > Date : 2014-09-05 >=20 > Abstract: > This document proposes the use of OAuth to obtain and validate > ephemeral tokens that can be used for TURN authentication. The usage > of ephemeral tokens ensure that access to a TURN server can be > controlled even if the tokens are compromised. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-third-party-authz= -03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri Sep 5 19:40:22 2014 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 2D6AA1A0488 for ; Fri, 5 Sep 2014 19:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 baqGmlMaYTsr for ; Fri, 5 Sep 2014 19:40:18 -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 E2E191A043D for ; Fri, 5 Sep 2014 19:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4910; q=dns/txt; s=iport; t=1409971217; x=1411180817; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cXVzK1Z9KO9+eNVGdPTvafe0swwJavCnRRDnt6FDiKY=; b=NiEXUMVJ5qf42SDWDe3XVuIM4jZKRbXps7r6I1l2FlvEZ3HWWFReamnu knF/6UR/lNnX1u+yXAGGgfxxPeAvNqEW4IujZFED/85AFQ1t2OkX4TEl5 TKi+SQvU0cMAT3dzp5vJbMowqXudz7sqipuHvmn97ydCGaqRWwkAjTh2/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAFdzClStJV2Z/2dsb2JhbABPCoMNU1cEgnjGJYdMARlrFneEAwEBAQQjEUMCDAQCAQgRBAEBAQICBh0DAgICMBQBBwEIAgQBDQUIiDoNqgOVNwEXgSyNRRcUFhsHBoJzNoEdAQSRPoQwgjuGH5NKgWceFoFGbIEIJByBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,477,1406592000"; d="scan'208";a="75476047" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 06 Sep 2014 02:40:17 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s862eHsU011368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Sep 2014 02:40:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 21:40:16 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Oleg Moskalenko Thread-Topic: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt Thread-Index: AQHPx4F++C74cYigpkyfKBx45aAoF5vv2y8AgAARVoCAAAglAIAADiMAgAARMICAACYXgIAABu6AgACGTcCAAhy0gIAAgFRg Date: Sat, 6 Sep 2014 02:40:16 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28324AE5@xmb-rcd-x10.cisco.com> References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <5407225B.5020005@akamai.com> <54074147.1000507@akamai.com> <540753F8.6020700@akamai.com> <54078257.2090206@akamai.com> <913383AAA69FF945B8F946018B75898A283228D5@xmb-rcd-x10.cisco.com> <5409BE63.10505@akamai.com> In-Reply-To: <5409BE63.10505@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/GaR7kg1THRXGkmEf1tTfebU41ZY Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 06 Sep 2014 02:40:20 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFtt YWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPiBTZW50OiBGcmlkYXksIFNlcHRl bWJlciAwNSwgMjAxNCA3OjE1IFBNDQo+IFRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkp OyBPbGVnIE1vc2thbGVua28NCj4gQ2M6IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyB0cmFt QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdHJhbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtd2luZy10cmFtLXR1cm4tDQo+IG1vYmlsaXR5LTAxLnR4dA0KPiANCj4g T24gMDkvMDQvMjAxNCAwNjozNyBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSB3cm90 ZToNCj4gPiBPbGVnIFdyb3RlOg0KPiA+DQo+ID4gSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwg Zm9yIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mDQo+ID4gdGhlIGRvY3Vt ZW50IHRvIG1ha2UgdGhlIGFyZ3VtZW50IHRoYXQgdGhlIHRva2VuIGhhcyBubyB2YWx1ZSBvZiBp dHMNCj4gPiBvd24gYW5kIHRvIGhpZ2hsaWdodCB0aGUgaW50ZXJuYWwgcmVxdWlyZW1lbnRzIG9m IHRoZSBUVVJOIHNlcnZlcg0KPiA+IGltcGxlbWVudGF0aW9uIHRoYXQgZW5zdXJlIHRoaXMgd2ls bCBiZSB0cnVlLg0KPiA+DQo+ID4gVGhlIG5vcm1hbCB1c2VyIGF1dGhlbnRpY2F0aW9uIGlzIHN0 aWxsIGluIHRoZSBwaWN0dXJlLiBTbyBpZiBhIHdyb25nDQo+ID4gdXNlciB1c2VzIHRoZSB0b2tl biB0aGF0IHdhcyBncmFudGVkIHRvIGEgZGlmZmVyZW50IGxlZ2l0aW1hdGUgdXNlciwNCj4gPiB0 aGVuIHRoZSByZXF1ZXN0IHdpbGwgYmUgcmVqZWN0ZWQgYW5kIHRoZSB3cm9uZyB1c2VyICh0aGF0 IGNhbm5vdA0KPiA+IGF1dGhlbnRpY2F0ZSBpdHNlbGYgYXMgdGhlIG9yaWdpbmFsIHVzZXIpIHdp bGwgbm90IGJlbmVmaXQgYnkgc25vb3BpbmcNCj4gPiB0aGUgdG9rZW4uIE1heSBiZSBpdCBpcyB3 b3J0aCBtZW50aW9uaW5nIGluIHRoZSBzZWN1cml0eSBzZWN0aW9uLg0KPiA+DQo+ID4gW1RSXSBJ dOKAmXMgYWxyZWFkeSBkaXNjdXNzZWQgaW4gdGhlIGRyYWZ0LiBTZWN0aW9uIDMuMi4yDQo+ID4N Cj4gPiA8c25pcD4NCj4gPg0KPiA+ICAgICBJZiB0aGUgc291cmNlIElQIGFkZHJlc3MgYW5kIHBv cnQgb2YgdGhlIFJlZnJlc2ggUmVxdWVzdCBpcw0KPiA+IGRpZmZlcmVudA0KPiA+DQo+ID4gICAg IGZyb20gdGhlIHN0b3JlZCA1LXR1cGxlIGFsbG9jYXRpb24sIHRoZSBUVVJOIHNlcnZlciBwcm9j ZWVkcyB3aXRoDQo+ID4NCj4gPiAgICAgTUVTU0FHRS1JTlRFR1JJVFkgdmFsaWRhdGlvbiB0byBp ZGVudGlmeSB0aGUgdGhhdCBpdCBpcyB0aGUgc2FtZQ0KPiA+IHVzZXINCj4gPg0KPiA+ICAgICB3 aGljaCBoYWQgcHJldmlvdXNseSBjcmVhdGVkIHRoZSBUVVJOIGFsbG9jYXRpb24uICBJZiB0aGUg YWJvdmUNCj4gPg0KPiA+ICAgICBjaGVja3MgYXJlIG5vdCBzdWNjZXNzZnVsIHRoZW4gc2VydmVy IE1VU1QgcmVqZWN0IHRoZSByZXF1ZXN0IHdpdGgNCj4gPiBhDQo+ID4NCj4gPiAgICAgNDQxIChX cm9uZyBDcmVkZW50aWFscykgZXJyb3IuDQo+ID4NCj4gPiA8L3NuaXA+DQo+IA0KPiBBZ3JlZWQu IFRoZSB2YWxpZGF0aW9uIGRlc2NyaWJlZCBoZXJlIGlzIGFkZXF1YXRlIHRvIGVuc3VyZSB0aGF0 IGEgc25vb3BlZA0KPiB0b2tlbiBpcyBub3QgdXNlZnVsIGFsbCBieSBpdHNlbGYuIFdpdGhvdXQg YSByZWZlcmVuY2UgaW4gdGhlIHNlY3VyaXR5DQo+IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24sIGl0 IGRpZG4ndCBvY2N1ciB0byBtZSB0byBnbyBiYWNrIHRocm91Z2ggdGhlIHJlc3Qgb2YNCj4gdGhl IGRvY3VtZW50IGxvb2tpbmcgZm9yIHNvbWV0aGluZyBpbnRlbmRlZCB0byBtZWV0IHRoaXMgc2Vj dXJpdHkNCj4gcmVxdWlyZW1lbnQuDQo+IA0KPiA+DQo+ID4gQnJhbmRvbiBXcm90ZToNCj4gPg0K PiA+IEkgZGlzYWdyZWUuIElmIHRoZXJlIGlzIG5vIHNvdXJjZSBvZiBlbnRyb3B5LCB0aGVuIEkg Y2FuIGxlYXJuDQo+ID4gc29tZXRoaW5nIGZyb20gdGhlIHRpY2tldCBiYXNlZCBvbiBpdHMgZW5j cnlwdGVkIGZvcm0uIEZvciBleGFtcGxlLCBpZg0KPiA+IEkgY2FuIHNlZSB0aGF0IGV2ZXJ5IGNv bm5lY3Rpb24gd2l0aCB0aGUgc2FtZSBjbGllbnQtc2lkZSB0dXBsZSBlbmRzDQo+ID4gdXAgd2l0 aCBleGFjdGx5IHRoZSBzYW1lIHRpY2tldCwgdGhlbiBJIGhhdmUgbW9zdCBsaWtlbHkgbGVhcm5l ZA0KPiA+IHNvbWV0aGluZyBhYm91dCB0aGUgdW5lbmNyeXB0ZWQgZm9ybSBvZiB0aGUgdGlja2V0 IHRoYXQgd2lsbCBoZWxwIG1lDQo+ID4gdG8gY3JhY2sgdGhlIGtleXMgdXNlZCB0byBjb25zdHJ1 Y3QgdGhlIHRpY2tldC4gSWYgdGhlIHNvdXJjZSBvZg0KPiA+IGVudHJvcHkgaXMgYnVpbHQgaW50 byB0aGUgYWxnb3JpdGhtLCB0aGVuIHlvdSdyZSByaWdodCB0aGF0IGEgZ29vZCBhbGdvcml0aG0g aXMNCj4gZ29vZCBlbm91Z2guDQo+ID4gSG93ZXZlciwgc29tZSBjb21tb24gZW5jcnlwdGlvbiBh bGdvcml0aG1zIHJlcXVpcmUgdGhlIHVzZXIgdG8gcHJvdmlkZQ0KPiA+IHN1Y2ggZW50cm9weSAo ZS5nLiB2aWEgYSByYW5kb20gaW5pdGlhbGl6YXRpb24gdmVjdG9yKS4NCj4gPg0KPiA+IFtUUl0g QWdyZWVkLiBXZSBjYW4gYWRkIGEgcmVjb21tZW5kYXRpb24gb2YgY29uc3RydWN0aW5nIHRoZSB0 b2tlbg0KPiA+IGp1c3QgbGlrZSBpdOKAmXMgZG9uZSBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM0NTA3I3NlY3Rpb24tNA0KPiANCj4gSSBnZXQgdGhlIGltcHJlc3Npb24gdGhhdCBP bGVnIHByZWZlcnMgYSBtb2JpbGl0eSB0aWNrZXQgdGhhdCBpcyBqdXN0IGEgcmFuZG9tDQo+IHN0 cmluZyBvZiBieXRlcyB3aXRob3V0IGFueSBlbmNvZGVkIG1lYW5pbmcuIEJhc2VkIG9uIHRoZSBk aXNjdXNzaW9uIGluIHRoaXMNCj4gdGhyZWFkLCBJIHRoaW5rIHRoYXQgYm90aCBhcHByb2FjaGVz IGFyZSByZWFzb25hYmxlIGFuZCB0aGF0IHRoZSBtb3N0DQo+IGltcG9ydGFudCB0aGluZyBpcyBm b3IgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gdG8gZGVzY3JpYmUgdGhlDQo+ IHByaXZhY3kgcHJvdGVjdGlvbiByZXF1aXJlbWVudC4gVGhlIHR3byBhcHByb2FjaGVzIHRvIHRv a2VuIGdlbmVyYXRpb24NCj4gY291bGQgYmUgcHJvdmlkZWQgYXMgZXhhbXBsZXMgb2YgaG93IHRv IG1lZXQgdGhlIHByaXZhY3kgcmVxdWlyZW1lbnQgaW4NCj4gb3JkZXIgdG8gaGVscCBtYWtlIGl0 IGNsZWFyLg0KDQpJIGFtIG5vdCBzdXJlIGFib3V0IHRoZSBuZWVkIGZvciB0d28gYXBwcm9hY2hl cy4gd2h5IHdvdWxkIHRoZSBUVVJOIHNlcnZlciBzdGF0ZSBiZSBzdGF0ZWxlc3MgaW4gY2FzZSBv ZiBNb2JpbGl0eSA/DQoNCi1UaXJ1DQoNCj4gDQo+IC0tQnJhbmRvbg0KPiANCj4gLS0NCj4gQnJh bmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBhbCBTb2Z0d2FyZSBFbmdpbmVlciBFbWVyZ2lu ZyBQcm9kdWN0cw0KPiBFbmdpbmVlcmluZzsgQWthbWFpIFRlY2hub2xvZ2llcyBJbmMuDQo= From nobody Fri Sep 5 19:57:23 2014 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 7211D1A05C0 for ; Fri, 5 Sep 2014 19:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 BTm8gWlenGMB for ; Fri, 5 Sep 2014 19:57:18 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31AD81A058E for ; Fri, 5 Sep 2014 19:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5516; q=dns/txt; s=iport; t=1409972238; x=1411181838; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xZAI1wVEL+VgjvkugOIcJD3grUv5hGGVluXt/jimbU0=; b=SSj5O6ZwVDEchpmX22G1swG937XyA3imV6AccY0r6BTkRYVpRVVl6WkD 4Z/Wb/JBOqyAvx6ryqQVAkUPnhXnwrDEYe16Cd8ExbOwGkvtOGgmeaa3F E5Oax9qPUicMWjs5XF783DlvHnYAF5zGugRMdDxSZf3Nd+oT4woccUTuv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FADB3ClStJV2R/2dsb2JhbABZgw1TUwQEyRMKh0wBgQQWd4QDAQEBBAEBATc0CQ4EAgEIEQQBAQEKFAkHJwsUCAEIAgQBEggBEognCAW/OAEXigCFCBQ4BoMpgR0FkT6EMIhak0qCG4FGbAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,477,1406592000"; d="scan'208";a="75475462" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP; 06 Sep 2014 02:57:16 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s862vGBF006909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Sep 2014 02:57:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 21:57:16 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "Prashanth Patil (praspati)" , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt Thread-Index: AQHPyEeMQKpkjjAt3UKrNIrAF39nT5vy8BWAgAALGoCAAG4AgA== Date: Sat, 6 Sep 2014 02:57:15 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28324B00@xmb-rcd-x10.cisco.com> References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> <5409D31F.9070003@akamai.com> In-Reply-To: <5409D31F.9070003@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/D7FjqGlXrR09bsi1O9uoE0eB-C8 Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 06 Sep 2014 02:57:22 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Friday, September 05, 2014 8:44 PM > To: Prashanth Patil (praspati); tram@ietf.org > Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn= - > mobility-01.txt >=20 > On 09/05/2014 10:33 AM, Prashanth Patil (praspati) wrote: > > > > > > On 9/4/14 7:22 PM, "Brandon Williams" > wrote: > > > >> I had one other thought on this one ... > >> > >> For a large distributed system that selects the relay server for best > >> performance, I think that support for redirection via the response to > >> the mobility refresh request is important. When the client changes > >> its IP address, this will often mean there was a significant change > >> to its network geography as well. For example, when moving from a 3G > >> address to a wifi address, continuing to use the same relay server > >> will be good for short term connection continuity, but could be > >> generally bad for call quality. Having the capability to signal that > >> the client should attempt to shift its flows to another relay would be > beneficial. > > > > Bad quality, if so, would probably be due to the new link. The host > > isn't roaming across large boundaries that a new relay server would > > provide significantly better quality. > > >=20 > Do you mean that you specifically don't expect mobility tickets to be use= d in > the case that I describe (going from a 3G address to a wifi address)? If = that's > not what you mean, then I don't understand your point. It would be quite > common for the optimal relay to change when you change service providers, > which you're probably doing when you change from 3G to wifi. This would b= e > substantially less likely to be true (though not impossible) if you're ju= st > changing 3G access points. When a mobile device roams from one eNodeB to another, Selected IP traffic = offload (SIPTO) would cause NAT to change b/w the mobile device and TURN se= rver (let's say provided by the application server). For more information o= n SIPTO refer to http://tools.ietf.org/html/draft-penno-rtcweb-pcp-00#secti= on-3.8;=20 -Tiru >=20 > --Brandon >=20 > > -Prashanth > > > > > >> > >> This capability could be handled via updated channel bind / > >> permission requests using the mechanism from the peer-redirect draft, > >> though allowing the redirect in the refresh response itself would be > >> preferable I think. > >> > >> --Brandon > >> > >> On 08/25/2014 12:43 PM, Prashanth Patil (praspati) wrote: > >>> All, > >>> We've submitted a revision of the 'Mobility with TURN' draft. The > >>> update addresses comments raised by Brandon during IETF-90 regarding > >>> TURN client and server behavior when a STUN refresh message carrying > >>> MOBILITY-TICKET attribute is lost. > >>> > >>> Comments welcome. > >>> > >>> Thanks, > >>> Prashanth > >>> > >>> > >>> On 8/25/14 6:26 PM, "internet-drafts@ietf.org" > >>> > >>> wrote: > >>> > >>>> > >>>> A new version of I-D, draft-wing-tram-turn-mobility-01.txt > >>>> has been successfully submitted by Prashanth Patil and posted to > >>>> the IETF repository. > >>>> > >>>> Name: draft-wing-tram-turn-mobility > >>>> Revision: 01 > >>>> Title: Mobility with TURN > >>>> Document date: 2014-08-25 > >>>> Group: Individual Submission > >>>> Pages: 10 > >>>> URL: > >>>> > >>>> http://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobility-0 > >>>> 1.txt > >>>> Status: > >>>> https://datatracker.ietf.org/doc/draft-wing-tram-turn-mobility/ > >>>> Htmlized: > >>>> http://tools.ietf.org/html/draft-wing-tram-turn-mobility-01 > >>>> Diff: > >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-tram-turn-mobility-01 > >>>> > >>>> Abstract: > >>>> It is desirable to minimize traffic disruption caused by changin= g IP > >>>> address during a mobility event. One mechanism to minimize > >>>> disruption is to expose a shorter network path to the mobility e= vent > >>>> so only the local network elements are aware of the changed IP > >>>> address but the remote peer is unaware of the changed IP address= . > >>>> > >>>> This draft provides such an IP address mobility solution using T= URN. > >>>> This is achieved by allowing a client to retain an allocation on= the > >>>> TURN server when the IP address of the client changes. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 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 > >>> > >> > >> -- > >> Brandon Williams; Senior Principal Software Engineer Emerging > >> Products Engineering; Akamai Technologies Inc. > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri Sep 5 20:10:57 2014 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 39B481A0B79 for ; Fri, 5 Sep 2014 20:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 NcVpyxbgvK0g for ; Fri, 5 Sep 2014 20:10:45 -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 618CB1A052E for ; Fri, 5 Sep 2014 20:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2636; q=dns/txt; s=iport; t=1409973045; x=1411182645; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Hi1JCW2d2U+4U8J9eWBBvOfwRCwURCq7XdOXzuZOGgM=; b=esuEc7gEpiIHybDd3n5zlMLp8RnJTX4b5FV3qbUGjpsMT3hepzaqsFWv OQoKkI8iiNuW1kz+HMcduHVPd62gWkdkPw4lWSudEP6c9hwwYM/6O/1UT OhxqBLPNXeYb8bRFwUJb0J/22v5gNTN2DEv+R5dGH6DNQY98rDzZYDhWp A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAHF6ClStJV2Z/2dsb2JhbABZgw1TVwTJEwqHTAGBBBZ3hAMBAQEDAQEBATctBwQFDgQCAQgRBAEBAQoUCQcnCxQIAQgCBAESCIgyCA2/NAETBI8IFDgGgymBHQEEkT6gVIIbgUZsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,477,1406592000"; d="scan'208";a="75479289" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 06 Sep 2014 03:10:44 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s863AiQV022334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Sep 2014 03:10:44 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 22:10:44 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "Prashanth Patil (praspati)" , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt Thread-Index: AQHPyEeMQKpkjjAt3UKrNIrAF39nT5vy8BWAgAALGoCAABmzAIAAHHeAgAA8IrA= Date: Sat, 6 Sep 2014 03:10:43 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28324B18@xmb-rcd-x10.cisco.com> References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> <5409D31F.9070003@akamai.com> <540A008F.10600@akamai.com> In-Reply-To: <540A008F.10600@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/jWN-15S0xfrlCtF6RIkoqCrxjeA Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 06 Sep 2014 03:10:55 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Friday, September 05, 2014 11:57 PM > To: Prashanth Patil (praspati); tram@ietf.org > Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn= - > mobility-01.txt >=20 > On 09/05/2014 12:45 PM, Prashanth Patil (praspati) wrote: > > On 9/5/14 8:43 PM, "Brandon Williams" > wrote: > [snip] > >> Do you mean that you specifically don't expect mobility tickets to be > >>used in the case that I describe (going from a 3G address to a wifi > >>address)? If that's not what you mean, then I don't understand your > >>point. It would be quite common for the optimal relay to change when > >>you change service providers, which you're probably doing when you > >>change from 3G to wifi. > > > > I could be mistaken but it seems to me that even if you changed > > service providers, the likelihood of change in quality would not be > > significant enough for a client to shift relays. Shifting relays would > > result in session re-establishment with impact on the remote peer. > > >=20 > Change in service provider can be one of the most significant factors > influencing connection quality, because the peering relationships between > providers are so important. If the peering relationships for the new prov= ider > are distinctly different than the peering relationships for the previous,= that > could be enough to make the relay server a very bad choice in some cases. 1) how will peer-redirect work in this case ? Are you assuming that the relay server provided by both the service pro= viders have some tie-up for peer-redirect to be used ? 2)If let's say the client is using application provided TURN server or thir= d party provided TURN server and the client moves from 3G to Wifi or vice-= versa.=20 Is there a need for peer-redirect in this case ? -Tiru >=20 > It could be the case that the relationship between the relay server and t= he > carrier that it's on prevents it from being used by off-network clients, = but in > that case, it should not have handed back a mobility ticket in the first = place. It > might be a good idea to point that out in the draft. That's a little bit = off the > current topic though. >=20 > --Brandon >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri Sep 5 20:16:53 2014 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 E83391A0367 for ; Fri, 5 Sep 2014 20:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 Gj0-bevxBB9p for ; Fri, 5 Sep 2014 20:16:50 -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 40BDC1A0366 for ; Fri, 5 Sep 2014 20:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1520; q=dns/txt; s=iport; t=1409973410; x=1411183010; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9fyzvF+S9WfnUDoJJG8pCZxuEII9pq1YwK8Sar7S0J0=; b=MovZ9RD2zbJ8sX8HMrYpW489LqHAQgfpcxtY0yfaxCKa0TXOJ6clf7LG ZlfeA42epu7+gV2N0nevqSboPd1wYMYaVDkFGTjt5S7o0InZXz+BRQpc3 TsPdf6AMEKvsq7Ms1dmcRIHHVA7LEpWHkUF+Ab2HqGYGKaZlhHVD5bA/B c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAIh7ClStJA2J/2dsb2JhbABagw1TVwTJEwqHTAGBBBZ3hAMBAQEEAQEBNy0HBAUOBAIBCBEEAQEBChQJBycLFAgBCAIEARIIiDoNvzQBEwSPCBQ4BoMpgR0BBJE+oFSCG4FGbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,477,1406592000"; d="scan'208";a="353058538" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP; 06 Sep 2014 03:16:49 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s863GnXN007709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Sep 2014 03:16:49 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 22:16:49 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "Prashanth Patil (praspati)" , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt Thread-Index: AQHPyEeMQKpkjjAt3UKrNIrAF39nT5vy8BWAgAALGoCAABmzAIAAHHeAgAAC0ICAADvy4A== Date: Sat, 6 Sep 2014 03:16:48 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28324B2C@xmb-rcd-x10.cisco.com> References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> <5409D31F.9070003@akamai.com> <540A008F.10600@akamai.com> <540A02EB.4060205@akamai.com> In-Reply-To: <540A02EB.4060205@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/C_jrngY3QQ1lZynq3i4reVxajLs Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 06 Sep 2014 03:16:52 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Saturday, September 06, 2014 12:08 AM > To: Prashanth Patil (praspati); tram@ietf.org > Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn= - > mobility-01.txt >=20 > On 09/05/2014 02:27 PM, Brandon Williams wrote: > > It could be the case that the relationship between the relay server > > and the carrier that it's on prevents it from being used by > > off-network clients, but in that case, it should not have handed back > > a mobility ticket in the first place. It might be a good idea to point > > that out in the draft. That's a little bit off the current topic though= . >=20 > This is just wrong. Of course it would hand out mobility tickets to suppo= rt > changing address without changing provider. Under these conditions, the > relay server should reject the mobility ticket with an error message that > clearly indicates the reason if the new client address is not believed to= be on > the same provider. In this case why would the TURN server even accept incoming packets from an= y random external endpoints and subject itself to DDOS attacks ? -Tiru >=20 > --Brandon >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri Sep 5 23:32:51 2014 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 2ADA51A6F6E for ; Fri, 5 Sep 2014 23:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 vsJjGIvy0KBM for ; Fri, 5 Sep 2014 23:32:39 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733051A6F5D for ; Fri, 5 Sep 2014 23:32:39 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id x48so12576325wes.26 for ; Fri, 05 Sep 2014 23:32:38 -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=Y64MPberjHP63vy2Qedd6lhYm6mIA7B6+DK+FVqEeAY=; b=u3BbvYxOGA7QsPP1hvPfgi1f9J/ELSZBbxVZdwOmvyuI3w52ZXC0ru0bTfD7P3R48C h0P0c4I/3X+mhnUldbOUD95mSqt9PnI50MMJqrpvnaE1qeSAJ58exlde/UdQp2B5Bzye auMB75XJthTP13EhypTNJLiB47hVaUN3IGSIXMKjo0O8GHfieiKT6nD/3CRLdWteiGRu Kw0F2yf0DbFrZVYWfx/R9wzcVWUNdfCE4id8yOx/LF7pL5hNSZl3Xrzs+6TC7+lIBc6z 7tPCJz2V0rlud7+bp3z+9ZoXHncqx3BWGgWW8/V0tKYIbgmdCd9uWnm0VYnllhSMEqqi auNA== MIME-Version: 1.0 X-Received: by 10.194.89.67 with SMTP id bm3mr20204101wjb.80.1409985158069; Fri, 05 Sep 2014 23:32:38 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Fri, 5 Sep 2014 23:32:37 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A28324AE5@xmb-rcd-x10.cisco.com> References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <5407225B.5020005@akamai.com> <54074147.1000507@akamai.com> <540753F8.6020700@akamai.com> <54078257.2090206@akamai.com> <913383AAA69FF945B8F946018B75898A283228D5@xmb-rcd-x10.cisco.com> <5409BE63.10505@akamai.com> <913383AAA69FF945B8F946018B75898A28324AE5@xmb-rcd-x10.cisco.com> Date: Fri, 5 Sep 2014 23:32:37 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=089e0102f0b27c454c05025fc08c Archived-At: http://mailarchive.ietf.org/arch/msg/tram/oaY2TJC0E5HkmljzEWTifeB8-gE Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 06 Sep 2014 06:32:50 -0000 --089e0102f0b27c454c05025fc08c Content-Type: text/plain; charset=UTF-8 On Fri, Sep 5, 2014 at 7:40 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > > -----Original Message----- > > > > > I get the impression that Oleg prefers a mobility ticket that is just a > random > > string of bytes without any encoded meaning. Based on the discussion in > this > > thread, I think that both approaches are reasonable and that the most > > important thing is for the security considerations section to describe > the > > privacy protection requirement. The two approaches to token generation > > could be provided as examples of how to meet the privacy requirement in > > order to help make it clear. > > I am not sure about the need for two approaches. why would the TURN server > state be stateless in case of Mobility ? > > -Tiru > > Let me play a devil advocate... Let's imagine a massively scalable TURN server with loosely coupled processes in one or several connected systems. Then I can imagine an implementation that encodes all necessary information in the token, encrypts it and signs it with a private key. That would be perfectly meaningful - I can see a way to implement a TURN server where a hash or map of tokens may be impossible to implement (if multiple processes are involved). I suppose that a "stateless approach" can be useful for the TURN server. I use a different (stateful) approach - but I can understand why a developer may choose different implementation pattern. Oleg --089e0102f0b27c454c05025fc08c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 5, 2014 at 7:40 PM, Tirumaleswar Reddy (tireddy) <tire= ddy@cisco.com> wrote:

> -----Original Message-----

>
> I get the impression that Oleg prefers a mobility ticket that is just = a random
> string of bytes without any encoded meaning. Based on the discussion i= n this
> thread, I think that both approaches are reasonable and that the most<= br> > important thing is for the security considerations section to describe= the
> privacy protection requirement. The two approaches to token generation=
> could be provided as examples of how to meet the privacy requirement i= n
> order to help make it clear.

I am not sure about the need for two approaches. why would the = TURN server state be stateless in case of Mobility ?

-Tiru

<= br>

Let me play a devil advocate... Let's imagine a massively= scalable TURN server with loosely coupled processes in one or several conn= ected systems. Then I can imagine an implementation that encodes all necess= ary information in the token, encrypts it and signs it with a private key. = That would be perfectly meaningful - I can see a way to implement a TURN se= rver where a hash or map of tokens may be impossible to implement (if multi= ple processes are involved). I suppose that a "stateless approach"= ; can be useful for the TURN server. I use a different (stateful) approach = - but I can understand why a developer may choose different implementation = pattern.

Oleg

--089e0102f0b27c454c05025fc08c-- From nobody Mon Sep 8 06:42:30 2014 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 242171A87F1 for ; Mon, 8 Sep 2014 06:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 nDZkWtOwo4s9 for ; Mon, 8 Sep 2014 06:42:27 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2501A87EE for ; Mon, 8 Sep 2014 06:42:27 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6F80D28568; Mon, 8 Sep 2014 13:42:24 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 521EB28592; Mon, 8 Sep 2014 13:42:24 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 4DE4280059; Mon, 8 Sep 2014 13:42:24 +0000 (GMT) Message-ID: <540DB240.8070903@akamai.com> Date: Mon, 08 Sep 2014 09:42:24 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Oleg Moskalenko , "Tirumaleswar Reddy (tireddy)" References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <5407225B.5020005@akamai.com> <54074147.1000507@akamai.com> <540753F8.6020700@akamai.com> <54078257.2090206@akamai.com> <913383AAA69FF945B8F946018B75898A283228D5@xmb-rcd-x10.cisco.com> <5409BE63.10505@akamai.com> <913383AAA69FF945B8F946018B75898A28324AE5@xmb-rcd-x10.cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/DqMHUHGlDCzjfL2fmtU7v8iuD5M Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 08 Sep 2014 13:42:29 -0000 Also, it's not entirely about whether the internal implementation is stateful or stateless. Some implementers of stateful systems may simply prefer the approach that seems to be suggested in the draft (encoding information in the ticket), while other may prefer the approach that Oleg describes (use a string of random bytes). I think the thing that's important is to make sure that the privacy requirements for what gets transmitted are clearly stated. Descriptions of specific approaches could be useful to implementers as examples of how to meet the requirements. As Oleg has written previously, it is unnecessary and undesirable for the draft to use language that appears to require one approach or another. --Brandon On 09/06/2014 02:32 AM, Oleg Moskalenko wrote: > > > > On Fri, Sep 5, 2014 at 7:40 PM, Tirumaleswar Reddy (tireddy) > > wrote: > > > -----Original Message----- > > > > > I get the impression that Oleg prefers a mobility ticket that is > just a random > > string of bytes without any encoded meaning. Based on the > discussion in this > > thread, I think that both approaches are reasonable and that the most > > important thing is for the security considerations section to > describe the > > privacy protection requirement. The two approaches to token > generation > > could be provided as examples of how to meet the privacy > requirement in > > order to help make it clear. > > I am not sure about the need for two approaches. why would the TURN > server state be stateless in case of Mobility ? > > -Tiru > > > Let me play a devil advocate... Let's imagine a massively scalable TURN > server with loosely coupled processes in one or several connected > systems. Then I can imagine an implementation that encodes all necessary > information in the token, encrypts it and signs it with a private key. > That would be perfectly meaningful - I can see a way to implement a TURN > server where a hash or map of tokens may be impossible to implement (if > multiple processes are involved). I suppose that a "stateless approach" > can be useful for the TURN server. I use a different (stateful) approach > - but I can understand why a developer may choose different > implementation pattern. > > Oleg > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Sep 8 06:51:51 2014 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 46F751A8835 for ; Mon, 8 Sep 2014 06:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 LWCcMKRzLyG2 for ; Mon, 8 Sep 2014 06:51:48 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id DFDDC1A8820 for ; Mon, 8 Sep 2014 06:51:47 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 47F6B28556; Mon, 8 Sep 2014 13:51:47 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 3029E284E6; Mon, 8 Sep 2014 13:51:47 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 2D40180040; Mon, 8 Sep 2014 13:51:47 +0000 (GMT) Message-ID: <540DB473.3060208@akamai.com> Date: Mon, 08 Sep 2014 09:51:47 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "Prashanth Patil (praspati)" , "tram@ietf.org" References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> <5409D31F.9070003@akamai.com> <913383AAA69FF945B8F946018B75898A28324B00@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A28324B00@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/NOM5dVaA4-Xh0blRafczwJpjC4c Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 08 Sep 2014 13:51:50 -0000 On 09/05/2014 10:57 PM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Friday, September 05, 2014 8:44 PM >> To: Prashanth Patil (praspati); tram@ietf.org >> Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn- >> mobility-01.txt >> >> On 09/05/2014 10:33 AM, Prashanth Patil (praspati) wrote: >>> >>> >>> On 9/4/14 7:22 PM, "Brandon Williams" >> wrote: >>> >>>> I had one other thought on this one ... >>>> >>>> For a large distributed system that selects the relay server for best >>>> performance, I think that support for redirection via the response to >>>> the mobility refresh request is important. When the client changes >>>> its IP address, this will often mean there was a significant change >>>> to its network geography as well. For example, when moving from a 3G >>>> address to a wifi address, continuing to use the same relay server >>>> will be good for short term connection continuity, but could be >>>> generally bad for call quality. Having the capability to signal that >>>> the client should attempt to shift its flows to another relay would be >> beneficial. >>> >>> Bad quality, if so, would probably be due to the new link. The host >>> isn't roaming across large boundaries that a new relay server would >>> provide significantly better quality. >>> >> >> Do you mean that you specifically don't expect mobility tickets to be used in >> the case that I describe (going from a 3G address to a wifi address)? If that's >> not what you mean, then I don't understand your point. It would be quite >> common for the optimal relay to change when you change service providers, >> which you're probably doing when you change from 3G to wifi. This would be >> substantially less likely to be true (though not impossible) if you're just >> changing 3G access points. > > When a mobile device roams from one eNodeB to another, Selected IP traffic offload (SIPTO) would cause NAT to change b/w the mobile device and TURN server (let's say provided by the application server). For more information on SIPTO refer to http://tools.ietf.org/html/draft-penno-rtcweb-pcp-00#section-3.8; I'm not entirely certain what you're point is here. What my comment was meant to indicate is that changing 3G access points is unlikely to mean that the optimal relay server changes, even when the public IP address for the device changes. If you also change service providers when you change access points, then the likelihood of a change to the optimal relay server goes up substantially. --Brandon > > -Tiru > >> >> --Brandon >> >>> -Prashanth >>> >>> >>>> >>>> This capability could be handled via updated channel bind / >>>> permission requests using the mechanism from the peer-redirect draft, >>>> though allowing the redirect in the refresh response itself would be >>>> preferable I think. >>>> >>>> --Brandon >>>> >>>> On 08/25/2014 12:43 PM, Prashanth Patil (praspati) wrote: >>>>> All, >>>>> We've submitted a revision of the 'Mobility with TURN' draft. The >>>>> update addresses comments raised by Brandon during IETF-90 regarding >>>>> TURN client and server behavior when a STUN refresh message carrying >>>>> MOBILITY-TICKET attribute is lost. >>>>> >>>>> Comments welcome. >>>>> >>>>> Thanks, >>>>> Prashanth >>>>> >>>>> >>>>> On 8/25/14 6:26 PM, "internet-drafts@ietf.org" >>>>> >>>>> wrote: >>>>> >>>>>> >>>>>> A new version of I-D, draft-wing-tram-turn-mobility-01.txt >>>>>> has been successfully submitted by Prashanth Patil and posted to >>>>>> the IETF repository. >>>>>> >>>>>> Name: draft-wing-tram-turn-mobility >>>>>> Revision: 01 >>>>>> Title: Mobility with TURN >>>>>> Document date: 2014-08-25 >>>>>> Group: Individual Submission >>>>>> Pages: 10 >>>>>> URL: >>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobility-0 >>>>>> 1.txt >>>>>> Status: >>>>>> https://datatracker.ietf.org/doc/draft-wing-tram-turn-mobility/ >>>>>> Htmlized: >>>>>> http://tools.ietf.org/html/draft-wing-tram-turn-mobility-01 >>>>>> Diff: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-wing-tram-turn-mobility-01 >>>>>> >>>>>> Abstract: >>>>>> It is desirable to minimize traffic disruption caused by changing IP >>>>>> address during a mobility event. One mechanism to minimize >>>>>> disruption is to expose a shorter network path to the mobility event >>>>>> so only the local network elements are aware of the changed IP >>>>>> address but the remote peer is unaware of the changed IP address. >>>>>> >>>>>> This draft provides such an IP address mobility solution using TURN. >>>>>> This is achieved by allowing a client to retain an allocation on the >>>>>> TURN server when the IP address of the client changes. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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 >>>>> >>>> >>>> -- >>>> Brandon Williams; Senior Principal Software Engineer Emerging >>>> Products Engineering; Akamai Technologies Inc. >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>> >> >> -- >> Brandon Williams; Senior Principal Software Engineer Emerging Products >> Engineering; Akamai Technologies Inc. >> >> _______________________________________________ >> 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 > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Sep 8 07:05:25 2014 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 95DE81A882E for ; Mon, 8 Sep 2014 07:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652] 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 glhUZOQaiw07 for ; Mon, 8 Sep 2014 07:05:03 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 4211C1A87EC for ; Mon, 8 Sep 2014 07:05:03 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6ADBB47550; Mon, 8 Sep 2014 14:05:01 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5596647577; Mon, 8 Sep 2014 14:05:01 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 4EC86202E; Mon, 8 Sep 2014 14:05:01 +0000 (GMT) Message-ID: <540DB78D.8070906@akamai.com> Date: Mon, 08 Sep 2014 10:05:01 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "Prashanth Patil (praspati)" , "tram@ietf.org" References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> <5409D31F.9070003@akamai.com> <540A008F.10600@akamai.com> <913383AAA69FF945B8F946018B75898A28324B18@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A28324B18@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/WYG-YoL5cHNttZKwVimwHbK-YTA Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 08 Sep 2014 14:05:11 -0000 On 09/05/2014 11:10 PM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Friday, September 05, 2014 11:57 PM >> To: Prashanth Patil (praspati); tram@ietf.org >> Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn- >> mobility-01.txt >> >> On 09/05/2014 12:45 PM, Prashanth Patil (praspati) wrote: >>> On 9/5/14 8:43 PM, "Brandon Williams" >> wrote: >> [snip] >>>> Do you mean that you specifically don't expect mobility tickets to be >>>> used in the case that I describe (going from a 3G address to a wifi >>>> address)? If that's not what you mean, then I don't understand your >>>> point. It would be quite common for the optimal relay to change when >>>> you change service providers, which you're probably doing when you >>>> change from 3G to wifi. >>> >>> I could be mistaken but it seems to me that even if you changed >>> service providers, the likelihood of change in quality would not be >>> significant enough for a client to shift relays. Shifting relays would >>> result in session re-establishment with impact on the remote peer. >>> >> >> Change in service provider can be one of the most significant factors >> influencing connection quality, because the peering relationships between >> providers are so important. If the peering relationships for the new provider >> are distinctly different than the peering relationships for the previous, that >> could be enough to make the relay server a very bad choice in some cases. > > 1) how will peer-redirect work in this case ? > Are you assuming that the relay server provided by both the service providers have some tie-up for peer-redirect to be used ? Performance-based redirection (or really any use of try-alternate) assumes that the relay servers have some sort of tie-up, even though it might be quite loose. The one sending try-alternate has to have some way to know what the reasonable candidates are. That said, I'm not suggesting peer-redirect via a channelbind/permission response. I'm suggesting redirection via the refresh response. It would work something like this: * Client changes IP address and sends refresh with mobility ticket. * Relay sends refresh response with new mobility ticket and alternate server attribute. * Client continues to use relay with established session while at the same time setting up a new allocation and channel via the provided alternate server. * After the new allocation and channel are set up, the client can shift the flow to the new relay. It's pretty similar to the peer redirect case, except that it would potentially impact all existing p2p flows. > 2)If let's say the client is using application provided TURN server or third party provided TURN server and the client moves from 3G to Wifi or vice-versa. > Is there a need for peer-redirect in this case ? Do you mean there would be a case where the client uses an app provided relay when on 3G and a 3rd party relay when on wifi (or vice versa)? If that's the case, then mobility tickets wouldn't be used anyway, right? --Brandon > > -Tiru > >> >> It could be the case that the relationship between the relay server and the >> carrier that it's on prevents it from being used by off-network clients, but in >> that case, it should not have handed back a mobility ticket in the first place. It >> might be a good idea to point that out in the draft. That's a little bit off the >> current topic though. >> >> --Brandon >> >> -- >> Brandon Williams; Senior Principal Software Engineer Emerging Products >> Engineering; Akamai Technologies Inc. >> >> _______________________________________________ >> 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 > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Sep 8 07:10:57 2014 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 915941A8828 for ; Mon, 8 Sep 2014 07:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652] 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 dc4qcDTDidfJ for ; Mon, 8 Sep 2014 07:10:54 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1281A87EC for ; Mon, 8 Sep 2014 07:10:54 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CE8E94756F; Mon, 8 Sep 2014 14:10:53 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C0D4B4756E; Mon, 8 Sep 2014 14:10:53 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id BB320202E; Mon, 8 Sep 2014 14:10:53 +0000 (GMT) Message-ID: <540DB8ED.40000@akamai.com> Date: Mon, 08 Sep 2014 10:10:53 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "Prashanth Patil (praspati)" , "tram@ietf.org" References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> <54086EB6.5060002@akamai.com> <5409D31F.9070003@akamai.com> <540A008F.10600@akamai.com> <540A02EB.4060205@akamai.com> <913383AAA69FF945B8F946018B75898A28324B2C@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A28324B2C@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/JOWoTFhJmezYiaW4oVmUxecqcLI Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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, 08 Sep 2014 14:10:56 -0000 On 09/05/2014 11:16 PM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Saturday, September 06, 2014 12:08 AM >> To: Prashanth Patil (praspati); tram@ietf.org >> Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn- >> mobility-01.txt >> >> On 09/05/2014 02:27 PM, Brandon Williams wrote: >>> It could be the case that the relationship between the relay server >>> and the carrier that it's on prevents it from being used by >>> off-network clients, but in that case, it should not have handed back >>> a mobility ticket in the first place. It might be a good idea to point >>> that out in the draft. That's a little bit off the current topic though. >> >> This is just wrong. Of course it would hand out mobility tickets to support >> changing address without changing provider. Under these conditions, the >> relay server should reject the mobility ticket with an error message that >> clearly indicates the reason if the new client address is not believed to be on >> the same provider. > > In this case why would the TURN server even accept incoming packets from any random external endpoints and subject itself to DDOS attacks ? There are a variety of ways to handle the security here. Blocking early is great in an attack mitigation case, but for legitimate mobility cases, it's better for the relay to signal a useful error to the client. I think it's important to recognize the possible need for a try-alternate error with an alternate-server attribute. This could be preferable to just dropping the packets and requiring some timeout to expire for the refresh request. On the other hand, it's quite possible that the flow would be disrupted enough in either case to drive session termination. --Brandon > > -Tiru > >> >> --Brandon >> >> -- >> Brandon Williams; Senior Principal Software Engineer Emerging Products >> Engineering; Akamai Technologies Inc. >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Sep 8 08:28:13 2014 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 1BDCA1A8875 for ; Mon, 8 Sep 2014 08:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 7KGpg0e80hYU for ; Mon, 8 Sep 2014 08:28:09 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7287D1A8873 for ; Mon, 8 Sep 2014 08:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14448; q=dns/txt; s=iport; t=1410190090; x=1411399690; h=from:to:cc:subject:date:message-id:mime-version; bh=94c4NaSXxV6RBlvfqhSXM8JEY/4fP5J6ES1ATKr9hTg=; b=euVlyACosb3L5YXEDq7yjuBYCek1qUU0RJYJMO6Nby0cFtm8PAXn8z0b TLMIpgIg7T6V4ohLTQ4e4e/KFdEW9hZ8ts2dUmNPXwz5UtXuUOLPt7XgK ueZJ4rlqJ18pOj+ep4f0SAlp/oxyCplqKRH6sDZhlzqCy6rzac1ejo+/y s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFANvJDVStJA2M/2dsb2JhbABZgkdGU1cEgnjORAEZeRZ4hAMBAQEDASMKSgIMBgEIDgMEAQEBCh0DAgQfERQIAQkBBA4FCIgmAwkIpiCOSw2GXAEXjSCBaBQWGwYHgnM2gR0FkUCGbII2kQOGOYFnAhwWgUZsgUiBBwEBAQ X-IronPort-AV: E=Sophos; i="5.04,486,1406592000"; d="scan'208,217"; a="75963766" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP; 08 Sep 2014 15:28:09 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s88FS8NM029530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Sep 2014 15:28:08 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Mon, 8 Sep 2014 10:28:08 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt Thread-Index: Ac/LeXP8BSfeL6AaSm6XypY/QmX0qA== Date: Mon, 8 Sep 2014 15:28:07 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28325588@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.62.48] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A28325588xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/u0FtCt6EUlZydwRFBxKwf8hbPm8 Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.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:

--089e0118451ef5faf90503655f9b-- From nobody Fri Sep 19 00:21:39 2014 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 6B5471A8F3B for ; Fri, 19 Sep 2014 00:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=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 Il6T9nPpytdb for ; Fri, 19 Sep 2014 00:21:35 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CAA41A8F39 for ; Fri, 19 Sep 2014 00:21:35 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id k14so1984791wgh.24 for ; Fri, 19 Sep 2014 00:21:33 -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=nl25qt4Rm1IKYNqM/aXzUPFLY9AzcCojJEOW8JdQiW0=; b=n/ZhKakXjz8TCEFqDzjF4ESJWD00XwxTuaHK/6b9jbSutgve6z16fJSEsljLZat/sH fmVc3gKJ66qGXoSybV98K6xafuZ4oOD6q2h7jAq3xShyFRkpyRS89vrdobjWp6piKsVj 3jP/58WjEs31JiaVwC43FAYlAVAxa/fS+aIzMsVe766Wf92lK5w2DZFwzzrZFEYGuJ94 PDl8L57A9Hbe18FcFJTAW30DDnxBkxTMX37vTfgIXsR6pUYYroes/kTgsrPhLoAMZZGY w0klyED/GAXKONVWkQpV/SZ+kMkzbA7ijUu86RIa9DBwogdc5q+zvXw8ZcxcWLenTj2U AzPQ== MIME-Version: 1.0 X-Received: by 10.194.5.234 with SMTP id v10mr10248752wjv.45.1411111293839; Fri, 19 Sep 2014 00:21:33 -0700 (PDT) Received: by 10.194.67.167 with HTTP; Fri, 19 Sep 2014 00:21:33 -0700 (PDT) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A28328E81@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A28328F3F@xmb-rcd-x10.cisco.com>

Date: Fri, 19 Sep 2014 00:21:33 -0700 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b5d2fde6870db050365f368 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/TGd99IIT1ZtM5FOOGMFjzglWVv4 Cc: "Dan Wing \(dwing\)" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-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, 19 Sep 2014 07:21:37 -0000 --047d7b5d2fde6870db050365f368 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Actually, my comments about NONCE and REALM are invalid, those attributes must be used in oAuth in the same way as in usual long-term credentials. Scratch that. Thanks Oleg On Thu, Sep 18, 2014 at 11:40 PM, Oleg Moskalenko wrote: > One more comment, about the section 3. > > 1) It would be better to say in the text (or show it on the Figure 1), > explicitly, that the error code of the "Allocate error response" is 401. = We > are including the THIRD-PARTY-AUTHORIZATION attrbute only in the "challen= ge > response", not in any error responses. > 2) In the challenge response, we have to mention that we are still > including the NONCE and REALM parameters, in the case if the client does > not supports oAuth. And we have to mention that if the client does suppor= t > oAuth, then the client has to ignore those attributes. > > Thanks > Oleg > > > On Thu, Sep 18, 2014 at 11:08 PM, Oleg Moskalenko > wrote: > >> I have another comment, on Section 6.2. >> >> I do not think that the ACCESS-TOKEN must be a comprehension-optional >> attribute. The optional attributes are used when the message recipient m= ay >> be of a limited functionality (like in backward compatibility cases or >> minimal clients or minimal servers). There are two reasons why the optio= nal >> attribute does not fit well here in the dialog: >> >> 1) When the client sends the request with ACCESS-TOKEN, the server >> already made a commitment that the server understands the oAuth credenti= als >> (by sending the THIRD-PARTY-AUTHORIZATION attribute). So the server may = not >> be a legacy server. >> 2) The message cannot be handled properly if the server does not >> understands the ACCESS-TOKEN - because the KID is not a valid username, >> anyway, and the server does not know the mac even if somehow miraculousl= y >> the server had a username with KID as the value. >> >> If there are valid reasons why the ACCESS-TOKEN is a >> comprehension-optional attribute, I'd like to hear them. >> >> Thanks ! >> Oleg >> >> >> >> On Tue, Sep 16, 2014 at 3:21 PM, Oleg Moskalenko >> wrote: >> >>> I'd also suggest to create an Appendix, with the content similar to RFC >>> 5769, with ticket encoding/decoding sample examples. That would benefit >>> both client and server implementations, to avoid ambiguity and >>> misunderstandings. >>> >>> Thanks >>> Oleg >>> >>> >>> On Mon, Sep 15, 2014 at 5:26 AM, Simon Perreault >>> wrote: >>> >>>> >>>> On Mon, Sep 15, 2014 at 6:34 AM, Tirumaleswar Reddy (tireddy) < >>>> tireddy@cisco.com> wrote: >>>> >>>>> Second, even with unknown nonce, knowing the exact nonce field >>>>> positions, the client still can try the same attack - the client will= just >>>>> ignore the nonce positions, and the client will obtain the same attac= k >>>>> result as without the nonce (with very high degree of probability). I= f the >>>>> client finds a key that decrypts properly all positions except the no= nce, >>>>> then the client can be almost sure that he found the real long-term k= ey. >>>>> >>>>> >>>>> >>>>> [TR] Yup, the client will have to try all possible key combinations (= 2 >>>>> to the power 256 key combinations which takes very very long time) an= d >>>>> check if the decrypted token matches the plain token. Looks like we d= on=E2=80=99t >>>>> have to address this attack. >>>>> http://en.wikipedia.org/wiki/Talk%3ASalt_%28cryptography%29 mentions >>>>> that =E2=80=9Cmodern ciphers such as Advanced Encryption Standard are= not >>>>> susceptible to known-plaintext attacks=E2=80=9D. >>>>> >>>> >>>> Whatever you decide, please mention it in the Security Considerations >>>> section, and explain why you think your decision makes sense. >>>> >>>> Thanks, >>>> Simon >>>> >>> >>> >> > --047d7b5d2fde6870db050365f368 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Actually, my comments about NONCE and REALM are invalid, t= hose attributes must be used in oAuth in the same way as in usual long-term= credentials. Scratch that.

Thanks
Oleg

On Thu, Sep 18, 2014 at 11:40 PM,= Oleg Moskalenko <mom040267@gmail.com> wrote:

One more comment, abo= ut the section 3.

1) It would be better to say in the text (or= show it on the Figure 1), explicitly, that the error code of the "All= ocate error response" is 401. We are including the THIRD-PARTY-AUTHORI= ZATION attrbute only in the "challenge response", not in any erro= r responses.

2) In the challenge response, we have to mention that= we are still including the NONCE and REALM parameters, in the case if the = client does not supports oAuth. And we have to mention that if the client d= oes support oAuth, then the client has to ignore those attributes.

<= /div>Thanks
Oleg

<= /font>

On Thu, Sep 18, 2014 at 11:08 PM,= Oleg Moskalenko <mom040267@gmail.com> wrote:

I have another c= omment, on Section 6.2.

I do not think that the ACCESS-TOKEN m= ust be a comprehension-optional attribute. The optional attributes are used= when the message recipient may be of a limited functionality (like in back= ward compatibility cases or minimal clients or minimal servers). There are = two reasons why the optional attribute does not fit well here in the dialog= :

1) When the client sends the request with ACCESS-TOKEN, the server= already made a commitment that the server understands the oAuth credential= s (by sending the THIRD-PARTY-AUTHORIZATION attribute). So the server may n= ot be a legacy server.

2) The message cannot be handled properly i= f the server does not understands the ACCESS-TOKEN - because the KID is not= a valid username, anyway, and the server does not know the mac even if som= ehow miraculously the server had a username with KID as the value.

=

If there are valid reasons why the ACCESS-TOKEN is a comprehension-op= tional attribute, I'd like to hear them.

Thanks !
Oleg

On Tue, Sep 16, 2014 at 3:21 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:

I'd also suggest to create an Appendix, with the content similar to R= FC 5769, with ticket encoding/decoding sample examples. That would benefit = both client and server implementations, to avoid ambiguity and misunderstan= dings.

Thanks
Oleg
=C2=A0<= br>

On Mon, Sep 15, 2014 at 5:26 AM, Simon Perreault <sperr= eault@jive.com> wrote:

On Mon, Sep 15, 2014 at 6:34 AM, Tirumaleswar Reddy (tireddy) <tireddy= @cisco.com> wrote:
Second, even with unknown nonce, knowing the exact non= ce field positions, the client still can try the same attack - the client w= ill just ignore the nonce positions, and the client will obtain the same at= tack result as without the nonce (with very high degree of probability). If the client finds a key that dec= rypts properly all positions except the nonce, then the client can be almos= t sure that he found the real long-term key.

=C2=A0

[TR] Yup, the clie= nt will have to try all possible key combinations (2 to the power 256 key c= ombinations which takes very very long time) and check if the decrypted token matches the plain token. Looks like we don=E2=80=99t have to address= this attack. http://en.wikipedia.org/wiki/Talk%3ASalt_%28cr= yptography%29 mentions that =E2=80=9Cmodern ciphers such as Advanced En= cryption Standard are not susceptible to known-plaintext attacks=E2=80=9D.<= /span>

Whatever you decide, please mention= it in the Security Considerations section, and explain why you think your = decision makes sense.

Thanks,
Simon

--047d7b5d2fde6870db050365f368-- From nobody Fri Sep 19 01:46:49 2014 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 6D8661A0043 for ; Fri, 19 Sep 2014 01:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 zz0W3TUJzLmM for ; Fri, 19 Sep 2014 01:46:46 -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 155E41A000A for ; Fri, 19 Sep 2014 01:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15938; q=dns/txt; s=iport; t=1411116406; x=1412326006; h=from:to:cc:subject:date:message-id:mime-version; bh=8HYFyOROTG+FZ7RQkag1Tk6ReHTSYFY5V3gMTkiNg1Y=; b=DyPRoo5VB3DWyQRDqVH8XDxDMU39hhLJaaF/VVtgnuozHXIpeAezjLSZ l2lUvNVrTNEUKbW/zFexqvSwFvj4DBC2ITKKRcRowxdd31J1a2jIdAIJ+ VYUizdgABl3HPJ2ZUB6x59Nbsj5D2UxCP3B8HQ3Qh7z56yHc8pOoxsAox 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAB/tG1StJV2d/2dsb2JhbABggkdGU1cEgn3EdIFrh00BGWoWAXmEAwEBAQQjCkwSAQgOAwQBAQsdAwIEHxEUCQkBBAENBQiIIgMRDawMjwUNhy4BF41KgVUKCRQWGwYHgnI2gR0FkU6EN4R3kRaGQoNebIEGQoECAQEB X-IronPort-AV: E=Sophos; i="5.04,553,1406592000"; d="scan'208,217"; a="79321829" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP; 19 Sep 2014 08:46:45 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8J8kjo0023770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 08:46:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 03:46:44 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , Simon Perreault Thread-Topic: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03 Thread-Index: Ac/T5jovcMhQzGe4R/qpDldM86PXwA== Date: Fri, 19 Sep 2014 08:46:44 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2832BE86@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.39.66.1] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2832BE86xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/s-CWUuM1m1ki8vkMYR2vpuynx-Q Cc: "tram@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-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, 19 Sep 2014 08:46:48 -0000 --_000_913383AAA69FF945B8F946018B75898A2832BE86xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgT2xlZywNCg0KR29vZCBjYXRjaCwgY2hhbmdlZCBBQ0VTU19UT0tFTiB0byBjb21wcmVoZW5z aW9uLXJlcXVpcmVkIGF0dHJpYnV0ZS4NCg0KQ2hlZXJzLA0KLVRpcnUNCg0KRnJvbTogT2xlZyBN b3NrYWxlbmtvIFttYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbV0NClNlbnQ6IEZyaWRheSwgU2Vw dGVtYmVyIDE5LCAyMDE0IDExOjM5IEFNDQpUbzogU2ltb24gUGVycmVhdWx0DQpDYzogVGlydW1h bGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgdHJhbUBpZXRmLm9yZzsgRGFuIFdpbmcgKGR3aW5nKQ0K U3ViamVjdDogUmU6IFt0cmFtXSBXR0xDIGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5 LWF1dGh6LTAzDQoNCkkgaGF2ZSBhbm90aGVyIGNvbW1lbnQsIG9uIFNlY3Rpb24gNi4yLg0KSSBk byBub3QgdGhpbmsgdGhhdCB0aGUgQUNDRVNTLVRPS0VOIG11c3QgYmUgYSBjb21wcmVoZW5zaW9u LW9wdGlvbmFsIGF0dHJpYnV0ZS4gVGhlIG9wdGlvbmFsIGF0dHJpYnV0ZXMgYXJlIHVzZWQgd2hl biB0aGUgbWVzc2FnZSByZWNpcGllbnQgbWF5IGJlIG9mIGEgbGltaXRlZCBmdW5jdGlvbmFsaXR5 IChsaWtlIGluIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgY2FzZXMgb3IgbWluaW1hbCBjbGllbnRz IG9yIG1pbmltYWwgc2VydmVycykuIFRoZXJlIGFyZSB0d28gcmVhc29ucyB3aHkgdGhlIG9wdGlv bmFsIGF0dHJpYnV0ZSBkb2VzIG5vdCBmaXQgd2VsbCBoZXJlIGluIHRoZSBkaWFsb2c6DQoNCjEp IFdoZW4gdGhlIGNsaWVudCBzZW5kcyB0aGUgcmVxdWVzdCB3aXRoIEFDQ0VTUy1UT0tFTiwgdGhl IHNlcnZlciBhbHJlYWR5IG1hZGUgYSBjb21taXRtZW50IHRoYXQgdGhlIHNlcnZlciB1bmRlcnN0 YW5kcyB0aGUgb0F1dGggY3JlZGVudGlhbHMgKGJ5IHNlbmRpbmcgdGhlIFRISVJELVBBUlRZLUFV VEhPUklaQVRJT04gYXR0cmlidXRlKS4gU28gdGhlIHNlcnZlciBtYXkgbm90IGJlIGEgbGVnYWN5 IHNlcnZlci4NCjIpIFRoZSBtZXNzYWdlIGNhbm5vdCBiZSBoYW5kbGVkIHByb3Blcmx5IGlmIHRo ZSBzZXJ2ZXIgZG9lcyBub3QgdW5kZXJzdGFuZHMgdGhlIEFDQ0VTUy1UT0tFTiAtIGJlY2F1c2Ug dGhlIEtJRCBpcyBub3QgYSB2YWxpZCB1c2VybmFtZSwgYW55d2F5LCBhbmQgdGhlIHNlcnZlciBk b2VzIG5vdCBrbm93IHRoZSBtYWMgZXZlbiBpZiBzb21laG93IG1pcmFjdWxvdXNseSB0aGUgc2Vy dmVyIGhhZCBhIHVzZXJuYW1lIHdpdGggS0lEIGFzIHRoZSB2YWx1ZS4NCklmIHRoZXJlIGFyZSB2 YWxpZCByZWFzb25zIHdoeSB0aGUgQUNDRVNTLVRPS0VOIGlzIGEgY29tcHJlaGVuc2lvbi1vcHRp b25hbCBhdHRyaWJ1dGUsIEknZCBsaWtlIHRvIGhlYXIgdGhlbS4NClRoYW5rcyAhDQpPbGVnDQoN Cg0KT24gVHVlLCBTZXAgMTYsIDIwMTQgYXQgMzoyMSBQTSwgT2xlZyBNb3NrYWxlbmtvIDxtb20w NDAyNjdAZ21haWwuY29tPG1haWx0bzptb20wNDAyNjdAZ21haWwuY29tPj4gd3JvdGU6DQpJJ2Qg YWxzbyBzdWdnZXN0IHRvIGNyZWF0ZSBhbiBBcHBlbmRpeCwgd2l0aCB0aGUgY29udGVudCBzaW1p bGFyIHRvIFJGQyA1NzY5LCB3aXRoIHRpY2tldCBlbmNvZGluZy9kZWNvZGluZyBzYW1wbGUgZXhh bXBsZXMuIFRoYXQgd291bGQgYmVuZWZpdCBib3RoIGNsaWVudCBhbmQgc2VydmVyIGltcGxlbWVu dGF0aW9ucywgdG8gYXZvaWQgYW1iaWd1aXR5IGFuZCBtaXN1bmRlcnN0YW5kaW5ncy4NClRoYW5r cw0KT2xlZw0KDQoNCk9uIE1vbiwgU2VwIDE1LCAyMDE0IGF0IDU6MjYgQU0sIFNpbW9uIFBlcnJl YXVsdCA8c3BlcnJlYXVsdEBqaXZlLmNvbTxtYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbT4+IHdy b3RlOg0KDQpPbiBNb24sIFNlcCAxNSwgMjAxNCBhdCA2OjM0IEFNLCBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpIDx0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+ PiB3cm90ZToNClNlY29uZCwgZXZlbiB3aXRoIHVua25vd24gbm9uY2UsIGtub3dpbmcgdGhlIGV4 YWN0IG5vbmNlIGZpZWxkIHBvc2l0aW9ucywgdGhlIGNsaWVudCBzdGlsbCBjYW4gdHJ5IHRoZSBz YW1lIGF0dGFjayAtIHRoZSBjbGllbnQgd2lsbCBqdXN0IGlnbm9yZSB0aGUgbm9uY2UgcG9zaXRp b25zLCBhbmQgdGhlIGNsaWVudCB3aWxsIG9idGFpbiB0aGUgc2FtZSBhdHRhY2sgcmVzdWx0IGFz IHdpdGhvdXQgdGhlIG5vbmNlICh3aXRoIHZlcnkgaGlnaCBkZWdyZWUgb2YgcHJvYmFiaWxpdHkp LiBJZiB0aGUgY2xpZW50IGZpbmRzIGEga2V5IHRoYXQgZGVjcnlwdHMgcHJvcGVybHkgYWxsIHBv c2l0aW9ucyBleGNlcHQgdGhlIG5vbmNlLCB0aGVuIHRoZSBjbGllbnQgY2FuIGJlIGFsbW9zdCBz dXJlIHRoYXQgaGUgZm91bmQgdGhlIHJlYWwgbG9uZy10ZXJtIGtleS4NCg0KW1RSXSBZdXAsIHRo ZSBjbGllbnQgd2lsbCBoYXZlIHRvIHRyeSBhbGwgcG9zc2libGUga2V5IGNvbWJpbmF0aW9ucyAo MiB0byB0aGUgcG93ZXIgMjU2IGtleSBjb21iaW5hdGlvbnMgd2hpY2ggdGFrZXMgdmVyeSB2ZXJ5 IGxvbmcgdGltZSkgYW5kIGNoZWNrIGlmIHRoZSBkZWNyeXB0ZWQgdG9rZW4gbWF0Y2hlcyB0aGUg cGxhaW4gdG9rZW4uIExvb2tzIGxpa2Ugd2UgZG9u4oCZdCBoYXZlIHRvIGFkZHJlc3MgdGhpcyBh dHRhY2suIGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvVGFsayUzQVNhbHRfJTI4Y3J5cHRv Z3JhcGh5JTI5IG1lbnRpb25zIHRoYXQg4oCcbW9kZXJuIGNpcGhlcnMgc3VjaCBhcyBBZHZhbmNl ZCBFbmNyeXB0aW9uIFN0YW5kYXJkIGFyZSBub3Qgc3VzY2VwdGlibGUgdG8ga25vd24tcGxhaW50 ZXh0IGF0dGFja3PigJ0uDQoNCldoYXRldmVyIHlvdSBkZWNpZGUsIHBsZWFzZSBtZW50aW9uIGl0 IGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBhbmQgZXhwbGFpbiB3aHkg eW91IHRoaW5rIHlvdXIgZGVjaXNpb24gbWFrZXMgc2Vuc2UuDQoNClRoYW5rcywNClNpbW9uDQoN Cg0K --_000_913383AAA69FF945B8F946018B75898A2832BE86xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgT2xlZyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkdvb2QgY2F0Y2gsIGNoYW5nZWQgQUNFU1NfVE9LRU4gdG8gY29tcHJlaGVuc2lvbi1y ZXF1aXJlZCBhdHRyaWJ1dGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IE9sZWcgTW9za2FsZW5rbyBbbWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBTZXB0ZW1iZXIgMTksIDIwMTQgMTE6MzkgQU08YnI+DQo8Yj5U bzo8L2I+IFNpbW9uIFBlcnJlYXVsdDxicj4NCjxiPkNjOjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5 ICh0aXJlZGR5KTsgdHJhbUBpZXRmLm9yZzsgRGFuIFdpbmcgKGR3aW5nKTxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW3RyYW1dIFdHTEMgZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHkt YXV0aHotMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+SSBoYXZlIGFub3RoZXIgY29tbWVudCwgb24gU2VjdGlvbiA2LjIuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gbm90IHRoaW5rIHRoYXQgdGhl IEFDQ0VTUy1UT0tFTiBtdXN0IGJlIGEgY29tcHJlaGVuc2lvbi1vcHRpb25hbCBhdHRyaWJ1dGUu IFRoZSBvcHRpb25hbCBhdHRyaWJ1dGVzIGFyZSB1c2VkIHdoZW4gdGhlIG1lc3NhZ2UgcmVjaXBp ZW50IG1heSBiZSBvZiBhIGxpbWl0ZWQgZnVuY3Rpb25hbGl0eSAobGlrZSBpbiBiYWNrd2FyZCBj b21wYXRpYmlsaXR5IGNhc2VzIG9yIG1pbmltYWwgY2xpZW50cyBvciBtaW5pbWFsDQogc2VydmVy cykuIFRoZXJlIGFyZSB0d28gcmVhc29ucyB3aHkgdGhlIG9wdGlvbmFsIGF0dHJpYnV0ZSBkb2Vz IG5vdCBmaXQgd2VsbCBoZXJlIGluIHRoZSBkaWFsb2c6PGJyPg0KPGJyPg0KMSkgV2hlbiB0aGUg Y2xpZW50IHNlbmRzIHRoZSByZXF1ZXN0IHdpdGggQUNDRVNTLVRPS0VOLCB0aGUgc2VydmVyIGFs cmVhZHkgbWFkZSBhIGNvbW1pdG1lbnQgdGhhdCB0aGUgc2VydmVyIHVuZGVyc3RhbmRzIHRoZSBv QXV0aCBjcmVkZW50aWFscyAoYnkgc2VuZGluZyB0aGUgVEhJUkQtUEFSVFktQVVUSE9SSVpBVElP TiBhdHRyaWJ1dGUpLiBTbyB0aGUgc2VydmVyIG1heSBub3QgYmUgYSBsZWdhY3kgc2VydmVyLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjIpIFRoZSBtZXNzYWdlIGNhbm5vdCBiZSBoYW5kbGVkIHByb3Blcmx5 IGlmIHRoZSBzZXJ2ZXIgZG9lcyBub3QgdW5kZXJzdGFuZHMgdGhlIEFDQ0VTUy1UT0tFTiAtIGJl Y2F1c2UgdGhlIEtJRCBpcyBub3QgYSB2YWxpZCB1c2VybmFtZSwgYW55d2F5LCBhbmQgdGhlIHNl cnZlciBkb2VzIG5vdCBrbm93IHRoZSBtYWMgZXZlbiBpZiBzb21laG93IG1pcmFjdWxvdXNseQ0K IHRoZSBzZXJ2ZXIgaGFkIGEgdXNlcm5hbWUgd2l0aCBLSUQgYXMgdGhlIHZhbHVlLiA8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5JZiB0aGVyZSBhcmUgdmFsaWQgcmVhc29ucyB3aHkgdGhlIEFDQ0VTUy1UT0tF TiBpcyBhIGNvbXByZWhlbnNpb24tb3B0aW9uYWwgYXR0cmlidXRlLCBJJ2QgbGlrZSB0byBoZWFy IHRoZW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhhbmtzICE8YnI+DQpPbGVnPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwg U2VwIDE2LCAyMDE0IGF0IDM6MjEgUE0sIE9sZWcgTW9za2FsZW5rbyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1vbTA0MDI2N0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb20wNDAyNjdAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSdkIGFsc28gc3VnZ2Vz dCB0byBjcmVhdGUgYW4gQXBwZW5kaXgsIHdpdGggdGhlIGNvbnRlbnQgc2ltaWxhciB0byBSRkMg NTc2OSwgd2l0aCB0aWNrZXQgZW5jb2RpbmcvZGVjb2Rpbmcgc2FtcGxlIGV4YW1wbGVzLiBUaGF0 IHdvdWxkIGJlbmVmaXQgYm90aCBjbGllbnQgYW5kIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMsIHRv IGF2b2lkIGFtYmlndWl0eSBhbmQNCiBtaXN1bmRlcnN0YW5kaW5ncy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzPHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPk9sZWc8L3NwYW4+PGJyPg0KPHNwYW4g Y2xhc3M9ImhvZW56YiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBTZXAgMTUsIDIw MTQgYXQgNToyNiBBTSwgU2ltb24gUGVycmVhdWx0ICZsdDs8YSBocmVmPSJtYWlsdG86c3BlcnJl YXVsdEBqaXZlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNwZXJyZWF1bHRAaml2ZS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g TW9uLCBTZXAgMTUsIDIwMTQgYXQgNjozNCBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5 KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+U2Vjb25kLCBldmVuIHdpdGggdW5rbm93biBub25jZSwga25vd2luZyB0 aGUgZXhhY3Qgbm9uY2UgZmllbGQgcG9zaXRpb25zLCB0aGUgY2xpZW50IHN0aWxsIGNhbiB0cnkg dGhlIHNhbWUgYXR0YWNrIC0gdGhlIGNsaWVudCB3aWxsIGp1c3QgaWdub3JlIHRoZSBub25jZSBw b3NpdGlvbnMsIGFuZCB0aGUgY2xpZW50DQogd2lsbCBvYnRhaW4gdGhlIHNhbWUgYXR0YWNrIHJl c3VsdCBhcyB3aXRob3V0IHRoZSBub25jZSAod2l0aCB2ZXJ5IGhpZ2ggZGVncmVlIG9mIHByb2Jh YmlsaXR5KS4gSWYgdGhlIGNsaWVudCBmaW5kcyBhIGtleSB0aGF0IGRlY3J5cHRzIHByb3Blcmx5 IGFsbCBwb3NpdGlvbnMgZXhjZXB0IHRoZSBub25jZSwgdGhlbiB0aGUgY2xpZW50IGNhbiBiZSBh bG1vc3Qgc3VyZSB0aGF0IGhlIGZvdW5kIHRoZSByZWFsIGxvbmctdGVybSBrZXkuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5b VFJdIFl1cCwgdGhlIGNsaWVudCB3aWxsIGhhdmUgdG8gdHJ5IGFsbCBwb3NzaWJsZSBrZXkgY29t YmluYXRpb25zICgyIHRvIHRoZSBwb3dlciAyNTYga2V5IGNvbWJpbmF0aW9ucw0KIHdoaWNoIHRh a2VzIHZlcnkgdmVyeSBsb25nIHRpbWUpIGFuZCBjaGVjayBpZiB0aGUgZGVjcnlwdGVkIHRva2Vu IG1hdGNoZXMgdGhlIHBsYWluIHRva2VuLiBMb29rcyBsaWtlIHdlIGRvbuKAmXQgaGF2ZSB0byBh ZGRyZXNzIHRoaXMgYXR0YWNrLg0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9lbi53aWtpcGVkaWEu b3JnL3dpa2kvVGFsayUzQVNhbHRfJTI4Y3J5cHRvZ3JhcGh5JTI5IiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtp L1RhbGslM0FTYWx0XyUyOGNyeXB0b2dyYXBoeSUyOTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KIG1lbnRpb25zIHRoYXQg4oCcbW9kZXJuIGNp cGhlcnMgc3VjaCBhcyBBZHZhbmNlZCBFbmNyeXB0aW9uIFN0YW5kYXJkIGFyZSBub3Qgc3VzY2Vw dGlibGUgdG8ga25vd24tcGxhaW50ZXh0IGF0dGFja3PigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpXaGF0ZXZlciB5b3UgZGVjaWRl LCBwbGVhc2UgbWVudGlvbiBpdCBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlv biwgYW5kIGV4cGxhaW4gd2h5IHlvdSB0aGluayB5b3VyIGRlY2lzaW9uIG1ha2VzIHNlbnNlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu a3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T aW1vbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A2832BE86xmbrcdx10ciscoc_-- From nobody Fri Sep 19 01:48:10 2014 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 8AF301A003A for ; Fri, 19 Sep 2014 01:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 ksANuzm1o92B for ; Fri, 19 Sep 2014 01:48:06 -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 0C0221A0047 for ; Fri, 19 Sep 2014 01:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18716; q=dns/txt; s=iport; t=1411116487; x=1412326087; h=from:to:cc:subject:date:message-id:mime-version; bh=i/nlcgrFYHShya3M6Vcd048VbUiJOM+tj4PETMlqAgU=; b=N1leqCr5qtWJALMheJyj3h4GiJ7hIkvcByjNhjvMicdJW5NEJBbd83YN hnxOB00LR3CNVo29DzGTitBPk+ghWJHylBrSCTmUR5Y3i8m4+Hr+ssesr 94rWOhbL/OrLVF/aZpJTu4Fr7p5FT0kIsxnPT0PGB635w2//NOCE0GHnD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAKPsG1StJV2P/2dsb2JhbABggkdGU1cEgn3EdIFrh00BGWoWAXmEAwEBAQQjCkwSAQgOAwQBAQsdAwIEHxEUCQkBBAENBQiIIgMRDawKjwQNhy4BF41KgVUKCRQWGwYHgnI2gR0FkU6EN4R3kRaGQoNebIEGQoECAQEB X-IronPort-AV: E=Sophos; i="5.04,553,1406592000"; d="scan'208,217"; a="79375753" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP; 19 Sep 2014 08:48:05 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s8J8m48o030239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 08:48:04 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 03:48:04 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , Simon Perreault Thread-Topic: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03 Thread-Index: Ac/T5miiTwSfBv39TAyze9ZiZ/FSlw== Date: Fri, 19 Sep 2014 08:48:03 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2832BE9D@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.39.66.1] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2832BE9Dxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/fhqjgt_SHg-aa2VqW5hnD0CYN8k Cc: "tram@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-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, 19 Sep 2014 08:48:08 -0000 --_000_913383AAA69FF945B8F946018B75898A2832BE9Dxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUl0NCg0KRnJvbTogT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86bW9tMDQwMjY3QGdt YWlsLmNvbV0NClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDE5LCAyMDE0IDEyOjEwIFBNDQpUbzog U2ltb24gUGVycmVhdWx0DQpDYzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgdHJhbUBp ZXRmLm9yZzsgRGFuIFdpbmcgKGR3aW5nKQ0KU3ViamVjdDogUmU6IFt0cmFtXSBXR0xDIGRyYWZ0 LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTAzDQoNCk9uZSBtb3JlIGNvbW1lbnQs IGFib3V0IHRoZSBzZWN0aW9uIDMuDQoxKSBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gc2F5IGluIHRo ZSB0ZXh0IChvciBzaG93IGl0IG9uIHRoZSBGaWd1cmUgMSksIGV4cGxpY2l0bHksIHRoYXQgdGhl IGVycm9yIGNvZGUgb2YgdGhlICJBbGxvY2F0ZSBlcnJvciByZXNwb25zZSIgaXMgNDAxLiBXZSBh cmUgaW5jbHVkaW5nIHRoZSBUSElSRC1QQVJUWS1BVVRIT1JJWkFUSU9OIGF0dHJidXRlIG9ubHkg aW4gdGhlICJjaGFsbGVuZ2UgcmVzcG9uc2UiLCBub3QgaW4gYW55IGVycm9yIHJlc3BvbnNlcy4N Cg0KW1RSXSBVcGRhdGVkIGZpZ3VyZSAxDQoNCi1UaXJ1DQoNCjIpIEluIHRoZSBjaGFsbGVuZ2Ug cmVzcG9uc2UsIHdlIGhhdmUgdG8gbWVudGlvbiB0aGF0IHdlIGFyZSBzdGlsbCBpbmNsdWRpbmcg dGhlIE5PTkNFIGFuZCBSRUFMTSBwYXJhbWV0ZXJzLCBpbiB0aGUgY2FzZSBpZiB0aGUgY2xpZW50 IGRvZXMgbm90IHN1cHBvcnRzIG9BdXRoLiBBbmQgd2UgaGF2ZSB0byBtZW50aW9uIHRoYXQgaWYg dGhlIGNsaWVudCBkb2VzIHN1cHBvcnQgb0F1dGgsIHRoZW4gdGhlIGNsaWVudCBoYXMgdG8gaWdu b3JlIHRob3NlIGF0dHJpYnV0ZXMuDQpUaGFua3MNCk9sZWcNCg0KT24gVGh1LCBTZXAgMTgsIDIw MTQgYXQgMTE6MDggUE0sIE9sZWcgTW9za2FsZW5rbyA8bW9tMDQwMjY3QGdtYWlsLmNvbTxtYWls dG86bW9tMDQwMjY3QGdtYWlsLmNvbT4+IHdyb3RlOg0KSSBoYXZlIGFub3RoZXIgY29tbWVudCwg b24gU2VjdGlvbiA2LjIuDQpJIGRvIG5vdCB0aGluayB0aGF0IHRoZSBBQ0NFU1MtVE9LRU4gbXVz dCBiZSBhIGNvbXByZWhlbnNpb24tb3B0aW9uYWwgYXR0cmlidXRlLiBUaGUgb3B0aW9uYWwgYXR0 cmlidXRlcyBhcmUgdXNlZCB3aGVuIHRoZSBtZXNzYWdlIHJlY2lwaWVudCBtYXkgYmUgb2YgYSBs aW1pdGVkIGZ1bmN0aW9uYWxpdHkgKGxpa2UgaW4gYmFja3dhcmQgY29tcGF0aWJpbGl0eSBjYXNl cyBvciBtaW5pbWFsIGNsaWVudHMgb3IgbWluaW1hbCBzZXJ2ZXJzKS4gVGhlcmUgYXJlIHR3byBy ZWFzb25zIHdoeSB0aGUgb3B0aW9uYWwgYXR0cmlidXRlIGRvZXMgbm90IGZpdCB3ZWxsIGhlcmUg aW4gdGhlIGRpYWxvZzoNCg0KMSkgV2hlbiB0aGUgY2xpZW50IHNlbmRzIHRoZSByZXF1ZXN0IHdp dGggQUNDRVNTLVRPS0VOLCB0aGUgc2VydmVyIGFscmVhZHkgbWFkZSBhIGNvbW1pdG1lbnQgdGhh dCB0aGUgc2VydmVyIHVuZGVyc3RhbmRzIHRoZSBvQXV0aCBjcmVkZW50aWFscyAoYnkgc2VuZGlu ZyB0aGUgVEhJUkQtUEFSVFktQVVUSE9SSVpBVElPTiBhdHRyaWJ1dGUpLiBTbyB0aGUgc2VydmVy IG1heSBub3QgYmUgYSBsZWdhY3kgc2VydmVyLg0KMikgVGhlIG1lc3NhZ2UgY2Fubm90IGJlIGhh bmRsZWQgcHJvcGVybHkgaWYgdGhlIHNlcnZlciBkb2VzIG5vdCB1bmRlcnN0YW5kcyB0aGUgQUND RVNTLVRPS0VOIC0gYmVjYXVzZSB0aGUgS0lEIGlzIG5vdCBhIHZhbGlkIHVzZXJuYW1lLCBhbnl3 YXksIGFuZCB0aGUgc2VydmVyIGRvZXMgbm90IGtub3cgdGhlIG1hYyBldmVuIGlmIHNvbWVob3cg bWlyYWN1bG91c2x5IHRoZSBzZXJ2ZXIgaGFkIGEgdXNlcm5hbWUgd2l0aCBLSUQgYXMgdGhlIHZh bHVlLg0KSWYgdGhlcmUgYXJlIHZhbGlkIHJlYXNvbnMgd2h5IHRoZSBBQ0NFU1MtVE9LRU4gaXMg YSBjb21wcmVoZW5zaW9uLW9wdGlvbmFsIGF0dHJpYnV0ZSwgSSdkIGxpa2UgdG8gaGVhciB0aGVt Lg0KVGhhbmtzICENCk9sZWcNCg0KDQpPbiBUdWUsIFNlcCAxNiwgMjAxNCBhdCAzOjIxIFBNLCBP bGVnIE1vc2thbGVua28gPG1vbTA0MDI2N0BnbWFpbC5jb208bWFpbHRvOm1vbTA0MDI2N0BnbWFp bC5jb20+PiB3cm90ZToNCkknZCBhbHNvIHN1Z2dlc3QgdG8gY3JlYXRlIGFuIEFwcGVuZGl4LCB3 aXRoIHRoZSBjb250ZW50IHNpbWlsYXIgdG8gUkZDIDU3NjksIHdpdGggdGlja2V0IGVuY29kaW5n L2RlY29kaW5nIHNhbXBsZSBleGFtcGxlcy4gVGhhdCB3b3VsZCBiZW5lZml0IGJvdGggY2xpZW50 IGFuZCBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zLCB0byBhdm9pZCBhbWJpZ3VpdHkgYW5kIG1pc3Vu ZGVyc3RhbmRpbmdzLg0KVGhhbmtzDQpPbGVnDQoNCg0KT24gTW9uLCBTZXAgMTUsIDIwMTQgYXQg NToyNiBBTSwgU2ltb24gUGVycmVhdWx0IDxzcGVycmVhdWx0QGppdmUuY29tPG1haWx0bzpzcGVy cmVhdWx0QGppdmUuY29tPj4gd3JvdGU6DQoNCk9uIE1vbiwgU2VwIDE1LCAyMDE0IGF0IDY6MzQg QU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPG1haWx0 bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KU2Vjb25kLCBldmVuIHdpdGggdW5rbm93biBu b25jZSwga25vd2luZyB0aGUgZXhhY3Qgbm9uY2UgZmllbGQgcG9zaXRpb25zLCB0aGUgY2xpZW50 IHN0aWxsIGNhbiB0cnkgdGhlIHNhbWUgYXR0YWNrIC0gdGhlIGNsaWVudCB3aWxsIGp1c3QgaWdu b3JlIHRoZSBub25jZSBwb3NpdGlvbnMsIGFuZCB0aGUgY2xpZW50IHdpbGwgb2J0YWluIHRoZSBz YW1lIGF0dGFjayByZXN1bHQgYXMgd2l0aG91dCB0aGUgbm9uY2UgKHdpdGggdmVyeSBoaWdoIGRl Z3JlZSBvZiBwcm9iYWJpbGl0eSkuIElmIHRoZSBjbGllbnQgZmluZHMgYSBrZXkgdGhhdCBkZWNy eXB0cyBwcm9wZXJseSBhbGwgcG9zaXRpb25zIGV4Y2VwdCB0aGUgbm9uY2UsIHRoZW4gdGhlIGNs aWVudCBjYW4gYmUgYWxtb3N0IHN1cmUgdGhhdCBoZSBmb3VuZCB0aGUgcmVhbCBsb25nLXRlcm0g a2V5Lg0KDQpbVFJdIFl1cCwgdGhlIGNsaWVudCB3aWxsIGhhdmUgdG8gdHJ5IGFsbCBwb3NzaWJs ZSBrZXkgY29tYmluYXRpb25zICgyIHRvIHRoZSBwb3dlciAyNTYga2V5IGNvbWJpbmF0aW9ucyB3 aGljaCB0YWtlcyB2ZXJ5IHZlcnkgbG9uZyB0aW1lKSBhbmQgY2hlY2sgaWYgdGhlIGRlY3J5cHRl ZCB0b2tlbiBtYXRjaGVzIHRoZSBwbGFpbiB0b2tlbi4gTG9va3MgbGlrZSB3ZSBkb27igJl0IGhh dmUgdG8gYWRkcmVzcyB0aGlzIGF0dGFjay4gaHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9U YWxrJTNBU2FsdF8lMjhjcnlwdG9ncmFwaHklMjkgbWVudGlvbnMgdGhhdCDigJxtb2Rlcm4gY2lw aGVycyBzdWNoIGFzIEFkdmFuY2VkIEVuY3J5cHRpb24gU3RhbmRhcmQgYXJlIG5vdCBzdXNjZXB0 aWJsZSB0byBrbm93bi1wbGFpbnRleHQgYXR0YWNrc+KAnS4NCg0KV2hhdGV2ZXIgeW91IGRlY2lk ZSwgcGxlYXNlIG1lbnRpb24gaXQgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rp b24sIGFuZCBleHBsYWluIHdoeSB5b3UgdGhpbmsgeW91ciBkZWNpc2lvbiBtYWtlcyBzZW5zZS4N Cg0KVGhhbmtzLA0KU2ltb24NCg0KDQoNCg== --_000_913383AAA69FF945B8F946018B75898A2832BE9Dxmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90 dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHls ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SW5saW5lIFtUUl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIFNlcHRlbWJlciAxOSwgMjAxNCAxMjoxMCBQ TTxicj4NCjxiPlRvOjwvYj4gU2ltb24gUGVycmVhdWx0PGJyPg0KPGI+Q2M6PC9iPiBUaXJ1bWFs ZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyB0cmFtQGlldGYub3JnOyBEYW4gV2luZyAoZHdpbmcpPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gV0dMQyBkcmFmdC1pZXRmLXRyYW0tdHVybi10 aGlyZC1wYXJ0eS1hdXRoei0wMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPk9uZSBtb3JlIGNvbW1lbnQsIGFib3V0IHRoZSBzZWN0aW9uIDMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIEl0IHdvdWxkIGJlIGJldHRl ciB0byBzYXkgaW4gdGhlIHRleHQgKG9yIHNob3cgaXQgb24gdGhlIEZpZ3VyZSAxKSwgZXhwbGlj aXRseSwgdGhhdCB0aGUgZXJyb3IgY29kZSBvZiB0aGUgJnF1b3Q7QWxsb2NhdGUgZXJyb3IgcmVz cG9uc2UmcXVvdDsgaXMgNDAxLiBXZSBhcmUgaW5jbHVkaW5nIHRoZSBUSElSRC1QQVJUWS1BVVRI T1JJWkFUSU9OIGF0dHJidXRlIG9ubHkgaW4gdGhlICZxdW90O2NoYWxsZW5nZSByZXNwb25zZSZx dW90Oywgbm90DQogaW4gYW55IGVycm9yIHJlc3BvbnNlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSXSBVcGRhdGVkIGZpZ3VyZSAxPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4t VGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+MikgSW4gdGhlIGNoYWxsZW5nZSByZXNwb25zZSwgd2UgaGF2ZSB0byBtZW50aW9u IHRoYXQgd2UgYXJlIHN0aWxsIGluY2x1ZGluZyB0aGUgTk9OQ0UgYW5kIFJFQUxNIHBhcmFtZXRl cnMsIGluIHRoZSBjYXNlIGlmIHRoZSBjbGllbnQgZG9lcyBub3Qgc3VwcG9ydHMgb0F1dGguIEFu ZCB3ZSBoYXZlIHRvIG1lbnRpb24gdGhhdCBpZiB0aGUgY2xpZW50IGRvZXMNCiBzdXBwb3J0IG9B dXRoLCB0aGVuIHRoZSBjbGllbnQgaGFzIHRvIGlnbm9yZSB0aG9zZSBhdHRyaWJ1dGVzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPlRoYW5rczxicj4NCk9sZWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgU2VwIDE4LCAyMDE0IGF0IDExOjA4IFBNLCBPbGVn IE1vc2thbGVua28gJmx0OzxhIGhyZWY9Im1haWx0bzptb20wNDAyNjdAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+bW9tMDQwMjY3QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgaGF2ZSBhbm90aGVyIGNvbW1lbnQs IG9uIFNlY3Rpb24gNi4yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGRvIG5vdCB0aGluayB0aGF0IHRoZSBBQ0NFU1MtVE9LRU4gbXVzdCBiZSBhIGNvbXBy ZWhlbnNpb24tb3B0aW9uYWwgYXR0cmlidXRlLiBUaGUgb3B0aW9uYWwgYXR0cmlidXRlcyBhcmUg dXNlZCB3aGVuIHRoZSBtZXNzYWdlIHJlY2lwaWVudCBtYXkgYmUgb2YgYSBsaW1pdGVkIGZ1bmN0 aW9uYWxpdHkgKGxpa2UgaW4gYmFja3dhcmQgY29tcGF0aWJpbGl0eSBjYXNlcyBvciBtaW5pbWFs IGNsaWVudHMgb3IgbWluaW1hbA0KIHNlcnZlcnMpLiBUaGVyZSBhcmUgdHdvIHJlYXNvbnMgd2h5 IHRoZSBvcHRpb25hbCBhdHRyaWJ1dGUgZG9lcyBub3QgZml0IHdlbGwgaGVyZSBpbiB0aGUgZGlh bG9nOjxicj4NCjxicj4NCjEpIFdoZW4gdGhlIGNsaWVudCBzZW5kcyB0aGUgcmVxdWVzdCB3aXRo IEFDQ0VTUy1UT0tFTiwgdGhlIHNlcnZlciBhbHJlYWR5IG1hZGUgYSBjb21taXRtZW50IHRoYXQg dGhlIHNlcnZlciB1bmRlcnN0YW5kcyB0aGUgb0F1dGggY3JlZGVudGlhbHMgKGJ5IHNlbmRpbmcg dGhlIFRISVJELVBBUlRZLUFVVEhPUklaQVRJT04gYXR0cmlidXRlKS4gU28gdGhlIHNlcnZlciBt YXkgbm90IGJlIGEgbGVnYWN5IHNlcnZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4yKSBUaGUgbWVzc2Fn ZSBjYW5ub3QgYmUgaGFuZGxlZCBwcm9wZXJseSBpZiB0aGUgc2VydmVyIGRvZXMgbm90IHVuZGVy c3RhbmRzIHRoZSBBQ0NFU1MtVE9LRU4gLSBiZWNhdXNlIHRoZSBLSUQgaXMgbm90IGEgdmFsaWQg dXNlcm5hbWUsIGFueXdheSwgYW5kIHRoZSBzZXJ2ZXIgZG9lcyBub3Qga25vdyB0aGUgbWFjIGV2 ZW4gaWYgc29tZWhvdyBtaXJhY3Vsb3VzbHkNCiB0aGUgc2VydmVyIGhhZCBhIHVzZXJuYW1lIHdp dGggS0lEIGFzIHRoZSB2YWx1ZS4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SWYgdGhlcmUgYXJlIHZhbGlk IHJlYXNvbnMgd2h5IHRoZSBBQ0NFU1MtVE9LRU4gaXMgYSBjb21wcmVoZW5zaW9uLW9wdGlvbmFs IGF0dHJpYnV0ZSwgSSdkIGxpa2UgdG8gaGVhciB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoYW5r cyAhPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIi Pk9sZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgU2VwIDE2LCAy MDE0IGF0IDM6MjEgUE0sIE9sZWcgTW9za2FsZW5rbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vbTA0 MDI2N0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb20wNDAyNjdAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSdkIGFsc28gc3VnZ2VzdCB0byBjcmVh dGUgYW4gQXBwZW5kaXgsIHdpdGggdGhlIGNvbnRlbnQgc2ltaWxhciB0byBSRkMgNTc2OSwgd2l0 aCB0aWNrZXQgZW5jb2RpbmcvZGVjb2Rpbmcgc2FtcGxlIGV4YW1wbGVzLiBUaGF0IHdvdWxkIGJl bmVmaXQgYm90aCBjbGllbnQgYW5kIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMsIHRvIGF2b2lkIGFt YmlndWl0eSBhbmQNCiBtaXN1bmRlcnN0YW5kaW5ncy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxi cj4NCk9sZWc8YnI+DQombmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgU2VwIDE1LCAyMDE0IGF0IDU6 MjYgQU0sIFNpbW9uIFBlcnJlYXVsdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwZXJyZWF1bHRAaml2 ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5zcGVycmVhdWx0QGppdmUuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgU2Vw IDE1LCAyMDE0IGF0IDY6MzQgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0Ozxh IGhyZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlA Y2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlNlY29uZCwgZXZlbiB3aXRoIHVua25vd24gbm9uY2UsIGtub3dpbmcgdGhlIGV4YWN0 IG5vbmNlIGZpZWxkIHBvc2l0aW9ucywgdGhlIGNsaWVudCBzdGlsbCBjYW4gdHJ5IHRoZSBzYW1l IGF0dGFjayAtIHRoZSBjbGllbnQgd2lsbCBqdXN0IGlnbm9yZSB0aGUgbm9uY2UgcG9zaXRpb25z LCBhbmQgdGhlIGNsaWVudA0KIHdpbGwgb2J0YWluIHRoZSBzYW1lIGF0dGFjayByZXN1bHQgYXMg d2l0aG91dCB0aGUgbm9uY2UgKHdpdGggdmVyeSBoaWdoIGRlZ3JlZSBvZiBwcm9iYWJpbGl0eSku IElmIHRoZSBjbGllbnQgZmluZHMgYSBrZXkgdGhhdCBkZWNyeXB0cyBwcm9wZXJseSBhbGwgcG9z aXRpb25zIGV4Y2VwdCB0aGUgbm9uY2UsIHRoZW4gdGhlIGNsaWVudCBjYW4gYmUgYWxtb3N0IHN1 cmUgdGhhdCBoZSBmb3VuZCB0aGUgcmVhbCBsb25nLXRlcm0ga2V5LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSXSBZdXAs IHRoZSBjbGllbnQgd2lsbCBoYXZlIHRvIHRyeSBhbGwgcG9zc2libGUga2V5IGNvbWJpbmF0aW9u cyAoMiB0byB0aGUgcG93ZXIgMjU2IGtleSBjb21iaW5hdGlvbnMNCiB3aGljaCB0YWtlcyB2ZXJ5 IHZlcnkgbG9uZyB0aW1lKSBhbmQgY2hlY2sgaWYgdGhlIGRlY3J5cHRlZCB0b2tlbiBtYXRjaGVz IHRoZSBwbGFpbiB0b2tlbi4gTG9va3MgbGlrZSB3ZSBkb27igJl0IGhhdmUgdG8gYWRkcmVzcyB0 aGlzIGF0dGFjay4NCjwvc3Bhbj48YSBocmVmPSJodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtp L1RhbGslM0FTYWx0XyUyOGNyeXB0b2dyYXBoeSUyOSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9UYWxrJTNB U2FsdF8lMjhjcnlwdG9ncmFwaHklMjk8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4NCiBtZW50aW9ucyB0aGF0IOKAnG1vZGVybiBjaXBoZXJzIHN1 Y2ggYXMgQWR2YW5jZWQgRW5jcnlwdGlvbiBTdGFuZGFyZCBhcmUgbm90IHN1c2NlcHRpYmxlIHRv IGtub3duLXBsYWludGV4dCBhdHRhY2tz4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KV2hhdGV2ZXIgeW91IGRlY2lkZSwgcGxlYXNl IG1lbnRpb24gaXQgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24sIGFuZCBl eHBsYWluIHdoeSB5b3UgdGhpbmsgeW91ciBkZWNpc2lvbiBtYWtlcyBzZW5zZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2ltb248bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A2832BE9Dxmbrcdx10ciscoc_-- From nobody Fri Sep 19 02:00:24 2014 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 B5A5B1A0047 for ; Fri, 19 Sep 2014 02:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 wXgqoQD0ZbPV for ; Fri, 19 Sep 2014 02:00:20 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F671A000C for ; Fri, 19 Sep 2014 02:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21742; q=dns/txt; s=iport; t=1411117220; x=1412326820; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gnQ5J1uT7ewJawsiJ0T8sEc/AG4vPu99hTiV0Smj9Ow=; b=erqyrA5zY83drQi75QTC948wtZku8eLJs4LEfpWVDWgAohOj8rasiVGj dw8oimhUSJAkC8WEQjtg+YcCEmyioW8s4mYl9lWQRAtpfxk5sxIcoXRaM rcjQ7bxyE2RnBHsKqtCtoCl0/pnF6OL7yzIku+OtEGKALHbLjg/E6D0qO E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAHHvG1StJV2Q/2dsb2JhbABggkdGU1cEgn3EdIFrh00BGWkWAXmEAwEBAQQjCkUHEAIBCA4DBAEBCx0DAgICHxEUCQgCBAENBQiIIgMRDawSjwQNhy4BF41KgVUKCRQWGwYBBoJyNoEdBZFOhDeEd5EWhkKDXmyBBkKBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,553,1406592000"; d="scan'208,217"; a="79380757" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP; 19 Sep 2014 09:00:19 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s8J90JPW031930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 09:00:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 04:00:19 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , Simon Perreault Thread-Topic: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03 Thread-Index: Ac/Qvx644PLjBlafRrmDlBwUAS1QRQALXlkAAApi6PD//+gbgIACOHUAgAOnVgCAAAjMgIAAC4WAgAA7k0A= Date: Fri, 19 Sep 2014 09:00:18 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2832BED1@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A28328E81@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A28328F3F@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: [173.39.66.1] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2832BED1xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/yYGI6iZdQSrCguPx4GDMlNbqQhA Cc: "tram@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-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, 19 Sep 2014 09:00:22 -0000 --_000_913383AAA69FF945B8F946018B75898A2832BED1xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgT2xlZywNCg0KUmVnYXJkaW5nIHlvdXIgc2Vjb25kIGNvbW1lbnQsIHRob3VnaCBBcHBsaWNh dGlvbiBwcm92aWRlZCBUVVJOIHNlcnZlciBtYXkgb25seSBzdXBwb3J0IHRoaXJkIHBhcnR5IGF1 dGhvcml6YXRpb24uIEJ1dCBFbnRlcnByaXNlIHByb3ZpZGVkIFRVUk4gc2VydmVyIGNvdWxkIHN1 cHBvcnQgYm90aCBmaXJzdCBhbmQgdGhpcmQgcGFydHkgYXV0aG9yaXphdGlvbi4gVGhpcyB3YXkg Y2xpZW50IGNhbiB1c2UgdGhpcmQgcGFydHkgYXV0aG9yaXphdGlvbiB3aGVuIGl0IHVzZXMgV2Vi UlRDL1NJUCBzZXJ2ZXJzIHRoYXQgaGF2ZSBidXNpbmVzcyByZWxhdGlvbnNoaXAgd2l0aCB0aGUg RW50ZXJwcmlzZSBuZXR3b3JrIGFuZCB1c2UgZmlyc3QgcGFydHkgYXV0aG9yaXphdGlvbiBmb3Ig bm9uLWJ1c2luZXNzIHJlbGF0ZWQgY2FsbHMuDQoNClRVUk4gc2VydmVyIGluIHRoZSBjaGFsbGVu Z2Ugd2lsbCBpbmNsdWRlIE5PTkNFLCBSRUFMTSBhbmQgVEhJUkRfUEFSVFlfQVVUSE9SSVpBVElP TiBhdHRyaWJ1dGVzLCBjbGllbnQgdXNlcyB0aGUgVFVSTiBzZXJ2ZXIgbmFtZSB0byBkZXRlcm1p bmUgaWYgdGhpcmQgcGFydHkgYXV0aG9yaXphdGlvbiB3aWxsIHdvcmsgb3Igbm90IGJ5IGNyb3Nz LWNoZWNraW5nIHdpdGggdGhlIEF1dGhvcml6YXRpb24gc2V2ZXIuIElmIGl0IHdvcmtzIHRoZW4g Y2xpZW50IHdpbGwgcHJvY2VlZCB3aXRoIHRoaXJkIHBhcnR5IGF1dGhvcml6YXRpb24gb3IgZWxz ZSBjb250aW51ZSB3aXRoIGZpcnN0IHBhcnR5IGF1dGhlbnRpY2F0aW9uLg0KDQotVGlydQ0KDQpG cm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgT2xl ZyBNb3NrYWxlbmtvDQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAxOSwgMjAxNCAxMjo1MiBQTQ0K VG86IFNpbW9uIFBlcnJlYXVsdA0KQ2M6IERhbiBXaW5nIChkd2luZyk7IHRyYW1AaWV0Zi5vcmc7 IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNClN1YmplY3Q6IFJlOiBbdHJhbV0gV0dMQyBk cmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMw0KDQpBY3R1YWxseSwgbXkg Y29tbWVudHMgYWJvdXQgTk9OQ0UgYW5kIFJFQUxNIGFyZSBpbnZhbGlkLCB0aG9zZSBhdHRyaWJ1 dGVzIG11c3QgYmUgdXNlZCBpbiBvQXV0aCBpbiB0aGUgc2FtZSB3YXkgYXMgaW4gdXN1YWwgbG9u Zy10ZXJtIGNyZWRlbnRpYWxzLiBTY3JhdGNoIHRoYXQuDQoNClRoYW5rcw0KT2xlZw0KDQpPbiBU aHUsIFNlcCAxOCwgMjAxNCBhdCAxMTo0MCBQTSwgT2xlZyBNb3NrYWxlbmtvIDxtb20wNDAyNjdA Z21haWwuY29tPG1haWx0bzptb20wNDAyNjdAZ21haWwuY29tPj4gd3JvdGU6DQpPbmUgbW9yZSBj b21tZW50LCBhYm91dCB0aGUgc2VjdGlvbiAzLg0KMSkgSXQgd291bGQgYmUgYmV0dGVyIHRvIHNh eSBpbiB0aGUgdGV4dCAob3Igc2hvdyBpdCBvbiB0aGUgRmlndXJlIDEpLCBleHBsaWNpdGx5LCB0 aGF0IHRoZSBlcnJvciBjb2RlIG9mIHRoZSAiQWxsb2NhdGUgZXJyb3IgcmVzcG9uc2UiIGlzIDQw MS4gV2UgYXJlIGluY2x1ZGluZyB0aGUgVEhJUkQtUEFSVFktQVVUSE9SSVpBVElPTiBhdHRyYnV0 ZSBvbmx5IGluIHRoZSAiY2hhbGxlbmdlIHJlc3BvbnNlIiwgbm90IGluIGFueSBlcnJvciByZXNw b25zZXMuDQoyKSBJbiB0aGUgY2hhbGxlbmdlIHJlc3BvbnNlLCB3ZSBoYXZlIHRvIG1lbnRpb24g dGhhdCB3ZSBhcmUgc3RpbGwgaW5jbHVkaW5nIHRoZSBOT05DRSBhbmQgUkVBTE0gcGFyYW1ldGVy cywgaW4gdGhlIGNhc2UgaWYgdGhlIGNsaWVudCBkb2VzIG5vdCBzdXBwb3J0cyBvQXV0aC4gQW5k IHdlIGhhdmUgdG8gbWVudGlvbiB0aGF0IGlmIHRoZSBjbGllbnQgZG9lcyBzdXBwb3J0IG9BdXRo LCB0aGVuIHRoZSBjbGllbnQgaGFzIHRvIGlnbm9yZSB0aG9zZSBhdHRyaWJ1dGVzLg0KVGhhbmtz DQpPbGVnDQoNCk9uIFRodSwgU2VwIDE4LCAyMDE0IGF0IDExOjA4IFBNLCBPbGVnIE1vc2thbGVu a28gPG1vbTA0MDI2N0BnbWFpbC5jb208bWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb20+PiB3cm90 ZToNCkkgaGF2ZSBhbm90aGVyIGNvbW1lbnQsIG9uIFNlY3Rpb24gNi4yLg0KSSBkbyBub3QgdGhp bmsgdGhhdCB0aGUgQUNDRVNTLVRPS0VOIG11c3QgYmUgYSBjb21wcmVoZW5zaW9uLW9wdGlvbmFs IGF0dHJpYnV0ZS4gVGhlIG9wdGlvbmFsIGF0dHJpYnV0ZXMgYXJlIHVzZWQgd2hlbiB0aGUgbWVz c2FnZSByZWNpcGllbnQgbWF5IGJlIG9mIGEgbGltaXRlZCBmdW5jdGlvbmFsaXR5IChsaWtlIGlu IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgY2FzZXMgb3IgbWluaW1hbCBjbGllbnRzIG9yIG1pbmlt YWwgc2VydmVycykuIFRoZXJlIGFyZSB0d28gcmVhc29ucyB3aHkgdGhlIG9wdGlvbmFsIGF0dHJp YnV0ZSBkb2VzIG5vdCBmaXQgd2VsbCBoZXJlIGluIHRoZSBkaWFsb2c6DQoNCjEpIFdoZW4gdGhl IGNsaWVudCBzZW5kcyB0aGUgcmVxdWVzdCB3aXRoIEFDQ0VTUy1UT0tFTiwgdGhlIHNlcnZlciBh bHJlYWR5IG1hZGUgYSBjb21taXRtZW50IHRoYXQgdGhlIHNlcnZlciB1bmRlcnN0YW5kcyB0aGUg b0F1dGggY3JlZGVudGlhbHMgKGJ5IHNlbmRpbmcgdGhlIFRISVJELVBBUlRZLUFVVEhPUklaQVRJ T04gYXR0cmlidXRlKS4gU28gdGhlIHNlcnZlciBtYXkgbm90IGJlIGEgbGVnYWN5IHNlcnZlci4N CjIpIFRoZSBtZXNzYWdlIGNhbm5vdCBiZSBoYW5kbGVkIHByb3Blcmx5IGlmIHRoZSBzZXJ2ZXIg ZG9lcyBub3QgdW5kZXJzdGFuZHMgdGhlIEFDQ0VTUy1UT0tFTiAtIGJlY2F1c2UgdGhlIEtJRCBp cyBub3QgYSB2YWxpZCB1c2VybmFtZSwgYW55d2F5LCBhbmQgdGhlIHNlcnZlciBkb2VzIG5vdCBr bm93IHRoZSBtYWMgZXZlbiBpZiBzb21laG93IG1pcmFjdWxvdXNseSB0aGUgc2VydmVyIGhhZCBh IHVzZXJuYW1lIHdpdGggS0lEIGFzIHRoZSB2YWx1ZS4NCklmIHRoZXJlIGFyZSB2YWxpZCByZWFz b25zIHdoeSB0aGUgQUNDRVNTLVRPS0VOIGlzIGEgY29tcHJlaGVuc2lvbi1vcHRpb25hbCBhdHRy aWJ1dGUsIEknZCBsaWtlIHRvIGhlYXIgdGhlbS4NClRoYW5rcyAhDQpPbGVnDQoNCg0KT24gVHVl LCBTZXAgMTYsIDIwMTQgYXQgMzoyMSBQTSwgT2xlZyBNb3NrYWxlbmtvIDxtb20wNDAyNjdAZ21h aWwuY29tPG1haWx0bzptb20wNDAyNjdAZ21haWwuY29tPj4gd3JvdGU6DQpJJ2QgYWxzbyBzdWdn ZXN0IHRvIGNyZWF0ZSBhbiBBcHBlbmRpeCwgd2l0aCB0aGUgY29udGVudCBzaW1pbGFyIHRvIFJG QyA1NzY5LCB3aXRoIHRpY2tldCBlbmNvZGluZy9kZWNvZGluZyBzYW1wbGUgZXhhbXBsZXMuIFRo YXQgd291bGQgYmVuZWZpdCBib3RoIGNsaWVudCBhbmQgc2VydmVyIGltcGxlbWVudGF0aW9ucywg dG8gYXZvaWQgYW1iaWd1aXR5IGFuZCBtaXN1bmRlcnN0YW5kaW5ncy4NClRoYW5rcw0KT2xlZw0K DQoNCk9uIE1vbiwgU2VwIDE1LCAyMDE0IGF0IDU6MjYgQU0sIFNpbW9uIFBlcnJlYXVsdCA8c3Bl cnJlYXVsdEBqaXZlLmNvbTxtYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbT4+IHdyb3RlOg0KDQpP biBNb24sIFNlcCAxNSwgMjAxNCBhdCA2OjM0IEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVk ZHkpIDx0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+PiB3cm90ZToN ClNlY29uZCwgZXZlbiB3aXRoIHVua25vd24gbm9uY2UsIGtub3dpbmcgdGhlIGV4YWN0IG5vbmNl IGZpZWxkIHBvc2l0aW9ucywgdGhlIGNsaWVudCBzdGlsbCBjYW4gdHJ5IHRoZSBzYW1lIGF0dGFj ayAtIHRoZSBjbGllbnQgd2lsbCBqdXN0IGlnbm9yZSB0aGUgbm9uY2UgcG9zaXRpb25zLCBhbmQg dGhlIGNsaWVudCB3aWxsIG9idGFpbiB0aGUgc2FtZSBhdHRhY2sgcmVzdWx0IGFzIHdpdGhvdXQg dGhlIG5vbmNlICh3aXRoIHZlcnkgaGlnaCBkZWdyZWUgb2YgcHJvYmFiaWxpdHkpLiBJZiB0aGUg Y2xpZW50IGZpbmRzIGEga2V5IHRoYXQgZGVjcnlwdHMgcHJvcGVybHkgYWxsIHBvc2l0aW9ucyBl eGNlcHQgdGhlIG5vbmNlLCB0aGVuIHRoZSBjbGllbnQgY2FuIGJlIGFsbW9zdCBzdXJlIHRoYXQg aGUgZm91bmQgdGhlIHJlYWwgbG9uZy10ZXJtIGtleS4NCg0KW1RSXSBZdXAsIHRoZSBjbGllbnQg d2lsbCBoYXZlIHRvIHRyeSBhbGwgcG9zc2libGUga2V5IGNvbWJpbmF0aW9ucyAoMiB0byB0aGUg cG93ZXIgMjU2IGtleSBjb21iaW5hdGlvbnMgd2hpY2ggdGFrZXMgdmVyeSB2ZXJ5IGxvbmcgdGlt ZSkgYW5kIGNoZWNrIGlmIHRoZSBkZWNyeXB0ZWQgdG9rZW4gbWF0Y2hlcyB0aGUgcGxhaW4gdG9r ZW4uIExvb2tzIGxpa2Ugd2UgZG9u4oCZdCBoYXZlIHRvIGFkZHJlc3MgdGhpcyBhdHRhY2suIGh0 dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvVGFsayUzQVNhbHRfJTI4Y3J5cHRvZ3JhcGh5JTI5 IG1lbnRpb25zIHRoYXQg4oCcbW9kZXJuIGNpcGhlcnMgc3VjaCBhcyBBZHZhbmNlZCBFbmNyeXB0 aW9uIFN0YW5kYXJkIGFyZSBub3Qgc3VzY2VwdGlibGUgdG8ga25vd24tcGxhaW50ZXh0IGF0dGFj a3PigJ0uDQoNCldoYXRldmVyIHlvdSBkZWNpZGUsIHBsZWFzZSBtZW50aW9uIGl0IGluIHRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBhbmQgZXhwbGFpbiB3aHkgeW91IHRoaW5r IHlvdXIgZGVjaXNpb24gbWFrZXMgc2Vuc2UuDQoNClRoYW5rcywNClNpbW9uDQoNCg0KDQoNCg== --_000_913383AAA69FF945B8F946018B75898A2832BED1xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE9sZWcsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRpbmcgeW91 ciBzZWNvbmQgY29tbWVudCwgdGhvdWdoIEFwcGxpY2F0aW9uIHByb3ZpZGVkIFRVUk4gc2VydmVy IG1heSBvbmx5IHN1cHBvcnQgdGhpcmQgcGFydHkgYXV0aG9yaXphdGlvbi4gQnV0IEVudGVycHJp c2UgcHJvdmlkZWQgVFVSTiBzZXJ2ZXIgY291bGQNCiBzdXBwb3J0IGJvdGggZmlyc3QgYW5kIHRo aXJkIHBhcnR5IGF1dGhvcml6YXRpb24uIFRoaXMgd2F5IGNsaWVudCBjYW4gdXNlIHRoaXJkIHBh cnR5IGF1dGhvcml6YXRpb24gd2hlbiBpdCB1c2VzIFdlYlJUQy9TSVAgc2VydmVycyB0aGF0IGhh dmUgYnVzaW5lc3MgcmVsYXRpb25zaGlwIHdpdGggdGhlIEVudGVycHJpc2UgbmV0d29yayBhbmQg dXNlIGZpcnN0IHBhcnR5IGF1dGhvcml6YXRpb24gZm9yIG5vbi1idXNpbmVzcyByZWxhdGVkIGNh bGxzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UVVJOIHNlcnZlciBpbiB0aGUgY2hhbGxlbmdlIHdpbGwgaW5jbHVk ZSBOT05DRSwgUkVBTE0gYW5kIFRISVJEX1BBUlRZX0FVVEhPUklaQVRJT04gYXR0cmlidXRlcywg Y2xpZW50IHVzZXMgdGhlIFRVUk4gc2VydmVyIG5hbWUgdG8gZGV0ZXJtaW5lIGlmIHRoaXJkIHBh cnR5DQogYXV0aG9yaXphdGlvbiB3aWxsIHdvcmsgb3Igbm90IGJ5IGNyb3NzLWNoZWNraW5nIHdp dGggdGhlIEF1dGhvcml6YXRpb24gc2V2ZXIuIElmIGl0IHdvcmtzIHRoZW4gY2xpZW50IHdpbGwg cHJvY2VlZCB3aXRoIHRoaXJkIHBhcnR5IGF1dGhvcml6YXRpb24gb3IgZWxzZSBjb250aW51ZSB3 aXRoIGZpcnN0IHBhcnR5IGF1dGhlbnRpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdHJhbSBbbWFpbHRvOnRyYW0tYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+T2xlZyBNb3NrYWxlbmtvPGJyPg0K PGI+U2VudDo8L2I+IEZyaWRheSwgU2VwdGVtYmVyIDE5LCAyMDE0IDEyOjUyIFBNPGJyPg0KPGI+ VG86PC9iPiBTaW1vbiBQZXJyZWF1bHQ8YnI+DQo8Yj5DYzo8L2I+IERhbiBXaW5nIChkd2luZyk7 IHRyYW1AaWV0Zi5vcmc7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFt0cmFtXSBXR0xDIGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5 LWF1dGh6LTAzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFjdHVhbGx5LCBteSBjb21tZW50cyBhYm91dCBOT05DRSBhbmQgUkVBTE0gYXJlIGlu dmFsaWQsIHRob3NlIGF0dHJpYnV0ZXMgbXVzdCBiZSB1c2VkIGluIG9BdXRoIGluIHRoZSBzYW1l IHdheSBhcyBpbiB1c3VhbCBsb25nLXRlcm0gY3JlZGVudGlhbHMuIFNjcmF0Y2ggdGhhdC48YnI+ DQo8YnI+DQpUaGFua3M8YnI+DQpPbGVnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUaHUsIFNlcCAxOCwgMjAxNCBhdCAxMTo0MCBQTSwgT2xlZyBNb3Nr YWxlbmtvICZsdDs8YSBocmVmPSJtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm1vbTA0MDI2N0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uZSBtb3JlIGNvbW1lbnQsIGFib3V0IHRoZSBzZWN0aW9u IDMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIEl0IHdv dWxkIGJlIGJldHRlciB0byBzYXkgaW4gdGhlIHRleHQgKG9yIHNob3cgaXQgb24gdGhlIEZpZ3Vy ZSAxKSwgZXhwbGljaXRseSwgdGhhdCB0aGUgZXJyb3IgY29kZSBvZiB0aGUgJnF1b3Q7QWxsb2Nh dGUgZXJyb3IgcmVzcG9uc2UmcXVvdDsgaXMgNDAxLiBXZSBhcmUgaW5jbHVkaW5nIHRoZSBUSElS RC1QQVJUWS1BVVRIT1JJWkFUSU9OIGF0dHJidXRlIG9ubHkgaW4gdGhlICZxdW90O2NoYWxsZW5n ZSByZXNwb25zZSZxdW90Oywgbm90DQogaW4gYW55IGVycm9yIHJlc3BvbnNlcy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij4yKSBJbiB0aGUgY2hhbGxlbmdlIHJlc3BvbnNlLCB3ZSBoYXZlIHRvIG1lbnRpb24g dGhhdCB3ZSBhcmUgc3RpbGwgaW5jbHVkaW5nIHRoZSBOT05DRSBhbmQgUkVBTE0gcGFyYW1ldGVy cywgaW4gdGhlIGNhc2UgaWYgdGhlIGNsaWVudCBkb2VzIG5vdCBzdXBwb3J0cyBvQXV0aC4gQW5k IHdlIGhhdmUgdG8gbWVudGlvbiB0aGF0IGlmIHRoZSBjbGllbnQgZG9lcw0KIHN1cHBvcnQgb0F1 dGgsIHRoZW4gdGhlIGNsaWVudCBoYXMgdG8gaWdub3JlIHRob3NlIGF0dHJpYnV0ZXMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+VGhhbmtzPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFu IGNsYXNzPSJob2VuemIiPk9sZWc8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIFNlcCAxOCwgMjAx NCBhdCAxMTowOCBQTSwgT2xlZyBNb3NrYWxlbmtvICZsdDs8YSBocmVmPSJtYWlsdG86bW9tMDQw MjY3QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vbTA0MDI2N0BnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIGhh dmUgYW5vdGhlciBjb21tZW50LCBvbiBTZWN0aW9uIDYuMi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyBub3QgdGhpbmsgdGhhdCB0aGUgQUNDRVNTLVRP S0VOIG11c3QgYmUgYSBjb21wcmVoZW5zaW9uLW9wdGlvbmFsIGF0dHJpYnV0ZS4gVGhlIG9wdGlv bmFsIGF0dHJpYnV0ZXMgYXJlIHVzZWQgd2hlbiB0aGUgbWVzc2FnZSByZWNpcGllbnQgbWF5IGJl IG9mIGEgbGltaXRlZCBmdW5jdGlvbmFsaXR5IChsaWtlIGluIGJhY2t3YXJkIGNvbXBhdGliaWxp dHkgY2FzZXMgb3IgbWluaW1hbCBjbGllbnRzIG9yIG1pbmltYWwNCiBzZXJ2ZXJzKS4gVGhlcmUg YXJlIHR3byByZWFzb25zIHdoeSB0aGUgb3B0aW9uYWwgYXR0cmlidXRlIGRvZXMgbm90IGZpdCB3 ZWxsIGhlcmUgaW4gdGhlIGRpYWxvZzo8YnI+DQo8YnI+DQoxKSBXaGVuIHRoZSBjbGllbnQgc2Vu ZHMgdGhlIHJlcXVlc3Qgd2l0aCBBQ0NFU1MtVE9LRU4sIHRoZSBzZXJ2ZXIgYWxyZWFkeSBtYWRl IGEgY29tbWl0bWVudCB0aGF0IHRoZSBzZXJ2ZXIgdW5kZXJzdGFuZHMgdGhlIG9BdXRoIGNyZWRl bnRpYWxzIChieSBzZW5kaW5nIHRoZSBUSElSRC1QQVJUWS1BVVRIT1JJWkFUSU9OIGF0dHJpYnV0 ZSkuIFNvIHRoZSBzZXJ2ZXIgbWF5IG5vdCBiZSBhIGxlZ2FjeSBzZXJ2ZXIuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+MikgVGhlIG1lc3NhZ2UgY2Fubm90IGJlIGhhbmRsZWQgcHJvcGVybHkgaWYgdGhlIHNl cnZlciBkb2VzIG5vdCB1bmRlcnN0YW5kcyB0aGUgQUNDRVNTLVRPS0VOIC0gYmVjYXVzZSB0aGUg S0lEIGlzIG5vdCBhIHZhbGlkIHVzZXJuYW1lLCBhbnl3YXksIGFuZCB0aGUgc2VydmVyIGRvZXMg bm90IGtub3cgdGhlIG1hYyBldmVuIGlmIHNvbWVob3cgbWlyYWN1bG91c2x5DQogdGhlIHNlcnZl ciBoYWQgYSB1c2VybmFtZSB3aXRoIEtJRCBhcyB0aGUgdmFsdWUuIDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PklmIHRoZXJlIGFyZSB2YWxpZCByZWFzb25zIHdoeSB0aGUgQUNDRVNTLVRPS0VOIGlzIGEgY29t cHJlaGVuc2lvbi1vcHRpb25hbCBhdHRyaWJ1dGUsIEknZCBsaWtlIHRvIGhlYXIgdGhlbS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij5UaGFua3MgITxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQpP bGVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gVHVlLCBTZXAgMTYsIDIwMTQgYXQgMzoyMSBQTSwgT2xlZyBNb3NrYWxlbmtv ICZsdDs8YSBocmVmPSJtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm1vbTA0MDI2N0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5JJ2QgYWxzbyBzdWdnZXN0IHRvIGNyZWF0ZSBhbiBBcHBlbmRpeCwgd2l0aCB0aGUgY29udGVu dCBzaW1pbGFyIHRvIFJGQyA1NzY5LCB3aXRoIHRpY2tldCBlbmNvZGluZy9kZWNvZGluZyBzYW1w bGUgZXhhbXBsZXMuIFRoYXQgd291bGQgYmVuZWZpdCBib3RoIGNsaWVudCBhbmQgc2VydmVyIGlt cGxlbWVudGF0aW9ucywgdG8gYXZvaWQgYW1iaWd1aXR5IGFuZA0KIG1pc3VuZGVyc3RhbmRpbmdz LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8c3Bh biBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KT2xlZzxicj4NCiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gTW9uLCBTZXAgMTUsIDIwMTQgYXQgNToyNiBBTSwgU2ltb24gUGVycmVhdWx0ICZsdDs8YSBo cmVmPSJtYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNwZXJyZWF1 bHRAaml2ZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gTW9uLCBTZXAgMTUsIDIwMTQgYXQgNjozNCBBTSwgVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2Vjb25kLCBldmVuIHdpdGggdW5rbm93 biBub25jZSwga25vd2luZyB0aGUgZXhhY3Qgbm9uY2UgZmllbGQgcG9zaXRpb25zLCB0aGUgY2xp ZW50IHN0aWxsIGNhbiB0cnkgdGhlIHNhbWUgYXR0YWNrIC0gdGhlIGNsaWVudCB3aWxsIGp1c3Qg aWdub3JlIHRoZSBub25jZSBwb3NpdGlvbnMsIGFuZCB0aGUgY2xpZW50DQogd2lsbCBvYnRhaW4g dGhlIHNhbWUgYXR0YWNrIHJlc3VsdCBhcyB3aXRob3V0IHRoZSBub25jZSAod2l0aCB2ZXJ5IGhp Z2ggZGVncmVlIG9mIHByb2JhYmlsaXR5KS4gSWYgdGhlIGNsaWVudCBmaW5kcyBhIGtleSB0aGF0 IGRlY3J5cHRzIHByb3Blcmx5IGFsbCBwb3NpdGlvbnMgZXhjZXB0IHRoZSBub25jZSwgdGhlbiB0 aGUgY2xpZW50IGNhbiBiZSBhbG1vc3Qgc3VyZSB0aGF0IGhlIGZvdW5kIHRoZSByZWFsIGxvbmct dGVybSBrZXkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bVFJdIFl1cCwgdGhlIGNsaWVudCB3aWxsIGhhdmUgdG8gdHJ5IGFs bCBwb3NzaWJsZSBrZXkgY29tYmluYXRpb25zICgyIHRvIHRoZSBwb3dlciAyNTYga2V5IGNvbWJp bmF0aW9ucw0KIHdoaWNoIHRha2VzIHZlcnkgdmVyeSBsb25nIHRpbWUpIGFuZCBjaGVjayBpZiB0 aGUgZGVjcnlwdGVkIHRva2VuIG1hdGNoZXMgdGhlIHBsYWluIHRva2VuLiBMb29rcyBsaWtlIHdl IGRvbuKAmXQgaGF2ZSB0byBhZGRyZXNzIHRoaXMgYXR0YWNrLg0KPGEgaHJlZj0iaHR0cDovL2Vu Lndpa2lwZWRpYS5vcmcvd2lraS9UYWxrJTNBU2FsdF8lMjhjcnlwdG9ncmFwaHklMjkiIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvVGFsayUzQVNhbHRfJTI4 Y3J5cHRvZ3JhcGh5JTI5PC9hPiBtZW50aW9ucyB0aGF0IOKAnG1vZGVybiBjaXBoZXJzIHN1Y2gg YXMgQWR2YW5jZWQgRW5jcnlwdGlvbiBTdGFuZGFyZCBhcmUgbm90IHN1c2NlcHRpYmxlIHRvIGtu b3duLXBsYWludGV4dCBhdHRhY2tz4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KV2hhdGV2ZXIgeW91IGRlY2lkZSwgcGxlYXNlIG1l bnRpb24gaXQgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24sIGFuZCBleHBs YWluIHdoeSB5b3UgdGhpbmsgeW91ciBkZWNpc2lvbiBtYWtlcyBzZW5zZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2ltb248bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_913383AAA69FF945B8F946018B75898A2832BED1xmbrcdx10ciscoc_-- From nobody Fri Sep 19 06:37:49 2014 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 EFA811A0183 for ; Fri, 19 Sep 2014 06:37:46 -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 oHTduu9WFW_K for ; Fri, 19 Sep 2014 06:37:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB9B1A0199 for ; Fri, 19 Sep 2014 06:37:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140919133744.14808.8420.idtracker@ietfa.amsl.com> Date: Fri, 19 Sep 2014 06:37:44 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tram/V4znhCC_uU7ZEq4QvKHgFnMt4nc Subject: [tram] Milestones changed for tram WG X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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, 19 Sep 2014 13:37:47 -0000 URL: http://datatracker.ietf.org/wg/tram/charter/ From nobody Fri Sep 19 07:29:19 2014 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 01B391A019C for ; Fri, 19 Sep 2014 07:29:17 -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 Kd4y1JIAVuKC for ; Fri, 19 Sep 2014 07:29:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AABAD1A01C3 for ; Fri, 19 Sep 2014 07:29:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140919142914.17036.31392.idtracker@ietfa.amsl.com> Date: Fri, 19 Sep 2014 07:29:14 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tram/UnJAS8ZMpB5O91FKZML_n8_sPZw Subject: [tram] Milestones changed for tram WG X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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, 19 Sep 2014 14:29:17 -0000 Changed milestone "Send draft defining ALPN labels for STUN/TURN to IESG for publication as Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/tram/charter/ From nobody Fri Sep 19 08:28:20 2014 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 207BA1A016B for ; Fri, 19 Sep 2014 08:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 eTmXjrth3HfV for ; Fri, 19 Sep 2014 08:28:07 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA8331A011B for ; Fri, 19 Sep 2014 08:28:07 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id kx10so314578pab.33 for ; Fri, 19 Sep 2014 08:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=r9l8YEaSaOQFGOsP5HRYm6N8hZkbT9PJ/CBh9FalekU=; b=lmkwpiOovwjBjnFyyW2K0g+frQeXV1sByMyxeoWuzPlYi4PXLdKpuYk9vP43TByr2L 5TQs4UJjejU6fQFlIN09zOG9DV9jt9zyBrnpzO5Jh7pKkAqs0yh5IFqIeRnX+A2+UwZD wMhExucVRAkxksn6ULwyEfPkA43GrDRd9EFRfyP2ON+hIddY6pkEYKHsKdkx/2WZugWI 78o3mu6VoiPCjzBnQOt0SxUuYUQI7Y0/5LtfqwECgtzE9rv6LIcNGFlup+T39uoDfKvw COSXGKhHQDBB/QfXiiAMqQD9SEfuvSWs+NZVdsGyZ4y6yiL8VUWKIrVX9UAcEvOSUbyt 6Zgg== X-Received: by 10.67.1.9 with SMTP id bc9mr2784388pad.42.1411140486994; Fri, 19 Sep 2014 08:28:06 -0700 (PDT) Received: from [10.188.16.158] (232.sub-70-197-8.myvzw.com. [70.197.8.232]) by mx.google.com with ESMTPSA id rz8sm2168520pbc.63.2014.09.19.08.28.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Sep 2014 08:28:05 -0700 (PDT) References: <913383AAA69FF945B8F946018B75898A28328E81@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A28328F3F@xmb-rcd-x10.cisco.com>

<913383AAA69FF945B8F946018B75898A2832BED1@xmb-rcd-x10.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <913383AAA69FF945B8F946018B75898A2832BED1@xmb-rcd-x10.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-17F67A06-AAEA-437D-8AE3-2220AF7C05DD Content-Transfer-Encoding: 7bit Message-Id: <340AD494-81FF-436C-B7B9-0D2085FB1C8B@gmail.com> X-Mailer: iPhone Mail (11D201) From: Oleg Moskalenko Date: Fri, 19 Sep 2014 08:28:03 -0700 To: "Tirumaleswar Reddy (tireddy)" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/XY-c7Y5tGWfJl-ni4GqqMKUKmh8 Cc: Simon Perreault , "tram@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-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, 19 Sep 2014 15:28:10 -0000 --Apple-Mail-17F67A06-AAEA-437D-8AE3-2220AF7C05DD Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable OK, thanks ! Oleg Sent from my iPhone > On Sep 19, 2014, at 2:00 AM, "Tirumaleswar Reddy (tireddy)" wrote: >=20 > Hi Oleg, > =20 > Regarding your second comment, though Application provided TURN server may= only support third party authorization. But Enterprise provided TURN server= could support both first and third party authorization. This way client can= use third party authorization when it uses WebRTC/SIP servers that have bus= iness relationship with the Enterprise network and use first party authoriza= tion for non-business related calls. > =20 > TURN server in the challenge will include NONCE, REALM and THIRD_PARTY_AUT= HORIZATION attributes, client uses the TURN server name to determine if thir= d party authorization will work or not by cross-checking with the Authorizat= ion sever. If it works then client will proceed with third party authorizati= on or else continue with first party authentication. > =20 > -Tiru > =20 > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko > Sent: Friday, September 19, 2014 12:52 PM > To: Simon Perreault > Cc: Dan Wing (dwing); tram@ietf.org; Tirumaleswar Reddy (tireddy) > Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03 > =20 > Actually, my comments about NONCE and REALM are invalid, those attributes m= ust be used in oAuth in the same way as in usual long-term credentials. Scra= tch that. >=20 > Thanks > Oleg > =20 > On Thu, Sep 18, 2014 at 11:40 PM, Oleg Moskalenko wr= ote: > One more comment, about the section 3. >=20 > 1) It would be better to say in the text (or show it on the Figure 1), exp= licitly, that the error code of the "Allocate error response" is 401. We are= including the THIRD-PARTY-AUTHORIZATION attrbute only in the "challenge res= ponse", not in any error responses. > 2) In the challenge response, we have to mention that we are still includi= ng the NONCE and REALM parameters, in the case if the client does not suppor= ts oAuth. And we have to mention that if the client does support oAuth, then= the client has to ignore those attributes. >=20 > Thanks > Oleg >=20 > =20 > On Thu, Sep 18, 2014 at 11:08 PM, Oleg Moskalenko wr= ote: > I have another comment, on Section 6.2. >=20 > I do not think that the ACCESS-TOKEN must be a comprehension-optional attr= ibute. The optional attributes are used when the message recipient may be of= a limited functionality (like in backward compatibility cases or minimal cl= ients or minimal servers). There are two reasons why the optional attribute d= oes not fit well here in the dialog: >=20 > 1) When the client sends the request with ACCESS-TOKEN, the server already= made a commitment that the server understands the oAuth credentials (by sen= ding the THIRD-PARTY-AUTHORIZATION attribute). So the server may not be a le= gacy server. > 2) The message cannot be handled properly if the server does not understan= ds the ACCESS-TOKEN - because the KID is not a valid username, anyway, and t= he server does not know the mac even if somehow miraculously the server had a= username with KID as the value. >=20 > If there are valid reasons why the ACCESS-TOKEN is a comprehension-optiona= l attribute, I'd like to hear them. >=20 > Thanks ! > Oleg >=20 > =20 > =20 > On Tue, Sep 16, 2014 at 3:21 PM, Oleg Moskalenko wro= te: > I'd also suggest to create an Appendix, with the content similar to RFC 57= 69, with ticket encoding/decoding sample examples. That would benefit both c= lient and server implementations, to avoid ambiguity and misunderstandings. >=20 > Thanks > Oleg > =20 > =20 > On Mon, Sep 15, 2014 at 5:26 AM, Simon Perreault wro= te: > =20 > On Mon, Sep 15, 2014 at 6:34 AM, Tirumaleswar Reddy (tireddy) wrote: > Second, even with unknown nonce, knowing the exact nonce field positions, t= he client still can try the same attack - the client will just ignore the no= nce positions, and the client will obtain the same attack result as without t= he nonce (with very high degree of probability). If the client finds a key t= hat decrypts properly all positions except the nonce, then the client can be= almost sure that he found the real long-term key. > =20 > [TR] Yup, the client will have to try all possible key combinations (2 to t= he power 256 key combinations which takes very very long time) and check if t= he decrypted token matches the plain token. Looks like we don=92t have to ad= dress this attack. http://en.wikipedia.org/wiki/Talk%3ASalt_%28cryptography%= 29 mentions that =93modern ciphers such as Advanced Encryption Standard are n= ot susceptible to known-plaintext attacks=94. >=20 > Whatever you decide, please mention it in the Security Considerations sect= ion, and explain why you think your decision makes sense. > =20 > Thanks, > Simon > =20 > =20 > =20 > =20 --Apple-Mail-17F67A06-AAEA-437D-8AE3-2220AF7C05DD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

OK, thanks !

= Oleg

Sent from my iPhone

On Sep 19, 2014, at 2:00 AM, "= Tirumaleswar Reddy (tireddy)" <tired= dy@cisco.com> wrote:

Hi Oleg,<= /p>

Regarding your second comme= nt, though Application provided TURN server may only support third party aut= horization. But Enterprise provided TURN server could support both first and third party authorization. This way client can use t= hird party authorization when it uses WebRTC/SIP servers that have business r= elationship with the Enterprise network and use first party authorization fo= r non-business related calls.

TURN server in the challeng= e will include NONCE, REALM and THIRD_PARTY_AUTHORIZATION attributes, client= uses the TURN server name to determine if third party authorization will work or not by cross-checking with the Authorization sev= er. If it works then client will proceed with third party authorization or e= lse continue with first party authentication.

-Tiru
=

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Friday, September 19, 2014 12:52 PM
To: Simon Perreault
Cc: Dan Wing (dwing); tram@ietf.org<= /a>; Tirumaleswar Reddy (tireddy)
Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03

Actually, my comments about NONCE and REALM are inval= id, those attributes must be used in oAuth in the same way as in usual long-= term credentials. Scratch that.

Thanks
Oleg

On Thu, Sep 18, 2014 at 11:40 PM, Oleg Moskalenko <= ;mom040267@gmail.co= m> wrote:

One more comment, abou= t the section 3.

1) It would be better to say in the text (or show it o= n the Figure 1), explicitly, that the error code of the "Allocate error resp= onse" is 401. We are including the THIRD-PARTY-AUTHORIZATION attrbute only i= n the "challenge response", not in any error responses.

2) In the challenge re= sponse, we have to mention that we are still including the NONCE and REALM p= arameters, in the case if the client does not supports oAuth. And we have to= mention that if the client does support oAuth, then the client has to ignore those attributes.

Thanks
Oleg

On Thu, Sep 18, 2014 at 11:08 PM, Oleg Moskalenko <= ;mom040267@gmail.co= m> wrote:

I have another comment= , on Section 6.2.

I do not think that the ACCESS-TOKEN must be a compre= hension-optional attribute. The optional attributes are used when the messag= e recipient may be of a limited functionality (like in backward compatibilit= y cases or minimal clients or minimal servers). There are two reasons why the optional attribute does not fit wel= l here in the dialog:

1) When the client sends the request with ACCESS-TOKEN, the server already m= ade a commitment that the server understands the oAuth credentials (by sendi= ng the THIRD-PARTY-AUTHORIZATION attribute). So the server may not be a lega= cy server.

2) The message cannot b= e handled properly if the server does not understands the ACCESS-TOKEN - bec= ause the KID is not a valid username, anyway, and the server does not know t= he mac even if somehow miraculously the server had a username with KID as the value.

If there are valid rea= sons why the ACCESS-TOKEN is a comprehension-optional attribute, I'd like to= hear them.

Thanks !
Oleg

On Tue, Sep 16, 2014 at 3:21 PM, Oleg Moskalenko <= mom040267@gmail.com= > wrote:

I'd also suggest to cr= eate an Appendix, with the content similar to RFC 5769, with ticket encoding= /decoding sample examples. That would benefit both client and server impleme= ntations, to avoid ambiguity and misunderstandings.

Thanks
Oleg

On Mon, Sep 15, 2014 at 5:26 AM, Simon Perreault <= sperreault@jive.com= > wrote:

On Mon, Sep 15, 2014 at 6:34 AM, Tirumaleswar Reddy (= tireddy) <tireddy@= cisco.com> wrote:

Second, even with unknown nonce, knowing the exact nonce field posit= ions, the client still can try the same attack - the client will just ignore= the nonce positions, and the client will obtain the same attack result as without the nonce (with very high deg= ree of probability). If the client finds a key that decrypts properly all po= sitions except the nonce, then the client can be almost sure that he found t= he real long-term key.

[TR] Yup, the client will have to try all p= ossible key combinations (2 to the power 256 key combinations which takes very very long time) and check if the decrypted token matches t= he plain token. Looks like we don=E2=80=99t have to address this attack. http://en.wikipedia.org/wiki/Talk%3ASalt_%28cryptography%29 mentions tha= t =E2=80=9Cmodern ciphers such as Advanced Encryption Standard are not susce= ptible to known-plaintext attacks=E2=80=9D.

Whatever you decide, please mention it in the Security Considerations sectio= n, and explain why you think your decision makes sense.

Thanks,

Simon

= --Apple-Mail-17F67A06-AAEA-437D-8AE3-2220AF7C05DD-- From nobody Fri Sep 19 15:13:52 2014 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 128401A88E0 for ; Fri, 19 Sep 2014 15:13:51 -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 FvqsontiisaX for ; Fri, 19 Sep 2014 15:13:49 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66E2B1A88D2 for ; Fri, 19 Sep 2014 15:13:49 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id l4so3954875lbv.2 for ; Fri, 19 Sep 2014 15:13:47 -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=U6Vgzz7K9yrc8/iyh9m76mdpdBnwmedoPhKlGT3CYUU=; b=IMMIU84TqBN/lTynG9g2ORRudZ/FA1ffbh7RHPwHaxc+wKllZWwztcdm3XmqUnkvz6 hrifTZ3fdFPZ1u5OuZSpjCM1QO87iXrHPBEWex7auuZvNoIjA4JAP4nFKwLA0nYbCVCF t2fNwOZDvWfdhiNGYlUkKzvzye87IpJnzSZM/D3dcXkQf0YMks9IqD044KwE8NOtdo0p c9op4pPI/oloA49EKwWysZUuTq9nJPnzLj5nKrXHKNXw5dUUTQlQYXEnP3Lcc9yt7evP ULikYFelErNJNj0MhoM43LM5JiKyfknjKrQrd6fDP9pgisjDYxvXW4ycjYmtwK+3vQ0F dQYw== MIME-Version: 1.0 X-Received: by 10.112.202.1 with SMTP id ke1mr9048565lbc.33.1411164827701; Fri, 19 Sep 2014 15:13:47 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Fri, 19 Sep 2014 15:13:47 -0700 (PDT) In-Reply-To: References:

Date: Fri, 19 Sep 2014 15:13:47 -0700 Message-ID: From: Martin Thomson To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/CST7FApQBA9pKsVUucsfYC8KpXk Cc: "Prashanth Patil \(praspati\)" , Gonzalo Salgueiro , "tram@ietf.org" Subject: Re: [tram] WGLC draft-ietf-tram-alpn-00 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, 19 Sep 2014 22:13:51 -0000 On 18 September 2014 08:04, Simon Perreault wrote: > Agreed. But can we agree that if someone did want to do it, one could > rightfully expect it to work? I would say that when someone chooses to do that, the application that they are using should then ask for a new identifier. If you don't care to identify your application properly, how about you not use ALPN? From nobody Sun Sep 21 04:37:26 2014 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 DCC2D1A00AD for ; Sun, 21 Sep 2014 04:37:08 -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 0WojIhEkdcFU for ; Sun, 21 Sep 2014 04:37:07 -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 572901A00AB for ; Sun, 21 Sep 2014 04:37:06 -0700 (PDT) Received: from [IPv6:2001:470:40b8:0:8cdd:5a8b:e63e:1892] (unknown [IPv6:2001:470:40b8:0:8cdd:5a8b:e63e:1892]) (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 041AB2154A for ; Sun, 21 Sep 2014 13:37:03 +0200 (CEST) Message-ID: <541EB85D.90609@acm.org> Date: Sun, 21 Sep 2014 05:37:01 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.0 MIME-Version: 1.0 To: "tram@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/CXcesovgd2pI1c8Xy1Ffwen-euQ Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-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: Sun, 21 Sep 2014 11:37:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/10/2014 06:18 AM, Simon Perreault wrote: > TRAMsters, > > This email initiates a two-week working-group last call on this draft: > > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-03 > > Please read it now. Substantial comments should be addressed to the group. > Nits should be sent directly to the authors. > Before even starting talking about the details about 3rd party authorization, I have an issue about how this authorization scheme is presented in this draft. RFC 5389 defines two authentication mechanisms, a Short-Term Credential Mechanism (STCM) in section 10.1 and a Long-Term Credential Mechanism (LTCM) in section 10.2. None of these mechanisms are tied to a specific STUN usage, although, even at the time RFC 5389 was written, it was clear that STCM was designed to be used with ICE and LTCM with TURN. The RFC 5389 authors, who are IETF veterans, knew that the IETF does not provides protocol for applications, but building blocks, and these two sections reflects exactly that. Now my beef with draft-ietf-tram-turn-third-party-authz is that it is written as providing a protocol for an application, but not as a building block. It should have be written in the same spirit than section 10.1 or 10.2 of RFC 5389, i.e. as a generic authentication mechanism with different properties than these two. So my advice is to completely rewrite this draft to make it independent of TURN, and make it just another STUN Credential Mechanism (let's call it 3rd Party Credential Mechanism, 3PCM). Then we can have a separate section (or, better, a separate draft) that modifies TURN to use 3PCM as a replacement for LTCM. I'll do a more complete review if and when this rewrite will be done. Until then I do not support the publication of this draft in this form. 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 v1 iQIcBAEBCAAGBQJUHrhcAAoJECnERZXWan7EbKIP/jM282eKSOYViBY8qeUsCfO8 4U+Ar3CGWXqeUCbsB8K7DvQppZY+R7b9/j7yv0sVWgIo9vTlt758Vf660Ag4XFK0 hhJC55g9PeNRqRcKQlpp2m9/rMpuHPY95GKd7+PaczJ2Q/8NIUb0/XeBIX9+V5MM 48Y4pd/bfndwPHEUWHh+ypljqcClzaYsAA/jxmoO5vJPnipNIficvSxj4MB703Yq UPxc98hDsu3yU+5/aAjLkCz1tbj41uGmTenYCywFHTEYRAZZPw+1u0qHffsOEcOK JIIk9EELcaWZ0YE2aAKUfnKs/G45+/JCKAYw1/jr4CjdatgV8GJPMfq+gbUW15n+ N9744LbUxarokc/N0Ey07gB2rihtVhoQLeC9YGUj6KGoNNb2PukCTE7l8FbRIMWX OrfuppEhZjn2KzZyPw9mvtoeoDHz+lYwyYRKHsrz/mw7n8OVy+gwSHsvlLRGiI1D h6vPkTHeqI5jThgfcK5ffVGMNrHIhoSghMzWE2Lul54pm3f/kDucQ8klluqL1mAt MdrmO95jyGs7QlOrHpVRM+vgnWrufG8332Q26BL0vPqWwTKE3i0tiGYinS2xiaL0 FaRFvhUuuzv+jwapsKJfWhgo9Nb0MiO0ElF34RFooCzkFToCn3FvUzCZirbny1TS HdCDNaA9A5U63rVgkv8e =62Q8 -----END PGP SIGNATURE----- From nobody Sun Sep 21 10:03:17 2014 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 C15391A010D for ; Sun, 21 Sep 2014 10:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 yQESFsHL6SWr for ; Sun, 21 Sep 2014 10:03:13 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646651A00BF for ; Sun, 21 Sep 2014 10:03:13 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id fb4so1694336wid.0 for ; Sun, 21 Sep 2014 10:03:11 -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=RKjBLhYe1669KBIpW/hf2aqDngnqUitQ9JPjx6AAHfw=; b=dHdsp8BZLXDhmlTgajf3sqYLppPwixKybOp4zR7kLkFlGR1lrSbcsRgEPgk0odBxbs 8XulAxUbeaxPH4ydoXV0WuVlTuL+zgAF6ZZPhWiva/UeZBTM5uBFTu/1G7pYaN6RG752 vm34EbmkcuwJtCjXDsWLbLQul3nTOmC7HYZs9DjpAqmUY7lRQhdnvDvySDf9FfG6CXA9 5yVjKIbgcE4Ueiw0/O1060TYhJkedWKiebJGc6E59E/6tS6j/CHdMVTyRH6Bqj3LjYt0 AS/1fwrb90dRrLMOcZMe1i3/55Ehuh6qDMNQNiddjzYqdbqQQNMW7cYDLsTl5m1gueg7 2t1A== MIME-Version: 1.0 X-Received: by 10.180.90.207 with SMTP id by15mr10180415wib.76.1411318991725; Sun, 21 Sep 2014 10:03:11 -0700 (PDT) Received: by 10.194.67.167 with HTTP; Sun, 21 Sep 2014 10:03:11 -0700 (PDT) In-Reply-To: <541EB85D.90609@acm.org> References: <541EB85D.90609@acm.org> Date: Sun, 21 Sep 2014 10:03:11 -0700 Message-ID: From: Oleg Moskalenko To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=f46d043c80462aa9790503964f0f Archived-At: http://mailarchive.ietf.org/arch/msg/tram/4URljfn9c2IKDghqWXV-267q5JU Cc: "tram@ietf.org" Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-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: Sun, 21 Sep 2014 17:03:15 -0000 --f46d043c80462aa9790503964f0f Content-Type: text/plain; charset=UTF-8 I am not sure that "3PCM" can be distinguished as an independent replacement for "LTCM". I rather view 3PCM as a variation/extension/evolution of LTCM. A third-party authorization server can be used with LTCM as-is, but that would be somewhat complicated and unnatural. The 3PCM draft proposed an extension to LTCM that allows natural convenient way of using a third-party server. The draft could be re-worded to eliminate tight connection to TURN, if that's absolutely necessary. Oleg On Sun, Sep 21, 2014 at 4:37 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 09/10/2014 06:18 AM, Simon Perreault wrote: > > TRAMsters, > > > > This email initiates a two-week working-group last call on this draft: > > > > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-03 > > > > Please read it now. Substantial comments should be addressed to the > group. > > Nits should be sent directly to the authors. > > > > Before even starting talking about the details about 3rd party > authorization, > I have an issue about how this authorization scheme is presented in this > draft. > > RFC 5389 defines two authentication mechanisms, a Short-Term Credential > Mechanism (STCM) in section 10.1 and a Long-Term Credential Mechanism > (LTCM) > in section 10.2. None of these mechanisms are tied to a specific STUN > usage, > although, even at the time RFC 5389 was written, it was clear that STCM was > designed to be used with ICE and LTCM with TURN. The RFC 5389 authors, who > are IETF veterans, knew that the IETF does not provides protocol for > applications, but building blocks, and these two sections reflects exactly > that. > > Now my beef with draft-ietf-tram-turn-third-party-authz is that it is > written > as providing a protocol for an application, but not as a building block. > It > should have be written in the same spirit than section 10.1 or 10.2 of RFC > 5389, i.e. as a generic authentication mechanism with different properties > than these two. > > So my advice is to completely rewrite this draft to make it independent of > TURN, and make it just another STUN Credential Mechanism (let's call it 3rd > Party Credential Mechanism, 3PCM). > > Then we can have a separate section (or, better, a separate draft) that > modifies TURN to use 3PCM as a replacement for LTCM. > > I'll do a more complete review if and when this rewrite will be done. > Until > then I do not support the publication of this draft in this form. > > 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 v1 > > iQIcBAEBCAAGBQJUHrhcAAoJECnERZXWan7EbKIP/jM282eKSOYViBY8qeUsCfO8 > 4U+Ar3CGWXqeUCbsB8K7DvQppZY+R7b9/j7yv0sVWgIo9vTlt758Vf660Ag4XFK0 > hhJC55g9PeNRqRcKQlpp2m9/rMpuHPY95GKd7+PaczJ2Q/8NIUb0/XeBIX9+V5MM > 48Y4pd/bfndwPHEUWHh+ypljqcClzaYsAA/jxmoO5vJPnipNIficvSxj4MB703Yq > UPxc98hDsu3yU+5/aAjLkCz1tbj41uGmTenYCywFHTEYRAZZPw+1u0qHffsOEcOK > JIIk9EELcaWZ0YE2aAKUfnKs/G45+/JCKAYw1/jr4CjdatgV8GJPMfq+gbUW15n+ > N9744LbUxarokc/N0Ey07gB2rihtVhoQLeC9YGUj6KGoNNb2PukCTE7l8FbRIMWX > OrfuppEhZjn2KzZyPw9mvtoeoDHz+lYwyYRKHsrz/mw7n8OVy+gwSHsvlLRGiI1D > h6vPkTHeqI5jThgfcK5ffVGMNrHIhoSghMzWE2Lul54pm3f/kDucQ8klluqL1mAt > MdrmO95jyGs7QlOrHpVRM+vgnWrufG8332Q26BL0vPqWwTKE3i0tiGYinS2xiaL0 > FaRFvhUuuzv+jwapsKJfWhgo9Nb0MiO0ElF34RFooCzkFToCn3FvUzCZirbny1TS > HdCDNaA9A5U63rVgkv8e > =62Q8 > -----END PGP SIGNATURE----- > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --f46d043c80462aa9790503964f0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I am not sure that "3PCM" can be = distinguished as an independent replacement for "LTCM". I rather = view 3PCM as a variation/extension/evolution of LTCM.

A third= -party authorization server can be used with LTCM as-is, but that would be = somewhat complicated and unnatural. The 3PCM draft proposed an extension to= LTCM that allows natural convenient way of using a third-party server.

The draft could be re-worded to eliminate tight connection to TU= RN, if that's absolutely necessary.

Oleg

On Sun, Sep 21, 2014 at 4:37 AM, Marc Petit-Huguenin <petithug@acm.org= > wrote:

-----BEGIN PGP SIG= NED MESSAGE-----
Hash: SHA256

On 09/10/2014 06:18 AM, Simon Perreault wrote:
> TRAMsters,
>
> This email initiates a two-week working-group last call on this draft:=
>
> http://tools.ietf.org/html/draft-ietf-tram-tur= n-third-party-authz-03
>
> Please read it now. Substantial comments should be addressed to the gr= oup.
> Nits should be sent directly to the authors.
>

Before even starting talking about the details about 3rd party = authorization,
I have an issue about how this authorization scheme is presented in this dr= aft.

RFC 5389 defines two authentication mechanisms, a Short-Term Credential
Mechanism (STCM) in section 10.1 and a Long-Term Credential Mechanism (LTCM= )
in section 10.2.=C2=A0 None of these mechanisms are tied to a specific STUN= usage,
although, even at the time RFC 5389 was written, it was clear that STCM was=
designed to be used with ICE and LTCM with TURN.=C2=A0 The RFC 5389 authors= , who
are IETF veterans, knew that the IETF does not provides protocol for
applications, but building blocks, and these two sections reflects exactly = that.

Now my beef with draft-ietf-tram-turn-third-party-authz is that it is writt= en
as providing a protocol for an application, but not as a building block.=C2= =A0 It
should have be written in the same spirit than section 10.1 or 10.2 of RFC<= br> 5389, i.e. as a generic authentication mechanism with different properties<= br> than these two.

So my advice is to completely rewrite this draft to make it independent of<= br> TURN, and make it just another STUN Credential Mechanism (let's call it= 3rd
Party Credential Mechanism, 3PCM).

Then we can have a separate section (or, better, a separate draft) that
modifies TURN to use 3PCM as a replacement for LTCM.

I'll do a more complete review if and when this rewrite will be done.= =C2=A0 Until
then I do not support the publication of this draft in this form.

Thanks.

- --
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: htt= p://blog.marc.petit-huguenin.org
Profile: = http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUHrhcAAoJECnERZXWan7EbKIP/jM282eKSOYViBY8qeUsCfO8
4U+Ar3CGWXqeUCbsB8K7DvQppZY+R7b9/j7yv0sVWgIo9vTlt758Vf660Ag4XFK0
hhJC55g9PeNRqRcKQlpp2m9/rMpuHPY95GKd7+PaczJ2Q/8NIUb0/XeBIX9+V5MM
48Y4pd/bfndwPHEUWHh+ypljqcClzaYsAA/jxmoO5vJPnipNIficvSxj4MB703Yq
UPxc98hDsu3yU+5/aAjLkCz1tbj41uGmTenYCywFHTEYRAZZPw+1u0qHffsOEcOK
JIIk9EELcaWZ0YE2aAKUfnKs/G45+/JCKAYw1/jr4CjdatgV8GJPMfq+gbUW15n+
N9744LbUxarokc/N0Ey07gB2rihtVhoQLeC9YGUj6KGoNNb2PukCTE7l8FbRIMWX
OrfuppEhZjn2KzZyPw9mvtoeoDHz+lYwyYRKHsrz/mw7n8OVy+gwSHsvlLRGiI1D
h6vPkTHeqI5jThgfcK5ffVGMNrHIhoSghMzWE2Lul54pm3f/kDucQ8klluqL1mAt
MdrmO95jyGs7QlOrHpVRM+vgnWrufG8332Q26BL0vPqWwTKE3i0tiGYinS2xiaL0
FaRFvhUuuzv+jwapsKJfWhgo9Nb0MiO0ElF34RFooCzkFToCn3FvUzCZirbny1TS
HdCDNaA9A5U63rVgkv8e
=3D62Q8
-----END PGP SIGNATURE-----

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

--f46d043c80462aa9790503964f0f-- From nobody Sun Sep 21 11:04:26 2014 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 A36B81A033C for ; Sun, 21 Sep 2014 11:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ym73cx95hmY6 for ; Sun, 21 Sep 2014 11:04:23 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE831A0183 for ; Sun, 21 Sep 2014 11:04:22 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id 10so3833849lbg.32 for ; Sun, 21 Sep 2014 11:04:21 -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=nPQKup0fCppDBax+AfJ8jAv5MiHjgwg30RdMsQT/I4s=; b=PGOXq7jPnsp17pt2TOrDmJXVGMYgqNqONP4Nav1PhHZ0v5BtJwlXXYRCPTP6eXgAPC Ig2094GyPXWeJXtIjX+Ef2uQkereDCTYadGYJoQ3tpPKq5jIVGvtizdS43N/yqLhWvEd 8nCp5WTGusvb6RcholHYEBHFTNgnKzJyPLx+fXdDyXVcM3WfclFdF8IpUXcCEycciEz/ rXF3iI/xK3e9p180po8mUi+5Z/EuSfDlBnTy5xXa6wPDKF6SPoCt8Tzm39kf+iU+4rDh gu+Ofmmi50bhOnr8r8T88QCCMCPeBJ9MnPcguMxK5SpnWz5+qnpYe31N9t0USofZmyQc 5+VQ== X-Gm-Message-State: ALoCoQmghmqGAWSqjp07dyDENgMoBtZQM4HZIsFOAvRkvaLF/WwiKUrRID2eu1AoopcbvViysCfG MIME-Version: 1.0 X-Received: by 10.112.210.197 with SMTP id mw5mr19911117lbc.20.1411322661019; Sun, 21 Sep 2014 11:04:21 -0700 (PDT) Received: by 10.25.137.193 with HTTP; Sun, 21 Sep 2014 11:04:20 -0700 (PDT) Received: by 10.25.137.193 with HTTP; Sun, 21 Sep 2014 11:04:20 -0700 (PDT) In-Reply-To: References:

Date: Sun, 21 Sep 2014 14:04:20 -0400 Message-ID: From: Simon Perreault To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c3c7dcdfea5f05039729d7 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/7lYvhsO-xxG0FK_gZRzp_1diRUk Cc: "Prashanth Patil \(praspati\)" , "Gonzalo Salgueiro \(gsalguei\)" , "tram@ietf.org" Subject: Re: [tram] WGLC draft-ietf-tram-alpn-00 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, 21 Sep 2014 18:04:24 -0000 --001a11c3c7dcdfea5f05039729d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As individual participant, I don't find this argument convincing. No game developer would spend energy getting his own label, even if the registry was FCFS. Also, I think that a "stun" label is still providing information that could be somewhat valuable. But I also don't think that this is an important issue. Now, as chair I think we're starting to rehash the same arguments, and I think we should move on. To me, the most sensible course of action if we don't reach consensus would be to do nothing, i.e., not define a "stun" label. We can always revisit this issue later if it becomes a pain point. For now I think everyone can live without it. Can anyone not live with this course of action? Simon Le 2014-09-19 18:13, "Martin Thomson" a =C3=A9cr= it : > On 18 September 2014 08:04, Simon Perreault wrote: > > Agreed. But can we agree that if someone did want to do it, one could > > rightfully expect it to work? > > I would say that when someone chooses to do that, the application that > they are using should then ask for a new identifier. > > If you don't care to identify your application properly, how about you > not use ALPN? > --001a11c3c7dcdfea5f05039729d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

As individual participant, I don't find this argument co= nvincing. No game developer would spend energy getting his own label, even = if the registry was FCFS. Also, I think that a "stun" label is st= ill providing information that could be somewhat valuable. But I also don&#= 39;t think that this is an important issue.

Now, as chair I think we're starting to rehash the same = arguments, and I think we should move on. To me, the most sensible course o= f action if we don't reach consensus would be to do nothing, i.e., not = define a "stun" label. We can always revisit this issue later if = it becomes a pain point. For now I think everyone can live without it.

Can anyone not live with this course of action?

Simon

Le 2014-09-19 18:13, "Martin Thomson" = <martin.thomson@gmail.com> a =C3=A9crit :

On 18 September 2014 08:04, Simon Perreault <sperreault@jive.com> wrote:
> Agreed. But can we agree that if someone did want to do it, one could<= br> > rightfully expect it to work?

I would say that when someone chooses to do that, the application that
they are using should then ask for a new identifier.

If you don't care to identify your application properly, how about you<= br> not use ALPN?

--001a11c3c7dcdfea5f05039729d7-- From nobody Sun Sep 21 22:05:17 2014 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 D839C1A1A22 for ; Sun, 21 Sep 2014 22:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 DLsREzwMV9ps for ; Sun, 21 Sep 2014 22:05:04 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D891A1A1E for ; Sun, 21 Sep 2014 22:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3823; q=dns/txt; s=iport; t=1411362302; x=1412571902; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=FZnWpnE9WWP7uPuq9faTrVjJDpviOpLJmgdGWWBs2y4=; b=hceTCK+/kurN1gRlSd+Jid0weEOa9DUXmR7j0UnDvqnYfhAxwVX2pS5Q 5uqS+dFrly2Eu3/N7yBEkBq8EUX0kJS7+I+k9bsxssBXOdUc8V9reZtV9 nOKDtc5gXIJhn2cgxscriRdevsnoi9QxeH3E5RV1ZvhX4UyF2tVerse7e A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFANisH1StJV2Z/2dsb2JhbABggw5TW8oYCodNAYEEFgF5hAMBAQEEAQEBNzQXBAIBCBEEAQEBChQJBycLFAkIAgQBEgiINg3DMAEXjUaBXhEBHzgGgyiBHQWRV4Q4iGiTcYFrHYFZbAGBDjmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,570,1406592000"; d="scan'208";a="356848171" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 22 Sep 2014 05:05:01 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8M551wf023460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 05:05:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 00:05:00 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Marc Petit-Huguenin , "tram@ietf.org" Thread-Topic: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03 Thread-Index: AQHPzPFgAS/DFhCXG0+VG6pmuTD3zpwL2qaAgADQ5LA= Date: Mon, 22 Sep 2014 05:05:00 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2832C997@xmb-rcd-x10.cisco.com> References: <541EB85D.90609@acm.org> In-Reply-To: <541EB85D.90609@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.64.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/gPNBjIHoG5dd0Jng6zhEGcIvIKY Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-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, 22 Sep 2014 05:05:13 -0000 Third party authorization is relevant to TURN server usage and don't see a = need for STUN server on the Internet to support it. If at all there is a u= se case for third party authorization in future with STUN=20 server then the mechanism proposed in the draft will also work with STUN se= rver. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Marc Petit- > Huguenin > Sent: Sunday, September 21, 2014 5:07 PM > To: tram@ietf.org > Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 09/10/2014 06:18 AM, Simon Perreault wrote: > > TRAMsters, > > > > This email initiates a two-week working-group last call on this draft: > > > > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-03 > > > > Please read it now. Substantial comments should be addressed to the > group. > > Nits should be sent directly to the authors. > > >=20 > Before even starting talking about the details about 3rd party authorizat= ion, > I have an issue about how this authorization scheme is presented in this > draft. >=20 > RFC 5389 defines two authentication mechanisms, a Short-Term Credential > Mechanism (STCM) in section 10.1 and a Long-Term Credential Mechanism > (LTCM) > in section 10.2. None of these mechanisms are tied to a specific STUN us= age, > although, even at the time RFC 5389 was written, it was clear that STCM w= as > designed to be used with ICE and LTCM with TURN. The RFC 5389 authors, > who > are IETF veterans, knew that the IETF does not provides protocol for > applications, but building blocks, and these two sections reflects exactl= y that. >=20 > Now my beef with draft-ietf-tram-turn-third-party-authz is that it is wri= tten > as providing a protocol for an application, but not as a building block. = It > should have be written in the same spirit than section 10.1 or 10.2 of RF= C > 5389, i.e. as a generic authentication mechanism with different propertie= s > than these two. >=20 > So my advice is to completely rewrite this draft to make it independent o= f > TURN, and make it just another STUN Credential Mechanism (let's call it 3= rd > Party Credential Mechanism, 3PCM). >=20 > Then we can have a separate section (or, better, a separate draft) that > modifies TURN to use 3PCM as a replacement for LTCM. >=20 > I'll do a more complete review if and when this rewrite will be done. Un= til > then I do not support the publication of this draft in this form. >=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 v1 >=20 > iQIcBAEBCAAGBQJUHrhcAAoJECnERZXWan7EbKIP/jM282eKSOYViBY8qeUsCf > O8 > 4U+Ar3CGWXqeUCbsB8K7DvQppZY+R7b9/j7yv0sVWgIo9vTlt758Vf660Ag4XFK > 0 > hhJC55g9PeNRqRcKQlpp2m9/rMpuHPY95GKd7+PaczJ2Q/8NIUb0/XeBIX9+V5 > MM > 48Y4pd/bfndwPHEUWHh+ypljqcClzaYsAA/jxmoO5vJPnipNIficvSxj4MB703Yq > UPxc98hDsu3yU+5/aAjLkCz1tbj41uGmTenYCywFHTEYRAZZPw+1u0qHffsOEcO > K > JIIk9EELcaWZ0YE2aAKUfnKs/G45+/JCKAYw1/jr4CjdatgV8GJPMfq+gbUW15n+ > N9744LbUxarokc/N0Ey07gB2rihtVhoQLeC9YGUj6KGoNNb2PukCTE7l8FbRIMW > X > OrfuppEhZjn2KzZyPw9mvtoeoDHz+lYwyYRKHsrz/mw7n8OVy+gwSHsvlLRGiI1 > D > h6vPkTHeqI5jThgfcK5ffVGMNrHIhoSghMzWE2Lul54pm3f/kDucQ8klluqL1mAt > MdrmO95jyGs7QlOrHpVRM+vgnWrufG8332Q26BL0vPqWwTKE3i0tiGYinS2xia > L0 > FaRFvhUuuzv+jwapsKJfWhgo9Nb0MiO0ElF34RFooCzkFToCn3FvUzCZirbny1TS > HdCDNaA9A5U63rVgkv8e > =3D62Q8 > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Sep 22 05:52:01 2014 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 E0B1B1A00D0 for ; Mon, 22 Sep 2014 05:51:59 -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=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 zSjIg46WGDc5 for ; Mon, 22 Sep 2014 05:51:58 -0700 (PDT) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C5D1A00B7 for ; Mon, 22 Sep 2014 05:51:57 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id el20so216600lab.18 for ; Mon, 22 Sep 2014 05:51:55 -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=mVmyojGqlhMDXx/QiZz5NFydgdszaX+ugolEZaKU6E0=; b=CvQzJ0oShiQZLvzL2xjhxwnQurkxJdVKo6ncMyU9xpN5uAakuYBqWMhCkvtVj853gU Aw2pnm28vM0gLoyVxrgURnr3BBe6/V5beqEs9vtU59bt0TA6ouNAn1Gmzzn+lMK4m3aN N/fgi5VKEvjwMyR3+1/uotNwVIJrN/UyiducyGcuvr1xMEeSgmRjQ8gRxJN17BVCNgL0 AapUpO0YZGskAJyYz6vLXNwTe1w6oy8REXcuIfF7MwtZYEY7bpEgQIZpPV6MwR3MlAvZ AWbckxuYMITVnz5p8pJ+OVdsRKHxTdsn2dKNXntVsCsAm3RhndC5nAA7m1amMg3JCFYE zz9w== X-Gm-Message-State: ALoCoQnCHROLraZsEt9k2Een0KtoKA+d8B4U6x3bQoEY8FtRXDHP5e/Vb8KFjp5bQFbAaAvUWpLX MIME-Version: 1.0 X-Received: by 10.152.21.168 with SMTP id w8mr26007862lae.59.1411390315690; Mon, 22 Sep 2014 05:51:55 -0700 (PDT) Received: by 10.25.137.193 with HTTP; Mon, 22 Sep 2014 05:51:55 -0700 (PDT) In-Reply-To: References: <541EB85D.90609@acm.org> Date: Mon, 22 Sep 2014 08:51:55 -0400 Message-ID: From: Simon Perreault To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=089e0158ad546810fe0503a6eac8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/gSMFZBQ3gZ9yWadENhuTLT4pLOI Cc: Marc Petit-Huguenin , "tram@ietf.org" Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-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, 22 Sep 2014 12:52:00 -0000 --089e0158ad546810fe0503a6eac8 Content-Type: text/plain; charset=UTF-8 On Sun, Sep 21, 2014 at 1:03 PM, Oleg Moskalenko wrote: > I am not sure that "3PCM" can be distinguished as an independent > replacement for "LTCM". I rather view 3PCM as a > variation/extension/evolution of LTCM. > Does that really matter? Whether you're using 3PCM or LTCM is easily determined by looking at the packets. That's what matters. If the protocol is different, then as far as we're concerned they're different things. A third-party authorization server can be used with LTCM as-is, but that > would be somewhat complicated and unnatural. The 3PCM draft proposed an > extension to LTCM that allows natural convenient way of using a third-party > server. > Correct, but again I don't see why that matters. The draft could be re-worded to eliminate tight connection to TURN, if > that's absolutely necessary. I don't think it's "absolutely necessary", but I think it's very desirable. I've been saying it since the beginning: this authentication mechanism is for STUN, not for TURN. I fully agree with Marc's comment. Although I don't think the draft needs a "rewrite". A careful search & replace should be sufficient to make the text TURN-agnostic. Simon --089e0158ad546810fe0503a6eac8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Sep 21, 2014 at 1:03 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:

I am not su= re that "3PCM" can be distinguished as an independent replacement= for "LTCM". I rather view 3PCM as a variation/extension/evolutio= n of LTCM.

Does that reall= y matter?

Whether you're using 3PCM or LTCM is= easily determined by looking at the packets. That's what matters. If t= he protocol is different, then as far as we're concerned they're di= fferent things.

A t= hird-party authorization server can be used with LTCM as-is, but that would= be somewhat complicated and unnatural. The 3PCM draft proposed an extensio= n to LTCM that allows natural convenient way of using a third-party server.=

Correct, but again I don't = see why that matters.

Th= e draft could be re-worded to eliminate tight connection to TURN, if that&#= 39;s absolutely necessary.

I don't think it's= "absolutely necessary", but I think it's very desirable. I&#= 39;ve been saying it since the beginning: this authentication mechanism is = for STUN, not for TURN. I fully agree with Marc's comment. Although I d= on't think the draft needs a "rewrite". A careful search &= ; replace should be sufficient to make the text TURN-agnostic.

Simon

--089e0158ad546810fe0503a6eac8-- From nobody Mon Sep 22 05:54:37 2014 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 966301A00B7 for ; Mon, 22 Sep 2014 05:54:36 -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=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 5-yjZhHTnTDe for ; Mon, 22 Sep 2014 05:54:35 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8D51A00D0 for ; Mon, 22 Sep 2014 05:54:35 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id gi9so6499170lab.24 for ; Mon, 22 Sep 2014 05:54:33 -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=VUGpr3Rq8p3+NysBNjQLMHHzoa2aVjv+CUAxHQpK90c=; b=GqHBA2H7DbgFoqKl3uQrKx7jXvwGzanqu3BcN4RuLuQuKln2Bbc1oPb27sx/1bm4+b FecE0glbGGww2jX2WCIGydnLdwT7Bm5KZ/LghMzFO9iDaljclEK/EClshKbwbEy9VLzm ZAOnQbhYC68/d8WANDmrxPNdyGXufWIlRp7FnTFI73jdo7ZQvwchrOSimJdl8t4vDycK OlPvR0KrkRyr8mBoa8IpeoK+3c3IT4hQGwzrbJLJYIqgzNWJr+YGXKqQ/G22Zzm1is19 kqQk1O3YhBa9N2IAGSeXiya1zhQV6QmvU3K9DuNPgpyH7zRP0qnjHtofSYAzxJGLEFjw BpQg== X-Gm-Message-State: ALoCoQnpb7FHYi9jeZJtUhTgjpSH6jYzaUfHBH/5G6WojJv9gUloLvzgYcbs9A6afGWCxb/Hj+cZ MIME-Version: 1.0 X-Received: by 10.152.163.66 with SMTP id yg2mr25454790lab.38.1411390473500; Mon, 22 Sep 2014 05:54:33 -0700 (PDT) Received: by 10.25.137.193 with HTTP; Mon, 22 Sep 2014 05:54:33 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A2832C997@xmb-rcd-x10.cisco.com> References: <541EB85D.90609@acm.org> <913383AAA69FF945B8F946018B75898A2832C997@xmb-rcd-x10.cisco.com> Date: Mon, 22 Sep 2014 08:54:33 -0400 Message-ID: From: Simon Perreault To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a11341806d00e0e0503a6f30c Archived-At: http://mailarchive.ietf.org/arch/msg/tram/hAniliCW1481_Sc9EmdVofBCw8I Cc: Marc Petit-Huguenin , "tram@ietf.org" Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-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, 22 Sep 2014 12:54:36 -0000 --001a11341806d00e0e0503a6f30c Content-Type: text/plain; charset=UTF-8 On Mon, Sep 22, 2014 at 1:05 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Third party authorization is relevant to TURN server usage and don't see a > need for STUN server on the Internet to support it. > That's irrelevant IMHO. > If at all there is a use case for third party authorization in future with > STUN > server then the mechanism proposed in the draft will also work with STUN > server. > Exactly! That's the very reason why this extension needs to be described in terms of STUN. Simon --001a11341806d00e0e0503a6f30c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Sep 22, 2014 at 1:05 AM, Tirumaleswar Reddy (tireddy) <tireddy@cis= co.com> wrote:

Third party authorization is re= levant to TURN server usage and don't see a need for STUN server on the= Internet to support it.

That's i= rrelevant IMHO.

=C2=A0

If at all there is a use = case for third party authorization in future with STUN
server then the mechanism proposed in the draft will also work with STUN se= rver.

Exactly! That's the very reason why t= his extension needs to be described in terms of STUN.

Simon

--001a11341806d00e0e0503a6f30c-- From nobody Mon Sep 22 06:05:01 2014 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 2C78A1A1ACC for ; Mon, 22 Sep 2014 06:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 3VHefNVpq856 for ; Mon, 22 Sep 2014 06:04:47 -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 E6E321A1AB8 for ; Mon, 22 Sep 2014 06:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4170; q=dns/txt; s=iport; t=1411391087; x=1412600687; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=KwiJp9cqlnltxHoCJO+gdO9KJFmYzjs1cYVGVr/QKWg=; b=MDOngWwoEcCiZE9oPR52avTclpO6OHlScwMXGXNddqsAsI48Ei7URqqP dQVy3Ju8hflkcPyrVrA0LQDM+Q3aMkY53bftluY/5lUEJcbcUBWbNZ1UW TURoeQHkPisTxQXc6gOQh9HoZrScQNC+7YVlY/1BQ88tLc/P46Y2pGLy9 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAJcdIFStJA2N/2dsb2JhbABggw5TVwTKRgqHTQGBDRYBeYQDAQEBBAEBATc0GwIBCBgeECcLGwEGAwIEARIbiCMNxBoBF41GgV4RAVeESwWRV4Q4hweBYZNxgWsdgVlsAYEOOYECAQEB X-IronPort-AV: E=Sophos;i="5.04,571,1406592000"; d="scan'208";a="357148717" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP; 22 Sep 2014 13:04:46 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s8MD4kPJ030212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 13:04:46 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.38]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 08:04:45 -0500 From: "Prashanth Patil (praspati)" To: Marc Petit-Huguenin , "tram@ietf.org" Thread-Topic: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03 Thread-Index: AQHP1mXI0zFcFhrggEObdqFkle+Sbw== Date: Mon, 22 Sep 2014 13:04:45 +0000 Message-ID: References: <541EB85D.90609@acm.org> In-Reply-To: <541EB85D.90609@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [173.39.66.145] Content-Type: text/plain; charset="us-ascii" Content-ID: <4255E8E7034AFF498CE0A0541FE7DD06@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/mPDU4YeNNuhAMDQ3CcZU8uef1U0 Subject: [tram] FW: WGLC draft-ietf-tram-turn-third-party-authz-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, 22 Sep 2014 13:04:55 -0000 On 9/21/14 5:07 PM, "Marc Petit-Huguenin" wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >On 09/10/2014 06:18 AM, Simon Perreault wrote: >> TRAMsters, >>=20 >> This email initiates a two-week working-group last call on this draft: >>=20 >> http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-03 >>=20 >> Please read it now. Substantial comments should be addressed to the >>group. >> Nits should be sent directly to the authors. >>=20 > >Before even starting talking about the details about 3rd party >authorization, >I have an issue about how this authorization scheme is presented in this >draft. > >RFC 5389 defines two authentication mechanisms, a Short-Term Credential >Mechanism (STCM) in section 10.1 and a Long-Term Credential Mechanism >(LTCM) >in section 10.2. None of these mechanisms are tied to a specific STUN >usage, >although, even at the time RFC 5389 was written, it was clear that STCM >was >designed to be used with ICE and LTCM with TURN. The RFC 5389 authors, >who >are IETF veterans, knew that the IETF does not provides protocol for >applications, but building blocks, and these two sections reflects >exactly that. > >Now my beef with draft-ietf-tram-turn-third-party-authz is that it is >written >as providing a protocol for an application, but not as a building block. >It >should have be written in the same spirit than section 10.1 or 10.2 of RFC >5389, i.e. as a generic authentication mechanism with different properties >than these two. The only piece of the draft that follows a protocol is the "Token". Im afraid it has to be this way because token construction has to be very clearly defined, so all parties play nice. The solution will not be interoperable otherwise. Most of everything else is non-prescriptive, but only explains how things are to work with OAuth. It's quite like a building block: For example, the draft does not prescribe any protocol for interactions between the Authorization-Server and the Turn Client to obtain a token. The draft only provides an example of how this could be achieved. Similarly, for Key-Establishment, the draft does not prescribe a specific means to establish keys between the Authorization-Server and the TURN Server. It only suggests possible means for this establishment. > >So my advice is to completely rewrite this draft to make it independent of >TURN, and make it just another STUN Credential Mechanism (let's call it >3rd >Party Credential Mechanism, 3PCM). Will it suffice if we mentioned that the draft explains the solution with TURN as an example, but is equally applicable for other STUN usages. -Prashanth > >Then we can have a separate section (or, better, a separate draft) that >modifies TURN to use 3PCM as a replacement for LTCM. > >I'll do a more complete review if and when this rewrite will be done. >Until >then I do not support the publication of this draft in this form. > >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 v1 > >iQIcBAEBCAAGBQJUHrhcAAoJECnERZXWan7EbKIP/jM282eKSOYViBY8qeUsCfO8 >4U+Ar3CGWXqeUCbsB8K7DvQppZY+R7b9/j7yv0sVWgIo9vTlt758Vf660Ag4XFK0 >hhJC55g9PeNRqRcKQlpp2m9/rMpuHPY95GKd7+PaczJ2Q/8NIUb0/XeBIX9+V5MM >48Y4pd/bfndwPHEUWHh+ypljqcClzaYsAA/jxmoO5vJPnipNIficvSxj4MB703Yq >UPxc98hDsu3yU+5/aAjLkCz1tbj41uGmTenYCywFHTEYRAZZPw+1u0qHffsOEcOK >JIIk9EELcaWZ0YE2aAKUfnKs/G45+/JCKAYw1/jr4CjdatgV8GJPMfq+gbUW15n+ >N9744LbUxarokc/N0Ey07gB2rihtVhoQLeC9YGUj6KGoNNb2PukCTE7l8FbRIMWX >OrfuppEhZjn2KzZyPw9mvtoeoDHz+lYwyYRKHsrz/mw7n8OVy+gwSHsvlLRGiI1D >h6vPkTHeqI5jThgfcK5ffVGMNrHIhoSghMzWE2Lul54pm3f/kDucQ8klluqL1mAt >MdrmO95jyGs7QlOrHpVRM+vgnWrufG8332Q26BL0vPqWwTKE3i0tiGYinS2xiaL0 >FaRFvhUuuzv+jwapsKJfWhgo9Nb0MiO0ElF34RFooCzkFToCn3FvUzCZirbny1TS >HdCDNaA9A5U63rVgkv8e >=3D62Q8 >-----END PGP SIGNATURE----- > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Mon Sep 22 06:12:22 2014 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 366D91A1AB9 for ; Mon, 22 Sep 2014 06:12:13 -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=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 Dpzu9R_3tjZw for ; Mon, 22 Sep 2014 06:12:11 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3AF1A00D0 for ; Mon, 22 Sep 2014 06:12:11 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id u10so6537931lbd.41 for ; Mon, 22 Sep 2014 06:12:09 -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=8wBnwQlYiB4YHj8bW9sSH6Pw9he9oHA5Xao9Pq5ePLs=; b=O783y1tsT96hzxebI8NGL0Wh1AmbXaUkechG5f2aF3I5CvSJHRE+PceCDhu7p0I+8i DQjhjTfNeKkjhMLMZbhc/sJZHMkUhTBafLZaZRUOxIH0Yhq4zVFCwRVhjl5Ny1SGCP30 K5Ci8hsPaPlkbLijCZOt4PQ+CLfDxJR8z+Dab+kI+vvJEZM6kl1wWxoPz+3d5UY31AOv b8ZCV1Fi2ft7tLt8TIQDLrLK3HKxo/1xlYaiLVqJQJcz05J+Nxb7F73ozMku013HE6Os CWLAqymfazyLwysrZMeJpH5CghEjLNvgUr2nVEG/Q5Q44jOAJ6ccgaj0RRzrFHIvLI7N xlyw== X-Gm-Message-State: ALoCoQkZNAL2UPrc1t/P4FRaUmByu2vzLjh0EdTEitaipjmPfw6oUlB6GuBAyYlV8crNfZjlmqHY MIME-Version: 1.0 X-Received: by 10.152.170.167 with SMTP id an7mr2587655lac.94.1411391529782; Mon, 22 Sep 2014 06:12:09 -0700 (PDT) Received: by 10.25.137.193 with HTTP; Mon, 22 Sep 2014 06:12:09 -0700 (PDT) In-Reply-To: References: <541EB85D.90609@acm.org> Date: Mon, 22 Sep 2014 09:12:09 -0400 Message-ID: From: Simon Perreault To: "Prashanth Patil (praspati)" Content-Type: multipart/alternative; boundary=089e0117690fc59fa30503a73217 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/QVdDdrbD9I2LisrPo4DZnC-X5eY Cc: Marc Petit-Huguenin , "tram@ietf.org" Subject: Re: [tram] FW: WGLC draft-ietf-tram-turn-third-party-authz-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, 22 Sep 2014 13:12:13 -0000 --089e0117690fc59fa30503a73217 Content-Type: text/plain; charset=UTF-8 On Mon, Sep 22, 2014 at 9:04 AM, Prashanth Patil (praspati) < praspati@cisco.com> wrote: > Will it suffice if we mentioned that the draft explains the solution with > TURN as an example, but is equally applicable for other STUN usages. > Not really. It is more than "equally applicable to other STUN usages": it is usage-agnostic. What would be more appropriate IMHO would be to define the extension in terms of the base STUN protocol, make no mention of any STUN usage, then in a separate section show an example using TURN. Simon --089e0117690fc59fa30503a73217 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Sep 22, 2014 at 9:04 AM, Prashanth Patil (praspati) <praspati@cis= co.com> wrote:

Will it suffice if we mentioned= that the draft explains the solution with
TURN as an example, but is equally applicable for other STUN usages.
<= /blockquote>

Not really. It is more than "equally applicable = to other STUN usages": it is usage-agnostic. What would be more approp= riate IMHO would be to define the extension in terms of the base STUN proto= col, make no mention of any STUN usage, then in a separate section show an = example using TURN.

Simon

--089e0117690fc59fa30503a73217-- From nobody Mon Sep 22 07:07:36 2014 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 4165D1A1B12 for ; Mon, 22 Sep 2014 07:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 bBmR-j-4VcQm for ; Mon, 22 Sep 2014 07:07:29 -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 CD2421A6EE5 for ; Mon, 22 Sep 2014 06:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4017; q=dns/txt; s=iport; t=1411393901; x=1412603501; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9ALYKS2+FjiMq8Cag4KnA2xfFHuB1FuA1PeiZJ6OMzA=; b=UEJZxC0O2IQvftIj1XGgnO0F8Rg/jDQh3RvPfae8aR0pyCL1UymY3k+V JYja4mBrB6ReJwkApmh+bQXjAF+KEHRy6z8xjql3qro2QzzzcV5I95rqF rMgiAdCZohk8lonqRgmov2ElfIZhukGarGqAm2ZeU3GyYrmcJROT0UW4V I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAB8oIFStJV2c/2dsb2JhbABggkhGgSoE0h0BgQsWAXmEAwEBAQR5EAIBCAQKAwMBAigHMhQIAQgCBA4FG4gjxAcBF491EQeESwWRV4s/lVKDYWyBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,571,1406592000"; d="scan'208,217";a="357163443" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 22 Sep 2014 13:51:40 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8MDpeGM007299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 13:51:40 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.38]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 08:51:39 -0500 From: "Prashanth Patil (praspati)" To: Simon Perreault Thread-Topic: [tram] FW: WGLC draft-ietf-tram-turn-third-party-authz-03 Thread-Index: AQHP1mbbmy+NEgeQNky4ViUsdhRNeJwN29+A Date: Mon, 22 Sep 2014 13:51:39 +0000 Message-ID: References: <541EB85D.90609@acm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [173.39.66.145] Content-Type: multipart/alternative; boundary="_000_D04627204EED1praspaticiscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Jxb-Qu-fXOOb2bJ4Y7xII_PWzS4 Cc: Marc Petit-Huguenin , "tram@ietf.org" Subject: Re: [tram] FW: WGLC draft-ietf-tram-turn-third-party-authz-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, 22 Sep 2014 14:07:32 -0000 --_000_D04627204EED1praspaticiscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure, we'll update the next revision accordingly. -Prashanth From: Simon Perreault > Date: Monday, September 22, 2014 6:42 PM To: Prashanth Patil > Cc: Marc Petit-Huguenin >, "tram@= ietf.org" > Subject: Re: [tram] FW: WGLC draft-ietf-tram-turn-third-party-authz-03 On Mon, Sep 22, 2014 at 9:04 AM, Prashanth Patil (praspati) > wrote: Will it suffice if we mentioned that the draft explains the solution with TURN as an example, but is equally applicable for other STUN usages. Not really. It is more than "equally applicable to other STUN usages": it i= s usage-agnostic. What would be more appropriate IMHO would be to define th= e extension in terms of the base STUN protocol, make no mention of any STUN= usage, then in a separate section show an example using TURN. Simon --_000_D04627204EED1praspaticiscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3A9A41F9B8684948AB19EF668C9CDE84@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Sure, we'll update the next revision accordingly.

-Prashanth

From: Simon Perreault <sperreault@jive.com>
Date: Monday, September 22, 2014 6:= 42 PM
To: Prashanth Patil <praspati@cisco.com>
Cc: Marc Petit-Huguenin <petithug@acm.org>, "tram@ietf.org" <tram@ietf.org>
Subject: Re: [tram] FW: WGLC draft-= ietf-tram-turn-third-party-authz-03

On Mon, Sep 22, 2014 at 9:04 AM, Prashanth Patil= (praspati) <praspati@cisco.com> wrote:

Will it suffice if = we mentioned that the draft explains the solution with
TURN as an example, but is equally applicable for other STUN usages.

Not really. It is more than "equally applicable to other STUN usages&q= uot;: it is usage-agnostic. What would be more appropriate IMHO would be to= define the extension in terms of the base STUN protocol, make no mention o= f any STUN usage, then in a separate section show an example using TURN.

Simon

--_000_D04627204EED1praspaticiscocom_-- From nobody Wed Sep 24 19:22:28 2014 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 8ADA91A00BD; Wed, 24 Sep 2014 19:22:22 -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 6pkVwoyZFX8Q; Wed, 24 Sep 2014 19:22:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE8C1A00E6; Wed, 24 Sep 2014 19:22:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140925022221.19782.11755.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 19:22:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BKKpI75Z7w6K5NRQ25PxMVL7eic Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-04.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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, 25 Sep 2014 02:22:22 -0000 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 : Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization Authors : Tirumaleswar Reddy Prashanth Patil Ram Mohan Ravindranath Justin Uberti Filename : draft-ietf-tram-turn-third-party-authz-04.txt Pages : 20 Date : 2014-09-24 Abstract: This document proposes the use of OAuth to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensure that access to a STUN server can be controlled even if the tokens are compromised. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-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/ From nobody Wed Sep 24 19:28:27 2014 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 BC1A51A011F for ; Wed, 24 Sep 2014 19:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 YxRXdpOmRRk8 for ; Wed, 24 Sep 2014 19:28:24 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22CDF1A00BD for ; Wed, 24 Sep 2014 19:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2317; q=dns/txt; s=iport; t=1411612104; x=1412821704; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IgXaZ8be+lSrhOuJUL3fNGTqdP1Qbs2ml1VRJ5GKgS4=; b=F6SdSUVSOhhTvGlNnc63fOyb7L7sn5yJcVXUJ5lxzu5UD0/G4cfEgnct uB1IPzYIsvdQWeIipo2Lepl0Cehbnum3nCcHGjcFOhdDHWc0vAerNZAcr 0jTw+HfPBZS4HVaV+nje7kBLAKcQpyGcpPClY8PGK8hbXEC40gtp8DnxM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAH99I1StJV2R/2dsb2JhbABggw5TUwQEykAMh0wBgQkWAXqEAwEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEEwgBiDUIBcQiARePbTgGgyiBHQWRXoQ6iGqTc4NibIEIJByBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,593,1406592000"; d="scan'208";a="81043202" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP; 25 Sep 2014 02:28:05 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s8P2S5Ob029370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 25 Sep 2014 02:28:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 21:28:05 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-04.txt Thread-Index: AQHP2GeYmv+rcBv2bECN+5OeKUiIF5wRH5dw Date: Thu, 25 Sep 2014 02:28:05 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2832FFA7@xmb-rcd-x10.cisco.com> References: <20140925022221.19782.11755.idtracker@ietfa.amsl.com> In-Reply-To: <20140925022221.19782.11755.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.50.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/vCSiLsjz-RG3UaNIjHDAMQWi4vk Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-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: Thu, 25 Sep 2014 02:28:25 -0000 We submitted http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-au= thz-04 which addresses the WGLC comments received. side-by-side diffs: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn= -third-party-authz-04 -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, September 25, 2014 7:52 AM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized Working > Group of the IETF. >=20 > Title : Session Traversal Utilities for NAT (STUN) Exte= nsion for Third > Party Authorization > Authors : Tirumaleswar Reddy > Prashanth Patil > Ram Mohan Ravindranath > Justin Uberti > Filename : draft-ietf-tram-turn-third-party-authz-04.txt > Pages : 20 > Date : 2014-09-24 >=20 > Abstract: > This document proposes the use of OAuth to obtain and validate > ephemeral tokens that can be used for Session Traversal Utilities for > NAT (STUN) authentication. The usage of ephemeral tokens ensure that > access to a STUN server can be controlled even if the tokens are > compromised. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-third-party-authz= -04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Sep 24 21:35:53 2014 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 702451A1A58 for ; Wed, 24 Sep 2014 21:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 hXWg3CQzlD3Y for ; Wed, 24 Sep 2014 21:35:50 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61F51A1A42 for ; Wed, 24 Sep 2014 21:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6046; q=dns/txt; s=iport; t=1411619749; x=1412829349; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RK6pL7wlhBCoMhdBHYzx+nzXudE6ezPqoSk2oDres+0=; b=PFp+dMAvBFAPu8hQ42a5XEhhalmqWK1vCM8+2zfENlTlkoW6SoJ/zY2A 3w/s4zpmPdREVte9pjTcd2g3vO2yDG3iarJoV0HjrmxfGlYZOYSrETlUd LtsQrLGcEQgXqrE5ASdYwB0S7aF+B3g8JTOgg+qMPCkv9uHLCkMbp1kVq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAHCbI1StJA2K/2dsb2JhbABWCoJIRoEqBNIWAYELFgF6hAMBAQEEeRACAQgOAwMBAgEnByERFAkIAgQBDQWIKgMRvFINhyABF41ugVRLEQeESwWLD4ZPiTOCEI8OhkaDYmyBSIECAQEB X-IronPort-AV: E=Sophos; i="5.04,594,1406592000"; d="scan'208,217"; a="81060824" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP; 25 Sep 2014 04:35:48 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8P4Zmlo028804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Sep 2014 04:35:48 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.38]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 23:35:48 -0500 From: "Prashanth Patil (praspati)" To: Simon Perreault , Martin Thomson Thread-Topic: [tram] WGLC draft-ietf-tram-alpn-00 Thread-Index: AQHP0iZTcDYu+ea/iEGE0aPHlSxTTZwFmXMAgAGlYACAABRKgIACCl+AgALe9wCABcOeAA== Date: Thu, 25 Sep 2014 04:35:48 +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.4.3.140616 x-originating-ip: [10.65.56.34] Content-Type: multipart/alternative; boundary="_000_D049970B4F32Cpraspaticiscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/jcqHf7h-AIq8zIBnYEXx373GkY0 Cc: "Gonzalo Salgueiro \(gsalguei\)" , "tram@ietf.org" Subject: Re: [tram] WGLC draft-ietf-tram-alpn-00 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, 25 Sep 2014 04:35:51 -0000 --_000_D049970B4F32Cpraspaticiscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It seems like there is no objection to removing the 'stun' label from the d= raft; we'll submit a revision accordingly. The new revision will only inclu= de labels to identify the two specific usages i.e., turn & nat-discovery. N= o additional label will be defined to identify other STUN usages. -Prashanth From: Simon Perreault > Date: Sunday, September 21, 2014 11:34 PM To: Martin Thomson > Cc: Prashanth Patil >, "Gonza= lo Salgueiro (gsalguei)" >, "= tram@ietf.org" > Subject: Re: [tram] WGLC draft-ietf-tram-alpn-00 As individual participant, I don't find this argument convincing. No game d= eveloper would spend energy getting his own label, even if the registry was= FCFS. Also, I think that a "stun" label is still providing information tha= t could be somewhat valuable. But I also don't think that this is an import= ant issue. Now, as chair I think we're starting to rehash the same arguments, and I th= ink we should move on. To me, the most sensible course of action if we don'= t reach consensus would be to do nothing, i.e., not define a "stun" label. = We can always revisit this issue later if it becomes a pain point. For now = I think everyone can live without it. Can anyone not live with this course of action? Simon Le 2014-09-19 18:13, "Martin Thomson" > a =E9crit : On 18 September 2014 08:04, Simon Perreault > wrote: > Agreed. But can we agree that if someone did want to do it, one could > rightfully expect it to work? I would say that when someone chooses to do that, the application that they are using should then ask for a new identifier. If you don't care to identify your application properly, how about you not use ALPN? --_000_D049970B4F32Cpraspaticiscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <6FA01E0C838A0F4E94C9E6CB24ACE9B7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

It seems like there is no objection to removing the 'stun' label from = the draft; we'll submit a revision accordingly. The new revision will only = include labels to identify the two specific usages i.e., turn & nat-dis= covery. No additional label will be defined to identify other STUN usages.

-Prashanth

From: Simon Perreault <sperreault@jive.com>
Date: Sunday, September 21, 2014 11= :34 PM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Prashanth Patil <praspati@cisco.com>, "Gonzalo Salgue= iro (gsalguei)" <gsalguei@cis= co.com>, "tram@ietf.org&qu= ot; <tram@ietf.org>
Subject: Re: [tram] WGLC draft-ietf= -tram-alpn-00

As individual participant, I don't find this argument convin= cing. No game developer would spend energy getting his own label, even if t= he registry was FCFS. Also, I think that a "stun" label is still = providing information that could be somewhat valuable. But I also don't think that this is an important issue.

Now, as chair I think we're starting to rehash the same argu= ments, and I think we should move on. To me, the most sensible course of ac= tion if we don't reach consensus would be to do nothing, i.e., not define a= "stun" label. We can always revisit this issue later if it becomes a pain point. For now I think everyone can = live without it.

Can anyone not live with this course of action?

Simon

Le 2014-09-19 18:13, "Martin Thomson" = <martin.thomson@gmail.com> a =E9crit :

On 18 September 2014 08:04, Simon Perreault <sperreault@jive.com> wrote:
> Agreed. But can we agree that if someone did want to do it, one could<= br> > rightfully expect it to work?

I would say that when someone chooses to do that, the application that
they are using should then ask for a new identifier.

If you don't care to identify your application properly, how about you
not use ALPN?

--_000_D049970B4F32Cpraspaticiscocom_-- From nobody Thu Sep 25 05:48:01 2014 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 CE90E1A0023 for ; Thu, 25 Sep 2014 05:47:59 -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=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 nS_ozS_k5f7u for ; Thu, 25 Sep 2014 05:47:58 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DD51A0077 for ; Thu, 25 Sep 2014 05:47:57 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id w7so6984027lbi.34 for ; Thu, 25 Sep 2014 05:47:55 -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=lLHUg0hg3sA9tWJPfjuZVVFy+wQwxVLN9BvHkCmk9Io=; b=kF7QqwAcoZ77/5gpV1N5E/Meksg+OoQfqnUY9tENpQjg3FWjF73O4bamIUtYzpk7cA ED1Z7OArNeXF8nr8X2laOuvO80xIDooL3VQ4fMOEq1D6tmPbuWTMKX2jmfg3jfk/tb90 D99xYIOGc35nmUD1M5wr6laYn3CqIWJ3sGPQ4KmYIwqZrj5He59DZLN3AiBRGr9ewDMU uEmM3ICinLrDiqCTxtAXZENeh8m4xUU6DrTnj++wRl85+1R619otpNSh1sAshiucTmpI M9W1epntfEhJTAsx/vbJzEBC6wTJXWGHauvigqCRcTY/mUMnxWKrDULwn+2J0ud4wpV8 cGSA== X-Gm-Message-State: ALoCoQmyCWmF5zaPkajE5MVjJPfHfNz1LrH3uX5BJpbQFMPW7hkGOim5/XRy5XvgIHqNi7tOuhab MIME-Version: 1.0 X-Received: by 10.152.21.168 with SMTP id w8mr13320402lae.59.1411649275787; Thu, 25 Sep 2014 05:47:55 -0700 (PDT) Received: by 10.25.137.193 with HTTP; Thu, 25 Sep 2014 05:47:55 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A2832FFA7@xmb-rcd-x10.cisco.com> References: <20140925022221.19782.11755.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A2832FFA7@xmb-rcd-x10.cisco.com> Date: Thu, 25 Sep 2014 08:47:55 -0400 Message-ID: From: Simon Perreault To: "Tirumaleswar Reddy (tireddy)" , Oleg Moskalenko , Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=089e0158ad54a187a70503e3353d Archived-At: http://mailarchive.ietf.org/arch/msg/tram/3bfV3pjUpciIMVXX89Usq_lXo5Y Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-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: