From nobody Sun Feb 1 00:07:45 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589B41A8757 for ; Sun, 1 Feb 2015 00:07:41 -0800 (PST) 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 PxgTUuM659Iw for ; Sun, 1 Feb 2015 00:07:39 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CB41A8755 for ; Sun, 1 Feb 2015 00:07:38 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id m14so33881567wev.11 for ; Sun, 01 Feb 2015 00:07:37 -0800 (PST) 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=jxi6DkMXq4kq1vybFAS566Jam6Zg9ct0ZR7AuPO+G3A=; b=i+fa6Nmrfgaihu/jwvw9f5k0rnd28D9fY8UfYxFzZjKr/QSKjhCGwMHMOX6gyLTL9p zO2NubIQ+7Zaeqt7zdHGmfTTGiQKGGWCUDiwNSe558pYN/ll+s6Sp6906n/zS5H4JMSJ LO20WWeDKWxkDzsD41Q7zWhUgprvfWj1clIKKRT+l7GEa51496pYAiZEHOxAnc/p88eX 2PbmF3NUdSkaHw3RXYENXoaEb/rLkThwPQU34DRD+PWmW7Q/LSpbvBttvnWgTnZ+xENb LMKxq/2Mxxq+dDfVU2vec98xqz5fWgoTSKEd+XJcSQeGZw09YmWUHXP3xVaDpeUHh2SH cNbg== MIME-Version: 1.0 X-Received: by 10.194.81.104 with SMTP id z8mr30257874wjx.45.1422778057306; Sun, 01 Feb 2015 00:07:37 -0800 (PST) Received: by 10.194.87.98 with HTTP; Sun, 1 Feb 2015 00:07:37 -0800 (PST) In-Reply-To: References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553506F@xmb-rcd-x10.cisco.com> Date: Sun, 1 Feb 2015 00:07:37 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7bf0c58eb337c5050e0254c1 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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: Sun, 01 Feb 2015 08:07:41 -0000 --047d7bf0c58eb337c5050e0254c1 Content-Type: text/plain; charset=UTF-8 I found another thing. In the section 7.1, the turnbis document is saying that: "The client MUST NOT include any REQUESTED-ADDRESS-FAMILY attribute in its Refresh Request." But in the next section, 7.2, there is a paragraph that discusses the server behaviour when it receives the REQUESTED-ADDRESS-FAMILY attribute in the REFRESH request. I guess that paragraph slipped into turnbis from SSODA draft and if has to be removed. Thanks Oleg On Sat, Jan 31, 2015 at 11:07 PM, Oleg Moskalenko wrote: > Tiru, I do not see any problem with EVEN-PORT when its value is 0. The > problem only arises when EVEN-PORT is equals 0x80 (reserved allocation > required). So I'd suggest for forbid only the situation when the highest > bit of EVEN-PORT is 1. > > Thanks > Oleg > > On Sat, Jan 31, 2015 at 6:36 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > >> *From:* Oleg Moskalenko [mailto:mom040267@gmail.com] >> *Sent:* Sunday, February 01, 2015 4:40 AM >> *To:* Tirumaleswar Reddy (tireddy) >> *Cc:* tram@ietf.org >> *Subject:* Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt >> >> >> >> Hi Tiru >> >> as the turnbis written, in its current form, it allows EVEN-PORT >> attribute in the ALLOCATE request together with the >> ADDITIONAL-ADDRESS-FAMILY attribute. If this is really what you want, then >> the RESERVATION-TOKEN handling must be changed in the ALLOCATE response - >> because there will be two RESERVATION-TOKEN attributes included into the >> response (when EVEN-PORT=1). >> >> Or the EVEN-PORT must be prohibited in the same request with >> ADDITIONAL-ADDRESS-FAMILY. >> >> As of now, there is inherent inconsistency. >> >> [TR] Agreed, will update the draft that AAF must not be used with even >> port. >> >> -Tiru >> >> Thanks >> Oleg >> >> >> >> >> >> On Thu, Jan 29, 2015 at 9:39 PM, Tirumaleswar Reddy (tireddy) < >> tireddy@cisco.com> wrote: >> >> Major changes in this revision are support for SSODA and merged RFC6156. >> Please review and provide your valuable comments. >> Diff from previous version : >> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tram-turnbis-01.txt >> >> -Tiru >> >> >> > -----Original Message----- >> > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- >> > drafts@ietf.org >> > Sent: Friday, January 30, 2015 10:48 AM >> > To: i-d-announce@ietf.org >> > Cc: tram@ietf.org >> > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt >> > >> > >> > 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 : Traversal Using Relays around NAT (TURN): >> Relay Extensions >> > to Session Traversal Utilities for NAT (STUN) >> > Authors : Tirumaleswar Reddy >> > Alan Johnston >> > Philip Matthews >> > Jonathan Rosenberg >> > Filename : draft-ietf-tram-turnbis-01.txt >> > Pages : 77 >> > Date : 2015-01-29 >> > >> > Abstract: >> > If a host is located behind a NAT, then in certain situations it can >> > be impossible for that host to communicate directly with other hosts >> > (peers). In these situations, it is necessary for the host to use >> > the services of an intermediate node that acts as a communication >> > relay. This specification defines a protocol, called TURN (Traversal >> > Using Relays around NAT), that allows the host to control the >> > operation of the relay and to exchange packets with its peers using >> > the relay. TURN differs from some other relay control protocols in >> > that it allows a client to communicate with multiple peers using a >> > single relay address. >> > >> > The TURN protocol was designed to be used as part of the ICE >> > (Interactive Connectivity Establishment) approach to NAT traversal, >> > though it also can be used without ICE. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-tram-turnbis-01 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-01 >> > >> > >> > 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 >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> >> > > --047d7bf0c58eb337c5050e0254c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I found another thing. In the section 7.1, the t= urnbis document is saying that:

"The client MUS=
T NOT include any REQUESTED-ADDRESS-FAMILY attribute in its Refresh Request=
."
But in the next section, 7.2, there is a paragraph that = discusses the server behaviour when it receives the REQUESTED-ADDRESS-FAMIL= Y attribute in the REFRESH request. I guess that paragraph slipped into tur= nbis from SSODA draft and if has to be removed.

Thanks
Oleg=
=C2=A0

On Sat, Jan 31, 2015 at 11:07 PM, Oleg Moskale= nko <mom040267@gmail.com> wrote:
Tiru, I do not see any problem with EVE= N-PORT when its value is 0. The problem only arises when EVEN-PORT is equal= s 0x80 (reserved allocation required). So I'd suggest for forbid only t= he situation when the highest bit of EVEN-PORT is 1.

Thanks
Oleg

On Sat, Jan 31, 2015 at 6:36 PM, Tirumaleswar Reddy (tired= dy) <tireddy@cisco.com> wrote:

From: Oleg Mos= kalenko [mailto:mo= m040267@gmail.com]
Sent: Sunday, February 01, 2015 4:40 AM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org=
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

=C2=A0

Hi Tiru=

as the turnbis writte= n, in its current form, it allows EVEN-PORT attribute in the ALLOCATE reque= st together with the ADDITIONAL-ADDRESS-FAMILY attribute. If this is really= what you want, then the RESERVATION-TOKEN handling must be changed in the ALLOCATE response - because there will be = two RESERVATION-TOKEN attributes included into the response (when EVEN-PORT= =3D1).

Or the EVEN-PORT must= be prohibited in the same request with ADDITIONAL-ADDRESS-FAMILY.

As of now, there is i= nherent inconsistency.

[TR] Agreed, will update the draft that AAF must not be used w= ith even port.

-Tiru

Thanks
Oleg

=C2=A0

=C2=A0

On Thu, Jan 29, 2015 at 9:39 PM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

Major changes in this revision are support for SSODA= and merged RFC6156. Please review and provide your valuable comments.
Diff from previous version : http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-tra= m-turnbis-01.txt

-Tiru


> -----Original Message-----
> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Friday, January 30, 2015 10:48 AM
> To: i-d-ann= ounce@ietf.org
> Cc: tram@ietf.org
> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-01.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: Traversal Using Relays around NAT (TURN): Relay Extensions
> to Session Traversal Utilities for NAT (STUN)
>=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=A0Alan Johnston
>=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=A0Philip Matthews
>=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=A0Jonathan Rosenberg
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tram-turnbis-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 77
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-01-29
>
> Abstract:
>=C2=A0 =C2=A0 If a host is located behind a NAT, then in certain situat= ions it can
>=C2=A0 =C2=A0 be impossible for that host to communicate directly with = other hosts
>=C2=A0 =C2=A0 (peers).=C2=A0 In these situations, it is necessary for t= he host to use
>=C2=A0 =C2=A0 the services of an intermediate node that acts as a commu= nication
>=C2=A0 =C2=A0 relay.=C2=A0 This specification defines a protocol, calle= d TURN (Traversal
>=C2=A0 =C2=A0 Using Relays around NAT), that allows the host to control= the
>=C2=A0 =C2=A0 operation of the relay and to exchange packets with its p= eers using
>=C2=A0 =C2=A0 the relay.=C2=A0 TURN differs from some other relay contr= ol protocols in
>=C2=A0 =C2=A0 that it allows a client to communicate with multiple peer= s using a
>=C2=A0 =C2=A0 single relay address.
>
>=C2=A0 =C2=A0 The TURN protocol was designed to be used as part of the = ICE
>=C2=A0 =C2=A0 (Interactive Connectivity Establishment) approach to NAT = traversal,
>=C2=A0 =C2=A0 though it also can be used without ICE.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tram-turnbis-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-01
>
>
> 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

=C2=A0



--047d7bf0c58eb337c5050e0254c1-- From nobody Sun Feb 1 05:01:50 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3E11B29A6 for ; Mon, 26 Jan 2015 13:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pygay2z6oOfu for ; Mon, 26 Jan 2015 13:27:22 -0800 (PST) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9981A9139 for ; Mon, 26 Jan 2015 13:27:11 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id va2so10159228obc.2 for ; Mon, 26 Jan 2015 13:27:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ASXICAgjQaKFDq4CcLZ09U6jQJIFaYRmU4QqncuvX2o=; b=HM5FUVNkMELQRKcvwtUYDseLcRA+ynDzigyTMntoKhoWPzBL3UE963uoVLwhKePbk2 ZyPDmKPrhW32mk2gBc+AMfqtGY9I9Yiuu3VangvmbSrDQecYsz3eT2yWFtzU5Mhq8qMR D5CGyvpHTv3wx5zRnlq26JQ4kAv0/NxU8qS8jKj1yeinUEZnpD3VdYPrKqu+fd+yfrbw 9m7bqyMZNsVuWiVwC2E/bdieN8JgHZ0R+T0uFY+Lt7bhDmR85ONtB32BamZl+3bAqUdv S3cAGqSmSoD6ZYLCalk3WXfJHirhuOhcoGdKDc9I9jspyHKf12t3Suah5PRwBPcCyvpH eohQ== X-Gm-Message-State: ALoCoQnV1AuDTGCakHMuhHbAfGMJZ9DYm5lGSAlwAXzAKd2MrX5qeiJVJ73OFdxu0BwKGD3lGQmX X-Received: by 10.202.202.4 with SMTP id a4mr13463710oig.5.1422307631268; Mon, 26 Jan 2015 13:27:11 -0800 (PST) Received: from [10.20.130.188] ([199.87.120.126]) by mx.google.com with ESMTPSA id sz6sm5922392obc.11.2015.01.26.13.27.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Jan 2015 13:27:10 -0800 (PST) Message-ID: <54C6B12E.6030403@jive.com> Date: Mon, 26 Jan 2015 14:27:10 -0700 From: tshields User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: praspati@cisco.com, tireddy@cisco.com, dwing@cisco.com, tram@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 01 Feb 2015 05:01:47 -0800 Subject: [tram] Review of draft-ietf-tram-turn-server-discovery-01 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, 26 Jan 2015 21:27:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Overview Overall this draft was very clear and straight-forward. There was one more important question that jumped out at me as I was reviewing; it was somewhat unclear to me whether or not both mechanisms for TURN server discovery are really required, which one is prefered, and why. Major Issues/Questions: Section 1, Paragraph 2 > The reason for providing two mechanisms is to maximize the > opportunity for discovery, based on the network in the which the > TURN client sees itself. So would someone implementing this use both mechanisms in order to maximize the opportunity for discovery, or would they choose the one that makes sense for them? Am I breaking the standard if I just implement one? I think the wording here could be a little more explicit. If I MUST implement both mechanisms then the document should make that clear. Section 3, Paragraph 1 does specify that the auto discovery algorithm MUST try service resolution first and then Anycast (steps 2 & 3). So at this point it becomes clear that both mechanisms must be implemented. However, it seems to me (based on the document) that Discovery using Anycast is a much simpler, more "elegant" solution. Does the document really care that I try to use Discovery Using Service Resolution first, or may I choose the order that makes sense to me as an implementer? If it does care, I think the reason should be stated in Paragraph 1 of Section 3 (or somewhere else that makes sense). Section 4.2.1, Paragraph 3 > If this lookup fails, the discovery procedure is aborted without a > result. If this lookup fails then we give up entirely with dicovering a TURN server, or just for this domain/interface/address family combination? Do we move on to Discovery using Anycast at this point? Should be made more clear. Minor Issues/Questions: Section 4, Paragraph 4 > On hosts with more than one interface or address family (IPv4/v6), > the TURN server discovery procedure has to be run for each > combination of interface and address family. Out of curiosity, what is the maximum number of interfaces and address families that could be expected? Is there any concern that checking every combination of interface and address family could be too expensive of a task? My gut tells me it's not a problem but I thought I would at least ask the question. Nits: Section 3, Paragraph 3 > Service Resolution : The TURN client attempts to perform TURN > service resolution using the DNS domain name that the host belongs > to OR the hosts' global IP address. Is it really multiple hosts ("hosts'") or a is it a single host ("host's"). Also, im my opinion, the sentence can be altered to make it slightly more readable: "Service Resolution : The TURN client attempts to perform TURN service resolution using the host's DNS domain OR the host's global IP address." - -- Troy Shields Developer of Awesome | Jive Communications, Inc. Jive.com | tshields@jive.com -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUxrEtAAoJEPpHBvvPaXlQPe8P/Rj4qj19jQRiefzibQ6EYXqc 29OWBhIks1YCdQhuy3JIEML895HZrw1pCJEKQ6yckixL9Nf0zBCEZCe2HPejxSgO pgeZ6y7xzYTCOGm2+KMB0Ixt9mdOPglRpYsBqZaCediCz1VbqU8vRZXpy7dcFpzE ppzrcYhN5u71B6apN+jEC9a1Fo9J09jWlsSF4cFHXd2ZUBbe7LqmeiY8B9292cFt ReTVi8ltY4RbLkoekcuc88phZWIDPbG27IV/s5BZCecLNZpgarMI4otbnnD5MX9x CGCZACtTPkWpGzrN1ERllB/6BGtgt+e52EymYh2ulchCYEw/yZfQXHe58UTcc9o0 YCXTHjiZ7J57OH9EGcZ0VfLE9VumaWIYciwdhcX759yGHAZ1mRmpSpTcXr54Sa09 C4bs8w0MQ6M62eJ4pHnNL+7JwZOgHQVi3leVhImqZGAkM+oYfxy8oSOEtDU/SU+h ndz3vbXVS83UfNs4wv5tP9UpjjNFsB0B0qqeDZpkh5pWEdhJxOJ3nEp+E6PyJuhs sXFlplY2J96377vA1iQ9TevaoRHDK9xvmIA32yqxud2kXyf2cJPSOXLuTY4yY+1B FgJxW+LGJ+TilOXAe97Dpxmeq8DmAMcpJAvhScsI73slzMkJ7xVYQHPcukFv/CWo jiDGJlq/YRqRofW42fhk =vGbc -----END PGP SIGNATURE----- From nobody Sun Feb 1 05:01:52 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8181A19F4; Wed, 28 Jan 2015 13:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 hhSNYEP4KE3b; Wed, 28 Jan 2015 13:32:18 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F481A0545; Wed, 28 Jan 2015 13:32:18 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t0SLWHsh028985; Wed, 28 Jan 2015 21:32:17 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id E4BFEC20682; Wed, 28 Jan 2015 21:32:17 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <913383AAA69FF945B8F946018B75898A35532FF8@xmb-rcd-x10.cisco.com> References: <20150121200309.32037.30290.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35532FF8@xmb-rcd-x10.cisco.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #806090 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 28 Jan 2015 21:32:17 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Sun, 01 Feb 2015 05:01:47 -0800 Cc: liang@icann.org, draft-ietf-tram-turn-third-party-authz@tools.ietf.org, tram@ietf.org, tram-chairs@tools.ietf.org, iesg@ietf.org Subject: [tram] [IANA #806090] RE: Last Call: (Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-issues@iana.org 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, 28 Jan 2015 21:32:21 -0000 On Wed Jan 28 04:51:06 2015, tireddy@cisco.com wrote: > > -----Original Message----- > > From: Pearl Liang via RT [mailto:drafts-lastcall@iana.org] > > Sent: Wednesday, January 28, 2015 5:07 AM > > Cc: draft-ietf-tram-turn-third-party-authz@tools.ietf.org; tram- > > chairs@tools.ietf.org; iesg@ietf.org > > Subject: [IANA #804968] Last Call: > authz- > > 07.txt> (Session Traversal Utilities for NAT (STUN) Extension for > > Third Party > > Authorization) to Proposed Standard > > > > (BEGIN IANA LAST CALL COMMENTS) > > > > IESG/Authors/WG Chairs: > > > > IANA has reviewed draft-ietf-tram-turn-third-party-authz-07 Authors > > should > > review the comments and/or questions below. Please report any > > inaccuracies and respond to any questions as soon as possible. > > > > IANA has questions about some of the IANA actions requested in the > > IANA > > Considerations section of this document. > > > > We received the following comments/questions from the IANA's > > reviewer: > > > > IANA understands that, upon approval of this document, there is a > > single > > action which IANA must complete. > > > > In the STUN Attributes subregistry of the Session Traversal Utilities > > for NAT > > (STUN) Parameters registry located at: > > > > http://www.iana.org/assignments/stun-parameters/ > > > > two new STUN attributes are to be registered as follows: > > > > Value: [ TBD-at-registration ] > > Name: THIRD-PARTY-AUTHORIZATION > > Reference: [ RFC-to-be ] > > > > Value: [ TBD-at-registration ] > > Name: ACCESS-TOKEN > > Reference: [ RFC-to-be ] > > > > Question: which range or ranges in the STUN Attributes registry the > > above > > two new > > attributes should be registered? The registry defines the following > > ranges: > > > > Range Registration Procedures Note > > 0x0000-0x3FFF IETF Review comprehension-required range > > 0x4000-0x7FFF Designated Expert comprehension-required range > > 0x8000-0xBFFF IETF Review comprehension-optional range > > 0xC000-0xFFFF Designated Expert comprehension-optional range > > > > It appears that section 6 defines the new attributes to be in two > > different > > ranges, comprehension-optional and comprehension-required. Is that > > correct? > > Yes. > > > If so, please either add the ranges in the IC section or add a > > pointer > > to section 6 in the IC section. > > NEW (IC section): > > [Paragraphs below in braces should be removed by the RFC Editor upon > publication] > > [The THIRD-PARTY-AUTHORIZATION attribute requires that IANA allocate a > value in > the "STUN attributes Registry" from the comprehension-optional range > (0x8000-0xFFFF)] > As described above, the range 0x8000-0xFFFF has two different registration rules as defined by RFC5389. Which one of the following the new STUN attribute should be registered: 0x8000-0xBFFF IETF Review comprehension-optional range 0xC000-0xFFFF Designated Expert comprehension-optional range ? Should it be in 0x8000-0xBFFF? Thanks, ~pl > This document defines the THIRD-PARTY-AUTHORIZATION STUN attribute, > described > in Section 6. IANA has allocated the comprehension-optional > codepoint TBD for this attribute. > > [The ACCESS-TOKEN attribute requires that IANA allocate a value > in the "STUN attributes Registry" from the comprehension-required > range (0x0000-0x3FFF)] > > This document defines the ACCESS-TOKEN STUN attribute, described > in Section 6. IANA has allocated the comprehension-required > codepoint TBD for this attribute. > > -Tiru > > > > > Further, if a new attribute is in the comprehension-optional range, > > the > > authors need to define which of the comprehension-optional ranges, > > 0x8000-0xBFFF or 0xC000-0xFFFF, the new attribute should be > > registered. > > So, if the authors pick "0x8000-0xBFFF" of the comprehension-optional > > range, IETF Review registration rule will be used. The IC section > > has no clear > > texts about these. > > > > > > IANA understands that this is the only action that needs to be > > completed > > upon approval of this document. > > > > Note: The actions requested in this document will not be completed > > until the > > document has been approved for publication as an RFC. This message is > > only > > to confirm what actions will be performed. > > > > > > Thanks, > > > > Pearl Liang > > ICANN > > > > (END IANA LAST CALL COMMENTS) > > > > On Wed Jan 21 20:03:33 2015, iesg-secretary@ietf.org wrote: > > > > > > The IESG has received a request from the TURN Revised and > > > Modernized > > > WG > > > (tram) to consider the following document: > > > - 'Session Traversal Utilities for NAT (STUN) Extension for Third > > > Party > > > Authorization' > > > as Proposed > > > Standard > > > > > > The IESG plans to make a decision in the next few weeks, and > > > solicits > > > final comments on this action. Please send substantive comments to > > > the > > > ietf@ietf.org mailing lists by 2015-02-04. Exceptionally, comments > > > may > > > be > > > sent to iesg@ietf.org instead. In either case, please retain the > > > beginning of the Subject line to allow automated sorting. > > > > > > 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 file can be obtained via > > > http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party- > > > authz/ > > > > > > IESG discussion can be tracked via > > > http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party- > > > authz/ballot/ > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > From nobody Sun Feb 1 05:01:54 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6797F1A1AF9; Wed, 28 Jan 2015 19:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 H9zfJ5YyKa-T; Wed, 28 Jan 2015 19:30:55 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6FD81A1AB4; Wed, 28 Jan 2015 19:30:55 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t0T3Undm012627; Thu, 29 Jan 2015 03:30:49 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id B2118C20682; Thu, 29 Jan 2015 03:30:49 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: References: <20150121200309.32037.30290.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35532FF8@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553364C@xmb-rcd-x10.cisco.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #806090 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 29 Jan 2015 03:30:49 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Sun, 01 Feb 2015 05:01:47 -0800 Cc: tram@ietf.org, draft-ietf-tram-turn-third-party-authz@tools.ietf.org, liang@icann.org, tram-chairs@tools.ietf.org, tireddy@cisco.com, iesg@ietf.org Subject: [tram] [IANA #806090] RE: Last Call: (Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-issues@iana.org 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, 29 Jan 2015 03:30:58 -0000 On Thu Jan 29 02:39:56 2015, tireddy@cisco.com wrote: > > -----Original Message----- > > From: Pearl Liang via RT [mailto:iana-issues@iana.org] > > Sent: Thursday, January 29, 2015 3:02 AM > > Cc: tram@ietf.org; draft-ietf-tram-turn-third-party- > > authz@tools.ietf.org; > > tram-chairs@tools.ietf.org; iesg@ietf.org; liang@icann.org > > Subject: [IANA #806090] RE: Last Call: > party-authz- > > 07.txt> (Session Traversal Utilities for NAT (STUN) Extension for > > Third Party > > Authorization) to Proposed Standard > > > > On Wed Jan 28 04:51:06 2015, tireddy@cisco.com wrote: > > > > -----Original Message----- > > > > From: Pearl Liang via RT [mailto:drafts-lastcall@iana.org] > > > > Sent: Wednesday, January 28, 2015 5:07 AM > > > > Cc: draft-ietf-tram-turn-third-party-authz@tools.ietf.org; tram- > > > > chairs@tools.ietf.org; iesg@ietf.org > > > > Subject: [IANA #804968] Last Call: > > > > > > > authz- > > > > 07.txt> (Session Traversal Utilities for NAT (STUN) Extension for > > > > Third Party > > > > Authorization) to Proposed Standard > > > > > > > > (BEGIN IANA LAST CALL COMMENTS) > > > > > > > > IESG/Authors/WG Chairs: > > > > > > > > IANA has reviewed draft-ietf-tram-turn-third-party-authz-07 > > > > Authors > > > > should review the comments and/or questions below. Please report > > > > any inaccuracies and respond to any questions as soon as > > > > possible. > > > > > > > > IANA has questions about some of the IANA actions requested in > > > > the > > > > IANA Considerations section of this document. > > > > > > > > We received the following comments/questions from the IANA's > > > > reviewer: > > > > > > > > IANA understands that, upon approval of this document, there is a > > > > single action which IANA must complete. > > > > > > > > In the STUN Attributes subregistry of the Session Traversal > > > > Utilities for NAT > > > > (STUN) Parameters registry located at: > > > > > > > > http://www.iana.org/assignments/stun-parameters/ > > > > > > > > two new STUN attributes are to be registered as follows: > > > > > > > > Value: [ TBD-at-registration ] > > > > Name: THIRD-PARTY-AUTHORIZATION > > > > Reference: [ RFC-to-be ] > > > > > > > > Value: [ TBD-at-registration ] > > > > Name: ACCESS-TOKEN > > > > Reference: [ RFC-to-be ] > > > > > > > > Question: which range or ranges in the STUN Attributes registry > > > > the > > > > above two new > > > > attributes should be registered? The registry defines the > > > > following > > > > ranges: > > > > > > > > Range Registration Procedures Note > > > > 0x0000-0x3FFF IETF Review comprehension-required range > > > > 0x4000-0x7FFF Designated Expert comprehension-required > > > > range > > > > 0x8000-0xBFFF IETF Review comprehension-optional range > > > > 0xC000-0xFFFF Designated Expert comprehension-optional > > > > range > > > > > > > > It appears that section 6 defines the new attributes to be in two > > > > different ranges, comprehension-optional and comprehension- > > > > required. > > > > Is that > > > > correct? > > > > > > Yes. > > > > > > > If so, please either add the ranges in the IC section or add a > > > > pointer to section 6 in the IC section. > > > > > > NEW (IC section): > > > > > > [Paragraphs below in braces should be removed by the RFC Editor > > > upon > > > publication] > > > > > > [The THIRD-PARTY-AUTHORIZATION attribute requires that IANA > > > allocate a > > > value in the "STUN attributes Registry" from the > > > comprehension-optional range (0x8000-0xFFFF)] > > > > > > > As described above, the range 0x8000-0xFFFF has two different > > registration > > rules as defined by RFC5389. Which one of the following the new STUN > > attribute should be registered: > > > > 0x8000-0xBFFF IETF Review comprehension-optional range > > 0xC000-0xFFFF Designated Expert comprehension-optional range > > > > ? > > > > Should it be in 0x8000-0xBFFF? > > Yes, updated IC section and published revision to address the comment. > Great. Then IETF Review applies. Please update the IC section in the next version to include the texts we discussed. Thanks, ~pl > Thanks, > -Tiru > > > > > Thanks, > > ~pl > > > > > > > This document defines the THIRD-PARTY-AUTHORIZATION STUN attribute, > > > described in Section 6. IANA has allocated the comprehension- > > > optional > > > codepoint TBD for this attribute. > > > > > > [The ACCESS-TOKEN attribute requires that IANA allocate a value in > > > the > > > "STUN attributes Registry" from the comprehension-required range > > > (0x0000-0x3FFF)] > > > > > > This document defines the ACCESS-TOKEN STUN attribute, described in > > > Section 6. IANA has allocated the comprehension-required codepoint > > > TBD for this attribute. > > > > > > -Tiru > > > > > > > > > > > Further, if a new attribute is in the comprehension-optional > > > > range, > > > > the authors need to define which of the comprehension-optional > > > > ranges, 0x8000-0xBFFF or 0xC000-0xFFFF, the new attribute should > > > > be > > > > registered. > > > > So, if the authors pick "0x8000-0xBFFF" of the > > > > comprehension-optional range, IETF Review registration rule will > > > > be > > > > used. The IC section has no clear texts about these. > > > > > > > > > > > > IANA understands that this is the only action that needs to be > > > > completed upon approval of this document. > > > > > > > > Note: The actions requested in this document will not be > > > > completed > > > > until the document has been approved for publication as an RFC. > > > > This > > > > message is only to confirm what actions will be performed. > > > > > > > > > > > > Thanks, > > > > > > > > Pearl Liang > > > > ICANN > > > > > > > > (END IANA LAST CALL COMMENTS) > > > > > > > > On Wed Jan 21 20:03:33 2015, iesg-secretary@ietf.org wrote: > > > > > > > > > > The IESG has received a request from the TURN Revised and > > > > > Modernized WG > > > > > (tram) to consider the following document: > > > > > - 'Session Traversal Utilities for NAT (STUN) Extension for > > > > > Third > > > > > Party > > > > > Authorization' > > > > > as Proposed > > > > > Standard > > > > > > > > > > The IESG plans to make a decision in the next few weeks, and > > > > > solicits final comments on this action. Please send substantive > > > > > comments to the ietf@ietf.org mailing lists by 2015-02-04. > > > > > Exceptionally, comments may be sent to iesg@ietf.org instead. > > > > > In > > > > > either case, please retain the beginning of the Subject line to > > > > > allow automated sorting. > > > > > > > > > > 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 file can be obtained via > > > > > http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third- > > > > > party- > > > > > authz/ > > > > > > > > > > IESG discussion can be tracked via > > > > > http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third- > > > > > party- > > > > > authz/ballot/ > > > > > > > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > From nobody Sun Feb 1 05:01:55 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65EC1A1B74; Fri, 30 Jan 2015 09:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0CypOosDiyBN; Fri, 30 Jan 2015 09:02:37 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC9A1A1B3D; Fri, 30 Jan 2015 09:02:37 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t0UH2UpO007811; Fri, 30 Jan 2015 17:02:30 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 4E100C20350; Fri, 30 Jan 2015 17:02:30 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <913383AAA69FF945B8F946018B75898A3553387B@xmb-rcd-x10.cisco.com> References: <20150121200309.32037.30290.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553364C@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553387B@xmb-rcd-x10.cisco.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #806269 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Fri, 30 Jan 2015 17:02:30 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Sun, 01 Feb 2015 05:01:48 -0800 Cc: tireddy@cisco.com, tram@ietf.org, draft-ietf-tram-turn-third-party-authz@tools.ietf.org, liang@icann.org, tram-chairs@tools.ietf.org, iesg@ietf.org Subject: [tram] [IANA #806269] RE: RE: Last Call: (Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-issues@iana.org 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, 30 Jan 2015 17:02:43 -0000 On Thu Jan 29 05:01:50 2015, tireddy@cisco.com wrote: > > -----Original Message----- > > From: Pearl Liang via RT [mailto:iana-issues@iana.org] > > Sent: Thursday, January 29, 2015 9:01 AM > > Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org; draft-ietf-tram- > > turn-third- > > party-authz@tools.ietf.org; iesg@ietf.org; tram- > > chairs@tools.ietf.org; > > liang@icann.org > > Subject: [IANA #806090] RE: Last Call: > party-authz- > > 07.txt> (Session Traversal Utilities for NAT (STUN) Extension for > > Third Party > > Authorization) to Proposed Standard > > > > On Thu Jan 29 02:39:56 2015, tireddy@cisco.com wrote: > > > > -----Original Message----- > > > > From: Pearl Liang via RT [mailto:iana-issues@iana.org] > > > > Sent: Thursday, January 29, 2015 3:02 AM > > > > Cc: tram@ietf.org; draft-ietf-tram-turn-third-party- > > > > authz@tools.ietf.org; tram-chairs@tools.ietf.org; iesg@ietf.org; > > > > liang@icann.org > > > > Subject: [IANA #806090] RE: Last Call: > > > third- > > > > party-authz- > > > > 07.txt> (Session Traversal Utilities for NAT (STUN) Extension for > > > > Third Party > > > > Authorization) to Proposed Standard > > > > > > > > On Wed Jan 28 04:51:06 2015, tireddy@cisco.com wrote: > > > > > > -----Original Message----- > > > > > > From: Pearl Liang via RT [mailto:drafts-lastcall@iana.org] > > > > > > Sent: Wednesday, January 28, 2015 5:07 AM > > > > > > Cc: draft-ietf-tram-turn-third-party-authz@tools.ietf.org; > > > > > > tram- > > > > > > chairs@tools.ietf.org; iesg@ietf.org > > > > > > Subject: [IANA #804968] Last Call: > > > > > > > > > > > authz- > > > > > > 07.txt> (Session Traversal Utilities for NAT (STUN) Extension > > > > > > for Third Party > > > > > > Authorization) to Proposed Standard > > > > > > > > > > > > (BEGIN IANA LAST CALL COMMENTS) > > > > > > > > > > > > IESG/Authors/WG Chairs: > > > > > > > > > > > > IANA has reviewed draft-ietf-tram-turn-third-party-authz-07 > > > > > > Authors > > > > > > should review the comments and/or questions below. Please > > > > > > report any inaccuracies and respond to any questions as soon > > > > > > as > > > > > > possible. > > > > > > > > > > > > IANA has questions about some of the IANA actions requested > > > > > > in > > > > > > the IANA Considerations section of this document. > > > > > > > > > > > > We received the following comments/questions from the IANA's > > > > > > reviewer: > > > > > > > > > > > > IANA understands that, upon approval of this document, there > > > > > > is > > > > > > a single action which IANA must complete. > > > > > > > > > > > > In the STUN Attributes subregistry of the Session Traversal > > > > > > Utilities for NAT > > > > > > (STUN) Parameters registry located at: > > > > > > > > > > > > http://www.iana.org/assignments/stun-parameters/ > > > > > > > > > > > > two new STUN attributes are to be registered as follows: > > > > > > > > > > > > Value: [ TBD-at-registration ] > > > > > > Name: THIRD-PARTY-AUTHORIZATION > > > > > > Reference: [ RFC-to-be ] > > > > > > > > > > > > Value: [ TBD-at-registration ] > > > > > > Name: ACCESS-TOKEN > > > > > > Reference: [ RFC-to-be ] > > > > > > > > > > > > Question: which range or ranges in the STUN Attributes > > > > > > registry > > > > > > the above two new > > > > > > attributes should be registered? The registry defines the > > > > > > following > > > > > > ranges: > > > > > > > > > > > > Range Registration Procedures Note > > > > > > 0x0000-0x3FFF IETF Review comprehension-required range > > > > > > 0x4000-0x7FFF Designated Expert comprehension-required > > > > > > range > > > > > > 0x8000-0xBFFF IETF Review comprehension-optional range > > > > > > 0xC000-0xFFFF Designated Expert comprehension-optional > > > > > > range > > > > > > > > > > > > It appears that section 6 defines the new attributes to be in > > > > > > two different ranges, comprehension-optional and > > > > > > comprehension- > > > > > > required. > > > > > > Is that > > > > > > correct? > > > > > > > > > > Yes. > > > > > > > > > > > If so, please either add the ranges in the IC section or add > > > > > > a > > > > > > pointer to section 6 in the IC section. > > > > > > > > > > NEW (IC section): > > > > > > > > > > [Paragraphs below in braces should be removed by the RFC Editor > > > > > upon publication] > > > > > > > > > > [The THIRD-PARTY-AUTHORIZATION attribute requires that IANA > > > > > allocate a value in the "STUN attributes Registry" from the > > > > > comprehension-optional range (0x8000-0xFFFF)] > > > > > > > > > > > > > As described above, the range 0x8000-0xFFFF has two different > > > > registration > > > > rules as defined by RFC5389. Which one of the following the new > > > > STUN > > > > attribute should be registered: > > > > > > > > 0x8000-0xBFFF IETF Review comprehension-optional range > > > > 0xC000-0xFFFF Designated Expert comprehension-optional > > > > range > > > > > > > > ? > > > > > > > > Should it be in 0x8000-0xBFFF? > > > > > > Yes, updated IC section and published revision to address the > > > comment. > > > > > > > Great. Then IETF Review applies. Please update the IC section in > > the next > > version > > to include the texts we discussed. > > Revision https://tools.ietf.org/html/draft-ietf-tram-turn-third-party- > authz-08 includes the text discussed. > This version looks okay. Thanks, ~pl > Cheers, > -Tiru > > > > > Thanks, > > ~pl > > > > > > > Thanks, > > > -Tiru > > > > > > > > > > > Thanks, > > > > ~pl > > > > > > > > > > > > > This document defines the THIRD-PARTY-AUTHORIZATION STUN > > attribute, > > > > > described in Section 6. IANA has allocated the comprehension- > > > > > optional > > > > > codepoint TBD for this attribute. > > > > > > > > > > [The ACCESS-TOKEN attribute requires that IANA allocate a value > > > > > in > > > > > the > > > > > "STUN attributes Registry" from the comprehension-required > > > > > range > > > > > (0x0000-0x3FFF)] > > > > > > > > > > This document defines the ACCESS-TOKEN STUN attribute, > > > > > described in > > > > > Section 6. IANA has allocated the comprehension-required > > > > > codepoint > > > > > TBD for this attribute. > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > Further, if a new attribute is in the comprehension-optional > > > > > > range, > > > > > > the authors need to define which of the comprehension- > > > > > > optional > > > > > > ranges, 0x8000-0xBFFF or 0xC000-0xFFFF, the new attribute > > > > > > should > > > > > > be > > > > > > registered. > > > > > > So, if the authors pick "0x8000-0xBFFF" of the > > > > > > comprehension-optional range, IETF Review registration rule > > > > > > will > > > > > > be > > > > > > used. The IC section has no clear texts about these. > > > > > > > > > > > > > > > > > > IANA understands that this is the only action that needs to > > > > > > be > > > > > > completed upon approval of this document. > > > > > > > > > > > > Note: The actions requested in this document will not be > > > > > > completed > > > > > > until the document has been approved for publication as an > > > > > > RFC. > > > > > > This > > > > > > message is only to confirm what actions will be performed. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Pearl Liang > > > > > > ICANN > > > > > > > > > > > > (END IANA LAST CALL COMMENTS) > > > > > > From nobody Sun Feb 1 07:27:37 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987B91A8A4B for ; Sun, 1 Feb 2015 07:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnSmwKaiCkFW for ; Sun, 1 Feb 2015 07:27:33 -0800 (PST) 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 0B6741A8A51 for ; Sun, 1 Feb 2015 07:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30252; q=dns/txt; s=iport; t=1422804450; x=1424014050; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wmmKTsuZFDm6GGCNCq7ccM+dwCgmmQrKD3P67ze7V3E=; b=UkNXY9STYNXefp6HZkgJf4UlPrWsu9MPw5ZwYsGpKhSoBdSMEOmcrCqW uJqWjDB+Lesd+s+IVUW/rNfmeHX/rRAdPRG8wM22rUyxpbOhtExYWL9ph FtE+XwbR9ZrpndYqtfQY9Tf1tR8SjeKJgwBWboltuSHHRDIy9sTxUVSVi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B4BwAtRc5U/5NdJa1bgkNDUlQFBIJ9vzk8gV8BC4VvAhx2QwEBAQEBfYQMAQEBBAEBASAKQQsMBAIBCA4DBAEBCxYHAwICAh8GCxQJCAIEDgUIAYgQAxEIBb0YjzoNhVABAQEBAQEBAQEBAQEBAQEBAQEBAQEXjU6BeRYXBAYBBgOCXy6BEwWFfYkMg06EEYJdNoJNiAg9gkCDPSKDbm8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,502,1418083200"; d="scan'208,217";a="119485512" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP; 01 Feb 2015 15:27:28 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t11FRSWO018268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 1 Feb 2015 15:27:28 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Sun, 1 Feb 2015 09:27:28 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt Thread-Index: AQHQPEw30UXpKS+dFk6Udma1HT7B3pzYIAdggAMiCYD//9HbMIAAs3oAgAAQ34CAABT24A== Date: Sun, 1 Feb 2015 15:27:27 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3553522B@xmb-rcd-x10.cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553506F@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.58.57] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A3553522Bxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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: Sun, 01 Feb 2015 15:27:36 -0000 --_000_913383AAA69FF945B8F946018B75898A3553522Bxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbV0NClNlbnQ6 IFN1bmRheSwgRmVicnVhcnkgMDEsIDIwMTUgMTozOCBQTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkNCkNjOiB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RyYW1dIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxLnR4dA0KDQpJIGZvdW5kIGFub3RoZXIg dGhpbmcuIEluIHRoZSBzZWN0aW9uIDcuMSwgdGhlIHR1cm5iaXMgZG9jdW1lbnQgaXMgc2F5aW5n IHRoYXQ6DQoNCiJUaGUgY2xpZW50IE1VU1QgTk9UIGluY2x1ZGUgYW55IFJFUVVFU1RFRC1BRERS RVNTLUZBTUlMWSBhdHRyaWJ1dGUgaW4gaXRzIFJlZnJlc2ggUmVxdWVzdC4iDQpCdXQgaW4gdGhl IG5leHQgc2VjdGlvbiwgNy4yLCB0aGVyZSBpcyBhIHBhcmFncmFwaCB0aGF0IGRpc2N1c3NlcyB0 aGUgc2VydmVyIGJlaGF2aW91ciB3aGVuIGl0IHJlY2VpdmVzIHRoZSBSRVFVRVNURUQtQUREUkVT Uy1GQU1JTFkgYXR0cmlidXRlIGluIHRoZSBSRUZSRVNIIHJlcXVlc3QuIEkgZ3Vlc3MgdGhhdCBw YXJhZ3JhcGggc2xpcHBlZCBpbnRvIHR1cm5iaXMgZnJvbSBTU09EQSBkcmFmdCBhbmQgaWYgaGFz IHRvIGJlIHJlbW92ZWQuDQpbVFJdIFRoZSBwYXJhZ3JhcGggd2FzIHBpY2tlZCBmcm9tIFJGQyA2 MTU2OyBTZWN0aW9uIDUuMSBzYXlzIGNsaWVudCBNVVNUIG5vdCBpbmNsdWRlIGFueSBSQUYgYXR0 cmlidXRlIGluIGl0cyBSZWZyZXNoIHJlcXVlc3QgYW5kIHNlY3Rpb24gNS4yIGRpc2N1c3NlcyB0 aGUgc2VydmVyIGJlaGF2aW9yIHdoZW4gaXQgcmVjZWl2ZXMgUkFGDQo1LjI8aHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjE1NiNzZWN0aW9uLTUuMj4uICBSZWNlaXZpbmcgYSBSZWZyZXNo IFJlcXVlc3QNCiAgIElmIGEgc2VydmVyIHJlY2VpdmVzIGEgUmVmcmVzaCBSZXF1ZXN0IHdpdGgg YSBSRVFVRVNURUQtQUREUkVTUy0NCiAgIEZBTUlMWSBhdHRyaWJ1dGUsIGFuZCB0aGUgYXR0cmli dXRlJ3MgdmFsdWUgZG9lc24ndCBtYXRjaCB0aGUgYWRkcmVzcw0KICAgZmFtaWx5IG9mIHRoZSBh bGxvY2F0aW9uLCB0aGUgc2VydmVyIE1VU1QgcmVwbHkgd2l0aCBhIDQ0MyAoUGVlcg0KICAgQWRk cmVzcyBGYW1pbHkgTWlzbWF0Y2gpIFJlZnJlc2ggZXJyb3IgcmVzcG9uc2UuDQoNCi1UaXJ1DQoN Ci1UaXJ1DQpUaGFua3MNCk9sZWcNCg0KDQoNCk9uIFNhdCwgSmFuIDMxLCAyMDE1IGF0IDExOjA3 IFBNLCBPbGVnIE1vc2thbGVua28gPG1vbTA0MDI2N0BnbWFpbC5jb208bWFpbHRvOm1vbTA0MDI2 N0BnbWFpbC5jb20+PiB3cm90ZToNClRpcnUsIEkgZG8gbm90IHNlZSBhbnkgcHJvYmxlbSB3aXRo IEVWRU4tUE9SVCB3aGVuIGl0cyB2YWx1ZSBpcyAwLiBUaGUgcHJvYmxlbSBvbmx5IGFyaXNlcyB3 aGVuIEVWRU4tUE9SVCBpcyBlcXVhbHMgMHg4MCAocmVzZXJ2ZWQgYWxsb2NhdGlvbiByZXF1aXJl ZCkuIFNvIEknZCBzdWdnZXN0IGZvciBmb3JiaWQgb25seSB0aGUgc2l0dWF0aW9uIHdoZW4gdGhl IGhpZ2hlc3QgYml0IG9mIEVWRU4tUE9SVCBpcyAxLg0KVGhhbmtzDQpPbGVnDQoNCk9uIFNhdCwg SmFuIDMxLCAyMDE1IGF0IDY6MzYgUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgPHRp cmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KRnJvbTog T2xlZyBNb3NrYWxlbmtvIFttYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbTxtYWlsdG86bW9tMDQw MjY3QGdtYWlsLmNvbT5dDQpTZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDAxLCAyMDE1IDQ6NDAgQU0N ClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpDYzogdHJhbUBpZXRmLm9yZzxtYWls dG86dHJhbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi10cmFtLXR1cm5iaXMtMDEudHh0DQoNCkhpIFRpcnUNCmFzIHRoZSB0dXJuYmlzIHdyaXR0 ZW4sIGluIGl0cyBjdXJyZW50IGZvcm0sIGl0IGFsbG93cyBFVkVOLVBPUlQgYXR0cmlidXRlIGlu IHRoZSBBTExPQ0FURSByZXF1ZXN0IHRvZ2V0aGVyIHdpdGggdGhlIEFERElUSU9OQUwtQUREUkVT Uy1GQU1JTFkgYXR0cmlidXRlLiBJZiB0aGlzIGlzIHJlYWxseSB3aGF0IHlvdSB3YW50LCB0aGVu IHRoZSBSRVNFUlZBVElPTi1UT0tFTiBoYW5kbGluZyBtdXN0IGJlIGNoYW5nZWQgaW4gdGhlIEFM TE9DQVRFIHJlc3BvbnNlIC0gYmVjYXVzZSB0aGVyZSB3aWxsIGJlIHR3byBSRVNFUlZBVElPTi1U T0tFTiBhdHRyaWJ1dGVzIGluY2x1ZGVkIGludG8gdGhlIHJlc3BvbnNlICh3aGVuIEVWRU4tUE9S VD0xKS4NCk9yIHRoZSBFVkVOLVBPUlQgbXVzdCBiZSBwcm9oaWJpdGVkIGluIHRoZSBzYW1lIHJl cXVlc3Qgd2l0aCBBRERJVElPTkFMLUFERFJFU1MtRkFNSUxZLg0KQXMgb2Ygbm93LCB0aGVyZSBp cyBpbmhlcmVudCBpbmNvbnNpc3RlbmN5Lg0KW1RSXSBBZ3JlZWQsIHdpbGwgdXBkYXRlIHRoZSBk cmFmdCB0aGF0IEFBRiBtdXN0IG5vdCBiZSB1c2VkIHdpdGggZXZlbiBwb3J0Lg0KLVRpcnUNClRo YW5rcw0KT2xlZw0KDQoNCk9uIFRodSwgSmFuIDI5LCAyMDE1IGF0IDk6MzkgUE0sIFRpcnVtYWxl c3dhciBSZWRkeSAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNp c2NvLmNvbT4+IHdyb3RlOg0KTWFqb3IgY2hhbmdlcyBpbiB0aGlzIHJldmlzaW9uIGFyZSBzdXBw b3J0IGZvciBTU09EQSBhbmQgbWVyZ2VkIFJGQzYxNTYuIFBsZWFzZSByZXZpZXcgYW5kIHByb3Zp ZGUgeW91ciB2YWx1YWJsZSBjb21tZW50cy4NCkRpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uIDog aHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/ZGlmZnR5cGU9LS1od2RpZmYmdXJsMj1kcmFm dC1pZXRmLXRyYW0tdHVybmJpcy0wMS50eHQNCg0KLVRpcnUNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtDQo+IGRy YWZ0c0BpZXRmLm9yZzxtYWlsdG86ZHJhZnRzQGlldGYub3JnPg0KPiBTZW50OiBGcmlkYXksIEph bnVhcnkgMzAsIDIwMTUgMTA6NDggQU0NCj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWls dG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KPiBDYzogdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJh bUBpZXRmLm9yZz4NCj4gU3ViamVjdDogW3RyYW1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHJh bS10dXJuYmlzLTAxLnR4dA0KPg0KPg0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ICBUaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUVVJOIFJldmlzZWQgYW5kIE1vZGVybml6ZWQg V29ya2luZw0KPiBHcm91cCBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAgICBUaXRsZSAgICAgICAg ICAgOiBUcmF2ZXJzYWwgVXNpbmcgUmVsYXlzIGFyb3VuZCBOQVQgKFRVUk4pOiBSZWxheSBFeHRl bnNpb25zDQo+IHRvIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChTVFVOKQ0K PiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFRpcnVtYWxlc3dhciBSZWRkeQ0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgIEFsYW4gSm9obnN0b24NCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICBQaGlsaXAgTWF0dGhld3MNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBKb25hdGhh biBSb3NlbmJlcmcNCj4gICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi10cmFtLXR1 cm5iaXMtMDEudHh0DQo+ICAgICAgIFBhZ2VzICAgICAgICAgICA6IDc3DQo+ICAgICAgIERhdGUg ICAgICAgICAgICA6IDIwMTUtMDEtMjkNCj4NCj4gQWJzdHJhY3Q6DQo+ICAgIElmIGEgaG9zdCBp cyBsb2NhdGVkIGJlaGluZCBhIE5BVCwgdGhlbiBpbiBjZXJ0YWluIHNpdHVhdGlvbnMgaXQgY2Fu DQo+ICAgIGJlIGltcG9zc2libGUgZm9yIHRoYXQgaG9zdCB0byBjb21tdW5pY2F0ZSBkaXJlY3Rs eSB3aXRoIG90aGVyIGhvc3RzDQo+ICAgIChwZWVycykuICBJbiB0aGVzZSBzaXR1YXRpb25zLCBp dCBpcyBuZWNlc3NhcnkgZm9yIHRoZSBob3N0IHRvIHVzZQ0KPiAgICB0aGUgc2VydmljZXMgb2Yg YW4gaW50ZXJtZWRpYXRlIG5vZGUgdGhhdCBhY3RzIGFzIGEgY29tbXVuaWNhdGlvbg0KPiAgICBy ZWxheS4gIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgcHJvdG9jb2wsIGNhbGxlZCBUVVJO IChUcmF2ZXJzYWwNCj4gICAgVXNpbmcgUmVsYXlzIGFyb3VuZCBOQVQpLCB0aGF0IGFsbG93cyB0 aGUgaG9zdCB0byBjb250cm9sIHRoZQ0KPiAgICBvcGVyYXRpb24gb2YgdGhlIHJlbGF5IGFuZCB0 byBleGNoYW5nZSBwYWNrZXRzIHdpdGggaXRzIHBlZXJzIHVzaW5nDQo+ICAgIHRoZSByZWxheS4g IFRVUk4gZGlmZmVycyBmcm9tIHNvbWUgb3RoZXIgcmVsYXkgY29udHJvbCBwcm90b2NvbHMgaW4N Cj4gICAgdGhhdCBpdCBhbGxvd3MgYSBjbGllbnQgdG8gY29tbXVuaWNhdGUgd2l0aCBtdWx0aXBs ZSBwZWVycyB1c2luZyBhDQo+ICAgIHNpbmdsZSByZWxheSBhZGRyZXNzLg0KPg0KPiAgICBUaGUg VFVSTiBwcm90b2NvbCB3YXMgZGVzaWduZWQgdG8gYmUgdXNlZCBhcyBwYXJ0IG9mIHRoZSBJQ0UN Cj4gICAgKEludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2htZW50KSBhcHByb2FjaCB0 byBOQVQgdHJhdmVyc2FsLA0KPiAgICB0aG91Z2ggaXQgYWxzbyBjYW4gYmUgdXNlZCB3aXRob3V0 IElDRS4NCj4NCj4NCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg ZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt dHJhbS10dXJuYmlzLw0KPg0KPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWls YWJsZSBhdDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1 cm5iaXMtMDENCj4NCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Og0KPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRy YW0tdHVybmJpcy0wMQ0KPg0KPg0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8 aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCj4NCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2 YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiB0cmFtIG1haWxpbmcgbGlzdA0KPiB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFt QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0g bWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg0KDQo= --_000_913383AAA69FF945B8F946018B75898A3553522Bxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpoMw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoi SGVhZGluZyAzIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMy41cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsInNl cmlmIjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5CYWxs b29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhlYWRpbmczQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToiSGVhZGluZyAzIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1z dHlsZS1saW5rOiJIZWFkaW5nIDMiOw0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86bW9tMDQwMjY3QGdt YWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEZlYnJ1YXJ5IDAxLCAyMDE1IDE6 MzggUE08YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQo8 Yj5DYzo8L2I+IHRyYW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgZm91bmQgYW5vdGhlciB0aGluZy4gSW4gdGhlIHNl Y3Rpb24gNy4xLCB0aGUgdHVybmJpcyBkb2N1bWVudCBpcyBzYXlpbmcgdGhhdDo8bzpwPjwvbzpw PjwvcD4NCjxwcmU+JnF1b3Q7VGhlIGNsaWVudCBNVVNUIE5PVCBpbmNsdWRlIGFueSBSRVFVRVNU RUQtQUREUkVTUy1GQU1JTFkgYXR0cmlidXRlIGluIGl0cyBSZWZyZXNoIFJlcXVlc3QuJnF1b3Q7 PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5CdXQgaW4gdGhlIG5leHQgc2VjdGlvbiwgNy4yLCB0aGVyZSBp cyBhIHBhcmFncmFwaCB0aGF0IGRpc2N1c3NlcyB0aGUgc2VydmVyIGJlaGF2aW91ciB3aGVuIGl0 IHJlY2VpdmVzIHRoZSBSRVFVRVNURUQtQUREUkVTUy1GQU1JTFkgYXR0cmlidXRlIGluIHRoZSBS RUZSRVNIIHJlcXVlc3QuIEkgZ3Vlc3MgdGhhdCBwYXJhZ3JhcGggc2xpcHBlZCBpbnRvIHR1cm5i aXMNCiBmcm9tIFNTT0RBIGRyYWZ0IGFuZCBpZiBoYXMgdG8gYmUgcmVtb3ZlZC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5bVFJdIFRoZSBwYXJhZ3JhcGggd2FzIHBpY2tlZCBmcm9tIFJGQyA2MTU2 OyBTZWN0aW9uIDUuMSBzYXlzIGNsaWVudCBNVVNUIG5vdCBpbmNsdWRlIGFueSBSQUYgYXR0cmli dXRlIGluIGl0cyBSZWZyZXNoIHJlcXVlc3QgYW5kIHNlY3Rpb24gNS4yIGRpc2N1c3NlcyB0aGUN CiBzZXJ2ZXIgYmVoYXZpb3Igd2hlbiBpdCByZWNlaXZlcyBSQUYgJm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5h bWU9InNlY3Rpb24tNS4yIj48L2E+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNjE1NiNzZWN0aW9uLTUuMiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjUuMjwvc3Bhbj48L2I+PC9hPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4uJm5ic3A7DQogUmVjZWl2aW5nIGEgUmVmcmVzaCBSZXF1ZXN0PG86cD48L286cD48 L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgSWYgYSBzZXJ2ZXIgcmVjZWl2ZXMgYSBSZWZyZXNoIFJlcXVlc3Qgd2l0aCBhIFJFUVVFU1RF RC1BRERSRVNTLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgRkFNSUxZIGF0dHJpYnV0ZSwgYW5kIHRoZSBhdHRyaWJ1dGUn cyB2YWx1ZSBkb2Vzbid0IG1hdGNoIHRoZSBhZGRyZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBmYW1pbHkgb2YgdGhl IGFsbG9jYXRpb24sIHRoZSBzZXJ2ZXIgTVVTVCByZXBseSB3aXRoIGEgNDQzIChQZWVyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyBBZGRyZXNzIEZhbWlseSBNaXNtYXRjaCkgUmVmcmVzaCBlcnJvciByZXNwb25zZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8YnI+DQpPbGVnPGJyPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFNhdCwgSmFuIDMxLCAyMDE1IGF0IDExOjA3IFBNLCBPbGVnIE1vc2thbGVua28gJmx0 OzxhIGhyZWY9Im1haWx0bzptb20wNDAyNjdAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9t MDQwMjY3QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5UaXJ1LCBJIGRvIG5vdCBzZWUgYW55IHByb2JsZW0gd2l0aCBFVkVOLVBPUlQgd2hlbiBp dHMgdmFsdWUgaXMgMC4gVGhlIHByb2JsZW0gb25seSBhcmlzZXMgd2hlbiBFVkVOLVBPUlQgaXMg ZXF1YWxzIDB4ODAgKHJlc2VydmVkIGFsbG9jYXRpb24gcmVxdWlyZWQpLiBTbyBJJ2Qgc3VnZ2Vz dCBmb3IgZm9yYmlkIG9ubHkgdGhlIHNpdHVhdGlvbiB3aGVuIHRoZQ0KIGhpZ2hlc3QgYml0IG9m IEVWRU4tUE9SVCBpcyAxLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gY2xhc3M9ImhvZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPk9sZWc8L3Nw YW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBTYXQsIEphbiAzMSwgMjAxNSBhdCA2OjM2IFBNLCBUaXJ1bWFsZXN3 YXIgUmVkZHkgKHRpcmVkZHkpICZsdDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20i IHRhcmdldD0iX2JsYW5rIj50aXJlZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IE9sZWcgTW9za2FsZW5rbyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb20wNDAy NjdAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9tMDQwMjY3QGdtYWlsLmNvbTwvYT5dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBGZWJydWFyeSAwMSwgMjAxNSA0OjQwIEFNPGJyPg0K PGI+VG86PC9iPiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6PC9iPiA8 YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi10cmFtLXR1cm5iaXMtMDEudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIFRpcnU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5hcyB0aGUgdHVybmJpcyB3cml0dGVuLCBpbiBpdHMg Y3VycmVudCBmb3JtLCBpdCBhbGxvd3MgRVZFTi1QT1JUIGF0dHJpYnV0ZSBpbiB0aGUgQUxMT0NB VEUgcmVxdWVzdCB0b2dldGhlciB3aXRoIHRoZSBBRERJVElPTkFMLUFERFJFU1MtRkFNSUxZIGF0 dHJpYnV0ZS4gSWYgdGhpcyBpcyByZWFsbHkgd2hhdCB5b3Ugd2FudCwNCiB0aGVuIHRoZSBSRVNF UlZBVElPTi1UT0tFTiBoYW5kbGluZyBtdXN0IGJlIGNoYW5nZWQgaW4gdGhlIEFMTE9DQVRFIHJl c3BvbnNlIC0gYmVjYXVzZSB0aGVyZSB3aWxsIGJlIHR3byBSRVNFUlZBVElPTi1UT0tFTiBhdHRy aWJ1dGVzIGluY2x1ZGVkIGludG8gdGhlIHJlc3BvbnNlICh3aGVuIEVWRU4tUE9SVD0xKS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+T3IgdGhlIEVWRU4t UE9SVCBtdXN0IGJlIHByb2hpYml0ZWQgaW4gdGhlIHNhbWUgcmVxdWVzdCB3aXRoIEFERElUSU9O QUwtQUREUkVTUy1GQU1JTFkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPkFzIG9mIG5vdywgdGhlcmUgaXMgaW5oZXJlbnQgaW5jb25zaXN0ZW5jeS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPltUUl0gQWdyZWVkLCB3aWxsIHVwZGF0ZSB0aGUgZHJhZnQgdGhhdCBB QUYgbXVzdCBub3QgYmUgdXNlZCB3aXRoIGV2ZW4gcG9ydC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+VGhhbmtzPGJyPg0KT2xlZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBKYW4g MjksIDIwMTUgYXQgOTozOSBQTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBj aXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+TWFqb3IgY2hhbmdlcyBpbiB0aGlzIHJldmlzaW9uIGFyZSBzdXBwb3J0IGZvciBTU09E QSBhbmQgbWVyZ2VkIFJGQzYxNTYuIFBsZWFzZSByZXZpZXcgYW5kIHByb3ZpZGUgeW91ciB2YWx1 YWJsZSBjb21tZW50cy48YnI+DQpEaWZmIGZyb20gcHJldmlvdXMgdmVyc2lvbiA6IDxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP2RpZmZ0eXBlPS0taHdkaWZmJmFtcDt1cmwy PWRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/ZGlmZnR5cGU9LS1od2RpZmYmYW1wO3VybDI9ZHJhZnQt aWV0Zi10cmFtLXR1cm5iaXMtMDEudHh0PC9hPjxicj4NCjxicj4NCi1UaXJ1PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KJmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogdHJhbSBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtPGJyPg0KJmd0OyA8YSBo cmVmPSJtYWlsdG86ZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnRzQGlldGYu b3JnPC9hPjxicj4NCiZndDsgU2VudDogRnJpZGF5LCBKYW51YXJ5IDMwLCAyMDE1IDEwOjQ4IEFN PGJyPg0KJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IENjOiA8YSBo cmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFt LXR1cm5iaXMtMDEudHh0PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBk aXJlY3Rvcmllcy48YnI+DQomZ3Q7Jm5ic3A7IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2Yg dGhlIFRVUk4gUmV2aXNlZCBhbmQgTW9kZXJuaXplZCBXb3JraW5nPGJyPg0KJmd0OyBHcm91cCBv ZiB0aGUgSUVURi48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBU cmF2ZXJzYWwgVXNpbmcgUmVsYXlzIGFyb3VuZCBOQVQgKFRVUk4pOiBSZWxheSBFeHRlbnNpb25z PGJyPg0KJmd0OyB0byBTZXNzaW9uIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTik8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0F1dGhvcnMmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBUaXJ1bWFsZXN3YXIgUmVkZHk8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FsYW4gSm9obnN0b248YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BoaWxpcCBNYXR0 aGV3czxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Sm9u YXRoYW4gUm9zZW5iZXJnPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ZpbGVu YW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMt MDEudHh0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BhZ2VzJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDc3PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0RhdGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyA6IDIwMTUtMDEtMjk8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyBJZiBhIGhvc3QgaXMgbG9jYXRlZCBiZWhpbmQgYSBOQVQsIHRoZW4gaW4g Y2VydGFpbiBzaXR1YXRpb25zIGl0IGNhbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGJlIGltcG9z c2libGUgZm9yIHRoYXQgaG9zdCB0byBjb21tdW5pY2F0ZSBkaXJlY3RseSB3aXRoIG90aGVyIGhv c3RzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgKHBlZXJzKS4mbmJzcDsgSW4gdGhlc2Ugc2l0dWF0 aW9ucywgaXQgaXMgbmVjZXNzYXJ5IGZvciB0aGUgaG9zdCB0byB1c2U8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyB0aGUgc2VydmljZXMgb2YgYW4gaW50ZXJtZWRpYXRlIG5vZGUgdGhhdCBhY3RzIGFz IGEgY29tbXVuaWNhdGlvbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHJlbGF5LiZuYnNwOyBUaGlz IHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIHByb3RvY29sLCBjYWxsZWQgVFVSTiAoVHJhdmVyc2Fs PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgVXNpbmcgUmVsYXlzIGFyb3VuZCBOQVQpLCB0aGF0IGFs bG93cyB0aGUgaG9zdCB0byBjb250cm9sIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG9wZXJh dGlvbiBvZiB0aGUgcmVsYXkgYW5kIHRvIGV4Y2hhbmdlIHBhY2tldHMgd2l0aCBpdHMgcGVlcnMg dXNpbmc8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB0aGUgcmVsYXkuJm5ic3A7IFRVUk4gZGlmZmVy cyBmcm9tIHNvbWUgb3RoZXIgcmVsYXkgY29udHJvbCBwcm90b2NvbHMgaW48YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyB0aGF0IGl0IGFsbG93cyBhIGNsaWVudCB0byBjb21tdW5pY2F0ZSB3aXRoIG11 bHRpcGxlIHBlZXJzIHVzaW5nIGE8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBzaW5nbGUgcmVsYXkg YWRkcmVzcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgVGhlIFRVUk4gcHJvdG9j b2wgd2FzIGRlc2lnbmVkIHRvIGJlIHVzZWQgYXMgcGFydCBvZiB0aGUgSUNFPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgKEludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2htZW50KSBhcHBy b2FjaCB0byBOQVQgdHJhdmVyc2FsLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHRob3VnaCBpdCBh bHNvIGNhbiBiZSB1c2VkIHdpdGhvdXQgSUNFLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+ DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtdHJhbS10dXJuYmlzLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMvPC9hPjxicj4NCiZndDs8YnI+DQom Z3Q7IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxicj4NCiZn dDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1 cm5iaXMtMDEiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IEEgZGlmZiBm cm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7IDxhIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdHJhbS10dXJu YmlzLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMTwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCiZndDsgdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6PGJyPg0KJmd0OyA8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv PC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyB0cmFtIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEg aHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtQGlldGYub3Jn PC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90cmFtPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFt PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A3553522Bxmbrcdx10ciscoc_-- From nobody Sun Feb 1 07:43:58 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C78A1A8AA1 for ; Sun, 1 Feb 2015 07:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAiW82-X8LlR for ; Sun, 1 Feb 2015 07:43:52 -0800 (PST) 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 8D9391A8A99 for ; Sun, 1 Feb 2015 07:43:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23416; q=dns/txt; s=iport; t=1422805432; x=1424015032; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=o83E0dVlYBqADSSvut14dfJTmk8USOCIMm9aqAXHcmo=; b=MpC2sXM/4MFCoIaLy5mdz2ee1lGhYzVUxhJknd/3iCdLKV6qMxrDkZoZ DTcUYR0B6WG4C3/ovQG41z1+4pBQJSVq6g6SEaUH9rrzFFJdNVv4SwaMu 59cdtI+8nBJ82/WgwTBwU/kzubsm8GFgkicEbg8aMHilDsGC46TrLE+UG g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A/BgCnSM5U/4kNJK1bgkNDUlQFBIJ9vzk8gV8BC4VvAhx2QwEBAQEBfYQMAQEBBAEBASAKQQsMBAIBCA4DBAEBCx0DAgICHwYLFAkIAgQOBQgBiBADEQgFvRWPOg2FUAEBAQEBAQEBAQEBAQEBAQEBAQEBAReNToF5FhcEBgEGA4JfLoETBY8Jg06EEYJdNoJNiAg9gkCDPSKDbm8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,502,1418083200"; d="scan'208,217";a="119494522" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 01 Feb 2015 15:43:51 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t11Fhp2i007968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 1 Feb 2015 15:43:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Sun, 1 Feb 2015 09:43:51 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt Thread-Index: AQHQPEw30UXpKS+dFk6Udma1HT7B3pzYIAdggAMiCYD//9HbMIAAs3oAgAArW9A= Date: Sun, 1 Feb 2015 15:43:50 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35535244@xmb-rcd-x10.cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553506F@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.58.57] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35535244xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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: Sun, 01 Feb 2015 15:43:55 -0000 --_000_913383AAA69FF945B8F946018B75898A35535244xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbV0NClNlbnQ6 IFN1bmRheSwgRmVicnVhcnkgMDEsIDIwMTUgMTI6MzcgUE0NClRvOiBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpDQpDYzogdHJhbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0cmFtXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMS50eHQNCg0KVGlydSwgSSBkbyBub3Qg c2VlIGFueSBwcm9ibGVtIHdpdGggRVZFTi1QT1JUIHdoZW4gaXRzIHZhbHVlIGlzIDAuIFRoZSBw cm9ibGVtIG9ubHkgYXJpc2VzIHdoZW4gRVZFTi1QT1JUIGlzIGVxdWFscyAweDgwIChyZXNlcnZl ZCBhbGxvY2F0aW9uIHJlcXVpcmVkKS4gU28gSSdkIHN1Z2dlc3QgZm9yIGZvcmJpZCBvbmx5IHRo ZSBzaXR1YXRpb24gd2hlbiB0aGUgaGlnaGVzdCBiaXQgb2YgRVZFTi1QT1JUIGlzIDEuDQpbVFJd IFVwZGF0ZWQgZHJhZnQuDQotVGlydQ0KVGhhbmtzDQpPbGVnDQoNCk9uIFNhdCwgSmFuIDMxLCAy MDE1IGF0IDY6MzYgUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgPHRpcmVkZHlAY2lz Y28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KRnJvbTogT2xlZyBNb3Nr YWxlbmtvIFttYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbTxtYWlsdG86bW9tMDQwMjY3QGdtYWls LmNvbT5dDQpTZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDAxLCAyMDE1IDQ6NDAgQU0NClRvOiBUaXJ1 bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpDYzogdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFt LXR1cm5iaXMtMDEudHh0DQoNCkhpIFRpcnUNCmFzIHRoZSB0dXJuYmlzIHdyaXR0ZW4sIGluIGl0 cyBjdXJyZW50IGZvcm0sIGl0IGFsbG93cyBFVkVOLVBPUlQgYXR0cmlidXRlIGluIHRoZSBBTExP Q0FURSByZXF1ZXN0IHRvZ2V0aGVyIHdpdGggdGhlIEFERElUSU9OQUwtQUREUkVTUy1GQU1JTFkg YXR0cmlidXRlLiBJZiB0aGlzIGlzIHJlYWxseSB3aGF0IHlvdSB3YW50LCB0aGVuIHRoZSBSRVNF UlZBVElPTi1UT0tFTiBoYW5kbGluZyBtdXN0IGJlIGNoYW5nZWQgaW4gdGhlIEFMTE9DQVRFIHJl c3BvbnNlIC0gYmVjYXVzZSB0aGVyZSB3aWxsIGJlIHR3byBSRVNFUlZBVElPTi1UT0tFTiBhdHRy aWJ1dGVzIGluY2x1ZGVkIGludG8gdGhlIHJlc3BvbnNlICh3aGVuIEVWRU4tUE9SVD0xKS4NCk9y IHRoZSBFVkVOLVBPUlQgbXVzdCBiZSBwcm9oaWJpdGVkIGluIHRoZSBzYW1lIHJlcXVlc3Qgd2l0 aCBBRERJVElPTkFMLUFERFJFU1MtRkFNSUxZLg0KQXMgb2Ygbm93LCB0aGVyZSBpcyBpbmhlcmVu dCBpbmNvbnNpc3RlbmN5Lg0KW1RSXSBBZ3JlZWQsIHdpbGwgdXBkYXRlIHRoZSBkcmFmdCB0aGF0 IEFBRiBtdXN0IG5vdCBiZSB1c2VkIHdpdGggZXZlbiBwb3J0Lg0KLVRpcnUNClRoYW5rcw0KT2xl Zw0KDQoNCk9uIFRodSwgSmFuIDI5LCAyMDE1IGF0IDk6MzkgUE0sIFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+ IHdyb3RlOg0KTWFqb3IgY2hhbmdlcyBpbiB0aGlzIHJldmlzaW9uIGFyZSBzdXBwb3J0IGZvciBT U09EQSBhbmQgbWVyZ2VkIFJGQzYxNTYuIFBsZWFzZSByZXZpZXcgYW5kIHByb3ZpZGUgeW91ciB2 YWx1YWJsZSBjb21tZW50cy4NCkRpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uIDogaHR0cDovL3Rv b2xzLmlldGYub3JnL3JmY2RpZmY/ZGlmZnR5cGU9LS1od2RpZmYmdXJsMj1kcmFmdC1pZXRmLXRy YW0tdHVybmJpcy0wMS50eHQNCg0KLVRpcnUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0cmFt LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtDQo+IGRyYWZ0c0BpZXRm Lm9yZzxtYWlsdG86ZHJhZnRzQGlldGYub3JnPg0KPiBTZW50OiBGcmlkYXksIEphbnVhcnkgMzAs IDIwMTUgMTA6NDggQU0NCj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFu bm91bmNlQGlldGYub3JnPg0KPiBDYzogdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9y Zz4NCj4gU3ViamVjdDogW3RyYW1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlz LTAxLnR4dA0KPg0KPg0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ICBUaGlzIGRyYWZ0IGlz IGEgd29yayBpdGVtIG9mIHRoZSBUVVJOIFJldmlzZWQgYW5kIE1vZGVybml6ZWQgV29ya2luZw0K PiBHcm91cCBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBUcmF2 ZXJzYWwgVXNpbmcgUmVsYXlzIGFyb3VuZCBOQVQgKFRVUk4pOiBSZWxheSBFeHRlbnNpb25zDQo+ IHRvIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChTVFVOKQ0KPiAgICAgICAg IEF1dGhvcnMgICAgICAgICA6IFRpcnVtYWxlc3dhciBSZWRkeQ0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgIEFsYW4gSm9obnN0b24NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBQaGls aXAgTWF0dGhld3MNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBKb25hdGhhbiBSb3NlbmJl cmcNCj4gICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDEu dHh0DQo+ICAgICAgIFBhZ2VzICAgICAgICAgICA6IDc3DQo+ICAgICAgIERhdGUgICAgICAgICAg ICA6IDIwMTUtMDEtMjkNCj4NCj4gQWJzdHJhY3Q6DQo+ICAgIElmIGEgaG9zdCBpcyBsb2NhdGVk IGJlaGluZCBhIE5BVCwgdGhlbiBpbiBjZXJ0YWluIHNpdHVhdGlvbnMgaXQgY2FuDQo+ICAgIGJl IGltcG9zc2libGUgZm9yIHRoYXQgaG9zdCB0byBjb21tdW5pY2F0ZSBkaXJlY3RseSB3aXRoIG90 aGVyIGhvc3RzDQo+ICAgIChwZWVycykuICBJbiB0aGVzZSBzaXR1YXRpb25zLCBpdCBpcyBuZWNl c3NhcnkgZm9yIHRoZSBob3N0IHRvIHVzZQ0KPiAgICB0aGUgc2VydmljZXMgb2YgYW4gaW50ZXJt ZWRpYXRlIG5vZGUgdGhhdCBhY3RzIGFzIGEgY29tbXVuaWNhdGlvbg0KPiAgICByZWxheS4gIFRo aXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgcHJvdG9jb2wsIGNhbGxlZCBUVVJOIChUcmF2ZXJz YWwNCj4gICAgVXNpbmcgUmVsYXlzIGFyb3VuZCBOQVQpLCB0aGF0IGFsbG93cyB0aGUgaG9zdCB0 byBjb250cm9sIHRoZQ0KPiAgICBvcGVyYXRpb24gb2YgdGhlIHJlbGF5IGFuZCB0byBleGNoYW5n ZSBwYWNrZXRzIHdpdGggaXRzIHBlZXJzIHVzaW5nDQo+ICAgIHRoZSByZWxheS4gIFRVUk4gZGlm ZmVycyBmcm9tIHNvbWUgb3RoZXIgcmVsYXkgY29udHJvbCBwcm90b2NvbHMgaW4NCj4gICAgdGhh dCBpdCBhbGxvd3MgYSBjbGllbnQgdG8gY29tbXVuaWNhdGUgd2l0aCBtdWx0aXBsZSBwZWVycyB1 c2luZyBhDQo+ICAgIHNpbmdsZSByZWxheSBhZGRyZXNzLg0KPg0KPiAgICBUaGUgVFVSTiBwcm90 b2NvbCB3YXMgZGVzaWduZWQgdG8gYmUgdXNlZCBhcyBwYXJ0IG9mIHRoZSBJQ0UNCj4gICAgKElu dGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2htZW50KSBhcHByb2FjaCB0byBOQVQgdHJh dmVyc2FsLA0KPiAgICB0aG91Z2ggaXQgYWxzbyBjYW4gYmUgdXNlZCB3aXRob3V0IElDRS4NCj4N Cj4NCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJu YmlzLw0KPg0KPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoN Cj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDEN Cj4NCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRyYW0tdHVybmJp cy0wMQ0KPg0KPg0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rv b2xzLmlldGYub3JnPi4NCj4NCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz Lw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiB0cmFtIG1haWxpbmcgbGlzdA0KPiB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3Jn Pg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBs aXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg0K --_000_913383AAA69FF945B8F946018B75898A35535244xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9sZWcgTW9za2FsZW5rbyBb bWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBG ZWJydWFyeSAwMSwgMjAxNSAxMjozNyBQTTxicj4NCjxiPlRvOjwvYj4gVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KTxicj4NCjxiPkNjOjwvYj4gdHJhbUBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW3RyYW1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAx LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGlydSwgSSBkbyBu b3Qgc2VlIGFueSBwcm9ibGVtIHdpdGggRVZFTi1QT1JUIHdoZW4gaXRzIHZhbHVlIGlzIDAuIFRo ZSBwcm9ibGVtIG9ubHkgYXJpc2VzIHdoZW4gRVZFTi1QT1JUIGlzIGVxdWFscyAweDgwIChyZXNl cnZlZCBhbGxvY2F0aW9uIHJlcXVpcmVkKS4gU28gSSdkIHN1Z2dlc3QgZm9yIGZvcmJpZCBvbmx5 IHRoZSBzaXR1YXRpb24gd2hlbiB0aGUNCiBoaWdoZXN0IGJpdCBvZiBFVkVOLVBPUlQgaXMgMS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0g VXBkYXRlZCBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9sZWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFNhdCwgSmFuIDMxLCAyMDE1IGF0IDY6MzYgUE0sIFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkgJmx0OzxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnRpcmVkZHlAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vbTA0MDI2N0BnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb20wNDAyNjdAZ21haWwuY29tPC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBTdW5kYXksIEZlYnJ1YXJ5IDAxLCAyMDE1IDQ6NDAgQU08YnI+DQo8Yj5Ubzo8 L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9 Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBpZXRmLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRy YW0tdHVybmJpcy0wMS50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgVGlydTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPmFzIHRoZSB0dXJuYmlzIHdyaXR0ZW4sIGluIGl0cyBjdXJyZW50 IGZvcm0sIGl0IGFsbG93cyBFVkVOLVBPUlQgYXR0cmlidXRlIGluIHRoZSBBTExPQ0FURSByZXF1 ZXN0IHRvZ2V0aGVyIHdpdGggdGhlIEFERElUSU9OQUwtQUREUkVTUy1GQU1JTFkgYXR0cmlidXRl LiBJZiB0aGlzIGlzIHJlYWxseSB3aGF0IHlvdSB3YW50LA0KIHRoZW4gdGhlIFJFU0VSVkFUSU9O LVRPS0VOIGhhbmRsaW5nIG11c3QgYmUgY2hhbmdlZCBpbiB0aGUgQUxMT0NBVEUgcmVzcG9uc2Ug LSBiZWNhdXNlIHRoZXJlIHdpbGwgYmUgdHdvIFJFU0VSVkFUSU9OLVRPS0VOIGF0dHJpYnV0ZXMg aW5jbHVkZWQgaW50byB0aGUgcmVzcG9uc2UgKHdoZW4gRVZFTi1QT1JUPTEpLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5PciB0aGUgRVZFTi1QT1JUIG11 c3QgYmUgcHJvaGliaXRlZCBpbiB0aGUgc2FtZSByZXF1ZXN0IHdpdGggQURESVRJT05BTC1BRERS RVNTLUZBTUlMWS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+QXMgb2Ygbm93LCB0aGVyZSBpcyBpbmhlcmVudCBpbmNvbnNpc3RlbmN5LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+W1RSXSBBZ3JlZWQsIHdpbGwgdXBkYXRlIHRoZSBkcmFmdCB0aGF0IEFBRiBtdXN0 IG5vdCBiZSB1c2VkIHdpdGggZXZlbiBwb3J0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPi1UaXJ1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij5UaGFua3M8YnI+DQpPbGVnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIEphbiAyOSwgMjAx NSBhdCA5OjM5IFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpICZsdDs8YSBocmVmPSJt YWlsdG86dGlyZWRkeUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj50aXJlZGR5QGNpc2NvLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5N YWpvciBjaGFuZ2VzIGluIHRoaXMgcmV2aXNpb24gYXJlIHN1cHBvcnQgZm9yIFNTT0RBIGFuZCBt ZXJnZWQgUkZDNjE1Ni4gUGxlYXNlIHJldmlldyBhbmQgcHJvdmlkZSB5b3VyIHZhbHVhYmxlIGNv bW1lbnRzLjxicj4NCkRpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uIDogPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/ZGlmZnR5cGU9LS1od2RpZmYmYW1wO3VybDI9ZHJhZnQt aWV0Zi10cmFtLXR1cm5iaXMtMDEudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMu aWV0Zi5vcmcvcmZjZGlmZj9kaWZmdHlwZT0tLWh3ZGlmZiZhbXA7dXJsMj1kcmFmdC1pZXRmLXRy YW0tdHVybmJpcy0wMS50eHQ8L2E+PGJyPg0KPGJyPg0KLVRpcnU8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQomZ3Q7IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiB0cmFtIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW0tYm91bmNlc0Bp ZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC08YnI+DQomZ3Q7IDxhIGhyZWY9Im1h aWx0bzpkcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdHNAaWV0Zi5vcmc8L2E+ PGJyPg0KJmd0OyBTZW50OiBGcmlkYXksIEphbnVhcnkgMzAsIDIwMTUgMTA6NDggQU08YnI+DQom Z3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+aS1kLWFubm91bmNlQGlldGYub3JnPC9hPjxicj4NCiZndDsgQ2M6IDxhIGhyZWY9Im1h aWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBpZXRmLm9yZzwvYT48YnI+ DQomZ3Q7IFN1YmplY3Q6IFt0cmFtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRyYW0tdHVybmJp cy0wMS50eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQSBOZXcgSW50ZXJuZXQtRHJh ZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9y aWVzLjxicj4NCiZndDsmbmJzcDsgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgVFVS TiBSZXZpc2VkIGFuZCBNb2Rlcm5pemVkIFdvcmtpbmc8YnI+DQomZ3Q7IEdyb3VwIG9mIHRoZSBJ RVRGLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O1RpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IFRyYXZlcnNh bCBVc2luZyBSZWxheXMgYXJvdW5kIE5BVCAoVFVSTik6IFJlbGF5IEV4dGVuc2lvbnM8YnI+DQom Z3Q7IHRvIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChTVFVOKTxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QXV0aG9ycyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs6IFRpcnVtYWxlc3dhciBSZWRkeTxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QWxhbiBKb2huc3Rvbjxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UGhpbGlwIE1hdHRoZXdzPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtKb25hdGhhbiBS b3NlbmJlcmc8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RmlsZW5hbWUmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMS50eHQ8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UGFnZXMmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogNzc8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7RGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDog MjAxNS0wMS0yOTxicj4NCiZndDs8YnI+DQomZ3Q7IEFic3RyYWN0Ojxicj4NCiZndDsmbmJzcDsg Jm5ic3A7IElmIGEgaG9zdCBpcyBsb2NhdGVkIGJlaGluZCBhIE5BVCwgdGhlbiBpbiBjZXJ0YWlu IHNpdHVhdGlvbnMgaXQgY2FuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgYmUgaW1wb3NzaWJsZSBm b3IgdGhhdCBob3N0IHRvIGNvbW11bmljYXRlIGRpcmVjdGx5IHdpdGggb3RoZXIgaG9zdHM8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAocGVlcnMpLiZuYnNwOyBJbiB0aGVzZSBzaXR1YXRpb25zLCBp dCBpcyBuZWNlc3NhcnkgZm9yIHRoZSBob3N0IHRvIHVzZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7 IHRoZSBzZXJ2aWNlcyBvZiBhbiBpbnRlcm1lZGlhdGUgbm9kZSB0aGF0IGFjdHMgYXMgYSBjb21t dW5pY2F0aW9uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgcmVsYXkuJm5ic3A7IFRoaXMgc3BlY2lm aWNhdGlvbiBkZWZpbmVzIGEgcHJvdG9jb2wsIGNhbGxlZCBUVVJOIChUcmF2ZXJzYWw8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyBVc2luZyBSZWxheXMgYXJvdW5kIE5BVCksIHRoYXQgYWxsb3dzIHRo ZSBob3N0IHRvIGNvbnRyb2wgdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgb3BlcmF0aW9uIG9m IHRoZSByZWxheSBhbmQgdG8gZXhjaGFuZ2UgcGFja2V0cyB3aXRoIGl0cyBwZWVycyB1c2luZzxi cj4NCiZndDsmbmJzcDsgJm5ic3A7IHRoZSByZWxheS4mbmJzcDsgVFVSTiBkaWZmZXJzIGZyb20g c29tZSBvdGhlciByZWxheSBjb250cm9sIHByb3RvY29scyBpbjxicj4NCiZndDsmbmJzcDsgJm5i c3A7IHRoYXQgaXQgYWxsb3dzIGEgY2xpZW50IHRvIGNvbW11bmljYXRlIHdpdGggbXVsdGlwbGUg cGVlcnMgdXNpbmcgYTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHNpbmdsZSByZWxheSBhZGRyZXNz Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBUaGUgVFVSTiBwcm90b2NvbCB3YXMg ZGVzaWduZWQgdG8gYmUgdXNlZCBhcyBwYXJ0IG9mIHRoZSBJQ0U8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAoSW50ZXJhY3RpdmUgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQpIGFwcHJvYWNoIHRv IE5BVCB0cmF2ZXJzYWwsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgdGhvdWdoIGl0IGFsc28gY2Fu IGJlIHVzZWQgd2l0aG91dCBJQ0UuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCiZndDsg PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFt LXR1cm5iaXMvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhl cmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6PGJyPg0KJmd0OyA8YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0w MSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi10cmFtLXR1cm5iaXMtMDE8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgQSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsgPGEgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDEi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWlldGYtdHJhbS10dXJuYmlzLTAxPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KJmd0OyB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCiZndDs8YnI+DQomZ3Q7 IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8 YnI+DQomZ3Q7IDxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0 YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2E+PGJy Pg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7IHRyYW0gbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJt YWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ry YW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RyYW08L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp0 cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A35535244xmbrcdx10ciscoc_-- From nobody Sun Feb 1 11:07:41 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1D81A908B for ; Sun, 1 Feb 2015 11:07:34 -0800 (PST) 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 ldOudR9dTNDF for ; Sun, 1 Feb 2015 11:07:30 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C781A9084 for ; Sun, 1 Feb 2015 11:07:29 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so35479120wes.10 for ; Sun, 01 Feb 2015 11:07:28 -0800 (PST) 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=O9F9KdkJOo49S/kyqmUx8VuZ3xfQKSw9+JmLOtYKR44=; b=uZFh6yBO7fUZtXD4xAzpm1lvTsApy9a2l4THtoxEL5uhWlonfkaX3Qyqsau0JQ1Koy T9BSox451ECTh4TcA48OcCJKm12PYXb+xk19WBQshf/87YPA6WlZl43h015AKn+8Bww3 d2A52/94uis/XlIjV+6WSEq7w5zOceIH+dNdjknhd9ykaGIRnkXWeG3Lqodd5b2YycO2 F1EP1bytdxlXLpq8NygyoiCvqU0ZJqz5b+lDzxwj4972UgwAcir04qNCVbZ9x1z9GZdW gfhxI68BNHKwo5I/p8REnK37Y4GWvuVzIgqxAlTja/k1e9+gAl73E3+stOUr6yLmRcT4 fF0A== MIME-Version: 1.0 X-Received: by 10.194.2.240 with SMTP id 16mr36283540wjx.108.1422817647895; Sun, 01 Feb 2015 11:07:27 -0800 (PST) Received: by 10.194.87.98 with HTTP; Sun, 1 Feb 2015 11:07:27 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A3553522B@xmb-rcd-x10.cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553506F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553522B@xmb-rcd-x10.cisco.com> Date: Sun, 1 Feb 2015 11:07:27 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b343d847baaa0050e0b8c8e Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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: Sun, 01 Feb 2015 19:07:35 -0000 --047d7b343d847baaa0050e0b8c8e Content-Type: text/plain; charset=UTF-8 On Sun, Feb 1, 2015 at 7:27 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > *From:* Oleg Moskalenko [mailto:mom040267@gmail.com] > *Sent:* Sunday, February 01, 2015 1:38 PM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt > > > > I found another thing. In the section 7.1, the turnbis document is saying > that: > > "The client MUST NOT include any REQUESTED-ADDRESS-FAMILY attribute in its Refresh Request." > > But in the next section, 7.2, there is a paragraph that discusses the > server behaviour when it receives the REQUESTED-ADDRESS-FAMILY attribute in > the REFRESH request. I guess that paragraph slipped into turnbis from SSODA > draft and if has to be removed. > > [TR] The paragraph was picked from RFC 6156; Section 5.1 says client MUST > not include any RAF attribute in its Refresh request and section 5.2 > discusses the server behavior when it receives RAF > > *5.2* *. Receiving a > Refresh Request* > > If a server receives a Refresh Request with a REQUESTED-ADDRESS- > > FAMILY attribute, and the attribute's value doesn't match the address > > family of the allocation, the server MUST reply with a 443 (Peer > > Address Family Mismatch) Refresh error response. > > > Tiru, I got that. But could you please explain why it is written that way ? As it is now, I see two points: 1) The legacy RFC 6156-compliant clients are not turnbis-compliant - because they include RAF into REFRESH; 2) The legacy RFC 6156-compliant clients are compatible with the new turnbis-servers - because the turnbis-servers know how to handle RAF in REFRESH. Was that what you were trying to achieve ? Thanks Oleg > > > > > > On Sat, Jan 31, 2015 at 11:07 PM, Oleg Moskalenko > wrote: > > Tiru, I do not see any problem with EVEN-PORT when its value is 0. The > problem only arises when EVEN-PORT is equals 0x80 (reserved allocation > required). So I'd suggest for forbid only the situation when the highest > bit of EVEN-PORT is 1. > > Thanks > > Oleg > > > > On Sat, Jan 31, 2015 at 6:36 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > *From:* Oleg Moskalenko [mailto:mom040267@gmail.com] > *Sent:* Sunday, February 01, 2015 4:40 AM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt > > > > Hi Tiru > > as the turnbis written, in its current form, it allows EVEN-PORT attribute > in the ALLOCATE request together with the ADDITIONAL-ADDRESS-FAMILY > attribute. If this is really what you want, then the RESERVATION-TOKEN > handling must be changed in the ALLOCATE response - because there will be > two RESERVATION-TOKEN attributes included into the response (when > EVEN-PORT=1). > > Or the EVEN-PORT must be prohibited in the same request with > ADDITIONAL-ADDRESS-FAMILY. > > As of now, there is inherent inconsistency. > > [TR] Agreed, will update the draft that AAF must not be used with even > port. > > -Tiru > > Thanks > Oleg > > > > > > On Thu, Jan 29, 2015 at 9:39 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Major changes in this revision are support for SSODA and merged RFC6156. > Please review and provide your valuable comments. > Diff from previous version : > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tram-turnbis-01.txt > > -Tiru > > > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: Friday, January 30, 2015 10:48 AM > > To: i-d-announce@ietf.org > > Cc: tram@ietf.org > > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt > > > > > > 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 : Traversal Using Relays around NAT (TURN): > Relay Extensions > > to Session Traversal Utilities for NAT (STUN) > > Authors : Tirumaleswar Reddy > > Alan Johnston > > Philip Matthews > > Jonathan Rosenberg > > Filename : draft-ietf-tram-turnbis-01.txt > > Pages : 77 > > Date : 2015-01-29 > > > > Abstract: > > If a host is located behind a NAT, then in certain situations it can > > be impossible for that host to communicate directly with other hosts > > (peers). In these situations, it is necessary for the host to use > > the services of an intermediate node that acts as a communication > > relay. This specification defines a protocol, called TURN (Traversal > > Using Relays around NAT), that allows the host to control the > > operation of the relay and to exchange packets with its peers using > > the relay. TURN differs from some other relay control protocols in > > that it allows a client to communicate with multiple peers using a > > single relay address. > > > > The TURN protocol was designed to be used as part of the ICE > > (Interactive Connectivity Establishment) approach to NAT traversal, > > though it also can be used without ICE. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-tram-turnbis-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-01 > > > > > > 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 > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > > > --047d7b343d847baaa0050e0b8c8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Feb 1, 2015 at 7:27 AM, Tirumaleswar Reddy (tireddy) <tireddy= @cisco.com> wrote:

From: Oleg Mos= kalenko [mailto:mo= m040267@gmail.com]
Sent: Sunday, February 01, 2015 1:38 PM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org=
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

=C2=A0

I found another thing= . In the section 7.1, the turnbis document is saying that: 

"The client MUST NOT include any REQUESTED-ADDRESS-FAMILY attribu=
te in its Refresh Request."

But in the next secti= on, 7.2, there is a paragraph that discusses the server behaviour when it r= eceives the REQUESTED-ADDRESS-FAMILY attribute in the REFRESH request. I gu= ess that paragraph slipped into turnbis from SSODA draft and if has to be removed.

[TR] The paragraph= was picked from RFC 6156; Section 5.1 says client MUST not include any RAF= attribute in its Refresh request and section 5.2 discusses the server behavior when it receives RAF =C2=A0

5.2.=C2=A0 Receiving a Refresh Request

=C2=A0=C2=A0 If a server receives a Refresh Request with a= REQUESTED-ADDRESS-

=C2=A0=C2=A0 FAMILY attribute, and the attribute's val= ue doesn't match the address

=C2=A0=C2=A0 family of the allocation, the server MUST rep= ly with a 443 (Peer

=C2=A0=C2=A0 Address Family Mismatch) Refresh error respon= se.

=C2=A0


Tiru, I got that= . But could you please explain why it is written that way ? As it is now, I= see two points:

1) The legacy RFC 6156-compliant clients= are not turnbis-compliant - because they include RAF into REFRESH;
2) The legacy RFC 6156-compliant clients are compatible with the new= turnbis-servers - because the turnbis-servers know how to handle RAF in RE= FRESH.

Was that what you were trying to achieve ?

Thanks
Oleg

=C2=A0

=C2=A0

=C2=A0

On Sat, Jan 31, 2015 at 11:07 PM, Oleg Moskalenko &l= t;mom040267@gmail.= com> wrote:

Tiru, I do not see an= y problem with EVEN-PORT when its value is 0. The problem only arises when = EVEN-PORT is equals 0x80 (reserved allocation required). So I'd suggest= for forbid only the situation when the highest bit of EVEN-PORT is 1.

Thanks

Oleg

=C2=A0

On Sat, Jan 31, 2015 at 6:36 PM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

From: Oleg Mos= kalenko [mailto:mo= m040267@gmail.com]
Sent: Sunday, February 01, 2015 4:40 AM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org=
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

=C2=A0

Hi Tiru=

as the turnbis writte= n, in its current form, it allows EVEN-PORT attribute in the ALLOCATE reque= st together with the ADDITIONAL-ADDRESS-FAMILY attribute. If this is really= what you want, then the RESERVATION-TOKEN handling must be changed in the ALLOCATE respon= se - because there will be two RESERVATION-TOKEN attributes included into t= he response (when EVEN-PORT=3D1).

Or the EVEN-PORT must= be prohibited in the same request with ADDITIONAL-ADDRESS-FAMILY.

As of now, there is i= nherent inconsistency.

[TR] Agreed, will update the draft that AAF must not be used with eve= n port.

-Tiru

Thanks
Oleg

=C2=A0

=C2=A0

On Thu, Jan 29, 2015 at 9:39 PM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

Major changes in this revision are support for SSODA= and merged RFC6156. Please review and provide your valuable comments.
Diff from previous version : http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-tra= m-turnbis-01.txt

-Tiru


> -----Original Message-----
> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Friday, January 30, 2015 10:48 AM
> To: i-d-ann= ounce@ietf.org
> Cc: tram@ietf.org
> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-01.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: Traversal Using Relays around NAT (TURN): Relay Extensions
> to Session Traversal Utilities for NAT (STUN)
>=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=A0Alan Johnston
>=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=A0Philip Matthews
>=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=A0Jonathan Rosenberg
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tram-turnbis-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 77
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-01-29
>
> Abstract:
>=C2=A0 =C2=A0 If a host is located behind a NAT, then in certain situat= ions it can
>=C2=A0 =C2=A0 be impossible for that host to communicate directly with = other hosts
>=C2=A0 =C2=A0 (peers).=C2=A0 In these situations, it is necessary for t= he host to use
>=C2=A0 =C2=A0 the services of an intermediate node that acts as a commu= nication
>=C2=A0 =C2=A0 relay.=C2=A0 This specification defines a protocol, calle= d TURN (Traversal
>=C2=A0 =C2=A0 Using Relays around NAT), that allows the host to control= the
>=C2=A0 =C2=A0 operation of the relay and to exchange packets with its p= eers using
>=C2=A0 =C2=A0 the relay.=C2=A0 TURN differs from some other relay contr= ol protocols in
>=C2=A0 =C2=A0 that it allows a client to communicate with multiple peer= s using a
>=C2=A0 =C2=A0 single relay address.
>
>=C2=A0 =C2=A0 The TURN protocol was designed to be used as part of the = ICE
>=C2=A0 =C2=A0 (Interactive Connectivity Establishment) approach to NAT = traversal,
>=C2=A0 =C2=A0 though it also can be used without ICE.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tram-turnbis-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-01
>
>
> 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

=C2=A0

=C2=A0

=C2=A0


--047d7b343d847baaa0050e0b8c8e-- From nobody Sun Feb 1 18:50:36 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464071A9148 for ; Sun, 1 Feb 2015 18:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf77OC_TnmHH for ; Sun, 1 Feb 2015 18:50:31 -0800 (PST) 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 CC2731A9147 for ; Sun, 1 Feb 2015 18:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36730; q=dns/txt; s=iport; t=1422845431; x=1424055031; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VbICbsAsFf4fwHWFVFNGGxZsBx1sK/ZxSPQCupn2MNE=; b=fevjdjnfFhSOg0teGcUnidyMhfy9gRF+LJhVNj0N74HtZ+BvuHeE6u4W s1PJi4G7Xr7YEjNE0BhU3nqd4VdLoBrGz7jXb0miawvsGRxu8VEDPvQvo HyZEfewozRvxHEf86/K32bugO1AL/kBrWDom15SV7bMDEoJ/Xfy7Pj7Ta g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0HADDlzlStJA2H/2dsb2JhbABbgkNDUlQFBIJ9vz48gV8BC4VvAhx4QwEBAQEBfYQMAQEBBAEBASAKQQsMBAIBCA4DBAEBCxYHAwICAh8GCxQJCAIEDgUIAYgQAxEIBb0ij1oNhVABAQEBAQEBAQEBAQEBAQEBAQEBAQEXjU6BeRYXBAYBBgOCXy6BEwWFfYkMg06EEYJdNoJNiAg9gkCDPSKDbm8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,503,1418083200"; d="scan'208,217";a="392567487" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 02 Feb 2015 02:50:29 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t122oT0B022680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Feb 2015 02:50:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Sun, 1 Feb 2015 20:50:29 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt Thread-Index: AQHQPEw30UXpKS+dFk6Udma1HT7B3pzYIAdggAMiCYD//9HbMIAAs3oAgAAQ34CAABT24IAAo2WAgAAbqJA= Date: Mon, 2 Feb 2015 02:50:28 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3553539F@xmb-rcd-x10.cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553506F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553522B@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.12] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A3553539Fxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 02 Feb 2015 02:50:34 -0000 --_000_913383AAA69FF945B8F946018B75898A3553539Fxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUjJdDQoNCkZyb206IE9sZWcgTW9za2FsZW5rbyBbbWFpbHRvOm1vbTA0MDI2N0Bn bWFpbC5jb21dDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDAyLCAyMDE1IDEyOjM3IEFNDQpUbzog VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KQ2M6IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDEudHh0DQoN Cg0KDQpPbiBTdW4sIEZlYiAxLCAyMDE1IGF0IDc6MjcgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdy b3RlOg0KRnJvbTogT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbTxt YWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbT5dDQpTZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDAxLCAy MDE1IDE6MzggUE0NClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpDYzogdHJhbUBp ZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdHJhbV0gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDEudHh0DQoNCkkgZm91bmQgYW5vdGhlciB0 aGluZy4gSW4gdGhlIHNlY3Rpb24gNy4xLCB0aGUgdHVybmJpcyBkb2N1bWVudCBpcyBzYXlpbmcg dGhhdDoNCg0KIlRoZSBjbGllbnQgTVVTVCBOT1QgaW5jbHVkZSBhbnkgUkVRVUVTVEVELUFERFJF U1MtRkFNSUxZIGF0dHJpYnV0ZSBpbiBpdHMgUmVmcmVzaCBSZXF1ZXN0LiINCkJ1dCBpbiB0aGUg bmV4dCBzZWN0aW9uLCA3LjIsIHRoZXJlIGlzIGEgcGFyYWdyYXBoIHRoYXQgZGlzY3Vzc2VzIHRo ZSBzZXJ2ZXIgYmVoYXZpb3VyIHdoZW4gaXQgcmVjZWl2ZXMgdGhlIFJFUVVFU1RFRC1BRERSRVNT LUZBTUlMWSBhdHRyaWJ1dGUgaW4gdGhlIFJFRlJFU0ggcmVxdWVzdC4gSSBndWVzcyB0aGF0IHBh cmFncmFwaCBzbGlwcGVkIGludG8gdHVybmJpcyBmcm9tIFNTT0RBIGRyYWZ0IGFuZCBpZiBoYXMg dG8gYmUgcmVtb3ZlZC4NCltUUl0gVGhlIHBhcmFncmFwaCB3YXMgcGlja2VkIGZyb20gUkZDIDYx NTY7IFNlY3Rpb24gNS4xIHNheXMgY2xpZW50IE1VU1Qgbm90IGluY2x1ZGUgYW55IFJBRiBhdHRy aWJ1dGUgaW4gaXRzIFJlZnJlc2ggcmVxdWVzdCBhbmQgc2VjdGlvbiA1LjIgZGlzY3Vzc2VzIHRo ZSBzZXJ2ZXIgYmVoYXZpb3Igd2hlbiBpdCByZWNlaXZlcyBSQUYNCjUuMjxodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM2MTU2I3NlY3Rpb24tNS4yPi4gIFJlY2VpdmluZyBhIFJlZnJlc2gg UmVxdWVzdA0KICAgSWYgYSBzZXJ2ZXIgcmVjZWl2ZXMgYSBSZWZyZXNoIFJlcXVlc3Qgd2l0aCBh IFJFUVVFU1RFRC1BRERSRVNTLQ0KICAgRkFNSUxZIGF0dHJpYnV0ZSwgYW5kIHRoZSBhdHRyaWJ1 dGUncyB2YWx1ZSBkb2Vzbid0IG1hdGNoIHRoZSBhZGRyZXNzDQogICBmYW1pbHkgb2YgdGhlIGFs bG9jYXRpb24sIHRoZSBzZXJ2ZXIgTVVTVCByZXBseSB3aXRoIGEgNDQzIChQZWVyDQogICBBZGRy ZXNzIEZhbWlseSBNaXNtYXRjaCkgUmVmcmVzaCBlcnJvciByZXNwb25zZS4NCg0KDQpUaXJ1LCBJ IGdvdCB0aGF0LiBCdXQgY291bGQgeW91IHBsZWFzZSBleHBsYWluIHdoeSBpdCBpcyB3cml0dGVu IHRoYXQgd2F5ID8NCltUUjJdIEkgZG9u4oCZdCBrbm93IHdoeSBpdCBpcyB3cml0dGVuIGxpa2Ug dGhhdCA/DQpTaW1vbi9Hb256YWxvIC0gIENhbiB5b3UgcGxlYXNlIGNsYXJpZnkgdGhlIHJlYXNv bmluZyBmb3IgU2VjdGlvbiA1LjINCkFzIGl0IGlzIG5vdywgSSBzZWUgdHdvIHBvaW50czoNCjEp IFRoZSBsZWdhY3kgUkZDIDYxNTYtY29tcGxpYW50IGNsaWVudHMgYXJlIG5vdCB0dXJuYmlzLWNv bXBsaWFudCAtIGJlY2F1c2UgdGhleSBpbmNsdWRlIFJBRiBpbnRvIFJFRlJFU0g7DQoyKSBUaGUg bGVnYWN5IFJGQyA2MTU2LWNvbXBsaWFudCBjbGllbnRzIGFyZSBjb21wYXRpYmxlIHdpdGggdGhl IG5ldyB0dXJuYmlzLXNlcnZlcnMgLSBiZWNhdXNlIHRoZSB0dXJuYmlzLXNlcnZlcnMga25vdyBo b3cgdG8gaGFuZGxlIFJBRiBpbiBSRUZSRVNILg0KV2FzIHRoYXQgd2hhdCB5b3Ugd2VyZSB0cnlp bmcgdG8gYWNoaWV2ZSA/DQoNCltUUjIgUG9pbnQgMiAoV2UgY2Fubm90IHByb2NlZWQgd2l0aCBw b2ludCAxIGJlY2F1c2UgaXQgd2lsbCBicmVhayBiYWNrd2FyZCBjb21wYXRpYmlsaXR5KQ0KDQot VGlydQ0KDQpUaGFua3MNCk9sZWcNCg0KDQoNCg0KT24gU2F0LCBKYW4gMzEsIDIwMTUgYXQgMTE6 MDcgUE0sIE9sZWcgTW9za2FsZW5rbyA8bW9tMDQwMjY3QGdtYWlsLmNvbTxtYWlsdG86bW9tMDQw MjY3QGdtYWlsLmNvbT4+IHdyb3RlOg0KVGlydSwgSSBkbyBub3Qgc2VlIGFueSBwcm9ibGVtIHdp dGggRVZFTi1QT1JUIHdoZW4gaXRzIHZhbHVlIGlzIDAuIFRoZSBwcm9ibGVtIG9ubHkgYXJpc2Vz IHdoZW4gRVZFTi1QT1JUIGlzIGVxdWFscyAweDgwIChyZXNlcnZlZCBhbGxvY2F0aW9uIHJlcXVp cmVkKS4gU28gSSdkIHN1Z2dlc3QgZm9yIGZvcmJpZCBvbmx5IHRoZSBzaXR1YXRpb24gd2hlbiB0 aGUgaGlnaGVzdCBiaXQgb2YgRVZFTi1QT1JUIGlzIDEuDQpUaGFua3MNCk9sZWcNCg0KT24gU2F0 LCBKYW4gMzEsIDIwMTUgYXQgNjozNiBQTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8 dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQpGcm9t OiBPbGVnIE1vc2thbGVua28gW21haWx0bzptb20wNDAyNjdAZ21haWwuY29tPG1haWx0bzptb20w NDAyNjdAZ21haWwuY29tPl0NClNlbnQ6IFN1bmRheSwgRmVicnVhcnkgMDEsIDIwMTUgNDo0MCBB TQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiB0cmFtQGlldGYub3JnPG1h aWx0bzp0cmFtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0cmFtXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLXRyYW0tdHVybmJpcy0wMS50eHQNCg0KSGkgVGlydQ0KYXMgdGhlIHR1cm5iaXMgd3Jp dHRlbiwgaW4gaXRzIGN1cnJlbnQgZm9ybSwgaXQgYWxsb3dzIEVWRU4tUE9SVCBhdHRyaWJ1dGUg aW4gdGhlIEFMTE9DQVRFIHJlcXVlc3QgdG9nZXRoZXIgd2l0aCB0aGUgQURESVRJT05BTC1BRERS RVNTLUZBTUlMWSBhdHRyaWJ1dGUuIElmIHRoaXMgaXMgcmVhbGx5IHdoYXQgeW91IHdhbnQsIHRo ZW4gdGhlIFJFU0VSVkFUSU9OLVRPS0VOIGhhbmRsaW5nIG11c3QgYmUgY2hhbmdlZCBpbiB0aGUg QUxMT0NBVEUgcmVzcG9uc2UgLSBiZWNhdXNlIHRoZXJlIHdpbGwgYmUgdHdvIFJFU0VSVkFUSU9O LVRPS0VOIGF0dHJpYnV0ZXMgaW5jbHVkZWQgaW50byB0aGUgcmVzcG9uc2UgKHdoZW4gRVZFTi1Q T1JUPTEpLg0KT3IgdGhlIEVWRU4tUE9SVCBtdXN0IGJlIHByb2hpYml0ZWQgaW4gdGhlIHNhbWUg cmVxdWVzdCB3aXRoIEFERElUSU9OQUwtQUREUkVTUy1GQU1JTFkuDQpBcyBvZiBub3csIHRoZXJl IGlzIGluaGVyZW50IGluY29uc2lzdGVuY3kuDQpbVFJdIEFncmVlZCwgd2lsbCB1cGRhdGUgdGhl IGRyYWZ0IHRoYXQgQUFGIG11c3Qgbm90IGJlIHVzZWQgd2l0aCBldmVuIHBvcnQuDQotVGlydQ0K VGhhbmtzDQpPbGVnDQoNCg0KT24gVGh1LCBKYW4gMjksIDIwMTUgYXQgOTozOSBQTSwgVGlydW1h bGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlA Y2lzY28uY29tPj4gd3JvdGU6DQpNYWpvciBjaGFuZ2VzIGluIHRoaXMgcmV2aXNpb24gYXJlIHN1 cHBvcnQgZm9yIFNTT0RBIGFuZCBtZXJnZWQgUkZDNjE1Ni4gUGxlYXNlIHJldmlldyBhbmQgcHJv dmlkZSB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzLg0KRGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb24g OiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj9kaWZmdHlwZT0tLWh3ZGlmZiZ1cmwyPWRy YWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxLnR4dA0KDQotVGlydQ0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC0NCj4g ZHJhZnRzQGlldGYub3JnPG1haWx0bzpkcmFmdHNAaWV0Zi5vcmc+DQo+IFNlbnQ6IEZyaWRheSwg SmFudWFyeSAzMCwgMjAxNSAxMDo0OCBBTQ0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnPG1h aWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+IENjOiB0cmFtQGlldGYub3JnPG1haWx0bzp0 cmFtQGlldGYub3JnPg0KPiBTdWJqZWN0OiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10 cmFtLXR1cm5iaXMtMDEudHh0DQo+DQo+DQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gIFRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFRVUk4gUmV2aXNlZCBhbmQgTW9kZXJuaXpl ZCBXb3JraW5nDQo+IEdyb3VwIG9mIHRoZSBJRVRGLg0KPg0KPiAgICAgICAgIFRpdGxlICAgICAg ICAgICA6IFRyYXZlcnNhbCBVc2luZyBSZWxheXMgYXJvdW5kIE5BVCAoVFVSTik6IFJlbGF5IEV4 dGVuc2lvbnMNCj4gdG8gU2Vzc2lvbiBUcmF2ZXJzYWwgVXRpbGl0aWVzIGZvciBOQVQgKFNUVU4p DQo+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogVGlydW1hbGVzd2FyIFJlZGR5DQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgQWxhbiBKb2huc3Rvbg0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgIFBoaWxpcCBNYXR0aGV3cw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEpvbmF0 aGFuIFJvc2VuYmVyZw0KPiAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXRyYW0t dHVybmJpcy0wMS50eHQNCj4gICAgICAgUGFnZXMgICAgICAgICAgIDogNzcNCj4gICAgICAgRGF0 ZSAgICAgICAgICAgIDogMjAxNS0wMS0yOQ0KPg0KPiBBYnN0cmFjdDoNCj4gICAgSWYgYSBob3N0 IGlzIGxvY2F0ZWQgYmVoaW5kIGEgTkFULCB0aGVuIGluIGNlcnRhaW4gc2l0dWF0aW9ucyBpdCBj YW4NCj4gICAgYmUgaW1wb3NzaWJsZSBmb3IgdGhhdCBob3N0IHRvIGNvbW11bmljYXRlIGRpcmVj dGx5IHdpdGggb3RoZXIgaG9zdHMNCj4gICAgKHBlZXJzKS4gIEluIHRoZXNlIHNpdHVhdGlvbnMs IGl0IGlzIG5lY2Vzc2FyeSBmb3IgdGhlIGhvc3QgdG8gdXNlDQo+ICAgIHRoZSBzZXJ2aWNlcyBv ZiBhbiBpbnRlcm1lZGlhdGUgbm9kZSB0aGF0IGFjdHMgYXMgYSBjb21tdW5pY2F0aW9uDQo+ICAg IHJlbGF5LiAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBwcm90b2NvbCwgY2FsbGVkIFRV Uk4gKFRyYXZlcnNhbA0KPiAgICBVc2luZyBSZWxheXMgYXJvdW5kIE5BVCksIHRoYXQgYWxsb3dz IHRoZSBob3N0IHRvIGNvbnRyb2wgdGhlDQo+ICAgIG9wZXJhdGlvbiBvZiB0aGUgcmVsYXkgYW5k IHRvIGV4Y2hhbmdlIHBhY2tldHMgd2l0aCBpdHMgcGVlcnMgdXNpbmcNCj4gICAgdGhlIHJlbGF5 LiAgVFVSTiBkaWZmZXJzIGZyb20gc29tZSBvdGhlciByZWxheSBjb250cm9sIHByb3RvY29scyBp bg0KPiAgICB0aGF0IGl0IGFsbG93cyBhIGNsaWVudCB0byBjb21tdW5pY2F0ZSB3aXRoIG11bHRp cGxlIHBlZXJzIHVzaW5nIGENCj4gICAgc2luZ2xlIHJlbGF5IGFkZHJlc3MuDQo+DQo+ICAgIFRo ZSBUVVJOIHByb3RvY29sIHdhcyBkZXNpZ25lZCB0byBiZSB1c2VkIGFzIHBhcnQgb2YgdGhlIElD RQ0KPiAgICAoSW50ZXJhY3RpdmUgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQpIGFwcHJvYWNo IHRvIE5BVCB0cmF2ZXJzYWwsDQo+ICAgIHRob3VnaCBpdCBhbHNvIGNhbiBiZSB1c2VkIHdpdGhv dXQgSUNFLg0KPg0KPg0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhp cyBkcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi10cmFtLXR1cm5iaXMvDQo+DQo+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZh aWxhYmxlIGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0t dHVybmJpcy0wMQ0KPg0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFp bGFibGUgYXQ6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt dHJhbS10dXJuYmlzLTAxDQo+DQo+DQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y ZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KPg0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IHRyYW0gbWFpbGluZyBsaXN0DQo+IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRy YW1AaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJh bQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJh bSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KDQoNCg0K --_000_913383AAA69FF945B8F946018B75898A3553539Fxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklubGluZSBbVFIy XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPbGVnIE1vc2th bGVua28gW21haWx0bzptb20wNDAyNjdAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1v bmRheSwgRmVicnVhcnkgMDIsIDIwMTUgMTI6MzcgQU08YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxl c3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQo8Yj5DYzo8L2I+IHRyYW1AaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRyYW0tdHVy bmJpcy0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g U3VuLCBGZWIgMSwgMjAxNSBhdCA3OjI3IEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkp ICZsdDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj50 aXJlZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9sZWcgTW9z a2FsZW5rbyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb20wNDAyNjdAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+bW9tMDQwMjY3QGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g U3VuZGF5LCBGZWJydWFyeSAwMSwgMjAxNSAxOjM4IFBNPGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFs ZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dHJh bUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMt MDEudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPkkgZm91bmQgYW5vdGhlciB0aGluZy4gSW4gdGhlIHNlY3Rpb24gNy4x LCB0aGUgdHVybmJpcyBkb2N1bWVudCBpcyBzYXlpbmcgdGhhdDo8bzpwPjwvbzpwPjwvcD4NCjxw cmU+JnF1b3Q7VGhlIGNsaWVudCBNVVNUIE5PVCBpbmNsdWRlIGFueSBSRVFVRVNURUQtQUREUkVT Uy1GQU1JTFkgYXR0cmlidXRlIGluIGl0cyBSZWZyZXNoIFJlcXVlc3QuJnF1b3Q7PG86cD48L286 cD48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5CdXQgaW4gdGhlIG5leHQgc2VjdGlv biwgNy4yLCB0aGVyZSBpcyBhIHBhcmFncmFwaCB0aGF0IGRpc2N1c3NlcyB0aGUgc2VydmVyIGJl aGF2aW91ciB3aGVuIGl0IHJlY2VpdmVzIHRoZSBSRVFVRVNURUQtQUREUkVTUy1GQU1JTFkgYXR0 cmlidXRlIGluIHRoZSBSRUZSRVNIIHJlcXVlc3QuIEkgZ3Vlc3MgdGhhdCBwYXJhZ3JhcGgNCiBz bGlwcGVkIGludG8gdHVybmJpcyBmcm9tIFNTT0RBIGRyYWZ0IGFuZCBpZiBoYXMgdG8gYmUgcmVt b3ZlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0gVGhlIHBhcmFncmFwaCB3YXMgcGlj a2VkIGZyb20gUkZDIDYxNTY7IFNlY3Rpb24gNS4xIHNheXMgY2xpZW50IE1VU1Qgbm90IGluY2x1 ZGUgYW55IFJBRiBhdHRyaWJ1dGUNCiBpbiBpdHMgUmVmcmVzaCByZXF1ZXN0IGFuZCBzZWN0aW9u IDUuMiBkaXNjdXNzZXMgdGhlIHNlcnZlciBiZWhhdmlvciB3aGVuIGl0IHJlY2VpdmVzIFJBRiAm bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5h bWU9IjE0YjQ1YzBmYzBkZGMzMmFfc2VjdGlvbi01LjIiPjwvYT48YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM2MTU2I3NlY3Rpb24tNS4yIiB0YXJnZXQ9Il9ibGFuayI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPjUuMjwvc3Bhbj48L2I+PC9hPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4uJm5ic3A7DQogUmVjZWl2 aW5nIGEgUmVmcmVzaCBSZXF1ZXN0PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBJZiBhIHNlcnZlciByZWNlaXZl cyBhIFJlZnJlc2ggUmVxdWVzdCB3aXRoIGEgUkVRVUVTVEVELUFERFJFU1MtPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 IEZBTUlMWSBhdHRyaWJ1dGUsIGFuZCB0aGUgYXR0cmlidXRlJ3MgdmFsdWUgZG9lc24ndCBtYXRj aCB0aGUgYWRkcmVzczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBmYW1pbHkgb2YgdGhlIGFsbG9jYXRpb24sIHRoZSBz ZXJ2ZXIgTVVTVCByZXBseSB3aXRoIGEgNDQzIChQZWVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEFkZHJlc3MgRmFt aWx5IE1pc21hdGNoKSBSZWZyZXNoIGVycm9yIHJlc3BvbnNlLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPlRpcnUsIEkgZ290IHRoYXQuIEJ1dCBjb3VsZCB5b3UgcGxl YXNlIGV4cGxhaW4gd2h5IGl0IGlzIHdyaXR0ZW4gdGhhdCB3YXkgPw0KPHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPltUUjJdIEkgZG9u4oCZdCBrbm93IHdoeSBpdCBpcyB3cml0dGVuIGxp a2UgdGhhdCA/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5TaW1vbi9Hb256YWxvIC0gJm5ic3A7Q2FuIHlvdSBwbGVhc2UgY2xhcmlm eSB0aGUgcmVhc29uaW5nIGZvciBTZWN0aW9uIDUuMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QXMgaXQgaXMg bm93LCBJIHNlZSB0d28gcG9pbnRzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+MSkgVGhlIGxlZ2FjeSBSRkMgNjE1Ni1jb21wbGlhbnQgY2xpZW50 cyBhcmUgbm90IHR1cm5iaXMtY29tcGxpYW50IC0gYmVjYXVzZSB0aGV5IGluY2x1ZGUgUkFGIGlu dG8gUkVGUkVTSDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+MikgVGhlIGxlZ2FjeSBSRkMgNjE1 Ni1jb21wbGlhbnQgY2xpZW50cyBhcmUgY29tcGF0aWJsZSB3aXRoIHRoZSBuZXcgdHVybmJpcy1z ZXJ2ZXJzIC0gYmVjYXVzZSB0aGUgdHVybmJpcy1zZXJ2ZXJzIGtub3cgaG93IHRvIGhhbmRsZSBS QUYgaW4gUkVGUkVTSC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldhcyB0aGF0IHdoYXQgeW91IHdlcmUgdHJ5aW5nIHRvIGFjaGlldmUgPzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5b VFIyIFBvaW50IDIgKFdlIGNhbm5vdCBwcm9jZWVkIHdpdGggcG9pbnQgMSBiZWNhdXNlIGl0IHdp bGwgYnJlYWsgYmFja3dhcmQgY29tcGF0aWJpbGl0eSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu a3M8YnI+DQpPbGVnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU2F0LCBKYW4gMzEs IDIwMTUgYXQgMTE6MDcgUE0sIE9sZWcgTW9za2FsZW5rbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1v bTA0MDI2N0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb20wNDAyNjdAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPlRpcnUsIEkgZG8gbm90IHNlZSBhbnkgcHJvYmxlbSB3aXRoIEVWRU4tUE9SVCB3 aGVuIGl0cyB2YWx1ZSBpcyAwLiBUaGUgcHJvYmxlbSBvbmx5IGFyaXNlcyB3aGVuIEVWRU4tUE9S VCBpcyBlcXVhbHMgMHg4MCAocmVzZXJ2ZWQgYWxsb2NhdGlvbiByZXF1aXJlZCkuIFNvIEknZCBz dWdnZXN0IGZvciBmb3JiaWQgb25seQ0KIHRoZSBzaXR1YXRpb24gd2hlbiB0aGUgaGlnaGVzdCBi aXQgb2YgRVZFTi1QT1JUIGlzIDEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGhhbmtzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPk9sZWc8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBTYXQsIEphbiAzMSwgMjAxNSBhdCA2OjM2IFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVk ZHkpICZsdDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5r Ij50aXJlZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9sZWcg TW9za2FsZW5rbyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb20wNDAyNjdAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bW9tMDQwMjY3QGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gU3VuZGF5LCBGZWJydWFyeSAwMSwgMjAxNSA0OjQwIEFNPGJyPg0KPGI+VG86PC9iPiBUaXJ1 bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86 dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFtLXR1cm5i aXMtMDEudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPkhpIFRpcnU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij5hcyB0aGUgdHVybmJpcyB3cml0dGVuLCBpbiBpdHMgY3VycmVudCBmb3JtLCBp dCBhbGxvd3MgRVZFTi1QT1JUIGF0dHJpYnV0ZSBpbiB0aGUgQUxMT0NBVEUgcmVxdWVzdCB0b2dl dGhlciB3aXRoIHRoZSBBRERJVElPTkFMLUFERFJFU1MtRkFNSUxZIGF0dHJpYnV0ZS4gSWYgdGhp cyBpcyByZWFsbHkgd2hhdCB5b3Ugd2FudCwNCiB0aGVuIHRoZSBSRVNFUlZBVElPTi1UT0tFTiBo YW5kbGluZyBtdXN0IGJlIGNoYW5nZWQgaW4gdGhlIEFMTE9DQVRFIHJlc3BvbnNlIC0gYmVjYXVz ZSB0aGVyZSB3aWxsIGJlIHR3byBSRVNFUlZBVElPTi1UT0tFTiBhdHRyaWJ1dGVzIGluY2x1ZGVk IGludG8gdGhlIHJlc3BvbnNlICh3aGVuIEVWRU4tUE9SVD0xKS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+T3IgdGhlIEVWRU4tUE9SVCBtdXN0IGJlIHBy b2hpYml0ZWQgaW4gdGhlIHNhbWUgcmVxdWVzdCB3aXRoIEFERElUSU9OQUwtQUREUkVTUy1GQU1J TFkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkFzIG9m IG5vdywgdGhlcmUgaXMgaW5oZXJlbnQgaW5jb25zaXN0ZW5jeS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PltUUl0gQWdyZWVkLCB3aWxsIHVwZGF0ZSB0aGUgZHJhZnQgdGhhdCBBQUYgbXVzdCBub3QgYmUg dXNlZCB3aXRoIGV2ZW4gcG9ydC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4tVGlydTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhhbmtz PGJyPg0KT2xlZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBKYW4gMjksIDIwMTUgYXQgOToz OSBQTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRp cmVkZHlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TWFqb3IgY2hh bmdlcyBpbiB0aGlzIHJldmlzaW9uIGFyZSBzdXBwb3J0IGZvciBTU09EQSBhbmQgbWVyZ2VkIFJG QzYxNTYuIFBsZWFzZSByZXZpZXcgYW5kIHByb3ZpZGUgeW91ciB2YWx1YWJsZSBjb21tZW50cy48 YnI+DQpEaWZmIGZyb20gcHJldmlvdXMgdmVyc2lvbiA6IDxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9yZmNkaWZmP2RpZmZ0eXBlPS0taHdkaWZmJmFtcDt1cmwyPWRyYWZ0LWlldGYtdHJh bS10dXJuYmlzLTAxLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmlldGYub3Jn L3JmY2RpZmY/ZGlmZnR5cGU9LS1od2RpZmYmYW1wO3VybDI9ZHJhZnQtaWV0Zi10cmFtLXR1cm5i aXMtMDEudHh0PC9hPjxicj4NCjxicj4NCi1UaXJ1PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCiZndDsgRnJvbTogdHJhbSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0cmFt LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtPGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86ZHJh ZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnRzQGlldGYub3JnPC9hPjxicj4NCiZn dDsgU2VudDogRnJpZGF5LCBKYW51YXJ5IDMwLCAyMDE1IDEwOjQ4IEFNPGJyPg0KJmd0OyBUbzog PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmkt ZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86dHJh bUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBT dWJqZWN0OiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDEudHh0 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2 YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+ DQomZ3Q7Jm5ic3A7IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFRVUk4gUmV2aXNl ZCBhbmQgTW9kZXJuaXplZCBXb3JraW5nPGJyPg0KJmd0OyBHcm91cCBvZiB0aGUgSUVURi48YnI+ DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaXRsZSZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBUcmF2ZXJzYWwgVXNpbmcg UmVsYXlzIGFyb3VuZCBOQVQgKFRVUk4pOiBSZWxheSBFeHRlbnNpb25zPGJyPg0KJmd0OyB0byBT ZXNzaW9uIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTik8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0F1dGhvcnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7OiBUaXJ1bWFsZXN3YXIgUmVkZHk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FsYW4gSm9obnN0b248YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BoaWxpcCBNYXR0aGV3czxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Sm9uYXRoYW4gUm9zZW5iZXJn PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ZpbGVuYW1lJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDEudHh0PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BhZ2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs6IDc3PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0RhdGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIwMTUtMDEt Mjk8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBJ ZiBhIGhvc3QgaXMgbG9jYXRlZCBiZWhpbmQgYSBOQVQsIHRoZW4gaW4gY2VydGFpbiBzaXR1YXRp b25zIGl0IGNhbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGJlIGltcG9zc2libGUgZm9yIHRoYXQg aG9zdCB0byBjb21tdW5pY2F0ZSBkaXJlY3RseSB3aXRoIG90aGVyIGhvc3RzPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgKHBlZXJzKS4mbmJzcDsgSW4gdGhlc2Ugc2l0dWF0aW9ucywgaXQgaXMgbmVj ZXNzYXJ5IGZvciB0aGUgaG9zdCB0byB1c2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB0aGUgc2Vy dmljZXMgb2YgYW4gaW50ZXJtZWRpYXRlIG5vZGUgdGhhdCBhY3RzIGFzIGEgY29tbXVuaWNhdGlv bjxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHJlbGF5LiZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24g ZGVmaW5lcyBhIHByb3RvY29sLCBjYWxsZWQgVFVSTiAoVHJhdmVyc2FsPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgVXNpbmcgUmVsYXlzIGFyb3VuZCBOQVQpLCB0aGF0IGFsbG93cyB0aGUgaG9zdCB0 byBjb250cm9sIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG9wZXJhdGlvbiBvZiB0aGUgcmVs YXkgYW5kIHRvIGV4Y2hhbmdlIHBhY2tldHMgd2l0aCBpdHMgcGVlcnMgdXNpbmc8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyB0aGUgcmVsYXkuJm5ic3A7IFRVUk4gZGlmZmVycyBmcm9tIHNvbWUgb3Ro ZXIgcmVsYXkgY29udHJvbCBwcm90b2NvbHMgaW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB0aGF0 IGl0IGFsbG93cyBhIGNsaWVudCB0byBjb21tdW5pY2F0ZSB3aXRoIG11bHRpcGxlIHBlZXJzIHVz aW5nIGE8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBzaW5nbGUgcmVsYXkgYWRkcmVzcy48YnI+DQom Z3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgVGhlIFRVUk4gcHJvdG9jb2wgd2FzIGRlc2lnbmVk IHRvIGJlIHVzZWQgYXMgcGFydCBvZiB0aGUgSUNFPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgKElu dGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2htZW50KSBhcHByb2FjaCB0byBOQVQgdHJh dmVyc2FsLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHRob3VnaCBpdCBhbHNvIGNhbiBiZSB1c2Vk IHdpdGhvdXQgSUNFLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlz LyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi10cmFtLXR1cm5iaXMvPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZXJlJ3MgYWxz byBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsgPGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDEiIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10 dXJuYmlzLTAxPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91 cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxIiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRy YW0tdHVybmJpcy0wMTwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbjxicj4NCiZndDsgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KJmd0 OyA8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgdGFyZ2V0PSJf YmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCiZndDs8 YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KJmd0OyB0cmFtIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnRy YW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtQGlldGYub3JnPC9hPjxicj4NCiZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9h Pjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A3553539Fxmbrcdx10ciscoc_-- From nobody Sun Feb 1 20:19:44 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF631A914A for ; Sun, 1 Feb 2015 20:19:44 -0800 (PST) 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 zk_Qlq10Walv for ; Sun, 1 Feb 2015 20:19:43 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF6CF1A9145 for ; Sun, 1 Feb 2015 20:19:42 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id fb4so13874318wid.2 for ; Sun, 01 Feb 2015 20:19:41 -0800 (PST) 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=e7o+RORMiVaB6nLxnny+7FPYkoizOWCv+bkPR3rwaHM=; b=LNpmwdsYcGNpjYkBsNd2Ux8kTFeNHJ1sinmFIAl/x+Xw0VL5OFhQXg58W9ajGuPXFa ul0rpQuCWT5fG/cSGtkKyg2SQBl0MDFi9iZeofT9DyoAvAAQIumFsEXToFJPkI4H1KrL aYmS/KGXjottDII2uM2bCYVakCj7WmQiALItLx2GuqiuEvD6vCCtSR54SABVwrtdaon2 t+/1fs2ywyZtdA1/+AfgLObMgzMAGAI910YJ8hIv/RAK85auy2a1LgkzMiBhPs4QksA4 O8/JIW44lhlj/pK/j0s9ELnvXrA+4ha3RAofsWv+QGgIeb78WZyaVNYjXg0P6VFK2NG8 oQ4w== MIME-Version: 1.0 X-Received: by 10.194.60.19 with SMTP id d19mr37895540wjr.48.1422850781564; Sun, 01 Feb 2015 20:19:41 -0800 (PST) Received: by 10.194.87.98 with HTTP; Sun, 1 Feb 2015 20:19:41 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A3553539F@xmb-rcd-x10.cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553506F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553522B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553539F@xmb-rcd-x10.cisco.com> Date: Sun, 1 Feb 2015 20:19:41 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b86c8986755f5050e134369 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 02 Feb 2015 04:19:44 -0000 --047d7b86c8986755f5050e134369 Content-Type: text/plain; charset=UTF-8 As it is now, I see two points: > > 1) The legacy RFC 6156-compliant clients are not turnbis-compliant - > because they include RAF into REFRESH; > > 2) The legacy RFC 6156-compliant clients are compatible with the new > turnbis-servers - because the turnbis-servers know how to handle RAF in > REFRESH. > > Was that what you were trying to achieve ? > > > > [TR2 Point 2 (We cannot proceed with point 1 because it will break > backward compatibility) > > > > I understand that. But I do not understand why the section 7.1 says that the clients MUST not include RAF into REFRESH; but the section 7.2 describes what server has to do if it does receive RAF in the REFRESH request. What was the reasoning for that ? The same wording can be found in RFC 6156. So, the section 7.1 contradicts the section 7.2. I still cannot understand why the current wording is chosen. Thanks Oleg --047d7b86c8986755f5050e134369 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


As it is now, I see two= points:

1) The legacy RFC 6156-compliant clients are not tur= nbis-compliant - because they include RAF into REFRESH;

2) The legacy RFC 6156-= compliant clients are compatible with the new turnbis-servers - because the= turnbis-servers know how to handle RAF in REFRESH.

Was that what you were trying to achieve ?=

=C2=A0=

[TR2 Point 2 = (We cannot proceed with point 1 because it will break backward compatibilit= y)

=C2=A0=




I understand that. But I do not understand why the section 7= .1 says that the clients MUST not include RAF into REFRESH; but the section= 7.2 describes what server has to do if it does receive RAF in the REFRESH = request. What was the reasoning for that ? The same wording can be found in= RFC 6156.

So, the section 7.1 contradicts the section 7.2. I= still cannot understand why the current wording is chosen.

Th= anks
Oleg



--047d7b86c8986755f5050e134369-- From nobody Sun Feb 1 21:14:43 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2E71A9169 for ; Sun, 1 Feb 2015 21:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtG_ZmRti-nz for ; Sun, 1 Feb 2015 21:14:40 -0800 (PST) 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 F11F31A9167 for ; Sun, 1 Feb 2015 21:14:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10474; q=dns/txt; s=iport; t=1422854080; x=1424063680; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kY8aAR8NTylPfVhkyedHhJUq2I9By31lus8vzAEbcas=; b=BUSHNd7vC9u3Im2vzdWkOh3OnkOePvDWG4URUr2Hssg/pru9yKIYNOKr 4/TqBxr52+OH5uUo7/R/vo4buc/X5y0RmZsPJuKypQzl+OOUYMag5YE5H J1VsveTWfiU3PmeUznmgseqKNTGqjdE4+vncz6nQWNHUVjM5+i1ZE4RmI c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B5BQCVB89U/5BdJa1bgkNDUlkEgn2/QIgWAhx6QwEBAQEBfYQMAQEBBCMKTBACAQgOAwQBAQsdAwICAh8RFAkIAgQOBQiIEQMRvT2PWw2FUAEBAQEBAQEBAQEBAQEBAQEBAQEBAReNToF5MQYBgmgugRMFjwmHX44lhX0ig25vgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,504,1418083200"; d="scan'208,217";a="119599923" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP; 02 Feb 2015 05:14:38 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t125EccD009426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Feb 2015 05:14:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Sun, 1 Feb 2015 23:14:38 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt Thread-Index: AQHQPEw30UXpKS+dFk6Udma1HT7B3pzYIAdggAMiCYD//9HbMIAAs3oAgAAQ34CAABT24IAAo2WAgAAbqJCAAH6jgP//qJXg Date: Mon, 2 Feb 2015 05:14:38 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35535415@xmb-rcd-x10.cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553506F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553522B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553539F@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.12] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35535415xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 02 Feb 2015 05:14:42 -0000 --_000_913383AAA69FF945B8F946018B75898A35535415xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUjNdDQoNCkZyb206IE9sZWcgTW9za2FsZW5rbyBbbWFpbHRvOm1vbTA0MDI2N0Bn bWFpbC5jb21dDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDAyLCAyMDE1IDk6NTAgQU0NClRvOiBU aXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpDYzogdHJhbUBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFt0cmFtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMS50eHQNCg0K DQoNCkFzIGl0IGlzIG5vdywgSSBzZWUgdHdvIHBvaW50czoNCjEpIFRoZSBsZWdhY3kgUkZDIDYx NTYtY29tcGxpYW50IGNsaWVudHMgYXJlIG5vdCB0dXJuYmlzLWNvbXBsaWFudCAtIGJlY2F1c2Ug dGhleSBpbmNsdWRlIFJBRiBpbnRvIFJFRlJFU0g7DQoyKSBUaGUgbGVnYWN5IFJGQyA2MTU2LWNv bXBsaWFudCBjbGllbnRzIGFyZSBjb21wYXRpYmxlIHdpdGggdGhlIG5ldyB0dXJuYmlzLXNlcnZl cnMgLSBiZWNhdXNlIHRoZSB0dXJuYmlzLXNlcnZlcnMga25vdyBob3cgdG8gaGFuZGxlIFJBRiBp biBSRUZSRVNILg0KV2FzIHRoYXQgd2hhdCB5b3Ugd2VyZSB0cnlpbmcgdG8gYWNoaWV2ZSA/DQoN CltUUjIgUG9pbnQgMiAoV2UgY2Fubm90IHByb2NlZWQgd2l0aCBwb2ludCAxIGJlY2F1c2UgaXQg d2lsbCBicmVhayBiYWNrd2FyZCBjb21wYXRpYmlsaXR5KQ0KDQoNCg0KSSB1bmRlcnN0YW5kIHRo YXQuIEJ1dCBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoeSB0aGUgc2VjdGlvbiA3LjEgc2F5cyB0aGF0 IHRoZSBjbGllbnRzIE1VU1Qgbm90IGluY2x1ZGUgUkFGIGludG8gUkVGUkVTSDsgYnV0IHRoZSBz ZWN0aW9uIDcuMiBkZXNjcmliZXMgd2hhdCBzZXJ2ZXIgaGFzIHRvIGRvIGlmIGl0IGRvZXMgcmVj ZWl2ZSBSQUYgaW4gdGhlIFJFRlJFU0ggcmVxdWVzdC4gV2hhdCB3YXMgdGhlIHJlYXNvbmluZyBm b3IgdGhhdCA/IFRoZSBzYW1lIHdvcmRpbmcgY2FuIGJlIGZvdW5kIGluIFJGQyA2MTU2Lg0KU28s IHRoZSBzZWN0aW9uIDcuMSBjb250cmFkaWN0cyB0aGUgc2VjdGlvbiA3LjIuIEkgc3RpbGwgY2Fu bm90IHVuZGVyc3RhbmQgd2h5IHRoZSBjdXJyZW50IHdvcmRpbmcgaXMgY2hvc2VuLg0KW1RSM10g WWVzLCBJIGFncmVlIHRoYXQgdGhlIGNvbnRyYWRpY3RvcnkgdGV4dCBpbiBzZWN0aW9uIDcuMiBz aG91bGQgYmUgcmVtb3ZlZC4gQnV0IGxldOKAmXMgaGVhciBmcm9tIHRoZSBhdXRob3JzIG9mIFJG QyA2MTU2LCB0aGV5IG1pZ2h0IGhhZCBzb21lIHZhbGlkIHJlYXNvbiBmb3IgdGhpcyBiZWhhdmlv ci4NCi1UaXJ1DQpUaGFua3MNCk9sZWcNCg0KDQo= --_000_913383AAA69FF945B8F946018B75898A35535415xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW5saW5lIFtUUjNdPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9sZWcgTW9za2FsZW5r byBbbWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBGZWJydWFyeSAwMiwgMjAxNSA5OjUwIEFNPGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFsZXN3YXIg UmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6PC9iPiB0cmFtQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMt MDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2lu ZG93dGV4dCAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O2JvcmRlci1jb2xvcjotbW96 LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvciBi bHVlIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkFzIGl0 IGlzIG5vdywgSSBzZWUgdHdvIHBvaW50czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MSkgVGhlIGxlZ2FjeSBSRkMgNjE1Ni1jb21wbGlhbnQg Y2xpZW50cyBhcmUgbm90IHR1cm5iaXMtY29tcGxpYW50IC0gYmVjYXVzZSB0aGV5IGluY2x1ZGUg UkFGIGludG8gUkVGUkVTSDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+MikgVGhlIGxlZ2FjeSBSRkMgNjE1Ni1jb21wbGlhbnQgY2xpZW50cyBhcmUgY29t cGF0aWJsZSB3aXRoIHRoZSBuZXcgdHVybmJpcy1zZXJ2ZXJzIC0gYmVjYXVzZSB0aGUgdHVybmJp cy1zZXJ2ZXJzIGtub3cgaG93IHRvIGhhbmRsZSBSQUYgaW4gUkVGUkVTSC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2FzIHRoYXQgd2hhdCB5 b3Ugd2VyZSB0cnlpbmcgdG8gYWNoaWV2ZSA/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFIyIFBvaW50IDIgKFdlIGNhbm5v dCBwcm9jZWVkIHdpdGggcG9pbnQgMSBiZWNhdXNlIGl0IHdpbGwgYnJlYWsgYmFja3dhcmQgY29t cGF0aWJpbGl0eSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgdW5kZXJzdGFuZCB0 aGF0LiBCdXQgSSBkbyBub3QgdW5kZXJzdGFuZCB3aHkgdGhlIHNlY3Rpb24gNy4xIHNheXMgdGhh dCB0aGUgY2xpZW50cyBNVVNUIG5vdCBpbmNsdWRlIFJBRiBpbnRvIFJFRlJFU0g7IGJ1dCB0aGUg c2VjdGlvbiA3LjIgZGVzY3JpYmVzIHdoYXQgc2VydmVyIGhhcyB0byBkbyBpZiBpdCBkb2VzIHJl Y2VpdmUgUkFGIGluIHRoZSBSRUZSRVNIDQogcmVxdWVzdC4gV2hhdCB3YXMgdGhlIHJlYXNvbmlu ZyBmb3IgdGhhdCA/IFRoZSBzYW1lIHdvcmRpbmcgY2FuIGJlIGZvdW5kIGluIFJGQyA2MTU2Lg0K PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+U28sIHRoZSBzZWN0aW9uIDcuMSBjb250cmFkaWN0cyB0aGUgc2Vj dGlvbiA3LjIuIEkgc3RpbGwgY2Fubm90IHVuZGVyc3RhbmQgd2h5IHRoZSBjdXJyZW50IHdvcmRp bmcgaXMgY2hvc2VuLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+W1RSM10gWWVzLCBJIGFncmVlIHRoYXQgdGhlIGNvbnRyYWRpY3RvcnkgdGV4dCBp biBzZWN0aW9uIDcuMiBzaG91bGQgYmUgcmVtb3ZlZC4gQnV0IGxldOKAmXMgaGVhciBmcm9tIHRo ZSBhdXRob3JzIG9mIFJGQyA2MTU2LCB0aGV5DQogbWlnaHQgaGFkIHNvbWUgdmFsaWQgcmVhc29u IGZvciB0aGlzIGJlaGF2aW9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoYW5r czxicj4NCk9sZWc8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A35535415xmbrcdx10ciscoc_-- From nobody Mon Feb 2 08:28:25 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB96B1A870E for ; Mon, 2 Feb 2015 08:28:23 -0800 (PST) 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 JNCkgeNp-naF for ; Mon, 2 Feb 2015 08:28:22 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7341A7009 for ; Mon, 2 Feb 2015 08:28:22 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id a1so39647901wgh.12 for ; Mon, 02 Feb 2015 08:28:20 -0800 (PST) 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=cejfEEUa5LKShtDBtPHgv7fVA/SNOtOYP49WzLHdbIA=; b=TPRVCXP62fsJdj7gStexhUIp5vDd4fvI2GIctGaHGzKYquRdMlBDFzQ2Emc9E0DDht Oa5rBb2H7+P35KfSKuN1u8pSS9c3HrSJvtrpnkvcAFFfNVnQZHMcIB1lD35psDDW6NcU FB65x/U+tPgtifmbMBdC2en7MxoFFctefrqqC989akhLJamdS+g845zAarSf3/vtIvys 96HN0eSbXAUc1Mk9jqmSoBn0A94j+THne7Ymc5pmPzZT5h2S9PmsRWwMYfCUgiVFgOdL eHlj60/RsroY/Kq42jPIovd2bm2Fkj5J3uBFSO+3dGILOoKpf+O5J8xHQnyscJZbqPQY rpWg== MIME-Version: 1.0 X-Received: by 10.194.60.19 with SMTP id d19mr43821798wjr.48.1422894500762; Mon, 02 Feb 2015 08:28:20 -0800 (PST) Received: by 10.194.87.98 with HTTP; Mon, 2 Feb 2015 08:28:20 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A35535415@xmb-rcd-x10.cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553506F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553522B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553539F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35535415@xmb-rcd-x10.cisco.com> Date: Mon, 2 Feb 2015 08:28:20 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b86c898456196050e1d71cd Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 02 Feb 2015 16:28:24 -0000 --047d7b86c898456196050e1d71cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The process of proof-reading the draft involved actual implementation: https://code.google.com/p/coturn/wiki/Downloads For experimental implementation, I used new attribute types 0x8032 and 0x8033 (for ADDITIONAL-ADDRESS-FAMILY and ADDRESS-ERROR-CODE). That will be changed when IANA assigns actual numbers Oleg On Sun, Feb 1, 2015 at 9:14 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Inline [TR3] > > > > *From:* Oleg Moskalenko [mailto:mom040267@gmail.com] > *Sent:* Monday, February 02, 2015 9:50 AM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt > > > > > > > > As it is now, I see two points: > > 1) The legacy RFC 6156-compliant clients are not turnbis-compliant - > because they include RAF into REFRESH; > > 2) The legacy RFC 6156-compliant clients are compatible with the new > turnbis-servers - because the turnbis-servers know how to handle RAF in > REFRESH. > > Was that what you were trying to achieve ? > > > > [TR2 Point 2 (We cannot proceed with point 1 because it will break > backward compatibility) > > > > > > > > I understand that. But I do not understand why the section 7.1 says that > the clients MUST not include RAF into REFRESH; but the section 7.2 > describes what server has to do if it does receive RAF in the REFRESH > request. What was the reasoning for that ? The same wording can be found = in > RFC 6156. > > So, the section 7.1 contradicts the section 7.2. I still cannot understan= d > why the current wording is chosen. > > [TR3] Yes, I agree that the contradictory text in section 7.2 should be > removed. But let=E2=80=99s hear from the authors of RFC 6156, they might = had some > valid reason for this behavior. > > -Tiru > > Thanks > Oleg > > > > > --047d7b86c898456196050e1d71cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The process of proof-reading the draft involved actua= l implementation:

https://code.google.com/p/coturn/wiki/Downloads

=
For experimental implementation, I used new attribute types 0x8032 and= 0x8033 (for ADDITIONAL-ADDRESS-FAMILY and ADDRESS-ERROR-CODE). That will b= e changed when IANA assigns actual numbers

Oleg


On Sun,= Feb 1, 2015 at 9:14 PM, Tirumaleswar Reddy (tireddy) <= ;tireddy@cisco.com> wrote:

Inline [TR3]

=C2=A0

From: Oleg Mos= kalenko [mailto:mo= m040267@gmail.com]
Sent: Monday, February 02, 2015 9:50 AM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org=
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

=C2=A0

=C2=A0

=C2=A0

As it is now, I see t= wo points:

1) The legacy RFC 6156-compliant clients are not tur= nbis-compliant - because they include RAF into REFRESH;

2) The legacy RFC 615= 6-compliant clients are compatible with the new turnbis-servers - because t= he turnbis-servers know how to handle RAF in REFRESH.

Was that what you were trying to achieve ?=

=C2=A0

[TR2 Point 2 (We cannot p= roceed with point 1 because it will break backward compatibility)=

=C2=A0

=C2=A0

=C2=A0<= /p>

I understand that. Bu= t I do not understand why the section 7.1 says that the clients MUST not in= clude RAF into REFRESH; but the section 7.2 describes what server has to do= if it does receive RAF in the REFRESH request. What was the reasoning for that ? The same wording can be found i= n RFC 6156.

So, the section 7.1 c= ontradicts the section 7.2. I still cannot understand why the current wordi= ng is chosen.

[TR3] Yes, I agree that the contradictory text in section= 7.2 should be removed. But let=E2=80=99s hear from the authors of RFC 6156= , they might had some valid reason for this behavior.

-Tiru

Thanks
Oleg

=C2=A0

=C2=A0


--047d7b86c898456196050e1d71cd-- From nobody Mon Feb 2 10:08:00 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580841A8836; Mon, 2 Feb 2015 10:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAKfyU4dFgyc; Mon, 2 Feb 2015 10:07:33 -0800 (PST) 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 BCB8E1A883A; Mon, 2 Feb 2015 10:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8188; q=dns/txt; s=iport; t=1422900439; x=1424110039; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=QtBbdREcyIGZXu2l/JRuJ7E5BdVGdQxyW62C5l2xFok=; b=Wr4VNt5/DaWuSZMSj22D6wswi2F3OQ1u1dJytE3aaQ533PEW1mCjBqnp zXygvhTND6wx6Hk8Z7AAy8ipcmcE3ZD6FWeEYJ9VngIPbxaw3sSJNk62f ZU/sWsXh5TdD1qAPyiVHG1rDMVeoUiZCcYf9XJV4WyZ+rE8lniNIiGvc8 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CPBQCYvM9U/40NJK1bgwZSWQTCP4IlhXECgRxDAQEBAQF9hAwBAQEDAScTPwUHBgEIEQQBAQsOBgkoERQJCQEEAQ0FCIgRAwkIDdBhDYU2AQEBAQEBAQEBAQEBAQEBAQEBAQEBF41OgXkxDRKCfoETBY0mgWODToQRgl02gk2IRYV9IoIBARyBUG8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,507,1418083200"; d="scan'208";a="119795734" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP; 02 Feb 2015 18:07:18 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t12I7I0i022162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Feb 2015 18:07:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 12:07:18 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Yaron Sheffer , IETF Security Directorate , The IESG , "draft-ietf-tram-turn-third-party-authz.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-tram-turn-third-party-authz-07 Thread-Index: AdA/ExG1WBn6u6R0RKmUj5mvhiVERQ== Date: Mon, 2 Feb 2015 18:07:18 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35535978@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.32.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] SecDir review of draft-ietf-tram-turn-third-party-authz-07 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, 02 Feb 2015 18:07:37 -0000 Hi Yaron, Thanks for the detailed review. Please see inline > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Sunday, February 01, 2015 11:26 PM > To: IETF Security Directorate; The IESG; draft-ietf-tram-turn-third-party= - > authz.all@tools.ietf.org > Subject: SecDir review of draft-ietf-tram-turn-third-party-authz-07 >=20 > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security are= a > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. >=20 > This document defines a mechanism where a STUN client can present an > OAUTH token and get authorized to use a particular STUN server. >=20 > Summary >=20 > IMHO, the document is not yet ready to be published. >=20 > Details >=20 > * What is the motivation for this authorization? Is it intended to conser= ve > server resources? Yes, to ensure that only authorized clients can use the STUN server. For ex= ample allow the client to use the TURN server only when making a call using= the WebRTC server. >=20 > * What is HMAC-SHA-256-128? Is the output 128 or 256 bits long?=20 The output is truncated to 128 bit. > Please > include a reference. Added reference to RFC 4868. >=20 > * Maybe I'm confused, but it seems to me that the discussion immediately > following Fig. 2 mixes the hash algorithm that signs the token itself wit= h the > algorithm that integrity-protects STUN messages. If they must be the same > for some reason, please state it clearly. No, they do not need to be same. RFC 5389 mandates HMAC-SHA1 for integrity = protection of STUN message and in future the WG plans to remove this limita= tion, hence we added this paragraph after Fig.2. >=20 > * 4.1: there are obvious benefits to using an asymmetric key here, and in= fact > this can be done efficiently using elliptic curves (ECDSA). So I think th= e "MUST > establish a symmetric key" is misguided. Agreed.=20 NEW: Elliptic curve cryptography (ECC) or symmetric-key algorithm MUST be chosen= to ensure that the size of encrypted token is not large because usage of R= SA will result in large encrypted tokens which may not fit into a single ST= UN message. >=20 > * 4.1.1: the derivation of both keys seems to be the same, so are they > identical?! The derivation of the keys is required if the encryption and HMAC algorithm= require keys of different length. NEW: For example if the input symmetric key (K) is 32 octets length, encryption algorithm is AES_256_CBC and HMAC algorithm is HMAC-SHA1 [RFC2104] then the secondary keys AS-RS, AUTH are generated from the input key K as follows 1. HKDF-Extract(zero, K) -> PRK 2. HKDF-Expand(PRK, zero, 16) -> AUTH key=20 3. HKDF-Expand(PRK, zero, 32) -> AS-RS key >=20 > * 4.1.2: this interaction (a simple REST query to get a long-term key) is= by > default insecure, so I'm surprised to see it here with no comments about = the > need to encrypt it an authenticate the client. Good point, updated draft. NEW: The two servers could choose to use REST API over HTTPS to establish a symm= etric key. HTTPS MUST be used for mutual authentication and confidentiality= . >=20 > * 4.1.3: please provide a reference for AES_256_CBC_HMAC_SHA_512. Added reference. >=20 > * 6.1, last sentence: so an attacker who can disrupt communication to the= AS > can force the client to switch to 1st party authentication, which is easi= ly > susceptible to dictionary attacks ? The possible way to mitigate the attack is use (D)TLS for communication b/w= the client and server.=20 NEW text (added to Security considerations): An attacker may remove the THIRD-PARTY-AUTHORIZATION STUN attribute from the error message forcing the client to pick first party authentication, this attack may be mitigated by opting for Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC6347] as a transport protocol for Session Traversal Utilities for NAT (STUN), as defined in [RFC5389]and [RFC7350]. >=20 > * 6.2: the timestamp value is strange, specifically the fractional part. > Why are fractions needed, do we think this improves security? We used the description from http://tools.ietf.org/html/rfc3971#section-5.3= .1 =20 Do you see a problem ? >=20 > * 6.2 example: when using AES-256-CBC something must be said about > padding and about the IV. Yes, updated encrypted_block to include padding, padding_length; struct { opaque { uint16_t key_length; opaque mac_key[key_length]; uint64_t timestamp; uint32_t lifetime; uint8_t padding_length; uint8_t padding[padding_length]; } encrypted_block; opaque mac[mac_length]; uint8_t mac_length; } token; padding_length: The padding length MUST be such that the total size of the encrypted_block structure is a multiple of the cipher's block length. padding: Padding that is added to force the length of the plaintext to be an integral multiple of the block cipher's block length. And the below text to address the comment on IV o C =3D AES_256_CBC(AS-RS, encrypted_block) * Initialization vector can be set to zero because the encrypted_block in each access token will not be identical and hence will not result in generation of identical ciphertext. >=20 > * 6.2, last sentence: the length of the nonce surely depends on the selec= ted > algorithm, and cannot be a constant 12. Yes, removed the last sentence and added the following line: The length of nonce for AEAD algorithms is explained in [RFC5116]. >=20 > * 8: Is the MESAGE INTEGRITY attribute itself mandatory ?=20 Yes. > The client should > reject messages if this attribute is not included. Added following text for clarity: o The client looks for the MESSAGE-INTEGRITY attribute in the response. If MESSAGE-INTEGRITY is absent or the value computed for message integrity using mac_key does not match the contents of the MESSAGE-INTEGRITY attribute then the response MUST be discarded. >=20 > * 9: if the server is allowed to cache access tokens, there must be a way= for > the client to refer to a token by name. Otherwise there may be confusion > when tokens are expired and replaced by new ones, especially in the > presence of dropped messages. That line is only for server implementation optimization.=20 NEW: Since the access token is only valid for a specific period of time, the TUR= N server can cache it so that it can check if the access token in a new all= ocation request matches one of the cached tokens and avoids the need not de= crypt the access token. >=20 > * 10: is the server required to cache old transaction IDs to avoid replay > attacks? If this is the case, you need to mandate it explicitly. Fixed. NEW: An attacker trying to replay message with ACCESS-TOKEN attribute can be mit= igated by frequent changes of nonce value as discussed in section 10.2 of [RFC5389]. >=20 > * App. A: the mac_key as included in the token should be binary IMO, and > not as shown here, encoded in base64. Assuming mac_key is negotiated using DSKPP base64 encoding is shown, will a= dd a note that mac_key is base64 encoded and=20 must be converted to binary for HMAC computation. >=20 > * I suggest to rename "long term password" to "long term key"=20 Fixed. > (and again, it > should be binary). Added note that long_term_key is base64 encoded and must be converted to bi= nary for encrypting and decrypting of token. >=20 > * Similarly, the nonce should be binary. Updated. Best Regards, -Tiru >=20 > Thanks, > Yaron From nobody Mon Feb 2 10:46:15 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0AA1A8931 for ; Mon, 2 Feb 2015 10:46:14 -0800 (PST) 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 zZUuBEdt38M8 for ; Mon, 2 Feb 2015 10:46:11 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126721A890D for ; Mon, 2 Feb 2015 10:46:11 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id z12so40534741wgg.3 for ; Mon, 02 Feb 2015 10:46:09 -0800 (PST) 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=5yWO8HNxzNblrNYj4V/6XILDF93UwLes55S8o4bcbbU=; b=IMWF9sR56EMC/7qhOKkY3HFDRf8sLCLTPRLAodxTSvACPfLNKqG5rdbZMhXILBGLAv ePY6PZvXAvFxJ/rKYEh2DqV7dFHE+LkGiJ26DOgrQmPmqXjG+EYrh4z58Yl/DKbTE5sB AcRzvKs25A9LFvHD41WeXzwhqvPYNeZBwD6COqZg4OMlCeK9Roakq0TyqktbEn1BxdKR QJb9mSfyP1fLvxSmqLBg6dSy/26VcIPzTL9+BECKyBnoM2cHjQg81KMemjs86vR/NZa4 bSHTfyZuXkIqhdo0VWp9Az0VFp7rQRtZCw/pbsnFvYuN5S95EufI04hRm9XWLm2/lGVL 3aGw== MIME-Version: 1.0 X-Received: by 10.194.81.104 with SMTP id z8mr45843068wjx.45.1422902769716; Mon, 02 Feb 2015 10:46:09 -0800 (PST) Received: by 10.194.87.98 with HTTP; Mon, 2 Feb 2015 10:46:09 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A35535978@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A35535978@xmb-rcd-x10.cisco.com> Date: Mon, 2 Feb 2015 10:46:09 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7bf0c58e23b23b050e1f5ebe Archived-At: Cc: Yaron Sheffer , "draft-ietf-tram-turn-third-party-authz.all@tools.ietf.org" , "tram@ietf.org" Subject: Re: [tram] SecDir review of draft-ietf-tram-turn-third-party-authz-07 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, 02 Feb 2015 18:46:15 -0000 --047d7bf0c58e23b23b050e1f5ebe Content-Type: text/plain; charset=UTF-8 Tiru, if we are changing the nonce length, then the example vectors must be re-calculated... let me know when you complete the changes, I can adjust my code and re-calculate the vectors. Regards, Oleg On Mon, Feb 2, 2015 at 10:07 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Hi Yaron, > > Thanks for the detailed review. Please see inline > > > -----Original Message----- > > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > > Sent: Sunday, February 01, 2015 11:26 PM > > To: IETF Security Directorate; The IESG; > draft-ietf-tram-turn-third-party- > > authz.all@tools.ietf.org > > Subject: SecDir review of draft-ietf-tram-turn-third-party-authz-07 > > > > I have reviewed this document as part of the security directorate's > ongoing > > effort to review all IETF documents being processed by the IESG. > > These comments were written primarily for the benefit of the security > area > > directors. Document editors and WG chairs should treat these comments > > just like any other last call comments. > > > > This document defines a mechanism where a STUN client can present an > > OAUTH token and get authorized to use a particular STUN server. > > > > Summary > > > > IMHO, the document is not yet ready to be published. > > > > Details > > > > * What is the motivation for this authorization? Is it intended to > conserve > > server resources? > > Yes, to ensure that only authorized clients can use the STUN server. For > example allow the client to use the TURN server only when making a call > using the WebRTC server. > > > > > * What is HMAC-SHA-256-128? Is the output 128 or 256 bits long? > > The output is truncated to 128 bit. > > > Please > > include a reference. > > Added reference to RFC 4868. > > > > > * Maybe I'm confused, but it seems to me that the discussion immediately > > following Fig. 2 mixes the hash algorithm that signs the token itself > with the > > algorithm that integrity-protects STUN messages. If they must be the same > > for some reason, please state it clearly. > > No, they do not need to be same. RFC 5389 mandates HMAC-SHA1 for integrity > protection of STUN message and in future the WG plans to remove this > limitation, hence we added this paragraph after Fig.2. > > > > > * 4.1: there are obvious benefits to using an asymmetric key here, and > in fact > > this can be done efficiently using elliptic curves (ECDSA). So I think > the "MUST > > establish a symmetric key" is misguided. > > Agreed. > NEW: > Elliptic curve cryptography (ECC) or symmetric-key algorithm MUST be > chosen to ensure that the size of encrypted token is not large because > usage of RSA will result in large encrypted tokens which may not fit into a > single STUN message. > > > > > * 4.1.1: the derivation of both keys seems to be the same, so are they > > identical?! > > The derivation of the keys is required if the encryption and HMAC > algorithm require keys of different length. > > NEW: > For example > if the input symmetric key (K) is 32 octets length, encryption > algorithm is AES_256_CBC and HMAC algorithm is HMAC-SHA1 [RFC2104] > then the secondary keys AS-RS, AUTH are generated from the input key > K as follows > > 1. HKDF-Extract(zero, K) -> PRK > > 2. HKDF-Expand(PRK, zero, 16) -> AUTH key > > 3. HKDF-Expand(PRK, zero, 32) -> AS-RS key > > > > > * 4.1.2: this interaction (a simple REST query to get a long-term key) > is by > > default insecure, so I'm surprised to see it here with no comments about > the > > need to encrypt it an authenticate the client. > > Good point, updated draft. > NEW: > The two servers could choose to use REST API over HTTPS to establish a > symmetric key. HTTPS MUST be used for mutual authentication and > confidentiality. > > > > > * 4.1.3: please provide a reference for AES_256_CBC_HMAC_SHA_512. > > Added reference. > > > > > * 6.1, last sentence: so an attacker who can disrupt communication to > the AS > > can force the client to switch to 1st party authentication, which is > easily > > susceptible to dictionary attacks ? > > The possible way to mitigate the attack is use (D)TLS for communication > b/w the client and server. > > NEW text (added to Security considerations): > An attacker may remove the THIRD-PARTY-AUTHORIZATION STUN attribute > from the error message forcing the client to pick first party > authentication, this attack may be mitigated by opting for Transport > Layer Security (TLS) [RFC5246] or Datagram Transport Layer Security > (DTLS) [RFC6347] as a transport protocol for Session Traversal > Utilities for NAT (STUN), as defined in [RFC5389]and [RFC7350]. > > > > > * 6.2: the timestamp value is strange, specifically the fractional part. > > Why are fractions needed, do we think this improves security? > > We used the description from > http://tools.ietf.org/html/rfc3971#section-5.3.1 > Do you see a problem ? > > > > > * 6.2 example: when using AES-256-CBC something must be said about > > padding and about the IV. > > Yes, updated encrypted_block to include padding, padding_length; > > struct { > opaque { > uint16_t key_length; > opaque mac_key[key_length]; > uint64_t timestamp; > uint32_t lifetime; > uint8_t padding_length; > uint8_t padding[padding_length]; > } encrypted_block; > opaque mac[mac_length]; > uint8_t mac_length; > } token; > > padding_length: The padding length MUST be such that the total size > of the encrypted_block structure is a multiple of the cipher's > block length. > > padding: Padding that is added to force the length of the plaintext > to be an integral multiple of the block cipher's block length. > > And the below text to address the comment on IV > > o C = AES_256_CBC(AS-RS, encrypted_block) > > * Initialization vector can be set to zero because the > encrypted_block in each access token will not be identical and > hence will not result in generation of identical ciphertext. > > > > > * 6.2, last sentence: the length of the nonce surely depends on the > selected > > algorithm, and cannot be a constant 12. > > Yes, removed the last sentence and added the following line: > The length of nonce for AEAD algorithms is explained in [RFC5116]. > > > > > * 8: Is the MESAGE INTEGRITY attribute itself mandatory ? > > Yes. > > > The client should > > reject messages if this attribute is not included. > > Added following text for clarity: > > o The client looks for the MESSAGE-INTEGRITY attribute in the > response. If MESSAGE-INTEGRITY is absent or the value computed > for message integrity using mac_key does not match the contents of > the MESSAGE-INTEGRITY attribute then the response MUST be > discarded. > > > > > * 9: if the server is allowed to cache access tokens, there must be a > way for > > the client to refer to a token by name. Otherwise there may be confusion > > when tokens are expired and replaced by new ones, especially in the > > presence of dropped messages. > > That line is only for server implementation optimization. > NEW: > Since the access token is only valid for a specific period of time, the > TURN server can cache it so that it can check if the access token in a new > allocation request matches one of the cached tokens and avoids the need not > decrypt the access token. > > > > > * 10: is the server required to cache old transaction IDs to avoid replay > > attacks? If this is the case, you need to mandate it explicitly. > > Fixed. > NEW: > An attacker trying to replay message with ACCESS-TOKEN attribute can be > mitigated by > frequent changes of nonce value as discussed in section 10.2 of > [RFC5389]. > > > > > * App. A: the mac_key as included in the token should be binary IMO, and > > not as shown here, encoded in base64. > > Assuming mac_key is negotiated using DSKPP base64 encoding is shown, will > add a note that mac_key is base64 encoded and > must be converted to binary for HMAC computation. > > > > > > * I suggest to rename "long term password" to "long term key" > > Fixed. > > > (and again, it > > should be binary). > > Added note that long_term_key is base64 encoded and must be converted to > binary for encrypting and decrypting of token. > > > > > * Similarly, the nonce should be binary. > > Updated. > > Best Regards, > -Tiru > > > > > Thanks, > > Yaron > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7bf0c58e23b23b050e1f5ebe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tiru, if we are changing the nonce length, then the e= xample vectors must be re-calculated... let me know when you complete the c= hanges, I can adjust my code and re-calculate the vectors.

Regards,
Oleg


On Mon, Feb 2, 2015 at 10:07 AM, Tirumaleswar Reddy (t= ireddy) <tireddy@cisco.com> wrote:
Hi Yaron,

Thanks for the detailed review. Please see inline

> -----Original Message-----
> From: Yaron Sheffer [mailto:y= aronf.ietf@gmail.com]
> Sent: Sunday, February 01, 2015 11:26 PM
> To: IETF Security Directorate; The IESG; draft-ietf-tram-turn-third-pa= rty-
> authz.all@tools.ietf.org
> Subject: SecDir review of draft-ietf-tram-turn-third-party-authz-07 >
> I have reviewed this document as part of the security directorate'= s ongoing
> effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security = area
> directors.=C2=A0 Document editors and WG chairs should treat these com= ments
> just like any other last call comments.
>
> This document defines a mechanism where a STUN client can present an > OAUTH token and get authorized to use a particular STUN server.
>
> Summary
>
> IMHO, the document is not yet ready to be published.
>
> Details
>
> * What is the motivation for this authorization? Is it intended to con= serve
> server resources?

Yes, to ensure that only authorized clients can use the STUN server. For ex= ample allow the client to use the TURN server only when making a call using= the WebRTC server.

>
> * What is HMAC-SHA-256-128? Is the output 128 or 256 bits long?

The output is truncated to 128 bit.

> Please
> include a reference.

Added reference to RFC 4868.

>
> * Maybe I'm confused, but it seems to me that the discussion immed= iately
> following Fig. 2 mixes the hash algorithm that signs the token itself = with the
> algorithm that integrity-protects STUN messages. If they must be the s= ame
> for some reason, please state it clearly.

No, they do not need to be same. RFC 5389 mandates HMAC-SHA1 for integrity = protection of STUN message and in future the WG plans to remove this limita= tion, hence we added this paragraph after Fig.2.

>
> * 4.1: there are obvious benefits to using an asymmetric key here, and= in fact
> this can be done efficiently using elliptic curves (ECDSA). So I think= the "MUST
> establish a symmetric key" is misguided.

Agreed.
NEW:
Elliptic curve cryptography (ECC) or symmetric-key algorithm MUST be chosen= to ensure that the size of encrypted token is not large because usage of R= SA will result in large encrypted tokens which may not fit into a single ST= UN message.

>
> * 4.1.1: the derivation of both keys seems to be the same, so are they=
> identical?!

The derivation of the keys is required if the encryption and HMAC algorithm= require keys of different length.

NEW:
For example
=C2=A0 =C2=A0if the input symmetric key (K) is 32 octets length, encryption=
=C2=A0 =C2=A0algorithm is AES_256_CBC and HMAC algorithm is HMAC-SHA1 [RFC2= 104]
=C2=A0 =C2=A0then the secondary keys AS-RS, AUTH are generated from the inp= ut key
=C2=A0 =C2=A0K as follows

=C2=A0 =C2=A01.=C2=A0 HKDF-Extract(zero, K) -> PRK

=C2=A0 =C2=A02.=C2=A0 HKDF-Expand(PRK, zero, 16) -> AUTH key

=C2=A0 =C2=A03.=C2=A0 HKDF-Expand(PRK, zero, 32) -> AS-RS key

>
> * 4.1.2: this interaction (a simple REST query to get a long-term key)= is by
> default insecure, so I'm surprised to see it here with no comments= about the
> need to encrypt it an authenticate the client.

Good point, updated draft.
NEW:
The two servers could choose to use REST API over HTTPS to establish a symm= etric key. HTTPS MUST be used for mutual authentication and confidentiality= .

>
> * 4.1.3: please provide a reference for AES_256_CBC_HMAC_SHA_512.

Added reference.

>
> * 6.1, last sentence: so an attacker who can disrupt communication to = the AS
> can force the client to switch to 1st party authentication, which is e= asily
> susceptible to dictionary attacks ?

The possible way to mitigate the attack is use (D)TLS for communication b/w= the client and server.

NEW text (added to Security considerations):
=C2=A0 =C2=A0An attacker may remove the THIRD-PARTY-AUTHORIZATION STUN attr= ibute
=C2=A0 =C2=A0from the error message forcing the client to pick first party<= br> =C2=A0 =C2=A0authentication, this attack may be mitigated by opting for Tra= nsport
=C2=A0 =C2=A0Layer Security (TLS) [RFC5246] or Datagram Transport Layer Sec= urity
=C2=A0 =C2=A0(DTLS) [RFC6347] as a transport protocol for Session Traversal=
=C2=A0 =C2=A0Utilities for NAT (STUN), as defined in [RFC5389]and [RFC7350]= .

>
> * 6.2: the timestamp value is strange, specifically the fractional par= t.
> Why are fractions needed, do we think this improves security?

We used the description from http://tools.ietf.org/html/rfc3971#section= -5.3.1
Do you see a problem ?

>
> * 6.2 example: when using AES-256-CBC something must be said about
> padding and about the IV.

Yes, updated encrypted_block to include padding, padding_length;

=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=A0uint16_t key_= length;
=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=A0uint64_t time= stamp;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32_t life= time;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint8_t=C2=A0= padding_length;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint8_t paddi= ng[padding_length];
=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 =C2=A0 =C2=A0uint8_t mac_length;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} token;

=C2=A0 =C2=A0padding_length:=C2=A0 The padding length MUST be such that the= total size
=C2=A0 =C2=A0 =C2=A0 of the encrypted_block structure is a multiple of the = cipher's
=C2=A0 =C2=A0 =C2=A0 block length.

=C2=A0 =C2=A0padding:=C2=A0 Padding that is added to force the length of th= e plaintext
=C2=A0 =C2=A0 =C2=A0 to be an integral multiple of the block cipher's b= lock length.

And the below text to address the comment on IV

=C2=A0 =C2=A0o=C2=A0 C =3D AES_256_CBC(AS-RS, encrypted_block)

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 Initialization vector can be set to zero becau= se the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0encrypted_block in each access token will= not be identical and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hence will not result in generation of id= entical ciphertext.

>
> * 6.2, last sentence: the length of the nonce surely depends on the se= lected
> algorithm, and cannot be a constant 12.

Yes, removed the last sentence and added the following line:
The length of nonce for AEAD algorithms is explained in [RFC5116].

>
> * 8: Is the MESAGE INTEGRITY attribute itself mandatory ?

Yes.

> The client should
> reject messages if this attribute is not included.

Added following text for clarity:

=C2=A0 =C2=A0o=C2=A0 The client looks for the MESSAGE-INTEGRITY attribute i= n the
=C2=A0 =C2=A0 =C2=A0 response.=C2=A0 If MESSAGE-INTEGRITY is absent or the = value computed
=C2=A0 =C2=A0 =C2=A0 for message integrity using mac_key does not match the= contents of
=C2=A0 =C2=A0 =C2=A0 the MESSAGE-INTEGRITY attribute then the response MUST= be
=C2=A0 =C2=A0 =C2=A0 discarded.

>
> * 9: if the server is allowed to cache access tokens, there must be a = way for
> the client to refer to a token by name. Otherwise there may be confusi= on
> when tokens are expired and replaced by new ones, especially in the > presence of dropped messages.

That line is only for server implementation optimization.
NEW:
Since the access token is only valid for a specific period of time, the TUR= N server can cache it so that it can check if the access token in a new all= ocation request matches one of the cached tokens and avoids the need not de= crypt the access token.

>
> * 10: is the server required to cache old transaction IDs to avoid rep= lay
> attacks? If this is the case, you need to mandate it explicitly.

Fixed.
NEW:
An attacker trying to replay message with ACCESS-TOKEN attribute can be mit= igated by
frequent changes of nonce value as discussed in section 10.2 of
[RFC5389].

>
> * App. A: the mac_key as included in the token should be binary IMO, a= nd
> not as shown here, encoded in base64.

Assuming mac_key is negotiated using DSKPP base64 encoding is shown, will a= dd a note that mac_key is base64 encoded and
must be converted to binary for HMAC computation.


>
> * I suggest to rename "long term password" to "long ter= m key"

Fixed.

> (and again, it
> should be binary).

Added note that long_term_key is base64 encoded and must be converted to bi= nary for encrypting and decrypting of token.

>
> * Similarly, the nonce should be binary.

Updated.

Best Regards,
-Tiru

>
> Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yaron

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

--047d7bf0c58e23b23b050e1f5ebe-- From nobody Mon Feb 2 11:06:33 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3B81A8948 for ; Mon, 2 Feb 2015 11:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jC_NeXY9PksF for ; Mon, 2 Feb 2015 11:06:22 -0800 (PST) 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 BC4C71A893F for ; Mon, 2 Feb 2015 11:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17334; q=dns/txt; s=iport; t=1422903982; x=1424113582; h=from:to:cc:subject:date:message-id:mime-version; bh=cLc/hA4vcdoqLCGSafE5ycLb9ByYhNirB6iX9p0ZZHo=; b=YVgExPDt/V1iFayNz/UvopMAecoLB4Xd4v64H8X/O+PXIG9JXYtBZW0S 8jZ83dFu3lLoLwlj5AZS3z3ROdyAaLjbCj1K3YEwvsfVCWurqEOQJhJVO a2ldaH9heH+80Fcdd/m2U7tig5ifxTPJN9VpisucAFE2FstpK5b9MsM9/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0FALLJz1StJA2N/2dsb2JhbABbgkNDUlkEgn2/QoIlhXECHIEBQwEBAQEBfYQMAQEBBCMKTBIBCA4DBAEBCx0DAgQfERQJCQEEDgUIiBEDEQ3ALJAcDYU2AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSNToF5LQQGgmkugRMFhEoGijmDToQRjiWFfSKDbm+BRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,507,1418083200"; d="scan'208,217";a="393133176" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP; 02 Feb 2015 19:06:22 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t12J6LkP017046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Feb 2015 19:06:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 13:06:21 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt Thread-Index: AdA/G1ECTZoLkAQFTVODnFUgyI9qYg== Date: Mon, 2 Feb 2015 19:06:21 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35536EC1@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.32.8] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35536EC1xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 02 Feb 2015 19:06:30 -0000 --_000_913383AAA69FF945B8F946018B75898A35536EC1xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXdlc29tZSDimLoNCg0KLVRpcnUNCg0KRnJvbTogT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86bW9t MDQwMjY3QGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMDIsIDIwMTUgOTo1OCBQ TQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiB0cmFtQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3RyYW1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAx LnR4dA0KDQpUaGUgcHJvY2VzcyBvZiBwcm9vZi1yZWFkaW5nIHRoZSBkcmFmdCBpbnZvbHZlZCBh Y3R1YWwgaW1wbGVtZW50YXRpb246DQoNCmh0dHBzOi8vY29kZS5nb29nbGUuY29tL3AvY290dXJu L3dpa2kvRG93bmxvYWRzDQpGb3IgZXhwZXJpbWVudGFsIGltcGxlbWVudGF0aW9uLCBJIHVzZWQg bmV3IGF0dHJpYnV0ZSB0eXBlcyAweDgwMzIgYW5kIDB4ODAzMyAoZm9yIEFERElUSU9OQUwtQURE UkVTUy1GQU1JTFkgYW5kIEFERFJFU1MtRVJST1ItQ09ERSkuIFRoYXQgd2lsbCBiZSBjaGFuZ2Vk IHdoZW4gSUFOQSBhc3NpZ25zIGFjdHVhbCBudW1iZXJzDQpPbGVnDQoNCk9uIFN1biwgRmViIDEs IDIwMTUgYXQgOToxNCBQTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBj aXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQpJbmxpbmUgW1RSM10N Cg0KRnJvbTogT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbTxtYWls dG86bW9tMDQwMjY3QGdtYWlsLmNvbT5dDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDAyLCAyMDE1 IDk6NTAgQU0NClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpDYzogdHJhbUBpZXRm Lm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdHJhbV0gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDEudHh0DQoNCg0KDQpBcyBpdCBpcyBub3csIEkg c2VlIHR3byBwb2ludHM6DQoxKSBUaGUgbGVnYWN5IFJGQyA2MTU2LWNvbXBsaWFudCBjbGllbnRz IGFyZSBub3QgdHVybmJpcy1jb21wbGlhbnQgLSBiZWNhdXNlIHRoZXkgaW5jbHVkZSBSQUYgaW50 byBSRUZSRVNIOw0KMikgVGhlIGxlZ2FjeSBSRkMgNjE1Ni1jb21wbGlhbnQgY2xpZW50cyBhcmUg Y29tcGF0aWJsZSB3aXRoIHRoZSBuZXcgdHVybmJpcy1zZXJ2ZXJzIC0gYmVjYXVzZSB0aGUgdHVy bmJpcy1zZXJ2ZXJzIGtub3cgaG93IHRvIGhhbmRsZSBSQUYgaW4gUkVGUkVTSC4NCldhcyB0aGF0 IHdoYXQgeW91IHdlcmUgdHJ5aW5nIHRvIGFjaGlldmUgPw0KDQpbVFIyIFBvaW50IDIgKFdlIGNh bm5vdCBwcm9jZWVkIHdpdGggcG9pbnQgMSBiZWNhdXNlIGl0IHdpbGwgYnJlYWsgYmFja3dhcmQg Y29tcGF0aWJpbGl0eSkNCg0KDQoNCkkgdW5kZXJzdGFuZCB0aGF0LiBCdXQgSSBkbyBub3QgdW5k ZXJzdGFuZCB3aHkgdGhlIHNlY3Rpb24gNy4xIHNheXMgdGhhdCB0aGUgY2xpZW50cyBNVVNUIG5v dCBpbmNsdWRlIFJBRiBpbnRvIFJFRlJFU0g7IGJ1dCB0aGUgc2VjdGlvbiA3LjIgZGVzY3JpYmVz IHdoYXQgc2VydmVyIGhhcyB0byBkbyBpZiBpdCBkb2VzIHJlY2VpdmUgUkFGIGluIHRoZSBSRUZS RVNIIHJlcXVlc3QuIFdoYXQgd2FzIHRoZSByZWFzb25pbmcgZm9yIHRoYXQgPyBUaGUgc2FtZSB3 b3JkaW5nIGNhbiBiZSBmb3VuZCBpbiBSRkMgNjE1Ni4NClNvLCB0aGUgc2VjdGlvbiA3LjEgY29u dHJhZGljdHMgdGhlIHNlY3Rpb24gNy4yLiBJIHN0aWxsIGNhbm5vdCB1bmRlcnN0YW5kIHdoeSB0 aGUgY3VycmVudCB3b3JkaW5nIGlzIGNob3Nlbi4NCltUUjNdIFllcywgSSBhZ3JlZSB0aGF0IHRo ZSBjb250cmFkaWN0b3J5IHRleHQgaW4gc2VjdGlvbiA3LjIgc2hvdWxkIGJlIHJlbW92ZWQuIEJ1 dCBsZXTigJlzIGhlYXIgZnJvbSB0aGUgYXV0aG9ycyBvZiBSRkMgNjE1NiwgdGhleSBtaWdodCBo YWQgc29tZSB2YWxpZCByZWFzb24gZm9yIHRoaXMgYmVoYXZpb3IuDQotVGlydQ0KVGhhbmtzDQpP bGVnDQoNCg0KDQo= --_000_913383AAA69FF945B8F946018B75898A35536EC1xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Bd2Vz b21lDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2lu Z2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86bW9tMDQwMjY3QGdt YWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDAyLCAyMDE1IDk6 NTggUE08YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQo8 Yj5DYzo8L2I+IHRyYW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+VGhlIHByb2Nlc3Mgb2YgcHJvb2YtcmVhZGluZyB0aGUgZHJhZnQg aW52b2x2ZWQgYWN0dWFsIGltcGxlbWVudGF0aW9uOjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vY29kZS5nb29nbGUuY29tL3AvY290dXJuL3dpa2kvRG93bmxvYWRzIj5odHRwczovL2NvZGUu Z29vZ2xlLmNvbS9wL2NvdHVybi93aWtpL0Rvd25sb2FkczwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+Rm9yIGV4cGVyaW1lbnRhbCBpbXBsZW1lbnRhdGlvbiwgSSB1c2VkIG5ldyBhdHRyaWJ1 dGUgdHlwZXMgMHg4MDMyIGFuZCAweDgwMzMgKGZvciBBRERJVElPTkFMLUFERFJFU1MtRkFNSUxZ IGFuZCBBRERSRVNTLUVSUk9SLUNPREUpLiBUaGF0IHdpbGwgYmUgY2hhbmdlZCB3aGVuIElBTkEg YXNzaWducyBhY3R1YWwgbnVtYmVyczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbGVnPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwg RmViIDEsIDIwMTUgYXQgOToxNCBQTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRk eUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SW5saW5lIFtUUjNdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBPbGVnIE1vc2thbGVua28gW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOm1vbTA0MDI2N0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+bW9tMDQwMjY3QGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDAyLCAy MDE1IDk6NTAgQU08YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8 YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDEudHh0PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdDtib3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVz ZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3IgYmx1ZSI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5BcyBpdCBpcyBub3csIEkgc2VlIHR3byBwb2lu dHM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+MSkgVGhlIGxlZ2FjeSBSRkMgNjE1Ni1jb21wbGlhbnQgY2xpZW50cyBh cmUgbm90IHR1cm5iaXMtY29tcGxpYW50IC0gYmVjYXVzZSB0aGV5IGluY2x1ZGUgUkFGIGludG8g UkVGUkVTSDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ MikgVGhlIGxlZ2FjeSBSRkMgNjE1Ni1jb21wbGlhbnQgY2xpZW50cyBhcmUgY29tcGF0aWJsZSB3 aXRoIHRoZSBuZXcgdHVybmJpcy1zZXJ2ZXJzIC0gYmVjYXVzZSB0aGUgdHVybmJpcy1zZXJ2ZXJz IGtub3cgaG93IHRvIGhhbmRsZSBSQUYgaW4gUkVGUkVTSC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2FzIHRoYXQgd2hhdCB5b3Ugd2VyZSB0 cnlpbmcgdG8gYWNoaWV2ZSA/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFIyIFBvaW50IDIgKFdlIGNhbm5vdCBwcm9jZWVk IHdpdGggcG9pbnQgMSBiZWNhdXNlIGl0IHdpbGwgYnJlYWsgYmFja3dhcmQgY29tcGF0aWJpbGl0 eSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ SSB1bmRlcnN0YW5kIHRoYXQuIEJ1dCBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoeSB0aGUgc2VjdGlv biA3LjEgc2F5cyB0aGF0IHRoZSBjbGllbnRzIE1VU1Qgbm90IGluY2x1ZGUgUkFGIGludG8gUkVG UkVTSDsgYnV0IHRoZSBzZWN0aW9uIDcuMiBkZXNjcmliZXMgd2hhdCBzZXJ2ZXIgaGFzIHRvIGRv IGlmIGl0IGRvZXMNCiByZWNlaXZlIFJBRiBpbiB0aGUgUkVGUkVTSCByZXF1ZXN0LiBXaGF0IHdh cyB0aGUgcmVhc29uaW5nIGZvciB0aGF0ID8gVGhlIHNhbWUgd29yZGluZyBjYW4gYmUgZm91bmQg aW4gUkZDIDYxNTYuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5TbywgdGhlIHNlY3Rpb24gNy4xIGNvbnRyYWRp Y3RzIHRoZSBzZWN0aW9uIDcuMi4gSSBzdGlsbCBjYW5ub3QgdW5kZXJzdGFuZCB3aHkgdGhlIGN1 cnJlbnQgd29yZGluZyBpcyBjaG9zZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+W1RSM10gWWVzLCBJIGFncmVlIHRoYXQgdGhlIGNvbnRyYWRpY3RvcnkgdGV4dCBpbiBzZWN0 aW9uIDcuMiBzaG91bGQgYmUgcmVtb3ZlZC4gQnV0IGxldOKAmXMgaGVhciBmcm9tIHRoZQ0KIGF1 dGhvcnMgb2YgUkZDIDYxNTYsIHRoZXkgbWlnaHQgaGFkIHNvbWUgdmFsaWQgcmVhc29uIGZvciB0 aGlzIGJlaGF2aW9yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoYW5rczxicj4NCk9sZWc8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A35536EC1xmbrcdx10ciscoc_-- From nobody Mon Feb 2 16:27:07 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAF51A874F for ; Mon, 2 Feb 2015 16:27:06 -0800 (PST) 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 fVBYaB3cg_W2 for ; Mon, 2 Feb 2015 16:27:02 -0800 (PST) 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 8E23D1A871C for ; Mon, 2 Feb 2015 16:27:01 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ge10so46693520lab.10 for ; Mon, 02 Feb 2015 16:27:00 -0800 (PST) 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=YVYPJPIE1e6sqFuii78a/O5v+fV42quxxJwlo36zqWE=; b=IfmVD0nfzwMeSVT2AspAWAH+hvg8ri+UITz0iAKq8t0UPVngc6Ota86CVza4TmxLoM cdmm9dTjPCkF5aNEmmmtNB0E9WtapM37f/H271cMDpt/NvXpwPNzjdhGL0+wph2KhVPm Bk4gPbbPBrWBjoxv+bJAo5bIXS9eIR0TR+44HLuahbhXRfqZg1kunb5TO3EJpc4+Kpjk UpXKzd/VWwnJ9M9gxxZoh0H+0mvN/jvi+ypkqimkpMK/NiBE5wn1RwhRtlBhQuRU6sY8 CcrnUtdG49CpL0z7mangl2yUiQw1ZPqxqrsxwq91r8KR+JbLGrUIu7TqQaMvqPFuhjMb hX7A== X-Gm-Message-State: ALoCoQnTvZXvqgVtMMyS6J8LkALu+5KRqATWc6cupn72TEGHzjK4qVz7DaMdrpV3VqErHTaq6gJF MIME-Version: 1.0 X-Received: by 10.152.2.41 with SMTP id 9mr1217194lar.59.1422923219994; Mon, 02 Feb 2015 16:26:59 -0800 (PST) Received: by 10.25.205.135 with HTTP; Mon, 2 Feb 2015 16:26:59 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A3553539F@xmb-rcd-x10.cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553506F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553522B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553539F@xmb-rcd-x10.cisco.com> Date: Mon, 2 Feb 2015 19:26:59 -0500 Message-ID: From: Simon Perreault To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=089e013c6258126aee050e2421eb Archived-At: Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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: Tue, 03 Feb 2015 00:27:06 -0000 --089e013c6258126aee050e2421eb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Feb 1, 2015 at 9:50 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > I found another thing. In the section 7.1, the turnbis document is saying > that: > > "The client MUST NOT include any REQUESTED-ADDRESS-FAMILY attribute in it= s Refresh Request." > > But in the next section, 7.2, there is a paragraph that discusses the > server behaviour when it receives the REQUESTED-ADDRESS-FAMILY attribute = in > the REFRESH request. I guess that paragraph slipped into turnbis from SSO= DA > draft and if has to be removed. > > [TR] The paragraph was picked from RFC 6156; Section 5.1 says client MUST > not include any RAF attribute in its Refresh request and section 5.2 > discusses the server behavior when it receives RAF > > *5.2* *. Receiving a > Refresh Request* > > If a server receives a Refresh Request with a REQUESTED-ADDRESS- > > FAMILY attribute, and the attribute's value doesn't match the address > > family of the allocation, the server MUST reply with a 443 (Peer > > Address Family Mismatch) Refresh error response. > > > > > > Tiru, I got that. But could you please explain why it is written that way > ? > > [TR2] I don=E2=80=99t know why it is written like that ? > > Simon/Gonzalo - Can you please clarify the reasoning for Section 5.2 > Yeah it looks strange, but all of it is correct. That is, RAF is not present in Refresh requests. I don't remember why we specified server behaviour for invalid Refresh requests. Feel free to remove that in turnbis= . Simon --089e013c6258126aee050e2421eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Feb 1, 2015 at 9:50 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisc= o.com> wrote:

I found another thing. In the section 7.1, the turnbis doc= ument is saying that:

"The client MUST NOT include any REQUESTED-ADDRESS-FAMILY attribu=
te in its Refresh Request."

But in the next secti= on, 7.2, there is a paragraph that discusses the server behaviour when it r= eceives the REQUESTED-ADDRESS-FAMILY attribute in the REFRESH request. I gu= ess that paragraph slipped into turnbis from SSODA draft and if has to be removed.<= /u>

[TR] The paragraph was pi= cked from RFC 6156; Section 5.1 says client MUST not include any RAF attrib= ute in its Refresh request and section 5.2 discusses the server behavior when = it receives RAF =C2=A0

5.2.=C2=A0 Receiving a Refresh Request

=C2=A0=C2=A0 If a server receives a Refresh Request with a= REQUESTED-ADDRESS-

=C2=A0=C2=A0 FAMILY attribute, and the attribute's val= ue doesn't match the address

=C2=A0=C2=A0 family of the allocation, the server MUST rep= ly with a 443 (Peer

=C2=A0=C2=A0 Address Family Mismatch) Refresh error respon= se.

=C2=A0

=C2=A0

Tiru, I got that. But= could you please explain why it is written that way ?

[TR2] I don=E2=80=99t know why it is written like that ?

Simon/Gonzalo - =C2=A0Can you please clarify the reasoning for Sectio= n 5.2

Yeah it looks strange, but all of = it is correct. That is, RAF is not present in Refresh requests. I don't= remember why we specified server behaviour for invalid Refresh requests. F= eel free to remove that in turnbis.

Simon
--089e013c6258126aee050e2421eb-- From nobody Mon Feb 2 19:06:51 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713BF1A1BC6 for ; Mon, 2 Feb 2015 19:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEQ2-1ojvbSf for ; Mon, 2 Feb 2015 19:06:46 -0800 (PST) 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 04E701A1BE4 for ; Mon, 2 Feb 2015 19:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13250; q=dns/txt; s=iport; t=1422932806; x=1424142406; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BmYBqPFxn5gYLV2W4P2YZcoSNaUZvzgYrs1II6caphA=; b=f7r8/2N0RPtpb5VucZKEXRYPgPszQwSjpxLUtR/UUk2PO+2jaOu8XewA 1p5wnmqOiM99HFOVNHlZmqxZSSQqlwbnJfF0AAJioIyzLswTDCjCrCIJ0 bY5wWVGhsEKmUdbKc3gZ7beglFy/KY7RRIOloSDhQ1I/X1BBX6iceG6HN 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D2BQAkOtBU/4kNJK1agkNDUlkEgn2/WjyBaYVxAhyBA0MBAQEBAX2EDAEBAQQjCkwQAgEIDgMEAQELHQMCAgIwFAkIAgQOBQiIJQ2/RZY2AQEBAQEBAQEBAQEBAQEBAQEBAQEBF49HMQYBgmgugRMFhX2JDINOhm42gk2OQiKDbm8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,510,1418083200"; d="scan'208,217";a="119936640" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP; 03 Feb 2015 03:06:45 +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 t1336jRZ003914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 03:06:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 21:06:44 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt Thread-Index: AQHQPEw30UXpKS+dFk6Udma1HT7B3pzYIAdggAMiCYD//9HbMIAAs3oAgAAQ34CAABT24IAAo2WAgAAbqJCAAc/0gP//xwcQ Date: Tue, 3 Feb 2015 03:06:44 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A355371AC@xmb-rcd-x10.cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553506F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553522B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553539F@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.34.110] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A355371ACxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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: Tue, 03 Feb 2015 03:06:49 -0000 --_000_913383AAA69FF945B8F946018B75898A355371ACxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogU2ltb24gUGVycmVhdWx0IFttYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbV0NClNlbnQ6 IFR1ZXNkYXksIEZlYnJ1YXJ5IDAzLCAyMDE1IDU6NTcgQU0NClRvOiBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpDQpDYzogT2xlZyBNb3NrYWxlbmtvOyB0cmFtQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3RyYW1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxLnR4dA0K DQoNCk9uIFN1biwgRmViIDEsIDIwMTUgYXQgOTo1MCBQTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0 aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3Jv dGU6DQpJIGZvdW5kIGFub3RoZXIgdGhpbmcuIEluIHRoZSBzZWN0aW9uIDcuMSwgdGhlIHR1cm5i aXMgZG9jdW1lbnQgaXMgc2F5aW5nIHRoYXQ6DQoNCiJUaGUgY2xpZW50IE1VU1QgTk9UIGluY2x1 ZGUgYW55IFJFUVVFU1RFRC1BRERSRVNTLUZBTUlMWSBhdHRyaWJ1dGUgaW4gaXRzIFJlZnJlc2gg UmVxdWVzdC4iDQpCdXQgaW4gdGhlIG5leHQgc2VjdGlvbiwgNy4yLCB0aGVyZSBpcyBhIHBhcmFn cmFwaCB0aGF0IGRpc2N1c3NlcyB0aGUgc2VydmVyIGJlaGF2aW91ciB3aGVuIGl0IHJlY2VpdmVz IHRoZSBSRVFVRVNURUQtQUREUkVTUy1GQU1JTFkgYXR0cmlidXRlIGluIHRoZSBSRUZSRVNIIHJl cXVlc3QuIEkgZ3Vlc3MgdGhhdCBwYXJhZ3JhcGggc2xpcHBlZCBpbnRvIHR1cm5iaXMgZnJvbSBT U09EQSBkcmFmdCBhbmQgaWYgaGFzIHRvIGJlIHJlbW92ZWQuDQpbVFJdIFRoZSBwYXJhZ3JhcGgg d2FzIHBpY2tlZCBmcm9tIFJGQyA2MTU2OyBTZWN0aW9uIDUuMSBzYXlzIGNsaWVudCBNVVNUIG5v dCBpbmNsdWRlIGFueSBSQUYgYXR0cmlidXRlIGluIGl0cyBSZWZyZXNoIHJlcXVlc3QgYW5kIHNl Y3Rpb24gNS4yIGRpc2N1c3NlcyB0aGUgc2VydmVyIGJlaGF2aW9yIHdoZW4gaXQgcmVjZWl2ZXMg UkFGDQo1LjI8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE1NiNzZWN0aW9uLTUuMj4u ICBSZWNlaXZpbmcgYSBSZWZyZXNoIFJlcXVlc3QNCiAgIElmIGEgc2VydmVyIHJlY2VpdmVzIGEg UmVmcmVzaCBSZXF1ZXN0IHdpdGggYSBSRVFVRVNURUQtQUREUkVTUy0NCiAgIEZBTUlMWSBhdHRy aWJ1dGUsIGFuZCB0aGUgYXR0cmlidXRlJ3MgdmFsdWUgZG9lc24ndCBtYXRjaCB0aGUgYWRkcmVz cw0KICAgZmFtaWx5IG9mIHRoZSBhbGxvY2F0aW9uLCB0aGUgc2VydmVyIE1VU1QgcmVwbHkgd2l0 aCBhIDQ0MyAoUGVlcg0KICAgQWRkcmVzcyBGYW1pbHkgTWlzbWF0Y2gpIFJlZnJlc2ggZXJyb3Ig cmVzcG9uc2UuDQoNCg0KVGlydSwgSSBnb3QgdGhhdC4gQnV0IGNvdWxkIHlvdSBwbGVhc2UgZXhw bGFpbiB3aHkgaXQgaXMgd3JpdHRlbiB0aGF0IHdheSA/DQpbVFIyXSBJIGRvbuKAmXQga25vdyB3 aHkgaXQgaXMgd3JpdHRlbiBsaWtlIHRoYXQgPw0KU2ltb24vR29uemFsbyAtICBDYW4geW91IHBs ZWFzZSBjbGFyaWZ5IHRoZSByZWFzb25pbmcgZm9yIFNlY3Rpb24gNS4yDQpZZWFoIGl0IGxvb2tz IHN0cmFuZ2UsIGJ1dCBhbGwgb2YgaXQgaXMgY29ycmVjdC4gVGhhdCBpcywgUkFGIGlzIG5vdCBw cmVzZW50IGluIFJlZnJlc2ggcmVxdWVzdHMuIEkgZG9uJ3QgcmVtZW1iZXIgd2h5IHdlIHNwZWNp ZmllZCBzZXJ2ZXIgYmVoYXZpb3VyIGZvciBpbnZhbGlkIFJlZnJlc2ggcmVxdWVzdHMuIEZlZWwg ZnJlZSB0byByZW1vdmUgdGhhdCBpbiB0dXJuYmlzLg0KDQpbVFJdIERvbmUuDQoNCi1UaXJ1DQoN ClNpbW9uDQo= --_000_913383AAA69FF945B8F946018B75898A355371ACxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBTaW1vbiBQZXJyZWF1bHQgW21haWx0bzpzcGVycmVhdWx0QGppdmUuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDAzLCAyMDE1IDU6NTcgQU08 YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQo8Yj5DYzo8 L2I+IE9sZWcgTW9za2FsZW5rbzsgdHJhbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3RyYW1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxLnR4dDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3Vu LCBGZWIgMSwgMjAxNSBhdCA5OjUwIFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpICZs dDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj50aXJl ZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Ij5JIGZvdW5kIGFub3RoZXIgdGhpbmcuIEluIHRoZSBzZWN0aW9uIDcuMSwgdGhlIHR1 cm5iaXMgZG9jdW1lbnQgaXMgc2F5aW5nIHRoYXQ6PG86cD48L286cD48L3A+DQo8cHJlPiZxdW90 O1RoZSBjbGllbnQgTVVTVCBOT1QgaW5jbHVkZSBhbnkgUkVRVUVTVEVELUFERFJFU1MtRkFNSUxZ IGF0dHJpYnV0ZSBpbiBpdHMgUmVmcmVzaCBSZXF1ZXN0LiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+QnV0IGluIHRoZSBuZXh0IHNlY3Rpb24sIDcuMiwg dGhlcmUgaXMgYSBwYXJhZ3JhcGggdGhhdCBkaXNjdXNzZXMgdGhlIHNlcnZlciBiZWhhdmlvdXIg d2hlbiBpdCByZWNlaXZlcyB0aGUgUkVRVUVTVEVELUFERFJFU1MtRkFNSUxZIGF0dHJpYnV0ZSBp biB0aGUgUkVGUkVTSCByZXF1ZXN0LiBJIGd1ZXNzIHRoYXQgcGFyYWdyYXBoDQogc2xpcHBlZCBp bnRvIHR1cm5iaXMgZnJvbSBTU09EQSBkcmFmdCBhbmQgaWYgaGFzIHRvIGJlIHJlbW92ZWQuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFJdIFRoZSBwYXJhZ3JhcGggd2FzIHBpY2tlZCBmcm9t IFJGQyA2MTU2OyBTZWN0aW9uIDUuMSBzYXlzIGNsaWVudCBNVVNUIG5vdCBpbmNsdWRlIGFueSBS QUYgYXR0cmlidXRlDQogaW4gaXRzIFJlZnJlc2ggcmVxdWVzdCBhbmQgc2VjdGlvbiA1LjIgZGlz Y3Vzc2VzIHRoZSBzZXJ2ZXIgYmVoYXZpb3Igd2hlbiBpdCByZWNlaXZlcyBSQUYgJm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSIxNGI0 ODMyNjVmN2UyYzJlXzE0YjQ1YzBmYzBkZGMzMmFfc2VjdGlvIj48L2E+PGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE1NiNzZWN0aW9uLTUuMiIgdGFyZ2V0PSJfYmxhbmsi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij41LjI8L3NwYW4+PC9iPjwvYT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LiZuYnNwOw0KIFJl Y2VpdmluZyBhIFJlZnJlc2ggUmVxdWVzdDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgSWYgYSBzZXJ2ZXIgcmVj ZWl2ZXMgYSBSZWZyZXNoIFJlcXVlc3Qgd2l0aCBhIFJFUVVFU1RFRC1BRERSRVNTLTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyBGQU1JTFkgYXR0cmlidXRlLCBhbmQgdGhlIGF0dHJpYnV0ZSdzIHZhbHVlIGRvZXNuJ3Qg bWF0Y2ggdGhlIGFkZHJlc3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZmFtaWx5IG9mIHRoZSBhbGxvY2F0aW9uLCB0 aGUgc2VydmVyIE1VU1QgcmVwbHkgd2l0aCBhIDQ0MyAoUGVlcjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBBZGRyZXNz IEZhbWlseSBNaXNtYXRjaCkgUmVmcmVzaCBlcnJvciByZXNwb25zZS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlRpcnUs IEkgZ290IHRoYXQuIEJ1dCBjb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gd2h5IGl0IGlzIHdyaXR0 ZW4gdGhhdCB3YXkgPw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFIyXSBJIGRvbuKAmXQga25vdyB3 aHkgaXQgaXMgd3JpdHRlbiBsaWtlIHRoYXQgPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ U2ltb24vR29uemFsbyAtICZuYnNwO0NhbiB5b3UgcGxlYXNlIGNsYXJpZnkgdGhlIHJlYXNvbmlu ZyBmb3IgU2VjdGlvbiA1LjI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVhaCBpdCBsb29rcyBzdHJhbmdlLCBidXQgYWxsIG9mIGl0 IGlzIGNvcnJlY3QuIFRoYXQgaXMsIFJBRiBpcyBub3QgcHJlc2VudCBpbiBSZWZyZXNoIHJlcXVl c3RzLiBJIGRvbid0IHJlbWVtYmVyIHdoeSB3ZSBzcGVjaWZpZWQgc2VydmVyIGJlaGF2aW91ciBm b3IgaW52YWxpZCBSZWZyZXNoIHJlcXVlc3RzLiBGZWVsIGZyZWUgdG8gcmVtb3ZlIHRoYXQgaW4g dHVybmJpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+W1RSXSBEb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbW9uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_913383AAA69FF945B8F946018B75898A355371ACxmbrcdx10ciscoc_-- From nobody Tue Feb 3 00:18:52 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987A41A86EF for ; Tue, 3 Feb 2015 00:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.358 X-Spam-Level: X-Spam-Status: No, score=0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_44=0.6, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 WFZGbg8cgM43 for ; Tue, 3 Feb 2015 00:18:49 -0800 (PST) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id A20CA1A1B4A for ; Tue, 3 Feb 2015 00:18:48 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.78]) by app1 (Coremail) with SMTP id Z0GX06BbVQu3bdBUzMzKAQ==.55770S2; Tue, 03 Feb 2015 14:41:59 +0800 (CST) From: "Aijun Wang" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Brandon Williams'" References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> In-Reply-To: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> Date: Tue, 3 Feb 2015 16:18:34 +0800 Message-ID: <000001d03f8a$010c89a0$03259ce0$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdA8PxLQg9aQqJ+XQfSjIKEgPWlZUQDRGkxw Content-Language: zh-cn X-CM-TRANSID: Z0GX06BbVQu3bdBUzMzKAQ==.55770S2 X-Coremail-Antispam: 1U3129KBjvJXoWxAFyUXrW5ZrW8WF1xJry7Jrb_yoWruFyUpF W3Wry3Gw1kJr4xAw4kCw1UZFyruFyrWrZrGrnxGrn7ua98A3WYqF9Yyr45KFyDCrn5Z34j qr4Y9a1UC3sYyrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVWUJVW8JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUojjgDUUUU Archived-At: Cc: tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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: Tue, 03 Feb 2015 08:18:51 -0000 Hi, Reddy, I have some comments to the current version of turn-bis: 1. About Transport protocol "Section 2.1 Transports" describe the reason that use different transport protocol between TURN Client/TURN Server and TURN Server/Peer. But from the viewpoint of application, it is very strange that one client use TCP to transport data and the other end use UDP to transport. The common way is the two peers will select the same protocol to transport data. So, I think it is better to use the same protocol between the two legs(TURN Client/TURN Server and TURN Server/Peer). Then the table in section 2.1 should be changed. 2. About EDM NAT transversal between TURN server and peer "Section 2.4 Send Mechanism" describes as below: " When using the Send mechanism, the client sends a Send indication to the TURN server containing (a) an XOR-PEER-ADDRESS attribute specifying the (server-reflexive) transport address of the peer and (b) a DATA attribute holding the application data. When the TURN server receives the Send indication, it extracts the application data from the DATA attribute and sends it in a UDP datagram to the peer, using the allocated relay address as the source address. Note that there is no need to specify the relayed transport address, since it is implied by the 5-tuple used for the Send indication. " If there is one EDM NAT between TURN server and the peer, then the UDP datagram can't pass through it, because the peer did not send packet to the client's relay address before. Here we should add some descriptions about how to meet such environments. 3. Relay between multiple TURN Server As we described in the mail list previously and as proposed by Brandon, I think we should include the scenarios that encompass two TURN Servers between the client and peer. This scenario need not be very detail, but should clarify some key points that different from the one TURN server scenario. Such as which transport method will be used between the client/TURN Server 1; TURN Server 1/TURN Server 2; TURN Server2/peer; how to install the permission on different TURN servers and how the client know the TURN Server 2's address that the peer selects etc. Aijun Wang Best Regards. > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, January 30, 2015 1:18 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt > > > 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 : Traversal Using Relays around NAT (TURN): Relay > Extensions to Session Traversal Utilities for NAT (STUN) > Authors : Tirumaleswar Reddy > Alan Johnston > Philip Matthews > Jonathan Rosenberg > Filename : draft-ietf-tram-turnbis-01.txt > Pages : 77 > Date : 2015-01-29 > > Abstract: > If a host is located behind a NAT, then in certain situations it can > be impossible for that host to communicate directly with other hosts > (peers). In these situations, it is necessary for the host to use > the services of an intermediate node that acts as a communication > relay. This specification defines a protocol, called TURN (Traversal > Using Relays around NAT), that allows the host to control the > operation of the relay and to exchange packets with its peers using > the relay. TURN differs from some other relay control protocols in > that it allows a client to communicate with multiple peers using a > single relay address. > > The TURN protocol was designed to be used as part of the ICE > (Interactive Connectivity Establishment) approach to NAT traversal, > though it also can be used without ICE. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-turnbis-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-01 > > > 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 From nobody Tue Feb 3 00:50:57 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798A21A1A92 for ; Tue, 3 Feb 2015 00:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 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, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvqmN8qIVjox for ; Tue, 3 Feb 2015 00:50:52 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934381A0118 for ; Tue, 3 Feb 2015 00:50:51 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id a1so43156760wgh.12 for ; Tue, 03 Feb 2015 00:50:50 -0800 (PST) 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=gQ06o3jYb+JX1UeTSZhIYljy3s4LkXDlD+y4/U/HGH0=; b=y/BOqPk1fkcZnnosmG19NXRuLK1Bg7yhr3dyv3o82v6eKRiw8wY5iVyl8wQBG5dJzI CZflmo9PN7ubvDUkL4kHd3eInbj+JAEPKh5cLgIsztuPlzW1Q1IhWAVrK2q0gCykxjjp HlDptFKqpLIxvBmc3PhAFpifk4klLyzhocRlG4mv/RJN/mY4MKQ2JNljaa4nsMwyFM0y cKDdAPCj5H4xRv5ZEIQ3M8LNUA548u8bH0Mk9Mu674dk2L7o36WBuq3UFbt5+2ZgMeqb 7sdlQNtFBDZcohP6GGY3Ra+fq7CRPXGYXLCnH8ggHHB9DLd9ejWyL/FY2lTl0rDouqj1 3PbQ== MIME-Version: 1.0 X-Received: by 10.194.60.19 with SMTP id d19mr50674615wjr.48.1422953450342; Tue, 03 Feb 2015 00:50:50 -0800 (PST) Received: by 10.194.87.98 with HTTP; Tue, 3 Feb 2015 00:50:50 -0800 (PST) In-Reply-To: <000001d03f8a$010c89a0$03259ce0$@org.cn> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <000001d03f8a$010c89a0$03259ce0$@org.cn> Date: Tue, 3 Feb 2015 00:50:50 -0800 Message-ID: From: Oleg Moskalenko To: Aijun Wang Content-Type: multipart/alternative; boundary=047d7b86c898f0908f050e2b2a45 Archived-At: Cc: Brandon Williams , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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: Tue, 03 Feb 2015 08:50:53 -0000 --047d7b86c898f0908f050e2b2a45 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 3, 2015 at 12:18 AM, Aijun Wang wrote: > Hi, Reddy, > > I have some comments to the current version of turn-bis: > 1. About Transport protocol > "Section 2.1 Transports" describe the reason that use different transport > protocol between TURN Client/TURN Server and TURN Server/Peer. But from the > viewpoint of application, it is very strange that one client use TCP to > transport data and the other end use UDP to transport. The common way is > the > two peers will select the same protocol to transport data. So, I think it > is > better to use the same protocol between the two legs(TURN Client/TURN > Server > and TURN Server/Peer). Then the table in section 2.1 should be changed. > I do not see any justification for this claim. This is how TURN always has been working, and it's been working just fine. We do not want to tie the protocols of different clients. Each client is free to use whatever protocol it wants and finds appropriate in the client's particular network conditions. > > 2. About EDM NAT transversal between TURN server and peer > "Section 2.4 Send Mechanism" describes as below: > " When using the Send mechanism, the client sends a Send indication to > the TURN server containing (a) an XOR-PEER-ADDRESS attribute > specifying the (server-reflexive) transport address of the peer and > (b) a DATA attribute holding the application data. When the TURN > server receives the Send indication, it extracts the application data > from the DATA attribute and sends it in a UDP datagram to the peer, > using the allocated relay address as the source address. Note that > there is no need to specify the relayed transport address, since it > is implied by the 5-tuple used for the Send indication. > " > If there is one EDM NAT between TURN server and the peer, then the UDP > datagram can't pass through it, because the peer did not send packet to the > client's relay address before. Here we should add some descriptions about > how to meet such environments. > The peer and the TURN server are supposed to be reachable both ways. If that is not the case, then the 'peer' has to be a TURN client. > > 3. Relay between multiple TURN Server > As we described in the mail list previously and as proposed by Brandon, I > think we should include the scenarios that encompass two TURN Servers > between the client and peer. This scenario need not be very detail, but > should clarify some key points that different from the one TURN server > scenario. Such as which transport method will be used between the > client/TURN Server 1; TURN Server 1/TURN Server 2; TURN Server2/peer; how > to > install the permission on different TURN servers and how the client know > the > TURN Server 2's address that the peer selects etc. > I do not see any sense in that clarification. The scheme is trivial. The use case of single TURN server is trivially scaled to whatever number of TURN servers you have. That's only about layers of the TURN protocol. Regards, Oleg --047d7b86c898f0908f050e2b2a45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 3, 2015 at 12:18 AM, Aijun Wang <wangaijun@tsinghu= a.org.cn> wrote:
Hi, Redd= y,

I have some comments to the current version of turn-bis:
1. About Transport protocol
"Section 2.1 Transports" describe the reason that use different t= ransport
protocol between TURN Client/TURN Server and TURN Server/Peer. But from the=
viewpoint of application, it is very strange that one client use TCP to
transport data and the other end use UDP to transport. The common way is th= e
two peers will select the same protocol to transport data. So, I think it i= s
better to use the same protocol between the two legs(TURN Client/TURN Serve= r
and TURN Server/Peer). Then the table in section 2.1 should be changed.
=


I do not see any justification for thi= s claim. This is how TURN always has been working, and it's been workin= g just fine. We do not want to tie the protocols of different clients. Each= client is free to use whatever protocol it wants and finds appropriate in = the client's particular network conditions.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
2. About EDM NAT transversal between TURN server and peer
"Section 2.4 Send Mechanism" describes as below:
" When using the Send mechanism, the client sends a Send indication to=
=C2=A0 =C2=A0the TURN server containing (a) an XOR-PEER-ADDRESS attribute =C2=A0 =C2=A0specifying the (server-reflexive) transport address of the pee= r and
=C2=A0 =C2=A0(b) a DATA attribute holding the application data.=C2=A0 When = the TURN
=C2=A0 =C2=A0server receives the Send indication, it extracts the applicati= on data
=C2=A0 =C2=A0from the DATA attribute and sends it in a UDP datagram to the = peer,
=C2=A0 =C2=A0using the allocated relay address as the source address.=C2=A0= Note that
=C2=A0 =C2=A0there is no need to specify the relayed transport address, sin= ce it
=C2=A0 =C2=A0is implied by the 5-tuple used for the Send indication.
=C2=A0"
If there is one EDM NAT between TURN server and the peer, then the UDP
datagram can't pass through it, because the peer did not send packet to= the
client's relay address before. Here we should add some descriptions abo= ut
how to meet such environments.


The = peer and the TURN server are supposed to be reachable both ways. If that is= not the case, then the 'peer' has to be a TURN client.

=C2=A0

3. Relay between multiple TURN Server
As we described in the mail list previously and as proposed by Brandon, I think we should include the scenarios that encompass two TURN Servers
between the client and peer. This scenario need not be very detail, but
should clarify some key points that different from the one TURN server
scenario. Such as which transport method will be used between the
client/TURN Server 1; TURN Server 1/TURN Server 2; TURN Server2/peer; how t= o
install the permission on different TURN servers and how the client know th= e
TURN Server 2's address that the peer selects etc.

I do not see any sense in that clarification. The scheme is= trivial. The use case of single TURN server is trivially scaled to whateve= r number of TURN servers you have. That's only about layers of the TURN= protocol.
=C2=A0
Regards,
Oleg

--047d7b86c898f0908f050e2b2a45-- From nobody Tue Feb 3 02:37:42 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085451A8769; Tue, 3 Feb 2015 02:37:40 -0800 (PST) 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 CnMe-cwOWWF4; Tue, 3 Feb 2015 02:37:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D26F41A6FBC; Tue, 3 Feb 2015 02:37:38 -0800 (PST) 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.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150203103738.22114.96877.idtracker@ietfa.amsl.com> Date: Tue, 03 Feb 2015 02:37:38 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turnbis-02.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: Tue, 03 Feb 2015 10:37:40 -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 : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Authors : Tirumaleswar Reddy Alan Johnston Philip Matthews Jonathan Rosenberg Filename : draft-ietf-tram-turnbis-02.txt Pages : 77 Date : 2015-02-03 Abstract: If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-turnbis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-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/ From nobody Tue Feb 3 02:40:48 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660F11A7023 for ; Tue, 3 Feb 2015 02:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2uZvex4rHR9 for ; Tue, 3 Feb 2015 02:40:45 -0800 (PST) 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 AA05D1A6F27 for ; Tue, 3 Feb 2015 02:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2639; q=dns/txt; s=iport; t=1422960045; x=1424169645; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=GIhGzHfv7kLFHqqy59ciD51IaUWGpzZ7iYvQlFSJwGQ=; b=A1DElsDfmstIZ7QIijai+HwqyouxWO4e1PdhuvoKCleR/cSZp6+v4oht cKxxzI3RyNaTago47BIzvAglzXYlYsyMo0nw/VmH56Lvh6adnw6cd3POz LQ8BniJvcbAY0VIr3bTPkAq1mQUnM5o94H7aLUPAJPgGIbdZXAEGJGl0K 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAFWl0FStJA2H/2dsb2JhbABagwZSVAnCXoIbCoVxAoEcQwEBAQEBfYQMAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQTCAGIJAgF1WkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj0c4BoMQgRMFjwmDToZuNoJNjkIig25vgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,512,1418083200"; d="scan'208";a="392982849" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 03 Feb 2015 10:40:38 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t13AecRP022637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 3 Feb 2015 10:40:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 04:40:38 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-02.txt Thread-Index: AQHQP5173vXSFBnsLkKxObXY5bhS0JzevE/g Date: Tue, 3 Feb 2015 10:40:37 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35537565@xmb-rcd-x10.cisco.com> References: <20150203103738.22114.96877.idtracker@ietfa.amsl.com> In-Reply-To: <20150203103738.22114.96877.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.127.12.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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: Tue, 03 Feb 2015 10:40:47 -0000 This revision addresses comments from Oleg. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, February 03, 2015 4:08 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-02.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 : Traversal Using Relays around NAT (TURN): Relay= Extensions > to Session Traversal Utilities for NAT (STUN) > Authors : Tirumaleswar Reddy > Alan Johnston > Philip Matthews > Jonathan Rosenberg > Filename : draft-ietf-tram-turnbis-02.txt > Pages : 77 > Date : 2015-02-03 >=20 > Abstract: > If a host is located behind a NAT, then in certain situations it can > be impossible for that host to communicate directly with other hosts > (peers). In these situations, it is necessary for the host to use > the services of an intermediate node that acts as a communication > relay. This specification defines a protocol, called TURN (Traversal > Using Relays around NAT), that allows the host to control the > operation of the relay and to exchange packets with its peers using > the relay. TURN differs from some other relay control protocols in > that it allows a client to communicate with multiple peers using a > single relay address. >=20 > The TURN protocol was designed to be used as part of the ICE > (Interactive Connectivity Establishment) approach to NAT traversal, > though it also can be used without ICE. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-turnbis-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-02 >=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 Tue Feb 3 18:41:57 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870331A1A5A for ; Tue, 3 Feb 2015 18:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.059 X-Spam-Level: *** X-Spam-Status: No, score=3.059 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 YkdvBY-YU3gZ for ; Tue, 3 Feb 2015 18:41:48 -0800 (PST) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 132B11A1A39 for ; Tue, 3 Feb 2015 18:41:43 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.78]) by app1 (Coremail) with SMTP id Z0GX06DrEAQhcNFUKAHbAQ==.25519S2; Wed, 04 Feb 2015 09:04:33 +0800 (CST) From: "Aijun Wang" To: "'Oleg Moskalenko'" References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <000001d03f8a$010c89a0$03259ce0$@org.cn> In-Reply-To: Date: Wed, 4 Feb 2015 10:41:20 +0800 Message-ID: <007401d04024$0ee0d3c0$2ca27b40$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0075_01D04067.1D0413C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdA/ggjREIvMJlcnR+W4IF8f6np09gAmqUig Content-Language: zh-cn X-CM-TRANSID: Z0GX06DrEAQhcNFUKAHbAQ==.25519S2 X-Coremail-Antispam: 1U3129KBjvJXoW3Ar47tw4xtw4Dur43Cr1xZrb_yoWxGF43pF Wagry3Aw1kJr42vw1DAw48WF1ruFWkGr17Jr1DKrn2yws5Ar1DKF97Kwn5KFyUCrZ5XFyY qr4jva1xCa4FvrJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQlb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r1j6r4UM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r126r1D0xZFpf9x0JUdManUUUUU= Archived-At: Cc: 'Brandon Williams' , "'Tirumaleswar Reddy \(tireddy\)'" , tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 04 Feb 2015 02:41:56 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0075_01D04067.1D0413C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 From: Oleg Moskalenko [mailto:mom040267@gmail.com]=20 Sent: Tuesday, February 03, 2015 4:51 PM To: Aijun Wang Cc: Tirumaleswar Reddy (tireddy); Brandon Williams; tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt =20 =20 =20 On Tue, Feb 3, 2015 at 12:18 AM, Aijun Wang = wrote: Hi, Reddy, I have some comments to the current version of turn-bis: 1. About Transport protocol "Section 2.1 Transports" describe the reason that use different = transport protocol between TURN Client/TURN Server and TURN Server/Peer. But from = the viewpoint of application, it is very strange that one client use TCP to transport data and the other end use UDP to transport. The common way is = the two peers will select the same protocol to transport data. So, I think = it is better to use the same protocol between the two legs(TURN Client/TURN = Server and TURN Server/Peer). Then the table in section 2.1 should be changed. =20 I do not see any justification for this claim. This is how TURN always = has been working, and it's been working just fine. We do not want to tie = the protocols of different clients. Each client is free to use whatever = protocol it wants and finds appropriate in the client's particular = network conditions. =20 =20 [Aijun Wang]: TURN acts just like one middleware component and should be = called by the application layer. Application will select TCP if they = want the transport layer to assure the data transfer reliability (for = example in file sharing scenario) and will select UDP if they want to = eliminate the transfer delay(for example in video transfer scenario). = Can you give one example that the application wants part of TCP and part = of UDP to transfer data? 2. About EDM NAT transversal between TURN server and peer "Section 2.4 Send Mechanism" describes as below: " When using the Send mechanism, the client sends a Send indication to the TURN server containing (a) an XOR-PEER-ADDRESS attribute specifying the (server-reflexive) transport address of the peer and (b) a DATA attribute holding the application data. When the TURN server receives the Send indication, it extracts the application data from the DATA attribute and sends it in a UDP datagram to the peer, using the allocated relay address as the source address. Note that there is no need to specify the relayed transport address, since it is implied by the 5-tuple used for the Send indication. " If there is one EDM NAT between TURN server and the peer, then the UDP datagram can't pass through it, because the peer did not send packet to = the client's relay address before. Here we should add some descriptions = about how to meet such environments. =20 =20 The peer and the TURN server are supposed to be reachable both ways. If = that is not the case, then the 'peer' has to be a TURN client. [Aijun Wang]: where is the assumption in current draft? In Figure 1 of = current draft, the peer is located behind one NAT device. So your = suppose(=E2=80=9C=E2=80=A6 be reachable both ways=E2=80=A6=E2=80=9D) is = not always true. Even in [RFC6062], there exists the following = description(section 3, Overview of Operation ):=20 =20 =E2=80=9CIf a client wishes to establish a TCP connection to a peer from = that relayed transport address, it issues a Connect request to the TURN server over the control connection. That request contains an XOR- PEER-ADDRESS attribute identifying the peer IP address and port (i.e., its "transport address") to which a connection is to be made. The TURN server attempts to open the TCP connection, and assuming it succeeds, then responds to the Connect request with a success response. The server also creates a connection identifier associated with this connection and passes that connection identifier back to the client in the success response. Note that a maximum of one connection to a given peer transport address can be established per allocation. =20 Note: Establishing a relayed connection from the client to a peer is done in two steps. First, the allocation is created, and second, the connection is established. Combining the two is not desirable for NAT traversal. It is expected that, between the first and second steps, the client will communicate off-band with the peer (e.g., using ICE [RFC5245]) and tell it the relayed transport address that the TURN server allocated and from which it is about to initiate a connection. The peer can then "get ready": open holes in its firewall, try to poke holes in a NAT, attempt a TCP simultaneous open, etc. =E2=80=9D So, this is also one evidence that your assumption is not always true. = For UDP transport, current TURN solution must also consider the involve = of other methods to let the data from TURN server pass the NAT to the = peer. Is this true? 3. Relay between multiple TURN Server As we described in the mail list previously and as proposed by Brandon, = I think we should include the scenarios that encompass two TURN Servers between the client and peer. This scenario need not be very detail, but should clarify some key points that different from the one TURN server scenario. Such as which transport method will be used between the client/TURN Server 1; TURN Server 1/TURN Server 2; TURN Server2/peer; = how to install the permission on different TURN servers and how the client know = the TURN Server 2's address that the peer selects etc. =20 I do not see any sense in that clarification. The scheme is trivial. The = use case of single TURN server is trivially scaled to whatever number of = TURN servers you have. That's only about layers of the TURN protocol. =20 [Aijun Wang]: Current TURN solution can=E2=80=99t assure the = communication peers select the same TURN Server, so this will be very = common phenomena when you deploy the TURN servers in distributed manner. = And it is not as simple as your image of easy scaling. We have discussed = this in the mail list before and it is not easy to illustrate. Can you = simplify the solution that based on the below graph: =20 A------NAT-1(EDM)-----------TURN Server 1-----------------------TURN = Server-2----------------------NAT-2(EDM)---------------------------B | | = |------------------------------------------------------------------------= ----------------NAT-3(EDM)----------------------------C =20 =20 Regards, Oleg ------=_NextPart_000_0075_01D04067.1D0413C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

From:= Oleg = Moskalenko [mailto:mom040267@gmail.com]
Sent: Tuesday, = February 03, 2015 4:51 PM
To: Aijun Wang
Cc: = Tirumaleswar Reddy (tireddy); Brandon Williams; = tram@ietf.org
Subject: Re: [tram] I-D Action: = draft-ietf-tram-turnbis-01.txt

 

 

 

On Tue, Feb 3, 2015 at 12:18 AM, = Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

Hi, = Reddy,

I have some comments to the current version of = turn-bis:
1. About Transport protocol
"Section 2.1 = Transports" describe the reason that use different = transport
protocol between TURN Client/TURN Server and TURN = Server/Peer. But from the
viewpoint of application, it is very = strange that one client use TCP to
transport data and the other end = use UDP to transport. The common way is the
two peers will select the = same protocol to transport data. So, I think it is
better to use the = same protocol between the two legs(TURN Client/TURN Server
and TURN = Server/Peer). Then the table in section 2.1 should be = changed.

 

I do not see any justification for = this claim. This is how TURN always has been working, and it's been = working just fine. We do not want to tie the protocols of different = clients. Each client is free to use whatever protocol it wants and finds = appropriate in the client's particular network = conditions.

 

 

[Aijun Wang]: TURN acts just like one middleware component and should = be called by the application layer. Application will select TCP=C2=A0 if = they want the transport layer to assure the data transfer reliability = (for example in file sharing scenario) and will select UDP if they want = to eliminate the transfer delay(for example in video transfer scenario). = Can you give one example that the application wants part of TCP and part = of UDP to transfer data?


2. About EDM NAT = transversal between TURN server and peer
"Section 2.4 Send = Mechanism" describes as below:
" When using the Send = mechanism, the client sends a Send indication to
   the = TURN server containing (a) an XOR-PEER-ADDRESS attribute
  =  specifying the (server-reflexive) transport address of the peer = and
   (b) a DATA attribute holding the application = data.  When the TURN
   server receives the Send = indication, it extracts the application data
   from the = DATA attribute and sends it in a UDP datagram to the peer,
  =  using the allocated relay address as the source address.  = Note that
   there is no need to specify the relayed = transport address, since it
   is implied by the 5-tuple = used for the Send indication.
 "
If there is one EDM NAT = between TURN server and the peer, then the UDP
datagram can't pass = through it, because the peer did not send packet to the
client's = relay address before. Here we should add some descriptions about
how = to meet such environments.

 

 

The peer and the TURN server are supposed to be reachable = both ways. If that is not the case, then the 'peer' has to be a TURN = client.


[Aijun Wang]: where is the assumption in current draft? In Figure 1 =
of current draft, the peer is located behind one NAT device. So your =
suppose(=E2=80=9C=E2=80=A6 be reachable both ways=E2=80=A6=E2=80=9D) is =
not always true. Even in [RFC6062], there exists the following =
description(section 3, Overview of Operation ): =

 
=E2=80=9CIf a client wishes to establish a =
TCP connection to a peer from that

=C2=A0=C2=A0 relayed transport = address, it issues a Connect request to the TURN

=C2=A0 =C2=A0server over the = control connection.=C2=A0 That request contains an = XOR-

=C2=A0=C2=A0 PEER-ADDRESS attribute identifying the peer IP = address and port

=C2=A0=C2=A0 (i.e., its "transport address") to = which a connection is to be made.

=C2=A0=C2=A0 The TURN server = attempts to open the TCP connection, and assuming = it

=C2=A0=C2=A0 succeeds, then = responds to the Connect request with a success

=C2=A0=C2=A0 response.=C2=A0 The = server also creates a connection identifier = associated

=C2=A0=C2=A0 with this connection and passes that = connection identifier back to

=C2=A0=C2=A0 the client in the = success response.=C2=A0 Note that a maximum of = one

=C2=A0=C2=A0 connection to a given peer transport address = can be established per

=C2=A0=C2=A0 allocation.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Note: Establishing a relayed connection from the client to a = peer

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is done in two steps.=C2=A0 = First, the allocation is created, and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = second, the connection is established.=C2=A0 Combining the two is = not

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 desirable for NAT = traversal.=C2=A0 It is expected that, between = the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 first and second = steps, the client will communicate = off-band with

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the peer (e.g., using ICE = [RFC5245]) and tell it the relayed

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = transport address that the TURN server allocated and from which = it

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is about to initiate a = connection.=C2=A0 The peer can then "get = ready":

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 open holes in its firewall, = try to poke holes in a NAT, attempt a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TCP = simultaneous open, etc.

=E2=80=9D

So,=C2=A0 this is also one evidence that your assumption is not = always true. For UDP transport, current TURN solution must also consider = the involve of other methods to let the data from TURN server pass the = NAT to the peer. Is this true?


3. Relay between = multiple TURN Server
As we described in the mail list previously and = as proposed by Brandon, I
think we should include the scenarios that = encompass two TURN Servers
between the client and peer. This scenario = need not be very detail, but
should clarify some key points that = different from the one TURN server
scenario. Such as which transport = method will be used between the
client/TURN Server 1; TURN Server = 1/TURN Server 2; TURN Server2/peer; how to
install the permission on = different TURN servers and how the client know the
TURN Server 2's = address that the peer selects = etc.

 

I do not see any sense in that = clarification. The scheme is trivial. The use case of single TURN server = is trivially scaled to whatever number of TURN servers you have. That's = only about layers of the TURN protocol.

 

[Aijun Wang]: Current TURN solution can=E2=80=99t assure the = communication peers select the same TURN Server, so this will be very = common phenomena when you deploy the TURN servers in distributed manner. = And it is not as simple as your image of easy scaling. We have discussed = this in the mail list before and it is not easy to illustrate. Can you = simplify the solution that based on the below = graph:

 

A------NAT-1(EDM)-----------TURN Server 1-----------------------TURN = Server-2----------------------NAT-2(EDM)---------------------------B=

=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=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=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=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=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=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= =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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0|------------------------------------------------------------------= ----------------------NAT-3(EDM)----------------------------C<= /span>

 

 

Regards,
Oleg

------=_NextPart_000_0075_01D04067.1D0413C0-- From nobody Tue Feb 3 19:11:34 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776001A1BA9 for ; Tue, 3 Feb 2015 19:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 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, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-km32tTmIdM for ; Tue, 3 Feb 2015 19:11:27 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DEBF1A1ACA for ; Tue, 3 Feb 2015 19:11:27 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id k48so48408301wev.9 for ; Tue, 03 Feb 2015 19:11:26 -0800 (PST) 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=2PA+tlalHetYfAY0jqshPeuGeVUrX+UFH7q2xgpcf4c=; b=XhGPRLYC8VCkGnUZw4GjeOO6M3cBQ28cglLqK3c9SOYTcG/h9lT5Ep2IrMLn1tWJI3 RHSYWmxXC8QIRQDDx1lagBscxpsrbCQQgDdEQCbOPKMVCUL5RZPCrrW5sz9JdIwkQWHP cJDparYTWOPRmTkezDm84naBYExW5Wfx9v4C9seK7yDTtWVIzGhbL74i0NQhOPIqgB7x PX3Oji/LsyH0Ig6zMJwhQda4f8LtRtJvj1yqhSsajKUgE/DG6DIZogROWs0bQfGKPWK7 Di+2hVktPBIAiQS6mTWM54vTOdLx7Rirvo4+uf80+OAFvSI7AdKuK2WVlgjy7Rg5cb5p Q68w== MIME-Version: 1.0 X-Received: by 10.194.206.70 with SMTP id lm6mr8022752wjc.48.1423019486125; Tue, 03 Feb 2015 19:11:26 -0800 (PST) Received: by 10.194.87.98 with HTTP; Tue, 3 Feb 2015 19:11:26 -0800 (PST) Received: by 10.194.87.98 with HTTP; Tue, 3 Feb 2015 19:11:26 -0800 (PST) In-Reply-To: <007401d04024$0ee0d3c0$2ca27b40$@org.cn> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <000001d03f8a$010c89a0$03259ce0$@org.cn> <007401d04024$0ee0d3c0$2ca27b40$@org.cn> Date: Tue, 3 Feb 2015 19:11:26 -0800 Message-ID: From: Oleg Moskalenko To: Aijun Wang Content-Type: multipart/alternative; boundary=047d7bb70b66faa438050e3a8ab0 Archived-At: Cc: tram@ietf.org, "Tirumaleswar Reddy \(tireddy\)" , Brandon Williams Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 04 Feb 2015 03:11:31 -0000 --047d7bb70b66faa438050e3a8ab0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Aijun, actually all answers to your questions are in RFC 5766. Sorry but I have a feeling that you did noy read it. TURN is not what you think it is. There is no point going into fine details while the whole picture is not clear to you. Regards, Oleg On Feb 3, 2015 6:41 PM, "Aijun Wang" wrote: > > > *From:* Oleg Moskalenko [mailto:mom040267@gmail.com] > *Sent:* Tuesday, February 03, 2015 4:51 PM > *To:* Aijun Wang > *Cc:* Tirumaleswar Reddy (tireddy); Brandon Williams; tram@ietf.org > *Subject:* Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt > > > > > > > > On Tue, Feb 3, 2015 at 12:18 AM, Aijun Wang > wrote: > > Hi, Reddy, > > I have some comments to the current version of turn-bis: > 1. About Transport protocol > "Section 2.1 Transports" describe the reason that use different transport > protocol between TURN Client/TURN Server and TURN Server/Peer. But from t= he > viewpoint of application, it is very strange that one client use TCP to > transport data and the other end use UDP to transport. The common way is > the > two peers will select the same protocol to transport data. So, I think it > is > better to use the same protocol between the two legs(TURN Client/TURN > Server > and TURN Server/Peer). Then the table in section 2.1 should be changed. > > > > I do not see any justification for this claim. This is how TURN always ha= s > been working, and it's been working just fine. We do not want to tie the > protocols of different clients. Each client is free to use whatever > protocol it wants and finds appropriate in the client's particular networ= k > conditions. > > > > > > [Aijun Wang]: TURN acts just like one middleware component and should be > called by the application layer. Application will select TCP if they wan= t > the transport layer to assure the data transfer reliability (for example = in > file sharing scenario) and will select UDP if they want to eliminate the > transfer delay(for example in video transfer scenario). Can you give one > example that the application wants part of TCP and part of UDP to transfe= r > data? > > > 2. About EDM NAT transversal between TURN server and peer > "Section 2.4 Send Mechanism" describes as below: > " When using the Send mechanism, the client sends a Send indication to > the TURN server containing (a) an XOR-PEER-ADDRESS attribute > specifying the (server-reflexive) transport address of the peer and > (b) a DATA attribute holding the application data. When the TURN > server receives the Send indication, it extracts the application data > from the DATA attribute and sends it in a UDP datagram to the peer, > using the allocated relay address as the source address. Note that > there is no need to specify the relayed transport address, since it > is implied by the 5-tuple used for the Send indication. > " > If there is one EDM NAT between TURN server and the peer, then the UDP > datagram can't pass through it, because the peer did not send packet to t= he > client's relay address before. Here we should add some descriptions about > how to meet such environments. > > > > > > The peer and the TURN server are supposed to be reachable both ways. If > that is not the case, then the 'peer' has to be a TURN client. > > > [Aijun Wang]: where is the assumption in current draft? In Figure 1 of cu= rrent draft, the peer is located behind one NAT device. So your suppose(=E2= =80=9C=E2=80=A6 be reachable both ways=E2=80=A6=E2=80=9D) is not always tru= e. Even in [RFC6062], there exists the following description(section 3, Ove= rview of Operation ): > > > > =E2=80=9CIf a client wishes to establish a TCP connection to a peer from = that > > relayed transport address, it issues a Connect request to the TURN > > server over the control connection. That request contains an XOR- > > PEER-ADDRESS attribute identifying the peer IP address and port > > (i.e., its "transport address") to which a connection is to be made. > > The TURN server attempts to open the TCP connection, and *assuming it* > > * succeeds*, then responds to the Connect request with a success > > response. The server also creates a connection identifier associated > > with this connection and passes that connection identifier back to > > the client in the success response. Note that a maximum of one > > connection to a given peer transport address can be established per > > allocation. > > > > Note: Establishing a relayed connection from the client to a peer > > is done in two steps. First, the allocation is created, and > > second, the connection is established. Combining the two is not > > desirable for NAT traversal. It is expected that, *between the* > > * first and second steps,* the client will communicate off-band with > > the peer (e.g., using ICE [RFC5245]) and tell it the relayed > > transport address that the TURN server allocated and from which it > > is about to initiate a connection. The peer can then "get ready": > > open holes in its firewall, try to poke holes in a NAT, attempt a > > TCP simultaneous open, etc. > > =E2=80=9D > > So, this is also one evidence that your assumption is not always true. > For UDP transport, current TURN solution must also consider the involve o= f > other methods to let the data from TURN server pass the NAT to the peer. = Is > this true? > > > 3. Relay between multiple TURN Server > As we described in the mail list previously and as proposed by Brandon, I > think we should include the scenarios that encompass two TURN Servers > between the client and peer. This scenario need not be very detail, but > should clarify some key points that different from the one TURN server > scenario. Such as which transport method will be used between the > client/TURN Server 1; TURN Server 1/TURN Server 2; TURN Server2/peer; how > to > install the permission on different TURN servers and how the client know > the > TURN Server 2's address that the peer selects etc. > > > > I do not see any sense in that clarification. The scheme is trivial. The > use case of single TURN server is trivially scaled to whatever number of > TURN servers you have. That's only about layers of the TURN protocol. > > > > [Aijun Wang]: Current TURN solution can=E2=80=99t assure the communicatio= n peers > select the same TURN Server, so this will be very common phenomena when y= ou > deploy the TURN servers in distributed manner. And it is not as simple as > your image of easy scaling. We have discussed this in the mail list befor= e > and it is not easy to illustrate. Can you simplify the solution that base= d > on the below graph: > > > > A------NAT-1(EDM)-----------TURN Server 1-----------------------TURN > Server-2----------------------NAT-2(EDM)---------------------------B > > | > > | > > > |-----------------------------------------------------------------------= -----------------NAT-3(EDM)----------------------------C > > > > > > Regards, > Oleg > --047d7bb70b66faa438050e3a8ab0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Aijun, actually all answers to your questions are in RFC 5766. Sorry but= I have a feeling that you did noy read it. TURN is not what you think it i= s. There is no point going into fine details while the whole picture is not= clear to you.

Regards,
Oleg

On Feb 3, 2015 6:41 PM, "Aijun Wang" &= lt;wangaijun@tsinghua.org.cn> wrote:

=C2=A0

From:= Oleg Moskalenko [mailto:mom040267@gmail.com]
<= b>Sent: Tuesday, February 03, 2015 4:51 PM
To: Aijun Wang
= Cc: Tirumaleswar Reddy (tireddy); Brandon Williams; tram@ietf.org
Subject: Re:= [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

=

=C2=A0

=C2=A0<= u>

= =C2=A0

On= Tue, Feb 3, 2015 at 12:18 AM, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:<= u>

Hi, Red= dy,

I have some comments to the current version of turn-bis:
1. A= bout Transport protocol
"Section 2.1 Transports" describe the = reason that use different transport
protocol between TURN Client/TURN Se= rver and TURN Server/Peer. But from the
viewpoint of application, it is = very strange that one client use TCP to
transport data and the other end= use UDP to transport. The common way is the
two peers will select the s= ame protocol to transport data. So, I think it is
better to use the same= protocol between the two legs(TURN Client/TURN Server
and TURN Server/P= eer). Then the table in section 2.1 should be changed.=

=C2=A0

I do not see any justification for this claim. This i= s how TURN always has been working, and it's been working just fine. We= do not want to tie the protocols of different clients. Each client is free= to use whatever protocol it wants and finds appropriate in the client'= s particular network conditions.

=C2=A0<= /u>

=C2=A0

[Aijun Wang]: TURN acts just like one middleware c= omponent and should be called by the application layer. Application will se= lect TCP=C2=A0 if they want the transport layer to assure the data transfer= reliability (for example in file sharing scenario) and will select UDP if = they want to eliminate the transfer delay(for example in video transfer sce= nario). Can you give one example that the application wants part of TCP and= part of UDP to transfer data?

=


2. About EDM NAT transversa= l between TURN server and peer
"Section 2.4 Send Mechanism" de= scribes as below:
" When using the Send mechanism, the client sends= a Send indication to
=C2=A0 =C2=A0the TURN server containing (a) an XOR= -PEER-ADDRESS attribute
=C2=A0 =C2=A0specifying the (server-reflexive) t= ransport address of the peer and
=C2=A0 =C2=A0(b) a DATA attribute holdi= ng the application data.=C2=A0 When the TURN
=C2=A0 =C2=A0server receive= s the Send indication, it extracts the application data
=C2=A0 =C2=A0fro= m the DATA attribute and sends it in a UDP datagram to the peer,
=C2=A0 = =C2=A0using the allocated relay address as the source address.=C2=A0 Note t= hat
=C2=A0 =C2=A0there is no need to specify the relayed transport addre= ss, since it
=C2=A0 =C2=A0is implied by the 5-tuple used for the Send in= dication.
=C2=A0"
If there is one EDM NAT between TURN server an= d the peer, then the UDP
datagram can't pass through it, because the= peer did not send packet to the
client's relay address before. Here= we should add some descriptions about
how to meet such environments.=

=C2=A0

=C2=A0

The peer and the T= URN server are supposed to be reachable both ways. If that is not the case,= then the 'peer' has to be a TURN client.

<= /div>

[Aijun Wang]: where is the assumption in current draft? In =
Figure 1 of current draft, the peer is located behind one NAT device. So yo=
ur suppose(=E2=80=9C=E2=80=A6 be reachable both ways=E2=80=A6=E2=80=9D) is =
not always true. Even in [RFC6062], there exists the following description(=
section 3, Overview of Operation ): 
=C2=A0
=E2=80=9CIf a client wishes to establish a TCP connection to a peer from that

=C2=A0=C2= =A0 relayed transport address, it issues a Connect request to the TURN

=C2=A0 =C2= =A0server over the control connection.=C2=A0 That request contains an XOR-<= u>

=C2=A0= =C2=A0 PEER-ADDRESS attribute identifying the peer IP address and port

=C2=A0=C2= =A0 (i.e., its "transport address") to which a connection is to b= e made.

=C2=A0=C2=A0 The TURN server attempts to open the TCP connection, and a= ssuming it

=C2=A0=C2=A0 succeeds, then resp= onds to the Connect request with a success

=C2=A0=C2=A0 response.=C2=A0 The server= also creates a connection identifier associated

=C2=A0=C2=A0 with this connection= and passes that connection identifier back to

=C2=A0=C2=A0 the client in the succ= ess response.=C2=A0 Note that a maximum of one

=C2=A0=C2=A0 connection to a given = peer transport address can be established per

=C2=A0=C2=A0 allocation.

=C2=A0

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Note: Establishing a relayed connection from the client to a p= eer

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 is done in two steps.=C2=A0 First, the allocati= on is created, and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 second, the connection is establ= ished.=C2=A0 Combining the two is not

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 desirable for= NAT traversal.=C2=A0 It is expected that, between the=

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 first and second steps, the= client will communicate off-band with

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the peer (e.= g., using ICE [RFC5245]) and tell it the relayed

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tr= ansport address that the TURN server allocated and from which it<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 is about to initiate a connection.=C2=A0 The peer can then = "get ready":

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 open holes in its firewall, = try to poke holes in a NAT, attempt a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TCP simultane= ous open, etc.

=E2=80=9D

So,=C2=A0 this is also one evidence that your assumption is not al= ways true. For UDP transport, current TURN solution must also consider the = involve of other methods to let the data from TURN server pass the NAT to t= he peer. Is this true?

=


3. Rela= y between multiple TURN Server
As we described in the mail list previous= ly and as proposed by Brandon, I
think we should include the scenarios t= hat encompass two TURN Servers
between the client and peer. This scenari= o need not be very detail, but
should clarify some key points that diffe= rent from the one TURN server
scenario. Such as which transport method w= ill be used between the
client/TURN Server 1; TURN Server 1/TURN Server = 2; TURN Server2/peer; how to
install the permission on different TURN se= rvers and how the client know the
TURN Server 2's address that the p= eer selects etc.

=C2=A0

I do not see any sense in that clari= fication. The scheme is trivial. The use case of single TURN server is triv= ially scaled to whatever number of TURN servers you have. That's only a= bout layers of the TURN protocol.

=C2=A0=

[Aijun= Wang]: Current TURN solution can=E2=80=99t assure the communication peers = select the same TURN Server, so this will be very common phenomena when you= deploy the TURN servers in distributed manner. And it is not as simple as = your image of easy scaling. We have discussed this in the mail list before = and it is not easy to illustrate. Can you simplify the solution that based = on the below graph:

=C2=A0

A------NAT-1(EDM)-= ----------TURN Server 1-----------------------TURN Server-2----------------= ------NAT-2(EDM)---------------------------B

=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=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=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=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=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=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=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=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=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=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0|-------------------------= ---------------------------------------------------------------NAT-3(EDM)--= --------------------------C

= =C2=A0

=C2=A0

Regards,
Oleg

<= /div>
--047d7bb70b66faa438050e3a8ab0-- From nobody Tue Feb 3 19:38:40 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689401A1AC8 for ; Tue, 3 Feb 2015 19:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.59 X-Spam-Level: X-Spam-Status: No, score=0.59 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDgCDNznq1Tg for ; Tue, 3 Feb 2015 19:38:32 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id A5CEF1A1BD1 for ; Tue, 3 Feb 2015 19:38:28 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.78]) by app1 (Coremail) with SMTP id Z0GX06AbjBB1fdFU_OLlAQ==.26908S2; Wed, 04 Feb 2015 10:01:25 +0800 (CST) From: "Aijun Wang" To: "'Oleg Moskalenko'" References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <000001d03f8a$010c89a0$03259ce0$@org.cn> <007401d04024$0ee0d3c0$2ca27b40$@org.cn> In-Reply-To: Date: Wed, 4 Feb 2015 11:38:13 +0800 Message-ID: <008801d0402c$011311b0$03393510$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01D0406F.0F3651B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdBAGv9IrquHY6m1QtSch8zgTWl4JAAEDerw Content-Language: zh-cn X-CM-TRANSID: Z0GX06AbjBB1fdFU_OLlAQ==.26908S2 X-Coremail-Antispam: 1U3129KBjvJXoW3GryktF17AFWkZFyDAr1xuFg_yoWxtw1rpF Wag343Ar1kJr42vw1DZw48WF1ruFWkGrW3Jr1DKr92yws5Ar1ktF97Kwn5GFyUCrZ5Za4Y qr4jva1xCFyFvrJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQlb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r1j6r4UM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r126r1D0xZFpf9x0JUdManUUUUU= Archived-At: Cc: tram@ietf.org, "'Tirumaleswar Reddy \(tireddy\)'" , 'Brandon Williams' Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 04 Feb 2015 03:38:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0089_01D0406F.0F3651B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Oleg, =20 =E2=80=9Cdraft-ietf-tram-turnbis-01.txt=E2=80=9D is the update version = of RFC 5766, and there is no clear description for these scenarios in = both documents.=20 Can you first answer the questions that I mentioned in these e-mails, = based on the contents of the related RFCs?=20 =20 Best Regards.=20 =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Wednesday, February 04, 2015 11:11 AM To: Aijun Wang Cc: tram@ietf.org; Tirumaleswar Reddy (tireddy); Brandon Williams Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt =20 Aijun, actually all answers to your questions are in RFC 5766. Sorry but = I have a feeling that you did noy read it. TURN is not what you think it = is. There is no point going into fine details while the whole picture is = not clear to you. Regards, Oleg On Feb 3, 2015 6:41 PM, "Aijun Wang" wrote: =20 From: Oleg Moskalenko [mailto:mom040267@gmail.com]=20 Sent: Tuesday, February 03, 2015 4:51 PM To: Aijun Wang Cc: Tirumaleswar Reddy (tireddy); Brandon Williams; tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt =20 =20 =20 On Tue, Feb 3, 2015 at 12:18 AM, Aijun Wang = wrote: Hi, Reddy, I have some comments to the current version of turn-bis: 1. About Transport protocol "Section 2.1 Transports" describe the reason that use different = transport protocol between TURN Client/TURN Server and TURN Server/Peer. But from = the viewpoint of application, it is very strange that one client use TCP to transport data and the other end use UDP to transport. The common way is = the two peers will select the same protocol to transport data. So, I think = it is better to use the same protocol between the two legs(TURN Client/TURN = Server and TURN Server/Peer). Then the table in section 2.1 should be changed. =20 I do not see any justification for this claim. This is how TURN always = has been working, and it's been working just fine. We do not want to tie = the protocols of different clients. Each client is free to use whatever = protocol it wants and finds appropriate in the client's particular = network conditions. =20 =20 [Aijun Wang]: TURN acts just like one middleware component and should be = called by the application layer. Application will select TCP if they = want the transport layer to assure the data transfer reliability (for = example in file sharing scenario) and will select UDP if they want to = eliminate the transfer delay(for example in video transfer scenario). = Can you give one example that the application wants part of TCP and part = of UDP to transfer data? 2. About EDM NAT transversal between TURN server and peer "Section 2.4 Send Mechanism" describes as below: " When using the Send mechanism, the client sends a Send indication to the TURN server containing (a) an XOR-PEER-ADDRESS attribute specifying the (server-reflexive) transport address of the peer and (b) a DATA attribute holding the application data. When the TURN server receives the Send indication, it extracts the application data from the DATA attribute and sends it in a UDP datagram to the peer, using the allocated relay address as the source address. Note that there is no need to specify the relayed transport address, since it is implied by the 5-tuple used for the Send indication. " If there is one EDM NAT between TURN server and the peer, then the UDP datagram can't pass through it, because the peer did not send packet to = the client's relay address before. Here we should add some descriptions = about how to meet such environments. =20 =20 The peer and the TURN server are supposed to be reachable both ways. If = that is not the case, then the 'peer' has to be a TURN client. [Aijun Wang]: where is the assumption in current draft? In Figure 1 of = current draft, the peer is located behind one NAT device. So your = suppose(=E2=80=9C=E2=80=A6 be reachable both ways=E2=80=A6=E2=80=9D) is = not always true. Even in [RFC6062], there exists the following = description(section 3, Overview of Operation ):=20 =20 =E2=80=9CIf a client wishes to establish a TCP connection to a peer from = that relayed transport address, it issues a Connect request to the TURN server over the control connection. That request contains an XOR- PEER-ADDRESS attribute identifying the peer IP address and port (i.e., its "transport address") to which a connection is to be made. The TURN server attempts to open the TCP connection, and assuming it succeeds, then responds to the Connect request with a success response. The server also creates a connection identifier associated with this connection and passes that connection identifier back to the client in the success response. Note that a maximum of one connection to a given peer transport address can be established per allocation. =20 Note: Establishing a relayed connection from the client to a peer is done in two steps. First, the allocation is created, and second, the connection is established. Combining the two is not desirable for NAT traversal. It is expected that, between the first and second steps, the client will communicate off-band with the peer (e.g., using ICE [RFC5245]) and tell it the relayed transport address that the TURN server allocated and from which it is about to initiate a connection. The peer can then "get ready": open holes in its firewall, try to poke holes in a NAT, attempt a TCP simultaneous open, etc. =E2=80=9D So, this is also one evidence that your assumption is not always true. = For UDP transport, current TURN solution must also consider the involve = of other methods to let the data from TURN server pass the NAT to the = peer. Is this true? 3. Relay between multiple TURN Server As we described in the mail list previously and as proposed by Brandon, = I think we should include the scenarios that encompass two TURN Servers between the client and peer. This scenario need not be very detail, but should clarify some key points that different from the one TURN server scenario. Such as which transport method will be used between the client/TURN Server 1; TURN Server 1/TURN Server 2; TURN Server2/peer; = how to install the permission on different TURN servers and how the client know = the TURN Server 2's address that the peer selects etc. =20 I do not see any sense in that clarification. The scheme is trivial. The = use case of single TURN server is trivially scaled to whatever number of = TURN servers you have. That's only about layers of the TURN protocol. =20 [Aijun Wang]: Current TURN solution can=E2=80=99t assure the = communication peers select the same TURN Server, so this will be very = common phenomena when you deploy the TURN servers in distributed manner. = And it is not as simple as your image of easy scaling. We have discussed = this in the mail list before and it is not easy to illustrate. Can you = simplify the solution that based on the below graph: =20 A------NAT-1(EDM)-----------TURN Server 1-----------------------TURN = Server-2----------------------NAT-2(EDM)---------------------------B | | = |------------------------------------------------------------------------= ----------------NAT-3(EDM)----------------------------C =20 =20 Regards, Oleg ------=_NextPart_000_0089_01D0406F.0F3651B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi, Oleg,

 

=E2=80=9Cdraft-ietf-tram-turnbis-01.txt=E2=80=9D is the update = version of RFC 5766,=C2=A0 and there is no clear description for these = scenarios in both documents.

Can you first answer the questions that I mentioned in these e-mails, = based on the contents of the related RFCs?

 

Best Regards.

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of Oleg = Moskalenko
Sent: Wednesday, February 04, 2015 11:11 = AM
To: Aijun Wang
Cc: tram@ietf.org; Tirumaleswar = Reddy (tireddy); Brandon Williams
Subject: Re: [tram] I-D = Action: = draft-ietf-tram-turnbis-01.txt

 

Aijun, = actually all answers to your questions are in RFC 5766. Sorry but I have = a feeling that you did noy read it. TURN is not what you think it is. = There is no point going into fine details while the whole picture is not = clear to you.

Regards,
Oleg

On Feb 3, 2015 6:41 PM, "Aijun = Wang" <wangaijun@tsinghua.org.cn&g= t; wrote:

 

From:= Oleg = Moskalenko [mailto:mom040267@gmail.com]
Sent: Tuesday, = February 03, 2015 4:51 PM
To: Aijun Wang
Cc: = Tirumaleswar Reddy (tireddy); Brandon Williams; tram@ietf.org
Subject: Re: [tram] I-D = Action: draft-ietf-tram-turnbis-01.txt

 

 

 

On Tue, Feb 3, 2015 at 12:18 AM, Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

Hi, Reddy,

I have some comments to the current = version of turn-bis:
1. About Transport protocol
"Section 2.1 = Transports" describe the reason that use different = transport
protocol between TURN Client/TURN Server and TURN = Server/Peer. But from the
viewpoint of application, it is very = strange that one client use TCP to
transport data and the other end = use UDP to transport. The common way is the
two peers will select the = same protocol to transport data. So, I think it is
better to use the = same protocol between the two legs(TURN Client/TURN Server
and TURN = Server/Peer). Then the table in section 2.1 should be = changed.

 

I do not see any justification for this claim. This is how = TURN always has been working, and it's been working just fine. We do not = want to tie the protocols of different clients. Each client is free to = use whatever protocol it wants and finds appropriate in the client's = particular network conditions.

 

 

[Aijun Wang]: TURN acts just like one middleware component and should = be called by the application layer. Application will select TCP  if = they want the transport layer to assure the data transfer reliability = (for example in file sharing scenario) and will select UDP if they want = to eliminate the transfer delay(for example in video transfer scenario). = Can you give one example that the application wants part of TCP and part = of UDP to transfer data?


2. About EDM NAT transversal between TURN server and = peer
"Section 2.4 Send Mechanism" describes as = below:
" When using the Send mechanism, the client sends a Send = indication to
   the TURN server containing (a) an = XOR-PEER-ADDRESS attribute
   specifying the = (server-reflexive) transport address of the peer and
   (b) = a DATA attribute holding the application data.  When the = TURN
   server receives the Send indication, it extracts = the application data
   from the DATA attribute and sends = it in a UDP datagram to the peer,
   using the allocated = relay address as the source address.  Note that
  =  there is no need to specify the relayed transport address, since = it
   is implied by the 5-tuple used for the Send = indication.
 "
If there is one EDM NAT between TURN = server and the peer, then the UDP
datagram can't pass through it, = because the peer did not send packet to the
client's relay address = before. Here we should add some descriptions about
how to meet such = environments.

 

 

The peer and the TURN server are supposed to be reachable = both ways. If that is not the case, then the 'peer' has to be a TURN = client.


[Aijun Wang]: where is the assumption in current draft? In Figure 1 =
of current draft, the peer is located behind one NAT device. So your =
suppose(=E2=80=9C=E2=80=A6 be reachable both ways=E2=80=A6=E2=80=9D) is =
not always true. Even in [RFC6062], there exists the following =
description(section 3, Overview of Operation ): 
 
=E2=80=9CIf a client wishes to establish a =
TCP connection to a peer from that

   relayed transport address, it issues a Connect = request to the TURN

   server over the control connection.  That = request contains an XOR-

   PEER-ADDRESS attribute identifying the peer IP = address and port

   (i.e., its "transport address") to = which a connection is to be made.

   The TURN server attempts to open the TCP = connection, and assuming it

   succeeds, then = responds to the Connect request with a success

   response.  The server also creates a = connection identifier associated

   with this connection and passes that = connection identifier back to

   the client in the success response.  Note = that a maximum of one

   connection to a given peer transport address = can be established per

   allocation.

 

      Note: Establishing a relayed = connection from the client to a peer

      is done in two steps.  = First, the allocation is created, and

      second, the connection is = established.  Combining the two is not

      desirable for NAT = traversal.  It is expected that, between = the

      first and second = steps, the client will communicate = off-band with

      the peer (e.g., using ICE = [RFC5245]) and tell it the relayed

      transport address that the = TURN server allocated and from which it

      is about to initiate a = connection.  The peer can then "get = ready":

      open holes in its firewall, = try to poke holes in a NAT, attempt a

      TCP simultaneous open, = etc.

=E2=80=9D

So,  this is also one evidence that your assumption is not = always true. For UDP transport, current TURN solution must also consider = the involve of other methods to let the data from TURN server pass the = NAT to the peer. Is this true?


3. Relay between multiple TURN Server
As we = described in the mail list previously and as proposed by Brandon, = I
think we should include the scenarios that encompass two TURN = Servers
between the client and peer. This scenario need not be very = detail, but
should clarify some key points that different from the = one TURN server
scenario. Such as which transport method will be used = between the
client/TURN Server 1; TURN Server 1/TURN Server 2; TURN = Server2/peer; how to
install the permission on different TURN servers = and how the client know the
TURN Server 2's address that the peer = selects etc.

 

I do not see any sense in that clarification. The scheme is = trivial. The use case of single TURN server is trivially scaled to = whatever number of TURN servers you have. That's only about layers of = the TURN protocol.

 

[Aijun Wang]: Current TURN solution can=E2=80=99t assure the = communication peers select the same TURN Server, so this will be very = common phenomena when you deploy the TURN servers in distributed manner. = And it is not as simple as your image of easy scaling. We have discussed = this in the mail list before and it is not easy to illustrate. Can you = simplify the solution that based on the below graph:

 

A------NAT-1(EDM)-----------TURN Server 1-----------------------TURN = Server-2----------------------NAT-2(EDM)---------------------------B

           &nbs= p;            = ;            =         |

           &nbs= p;            =             &= nbsp;       |

           &nbs= p;            = ;            =        =  |------------------------------------------------------------------= ----------------------NAT-3(EDM)----------------------------C

 

 

Regards,
Oleg

------=_NextPart_000_0089_01D0406F.0F3651B0-- From nobody Tue Feb 3 23:31:45 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D7B1A1A88; Tue, 3 Feb 2015 14:09:29 -0800 (PST) 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 VYhXPT7a6_bs; Tue, 3 Feb 2015 14:09:25 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F8C1A036B; Tue, 3 Feb 2015 14:09:25 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id vy18so28774367iec.8; Tue, 03 Feb 2015 14:09:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=TY+QxWFwk24cgxBEfwQ6uHR0vv1YmPVKHJjxWJpqsXY=; b=H0V6YDtptkaeu8Cjb3pta3l84SR8utqLLclK5PyWLrJHAEaIqG+1XzmMmV3i0o2gLu TNREJDOxAJYbzbagrzEppIi/MWyjz8a++xdg1EaWTh3g0+ZhBpqCcDX6/I6kiGh6s+7e cTBZDLqFK70hfHJ/rI3ESv2PIaCr7LAVEmVbG/Q3PKg4aNImLMqBuZ3zZGCzJRt80+je SIkAVte0Z1zqBgy67+qiYnUa65wH/ShcJGh/kqO4bsBazZPYquyl4ViafJv3ec/+X7xR d/RmCQnrGFbGC22rD1audlHLRpda1yQ+ruN8T4eF4czLrDgklYn8DEVrLftLARa/kvFR HIVg== X-Received: by 10.50.66.198 with SMTP id h6mr20957181igt.22.1423001364292; Tue, 03 Feb 2015 14:09:24 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-73-98.tor.primus.ca. [173.206.73.98]) by mx.google.com with ESMTPSA id mi3sm8588159igb.13.2015.02.03.14.09.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Feb 2015 14:09:23 -0800 (PST) Message-ID: <54D14709.2040204@gmail.com> Date: Tue, 03 Feb 2015 17:09:13 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "ops-dir@ietf.org" , Tirumaleswar Reddy , Prashanth Patil , Ram Mohan Ravindranath , Justin Uberti , Gonzalo Camarillo , Spencer Dawkins , The IETF , tram@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 03 Feb 2015 23:31:44 -0800 Cc: Christer Holmberg Subject: [tram] OPS-DIR review of draft-ietf-tram-turn-third-party-authz-08 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, 03 Feb 2015 22:09:30 -0000 I reviewed draft-ietf-tram-turn-third-party-authz-08 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This document has inconsistencies that need to be fixed before it can be published. Operational issues: To make this feature work, the following pre-configuration is required: a. In each authorization server, the list of STUN and TURN servers for which it will grant tokens, and the long-term secret shared with each b. Similarly, in each STUN or TURN server, the list of authorization servers from which the clients of that STUN or TURN server may request tokens, and the associated long-term secret. c. If manual configuration (Section 4.1.3) is used to establish symmetric keys, the necessary information has to be configured on each authorization server and STUN or TURN server. The client presumably obtains the session key and algorithm from the authorization server in company with the token. It would be good to have an Operational Considerations section summarizing this information and anything else I've missed. In terms of deployment, incremental deployment is possible, since default action is specified in the document if either the client or STUN or TURN server fails to understand the attributes defined in this document. However, the implication in "Other Issue" 3 below is that the "should" should be a "MUST". Other issues: 1. The procedures by which the client obtains the OAuth token are declared out of scope (middle of first paragraph of Section 3), yet a fair amount of text in the document deals with this topic. Either the declaration of scope should be changed or the examples of interaction between the client and the authorization server and related detailed procedural statements should be moved to an informative appendix. Fundamentally this document is not about WebRTC (even though that is the primary application the authors have in mind) and so WebRTC has no place in the body of the document. The rewriting would be a fair amount of work, but I will volunteer to help rework the text if need be. 2. The paragraph below Figure 2 in Section 3 talks of a future capability, algorithm agility. Part of the description mentions that the client sends the intersection of the algorithms common to it and the STUN server to the authorization server. The reason to do this depends specifically on the statement that the authorization server generates the session key between the client and resource server in draft-ietf-oauth-pop-key-distribution (which BTW is expired). I can see the point of this paragraph in providing a warning to implementors, but it is probably too speculative unless the depended-upon I-Ds (stunbis and oauth-pop-key) are very close to completion. At the least, the sentence relating to the interaction between the client and authorization server could be removed or made less detailed. (Relates to the first point above.) 3. The first sentence of Section 4 has a lower-case "should". Should this be "SHOULD" or perhaps "MUST"? It would also be good to add that this knowledge of the STUN server's authentication capability may be available prior to the initial request, or else it is acquired from the 401 Unauthorized response to the initial STUN request as described below. Maybe the implementation note under Figure 1 belongs down here, at the more detailed level, rather than in the overview section. 4. The detailed choice of how symmetric key establishment is done is left open in Section 4.1. Should there be a mandatory-to-implement choice? 5. Perhaps in Section 7 there should be a note that if a STUN server receives an ACCESS-TOKEN attribute unexpectedly (because it had not previously sent out a THIRD-PARTY-AUTHORIZATION), it will respond with an error code of 420 (Unknown Attribute) as specified in Section 7.3.1 of RFC 5389. 6. In Section 9, second bullet, a parameter Delta is shown but no suggested value is given. Would this be 5 seconds as in Section 7? Tom Taylor Nits/editorial suggestions ========================== General: missing "the"s and occasional "a"s or "an"s throughout the document. I indicated a number of places but got tired of doing so eventually. If absolutely necessary I could mark up a copy of the document with the additions. 1) Abstract: OLD The usage of ephemeral tokens ensure NEW The use of ephemeral tokens ensures 2) Section 3, first paragraph: It might be good to add a paragraph before the present one, saying that the client knows that it can use OAuth with the target STUN server either through configuration or when it receives the new STUN attribute THIRD-PARTY-AUTHORIZATION in the 401 Unauthorized response to its initial STUN request. OLD to avail STUN services NEW to avail itself of STUN services OLD The client is oblivious to the content of the token. The token is embedded within a STUN request sent to the STUN server. NEW The content of the token is opaque to the client. The client embeds the token within a STUN request sent to the STUN server. Second-last line: s/it's/its/ 3) Section 3, paragraph below Figure 2: Missing "The" in front of "Authorization server" at the beginning of a sentence, missing "the" in front of "client" (twice). Fourth line from the bottom: s/client had provided/the client provided/ 4) Last line of Section 3: OLD MUST be 'stun' string. NEW MUST be the string 'stun'. 5) Section 4, first paragraph: OLD using OAuth access token. NEW using an OAuth access token. OLD The STUN servers NEW The STUN server OLD additional STUN attribute NEW the additional STUN attribute 6) Section 4, paragraph between the two figures 4 and 5: s/i.e/i.e.,/ 7) Section 4.1, first sentence: s/resource server/STUN server/ Middle of paragraph: OLD The AS-RS, AUTH keys NEW The AS-RS and AUTH keys Missing "The" in front of "AS-RS key" in the next sentence. Missing "the" in front of "message integrity" later in that sentence. Second-last sentence: OLD The establishment of symmetric key is outside the scope NEW The procedure for establishment of the symmetric key is outside the scope 8) Sections 4.1.2 and 4.1.3 have missing instances of "the". 9) Section 4.1.3 first paragraph: OLD Mandatory to support authenticated encryption algorithm MUST be AES_256_CBC_HMAC_SHA_512. NEW If manual provisioning is supported, support MUST also be provided for AES_256_CBC_HMAC_SHA_512 as the authenticated encryption algorithm. 10) Section 5, second-last line: s/doesn't/do not/ 11) Section 6.1 third line: s/tie-up/tie-ups/ 12) Section 6.2, first paragraph: OLD of [RFC5389]), access token length NEW of [RFC5389]). The access token length OLD is opaque to the client and it NEW is opaque to the client and the client 13) Section 6.2, 'lifetime' bullet: OLD but the client assumes that NEW but the client would assume that 14) Section 6.2, 'encrypted_block' bullet: s/resource server/STUN server/ 15) Section 9, first bullet: OLD Since the access token is only valid for a specific period of time, NEW Since the access token is valid for a specific period of time, 16) Section 10, first paragraph: OLD detect that the transaction ID as used NEW detect that the transaction ID was used 17) Reference draft-ietf-tram-auth-problems has been published as RFC 7376 and should be updated. Informative references I-D.ietf-oauth-pop-architecture and I-D.ietf-oauth-pop-key-distribution have expired, but I guess there is nothing you can change for the moment. From nobody Wed Feb 4 02:18:50 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52EB1A1A92 for ; Wed, 4 Feb 2015 02:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4MlepYHndB7 for ; Wed, 4 Feb 2015 02:18:41 -0800 (PST) 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 0EB281A1BA9 for ; Wed, 4 Feb 2015 02:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13032; q=dns/txt; s=iport; t=1423045121; x=1424254721; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wcclCh+L9ZwnODlKBTmfDnsr/uWwgdVYUIoUq5BKGRM=; b=X4l6g1Ob/kxcTBK/NIXOZkFZTK/3Bi8RFMYsGHI1ir/X3XaSZVmF/CWF 7SYMFhBjaIb2+cn9fZ1goiFz6Au0D35+9hYHzVPliV0tdt2QbkolMr//o EbBWHSmd6xR1K/mfJ2LLsUMc/UYBkke/w5rl5kiLwXvglG8Tix/IzmN1G k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAA7x0VStJV2a/2dsb2JhbABagwZSWQSCfb8uCoVxAhx3QwEBAQEBfYQMAQEBAwEBAQEgEToLBQsCAQYCEQQBAQECAiMDAgICHwYLFAEICAIECgQFG4d+AwkIDaJUnGyQZg2FawEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGMLYFZAQEcMweCaC6BEwEEhUyHXYFjh2CBRoEXi0uCQIM9IoICHIFQb4ELOX4BAQE X-IronPort-AV: E=Sophos;i="5.09,517,1418083200"; d="scan'208";a="393313317" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 04 Feb 2015 10:18:39 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t14AIcbv026053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Feb 2015 10:18:38 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.166]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 4 Feb 2015 04:18:38 -0600 From: "Pal Martinsen (palmarti)" To: Aijun Wang Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt Thread-Index: AQHQPEw3iE7SBHjBP02Pt2UimDWYDJze//0AgAAJBACAASsYAIAAf8SA Date: Wed, 4 Feb 2015 10:18:38 +0000 Message-ID: <37F58EB6-2CAE-4CA5-B286-D622DC33B139@cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <000001d03f8a$010c89a0$03259ce0$@org.cn> <007401d04024$0ee0d3c0$2ca27b40$@org.cn> In-Reply-To: <007401d04024$0ee0d3c0$2ca27b40$@org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.75] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Oleg Moskalenko , "Tirumaleswar Reddy \(tireddy\)" , Brandon Williams , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 04 Feb 2015 10:18:44 -0000 DQo+IE9uIDA0IEZlYiAyMDE1LCBhdCAwMzo0MSwgQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5n aHVhLm9yZy5jbj4gd3JvdGU6DQo+IA0KPiAgDQo+IEZyb206IE9sZWcgTW9za2FsZW5rbyBbbWFp bHRvOm1vbTA0MDI2N0BnbWFpbC5jb21dIA0KPiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwMywg MjAxNSA0OjUxIFBNDQo+IFRvOiBBaWp1biBXYW5nDQo+IENjOiBUaXJ1bWFsZXN3YXIgUmVkZHkg KHRpcmVkZHkpOyBCcmFuZG9uIFdpbGxpYW1zOyB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDEudHh0DQo+ICAN Cj4gIA0KPiAgDQo+IE9uIFR1ZSwgRmViIDMsIDIwMTUgYXQgMTI6MTggQU0sIEFpanVuIFdhbmcg PHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+IHdyb3RlOg0KPiBIaSwgUmVkZHksDQo+IA0KPiBJ IGhhdmUgc29tZSBjb21tZW50cyB0byB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHR1cm4tYmlzOg0K PiAxLiBBYm91dCBUcmFuc3BvcnQgcHJvdG9jb2wNCj4gIlNlY3Rpb24gMi4xIFRyYW5zcG9ydHMi IGRlc2NyaWJlIHRoZSByZWFzb24gdGhhdCB1c2UgZGlmZmVyZW50IHRyYW5zcG9ydA0KPiBwcm90 b2NvbCBiZXR3ZWVuIFRVUk4gQ2xpZW50L1RVUk4gU2VydmVyIGFuZCBUVVJOIFNlcnZlci9QZWVy LiBCdXQgZnJvbSB0aGUNCj4gdmlld3BvaW50IG9mIGFwcGxpY2F0aW9uLCBpdCBpcyB2ZXJ5IHN0 cmFuZ2UgdGhhdCBvbmUgY2xpZW50IHVzZSBUQ1AgdG8NCj4gdHJhbnNwb3J0IGRhdGEgYW5kIHRo ZSBvdGhlciBlbmQgdXNlIFVEUCB0byB0cmFuc3BvcnQuIFRoZSBjb21tb24gd2F5IGlzIHRoZQ0K PiB0d28gcGVlcnMgd2lsbCBzZWxlY3QgdGhlIHNhbWUgcHJvdG9jb2wgdG8gdHJhbnNwb3J0IGRh dGEuIFNvLCBJIHRoaW5rIGl0IGlzDQo+IGJldHRlciB0byB1c2UgdGhlIHNhbWUgcHJvdG9jb2wg YmV0d2VlbiB0aGUgdHdvIGxlZ3MoVFVSTiBDbGllbnQvVFVSTiBTZXJ2ZXINCj4gYW5kIFRVUk4g U2VydmVyL1BlZXIpLiBUaGVuIHRoZSB0YWJsZSBpbiBzZWN0aW9uIDIuMSBzaG91bGQgYmUgY2hh bmdlZC4NCj4gIA0KPiANCj4gSSBkbyBub3Qgc2VlIGFueSBqdXN0aWZpY2F0aW9uIGZvciB0aGlz IGNsYWltLiBUaGlzIGlzIGhvdyBUVVJOIGFsd2F5cyBoYXMgYmVlbiB3b3JraW5nLCBhbmQgaXQn cyBiZWVuIHdvcmtpbmcganVzdCBmaW5lLiBXZSBkbyBub3Qgd2FudCB0byB0aWUgdGhlIHByb3Rv Y29scyBvZiBkaWZmZXJlbnQgY2xpZW50cy4gRWFjaCBjbGllbnQgaXMgZnJlZSB0byB1c2Ugd2hh dGV2ZXIgcHJvdG9jb2wgaXQgd2FudHMgYW5kIGZpbmRzIGFwcHJvcHJpYXRlIGluIHRoZSBjbGll bnQncyBwYXJ0aWN1bGFyIG5ldHdvcmsgY29uZGl0aW9ucy4NCj4gIA0KPiAgDQo+IFtBaWp1biBX YW5nXTogVFVSTiBhY3RzIGp1c3QgbGlrZSBvbmUgbWlkZGxld2FyZSBjb21wb25lbnQgYW5kIHNo b3VsZCBiZSBjYWxsZWQgYnkgdGhlIGFwcGxpY2F0aW9uIGxheWVyLiBBcHBsaWNhdGlvbiB3aWxs IHNlbGVjdCBUQ1AgIGlmIHRoZXkgd2FudCB0aGUgdHJhbnNwb3J0IGxheWVyIHRvIGFzc3VyZSB0 aGUgZGF0YSB0cmFuc2ZlciByZWxpYWJpbGl0eSAoZm9yIGV4YW1wbGUgaW4gZmlsZSBzaGFyaW5n IHNjZW5hcmlvKSBhbmQgd2lsbCBzZWxlY3QgVURQIGlmIHRoZXkgd2FudCB0byBlbGltaW5hdGUg dGhlIHRyYW5zZmVyIGRlbGF5KGZvciBleGFtcGxlIGluIHZpZGVvIHRyYW5zZmVyIHNjZW5hcmlv KS4gQ2FuIHlvdSBnaXZlIG9uZSBleGFtcGxlIHRoYXQgdGhlIGFwcGxpY2F0aW9uIHdhbnRzIHBh cnQgb2YgVENQIGFuZCBwYXJ0IG9mIFVEUCB0byB0cmFuc2ZlciBkYXRhPw0KDQpMb2NhbCBmaXJl d2FsbCB0cmF2ZXJzYWwhDQoNClZlcnkgY29udmVuaWVudCB0byBoYXZlIFRDUC9UTFMgYmV0d2Vl biB5b3UgYW5kIHlvdXIgVFVSTiBzZXJ2ZXIgdG8gZ2V0IHRocm91Z2ggc3R1YmJvcm4gZmlyZXdh bGxzLiBMaWtld2lzZSBpdCBpcyB2ZXJ5IGNvbnZlbmllbnQgdG8gc3RpbGwgYmUgYWJsZSB0byB0 YWxrIHRvIHRoZSByZW1vdGUgaG9zdCBvbiBVRFAuIFRoZSByZW1vdGUgaG9zdCBjYW4gYmUgYSBS RkxYIGFkZHJlc3Mgb2YgYW4gSUNFIGFnZW50LCBhIGxlZ2FjeSBTSVAgZW5kcG9pbnQgd2l0aCBh IHJlYWNoYWJsZSBJUCBhbmQgc28gb24uIA0KDQo+PiANCj4+IDIuIEFib3V0IEVETSBOQVQgdHJh bnN2ZXJzYWwgYmV0d2VlbiBUVVJOIHNlcnZlciBhbmQgcGVlcg0KPj4gIlNlY3Rpb24gMi40IFNl bmQgTWVjaGFuaXNtIiBkZXNjcmliZXMgYXMgYmVsb3c6DQo+PiAiIFdoZW4gdXNpbmcgdGhlIFNl bmQgbWVjaGFuaXNtLCB0aGUgY2xpZW50IHNlbmRzIGEgU2VuZCBpbmRpY2F0aW9uIHRvDQo+PiAg ICB0aGUgVFVSTiBzZXJ2ZXIgY29udGFpbmluZyAoYSkgYW4gWE9SLVBFRVItQUREUkVTUyBhdHRy aWJ1dGUNCj4+ICAgIHNwZWNpZnlpbmcgdGhlIChzZXJ2ZXItcmVmbGV4aXZlKSB0cmFuc3BvcnQg YWRkcmVzcyBvZiB0aGUgcGVlciBhbmQNCj4+ICAgIChiKSBhIERBVEEgYXR0cmlidXRlIGhvbGRp bmcgdGhlIGFwcGxpY2F0aW9uIGRhdGEuICBXaGVuIHRoZSBUVVJODQo+PiAgICBzZXJ2ZXIgcmVj ZWl2ZXMgdGhlIFNlbmQgaW5kaWNhdGlvbiwgaXQgZXh0cmFjdHMgdGhlIGFwcGxpY2F0aW9uIGRh dGENCj4+ICAgIGZyb20gdGhlIERBVEEgYXR0cmlidXRlIGFuZCBzZW5kcyBpdCBpbiBhIFVEUCBk YXRhZ3JhbSB0byB0aGUgcGVlciwNCj4+ICAgIHVzaW5nIHRoZSBhbGxvY2F0ZWQgcmVsYXkgYWRk cmVzcyBhcyB0aGUgc291cmNlIGFkZHJlc3MuICBOb3RlIHRoYXQNCj4+ICAgIHRoZXJlIGlzIG5v IG5lZWQgdG8gc3BlY2lmeSB0aGUgcmVsYXllZCB0cmFuc3BvcnQgYWRkcmVzcywgc2luY2UgaXQN Cj4+ICAgIGlzIGltcGxpZWQgYnkgdGhlIDUtdHVwbGUgdXNlZCBmb3IgdGhlIFNlbmQgaW5kaWNh dGlvbi4NCj4+ICAiDQo+PiBJZiB0aGVyZSBpcyBvbmUgRURNIE5BVCBiZXR3ZWVuIFRVUk4gc2Vy dmVyIGFuZCB0aGUgcGVlciwgdGhlbiB0aGUgVURQDQo+PiBkYXRhZ3JhbSBjYW4ndCBwYXNzIHRo cm91Z2ggaXQsIGJlY2F1c2UgdGhlIHBlZXIgZGlkIG5vdCBzZW5kIHBhY2tldCB0byB0aGUNCj4+ IGNsaWVudCdzIHJlbGF5IGFkZHJlc3MgYmVmb3JlLiBIZXJlIHdlIHNob3VsZCBhZGQgc29tZSBk ZXNjcmlwdGlvbnMgYWJvdXQNCj4+IGhvdyB0byBtZWV0IHN1Y2ggZW52aXJvbm1lbnRzLg0KPiAg DQo+ICANCj4gVGhlIHBlZXIgYW5kIHRoZSBUVVJOIHNlcnZlciBhcmUgc3VwcG9zZWQgdG8gYmUg cmVhY2hhYmxlIGJvdGggd2F5cy4gSWYgdGhhdCBpcyBub3QgdGhlIGNhc2UsIHRoZW4gdGhlICdw ZWVyJyBoYXMgdG8gYmUgYSBUVVJOIGNsaWVudC4NCj4gDQo+IFtBaWp1biBXYW5nXTogd2hlcmUg aXMgdGhlIGFzc3VtcHRpb24gaW4gY3VycmVudCBkcmFmdD8gSW4gRmlndXJlIDEgb2YgY3VycmVu dCBkcmFmdCwgdGhlIHBlZXIgaXMgbG9jYXRlZCBiZWhpbmQgb25lIE5BVCBkZXZpY2UuIFNvIHlv dXIgc3VwcG9zZSjigJzigKYgYmUgcmVhY2hhYmxlIGJvdGggd2F5c+KApuKAnSkgaXMgbm90IGFs d2F5cyB0cnVlLiBFdmVuIGluIFtSRkM2MDYyXSwgdGhlcmUgZXhpc3RzIHRoZSBmb2xsb3dpbmcg ZGVzY3JpcHRpb24oc2VjdGlvbiAzLCBPdmVydmlldyBvZiBPcGVyYXRpb24gKTogDQo+ICANCg0K SSB0aGluayBpdCBpcyBwcmV0dHkgY2xlYXIgZnJvbSB0aGUgSW50cm9kdWN0aW9uOg0KDQoiV2hl biBhIGRpcmVjdCBjb21tdW5pY2F0aW9uIHBhdGggY2Fubm90IGJlIGZvdW5kLCBpdCBpcyBuZWNl c3NhcnkgdG8NCiB1c2UgdGhlIHNlcnZpY2VzIG9mIGFuIGludGVybWVkaWF0ZSBob3N0IHRoYXQg YWN0cyBhcyBhIHJlbGF5IGZvciB0aGUNCiBwYWNrZXRzLiAgVGhpcyByZWxheSB0eXBpY2FsbHkg c2l0cyBpbiB0aGUgcHVibGljIEludGVybmV0IGFuZCByZWxheXMNCiBwYWNrZXRzIGJldHdlZW4g dHdvIGhvc3RzIHRoYXQgYm90aCBzaXQgYmVoaW5kIE5BVHMu4oCdDQoNCk9yIGlzIGl0IHRoZSBh Ym92ZSB0ZXh0IHRoYXQgY2F1c2VzIGNvbmZ1c2lvbj8gSSB0aGluayBpdCBjb3VsZCBiZSBhIGJp dCBtb3JlIGV4cGxpY2l0IGluIHRoYXQgaXQgaXMgbm90IG5lY3Nlc3NhcnkgZm9yIGJvdGggY2xp ZW50IHRvIGFsbG9jYXRlIHRoZWlyIFJFTEFZIGFkZHJlc3Mgb24gdGhlIHNhbWUgVFVSTiBzZXJ2 ZXIuIEJ1dCB0aGF0IGlzIGZhaXJseSBnb29kIGV4cGxhaW5lZCBsYXRlci4NCg0KSW4gdGhlIG9w ZXJhdGlvbiBzZWN0aW9uIGl0IGFsc28gc3RhdGVzOg0KIkluIGEgdHlwaWNhbCBjb25maWd1cmF0 aW9uLCBhIFRVUk4gY2xpZW50IGlzIGNvbm5lY3RlZCB0byBhIHByaXZhdGUNCiAgIG5ldHdvcmsg W1JGQzE5MThdIGFuZCB0aHJvdWdoIG9uZSBvciBtb3JlIE5BVHMgdG8gdGhlIHB1YmxpYw0KICAg SW50ZXJuZXQuICBPbiB0aGUgcHVibGljIEludGVybmV0IGlzIGEgVFVSTiBzZXJ2ZXIuICBFbHNl d2hlcmUgaW4gdGhlDQogICBJbnRlcm5ldCBhcmUgb25lIG9yIG1vcmUgcGVlcnMgd2l0aCB3aGlj aCB0aGUgVFVSTiBjbGllbnQgd2lzaGVzIHRvDQogICBjb21tdW5pY2F0ZS4gIFRoZXNlIHBlZXJz IG1heSBvciBtYXkgbm90IGJlIGJlaGluZCBvbmUgb3IgbW9yZSBOQVRzLg0KICAgVGhlIGNsaWVu dCB1c2VzIHRoZSBzZXJ2ZXIgYXMgYSByZWxheSB0byBzZW5kIHBhY2tldHMgdG8gdGhlc2UgcGVl cnMNCiAgIGFuZCB0byByZWNlaXZlIHBhY2tldHMgZnJvbSB0aGVzZSBwZWVycy4NCuKAnA0KDQpJ IGRvIG5vdCBzZWUgaG93IHRoZSBhYm92ZSB0ZXh0IGNhbiBiZSBtaXN1bmRlcnN0b29kLiANCg0K PiDigJxJZiBhIGNsaWVudCB3aXNoZXMgdG8gZXN0YWJsaXNoIGEgVENQIGNvbm5lY3Rpb24gdG8g YSBwZWVyIGZyb20gdGhhdA0KPiAgICByZWxheWVkIHRyYW5zcG9ydCBhZGRyZXNzLCBpdCBpc3N1 ZXMgYSBDb25uZWN0IHJlcXVlc3QgdG8gdGhlIFRVUk4NCj4gICAgc2VydmVyIG92ZXIgdGhlIGNv bnRyb2wgY29ubmVjdGlvbi4gIFRoYXQgcmVxdWVzdCBjb250YWlucyBhbiBYT1ItDQo+ICAgIFBF RVItQUREUkVTUyBhdHRyaWJ1dGUgaWRlbnRpZnlpbmcgdGhlIHBlZXIgSVAgYWRkcmVzcyBhbmQg cG9ydA0KPiAgICAoaS5lLiwgaXRzICJ0cmFuc3BvcnQgYWRkcmVzcyIpIHRvIHdoaWNoIGEgY29u bmVjdGlvbiBpcyB0byBiZSBtYWRlLg0KPiAgICBUaGUgVFVSTiBzZXJ2ZXIgYXR0ZW1wdHMgdG8g b3BlbiB0aGUgVENQIGNvbm5lY3Rpb24sIGFuZCBhc3N1bWluZyBpdA0KPiAgICBzdWNjZWVkcywg dGhlbiByZXNwb25kcyB0byB0aGUgQ29ubmVjdCByZXF1ZXN0IHdpdGggYSBzdWNjZXNzDQo+ICAg IHJlc3BvbnNlLiAgVGhlIHNlcnZlciBhbHNvIGNyZWF0ZXMgYSBjb25uZWN0aW9uIGlkZW50aWZp ZXIgYXNzb2NpYXRlZA0KPiAgICB3aXRoIHRoaXMgY29ubmVjdGlvbiBhbmQgcGFzc2VzIHRoYXQg Y29ubmVjdGlvbiBpZGVudGlmaWVyIGJhY2sgdG8NCj4gICAgdGhlIGNsaWVudCBpbiB0aGUgc3Vj Y2VzcyByZXNwb25zZS4gIE5vdGUgdGhhdCBhIG1heGltdW0gb2Ygb25lDQo+ICAgIGNvbm5lY3Rp b24gdG8gYSBnaXZlbiBwZWVyIHRyYW5zcG9ydCBhZGRyZXNzIGNhbiBiZSBlc3RhYmxpc2hlZCBw ZXINCj4gICAgYWxsb2NhdGlvbi4NCj4gIA0KPiAgICAgICBOb3RlOiBFc3RhYmxpc2hpbmcgYSBy ZWxheWVkIGNvbm5lY3Rpb24gZnJvbSB0aGUgY2xpZW50IHRvIGEgcGVlcg0KPiAgICAgICBpcyBk b25lIGluIHR3byBzdGVwcy4gIEZpcnN0LCB0aGUgYWxsb2NhdGlvbiBpcyBjcmVhdGVkLCBhbmQN Cj4gICAgICAgc2Vjb25kLCB0aGUgY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZC4gIENvbWJpbmlu ZyB0aGUgdHdvIGlzIG5vdA0KPiAgICAgICBkZXNpcmFibGUgZm9yIE5BVCB0cmF2ZXJzYWwuICBJ dCBpcyBleHBlY3RlZCB0aGF0LCBiZXR3ZWVuIHRoZQ0KPiAgICAgICBmaXJzdCBhbmQgc2Vjb25k IHN0ZXBzLCB0aGUgY2xpZW50IHdpbGwgY29tbXVuaWNhdGUgb2ZmLWJhbmQgd2l0aA0KPiAgICAg ICB0aGUgcGVlciAoZS5nLiwgdXNpbmcgSUNFIFtSRkM1MjQ1XSkgYW5kIHRlbGwgaXQgdGhlIHJl bGF5ZWQNCj4gICAgICAgdHJhbnNwb3J0IGFkZHJlc3MgdGhhdCB0aGUgVFVSTiBzZXJ2ZXIgYWxs b2NhdGVkIGFuZCBmcm9tIHdoaWNoIGl0DQo+ICAgICAgIGlzIGFib3V0IHRvIGluaXRpYXRlIGEg Y29ubmVjdGlvbi4gIFRoZSBwZWVyIGNhbiB0aGVuICJnZXQgcmVhZHkiOg0KPiAgICAgICBvcGVu IGhvbGVzIGluIGl0cyBmaXJld2FsbCwgdHJ5IHRvIHBva2UgaG9sZXMgaW4gYSBOQVQsIGF0dGVt cHQgYQ0KPiAgICAgICBUQ1Agc2ltdWx0YW5lb3VzIG9wZW4sIGV0Yy4NCj4g4oCdDQo+IA0KPiBT bywgIHRoaXMgaXMgYWxzbyBvbmUgZXZpZGVuY2UgdGhhdCB5b3VyIGFzc3VtcHRpb24gaXMgbm90 IGFsd2F5cyB0cnVlLiBGb3IgVURQIHRyYW5zcG9ydCwgY3VycmVudCBUVVJOIHNvbHV0aW9uIG11 c3QgYWxzbyBjb25zaWRlciB0aGUgaW52b2x2ZSBvZiBvdGhlciBtZXRob2RzIHRvIGxldCB0aGUg ZGF0YSBmcm9tIFRVUk4gc2VydmVyIHBhc3MgdGhlIE5BVCB0byB0aGUgcGVlci4gSXMgdGhpcyB0 cnVlPw0KDQpJIHRoaW5rIHlvdSBzaG91bGQgZm9sbG93IHRoZSBhZHZpY2UgZnJvbSB0aGUgSW50 cm9kdWN0aW9uOg0KIlRVUk4gd2FzIGRlc2lnbmVkIGFzIG9uZSBwaWVjZSBpbiB0aGUgbGFyZ2Vy IElDRSBhcHByb2FjaCB0byBOQVQNCiB0cmF2ZXJzYWwuICBJbXBsZW1lbnRvcnMgb2YgVFVSTiBh cmUgdXJnZWQgdG8gaW52ZXN0aWdhdGUgSUNFIGFuZA0KIHNlcmlvdXNseSBjb25zaWRlciB1c2lu ZyBpdCBmb3IgdGhlaXIgYXBwbGljYXRpb24uICBIb3dldmVyLCBpdCBpcw0KIHBvc3NpYmxlIHRv IHVzZSBUVVJOIHdpdGhvdXQgSUNFLuKAnQ0KDQoNCkl0IGlzIHBvc3NpYmxlIHRvIGRlcGxveSBU VVJOIHNlcnZlcnMgaW4gYSB3YXkgdGhhdCB3b3VsZCBub3Qgd29yay4gVGhpcyBpcyBiZWNhdXNl IHRoZSBzcGVjcyB3YXMgd3JpdHRlbiBpbiBhIG5vbiBsaW1pdGluZyB3YXkgdG8gYWxsb3cgZm9y IHdoYXQgZXZlciBkZXBsb3ltZW50IHNjZW5hcmlvcyB0aGF0IG1pZ2h0IGJlIHVzZWZ1bCB0byBk aWZmZXJlbnQgaW1wbGVtZW50b3JzLiBCdXQgSSB0aGluayBpdCBpcyBhbHNvIGRlc2NyaWJlZCBo b3cgdG8gZGVwbG95IGl0IGluIGEgd2F5IHRoYXQgYWN0dWFsbHkgd29ya3MuDQoNCj4+IA0KPj4g My4gUmVsYXkgYmV0d2VlbiBtdWx0aXBsZSBUVVJOIFNlcnZlcg0KPj4gQXMgd2UgZGVzY3JpYmVk IGluIHRoZSBtYWlsIGxpc3QgcHJldmlvdXNseSBhbmQgYXMgcHJvcG9zZWQgYnkgQnJhbmRvbiwg SQ0KPj4gdGhpbmsgd2Ugc2hvdWxkIGluY2x1ZGUgdGhlIHNjZW5hcmlvcyB0aGF0IGVuY29tcGFz cyB0d28gVFVSTiBTZXJ2ZXJzDQo+PiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHBlZXIuIFRoaXMg c2NlbmFyaW8gbmVlZCBub3QgYmUgdmVyeSBkZXRhaWwsIGJ1dA0KPj4gc2hvdWxkIGNsYXJpZnkg c29tZSBrZXkgcG9pbnRzIHRoYXQgZGlmZmVyZW50IGZyb20gdGhlIG9uZSBUVVJOIHNlcnZlcg0K Pj4gc2NlbmFyaW8uIFN1Y2ggYXMgd2hpY2ggdHJhbnNwb3J0IG1ldGhvZCB3aWxsIGJlIHVzZWQg YmV0d2VlbiB0aGUNCj4+IGNsaWVudC9UVVJOIFNlcnZlciAxOyBUVVJOIFNlcnZlciAxL1RVUk4g U2VydmVyIDI7IFRVUk4gU2VydmVyMi9wZWVyOyBob3cgdG8NCj4+IGluc3RhbGwgdGhlIHBlcm1p c3Npb24gb24gZGlmZmVyZW50IFRVUk4gc2VydmVycyBhbmQgaG93IHRoZSBjbGllbnQga25vdyB0 aGUNCj4+IFRVUk4gU2VydmVyIDIncyBhZGRyZXNzIHRoYXQgdGhlIHBlZXIgc2VsZWN0cyBldGMu DQo+ICANCj4gSSBkbyBub3Qgc2VlIGFueSBzZW5zZSBpbiB0aGF0IGNsYXJpZmljYXRpb24uIFRo ZSBzY2hlbWUgaXMgdHJpdmlhbC4gVGhlIHVzZSBjYXNlIG9mIHNpbmdsZSBUVVJOIHNlcnZlciBp cyB0cml2aWFsbHkgc2NhbGVkIHRvIHdoYXRldmVyIG51bWJlciBvZiBUVVJOIHNlcnZlcnMgeW91 IGhhdmUuIFRoYXQncyBvbmx5IGFib3V0IGxheWVycyBvZiB0aGUgVFVSTiBwcm90b2NvbC4NCj4g IA0KPiBbQWlqdW4gV2FuZ106IEN1cnJlbnQgVFVSTiBzb2x1dGlvbiBjYW7igJl0IGFzc3VyZSB0 aGUgY29tbXVuaWNhdGlvbiBwZWVycyBzZWxlY3QgdGhlIHNhbWUgVFVSTiBTZXJ2ZXIsIHNvIHRo aXMgd2lsbCBiZSB2ZXJ5IGNvbW1vbiBwaGVub21lbmEgd2hlbiB5b3UgZGVwbG95IHRoZSBUVVJO IHNlcnZlcnMgaW4gZGlzdHJpYnV0ZWQgbWFubmVyLiBBbmQgaXQgaXMgbm90IGFzIHNpbXBsZSBh cyB5b3VyIGltYWdlIG9mIGVhc3kgc2NhbGluZy4gV2UgaGF2ZSBkaXNjdXNzZWQgdGhpcyBpbiB0 aGUgbWFpbCBsaXN0IGJlZm9yZSBhbmQgaXQgaXMgbm90IGVhc3kgdG8gaWxsdXN0cmF0ZS4gQ2Fu IHlvdSBzaW1wbGlmeSB0aGUgc29sdXRpb24gdGhhdCBiYXNlZCBvbiB0aGUgYmVsb3cgZ3JhcGg6 DQo+ICANCj4gQS0tLS0tLU5BVC0xKEVETSktLS0tLS0tLS0tLVRVUk4gU2VydmVyIDEtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLVRVUk4gU2VydmVyLTItLS0tLS0tLS0tLS0tLS0tLS0tLS0tTkFULTIo RURNKS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUINCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHzigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJROQVQtMyhFRE0pLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLUMNCg0KUmVsYXlpbmcgYmV0d2VlbiBzZXZlcmFsIFRVUk4gc2VydmVycyBzaG91bGQg bm90IGJlIGEgcGFydCBvZiB0aGUgVFVSTiBSRkMuIEhvdyB0byBpbnN0YWxsIHBlcm1pc3Npb25z IGFuZCBzbyBvbiBpcyBkZXNjcmliZWQgaW4gdGhlIElDRSBSRkMuDQoNClRvIHN1bW1hcmlzZS4g RWFjaCBhZ2VudCBoYXMgYSByZXNwb25zaWJpbGl0eSB0byBnZXQgdGhyb3VnaCB0aGVpciBvd24g TkFULiBJZiBpdCBpcyBhIHJlc3RyaWN0aXZlIG9uZSBpdCBzaG91bGQgdXNlIFRVUk4gdG8gZ2V0 IHRocm91Z2ggaXQuIFdoYXQgdGhlIHJlbW90ZSBzaWRlIGlzIGRvaW5nIHRvIGdldCB0aHJvdWdo IGhpcyBvciBoZXIgTkFUIGlzIG5vdCB5b3VyIHByb2JsZW0uDQoNCi4tLg0KUMOlbC1FcmlrDQoN Cj4gIA0KPiAgDQo+IFJlZ2FyZHMsDQo+IE9sZWcNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRyYW0gbWFpbGluZyBsaXN0DQo+IHRyYW1A aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoN Cg== From nobody Wed Feb 4 07:25:33 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4B61A8AB2 for ; Wed, 4 Feb 2015 07:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TBjYbps4S2U for ; Wed, 4 Feb 2015 07:25:24 -0800 (PST) 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 675B21A8A4C for ; Wed, 4 Feb 2015 07:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2332; q=dns/txt; s=iport; t=1423063524; x=1424273124; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=GiBcZLMQoPqHGzYgvh8QGIEbE/3NiHe4ri6i4J1DKdA=; b=J9mz78y3kJ4nKCPc1JVZl9k6N5z0oM44dk7+I9n0bpW5Y2IlHtjud8cR vG4AeeDEZnE5F82xg43eKsaesbhmRIuG3GlbPo2HpZ0mdGNo7k8LQ58MN XDNX6Eslo6rrbZmxUAVcE7wGcUYTfYPKCURVRCH8mBIUgS24SmdoeA3o6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DGBQDxONJU/5RdJa1agwZSWQSCfb0XgieFbwIcfEMBAQEBAX2EDAEBAQQjEUMOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQTCAGIJA3AHJZZAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhjiY4BoJiLoETBY8Qg1CGcDaCTY5JIoNubwGBQ34BAQE X-IronPort-AV: E=Sophos;i="5.09,518,1418083200"; d="scan'208";a="120487292" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP; 04 Feb 2015 15:25:23 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t14FPNMR017369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 4 Feb 2015 15:25:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 4 Feb 2015 09:25:23 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt Thread-Index: AQHQQI6WdUQVEuPT30i8U4lnHv84fZzgnDZw Date: Wed, 4 Feb 2015 15:25:21 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> In-Reply-To: <20150204152347.30593.20532.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.54.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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, 04 Feb 2015 15:25:31 -0000 VGhpcyBkcmFmdCBkZXNjcmliZXMgYSBtZWFucyBmb3IgYW4gY2xpZW50IHRvIGRpc2NvdmVyIHRo YXQgdGhlIFRVUk4gc2VydmVyIGNhbiBwcm92aWRlIElQIGFkZHJlc3MgcHJpdmFjeS4NCkNvbW1l bnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCg0KLVRpcnUNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA0LCAy MDE1IDg6NTQgUE0NClRvOiBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgUHJhc2hhbnRo IFBhdGlsIChwcmFzcGF0aSkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2YWN5LTAwLnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3kt MDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBS ZWRkeSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1y ZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3kNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlJ UCBhZGRyZXNzIHByaXZhY3kgYnkgVFVSTiBzZXJ2ZXINCkRvY3VtZW50IGRhdGU6CTIwMTUtMDIt MDQNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTYNClVSTDogICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRkeS10cmFt LXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1w cml2YWN5Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXJlZGR5LXRyYW0tdHVybi1pcGFkZHJlc3MtcHJpdmFjeS0wMA0KDQoNCkFic3RyYWN0Og0KICAg QSBUVVJOIHNlcnZlciBhbGxvY2F0ZXMgYW4gSVAgYWRkcmVzcyBmb3IgYSB1c2VyLiAgSWYgdGhp cyBhZGRyZXNzIGlzDQogICBkaXMtYXNzb2NpYXRlZCBmcm9tIHRoZSB1c2VyJ3MgYWN0dWFsIG5l dHdvcmssIHRoZSBhbGxvY2F0ZWQgSVANCiAgIGFkZHJlc3MgaW5jcmVhc2VzIHRoZSB1c2VyJ3Mg cHJpdmFjeS4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGENCiAgIG1lYW5zIGZvciBhbiBjbGll bnQgdG8gZGlzY292ZXIgdGhhdCB0aGUgVFVSTiBzZXJ2ZXIgY2FuIHByb3ZpZGUgSVANCiAgIGFk ZHJlc3MgcHJpdmFjeS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Wed Feb 4 07:42:34 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D5D1A19F7 for ; Wed, 4 Feb 2015 07:42:33 -0800 (PST) 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 rf033chEhZGB for ; Wed, 4 Feb 2015 07:42:25 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107BC1A8A61 for ; Wed, 4 Feb 2015 07:42:22 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id pn19so2271953lab.2 for ; Wed, 04 Feb 2015 07:42:20 -0800 (PST) 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=YRJ8nfKW7dsZsCNcGsGAZNRXOBVIPU4xoKCP41GYObE=; b=K8CC//0BxP2BSP2UNbeey2s2TngjkOVNP5otgEfWo4UOgA6NFTvmTuyF6v0mHLI0P1 9ZOz6Gt3zgHMr8Z1+yo7MpRVWj3VlB2HMo+5F8xGm+Bj3mmkUnXMWq4/UeE7MvEIdZum jUjRQ0mzkl4C8otYQlSH4OAuA25TNq7XFFr0q/FyrxFsD5X71ek8kcVUULSKmmD5GYQT uLAjnQdeJr7uB6G8tvDk0Jqc5x4+RlQoJGLwMWKoxiXqQY5PeFthQ6WOxTjdiTYi0WuS U1d7xpqoqoe5b2o5ruGWIcmCbq/s8doBMQR63MaUdu1hFru4wS4gPGkYIDktvVFZ1T3O EARA== X-Gm-Message-State: ALoCoQmYfYAZidQEabPW5DCI5AfMD49ubE/eMbyVrRcerKN/DVr3SI9yASHbTlosBiFEULUSyYfa MIME-Version: 1.0 X-Received: by 10.112.122.52 with SMTP id lp20mr3900841lbb.98.1423064540356; Wed, 04 Feb 2015 07:42:20 -0800 (PST) Received: by 10.25.205.135 with HTTP; Wed, 4 Feb 2015 07:42:20 -0800 (PST) Received: by 10.25.205.135 with HTTP; Wed, 4 Feb 2015 07:42:20 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> Date: Wed, 4 Feb 2015 08:42:20 -0700 Message-ID: From: Simon Perreault To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7bb043406bbcac050e450883 Archived-At: Cc: tram@ietf.org Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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, 04 Feb 2015 15:42:33 -0000 --047d7bb043406bbcac050e450883 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for writing this. After a quick read, I am skeptical. I doubt any client would trust any assertion from an a priori unknown TURN server about its available privacy capabilities. Instead, why can't the client simply request an allocation, perhaps indicating its desire that the relayed address be "far" from its own with a new optional attribute, and then accept or reject the allocation using its own good judgment? Simon Le 2015-02-04 08:25, "Tirumaleswar Reddy (tireddy)" a =C3=A9crit : > This draft describes a means for an client to discover that the TURN > server can provide IP address privacy. > Comments and suggestions are welcome. > > -Tiru > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, February 04, 2015 8:54 PM > To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Tirumaleswa= r > Reddy (tireddy); Prashanth Patil (praspati) > Subject: New Version Notification for > draft-reddy-tram-turn-ipaddress-privacy-00.txt > > > A new version of I-D, draft-reddy-tram-turn-ipaddress-privacy-00.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the > IETF repository. > > Name: draft-reddy-tram-turn-ipaddress-privacy > Revision: 00 > Title: IP address privacy by TURN server > Document date: 2015-02-04 > Group: Individual Submission > Pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-ipaddress-priva= cy-00.txt > Status: > https://datatracker.ietf.org/doc/draft-reddy-tram-turn-ipaddress-privacy/ > Htmlized: > http://tools.ietf.org/html/draft-reddy-tram-turn-ipaddress-privacy-00 > > > Abstract: > A TURN server allocates an IP address for a user. If this address is > dis-associated from the user's actual network, the allocated IP > address increases the user's privacy. This document describes a > means for an client to discover that the TURN server can provide IP > address privacy. > > > > > 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 > --047d7bb043406bbcac050e450883 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks for writing this.

After a quick read, I am skeptical. I doubt any client would= trust any assertion from an a priori unknown TURN server about its availab= le privacy capabilities.

Instead, why can't the client simply request an allocati= on, perhaps indicating its desire that the relayed address be "far&quo= t; from its own with a new optional attribute, and then accept or reject th= e allocation using its own good judgment?

Simon

Le 2015-02-04 08:25, "Tirumaleswar Reddy (t= ireddy)" <tireddy@cisco.com> a =C3=A9crit :
This draft describes a means for an client to discover that the TURN serve= r can provide IP address privacy.
Comments and suggestions are welcome.

-Tiru

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Wednesday, February 04, 2015 8:54 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Tirumaleswar = Reddy (tireddy); Prashanth Patil (praspati)
Subject: New Version Notification for draft-reddy-tram-turn-ipaddress-priva= cy-00.txt


A new version of I-D, draft-reddy-tram-turn-ipaddress-privacy-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-reddy-tram-turn-ipaddre= ss-privacy
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IP address privacy by TURN server<= br> Document date:=C2=A0 2015-02-04
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-ipaddres= s-privacy-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/draft-reddy-tram-turn-ipaddress-privacy/ Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.i= etf.org/html/draft-reddy-tram-turn-ipaddress-privacy-00


Abstract:
=C2=A0 =C2=A0A TURN server allocates an IP address for a user.=C2=A0 If thi= s address is
=C2=A0 =C2=A0dis-associated from the user's actual network, the allocat= ed IP
=C2=A0 =C2=A0address increases the user's privacy.=C2=A0 This document = describes a
=C2=A0 =C2=A0means for an client to discover that the TURN server can provi= de IP
=C2=A0 =C2=A0address privacy.




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

The IETF Secretariat

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram
--047d7bb043406bbcac050e450883-- From nobody Wed Feb 4 07:45:56 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981A21A8AAC for ; Wed, 4 Feb 2015 07:45:52 -0800 (PST) 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 YOAym969oJnf for ; Wed, 4 Feb 2015 07:45:47 -0800 (PST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5A31A8AAB for ; Wed, 4 Feb 2015 07:45:46 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id hy4so741996vcb.8 for ; Wed, 04 Feb 2015 07:45:46 -0800 (PST) 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=9rR+RDtBJCjkZe5YmJS+HoZn0gMsYAGE+YybtoaK2+Y=; b=cgaarSWDXFUnXWaaVf5+8arpdK89MTnhcA15nxrNorZxK0TiifPQgi2LyeUIk0bOEe XhXtANU9fiiF2r4B7jQTI9jcpd6aOZo+8SyHHYdADROMyFTCEL7VP0EvCd9GVeHT52VJ D9mF6tdkFq8rHtFSAYqJoaYGMN9qKR2/j/U+zkptEFoexfY/9ALos303BATZBuNnQldq AW5H+2pGEpQ7Ra02OpGU7mS7XCYcXu2QsmWmr/14dPN0SnXWQ8e4Q4PLrz74LXoWqr7r 0eYBDpt4Iu+4fySQ/ASxdJkRCItmv2h79geJZ5Na9olIGwdY7TGE7sK5pSygZrBfAfwl f6Xw== X-Gm-Message-State: ALoCoQnQqjGvxU0CgoBA2Q5PW3jNnd/UuzNpETimbiH74rnNh0dR3vALBYxXH+LhO9TYf69OF7OJ X-Received: by 10.220.101.211 with SMTP id d19mr19728629vco.11.1423064746150; Wed, 04 Feb 2015 07:45:46 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com. [209.85.220.178]) by mx.google.com with ESMTPSA id ck15sm287288vdb.10.2015.02.04.07.45.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Feb 2015 07:45:45 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id hy10so747828vcb.9 for ; Wed, 04 Feb 2015 07:45:45 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.52.185.42 with SMTP id ez10mr14318410vdc.76.1423064745027; Wed, 04 Feb 2015 07:45:45 -0800 (PST) Received: by 10.52.54.194 with HTTP; Wed, 4 Feb 2015 07:45:44 -0800 (PST) In-Reply-To: References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> Date: Wed, 4 Feb 2015 10:45:44 -0500 Message-ID: From: Benjamin Schwartz To: Simon Perreault Content-Type: multipart/alternative; boundary=bcaec54865f69ec5d1050e4514d6 Archived-At: Cc: tram@ietf.org, "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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, 04 Feb 2015 15:45:53 -0000 --bcaec54865f69ec5d1050e4514d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Simon. 1. IP address privacy is not representable as a binary. See http://en.wikipedia.org/wiki/Degree_of_anonymity 2. This system actually _reduces_ privacy: > If the server determines that the relayed address it will allocate and client IP address are in the same geolocation then the server will redirect the client to another server This behavior provides me nonzero information about your location: you cannot be at the location indicated by the allocated IP address. (Even Simon's proposal here actually _increases_ address information leakage. The minimal-leakage strategy is to use a fixed/random address that might occasionally be close to your real address, by chance.) 3. "Same geolocation" is not a well-defined concept. There are a multitude of corporations with different, contradictory geolocation databases of varying quality. 4. I presume that the goal here is to allow building privacy-preserving communications systems, but this draft does not make that possible, because anyone setting up a privacy-preserving chat system cannot trust an arbitrary enterprise-configured TURN server to be privacy-preserving, just because that server claims to preserve privacy. On Wed, Feb 4, 2015 at 10:42 AM, Simon Perreault wrote: > Thanks for writing this. > > After a quick read, I am skeptical. I doubt any client would trust any > assertion from an a priori unknown TURN server about its available privac= y > capabilities. > > Instead, why can't the client simply request an allocation, perhaps > indicating its desire that the relayed address be "far" from its own with= a > new optional attribute, and then accept or reject the allocation using it= s > own good judgment? > > Simon > Le 2015-02-04 08:25, "Tirumaleswar Reddy (tireddy)" a > =C3=A9crit : > > This draft describes a means for an client to discover that the TURN >> server can provide IP address privacy. >> Comments and suggestions are welcome. >> >> -Tiru >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, February 04, 2015 8:54 PM >> To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); >> Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati) >> Subject: New Version Notification for >> draft-reddy-tram-turn-ipaddress-privacy-00.txt >> >> >> A new version of I-D, draft-reddy-tram-turn-ipaddress-privacy-00.txt >> has been successfully submitted by Tirumaleswar Reddy and posted to the >> IETF repository. >> >> Name: draft-reddy-tram-turn-ipaddress-privacy >> Revision: 00 >> Title: IP address privacy by TURN server >> Document date: 2015-02-04 >> Group: Individual Submission >> Pages: 6 >> URL: >> http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-ipaddress-priv= acy-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-reddy-tram-turn-ipaddress-privacy= / >> Htmlized: >> http://tools.ietf.org/html/draft-reddy-tram-turn-ipaddress-privacy-00 >> >> >> Abstract: >> A TURN server allocates an IP address for a user. If this address is >> dis-associated from the user's actual network, the allocated IP >> address increases the user's privacy. This document describes a >> means for an client to discover that the TURN server can provide IP >> address privacy. >> >> >> >> >> 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 >> > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --bcaec54865f69ec5d1050e4514d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Simon.

1. IP address privacy is not representable as a bina= ry.=C2=A0 See=C2=A0http://en.wikipedia.org/wiki/Degree_of_anonymity

2. This system actually _reduces_ privacy:
> If the server determines that the relayed address it will allocate = and client IP = address are in the same geolocation then the server will redirect the client to another s= erver

This behavior provides me nonzero information about your location: you ca= nnot be at the location indicated by the allocated IP address.
=

(Even Simon'= s proposal here actually _increases_ address information leakage. The mini= mal-leakage strategy is to use a fixed/random address that might occasional= ly be close to your real address, by chance.)


4. I presume that th= e goal here is to allow building privacy-preserving communications systems,= but this draft does not make that possible, because anyone setting up a pr= ivacy-preserving chat system cannot trust an arbitrary enterprise-configure= d TURN server to be privacy-preserving, just because that server claims to = preserve privacy.


On Wed, Feb 4, 2015 at 10:42 AM, Simon Perreault <= sperreault@jive.com> wrote:

Thanks for writing this.

After a quick read, I am skeptical. I doubt any client would= trust any assertion from an a priori unknown TURN server about its availab= le privacy capabilities.

Instead, why can't the client simply request an allocati= on, perhaps indicating its desire that the relayed address be "far&quo= t; from its own with a new optional attribute, and then accept or reject th= e allocation using its own good judgment?

Simon

Le 2015-02-04 08:25, "Tirumaleswar Reddy (t= ireddy)" <ti= reddy@cisco.com> a =C3=A9crit :

This draft describes a means for = an client to discover that the TURN server can provide IP address privacy.<= br> Comments and suggestions are welcome.

-Tiru

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, February 04, 2015 8:54 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Tirumaleswar = Reddy (tireddy); Prashanth Patil (praspati)
Subject: New Version Notification for draft-reddy-tram-turn-ipaddress-priva= cy-00.txt


A new version of I-D, draft-reddy-tram-turn-ipaddress-privacy-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-reddy-tram-turn-ipaddre= ss-privacy
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IP address privacy by TURN server<= br> Document date:=C2=A0 2015-02-04
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-ipaddres= s-privacy-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/draft-reddy-tram-turn-ipaddress-privacy/ Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.i= etf.org/html/draft-reddy-tram-turn-ipaddress-privacy-00


Abstract:
=C2=A0 =C2=A0A TURN server allocates an IP address for a user.=C2=A0 If thi= s address is
=C2=A0 =C2=A0dis-associated from the user's actual network, the allocat= ed IP
=C2=A0 =C2=A0address increases the user's privacy.=C2=A0 This document = describes a
=C2=A0 =C2=A0means for an client to discover that the TURN server can provi= de IP
=C2=A0 =C2=A0address privacy.




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

The IETF Secretariat

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

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


--bcaec54865f69ec5d1050e4514d6-- From nobody Wed Feb 4 07:58:34 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D431A8A7B for ; Wed, 4 Feb 2015 07:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eLkywAuDKWU for ; Wed, 4 Feb 2015 07:58:27 -0800 (PST) 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 72B4B1A8A61 for ; Wed, 4 Feb 2015 07:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15190; q=dns/txt; s=iport; t=1423065507; x=1424275107; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Qn0OEZ8+FY49Y2uqc4Jp2nnv+0u29DL61HGTiPQF1sk=; b=F4pgnsQCjYX+U2QXrY47uvnDGcswOPtnu8j3w5T1GKvXZyfCvtaMNcsl k6m2RTmlC0GxGs9PInPglEqiBl31VB3DUDGU4Ka46grp5PAL5T/ixCt7m IXnXA7kJbMU0QhQw1Ekt6opzImvtcT6klORt6Uam2Gi6zJ5ioeEjKb9Z2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C8BwBYQdJU/5JdJa1agkNDUlkEgn29FzyBXwELhW8CHH1DAQEBAQF9hAwBAQEEAQEBIApBCQIMBAIBCA4DBAEBCx0DAgICJQsUCAEIAgQOBQgBiCQNwDKDF5NAAQEBAQEBAQEBAQEBAQEBAQEBAQEBF49HFhcEBgEGA4JfLoETBY0tgWODUIZwNoJNgkaMAyKCMoE8bwGBQ34BAQE X-IronPort-AV: E=Sophos;i="5.09,518,1418083200"; d="scan'208,217";a="120499363" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP; 04 Feb 2015 15:58:10 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t14FwAmj014475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Feb 2015 15:58:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Wed, 4 Feb 2015 09:58:10 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt Thread-Index: AQHQQI6WdUQVEuPT30i8U4lnHv84fZzgnDZwgABplAD//52rEA== Date: Wed, 4 Feb 2015 15:58:09 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35538E02@xmb-rcd-x10.cisco.com> References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.54.201] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35538E02xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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, 04 Feb 2015 15:58:30 -0000 --_000_913383AAA69FF945B8F946018B75898A35538E02xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUl0NCg0KRnJvbTogU2ltb24gUGVycmVhdWx0IFttYWlsdG86c3BlcnJlYXVsdEBq aXZlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDQsIDIwMTUgOToxMiBQTQ0KVG86 IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiB0cmFtQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5 LXRyYW0tdHVybi1pcGFkZHJlc3MtcHJpdmFjeS0wMC50eHQNCg0KDQpUaGFua3MgZm9yIHdyaXRp bmcgdGhpcy4NCg0KQWZ0ZXIgYSBxdWljayByZWFkLCBJIGFtIHNrZXB0aWNhbC4gSSBkb3VidCBh bnkgY2xpZW50IHdvdWxkIHRydXN0IGFueSBhc3NlcnRpb24gZnJvbSBhbiBhIHByaW9yaSB1bmtu b3duIFRVUk4gc2VydmVyIGFib3V0IGl0cyBhdmFpbGFibGUgcHJpdmFjeSBjYXBhYmlsaXRpZXMu DQoNCltUUl0gVFVSTiBzZXJ2ZXIgY291bGQgYmUga25vd24gYW5kIHRydXN0ZWQgYnkgdGhlIGNs aWVudC4gSWYgdGhlIFRVUk4gc2VydmVyIGlzIG1hbGljaW91cyB0aGVuIHRoZXJlIGFyZSBvdGhl ciBwcml2YWN5IHByb2JsZW1zIGxpa2UgaXQgd2lsbCBrbm93IHRoZSBsb2NhdGlvbiBvZiBib3Ro IHRoZSBlbmRwb2ludHMsIGR1cmF0aW9uIG9mIHRoZSBjYWxsIGV0Yy4NCg0KSW5zdGVhZCwgd2h5 IGNhbid0IHRoZSBjbGllbnQgc2ltcGx5IHJlcXVlc3QgYW4gYWxsb2NhdGlvbiwgcGVyaGFwcyBp bmRpY2F0aW5nIGl0cyBkZXNpcmUgdGhhdCB0aGUgcmVsYXllZCBhZGRyZXNzIGJlICJmYXIiIGZy b20gaXRzIG93biB3aXRoIGEgbmV3IG9wdGlvbmFsIGF0dHJpYnV0ZSwgYW5kIHRoZW4gYWNjZXB0 IG9yIHJlamVjdCB0aGUgYWxsb2NhdGlvbiB1c2luZyBpdHMgb3duIGdvb2QganVkZ21lbnQgPw0K DQpbVFJdIEhvdyB0byBtZWFzdXJlIOKAnGZhcuKAnSAoc2FtZSBjb250aW5lbnQgZGlmZmVyZW50 IGNvdW50cnksIGRpZmZlcmVudCBjb250aW5lbnQpID8NCg0KLVRpcnUNCg0KU2ltb24NCkxlIDIw MTUtMDItMDQgMDg6MjUsICJUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIiA8dGlyZWRkeUBj aXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gYSDDqWNyaXQgOg0KVGhpcyBkcmFm dCBkZXNjcmliZXMgYSBtZWFucyBmb3IgYW4gY2xpZW50IHRvIGRpc2NvdmVyIHRoYXQgdGhlIFRV Uk4gc2VydmVyIGNhbiBwcm92aWRlIElQIGFkZHJlc3MgcHJpdmFjeS4NCkNvbW1lbnRzIGFuZCBz dWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCg0KLVRpcnUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPiBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPl0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDQsIDIw MTUgODo1NCBQTQ0KVG86IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBUaXJ1bWFsZXN3YXIg UmVkZHkgKHRpcmVkZHkpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBQcmFzaGFudGgg UGF0aWwgKHByYXNwYXRpKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDAudHh0DQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXJlZGR5LXRyYW0tdHVybi1pcGFkZHJlc3MtcHJpdmFjeS0w MC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGlydW1hbGVzd2FyIFJl ZGR5IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAg IGRyYWZ0LXJlZGR5LXRyYW0tdHVybi1pcGFkZHJlc3MtcHJpdmFjeQ0KUmV2aXNpb246ICAgICAg IDAwDQpUaXRsZTogICAgICAgICAgSVAgYWRkcmVzcyBwcml2YWN5IGJ5IFRVUk4gc2VydmVyDQpE b2N1bWVudCBkYXRlOiAgMjAxNS0wMi0wNA0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDYNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXBy aXZhY3ktMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2YWN5Lw0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5LXRyYW0tdHVybi1p cGFkZHJlc3MtcHJpdmFjeS0wMA0KDQoNCkFic3RyYWN0Og0KICAgQSBUVVJOIHNlcnZlciBhbGxv Y2F0ZXMgYW4gSVAgYWRkcmVzcyBmb3IgYSB1c2VyLiAgSWYgdGhpcyBhZGRyZXNzIGlzDQogICBk aXMtYXNzb2NpYXRlZCBmcm9tIHRoZSB1c2VyJ3MgYWN0dWFsIG5ldHdvcmssIHRoZSBhbGxvY2F0 ZWQgSVANCiAgIGFkZHJlc3MgaW5jcmVhc2VzIHRoZSB1c2VyJ3MgcHJpdmFjeS4gIFRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIGENCiAgIG1lYW5zIGZvciBhbiBjbGllbnQgdG8gZGlzY292ZXIgdGhh dCB0aGUgVFVSTiBzZXJ2ZXIgY2FuIHByb3ZpZGUgSVANCiAgIGFkZHJlc3MgcHJpdmFjeS4NCg0K DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9y Zz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxt YWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdHJhbQ0K --_000_913383AAA69FF945B8F946018B75898A35538E02xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SW5saW5lIFtUUl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gU2ltb24gUGVycmVhdWx0IFttYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE1IDk6MTIgUE08YnI+DQo8 Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQo8Yj5DYzo8L2I+IHRy YW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZh Y3ktMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+VGhhbmtzIGZvciB3cml0aW5n IHRoaXMuPG86cD48L286cD48L3A+DQo8cD5BZnRlciBhIHF1aWNrIHJlYWQsIEkgYW0gc2tlcHRp Y2FsLiBJIGRvdWJ0IGFueSBjbGllbnQgd291bGQgdHJ1c3QgYW55IGFzc2VydGlvbiBmcm9tIGFu IGEgcHJpb3JpIHVua25vd24gVFVSTiBzZXJ2ZXIgYWJvdXQgaXRzIGF2YWlsYWJsZSBwcml2YWN5 IGNhcGFiaWxpdGllcy48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5bVFJdIFRVUk4gc2VydmVyIGNvdWxkIGJlIGtub3duIGFuZCB0 cnVzdGVkIGJ5IHRoZSBjbGllbnQuIElmIHRoZSBUVVJOIHNlcnZlciBpcyBtYWxpY2lvdXMgdGhl biB0aGVyZSBhcmUgb3RoZXIgcHJpdmFjeSBwcm9ibGVtcyBsaWtlIGl0IHdpbGwga25vdyB0aGUg bG9jYXRpb24gb2YgYm90aCB0aGUgZW5kcG9pbnRzLA0KIGR1cmF0aW9uIG9mIHRoZSBjYWxsIGV0 Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD5JbnN0ZWFkLCB3aHkgY2FuJ3QgdGhlIGNsaWVu dCBzaW1wbHkgcmVxdWVzdCBhbiBhbGxvY2F0aW9uLCBwZXJoYXBzIGluZGljYXRpbmcgaXRzIGRl c2lyZSB0aGF0IHRoZSByZWxheWVkIGFkZHJlc3MgYmUgJnF1b3Q7ZmFyJnF1b3Q7IGZyb20gaXRz IG93biB3aXRoIGEgbmV3IG9wdGlvbmFsIGF0dHJpYnV0ZSwgYW5kIHRoZW4gYWNjZXB0IG9yIHJl amVjdCB0aGUgYWxsb2NhdGlvbiB1c2luZyBpdHMgb3duIGdvb2QganVkZ21lbnQ8c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+DQo8L3NwYW4+PzxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0gSG93IHRvIG1lYXN1cmUg4oCc ZmFy4oCdIChzYW1lIGNvbnRpbmVudCBkaWZmZXJlbnQgY291bnRyeSwgZGlmZmVyZW50IGNvbnRp bmVudCkgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPlNpbW9u PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGUgMjAxNS0wMi0w NCAwODoyNSwgJnF1b3Q7VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIj50aXJlZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7 IGEgw6ljcml0IDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZHJh ZnQgZGVzY3JpYmVzIGEgbWVhbnMgZm9yIGFuIGNsaWVudCB0byBkaXNjb3ZlciB0aGF0IHRoZSBU VVJOIHNlcnZlciBjYW4gcHJvdmlkZSBJUCBhZGRyZXNzIHByaXZhY3kuPGJyPg0KQ29tbWVudHMg YW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLjxicj4NCjxicj4NCi1UaXJ1PGJyPg0KPGJyPg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiA8YSBocmVmPSJtYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+IFttYWls dG86PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPC9hPl08YnI+DQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE1 IDg6NTQgUE08YnI+DQpUbzogUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSk7IFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFByYXNoYW50 aCBQYXRpbCAocHJhc3BhdGkpPGJyPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDAudHh0PGJyPg0K PGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXJlZGR5LXRyYW0tdHVybi1p cGFkZHJlc3MtcHJpdmFjeS0wMC50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2RyYWZ0LXJlZGR5LXRyYW0tdHVybi1pcGFkZHJlc3MtcHJpdmFjeTxicj4NClJldmlzaW9u OiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAwPGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBJUCBhZGRyZXNzIHByaXZhY3kgYnkgVFVSTiBzZXJ2ZXI8YnI+ DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE1LTAyLTA0PGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDY8YnI+DQpVUkw6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2YWN5 LTAwLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2YWN5LTAwLnR4dDwvYT48 YnI+DQpTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlZGR5LXRyYW0tdHVybi1pcGFk ZHJlc3MtcHJpdmFjeS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3kvPC9hPjxicj4N Ckh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5LXRyYW0tdHVybi1pcGFkZHJlc3MtcHJpdmFjeS0w MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5 LXRyYW0tdHVybi1pcGFkZHJlc3MtcHJpdmFjeS0wMDwvYT48YnI+DQo8YnI+DQo8YnI+DQpBYnN0 cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7QSBUVVJOIHNlcnZlciBhbGxvY2F0ZXMgYW4gSVAgYWRk cmVzcyBmb3IgYSB1c2VyLiZuYnNwOyBJZiB0aGlzIGFkZHJlc3MgaXM8YnI+DQombmJzcDsgJm5i c3A7ZGlzLWFzc29jaWF0ZWQgZnJvbSB0aGUgdXNlcidzIGFjdHVhbCBuZXR3b3JrLCB0aGUgYWxs b2NhdGVkIElQPGJyPg0KJm5ic3A7ICZuYnNwO2FkZHJlc3MgaW5jcmVhc2VzIHRoZSB1c2VyJ3Mg cHJpdmFjeS4mbmJzcDsgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYTxicj4NCiZuYnNwOyAmbmJz cDttZWFucyBmb3IgYW4gY2xpZW50IHRvIGRpc2NvdmVyIHRoYXQgdGhlIFRVUk4gc2VydmVyIGNh biBwcm92aWRlIElQPGJyPg0KJm5ic3A7ICZuYnNwO2FkZHJlc3MgcHJpdmFjeS48YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCjxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+ DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A35538E02xmbrcdx10ciscoc_-- From nobody Wed Feb 4 08:09:27 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0191A079D for ; Wed, 4 Feb 2015 08:09:21 -0800 (PST) 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 t-QHIT_HXWWa for ; Wed, 4 Feb 2015 08:09:19 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901601A0065 for ; Wed, 4 Feb 2015 08:09:04 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hz20so2412257lab.6 for ; Wed, 04 Feb 2015 08:09:03 -0800 (PST) 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=PmGVT0j8UB07bP7D+yBqnVyLaZF6pxuAT8SRo0HZhcc=; b=Ee0mJUu+Bcv8C1+sboOpkce/4WFk2g0PkxhMJW6n7LbQ3mXz58aboBaY2u2SpE631c 0D32nH1cLDRi2R7cQkU8qzGxBQUFHkuJLKLpgvM5/OEHxWCTZyRS0Cf1MKmgH7UwDCIP UJXg48O1mQ+mCBqh/+gKI22Eee7aaUTqeFpCiVohsGoKSYuHqEMfm6HcB5ONsYoobDDf khLY8d/zlav3k+jo1iHQUDXCoNzzPXg0be2c3cgsBpHusZPW7P/g57EnMFTBe07WKozw VKYLmSGuVIEAJg7B2bwAKlv5GZd/nsoRAsURB7qihr20ZoQY83BvZ8iMwDwQIjlJeBP/ wFfA== X-Gm-Message-State: ALoCoQkPV3OFTgcSPEA1uHjfT8GEhSt7ff2gYUR9lTgz8XTQ8v0R9ymyEGGJ1LdQOBIVQbLiofFX MIME-Version: 1.0 X-Received: by 10.112.122.52 with SMTP id lp20mr4048735lbb.98.1423066143079; Wed, 04 Feb 2015 08:09:03 -0800 (PST) Received: by 10.25.205.135 with HTTP; Wed, 4 Feb 2015 08:09:03 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A35538E02@xmb-rcd-x10.cisco.com> References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35538E02@xmb-rcd-x10.cisco.com> Date: Wed, 4 Feb 2015 09:09:03 -0700 Message-ID: From: Simon Perreault To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7bb04340f34e30050e456720 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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, 04 Feb 2015 16:09:22 -0000 --047d7bb04340f34e30050e456720 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 4, 2015 at 8:58 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > After a quick read, I am skeptical. I doubt any client would trust any > assertion from an a priori unknown TURN server about its available privac= y > capabilities. > > [TR] TURN server could be known and trusted by the client. If the TURN > server is malicious then there are other privacy problems like it will kn= ow > the location of both the endpoints, duration of the call etc. > Sure, but then 1. That needs to be stated clearly in the doc, and 2. That considerably reduces the applicability. Instead, why can't the client simply request an allocation, perhaps > indicating its desire that the relayed address be "far" from its own with= a > new optional attribute, and then accept or reject the allocation using it= s > own good judgment ? > > [TR] How to measure =E2=80=9Cfar=E2=80=9D (same continent different count= ry, different > continent) ? > Exactly! How does the server itself know if it can provide privacy, if even the client can't tell? Simon --047d7bb04340f34e30050e456720 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Feb 4, 2015 at 8:58 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisc= o.com> wrote:

After a quick read, I am skeptical. I doubt any client would trust= any assertion from an a priori unknown TURN server about its available pri= vacy capabilities.

[TR] TURN server could be known and tr= usted by the client. If the TURN server is malicious then there are other p= rivacy problems like it will know the location of both the endpoints, duration of the call etc.

Sure, but then
=

1. That needs to be stated clearly in the doc, and
2. That considerably reduces the applicability.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

<= /span>

Instead, why can't the client simply request an allocation, perhaps = indicating its desire that the relayed address be "far" from its = own with a new optional attribute, and then accept or reject the allocation= using its own good judgment ?

[TR] How to measure =E2=80=9Cfar=E2=80= =9D (same continent different country, different continent) ?

=C2=A0
Exactly! How does the server itself know i= f it can provide privacy, if even the client can't tell?

Simon
--047d7bb04340f34e30050e456720-- From nobody Wed Feb 4 08:11:54 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72FD1A6F12 for ; Wed, 4 Feb 2015 08:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnQHNBoF4p8a for ; Wed, 4 Feb 2015 08:11:50 -0800 (PST) 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 C8CC61A0404 for ; Wed, 4 Feb 2015 08:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24292; q=dns/txt; s=iport; t=1423066309; x=1424275909; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yNXXxKF+G0UeEZ88l6QGH6fwNeviWHfxw8vqJFhH364=; b=XCl/KgSY815gP7+towC/49addUlY6FgLgCaIIYxCWRNQ3WPdMPi9i9Yb mheOStHbPEgcBHS8alT+ZIhlbDTrotOA+BQ0Hz1jwNnfKdQAd0jeaZ72O VTz/gR1VxISg+KCoK2SkBSWnXTCn8IPx/WAoxd1gkFPapyzyrASAS/60b Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C8BwC4Q9JU/5FdJa1agkNDUlkEgn29FzyBXwELhW8CHH1DAQEBAQF9hAwBAQEDAQEBASAKQQkCBQcEAgEIDgMEAQELHQMCAgIlCxQIAQgCBAENBQgBiBwIDcAZllgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj0cPBxcEBgEGA4JfLoETBY0tgWODUIZwNoJNgkaIRoM9IoIygTxvAYFDfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,518,1418083200"; d="scan'208,217";a="120452653" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 04 Feb 2015 16:11:48 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t14GBmLW021482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Feb 2015 16:11:48 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Wed, 4 Feb 2015 10:11:48 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Benjamin Schwartz , Simon Perreault Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt Thread-Index: AQHQQI6WdUQVEuPT30i8U4lnHv84fZzgnDZwgABplACAAADzAP//nwEQ Date: Wed, 4 Feb 2015 16:11:47 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35538E3D@xmb-rcd-x10.cisco.com> References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.54.201] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35538E3Dxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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, 04 Feb 2015 16:11:52 -0000 --_000_913383AAA69FF945B8F946018B75898A35538E3Dxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUl0NCg0KRnJvbTogQmVuamFtaW4gU2Nod2FydHogW21haWx0bzpiZW1hc2NAd2Vi cnRjLm9yZ10NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDQsIDIwMTUgOToxNiBQTQ0KVG86 IFNpbW9uIFBlcnJlYXVsdA0KQ2M6IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IHRyYW1A aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJhbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2YWN5LTAwLnR4dA0KDQpJ IGFncmVlIHdpdGggU2ltb24uDQoNCjEuIElQIGFkZHJlc3MgcHJpdmFjeSBpcyBub3QgcmVwcmVz ZW50YWJsZSBhcyBhIGJpbmFyeS4gIFNlZSBodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0Rl Z3JlZV9vZl9hbm9ueW1pdHkNCg0KW1RSXSBJdCBpcyBvbmx5IG9mZmVyaW5nIElQIGFkZHJlc3Mg cHJpdmFjeSBmcm9tIHJlbW90ZSBwZWVyLg0KMi4gVGhpcyBzeXN0ZW0gYWN0dWFsbHkgX3JlZHVj ZXNfIHByaXZhY3k6DQo+IElmIHRoZSBzZXJ2ZXIgZGV0ZXJtaW5lcyB0aGF0IHRoZSByZWxheWVk IGFkZHJlc3MgaXQgd2lsbCBhbGxvY2F0ZSBhbmQgY2xpZW50IElQIGFkZHJlc3MgYXJlIGluIHRo ZSBzYW1lIGdlb2xvY2F0aW9uIHRoZW4gdGhlIHNlcnZlciB3aWxsIHJlZGlyZWN0IHRoZSBjbGll bnQgdG8gYW5vdGhlciBzZXJ2ZXINCg0KVGhpcyBiZWhhdmlvciBwcm92aWRlcyBtZSBub256ZXJv IGluZm9ybWF0aW9uIGFib3V0IHlvdXIgbG9jYXRpb246IHlvdSBjYW5ub3QgYmUgYXQgdGhlIGxv Y2F0aW9uIGluZGljYXRlZCBieSB0aGUgYWxsb2NhdGVkIElQIGFkZHJlc3MuDQoNCltUUl0gVGhl IHJlbGF5ZWQgYWRkcmVzcyBpcyBub3QgYWxsb2NhdGVkIGJ5IHRoZSBUVVJOIHNlcnZlciwgaXQg cmVkaXJlY3RzIHRoZSBjbGllbnQgdG8gYSBkaWZmZXJlbnQgVFVSTiBzZXJ2ZXIgdGhhdCBjYW4g b2ZmZXIgSVAgYWRkcmVzcyBwcml2YWN5Lg0KDQooRXZlbiBTaW1vbidzIHByb3Bvc2FsIGhlcmUg YWN0dWFsbHkgX2luY3JlYXNlc18gYWRkcmVzcyBpbmZvcm1hdGlvbiBsZWFrYWdlLiBUaGUgbWlu aW1hbC1sZWFrYWdlIHN0cmF0ZWd5IGlzIHRvIHVzZSBhIGZpeGVkL3JhbmRvbSBhZGRyZXNzIHRo YXQgbWlnaHQgb2NjYXNpb25hbGx5IGJlIGNsb3NlIHRvIHlvdXIgcmVhbCBhZGRyZXNzLCBieSBj aGFuY2UuKQ0KDQozLiAiU2FtZSBnZW9sb2NhdGlvbiIgaXMgbm90IGEgd2VsbC1kZWZpbmVkIGNv bmNlcHQuICBUaGVyZSBhcmUgYSBtdWx0aXR1ZGUgb2YgY29ycG9yYXRpb25zIHdpdGggZGlmZmVy ZW50LCBjb250cmFkaWN0b3J5IGdlb2xvY2F0aW9uIGRhdGFiYXNlcyBvZiB2YXJ5aW5nIHF1YWxp dHkuDQoNCltUUl0gR2VvbG9jYXRpb24gaXMgd2VsbC1kZWZpbmVkIGNvbmNlcHQgYWxyZWFkeSB1 c2VkIGJ5IGZpcmV3YWxscyBmcm9tIHZhcmlvdXMgdmVuZG9ycyB0byBtYWtlIGVmZmVjdGl2ZSBi bG9ja2luZyBkZWNpc2lvbnMuDQoNCjQuIEkgcHJlc3VtZSB0aGF0IHRoZSBnb2FsIGhlcmUgaXMg dG8gYWxsb3cgYnVpbGRpbmcgcHJpdmFjeS1wcmVzZXJ2aW5nIGNvbW11bmljYXRpb25zIHN5c3Rl bXMsIGJ1dCB0aGlzIGRyYWZ0IGRvZXMgbm90IG1ha2UgdGhhdCBwb3NzaWJsZSwgYmVjYXVzZSBh bnlvbmUgc2V0dGluZyB1cCBhIHByaXZhY3ktcHJlc2VydmluZyBjaGF0IHN5c3RlbSBjYW5ub3Qg dHJ1c3QgYW4gYXJiaXRyYXJ5IGVudGVycHJpc2UtY29uZmlndXJlZCBUVVJOIHNlcnZlciB0byBi ZSBwcml2YWN5LXByZXNlcnZpbmcsIGp1c3QgYmVjYXVzZSB0aGF0IHNlcnZlciBjbGFpbXMgdG8g cHJlc2VydmUgcHJpdmFjeS4NCg0KW1RSXSBFbnRlcnByaXNlIGNvbmZpZ3VyZWQgVFVSTiBzZXJ2 ZXIgaXMgbm90IGFuIGFyYml0cmFyeSBzZXJ2ZXIuIFR5cGljYWxseSB1c2VycyB0cnVzdCBFbnRl cnByaXNlIGZpcmV3YWxsIGFuZCBpdCBhY3QgYXMgSFRUUChTKSBwcm94eSwgaW4gdGhlIHNhbWUg bGluZXMgRW50ZXJwcmlzZSBUVVJOIHNlcnZlciBjYW4gYWxzbyBiZSB0cnVzdGVkIHdoZW4gaXQg Y2xhaW1zIGl0IGNhbiBwcm92aWRlIHByaXZhY3kuDQoNCi1UaXJ1DQoNCk9uIFdlZCwgRmViIDQs IDIwMTUgYXQgMTA6NDIgQU0sIFNpbW9uIFBlcnJlYXVsdCA8c3BlcnJlYXVsdEBqaXZlLmNvbTxt YWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbT4+IHdyb3RlOg0KDQpUaGFua3MgZm9yIHdyaXRpbmcg dGhpcy4NCg0KQWZ0ZXIgYSBxdWljayByZWFkLCBJIGFtIHNrZXB0aWNhbC4gSSBkb3VidCBhbnkg Y2xpZW50IHdvdWxkIHRydXN0IGFueSBhc3NlcnRpb24gZnJvbSBhbiBhIHByaW9yaSB1bmtub3du IFRVUk4gc2VydmVyIGFib3V0IGl0cyBhdmFpbGFibGUgcHJpdmFjeSBjYXBhYmlsaXRpZXMuDQoN Ckluc3RlYWQsIHdoeSBjYW4ndCB0aGUgY2xpZW50IHNpbXBseSByZXF1ZXN0IGFuIGFsbG9jYXRp b24sIHBlcmhhcHMgaW5kaWNhdGluZyBpdHMgZGVzaXJlIHRoYXQgdGhlIHJlbGF5ZWQgYWRkcmVz cyBiZSAiZmFyIiBmcm9tIGl0cyBvd24gd2l0aCBhIG5ldyBvcHRpb25hbCBhdHRyaWJ1dGUsIGFu ZCB0aGVuIGFjY2VwdCBvciByZWplY3QgdGhlIGFsbG9jYXRpb24gdXNpbmcgaXRzIG93biBnb29k IGp1ZGdtZW50Pw0KDQpTaW1vbg0KTGUgMjAxNS0wMi0wNCAwODoyNSwgIlRpcnVtYWxlc3dhciBS ZWRkeSAodGlyZWRkeSkiIDx0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5j b20+PiBhIMOpY3JpdCA6DQoNClRoaXMgZHJhZnQgZGVzY3JpYmVzIGEgbWVhbnMgZm9yIGFuIGNs aWVudCB0byBkaXNjb3ZlciB0aGF0IHRoZSBUVVJOIHNlcnZlciBjYW4gcHJvdmlkZSBJUCBhZGRy ZXNzIHByaXZhY3kuDQpDb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNCi1U aXJ1DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz5dDQpTZW50 OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE1IDg6NTQgUE0NClRvOiBQcmFzaGFudGggUGF0 aWwgKHByYXNwYXRpKTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KTsgUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSkNClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVz cy1wcml2YWN5LTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yZWRkeS10 cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJl cG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRy ZXNzLXByaXZhY3kNClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgIElQIGFkZHJl c3MgcHJpdmFjeSBieSBUVVJOIHNlcnZlcg0KRG9jdW1lbnQgZGF0ZTogIDIwMTUtMDItMDQNCkdy b3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICA2DQpV Ukw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt cmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2YWN5LTAwLnR4dA0KU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlZGR5LXRyYW0tdHVybi1p cGFkZHJlc3MtcHJpdmFjeS8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDANCg0KDQpBYnN0 cmFjdDoNCiAgIEEgVFVSTiBzZXJ2ZXIgYWxsb2NhdGVzIGFuIElQIGFkZHJlc3MgZm9yIGEgdXNl ci4gIElmIHRoaXMgYWRkcmVzcyBpcw0KICAgZGlzLWFzc29jaWF0ZWQgZnJvbSB0aGUgdXNlcidz IGFjdHVhbCBuZXR3b3JrLCB0aGUgYWxsb2NhdGVkIElQDQogICBhZGRyZXNzIGluY3JlYXNlcyB0 aGUgdXNlcidzIHByaXZhY3kuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhDQogICBtZWFucyBm b3IgYW4gY2xpZW50IHRvIGRpc2NvdmVyIHRoYXQgdGhlIFRVUk4gc2VydmVyIGNhbiBwcm92aWRl IElQDQogICBhZGRyZXNzIHByaXZhY3kuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBt YWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGll dGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90cmFtDQoNCg== --_000_913383AAA69FF945B8F946018B75898A35538E3Dxmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PklubGluZSBbVFJdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IEJlbmphbWluIFNjaHdhcnR6IFttYWlsdG86YmVtYXNjQHdlYnJ0Yy5vcmddDQo8YnI+DQo8Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNSA5OjE2IFBNPGJyPg0KPGI+VG86 PC9iPiBTaW1vbiBQZXJyZWF1bHQ8YnI+DQo8Yj5DYzo8L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSk7IHRyYW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRkeS10cmFtLXR1cm4taXBh ZGRyZXNzLXByaXZhY3ktMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgd2l0aCBTaW1vbi48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIy Ij4xLiBJUCBhZGRyZXNzIHByaXZhY3kgaXMgbm90IHJlcHJlc2VudGFibGUgYXMgYSBiaW5hcnku Jm5ic3A7IFNlZSZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRGVn cmVlX29mX2Fub255bWl0eSI+aHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9EZWdyZWVfb2Zf YW5vbnltaXR5PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5bVFJdIEl0IGlzIG9ubHkgb2ZmZXJpbmcgSVAgYWRkcmVzcyBw cml2YWN5IGZyb20gcmVtb3RlIHBlZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPjIuIFRoaXMgc3lzdGVtIGFjdHVhbGx5IF9yZWR1Y2Vz XyBwcml2YWN5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7IElmIHRoZSBzZXJ2ZXIgZGV0 ZXJtaW5lcyB0aGF0IHRoZSByZWxheWVkIGFkZHJlc3MgaXQgd2lsbCBhbGxvY2F0ZSBhbmQgY2xp ZW50IElQIGFkZHJlc3MgYXJlIGluIHRoZSBzYW1lIGdlb2xvY2F0aW9uIHRoZW4gdGhlIHNlcnZl ciB3aWxsIHJlZGlyZWN0IHRoZSBjbGllbnQgdG8gYW5vdGhlciBzZXJ2ZXI8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzIyMjIyMiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPlRoaXMgYmVoYXZpb3IgcHJvdmlkZXMgbWUgbm9uemVybyBpbmZv cm1hdGlvbiBhYm91dCB5b3VyIGxvY2F0aW9uOiB5b3UgY2Fubm90IGJlIGF0IHRoZSBsb2NhdGlv biBpbmRpY2F0ZWQgYnkgdGhlIGFsbG9jYXRlZCBJUCBhZGRyZXNzLjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMjIyMjIyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0gVGhlIHJlbGF5ZWQgYWRkcmVzcyBpcyBub3Qg YWxsb2NhdGVkIGJ5IHRoZSBUVVJOIHNlcnZlciwgaXQgcmVkaXJlY3RzIHRoZSBjbGllbnQgdG8g YSBkaWZmZXJlbnQgVFVSTiBzZXJ2ZXIgdGhhdCBjYW4gb2ZmZXIgSVAgYWRkcmVzcyBwcml2YWN5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4oRXZlbiBTaW1vbidzIHByb3Bvc2FsIGhlcmUgYWN0dWFsbHkgX2luY3JlYXNlc18gYWRkcmVz cyBpbmZvcm1hdGlvbiBsZWFrYWdlLiBUaGUgbWluaW1hbC1sZWFrYWdlIHN0cmF0ZWd5IGlzIHRv IHVzZSBhIGZpeGVkL3JhbmRvbSBhZGRyZXNzIHRoYXQgbWlnaHQgb2NjYXNpb25hbGx5IGJlIGNs b3NlIHRvIHlvdXINCiByZWFsIGFkZHJlc3MsIGJ5IGNoYW5jZS4pPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMyMjIyMjIiPjMuICZxdW90O1NhbWUgZ2VvbG9jYXRpb24mcXVvdDsgaXMgbm90IGEg d2VsbC1kZWZpbmVkIGNvbmNlcHQuJm5ic3A7IFRoZXJlIGFyZSBhIG11bHRpdHVkZSBvZiBjb3Jw b3JhdGlvbnMgd2l0aCBkaWZmZXJlbnQsIGNvbnRyYWRpY3RvcnkgZ2VvbG9jYXRpb24gZGF0YWJh c2VzIG9mIHZhcnlpbmcgcXVhbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0gR2VvbG9jYXRpb24gaXMgd2Vs bC1kZWZpbmVkIGNvbmNlcHQgYWxyZWFkeSB1c2VkIGJ5IGZpcmV3YWxscyBmcm9tIHZhcmlvdXMg dmVuZG9ycyB0byBtYWtlIGVmZmVjdGl2ZSBibG9ja2luZyBkZWNpc2lvbnMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzIyMjIyMiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+NC4gSSBwcmVz dW1lIHRoYXQgdGhlIGdvYWwgaGVyZSBpcyB0byBhbGxvdyBidWlsZGluZyBwcml2YWN5LXByZXNl cnZpbmcgY29tbXVuaWNhdGlvbnMgc3lzdGVtcywgYnV0IHRoaXMgZHJhZnQgZG9lcyBub3QgbWFr ZSB0aGF0IHBvc3NpYmxlLCBiZWNhdXNlIGFueW9uZSBzZXR0aW5nIHVwIGEgcHJpdmFjeS1wcmVz ZXJ2aW5nDQogY2hhdCBzeXN0ZW0gY2Fubm90IHRydXN0IGFuIGFyYml0cmFyeSBlbnRlcnByaXNl LWNvbmZpZ3VyZWQgVFVSTiBzZXJ2ZXIgdG8gYmUgcHJpdmFjeS1wcmVzZXJ2aW5nLCBqdXN0IGJl Y2F1c2UgdGhhdCBzZXJ2ZXIgY2xhaW1zIHRvIHByZXNlcnZlIHByaXZhY3kuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5b VFJdIEVudGVycHJpc2UgY29uZmlndXJlZCBUVVJOIHNlcnZlciBpcyBub3QgYW4gYXJiaXRyYXJ5 IHNlcnZlci4gVHlwaWNhbGx5IHVzZXJzIHRydXN0IEVudGVycHJpc2UgZmlyZXdhbGwgYW5kIGl0 IGFjdCBhcyBIVFRQKFMpIHByb3h5LCBpbiB0aGUgc2FtZSBsaW5lcw0KIEVudGVycHJpc2UgVFVS TiBzZXJ2ZXIgY2FuIGFsc28gYmUgdHJ1c3RlZCB3aGVuIGl0IGNsYWltcyBpdCBjYW4gcHJvdmlk ZSBwcml2YWN5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiA0LCAyMDE1IGF0IDEwOjQyIEFN LCBTaW1vbiBQZXJyZWF1bHQgJmx0OzxhIGhyZWY9Im1haWx0bzpzcGVycmVhdWx0QGppdmUuY29t IiB0YXJnZXQ9Il9ibGFuayI+c3BlcnJlYXVsdEBqaXZlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPHA+VGhhbmtzIGZvciB3cml0aW5nIHRoaXMuPG86cD48L286cD48L3A+DQo8 cD5BZnRlciBhIHF1aWNrIHJlYWQsIEkgYW0gc2tlcHRpY2FsLiBJIGRvdWJ0IGFueSBjbGllbnQg d291bGQgdHJ1c3QgYW55IGFzc2VydGlvbiBmcm9tIGFuIGEgcHJpb3JpIHVua25vd24gVFVSTiBz ZXJ2ZXIgYWJvdXQgaXRzIGF2YWlsYWJsZSBwcml2YWN5IGNhcGFiaWxpdGllcy48bzpwPjwvbzpw PjwvcD4NCjxwPkluc3RlYWQsIHdoeSBjYW4ndCB0aGUgY2xpZW50IHNpbXBseSByZXF1ZXN0IGFu IGFsbG9jYXRpb24sIHBlcmhhcHMgaW5kaWNhdGluZyBpdHMgZGVzaXJlIHRoYXQgdGhlIHJlbGF5 ZWQgYWRkcmVzcyBiZSAmcXVvdDtmYXImcXVvdDsgZnJvbSBpdHMgb3duIHdpdGggYSBuZXcgb3B0 aW9uYWwgYXR0cmlidXRlLCBhbmQgdGhlbiBhY2NlcHQgb3IgcmVqZWN0IHRoZSBhbGxvY2F0aW9u IHVzaW5nIGl0cyBvd24gZ29vZCBqdWRnbWVudD88bzpwPjwvbzpwPjwvcD4NCjxwPlNpbW9uPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGUgMjAxNS0wMi0wNCAw ODoyNSwgJnF1b3Q7VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBjaXNj by5jb208L2E+Jmd0OyBhIMOpY3JpdCA6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZHJhZnQgZGVzY3JpYmVzIGEgbWVhbnMgZm9yIGFuIGNs aWVudCB0byBkaXNjb3ZlciB0aGF0IHRoZSBUVVJOIHNlcnZlciBjYW4gcHJvdmlkZSBJUCBhZGRy ZXNzIHByaXZhY3kuPGJyPg0KQ29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLjxi cj4NCjxicj4NCi1UaXJ1PGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ DQpGcm9tOiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc8L2E+XTxicj4NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDQsIDIw MTUgODo1NCBQTTxicj4NClRvOiBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgUHJhc2hh bnRoIFBhdGlsIChwcmFzcGF0aSk8YnI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXJlZGR5LXRyYW0tdHVybi1pcGFkZHJlc3MtcHJpdmFjeS0wMC50eHQ8YnI+ DQo8YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmVkZHktdHJhbS10dXJu LWlwYWRkcmVzcy1wcml2YWN5LTAwLnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgVGlydW1hbGVzd2FyIFJlZGR5IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2YWN5PGJyPg0KUmV2aXNp b246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDA8YnI+DQpUaXRsZTombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElQIGFkZHJlc3MgcHJpdmFjeSBieSBUVVJOIHNlcnZlcjxi cj4NCkRvY3VtZW50IGRhdGU6Jm5ic3A7IDIwMTUtMDItMDQ8YnI+DQpHcm91cDombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NClBhZ2Vz OiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgNjxicj4NClVSTDombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZh Y3ktMDAudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDAudHh0PC9h Pjxicj4NClN0YXR1czombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmVkZHktdHJhbS10dXJuLWlw YWRkcmVzcy1wcml2YWN5LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXJlZGR5LXRyYW0tdHVybi1pcGFkZHJlc3MtcHJpdmFjeS88L2E+PGJy Pg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2YWN5 LTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVk ZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2YWN5LTAwPC9hPjxicj4NCjxicj4NCjxicj4NCkFi c3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtBIFRVUk4gc2VydmVyIGFsbG9jYXRlcyBhbiBJUCBh ZGRyZXNzIGZvciBhIHVzZXIuJm5ic3A7IElmIHRoaXMgYWRkcmVzcyBpczxicj4NCiZuYnNwOyAm bmJzcDtkaXMtYXNzb2NpYXRlZCBmcm9tIHRoZSB1c2VyJ3MgYWN0dWFsIG5ldHdvcmssIHRoZSBh bGxvY2F0ZWQgSVA8YnI+DQombmJzcDsgJm5ic3A7YWRkcmVzcyBpbmNyZWFzZXMgdGhlIHVzZXIn cyBwcml2YWN5LiZuYnNwOyBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhPGJyPg0KJm5ic3A7ICZu YnNwO21lYW5zIGZvciBhbiBjbGllbnQgdG8gZGlzY292ZXIgdGhhdCB0aGUgVFVSTiBzZXJ2ZXIg Y2FuIHByb3ZpZGUgSVA8YnI+DQombmJzcDsgJm5ic3A7YWRkcmVzcyBwcml2YWN5Ljxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxi cj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RyYW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RyYW08L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9y ZyI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A35538E3Dxmbrcdx10ciscoc_-- From nobody Wed Feb 4 08:32:24 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8F31A1A10 for ; Wed, 4 Feb 2015 08:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mToj-wwKCHeh for ; Wed, 4 Feb 2015 08:32:22 -0800 (PST) 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 1BAEB1A079D for ; Wed, 4 Feb 2015 08:32:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15736; q=dns/txt; s=iport; t=1423067542; x=1424277142; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+ahAsfLY6984MUAxNrQLct5+dTjFeesyEWAW9Q9H3HM=; b=ab6QTJnc0n13iyMRRBXXiV5iR6nUEVbquiKml/gOw3bsTjjJM+F1CDZf B+tsB1Z/UENnBhSmcUOq6RiqdQAK1dikjuRbXqh9j0KWlBVRpdXg2+hdB lmn4KEW6X7eW9qo6W9wkXq5VS+dbJ6sIA2ShkpqM15SnYGB03f+Uq8HBn g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUFAFBJ0lStJV2R/2dsb2JhbABagkNDUlkEgn29GIgWAhx+QwEBAQEBfYQMAQEBBCMKSgIQAgEIDgMEAQELHQMCAgIwFAgBCAIEDgUIiCXAR4MXk0IBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj0cxBgGCaC6BEwWPEIpAhUmMAyKCMoE8b4FEfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,518,1418083200"; d="scan'208,217";a="393359041" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP; 04 Feb 2015 16:32:12 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t14GWCYu012999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Feb 2015 16:32:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 4 Feb 2015 10:32:12 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt Thread-Index: AQHQQI6WdUQVEuPT30i8U4lnHv84fZzgnDZwgABplAD//52rEIAAacyA//+cgEA= Date: Wed, 4 Feb 2015 16:32:12 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35538EA8@xmb-rcd-x10.cisco.com> References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35538E02@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.54.201] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35538EA8xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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, 04 Feb 2015 16:32:24 -0000 --_000_913383AAA69FF945B8F946018B75898A35538EA8xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUjJdDQoNCkZyb206IFNpbW9uIFBlcnJlYXVsdCBbbWFpbHRvOnNwZXJyZWF1bHRA aml2ZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE1IDk6MzkgUE0NClRv OiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpDYzogdHJhbUBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFt0cmFtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRk eS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDAudHh0DQoNCg0KT24gV2VkLCBGZWIgNCwg MjAxNSBhdCA4OjU4IEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIDx0aXJlZGR5QGNp c2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+PiB3cm90ZToNCg0KQWZ0ZXIgYSBxdWlj ayByZWFkLCBJIGFtIHNrZXB0aWNhbC4gSSBkb3VidCBhbnkgY2xpZW50IHdvdWxkIHRydXN0IGFu eSBhc3NlcnRpb24gZnJvbSBhbiBhIHByaW9yaSB1bmtub3duIFRVUk4gc2VydmVyIGFib3V0IGl0 cyBhdmFpbGFibGUgcHJpdmFjeSBjYXBhYmlsaXRpZXMuDQoNCltUUl0gVFVSTiBzZXJ2ZXIgY291 bGQgYmUga25vd24gYW5kIHRydXN0ZWQgYnkgdGhlIGNsaWVudC4gSWYgdGhlIFRVUk4gc2VydmVy IGlzIG1hbGljaW91cyB0aGVuIHRoZXJlIGFyZSBvdGhlciBwcml2YWN5IHByb2JsZW1zIGxpa2Ug aXQgd2lsbCBrbm93IHRoZSBsb2NhdGlvbiBvZiBib3RoIHRoZSBlbmRwb2ludHMsIGR1cmF0aW9u IG9mIHRoZSBjYWxsIGV0Yy4NClN1cmUsIGJ1dCB0aGVuDQoNCg0KMS4gICAgIFRoYXQgbmVlZHMg dG8gYmUgc3RhdGVkIGNsZWFybHkgaW4gdGhlIGRvYywgYW5kDQoNCltUUjJdIEl0IGlzIGRpc2N1 c3NlZCBpbiB0aGUgZHJhZnQuDQo8c25pcD4NClRoZSBjbGllbnQgbXVzdCBvbmx5IHNlbGVjdCBh IFRVUk4gc2VydmVyIHdob3NlIGF1dGhlbnRpY2l0eSBjYW4gYmUgYXNjZXJ0YWluZWQgYW5kIGNh biBvZmZlciBJUCBhZGRyZXNzIHByaXZhY3kuDQo8L3NuaXA+DQoNCjIuIFRoYXQgY29uc2lkZXJh Ymx5IHJlZHVjZXMgdGhlIGFwcGxpY2FiaWxpdHkuDQoNCltUUjJdIENsaWVudCBsb29raW5nIGZv ciBJUCBhZGRyZXNzIHByaXZhY3kgc2hvdWxkIGdpdmUgaGlnaGVyIHByZWNlZGVuY2UgdG8gYSB0 cnVzdGVkIFRVUk4gc2VydmVyIHRoYW4gc29tZSByYW5kb20gVFVSTiBzZXJ2ZXIgd2hvc2UgYXV0 aGVudGljaXR5IGNhbm5vdCBiZSBhc2NlcnRhaW5lZC4gV2Ugc2hvdWxkIGFsc28gY29uc2lkZXIg c2NlbmFyaW9zIHdoZXJlIGF0dGFja2VycyBtYXkgZGVwbG95IFRVUk4gc2VydmVycy4NCg0KDQpJ bnN0ZWFkLCB3aHkgY2FuJ3QgdGhlIGNsaWVudCBzaW1wbHkgcmVxdWVzdCBhbiBhbGxvY2F0aW9u LCBwZXJoYXBzIGluZGljYXRpbmcgaXRzIGRlc2lyZSB0aGF0IHRoZSByZWxheWVkIGFkZHJlc3Mg YmUgImZhciIgZnJvbSBpdHMgb3duIHdpdGggYSBuZXcgb3B0aW9uYWwgYXR0cmlidXRlLCBhbmQg dGhlbiBhY2NlcHQgb3IgcmVqZWN0IHRoZSBhbGxvY2F0aW9uIHVzaW5nIGl0cyBvd24gZ29vZCBq dWRnbWVudCA/DQoNCltUUl0gSG93IHRvIG1lYXN1cmUg4oCcZmFy4oCdIChzYW1lIGNvbnRpbmVu dCBkaWZmZXJlbnQgY291bnRyeSwgZGlmZmVyZW50IGNvbnRpbmVudCkgPw0KDQpFeGFjdGx5ISBI b3cgZG9lcyB0aGUgc2VydmVyIGl0c2VsZiBrbm93IGlmIGl0IGNhbiBwcm92aWRlIHByaXZhY3ks IGlmIGV2ZW4gdGhlIGNsaWVudCBjYW4ndCB0ZWxsID8NCg0KW1RSXSBBRERSRVNTLVBSSVZBQ1kg YXR0cmlidXRlIGNhbiBwcm9iYWJseSBiZSBlbmhhbmNlZCB0byBpbmRpY2F0ZSB0aGUgbGV2ZWwg b2YgcHJpdmFjeSByZXF1aXJlZC4NCg0KLVRpcnUNCg0KU2ltb24NCg== --_000_913383AAA69FF945B8F946018B75898A35538EA8xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1h cmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjEyNTUzNTE0NjsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0MzE3OTI4NDgg Njc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2 OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JbmxpbmUgW1RSMl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU2ltb24gUGVycmVhdWx0IFttYWlsdG86c3BlcnJlYXVsdEBq aXZlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE1 IDk6MzkgUE08YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnI+ DQo8Yj5DYzo8L2I+IHRyYW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFt XSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRkeS10cmFtLXR1cm4t aXBhZGRyZXNzLXByaXZhY3ktMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiA0LCAyMDE1IGF0IDg6NTggQU0sIFRp cnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0OzxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8cD5BZnRlciBhIHF1aWNrIHJlYWQsIEkgYW0gc2tlcHRpY2FsLiBJ IGRvdWJ0IGFueSBjbGllbnQgd291bGQgdHJ1c3QgYW55IGFzc2VydGlvbiBmcm9tIGFuIGEgcHJp b3JpIHVua25vd24gVFVSTiBzZXJ2ZXIgYWJvdXQgaXRzIGF2YWlsYWJsZSBwcml2YWN5IGNhcGFi aWxpdGllcy48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5bVFJdIFRVUk4gc2VydmVyIGNvdWxkIGJlIGtub3duIGFuZCB0cnVzdGVk IGJ5IHRoZSBjbGllbnQuIElmIHRoZSBUVVJOIHNlcnZlciBpcyBtYWxpY2lvdXMgdGhlbiB0aGVy ZSBhcmUgb3RoZXIgcHJpdmFjeSBwcm9ibGVtcyBsaWtlIGl0IHdpbGwga25vdyB0aGUgbG9jYXRp b24gb2YgYm90aCB0aGUgZW5kcG9pbnRzLA0KIGR1cmF0aW9uIG9mIHRoZSBjYWxsIGV0Yy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VyZSwgYnV0 IHRoZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEu PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoYXQgbmVlZHMg dG8gYmUgc3RhdGVkIGNsZWFybHkgaW4gdGhlIGRvYywgYW5kPHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5bVFIyXSBJdCBpcyBkaXNjdXNzZWQgaW4gdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbHQ7c25pcCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIGNsaWVudCBtdXN0IG9ubHkgc2VsZWN0IGEgVFVS TiBzZXJ2ZXIgd2hvc2UgYXV0aGVudGljaXR5IGNhbiBiZSBhc2NlcnRhaW5lZCBhbmQgY2FuIG9m ZmVyIElQIGFkZHJlc3MgcHJpdmFjeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0 Oy9zbmlwJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBUaGF0 IGNvbnNpZGVyYWJseSByZWR1Y2VzIHRoZSBhcHBsaWNhYmlsaXR5LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFIyXSBDbGllbnQgbG9va2luZyBmb3IgSVAg YWRkcmVzcyBwcml2YWN5IHNob3VsZCBnaXZlIGhpZ2hlciBwcmVjZWRlbmNlIHRvIGEgdHJ1c3Rl ZCBUVVJOIHNlcnZlciB0aGFuIHNvbWUgcmFuZG9tIFRVUk4gc2VydmVyIHdob3NlIGF1dGhlbnRp Y2l0eSBjYW5ub3QgYmUNCiBhc2NlcnRhaW5lZC4gV2Ugc2hvdWxkIGFsc28gY29uc2lkZXIgc2Nl bmFyaW9zIHdoZXJlIGF0dGFja2VycyBtYXkgZGVwbG95IFRVUk4gc2VydmVycy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwPkluc3RlYWQsIHdoeSBjYW4n dCB0aGUgY2xpZW50IHNpbXBseSByZXF1ZXN0IGFuIGFsbG9jYXRpb24sIHBlcmhhcHMgaW5kaWNh dGluZyBpdHMgZGVzaXJlIHRoYXQgdGhlIHJlbGF5ZWQgYWRkcmVzcyBiZSAmcXVvdDtmYXImcXVv dDsgZnJvbSBpdHMgb3duIHdpdGggYSBuZXcgb3B0aW9uYWwgYXR0cmlidXRlLCBhbmQgdGhlbiBh Y2NlcHQgb3IgcmVqZWN0IHRoZSBhbGxvY2F0aW9uIHVzaW5nIGl0cyBvd24gZ29vZCBqdWRnbWVu dDxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCjwvc3Bhbj4/PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSXSBIb3cgdG8g bWVhc3VyZSDigJxmYXLigJ0gKHNhbWUgY29udGluZW50IGRpZmZlcmVudCBjb3VudHJ5LCBkaWZm ZXJlbnQgY29udGluZW50KSA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV4YWN0bHkhIEhvdyBkb2VzIHRoZSBzZXJ2 ZXIgaXRzZWxmIGtub3cgaWYgaXQgY2FuIHByb3ZpZGUgcHJpdmFjeSwgaWYgZXZlbiB0aGUgY2xp ZW50IGNhbid0IHRlbGw8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+DQo8L3NwYW4+PzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5b VFJdIEFERFJFU1MtUFJJVkFDWSBhdHRyaWJ1dGUgY2FuIHByb2JhYmx5IGJlIGVuaGFuY2VkIHRv IGluZGljYXRlIHRoZSBsZXZlbCBvZiBwcml2YWN5IHJlcXVpcmVkLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGly dTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U2ltb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A35538EA8xmbrcdx10ciscoc_-- From nobody Wed Feb 4 08:45:56 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D173F1A1A8A for ; Wed, 4 Feb 2015 08:45:54 -0800 (PST) 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 Gxfxwl4yUVlj for ; Wed, 4 Feb 2015 08:45:51 -0800 (PST) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209D01A1A19 for ; Wed, 4 Feb 2015 08:45:51 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id la4so889354vcb.10 for ; Wed, 04 Feb 2015 08:45:50 -0800 (PST) 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=LTNbY9xu8NLBXYf+r0P8DuDbrU2uKISh4rPkbwTQzgw=; b=NmjiJSqxN9Z4WnKBX3YrqvdEV6OQYfh26hjKe/1PZUU7MU2nHK0L+yGNOl078qksjb iCrCWvsh1LYwOyyRvq+YvfTqSDBEisjVh2rTup+R4lofdFu/nUSlLvOOIPmqfGfmNAuA PbPHfQOwFN8eej6jyIxplmdu/ei5ZizN2rw/YmkstD3as86raoVnPnGhxsnIRE88qNjd DmLVzvPeRYR3av6mk6M3Sk/iEbFca1e5Hz79Kmh6WbkwWCm3pu/646rWaDI+bjp8+4Bc 8JAkgE7lbNgk1h/s07LQsgcnUybUJqrdQ9k4SR4jA3YKBt8TvGJuOtQLE78wL4vne//o CsSg== X-Gm-Message-State: ALoCoQmMb6hJQuWY/fNZQYdZYMrQtTiIAA5al4N+TdJyqunE8Db2WLmwLdRMILND567nirkNFqQL X-Received: by 10.52.183.164 with SMTP id en4mr1537570vdc.61.1423068350330; Wed, 04 Feb 2015 08:45:50 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com. [209.85.220.170]) by mx.google.com with ESMTPSA id 7sm314886vdl.2.2015.02.04.08.45.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Feb 2015 08:45:49 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id kv7so903282vcb.1 for ; Wed, 04 Feb 2015 08:45:49 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.220.202.10 with SMTP id fc10mr18426409vcb.8.1423068349110; Wed, 04 Feb 2015 08:45:49 -0800 (PST) Received: by 10.52.54.194 with HTTP; Wed, 4 Feb 2015 08:45:48 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A35538E3D@xmb-rcd-x10.cisco.com> References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35538E3D@xmb-rcd-x10.cisco.com> Date: Wed, 4 Feb 2015 11:45:49 -0500 Message-ID: From: Benjamin Schwartz To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a11c1bb0870c1c5050e45ebeb Archived-At: Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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, 04 Feb 2015 16:45:55 -0000 --001a11c1bb0870c1c5050e45ebeb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 4, 2015 at 11:11 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Inline [TR] > > > > *From:* Benjamin Schwartz [mailto:bemasc@webrtc.org] > *Sent:* Wednesday, February 04, 2015 9:16 PM > *To:* Simon Perreault > *Cc:* Tirumaleswar Reddy (tireddy); tram@ietf.org > *Subject:* Re: [tram] FW: New Version Notification for > draft-reddy-tram-turn-ipaddress-privacy-00.txt > > > > I agree with Simon. > > > > 1. IP address privacy is not representable as a binary. See > http://en.wikipedia.org/wiki/Degree_of_anonymity > > > > [TR] It is only offering IP address privacy from remote peer. > I disagree with your conception of the problem. I think the real goal here is to achieve some degree of anonymity, assuming that the TURN server is trusted not to reveal its mapping table (and the adversary cannot deduce it). To achieve this, you must choose a TURN server that is not traceable to the aspect of your identity that you are trying to obscure. For example, if you are trying to conceal your IP address, then this TURN server must not imply your IP address. If you are trying to conceal your corporate affiliation, this TURN server must not be associated with your corporation. If you are trying to conceal your location on the planet, this TURN server must must be used by users on all continents ... etc. Given the wide variety of trust relationships and privacy goals held by users, the only reasonable approach here is to let the user select a TURN server that they trust explicitly. Such a configuration might happen by enterprise policy (in the same way that software can be installed on all workstations at an office), but network-level autoconfiguration does not indicate sufficient trust. > 2. This system actually _reduces_ privacy: > > > If the server determines that the relayed address it will allocate and > client IP address are in the same geolocation then the server will redire= ct > the client to another server > > > > This behavior provides me nonzero information about your location: you > cannot be at the location indicated by the allocated IP address. > > > > [TR] The relayed address is not allocated by the TURN server, it redirect= s > the client to a different TURN server that can offer IP address privacy. > Presumably the client is intended to ask the second server for address privacy as well, in which case that server will also redirect if the IP addresses match. The result is an information leak, albeit a small one. Perhaps more importantly, the procedure can easily fail, leaving the client to explain to the user that all attempts to find a privacy-promising intermediary have failed. > > > (Even Simon's proposal here actually _increases_ address information > leakage. The minimal-leakage strategy is to use a fixed/random address th= at > might occasionally be close to your real address, by chance.) > > > > 3. "Same geolocation" is not a well-defined concept. There are a > multitude of corporations with different, contradictory geolocation > databases of varying quality. > > > > [TR] Geolocation is well-defined concept already used by firewalls from > various vendors to make effective blocking decisions. > "Effective" perhaps, but not "reliable". Systems that promise privacy to users must be "reliable": they must never fail, because they are entrusted with a task of grave significance. I am not willing to bet the user's privacy on the accuracy of some arbitrary TURN server's geolocation database, which will likely be poorly implemented, incomplete, and out of date. > > > 4. I presume that the goal here is to allow building privacy-preserving > communications systems, but this draft does not make that possible, becau= se > anyone setting up a privacy-preserving chat system cannot trust an > arbitrary enterprise-configured TURN server to be privacy-preserving, jus= t > because that server claims to preserve privacy. > > > > [TR] Enterprise configured TURN server is not an arbitrary server. > Typically users trust Enterprise firewall and it act as HTTP(S) proxy, in > the same lines Enterprise TURN server can also be trusted when it claims = it > can provide privacy. > I agree that there exist situations where a trust relationship exists between the TURN server operator and the user, but not all TURN autodiscovery implementations have this property. For example, it is likely that some ISPs will provide TURN servers via autodiscovery, but I certainly would not trust my ISP to safeguard my privacy in any way. > > > -Tiru > > > > On Wed, Feb 4, 2015 at 10:42 AM, Simon Perreault > wrote: > > Thanks for writing this. > > After a quick read, I am skeptical. I doubt any client would trust any > assertion from an a priori unknown TURN server about its available privac= y > capabilities. > > Instead, why can't the client simply request an allocation, perhaps > indicating its desire that the relayed address be "far" from its own with= a > new optional attribute, and then accept or reject the allocation using it= s > own good judgment? > > Simon > > Le 2015-02-04 08:25, "Tirumaleswar Reddy (tireddy)" a > =C3=A9crit : > > > > This draft describes a means for an client to discover that the TURN > server can provide IP address privacy. > Comments and suggestions are welcome. > > -Tiru > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, February 04, 2015 8:54 PM > To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Tirumaleswa= r > Reddy (tireddy); Prashanth Patil (praspati) > Subject: New Version Notification for > draft-reddy-tram-turn-ipaddress-privacy-00.txt > > > A new version of I-D, draft-reddy-tram-turn-ipaddress-privacy-00.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the > IETF repository. > > Name: draft-reddy-tram-turn-ipaddress-privacy > Revision: 00 > Title: IP address privacy by TURN server > Document date: 2015-02-04 > Group: Individual Submission > Pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-ipaddress-priva= cy-00.txt > Status: > https://datatracker.ietf.org/doc/draft-reddy-tram-turn-ipaddress-privacy/ > Htmlized: > http://tools.ietf.org/html/draft-reddy-tram-turn-ipaddress-privacy-00 > > > Abstract: > A TURN server allocates an IP address for a user. If this address is > dis-associated from the user's actual network, the allocated IP > address increases the user's privacy. This document describes a > means for an client to discover that the TURN server can provide IP > address privacy. > > > > > 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 > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > --001a11c1bb0870c1c5050e45ebeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 4, 2015 at 11:11 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.c= om> wrote:

Inline [TR]=

=C2=A0

From: Benjamin= Schwartz [mailto:be= masc@webrtc.org]
Sent: Wednesday, February 04, 2015 9:16 PM
To: Simon Perreault
Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tra= m-turn-ipaddress-privacy-00.txt

=C2=A0

I agree with Simon.

=C2=A0

1. IP address privacy is not representable a= s a binary.=C2=A0 See=C2=A0http://en.wikipedia.org/wiki/Degree_of_anony= mity

=C2=A0

[TR] It is only offering = IP address privacy from remote peer.


I disagree with your conception of= the problem.

I think the real goal here is to ach= ieve some degree of anonymity, assuming that the TURN server is trusted not= to reveal its mapping table (and the adversary cannot deduce it).=C2=A0 To= achieve this, you must choose a TURN server that is not traceable to the a= spect of your identity that you are trying to obscure.=C2=A0 For example, i= f you are trying to conceal your IP address, then this TURN server must not= imply your IP address.=C2=A0 If you are trying to conceal your corporate a= ffiliation, this TURN server must not be associated with your corporation.= =C2=A0 If you are trying to conceal your location on the planet, this TURN = server must must be used by users on all continents ... etc.

=
Given the wide variety of trust relationships and privacy goals = held by users, the only reasonable approach here is to let the user select = a TURN server that they trust explicitly.=C2=A0 Such a configuration might = happen by enterprise policy (in the same way that software can be installed= on all workstations at an office), but network-level autoconfiguration doe= s not indicate sufficient trust.
=C2=A0
<= div>

<= /u>

2. This system actually _reduces_ privacy:

> If the server determines that the relayed= address it will allocate and client IP address are in the same geolocation= then the server will redirect the client to another server<= u>

=C2=A0

This behavior provides me nonzero information = about your location: you cannot be at the location indicated by the allocat= ed IP address.

=C2=A0

[TR] The relayed a= ddress is not allocated by the TURN server, it redirects the client to a di= fferent TURN server that can offer IP address privacy.


Presumably the c= lient is intended to ask the second server for address privacy as well, in = which case that server will also redirect if the IP addresses match.=C2=A0 = The result is an information leak, albeit a small one.=C2=A0 Perhaps more i= mportantly, the procedure can easily fail, leaving the client to explain to= the user that all attempts to find a privacy-promising intermediary have f= ailed.
=C2=A0

=C2=A0

(Even Simon's proposal here actually _incr= eases_ address information leakage. The minimal-leakage strategy is to use = a fixed/random address that might occasionally be close to your real address, by chance.)

=C2=A0

3. "Same geolocation" is not a wel= l-defined concept.=C2=A0 There are a multitude of corporations with differe= nt, contradictory geolocation databases of varying quality.

=C2=A0

[TR] Geolocation i= s well-defined concept already used by firewalls from various vendors to ma= ke effective blocking decisions.


"Effective" perhaps, but not= "reliable".=C2=A0 Systems that promise privacy to users must be = "reliable": they must never fail, because they are entrusted with= a task of grave significance.=C2=A0 I am not willing to bet the user's= privacy on the accuracy of some arbitrary TURN server's geolocation da= tabase, which will likely be poorly implemented, incomplete, and out of dat= e.
=C2=A0

=C2=A0

4. I presume that the goal here is to allow = building privacy-preserving communications systems, but this draft does not= make that possible, because anyone setting up a privacy-preserving chat system cannot trust an arbitrary enterprise-configured TURN server to= be privacy-preserving, just because that server claims to preserve privacy= .

=C2=A0

[TR] Enterprise co= nfigured TURN server is not an arbitrary server. Typically users trust Ente= rprise firewall and it act as HTTP(S) proxy, in the same lines Enterprise TURN server can also be trusted when it claims it can provide p= rivacy.

I agree that there exist situations where a trust relationship = exists between the TURN server operator and the user, but not all TURN auto= discovery implementations have this property.=C2=A0 For example, it is like= ly that some ISPs will provide TURN servers via autodiscovery, but I certai= nly would not trust my ISP to safeguard my privacy in any way.
= =C2=A0

=C2=A0

-Tiru

=C2=A0

On Wed, Feb 4, 2015 at 10:42 AM, Simon Perreault <= ;sperreault@jive.c= om> wrote:

Thanks for writing this.

After a quick read, I am skeptical. I doubt any client would trust any a= ssertion from an a priori unknown TURN server about its available privacy c= apabilities.

Instead, why can't the client simply request an allocation, perhaps = indicating its desire that the relayed address be "far" from its = own with a new optional attribute, and then accept or reject the allocation= using its own good judgment?

Simon

Le 2015-02-04 08:25, "Tirumaleswar Reddy (tired= dy)" <tiredd= y@cisco.com> a =C3=A9crit :

=C2=A0

This draft describes a means for an client to discov= er that the TURN server can provide IP address privacy.
Comments and suggestions are welcome.

-Tiru

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, February 04, 2015 8:54 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Tirumaleswar = Reddy (tireddy); Prashanth Patil (praspati)
Subject: New Version Notification for draft-reddy-tram-turn-ipaddress-priva= cy-00.txt


A new version of I-D, draft-reddy-tram-turn-ipaddress-privacy-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-reddy-tram-turn-ipaddre= ss-privacy
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IP address privacy by TURN server<= br> Document date:=C2=A0 2015-02-04
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-ipaddress-privacy= -00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/draft-reddy-tram-turn-ipaddress-privacy/ Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.i= etf.org/html/draft-reddy-tram-turn-ipaddress-privacy-00


Abstract:
=C2=A0 =C2=A0A TURN server allocates an IP address for a user.=C2=A0 If thi= s address is
=C2=A0 =C2=A0dis-associated from the user's actual network, the allocat= ed IP
=C2=A0 =C2=A0address increases the user's privacy.=C2=A0 This document = describes a
=C2=A0 =C2=A0means for an client to discover that the TURN server can provi= de IP
=C2=A0 =C2=A0address privacy.




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

The IETF Secretariat

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


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

=C2=A0


--001a11c1bb0870c1c5050e45ebeb-- From nobody Wed Feb 4 09:15:26 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51DA1A898D for ; Wed, 4 Feb 2015 09:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvUvSdSQhqnA for ; Wed, 4 Feb 2015 09:15:20 -0800 (PST) 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 DC1881A1B59 for ; Wed, 4 Feb 2015 09:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43488; q=dns/txt; s=iport; t=1423070119; x=1424279719; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dptaK52t3ZHIpk8I0Hm9nP8HzfkvpSX5486kBwZdFRY=; b=UOLEvSs6ccex9sAsjFDOopFgIQJl8D5zTNCEMraLu9pk8fm36Oq7/Q24 UaRQZpFsPMuOMSyyJH0un1XbjL9513ratJs2Ct2EP4WziXCl6JOpzYk4K 1Hh3mLBBEwn735bVTWh+JzfmU/g/rAvl/pDmkIGAhHSq0KFFMByb6J08q A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C/BwDpUtJU/51dJa1RCAGCQ0NSWQSCfb0XPIFGGQELhW8CHIEAQwEBAQEBfYQMAQEBAwEBAQEgCkEEBQIFBwQCAQgOAwQBAQsPAgUBBgMCAgIlCxQIAQgCBA4FCAGIHAgNwDyWXgEBAQEBAQEBAQEBAQEBAQEBAQEBARePHSoPBxcEBgEGAx4BgkAugRMFiU+DXoFjg1CGcDaCTYJGiEaDPSKCMoE8bwGBAyQcfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,519,1418083200"; d="scan'208,217";a="120530690" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 04 Feb 2015 17:15:18 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t14HFI4s006700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Feb 2015 17:15:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Wed, 4 Feb 2015 11:15:18 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Benjamin Schwartz Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt Thread-Index: AQHQQI6WdUQVEuPT30i8U4lnHv84fZzgnDZwgABplACAAADzAP//nwEQgABxyYD//5vKQA== Date: Wed, 4 Feb 2015 17:15:17 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35538F91@xmb-rcd-x10.cisco.com> References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35538E3D@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.54.201] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35538F91xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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, 04 Feb 2015 17:15:24 -0000 --_000_913383AAA69FF945B8F946018B75898A35538F91xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUjJdDQoNCkZyb206IEJlbmphbWluIFNjaHdhcnR6IFttYWlsdG86YmVtYXNjQHdl YnJ0Yy5vcmddDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE1IDEwOjE2IFBNDQpU bzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KQ2M6IFNpbW9uIFBlcnJlYXVsdDsgdHJh bUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0cmFtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDAudHh0DQoN Ck9uIFdlZCwgRmViIDQsIDIwMTUgYXQgMTE6MTEgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGly ZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3Rl Og0KSW5saW5lIFtUUl0NCg0KRnJvbTogQmVuamFtaW4gU2Nod2FydHogW21haWx0bzpiZW1hc2NA d2VicnRjLm9yZzxtYWlsdG86YmVtYXNjQHdlYnJ0Yy5vcmc+XQ0KU2VudDogV2VkbmVzZGF5LCBG ZWJydWFyeSAwNCwgMjAxNSA5OjE2IFBNDQpUbzogU2ltb24gUGVycmVhdWx0DQpDYzogVGlydW1h bGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbdHJhbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2YWN5LTAwLnR4dA0KDQpJIGFncmVl IHdpdGggU2ltb24uDQoNCjEuIElQIGFkZHJlc3MgcHJpdmFjeSBpcyBub3QgcmVwcmVzZW50YWJs ZSBhcyBhIGJpbmFyeS4gIFNlZSBodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0RlZ3JlZV9v Zl9hbm9ueW1pdHkNCg0KW1RSXSBJdCBpcyBvbmx5IG9mZmVyaW5nIElQIGFkZHJlc3MgcHJpdmFj eSBmcm9tIHJlbW90ZSBwZWVyLg0KDQpJIGRpc2FncmVlIHdpdGggeW91ciBjb25jZXB0aW9uIG9m IHRoZSBwcm9ibGVtLg0KDQpJIHRoaW5rIHRoZSByZWFsIGdvYWwgaGVyZSBpcyB0byBhY2hpZXZl IHNvbWUgZGVncmVlIG9mIGFub255bWl0eSwgYXNzdW1pbmcgdGhhdCB0aGUgVFVSTiBzZXJ2ZXIg aXMgdHJ1c3RlZCBub3QgdG8gcmV2ZWFsIGl0cyBtYXBwaW5nIHRhYmxlIChhbmQgdGhlIGFkdmVy c2FyeSBjYW5ub3QgZGVkdWNlIGl0KS4gIFRvIGFjaGlldmUgdGhpcywgeW91IG11c3QgY2hvb3Nl IGEgVFVSTiBzZXJ2ZXIgdGhhdCBpcyBub3QgdHJhY2VhYmxlIHRvIHRoZSBhc3BlY3Qgb2YgeW91 ciBpZGVudGl0eSB0aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIG9ic2N1cmUuICBGb3IgZXhhbXBsZSwg aWYgeW91IGFyZSB0cnlpbmcgdG8gY29uY2VhbCB5b3VyIElQIGFkZHJlc3MsIHRoZW4gdGhpcyBU VVJOIHNlcnZlciBtdXN0IG5vdCBpbXBseSB5b3VyIElQIGFkZHJlc3MuICBJZiB5b3UgYXJlIHRy eWluZyB0byBjb25jZWFsIHlvdXIgY29ycG9yYXRlIGFmZmlsaWF0aW9uLCB0aGlzIFRVUk4gc2Vy dmVyIG11c3Qgbm90IGJlIGFzc29jaWF0ZWQgd2l0aCB5b3VyIGNvcnBvcmF0aW9uLiAgSWYgeW91 IGFyZSB0cnlpbmcgdG8gY29uY2VhbCB5b3VyIGxvY2F0aW9uIG9uIHRoZSBwbGFuZXQsIHRoaXMg VFVSTiBzZXJ2ZXIgbXVzdCBtdXN0IGJlIHVzZWQgYnkgdXNlcnMgb24gYWxsIGNvbnRpbmVudHMg Li4uIGV0Yy4NCg0KR2l2ZW4gdGhlIHdpZGUgdmFyaWV0eSBvZiB0cnVzdCByZWxhdGlvbnNoaXBz IGFuZCBwcml2YWN5IGdvYWxzIGhlbGQgYnkgdXNlcnMsIHRoZSBvbmx5IHJlYXNvbmFibGUgYXBw cm9hY2ggaGVyZSBpcyB0byBsZXQgdGhlIHVzZXIgc2VsZWN0IGEgVFVSTiBzZXJ2ZXIgdGhhdCB0 aGV5IHRydXN0IGV4cGxpY2l0bHkuICBTdWNoIGEgY29uZmlndXJhdGlvbiBtaWdodCBoYXBwZW4g YnkgZW50ZXJwcmlzZSBwb2xpY3kgKGluIHRoZSBzYW1lIHdheSB0aGF0IHNvZnR3YXJlIGNhbiBi ZSBpbnN0YWxsZWQgb24gYWxsIHdvcmtzdGF0aW9ucyBhdCBhbiBvZmZpY2UpLCBidXQgbmV0d29y ay1sZXZlbCBhdXRvY29uZmlndXJhdGlvbiBkb2VzIG5vdCBpbmRpY2F0ZSBzdWZmaWNpZW50IHRy dXN0Lg0KDQoyLiBUaGlzIHN5c3RlbSBhY3R1YWxseSBfcmVkdWNlc18gcHJpdmFjeToNCj4gSWYg dGhlIHNlcnZlciBkZXRlcm1pbmVzIHRoYXQgdGhlIHJlbGF5ZWQgYWRkcmVzcyBpdCB3aWxsIGFs bG9jYXRlIGFuZCBjbGllbnQgSVAgYWRkcmVzcyBhcmUgaW4gdGhlIHNhbWUgZ2VvbG9jYXRpb24g dGhlbiB0aGUgc2VydmVyIHdpbGwgcmVkaXJlY3QgdGhlIGNsaWVudCB0byBhbm90aGVyIHNlcnZl cg0KDQpUaGlzIGJlaGF2aW9yIHByb3ZpZGVzIG1lIG5vbnplcm8gaW5mb3JtYXRpb24gYWJvdXQg eW91ciBsb2NhdGlvbjogeW91IGNhbm5vdCBiZSBhdCB0aGUgbG9jYXRpb24gaW5kaWNhdGVkIGJ5 IHRoZSBhbGxvY2F0ZWQgSVAgYWRkcmVzcy4NCg0KW1RSXSBUaGUgcmVsYXllZCBhZGRyZXNzIGlz IG5vdCBhbGxvY2F0ZWQgYnkgdGhlIFRVUk4gc2VydmVyLCBpdCByZWRpcmVjdHMgdGhlIGNsaWVu dCB0byBhIGRpZmZlcmVudCBUVVJOIHNlcnZlciB0aGF0IGNhbiBvZmZlciBJUCBhZGRyZXNzIHBy aXZhY3kuDQoNClByZXN1bWFibHkgdGhlIGNsaWVudCBpcyBpbnRlbmRlZCB0byBhc2sgdGhlIHNl Y29uZCBzZXJ2ZXIgZm9yIGFkZHJlc3MgcHJpdmFjeSBhcyB3ZWxsLCBpbiB3aGljaCBjYXNlIHRo YXQgc2VydmVyIHdpbGwgYWxzbyByZWRpcmVjdCBpZiB0aGUgSVAgYWRkcmVzc2VzIG1hdGNoLiAg VGhlIHJlc3VsdCBpcyBhbiBpbmZvcm1hdGlvbiBsZWFrLCBhbGJlaXQgYSBzbWFsbCBvbmUuICBQ ZXJoYXBzIG1vcmUgaW1wb3J0YW50bHksIHRoZSBwcm9jZWR1cmUgY2FuIGVhc2lseSBmYWlsLCBs ZWF2aW5nIHRoZSBjbGllbnQgdG8gZXhwbGFpbiB0byB0aGUgdXNlciB0aGF0IGFsbCBhdHRlbXB0 cyB0byBmaW5kIGEgcHJpdmFjeS1wcm9taXNpbmcgaW50ZXJtZWRpYXJ5IGhhdmUgZmFpbGVkLg0K DQpbVFIyXSBBIHJlbGF5IHNlcnZpY2UgcHJvdmlkZXIgd2l0aCBhIGJyb2FkbHkgZGlzdHJpYnV0 ZWQgc3lzdGVtIGxpa2UgdGhlIG9uZSBkaXNjdXNzZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXdpbGxpYW1zLXBlZXItcmVkaXJlY3QtMDMgY2FuIHBpY2sgdGhlIHJpZ2h0 IFRVUk4gc2VydmVyIGF2b2lkaW5nIE5OTiBudW1iZXIgb2YgcmVkaXJlY3Rpb25zLg0KDQoNCihF dmVuIFNpbW9uJ3MgcHJvcG9zYWwgaGVyZSBhY3R1YWxseSBfaW5jcmVhc2VzXyBhZGRyZXNzIGlu Zm9ybWF0aW9uIGxlYWthZ2UuIFRoZSBtaW5pbWFsLWxlYWthZ2Ugc3RyYXRlZ3kgaXMgdG8gdXNl IGEgZml4ZWQvcmFuZG9tIGFkZHJlc3MgdGhhdCBtaWdodCBvY2Nhc2lvbmFsbHkgYmUgY2xvc2Ug dG8geW91ciByZWFsIGFkZHJlc3MsIGJ5IGNoYW5jZS4pDQoNCjMuICJTYW1lIGdlb2xvY2F0aW9u IiBpcyBub3QgYSB3ZWxsLWRlZmluZWQgY29uY2VwdC4gIFRoZXJlIGFyZSBhIG11bHRpdHVkZSBv ZiBjb3Jwb3JhdGlvbnMgd2l0aCBkaWZmZXJlbnQsIGNvbnRyYWRpY3RvcnkgZ2VvbG9jYXRpb24g ZGF0YWJhc2VzIG9mIHZhcnlpbmcgcXVhbGl0eS4NCg0KW1RSXSBHZW9sb2NhdGlvbiBpcyB3ZWxs LWRlZmluZWQgY29uY2VwdCBhbHJlYWR5IHVzZWQgYnkgZmlyZXdhbGxzIGZyb20gdmFyaW91cyB2 ZW5kb3JzIHRvIG1ha2UgZWZmZWN0aXZlIGJsb2NraW5nIGRlY2lzaW9ucy4NCg0KIkVmZmVjdGl2 ZSIgcGVyaGFwcywgYnV0IG5vdCAicmVsaWFibGUiLiAgU3lzdGVtcyB0aGF0IHByb21pc2UgcHJp dmFjeSB0byB1c2VycyBtdXN0IGJlICJyZWxpYWJsZSI6IHRoZXkgbXVzdCBuZXZlciBmYWlsLCBi ZWNhdXNlIHRoZXkgYXJlIGVudHJ1c3RlZCB3aXRoIGEgdGFzayBvZiBncmF2ZSBzaWduaWZpY2Fu Y2UuICBJIGFtIG5vdCB3aWxsaW5nIHRvIGJldCB0aGUgdXNlcidzIHByaXZhY3kgb24gdGhlIGFj Y3VyYWN5IG9mIHNvbWUgYXJiaXRyYXJ5IFRVUk4gc2VydmVyJ3MgZ2VvbG9jYXRpb24gZGF0YWJh c2UsIHdoaWNoIHdpbGwgbGlrZWx5IGJlIHBvb3JseSBpbXBsZW1lbnRlZCwgaW5jb21wbGV0ZSwg YW5kIG91dCBvZiBkYXRlLg0KDQpbVFIyXSBUVVJOIHNlcnZpY2UgcHJvdmlkZXIgY2FuIG9mZmVy IHByaXZhY3kgYXMgZmVhdHVyZSB0byBjdXN0b21lcnMsIGluIHdoaWNoIGNhc2UgaXQgaGFzIFNM QSB0byBwcm92aWRlIHJlbGlhYmxlIHByaXZhY3kuIEl04oCZcyB2ZXJ5IHNpbWlsYXIgdG8gd2F5 IENsb3VkIGJhc2VkIFNlY3VyaXR5IGFzIGEgc2VydmljZSAoU2FhUykgaXMgb2ZmZXJlZCBhbmQg dGhlIEVudGVycHJpc2UgZW50ZXJzIGludG8gYW4gYWdyZWVtZW50IHdpdGggU2FhUyBmb3IgcHJp dmFjeSwgZGF0YSBsZWFrYWdlIHByZXZlbnRpb24gZXRjLg0KVFVSTiBjbGllbnQgY2FuIGFsc28g ZG8gdGhlIHZhbGlkYXRpb24gYnkgaXRzZWxmIHRvIGNoZWNrIGlmIHRoZSBnZW9sb2NhdGlvbiBv ZiB0aGUgcmVsYXllZCBhZGRyZXNzIG1hdGNoZXMgZW5kcG9pbnRzIGdlb2xvY2F0aW9uLg0KDQoN CjQuIEkgcHJlc3VtZSB0aGF0IHRoZSBnb2FsIGhlcmUgaXMgdG8gYWxsb3cgYnVpbGRpbmcgcHJp dmFjeS1wcmVzZXJ2aW5nIGNvbW11bmljYXRpb25zIHN5c3RlbXMsIGJ1dCB0aGlzIGRyYWZ0IGRv ZXMgbm90IG1ha2UgdGhhdCBwb3NzaWJsZSwgYmVjYXVzZSBhbnlvbmUgc2V0dGluZyB1cCBhIHBy aXZhY3ktcHJlc2VydmluZyBjaGF0IHN5c3RlbSBjYW5ub3QgdHJ1c3QgYW4gYXJiaXRyYXJ5IGVu dGVycHJpc2UtY29uZmlndXJlZCBUVVJOIHNlcnZlciB0byBiZSBwcml2YWN5LXByZXNlcnZpbmcs IGp1c3QgYmVjYXVzZSB0aGF0IHNlcnZlciBjbGFpbXMgdG8gcHJlc2VydmUgcHJpdmFjeS4NCg0K W1RSXSBFbnRlcnByaXNlIGNvbmZpZ3VyZWQgVFVSTiBzZXJ2ZXIgaXMgbm90IGFuIGFyYml0cmFy eSBzZXJ2ZXIuIFR5cGljYWxseSB1c2VycyB0cnVzdCBFbnRlcnByaXNlIGZpcmV3YWxsIGFuZCBp dCBhY3QgYXMgSFRUUChTKSBwcm94eSwgaW4gdGhlIHNhbWUgbGluZXMgRW50ZXJwcmlzZSBUVVJO IHNlcnZlciBjYW4gYWxzbyBiZSB0cnVzdGVkIHdoZW4gaXQgY2xhaW1zIGl0IGNhbiBwcm92aWRl IHByaXZhY3kuDQoNCkkgYWdyZWUgdGhhdCB0aGVyZSBleGlzdCBzaXR1YXRpb25zIHdoZXJlIGEg dHJ1c3QgcmVsYXRpb25zaGlwIGV4aXN0cyBiZXR3ZWVuIHRoZSBUVVJOIHNlcnZlciBvcGVyYXRv ciBhbmQgdGhlIHVzZXIsIGJ1dCBub3QgYWxsIFRVUk4gYXV0b2Rpc2NvdmVyeSBpbXBsZW1lbnRh dGlvbnMgaGF2ZSB0aGlzIHByb3BlcnR5LiAgRm9yIGV4YW1wbGUsIGl0IGlzIGxpa2VseSB0aGF0 IHNvbWUgSVNQcyB3aWxsIHByb3ZpZGUgVFVSTiBzZXJ2ZXJzIHZpYSBhdXRvZGlzY292ZXJ5LCBi dXQgSSBjZXJ0YWlubHkgd291bGQgbm90IHRydXN0IG15IElTUCB0byBzYWZlZ3VhcmQgbXkgcHJp dmFjeSBpbiBhbnkgd2F5Lg0KDQpbVFJdIENsaWVudCBjb3VsZCBkaXNjb3ZlciBUVVJOIHNlcnZl ciBwcm92aWRlZCBieSBJU1AgYW5kIGxlYXJuIHRoZSBUVVJOIHNlcnZlciBvZmZlcmVkIGJ5IGFw cGxpY2F0aW9uIHNlcnZlci4gQnV0IHVzZXIgbWF5IG5vdCB0cnVzdCB0aGUgYXBwbGljYXRpb24g c2VydmVyIGFuZCB3b3VsZCB3YW50IHRvIGdvIHdpdGggdGhlIFRVUk4gc2VydmVyIHByb3ZpZGVk IGJ5IHRoZSBJU1AuDQoNCi1UaXJ1DQoNCi1UaXJ1DQoNCk9uIFdlZCwgRmViIDQsIDIwMTUgYXQg MTA6NDIgQU0sIFNpbW9uIFBlcnJlYXVsdCA8c3BlcnJlYXVsdEBqaXZlLmNvbTxtYWlsdG86c3Bl cnJlYXVsdEBqaXZlLmNvbT4+IHdyb3RlOg0KDQpUaGFua3MgZm9yIHdyaXRpbmcgdGhpcy4NCg0K QWZ0ZXIgYSBxdWljayByZWFkLCBJIGFtIHNrZXB0aWNhbC4gSSBkb3VidCBhbnkgY2xpZW50IHdv dWxkIHRydXN0IGFueSBhc3NlcnRpb24gZnJvbSBhbiBhIHByaW9yaSB1bmtub3duIFRVUk4gc2Vy dmVyIGFib3V0IGl0cyBhdmFpbGFibGUgcHJpdmFjeSBjYXBhYmlsaXRpZXMuDQoNCkluc3RlYWQs IHdoeSBjYW4ndCB0aGUgY2xpZW50IHNpbXBseSByZXF1ZXN0IGFuIGFsbG9jYXRpb24sIHBlcmhh cHMgaW5kaWNhdGluZyBpdHMgZGVzaXJlIHRoYXQgdGhlIHJlbGF5ZWQgYWRkcmVzcyBiZSAiZmFy IiBmcm9tIGl0cyBvd24gd2l0aCBhIG5ldyBvcHRpb25hbCBhdHRyaWJ1dGUsIGFuZCB0aGVuIGFj Y2VwdCBvciByZWplY3QgdGhlIGFsbG9jYXRpb24gdXNpbmcgaXRzIG93biBnb29kIGp1ZGdtZW50 Pw0KDQpTaW1vbg0KTGUgMjAxNS0wMi0wNCAwODoyNSwgIlRpcnVtYWxlc3dhciBSZWRkeSAodGly ZWRkeSkiIDx0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+PiBhIMOp Y3JpdCA6DQoNClRoaXMgZHJhZnQgZGVzY3JpYmVzIGEgbWVhbnMgZm9yIGFuIGNsaWVudCB0byBk aXNjb3ZlciB0aGF0IHRoZSBUVVJOIHNlcnZlciBjYW4gcHJvdmlkZSBJUCBhZGRyZXNzIHByaXZh Y3kuDQpDb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNCi1UaXJ1DQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8 bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz5dDQpTZW50OiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDA0LCAyMDE1IDg6NTQgUE0NClRvOiBQcmFzaGFudGggUGF0aWwgKHByYXNw YXRpKTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0 aXJlZGR5KTsgUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSkNClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2YWN5 LTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yZWRkeS10cmFtLXR1cm4t aXBhZGRyZXNzLXByaXZhY3ktMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnku DQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZh Y3kNClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgIElQIGFkZHJlc3MgcHJpdmFj eSBieSBUVVJOIHNlcnZlcg0KRG9jdW1lbnQgZGF0ZTogIDIwMTUtMDItMDQNCkdyb3VwOiAgICAg ICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICA2DQpVUkw6ICAgICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcmVkZHktdHJh bS10dXJuLWlwYWRkcmVzcy1wcml2YWN5LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlZGR5LXRyYW0tdHVybi1pcGFkZHJlc3Mt cHJpdmFjeS8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDANCg0KDQpBYnN0cmFjdDoNCiAg IEEgVFVSTiBzZXJ2ZXIgYWxsb2NhdGVzIGFuIElQIGFkZHJlc3MgZm9yIGEgdXNlci4gIElmIHRo aXMgYWRkcmVzcyBpcw0KICAgZGlzLWFzc29jaWF0ZWQgZnJvbSB0aGUgdXNlcidzIGFjdHVhbCBu ZXR3b3JrLCB0aGUgYWxsb2NhdGVkIElQDQogICBhZGRyZXNzIGluY3JlYXNlcyB0aGUgdXNlcidz IHByaXZhY3kuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhDQogICBtZWFucyBmb3IgYW4gY2xp ZW50IHRvIGRpc2NvdmVyIHRoYXQgdGhlIFRVUk4gc2VydmVyIGNhbiBwcm92aWRlIElQDQogICBh ZGRyZXNzIHByaXZhY3kuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxo dHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5nIGxp c3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1h aWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90cmFtDQoNCg0K --_000_913383AAA69FF945B8F946018B75898A35538F91xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SW5saW5lIFtUUjJdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IEJlbmphbWluIFNjaHdhcnR6IFttYWlsdG86YmVtYXNjQHdlYnJ0Yy5vcmddDQo8YnI+ DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNSAxMDoxNiBQTTxicj4N CjxiPlRvOjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCjxiPkNjOjwvYj4g U2ltb24gUGVycmVhdWx0OyB0cmFtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb dHJhbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmVkZHktdHJhbS10 dXJuLWlwYWRkcmVzcy1wcml2YWN5LTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDQsIDIw MTUgYXQgMTE6MTEgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0OzxhIGhyZWY9 Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PklubGluZSBbVFJdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBCZW5qYW1pbiBTY2h3YXJ0eiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpiZW1hc2NAd2Vi cnRjLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJlbWFzY0B3ZWJydGMub3JnPC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE1IDk6MTYgUE08YnI+DQo8Yj5U bzo8L2I+IFNpbW9uIFBlcnJlYXVsdDxicj4NCjxiPkNjOjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5 ICh0aXJlZGR5KTsgPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij4NCnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gRlc6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRk cmVzcy1wcml2YWN5LTAwLnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhZ3JlZSB3aXRoIFNpbW9uLjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MjIyMjIyIj4xLiBJUCBhZGRyZXNzIHByaXZhY3kgaXMgbm90IHJlcHJlc2VudGFibGUgYXMgYSBi aW5hcnkuJm5ic3A7IFNlZSZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dp a2kvRGVncmVlX29mX2Fub255bWl0eSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9lbi53aWtpcGVk aWEub3JnL3dpa2kvRGVncmVlX29mX2Fub255bWl0eTwvYT48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0gSXQgaXMg b25seSBvZmZlcmluZyBJUCBhZGRyZXNzIHByaXZhY3kgZnJvbSByZW1vdGUgcGVlci48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRpc2FncmVlIHdpdGggeW91 ciBjb25jZXB0aW9uIG9mIHRoZSBwcm9ibGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZSByZWFsIGdvYWwgaGVyZSBpcyB0 byBhY2hpZXZlIHNvbWUgZGVncmVlIG9mIGFub255bWl0eSwgYXNzdW1pbmcgdGhhdCB0aGUgVFVS TiBzZXJ2ZXIgaXMgdHJ1c3RlZCBub3QgdG8gcmV2ZWFsIGl0cyBtYXBwaW5nIHRhYmxlIChhbmQg dGhlIGFkdmVyc2FyeSBjYW5ub3QgZGVkdWNlIGl0KS4mbmJzcDsgVG8gYWNoaWV2ZSB0aGlzLCB5 b3UgbXVzdCBjaG9vc2UgYSBUVVJOIHNlcnZlciB0aGF0IGlzIG5vdA0KIHRyYWNlYWJsZSB0byB0 aGUgYXNwZWN0IG9mIHlvdXIgaWRlbnRpdHkgdGhhdCB5b3UgYXJlIHRyeWluZyB0byBvYnNjdXJl LiZuYnNwOyBGb3IgZXhhbXBsZSwgaWYgeW91IGFyZSB0cnlpbmcgdG8gY29uY2VhbCB5b3VyIElQ IGFkZHJlc3MsIHRoZW4gdGhpcyBUVVJOIHNlcnZlciBtdXN0IG5vdCBpbXBseSB5b3VyIElQIGFk ZHJlc3MuJm5ic3A7IElmIHlvdSBhcmUgdHJ5aW5nIHRvIGNvbmNlYWwgeW91ciBjb3Jwb3JhdGUg YWZmaWxpYXRpb24sIHRoaXMgVFVSTiBzZXJ2ZXINCiBtdXN0IG5vdCBiZSBhc3NvY2lhdGVkIHdp dGggeW91ciBjb3Jwb3JhdGlvbi4mbmJzcDsgSWYgeW91IGFyZSB0cnlpbmcgdG8gY29uY2VhbCB5 b3VyIGxvY2F0aW9uIG9uIHRoZSBwbGFuZXQsIHRoaXMgVFVSTiBzZXJ2ZXIgbXVzdCBtdXN0IGJl IHVzZWQgYnkgdXNlcnMgb24gYWxsIGNvbnRpbmVudHMgLi4uIGV0Yy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2l2ZW4gdGhlIHdpZGUgdmFy aWV0eSBvZiB0cnVzdCByZWxhdGlvbnNoaXBzIGFuZCBwcml2YWN5IGdvYWxzIGhlbGQgYnkgdXNl cnMsIHRoZSBvbmx5IHJlYXNvbmFibGUgYXBwcm9hY2ggaGVyZSBpcyB0byBsZXQgdGhlIHVzZXIg c2VsZWN0IGEgVFVSTiBzZXJ2ZXIgdGhhdCB0aGV5IHRydXN0IGV4cGxpY2l0bHkuJm5ic3A7IFN1 Y2ggYSBjb25maWd1cmF0aW9uIG1pZ2h0IGhhcHBlbiBieSBlbnRlcnByaXNlIHBvbGljeQ0KIChp biB0aGUgc2FtZSB3YXkgdGhhdCBzb2Z0d2FyZSBjYW4gYmUgaW5zdGFsbGVkIG9uIGFsbCB3b3Jr c3RhdGlvbnMgYXQgYW4gb2ZmaWNlKSwgYnV0IG5ldHdvcmstbGV2ZWwgYXV0b2NvbmZpZ3VyYXRp b24gZG9lcyBub3QgaW5kaWNhdGUgc3VmZmljaWVudCB0cnVzdC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMjIyMjIyIj4yLiBUaGlzIHN5c3RlbSBhY3R1YWxseSBfcmVkdWNlc18gcHJpdmFjeTo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7IElmIHRoZSBzZXJ2ZXIgZGV0ZXJtaW5lcyB0 aGF0IHRoZSByZWxheWVkIGFkZHJlc3MgaXQgd2lsbCBhbGxvY2F0ZSBhbmQgY2xpZW50IElQIGFk ZHJlc3MgYXJlIGluIHRoZSBzYW1lIGdlb2xvY2F0aW9uDQogdGhlbiB0aGUgc2VydmVyIHdpbGwg cmVkaXJlY3QgdGhlIGNsaWVudCB0byBhbm90aGVyIHNlcnZlcjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzIyMjIyMiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhpcyBiZWhhdmlvciBw cm92aWRlcyBtZSBub256ZXJvIGluZm9ybWF0aW9uIGFib3V0IHlvdXIgbG9jYXRpb246IHlvdSBj YW5ub3QgYmUgYXQgdGhlIGxvY2F0aW9uIGluZGljYXRlZCBieSB0aGUgYWxsb2NhdGVkDQogSVAg YWRkcmVzcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFJdIFRoZSByZWxheWVkIGFkZHJlc3MgaXMgbm90IGFs bG9jYXRlZCBieSB0aGUgVFVSTiBzZXJ2ZXIsIGl0IHJlZGlyZWN0cyB0aGUgY2xpZW50IHRvIGEg ZGlmZmVyZW50DQogVFVSTiBzZXJ2ZXIgdGhhdCBjYW4gb2ZmZXIgSVAgYWRkcmVzcyBwcml2YWN5 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlByZXN1bWFibHkgdGhlIGNsaWVudCBpcyBpbnRlbmRlZCB0byBhc2sgdGhlIHNlY29uZCBz ZXJ2ZXIgZm9yIGFkZHJlc3MgcHJpdmFjeSBhcyB3ZWxsLCBpbiB3aGljaCBjYXNlIHRoYXQgc2Vy dmVyIHdpbGwgYWxzbyByZWRpcmVjdCBpZiB0aGUgSVAgYWRkcmVzc2VzIG1hdGNoLiZuYnNwOyBU aGUgcmVzdWx0IGlzIGFuIGluZm9ybWF0aW9uIGxlYWssIGFsYmVpdCBhIHNtYWxsIG9uZS4mbmJz cDsgUGVyaGFwcyBtb3JlIGltcG9ydGFudGx5LA0KIHRoZSBwcm9jZWR1cmUgY2FuIGVhc2lseSBm YWlsLCBsZWF2aW5nIHRoZSBjbGllbnQgdG8gZXhwbGFpbiB0byB0aGUgdXNlciB0aGF0IGFsbCBh dHRlbXB0cyB0byBmaW5kIGEgcHJpdmFjeS1wcm9taXNpbmcgaW50ZXJtZWRpYXJ5IGhhdmUgZmFp bGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5bVFIyXSBBIHJlbGF5IHNlcnZpY2UgcHJvdmlkZXIgd2l0aCBhIGJyb2FkbHkgZGlz dHJpYnV0ZWQgc3lzdGVtIGxpa2UgdGhlIG9uZSBkaXNjdXNzZWQgaW4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXdpbGxpYW1zLXBlZXItcmVkaXJlY3QtMDMgY2FuIHBpY2sNCiB0 aGUgcmlnaHQgVFVSTiBzZXJ2ZXIgYXZvaWRpbmcgTk5OIG51bWJlciBvZiByZWRpcmVjdGlvbnMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPihFdmVuIFNpbW9uJ3MgcHJvcG9zYWwgaGVyZSBhY3R1YWxseSBfaW5j cmVhc2VzXyBhZGRyZXNzIGluZm9ybWF0aW9uIGxlYWthZ2UuIFRoZSBtaW5pbWFsLWxlYWthZ2Ug c3RyYXRlZ3kgaXMgdG8gdXNlIGENCiBmaXhlZC9yYW5kb20gYWRkcmVzcyB0aGF0IG1pZ2h0IG9j Y2FzaW9uYWxseSBiZSBjbG9zZSB0byB5b3VyIHJlYWwgYWRkcmVzcywgYnkgY2hhbmNlLik8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIy MiI+My4gJnF1b3Q7U2FtZSBnZW9sb2NhdGlvbiZxdW90OyBpcyBub3QgYSB3ZWxsLWRlZmluZWQg Y29uY2VwdC4mbmJzcDsgVGhlcmUgYXJlIGEgbXVsdGl0dWRlIG9mIGNvcnBvcmF0aW9ucyB3aXRo IGRpZmZlcmVudCwgY29udHJhZGljdG9yeQ0KIGdlb2xvY2F0aW9uIGRhdGFiYXNlcyBvZiB2YXJ5 aW5nIHF1YWxpdHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSXSBHZW9sb2NhdGlvbiBpcyB3ZWxsLWRlZmlu ZWQgY29uY2VwdCBhbHJlYWR5IHVzZWQgYnkgZmlyZXdhbGxzIGZyb20gdmFyaW91cyB2ZW5kb3Jz IHRvIG1ha2UgZWZmZWN0aXZlDQogYmxvY2tpbmcgZGVjaXNpb25zLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O0VmZmVjdGl2 ZSZxdW90OyBwZXJoYXBzLCBidXQgbm90ICZxdW90O3JlbGlhYmxlJnF1b3Q7LiZuYnNwOyBTeXN0 ZW1zIHRoYXQgcHJvbWlzZSBwcml2YWN5IHRvIHVzZXJzIG11c3QgYmUgJnF1b3Q7cmVsaWFibGUm cXVvdDs6IHRoZXkgbXVzdCBuZXZlciBmYWlsLCBiZWNhdXNlIHRoZXkgYXJlIGVudHJ1c3RlZCB3 aXRoIGEgdGFzayBvZiBncmF2ZSBzaWduaWZpY2FuY2UuJm5ic3A7IEkgYW0gbm90IHdpbGxpbmcg dG8gYmV0IHRoZSB1c2VyJ3MgcHJpdmFjeSBvbiB0aGUgYWNjdXJhY3kNCiBvZiBzb21lIGFyYml0 cmFyeSBUVVJOIHNlcnZlcidzIGdlb2xvY2F0aW9uIGRhdGFiYXNlLCB3aGljaCB3aWxsIGxpa2Vs eSBiZSBwb29ybHkgaW1wbGVtZW50ZWQsIGluY29tcGxldGUsIGFuZCBvdXQgb2YgZGF0ZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ W1RSMl0gVFVSTiBzZXJ2aWNlIHByb3ZpZGVyIGNhbiBvZmZlciBwcml2YWN5IGFzIGZlYXR1cmUg dG8gY3VzdG9tZXJzLCBpbiB3aGljaCBjYXNlIGl0IGhhcyBTTEEgdG8gcHJvdmlkZSByZWxpYWJs ZSBwcml2YWN5LiBJdOKAmXMgdmVyeSBzaW1pbGFyIHRvIHdheSBDbG91ZA0KIGJhc2VkIFNlY3Vy aXR5IGFzIGEgc2VydmljZSAoU2FhUykgaXMgb2ZmZXJlZCBhbmQgdGhlIEVudGVycHJpc2UgZW50 ZXJzIGludG8gYW4gYWdyZWVtZW50IHdpdGggU2FhUyBmb3IgcHJpdmFjeSwgZGF0YSBsZWFrYWdl IHByZXZlbnRpb24gZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VFVSTiBjbGllbnQgY2FuIGFsc28gZG8gdGhlIHZhbGlkYXRp b24gYnkgaXRzZWxmIHRvIGNoZWNrIGlmIHRoZSBnZW9sb2NhdGlvbiBvZiB0aGUgcmVsYXllZCBh ZGRyZXNzIG1hdGNoZXMgZW5kcG9pbnRzIGdlb2xvY2F0aW9uLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMyMjIyMjIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+ NC4gSSBwcmVzdW1lIHRoYXQgdGhlIGdvYWwgaGVyZSBpcyB0byBhbGxvdyBidWlsZGluZyBwcml2 YWN5LXByZXNlcnZpbmcgY29tbXVuaWNhdGlvbnMgc3lzdGVtcywgYnV0IHRoaXMgZHJhZnQgZG9l cw0KIG5vdCBtYWtlIHRoYXQgcG9zc2libGUsIGJlY2F1c2UgYW55b25lIHNldHRpbmcgdXAgYSBw cml2YWN5LXByZXNlcnZpbmcgY2hhdCBzeXN0ZW0gY2Fubm90IHRydXN0IGFuIGFyYml0cmFyeSBl bnRlcnByaXNlLWNvbmZpZ3VyZWQgVFVSTiBzZXJ2ZXIgdG8gYmUgcHJpdmFjeS1wcmVzZXJ2aW5n LCBqdXN0IGJlY2F1c2UgdGhhdCBzZXJ2ZXIgY2xhaW1zIHRvIHByZXNlcnZlIHByaXZhY3kuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+W1RSXSBFbnRlcnByaXNlIGNvbmZpZ3VyZWQgVFVSTiBzZXJ2ZXIgaXMgbm90 IGFuIGFyYml0cmFyeSBzZXJ2ZXIuIFR5cGljYWxseSB1c2VycyB0cnVzdCBFbnRlcnByaXNlDQog ZmlyZXdhbGwgYW5kIGl0IGFjdCBhcyBIVFRQKFMpIHByb3h5LCBpbiB0aGUgc2FtZSBsaW5lcyBF bnRlcnByaXNlIFRVUk4gc2VydmVyIGNhbiBhbHNvIGJlIHRydXN0ZWQgd2hlbiBpdCBjbGFpbXMg aXQgY2FuIHByb3ZpZGUgcHJpdmFjeS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRoYXQgdGhlcmUgZXhpc3Qgc2l0dWF0 aW9ucyB3aGVyZSBhIHRydXN0IHJlbGF0aW9uc2hpcCBleGlzdHMgYmV0d2VlbiB0aGUgVFVSTiBz ZXJ2ZXIgb3BlcmF0b3IgYW5kIHRoZSB1c2VyLCBidXQgbm90IGFsbCBUVVJOIGF1dG9kaXNjb3Zl cnkgaW1wbGVtZW50YXRpb25zIGhhdmUgdGhpcyBwcm9wZXJ0eS4mbmJzcDsgRm9yIGV4YW1wbGUs IGl0IGlzIGxpa2VseSB0aGF0IHNvbWUgSVNQcyB3aWxsIHByb3ZpZGUNCiBUVVJOIHNlcnZlcnMg dmlhIGF1dG9kaXNjb3ZlcnksIGJ1dCBJIGNlcnRhaW5seSB3b3VsZCBub3QgdHJ1c3QgbXkgSVNQ IHRvIHNhZmVndWFyZCBteSBwcml2YWN5IGluIGFueSB3YXkuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5bVFJdIENsaWVudCBjb3VsZCBkaXNjb3ZlciBUVVJOIHNlcnZlciBwcm92aWRlZCBieSBJ U1AgYW5kIGxlYXJuIHRoZSBUVVJOIHNlcnZlciBvZmZlcmVkIGJ5IGFwcGxpY2F0aW9uIHNlcnZl ci4gQnV0IHVzZXIgbWF5IG5vdCB0cnVzdCB0aGUgYXBwbGljYXRpb24gc2VydmVyDQogYW5kIHdv dWxkIHdhbnQgdG8gZ28gd2l0aCB0aGUgVFVSTiBzZXJ2ZXIgcHJvdmlkZWQgYnkgdGhlIElTUC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+T24gV2VkLCBGZWIgNCwgMjAxNSBhdCAxMDo0MiBBTSwgU2ltb24gUGVycmVhdWx0ICZsdDs8 YSBocmVmPSJtYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNwZXJy ZWF1bHRAaml2ZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwPlRoYW5rcyBm b3Igd3JpdGluZyB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPHA+QWZ0ZXIgYSBxdWljayByZWFkLCBJ IGFtIHNrZXB0aWNhbC4gSSBkb3VidCBhbnkgY2xpZW50IHdvdWxkIHRydXN0IGFueSBhc3NlcnRp b24gZnJvbSBhbiBhIHByaW9yaSB1bmtub3duIFRVUk4gc2VydmVyIGFib3V0IGl0cyBhdmFpbGFi bGUgcHJpdmFjeSBjYXBhYmlsaXRpZXMuPG86cD48L286cD48L3A+DQo8cD5JbnN0ZWFkLCB3aHkg Y2FuJ3QgdGhlIGNsaWVudCBzaW1wbHkgcmVxdWVzdCBhbiBhbGxvY2F0aW9uLCBwZXJoYXBzIGlu ZGljYXRpbmcgaXRzIGRlc2lyZSB0aGF0IHRoZSByZWxheWVkIGFkZHJlc3MgYmUgJnF1b3Q7ZmFy JnF1b3Q7IGZyb20gaXRzIG93biB3aXRoIGEgbmV3IG9wdGlvbmFsIGF0dHJpYnV0ZSwgYW5kIHRo ZW4gYWNjZXB0IG9yIHJlamVjdCB0aGUgYWxsb2NhdGlvbiB1c2luZyBpdHMgb3duIGdvb2QganVk Z21lbnQ/PG86cD48L286cD48L3A+DQo8cD5TaW1vbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+TGUgMjAxNS0wMi0wNCAwODoyNSwgJnF1b3Q7VGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0OyBhIMOpY3Jp dCA6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBkcmFmdCBkZXNjcmli ZXMgYSBtZWFucyBmb3IgYW4gY2xpZW50IHRvIGRpc2NvdmVyIHRoYXQgdGhlIFRVUk4gc2VydmVy IGNhbiBwcm92aWRlIElQIGFkZHJlc3MgcHJpdmFjeS48YnI+DQpDb21tZW50cyBhbmQgc3VnZ2Vz dGlvbnMgYXJlIHdlbGNvbWUuPGJyPg0KPGJyPg0KLVRpcnU8YnI+DQo8YnI+DQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+ IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT5dPGJyPg0KU2VudDogV2VkbmVz ZGF5LCBGZWJydWFyeSAwNCwgMjAxNSA4OjU0IFBNPGJyPg0KVG86IFByYXNoYW50aCBQYXRpbCAo cHJhc3BhdGkpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpOyBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTxicj4NClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVz cy1wcml2YWN5LTAwLnR4dDxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDAudHh0PGJyPg0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVkZHkgYW5kIHBvc3Rl ZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNz LXByaXZhY3k8YnI+DQpSZXZpc2lvbjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswMDxicj4N ClRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSVAgYWRkcmVzcyBwcml2 YWN5IGJ5IFRVUk4gc2VydmVyPGJyPg0KRG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNS0wMi0wNDxi cj4NCkdyb3VwOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBT dWJtaXNzaW9uPGJyPg0KUGFnZXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA2 PGJyPg0KVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJlZGR5LXRyYW0t dHVybi1pcGFkZHJlc3MtcHJpdmFjeS0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJlZGR5LXRyYW0tdHVybi1pcGFkZHJl c3MtcHJpdmFjeS0wMC50eHQ8L2E+PGJyPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3kvIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRk cmVzcy1wcml2YWN5LzwvYT48YnI+DQpIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS10cmFtLXR1 cm4taXBhZGRyZXNzLXByaXZhY3ktMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDA8L2E+ PGJyPg0KPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO0EgVFVSTiBzZXJ2 ZXIgYWxsb2NhdGVzIGFuIElQIGFkZHJlc3MgZm9yIGEgdXNlci4mbmJzcDsgSWYgdGhpcyBhZGRy ZXNzIGlzPGJyPg0KJm5ic3A7ICZuYnNwO2Rpcy1hc3NvY2lhdGVkIGZyb20gdGhlIHVzZXIncyBh Y3R1YWwgbmV0d29yaywgdGhlIGFsbG9jYXRlZCBJUDxicj4NCiZuYnNwOyAmbmJzcDthZGRyZXNz IGluY3JlYXNlcyB0aGUgdXNlcidzIHByaXZhY3kuJm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIGE8YnI+DQombmJzcDsgJm5ic3A7bWVhbnMgZm9yIGFuIGNsaWVudCB0byBkaXNjb3ZlciB0 aGF0IHRoZSBUVVJOIHNlcnZlciBjYW4gcHJvdmlkZSBJUDxicj4NCiZuYnNwOyAmbmJzcDthZGRy ZXNzIHByaXZhY3kuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50b29scy5p ZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyYW0g bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj50cmFtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A35538F91xmbrcdx10ciscoc_-- From nobody Wed Feb 4 09:26:00 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB12E1A1A6C; Wed, 4 Feb 2015 09:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-u63JqI-MIf; Wed, 4 Feb 2015 09:22:27 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2ED51A1A59; Wed, 4 Feb 2015 09:22:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14558; q=dns/txt; s=iport; t=1423070546; x=1424280146; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=QsBXMSsWm86v1jfcOxzr0lVdHGMmQKaZu1NACnZ0MO8=; b=PfiBRKrxTs7Zz0qsQcX7dCL2vQyaSr7IUEpdJrGHvnf/LVGhgOfRRSfd FEYyyYhR9HSp+76uCrHyMPZY3sT932m30Byq7EZjEjI1CE3POCgcPEOF0 LVCmIEE7HaG8ofDs+EDoENE9Lpv/qKCz2isYc+qcpujDpT0qRlEIhIugH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMFAB5U0lStJV2R/2dsb2JhbABagwaBKwSCfb0XiBYCHIEBQwEBAQEBfYQMAQEBAwEjEUUFBwYBCBEBAwEBAwIGHQMCBB8RFAECBgkBBAENBQiIEQMJCMBZkGQNhWsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGMLYF5MQ2CYi6BEwWFS4lFh2OCXYMDiCErgkCDPSKCAR2BUG8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,519,1418083200"; d="scan'208";a="390305881" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP; 04 Feb 2015 17:22:25 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t14HMP8J025284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Feb 2015 17:22:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 4 Feb 2015 11:22:25 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Tom Taylor , "ops-dir@ietf.org" , "Prashanth Patil (praspati)" , "Ram Mohan R (rmohanr)" , Justin Uberti , Gonzalo Camarillo , Spencer Dawkins , The IETF , "tram@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-tram-turn-third-party-authz-08 Thread-Index: AdBAnx9rp0ZT+ulbTzKs2J65LpUl4Q== Date: Wed, 4 Feb 2015 17:22:24 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35538FB4@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.54.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 04 Feb 2015 09:25:54 -0800 Cc: Christer Holmberg Subject: Re: [tram] OPS-DIR review of draft-ietf-tram-turn-third-party-authz-08 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, 04 Feb 2015 17:22:30 -0000 VGhhbmtzIFRvbSBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUb20gVGF5bG9yIFttYWlsdG86dG9tLnRheWxv ci5zdGRzQGdtYWlsLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNSAz OjM5IEFNDQo+IFRvOiBvcHMtZGlyQGlldGYub3JnOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVk ZHkpOyBQcmFzaGFudGggUGF0aWwNCj4gKHByYXNwYXRpKTsgUmFtIE1vaGFuIFIgKHJtb2hhbnIp OyBKdXN0aW4gVWJlcnRpOyBHb256YWxvIENhbWFyaWxsbzsNCj4gU3BlbmNlciBEYXdraW5zOyBU aGUgSUVURjsgdHJhbUBpZXRmLm9yZw0KPiBDYzogQ2hyaXN0ZXIgSG9sbWJlcmcNCj4gU3ViamVj dDogT1BTLURJUiByZXZpZXcgb2YgZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0 aHotMDgNCj4gDQo+IEkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHkt YXV0aHotMDggYXMgcGFydCBvZiB0aGUNCj4gT3BlcmF0aW9uYWwgZGlyZWN0b3JhdGUncyBvbmdv aW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nDQo+IHByb2Nlc3Nl ZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9y DQo+IHRoZSBiZW5lZml0IG9mIHRoZSBvcGVyYXRpb25hbCBhcmVhIGRpcmVjdG9ycy4gICBEb2N1 bWVudCBlZGl0b3JzIGFuZCBXRw0KPiBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRz IGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiANCj4gU3VtbWFyeTog VGhpcyBkb2N1bWVudCBoYXMgaW5jb25zaXN0ZW5jaWVzIHRoYXQgbmVlZCB0byBiZSBmaXhlZCBi ZWZvcmUgaXQNCj4gY2FuIGJlIHB1Ymxpc2hlZC4NCj4gDQo+IE9wZXJhdGlvbmFsIGlzc3VlczoN Cj4gDQo+IFRvIG1ha2UgdGhpcyBmZWF0dXJlIHdvcmssIHRoZSBmb2xsb3dpbmcgcHJlLWNvbmZp Z3VyYXRpb24gaXMgcmVxdWlyZWQ6DQo+IA0KPiBhLiBJbiBlYWNoIGF1dGhvcml6YXRpb24gc2Vy dmVyLCB0aGUgbGlzdCBvZiBTVFVOIGFuZCBUVVJOIHNlcnZlcnMgZm9yIHdoaWNoIGl0DQo+IHdp bGwgZ3JhbnQgdG9rZW5zLCBhbmQgdGhlIGxvbmctdGVybSBzZWNyZXQgc2hhcmVkIHdpdGggZWFj aA0KPiANCj4gYi4gU2ltaWxhcmx5LCBpbiBlYWNoIFNUVU4gb3IgVFVSTiBzZXJ2ZXIsIHRoZSBs aXN0IG9mIGF1dGhvcml6YXRpb24gc2VydmVycw0KPiBmcm9tIHdoaWNoIHRoZSBjbGllbnRzIG9m IHRoYXQgU1RVTiBvciBUVVJOIHNlcnZlciBtYXkgcmVxdWVzdCB0b2tlbnMsIGFuZA0KPiB0aGUg YXNzb2NpYXRlZCBsb25nLXRlcm0gc2VjcmV0Lg0KPiANCj4gYy4gSWYgbWFudWFsIGNvbmZpZ3Vy YXRpb24gKFNlY3Rpb24gNC4xLjMpIGlzIHVzZWQgdG8gZXN0YWJsaXNoIHN5bW1ldHJpYyBrZXlz LA0KPiB0aGUgbmVjZXNzYXJ5IGluZm9ybWF0aW9uIGhhcyB0byBiZSBjb25maWd1cmVkIG9uIGVh Y2ggYXV0aG9yaXphdGlvbiBzZXJ2ZXINCj4gYW5kIFNUVU4gb3IgVFVSTiBzZXJ2ZXIuIFRoZSBj bGllbnQgcHJlc3VtYWJseSBvYnRhaW5zIHRoZSBzZXNzaW9uIGtleSBhbmQNCj4gYWxnb3JpdGht IGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGluIGNvbXBhbnkgd2l0aCB0aGUgdG9rZW4u DQo+IA0KPiBJdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgYW4gT3BlcmF0aW9uYWwgQ29uc2lkZXJh dGlvbnMgc2VjdGlvbiBzdW1tYXJpemluZw0KPiB0aGlzIGluZm9ybWF0aW9uIGFuZCBhbnl0aGlu ZyBlbHNlIEkndmUgbWlzc2VkLg0KPiANCj4gSW4gdGVybXMgb2YgZGVwbG95bWVudCwgaW5jcmVt ZW50YWwgZGVwbG95bWVudCBpcyBwb3NzaWJsZSwgc2luY2UgZGVmYXVsdA0KPiBhY3Rpb24gaXMg c3BlY2lmaWVkIGluIHRoZSBkb2N1bWVudCBpZiBlaXRoZXIgdGhlIGNsaWVudCBvciBTVFVOIG9y IFRVUk4gc2VydmVyDQo+IGZhaWxzIHRvIHVuZGVyc3RhbmQgdGhlIGF0dHJpYnV0ZXMgZGVmaW5l ZCBpbiB0aGlzIGRvY3VtZW50LiBIb3dldmVyLCB0aGUNCj4gaW1wbGljYXRpb24gaW4gIk90aGVy IElzc3VlIiAzIGJlbG93IGlzIHRoYXQgdGhlICJzaG91bGQiIHNob3VsZCBiZSBhICJNVVNUIi4N Cg0KSSB3aWxsIGFkZCBPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHRvIHRoZSBk cmFmdC4NCg0KPiANCj4gT3RoZXIgaXNzdWVzOg0KPiANCj4gMS4gVGhlIHByb2NlZHVyZXMgYnkg d2hpY2ggdGhlIGNsaWVudCBvYnRhaW5zIHRoZSBPQXV0aCB0b2tlbiBhcmUgZGVjbGFyZWQNCj4g b3V0IG9mIHNjb3BlIChtaWRkbGUgb2YgZmlyc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gMyksIHll dCBhIGZhaXIgYW1vdW50IG9mIHRleHQNCj4gaW4gdGhlIGRvY3VtZW50IGRlYWxzIHdpdGggdGhp cyB0b3BpYy4gRWl0aGVyIHRoZSBkZWNsYXJhdGlvbiBvZiBzY29wZSBzaG91bGQNCj4gYmUgY2hh bmdlZCBvciB0aGUgZXhhbXBsZXMgb2YgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFu ZCB0aGUNCj4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlbGF0ZWQgZGV0YWlsZWQgcHJvY2Vk dXJhbCBzdGF0ZW1lbnRzIHNob3VsZCBiZQ0KPiBtb3ZlZCB0byBhbiBpbmZvcm1hdGl2ZSBhcHBl bmRpeC4NCg0KSWYgd2UgcmVtb3ZlIHRoZSBiZWxvdyBsaW5lLCB3b3VsZCB0aGF0IGFkZHJlc3Mg eW91ciBjb21tZW50ID8NCg0KIlRoZSBleGFjdCBtZWNoYW5pc20gdXNlZCBieSBhIGNsaWVudCB0 byBvYnRhaW4gYSB0b2tlbiBmcm9tIHRoZSBPQXV0aCBhdXRob3JpemF0aW9uIHNlcnZlciBpcyBv dXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiINCg0KDQo+IEZ1bmRhbWVudGFsbHkg dGhpcyBkb2N1bWVudCBpcyBub3QgYWJvdXQgV2ViUlRDIChldmVuIHRob3VnaCB0aGF0IGlzIHRo ZQ0KPiBwcmltYXJ5IGFwcGxpY2F0aW9uIHRoZSBhdXRob3JzIGhhdmUgaW4gbWluZCkgYW5kIHNv IFdlYlJUQyBoYXMgbm8gcGxhY2UNCj4gaW4gdGhlIGJvZHkgb2YgdGhlIGRvY3VtZW50LiBUaGUg cmV3cml0aW5nIHdvdWxkIGJlIGEgZmFpciBhbW91bnQgb2Ygd29yaywNCj4gYnV0IEkgd2lsbCB2 b2x1bnRlZXIgdG8gaGVscCByZXdvcmsgdGhlIHRleHQgaWYgbmVlZCBiZS4NCg0KV2ViUlRDIGlz IG9ubHkgdXNlZCBhbiBleGFtcGxlIGluIHRoaXMgZG9jdW1lbnQgdG8gZGVtb25zdHJhdGUgaXRz IHVzYWdlLiAgU1RVTiAocmZjNTM4OSkgYWxzbyByZWZlcmVuY2VzIFNJUCBpbiB2YXJpb3VzIHBs YWNlcy4gDQpQbGVhc2UgY2xhcmlmeSB3aHkgdGhpcyBpcyBhIGNvbmNlcm4gPw0KDQo+IA0KPiAy LiBUaGUgcGFyYWdyYXBoIGJlbG93IEZpZ3VyZSAyIGluIFNlY3Rpb24gMyB0YWxrcyBvZiBhIGZ1 dHVyZSBjYXBhYmlsaXR5LA0KPiBhbGdvcml0aG0gYWdpbGl0eS4gUGFydCBvZiB0aGUgZGVzY3Jp cHRpb24gbWVudGlvbnMgdGhhdCB0aGUgY2xpZW50IHNlbmRzIHRoZQ0KPiBpbnRlcnNlY3Rpb24g b2YgdGhlIGFsZ29yaXRobXMgY29tbW9uIHRvIGl0IGFuZCB0aGUgU1RVTiBzZXJ2ZXIgdG8gdGhl DQo+IGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGUgcmVhc29uIHRvIGRvIHRoaXMgZGVwZW5kcyBz cGVjaWZpY2FsbHkgb24gdGhlDQo+IHN0YXRlbWVudCB0aGF0IHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBnZW5lcmF0ZXMgdGhlIHNlc3Npb24ga2V5IGJldHdlZW4NCj4gdGhlIGNsaWVudCBhbmQg cmVzb3VyY2Ugc2VydmVyIGluIGRyYWZ0LWlldGYtb2F1dGgtcG9wLWtleS1kaXN0cmlidXRpb24g KHdoaWNoDQo+IEJUVyBpcyBleHBpcmVkKS4gSSBjYW4gc2VlIHRoZSBwb2ludCBvZiB0aGlzIHBh cmFncmFwaCBpbiBwcm92aWRpbmcgYSB3YXJuaW5nDQo+IHRvIGltcGxlbWVudG9ycywgYnV0IGl0 IGlzIHByb2JhYmx5IHRvbyBzcGVjdWxhdGl2ZSB1bmxlc3MgdGhlIGRlcGVuZGVkLQ0KPiB1cG9u IEktRHMgKHN0dW5iaXMgYW5kIG9hdXRoLXBvcC1rZXkpIGFyZSB2ZXJ5IGNsb3NlIHRvIGNvbXBs ZXRpb24uIEF0IHRoZQ0KPiBsZWFzdCwgdGhlIHNlbnRlbmNlIHJlbGF0aW5nIHRvIHRoZSBpbnRl cmFjdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kDQo+IGF1dGhvcml6YXRpb24gc2VydmVyIGNv dWxkIGJlIHJlbW92ZWQgb3IgbWFkZSBsZXNzIGRldGFpbGVkLiAoUmVsYXRlcyB0byB0aGUNCj4g Zmlyc3QgcG9pbnQgYWJvdmUuKQ0KDQpJdCBpcyBhZ3JlZWQgaW4gdGhlIFdHIHRoYXQgc3R1bmJp cyB3aWxsIGJlIHN1cHBvcnQgaGFzaCBhZ2lsaXR5IGFuZCB1c2UgdGhlIHRlY2huaXF1ZSBtZW50 aW9uZWQgaW4gdGhlIGRyYWZ0Lg0KVGhlIHBhcmFncmFwaCBiZWxvdyBGaWd1cmUgMiBpbiBTZWN0 aW9uIDMgaXMgb3V0Y29tZSBvZiB0aGUgZGlzY3Vzc2lvbi4NCg0KPiANCj4gMy4gVGhlIGZpcnN0 IHNlbnRlbmNlIG9mIFNlY3Rpb24gNCBoYXMgYSBsb3dlci1jYXNlICJzaG91bGQiLiBTaG91bGQg dGhpcyBiZQ0KPiAiU0hPVUxEIiBvciBwZXJoYXBzICJNVVNUIj8gDQoNCkNoYW5nZWQgdG8gIk1V U1QiDQoNCj4gSXQgd291bGQgYWxzbyBiZSBnb29kIHRvIGFkZCB0aGF0IHRoaXMNCj4ga25vd2xl ZGdlIG9mIHRoZSBTVFVOIHNlcnZlcidzIGF1dGhlbnRpY2F0aW9uIGNhcGFiaWxpdHkgbWF5IGJl IGF2YWlsYWJsZQ0KPiBwcmlvciB0byB0aGUgaW5pdGlhbCByZXF1ZXN0LCBvciBlbHNlIGl0IGlz IGFjcXVpcmVkIGZyb20gdGhlDQo+IDQwMSBVbmF1dGhvcml6ZWQgcmVzcG9uc2UgdG8gdGhlIGlu aXRpYWwgU1RVTiByZXF1ZXN0IGFzIGRlc2NyaWJlZCBiZWxvdy4NCj4gTWF5YmUgdGhlIGltcGxl bWVudGF0aW9uIG5vdGUgdW5kZXIgRmlndXJlIDEgYmVsb25ncyBkb3duIGhlcmUsIGF0IHRoZQ0K PiBtb3JlIGRldGFpbGVkIGxldmVsLCByYXRoZXIgdGhhbiBpbiB0aGUgb3ZlcnZpZXcgc2VjdGlv bi4NCg0KT2theSwgbW92ZWQgdGhlIG5vdGUgdG8gU2VjdGlvbiA0Lg0KDQo+IA0KPiA0LiBUaGUg ZGV0YWlsZWQgY2hvaWNlIG9mIGhvdyBzeW1tZXRyaWMga2V5IGVzdGFibGlzaG1lbnQgaXMgZG9u ZSBpcyBsZWZ0DQo+IG9wZW4gaW4gU2VjdGlvbiA0LjEuIFNob3VsZCB0aGVyZSBiZSBhIG1hbmRh dG9yeS10by1pbXBsZW1lbnQgY2hvaWNlID8NCg0KVGhlIGNvbnNlbnN1cyBpbiB0aGUgV0cgaXMg dG8ga2VlcCBzeW1tZXRyaWMga2V5IGVzdGFibGlzaG1lbnQgcHJvY2VkdXJlIG91dHNpZGUgc2Nv cGUgYW5kIG5vdCB0byBtYW5kYXRlIGFueSBzeW1tZXRyaWMga2V5IGVzdGFibGlzaG1lbnQgcHJv Y2VkdXJlLiBQbGVhc2Ugbm90ZSB0aGF0IHRoZSBkcmFmdCB3aWxsIGJlIHVwZGF0ZWQgaW4gdGhl IG5leHQgcmV2aXNpb24gdG8gdXNlIEVDQyB0byBhZGRyZXNzIHRoZSBjb21tZW50IGZyb20gWWFy b24gU2hlZmZlciBhcyBwYXJ0IG9mIFNlY0RpciByZXZpZXcNCk5FVzoNCkVsbGlwdGljIGN1cnZl IGNyeXB0b2dyYXBoeSAoRUNDKSB3aXRoIEVsbGlwdGljIEN1cnZlIERpZ2l0YWwgU2lnbmF0dXJl IEFsZ29yaXRobSAoRUNEU0EpIG9yIHN5bW1ldHJpYy1rZXkgYWxnb3JpdGhtIHdpdGggSGFzaCBi YXNlZCBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGVzIChITUFDcykgTVVTVCBiZSBjaG9zZW4g dG8gZW5zdXJlIHRoYXQgdGhlIHNpemUgb2YgZW5jcnlwdGVkIHRva2VuIGlzIG5vdCBsYXJnZSBi ZWNhdXNlIHVzYWdlIG9mIFJTQSB3aWxsIHJlc3VsdCBpbiBsYXJnZSBlbmNyeXB0ZWQgdG9rZW5z IHdoaWNoIG1heSBub3QgZml0IGludG8gYSBzaW5nbGUgU1RVTiBtZXNzYWdlLg0KDQo+IA0KPiA1 LiBQZXJoYXBzIGluIFNlY3Rpb24gNyB0aGVyZSBzaG91bGQgYmUgYSBub3RlIHRoYXQgaWYgYSBT VFVOIHNlcnZlciByZWNlaXZlcw0KPiBhbiBBQ0NFU1MtVE9LRU4gYXR0cmlidXRlIHVuZXhwZWN0 ZWRseSAoYmVjYXVzZSBpdCBoYWQgbm90IHByZXZpb3VzbHkgc2VudA0KPiBvdXQgYSBUSElSRC1Q QVJUWS1BVVRIT1JJWkFUSU9OKSwgaXQgd2lsbCByZXNwb25kIHdpdGggYW4gZXJyb3IgY29kZSBv Zg0KPiA0MjAgKFVua25vd24gQXR0cmlidXRlKSBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA3LjMu MSBvZiBSRkMgNTM4OS4NCg0KU2luY2UgQUNDRVNTLVRPS0VOIGlzIGFuIGNvbXByZWhlbnNpb24t b3B0aW9uYWwgYXR0cmlidXRlIGl0IGNhbiBiZSBpZ25vcmVkIGJ5IHRoZSBzZXJ2ZXIgYW5kIG5v IG5lZWQgcmV0dXJuIGVycm9yLg0KDQo+IA0KPiA2LiBJbiBTZWN0aW9uIDksIHNlY29uZCBidWxs ZXQsIGEgcGFyYW1ldGVyIERlbHRhIGlzIHNob3duIGJ1dCBubyBzdWdnZXN0ZWQNCj4gdmFsdWUg aXMgZ2l2ZW4uIFdvdWxkIHRoaXMgYmUgNSBzZWNvbmRzIGFzIGluIFNlY3Rpb24gNz8NCg0KWWVz LCBhZGRlZCB0aGUgcmVjb21tZW5kZWQgZGVsdGEgdmFsdWUgaW4gU2VjdGlvbiA3Lg0KDQo+IA0K PiBUb20gVGF5bG9yDQo+IA0KPiANCj4gTml0cy9lZGl0b3JpYWwgc3VnZ2VzdGlvbnMNCj4gPT09 PT09PT09PT09PT09PT09PT09PT09PT0NCg0KRml4ZWQgYWxsIHRoZSBiZWxvdyBlZGl0b3JpYWwg c3VnZ2VzdGlvbnMuDQoNClRoYW5rcyBhbmQgUmVnYXJkcywNCi1UaXJ1DQoNCj4gDQo+IEdlbmVy YWw6IG1pc3NpbmcgInRoZSJzIGFuZCBvY2Nhc2lvbmFsICJhInMgb3IgImFuInMgdGhyb3VnaG91 dCB0aGUNCj4gZG9jdW1lbnQuIEkgaW5kaWNhdGVkIGEgbnVtYmVyIG9mIHBsYWNlcyBidXQgZ290 IHRpcmVkIG9mIGRvaW5nIHNvDQo+IGV2ZW50dWFsbHkuIElmIGFic29sdXRlbHkgbmVjZXNzYXJ5 IEkgY291bGQgbWFyayB1cCBhIGNvcHkgb2YgdGhlIGRvY3VtZW50DQo+IHdpdGggdGhlIGFkZGl0 aW9ucy4NCj4gDQo+IDEpIEFic3RyYWN0Og0KPiANCj4gT0xEDQo+IA0KPiBUaGUgdXNhZ2Ugb2Yg ZXBoZW1lcmFsIHRva2VucyBlbnN1cmUNCj4gDQo+IE5FVw0KPiANCj4gVGhlIHVzZSBvZiBlcGhl bWVyYWwgdG9rZW5zIGVuc3VyZXMNCj4gDQo+IDIpIFNlY3Rpb24gMywgZmlyc3QgcGFyYWdyYXBo Og0KPiANCj4gSXQgbWlnaHQgYmUgZ29vZCB0byBhZGQgYSBwYXJhZ3JhcGggYmVmb3JlIHRoZSBw cmVzZW50IG9uZSwgc2F5aW5nIHRoYXQgdGhlDQo+IGNsaWVudCBrbm93cyB0aGF0IGl0IGNhbiB1 c2UgT0F1dGggd2l0aCB0aGUgdGFyZ2V0IFNUVU4gc2VydmVyIGVpdGhlciB0aHJvdWdoDQo+IGNv bmZpZ3VyYXRpb24gb3Igd2hlbiBpdCByZWNlaXZlcyB0aGUgbmV3IFNUVU4gYXR0cmlidXRlIFRI SVJELVBBUlRZLQ0KPiBBVVRIT1JJWkFUSU9OIGluIHRoZSA0MDEgVW5hdXRob3JpemVkIHJlc3Bv bnNlIHRvIGl0cyBpbml0aWFsIFNUVU4NCj4gcmVxdWVzdC4NCj4gCQ0KPiBPTEQNCj4gDQo+IHRv IGF2YWlsIFNUVU4gc2VydmljZXMNCj4gDQo+IE5FVw0KPiANCj4gdG8gYXZhaWwgaXRzZWxmIG9m IFNUVU4gc2VydmljZXMNCj4gDQo+IE9MRA0KPiANCj4gVGhlIGNsaWVudCBpcyBvYmxpdmlvdXMg dG8gdGhlIGNvbnRlbnQgb2YgdGhlIHRva2VuLiAgVGhlIHRva2VuIGlzDQo+IGVtYmVkZGVkIHdp dGhpbiBhIFNUVU4gcmVxdWVzdCBzZW50IHRvIHRoZSBTVFVOIHNlcnZlci4NCj4gDQo+IE5FVw0K PiANCj4gVGhlIGNvbnRlbnQgb2YgdGhlIHRva2VuIGlzIG9wYXF1ZSB0byB0aGUgY2xpZW50LiBU aGUgY2xpZW50IGVtYmVkcyB0aGUNCj4gdG9rZW4gd2l0aGluIGEgU1RVTiByZXF1ZXN0IHNlbnQg dG8gdGhlIFNUVU4gc2VydmVyLg0KPiANCj4gU2Vjb25kLWxhc3QgbGluZTogcy9pdCdzL2l0cy8N Cj4gDQo+IDMpIFNlY3Rpb24gMywgcGFyYWdyYXBoIGJlbG93IEZpZ3VyZSAyOg0KPiANCj4gTWlz c2luZyAiVGhlIiBpbiBmcm9udCBvZiAiQXV0aG9yaXphdGlvbiBzZXJ2ZXIiIGF0IHRoZSBiZWdp bm5pbmcgb2YgYQ0KPiBzZW50ZW5jZSwgbWlzc2luZyAidGhlIiBpbiBmcm9udCBvZiAiY2xpZW50 IiAodHdpY2UpLg0KPiANCj4gRm91cnRoIGxpbmUgZnJvbSB0aGUgYm90dG9tOiBzL2NsaWVudCBo YWQgcHJvdmlkZWQvdGhlIGNsaWVudCBwcm92aWRlZC8NCj4gDQo+IDQpIExhc3QgbGluZSBvZiBT ZWN0aW9uIDM6DQo+IA0KPiBPTEQNCj4gDQo+IE1VU1QgYmUgJ3N0dW4nIHN0cmluZy4NCj4gDQo+ IE5FVw0KPiANCj4gTVVTVCBiZSB0aGUgc3RyaW5nICdzdHVuJy4NCj4gDQo+IDUpIFNlY3Rpb24g NCwgZmlyc3QgcGFyYWdyYXBoOg0KPiANCj4gT0xEDQo+IA0KPiB1c2luZyBPQXV0aCBhY2Nlc3Mg dG9rZW4uDQo+IA0KPiBORVcNCj4gDQo+IHVzaW5nIGFuIE9BdXRoIGFjY2VzcyB0b2tlbi4NCj4g DQo+IE9MRA0KPiANCj4gVGhlIFNUVU4gc2VydmVycw0KPiANCj4gTkVXDQo+IA0KPiBUaGUgU1RV TiBzZXJ2ZXINCj4gDQo+IE9MRA0KPiANCj4gYWRkaXRpb25hbCBTVFVOIGF0dHJpYnV0ZQ0KPiAN Cj4gTkVXDQo+IA0KPiB0aGUgYWRkaXRpb25hbCBTVFVOIGF0dHJpYnV0ZQ0KPiANCj4gNikgU2Vj dGlvbiA0LCBwYXJhZ3JhcGggYmV0d2VlbiB0aGUgdHdvIGZpZ3VyZXMgNCBhbmQgNTogcy9pLmUv aS5lLiwvDQo+IA0KPiA3KSBTZWN0aW9uIDQuMSwgZmlyc3Qgc2VudGVuY2U6IHMvcmVzb3VyY2Ug c2VydmVyL1NUVU4gc2VydmVyLw0KPiANCj4gICAgIE1pZGRsZSBvZiBwYXJhZ3JhcGg6DQo+IA0K PiBPTEQNCj4gDQo+IFRoZSBBUy1SUywgQVVUSCBrZXlzDQo+IA0KPiBORVcNCj4gDQo+IFRoZSBB Uy1SUyBhbmQgQVVUSCBrZXlzDQo+IA0KPiBNaXNzaW5nICJUaGUiIGluIGZyb250IG9mICJBUy1S UyBrZXkiIGluIHRoZSBuZXh0IHNlbnRlbmNlLiBNaXNzaW5nDQo+ICJ0aGUiIGluIGZyb250IG9m ICJtZXNzYWdlIGludGVncml0eSIgbGF0ZXIgaW4gdGhhdCBzZW50ZW5jZS4NCj4gDQo+IFNlY29u ZC1sYXN0IHNlbnRlbmNlOg0KPiANCj4gT0xEDQo+IA0KPiBUaGUgZXN0YWJsaXNobWVudCBvZiBz eW1tZXRyaWMga2V5IGlzIG91dHNpZGUgdGhlIHNjb3BlDQo+IA0KPiBORVcNCj4gDQo+IFRoZSBw cm9jZWR1cmUgZm9yIGVzdGFibGlzaG1lbnQgb2YgdGhlIHN5bW1ldHJpYyBrZXkgaXMgb3V0c2lk ZSB0aGUgc2NvcGUNCj4gDQo+IDgpIFNlY3Rpb25zIDQuMS4yIGFuZCA0LjEuMyBoYXZlIG1pc3Np bmcgaW5zdGFuY2VzIG9mICJ0aGUiLg0KPiANCj4gOSkgU2VjdGlvbiA0LjEuMyBmaXJzdCBwYXJh Z3JhcGg6DQo+IA0KPiBPTEQNCj4gDQo+IE1hbmRhdG9yeSB0byBzdXBwb3J0IGF1dGhlbnRpY2F0 ZWQgZW5jcnlwdGlvbiBhbGdvcml0aG0gTVVTVCBiZQ0KPiBBRVNfMjU2X0NCQ19ITUFDX1NIQV81 MTIuDQo+IA0KPiBORVcNCj4gDQo+IElmIG1hbnVhbCBwcm92aXNpb25pbmcgaXMgc3VwcG9ydGVk LCBzdXBwb3J0IE1VU1QgYWxzbyBiZSBwcm92aWRlZCBmb3INCj4gQUVTXzI1Nl9DQkNfSE1BQ19T SEFfNTEyIGFzIHRoZSBhdXRoZW50aWNhdGVkIGVuY3J5cHRpb24gYWxnb3JpdGhtLg0KPiANCj4g MTApIFNlY3Rpb24gNSwgc2Vjb25kLWxhc3QgbGluZTogcy9kb2Vzbid0L2RvIG5vdC8NCj4gDQo+ IDExKSBTZWN0aW9uIDYuMSB0aGlyZCBsaW5lOiBzL3RpZS11cC90aWUtdXBzLw0KPiANCj4gMTIp IFNlY3Rpb24gNi4yLCBmaXJzdCBwYXJhZ3JhcGg6DQo+IA0KPiBPTEQNCj4gDQo+IG9mIFtSRkM1 Mzg5XSksIGFjY2VzcyB0b2tlbiBsZW5ndGgNCj4gDQo+IE5FVw0KPiANCj4gb2YgW1JGQzUzODld KS4gVGhlIGFjY2VzcyB0b2tlbiBsZW5ndGgNCj4gDQo+IE9MRA0KPiANCj4gaXMgb3BhcXVlIHRv IHRoZSBjbGllbnQgYW5kIGl0DQo+IA0KPiBORVcNCj4gDQo+IGlzIG9wYXF1ZSB0byB0aGUgY2xp ZW50IGFuZCB0aGUgY2xpZW50DQo+IA0KPiAxMykgU2VjdGlvbiA2LjIsICdsaWZldGltZScgYnVs bGV0Og0KPiANCj4gT0xEDQo+IA0KPiBidXQgdGhlIGNsaWVudCBhc3N1bWVzIHRoYXQNCj4gDQo+ IE5FVw0KPiANCj4gYnV0IHRoZSBjbGllbnQgd291bGQgYXNzdW1lIHRoYXQNCj4gDQo+IDE0KSBT ZWN0aW9uIDYuMiwgJ2VuY3J5cHRlZF9ibG9jaycgYnVsbGV0Og0KPiAgICAgcy9yZXNvdXJjZSBz ZXJ2ZXIvU1RVTiBzZXJ2ZXIvDQo+IA0KPiAxNSkgU2VjdGlvbiA5LCBmaXJzdCBidWxsZXQ6DQo+ IA0KPiBPTEQNCj4gDQo+IFNpbmNlIHRoZSBhY2Nlc3MgdG9rZW4gaXMgb25seSB2YWxpZCBmb3Ig YSBzcGVjaWZpYyBwZXJpb2Qgb2YgdGltZSwNCj4gDQo+IE5FVw0KPiANCj4gU2luY2UgdGhlIGFj Y2VzcyB0b2tlbiBpcyB2YWxpZCBmb3IgYSBzcGVjaWZpYyBwZXJpb2Qgb2YgdGltZSwNCj4gDQo+ IDE2KSBTZWN0aW9uIDEwLCBmaXJzdCBwYXJhZ3JhcGg6DQo+IA0KPiBPTEQNCj4gDQo+IGRldGVj dCB0aGF0IHRoZSB0cmFuc2FjdGlvbiBJRCBhcyB1c2VkDQo+IA0KPiBORVcNCj4gDQo+IGRldGVj dCB0aGF0IHRoZSB0cmFuc2FjdGlvbiBJRCB3YXMgdXNlZA0KPiANCj4gMTcpIFJlZmVyZW5jZSBk cmFmdC1pZXRmLXRyYW0tYXV0aC1wcm9ibGVtcyBoYXMgYmVlbiBwdWJsaXNoZWQgYXMgUkZDDQo+ IDczNzYgYW5kIHNob3VsZCBiZSB1cGRhdGVkLiBJbmZvcm1hdGl2ZSByZWZlcmVuY2VzDQo+IEkt RC5pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUgYW5kIEktRC5pZXRmLW9hdXRoLXBvcC1rZXkt ZGlzdHJpYnV0aW9uDQo+IGhhdmUgZXhwaXJlZCwgYnV0IEkgZ3Vlc3MgdGhlcmUgaXMgbm90aGlu ZyB5b3UgY2FuIGNoYW5nZSBmb3IgdGhlIG1vbWVudC4NCg== From nobody Wed Feb 4 09:45:08 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A74C1A1B28 for ; Wed, 4 Feb 2015 09:45:06 -0800 (PST) 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 Si3gvtzeJnWU for ; Wed, 4 Feb 2015 09:45:02 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3A81A1A3E for ; Wed, 4 Feb 2015 09:45:02 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id kv7so1037639vcb.1 for ; Wed, 04 Feb 2015 09:45:01 -0800 (PST) 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=HQrzb8YOssSslSNCeHpruVdhD3lpwCWrmdJHwYheyK8=; b=eK8jkUAXJcykUpDRtxTs6/QiRuLorf4vuHExim9fzGENTjHZkLuw9UUoZ6mEQQ1gCO 1VEz/6slYuTcQ7BBD7Ey0oZPEqTG8tkJ0XiVnYNf+Mfxjv5O0Q4H88ScMf8Ogj7Gtm1v Lo5cInq4/vpbe2T+8t/jDhpTYzPjxDS4/dSv208rQNOtbLxkCvq15mjACNmb0eijdOX+ Uf4R5JNN4zcQcAgSJhfAq/Np8ezhJf4K+2XZ/XnqcrWU2Hsl5lflt3cjE9OoUAHUvqoD OjlLn3fzQSs1nfwEkHgrX+DP8EzHqNSdSwhoqM+qsrQ1tQS9jyssZyArOqoJzQ8Yk3ly Z9LQ== X-Gm-Message-State: ALoCoQl3ZEjNbhfEpbNaUPKSHgdM+d8s4UN/1bcjRKpcvgsfCrPQh50G81qJT7jouwxWuSL7FsjV X-Received: by 10.52.171.113 with SMTP id at17mr16713629vdc.58.1423071901488; Wed, 04 Feb 2015 09:45:01 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com. [209.85.220.178]) by mx.google.com with ESMTPSA id vk7sm332693vdc.14.2015.02.04.09.45.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Feb 2015 09:45:00 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id hy10so1019245vcb.9 for ; Wed, 04 Feb 2015 09:45:00 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.52.82.166 with SMTP id j6mr16959107vdy.21.1423071900410; Wed, 04 Feb 2015 09:45:00 -0800 (PST) Received: by 10.52.54.194 with HTTP; Wed, 4 Feb 2015 09:45:00 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A35538F91@xmb-rcd-x10.cisco.com> References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35538E3D@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35538F91@xmb-rcd-x10.cisco.com> Date: Wed, 4 Feb 2015 12:45:00 -0500 Message-ID: From: Benjamin Schwartz To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a1136ac4c1d58f6050e46bf82 Archived-At: Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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, 04 Feb 2015 17:45:06 -0000 --001a1136ac4c1d58f6050e46bf82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 4, 2015 at 12:15 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Inline [TR2] > > > > *From:* Benjamin Schwartz [mailto:bemasc@webrtc.org] > *Sent:* Wednesday, February 04, 2015 10:16 PM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* Simon Perreault; tram@ietf.org > *Subject:* Re: [tram] FW: New Version Notification for > draft-reddy-tram-turn-ipaddress-privacy-00.txt > > > > On Wed, Feb 4, 2015 at 11:11 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Inline [TR] > > > > *From:* Benjamin Schwartz [mailto:bemasc@webrtc.org] > *Sent:* Wednesday, February 04, 2015 9:16 PM > *To:* Simon Perreault > *Cc:* Tirumaleswar Reddy (tireddy); tram@ietf.org > *Subject:* Re: [tram] FW: New Version Notification for > draft-reddy-tram-turn-ipaddress-privacy-00.txt > > > > I agree with Simon. > > > > 1. IP address privacy is not representable as a binary. See > http://en.wikipedia.org/wiki/Degree_of_anonymity > > > > [TR] It is only offering IP address privacy from remote peer. > > > > I disagree with your conception of the problem. > > > > I think the real goal here is to achieve some degree of anonymity, > assuming that the TURN server is trusted not to reveal its mapping table > (and the adversary cannot deduce it). To achieve this, you must choose a > TURN server that is not traceable to the aspect of your identity that you > are trying to obscure. For example, if you are trying to conceal your IP > address, then this TURN server must not imply your IP address. If you ar= e > trying to conceal your corporate affiliation, this TURN server must not b= e > associated with your corporation. If you are trying to conceal your > location on the planet, this TURN server must must be used by users on al= l > continents ... etc. > > > > Given the wide variety of trust relationships and privacy goals held by > users, the only reasonable approach here is to let the user select a TURN > server that they trust explicitly. Such a configuration might happen by > enterprise policy (in the same way that software can be installed on all > workstations at an office), but network-level autoconfiguration does not > indicate sufficient trust. > > > > 2. This system actually _reduces_ privacy: > > > If the server determines that the relayed address it will allocate and > client IP address are in the same geolocation then the server will redire= ct > the client to another server > > > > This behavior provides me nonzero information about your location: you > cannot be at the location indicated by the allocated IP address. > > > > [TR] The relayed address is not allocated by the TURN server, it redirect= s > the client to a different TURN server that can offer IP address privacy. > > > > Presumably the client is intended to ask the second server for address > privacy as well, in which case that server will also redirect if the IP > addresses match. The result is an information leak, albeit a small one. > Perhaps more importantly, the procedure can easily fail, leaving the clie= nt > to explain to the user that all attempts to find a privacy-promising > intermediary have failed. > > > > [TR2] A relay service provider with a broadly distributed system like the > one discussed in > https://tools.ietf.org/html/draft-williams-peer-redirect-03 can pick the > right TURN server avoiding NNN number of redirections. > > > > > > (Even Simon's proposal here actually _increases_ address information > leakage. The minimal-leakage strategy is to use a fixed/random address th= at > might occasionally be close to your real address, by chance.) > > > > 3. "Same geolocation" is not a well-defined concept. There are a > multitude of corporations with different, contradictory geolocation > databases of varying quality. > > > > [TR] Geolocation is well-defined concept already used by firewalls from > various vendors to make effective blocking decisions. > > > > "Effective" perhaps, but not "reliable". Systems that promise privacy to > users must be "reliable": they must never fail, because they are entruste= d > with a task of grave significance. I am not willing to bet the user's > privacy on the accuracy of some arbitrary TURN server's geolocation > database, which will likely be poorly implemented, incomplete, and out of > date. > > > > [TR2] TURN service provider can offer privacy as feature to customers, in > which case it has SLA to provide reliable privacy. It=E2=80=99s very simi= lar to way > Cloud based Security as a service (SaaS) is offered and the Enterprise > enters into an agreement with SaaS for privacy, data leakage prevention e= tc. > > TURN client can also do the validation by itself to check if the > geolocation of the relayed address matches endpoints geolocation. > I agree that the client can do equally well itself, by sending a STUN Binding Request and comparing the response to the TURN server's own IP address. That's why I don't think that the protocol extension is helpful. > > > > > 4. I presume that the goal here is to allow building privacy-preserving > communications systems, but this draft does not make that possible, becau= se > anyone setting up a privacy-preserving chat system cannot trust an > arbitrary enterprise-configured TURN server to be privacy-preserving, jus= t > because that server claims to preserve privacy. > > > > [TR] Enterprise configured TURN server is not an arbitrary server. > Typically users trust Enterprise firewall and it act as HTTP(S) proxy, in > the same lines Enterprise TURN server can also be trusted when it claims = it > can provide privacy. > > > > I agree that there exist situations where a trust relationship exists > between the TURN server operator and the user, but not all TURN > autodiscovery implementations have this property. For example, it is > likely that some ISPs will provide TURN servers via autodiscovery, but I > certainly would not trust my ISP to safeguard my privacy in any way. > > > > [TR] Client could discover TURN server provided by ISP and learn the TURN > server offered by application server. But user may not trust the > application server and would want to go with the TURN server provided by > the ISP. > Or the client might want to use both, or even _have_ to use both, depending on their privacy goals and network configuration. > > > -Tiru > > > > -Tiru > > > > On Wed, Feb 4, 2015 at 10:42 AM, Simon Perreault > wrote: > > Thanks for writing this. > > After a quick read, I am skeptical. I doubt any client would trust any > assertion from an a priori unknown TURN server about its available privac= y > capabilities. > > Instead, why can't the client simply request an allocation, perhaps > indicating its desire that the relayed address be "far" from its own with= a > new optional attribute, and then accept or reject the allocation using it= s > own good judgment? > > Simon > > Le 2015-02-04 08:25, "Tirumaleswar Reddy (tireddy)" a > =C3=A9crit : > > > > This draft describes a means for an client to discover that the TURN > server can provide IP address privacy. > Comments and suggestions are welcome. > > -Tiru > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, February 04, 2015 8:54 PM > To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Tirumaleswa= r > Reddy (tireddy); Prashanth Patil (praspati) > Subject: New Version Notification for > draft-reddy-tram-turn-ipaddress-privacy-00.txt > > > A new version of I-D, draft-reddy-tram-turn-ipaddress-privacy-00.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the > IETF repository. > > Name: draft-reddy-tram-turn-ipaddress-privacy > Revision: 00 > Title: IP address privacy by TURN server > Document date: 2015-02-04 > Group: Individual Submission > Pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-ipaddress-priva= cy-00.txt > Status: > https://datatracker.ietf.org/doc/draft-reddy-tram-turn-ipaddress-privacy/ > Htmlized: > http://tools.ietf.org/html/draft-reddy-tram-turn-ipaddress-privacy-00 > > > Abstract: > A TURN server allocates an IP address for a user. If this address is > dis-associated from the user's actual network, the allocated IP > address increases the user's privacy. This document describes a > means for an client to discover that the TURN server can provide IP > address privacy. > > > > > 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 > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > --001a1136ac4c1d58f6050e46bf82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 4, 2015 at 12:15 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.c= om> wrote:

Inline [TR2]

=C2=A0

From: Benjamin= Schwartz [mailto:be= masc@webrtc.org]
Sent: Wednesday, February 04, 2015 10:16 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; tram@ietf.org
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tra= m-turn-ipaddress-privacy-00.txt

=C2=A0

On Wed, Feb 4, 2015 at 11:11 AM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

Inline [TR]=

=C2=A0

From: Benjamin= Schwartz [mailto:be= masc@webrtc.org]
Sent: Wednesday, February 04, 2015 9:16 PM
To: Simon Perreault
Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tra= m-turn-ipaddress-privacy-00.txt

=C2=A0

I agree with Simon.

=C2=A0

1. IP address privacy is not representable a= s a binary.=C2=A0 See=C2=A0http://en.wikipedia.org/wiki/Degree_of_anony= mity

=C2=A0

[TR] It is only offering = IP address privacy from remote peer.

=C2=A0

I disagree with your conception of the problem.

=C2=A0

I think the real goal here is to achieve some degree= of anonymity, assuming that the TURN server is trusted not to reveal its m= apping table (and the adversary cannot deduce it).=C2=A0 To achieve this, y= ou must choose a TURN server that is not traceable to the aspect of your identity that you are trying to obscure.= =C2=A0 For example, if you are trying to conceal your IP address, then this= TURN server must not imply your IP address.=C2=A0 If you are trying to con= ceal your corporate affiliation, this TURN server must not be associated with your corporation.=C2=A0 If you are trying to c= onceal your location on the planet, this TURN server must must be used by u= sers on all continents ... etc.

=C2=A0

Given the wide variety of trust relationships and pr= ivacy goals held by users, the only reasonable approach here is to let the = user select a TURN server that they trust explicitly.=C2=A0 Such a configur= ation might happen by enterprise policy (in the same way that software can be installed on all workstations at an = office), but network-level autoconfiguration does not indicate sufficient t= rust.

=C2=A0

2. This system actually _reduces_ privacy:

> If the server determines that the relayed= address it will allocate and client IP address are in the same geolocation then the server will redirect the client to another server

=C2=A0

This behavior provides me nonzero information = about your location: you cannot be at the location indicated by the allocat= ed IP address.

=C2=A0

[TR] The relayed address = is not allocated by the TURN server, it redirects the client to a different TURN server that can offer IP address privacy.

=C2=A0

Presumably the client is intended to ask the second = server for address privacy as well, in which case that server will also red= irect if the IP addresses match.=C2=A0 The result is an information leak, a= lbeit a small one.=C2=A0 Perhaps more importantly, the procedure can easily fail, leaving the client to explain to the user t= hat all attempts to find a privacy-promising intermediary have failed.

=C2=A0

[TR2] A relay serv= ice provider with a broadly distributed system like the one discussed in https://tools.ietf.org/html/draft-williams-peer-redirect-03 can pick the right TURN server avoiding NNN number of redirections.

=C2=A0

=C2=A0

(Even Simon's proposal here actually _incr= eases_ address information leakage. The minimal-leakage strategy is to use = a fixed/random address that might occasionally be close to your real address= , by chance.)

=C2=A0

3. "Same geolocation" is not a wel= l-defined concept.=C2=A0 There are a multitude of corporations with differe= nt, contradictory geolocation databases of varying quality.

=C2=A0

[TR] Geolocation is well-= defined concept already used by firewalls from various vendors to make effe= ctive blocking decisions.

=C2=A0

"Effective" perhaps, but not "reliabl= e".=C2=A0 Systems that promise privacy to users must be "reliable= ": they must never fail, because they are entrusted with a task of gra= ve significance.=C2=A0 I am not willing to bet the user's privacy on th= e accuracy of some arbitrary TURN server's geolocation database, which will likel= y be poorly implemented, incomplete, and out of date.

=C2=A0

[TR2] TURN service= provider can offer privacy as feature to customers, in which case it has S= LA to provide reliable privacy. It=E2=80=99s very similar to way Cloud based Security as a service (SaaS) is offered and the Enterprise enters in= to an agreement with SaaS for privacy, data leakage prevention etc.<= u>

TURN client can also do t= he validation by itself to check if the geolocation of the relayed address = matches endpoints geolocation.


I agree that the client can do equ= ally well itself, by sending a STUN Binding Request and comparing the respo= nse to the TURN server's own IP address.=C2=A0 That's why I don'= ;t think that the protocol extension is helpful.
=C2=A0

=C2=A0

=C2=A0

4. I presume that the goal here is to allow = building privacy-preserving communications systems, but this draft does not make that possible, because anyone setting up a privacy-preserving cha= t system cannot trust an arbitrary enterprise-configured TURN server to be = privacy-preserving, just because that server claims to preserve privacy.

=C2=A0

[TR] Enterprise configure= d TURN server is not an arbitrary server. Typically users trust Enterprise firewall and it act as HTTP(S) proxy, in the same lines Enterprise TURN se= rver can also be trusted when it claims it can provide privacy.

=C2=A0

I agree that there exist situations where a trust re= lationship exists between the TURN server operator and the user, but not al= l TURN autodiscovery implementations have this property.=C2=A0 For example,= it is likely that some ISPs will provide TURN servers via autodiscovery, but I certainly would not trust my ISP to = safeguard my privacy in any way.

=C2=A0

[TR] Client could discove= r TURN server provided by ISP and learn the TURN server offered by applicat= ion server. But user may not trust the application server and would want to go with the TURN server provided by the ISP.

<= /div>

O= r the client might want to use both, or even _have_ to use both, depending = on their privacy goals and network configuration.
=C2=A0

=C2=A0

-Tiru

=C2=A0

-Tiru

=C2=A0

On Wed, Feb 4, 2015 at 10:42 AM, Simon Perreault <= ;sperreault@jive.c= om> wrote:

Thanks for writing this.

After a quick read, I am skeptical. I doubt any client would trust any a= ssertion from an a priori unknown TURN server about its available privacy c= apabilities.

Instead, why can't the client simply request an allocation, perhaps = indicating its desire that the relayed address be "far" from its = own with a new optional attribute, and then accept or reject the allocation= using its own good judgment?

Simon

Le 2015-02-04 08:25, "Tirumaleswar Reddy (tired= dy)" <tiredd= y@cisco.com> a =C3=A9crit :

=C2=A0

This draft describes a means for an client to discov= er that the TURN server can provide IP address privacy.
Comments and suggestions are welcome.

-Tiru

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, February 04, 2015 8:54 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Tirumaleswar = Reddy (tireddy); Prashanth Patil (praspati)
Subject: New Version Notification for draft-reddy-tram-turn-ipaddress-priva= cy-00.txt


A new version of I-D, draft-reddy-tram-turn-ipaddress-privacy-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-reddy-tram-turn-ipaddre= ss-privacy
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IP address privacy by TURN server<= br> Document date:=C2=A0 2015-02-04
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-ipaddress-privacy= -00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/draft-reddy-tram-turn-ipaddress-privacy/ Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.i= etf.org/html/draft-reddy-tram-turn-ipaddress-privacy-00


Abstract:
=C2=A0 =C2=A0A TURN server allocates an IP address for a user.=C2=A0 If thi= s address is
=C2=A0 =C2=A0dis-associated from the user's actual network, the allocat= ed IP
=C2=A0 =C2=A0address increases the user's privacy.=C2=A0 This document = describes a
=C2=A0 =C2=A0means for an client to discover that the TURN server can provi= de IP
=C2=A0 =C2=A0address privacy.




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

The IETF Secretariat

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


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

=C2=A0

=C2=A0


--001a1136ac4c1d58f6050e46bf82-- From nobody Wed Feb 4 10:50:57 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812CC1A1B70 for ; Wed, 4 Feb 2015 10:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDRMX34glBRJ for ; Wed, 4 Feb 2015 10:50:51 -0800 (PST) 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 9D67F1A0673 for ; Wed, 4 Feb 2015 10:50:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5558; q=dns/txt; s=iport; t=1423075852; x=1424285452; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6ELHfgDK76T5IfAgGbMXkOFJKTWaSCS2OVdDRgmJJ7Q=; b=WRPvfNRFf45Bi+12XjUq0KGVta8mBLRB0CkL6ZgME3efeWIBNFPZpEUG P0FwTX6ercueJ2CY4vi7pdUC/WoEtrPKZtBn+HhMG7RwNqj+yPMibVXn7 EJ6TnH1EJa3pDszwFI2/Cjtf4b5mzkdxEguDIR6DwBD24u0cbOYM0ag3L 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFALpo0lStJV2Z/2dsb2JhbABagkNDUl2Cfb0biBYCHIECQwEBAQEBfYQMAQEBBCMKSgIQAgEIDhQgAgICMBwJAgQODYglwC2WPAEBAQEBAQEBAQEBAQEBAQEBAQEBARePRzEHgmgugRMFjxCcDCKCMoE8gjN+AQEB X-IronPort-AV: E=Sophos;i="5.09,519,1418083200"; d="scan'208,217";a="393795411" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 04 Feb 2015 18:50:52 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t14IooN6025409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Feb 2015 18:50:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 4 Feb 2015 12:50:50 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Benjamin Schwartz Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt Thread-Index: AQHQQI6WdUQVEuPT30i8U4lnHv84fZzgnDZwgABplACAAADzAP//nwEQgABxyYD//5vKQIAAdL8A//+buyA= Date: Wed, 4 Feb 2015 18:50:50 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A355390B9@xmb-rcd-x10.cisco.com> References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35538E3D@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35538F91@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.54.201] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A355390B9xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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, 04 Feb 2015 18:50:54 -0000 --_000_913383AAA69FF945B8F946018B75898A355390B9xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IHRoZSBjbGllbnQgY2FuIGRvIGVxdWFsbHkgd2VsbCBpdHNlbGYsIGJ5IHNl bmRpbmcgYSBTVFVOIEJpbmRpbmcgUmVxdWVzdCBhbmQgY29tcGFyaW5nIHRoZSByZXNwb25zZSB0 byB0aGUgVFVSTiBzZXJ2ZXIncyBvd24gSVAgYWRkcmVzcy4NCg0KW1RSM10gVGhlIGRpZmZlcmVu Y2UgdGhpcyBkcmFmdCBicmluZ3MgaW4gaXMgdGhhdCBpdCBoZWxwcyB0aGUgVFVSTiBzZXJ2ZXIg KG9mZmVyZWQgYnkgYSBnbG9iYWwgb3IgY2xvdWQgc2VydmljZSkgdG8gZGV0ZXJtaW5lIHRoYXQg dGhlIGNsaWVudCB3YW50cyBwcml2YWN5IGFuZCBsZXZlbCBvZiBwcml2YWN5IHJlcXVpcmVkIGNv bnZleWVkIGluIHRoZSBuZXcgU1RVTiBhdHRyaWJ1dGUsIHRoZSBUVVJOIHNlcnZlciBkZXRlcm1p bmVzIHN1aXRhYmxlIGFsdGVybmF0ZSBUVVJOIHNlcnZlciB0aGF0IGNhbiBvZmZlciB0aGUgcmVx dWlyZWQgbGV2ZWwgb2YgcHJpdmFjeS4NCg0KLVRpcnUNCg== --_000_913383AAA69FF945B8F946018B75898A355390B9xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRoYXQgdGhlIGNsaWVu dCBjYW4gZG8gZXF1YWxseSB3ZWxsIGl0c2VsZiwgYnkgc2VuZGluZyBhIFNUVU4gQmluZGluZyBS ZXF1ZXN0IGFuZCBjb21wYXJpbmcgdGhlIHJlc3BvbnNlIHRvIHRoZSBUVVJOIHNlcnZlcidzIG93 biBJUCBhZGRyZXNzLiZuYnNwOw0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+W1RSM10gVGhlIGRpZmZlcmVuY2UgdGhpcyBkcmFmdCBicmluZ3MgaW4gaXMgdGhhdCBpdCBo ZWxwcyB0aGUgVFVSTiBzZXJ2ZXIgKG9mZmVyZWQgYnkgYSBnbG9iYWwgb3IgY2xvdWQgc2Vydmlj ZSkgdG8gZGV0ZXJtaW5lIHRoYXQgdGhlIGNsaWVudCB3YW50cyBwcml2YWN5DQogYW5kIGxldmVs IG9mIHByaXZhY3kgcmVxdWlyZWQgY29udmV5ZWQgaW4gdGhlIG5ldyBTVFVOIGF0dHJpYnV0ZSwg dGhlIFRVUk4gc2VydmVyIGRldGVybWluZXMgc3VpdGFibGUgYWx0ZXJuYXRlIFRVUk4gc2VydmVy IHRoYXQgY2FuIG9mZmVyIHRoZSByZXF1aXJlZCBsZXZlbCBvZiBwcml2YWN5Lg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A355390B9xmbrcdx10ciscoc_-- From nobody Wed Feb 4 22:51:36 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89351A0248 for ; Wed, 4 Feb 2015 22:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.11 X-Spam-Level: ** X-Spam-Status: No, score=2.11 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_37=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_84=0.6] 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 YcMUiay8iCHk for ; Wed, 4 Feb 2015 22:51:31 -0800 (PST) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id A559F1A0218 for ; Wed, 4 Feb 2015 22:51:30 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.78]) by app1 (Coremail) with SMTP id Z0GX06ALdQMV_NJUo5_xAQ==.12204S2; Thu, 05 Feb 2015 13:13:58 +0800 (CST) From: "Aijun Wang" To: "'Pal Martinsen \(palmarti\)'" References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <000001d03f8a$010c89a0$03259ce0$@org.cn> <007401d04024$0ee0d3c0$2ca27b40$@org.cn> <37F58EB6-2CAE-4CA5-B286-D622DC33B139@cisco.com> In-Reply-To: <37F58EB6-2CAE-4CA5-B286-D622DC33B139@cisco.com> Date: Thu, 5 Feb 2015 14:51:04 +0800 Message-ID: <00ed01d04110$1ca32340$55e969c0$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: zh-cn Thread-Index: AQHQPEw3iE7SBHjBP02Pt2UimDWYDJze//0AgAAJBACAASsYAIAAf8SAgADkaWA= X-CM-TRANSID: Z0GX06ALdQMV_NJUo5_xAQ==.12204S2 X-Coremail-Antispam: 1U3129KBjvJXoWxAFy5WFW5ZF4fXFyrCr4rZrb_yoWrCr1rpF 45WF15GrWkAr4Iyw1UCa1UZF1Fv3y8Ww47Grn5Kry2vFZ8CFs0kFyaywn8GFyDGr1ruFyY qr4jgFWDCa4DZFJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVWUJVW8JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUAVWUtjIFyTuYvjfU5BT5DUUUU Archived-At: Cc: 'Oleg Moskalenko' , 'Brandon Williams' , "'Tirumaleswar Reddy \(tireddy\)'" , tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 05 Feb 2015 06:51:35 -0000 > 1. About Transport protocol > "Section 2.1 Transports" describe the reason that use different=20 > transport protocol between TURN Client/TURN Server and TURN > Local firewall traversal! >=20 > Very convenient to have TCP/TLS between you and your TURN server to = get > through stubborn firewalls. Likewise it is very convenient to still be = able to talk > to the remote host on UDP. The remote host can be a RFLX address of an = ICE > agent, a legacy SIP endpoint with a reachable IP and so on. >=20 TURN and ICE are mainly dealing with the communication between two = hosts. Before their communication, normally they will agree with which = transport protocol will be used. For the scenarios that you mentioned = here(it is also mentioned in the original draft), the two peers should = both select TCP as the transport protocol. If one leg(between client and = TURN server) select the TCP and the other leg(between TURN server and = the peer) select the UDP, then the application that builds on TURN will = lose the advantage of the data reliability(can be assured by TCP) and = data efficiency(can be reached by UDP) at the same time. Do you think = this is a good design?=20 My main point here is that although it is possible to use the different = transport protocols for these two legs, there is no benefits to do so.=20 > >> > >> 2. About EDM NAT transversal between TURN server and peer "Section >=20 > I do not see how the above text can be misunderstood. All these sections describes clearly only the applicable scope of TURN = but not related to my concern. My concern is that how you assure the UDP = packet from the TURN Server to pass through the EDM type NAT that = located before the peer?=20 > I think you should follow the advice from the Introduction: > "TURN was designed as one piece in the larger ICE approach to NAT = traversal. > Implementors of TURN are urged to investigate ICE and seriously = consider > using it for their application. However, it is possible to use TURN = without > ICE.=E2=80=9D >=20 >=20 > It is possible to deploy TURN servers in a way that would not work. = This is > because the specs was written in a non limiting way to allow for what = ever > deployment scenarios that might be useful to different implementors. = But I > think it is also described how to deploy it in a way that actually = works. If this spec can't even fulfill the general communication scenarios, = then its usage will be limited. From our test experiences, more and more = EDM NAT are now deployed, but current spec focuses only one special = scenarios. >=20 > >> > >> 3. Relay between multiple TURN Server As we described in the mail >=20 > Relaying between several TURN servers should not be a part of the TURN = RFC. > How to install permissions and so on is described in the ICE RFC. Then we developed another draft to meet the multiple TURN Servers = scenarios? "Create Permission" section is included in this draft, = ICE(RFC 5245) only deals with the connectivity check. >=20 > To summarise. Each agent has a responsibility to get through their own = NAT. If > it is a restrictive one it should use TURN to get through it. What the = remote > side is doing to get through his or her NAT is not your problem. >=20 So current TURN spec can't be used independently, there must exist other = mechanisms to assure it work correctly. As that described in [RFC6062], = that=20 "....... It is expected that, between the > first and second steps, the client will communicate off-band = with > the peer (e.g., using ICE [RFC5245]) and tell it the relayed > transport address that the TURN server allocated and from which = it > is about to initiate a connection. The peer can then "get = ready": > open holes in its firewall, try to poke holes in a NAT, attempt = a > TCP simultaneous open, etc." Can we design one new solution of TURN to cover all these incomplete = solutions? It can cover almost all the problems(even the current hot = topic ----"ip address privacy" ) that current TURN specs wants to solve, = but in one simpler manner. > .-. > P=C3=A5l-Erik >=20 > > > > > > Regards, > > Oleg > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Feb 4 22:55:22 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558CC1A037E for ; Wed, 4 Feb 2015 22:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=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 JVepuDE8lzkc for ; Wed, 4 Feb 2015 22:55:19 -0800 (PST) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id B10571A0277 for ; Wed, 4 Feb 2015 22:55:18 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.78]) by app1 (Coremail) with SMTP id Z0GX06ALogQT_dJUKZnpAQ==.12315S2; Thu, 05 Feb 2015 13:18:11 +0800 (CST) From: "Aijun Wang" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Benjamin Schwartz'" References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35538E3D@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35538F91@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A355390B9@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A355390B9@xmb-rcd-x10.cisco.com> Date: Thu, 5 Feb 2015 14:55:17 +0800 Message-ID: <00ee01d04110$b3825650$1a8702f0$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EF_01D04153.C1A59650" X-Mailer: Microsoft Office Outlook 12.0 Content-Language: zh-cn Thread-Index: AQHQQI6WdUQVEuPT30i8U4lnHv84fZzgnDZwgABplACAAADzAP//nwEQgABxyYD//5vKQIAAdL8A//+buyAAG3kPMA== X-CM-TRANSID: Z0GX06ALogQT_dJUKZnpAQ==.12315S2 X-Coremail-Antispam: 1U3129KBjvdXoW7Wr1xCF18Kr1fCryxKFWxJFb_yoWfuFg_uF ZaqryUJ3ykGF1jgw1DJrnxAr43ZrnIv3yUJ3yUJF109ayUCFnxZ392kr95CF1xC3yjgr98 XwsakrnxGr9xujkaLaAFLSUrUUUUjbIjqfuFe4nvWSU5nxnvy29KBjDU0xBIdaVrnRJUUU 7Cb7Iv0xC_Jr1l5I8CrVAYj202j2C_Gr0_Xr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kE w2xG04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r1j6r4UM7 C26xCjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF 1VAY17CE14v26r126r1DMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r1j6r4UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAF wI0_Jr0_GrUI43ZEXa7VUbWlk3UUUUU== Archived-At: Cc: 'Simon Perreault' , tram@ietf.org Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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, 05 Feb 2015 06:55:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00EF_01D04153.C1A59650 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable There is no mechanism to assure how soon the client can find the right = TURN Server that can provide one relay address to keep the privacy of = the clients. =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar = Reddy (tireddy) Sent: Thursday, February 05, 2015 2:51 AM To: Benjamin Schwartz Cc: Simon Perreault; tram@ietf.org Subject: Re: [tram] FW: New Version Notification for = draft-reddy-tram-turn-ipaddress-privacy-00.txt =20 I agree that the client can do equally well itself, by sending a STUN = Binding Request and comparing the response to the TURN server's own IP = address. =20 =20 [TR3] The difference this draft brings in is that it helps the TURN = server (offered by a global or cloud service) to determine that the = client wants privacy and level of privacy required conveyed in the new = STUN attribute, the TURN server determines suitable alternate TURN = server that can offer the required level of privacy.=20 =20 -Tiru ------=_NextPart_000_00EF_01D04153.C1A59650 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

There is no mechanism to assure how soon the client can find the = right TURN Server that can provide one relay address to keep the privacy = of the clients.

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy = (tireddy)
Sent: Thursday, February 05, 2015 2:51 = AM
To: Benjamin Schwartz
Cc: Simon Perreault; = tram@ietf.org
Subject: Re: [tram] FW: New Version Notification = for = draft-reddy-tram-turn-ipaddress-privacy-00.txt

 

I agree that the client can do equally well itself, by = sending a STUN Binding Request and comparing the response to the TURN = server's own IP address. 

 

[TR3] The difference this draft brings in is that it helps the TURN = server (offered by a global or cloud service) to determine that the = client wants privacy and level of privacy required conveyed in the new = STUN attribute, the TURN server determines suitable alternate TURN = server that can offer the required level of privacy. =

 

-Tiru

------=_NextPart_000_00EF_01D04153.C1A59650-- From nobody Thu Feb 5 01:44:20 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2051A017F for ; Thu, 5 Feb 2015 01:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.71 X-Spam-Level: X-Spam-Status: No, score=-12.71 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_37=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQc_UmHX104Z for ; Thu, 5 Feb 2015 01:44:16 -0800 (PST) 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 002951A0162 for ; Thu, 5 Feb 2015 01:44:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24452; q=dns/txt; s=iport; t=1423129455; x=1424339055; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uJq4/XkPDySCK5fAB1h007P9tAYhJ0VPWSMc3I8HbyA=; b=EKqthlovzA3zajkIkuYI8Yc+gDITLg0II/22Cm1ryl9hlXVy58BDwlsC F5CmVLs/unbIotJNoIb20Nyy0XFV9+UWHd50du+mAgirODT7o+CeALW9E FdmfNpnwjEXzj6iEC6I0ynJq4KjRJjNIpMWXQOXPMcUW0estUlH89bCHT k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B7BQDzOtNU/5tdJa1agwZSWQSCfb9AAQmFcQIcgQdDAQEBAQF9hA0BAQQBAQEgSwsQAgEGAj8DAgICJQsUEQIEDgUbiBINolecbJZDAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPIAcBAUsEB4JoLoETBY0xgWODUIFQhAqBF4MDixKDPiKDbm+BAgkXIn4BAQE X-IronPort-AV: E=Sophos;i="5.09,522,1418083200"; d="scan'208,217";a="120700586" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 05 Feb 2015 09:44:14 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t159iFtt013383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 09:44:15 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.166]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Thu, 5 Feb 2015 03:44:13 -0600 From: "Pal Martinsen (palmarti)" To: Aijun Wang Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt Thread-Index: AQHQPEw3iE7SBHjBP02Pt2UimDWYDJze//0AgAAJBACAASsYAIAAf8SAgADkaWCAAKRNgA== Date: Thu, 5 Feb 2015 09:44:13 +0000 Message-ID: <5F8B3F40-2232-4827-8904-2562CF447497@cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <000001d03f8a$010c89a0$03259ce0$@org.cn> <007401d04024$0ee0d3c0$2ca27b40$@org.cn> <37F58EB6-2CAE-4CA5-B286-D622DC33B139@cisco.com> <00ed01d04110$1ca32340$55e969c0$@org.cn> In-Reply-To: <00ed01d04110$1ca32340$55e969c0$@org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.75] Content-Type: multipart/alternative; boundary="_000_5F8B3F402232482789042562CF447497ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Oleg Moskalenko , "Tirumaleswar Reddy \(tireddy\)" , Brandon Williams , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 05 Feb 2015 09:44:19 -0000 --_000_5F8B3F402232482789042562CF447497ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2ssIEkgd2lsbCB0cnkgdG8gZXhwbGFpbi4gV291bGQgYmUgbmljZSBpZiBzb21lIG90aGVycyAg b24gdGhlIGxpc3QgY2FuIHZlcmlmeSB3aGF0IEkgc2F5IGlzIGNvcnJlY3QuDQoNCk9uIDA1IEZl YiAyMDE1LCBhdCAwNzo1MSwgQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbjxt YWlsdG86d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4+IHdyb3RlOg0KDQoxLiBBYm91dCBUcmFu c3BvcnQgcHJvdG9jb2wNCiJTZWN0aW9uIDIuMSBUcmFuc3BvcnRzIiBkZXNjcmliZSB0aGUgcmVh c29uIHRoYXQgdXNlIGRpZmZlcmVudA0KdHJhbnNwb3J0IHByb3RvY29sIGJldHdlZW4gVFVSTiBD bGllbnQvVFVSTiBTZXJ2ZXIgYW5kIFRVUk4NCkxvY2FsIGZpcmV3YWxsIHRyYXZlcnNhbCENCg0K VmVyeSBjb252ZW5pZW50IHRvIGhhdmUgVENQL1RMUyBiZXR3ZWVuIHlvdSBhbmQgeW91ciBUVVJO IHNlcnZlciB0byBnZXQNCnRocm91Z2ggc3R1YmJvcm4gZmlyZXdhbGxzLiBMaWtld2lzZSBpdCBp cyB2ZXJ5IGNvbnZlbmllbnQgdG8gc3RpbGwgYmUgYWJsZSB0byB0YWxrDQp0byB0aGUgcmVtb3Rl IGhvc3Qgb24gVURQLiBUaGUgcmVtb3RlIGhvc3QgY2FuIGJlIGEgUkZMWCBhZGRyZXNzIG9mIGFu IElDRQ0KYWdlbnQsIGEgbGVnYWN5IFNJUCBlbmRwb2ludCB3aXRoIGEgcmVhY2hhYmxlIElQIGFu ZCBzbyBvbi4NCg0KDQpUVVJOIGFuZCBJQ0UgYXJlIG1haW5seSBkZWFsaW5nIHdpdGggdGhlIGNv bW11bmljYXRpb24gYmV0d2VlbiB0d28gaG9zdHMuDQpTb3J0IG9mLiBBbnkgYm94IHRoYXQgdGVy bWluYXRlcyBtZWRpYS4gSXQgY2FuIGJlIHN3aXRjaGVkIE1DVSBvciBzb21ldGhpbmcgbm90IGNs ZWFybHkgZGVmaW5lZCBhcyBhIGNsaWVudC4gVGhlIElDRSB0ZXJtIGlzIGFnZW50Lg0KDQpCZWZv cmUgdGhlaXIgY29tbXVuaWNhdGlvbiwgbm9ybWFsbHkgdGhleSB3aWxsIGFncmVlIHdpdGggd2hp Y2ggdHJhbnNwb3J0IHByb3RvY29sIHdpbGwgYmUgdXNlZC4NCk5vLiBUaGUgd2hvbGUgaWRlYSB3 aXRoIElDRSBpcyB0byBzYXkgdG8gdGhlIHJlbW90ZSBhZ2VudCBhbGwgdGhlIGRpZmZlcmVudCBw cm90b2NvbHMgYW5kIGFkZHJlc3NlcyB5b3UgY2FuIHJlY2VpdmUgbWVkaWEgb24uIElQdjQsIElQ djYsIFVEUCwgVENQLCBUTFMsIEhPU1QsIFJGTFgsIFJFTEFZIGFuZCBtdWx0aWhvbWVkIGhvc3Rz IG1ha2VzIHRoaXMgYSBuaWNlIGxpc3Qgb2YgcG9zc2libGUgY29tYmluYXRpb25zLg0KDQpGb3Ig dGhlIHNjZW5hcmlvcyB0aGF0IHlvdSBtZW50aW9uZWQgaGVyZShpdCBpcyBhbHNvIG1lbnRpb25l ZCBpbiB0aGUgb3JpZ2luYWwgZHJhZnQpLCAgdGhlIHR3byBwZWVycyBzaG91bGQgYm90aCBzZWxl Y3QgVENQIGFzIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wuIElmIG9uZSBsZWcoYmV0d2VlbiBjbGll bnQgYW5kIFRVUk4gc2VydmVyKSBzZWxlY3QgdGhlIFRDUCBhbmQgdGhlIG90aGVyIGxlZyhiZXR3 ZWVuIFRVUk4gc2VydmVyIGFuZCB0aGUgcGVlcikgc2VsZWN0IHRoZSBVRFAsIHRoZW4gdGhlIGFw cGxpY2F0aW9uIHRoYXQgYnVpbGRzIG9uIFRVUk4gd2lsbCBsb3NlIHRoZSBhZHZhbnRhZ2Ugb2Yg dGhlIGRhdGEgcmVsaWFiaWxpdHkoY2FuIGJlIGFzc3VyZWQgYnkgVENQKSBhbmQgZGF0YSBlZmZp Y2llbmN5KGNhbiBiZSByZWFjaGVkIGJ5IFVEUCkgYXQgdGhlIHNhbWUgdGltZS4gRG8geW91IHRo aW5rIHRoaXMgaXMgYSBnb29kIGRlc2lnbj8NCk15IG1haW4gcG9pbnQgaGVyZSBpcyB0aGF0IGFs dGhvdWdoIGl0IGlzIHBvc3NpYmxlIHRvIHVzZSB0aGUgZGlmZmVyZW50IHRyYW5zcG9ydCBwcm90 b2NvbHMgZm9yIHRoZXNlIHR3byBsZWdzLCB0aGVyZSBpcyBubyBiZW5lZml0cyB0byBkbyBzby4N Cg0KWW91IGFyZSBtaXhpbmcgdXAgdGhpbmdzLg0KDQpJZiB5b3UgaGF2ZSBhIHByb3RvY29sIHRo YXQgcmVxdWlyZXMgVENQIHlvdSB3aWxsIG9ubHkgdXNlIElDRSBUQ1AgY2FuZGlkYXRlcy4gSG93 IHRvIGRvIHRoaXMgd2l0aCBUVVJOIGlzIGRlc2NyaWJlZCBpbiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNjA2Mi4gRm9yIElDRSB0aGlzIGlzIGRlc2NyaWJlZCBpbiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNjU0NC4NCg0KRm9yIHByb3RvY29scyBsaWtlIFJUUCB0aGF0 IHdpdGggc29tZSBtb2RpZmljYXRpb25zIGNhbiBiZSBydW4gb3ZlciBVRFAgYW5kIFRDUCB0aGUg bG9jYWwgYWdlbnQgY2FuIG9mZmVyIGFsbCB0aGUgY2FuZGlkYXRlcyB0ZXN0IHdoYXQgd29ya3Mg YW5kIHRoZW4gcGljayB0aGUgYmVzdCBzdWl0ZWQuIEZvciBSVFAgVURQIGlzIHRoZSBiZXN0IGNo b2ljZS4gVXNpbmcgVENQIG9ubHkgYmV0d2VlbiBhZ2VudCBhbmQgVFVSTiBzZXJ2ZXIgaGFzIGEg bmljZSBzaWRlIGVmZmVjdCBvZiBrZWVwaW5nIHRoZSBUQ1AgcGF0aCBzaG9ydCBhbmQgeW91IGRv IG5vdCBuZWVkIGFuIGFkZGl0aW9uYWwgZnJhbWluZyBwcm90b2NvbCBhcyBUVVJOIHByb3ZpZGVz IHRoYXQuIChBcyBsb25nIGFzIHRoZSBwdWJsaWMgZmFjaW5nIHNpZGUgaXMgVURQIHRvd2FyZHMg dGhlIHJlbW90ZSBwZWVyKS4NCg0KSSB0aGluayB0aGlzIGlzIGFuIGV4Y2VsbGVudCBkZXNpZ24u IEl0IGdpdmVzIGFnZW50cyB0aGUgZmxleGliaWxpdHkgdG8gY2hvb3NlIGFuZCBjYW4gcHJvdmlk ZSBpbnRlcm9wIHdpdGggb2xkIHN5c3RlbXMuDQoNCg0KDQoyLiBBYm91dCBFRE0gTkFUIHRyYW5z dmVyc2FsIGJldHdlZW4gVFVSTiBzZXJ2ZXIgYW5kIHBlZXIgIlNlY3Rpb24NCg0KSSBkbyBub3Qg c2VlIGhvdyB0aGUgYWJvdmUgdGV4dCBjYW4gYmUgbWlzdW5kZXJzdG9vZC4NCg0KQWxsIHRoZXNl IHNlY3Rpb25zIGRlc2NyaWJlcyBjbGVhcmx5IG9ubHkgdGhlIGFwcGxpY2FibGUgc2NvcGUgb2Yg VFVSTiBidXQgbm90IHJlbGF0ZWQgdG8gbXkgY29uY2Vybi4gTXkgY29uY2VybiBpcyB0aGF0IGhv dyB5b3UgYXNzdXJlIHRoZSBVRFAgcGFja2V0IGZyb20gdGhlIFRVUk4gU2VydmVyIHRvIHBhc3Mg dGhyb3VnaCB0aGUgRURNIHR5cGUgTkFUIHRoYXQgbG9jYXRlZCBiZWZvcmUgdGhlIHBlZXI/DQoN Cg0KQW5kIHRoYXQgaXMgbm90IHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgVFVSTiBzZXJ2ZXIu IFRoZSBUVVJOIHNlcnZlciBpcyB0aGVyZSB0byBoZWxwIHlvdXIgYWdlbnQgZ2V0IHRocm91Z2gg eW91ciBvd24gZmlyZXdhbGwuIFdoYXQgdGhlIHJlbW90ZSBzaWRlIGRvZXMgdG8gZ2V0IHRocm91 Z2ggdGhlIGZpcmV3YWxsIGlzIG5vdCBzb21ldGhpbmcgeW91IGNhbiBmaXguIChPdGhlciB0aGFu IHJ1biBJQ0UgYW5kIGhvcGUgdGhhdCB0aGUgcmVtb3RlIHNpZGUgYWxzbyBkbyB0aGF0KQ0KDQoN CkkgdGhpbmsgeW91IHNob3VsZCBmb2xsb3cgdGhlIGFkdmljZSBmcm9tIHRoZSBJbnRyb2R1Y3Rp b246DQoiVFVSTiB3YXMgZGVzaWduZWQgYXMgb25lIHBpZWNlIGluIHRoZSBsYXJnZXIgSUNFIGFw cHJvYWNoIHRvIE5BVCAgdHJhdmVyc2FsLg0KSW1wbGVtZW50b3JzIG9mIFRVUk4gYXJlIHVyZ2Vk IHRvIGludmVzdGlnYXRlIElDRSBhbmQgIHNlcmlvdXNseSBjb25zaWRlcg0KdXNpbmcgaXQgZm9y IHRoZWlyIGFwcGxpY2F0aW9uLiAgSG93ZXZlciwgaXQgaXMgIHBvc3NpYmxlIHRvIHVzZSBUVVJO IHdpdGhvdXQNCklDRS7igJ0NCg0KDQpJdCBpcyBwb3NzaWJsZSB0byBkZXBsb3kgVFVSTiBzZXJ2 ZXJzIGluIGEgd2F5IHRoYXQgd291bGQgbm90IHdvcmsuIFRoaXMgaXMNCmJlY2F1c2UgdGhlIHNw ZWNzIHdhcyB3cml0dGVuIGluIGEgbm9uIGxpbWl0aW5nIHdheSB0byBhbGxvdyBmb3Igd2hhdCBl dmVyDQpkZXBsb3ltZW50IHNjZW5hcmlvcyB0aGF0IG1pZ2h0IGJlIHVzZWZ1bCB0byBkaWZmZXJl bnQgaW1wbGVtZW50b3JzLiBCdXQgSQ0KdGhpbmsgaXQgaXMgYWxzbyBkZXNjcmliZWQgaG93IHRv IGRlcGxveSBpdCBpbiBhIHdheSB0aGF0IGFjdHVhbGx5IHdvcmtzLg0KDQpJZiB0aGlzIHNwZWMg Y2FuJ3QgZXZlbiBmdWxmaWxsIHRoZSBnZW5lcmFsIGNvbW11bmljYXRpb24gc2NlbmFyaW9zLCB0 aGVuIGl0cyB1c2FnZSB3aWxsIGJlIGxpbWl0ZWQuIEZyb20gb3VyIHRlc3QgZXhwZXJpZW5jZXMs IG1vcmUgYW5kIG1vcmUgRURNIE5BVCBhcmUgbm93IGRlcGxveWVkLCBidXQgY3VycmVudCBzcGVj IGZvY3VzZXMgb25seSBvbmUgc3BlY2lhbCBzY2VuYXJpb3MuDQoNCg0KUlRDd2ViIHNlZW1zIHRv IHdvcmsgZmluZS4gQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbiBob3cgdHdvIGFnZW50cyBydW5uaW5n IElDRSBhbmQgVFVSTiBmYWlsIHRvIGNvbW11bmljYXRlPw0KDQpBbnkgZGF0YSBvbiBob3cgbWFu eSBjYWxscyBmYWlscz8NCg0KDQoNCg0KMy4gUmVsYXkgYmV0d2VlbiBtdWx0aXBsZSBUVVJOIFNl cnZlciBBcyB3ZSBkZXNjcmliZWQgaW4gdGhlIG1haWwNCg0KUmVsYXlpbmcgYmV0d2VlbiBzZXZl cmFsIFRVUk4gc2VydmVycyBzaG91bGQgbm90IGJlIGEgcGFydCBvZiB0aGUgVFVSTiBSRkMuDQpI b3cgdG8gaW5zdGFsbCBwZXJtaXNzaW9ucyBhbmQgc28gb24gaXMgZGVzY3JpYmVkIGluIHRoZSBJ Q0UgUkZDLg0KDQpUaGVuIHdlIGRldmVsb3BlZCBhbm90aGVyIGRyYWZ0IHRvIG1lZXQgdGhlIG11 bHRpcGxlIFRVUk4gU2VydmVycyBzY2VuYXJpb3M/IOKAnENyZWF0ZSBQZXJtaXNzaW9uIiBzZWN0 aW9uIGlzIGluY2x1ZGVkIGluIHRoaXMgZHJhZnQsIElDRShSRkMgNTI0NSkgb25seSBkZWFscyB3 aXRoIHRoZSBjb25uZWN0aXZpdHkgY2hlY2suDQoNCg0KSSBkbyBub3QgdGhpbmsgdGhlcmUgaXMg YSBtdWx0aXBsZSBUVVJOIHNjZW5hcmlvLiBCdXQgcGxlYXNlIHBvc3QgYSBkcmFmdCBleHBsYWlu aW5nIHRoZSBwcm9ibGVtLiBCdXQgYXMgZnJpZW5kbHkgYWR2aWNlIEkgd291bGQgZW5jb3VyYWdl IHlvdSB0byBjaXJjdWxhdGUgaXQgYSBiaXQgb2ZmIGxpc3QgYW5kIHRyeSB0byBnZXQgYSBmZWVs IG9mIGl0IGJlZm9yZSB5b3UgcG9zdCBhbmQgYXNrIGZvciBhIHByZXNlbnRhdGlvbiBzbG90Lg0K DQoNCg0KVG8gc3VtbWFyaXNlLiBFYWNoIGFnZW50IGhhcyBhIHJlc3BvbnNpYmlsaXR5IHRvIGdl dCB0aHJvdWdoIHRoZWlyIG93biBOQVQuIElmDQppdCBpcyBhIHJlc3RyaWN0aXZlIG9uZSBpdCBz aG91bGQgdXNlIFRVUk4gdG8gZ2V0IHRocm91Z2ggaXQuIFdoYXQgdGhlIHJlbW90ZQ0Kc2lkZSBp cyBkb2luZyB0byBnZXQgdGhyb3VnaCBoaXMgb3IgaGVyIE5BVCBpcyBub3QgeW91ciBwcm9ibGVt Lg0KDQpTbyBjdXJyZW50IFRVUk4gc3BlYyBjYW4ndCBiZSB1c2VkIGluZGVwZW5kZW50bHksIHRo ZXJlIG11c3QgZXhpc3Qgb3RoZXIgbWVjaGFuaXNtcyB0byBhc3N1cmUgaXQgd29yayBjb3JyZWN0 bHkuIEFzIHRoYXQgZGVzY3JpYmVkIGluIFtSRkM2MDYyXSwgdGhhdA0KDQoiLi4uLi4uLiBJdCBp cyBleHBlY3RlZCB0aGF0LCBiZXR3ZWVuIHRoZQ0KICAgICBmaXJzdCBhbmQgc2Vjb25kIHN0ZXBz LCB0aGUgY2xpZW50IHdpbGwgY29tbXVuaWNhdGUgb2ZmLWJhbmQgd2l0aA0KICAgICB0aGUgcGVl ciAoZS5nLiwgdXNpbmcgSUNFIFtSRkM1MjQ1XSkgYW5kIHRlbGwgaXQgdGhlIHJlbGF5ZWQNCiAg ICAgdHJhbnNwb3J0IGFkZHJlc3MgdGhhdCB0aGUgVFVSTiBzZXJ2ZXIgYWxsb2NhdGVkIGFuZCBm cm9tIHdoaWNoIGl0DQogICAgIGlzIGFib3V0IHRvIGluaXRpYXRlIGEgY29ubmVjdGlvbi4gIFRo ZSBwZWVyIGNhbiB0aGVuICJnZXQgcmVhZHkiOg0KICAgICBvcGVuIGhvbGVzIGluIGl0cyBmaXJl d2FsbCwgdHJ5IHRvIHBva2UgaG9sZXMgaW4gYSBOQVQsIGF0dGVtcHQgYQ0KICAgICBUQ1Agc2lt dWx0YW5lb3VzIG9wZW4sIGV0Yy4iDQoNCkNhbiB3ZSBkZXNpZ24gb25lIG5ldyBzb2x1dGlvbiBv ZiBUVVJOIHRvIGNvdmVyIGFsbCB0aGVzZSBpbmNvbXBsZXRlIHNvbHV0aW9ucz8gSXQgY2FuIGNv dmVyIGFsbW9zdCBhbGwgdGhlIHByb2JsZW1zKGV2ZW4gdGhlIGN1cnJlbnQgaG90IHRvcGljIOKA lOKAlOKAnA0KaXAgYWRkcmVzcyBwcml2YWN5IiApIHRoYXQgY3VycmVudCBUVVJOIHNwZWNzIHdh bnRzIHRvIHNvbHZlLCBidXQgaW4gb25lIHNpbXBsZXIgbWFubmVyLg0KDQoNCk5vdCBzdXJlIHdo YXQgeW91IHdhbnQgdG8gYWNoaWV2ZS4gSXQgaXMgaW1wb3J0YW50IHRoYXQgVFVSTiBpcyBub3Qg YW4gb3BlbiBwaW5ob2xlIHRocm91Z2ggdGhlIE5BVC9GVywgdGh1cyBpdCBpcyBpbXBvcnRhbnQg dG8gaGF2ZSB0aGUgcGVybWlzc2lvbnMgc2V0IGNvcnJlY3RseS4gSXRzIHByaW1hcnkgdXNlIGlz IHRvIGdldCBiaWRpcmVjdGlvbmFsIGNvbW11bmljYXRpb24gdXAgYW5kIGdvaW5nLCBub3QgdG8g YmUgYSBnZW5lcmFsIGZpcmV3YWxsIHBlbmV0cmF0aW9uIHByb3h5IHRoaW5nLg0KDQouLS4NClDD pWwtRXJpaw0KDQoNCi4tLg0KUMOlbC1FcmlrDQoNCg0KDQpSZWdhcmRzLA0KT2xlZw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5n IGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3Jn PG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90cmFtDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg== --_000_5F8B3F402232482789042562CF447497ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <28F3C4FF341DDB4FB5C7E16B9D19CE2A@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KT2ssIEkgd2lsbCB0cnkgdG8gZXhw bGFpbi4gV291bGQgYmUgbmljZSBpZiBzb21lIG90aGVycyAmbmJzcDtvbiB0aGUgbGlzdCBjYW4g dmVyaWZ5IHdoYXQgSSBzYXkgaXMgY29ycmVjdC4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij5PbiAwNSBGZWIgMjAxNSwgYXQgMDc6NTEsIEFpanVuIFdhbmcgJmx0OzxhIGhyZWY9Im1haWx0 bzp3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuIiBjbGFzcz0iIj53YW5nYWlqdW5AdHNpbmdodWEu b3JnLmNuPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdl LW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPjEuIEFib3V0IFRyYW5zcG9ydCBwcm90b2NvbDxiciBjbGFzcz0iIj4NCiZxdW90O1NlY3Rp b24gMi4xIFRyYW5zcG9ydHMmcXVvdDsgZGVzY3JpYmUgdGhlIHJlYXNvbiB0aGF0IHVzZSBkaWZm ZXJlbnQgPGJyIGNsYXNzPSIiPg0KdHJhbnNwb3J0IHByb3RvY29sIGJldHdlZW4gVFVSTiBDbGll bnQvVFVSTiBTZXJ2ZXIgYW5kIFRVUk48YnIgY2xhc3M9IiI+DQpMb2NhbCBmaXJld2FsbCB0cmF2 ZXJzYWwhPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVmVyeSBjb252ZW5pZW50IHRvIGhh dmUgVENQL1RMUyBiZXR3ZWVuIHlvdSBhbmQgeW91ciBUVVJOIHNlcnZlciB0byBnZXQ8YnIgY2xh c3M9IiI+DQp0aHJvdWdoIHN0dWJib3JuIGZpcmV3YWxscy4gTGlrZXdpc2UgaXQgaXMgdmVyeSBj b252ZW5pZW50IHRvIHN0aWxsIGJlIGFibGUgdG8gdGFsazxiciBjbGFzcz0iIj4NCnRvIHRoZSBy ZW1vdGUgaG9zdCBvbiBVRFAuIFRoZSByZW1vdGUgaG9zdCBjYW4gYmUgYSBSRkxYIGFkZHJlc3Mg b2YgYW4gSUNFPGJyIGNsYXNzPSIiPg0KYWdlbnQsIGEgbGVnYWN5IFNJUCBlbmRwb2ludCB3aXRo IGEgcmVhY2hhYmxlIElQIGFuZCBzbyBvbi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpUVVJOIGFuZCBJQ0UgYXJlIG1haW5seSBkZWFs aW5nIHdpdGggdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiB0d28gaG9zdHMuIDwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj5Tb3J0IG9mLiBBbnkgYm94IHRoYXQgdGVybWluYXRlcyBtZWRpYS4g SXQgY2FuIGJlIHN3aXRjaGVkIE1DVSBvciBzb21ldGhpbmcgbm90IGNsZWFybHkgZGVmaW5lZCBh cyBhIGNsaWVudC4gVGhlIElDRSB0ZXJtIGlzIGFnZW50LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj5CZWZvcmUgdGhlaXIgY29tbXVuaWNhdGlvbiwgbm9ybWFsbHkgdGhleSB3aWxs IGFncmVlIHdpdGggd2hpY2ggdHJhbnNwb3J0IHByb3RvY29sIHdpbGwgYmUgdXNlZC4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj5Oby4gVGhlIHdob2xlIGlkZWEgd2l0aCBJQ0UgaXMgdG8g c2F5IHRvIHRoZSByZW1vdGUgYWdlbnQgYWxsIHRoZSBkaWZmZXJlbnQgcHJvdG9jb2xzIGFuZCBh ZGRyZXNzZXMgeW91IGNhbiByZWNlaXZlIG1lZGlhIG9uLiBJUHY0LCBJUHY2LCBVRFAsIFRDUCwg VExTLCBIT1NULCBSRkxYLCBSRUxBWSBhbmQgbXVsdGlob21lZCBob3N0cyBtYWtlcyB0aGlzIGEg bmljZSBsaXN0IG9mIHBvc3NpYmxlIGNvbWJpbmF0aW9ucy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+Rm9yIHRoZSBzY2VuYXJpb3MgdGhhdCB5b3UgbWVudGlvbmVkIGhlcmUoaXQg aXMgYWxzbyBtZW50aW9uZWQgaW4gdGhlIG9yaWdpbmFsIGRyYWZ0KSwgJm5ic3A7dGhlIHR3byBw ZWVycyBzaG91bGQgYm90aCBzZWxlY3QgVENQIGFzIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wuIElm IG9uZSBsZWcoYmV0d2VlbiBjbGllbnQgYW5kIFRVUk4gc2VydmVyKSBzZWxlY3QgdGhlIFRDUCBh bmQgdGhlIG90aGVyIGxlZyhiZXR3ZWVuIFRVUk4gc2VydmVyDQogYW5kIHRoZSBwZWVyKSBzZWxl Y3QgdGhlIFVEUCwgdGhlbiB0aGUgYXBwbGljYXRpb24gdGhhdCBidWlsZHMgb24gVFVSTiB3aWxs IGxvc2UgdGhlIGFkdmFudGFnZSBvZiB0aGUgZGF0YSByZWxpYWJpbGl0eShjYW4gYmUgYXNzdXJl ZCBieSBUQ1ApIGFuZCBkYXRhIGVmZmljaWVuY3koY2FuIGJlIHJlYWNoZWQgYnkgVURQKSBhdCB0 aGUgc2FtZSB0aW1lLiBEbyB5b3UgdGhpbmsgdGhpcyBpcyBhIGdvb2QgZGVzaWduPw0KPGJyIGNs YXNzPSIiPg0KTXkgbWFpbiBwb2ludCBoZXJlIGlzIHRoYXQgYWx0aG91Z2ggaXQgaXMgcG9zc2li bGUgdG8gdXNlIHRoZSBkaWZmZXJlbnQgdHJhbnNwb3J0IHByb3RvY29scyBmb3IgdGhlc2UgdHdv IGxlZ3MsIHRoZXJlIGlzIG5vIGJlbmVmaXRzIHRvIGRvIHNvLg0KPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PllvdSBhcmUgbWl4aW5nIHVw IHRoaW5ncy48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PklmIHlvdSBo YXZlIGEgcHJvdG9jb2wgdGhhdCByZXF1aXJlcyBUQ1AgeW91IHdpbGwgb25seSB1c2UgSUNFIFRD UCBjYW5kaWRhdGVzLiBIb3cgdG8gZG8gdGhpcyB3aXRoIFRVUk4gaXMgZGVzY3JpYmVkIGluJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYwNjIiIGNsYXNzPSIi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MDYyPC9hPi4gRm9yIElDRSB0aGlzIGlz IGRlc2NyaWJlZCBpbiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM2NTQ0IiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjU0NDwvYT4u PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5Gb3IgcHJvdG9jb2xzIGxp a2UgUlRQIHRoYXQgd2l0aCBzb21lIG1vZGlmaWNhdGlvbnMgY2FuIGJlIHJ1biBvdmVyIFVEUCBh bmQgVENQIHRoZSBsb2NhbCBhZ2VudCBjYW4gb2ZmZXIgYWxsIHRoZSBjYW5kaWRhdGVzIHRlc3Qg d2hhdCB3b3JrcyBhbmQgdGhlbiBwaWNrIHRoZSBiZXN0IHN1aXRlZC4gRm9yIFJUUCBVRFAgaXMg dGhlIGJlc3QgY2hvaWNlLiBVc2luZyBUQ1Agb25seSBiZXR3ZWVuIGFnZW50IGFuZCBUVVJOIHNl cnZlciBoYXMNCiBhIG5pY2Ugc2lkZSBlZmZlY3Qgb2Yga2VlcGluZyB0aGUgVENQIHBhdGggc2hv cnQgYW5kIHlvdSBkbyBub3QgbmVlZCBhbiBhZGRpdGlvbmFsIGZyYW1pbmcgcHJvdG9jb2wgYXMg VFVSTiBwcm92aWRlcyB0aGF0LiAoQXMgbG9uZyBhcyB0aGUgcHVibGljIGZhY2luZyBzaWRlIGlz IFVEUCB0b3dhcmRzIHRoZSByZW1vdGUgcGVlcikuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdj5JIHRoaW5rIHRoaXMgaXMgYW4gZXhjZWxsZW50IGRlc2lnbi4gSXQgZ2l2 ZXMgYWdlbnRzIHRoZSBmbGV4aWJpbGl0eSB0byBjaG9vc2UgYW5kIGNhbiBwcm92aWRlIGludGVy b3Agd2l0aCBvbGQgc3lzdGVtcy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KMi4gQWJvdXQgRURNIE5BVCB0cmFuc3ZlcnNhbCBiZXR3ZWVuIFRV Uk4gc2VydmVyIGFuZCBwZWVyICZxdW90O1NlY3Rpb248YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpJIGRvIG5vdCBzZWUgaG93IHRoZSBh Ym92ZSB0ZXh0IGNhbiBiZSBtaXN1bmRlcnN0b29kLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90 ZT4NCjxiciBjbGFzcz0iIj4NCkFsbCB0aGVzZSBzZWN0aW9ucyBkZXNjcmliZXMgY2xlYXJseSBv bmx5IHRoZSBhcHBsaWNhYmxlIHNjb3BlIG9mIFRVUk4gYnV0IG5vdCByZWxhdGVkIHRvIG15IGNv bmNlcm4uIE15IGNvbmNlcm4gaXMgdGhhdCBob3cgeW91IGFzc3VyZSB0aGUgVURQIHBhY2tldCBm cm9tIHRoZSBUVVJOIFNlcnZlciB0byBwYXNzIHRocm91Z2ggdGhlIEVETSB0eXBlIE5BVCB0aGF0 IGxvY2F0ZWQgYmVmb3JlIHRoZSBwZWVyPw0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5B bmQgdGhhdCBpcyBub3QgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBUVVJOIHNlcnZlci4gVGhl IFRVUk4gc2VydmVyIGlzIHRoZXJlIHRvIGhlbHAgeW91ciBhZ2VudCBnZXQgdGhyb3VnaCB5b3Vy IG93biBmaXJld2FsbC4gV2hhdCB0aGUgcmVtb3RlIHNpZGUgZG9lcyB0byBnZXQgdGhyb3VnaCB0 aGUgZmlyZXdhbGwgaXMgbm90IHNvbWV0aGluZyB5b3UgY2FuIGZpeC4gKE90aGVyIHRoYW4gcnVu IElDRSBhbmQgaG9wZSB0aGF0IHRoZQ0KIHJlbW90ZSBzaWRlIGFsc28gZG8gdGhhdCkmbmJzcDs8 L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj5JIHRoaW5rIHlvdSBzaG91bGQgZm9sbG93IHRoZSBhZHZpY2Ug ZnJvbSB0aGUgSW50cm9kdWN0aW9uOjxiciBjbGFzcz0iIj4NCiZxdW90O1RVUk4gd2FzIGRlc2ln bmVkIGFzIG9uZSBwaWVjZSBpbiB0aGUgbGFyZ2VyIElDRSBhcHByb2FjaCB0byBOQVQgJm5ic3A7 dHJhdmVyc2FsLjxiciBjbGFzcz0iIj4NCkltcGxlbWVudG9ycyBvZiBUVVJOIGFyZSB1cmdlZCB0 byBpbnZlc3RpZ2F0ZSBJQ0UgYW5kICZuYnNwO3NlcmlvdXNseSBjb25zaWRlcjxiciBjbGFzcz0i Ij4NCnVzaW5nIGl0IGZvciB0aGVpciBhcHBsaWNhdGlvbi4gJm5ic3A7SG93ZXZlciwgaXQgaXMg Jm5ic3A7cG9zc2libGUgdG8gdXNlIFRVUk4gd2l0aG91dDxiciBjbGFzcz0iIj4NCklDRS7igJ08 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJdCBpcyBwb3NzaWJs ZSB0byBkZXBsb3kgVFVSTiBzZXJ2ZXJzIGluIGEgd2F5IHRoYXQgd291bGQgbm90IHdvcmsuIFRo aXMgaXM8YnIgY2xhc3M9IiI+DQpiZWNhdXNlIHRoZSBzcGVjcyB3YXMgd3JpdHRlbiBpbiBhIG5v biBsaW1pdGluZyB3YXkgdG8gYWxsb3cgZm9yIHdoYXQgZXZlcjxiciBjbGFzcz0iIj4NCmRlcGxv eW1lbnQgc2NlbmFyaW9zIHRoYXQgbWlnaHQgYmUgdXNlZnVsIHRvIGRpZmZlcmVudCBpbXBsZW1l bnRvcnMuIEJ1dCBJPGJyIGNsYXNzPSIiPg0KdGhpbmsgaXQgaXMgYWxzbyBkZXNjcmliZWQgaG93 IHRvIGRlcGxveSBpdCBpbiBhIHdheSB0aGF0IGFjdHVhbGx5IHdvcmtzLjxiciBjbGFzcz0iIj4N CjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCklmIHRoaXMgc3BlYyBjYW4ndCBldmVuIGZ1 bGZpbGwgdGhlIGdlbmVyYWwgY29tbXVuaWNhdGlvbiBzY2VuYXJpb3MsIHRoZW4gaXRzIHVzYWdl IHdpbGwgYmUgbGltaXRlZC4gRnJvbSBvdXIgdGVzdCBleHBlcmllbmNlcywgbW9yZSBhbmQgbW9y ZSBFRE0gTkFUIGFyZSBub3cgZGVwbG95ZWQsIGJ1dCBjdXJyZW50IHNwZWMgZm9jdXNlcyBvbmx5 IG9uZSBzcGVjaWFsIHNjZW5hcmlvcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlJUQ3dl YiBzZWVtcyB0byB3b3JrIGZpbmUuIENhbiB5b3UgcGxlYXNlIGV4cGxhaW4gaG93IHR3byBhZ2Vu dHMgcnVubmluZyBJQ0UgYW5kIFRVUk4gZmFpbCB0byBjb21tdW5pY2F0ZT88L2Rpdj4NCjxkaXY+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkFueSBkYXRhIG9uIGhvdyBtYW55IGNhbGxzIGZh aWxzPyZuYnNwOzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KMy4gUmVsYXkgYmV0d2VlbiBtdWx0aXBsZSBUVVJOIFNlcnZlciBBcyB3 ZSBkZXNjcmliZWQgaW4gdGhlIG1haWw8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpSZWxheWluZyBiZXR3ZWVuIHNldmVyYWwgVFVSTiBz ZXJ2ZXJzIHNob3VsZCBub3QgYmUgYSBwYXJ0IG9mIHRoZSBUVVJOIFJGQy48YnIgY2xhc3M9IiI+ DQpIb3cgdG8gaW5zdGFsbCBwZXJtaXNzaW9ucyBhbmQgc28gb24gaXMgZGVzY3JpYmVkIGluIHRo ZSBJQ0UgUkZDLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClRo ZW4gd2UgZGV2ZWxvcGVkIGFub3RoZXIgZHJhZnQgdG8gbWVldCB0aGUgbXVsdGlwbGUgVFVSTiBT ZXJ2ZXJzIHNjZW5hcmlvcz8g4oCcQ3JlYXRlIFBlcm1pc3Npb24mcXVvdDsgc2VjdGlvbiBpcyBp bmNsdWRlZCBpbiB0aGlzIGRyYWZ0LCBJQ0UoUkZDIDUyNDUpIG9ubHkgZGVhbHMgd2l0aCB0aGUg Y29ubmVjdGl2aXR5IGNoZWNrLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SSBkbyBub3Qg dGhpbmsgdGhlcmUgaXMgYSBtdWx0aXBsZSBUVVJOIHNjZW5hcmlvLiBCdXQgcGxlYXNlIHBvc3Qg YSBkcmFmdCBleHBsYWluaW5nIHRoZSBwcm9ibGVtLiBCdXQgYXMgZnJpZW5kbHkgYWR2aWNlIEkg d291bGQgZW5jb3VyYWdlIHlvdSB0byBjaXJjdWxhdGUgaXQgYSBiaXQgb2ZmIGxpc3QgYW5kIHRy eSB0byBnZXQgYSBmZWVsIG9mIGl0IGJlZm9yZSB5b3UgcG9zdCBhbmQgYXNrIGZvciBhIHByZXNl bnRhdGlvbiBzbG90LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NClRvIHN1bW1h cmlzZS4gRWFjaCBhZ2VudCBoYXMgYSByZXNwb25zaWJpbGl0eSB0byBnZXQgdGhyb3VnaCB0aGVp ciBvd24gTkFULiBJZjxiciBjbGFzcz0iIj4NCml0IGlzIGEgcmVzdHJpY3RpdmUgb25lIGl0IHNo b3VsZCB1c2UgVFVSTiB0byBnZXQgdGhyb3VnaCBpdC4gV2hhdCB0aGUgcmVtb3RlPGJyIGNsYXNz PSIiPg0Kc2lkZSBpcyBkb2luZyB0byBnZXQgdGhyb3VnaCBoaXMgb3IgaGVyIE5BVCBpcyBub3Qg eW91ciBwcm9ibGVtLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4N ClNvIGN1cnJlbnQgVFVSTiBzcGVjIGNhbid0IGJlIHVzZWQgaW5kZXBlbmRlbnRseSwgdGhlcmUg bXVzdCBleGlzdCBvdGhlciBtZWNoYW5pc21zIHRvIGFzc3VyZSBpdCB3b3JrIGNvcnJlY3RseS4g QXMgdGhhdCBkZXNjcmliZWQgaW4gW1JGQzYwNjJdLCB0aGF0DQo8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQomcXVvdDsuLi4uLi4uIEl0IGlzIGV4cGVjdGVkIHRoYXQsIGJldHdlZW4gdGhl PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Zmlyc3QgYW5kIHNlY29uZCBzdGVwcywgdGhlIGNsaWVudCB3 aWxsIGNvbW11bmljYXRlIG9mZi1iYW5kIHdpdGg8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDt0aGUgcGVlciAoZS5nLiwgdXNpbmcgSUNFIFtSRkM1MjQ1XSkgYW5k IHRlbGwgaXQgdGhlIHJlbGF5ZWQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDt0cmFuc3BvcnQgYWRkcmVzcyB0aGF0IHRoZSBUVVJOIHNlcnZlciBhbGxvY2F0ZWQg YW5kIGZyb20gd2hpY2ggaXQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtpcyBhYm91dCB0byBpbml0aWF0ZSBhIGNvbm5lY3Rpb24uICZuYnNwO1RoZSBwZWVyIGNh biB0aGVuICZxdW90O2dldCByZWFkeSZxdW90Ozo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtvcGVuIGhvbGVzIGluIGl0cyBmaXJld2FsbCwgdHJ5IHRvIHBva2Ug aG9sZXMgaW4gYSBOQVQsIGF0dGVtcHQgYTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO1RDUCBzaW11bHRhbmVvdXMgb3BlbiwgZXRjLiZxdW90OzxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkNhbiB3ZSBkZXNpZ24gb25lIG5ldyBz b2x1dGlvbiBvZiBUVVJOIHRvIGNvdmVyIGFsbCB0aGVzZSBpbmNvbXBsZXRlIHNvbHV0aW9ucz8g SXQgY2FuIGNvdmVyIGFsbW9zdCBhbGwgdGhlIHByb2JsZW1zKGV2ZW4gdGhlIGN1cnJlbnQgaG90 IHRvcGljIOKAlOKAlOKAnDwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPmlwIGFkZHJlc3MgcHJpdmFjeSZxdW90OyAp IHRoYXQgY3VycmVudCBUVVJOIHNwZWNzIHdhbnRzIHRvIHNvbHZlLCBidXQgaW4gb25lIHNpbXBs ZXIgbWFubmVyLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Tm90IHN1cmUgd2hhdCB5b3Ug d2FudCB0byBhY2hpZXZlLiBJdCBpcyBpbXBvcnRhbnQgdGhhdCBUVVJOIGlzIG5vdCBhbiBvcGVu IHBpbmhvbGUgdGhyb3VnaCB0aGUgTkFUL0ZXLCB0aHVzIGl0IGlzIGltcG9ydGFudCB0byBoYXZl IHRoZSBwZXJtaXNzaW9ucyBzZXQgY29ycmVjdGx5LiBJdHMgcHJpbWFyeSB1c2UgaXMgdG8gZ2V0 IGJpZGlyZWN0aW9uYWwgY29tbXVuaWNhdGlvbiB1cCBhbmQgZ29pbmcsIG5vdCB0byBiZSBhIGdl bmVyYWwNCiBmaXJld2FsbCBwZW5ldHJhdGlvbiBwcm94eSB0aGluZy48L2Rpdj4NCjxkaXY+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pi4tLjwvZGl2Pg0KPGRpdj5Qw6VsLUVyaWs8L2Rpdj4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4uLS48YnIgY2xhc3M9IiI+DQpQw6VsLUVyaWs8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpSZWdhcmRzLDxiciBjbGFzcz0iIj4NCk9sZWc8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxiciBjbGFzcz0iIj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0K PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIGNsYXNzPSIiPnRyYW1AaWV0Zi5vcmc8L2E+ PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFt PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQp0cmFtIG1h aWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiBj bGFzcz0iIj50cmFtQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnIgY2xh c3M9IiI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgY2xhc3M9IiI+dHJhbUBpZXRm Lm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RyYW08YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5F8B3F402232482789042562CF447497ciscocom_-- From nobody Thu Feb 5 16:51:41 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876F31A0217 for ; Thu, 5 Feb 2015 16:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5cj1o-q0qVc for ; Thu, 5 Feb 2015 16:51:30 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B521A0027 for ; Thu, 5 Feb 2015 16:51:29 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id l13so9540443iga.1 for ; Thu, 05 Feb 2015 16:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zUuw2MQ7y2m+mRp4tT0bYp2MBZkIKVNGD8B8g0Bbt/Y=; b=kqi/pmMG/tz3xqZyML6MZ6jCcOOkTTYRv6by4Wt0WDbC0hiZfD2nFHeAX8r7HqLymL p/XTH7UFzi8JBSDZ3DCnALd+lqw06gYqV/zjizOd2TpkUKu3WUVW8jIw0qsG8wqKOUL+ IypMbnFCSWkYdl9ZwI5zAVX75cnIAaDhKwCqOld0Y+TBKpjmiXrq6dGvx2LrpkfUSTNG 66r/t1yTsrYXb5aLgSLxp/aQNTCHdHNIl2kRB5ODr5SkcgBCNbwmU5/bB+MqSgLTuDJx 53EWVMxd4wIRR8SXELF50xgdyuiaz6RLqg+MzXi64LweCLkpXRh/Y43Pmd1JMzWphRWC Fdyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zUuw2MQ7y2m+mRp4tT0bYp2MBZkIKVNGD8B8g0Bbt/Y=; b=Nu5d8yGbo5rPqhVmTvaRJSGc8t88OMZXzfU7SpIO06d1S9pQhZ5NeSTzXQ3sQBsfqj m1f0dLbametGwdAu8oyRwMxn/SFln0qTcLx/NjSZTS9ei9CFTCVK+c3eoPKMTZIRBWWs klLOYQhuADpTGJlVrDK2FxwkVjjMbrFqMmodZbxh9GKYIDLCpF+UerpV4573KJ1OJJTI kgQGzvMjGRvahyqIDP7HaWxuqwsbP/VqYETUCvH7w44DvGKSb2flmBYCMTRavc6aRKIu 8g+jLZ0X/YmpcOsuVt8RQt4drC8uuP45J/N69Zk46hD7vcAm/G0lJBGJdjhRUPI7LkbU C+lg== X-Gm-Message-State: ALoCoQkpdLOZ1AVGvTR/cEzkxTgnkdGvdbbXVN+lJneHZiNeIuwyq7x1GsmC1tLBN9oQ9XUU68Jx X-Received: by 10.43.140.68 with SMTP id iz4mr5496067icc.77.1423183888983; Thu, 05 Feb 2015 16:51:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.66 with HTTP; Thu, 5 Feb 2015 16:51:08 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A355390B9@xmb-rcd-x10.cisco.com> References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35538E3D@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35538F91@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A355390B9@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Thu, 5 Feb 2015 16:51:08 -0800 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a11c335f6274572050e60d231 Archived-At: Cc: Simon Perreault , Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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: Fri, 06 Feb 2015 00:51:31 -0000 --001a11c335f6274572050e60d231 Content-Type: text/plain; charset=UTF-8 I agree with Simon and Ben in being skeptical about this proposal. The client is the only party which knows exactly what 'privacy' means, and there is no trivial way to serialize this into a single attribute for the TURN server. As such, I think this decision should be left entirely to the client. On Wed, Feb 4, 2015 at 10:50 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > I agree that the client can do equally well itself, by sending a STUN > Binding Request and comparing the response to the TURN server's own IP > address. > > > > [TR3] The difference this draft brings in is that it helps the TURN server > (offered by a global or cloud service) to determine that the client wants > privacy and level of privacy required conveyed in the new STUN attribute, > the TURN server determines suitable alternate TURN server that can offer > the required level of privacy. > > > > -Tiru > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --001a11c335f6274572050e60d231 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Simon and Ben in being skeptical about this p= roposal.

The client is the only party which knows exactl= y what 'privacy' means, and there is no trivial way to serialize th= is into a single attribute for the TURN server.

As= such, I think this decision should be left entirely to the client.

On Wed, Feb 4= , 2015 at 10:50 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>= ; wrote:

I agree that the client can do equally well itself, = by sending a STUN Binding Request and comparing the response to the TURN se= rver's own IP address.=C2=A0

=C2=A0

[TR3] The differen= ce this draft brings in is that it helps the TURN server (offered by a glob= al or cloud service) to determine that the client wants privacy and level of privacy required conveyed in the new STUN attribute, the TURN= server determines suitable alternate TURN server that can offer the requir= ed level of privacy.

=C2=A0

-Tiru


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


--001a11c335f6274572050e60d231-- From nobody Thu Feb 5 17:17:13 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD80A1A00E7; Thu, 5 Feb 2015 17:17:04 -0800 (PST) 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 6uRgegLsP9qL; Thu, 5 Feb 2015 17:17:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 373EB1A0067; Thu, 5 Feb 2015 17:17:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206011702.17303.16733.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 17:17:02 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-09.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: Fri, 06 Feb 2015 01:17:05 -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-09.txt Pages : 23 Date : 2015-02-05 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 ensures 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-09 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 Thu Feb 5 17:20:22 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920B91A00E6 for ; Thu, 5 Feb 2015 17:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ofo5x_n3sb8l for ; Thu, 5 Feb 2015 17:20:09 -0800 (PST) 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 849FB1A00D1 for ; Thu, 5 Feb 2015 17:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2138; q=dns/txt; s=iport; t=1423185609; x=1424395209; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EfVyJXTqwOWnfMU0jnK0YF3E5Gr3KLOUGpr2FuVgcwg=; b=UDvWMCz3BdjcaeUu43FEL4RnyHZbcNyrU+trkaZEFUIyxh6We06sJYdb cLUWsXe6Tf5UIZhOseKCVfun9rc5kicWmUZ7SAvnf6gVkauKSAlnOWGyA kRyDx7Dmd5YMTrYTb1urZmYx3Ttaj9ujR17VawEjMx/SbqJlE9zDXRAZY Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BRBQDlFdRU/4oNJK1agwZSVAUEwCiCHAyFbwKBIEMBAQEBAX2EDAEBAQQBAQE3NAsMBAIBCBEEAQELFAkHJwsUCQgCBA4FCAGIJAgF1gYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj0cxBwaDEIETBY8Yg1CGczaCTY5RIoNub4EEJBx+AQEB X-IronPort-AV: E=Sophos;i="5.09,527,1418083200"; d="scan'208";a="121043900" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP; 06 Feb 2015 01:20:08 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t161K8Ib024047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 01:20:08 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 5 Feb 2015 19:20:08 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-09.txt Thread-Index: AQHQQaquAGIReu9GC0yclGTQ+U0iDJzi0lcw Date: Fri, 6 Feb 2015 01:20:08 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35539EC2@xmb-rcd-x10.cisco.com> References: <20150206011702.17303.16733.idtracker@ietfa.amsl.com> In-Reply-To: <20150206011702.17303.16733.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.88.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Yaron Sheffer \(yaronf.ietf@gmail.com\)" , "Tom Taylor \(tom.taylor.stds@gmail.com\)" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-09.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, 06 Feb 2015 01:20:16 -0000 This revision addresses comments from Yaron and Tom. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, February 06, 2015 6:47 AM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-09.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-09.txt > Pages : 23 > Date : 2015-02-05 >=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 ensures > 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-09 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-third-party-authz= -09 >=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 Feb 6 02:18:48 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5951A1B2E for ; Fri, 6 Feb 2015 02:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw7gIuhSz3oG for ; Fri, 6 Feb 2015 02:18:11 -0800 (PST) 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 C046A1A1B23 for ; Fri, 6 Feb 2015 02:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4254; q=dns/txt; s=iport; t=1423217892; x=1424427492; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PsHnTafh/a7uL3LYyV2s+6Yk/R3z07Mgg42Vlh8ooSA=; b=VD4LX1a5tT8huP9lDGZ5ugGDbJLba3nbL7w7NkDzyoh5w8S/4A6J+xbu GAMS0wYh6SCps1UplWMgNNu3yMhcVIP1v9bK+vJRqe1KD3//1SM4UFk1I 0fD4RzSOg0az/6WTdBxZXh2OBVA5tj2/KANGnl9sg9Yq5hHcgxfEtEiCN U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQGAO+T1FStJA2I/2dsb2JhbABagwZSVAUEgn29NIIcCoVxAhyBAEMBAQEBAX2EDAEBAQMBAQEBIBE6CwwEAgEIEQQBAQECAgYdAwICAh8GCxQBCAgCBAENBQgBiBADCQgIBb5pkEoNhUwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGMLYF5FhsHBoJiLoETBY8Yg1CEFoJdNoJNiFGCQoM+IoF/H4FQbwGBAyQcfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,528,1418083200"; d="scan'208";a="393976246" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP; 06 Feb 2015 10:18:12 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t16AIAWT011723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 10:18:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 6 Feb 2015 04:18:10 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Yaron Sheffer , "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-09.txt Thread-Index: AQHQQaquAGIReu9GC0yclGTQ+U0iDJzi0lcwgAD4A4D//55iIA== Date: Fri, 6 Feb 2015 10:18:09 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3553A271@xmb-rcd-x10.cisco.com> References: <20150206011702.17303.16733.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35539EC2@xmb-rcd-x10.cisco.com> <54D4921B.7060801@gmail.com> In-Reply-To: <54D4921B.7060801@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.102] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Tom Taylor \(tom.taylor.stds@gmail.com\)" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-09.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, 06 Feb 2015 10:18:16 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBZYXJvbiBTaGVmZmVyIFttYWls dG86eWFyb25mLmlldGZAZ21haWwuY29tXQ0KPiBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA2LCAy MDE1IDM6MzYgUE0NCj4gVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IHRyYW1AaWV0 Zi5vcmcNCj4gQ2M6IFRvbSBUYXlsb3IgKHRvbS50YXlsb3Iuc3Rkc0BnbWFpbC5jb20pDQo+IFN1 YmplY3Q6IFJlOiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQt cGFydHktYXV0aHotMDkudHh0DQo+IA0KPiBIaSBUaXJ1LA0KPiANCj4gVGhhbmtzIGZvciB0aGUg bmV3IHJldmlzaW9uLiBPbmUgcmVtYWluaW5nIGNvbW1lbnQ6DQo+IA0KPiBMb29raW5nIGF0IDQu MS4xIGFuZCB0aGUgSEtERiBhbGdvcml0aG0sIEkgYmVsaWV2ZSB0aGF0IHlvdXIgQVVUSCBrZXkg aXMNCj4gaWRlbnRpY2FsIHRvIHRoZSBmaXJzdCAyMCBieXRlcyBvZiB0aGUgQVMtUlMga2V5LCB3 aGljaCBpcyBkZWZpbml0ZWx5IG5vdCB3aGF0DQo+IHlvdSdkIHdhbnQuIEFzIEknbSBzdXJlIHlv dSBrbm93LCB0aGUgc3RhbmRhcmQgd2F5IHRvIHNlcGFyYXRlIHR3byBkZXJpdmVkDQo+IGtleXMg aXMgdG8gYXBwZW5kIGEgc3RyaW5nIGxpa2UgImF1dGgiIG9yICJhcy1ycyIgdG8gdGhlIGlucHV0 Lg0KDQpHb29kIGNhdGNoLCBmaXhlZC4NCg0KLVRpcnUNCg0KPiANCj4gVGhhbmtzLA0KPiAJWWFy b24NCj4gDQo+IE9uIDAyLzA2LzIwMTUgMDM6MjAgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGly ZWRkeSkgd3JvdGU6DQo+ID4gVGhpcyByZXZpc2lvbiBhZGRyZXNzZXMgY29tbWVudHMgZnJvbSBZ YXJvbiBhbmQgVG9tLg0KPiA+DQo+ID4gLVRpcnUNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtDQo+ID4+IGRyYWZ0c0BpZXRmLm9yZw0KPiA+PiBTZW50 OiBGcmlkYXksIEZlYnJ1YXJ5IDA2LCAyMDE1IDY6NDcgQU0NCj4gPj4gVG86IGktZC1hbm5vdW5j ZUBpZXRmLm9yZw0KPiA+PiBDYzogdHJhbUBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBbdHJhbV0g SS1EIEFjdGlvbjoNCj4gPj4gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHot MDkudHh0DQo+ID4+DQo+ID4+DQo+ID4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPiBkaXJlY3Rvcmllcy4NCj4gPj4g ICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUVVJOIFJldmlzZWQgYW5kIE1vZGVy bml6ZWQNCj4gPj4gV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4gPj4NCj4gPj4gICAgICAg ICAgVGl0bGUgICAgICAgICAgIDogU2Vzc2lvbiBUcmF2ZXJzYWwgVXRpbGl0aWVzIGZvciBOQVQg KFNUVU4pIEV4dGVuc2lvbiBmb3INCj4gVGhpcmQNCj4gPj4gUGFydHkgQXV0aG9yaXphdGlvbg0K PiA+PiAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgUHJhc2hhbnRoIFBhdGlsDQo+ID4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFJhbSBNb2hhbiBSYXZpbmRyYW5hdGgNCj4gPj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgSnVzdGluIFViZXJ0aQ0KPiA+PiAJRmlsZW5hbWUgICAgICAgIDog ZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDkudHh0DQo+ID4+IAlQYWdl cyAgICAgICAgICAgOiAyMw0KPiA+PiAJRGF0ZSAgICAgICAgICAgIDogMjAxNS0wMi0wNQ0KPiA+ Pg0KPiA+PiBBYnN0cmFjdDoNCj4gPj4gICAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdGhlIHVz ZSBvZiBPQXV0aCB0byBvYnRhaW4gYW5kIHZhbGlkYXRlDQo+ID4+ICAgICBlcGhlbWVyYWwgdG9r ZW5zIHRoYXQgY2FuIGJlIHVzZWQgZm9yIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IN Cj4gPj4gICAgIE5BVCAoU1RVTikgYXV0aGVudGljYXRpb24uICBUaGUgdXNhZ2Ugb2YgZXBoZW1l cmFsIHRva2VucyBlbnN1cmVzDQo+ID4+ICAgICB0aGF0IGFjY2VzcyB0byBhIFNUVU4gc2VydmVy IGNhbiBiZSBjb250cm9sbGVkIGV2ZW4gaWYgdGhlIHRva2VucyBhcmUNCj4gPj4gICAgIGNvbXBy b21pc2VkLg0KPiA+Pg0KPiA+Pg0KPiA+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0DQo+ID4+IGh6Lw0KPiA+Pg0K PiA+PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gPj4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFy dHktYXV0aHotMDkNCj4gPj4NCj4gPj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KPiA+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXQNCj4gPj4gaHotMDkNCj4gPj4NCj4g Pj4NCj4gPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2YNCj4gPj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+IHRvb2xzLmlldGYub3JnLg0KPiA+Pg0K PiA+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAg YXQ6DQo+ID4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4+DQo+ID4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHRy YW0gbWFpbGluZyBsaXN0DQo+ID4+IHRyYW1AaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQo= From nobody Fri Feb 6 02:19:06 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8821A1B23 for ; Fri, 6 Feb 2015 02:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDMdvJTLMPWu for ; Fri, 6 Feb 2015 02:18:50 -0800 (PST) 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 488161A1B8F for ; Fri, 6 Feb 2015 02:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11080; q=dns/txt; s=iport; t=1423217931; x=1424427531; h=from:to:cc:subject:date:message-id:mime-version; bh=s9ZEG6gHIHOd9xPur2bdeLI0RBTNnEL8FXjDCyOjwa0=; b=mpL5ivRujFiZO/ciZMmiYrtHCUSlCwmoOxdzUUPUED4ANRZyro6xMXRC 5cqXZfm2234YDkg9nKVM/6CwzvJWVF9kdHxRRfn7boSzc0eInQDJx8a2b ebwr7gqiV1VY4LBbzwFs2sfRuerL0fnuIL3z8SO17BOzpbBx11KxsrKKI c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DtBQD2k9RU/49dJa1agkNDUlkEgn29NIIcAQmFcQIcgQBDAQEBAQF9hAwBAQEEAQEBIApBCQISAQgOAwQBAQsdAwIEJQsUCAEJAQQOBQiIJQ2+aZYjAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPRy0EBoJpLoETBY8YnBcigjKBPG+BRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,528,1418083200"; d="scan'208,217";a="121097489" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP; 06 Feb 2015 10:18:50 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t16AIneR023004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 10:18:49 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Fri, 6 Feb 2015 04:18:48 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt Thread-Index: AdBB9kl12RUjiuL2RlOXbBb+e+2XWg== Date: Fri, 6 Feb 2015 10:18:48 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3553A27C@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.67.102] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A3553A27Cxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Simon Perreault , Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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: Fri, 06 Feb 2015 10:18:55 -0000 --_000_913383AAA69FF945B8F946018B75898A3553A27Cxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUl0NCg0KRnJvbTogSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xl LmNvbV0NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDYsIDIwMTUgNjoyMSBBTQ0KVG86IFRpcnVt YWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiBCZW5qYW1pbiBTY2h3YXJ0ejsgU2ltb24gUGVy cmVhdWx0OyB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RyYW1dIEZXOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5LXRyYW0tdHVybi1pcGFkZHJlc3MtcHJpdmFj eS0wMC50eHQNCg0KSSBhZ3JlZSB3aXRoIFNpbW9uIGFuZCBCZW4gaW4gYmVpbmcgc2tlcHRpY2Fs IGFib3V0IHRoaXMgcHJvcG9zYWwuDQoNClRoZSBjbGllbnQgaXMgdGhlIG9ubHkgcGFydHkgd2hp Y2gga25vd3MgZXhhY3RseSB3aGF0ICdwcml2YWN5JyBtZWFucywgYW5kIHRoZXJlIGlzIG5vIHRy aXZpYWwgd2F5IHRvIHNlcmlhbGl6ZSB0aGlzIGludG8gYSBzaW5nbGUgYXR0cmlidXRlIGZvciB0 aGUgVFVSTiBzZXJ2ZXIuDQoNCltUUl0gV2UgYXJlIGV2YWx1YXRpbmcgaG93IHRoZSBjbGllbnQg Y2FuIGNvdmV5IGl0cyDigJhwcml2YWN54oCZIG5lZWRzIGluIHRoaXMgbmV3IGF0dHJpYnV0ZSB0 byB0aGUgVFVSTiBzZXJ2ZXIgc28gdGhhdCBpdCBjYW4gdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24g YW5kIHRoZSBzZXJ2ZXIgcmVzcG9uZHMgaWYgdGhlIGNsaWVudCDigJhwcml2YWN54oCZIHJlcXVp cmVtZW50IGNhbiBiZSBtZXQgZnVsbHkgb3IgcGFydGlhbGx5Lg0KDQotVGlydQ0KDQpBcyBzdWNo LCBJIHRoaW5rIHRoaXMgZGVjaXNpb24gc2hvdWxkIGJlIGxlZnQgZW50aXJlbHkgdG8gdGhlIGNs aWVudC4NCg0KT24gV2VkLCBGZWIgNCwgMjAxNSBhdCAxMDo1MCBBTSwgVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29t Pj4gd3JvdGU6DQpJIGFncmVlIHRoYXQgdGhlIGNsaWVudCBjYW4gZG8gZXF1YWxseSB3ZWxsIGl0 c2VsZiwgYnkgc2VuZGluZyBhIFNUVU4gQmluZGluZyBSZXF1ZXN0IGFuZCBjb21wYXJpbmcgdGhl IHJlc3BvbnNlIHRvIHRoZSBUVVJOIHNlcnZlcidzIG93biBJUCBhZGRyZXNzLg0KDQpbVFIzXSBU aGUgZGlmZmVyZW5jZSB0aGlzIGRyYWZ0IGJyaW5ncyBpbiBpcyB0aGF0IGl0IGhlbHBzIHRoZSBU VVJOIHNlcnZlciAob2ZmZXJlZCBieSBhIGdsb2JhbCBvciBjbG91ZCBzZXJ2aWNlKSB0byBkZXRl cm1pbmUgdGhhdCB0aGUgY2xpZW50IHdhbnRzIHByaXZhY3kgYW5kIGxldmVsIG9mIHByaXZhY3kg cmVxdWlyZWQgY29udmV5ZWQgaW4gdGhlIG5ldyBTVFVOIGF0dHJpYnV0ZSwgdGhlIFRVUk4gc2Vy dmVyIGRldGVybWluZXMgc3VpdGFibGUgYWx0ZXJuYXRlIFRVUk4gc2VydmVyIHRoYXQgY2FuIG9m ZmVyIHRoZSByZXF1aXJlZCBsZXZlbCBvZiBwcml2YWN5Lg0KDQotVGlydQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5nIGxpc3QN CnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0K --_000_913383AAA69FF945B8F946018B75898A3553A27Cxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JbmxpbmUgW1RSXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+ U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMDYsIDIwMTUgNjoyMSBBTTxicj4NCjxiPlRvOjwv Yj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCjxiPkNjOjwvYj4gQmVuamFtaW4g U2Nod2FydHo7IFNpbW9uIFBlcnJlYXVsdDsgdHJhbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJl ZGR5LXRyYW0tdHVybi1pcGFkZHJlc3MtcHJpdmFjeS0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRoIFNpbW9uIGFu ZCBCZW4gaW4gYmVpbmcgc2tlcHRpY2FsIGFib3V0IHRoaXMgcHJvcG9zYWwuPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY2xpZW50IGlzIHRoZSBvbmx5 IHBhcnR5IHdoaWNoIGtub3dzIGV4YWN0bHkgd2hhdCAncHJpdmFjeScgbWVhbnMsIGFuZCB0aGVy ZSBpcyBubyB0cml2aWFsIHdheSB0byBzZXJpYWxpemUgdGhpcyBpbnRvIGEgc2luZ2xlIGF0dHJp YnV0ZSBmb3IgdGhlIFRVUk4gc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFJdIFdlIGFyZSBldmFsdWF0aW5nIGhvdyB0 aGUgY2xpZW50IGNhbiBjb3ZleSBpdHMg4oCYcHJpdmFjeeKAmSBuZWVkcyBpbiB0aGlzIG5ldyBh dHRyaWJ1dGUgdG8gdGhlIFRVUk4gc2VydmVyIHNvIHRoYXQgaXQgY2FuIHRha2UgYXBwcm9wcmlh dGUgYWN0aW9uIGFuZCB0aGUNCiBzZXJ2ZXIgcmVzcG9uZHMgaWYgdGhlIGNsaWVudCDigJhwcml2 YWN54oCZIHJlcXVpcmVtZW50IGNhbiBiZSBtZXQgZnVsbHkgb3IgcGFydGlhbGx5LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFzIHN1Y2gsIEkgdGhpbmsgdGhpcyBkZWNpc2lvbiBzaG91bGQgYmUgbGVm dCBlbnRpcmVseSB0byB0aGUgY2xpZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiA0LCAyMDE1IGF0IDEwOjUwIEFNLCBU aXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpICZsdDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBj aXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj50aXJlZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkg YWdyZWUgdGhhdCB0aGUgY2xpZW50IGNhbiBkbyBlcXVhbGx5IHdlbGwgaXRzZWxmLCBieSBzZW5k aW5nIGEgU1RVTiBCaW5kaW5nIFJlcXVlc3QgYW5kIGNvbXBhcmluZyB0aGUgcmVzcG9uc2UgdG8g dGhlIFRVUk4gc2VydmVyJ3Mgb3duIElQIGFkZHJlc3MuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUjNdIFRo ZSBkaWZmZXJlbmNlIHRoaXMgZHJhZnQgYnJpbmdzIGluIGlzIHRoYXQgaXQgaGVscHMgdGhlIFRV Uk4gc2VydmVyIChvZmZlcmVkIGJ5IGEgZ2xvYmFsIG9yDQogY2xvdWQgc2VydmljZSkgdG8gZGV0 ZXJtaW5lIHRoYXQgdGhlIGNsaWVudCB3YW50cyBwcml2YWN5IGFuZCBsZXZlbCBvZiBwcml2YWN5 IHJlcXVpcmVkIGNvbnZleWVkIGluIHRoZSBuZXcgU1RVTiBhdHRyaWJ1dGUsIHRoZSBUVVJOIHNl cnZlciBkZXRlcm1pbmVzIHN1aXRhYmxlIGFsdGVybmF0ZSBUVVJOIHNlcnZlciB0aGF0IGNhbiBv ZmZlciB0aGUgcmVxdWlyZWQgbGV2ZWwgb2YgcHJpdmFjeS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIj50cmFtQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A3553A27Cxmbrcdx10ciscoc_-- From nobody Fri Feb 6 02:49:19 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9E81A01EC for ; Fri, 6 Feb 2015 02:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 C-vFNLSorSlT for ; Fri, 6 Feb 2015 02:49:12 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id BE07E1A01CB for ; Fri, 6 Feb 2015 02:49:11 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id EE42023F048E; Fri, 6 Feb 2015 11:49:09 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.206]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0224.002; Fri, 6 Feb 2015 11:49:09 +0100 From: "Hutton, Andrew" To: Justin Uberti , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt Thread-Index: AQHQQacTqq8Ul8nRs0eSp74XlWYQPpzjbsBA Date: Fri, 6 Feb 2015 10:49:08 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E6AC8F3@MCHP04MSX.global-ad.net> References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35538E3D@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35538F91@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A355390B9@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: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E6AC8F3MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: Cc: Simon Perreault , Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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: Fri, 06 Feb 2015 10:49:15 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E6AC8F3MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gYSBmaXJzdCByZWFkIEkgYW0gYWxzbyByYXRoZXIgc2tlcHRpY2FsIGFib3V0IGhhbmRpbmcg dGhpcyBwcml2YWN5IGZ1bmN0aW9uIG92ZXIgdG8gdGhlIFRVUk4gc2VydmVyLg0KDQpUaGUgZHJh ZnQgaW50cm9kdWNlcyB0aGUgZmlyc3QgYXJndW1lbnQgSSBoYXZlIHNlZW4gYWdhaW5zdCB1c2lu ZyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nod2FydHotcnRjd2ViLXJldHVy bi0wMyBpbiB0aGF0IGl0IHN0YXRlczoNCg0K4oCcSWYgdGhlIHRoaXJkIHBhcnR5IG9mZmVyZWQg VFVSTiBzZXJ2ZXIgY2FuIHByb3ZpZGUgSVAgYWRkcmVzcyBwcml2YWN5IHRoZW4gdGhlIGFwcGxp Y2F0aW9uIGNhbiBhdm9pZCBUVVJOLWluLVRVUk4gbWVjaGFuaXNtIGRpc2N1c3NlZCBpbltJLUQu c2Nod2FydHotcnRjd2ViLXJldHVybjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1y ZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDAjcmVmLUktRC5zY2h3YXJ0ei1ydGN3 ZWItcmV0dXJuPl0gYW5kIHRodXMgYXZvaWQgdGhlIG92ZXJoZWFkIG9mIHVzaW5nIFJFVFVSTiBw cm94eWluZ+KAnS4NCg0KSG93ZXZlciBpdCBkb2VzIG5vdCBzZWVtIHRvIG1lIHRoYXQgdGhlIG92 ZXJoZWFkIG9mIHVzaW5nIGEgUkVUVVJOIHByb3h5IGlzIHJlYWxseSB0aGF0IHNpZ25pZmljYW50 IGdpdmVuIHRoYXQgdGhlIFJFVFVSTiBwcm94eSBpcyBsaWtlbHkgdG8gYmUgY2xvc2UgdG8gdGhl IGNsaWVudCBpbiB0aGUgZW50ZXJwcmlzZSBwcm94eS9maXJld2FsbCBvciBpbiB0aGUgYWNjZXNz IG5ldHdvcmsuDQoNCkFuZHkNCg0KDQoNCg0KDQpGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDogMDYgRmVicnVh cnkgMjAxNSAwMDo1MQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiBTaW1v biBQZXJyZWF1bHQ7IEJlbmphbWluIFNjaHdhcnR6OyB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5LXRy YW0tdHVybi1pcGFkZHJlc3MtcHJpdmFjeS0wMC50eHQNCg0KSSBhZ3JlZSB3aXRoIFNpbW9uIGFu ZCBCZW4gaW4gYmVpbmcgc2tlcHRpY2FsIGFib3V0IHRoaXMgcHJvcG9zYWwuDQoNClRoZSBjbGll bnQgaXMgdGhlIG9ubHkgcGFydHkgd2hpY2gga25vd3MgZXhhY3RseSB3aGF0ICdwcml2YWN5JyBt ZWFucywgYW5kIHRoZXJlIGlzIG5vIHRyaXZpYWwgd2F5IHRvIHNlcmlhbGl6ZSB0aGlzIGludG8g YSBzaW5nbGUgYXR0cmlidXRlIGZvciB0aGUgVFVSTiBzZXJ2ZXIuDQoNCkFzIHN1Y2gsIEkgdGhp bmsgdGhpcyBkZWNpc2lvbiBzaG91bGQgYmUgbGVmdCBlbnRpcmVseSB0byB0aGUgY2xpZW50Lg0K DQpPbiBXZWQsIEZlYiA0LCAyMDE1IGF0IDEwOjUwIEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRp cmVkZHkpIDx0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+PiB3cm90 ZToNCkkgYWdyZWUgdGhhdCB0aGUgY2xpZW50IGNhbiBkbyBlcXVhbGx5IHdlbGwgaXRzZWxmLCBi eSBzZW5kaW5nIGEgU1RVTiBCaW5kaW5nIFJlcXVlc3QgYW5kIGNvbXBhcmluZyB0aGUgcmVzcG9u c2UgdG8gdGhlIFRVUk4gc2VydmVyJ3Mgb3duIElQIGFkZHJlc3MuDQoNCltUUjNdIFRoZSBkaWZm ZXJlbmNlIHRoaXMgZHJhZnQgYnJpbmdzIGluIGlzIHRoYXQgaXQgaGVscHMgdGhlIFRVUk4gc2Vy dmVyIChvZmZlcmVkIGJ5IGEgZ2xvYmFsIG9yIGNsb3VkIHNlcnZpY2UpIHRvIGRldGVybWluZSB0 aGF0IHRoZSBjbGllbnQgd2FudHMgcHJpdmFjeSBhbmQgbGV2ZWwgb2YgcHJpdmFjeSByZXF1aXJl ZCBjb252ZXllZCBpbiB0aGUgbmV3IFNUVU4gYXR0cmlidXRlLCB0aGUgVFVSTiBzZXJ2ZXIgZGV0 ZXJtaW5lcyBzdWl0YWJsZSBhbHRlcm5hdGUgVFVSTiBzZXJ2ZXIgdGhhdCBjYW4gb2ZmZXIgdGhl IHJlcXVpcmVkIGxldmVsIG9mIHByaXZhY3kuDQoNCi1UaXJ1DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBp ZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHJhbQ0KDQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF1E6AC8F3MCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj5PbiBhIGZpcnN0IHJlYWQgSSBhbSBhbHNvIHJhdGhlciBza2VwdGljYWwgYWJvdXQgaGFu ZGluZyB0aGlzIHByaXZhY3kgZnVuY3Rpb24gb3ZlciB0byB0aGUgVFVSTiBzZXJ2ZXIuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPlRoZSBkcmFmdCBpbnRyb2R1Y2VzIHRoZSBmaXJz dCBhcmd1bWVudCBJIGhhdmUgc2VlbiBhZ2FpbnN0IHVzaW5nDQo8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nod2FydHotcnRjd2ViLXJldHVybi0wMyI+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2h3YXJ0ei1ydGN3ZWItcmV0dXJuLTAzPC9zcGFuPjwv YT4gaW4gdGhhdCBpdCBzdGF0ZXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPuKA nElmIHRoZSB0aGlyZCBwYXJ0eSBvZmZlcmVkIFRVUk4gc2VydmVyIGNhbiBwcm92aWRlIElQIGFk ZHJlc3MgcHJpdmFjeSB0aGVuIHRoZSBhcHBsaWNhdGlvbiBjYW4gYXZvaWQgVFVSTi1pbi1UVVJO IG1lY2hhbmlzbSBkaXNjdXNzZWQgaW5bPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2YWN5LTAwI3JlZi1JLUQuc2No d2FydHotcnRjd2ViLXJldHVybiI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPkktRC5zY2h3YXJ0ei1ydGN3ZWItcmV0dXJuPC9zcGFuPjwvYT5dDQog YW5kIHRodXMgYXZvaWQgdGhlIG92ZXJoZWFkIG9mIHVzaW5nIFJFVFVSTiBwcm94eWluZ+KAnS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciBpdCBkb2VzIG5vdCBzZWVtIHRvIG1lIHRo YXQgdGhlIG92ZXJoZWFkIG9mIHVzaW5nIGEgUkVUVVJOIHByb3h5IGlzIHJlYWxseSB0aGF0IHNp Z25pZmljYW50IGdpdmVuIHRoYXQgdGhlIFJFVFVSTiBwcm94eSBpcyBsaWtlbHkgdG8gYmUgY2xv c2UgdG8gdGhlIGNsaWVudCBpbiB0aGUgZW50ZXJwcmlzZSBwcm94eS9maXJld2FsbCBvciBpbiB0 aGUgYWNjZXNzIG5ldHdvcmsuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0cmFtIFttYWlsdG86dHJhbS1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+ U2VudDo8L2I+IDA2IEZlYnJ1YXJ5IDIwMTUgMDA6NTE8YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxl c3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQo8Yj5DYzo8L2I+IFNpbW9uIFBlcnJlYXVsdDsgQmVu amFtaW4gU2Nod2FydHo7IHRyYW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0 cmFtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRkeS10cmFtLXR1 cm4taXBhZGRyZXNzLXByaXZhY3ktMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgd2l0aCBTaW1vbiBhbmQgQmVuIGluIGJl aW5nIHNrZXB0aWNhbCBhYm91dCB0aGlzIHByb3Bvc2FsLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNsaWVudCBpcyB0aGUgb25seSBwYXJ0eSB3aGlj aCBrbm93cyBleGFjdGx5IHdoYXQgJ3ByaXZhY3knIG1lYW5zLCBhbmQgdGhlcmUgaXMgbm8gdHJp dmlhbCB3YXkgdG8gc2VyaWFsaXplIHRoaXMgaW50byBhIHNpbmdsZSBhdHRyaWJ1dGUgZm9yIHRo ZSBUVVJOIHNlcnZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QXMgc3VjaCwgSSB0aGluayB0aGlzIGRlY2lzaW9uIHNob3VsZCBiZSBsZWZ0 IGVudGlyZWx5IHRvIHRoZSBjbGllbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDQsIDIwMTUgYXQgMTA6NTAgQU0sIFRp cnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0OzxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBh Z3JlZSB0aGF0IHRoZSBjbGllbnQgY2FuIGRvIGVxdWFsbHkgd2VsbCBpdHNlbGYsIGJ5IHNlbmRp bmcgYSBTVFVOIEJpbmRpbmcgUmVxdWVzdCBhbmQgY29tcGFyaW5nIHRoZSByZXNwb25zZSB0byB0 aGUgVFVSTiBzZXJ2ZXIncyBvd24gSVAgYWRkcmVzcy4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSM10gVGhl IGRpZmZlcmVuY2UgdGhpcyBkcmFmdCBicmluZ3MgaW4gaXMgdGhhdCBpdCBoZWxwcyB0aGUgVFVS TiBzZXJ2ZXIgKG9mZmVyZWQgYnkgYSBnbG9iYWwgb3INCiBjbG91ZCBzZXJ2aWNlKSB0byBkZXRl cm1pbmUgdGhhdCB0aGUgY2xpZW50IHdhbnRzIHByaXZhY3kgYW5kIGxldmVsIG9mIHByaXZhY3kg cmVxdWlyZWQgY29udmV5ZWQgaW4gdGhlIG5ldyBTVFVOIGF0dHJpYnV0ZSwgdGhlIFRVUk4gc2Vy dmVyIGRldGVybWluZXMgc3VpdGFibGUgYWx0ZXJuYXRlIFRVUk4gc2VydmVyIHRoYXQgY2FuIG9m ZmVyIHRoZSByZXF1aXJlZCBsZXZlbCBvZiBwcml2YWN5Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9F33F40F6F2CD847824537F3C4E37DDF1E6AC8F3MCHP04MSXglobal_-- From nobody Fri Feb 6 03:02:51 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C676D1A1A4A for ; Fri, 6 Feb 2015 02:06:24 -0800 (PST) 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 lzli8uBwtzuC for ; Fri, 6 Feb 2015 02:06:22 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B791A0145 for ; Fri, 6 Feb 2015 02:06:22 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id u56so7156227wes.10 for ; Fri, 06 Feb 2015 02:06:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OSh/L682Db0PwBGFuwmCo7Dz1yEg0wOsShgIQBDuMXM=; b=ZkYyqrItjobHVPCnUYENFd8fn58JJMiycxzfc16nD/xCiHlv+ZRYgvVClMqSPzf0fQ TakK3YCzBB8KV5YCNWpdyeLati+K+lM6ztO9Z5vyaByCheBjE9eiFv1bIk4wypqcK3gT oW/YBmlypdPPMhl6gBfQvJUXR0adwqlXmUeFlLPUvUxfT++JY52l39c3giX4EMKRzgv4 NOPrdKGPF86T/RE9ZU9yVU7I3Bn7wmJ08yJvVP0i3n9ZUib9ny6U96ukR9x+UJm8+ivt z/iy6FPf28fXHE//T9VhIAT6jbI4PXCCmTHPvWDornxA4yd27VAO2oSF/clP8bkoZxQq 2CvA== X-Received: by 10.194.240.99 with SMTP id vz3mr5907345wjc.37.1423217181300; Fri, 06 Feb 2015 02:06:21 -0800 (PST) Received: from [10.0.0.8] (bzq-109-67-159-223.red.bezeqint.net. [109.67.159.223]) by mx.google.com with ESMTPSA id p6sm770504wia.14.2015.02.06.02.06.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Feb 2015 02:06:20 -0800 (PST) Message-ID: <54D4921B.7060801@gmail.com> Date: Fri, 06 Feb 2015 12:06:19 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "tram@ietf.org" References: <20150206011702.17303.16733.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35539EC2@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A35539EC2@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 06 Feb 2015 03:02:41 -0800 Cc: "Tom Taylor \(tom.taylor.stds@gmail.com\)" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-09.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, 06 Feb 2015 10:06:25 -0000 Hi Tiru, Thanks for the new revision. One remaining comment: Looking at 4.1.1 and the HKDF algorithm, I believe that your AUTH key is identical to the first 20 bytes of the AS-RS key, which is definitely not what you'd want. As I'm sure you know, the standard way to separate two derived keys is to append a string like "auth" or "as-rs" to the input. Thanks, Yaron On 02/06/2015 03:20 AM, Tirumaleswar Reddy (tireddy) wrote: > This revision addresses comments from Yaron and Tom. > > -Tiru > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Friday, February 06, 2015 6:47 AM >> To: i-d-announce@ietf.org >> Cc: tram@ietf.org >> Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-09.txt >> >> >> 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-09.txt >> Pages : 23 >> Date : 2015-02-05 >> >> 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 ensures >> 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-09 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-09 >> >> >> 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 From nobody Fri Feb 6 06:15:51 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E3C1A1AE0; Fri, 6 Feb 2015 06:15:39 -0800 (PST) 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 k7bl__8AJsPE; Fri, 6 Feb 2015 06:15:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB131A001B; Fri, 6 Feb 2015 06:15:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206141537.23425.13842.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 06:15:37 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-10.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: Fri, 06 Feb 2015 14:15:39 -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-10.txt Pages : 22 Date : 2015-02-06 Abstract: This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised. 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-10 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 Feb 6 06:24:25 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A401A1B05 for ; Fri, 6 Feb 2015 06:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IenUKsMolsCX for ; Fri, 6 Feb 2015 06:23:58 -0800 (PST) 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 108E71A1A96 for ; Fri, 6 Feb 2015 06:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2240; q=dns/txt; s=iport; t=1423232638; x=1424442238; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zuvBdQjhb/WEGggTPI+dqTvYdErmOpoAJs4o5pxrnDI=; b=caNMVfgwSShHqVxOOlI/l+Fb7mmBA2fmT8y8Sjj2yORH/H81IBKovbqz Nd5vW7hn7MT0l78c3bPEs9XE9RouxDTP5QA1HOoXaYhEH5TMtnZsLhyRj eOKnwnXSbu7NqzCPGabMGnOsOt6omlckHoKEzNiXDqm4poZdb2EKk8Khn I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A9BgCXy9RU/4YNJK1agwZSVQUEwDaCHAyFbwKBG0MBAQEBAX2EDAEBAQQBAQE3NAsMBAIBCBEEAQELFAkHJwsUCQgCBA4FCAGIJAgF1R0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXj0cxBwaDEIETBY8ag1CGczaCTY5SIoNub4EEJBx+AQEB X-IronPort-AV: E=Sophos;i="5.09,529,1418083200"; d="scan'208";a="121154763" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP; 06 Feb 2015 14:23:57 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t16ENv7x008665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 14:23:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 6 Feb 2015 08:23:57 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-10.txt Thread-Index: AQHQQhdtPZrEEHoZ9UeDBUqo6e1V2Zzjq1iw Date: Fri, 6 Feb 2015 14:23:56 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3553A743@xmb-rcd-x10.cisco.com> References: <20150206141537.23425.13842.idtracker@ietfa.amsl.com> In-Reply-To: <20150206141537.23425.13842.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.48.194] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Yaron Sheffer \(yaronf.ietf@gmail.com\)" , "'Christer Holmberg' \(christer.holmberg@ericsson.com\)" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-10.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, 06 Feb 2015 14:24:08 -0000 This revision addresses comments from Christer and updates section 4.1.1 to= use different strings in HKDF function to generate AS-RS and AUTH keys. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, February 06, 2015 7:46 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-10.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-10.txt > Pages : 22 > Date : 2015-02-06 >=20 > Abstract: > This document proposes the use of OAuth 2.0 to obtain and validate > ephemeral tokens that can be used for Session Traversal Utilities for > NAT (STUN) authentication. The usage of ephemeral tokens ensures > that access to a STUN server can be controlled even if the tokens are > compromised. >=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-10 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-third-party-authz= -10 >=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 Feb 6 06:28:50 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A511A1AE5 for ; Fri, 6 Feb 2015 06:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ac4MEJY6EtOg for ; Fri, 6 Feb 2015 06:28:45 -0800 (PST) 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 162701A1A96 for ; Fri, 6 Feb 2015 06:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19080; q=dns/txt; s=iport; t=1423232925; x=1424442525; h=from:to:cc:subject:date:message-id:mime-version; bh=PImokc9Ctp+btWWXIFFKzZsCbSs9qEKS30XKIXjzOYk=; b=NLOOZraaB+UJjet4FEcwDOwt9Qx8lKfYHHwcOMiGjUzDz8HI2BX1iunD yXY9DImL99cDNVF6KekOeReHcRkj64bJIls+HsASGGxCSQSdCWzi1TDPl jyzaKUbW+UEl2viHNfFuX4ZjmjGSEL58LilAv2QH+LFs4/nmZAhYC1H6H w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAJHO1FStJV2P/2dsb2JhbABagkNDUloEgn29OTyBYAELhW8CHH9DAQEBAQF9hAwBAQEEAQEBIApBCQISAQgRBAEBCx0DAgQlCxQIAQkBBAENBQiIJQ2/M5YAAQEBAQEBAQEBAQEBAQEBAQEBAQEBF49HLQQGgmkugRMFjxqDUIZzNoJNgkaMDCKCBxcUgTxvAYFDfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,529,1418083200"; d="scan'208,217";a="393983519" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP; 06 Feb 2015 14:28:44 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t16ESiPa002377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 14:28:44 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 6 Feb 2015 08:28:44 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Hutton, Andrew" , Justin Uberti Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt Thread-Index: AdBCGTIyExgr6Ut5RQSqGDxpzpP/og== Date: Fri, 6 Feb 2015 14:28:43 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3553A767@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.48.194] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A3553A767xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Simon Perreault , Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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: Fri, 06 Feb 2015 14:28:47 -0000 --_000_913383AAA69FF945B8F946018B75898A3553A767xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUl0NCg0KRnJvbTogSHV0dG9uLCBBbmRyZXcgW21haWx0bzphbmRyZXcuaHV0dG9u QHVuaWZ5LmNvbV0NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDYsIDIwMTUgNDoxOSBQTQ0KVG86 IEp1c3RpbiBVYmVydGk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiBTaW1vbiBQ ZXJyZWF1bHQ7IEJlbmphbWluIFNjaHdhcnR6OyB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBSRTog W3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5LXRyYW0t dHVybi1pcGFkZHJlc3MtcHJpdmFjeS0wMC50eHQNCg0KT24gYSBmaXJzdCByZWFkIEkgYW0gYWxz byByYXRoZXIgc2tlcHRpY2FsIGFib3V0IGhhbmRpbmcgdGhpcyBwcml2YWN5IGZ1bmN0aW9uIG92 ZXIgdG8gdGhlIFRVUk4gc2VydmVyLg0KDQpbVFJdIFBsZWFzZSBjbGFyaWZ5IHdoeSB0aGlzIGlz IGEgY29uY2VybiA/DQpJZiBwcml2YWN5IGlzIHByb3ZpZGVkIGxldOKAmXMgc2F5IHVzaW5nIFRv ciBvciBhbm9ueW1vdXMgVlBOIHNlcnZpY2UgdGhlbiB0aGUgZW5kcG9pbnQgaXMgdHJ1c3Rpbmcg dGhlc2Ugc2VydmljZXMuDQoNClRoZSBkcmFmdCBpbnRyb2R1Y2VzIHRoZSBmaXJzdCBhcmd1bWVu dCBJIGhhdmUgc2VlbiBhZ2FpbnN0IHVzaW5nIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1zY2h3YXJ0ei1ydGN3ZWItcmV0dXJuLTAzIGluIHRoYXQgaXQgc3RhdGVzOg0KDQrigJxJ ZiB0aGUgdGhpcmQgcGFydHkgb2ZmZXJlZCBUVVJOIHNlcnZlciBjYW4gcHJvdmlkZSBJUCBhZGRy ZXNzIHByaXZhY3kgdGhlbiB0aGUgYXBwbGljYXRpb24gY2FuIGF2b2lkIFRVUk4taW4tVFVSTiBt ZWNoYW5pc20gZGlzY3Vzc2VkIGluW0ktRC5zY2h3YXJ0ei1ydGN3ZWItcmV0dXJuPGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5LXRyYW0tdHVybi1pcGFkZHJlc3MtcHJpdmFj eS0wMCNyZWYtSS1ELnNjaHdhcnR6LXJ0Y3dlYi1yZXR1cm4+XSBhbmQgdGh1cyBhdm9pZCB0aGUg b3ZlcmhlYWQgb2YgdXNpbmcgUkVUVVJOIHByb3h5aW5n4oCdLg0KDQpIb3dldmVyIGl0IGRvZXMg bm90IHNlZW0gdG8gbWUgdGhhdCB0aGUgb3ZlcmhlYWQgb2YgdXNpbmcgYSBSRVRVUk4gcHJveHkg aXMgcmVhbGx5IHRoYXQgc2lnbmlmaWNhbnQgZ2l2ZW4gdGhhdCB0aGUgUkVUVVJOIHByb3h5IGlz IGxpa2VseSB0byBiZSBjbG9zZSB0byB0aGUgY2xpZW50IGluIHRoZSBlbnRlcnByaXNlIHByb3h5 L2ZpcmV3YWxsIG9yIGluIHRoZSBhY2Nlc3MgbmV0d29yay4NCg0KW1RSXSBUaGUgYXBwbGljYXRp b24gcHJvdmlkZWQgVFVSTiBzZXJ2ZXIgbWF5IG5vdCBhbHdheXMgYmUgY2xvc2UgdG8gdGhlIGVu ZHBvaW50IG9yIHRoZSB1c2VyIG1heSBub3QgdHJ1c3QgdGhlIGFwcGxpY2F0aW9uIHNlcnZlci4g UkVUVVJOIHByb3h5aW5nIGlzIGNlcnRhaW5seSB1c2VmdWwgaW4gY2VydGFpbiBzY2VuYXJpb3Mg YW5kIHRoaXMgZHJhZnQgaGVscHMgY2xpZW50IGRldGVybWluZSBpZiBSRVRVUk4gcHJveHlpbmcg aXMgcmVxdWlyZWQgbm90LiBUaGlzIGRyYWZ0IGNhbiBiZSB1c2VkIHdpdGggUkVUVVJOIHByb3h5 aW5nLCBmb3IgZXhhbXBsZSBiYXNlZCBvbiB0aGUg4oCYcHJpdmFjeeKAmSBuZWVkIGNvbnZleWVk IHRoZSBjbGllbnQgdGhlICBhcHBsaWNhdGlvbiBwcm92aWRlZCBUVVJOIHNlcnZlciBtYXkgcG9p bnQgdGhlIGNsaWVudCB0byBhbiBhbHRlcm5hdGUgVFVSTiBzZXJ2ZXIgd2hpY2ggY2FuIG1lZXQg dGhlIGNsaWVudOKAmXMg4oCYcHJpdmFjeeKAmSBuZWVkcy4NCg0KLVRpcnUNCg0KQW5keQ0KDQoN Cg0KDQoNCkZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiAwNiBGZWJydWFyeSAyMDE1IDAwOjUxDQpUbzogVGly dW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KQ2M6IFNpbW9uIFBlcnJlYXVsdDsgQmVuamFtaW4g U2Nod2FydHo7IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJhbV0gRlc6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2 YWN5LTAwLnR4dA0KDQpJIGFncmVlIHdpdGggU2ltb24gYW5kIEJlbiBpbiBiZWluZyBza2VwdGlj YWwgYWJvdXQgdGhpcyBwcm9wb3NhbC4NCg0KVGhlIGNsaWVudCBpcyB0aGUgb25seSBwYXJ0eSB3 aGljaCBrbm93cyBleGFjdGx5IHdoYXQgJ3ByaXZhY3knIG1lYW5zLCBhbmQgdGhlcmUgaXMgbm8g dHJpdmlhbCB3YXkgdG8gc2VyaWFsaXplIHRoaXMgaW50byBhIHNpbmdsZSBhdHRyaWJ1dGUgZm9y IHRoZSBUVVJOIHNlcnZlci4NCg0KQXMgc3VjaCwgSSB0aGluayB0aGlzIGRlY2lzaW9uIHNob3Vs ZCBiZSBsZWZ0IGVudGlyZWx5IHRvIHRoZSBjbGllbnQuDQoNCk9uIFdlZCwgRmViIDQsIDIwMTUg YXQgMTA6NTAgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28u Y29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KSSBhZ3JlZSB0aGF0IHRoZSBj bGllbnQgY2FuIGRvIGVxdWFsbHkgd2VsbCBpdHNlbGYsIGJ5IHNlbmRpbmcgYSBTVFVOIEJpbmRp bmcgUmVxdWVzdCBhbmQgY29tcGFyaW5nIHRoZSByZXNwb25zZSB0byB0aGUgVFVSTiBzZXJ2ZXIn cyBvd24gSVAgYWRkcmVzcy4NCg0KW1RSM10gVGhlIGRpZmZlcmVuY2UgdGhpcyBkcmFmdCBicmlu Z3MgaW4gaXMgdGhhdCBpdCBoZWxwcyB0aGUgVFVSTiBzZXJ2ZXIgKG9mZmVyZWQgYnkgYSBnbG9i YWwgb3IgY2xvdWQgc2VydmljZSkgdG8gZGV0ZXJtaW5lIHRoYXQgdGhlIGNsaWVudCB3YW50cyBw cml2YWN5IGFuZCBsZXZlbCBvZiBwcml2YWN5IHJlcXVpcmVkIGNvbnZleWVkIGluIHRoZSBuZXcg U1RVTiBhdHRyaWJ1dGUsIHRoZSBUVVJOIHNlcnZlciBkZXRlcm1pbmVzIHN1aXRhYmxlIGFsdGVy bmF0ZSBUVVJOIHNlcnZlciB0aGF0IGNhbiBvZmZlciB0aGUgcmVxdWlyZWQgbGV2ZWwgb2YgcHJp dmFjeS4NCg0KLVRpcnUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg== --_000_913383AAA69FF945B8F946018B75898A3553A767xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklu bGluZSBbVFJdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEh1 dHRvbiwgQW5kcmV3IFttYWlsdG86YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAwNiwgMjAxNSA0OjE5IFBNPGJyPg0KPGI+VG86PC9i PiBKdXN0aW4gVWJlcnRpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6 PC9iPiBTaW1vbiBQZXJyZWF1bHQ7IEJlbmphbWluIFNjaHdhcnR6OyB0cmFtQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbdHJhbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2YWN5LTAwLnR4dDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPk9uIGEgZmlyc3QgcmVhZCBJIGFtIGFsc28gcmF0aGVyIHNrZXB0 aWNhbCBhYm91dCBoYW5kaW5nIHRoaXMgcHJpdmFjeSBmdW5jdGlvbiBvdmVyIHRvIHRoZSBUVVJO IHNlcnZlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSXSBQbGVhc2UgY2xhcmlmeSB3aHkgdGhpcyBpcyBhIGNv bmNlcm4gPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JZiBwcml2YWN5IGlzIHByb3ZpZGVkIGxldOKAmXMgc2F5IHVzaW5nIFRv ciBvciBhbm9ueW1vdXMgVlBOIHNlcnZpY2UgdGhlbiB0aGUgZW5kcG9pbnQgaXMgdHJ1c3Rpbmcg dGhlc2Ugc2VydmljZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj5U aGUgZHJhZnQgaW50cm9kdWNlcyB0aGUgZmlyc3QgYXJndW1lbnQgSSBoYXZlIHNlZW4gYWdhaW5z dCB1c2luZw0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaHdh cnR6LXJ0Y3dlYi1yZXR1cm4tMDMiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nod2Fy dHotcnRjd2ViLXJldHVybi0wMzwvc3Bhbj48L2E+IGluIHRoYXQgaXQgc3RhdGVzOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPuKAnElmIHRoZSB0aGlyZCBwYXJ0eSBvZmZlcmVkIFRVUk4gc2Vy dmVyIGNhbiBwcm92aWRlIElQIGFkZHJlc3MgcHJpdmFjeSB0aGVuIHRoZSBhcHBsaWNhdGlvbiBj YW4gYXZvaWQgVFVSTi1pbi1UVVJOIG1lY2hhbmlzbSBkaXNjdXNzZWQgaW5bPGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1w cml2YWN5LTAwI3JlZi1JLUQuc2Nod2FydHotcnRjd2ViLXJldHVybiI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPkktRC5zY2h3YXJ0ei1ydGN3ZWIt cmV0dXJuPC9zcGFuPjwvYT5dDQogYW5kIHRodXMgYXZvaWQgdGhlIG92ZXJoZWFkIG9mIHVzaW5n IFJFVFVSTiBwcm94eWluZ+KAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciBpdCBk b2VzIG5vdCBzZWVtIHRvIG1lIHRoYXQgdGhlIG92ZXJoZWFkIG9mIHVzaW5nIGEgUkVUVVJOIHBy b3h5IGlzIHJlYWxseSB0aGF0IHNpZ25pZmljYW50IGdpdmVuIHRoYXQgdGhlIFJFVFVSTiBwcm94 eSBpcyBsaWtlbHkgdG8gYmUgY2xvc2UgdG8gdGhlIGNsaWVudCBpbiB0aGUgZW50ZXJwcmlzZSBw cm94eS9maXJld2FsbCBvciBpbiB0aGUgYWNjZXNzIG5ldHdvcmsuJm5ic3A7DQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSXSBU aGUgYXBwbGljYXRpb24gcHJvdmlkZWQgVFVSTiBzZXJ2ZXIgbWF5IG5vdCBhbHdheXMgYmUgY2xv c2UgdG8gdGhlIGVuZHBvaW50IG9yIHRoZSB1c2VyIG1heSBub3QgdHJ1c3QgdGhlIGFwcGxpY2F0 aW9uIHNlcnZlci4gUkVUVVJOIHByb3h5aW5nIGlzIGNlcnRhaW5seQ0KIHVzZWZ1bCBpbiBjZXJ0 YWluIHNjZW5hcmlvcyBhbmQgdGhpcyBkcmFmdCBoZWxwcyBjbGllbnQgZGV0ZXJtaW5lIGlmIFJF VFVSTiBwcm94eWluZyBpcyByZXF1aXJlZCBub3QuIFRoaXMgZHJhZnQgY2FuIGJlIHVzZWQgd2l0 aCBSRVRVUk4gcHJveHlpbmcsIGZvciBleGFtcGxlIGJhc2VkIG9uIHRoZSDigJhwcml2YWN54oCZ IG5lZWQgY29udmV5ZWQgdGhlIGNsaWVudCB0aGUmbmJzcDsgYXBwbGljYXRpb24gcHJvdmlkZWQg VFVSTiBzZXJ2ZXIgbWF5IHBvaW50IHRoZQ0KIGNsaWVudCB0byBhbiBhbHRlcm5hdGUgVFVSTiBz ZXJ2ZXIgd2hpY2ggY2FuIG1lZXQgdGhlIGNsaWVudOKAmXMg4oCYcHJpdmFjeeKAmSBuZWVkcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBVYmVydGk8YnI+DQo8Yj5TZW50 OjwvYj4gMDYgRmVicnVhcnkgMjAxNSAwMDo1MTxicj4NCjxiPlRvOjwvYj4gVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KTxicj4NCjxiPkNjOjwvYj4gU2ltb24gUGVycmVhdWx0OyBCZW5qYW1p biBTY2h3YXJ0ejsgdHJhbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RyYW1d IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5LXRyYW0tdHVybi1p cGFkZHJlc3MtcHJpdmFjeS0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRoIFNpbW9uIGFuZCBCZW4gaW4gYmVpbmcg c2tlcHRpY2FsIGFib3V0IHRoaXMgcHJvcG9zYWwuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY2xpZW50IGlzIHRoZSBvbmx5IHBhcnR5IHdoaWNoIGtu b3dzIGV4YWN0bHkgd2hhdCAncHJpdmFjeScgbWVhbnMsIGFuZCB0aGVyZSBpcyBubyB0cml2aWFs IHdheSB0byBzZXJpYWxpemUgdGhpcyBpbnRvIGEgc2luZ2xlIGF0dHJpYnV0ZSBmb3IgdGhlIFRV Uk4gc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BcyBzdWNoLCBJIHRoaW5rIHRoaXMgZGVjaXNpb24gc2hvdWxkIGJlIGxlZnQgZW50 aXJlbHkgdG8gdGhlIGNsaWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgNCwgMjAxNSBhdCAxMDo1MCBBTSwgVGlydW1h bGVzd2FyIFJlZGR5ICh0aXJlZGR5KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28u Y29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFncmVl IHRoYXQgdGhlIGNsaWVudCBjYW4gZG8gZXF1YWxseSB3ZWxsIGl0c2VsZiwgYnkgc2VuZGluZyBh IFNUVU4gQmluZGluZyBSZXF1ZXN0IGFuZCBjb21wYXJpbmcgdGhlIHJlc3BvbnNlIHRvIHRoZSBU VVJOIHNlcnZlcidzIG93biBJUCBhZGRyZXNzLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFIzXSBUaGUgZGlm ZmVyZW5jZSB0aGlzIGRyYWZ0IGJyaW5ncyBpbiBpcyB0aGF0IGl0IGhlbHBzIHRoZSBUVVJOIHNl cnZlciAob2ZmZXJlZCBieSBhIGdsb2JhbCBvcg0KIGNsb3VkIHNlcnZpY2UpIHRvIGRldGVybWlu ZSB0aGF0IHRoZSBjbGllbnQgd2FudHMgcHJpdmFjeSBhbmQgbGV2ZWwgb2YgcHJpdmFjeSByZXF1 aXJlZCBjb252ZXllZCBpbiB0aGUgbmV3IFNUVU4gYXR0cmlidXRlLCB0aGUgVFVSTiBzZXJ2ZXIg ZGV0ZXJtaW5lcyBzdWl0YWJsZSBhbHRlcm5hdGUgVFVSTiBzZXJ2ZXIgdGhhdCBjYW4gb2ZmZXIg dGhlIHJlcXVpcmVkIGxldmVsIG9mIHByaXZhY3kuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A3553A767xmbrcdx10ciscoc_-- From nobody Fri Feb 6 08:20:08 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C271A6F7B for ; Fri, 6 Feb 2015 08:20:01 -0800 (PST) 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 LiUpn8sFFwIi for ; Fri, 6 Feb 2015 08:19:59 -0800 (PST) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED671A6FCB for ; Fri, 6 Feb 2015 08:19:22 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id la4so5370887vcb.10 for ; Fri, 06 Feb 2015 08:19:22 -0800 (PST) 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=xOdQXU2SEiih9kWX2RnEweXw2p7KVwuVuZzoU8K6VZo=; b=hiKrbLcliLTPLhGRJdD7Q+KtJ3ZzKb9aNXhySjb6ASyvWQSpTWgCE40tNvIYJZ8eOG P+djcs7/2WXh2hPlJV8+nH5/K0lVYoo6epBxuTnIw7Q30rCiyhS0lLwgTWKjfwbQrW8K CitwYosKy0hMCl8aKH9JxMLsj/P2WJbknlAUlcNXxd+H+AR39wmsUJ5bW5gJMFVny3oN hTww+XlgJM9ZAxhxgT1ZaIYwy7+lIharp1QH/xw4irtwo0nmkyuTIDSp9ebEgKxTySsl 3UwBR3txyhzKcEwUcU2TL25wARkdiTg+YRS37Y55OOMmmeTS4YjFFe2tb3wBK12jsOrR Z5aQ== X-Gm-Message-State: ALoCoQkQ1ytRp6k1IOffinVKCd+YnEx4NfaLCGwLGvRubsCMLjKWfC9rq0jT2h00dTZPQyrqMd6p X-Received: by 10.220.83.7 with SMTP id d7mr2695158vcl.24.1423239562038; Fri, 06 Feb 2015 08:19:22 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com. [209.85.220.172]) by mx.google.com with ESMTPSA id j5sm422959vdy.0.2015.02.06.08.19.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Feb 2015 08:19:21 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id le20so5363238vcb.3 for ; Fri, 06 Feb 2015 08:19:20 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.221.48.197 with SMTP id ux5mr2680251vcb.40.1423239560566; Fri, 06 Feb 2015 08:19:20 -0800 (PST) Received: by 10.52.54.194 with HTTP; Fri, 6 Feb 2015 08:19:20 -0800 (PST) Received: by 10.52.54.194 with HTTP; Fri, 6 Feb 2015 08:19:20 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A3553A27C@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A3553A27C@xmb-rcd-x10.cisco.com> Date: Fri, 6 Feb 2015 11:19:20 -0500 Message-ID: From: Benjamin Schwartz To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a113399727043d7050e6dc828 Archived-At: Cc: Simon Perreault , tram@ietf.org, Justin Uberti Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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: Fri, 06 Feb 2015 16:20:01 -0000 --001a113399727043d7050e6dc828 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I appreciate the goal of this work. Maybe a slightly different strategy would be more easily accepted in the working group. What if the client could query the server for a list of alternate TURN servers? Then the client could have the option of selecting a server based on geolocation, but the client would not have to convey its privacy goals to the server explicitly. Inline [TR] *From:* Justin Uberti [mailto:juberti@google.com] *Sent:* Friday, February 06, 2015 6:21 AM *To:* Tirumaleswar Reddy (tireddy) *Cc:* Benjamin Schwartz; Simon Perreault; tram@ietf.org *Subject:* Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt I agree with Simon and Ben in being skeptical about this proposal. The client is the only party which knows exactly what 'privacy' means, and there is no trivial way to serialize this into a single attribute for the TURN server. [TR] We are evaluating how the client can covey its =E2=80=98privacy=E2=80= =99 needs in this new attribute to the TURN server so that it can take appropriate action and the server responds if the client =E2=80=98privacy=E2=80=99 requirement can= be met fully or partially. -Tiru As such, I think this decision should be left entirely to the client. On Wed, Feb 4, 2015 at 10:50 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: I agree that the client can do equally well itself, by sending a STUN Binding Request and comparing the response to the TURN server's own IP address. [TR3] The difference this draft brings in is that it helps the TURN server (offered by a global or cloud service) to determine that the client wants privacy and level of privacy required conveyed in the new STUN attribute, the TURN server determines suitable alternate TURN server that can offer the required level of privacy. -Tiru _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --001a113399727043d7050e6dc828 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I appreciate the goal of this work.=C2=A0 Maybe a slightly d= ifferent strategy would be more easily accepted in the working group.=C2=A0= What if the client could query the server for a list of alternate TURN ser= vers?=C2=A0 Then the client could have the option of selecting a server bas= ed on geolocation, but the client would not have to convey its privacy goal= s to the server explicitly.

Inline [TR]=

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Friday, February 06, 2015 6:21 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Benjamin Schwartz; Simon Perreault; tram@ietf.org
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tra= m-turn-ipaddress-privacy-00.txt

=C2=A0

I agree with Simon and Ben in being skeptical about = this proposal.

=C2=A0

The client is the only party which knows exactly wha= t 'privacy' means, and there is no trivial way to serialize this in= to a single attribute for the TURN server.

=C2=A0

[TR] We are evaluating ho= w the client can covey its =E2=80=98privacy=E2=80=99 needs in this new attr= ibute to the TURN server so that it can take appropriate action and the server responds if the client =E2=80=98privacy=E2=80=99 requirement can be= met fully or partially.

=C2=A0

-Tiru

=C2=A0

As such, I think this decision should be left entire= ly to the client.

=C2=A0

On Wed, Feb 4, 2015 at 10:50 AM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

I agree that the client can do equally well itself, = by sending a STUN Binding Request and comparing the response to the TURN se= rver's own IP address.=C2=A0

=C2=A0

[TR3] The difference this= draft brings in is that it helps the TURN server (offered by a global or cloud service) to determine that the client wants privacy and level of pri= vacy required conveyed in the new STUN attribute, the TURN server determine= s suitable alternate TURN server that can offer the required level of priva= cy.

=C2=A0

-Tiru


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

=C2=A0

--001a113399727043d7050e6dc828-- From nobody Fri Feb 6 08:42:37 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60CD1A6FDB for ; Fri, 6 Feb 2015 08:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRH830_ec3Fe for ; Fri, 6 Feb 2015 08:42:31 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8471A6F7C for ; Fri, 6 Feb 2015 08:42:30 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id l15so3835832wiw.4 for ; Fri, 06 Feb 2015 08:42:29 -0800 (PST) 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=LS9LlCGcWBoKi4eULLOJkd8lRCBKj226HmgQmDF/rnw=; b=Q8Z0EBnW20/mI0TLjQeCZbeSmrJnYhFgR0dTOOZzxbuxKKk2qsILSlpxtSPD3QTT/a mXvo41DAVvt3AgNK1hX2rgHJickNHnKBs5sOnDZq9twqdWnCSTyDBO056ukyQmRp2yV8 VvgYquPigs9kcFU6N4Rb5NEfzmiFTiuQnv5rPzb6TWotyCj2Luzc+dmLaMMAi214zVEZ PLwc8yFw2jiygPnfKEg619rnnXhLVijl0TZWcMV08cWhZx8GIuyElKTrdsZw2410csOF Tom5G+PB4+6Djb85yBVLyuCBlSCZjOES+S7O1u3C7phzwpgMw5VfwGb79S3dRsu6wEE3 VvcA== MIME-Version: 1.0 X-Received: by 10.194.6.228 with SMTP id e4mr9384987wja.63.1423240949581; Fri, 06 Feb 2015 08:42:29 -0800 (PST) Received: by 10.194.190.18 with HTTP; Fri, 6 Feb 2015 08:42:29 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A3553A743@xmb-rcd-x10.cisco.com> References: <20150206141537.23425.13842.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553A743@xmb-rcd-x10.cisco.com> Date: Fri, 6 Feb 2015 08:42:29 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Yaron Sheffer \(yaronf.ietf@gmail.com\)" , "tram@ietf.org" , "'Christer Holmberg' \(christer.holmberg@ericsson.com\)" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-10.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, 06 Feb 2015 16:42:33 -0000 As the key generation changed, the Appendix A vectors are to be changed. I'll send the new vectors, later. Oleg On Fri, Feb 6, 2015 at 6:23 AM, Tirumaleswar Reddy (tireddy) wrote: > This revision addresses comments from Christer and updates section 4.1.1 to use different strings in HKDF function to generate AS-RS and AUTH keys. > > -Tiru > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Friday, February 06, 2015 7:46 PM >> To: i-d-announce@ietf.org >> Cc: tram@ietf.org >> Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-10.txt >> >> >> 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-10.txt >> Pages : 22 >> Date : 2015-02-06 >> >> Abstract: >> This document proposes the use of OAuth 2.0 to obtain and validate >> ephemeral tokens that can be used for Session Traversal Utilities for >> NAT (STUN) authentication. The usage of ephemeral tokens ensures >> that access to a STUN server can be controlled even if the tokens are >> compromised. >> >> >> 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-10 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-10 >> >> >> 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 > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Sun Feb 8 17:54:23 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B6F1A86E2 for ; Sun, 8 Feb 2015 17:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.991 X-Spam-Level: * X-Spam-Status: No, score=1.991 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_72=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-Ma8N9EftQh for ; Sun, 8 Feb 2015 17:54:19 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id CA4471A6F22 for ; Sun, 8 Feb 2015 17:54:18 -0800 (PST) Received: from ctbriwangaij (unknown [124.127.116.138]) by app1 (Coremail) with SMTP id Z0GX06Cb5AFB_NdU_50lAg==.2240S2; Mon, 09 Feb 2015 08:16:01 +0800 (CST) From: "Aijun Wang" To: "'Pal Martinsen \(palmarti\)'" References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <000001d03f8a$010c89a0$03259ce0$@org.cn> <007401d04024$0ee0d3c0$2ca27b40$@org.cn> <37F58EB6-2CAE-4CA5-B286-D622DC33B139@cisco.com> <00ed01d04110$1ca32340$55e969c0$@org.cn> <5F8B3F40-2232-4827-8904-2562CF447497@cisco.com> In-Reply-To: <5F8B3F40-2232-4827-8904-2562CF447497@cisco.com> Date: Mon, 9 Feb 2015 09:54:03 +0800 Message-ID: <000c01d0440b$483c1310$d8b43930$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01D0444E.565F5310" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQPEw3iE7SBHjBP02Pt2UimDWYDJze//0AgAAJBACAASsYAIAAf8SAgADkaWCAAKRNgIAFVvSQ Content-Language: zh-cn X-CM-TRANSID: Z0GX06Cb5AFB_NdU_50lAg==.2240S2 X-Coremail-Antispam: 1U3129KBjvJXoW7CFyDuF4UGFW5tFWkXF1fWFg_yoW5JF1xpa 9xJ343J3Wvqr1xCws5Wa4UXryrZF97GFy7Jr15Wr95Can5CrnFqr9Ikw48KryUXFyFq3WY qryjva4DC34rZaDanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjHCb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r1j6r4UM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwCY1x0262kK e7AKxVWUAVWUtwC2zVAF1VAY17CE14v26r126r1D0xZFpf9x0JUBBT5UUUUU= Archived-At: Cc: 'Oleg Moskalenko' , "'Tirumaleswar Reddy \(tireddy\)'" , 'Brandon Williams' , tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 09 Feb 2015 01:54:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01D0444E.565F5310 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Pal: =20 Sorry to reply you late. Here I have one question to ask, would you like = to explain it then: =20 http://tools.ietf.org/html/draft-ietf-tram-turnbis-02#section-8 = =E2=80=9CPermissions=E2=80=9D describes as bellowing: =20 =E2=80=9CFor each allocation, the server keeps a list of zero or more permissions. Each permission consists of an IP address and an associated time-to-expiry. While a permission exists, all peers using the IP address in the permission are allowed to send data to the client.=E2=80=9D =20 Why doesn=E2=80=99t the permission consider the Port value of = XOR-PEER-ADDRESS? When the CGN(Carrier Grade NAT) are deployed by the = service provider, many hosts may share one public addresses. Then in = such environment, the client is prone to be attacked by hosts that under = the same CGN coverage? The TURN server will also relay many traffic that = is not the client=E2=80=99s desirable data. =20 Also in such situation, even with the cooperation of TURN and ICE, there = will likely be failure for the communication between two hosts, = lets=E2=80=99 consider the following diagram: A---------EDM NAT 1-------------TURN Server--------EDM NAT = 2(CGN)------------------------B =20 1. Let=E2=80=99s suppose A=E3=80=81B Send ICE packet to each other and = punch hole in the EDM NAT 1 and EDM NAT 2(this process should be added = in current draft = http://tools.ietf.org/html/draft-ietf-tram-turnbis-02#section-10.2) 2. A send =E2=80=9CSendIndicatiion=E2=80=9D to TURN Server, TURN Server = send UDP packet to B, using A=E2=80=99s Relay Address(RA) as the source = address. 3. B will send response UDP packet to TURN Server=EF=BC=8Cuse RA as the = destination address. When one EDM NAT lies between the TURN server and = host B, TURN Server will see this response UDP packet come from one new = reflex address(we call XB=E2=80=99), not the reflex address(we call XB) = when B send binding request to TURN Server=E2=80=99s well-known address. 4. So, if the IP address portion of XB=E2=80=99 is same as that of XB, = this packet will be relayed by TURN Server; if not, this packet will = dropped by TURN Server. This will lead to the communication failure = between A and B. =20 How do you think about this scenarios? =20 =20 From: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]=20 Sent: Thursday, February 05, 2015 5:44 PM To: Aijun Wang Cc: Oleg Moskalenko; Brandon Williams; Tirumaleswar Reddy (tireddy); = tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt =20 Ok, I will try to explain. Would be nice if some others on the list can = verify what I say is correct.=20 =20 ------=_NextPart_000_000D_01D0444E.565F5310 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi, Pal:

 

Sorry to reply you late. Here I have one question to ask, would you = like to explain it then:

 

= http://tools.ietf.org/html/draft-ietf-tram-turnbis-02#section-8 = =C2=A0=E2=80=9CPermissions=E2=80=9D describes as = bellowing:

 
=E2=80=9CFor each =
allocation, the server keeps a list of zero or =
more

=C2=A0=C2=A0 permissions.=C2=A0 Each = permission consists of an IP address and an

=C2=A0=C2=A0 associated time-to-expiry.=C2=A0 = While a permission exists, all peers

=C2=A0=C2=A0 using the IP address in the = permission are allowed to send data to

=C2=A0=C2=A0 the client.=E2=80=9D

 

Why doesn=E2=80=99t the permission consider the Port value of = XOR-PEER-ADDRESS? When the CGN(Carrier Grade NAT) are deployed by the = service provider, many hosts may share one public addresses. Then in = such environment, the client is prone to be attacked by hosts that under = the same CGN coverage? The TURN server will also relay many traffic that = is not the client=E2=80=99s =C2=A0desirable = data.

 

Also in such situation, even with the cooperation of TURN and ICE, = there will likely be failure for the communication between two hosts, = lets=E2=80=99 consider the following diagram:

A---------EDM NAT 1-------------TURN Server--------EDM NAT = 2(CGN)------------------------B

 

1. Let=E2=80=99s suppose A=E3=80=81B Send ICE packet to each other and punch hole in the EDM NAT 1 and =
EDM NAT 2(this process should be added in current draft http://tools.ietf.org/html/draft-ietf-tram-turnbis-02#section-10.2=
)

2. A send =E2=80=9CSendIndicatiion=E2=80=9D to TURN Server, TURN = Server send UDP packet to B, using A=E2=80=99s Relay Address(RA) as the = source address.

3. B will send response UDP packet to TURN Server=EF=BC=8Cuse RA as the destination address. When one EDM NAT lies between the = TURN server and host B, TURN Server will see this response UDP packet = come from one new reflex address(we call XB=E2=80=99), not the reflex = address(we call XB) when B send binding request to TURN Server=E2=80=99s = well-known address.

4. So, if the IP address portion of XB=E2=80=99 is same as that of = XB, this packet will be relayed by TURN Server; if not, this packet will = dropped by TURN Server. This will lead to the communication failure = between A and B.

 

How do you think about this scenarios?

 

 

From:= Pal = Martinsen (palmarti) [mailto:palmarti@cisco.com]
Sent: = Thursday, February 05, 2015 5:44 PM
To: Aijun = Wang
Cc: Oleg Moskalenko; Brandon Williams; Tirumaleswar Reddy = (tireddy); tram@ietf.org
Subject: Re: [tram] I-D Action: = draft-ietf-tram-turnbis-01.txt

 

Ok, I will try to explain. Would be = nice if some others  on the list can verify what I say is correct. =

 

------=_NextPart_000_000D_01D0444E.565F5310-- From nobody Mon Feb 9 00:58:18 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C29C1A00F4 for ; Mon, 9 Feb 2015 00:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.31 X-Spam-Level: X-Spam-Status: No, score=-13.31 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_37=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bk2d1mXEWyYl for ; Mon, 9 Feb 2015 00:58:13 -0800 (PST) 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 770791A0078 for ; Mon, 9 Feb 2015 00:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36768; q=dns/txt; s=iport; t=1423472294; x=1424681894; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0aRWkmW5fb5CB9Fe4o4J8Zzm361TDcItodAK3cFCwHk=; b=ieD2rOsuOz482os3cMEXQ45pkuIvCMl1qKlV4CzKAv/QIYhzcSvOWC/6 DbvDLnBwAn569cnPVtvCtJOmyCd4dlsAgqnbRq6kOU5jkxjrZepw9maW6 xlDIcEWl2aOWAmov3kP1o+nQLeZnmogI5wDLDnxGsJOuLNLqxTGeu7f+Z I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BTCADGddhU/4QNJK1cgkNDUloEgn6+C4FHGQEJhXECHHdDAQEBAQEBfIQMAQEBBAEBASAkIAcLEAIBCBEEAQEhAQYDAgICJQsUCQgCBA4FiC0NsEmFFpBwAQEBAQEBAQEBAQEBAQEBAQEBAQEBF490BAYBgmiBQgWFUodmgWODUIVcgRg2jWSDPiKDbm8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,542,1418083200"; d="scan'208,217";a="121742355" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP; 09 Feb 2015 08:58:13 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t198wCVk024462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Feb 2015 08:58:12 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.15]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Mon, 9 Feb 2015 02:58:12 -0600 From: "Pal Martinsen (palmarti)" To: Aijun Wang Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt Thread-Index: AQHQPEw3iE7SBHjBP02Pt2UimDWYDJze//0AgAAJBACAASsYAIAAf8SAgADkaWCAAKRNgIAFVvSQgADloYA= Date: Mon, 9 Feb 2015 08:58:11 +0000 Message-ID: <438D1571-86AF-4E48-B606-2191348617CE@cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <000001d03f8a$010c89a0$03259ce0$@org.cn> <007401d04024$0ee0d3c0$2ca27b40$@org.cn> <37F58EB6-2CAE-4CA5-B286-D622DC33B139@cisco.com> <00ed01d04110$1ca32340$55e969c0$@org.cn> <5F8B3F40-2232-4827-8904-2562CF447497@cisco.com> <000c01d0440b$483c1310$d8b43930$@org.cn> In-Reply-To: <000c01d0440b$483c1310$d8b43930$@org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.76] Content-Type: multipart/alternative; boundary="_000_438D157186AF4E48B6062191348617CEciscocom_" MIME-Version: 1.0 Archived-At: Cc: Oleg Moskalenko , Brandon Williams , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 09 Feb 2015 08:58:17 -0000 --_000_438D157186AF4E48B6062191348617CEciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAwOSBGZWIgMjAxNSwgYXQgMDI6NTQsIEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1 YS5vcmcuY248bWFpbHRvOndhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+PiB3cm90ZToNCg0KSGks IFBhbDoNCg0KU29ycnkgdG8gcmVwbHkgeW91IGxhdGUuDQoNCk5vIHN1Y2ggdGhpbmsgYXMgYSBs YXRlIHJlcGx5IGluIElFVEYuLiA6LSkNCg0KSGVyZSBJIGhhdmUgb25lIHF1ZXN0aW9uIHRvIGFz aywgd291bGQgeW91IGxpa2UgdG8gZXhwbGFpbiBpdCB0aGVuOg0KDQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMiNzZWN0aW9uLTggIOKAnFBlcm1p c3Npb25z4oCdIGRlc2NyaWJlcyBhcyBiZWxsb3dpbmc6DQoNCg0KDQrigJxGb3IgZWFjaCBhbGxv Y2F0aW9uLCB0aGUgc2VydmVyIGtlZXBzIGEgbGlzdCBvZiB6ZXJvIG9yIG1vcmUNCg0KICAgcGVy bWlzc2lvbnMuICBFYWNoIHBlcm1pc3Npb24gY29uc2lzdHMgb2YgYW4gSVAgYWRkcmVzcyBhbmQg YW4NCiAgIGFzc29jaWF0ZWQgdGltZS10by1leHBpcnkuICBXaGlsZSBhIHBlcm1pc3Npb24gZXhp c3RzLCBhbGwgcGVlcnMNCiAgIHVzaW5nIHRoZSBJUCBhZGRyZXNzIGluIHRoZSBwZXJtaXNzaW9u IGFyZSBhbGxvd2VkIHRvIHNlbmQgZGF0YSB0bw0KICAgdGhlIGNsaWVudC7igJ0NCg0KV2h5IGRv ZXNu4oCZdCB0aGUgcGVybWlzc2lvbiBjb25zaWRlciB0aGUgUG9ydCB2YWx1ZSBvZiBYT1ItUEVF Ui1BRERSRVNTPw0KDQpJIHRoaW5rIHRoZSBpZGVhIGlzIHRvIG1pbWljIGhvdyBhIOKAnGdvb2Qg TkFU4oCdIHdvdWxkIHdvcmsuDQoNClRoaXMgYmVoYXZpb3VyIGlzIG5lZWRlZCBmb3IgSUNFIHRv IHdvcmsuIFR5cGljYWwgeW91IHdvbGQgc2V0IHBlcm1pc3Npb25zIG9uIHlvdSBUVVJOIHNlcnZl ciB0byBhbGxvdyB0cmFmZmljIGZyb20gdGhlIHJlbW90ZSBSRkxYIGFuZCBSRUxBWSBhZGRyZXNz ZXMuIFNpbmNlIHRoZSByZW1vdGUgYWdlbnQgcHJvYmFibHkgbGVhcm50IGhpcyBSRkxYIGFkZHJl c3Mgd2hlbiBhbGxvY2F0aW5nIGEgUkVMQVkgYWRkcmVzcyBvbiBoaXMgVFVSTiBzZXJ2ZXIsIHRo ZSBjb25uZWN0aXZpdHkgY2hlY2tzIHJlYWNoaW5nIHlvdXIgVFVSTiBzZXJ2ZXIgbWlnaHQgY29t ZSBmcm9tIGEgZGlmZmVyZW50IHBvcnQgb24gdGhlIHJlbW90ZSBzaWRlIE5BVCB0aGVuIHdoYXQg aGUgc2lnbmFsbGVkIGFzIGEgUkZMWCBjYW5kaWRhdGUgaW4gdGhlIFNEUC4NCg0KU2VjdGlvbiAx Ny4yIGV4cGxhaW5zIHRoaXMgYSBiaXQgbW9yZS4gQnV0IHNvbWUgbW9yZSB0ZXh0IGluIFRVUk5i aXMgZXhwbGFpbmluZyB0aGF0IHNldHRpbmcgcGVybWlzc2lvbnMgd2l0aCB3b3VsZCBicmVhayBJ Q0UgbWlnaHQgY29tZSBpbiBoYW5keS4gVGlydSwgYW55IHRob3VnaHRzPw0KDQoNCldoZW4gdGhl IENHTihDYXJyaWVyIEdyYWRlIE5BVCkgYXJlIGRlcGxveWVkIGJ5IHRoZSBzZXJ2aWNlIHByb3Zp ZGVyLCBtYW55IGhvc3RzIG1heSBzaGFyZSBvbmUgcHVibGljIGFkZHJlc3Nlcy4gVGhlbiBpbiBz dWNoIGVudmlyb25tZW50LCB0aGUgY2xpZW50IGlzIHByb25lIHRvIGJlIGF0dGFja2VkIGJ5IGhv c3RzIHRoYXQgdW5kZXIgdGhlIHNhbWUgQ0dOIGNvdmVyYWdlPyBUaGUgVFVSTiBzZXJ2ZXIgd2ls bCBhbHNvIHJlbGF5IG1hbnkgdHJhZmZpYyB0aGF0IGlzIG5vdCB0aGUgY2xpZW504oCZcyAgZGVz aXJhYmxlIGRhdGEuDQoNCkkgYW0gbm90IHZlcnkgZmFtaWxpYXIgd2l0aCBob3cgYSBDR04gTkFU IHdvdWxkIGRpZmZlciBmcm9tIGEg4oCcbm9ybWFs4oCdIE5BVCBpbiBJQ0UvVFVSTiBzY2VuYXJp b3MuIFRoZSBhbnN3ZXJzIGJlbG93IG1pZ2h0IHJlZmxlY3QgdGhhdC4NCg0KQWxzbyBpbiBzdWNo IHNpdHVhdGlvbiwgZXZlbiB3aXRoIHRoZSBjb29wZXJhdGlvbiBvZiBUVVJOIGFuZCBJQ0UsIHRo ZXJlIHdpbGwgbGlrZWx5IGJlIGZhaWx1cmUgZm9yIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4g dHdvIGhvc3RzLCBsZXRz4oCZIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZGlhZ3JhbToNCkEtLS0t LS0tLS1FRE0gTkFUIDEtLS0tLS0tLS0tLS0tVFVSTiBTZXJ2ZXItLS0tLS0tLUVETSBOQVQgMihD R04pLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tQg0KDQoNCjEuIExldOKAmXMgc3VwcG9zZSBB44CB QiBTZW5kIElDRSBwYWNrZXQgdG8gZWFjaCBvdGhlciBhbmQgcHVuY2ggaG9sZSBpbiB0aGUgRURN IE5BVCAxIGFuZCBFRE0gTkFUIDIodGhpcyBwcm9jZXNzIHNob3VsZCBiZSBhZGRlZCBpbiBjdXJy ZW50IGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJu YmlzLTAyI3NlY3Rpb24tMTAuMikNCg0KSXNu4oCZdCB0aGlzIGRlc2NyaWJlZCBpbiBSRkM1MjQ1 PyBUaGlzIGlzIGhvdyBJQ0UgZG9lcyBpdCBSRkxYIHRvIFJGTFggY2hlY2tzPyBJcyB0aGUgcG9p bnQgdGhhdCBpZiB0d28gQ0dOIE5BVHMgYXJlIGludm9sdmVkIElDRSB3b3VsZCBhbHdheXMgZmFp bCBpbiB0aGUgUkZMWCB0byBSRkxYIHNjZW5hcmlvLCBhbmQgaGF2ZSB0byBmYWxsIGJhY2sgdG8g dXNpbmcgVFVSTj8gKEFnYWluLCBJIGRvIG5vdCBrbm93IGhvdyBDR04gTkFUUyBvcGVyYXRlKQ0K DQoNCjIuIEEgc2VuZCDigJxTZW5kSW5kaWNhdGlpb27igJ0gdG8gVFVSTiBTZXJ2ZXIsIFRVUk4g U2VydmVyIHNlbmQgVURQIHBhY2tldCB0byBCLCB1c2luZyBB4oCZcyBSZWxheSBBZGRyZXNzKFJB KSBhcyB0aGUgc291cmNlIGFkZHJlc3MuDQozLiBCIHdpbGwgc2VuZCByZXNwb25zZSBVRFAgcGFj a2V0IHRvIFRVUk4gU2VydmVy77yMdXNlIFJBIGFzIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzLiBX aGVuIG9uZSBFRE0gTkFUIGxpZXMgYmV0d2VlbiB0aGUgVFVSTiBzZXJ2ZXIgYW5kIGhvc3QgQiwg VFVSTiBTZXJ2ZXIgd2lsbCBzZWUgdGhpcyByZXNwb25zZSBVRFAgcGFja2V0IGNvbWUgZnJvbSBv bmUgbmV3IHJlZmxleCBhZGRyZXNzKHdlIGNhbGwgWELigJkpLCBub3QgdGhlIHJlZmxleCBhZGRy ZXNzKHdlIGNhbGwgWEIpIHdoZW4gQiBzZW5kIGJpbmRpbmcgcmVxdWVzdCB0byBUVVJOIFNlcnZl cuKAmXMgd2VsbC1rbm93biBhZGRyZXNzLg0KWW91IGFyZSBmb3JnZXR0aW5nIHRoYXQgYXMgcGFy dCBvZiBJQ0UgQiB3aWxsIGFsc28gc2VuZCBhIGNvbm5lY3Rpdml0eSBjaGVjayB0b3dhcmRzIFJB LiBUaGlzIHNob3VsZCBvcGVuIHVwIHRoZSBwaW5ob2xlIGluIEVETSBOQVQgMi4NCg0KNC4gU28s IGlmIHRoZSBJUCBhZGRyZXNzIHBvcnRpb24gb2YgWELigJkgaXMgc2FtZSBhcyB0aGF0IG9mIFhC LCB0aGlzIHBhY2tldCB3aWxsIGJlIHJlbGF5ZWQgYnkgVFVSTiBTZXJ2ZXI7IGlmIG5vdCwgdGhp cyBwYWNrZXQgd2lsbCBkcm9wcGVkIGJ5IFRVUk4gU2VydmVyLiBUaGlzIHdpbGwgbGVhZCB0byB0 aGUgY29tbXVuaWNhdGlvbiBmYWlsdXJlIGJldHdlZW4gQSBhbmQgQi4NCg0KSG93IGRvIHlvdSB0 aGluayBhYm91dCB0aGlzIHNjZW5hcmlvcz8NCg0KSUNFIHdpbGwgZml4IHRoaXMuIFJlbWVtYmVy IEEgYW5kIEIgaGF2ZSBleGNoYW5nZWQgYWxsIGNhbmRpZGF0ZXMgYW5kIGNyYXRlZCBhIHNpbWls YXIgY2hlY2tsaXN0IHRoYXQgd2lsbCBydW4gc2ltdWx0YW5lb3VzbHkgZm9ybSBib3RoIHNpZGVz LiBTb21lIHBhY2tldHMgd2lsbCBiZSBibG9ja2VkIGF0IHRoZSByZW1vdGUgTkFULCBidXQgdGhl eSBzdGlsbCBoYXZlIG9wZW5lZCB1cCBhIHBpbmhvbGUgb24gdGhlIGxvY2FsIE5BVC4gU28gd2l0 aCBzb21lIHN5bmNocm9uaXNhdGlvbiBhbmQgcmV0cmFuc21pdHMgYWwgdGhlIG5lY2Vzc2FyeSBw b3J0cyB3aWxsIGJlIG9wZW5lZCB1cC4gSW4gSUNFIHRoZXJlIGlzIGFsc28gdGhlIGNvbmNlcHQg b2YgcGVlciBSRkxYIGFkZHJlc3NlcyB0aGF0IHRoZSBhZ2VudHMgbGVhcm4gd2hlbiB0aGV5IGRv IHRoZSBjb25uZWN0aXZpdHkgY2hlY2tzLiBVbmRlcnN0YW5kaW5nIGhvdyB0aG9zZSB3b3JrIGlz IHByb2JhYmx5IGltcG9ydGFudCB0byB1bmRlcnN0YW5kIGhvdyBJQ0Ugc29sdmVzIHlvdXIgYWJv dmUgc2NlbmFyaW8uIEFsc28ga2VlcCBpbiBtaW5kIHRoYXQgdGhlIGNvbm5lY3Rpdml0eSBjaGVj a3MgYWxzbyBhcmUg4oCcdHVubmVsbGVk4oCdIHZpYSB0aGUgVFVSTiBzZXJ2ZXIgYW5kIGFwcGVh cnMgdG8gYmUgc2VudCBieSB0aGUgUkVMQVkgYWRkcmVzcy4NCg0KT3IgaXMgeW91ciBpbnRlbnRp b24gdG8gZml4IHVwIFRVUk4gc28gaXQgaXMgaW5kZXBlbmRlbnQgb2YgSUNFLiBJbiB0aGF0IGNh c2UgaXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gaGVhciBtb3JlIGFib3V0IHlvdXIgdXNlIGNh c2UgYW5kIG1vdGl2YXRpb24gZm9yIGRvaW5nIHRoYXQuDQoNCi4tLg0KUMOlbC1FcmlrDQoNCg0K DQoNCg0KRnJvbTogUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpIFttYWlsdG86cGFsbWFydGlAY2lz Y28uY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE1IDU6NDQgUE0NClRvOiBB aWp1biBXYW5nDQpDYzogT2xlZyBNb3NrYWxlbmtvOyBCcmFuZG9uIFdpbGxpYW1zOyBUaXJ1bWFs ZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFt0cmFtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRyYW0tdHVybmJp cy0wMS50eHQNCg0KT2ssIEkgd2lsbCB0cnkgdG8gZXhwbGFpbi4gV291bGQgYmUgbmljZSBpZiBz b21lIG90aGVycyAgb24gdGhlIGxpc3QgY2FuIHZlcmlmeSB3aGF0IEkgc2F5IGlzIGNvcnJlY3Qu DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmFt IG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQo= --_000_438D157186AF4E48B6062191348617CEciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <99E827C6CD815B45880C09E4404C8671@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAwOSBG ZWIgMjAxNSwgYXQgMDI6NTQsIEFpanVuIFdhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5nYWlq dW5AdHNpbmdodWEub3JnLmNuIiBjbGFzcz0iIj53YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPC9h PiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6 IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiDlrovk vZM7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41 cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiIGNsYXNzPSIiPkhpLCBQYWw6PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6IOWui+S9kzsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiDlrovkvZM7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPlNvcnJ5IHRvIHJlcGx5IHlvdSBsYXRlLg0KPC9z cGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2Pk5vIHN1Y2ggdGhpbmsgYXMgYSBsYXRlIHJlcGx5IGluIElFVEYu LiA6LSkmbmJzcDs8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5 bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiDlrovkvZM7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkhlcmUgSSBoYXZlIG9uZSBxdWVzdGlvbiB0byBhc2ss IHdvdWxkIHlvdSBsaWtlIHRvIGV4cGxhaW4gaXQgdGhlbjo8bzpwIGNsYXNzPSIiPjwvbzpwPjwv c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTog5a6L5L2TOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDIjc2VjdGlvbi04IiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMiNz ZWN0aW9uLTg8L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPiZuYnNwO+KAnFBlcm1pc3Npb25z4oCdDQogZGVzY3JpYmVzIGFzIGJlbGxvd2luZzo8bzpw IGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog5a6L5L2TOyBwYWdlLWJy ZWFrLWJlZm9yZTogYWx3YXlzOyIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiDlrovkvZM7IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7IiBjbGFzcz0iIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj7igJw8L3Nw YW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IiBjbGFzcz0iIj5Gb3Ig ZWFjaCBhbGxvY2F0aW9uLCB0aGUgc2VydmVyIGtlZXBzIGEgbGlzdCBvZiB6ZXJvIG9yIG1vcmU8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog5a6L5L2TOyBwYWdl LWJyZWFrLWJlZm9yZTogYWx3YXlzOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtc2l6ZTogMTBwdDsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBwZXJtaXNzaW9ucy4mbmJz cDsgRWFjaCBwZXJtaXNzaW9uIGNvbnNpc3RzIG9mIGFuIElQIGFkZHJlc3MgYW5kIGFuPG86cCBj bGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgcGFnZS1icmVh ay1iZWZvcmU6IGFsd2F5czsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250 LXNpemU6IDEwcHQ7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgYXNzb2NpYXRlZCB0aW1lLXRvLWV4 cGlyeS4mbmJzcDsgV2hpbGUgYSBwZXJtaXNzaW9uIGV4aXN0cywgYWxsIHBlZXJzPG86cCBjbGFz cz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgcGFnZS1icmVhay1i ZWZvcmU6IGFsd2F5czsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgdXNpbmcgdGhlIElQIGFkZHJlc3MgaW4g dGhlIHBlcm1pc3Npb24gYXJlIGFsbG93ZWQgdG8gc2VuZCBkYXRhIHRvPG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsiIGNsYXNzPSIiPg0KPHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsg dGhlIGNsaWVudC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEw LjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyIgY2xhc3M9IiI+4oCdPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6IOWui+S9kzsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiDlrovkvZM7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPldoeSBkb2VzbuKAmXQgdGhlIHBlcm1pc3Npb24gY29u c2lkZXIgdGhlIFBvcnQgdmFsdWUgb2YgWE9SLVBFRVItQUREUkVTUz8NCjwvc3Bhbj48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdj5JIHRoaW5rIHRoZSBpZGVhIGlzIHRvIG1pbWljIGhvdyBhIOKAnGdvb2QgTkFU4oCd IHdvdWxkIHdvcmsuJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp dj5UaGlzIGJlaGF2aW91ciBpcyBuZWVkZWQgZm9yIElDRSB0byB3b3JrLiBUeXBpY2FsIHlvdSB3 b2xkIHNldCBwZXJtaXNzaW9ucyBvbiB5b3UgVFVSTiBzZXJ2ZXIgdG8gYWxsb3cgdHJhZmZpYyBm cm9tIHRoZSByZW1vdGUgUkZMWCBhbmQgUkVMQVkgYWRkcmVzc2VzLiBTaW5jZSB0aGUgcmVtb3Rl IGFnZW50IHByb2JhYmx5IGxlYXJudCBoaXMgUkZMWCBhZGRyZXNzIHdoZW4gYWxsb2NhdGluZyBh IFJFTEFZIGFkZHJlc3Mgb24gaGlzIFRVUk4NCiBzZXJ2ZXIsIHRoZSBjb25uZWN0aXZpdHkgY2hl Y2tzIHJlYWNoaW5nIHlvdXIgVFVSTiBzZXJ2ZXIgbWlnaHQgY29tZSBmcm9tIGEgZGlmZmVyZW50 IHBvcnQgb24gdGhlIHJlbW90ZSBzaWRlIE5BVCB0aGVuIHdoYXQgaGUgc2lnbmFsbGVkIGFzIGEg UkZMWCBjYW5kaWRhdGUgaW4gdGhlIFNEUC48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2PlNlY3Rpb24gMTcuMiBleHBsYWlucyB0aGlzIGEgYml0IG1vcmUuIEJ1dCBzb21l IG1vcmUgdGV4dCBpbiBUVVJOYmlzIGV4cGxhaW5pbmcgdGhhdCBzZXR0aW5nIHBlcm1pc3Npb25z IHdpdGggd291bGQgYnJlYWsgSUNFIG1pZ2h0IGNvbWUgaW4gaGFuZHkuIFRpcnUsIGFueSB0aG91 Z2h0cz88L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24x OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsiIGNsYXNzPSIi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9 IiI+V2hlbiB0aGUgQ0dOKENhcnJpZXIgR3JhZGUgTkFUKSBhcmUgZGVwbG95ZWQgYnkgdGhlIHNl cnZpY2UgcHJvdmlkZXIsIG1hbnkgaG9zdHMgbWF5IHNoYXJlIG9uZSBwdWJsaWMgYWRkcmVzc2Vz LiBUaGVuIGluIHN1Y2ggZW52aXJvbm1lbnQsIHRoZQ0KIGNsaWVudCBpcyBwcm9uZSB0byBiZSBh dHRhY2tlZCBieSBob3N0cyB0aGF0IHVuZGVyIHRoZSBzYW1lIENHTiBjb3ZlcmFnZT8gVGhlIFRV Uk4gc2VydmVyIHdpbGwgYWxzbyByZWxheSBtYW55IHRyYWZmaWMgdGhhdCBpcyBub3QgdGhlIGNs aWVudOKAmXMgJm5ic3A7ZGVzaXJhYmxlIGRhdGEuPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpJIGFtIG5vdCB2 ZXJ5IGZhbWlsaWFyIHdpdGggaG93IGEgQ0dOIE5BVCB3b3VsZCBkaWZmZXIgZnJvbSBhIOKAnG5v cm1hbOKAnSBOQVQgaW4gSUNFL1RVUk4gc2NlbmFyaW9zLiBUaGUgYW5zd2VycyBiZWxvdyBtaWdo dCByZWZsZWN0IHRoYXQuJm5ic3A7PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBz dHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6IOWui+S9kzsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6IOWui+S9kzsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiDlrovkvZM7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkFsc28gaW4gc3VjaCBzaXR1YXRpb24sIGV2 ZW4gd2l0aCB0aGUgY29vcGVyYXRpb24gb2YgVFVSTiBhbmQgSUNFLCB0aGVyZSB3aWxsIGxpa2Vs eSBiZSBmYWlsdXJlIGZvciB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHR3byBob3N0cywgbGV0 c+KAmQ0KIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZGlhZ3JhbTo8bzpwIGNsYXNzPSIiPjwvbzpw Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog5a6L5L2TOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5BLS0tLS0tLS0t RURNIE5BVCAxLS0tLS0tLS0tLS0tLVRVUk4gU2VydmVyLS0tLS0tLS1FRE0gTkFUIDIoQ0dOKS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLUI8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTog5a6L5L2TOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8cHJl IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6IOWui+S9kzsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiIGNsYXNzPSIiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPjEuIExl dOKAmXMgc3VwcG9zZSBBPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj7jgIE8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+QiBTZW5kIElDRSBwYWNr ZXQgdG8gZWFjaCBvdGhlciBhbmQgcHVuY2ggaG9sZSBpbiB0aGUgRURNIE5BVCAxIGFuZCBFRE0g TkFUIDIodGhpcyBwcm9jZXNzIHNob3VsZCBiZSBhZGRlZCBpbiBjdXJyZW50IGRyYWZ0IDxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAy I3NlY3Rpb24tMTAuMiIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5k ZXJsaW5lOyIgY2xhc3M9IiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10 cmFtLXR1cm5iaXMtMDIjc2VjdGlvbi0xMC4yPC9hPik8L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj5Jc27igJl0IHRoaXMgZGVzY3JpYmVkIGluIFJGQzUy NDU/IFRoaXMgaXMgaG93IElDRSBkb2VzIGl0IFJGTFggdG8gUkZMWCBjaGVja3M/IElzIHRoZSBw b2ludCB0aGF0IGlmIHR3byBDR04gTkFUcyBhcmUgaW52b2x2ZWQgSUNFIHdvdWxkIGFsd2F5cyBm YWlsIGluIHRoZSBSRkxYIHRvIFJGTFggc2NlbmFyaW8sIGFuZCBoYXZlIHRvIGZhbGwgYmFjayB0 byB1c2luZyBUVVJOPyAoQWdhaW4sIEkgZG8gbm90IGtub3cgaG93IENHTiBOQVRTIG9wZXJhdGUp PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBz dHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8cHJl IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6IOWui+S9kzsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiIGNsYXNzPSIiPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyIgY2xhc3M9IiI+PG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9wcmU+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsiIGNsYXNzPSIiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Mi4g QSBzZW5kIOKAnFNlbmRJbmRpY2F0aWlvbuKAnSB0byBUVVJOIFNlcnZlciwgVFVSTiBTZXJ2ZXIg c2VuZCBVRFAgcGFja2V0IHRvIEIsIHVzaW5nIEHigJlzIFJlbGF5IEFkZHJlc3MoUkEpIGFzIHRo ZSBzb3VyY2UgYWRkcmVzcy48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsiIGNsYXNzPSIiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsiIGNsYXNz PSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xh c3M9IiI+My4gQiB3aWxsIHNlbmQgcmVzcG9uc2UgVURQIHBhY2tldCB0byBUVVJOIFNlcnZlcjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyIgY2xhc3M9IiI+77yMPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPnVzZQ0KIFJBIGFzIHRoZSBkZXN0aW5hdGlvbiBhZGRy ZXNzLiBXaGVuIG9uZSBFRE0gTkFUIGxpZXMgYmV0d2VlbiB0aGUgVFVSTiBzZXJ2ZXIgYW5kIGhv c3QgQiwgVFVSTiBTZXJ2ZXIgd2lsbCBzZWUgdGhpcyByZXNwb25zZSBVRFAgcGFja2V0IGNvbWUg ZnJvbSBvbmUgbmV3IHJlZmxleCBhZGRyZXNzKHdlIGNhbGwgWELigJkpLCBub3QgdGhlIHJlZmxl eCBhZGRyZXNzKHdlIGNhbGwgWEIpIHdoZW4gQiBzZW5kIGJpbmRpbmcgcmVxdWVzdCB0byBUVVJO IFNlcnZlcuKAmXMNCiB3ZWxsLWtub3duIGFkZHJlc3MuPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCllvdSBhcmUgZm9yZ2V0dGluZyB0aGF0IGFzIHBhcnQgb2Yg SUNFIEIgd2lsbCBhbHNvIHNlbmQgYSBjb25uZWN0aXZpdHkgY2hlY2sgdG93YXJkcyBSQS4gVGhp cyBzaG91bGQgb3BlbiB1cCB0aGUgcGluaG9sZSBpbiBFRE0gTkFUIDIuJm5ic3A7PC9kaXY+DQo8 ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRT ZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IiBj bGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi IGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiDl rovkvZM7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiIGNsYXNzPSIiPjQuIFNvLCBpZiB0aGUgSVAgYWRkcmVzcyBwb3J0aW9uIG9mIFhC 4oCZIGlzIHNhbWUgYXMgdGhhdCBvZiBYQiwgdGhpcyBwYWNrZXQgd2lsbCBiZSByZWxheWVkIGJ5 IFRVUk4gU2VydmVyOyBpZiBub3QsIHRoaXMgcGFja2V0IHdpbGwgZHJvcHBlZCBieQ0KIFRVUk4g U2VydmVyLiBUaGlzIHdpbGwgbGVhZCB0byB0aGUgY29tbXVuaWNhdGlvbiBmYWlsdXJlIGJldHdl ZW4gQSBhbmQgQi48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog 5a6L5L2TOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTog MTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IOWui+S9 kzsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyIgY2xhc3M9IiI+SG93IGRvIHlvdSB0aGluayBhYm91dCB0aGlzIHNjZW5hcmlvcz88L3Nw YW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXY+SUNFIHdpbGwgZml4IHRoaXMuIFJlbWVtYmVyIEEgYW5kIEIgaGF2 ZSBleGNoYW5nZWQgYWxsIGNhbmRpZGF0ZXMgYW5kIGNyYXRlZCBhIHNpbWlsYXIgY2hlY2tsaXN0 IHRoYXQgd2lsbCBydW4gc2ltdWx0YW5lb3VzbHkgZm9ybSBib3RoIHNpZGVzLiBTb21lIHBhY2tl dHMgd2lsbCBiZSBibG9ja2VkIGF0IHRoZSByZW1vdGUgTkFULCBidXQgdGhleSBzdGlsbCBoYXZl IG9wZW5lZCB1cCBhIHBpbmhvbGUgb24gdGhlIGxvY2FsIE5BVC4gU28NCiB3aXRoIHNvbWUgc3lu Y2hyb25pc2F0aW9uIGFuZCByZXRyYW5zbWl0cyBhbCB0aGUgbmVjZXNzYXJ5IHBvcnRzIHdpbGwg YmUgb3BlbmVkIHVwLiBJbiBJQ0UgdGhlcmUgaXMgYWxzbyB0aGUgY29uY2VwdCBvZiBwZWVyIFJG TFggYWRkcmVzc2VzIHRoYXQgdGhlIGFnZW50cyBsZWFybiB3aGVuIHRoZXkgZG8gdGhlIGNvbm5l Y3Rpdml0eSBjaGVja3MuIFVuZGVyc3RhbmRpbmcgaG93IHRob3NlIHdvcmsgaXMgcHJvYmFibHkg aW1wb3J0YW50IHRvIHVuZGVyc3RhbmQNCiBob3cgSUNFIHNvbHZlcyB5b3VyIGFib3ZlIHNjZW5h cmlvLiBBbHNvIGtlZXAgaW4gbWluZCB0aGF0IHRoZSBjb25uZWN0aXZpdHkgY2hlY2tzIGFsc28g YXJlIOKAnHR1bm5lbGxlZOKAnSB2aWEgdGhlIFRVUk4gc2VydmVyIGFuZCBhcHBlYXJzIHRvIGJl IHNlbnQgYnkgdGhlIFJFTEFZIGFkZHJlc3MuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdj5PciBpcyB5b3VyIGludGVudGlvbiB0byBmaXggdXAgVFVSTiBzbyBpdCBpcyBp bmRlcGVuZGVudCBvZiBJQ0UuIEluIHRoYXQgY2FzZSBpdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0 byBoZWFyIG1vcmUgYWJvdXQgeW91ciB1c2UgY2FzZSBhbmQgbW90aXZhdGlvbiBmb3IgZG9pbmcg dGhhdC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pi4tLjwv ZGl2Pg0KPGRpdj5Qw6VsLUVyaWs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6IOWui+S9kzsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1s ZWZ0LWNvbG9yOiBibHVlOyBib3JkZXItbGVmdC13aWR0aDogMS41cHQ7IHBhZGRpbmc6IDBjbSAw Y20gMGNtIDRwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImJvcmRl ci1zdHlsZTogc29saWQgbm9uZSBub25lOyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMTgxLCAxOTYs IDIyMyk7IGJvcmRlci10b3Atd2lkdGg6IDFwdDsgcGFkZGluZzogM3B0IDBjbSAwY207IiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTog5a6L5L2TOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5QYWwgTWFydGluc2VuDQogKHBhbG1hcnRpKSBbPGEgaHJlZj0ibWFpbHRvOnBhbG1hcnRpQGNp c2NvLmNvbSIgY2xhc3M9IiI+bWFpbHRvOnBhbG1hcnRpQGNpc2NvLmNvbTwvYT5dPHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5UaHVyc2RheSwgRmVicnVhcnkgMDUsIDIwMTUgNTo0NCBQTTxiciBjbGFzcz0i Ij4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+QWlqdW4gV2FuZzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkNjOjwv Yj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+T2xlZyBN b3NrYWxlbmtvOyBCcmFuZG9uIFdpbGxpYW1zOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkp Ow0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIGNsYXNzPSIiPnRyYW1AaWV0Zi5vcmc8 L2E+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbdHJhbV0gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDEudHh0PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+ PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IiBjbGFzcz0iIj4NCjxz cGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 IOWui+S9kzsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPk9rLCBJIHdp bGwgdHJ5IHRvIGV4cGxhaW4uIFdvdWxkIGJlIG5pY2UgaWYgc29tZSBvdGhlcnMgJm5ic3A7b24g dGhlIGxpc3QgY2FuIHZlcmlmeSB3aGF0IEkgc2F5IGlzIGNvcnJlY3QuPG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IiBj bGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5l LWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJy IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w b3J0YW50OyIgY2xhc3M9IiI+dHJhbQ0KIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBj bGFzcz0iIj48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgY2xhc3M9IiI+dHJhbUBpZXRm Lm9yZzwvYT48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_438D157186AF4E48B6062191348617CEciscocom_-- From nobody Mon Feb 9 05:34:37 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3BE1A0318 for ; Mon, 9 Feb 2015 05:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 i_jEv1iCkBnb for ; Mon, 9 Feb 2015 05:33:59 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450361A0161 for ; Mon, 9 Feb 2015 05:33:59 -0800 (PST) Received: by lams18 with SMTP id s18so7420425lam.11 for ; Mon, 09 Feb 2015 05:33:57 -0800 (PST) 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=c5v3lBm5S4feFH24TMOZrDQQpvJuihqKMvmNyeIeNxo=; b=SKgzWjJ6xvbZQv5KNQjBnp5LcF8bgvTadA72IpySrPNTMUAOd8Pmb76ZyPt5YFRm/C hwiNxHnxzPjoD5QSo1CYkPnTIcz7cZQXp87IseLDbXzs2v4J+CMZNHdb4hEgfXXAtrRW 934D+LHpV1O3dmjHvk7KGAzGszqv57uRxAml1w4O1fw1hCwB0KP7FNF0+SKaUN3nRFxO oEzCNlbDkgePcX/tosGEtaYYEaXVQyJ472yeoox3OZyoZurVJGb7cIx6sFdSPI+WTL8P 4rhkqv5+lbtzo1CKrcB4MojhLvv0T5Uy8YT9SaeS+K/YCMheX/Y4kolDdmWxYzhfbcEQ 6TeQ== X-Gm-Message-State: ALoCoQkL07j1kXYMx616WIxDf/c9IQ6zAw1oeAfTIMmSPrsqsfWQq8oZiwmJGr3fUYQymq2phUeC MIME-Version: 1.0 X-Received: by 10.112.155.168 with SMTP id vx8mr6589218lbb.110.1423488837728; Mon, 09 Feb 2015 05:33:57 -0800 (PST) Received: by 10.25.205.135 with HTTP; Mon, 9 Feb 2015 05:33:57 -0800 (PST) In-Reply-To: <000c01d0440b$483c1310$d8b43930$@org.cn> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <000001d03f8a$010c89a0$03259ce0$@org.cn> <007401d04024$0ee0d3c0$2ca27b40$@org.cn> <37F58EB6-2CAE-4CA5-B286-D622DC33B139@cisco.com> <00ed01d04110$1ca32340$55e969c0$@org.cn> <5F8B3F40-2232-4827-8904-2562CF447497@cisco.com> <000c01d0440b$483c1310$d8b43930$@org.cn> Date: Mon, 9 Feb 2015 06:33:57 -0700 Message-ID: From: Simon Perreault To: Aijun Wang Content-Type: multipart/alternative; boundary=089e01176fa183d94f050ea7d2aa Archived-At: Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , Oleg Moskalenko , "Tirumaleswar Reddy \(tireddy\)" , Brandon Williams Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 09 Feb 2015 13:34:01 -0000 --089e01176fa183d94f050ea7d2aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To expand upon Pal's excellent answers (you should be thankful for his patience!)... On Sun, Feb 8, 2015 at 6:54 PM, Aijun Wang wrote: > > Why doesn=E2=80=99t the permission consider the Port value of XOR-PEER-AD= DRESS? > When the CGN(Carrier Grade NAT) are deployed by the service provider, man= y > hosts may share one public addresses. Then in such environment, the clien= t > is prone to be attacked by hosts that under the same CGN coverage? > Correct. > The TURN server will also relay many traffic that is not the client=E2=80= =99s > desirable data. > Yes if the client is "under attack". No in normal circumstances. Also in such situation, even with the cooperation of TURN and ICE, there > will likely be failure for the communication between two hosts, lets=E2= =80=99 > consider the following diagram: > > A---------EDM NAT 1-------------TURN Server--------EDM NAT > 2(CGN)------------------------B > > > > 1. Let=E2=80=99s suppose A=E3=80=81B Send ICE packet to each other and pu= nch hole in the EDM NAT 1 and EDM NAT 2(this process should be added in cur= rent draft http://tools.ietf.org/html/draft-ietf-tram-turnbis-02#section-10= .2) > > 2. A send =E2=80=9CSendIndicatiion=E2=80=9D to TURN Server, TURN Server s= end UDP packet to > B, using A=E2=80=99s Relay Address(RA) as the source address. > > 3. B will send response UDP packet to TURN Server=EF=BC=8Cuse RA as the > destination address. When one EDM NAT lies between the TURN server and ho= st > B, TURN Server will see this response UDP packet come from one new reflex > address(we call XB=E2=80=99), not the reflex address(we call XB) when B s= end > binding request to TURN Server=E2=80=99s well-known address. > 4. So, if the IP address portion of XB=E2=80=99 is same as that of XB, this= packet > will be relayed by TURN Server; if not, this packet will dropped by TURN > Server. This will lead to the communication failure between A and B. > > > > How do you think about this scenarios? > It is well known that using a single TURN server may not always work for NATs that have arbitrary IP address pooling behaviour (see REQ-2 in RFC 4787). In that case it is necessary that two TURN servers be used. This was a deliberate design decision favouring simplicity over completeness. Simon --089e01176fa183d94f050ea7d2aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To expand upon Pal's excell= ent answers (you should be thankful for his patience!)...

On Sun, Feb 8, 2015 at 6:54= PM, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:

Why doesn=E2=80=99t the permission consider the Port val= ue of XOR-PEER-ADDRESS? When the CGN(Carrier Grade NAT) are deployed by the= service provider, many hosts may share one public addresses. Then in such = environment, the client is prone to be attacked by hosts that under the sam= e CGN coverage?


Correct.
=C2=A0

The TURN server will also relay many t= raffic that is not the client=E2=80=99s =C2=A0desirable data.


Yes if the client is "under attack"= . No in normal circumstances.

Also= in such situation, even with the cooperation of TURN and ICE, there will l= ikely be failure for the communication between two hosts, lets=E2=80=99 con= sider the following diagram:

A---------EDM NAT 1------------= -TURN Server--------EDM NAT 2(CGN)------------------------B

<= u>=C2=A0

=E3=80=81B Send ICE=
 packet to each other and punch hole in the EDM NAT 1 and EDM NAT 2(this pr=
ocess should be added in current draft http://tools.i=
etf.org/html/draft-ietf-tram-turnbis-02#section-10.2)

2. A send =E2=80=9CSend= Indicatiion=E2=80=9D to TURN Server, TURN Server send UDP packet to B, usin= g A=E2=80=99s Relay Address(RA) as the source address.=

3. B w= ill send response UDP packet to TURN Server=EF=BC=8Cuse RA as the destination address. When one EDM NAT lies between the T= URN server and host B, TURN Server will see this response UDP packet come f= rom one new reflex address(we call XB=E2=80=99), not the reflex address(we = call XB) when B send binding request to TURN Server=E2=80=99s well-known ad= dress.

4. So, if= the IP address portion of XB=E2=80=99 is same as that of XB, this packet w= ill be relayed by TURN Server; if not, this packet will dropped by TURN Ser= ver. This will lead to the communication failure between A and B.=

=C2=A0

How do you think about this scenarios?

=

It is well known that using a single TURN server may= not always work for NATs that have arbitrary IP address pooling behaviour = (see REQ-2 in RFC 4787). In that case it is necessary that two TURN servers= be used. This was a deliberate design decision favouring simplicity over c= ompleteness.

Simon
--089e01176fa183d94f050ea7d2aa-- From nobody Mon Feb 9 07:03:28 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8811A040B for ; Mon, 9 Feb 2015 06:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 EoKwXDUX6J9K for ; Mon, 9 Feb 2015 06:45:49 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 791AE1A006F for ; Mon, 9 Feb 2015 06:45:49 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6DEF3476CB for ; Mon, 9 Feb 2015 14:45:48 +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 5BD6A476C8 for ; Mon, 9 Feb 2015 14:45:48 +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 4E6248005C for ; Mon, 9 Feb 2015 14:45:48 +0000 (GMT) Message-ID: <54D8C81C.20608@akamai.com> Date: Mon, 09 Feb 2015 09:45:48 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <1EA9BD83-A95A-427D-B007-6DADD43D998D@cisco.com> In-Reply-To: <1EA9BD83-A95A-427D-B007-6DADD43D998D@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-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: Mon, 09 Feb 2015 14:45:53 -0000 Sorry for the delayed feedback on this one. I've been having a little trouble thinking it through, mostly around the question of what type of guidance I think would be useful here. At this point, it's unclear to me whether the document should be giving any recommendations at all. But if not, then what purpose can it serve? I agree with Justin that any recommendations presented in the document should be clear and straight-forward. If they aren't, then they will be difficult for an implementor to apply and end up being meaningless. That said, for a couple of reasons, I'm not certain that it's possible to put forward a strong and clear set of recommendations for server selection. First, I think such recommendations could quickly go out-of-date as new mechanisms are defined to extend the procol. For example, if this document had been written a couple of years ago, it might not have made reference to return, mobility, or DTLS. Second, I think the selection criteria could have different priorities for different users and/or applications, making the recommendations difficult to apply. For example, the goals of location privacy and performance could be in conflict, since a relay server more closely tied to the peer's network geographic location will often provide better performance. The same could be said for any capability not directly related to the relay function, since it any limitation on the candidate set for relay selection could result in added latency. If it's not possible to give implementable recommendations that will have ongoing relevance, then what's the purpose of the document at all? One possibility is that it could be used to provide guidance for authors of other drafts, helping them to identify important areas of discussion relevant to new TURN mechanisms and their impact on server selection. This would also help reviewers to remember to ask important questions (e.g. "does this draft discuss the impact on location privacy?"). I've got some comment on the specifics of the draft too, but I'm not sure how relevant they are until I'm more confident about the intended purpose/goals of the draft. --Brandon On 01/09/2015 11:28 AM, Gonzalo Salgueiro (gsalguei) wrote: > Thanks, Justin. We'll collect Brandon's feedback on the draft too and the authors will deliberate on text edits and produce a new version for your review. > > -G > > >> On Jan 8, 2015, at 5:34 PM, Justin Uberti wrote: >> >> At IETF 91, I promised to send feedback on this document, so here goes. >> >> Generally, I think many of the issues mentioned in this document are important, but the recommendations are confusing and possibly contradictory; a developer with little knowledge of TURN will have a hard time figuring out exactly what to do. Furthermore, many of the properties discussed in this document are dynamic, and should be handled by the ICE process, rather than in TURN server selection (for example, the notion of RTT as it relates to user experience). >> >> Therefore, I think this document should take a stronger stance and put forth explicit best practices for selection (as opposed to "things to consider"), for non-dynamic properties, and leave the decisions on dynamic properties to be resolved by ICE. >> >> For example, I think we should omit the text in Section 3 about what to do with non-working TURN servers, and measuring RTT. Same for Section 3.3, which also discusses RTT, and Section 3.4, which talks about multiple interfaces. This can all be handled by ICE. >> >> In addition, the sections on local config and location privacy are unnecessary when RETURN is used. When RETURN is used, the application can always use the app TURN server for location privacy, and the relationship between local TURN server and app TURN server is fully spelled out, so there is nothing for the application to decide on. >> >> This leaves only the Security, Authentication, and Mobility sections. >> >> For security, I think we can give some clear guidance on what applications should do. For security, I think the guidance should be to use only DTLS + TLS, if both are available, with fallback to UDP or TCP if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP fallback may be contraindicated, but at this point in time, DTLS deployment isn't widespread enough to truly recommend this. >> >> This relates to the Authentication section - but I think any failures to authenticate the server cert should cause the TURN allocation to fail. This is just like any other misconfiguration on the TURN server - there's no reason we should even allow use of TURN servers whose cert chains don't validate. So, this section could probably be removed. >> >> Lastly, the Mobility section says that if "all other parameters [are] equal", a TURN server with mobility should be used. Clearly, all other parameters will not be equal (e.g. RTT), and even if they were, the client has no way to know if a server is mobility-capable a priori. So I think this recommendation ought to be removed, or perhaps turned into some sort of recommendation for TURN server developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD support mobility, SHOULD support redirect), probably in a separate doc. >> >> These recommendations should reduce the size of this document and provide much clearer advice to app developers. >> _______________________________________________ >> 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 Feb 9 08:14:51 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857D41A8841 for ; Sat, 7 Feb 2015 13:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 DeWyfcODQHWi for ; Sat, 7 Feb 2015 13:20:56 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890691A8834 for ; Sat, 7 Feb 2015 13:20:56 -0800 (PST) Received: by iecrp18 with SMTP id rp18so2461451iec.7 for ; Sat, 07 Feb 2015 13:20:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5nZU7rOwxkM5SYbPcxP8ZtAACByb66ae6JvwCkEKHMM=; b=N0dr0p7ibyVlTebVR0oRwKDyvJPIhd5sXg/iEtj8zVddGS6NRga6kNg43GnvJvvjmP qRiYqo8OFimJG+95P31p8LaurRKwMtfLXsyG505PSAdv4nQtu+y2QykhqL8X6jjCCp7+ /3M9qYsuhtInHV8W9rZfevdN4PwcINZm0/AvDZxEBTQEKyb/ciVaHg7L1OPK5G/fku/a DsEes2hSO/qMLJCPEhG7B3k6RMtfCmb71d/aKIMUjvs11yskZ6q79XcaYo/lFMVOu/gC H5v2+G4nvQ4t+OxM70sZS4iRPxyDP8PdS982t9Eht4g7O/hV509aA1JoW9v/l0ao5QJa NlXw== X-Received: by 10.43.19.134 with SMTP id qk6mr15519638icb.29.1423344056062; Sat, 07 Feb 2015 13:20:56 -0800 (PST) Received: from [192.168.0.102] (dsl-173-206-36-51.tor.primus.ca. [173.206.36.51]) by mx.google.com with ESMTPSA id sd7sm2802004igb.20.2015.02.07.13.20.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Feb 2015 13:20:55 -0800 (PST) Message-ID: <54D681A1.3040405@gmail.com> Date: Sat, 07 Feb 2015 16:20:33 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "tram@ietf.org" References: <20150206011702.17303.16733.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35539EC2@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A35539EC2@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Mon, 09 Feb 2015 08:14:32 -0800 Cc: "Yaron Sheffer \(yaronf.ietf@gmail.com\)" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-09.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, 07 Feb 2015 21:20:59 -0000 Looks good. There is editorial work to be done, but I'll leave that to the RFC Ed. Tom Taylor On 05/02/2015 8:20 PM, Tirumaleswar Reddy (tireddy) wrote: > This revision addresses comments from Yaron and Tom. > > -Tiru > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Friday, February 06, 2015 6:47 AM >> To: i-d-announce@ietf.org >> Cc: tram@ietf.org >> Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-09.txt >> >> >> 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-09.txt >> Pages : 23 >> Date : 2015-02-05 >> >> 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 ensures >> 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-09 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-09 >> >> >> 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 > From nobody Mon Feb 9 08:51:44 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A901A1B42 for ; Mon, 9 Feb 2015 08:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 iRUOyE-M9smy for ; Mon, 9 Feb 2015 08:40:57 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id BCB8A1A1A72 for ; Mon, 9 Feb 2015 08:37:44 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BE213476DA for ; Mon, 9 Feb 2015 16:37:43 +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 A6ECE476C2 for ; Mon, 9 Feb 2015 16:37:43 +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 A3BAF204E for ; Mon, 9 Feb 2015 16:37:43 +0000 (GMT) Message-ID: <54D8E257.9000300@akamai.com> Date: Mon, 09 Feb 2015 11:37:43 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tram] location privacy considerations for TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 16:41:00 -0000 Hi all, There has been recent discussion about location privacy on the list. One approach to location privacy has been to select a relay server that will not give away important location information, but one key issue has been how to determine whether an allocated relay address meets the peer's location privacy requirements. If such a relay server can be identified, then the location privacy requirements can be met, but this could sacrifice the user's performance expectations. We have been working on some ideas about how to address these privacy concerns by adding a new channel binding mechanism to TURN that does not require a peer to know even the relay address of the remote peer. Before I try to engage the WG on a possible solution, I first want to get some sense of whether I'm on target in the way that I'm framing the problem (location privacy vs. performance). I've included a rough cut of the problem statement below (this seemed better than publishing a draft just for the one page of content) and will appreciate feedback from the list. Have I clearly stated the problem? Are there other ways in which location privacy could negatively impact performance? And is anyone else interested in trying to solve this problem within the WG? Thanks, --Brandon ----- 1. Introduction Traversal Using Relay around NAT (TURN) [RFC5766] defines a mechanism for establishment of peer-to-peer communication using a data relay server. Although not part of the explicit intent of the protocol, a TURN relay can also be used in a way that provides enhanced privacy by hiding the network geographic location of one or both peers from the other peer. However, location privacy considerations can have a negative impact on latency, both during call setup and throughout the life of the session. 1.1. Location Privacy During Session Initiation Peer-to-peer session initiation typically involves relay of an invitation via a rendezvous server. The initiating peer sends an invitation to the rendezvous server, which relays the invitation to the receiving peer for acceptance. Although the rendezvous server's role requires it to maintain a registry of peer addresses, location privacy demands that it should not send the receiving peer's address to the initiating peer until the receiving peer has accepted the call. When direct connectivity between the peers is possible, Interactive Connectivity Establishment (ICE) [RFC5245] connectivity checks can proceed and complete successfully as soon as the receiving peer has received the invitation, since the initiating peer's host and reflexive addresses can be delivered to the receiving peer along with the invitation. However, when the initiating peer requires a TURN relay, the receiving peer's address information must be delivered via the rendezvous server with the invitation response in order for the initiating peer to send a ChannelBind or CreatePermission request. Since the rendezvous server is often centrally located, even one-way latency between the peers via the rendezvous server can be significantly longer than the latency for direct connectivity, meaning that initiation of successful peer-to-peer communication can take significantly longer when a TURN relay is used, even if the relay server is optimally selected for end-to-end performance. 1.2. Location Privacy and Call Quality Many peer-to-peer applications (e.g. voice or video calls) are sensitive to path latency, with long one-way latencies often leading to a negative impact on user experience. For this reason, it can be important to select a relay server that is on-path between the peers in order to prevent use of the relay from negatively impacting latency. Achieving this goal can mean selecting the relay based on its relative proximity to the associated peer. For this reason, the relay address itself could provide information about the location of the peer. In other words, a user who wishes not to disclose her/his current location to the remote peer might have to intentionally select a TURN relay that is suboptimal for performance. ----- -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Feb 9 10:11:23 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEF11A1EE8 for ; Mon, 9 Feb 2015 10:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6d-raCh4-Q0 for ; Mon, 9 Feb 2015 10:10:43 -0800 (PST) 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 959471A1BF9 for ; Mon, 9 Feb 2015 10:10:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18580; q=dns/txt; s=iport; t=1423505443; x=1424715043; h=from:to:cc:subject:date:message-id:mime-version; bh=QuvudCUmLBXvjV9/28M7BCAbDne+4O1P92aeOvwibak=; b=I4QJELk7QKY6rDgeoHPUzhKESqhcW9L9JVrXZuZkhPySQs4m+BBcfNzD jcSkSJFDvmDI4/2stgg/gfOjxfPs4Td7JRaExOtZlKNisgOougnFEm1md 9K2NEqb6n8emmAcL81A88RrxXcKdwNEb+6jl8+5kbAIhdrhmqP0SDP3Tb A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFAKr32FStJV2Q/2dsb2JhbABcgkNDUloEgn69UYIcAQmFcQIcf0MBAQEBAQF8hAwBAQEEAQEBIApBCQISAQgOAwQBAQsdAwIEJQsUCAEJAQQOBQiIJQ2yLZYXAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPRy0EBoJpLoEUBY8bnBwigjKBPG+BRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,545,1418083200"; d="scan'208,217";a="394695344" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP; 09 Feb 2015 18:10:42 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t19IAgdZ023070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Feb 2015 18:10:42 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.155]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 9 Feb 2015 12:10:42 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Benjamin Schwartz Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt Thread-Index: AdBEk7LOugc8dKgRQ2ynrYYRppNRKg== Date: Mon, 9 Feb 2015 18:10:41 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35548A91@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.35.179] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35548A91xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Simon Perreault , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 18:10:47 -0000 --_000_913383AAA69FF945B8F946018B75898A35548A91xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUjJdDQoNCkZyb206IEJlbmphbWluIFNjaHdhcnR6IFttYWlsdG86YmVtYXNjQHdl YnJ0Yy5vcmddDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA2LCAyMDE1IDk6NDkgUE0NClRvOiBU aXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpDYzogSnVzdGluIFViZXJ0aTsgdHJhbUBpZXRm Lm9yZzsgU2ltb24gUGVycmVhdWx0DQpTdWJqZWN0OiBSRTogW3RyYW1dIEZXOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5LXRyYW0tdHVybi1pcGFkZHJlc3MtcHJpdmFj eS0wMC50eHQNCg0KDQpJIGFwcHJlY2lhdGUgdGhlIGdvYWwgb2YgdGhpcyB3b3JrLiAgTWF5YmUg YSBzbGlnaHRseSBkaWZmZXJlbnQgc3RyYXRlZ3kgd291bGQgYmUgbW9yZSBlYXNpbHkgYWNjZXB0 ZWQgaW4gdGhlIHdvcmtpbmcgZ3JvdXAuICBXaGF0IGlmIHRoZSBjbGllbnQgY291bGQgcXVlcnkg dGhlIHNlcnZlciBmb3IgYSBsaXN0IG9mIGFsdGVybmF0ZSBUVVJOIHNlcnZlcnM/ICBUaGVuIHRo ZSBjbGllbnQgY291bGQgaGF2ZSB0aGUgb3B0aW9uIG9mIHNlbGVjdGluZyBhIHNlcnZlciBiYXNl ZCBvbiBnZW9sb2NhdGlvbiwgYnV0IHRoZSBjbGllbnQgd291bGQgbm90IGhhdmUgdG8gY29udmV5 IGl0cyBwcml2YWN5IGdvYWxzIHRvIHRoZSBzZXJ2ZXIgZXhwbGljaXRseS4NCg0KW1RSMl0gSW50 ZXJlc3RpbmcgYWx0ZXJuYXRpdmUsIGl0IGhhcyBwcm9zIGFuZCBjb25zIHRoYXQgY2xpZW50IHdp bGwgbm90IGhhdmUgdG8gY29udmV5IGl0cyBwcml2YWN5IGdvYWxzIHRvIHNlcnZlciBleHBsaWNp dGx5IGJ1dCBpZiBpdCByZWNlaXZlcyBOTk4gbnVtYmVyIG9mIGFsdGVybmF0ZSBzZXJ2ZXJzIGl0 IHdpbGwgaGF2ZSB0byB0cnkgYWxsIG9mIHRoZW0gYW5kIHBpY2sgdGhlIG9uZSB3aGljaCBzdWl0 ZXMgaXRzIHByaXZhY3kgbmVlZHMgKFRVUk4gc2VydmVyIGNhbiBwcm9iYWJseSBnaXZlIGFkZGl0 aW9uYWwgaW5mb3JtYXRpb24gb24gdGhlIHByaXZhY3kgbGV2ZWxzIHRoYXQgY2FuIGJlIHByb3Zp ZGVkIGJ5IGVhY2ggb2YgdGhlIGFsdGVybmF0ZSBzZXJ2ZXJzIHRvIGFkZHJlc3MgdGhpcyBwcm9i bGVtKQ0KDQotVGlydQ0KSW5saW5lIFtUUl0NCg0KRnJvbTogSnVzdGluIFViZXJ0aSBbbWFpbHRv Omp1YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPl0NClNlbnQ6IEZy aWRheSwgRmVicnVhcnkgMDYsIDIwMTUgNjoyMSBBTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSkNCkNjOiBCZW5qYW1pbiBTY2h3YXJ0ejsgU2ltb24gUGVycmVhdWx0OyB0cmFtQGll dGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0cmFtXSBGVzogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNz LXByaXZhY3ktMDAudHh0DQoNCkkgYWdyZWUgd2l0aCBTaW1vbiBhbmQgQmVuIGluIGJlaW5nIHNr ZXB0aWNhbCBhYm91dCB0aGlzIHByb3Bvc2FsLg0KDQpUaGUgY2xpZW50IGlzIHRoZSBvbmx5IHBh cnR5IHdoaWNoIGtub3dzIGV4YWN0bHkgd2hhdCAncHJpdmFjeScgbWVhbnMsIGFuZCB0aGVyZSBp cyBubyB0cml2aWFsIHdheSB0byBzZXJpYWxpemUgdGhpcyBpbnRvIGEgc2luZ2xlIGF0dHJpYnV0 ZSBmb3IgdGhlIFRVUk4gc2VydmVyLg0KDQpbVFJdIFdlIGFyZSBldmFsdWF0aW5nIGhvdyB0aGUg Y2xpZW50IGNhbiBjb3ZleSBpdHMg4oCYcHJpdmFjeeKAmSBuZWVkcyBpbiB0aGlzIG5ldyBhdHRy aWJ1dGUgdG8gdGhlIFRVUk4gc2VydmVyIHNvIHRoYXQgaXQgY2FuIHRha2UgYXBwcm9wcmlhdGUg YWN0aW9uIGFuZCB0aGUgc2VydmVyIHJlc3BvbmRzIGlmIHRoZSBjbGllbnQg4oCYcHJpdmFjeeKA mSByZXF1aXJlbWVudCBjYW4gYmUgbWV0IGZ1bGx5IG9yIHBhcnRpYWxseS4NCg0KLVRpcnUNCg0K QXMgc3VjaCwgSSB0aGluayB0aGlzIGRlY2lzaW9uIHNob3VsZCBiZSBsZWZ0IGVudGlyZWx5IHRv IHRoZSBjbGllbnQuDQoNCk9uIFdlZCwgRmViIDQsIDIwMTUgYXQgMTA6NTAgQU0sIFRpcnVtYWxl c3dhciBSZWRkeSAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNp c2NvLmNvbT4+IHdyb3RlOg0KSSBhZ3JlZSB0aGF0IHRoZSBjbGllbnQgY2FuIGRvIGVxdWFsbHkg d2VsbCBpdHNlbGYsIGJ5IHNlbmRpbmcgYSBTVFVOIEJpbmRpbmcgUmVxdWVzdCBhbmQgY29tcGFy aW5nIHRoZSByZXNwb25zZSB0byB0aGUgVFVSTiBzZXJ2ZXIncyBvd24gSVAgYWRkcmVzcy4NCg0K W1RSM10gVGhlIGRpZmZlcmVuY2UgdGhpcyBkcmFmdCBicmluZ3MgaW4gaXMgdGhhdCBpdCBoZWxw cyB0aGUgVFVSTiBzZXJ2ZXIgKG9mZmVyZWQgYnkgYSBnbG9iYWwgb3IgY2xvdWQgc2VydmljZSkg dG8gZGV0ZXJtaW5lIHRoYXQgdGhlIGNsaWVudCB3YW50cyBwcml2YWN5IGFuZCBsZXZlbCBvZiBw cml2YWN5IHJlcXVpcmVkIGNvbnZleWVkIGluIHRoZSBuZXcgU1RVTiBhdHRyaWJ1dGUsIHRoZSBU VVJOIHNlcnZlciBkZXRlcm1pbmVzIHN1aXRhYmxlIGFsdGVybmF0ZSBUVVJOIHNlcnZlciB0aGF0 IGNhbiBvZmZlciB0aGUgcmVxdWlyZWQgbGV2ZWwgb2YgcHJpdmFjeS4NCg0KLVRpcnUNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGlu ZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg== --_000_913383AAA69FF945B8F946018B75898A35548A91xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbmxpbmUgW1RSMl08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQmVuamFtaW4gU2Nod2Fy dHogW21haWx0bzpiZW1hc2NAd2VicnRjLm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks IEZlYnJ1YXJ5IDA2LCAyMDE1IDk6NDkgUE08YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBS ZWRkeSAodGlyZWRkeSk8YnI+DQo8Yj5DYzo8L2I+IEp1c3RpbiBVYmVydGk7IHRyYW1AaWV0Zi5v cmc7IFNpbW9uIFBlcnJlYXVsdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3RyYW1dIEZXOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5LXRyYW0tdHVybi1pcGFkZHJl c3MtcHJpdmFjeS0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5JIGFwcHJlY2lh dGUgdGhlIGdvYWwgb2YgdGhpcyB3b3JrLiZuYnNwOyBNYXliZSBhIHNsaWdodGx5IGRpZmZlcmVu dCBzdHJhdGVneSB3b3VsZCBiZSBtb3JlIGVhc2lseSBhY2NlcHRlZCBpbiB0aGUgd29ya2luZyBn cm91cC4mbmJzcDsgV2hhdCBpZiB0aGUgY2xpZW50IGNvdWxkIHF1ZXJ5IHRoZSBzZXJ2ZXIgZm9y IGEgbGlzdCBvZiBhbHRlcm5hdGUgVFVSTiBzZXJ2ZXJzPyZuYnNwOyBUaGVuIHRoZSBjbGllbnQg Y291bGQgaGF2ZSB0aGUgb3B0aW9uIG9mIHNlbGVjdGluZw0KIGEgc2VydmVyIGJhc2VkIG9uIGdl b2xvY2F0aW9uLCBidXQgdGhlIGNsaWVudCB3b3VsZCBub3QgaGF2ZSB0byBjb252ZXkgaXRzIHBy aXZhY3kgZ29hbHMgdG8gdGhlIHNlcnZlciBleHBsaWNpdGx5LjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUjJdIEludGVyZXN0 aW5nIGFsdGVybmF0aXZlLCBpdCBoYXMgcHJvcyBhbmQgY29ucyB0aGF0IGNsaWVudCB3aWxsIG5v dCBoYXZlIHRvIGNvbnZleSBpdHMgcHJpdmFjeSBnb2FscyB0byBzZXJ2ZXIgZXhwbGljaXRseSBi dXQgaWYgaXQgcmVjZWl2ZXMgTk5OIG51bWJlciBvZiBhbHRlcm5hdGUgc2VydmVycw0KIGl0IHdp bGwgaGF2ZSB0byB0cnkgYWxsIG9mIHRoZW0gYW5kIHBpY2sgdGhlIG9uZSB3aGljaCBzdWl0ZXMg aXRzIHByaXZhY3kgbmVlZHMgKFRVUk4gc2VydmVyIGNhbiBwcm9iYWJseSBnaXZlIGFkZGl0aW9u YWwgaW5mb3JtYXRpb24gb24gdGhlIHByaXZhY3kgbGV2ZWxzIHRoYXQgY2FuIGJlIHByb3ZpZGVk IGJ5IGVhY2ggb2YgdGhlIGFsdGVybmF0ZSBzZXJ2ZXJzIHRvIGFkZHJlc3MgdGhpcyBwcm9ibGVt KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklu bGluZSBbVFJdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBKdXN0aW4gVWJlcnRpIFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdv b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+anVi ZXJ0aUBnb29nbGUuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0K PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMDYsIDIwMTUgNjoyMSBBTTxicj4N CjxiPlRvOjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCjxiPkNjOjwvYj4g QmVuamFtaW4gU2Nod2FydHo7IFNpbW9uIFBlcnJlYXVsdDsgPC9zcGFuPjxhIGhyZWY9Im1haWx0 bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDAudHh0PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J IGFncmVlIHdpdGggU2ltb24gYW5kIEJlbiBpbiBiZWluZyBza2VwdGljYWwgYWJvdXQgdGhpcyBw cm9wb3NhbC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5UaGUgY2xpZW50IGlzIHRoZSBvbmx5IHBhcnR5IHdoaWNoIGtub3dzIGV4YWN0bHkgd2hhdCAn cHJpdmFjeScgbWVhbnMsIGFuZCB0aGVyZSBpcyBubyB0cml2aWFsIHdheSB0byBzZXJpYWxpemUg dGhpcyBpbnRvIGEgc2luZ2xlIGF0dHJpYnV0ZSBmb3IgdGhlIFRVUk4gc2VydmVyLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ W1RSXSBXZSBhcmUgZXZhbHVhdGluZyBob3cgdGhlIGNsaWVudCBjYW4gY292ZXkgaXRzIOKAmHBy aXZhY3nigJkgbmVlZHMgaW4gdGhpcyBuZXcgYXR0cmlidXRlIHRvIHRoZQ0KIFRVUk4gc2VydmVy IHNvIHRoYXQgaXQgY2FuIHRha2UgYXBwcm9wcmlhdGUgYWN0aW9uIGFuZCB0aGUgc2VydmVyIHJl c3BvbmRzIGlmIHRoZSBjbGllbnQg4oCYcHJpdmFjeeKAmSByZXF1aXJlbWVudCBjYW4gYmUgbWV0 IGZ1bGx5IG9yIHBhcnRpYWxseS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIHN1Y2gs IEkgdGhpbmsgdGhpcyBkZWNpc2lvbiBzaG91bGQgYmUgbGVmdCBlbnRpcmVseSB0byB0aGUgY2xp ZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gV2VkLCBGZWIgNCwgMjAxNSBhdCAxMDo1MCBBTSwgVGlydW1hbGVzd2FyIFJlZGR5 ICh0aXJlZGR5KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIiB0YXJnZXQ9 Il9ibGFuayI+dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFncmVlIHRoYXQgdGhlIGNs aWVudCBjYW4gZG8gZXF1YWxseSB3ZWxsIGl0c2VsZiwgYnkgc2VuZGluZyBhIFNUVU4gQmluZGlu ZyBSZXF1ZXN0IGFuZCBjb21wYXJpbmcgdGhlIHJlc3BvbnNlIHRvIHRoZSBUVVJOIHNlcnZlcidz IG93biBJUCBhZGRyZXNzLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFIzXSBUaGUgZGlmZmVyZW5jZSB0aGlz IGRyYWZ0IGJyaW5ncyBpbiBpcyB0aGF0IGl0IGhlbHBzIHRoZSBUVVJOIHNlcnZlciAob2ZmZXJl ZCBieSBhIGdsb2JhbCBvcg0KIGNsb3VkIHNlcnZpY2UpIHRvIGRldGVybWluZSB0aGF0IHRoZSBj bGllbnQgd2FudHMgcHJpdmFjeSBhbmQgbGV2ZWwgb2YgcHJpdmFjeSByZXF1aXJlZCBjb252ZXll ZCBpbiB0aGUgbmV3IFNUVU4gYXR0cmlidXRlLCB0aGUgVFVSTiBzZXJ2ZXIgZGV0ZXJtaW5lcyBz dWl0YWJsZSBhbHRlcm5hdGUgVFVSTiBzZXJ2ZXIgdGhhdCBjYW4gb2ZmZXIgdGhlIHJlcXVpcmVk IGxldmVsIG9mIHByaXZhY3kuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRy YW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90cmFtPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A35548A91xmbrcdx10ciscoc_-- From nobody Mon Feb 9 11:56:51 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCF61A8792 for ; Mon, 9 Feb 2015 11:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 ykimYZX_sprA for ; Mon, 9 Feb 2015 11:24:27 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2B31A878E for ; Mon, 9 Feb 2015 11:24:26 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4CBE5476D8 for ; Mon, 9 Feb 2015 19:24:26 +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 36EAB476D5 for ; Mon, 9 Feb 2015 19:24:26 +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 331882044 for ; Mon, 9 Feb 2015 19:24:26 +0000 (GMT) Message-ID: <54D9096A.1000804@akamai.com> Date: Mon, 09 Feb 2015 14:24:26 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <913383AAA69FF945B8F946018B75898A35548A91@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A35548A91@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 19:24:30 -0000 I'm not sure that the "return NNN" approach can address the issue anyway. If you take the case of a broadly distributed system (e.g. a single system with several hundred POPs, for example), how will it decide which "NNN" alternates to provide? If I have 3 reasonable relay servers for your location and you want 3 alternates, should I intentionally not return the 3 reasonable ones? If the only purpose of this method is privacy, then the server could pick a set of alternates that is broadly distributed geographically. It could even indicate a score of some sort that tells the client how closely correlated each relay server is to the client address. But you still have the trust issue here. If the server returned a bad candidate set, did it do so because it didn't have options, or because it doesn't want to give you location privacy? And if the alternates are good, how will client select alternates over time to ensure that this selection doesn't give enough away about where the client isn't to allow you to figure out where the client is? If the client has to select the relay very carefully in order to ensure that it gets the privacy characteristics that it wants, then it's probably better to provide a server with a fixed location that never changes no matter where you're located. That way, you can always select the privacy relay when that's what you want and know that the relay's location will never say something useful about you all by itself. --Brandon On 02/09/2015 01:10 PM, Tirumaleswar Reddy (tireddy) wrote: > Inline [TR2] > > *From:*Benjamin Schwartz [mailto:bemasc@webrtc.org] > *Sent:* Friday, February 06, 2015 9:49 PM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* Justin Uberti; tram@ietf.org; Simon Perreault > *Subject:* RE: [tram] FW: New Version Notification for > draft-reddy-tram-turn-ipaddress-privacy-00.txt > > I appreciate the goal of this work. Maybe a slightly different strategy > would be more easily accepted in the working group. What if the client > could query the server for a list of alternate TURN servers? Then the > client could have the option of selecting a server based on geolocation, > but the client would not have to convey its privacy goals to the server > explicitly. > > [TR2] Interesting alternative, it has pros and cons that client will not > have to convey its privacy goals to server explicitly but if it receives > NNN number of alternate servers it will have to try all of them and pick > the one which suites its privacy needs (TURN server can probably give > additional information on the privacy levels that can be provided by > each of the alternate servers to address this problem) > > -Tiru > > Inline [TR] > > *From:*Justin Uberti [mailto:juberti@google.com > ] > *Sent:* Friday, February 06, 2015 6:21 AM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* Benjamin Schwartz; Simon Perreault; tram@ietf.org > > *Subject:* Re: [tram] FW: New Version Notification for > draft-reddy-tram-turn-ipaddress-privacy-00.txt > > I agree with Simon and Ben in being skeptical about this proposal. > > The client is the only party which knows exactly what 'privacy' means, > and there is no trivial way to serialize this into a single attribute > for the TURN server. > > [TR] We are evaluating how the client can covey its ‘privacy’ needs in > this new attribute to the TURN server so that it can take appropriate > action and the server responds if the client ‘privacy’ requirement can > be met fully or partially. > > -Tiru > > As such, I think this decision should be left entirely to the client. > > On Wed, Feb 4, 2015 at 10:50 AM, Tirumaleswar Reddy (tireddy) > > wrote: > > I agree that the client can do equally well itself, by sending a STUN > Binding Request and comparing the response to the TURN server's own IP > address. > > [TR3] The difference this draft brings in is that it helps the TURN > server (offered by a global or cloud service) to determine that the > client wants privacy and level of privacy required conveyed in the new > STUN attribute, the TURN server determines suitable alternate TURN > server that can offer the required level of privacy. > > -Tiru > > > _______________________________________________ > 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 Feb 9 11:59:50 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244731A878E; Mon, 9 Feb 2015 11:24:32 -0800 (PST) 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 KRO8EaUNWCv3; Mon, 9 Feb 2015 11:24:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B09FD1A1BA0; Mon, 9 Feb 2015 11:24:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209192429.7833.11921.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 11:24:29 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-11.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: Mon, 09 Feb 2015 19:24:32 -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-11.txt Pages : 22 Date : 2015-02-09 Abstract: This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised. 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-11 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 Mon Feb 9 12:01:13 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A931A1B9C for ; Mon, 9 Feb 2015 11:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7pYdNGVcTVx for ; Mon, 9 Feb 2015 11:27:55 -0800 (PST) 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 1394F1A8797 for ; Mon, 9 Feb 2015 11:27:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2235; q=dns/txt; s=iport; t=1423510070; x=1424719670; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RyGVwmYujDAkp6QZrtJezwsaDGK4yLxicaMdsggez4M=; b=ksGEaBufmPs0AaBMBZbDW6CPEdA2UWt62DAzZ2tSR8ClGoE2qwwRb9H9 Un7HxNadKTx74FRX5j9sU+I0UhiG0aBOfeEGhBW6yLw0+ri9TSqcHWGMC pEcDeYacsyCfjtqg5QO9PZzw4ZVXsbbveMExpc/+tD2OGBlK8SPqE9i7N E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B0BQDdCdlU/51dJa1cgwZSVQUEwFCCHAyFbwKBHUMBAQEBAQF8hAwBAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCQgCBBMIAYgkCAXIZgEBAQEBAQEBAQEBAQEBAQEBAQEBARePRzgGgxCBFAWPG4NQhnQ2gk2OVSKDbm+BBCQcfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,545,1418083200"; d="scan'208";a="394554450" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 09 Feb 2015 19:27:35 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t19JRZT0003290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Feb 2015 19:27:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.155]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 9 Feb 2015 13:27:35 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-11.txt Thread-Index: AQHQRJ4ZYGMMEBxJ30uZ9g2PK693n5zos28A Date: Mon, 9 Feb 2015 19:27:34 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3554906F@xmb-rcd-x10.cisco.com> References: <20150209192429.7833.11921.idtracker@ietfa.amsl.com> In-Reply-To: <20150209192429.7833.11921.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.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-11.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, 09 Feb 2015 19:27:58 -0000 This revision updates Appendix A based on the changes in using HKDF functio= n in section 4.1.1, thanks to Oleg for providing the sample data. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, February 10, 2015 12:54 AM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-11.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-11.txt > Pages : 22 > Date : 2015-02-09 >=20 > Abstract: > This document proposes the use of OAuth 2.0 to obtain and validate > ephemeral tokens that can be used for Session Traversal Utilities for > NAT (STUN) authentication. The usage of ephemeral tokens ensures > that access to a STUN server can be controlled even if the tokens are > compromised. >=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-11 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-third-party-authz= -11 >=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 Mon Feb 9 12:33:29 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E81A1A1BF3 for ; Mon, 9 Feb 2015 11:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.511 X-Spam-Level: X-Spam-Status: No, score=-16.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8IfI9vhGdaF for ; Mon, 9 Feb 2015 11:50:23 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FFCB1A1BCF for ; Mon, 9 Feb 2015 11:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5142; q=dns/txt; s=iport; t=1423511423; x=1424721023; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=gj68i4xeThhoepCugjNK9Wz8dRE0nfdi1BTnvAw0YOA=; b=PsNn+En85NJL6446cl/OxD0IY3wZTLIsXZipP4nraKwrbT0d/RdmS5mK bKi9lRnPyO2fU7bH8HGqSTAO89eKvyuD54YLPgH6zE0Q9GxBfuWnNZBCu Dh/XZbZtzMfgyeXryz4O7S6xii7uNzMbCgZsgYqS5QGU4N4rE5l6b3DV8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAPsO2VStJA2F/2dsb2JhbABcgwZSWgTAUIIcCoVxAoEeQwEBAQEBAXyEDAEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIEQKIEg3IeAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj0c4BoMQgRQFjxuFYZY7IoNub4ECBjx+AQEB X-IronPort-AV: E=Sophos;i="5.09,545,1418083200"; d="scan'208";a="394707482" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP; 09 Feb 2015 19:50:22 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t19JoM9m010804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Feb 2015 19:50:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.155]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 9 Feb 2015 13:50:22 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] location privacy considerations for TURN Thread-Index: AQHQRIcyHl0RlnzmqkSOwpOLhmIjmpzotbpQ Date: Mon, 9 Feb 2015 19:50:21 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A355490E9@xmb-rcd-x10.cisco.com> References: <54D8E257.9000300@akamai.com> In-Reply-To: <54D8E257.9000300@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.50.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] location privacy considerations for TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 19:50:28 -0000 Do you have any performance numbers to show the impact of the problem ? -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Monday, February 09, 2015 10:08 PM > To: tram@ietf.org > Subject: [tram] location privacy considerations for TURN >=20 > Hi all, >=20 > There has been recent discussion about location privacy on the list. One > approach to location privacy has been to select a relay server that will = not > give away important location information, but one key issue has been how = to > determine whether an allocated relay address meets the peer's location > privacy requirements. If such a relay server can be identified, then the > location privacy requirements can be met, but this could sacrifice the us= er's > performance expectations. >=20 > We have been working on some ideas about how to address these privacy > concerns by adding a new channel binding mechanism to TURN that does not > require a peer to know even the relay address of the remote peer. Before = I > try to engage the WG on a possible solution, I first want to get some sen= se of > whether I'm on target in the way that I'm framing the problem (location > privacy vs. performance). >=20 > I've included a rough cut of the problem statement below (this seemed > better than publishing a draft just for the one page of content) and will > appreciate feedback from the list. Have I clearly stated the problem? Are > there other ways in which location privacy could negatively impact > performance? And is anyone else interested in trying to solve this proble= m > within the WG? >=20 > Thanks, > --Brandon >=20 > ----- > 1. Introduction >=20 > Traversal Using Relay around NAT (TURN) [RFC5766] defines a mechanism > for establishment of peer-to-peer communication using a data relay > server. Although not part of the explicit intent of the protocol, a > TURN relay can also be used in a way that provides enhanced privacy > by hiding the network geographic location of one or both peers from > the other peer. However, location privacy considerations can have a > negative impact on latency, both during call setup and throughout the > life of the session. >=20 > 1.1. Location Privacy During Session Initiation >=20 > Peer-to-peer session initiation typically involves relay of an > invitation via a rendezvous server. The initiating peer sends an > invitation to the rendezvous server, which relays the invitation to > the receiving peer for acceptance. Although the rendezvous server's > role requires it to maintain a registry of peer addresses, location > privacy demands that it should not send the receiving peer's address > to the initiating peer until the receiving peer has accepted the > call. >=20 > When direct connectivity between the peers is possible, Interactive > Connectivity Establishment (ICE) [RFC5245] connectivity checks can > proceed and complete successfully as soon as the receiving peer has > received the invitation, since the initiating peer's host and > reflexive addresses can be delivered to the receiving peer along with > the invitation. However, when the initiating peer requires a TURN > relay, the receiving peer's address information must be delivered via > the rendezvous server with the invitation response in order for the > initiating peer to send a ChannelBind or CreatePermission request. >=20 > Since the rendezvous server is often centrally located, even one-way > latency between the peers via the rendezvous server can be > significantly longer than the latency for direct connectivity, > meaning that initiation of successful peer-to-peer communication can > take significantly longer when a TURN relay is used, even if the > relay server is optimally selected for end-to-end performance. >=20 > 1.2. Location Privacy and Call Quality >=20 > Many peer-to-peer applications (e.g. voice or video calls) are > sensitive to path latency, with long one-way latencies often leading > to a negative impact on user experience. For this reason, it can be > important to select a relay server that is on-path between the peers > in order to prevent use of the relay from negatively impacting > latency. Achieving this goal can mean selecting the relay based on > its relative proximity to the associated peer. For this reason, the > relay address itself could provide information about the location of > the peer. In other words, a user who wishes not to disclose her/his > current location to the remote peer might have to intentionally > select a TURN relay that is suboptimal for performance. > ----- >=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 Mon Feb 9 14:50:02 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5CA1A8A5F for ; Mon, 9 Feb 2015 14:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1Xqt7GVZ8K5C for ; Mon, 9 Feb 2015 14:32:21 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EEA71A8A57 for ; Mon, 9 Feb 2015 14:32:21 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so19756479igb.5 for ; Mon, 09 Feb 2015 14:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LsLGtZTi5anM4JL46UlFv16AYwDXdZRTbRXo9yox0Mk=; b=KCW9XN5PWBefGT/8ixWTi36OaqJznBnQkVxawM+WD/CkYRehUF/RYV3UqRqsXy50oC s/6E6KuUckc0Jqk3coq/fJ9zZY0hQHRHCu6Q6Jh7aJWtILHsPA1AVK5ZqgIOP6fO/Nnq l4A3nGC5X7ofDSeUH5RoqYPoUndonozYte0FT9kFAoGxRkU2wEMbnPzr0Z7Kqhh1LZpW 0FTW3Eq2vpP6d9AbpmBokuytddQ5Z7E4OCdO6fxIMkO6Svh8IoKvcLyGyNdf8wzGEM2S m8kzkEIwPzb0ZDeWhbkCFrIIoH+uw5Fco8aHqhX+vbZq3o9k91ne2QwjYUqYR60x7fBB yxLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LsLGtZTi5anM4JL46UlFv16AYwDXdZRTbRXo9yox0Mk=; b=UVQwHPJCV68AAVH+uQp/MtpsqwuR9sPFS+kRf+5/8mhmNsNY0TU5NuDPidUDOTWaH+ fLsKfB6tYvvfKI29buflr4f6T/n+OQ7JL4LSTZZnmh1d9HKoNb8/o7CTL4ba/bOFgHr4 q3k2XdDkTFXTrbg+FwTGYtCFisDMK7gI48POx3w/qlw/aJ7thK/pJr+jcMTxPm38cMZ9 tqBrn96l5j20A6qqg7TilUw9dv9qVu8h98nH1KJc2cUoLiKo7Nr2gYqHa4fzXCwvQDSM 9gyZlN0zdDYM2kHKdK16R0Y/NK4K3bOIYEL745cynSP+BVt9pDgVocykbT7JbhUwj3On kTWg== X-Gm-Message-State: ALoCoQnQxxIMqTj1d3JBglnnywDSo/xf7zCEv/8XSYGN6Evmgii3gfiZcryMdR1Nc0J6NdewDMmf X-Received: by 10.42.110.14 with SMTP id n14mr3962985icp.21.1423521140356; Mon, 09 Feb 2015 14:32:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.66 with HTTP; Mon, 9 Feb 2015 14:31:59 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A355490E9@xmb-rcd-x10.cisco.com> References: <54D8E257.9000300@akamai.com> <913383AAA69FF945B8F946018B75898A355490E9@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Mon, 9 Feb 2015 14:31:59 -0800 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=20cf303ea06ce6d228050eaf5740 Archived-At: Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] location privacy considerations for TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 22:32:24 -0000 --20cf303ea06ce6d228050eaf5740 Content-Type: text/plain; charset=UTF-8 I agree that these goals seem to be at odds with one another, so if you have a proposal to solve both simultaneously I think you are on the right track. On Mon, Feb 9, 2015 at 11:50 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Do you have any performance numbers to show the impact of the problem ? > > -Tiru > > > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > > Sent: Monday, February 09, 2015 10:08 PM > > To: tram@ietf.org > > Subject: [tram] location privacy considerations for TURN > > > > Hi all, > > > > There has been recent discussion about location privacy on the list. One > > approach to location privacy has been to select a relay server that will > not > > give away important location information, but one key issue has been how > to > > determine whether an allocated relay address meets the peer's location > > privacy requirements. If such a relay server can be identified, then the > > location privacy requirements can be met, but this could sacrifice the > user's > > performance expectations. > > > > We have been working on some ideas about how to address these privacy > > concerns by adding a new channel binding mechanism to TURN that does not > > require a peer to know even the relay address of the remote peer. Before > I > > try to engage the WG on a possible solution, I first want to get some > sense of > > whether I'm on target in the way that I'm framing the problem (location > > privacy vs. performance). > > > > I've included a rough cut of the problem statement below (this seemed > > better than publishing a draft just for the one page of content) and will > > appreciate feedback from the list. Have I clearly stated the problem? Are > > there other ways in which location privacy could negatively impact > > performance? And is anyone else interested in trying to solve this > problem > > within the WG? > > > > Thanks, > > --Brandon > > > > ----- > > 1. Introduction > > > > Traversal Using Relay around NAT (TURN) [RFC5766] defines a mechanism > > for establishment of peer-to-peer communication using a data relay > > server. Although not part of the explicit intent of the protocol, a > > TURN relay can also be used in a way that provides enhanced privacy > > by hiding the network geographic location of one or both peers from > > the other peer. However, location privacy considerations can have a > > negative impact on latency, both during call setup and throughout the > > life of the session. > > > > 1.1. Location Privacy During Session Initiation > > > > Peer-to-peer session initiation typically involves relay of an > > invitation via a rendezvous server. The initiating peer sends an > > invitation to the rendezvous server, which relays the invitation to > > the receiving peer for acceptance. Although the rendezvous server's > > role requires it to maintain a registry of peer addresses, location > > privacy demands that it should not send the receiving peer's address > > to the initiating peer until the receiving peer has accepted the > > call. > > > > When direct connectivity between the peers is possible, Interactive > > Connectivity Establishment (ICE) [RFC5245] connectivity checks can > > proceed and complete successfully as soon as the receiving peer has > > received the invitation, since the initiating peer's host and > > reflexive addresses can be delivered to the receiving peer along with > > the invitation. However, when the initiating peer requires a TURN > > relay, the receiving peer's address information must be delivered via > > the rendezvous server with the invitation response in order for the > > initiating peer to send a ChannelBind or CreatePermission request. > > > > Since the rendezvous server is often centrally located, even one-way > > latency between the peers via the rendezvous server can be > > significantly longer than the latency for direct connectivity, > > meaning that initiation of successful peer-to-peer communication can > > take significantly longer when a TURN relay is used, even if the > > relay server is optimally selected for end-to-end performance. > > > > 1.2. Location Privacy and Call Quality > > > > Many peer-to-peer applications (e.g. voice or video calls) are > > sensitive to path latency, with long one-way latencies often leading > > to a negative impact on user experience. For this reason, it can be > > important to select a relay server that is on-path between the peers > > in order to prevent use of the relay from negatively impacting > > latency. Achieving this goal can mean selecting the relay based on > > its relative proximity to the associated peer. For this reason, the > > relay address itself could provide information about the location of > > the peer. In other words, a user who wishes not to disclose her/his > > current location to the remote peer might have to intentionally > > select a TURN relay that is suboptimal for performance. > > ----- > > > > -- > > 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 > --20cf303ea06ce6d228050eaf5740 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that these goals seem to be at odds with one anoth= er, so if you have a proposal to solve both simultaneously I think you are = on the right track.

On Mon, Feb 9, 2015 at 11:50 AM, Tirumaleswar Reddy (tireddy) <tir= eddy@cisco.com> wrote:
Do y= ou have any performance numbers to show the impact of the problem ?

-Tiru


> -----Original Message-----
> From: tram [mailto:tram-bounc= es@ietf.org] On Behalf Of Brandon Williams
> Sent: Monday, February 09, 2015 10:08 PM
> To: tram@ietf.org
> Subject: [tram] location privacy considerations for TURN
>
> Hi all,
>
> There has been recent discussion about location privacy on the list. O= ne
> approach to location privacy has been to select a relay server that wi= ll not
> give away important location information, but one key issue has been h= ow to
> determine whether an allocated relay address meets the peer's loca= tion
> privacy requirements. If such a relay server can be identified, then t= he
> location privacy requirements can be met, but this could sacrifice the= user's
> performance expectations.
>
> We have been working on some ideas about how to address these privacy<= br> > concerns by adding a new channel binding mechanism to TURN that does n= ot
> require a peer to know even the relay address of the remote peer. Befo= re I
> try to engage the WG on a possible solution, I first want to get some = sense of
> whether I'm on target in the way that I'm framing the problem = (location
> privacy vs. performance).
>
> I've included a rough cut of the problem statement below (this see= med
> better than publishing a draft just for the one page of content) and w= ill
> appreciate feedback from the list. Have I clearly stated the problem? = Are
> there other ways in which location privacy could negatively impact
> performance? And is anyone else interested in trying to solve this pro= blem
> within the WG?
>
> Thanks,
> --Brandon
>
> -----
> 1.=C2=A0 Introduction
>
>=C2=A0 =C2=A0 =C2=A0Traversal Using Relay around NAT (TURN) [RFC5766] d= efines a mechanism
>=C2=A0 =C2=A0 =C2=A0for establishment of peer-to-peer communication usi= ng a data relay
>=C2=A0 =C2=A0 =C2=A0server.=C2=A0 Although not part of the explicit int= ent of the protocol, a
>=C2=A0 =C2=A0 =C2=A0TURN relay can also be used in a way that provides = enhanced privacy
>=C2=A0 =C2=A0 =C2=A0by hiding the network geographic location of one or= both peers from
>=C2=A0 =C2=A0 =C2=A0the other peer.=C2=A0 However, location privacy con= siderations can have a
>=C2=A0 =C2=A0 =C2=A0negative impact on latency, both during call setup = and throughout the
>=C2=A0 =C2=A0 =C2=A0life of the session.
>
> 1.1.=C2=A0 Location Privacy During Session Initiation
>
>=C2=A0 =C2=A0 =C2=A0Peer-to-peer session initiation typically involves = relay of an
>=C2=A0 =C2=A0 =C2=A0invitation via a rendezvous server.=C2=A0 The initi= ating peer sends an
>=C2=A0 =C2=A0 =C2=A0invitation to the rendezvous server, which relays t= he invitation to
>=C2=A0 =C2=A0 =C2=A0the receiving peer for acceptance.=C2=A0 Although t= he rendezvous server's
>=C2=A0 =C2=A0 =C2=A0role requires it to maintain a registry of peer add= resses, location
>=C2=A0 =C2=A0 =C2=A0privacy demands that it should not send the receivi= ng peer's address
>=C2=A0 =C2=A0 =C2=A0to the initiating peer until the receiving peer has= accepted the
>=C2=A0 =C2=A0 =C2=A0call.
>
>=C2=A0 =C2=A0 =C2=A0When direct connectivity between the peers is possi= ble, Interactive
>=C2=A0 =C2=A0 =C2=A0Connectivity Establishment (ICE) [RFC5245] connecti= vity checks can
>=C2=A0 =C2=A0 =C2=A0proceed and complete successfully as soon as the re= ceiving peer has
>=C2=A0 =C2=A0 =C2=A0received the invitation, since the initiating peer&= #39;s host and
>=C2=A0 =C2=A0 =C2=A0reflexive addresses can be delivered to the receivi= ng peer along with
>=C2=A0 =C2=A0 =C2=A0the invitation.=C2=A0 However, when the initiating = peer requires a TURN
>=C2=A0 =C2=A0 =C2=A0relay, the receiving peer's address information= must be delivered via
>=C2=A0 =C2=A0 =C2=A0the rendezvous server with the invitation response = in order for the
>=C2=A0 =C2=A0 =C2=A0initiating peer to send a ChannelBind or CreatePerm= ission request.
>
>=C2=A0 =C2=A0 =C2=A0Since the rendezvous server is often centrally loca= ted, even one-way
>=C2=A0 =C2=A0 =C2=A0latency between the peers via the rendezvous server= can be
>=C2=A0 =C2=A0 =C2=A0significantly longer than the latency for direct co= nnectivity,
>=C2=A0 =C2=A0 =C2=A0meaning that initiation of successful peer-to-peer = communication can
>=C2=A0 =C2=A0 =C2=A0take significantly longer when a TURN relay is used= , even if the
>=C2=A0 =C2=A0 =C2=A0relay server is optimally selected for end-to-end p= erformance.
>
> 1.2.=C2=A0 Location Privacy and Call Quality
>
>=C2=A0 =C2=A0 =C2=A0Many peer-to-peer applications (e.g. voice or video= calls) are
>=C2=A0 =C2=A0 =C2=A0sensitive to path latency, with long one-way latenc= ies often leading
>=C2=A0 =C2=A0 =C2=A0to a negative impact on user experience.=C2=A0 For = this reason, it can be
>=C2=A0 =C2=A0 =C2=A0important to select a relay server that is on-path = between the peers
>=C2=A0 =C2=A0 =C2=A0in order to prevent use of the relay from negativel= y impacting
>=C2=A0 =C2=A0 =C2=A0latency.=C2=A0 Achieving this goal can mean selecti= ng the relay based on
>=C2=A0 =C2=A0 =C2=A0its relative proximity to the associated peer.=C2= =A0 For this reason, the
>=C2=A0 =C2=A0 =C2=A0relay address itself could provide information abou= t the location of
>=C2=A0 =C2=A0 =C2=A0the peer.=C2=A0 In other words, a user who wishes n= ot to disclose her/his
>=C2=A0 =C2=A0 =C2=A0current location to the remote peer might have to i= ntentionally
>=C2=A0 =C2=A0 =C2=A0select a TURN relay that is suboptimal for performa= nce.
> -----
>
> --
> 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
ht= tps://www.ietf.org/mailman/listinfo/tram

--20cf303ea06ce6d228050eaf5740-- From nobody Mon Feb 9 15:51:48 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0211A8A8D for ; Mon, 9 Feb 2015 15:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.489 X-Spam-Level: X-Spam-Status: No, score=0.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, T_RP_MATCHES_RCVD=-0.01] 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 JVb_LsJzp1I6 for ; Mon, 9 Feb 2015 15:45:40 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 29AD51A8AA0 for ; Mon, 9 Feb 2015 15:45:39 -0800 (PST) Received: from [10.160.20.80] (unknown [106.120.233.20]) by app1 (Coremail) with SMTP id Z0GX06A7ygJhL9lUcgAuAg==.58775S2; Tue, 10 Feb 2015 06:06:25 +0800 (CST) Content-Type: multipart/alternative; boundary=Apple-Mail-39A75633-21F3-4470-9DCC-8BA245FEEEE2 Mime-Version: 1.0 (1.0) From: Aijun Wang X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Tue, 10 Feb 2015 07:44:39 +0800 Content-Transfer-Encoding: 7bit Message-Id: <915A8DA0-A081-4564-AFCC-CBDF16F91272@tsinghua.org.cn> References: <54D8E257.9000300@akamai.com> <913383AAA69FF945B8F946018B75898A355490E9@xmb-rcd-x10.cisco.com> To: Justin Uberti X-CM-TRANSID: Z0GX06A7ygJhL9lUcgAuAg==.58775S2 X-Coremail-Antispam: 1U3129KBjvJXoWxKFWUXw47KryUuFWUZF45GFg_yoWxuFWUpF Wruw4xKFykJr48A3ykXw10gF1Uu395Gry5Jr15Kr1UC398GFnavr47tw45GayUWrn5Ar4Y qryq9a1Duw1vvrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWj9Fb7 Iv0xC_Jr1lb4IE77IF4wAFF20E14v26r1j6r4UM7C26xCjj4IEI4klw4CSwwAFxVCaYxvI 4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY17CE14v26r126r1D0xZFpf9x0J ULVyxUUUUU= Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Brandon Williams Subject: Re: [tram] [SPAM] Re: location privacy considerations for TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 23:45:44 -0000 --Apple-Mail-39A75633-21F3-4470-9DCC-8BA245FEEEE2 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable If the communication peers use one well known relay addresses, then it will c= onceal its location from its peer.=20 Under such architecture, each distributed TURN server will have one unique w= ell known address, and the rendezvous server can select one most suitable TU= RN server(located at the most suitable optimal path) based on the proximity o= f the reflex addresses of the two peers, or it can select another TURN serve= r if the client want more location privacy than performance. On the other h= and, if these TURN servers use one ANYCAST well known address,then the priva= cy and performance can be achieved simultaneously. If the above mechanism is suitable, then we need another command to bind the= two peers at the TURN relay server(because each peer send traffic to the we= ll known relay address, the TURN server should know where is the correspondi= ng peer. We have proposed such solution in draft http://datatracker.ietf.org= /doc/draft-wang-tram-turnlite/ and are trying to revise it based on the feed= back from our presentation in last IETF meeting and the discuss recently in t= his WG list. This lightweight TURN solution can decouple the TURN function from the ICE p= rocedure, alleviate the relay address allocation burden of the TURN server, m= ake the TURN function be easily incorporated in some already distributed dep= loyed network devices, cover almost all the functions provided by current TU= RN solution. And meet the requirements of local privacy preserve and achieve= best performance described above. =46rom Aijun Wang > =D4=DA 2015=C4=EA2=D4=C210=C8=D5=A3=AC06:31=A3=ACJustin Uberti =D0=B4=B5=C0=A3=BA >=20 > I agree that these goals seem to be at odds with one another, so if you ha= ve a proposal to solve both simultaneously I think you are on the right trac= k. >=20 >> On Mon, Feb 9, 2015 at 11:50 AM, Tirumaleswar Reddy (tireddy) wrote: >> Do you have any performance numbers to show the impact of the problem ? >>=20 >> -Tiru >>=20 >>=20 >> > -----Original Message----- >> > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams= >> > Sent: Monday, February 09, 2015 10:08 PM >> > To: tram@ietf.org >> > Subject: [tram] location privacy considerations for TURN >> > >> > Hi all, >> > >> > There has been recent discussion about location privacy on the list. On= e >> > approach to location privacy has been to select a relay server that wil= l not >> > give away important location information, but one key issue has been ho= w to >> > determine whether an allocated relay address meets the peer's location >> > privacy requirements. If such a relay server can be identified, then th= e >> > location privacy requirements can be met, but this could sacrifice the u= ser's >> > performance expectations. >> > >> > We have been working on some ideas about how to address these privacy >> > concerns by adding a new channel binding mechanism to TURN that does no= t >> > require a peer to know even the relay address of the remote peer. Befor= e I >> > try to engage the WG on a possible solution, I first want to get some s= ense of >> > whether I'm on target in the way that I'm framing the problem (location= >> > privacy vs. performance). >> > >> > I've included a rough cut of the problem statement below (this seemed >> > better than publishing a draft just for the one page of content) and wi= ll >> > appreciate feedback from the list. Have I clearly stated the problem? A= re >> > there other ways in which location privacy could negatively impact >> > performance? And is anyone else interested in trying to solve this prob= lem >> > within the WG? >> > >> > Thanks, >> > --Brandon >> > >> > ----- >> > 1. Introduction >> > >> > Traversal Using Relay around NAT (TURN) [RFC5766] defines a mechani= sm >> > for establishment of peer-to-peer communication using a data relay >> > server. Although not part of the explicit intent of the protocol, a= >> > TURN relay can also be used in a way that provides enhanced privacy= >> > by hiding the network geographic location of one or both peers from= >> > the other peer. However, location privacy considerations can have a= >> > negative impact on latency, both during call setup and throughout t= he >> > life of the session. >> > >> > 1.1. Location Privacy During Session Initiation >> > >> > Peer-to-peer session initiation typically involves relay of an >> > invitation via a rendezvous server. The initiating peer sends an >> > invitation to the rendezvous server, which relays the invitation to= >> > the receiving peer for acceptance. Although the rendezvous server'= s >> > role requires it to maintain a registry of peer addresses, location= >> > privacy demands that it should not send the receiving peer's addres= s >> > to the initiating peer until the receiving peer has accepted the >> > call. >> > >> > When direct connectivity between the peers is possible, Interactive= >> > Connectivity Establishment (ICE) [RFC5245] connectivity checks can >> > proceed and complete successfully as soon as the receiving peer has= >> > received the invitation, since the initiating peer's host and >> > reflexive addresses can be delivered to the receiving peer along wi= th >> > the invitation. However, when the initiating peer requires a TURN >> > relay, the receiving peer's address information must be delivered v= ia >> > the rendezvous server with the invitation response in order for the= >> > initiating peer to send a ChannelBind or CreatePermission request. >> > >> > Since the rendezvous server is often centrally located, even one-wa= y >> > latency between the peers via the rendezvous server can be >> > significantly longer than the latency for direct connectivity, >> > meaning that initiation of successful peer-to-peer communication ca= n >> > take significantly longer when a TURN relay is used, even if the >> > relay server is optimally selected for end-to-end performance. >> > >> > 1.2. Location Privacy and Call Quality >> > >> > Many peer-to-peer applications (e.g. voice or video calls) are >> > sensitive to path latency, with long one-way latencies often leadin= g >> > to a negative impact on user experience. For this reason, it can b= e >> > important to select a relay server that is on-path between the peer= s >> > in order to prevent use of the relay from negatively impacting >> > latency. Achieving this goal can mean selecting the relay based on= >> > its relative proximity to the associated peer. For this reason, th= e >> > relay address itself could provide information about the location o= f >> > the peer. In other words, a user who wishes not to disclose her/hi= s >> > current location to the remote peer might have to intentionally >> > select a TURN relay that is suboptimal for performance. >> > ----- >> > >> > -- >> > 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 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram --Apple-Mail-39A75633-21F3-4470-9DCC-8BA245FEEEE2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If the commu= nication peers use one well known relay addresses, then it will conceal its l= ocation from its peer. 
Under such architecture, each distrib= uted TURN server will have one unique well known address, and the rendezvous= server can select one most suitable TURN server(located at the most suitabl= e optimal path) based on the proximity of the reflex addresses of the two pe= ers, or it can select another TURN server if the client want more location p= rivacy than performance.  On the other hand, if these TURN servers use o= ne ANYCAST well known address,then the privacy and performance can be achiev= ed simultaneously.

If the above mechanism is suitab= le, then we need another command to bind the two peers at the TURN relay ser= ver(because each peer send traffic to the well known relay address, the TURN= server should know where is the corresponding peer. We have proposed such s= olution in draft http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ and are trying to revise it based on the feedback from our presentation in= last IETF meeting and the discuss recently in this WG list.

<= /div>
This lightweight TURN solution can decouple the TURN function from= the ICE procedure, alleviate the relay address allocation burden of the TUR= N server, make the TURN function be easily incorporated in some already dist= ributed deployed network devices, cover almost all the functions provided by= current TURN solution. And meet the requirements of local privacy preserve a= nd achieve best performance described above.




=46rom Aijun Wang

I a= gree that these goals seem to be at odds with one another, so if you have a p= roposal to solve both simultaneously I think you are on the right track.

On Mon, Feb 9, 2= 015 at 11:50 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
Do you have any performance number= s to show the impact of the problem ?

-Tiru


> -----Original Message-----
> From: tram [mailto:tram-bounce= s@ietf.org] On Behalf Of Brandon Williams
> Sent: Monday, February 09, 2015 10:08 PM
> To: tram@ietf.org
> Subject: [tram] location privacy considerations for TURN
>
> Hi all,
>
> There has been recent discussion about location privacy on the list. On= e
> approach to location privacy has been to select a relay server that wil= l not
> give away important location information, but one key issue has been ho= w to
> determine whether an allocated relay address meets the peer's location<= br> > privacy requirements. If such a relay server can be identified, then th= e
> location privacy requirements can be met, but this could sacrifice the u= ser's
> performance expectations.
>
> We have been working on some ideas about how to address these privacy > concerns by adding a new channel binding mechanism to TURN that does no= t
> require a peer to know even the relay address of the remote peer. Befor= e I
> try to engage the WG on a possible solution, I first want to get some s= ense of
> whether I'm on target in the way that I'm framing the problem (location=
> privacy vs. performance).
>
> I've included a rough cut of the problem statement below (this seemed > better than publishing a draft just for the one page of content) and wi= ll
> appreciate feedback from the list. Have I clearly stated the problem? A= re
> there other ways in which location privacy could negatively impact
> performance? And is anyone else interested in trying to solve this prob= lem
> within the WG?
>
> Thanks,
> --Brandon
>
> -----
> 1.  Introduction
>
>     Traversal Using Relay around NAT (TURN) [RFC5766] de= fines a mechanism
>     for establishment of peer-to-peer communication usin= g a data relay
>     server.  Although not part of the explicit inte= nt of the protocol, a
>     TURN relay can also be used in a way that provides e= nhanced privacy
>     by hiding the network geographic location of one or b= oth peers from
>     the other peer.  However, location privacy cons= iderations can have a
>     negative impact on latency, both during call setup a= nd throughout the
>     life of the session.
>
> 1.1.  Location Privacy During Session Initiation
>
>     Peer-to-peer session initiation typically involves r= elay of an
>     invitation via a rendezvous server.  The initia= ting peer sends an
>     invitation to the rendezvous server, which relays th= e invitation to
>     the receiving peer for acceptance.  Although th= e rendezvous server's
>     role requires it to maintain a registry of peer addr= esses, location
>     privacy demands that it should not send the receivin= g peer's address
>     to the initiating peer until the receiving peer has a= ccepted the
>     call.
>
>     When direct connectivity between the peers is possib= le, Interactive
>     Connectivity Establishment (ICE) [RFC5245] connectiv= ity checks can
>     proceed and complete successfully as soon as the rec= eiving peer has
>     received the invitation, since the initiating peer's= host and
>     reflexive addresses can be delivered to the receivin= g peer along with
>     the invitation.  However, when the initiating p= eer requires a TURN
>     relay, the receiving peer's address information must= be delivered via
>     the rendezvous server with the invitation response i= n order for the
>     initiating peer to send a ChannelBind or CreatePermi= ssion request.
>
>     Since the rendezvous server is often centrally locat= ed, even one-way
>     latency between the peers via the rendezvous server c= an be
>     significantly longer than the latency for direct con= nectivity,
>     meaning that initiation of successful peer-to-peer c= ommunication can
>     take significantly longer when a TURN relay is used,= even if the
>     relay server is optimally selected for end-to-end pe= rformance.
>
> 1.2.  Location Privacy and Call Quality
>
>     Many peer-to-peer applications (e.g. voice or video c= alls) are
>     sensitive to path latency, with long one-way latenci= es often leading
>     to a negative impact on user experience.  For t= his reason, it can be
>     important to select a relay server that is on-path b= etween the peers
>     in order to prevent use of the relay from negatively= impacting
>     latency.  Achieving this goal can mean selectin= g the relay based on
>     its relative proximity to the associated peer. = For this reason, the
>     relay address itself could provide information about= the location of
>     the peer.  In other words, a user who wishes no= t to disclose her/his
>     current location to the remote peer might have to in= tentionally
>     select a TURN relay that is suboptimal for performan= ce.
> -----
>
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products<= br> > Engineering; Akamai Technologies Inc.
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram

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

____________________= ___________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman= /listinfo/tram
= --Apple-Mail-39A75633-21F3-4470-9DCC-8BA245FEEEE2-- From nobody Mon Feb 9 22:58:56 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DE51A0019 for ; Mon, 9 Feb 2015 22:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jBNztKLgx-i for ; Mon, 9 Feb 2015 22:58:51 -0800 (PST) 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 2AC8B1A000F for ; Mon, 9 Feb 2015 22:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7814; q=dns/txt; s=iport; t=1423551531; x=1424761131; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=gxuaZ7LMT5pxpP/cEEphZ7D2e69xOPk1MXGF8zm+CBk=; b=dzFMYR4ezRSAsTs2NZ+3xNXBrPXN8T2c2NQ3oAKdqzWYegOjnAMi1P7r aNWXoq8XXs+6zwes+FbVCn+Rrh6MDfWLcgb2OVxi8lv3pcZHtlaPms5SP PIuY3jLy9tz5ucbQAOp5kflX69Dcovq6JKyyNeDX3gGesWA7jozVMYHA6 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskFAFOr2VStJV2Y/2dsb2JhbABcgwZSWgSCfr1bghwKhXECHIEBQwEBAQEBAXyEDAEBAQMBAQEBIBE6CQcHBgEIEQQBAQECAgYdAwIEJQsUAQcBCQEEARIIiB0IDbYolwMBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhjiUWKIJiLoEUBY8bhWGEY44agz4iggIFFxSBPG+BRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,548,1418083200"; d="scan'208";a="394842114" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 10 Feb 2015 06:58:49 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t1A6wnhH032652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Feb 2015 06:58:49 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.155]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Tue, 10 Feb 2015 00:58:48 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt Thread-Index: AdBE/wF1Kl/vMpNLSQ6RfbUlOQjAtQ== Date: Tue, 10 Feb 2015 06:58:48 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A355495D0@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.66.14] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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: Tue, 10 Feb 2015 06:58:55 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJhbmRvbiBXaWxsaWFtcw0KPiBTZW50OiBU dWVzZGF5LCBGZWJydWFyeSAxMCwgMjAxNSAxMjo1NCBBTQ0KPiBUbzogdHJhbUBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXJlZGR5LXRyYW0tdHVybi0NCj4gaXBhZGRyZXNzLXByaXZhY3ktMDAudHh0DQo+IA0KPiBJ J20gbm90IHN1cmUgdGhhdCB0aGUgInJldHVybiBOTk4iIGFwcHJvYWNoIGNhbiBhZGRyZXNzIHRo ZSBpc3N1ZSBhbnl3YXkuDQo+IElmIHlvdSB0YWtlIHRoZSBjYXNlIG9mIGEgYnJvYWRseSBkaXN0 cmlidXRlZCBzeXN0ZW0gKGUuZy4gYSBzaW5nbGUgc3lzdGVtIHdpdGgNCj4gc2V2ZXJhbCBodW5k cmVkIFBPUHMsIGZvciBleGFtcGxlKSwgaG93IHdpbGwgaXQgZGVjaWRlIHdoaWNoICJOTk4iDQo+ IGFsdGVybmF0ZXMgdG8gcHJvdmlkZT8gSWYgSSBoYXZlIDMgcmVhc29uYWJsZSByZWxheSBzZXJ2 ZXJzIGZvciB5b3VyIGxvY2F0aW9uDQo+IGFuZCB5b3Ugd2FudCAzIGFsdGVybmF0ZXMsIHNob3Vs ZCBJIGludGVudGlvbmFsbHkgbm90IHJldHVybiB0aGUgMyByZWFzb25hYmxlDQo+IG9uZXM/DQo+ IA0KPiBJZiB0aGUgb25seSBwdXJwb3NlIG9mIHRoaXMgbWV0aG9kIGlzIHByaXZhY3ksIHRoZW4g dGhlIHNlcnZlciBjb3VsZCBwaWNrIGEgc2V0DQo+IG9mIGFsdGVybmF0ZXMgdGhhdCBpcyBicm9h ZGx5IGRpc3RyaWJ1dGVkIGdlb2dyYXBoaWNhbGx5LiBJdCBjb3VsZCBldmVuIGluZGljYXRlDQo+ IGEgc2NvcmUgb2Ygc29tZSBzb3J0IHRoYXQgdGVsbHMgdGhlIGNsaWVudCBob3cgY2xvc2VseSBj b3JyZWxhdGVkIGVhY2ggcmVsYXkNCj4gc2VydmVyIGlzIHRvIHRoZSBjbGllbnQgYWRkcmVzcy4g QnV0IHlvdSBzdGlsbCBoYXZlIHRoZSB0cnVzdCBpc3N1ZSBoZXJlLiANCg0KVGhlcmUgbXVzdCBi ZSB0cnVzdCBiL3cgdGhlIGVuZHBvaW50IGFuZCB0aGUgVFVSTiBzZXJ2ZXIsIHNpbWlsYXIgdG8g dGhlIHdheSBlbmRwb2ludHMgdHJ1c3RzIEFub255bW91cyBWUE4gc2VydmljZSBwcm92aWRlciAu DQoNCj4gSWYgdGhlDQo+IHNlcnZlciByZXR1cm5lZCBhIGJhZCBjYW5kaWRhdGUgc2V0LCBkaWQg aXQgZG8gc28gYmVjYXVzZSBpdCBkaWRuJ3QgaGF2ZQ0KPiBvcHRpb25zLCBvciBiZWNhdXNlIGl0 IGRvZXNuJ3Qgd2FudCB0byBnaXZlIHlvdSBsb2NhdGlvbiBwcml2YWN5PyANCg0KSWYgdGhlIHNl cnZlciBjYW5ub3Qgc3VwcG9ydCBwcml2YWN5IHRoZW4gaXQgc2hvdWxkIG5vdCByZXR1cm4gdGhl IG5ldyBhdHRyaWJ1dGUgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0Lg0KDQo+IEFuZCBpZiB0aGUNCj4g YWx0ZXJuYXRlcyBhcmUgZ29vZCwgaG93IHdpbGwgY2xpZW50IHNlbGVjdCBhbHRlcm5hdGVzIG92 ZXIgdGltZSB0byBlbnN1cmUgdGhhdA0KPiB0aGlzIHNlbGVjdGlvbiBkb2Vzbid0IGdpdmUgZW5v dWdoIGF3YXkgYWJvdXQgd2hlcmUgdGhlIGNsaWVudCBpc24ndCB0byBhbGxvdw0KPiB5b3UgdG8g ZmlndXJlIG91dCB3aGVyZSB0aGUgY2xpZW50IGlzPw0KDQpGb3IgZXZlcnkgY2FsbCBjbGllbnQg bWFrZXMgYSBkZWNpc2lvbiBpZiBwcml2YWN5IGlzIHJlcXVpcmVkIG9yIG5vdCwgZWFjaCB0aW1l IGl0IHdpbGwgbGVhcm4gbmV3IGFsdGVybmF0aXZlcyBmcm9tIHRoZSBUVVJOIHNlcnZlci4NCg0K PiANCj4gSWYgdGhlIGNsaWVudCBoYXMgdG8gc2VsZWN0IHRoZSByZWxheSB2ZXJ5IGNhcmVmdWxs eSBpbiBvcmRlciB0byBlbnN1cmUgdGhhdCBpdCBnZXRzDQo+IHRoZSBwcml2YWN5IGNoYXJhY3Rl cmlzdGljcyB0aGF0IGl0IHdhbnRzLCB0aGVuIGl0J3MgcHJvYmFibHkgYmV0dGVyIHRvIHByb3Zp ZGUgYQ0KPiBzZXJ2ZXIgd2l0aCBhIGZpeGVkIGxvY2F0aW9uIHRoYXQgbmV2ZXIgY2hhbmdlcyBu byBtYXR0ZXIgd2hlcmUgeW91J3JlDQo+IGxvY2F0ZWQuIFRoYXQgd2F5LCB5b3UgY2FuIGFsd2F5 cyBzZWxlY3QgdGhlIHByaXZhY3kgcmVsYXkgd2hlbiB0aGF0J3Mgd2hhdA0KPiB5b3Ugd2FudCBh bmQga25vdyB0aGF0IHRoZSByZWxheSdzIGxvY2F0aW9uIHdpbGwgbmV2ZXIgc2F5IHNvbWV0aGlu ZyB1c2VmdWwNCj4gYWJvdXQgeW91IGFsbCBieSBpdHNlbGYuDQoNClRoaXMgbWVjaGFuaXNtIHdv bid0IHdvcmsgaWYgdGhlIHVzZXIgaXMgcm9hbWluZy4NCg0KLVRpcnUNCg0KPiANCj4gLS1CcmFu ZG9uDQo+IA0KPiBPbiAwMi8wOS8yMDE1IDAxOjEwIFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRp cmVkZHkpIHdyb3RlOg0KPiA+IElubGluZSBbVFIyXQ0KPiA+DQo+ID4gKkZyb206KkJlbmphbWlu IFNjaHdhcnR6IFttYWlsdG86YmVtYXNjQHdlYnJ0Yy5vcmddDQo+ID4gKlNlbnQ6KiBGcmlkYXks IEZlYnJ1YXJ5IDA2LCAyMDE1IDk6NDkgUE0NCj4gPiAqVG86KiBUaXJ1bWFsZXN3YXIgUmVkZHkg KHRpcmVkZHkpDQo+ID4gKkNjOiogSnVzdGluIFViZXJ0aTsgdHJhbUBpZXRmLm9yZzsgU2ltb24g UGVycmVhdWx0DQo+ID4gKlN1YmplY3Q6KiBSRTogW3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yDQo+ID4gZHJhZnQtcmVkZHktdHJhbS10dXJuLWlwYWRkcmVzcy1wcml2YWN5 LTAwLnR4dA0KPiA+DQo+ID4gSSBhcHByZWNpYXRlIHRoZSBnb2FsIG9mIHRoaXMgd29yay4gIE1h eWJlIGEgc2xpZ2h0bHkgZGlmZmVyZW50DQo+ID4gc3RyYXRlZ3kgd291bGQgYmUgbW9yZSBlYXNp bHkgYWNjZXB0ZWQgaW4gdGhlIHdvcmtpbmcgZ3JvdXAuICBXaGF0IGlmDQo+ID4gdGhlIGNsaWVu dCBjb3VsZCBxdWVyeSB0aGUgc2VydmVyIGZvciBhIGxpc3Qgb2YgYWx0ZXJuYXRlIFRVUk4NCj4g PiBzZXJ2ZXJzPyAgVGhlbiB0aGUgY2xpZW50IGNvdWxkIGhhdmUgdGhlIG9wdGlvbiBvZiBzZWxl Y3RpbmcgYSBzZXJ2ZXINCj4gPiBiYXNlZCBvbiBnZW9sb2NhdGlvbiwgYnV0IHRoZSBjbGllbnQg d291bGQgbm90IGhhdmUgdG8gY29udmV5IGl0cw0KPiA+IHByaXZhY3kgZ29hbHMgdG8gdGhlIHNl cnZlciBleHBsaWNpdGx5Lg0KPiA+DQo+ID4gW1RSMl0gSW50ZXJlc3RpbmcgYWx0ZXJuYXRpdmUs IGl0IGhhcyBwcm9zIGFuZCBjb25zIHRoYXQgY2xpZW50IHdpbGwNCj4gPiBub3QgaGF2ZSB0byBj b252ZXkgaXRzIHByaXZhY3kgZ29hbHMgdG8gc2VydmVyIGV4cGxpY2l0bHkgYnV0IGlmIGl0DQo+ ID4gcmVjZWl2ZXMgTk5OIG51bWJlciBvZiBhbHRlcm5hdGUgc2VydmVycyBpdCB3aWxsIGhhdmUg dG8gdHJ5IGFsbCBvZg0KPiA+IHRoZW0gYW5kIHBpY2sgdGhlIG9uZSB3aGljaCBzdWl0ZXMgaXRz IHByaXZhY3kgbmVlZHMgKFRVUk4gc2VydmVyIGNhbg0KPiA+IHByb2JhYmx5IGdpdmUgYWRkaXRp b25hbCBpbmZvcm1hdGlvbiBvbiB0aGUgcHJpdmFjeSBsZXZlbHMgdGhhdCBjYW4gYmUNCj4gPiBw cm92aWRlZCBieSBlYWNoIG9mIHRoZSBhbHRlcm5hdGUgc2VydmVycyB0byBhZGRyZXNzIHRoaXMg cHJvYmxlbSkNCj4gPg0KPiA+IC1UaXJ1DQo+ID4NCj4gPiBJbmxpbmUgW1RSXQ0KPiA+DQo+ID4g KkZyb206Kkp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20NCj4gPiA8bWFp bHRvOmp1YmVydGlAZ29vZ2xlLmNvbT5dDQo+ID4gKlNlbnQ6KiBGcmlkYXksIEZlYnJ1YXJ5IDA2 LCAyMDE1IDY6MjEgQU0NCj4gPiAqVG86KiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+ ID4gKkNjOiogQmVuamFtaW4gU2Nod2FydHo7IFNpbW9uIFBlcnJlYXVsdDsgdHJhbUBpZXRmLm9y Zw0KPiA+IDxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCj4gPiAqU3ViamVjdDoqIFJlOiBbdHJhbV0g Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPiBkcmFmdC1yZWRkeS10cmFtLXR1 cm4taXBhZGRyZXNzLXByaXZhY3ktMDAudHh0DQo+ID4NCj4gPiBJIGFncmVlIHdpdGggU2ltb24g YW5kIEJlbiBpbiBiZWluZyBza2VwdGljYWwgYWJvdXQgdGhpcyBwcm9wb3NhbC4NCj4gPg0KPiA+ IFRoZSBjbGllbnQgaXMgdGhlIG9ubHkgcGFydHkgd2hpY2gga25vd3MgZXhhY3RseSB3aGF0ICdw cml2YWN5JyBtZWFucywNCj4gPiBhbmQgdGhlcmUgaXMgbm8gdHJpdmlhbCB3YXkgdG8gc2VyaWFs aXplIHRoaXMgaW50byBhIHNpbmdsZSBhdHRyaWJ1dGUNCj4gPiBmb3IgdGhlIFRVUk4gc2VydmVy Lg0KPiA+DQo+ID4gW1RSXSBXZSBhcmUgZXZhbHVhdGluZyBob3cgdGhlIGNsaWVudCBjYW4gY292 ZXkgaXRzIOKAmHByaXZhY3nigJkgbmVlZHMgaW4NCj4gPiB0aGlzIG5ldyBhdHRyaWJ1dGUgdG8g dGhlIFRVUk4gc2VydmVyIHNvIHRoYXQgaXQgY2FuIHRha2UgYXBwcm9wcmlhdGUNCj4gPiBhY3Rp b24gYW5kIHRoZSBzZXJ2ZXIgcmVzcG9uZHMgaWYgdGhlIGNsaWVudCDigJhwcml2YWN54oCZIHJl cXVpcmVtZW50IGNhbg0KPiA+IGJlIG1ldCBmdWxseSBvciBwYXJ0aWFsbHkuDQo+ID4NCj4gPiAt VGlydQ0KPiA+DQo+ID4gQXMgc3VjaCwgSSB0aGluayB0aGlzIGRlY2lzaW9uIHNob3VsZCBiZSBs ZWZ0IGVudGlyZWx5IHRvIHRoZSBjbGllbnQuDQo+ID4NCj4gPiBPbiBXZWQsIEZlYiA0LCAyMDE1 IGF0IDEwOjUwIEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+ID4gPHRpcmVkZHlA Y2lzY28uY29tIDxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+PiB3cm90ZToNCj4gPg0KPiA+IEkg YWdyZWUgdGhhdCB0aGUgY2xpZW50IGNhbiBkbyBlcXVhbGx5IHdlbGwgaXRzZWxmLCBieSBzZW5k aW5nIGEgU1RVTg0KPiA+IEJpbmRpbmcgUmVxdWVzdCBhbmQgY29tcGFyaW5nIHRoZSByZXNwb25z ZSB0byB0aGUgVFVSTiBzZXJ2ZXIncyBvd24gSVANCj4gPiBhZGRyZXNzLg0KPiA+DQo+ID4gW1RS M10gVGhlIGRpZmZlcmVuY2UgdGhpcyBkcmFmdCBicmluZ3MgaW4gaXMgdGhhdCBpdCBoZWxwcyB0 aGUgVFVSTg0KPiA+IHNlcnZlciAob2ZmZXJlZCBieSBhIGdsb2JhbCBvciBjbG91ZCBzZXJ2aWNl KSB0byBkZXRlcm1pbmUgdGhhdCB0aGUNCj4gPiBjbGllbnQgd2FudHMgcHJpdmFjeSBhbmQgbGV2 ZWwgb2YgcHJpdmFjeSByZXF1aXJlZCBjb252ZXllZCBpbiB0aGUgbmV3DQo+ID4gU1RVTiBhdHRy aWJ1dGUsIHRoZSBUVVJOIHNlcnZlciBkZXRlcm1pbmVzIHN1aXRhYmxlIGFsdGVybmF0ZSBUVVJO DQo+ID4gc2VydmVyIHRoYXQgY2FuIG9mZmVyIHRoZSByZXF1aXJlZCBsZXZlbCBvZiBwcml2YWN5 Lg0KPiA+DQo+ID4gLVRpcnUNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiB0cmFtIG1haWxpbmcgbGlzdA0KPiA+IHRyYW1A aWV0Zi5vcmcgPG1haWx0bzp0cmFtQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPiA+DQo+IA0KPiAtLQ0KPiBCcmFuZG9uIFdpbGxpYW1z OyBTZW5pb3IgUHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2luZWVyIEVtZXJnaW5nIFByb2R1Y3RzDQo+ IEVuZ2luZWVyaW5nOyBBa2FtYWkgVGVjaG5vbG9naWVzIEluYy4NCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRyYW0gbWFpbGluZyBsaXN0 DQo+IHRyYW1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90cmFtDQo= From nobody Tue Feb 10 06:33:44 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7EE1A0270 for ; Tue, 10 Feb 2015 06:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.61 X-Spam-Level: X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 n8oiJtz4Kf7a for ; Tue, 10 Feb 2015 06:33:37 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id A60361A01F2 for ; Tue, 10 Feb 2015 06:33:37 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5DBE528574; Tue, 10 Feb 2015 14:33:36 +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 4AF1328571; Tue, 10 Feb 2015 14:33: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 3F896205F; Tue, 10 Feb 2015 14:33:36 +0000 (GMT) Message-ID: <54DA16C0.30506@akamai.com> Date: Tue, 10 Feb 2015 09:33:36 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Aijun Wang , Justin Uberti References: <54D8E257.9000300@akamai.com> <913383AAA69FF945B8F946018B75898A355490E9@xmb-rcd-x10.cisco.com> <915A8DA0-A081-4564-AFCC-CBDF16F91272@tsinghua.org.cn> In-Reply-To: <915A8DA0-A081-4564-AFCC-CBDF16F91272@tsinghua.org.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] [SPAM] Re: location privacy considerations for TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 14:33:42 -0000 On 02/09/2015 06:44 PM, Aijun Wang wrote: > If the communication peers use one well known relay addresses, then it > will conceal its location from its peer. > Under such architecture, each distributed TURN server will have one > unique well known address, and the rendezvous server can select one most > suitable TURN server(located at the most suitable optimal path) based on > the proximity of the reflex addresses of the two peers, or it can select > another TURN server if the client want more location privacy than > performance. As soon as you use a publicly available address and disclose it to the other peer, you begin to give away information about your location, especially (though not exclusively) if the address is selected based on proximity. > On the other hand, if these TURN servers use one ANYCAST > well known address,then the privacy and performance can be achieved > simultaneously. You cannot reliably use an ANYCAST address for a long-lived data flow, which is why TURN auto-discovery redirects the peer to a unicast address in response to the allocate request. > > If the above mechanism is suitable, then we need another command to bind > the two peers at the TURN relay server(because each peer send traffic to > the well known relay address, the TURN server should know where is the > corresponding peer. We have proposed such solution in draft > http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ and are trying > to revise it based on the feedback from our presentation in last IETF > meeting and the discuss recently in this WG list. When the "turnlite" proposal was presented in Honolulu, the WG essentially said "this is not TURN". At least that was my understanding of the response. Unless the proposal has been modified so significantly that it is indistinguishable from the first draft, I would not expect the WG response to change. I am not trying to discourage you from working on your idea. I'm simply suggesting that, since it doesn't really appear to be an update to TURN, this WG might not be the best forum for the proposal. --Brandon > > This lightweight TURN solution can decouple the TURN function from the > ICE procedure, alleviate the relay address allocation burden of the TURN > server, make the TURN function be easily incorporated in some already > distributed deployed network devices, cover almost all the functions > provided by current TURN solution. And meet the requirements of local > privacy preserve and achieve best performance described above. > > > > > From Aijun Wang > > > 在 2015å¹´2月10日，06:31，Justin Uberti > 写é“： > >> I agree that these goals seem to be at odds with one another, so if >> you have a proposal to solve both simultaneously I think you are on >> the right track. >> >> On Mon, Feb 9, 2015 at 11:50 AM, Tirumaleswar Reddy (tireddy) >> > wrote: >> >> Do you have any performance numbers to show the impact of the >> problem ? >> >> -Tiru >> >> >> > -----Original Message----- >> > From: tram [mailto:tram-bounces@ietf.org >> ] On Behalf Of Brandon Williams >> > Sent: Monday, February 09, 2015 10:08 PM >> > To: tram@ietf.org >> > Subject: [tram] location privacy considerations for TURN >> > >> > Hi all, >> > >> > There has been recent discussion about location privacy on the >> list. One >> > approach to location privacy has been to select a relay server >> that will not >> > give away important location information, but one key issue has >> been how to >> > determine whether an allocated relay address meets the peer's >> location >> > privacy requirements. If such a relay server can be identified, >> then the >> > location privacy requirements can be met, but this could >> sacrifice the user's >> > performance expectations. >> > >> > We have been working on some ideas about how to address these >> privacy >> > concerns by adding a new channel binding mechanism to TURN that >> does not >> > require a peer to know even the relay address of the remote >> peer. Before I >> > try to engage the WG on a possible solution, I first want to get >> some sense of >> > whether I'm on target in the way that I'm framing the problem >> (location >> > privacy vs. performance). >> > >> > I've included a rough cut of the problem statement below (this >> seemed >> > better than publishing a draft just for the one page of content) >> and will >> > appreciate feedback from the list. Have I clearly stated the >> problem? Are >> > there other ways in which location privacy could negatively impact >> > performance? And is anyone else interested in trying to solve >> this problem >> > within the WG? >> > >> > Thanks, >> > --Brandon >> > >> > ----- >> > 1. Introduction >> > >> > Traversal Using Relay around NAT (TURN) [RFC5766] defines a >> mechanism >> > for establishment of peer-to-peer communication using a data >> relay >> > server. Although not part of the explicit intent of the >> protocol, a >> > TURN relay can also be used in a way that provides enhanced >> privacy >> > by hiding the network geographic location of one or both >> peers from >> > the other peer. However, location privacy considerations >> can have a >> > negative impact on latency, both during call setup and >> throughout the >> > life of the session. >> > >> > 1.1. Location Privacy During Session Initiation >> > >> > Peer-to-peer session initiation typically involves relay of an >> > invitation via a rendezvous server. The initiating peer >> sends an >> > invitation to the rendezvous server, which relays the >> invitation to >> > the receiving peer for acceptance. Although the rendezvous >> server's >> > role requires it to maintain a registry of peer addresses, >> location >> > privacy demands that it should not send the receiving peer's >> address >> > to the initiating peer until the receiving peer has accepted the >> > call. >> > >> > When direct connectivity between the peers is possible, >> Interactive >> > Connectivity Establishment (ICE) [RFC5245] connectivity >> checks can >> > proceed and complete successfully as soon as the receiving >> peer has >> > received the invitation, since the initiating peer's host and >> > reflexive addresses can be delivered to the receiving peer >> along with >> > the invitation. However, when the initiating peer requires >> a TURN >> > relay, the receiving peer's address information must be >> delivered via >> > the rendezvous server with the invitation response in order >> for the >> > initiating peer to send a ChannelBind or CreatePermission >> request. >> > >> > Since the rendezvous server is often centrally located, even >> one-way >> > latency between the peers via the rendezvous server can be >> > significantly longer than the latency for direct connectivity, >> > meaning that initiation of successful peer-to-peer >> communication can >> > take significantly longer when a TURN relay is used, even if the >> > relay server is optimally selected for end-to-end performance. >> > >> > 1.2. Location Privacy and Call Quality >> > >> > Many peer-to-peer applications (e.g. voice or video calls) are >> > sensitive to path latency, with long one-way latencies often >> leading >> > to a negative impact on user experience. For this reason, >> it can be >> > important to select a relay server that is on-path between >> the peers >> > in order to prevent use of the relay from negatively impacting >> > latency. Achieving this goal can mean selecting the relay >> based on >> > its relative proximity to the associated peer. For this >> reason, the >> > relay address itself could provide information about the >> location of >> > the peer. In other words, a user who wishes not to disclose >> her/his >> > current location to the remote peer might have to intentionally >> > select a TURN relay that is suboptimal for performance. >> > ----- >> > >> > -- >> > 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 >> >> >> _______________________________________________ >> 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 Tue Feb 10 07:08:38 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB19F1A9034 for ; Tue, 10 Feb 2015 07:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 5x0gTFXeknHu for ; Tue, 10 Feb 2015 07:08:30 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 6280E1A8A91 for ; Tue, 10 Feb 2015 07:08:30 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2F8FF47640; Tue, 10 Feb 2015 15:08:29 +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 B6649476C8; Tue, 10 Feb 2015 15:08:28 +0000 (GMT) Received: from [172.28.115.172] (unknown [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 9DA0E80074; Tue, 10 Feb 2015 15:08:28 +0000 (GMT) Message-ID: <54DA1EEC.7000704@akamai.com> Date: Tue, 10 Feb 2015 10:08:28 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A355495D0@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A355495D0@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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: Tue, 10 Feb 2015 15:08:36 -0000 On 02/10/2015 01:58 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Tuesday, February 10, 2015 12:54 AM >> To: tram@ietf.org >> Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn- >> ipaddress-privacy-00.txt >> >> I'm not sure that the "return NNN" approach can address the issue anyway. >> If you take the case of a broadly distributed system (e.g. a single system with >> several hundred POPs, for example), how will it decide which "NNN" >> alternates to provide? If I have 3 reasonable relay servers for your location >> and you want 3 alternates, should I intentionally not return the 3 reasonable >> ones? >> >> If the only purpose of this method is privacy, then the server could pick a set >> of alternates that is broadly distributed geographically. It could even indicate >> a score of some sort that tells the client how closely correlated each relay >> server is to the client address. But you still have the trust issue here. > > There must be trust b/w the endpoint and the TURN server, similar to the way endpoints trusts Anonymous VPN service provider . > >> If the >> server returned a bad candidate set, did it do so because it didn't have >> options, or because it doesn't want to give you location privacy? > > If the server cannot support privacy then it should not return the new attribute defined in this draft. > >> And if the >> alternates are good, how will client select alternates over time to ensure that >> this selection doesn't give enough away about where the client isn't to allow >> you to figure out where the client is? > > For every call client makes a decision if privacy is required or not, each time it will learn new alternatives from the TURN server. I agree that a mechanism like the one in the draft requires trust b/w the endpoint and the TURN server. I was arguing that the "return NNN" approach has that same limitation, and that it needs some explicit indication of the privacy requirement in order to know which NNN alternates to return. It doesn't seem to simplify the solution. > >> >> If the client has to select the relay very carefully in order to ensure that it gets >> the privacy characteristics that it wants, then it's probably better to provide a >> server with a fixed location that never changes no matter where you're >> located. That way, you can always select the privacy relay when that's what >> you want and know that the relay's location will never say something useful >> about you all by itself. > > This mechanism won't work if the user is roaming. How does it not work if the user is roaming? It won't give good performance, but I maintain that performance goals and privacy goals are in conflict as long as you must disclose the relay address to the remote peer. The point of always using the same relay server, even when roaming, is to hide details about your location (such as the fact that you're roaming). --Brandon > > -Tiru > >> >> --Brandon >> >> On 02/09/2015 01:10 PM, Tirumaleswar Reddy (tireddy) wrote: >>> Inline [TR2] >>> >>> *From:*Benjamin Schwartz [mailto:bemasc@webrtc.org] >>> *Sent:* Friday, February 06, 2015 9:49 PM >>> *To:* Tirumaleswar Reddy (tireddy) >>> *Cc:* Justin Uberti; tram@ietf.org; Simon Perreault >>> *Subject:* RE: [tram] FW: New Version Notification for >>> draft-reddy-tram-turn-ipaddress-privacy-00.txt >>> >>> I appreciate the goal of this work. Maybe a slightly different >>> strategy would be more easily accepted in the working group. What if >>> the client could query the server for a list of alternate TURN >>> servers? Then the client could have the option of selecting a server >>> based on geolocation, but the client would not have to convey its >>> privacy goals to the server explicitly. >>> >>> [TR2] Interesting alternative, it has pros and cons that client will >>> not have to convey its privacy goals to server explicitly but if it >>> receives NNN number of alternate servers it will have to try all of >>> them and pick the one which suites its privacy needs (TURN server can >>> probably give additional information on the privacy levels that can be >>> provided by each of the alternate servers to address this problem) >>> >>> -Tiru >>> >>> Inline [TR] >>> >>> *From:*Justin Uberti [mailto:juberti@google.com >>> ] >>> *Sent:* Friday, February 06, 2015 6:21 AM >>> *To:* Tirumaleswar Reddy (tireddy) >>> *Cc:* Benjamin Schwartz; Simon Perreault; tram@ietf.org >>> >>> *Subject:* Re: [tram] FW: New Version Notification for >>> draft-reddy-tram-turn-ipaddress-privacy-00.txt >>> >>> I agree with Simon and Ben in being skeptical about this proposal. >>> >>> The client is the only party which knows exactly what 'privacy' means, >>> and there is no trivial way to serialize this into a single attribute >>> for the TURN server. >>> >>> [TR] We are evaluating how the client can covey its ‘privacy’ needs in >>> this new attribute to the TURN server so that it can take appropriate >>> action and the server responds if the client ‘privacy’ requirement can >>> be met fully or partially. >>> >>> -Tiru >>> >>> As such, I think this decision should be left entirely to the client. >>> >>> On Wed, Feb 4, 2015 at 10:50 AM, Tirumaleswar Reddy (tireddy) >>> > wrote: >>> >>> I agree that the client can do equally well itself, by sending a STUN >>> Binding Request and comparing the response to the TURN server's own IP >>> address. >>> >>> [TR3] The difference this draft brings in is that it helps the TURN >>> server (offered by a global or cloud service) to determine that the >>> client wants privacy and level of privacy required conveyed in the new >>> STUN attribute, the TURN server determines suitable alternate TURN >>> server that can offer the required level of privacy. >>> >>> -Tiru >>> >>> >>> _______________________________________________ >>> 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 Tue Feb 10 07:26:19 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79AD1A03A3 for ; Tue, 10 Feb 2015 07:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 4Co-iiCZkgCu for ; Tue, 10 Feb 2015 07:26:11 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id E46911A00FA for ; Tue, 10 Feb 2015 07:26:10 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0F7D128573 for ; Tue, 10 Feb 2015 15:26:10 +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 F228A28561 for ; Tue, 10 Feb 2015 15:26:09 +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 EEB142056 for ; Tue, 10 Feb 2015 15:26:09 +0000 (GMT) Message-ID: <54DA2311.7030009@akamai.com> Date: Tue, 10 Feb 2015 10:26:09 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "tram@ietf.org" References: <54D8E257.9000300@akamai.com> <913383AAA69FF945B8F946018B75898A355490E9@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A355490E9@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] location privacy considerations for TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 15:26:18 -0000 If you mean real-world data, then I could possibly provide some example numbers for the impact on call setup, but I don't have numbers for the call quality impact because I don't provide a true location privacy service today. The impact of the rendezvous server's location during call setup will have a lot to do with how far off path it is for the individual peer pair. I have seen cases where the one way latency via the rendezvous server is a few hundred msec. IOW, the privacy concern is probably not extending the call setup time all that much. I have a hard time getting excited about this one, though I've got a customer who cares about it. The one way in which it's a problem for performance is that the additional delay to starting the ICE check via the relay can cause the relay path to be rejected as a result of the direct check completing first, even if the relay provides significantly better latency. That issue can be resolved by some of the work going on to improve ICE. The call quality issue is the one that I don't expect there would be much question about, since it's fairly similar to the standard problem statement for use of a relay ... if the relay isn't on-path, then it will negatively impact performance to the degree that it isn't on-path. Client-side implementers probably have a better sense of what kind of latency impact would be observable by the user than I do. --Brandon On 02/09/2015 02:50 PM, Tirumaleswar Reddy (tireddy) wrote: > Do you have any performance numbers to show the impact of the problem ? > > -Tiru > > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Monday, February 09, 2015 10:08 PM >> To: tram@ietf.org >> Subject: [tram] location privacy considerations for TURN >> >> Hi all, >> >> There has been recent discussion about location privacy on the list. One >> approach to location privacy has been to select a relay server that will not >> give away important location information, but one key issue has been how to >> determine whether an allocated relay address meets the peer's location >> privacy requirements. If such a relay server can be identified, then the >> location privacy requirements can be met, but this could sacrifice the user's >> performance expectations. >> >> We have been working on some ideas about how to address these privacy >> concerns by adding a new channel binding mechanism to TURN that does not >> require a peer to know even the relay address of the remote peer. Before I >> try to engage the WG on a possible solution, I first want to get some sense of >> whether I'm on target in the way that I'm framing the problem (location >> privacy vs. performance). >> >> I've included a rough cut of the problem statement below (this seemed >> better than publishing a draft just for the one page of content) and will >> appreciate feedback from the list. Have I clearly stated the problem? Are >> there other ways in which location privacy could negatively impact >> performance? And is anyone else interested in trying to solve this problem >> within the WG? >> >> Thanks, >> --Brandon >> >> ----- >> 1. Introduction >> >> Traversal Using Relay around NAT (TURN) [RFC5766] defines a mechanism >> for establishment of peer-to-peer communication using a data relay >> server. Although not part of the explicit intent of the protocol, a >> TURN relay can also be used in a way that provides enhanced privacy >> by hiding the network geographic location of one or both peers from >> the other peer. However, location privacy considerations can have a >> negative impact on latency, both during call setup and throughout the >> life of the session. >> >> 1.1. Location Privacy During Session Initiation >> >> Peer-to-peer session initiation typically involves relay of an >> invitation via a rendezvous server. The initiating peer sends an >> invitation to the rendezvous server, which relays the invitation to >> the receiving peer for acceptance. Although the rendezvous server's >> role requires it to maintain a registry of peer addresses, location >> privacy demands that it should not send the receiving peer's address >> to the initiating peer until the receiving peer has accepted the >> call. >> >> When direct connectivity between the peers is possible, Interactive >> Connectivity Establishment (ICE) [RFC5245] connectivity checks can >> proceed and complete successfully as soon as the receiving peer has >> received the invitation, since the initiating peer's host and >> reflexive addresses can be delivered to the receiving peer along with >> the invitation. However, when the initiating peer requires a TURN >> relay, the receiving peer's address information must be delivered via >> the rendezvous server with the invitation response in order for the >> initiating peer to send a ChannelBind or CreatePermission request. >> >> Since the rendezvous server is often centrally located, even one-way >> latency between the peers via the rendezvous server can be >> significantly longer than the latency for direct connectivity, >> meaning that initiation of successful peer-to-peer communication can >> take significantly longer when a TURN relay is used, even if the >> relay server is optimally selected for end-to-end performance. >> >> 1.2. Location Privacy and Call Quality >> >> Many peer-to-peer applications (e.g. voice or video calls) are >> sensitive to path latency, with long one-way latencies often leading >> to a negative impact on user experience. For this reason, it can be >> important to select a relay server that is on-path between the peers >> in order to prevent use of the relay from negatively impacting >> latency. Achieving this goal can mean selecting the relay based on >> its relative proximity to the associated peer. For this reason, the >> relay address itself could provide information about the location of >> the peer. In other words, a user who wishes not to disclose her/his >> current location to the remote peer might have to intentionally >> select a TURN relay that is suboptimal for performance. >> ----- >> >> -- >> 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 Tue Feb 10 07:45:40 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8991A047A for ; Tue, 10 Feb 2015 07:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, J_CHICKENPOX_74=0.6, MIME_CHARSET_FARAWAY=2.45, T_RP_MATCHES_RCVD=-0.01] 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 L68MYM8wvtaU for ; Tue, 10 Feb 2015 07:45:33 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1961A0076 for ; Tue, 10 Feb 2015 07:45:32 -0800 (PST) Received: from [192.168.1.3] (unknown [114.248.163.32]) by app1 (Coremail) with SMTP id Z0GX06ArDAByENpU+8xBAg==.32122S2; Tue, 10 Feb 2015 22:06:43 +0800 (CST) Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) From: Aijun Wang X-Mailer: iPhone Mail (12B466) In-Reply-To: <54DA16C0.30506@akamai.com> Date: Tue, 10 Feb 2015 23:45:08 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <42397329-9E02-40FD-95E8-435435644B66@tsinghua.org.cn> References: <54D8E257.9000300@akamai.com> <913383AAA69FF945B8F946018B75898A355490E9@xmb-rcd-x10.cisco.com> <915A8DA0-A081-4564-AFCC-CBDF16F91272@tsinghua.org.cn> <54DA16C0.30506@akamai.com> To: Brandon Williams X-CM-TRANSID: Z0GX06ArDAByENpU+8xBAg==.32122S2 X-Coremail-Antispam: 1U3129KBjvJXoW3uw18Kry3JryxCF4kWr48WFg_yoWDCw17pF WrAa1xKF4kJr4xAwsrtw1qqF1j9rZ5Gr45Xrn8tr18A390vFn3KF17Kw15uFWDGrn5Gr1Y qryj9a9ruwnYvrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVWUJVW8JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUAVWUtjIFyTuYvjfU5BT5DUUUU Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Justin Uberti Subject: Re: [tram] [SPAM] Re: location privacy considerations for TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 15:45:38 -0000 OK, Brandon, thank you for your advices. We are trying modify the previous d= raft, which will try to solve several problems that mentioned in this WG mai= l list.=20 Other responses for your concerns points are described inline below. =46rom Aijun Wang > =D4=DA 2015=C4=EA2=D4=C210=C8=D5=A3=AC22:33=A3=ACBrandon Williams =D0=B4=B5=C0=A3=BA >=20 >> On 02/09/2015 06:44 PM, Aijun Wang wrote: >> If the communication peers use one well known relay addresses, then it >> will conceal its location from its peer. >> Under such architecture, each distributed TURN server will have one >> unique well known address, and the rendezvous server can select one most >> suitable TURN server(located at the most suitable optimal path) based on >> the proximity of the reflex addresses of the two peers, or it can select >> another TURN server if the client want more location privacy than >> performance. >=20 > As soon as you use a publicly available address and disclose it to the oth= er peer, you begin to give away information about your location, especially (= though not exclusively) if the address is selected based on proximity. Proximity is just one principle, the rendezvous server can select other TURN= server for the two peers, based on the service policy that required by the c= ommunication peers. >=20 >> On the other hand, if these TURN servers use one ANYCAST >> well known address,then the privacy and performance can be achieved >> simultaneously. >=20 > You cannot reliably use an ANYCAST address for a long-lived data flow, whi= ch is why TURN auto-discovery redirects the peer to a unicast address in res= ponse to the allocate request. >=20 Why can't? If one of the TURN server failed, the peer can reselect another T= URN server to relay data. DS-Lite is using the ANYCAST method to encapsulate= and decapsulate the IPv4inIPv6 packet, which is also long lived data flow. >>=20 >> If the above mechanism is suitable, then we need another command to bind >> the two peers at the TURN relay server(because each peer send traffic to >> the well known relay address, the TURN server should know where is the >> corresponding peer. We have proposed such solution in draft >> http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ and are trying >> to revise it based on the feedback from our presentation in last IETF >> meeting and the discuss recently in this WG list. >=20 > When the "turnlite" proposal was presented in Honolulu, the WG essentially= said "this is not TURN". At least that was my understanding of the response= . Unless the proposal has been modified so significantly that it is indistin= guishable from the first draft, I would not expect the WG response to change= . I am not trying to discourage you from working on your idea. I'm simply su= ggesting that, since it doesn't really appear to be an update to TURN, this W= G might not be the best forum for the proposal. >=20 This draft has the same aim to achieve as current TURN draft, that is to sol= ve several problems when two peers are behind NAT devices and can't build t= he direct channel between them.=20 We also admire the achievement of current related ICE/TURN draft, but as al= l the TRAMer discussed here, there are still some scenarios that current ICE= /TURN draft can't solve, or solve in one complex design, so why don't we als= o consider another possible viewpoint to solve these problems? Especially in= one lightweight manner? > --Brandon >=20 >>=20 >> This lightweight TURN solution can decouple the TURN function from the >> ICE procedure, alleviate the relay address allocation burden of the TURN >> server, make the TURN function be easily incorporated in some already >> distributed deployed network devices, cover almost all the functions >> provided by current TURN solution. And meet the requirements of local >> privacy preserve and achieve best performance described above. >>=20 >>=20 >>=20 >>=20 >> =46rom Aijun Wang >>=20 >>=20 >> =D4=DA 2015=C4=EA2=D4=C210=C8=D5=A3=AC06:31=A3=ACJustin Uberti > > =D0=B4=B5=C0=A3=BA >>=20 >>> I agree that these goals seem to be at odds with one another, so if >>> you have a proposal to solve both simultaneously I think you are on >>> the right track. >>>=20 >>> On Mon, Feb 9, 2015 at 11:50 AM, Tirumaleswar Reddy (tireddy) >>> > wrote: >>>=20 >>> Do you have any performance numbers to show the impact of the >>> problem ? >>>=20 >>> -Tiru >>>=20 >>>=20 >>> > -----Original Message----- >>> > From: tram [mailto:tram-bounces@ietf.org >>> ] On Behalf Of Brandon Williams >>> > Sent: Monday, February 09, 2015 10:08 PM >>> > To: tram@ietf.org >>> > Subject: [tram] location privacy considerations for TURN >>> > >>> > Hi all, >>> > >>> > There has been recent discussion about location privacy on the >>> list. One >>> > approach to location privacy has been to select a relay server >>> that will not >>> > give away important location information, but one key issue has >>> been how to >>> > determine whether an allocated relay address meets the peer's >>> location >>> > privacy requirements. If such a relay server can be identified, >>> then the >>> > location privacy requirements can be met, but this could >>> sacrifice the user's >>> > performance expectations. >>> > >>> > We have been working on some ideas about how to address these >>> privacy >>> > concerns by adding a new channel binding mechanism to TURN that >>> does not >>> > require a peer to know even the relay address of the remote >>> peer. Before I >>> > try to engage the WG on a possible solution, I first want to get >>> some sense of >>> > whether I'm on target in the way that I'm framing the problem >>> (location >>> > privacy vs. performance). >>> > >>> > I've included a rough cut of the problem statement below (this >>> seemed >>> > better than publishing a draft just for the one page of content) >>> and will >>> > appreciate feedback from the list. Have I clearly stated the >>> problem? Are >>> > there other ways in which location privacy could negatively impact >>> > performance? And is anyone else interested in trying to solve >>> this problem >>> > within the WG? >>> > >>> > Thanks, >>> > --Brandon >>> > >>> > ----- >>> > 1. Introduction >>> > >>> > Traversal Using Relay around NAT (TURN) [RFC5766] defines a >>> mechanism >>> > for establishment of peer-to-peer communication using a data >>> relay >>> > server. Although not part of the explicit intent of the >>> protocol, a >>> > TURN relay can also be used in a way that provides enhanced >>> privacy >>> > by hiding the network geographic location of one or both >>> peers from >>> > the other peer. However, location privacy considerations >>> can have a >>> > negative impact on latency, both during call setup and >>> throughout the >>> > life of the session. >>> > >>> > 1.1. Location Privacy During Session Initiation >>> > >>> > Peer-to-peer session initiation typically involves relay of an >>> > invitation via a rendezvous server. The initiating peer >>> sends an >>> > invitation to the rendezvous server, which relays the >>> invitation to >>> > the receiving peer for acceptance. Although the rendezvous >>> server's >>> > role requires it to maintain a registry of peer addresses, >>> location >>> > privacy demands that it should not send the receiving peer's >>> address >>> > to the initiating peer until the receiving peer has accepted th= e >>> > call. >>> > >>> > When direct connectivity between the peers is possible, >>> Interactive >>> > Connectivity Establishment (ICE) [RFC5245] connectivity >>> checks can >>> > proceed and complete successfully as soon as the receiving >>> peer has >>> > received the invitation, since the initiating peer's host and >>> > reflexive addresses can be delivered to the receiving peer >>> along with >>> > the invitation. However, when the initiating peer requires >>> a TURN >>> > relay, the receiving peer's address information must be >>> delivered via >>> > the rendezvous server with the invitation response in order >>> for the >>> > initiating peer to send a ChannelBind or CreatePermission >>> request. >>> > >>> > Since the rendezvous server is often centrally located, even >>> one-way >>> > latency between the peers via the rendezvous server can be >>> > significantly longer than the latency for direct connectivity, >>> > meaning that initiation of successful peer-to-peer >>> communication can >>> > take significantly longer when a TURN relay is used, even if th= e >>> > relay server is optimally selected for end-to-end performance. >>> > >>> > 1.2. Location Privacy and Call Quality >>> > >>> > Many peer-to-peer applications (e.g. voice or video calls) are >>> > sensitive to path latency, with long one-way latencies often >>> leading >>> > to a negative impact on user experience. For this reason, >>> it can be >>> > important to select a relay server that is on-path between >>> the peers >>> > in order to prevent use of the relay from negatively impacting >>> > latency. Achieving this goal can mean selecting the relay >>> based on >>> > its relative proximity to the associated peer. For this >>> reason, the >>> > relay address itself could provide information about the >>> location of >>> > the peer. In other words, a user who wishes not to disclose >>> her/his >>> > current location to the remote peer might have to intentionally= >>> > select a TURN relay that is suboptimal for performance. >>> > ----- >>> > >>> > -- >>> > 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 >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>>=20 >>>=20 >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >=20 > --=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 Tue Feb 10 08:10:51 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D851A006F for ; Tue, 10 Feb 2015 08:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 6KJdTFnwtbF8 for ; Tue, 10 Feb 2015 08:10:47 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 1D74D1A1A31 for ; Tue, 10 Feb 2015 08:10:00 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0A76E476EA; Tue, 10 Feb 2015 16:10:00 +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 F1185476D5; Tue, 10 Feb 2015 16:09:59 +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 DB0102096; Tue, 10 Feb 2015 16:09:57 +0000 (GMT) Message-ID: <54DA2D55.1020609@akamai.com> Date: Tue, 10 Feb 2015 11:09:57 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Aijun Wang References: <54D8E257.9000300@akamai.com> <913383AAA69FF945B8F946018B75898A355490E9@xmb-rcd-x10.cisco.com> <915A8DA0-A081-4564-AFCC-CBDF16F91272@tsinghua.org.cn> <54DA16C0.30506@akamai.com> <42397329-9E02-40FD-95E8-435435644B66@tsinghua.org.cn> In-Reply-To: <42397329-9E02-40FD-95E8-435435644B66@tsinghua.org.cn> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Justin Uberti Subject: Re: [tram] [SPAM] Re: location privacy considerations for TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 16:10:50 -0000 Let me put it less categorically ... If you want to use ANYCAST in a system that requires state to be maintained, then either you have to reliably share state across all machines that share the ANYCAST address, or you have to be prepared for flows to break when routing drives them to move to machines that do not have the state already. Protocol designers often avoid the state sharing problem by quickly moving the flow to a unicast address, as is done with the proposed TURN ANYCAST discovery mechanism. Switching to ANYCAST addresses for TURN relays in order to provide privacy would be complicated due to the state sharing requirements. --Brandon On 02/10/2015 10:45 AM, Aijun Wang wrote: >> You cannot reliably use an ANYCAST address for a long-lived data flow, which is why TURN auto-discovery redirects the peer to a unicast address in response to the allocate request. >> > > Why can't? If one of the TURN server failed, the peer can reselect another TURN server to relay data. DS-Lite is using the ANYCAST method to encapsulate and decapsulate the IPv4inIPv6 packet, which is also long lived data flow. > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Tue Feb 10 08:52:41 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7F91A90E5 for ; Tue, 10 Feb 2015 08:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrCAwpXnTRiL for ; Tue, 10 Feb 2015 08:52:37 -0800 (PST) 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 159051A90EA for ; Tue, 10 Feb 2015 08:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10034; q=dns/txt; s=iport; t=1423586966; x=1424796566; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cGysvdqyjRXC1034Y+jUfZpcIX1BUYJoVr4c9/Si1gk=; b=mzJxeKOsWshypwZdBIpC3fzJa7lYw+SN09T2ELUc3Yuj77dbqzgn9yIs sEp+wS+jKEp1ZfcGAlbbn62v5PB0GXh+V1yxu60dm4yOUADw2b9fiSXMQ O/xEJ+BmlU90T4QUSD1YVG8vb/pqL1hNK9rB2pOeRw7F2fyvELYYvdikT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwFAJo12lStJA2I/2dsb2JhbABcgwZSWgSCfr1rghwKhXECHIEFQwEBAQEBAXyEDAEBAQQBAQEgEToJDgQCAQgRBAEBAQICBh0DAgICJQsUAQcBCAEBBAESCBOIEg26LpZiAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIY4lFiIGgmIugRQFjTuBZYVihGSOIIM+IoICBRcUgTxvgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,551,1418083200"; d="scan'208";a="394986838" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP; 10 Feb 2015 16:49:25 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1AGnPDq009450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Feb 2015 16:49:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 10 Feb 2015 10:49:24 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt Thread-Index: AdBE/wF1Kl/vMpNLSQ6RfbUlOQjAtQAdrWwAAAkav0A= Date: Tue, 10 Feb 2015 16:49:23 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3669D8BB@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A355495D0@xmb-rcd-x10.cisco.com> <54DA1EEC.7000704@akamai.com> In-Reply-To: <54DA1EEC.7000704@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.66.14] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-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: Tue, 10 Feb 2015 16:52:40 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFtt YWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBGZWJy dWFyeSAxMCwgMjAxNSA4OjM4IFBNDQo+IFRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkp OyB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdHJhbV0gRlc6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtcmVkZHktdHJhbS10dXJuLQ0KPiBpcGFkZHJlc3MtcHJpdmFj eS0wMC50eHQNCj4gDQo+IE9uIDAyLzEwLzIwMTUgMDE6NTggQU0sIFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkgd3JvdGU6DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ IEZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBC cmFuZG9uDQo+ID4+IFdpbGxpYW1zDQo+ID4+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDEwLCAy MDE1IDEyOjU0IEFNDQo+ID4+IFRvOiB0cmFtQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBb dHJhbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPj4gZHJhZnQtcmVkZHkt dHJhbS10dXJuLSBpcGFkZHJlc3MtcHJpdmFjeS0wMC50eHQNCj4gPj4NCj4gPj4gSSdtIG5vdCBz dXJlIHRoYXQgdGhlICJyZXR1cm4gTk5OIiBhcHByb2FjaCBjYW4gYWRkcmVzcyB0aGUgaXNzdWUN Cj4gYW55d2F5Lg0KPiA+PiBJZiB5b3UgdGFrZSB0aGUgY2FzZSBvZiBhIGJyb2FkbHkgZGlzdHJp YnV0ZWQgc3lzdGVtIChlLmcuIGEgc2luZ2xlDQo+ID4+IHN5c3RlbSB3aXRoIHNldmVyYWwgaHVu ZHJlZCBQT1BzLCBmb3IgZXhhbXBsZSksIGhvdyB3aWxsIGl0IGRlY2lkZSB3aGljaA0KPiAiTk5O Ig0KPiA+PiBhbHRlcm5hdGVzIHRvIHByb3ZpZGU/IElmIEkgaGF2ZSAzIHJlYXNvbmFibGUgcmVs YXkgc2VydmVycyBmb3IgeW91cg0KPiA+PiBsb2NhdGlvbiBhbmQgeW91IHdhbnQgMyBhbHRlcm5h dGVzLCBzaG91bGQgSSBpbnRlbnRpb25hbGx5IG5vdCByZXR1cm4NCj4gPj4gdGhlIDMgcmVhc29u YWJsZSBvbmVzPw0KPiA+Pg0KPiA+PiBJZiB0aGUgb25seSBwdXJwb3NlIG9mIHRoaXMgbWV0aG9k IGlzIHByaXZhY3ksIHRoZW4gdGhlIHNlcnZlciBjb3VsZA0KPiA+PiBwaWNrIGEgc2V0IG9mIGFs dGVybmF0ZXMgdGhhdCBpcyBicm9hZGx5IGRpc3RyaWJ1dGVkIGdlb2dyYXBoaWNhbGx5Lg0KPiA+ PiBJdCBjb3VsZCBldmVuIGluZGljYXRlIGEgc2NvcmUgb2Ygc29tZSBzb3J0IHRoYXQgdGVsbHMg dGhlIGNsaWVudCBob3cNCj4gPj4gY2xvc2VseSBjb3JyZWxhdGVkIGVhY2ggcmVsYXkgc2VydmVy IGlzIHRvIHRoZSBjbGllbnQgYWRkcmVzcy4gQnV0IHlvdSBzdGlsbA0KPiBoYXZlIHRoZSB0cnVz dCBpc3N1ZSBoZXJlLg0KPiA+DQo+ID4gVGhlcmUgbXVzdCBiZSB0cnVzdCBiL3cgdGhlIGVuZHBv aW50IGFuZCB0aGUgVFVSTiBzZXJ2ZXIsIHNpbWlsYXIgdG8gdGhlDQo+IHdheSBlbmRwb2ludHMg dHJ1c3RzIEFub255bW91cyBWUE4gc2VydmljZSBwcm92aWRlciAuDQo+ID4NCj4gPj4gSWYgdGhl DQo+ID4+IHNlcnZlciByZXR1cm5lZCBhIGJhZCBjYW5kaWRhdGUgc2V0LCBkaWQgaXQgZG8gc28g YmVjYXVzZSBpdCBkaWRuJ3QNCj4gPj4gaGF2ZSBvcHRpb25zLCBvciBiZWNhdXNlIGl0IGRvZXNu J3Qgd2FudCB0byBnaXZlIHlvdSBsb2NhdGlvbiBwcml2YWN5Pw0KPiA+DQo+ID4gSWYgdGhlIHNl cnZlciBjYW5ub3Qgc3VwcG9ydCBwcml2YWN5IHRoZW4gaXQgc2hvdWxkIG5vdCByZXR1cm4gdGhl IG5ldw0KPiBhdHRyaWJ1dGUgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0Lg0KPiA+DQo+ID4+IEFuZCBp ZiB0aGUNCj4gPj4gYWx0ZXJuYXRlcyBhcmUgZ29vZCwgaG93IHdpbGwgY2xpZW50IHNlbGVjdCBh bHRlcm5hdGVzIG92ZXIgdGltZSB0bw0KPiA+PiBlbnN1cmUgdGhhdCB0aGlzIHNlbGVjdGlvbiBk b2Vzbid0IGdpdmUgZW5vdWdoIGF3YXkgYWJvdXQgd2hlcmUgdGhlDQo+ID4+IGNsaWVudCBpc24n dCB0byBhbGxvdyB5b3UgdG8gZmlndXJlIG91dCB3aGVyZSB0aGUgY2xpZW50IGlzPw0KPiA+DQo+ ID4gRm9yIGV2ZXJ5IGNhbGwgY2xpZW50IG1ha2VzIGEgZGVjaXNpb24gaWYgcHJpdmFjeSBpcyBy ZXF1aXJlZCBvciBub3QsIGVhY2ggdGltZQ0KPiBpdCB3aWxsIGxlYXJuIG5ldyBhbHRlcm5hdGl2 ZXMgZnJvbSB0aGUgVFVSTiBzZXJ2ZXIuDQo+IA0KPiBJIGFncmVlIHRoYXQgYSBtZWNoYW5pc20g bGlrZSB0aGUgb25lIGluIHRoZSBkcmFmdCByZXF1aXJlcyB0cnVzdCBiL3cgdGhlDQo+IGVuZHBv aW50IGFuZCB0aGUgVFVSTiBzZXJ2ZXIuIEkgd2FzIGFyZ3VpbmcgdGhhdCB0aGUgInJldHVybiBO Tk4iDQo+IGFwcHJvYWNoIGhhcyB0aGF0IHNhbWUgbGltaXRhdGlvbiwgYW5kIHRoYXQgaXQgbmVl ZHMgc29tZSBleHBsaWNpdCBpbmRpY2F0aW9uDQo+IG9mIHRoZSBwcml2YWN5IHJlcXVpcmVtZW50 IGluIG9yZGVyIHRvIGtub3cgd2hpY2ggTk5OIGFsdGVybmF0ZXMgdG8gcmV0dXJuLg0KPiBJdCBk b2Vzbid0IHNlZW0gdG8gc2ltcGxpZnkgdGhlIHNvbHV0aW9uLg0KDQpBZ3JlZWQuDQoNCi1UaXJ1 DQoNCj4gDQo+ID4NCj4gPj4NCj4gPj4gSWYgdGhlIGNsaWVudCBoYXMgdG8gc2VsZWN0IHRoZSBy ZWxheSB2ZXJ5IGNhcmVmdWxseSBpbiBvcmRlciB0bw0KPiA+PiBlbnN1cmUgdGhhdCBpdCBnZXRz IHRoZSBwcml2YWN5IGNoYXJhY3RlcmlzdGljcyB0aGF0IGl0IHdhbnRzLCB0aGVuDQo+ID4+IGl0 J3MgcHJvYmFibHkgYmV0dGVyIHRvIHByb3ZpZGUgYSBzZXJ2ZXIgd2l0aCBhIGZpeGVkIGxvY2F0 aW9uIHRoYXQNCj4gPj4gbmV2ZXIgY2hhbmdlcyBubyBtYXR0ZXIgd2hlcmUgeW91J3JlIGxvY2F0 ZWQuIFRoYXQgd2F5LCB5b3UgY2FuDQo+ID4+IGFsd2F5cyBzZWxlY3QgdGhlIHByaXZhY3kgcmVs YXkgd2hlbiB0aGF0J3Mgd2hhdCB5b3Ugd2FudCBhbmQga25vdw0KPiA+PiB0aGF0IHRoZSByZWxh eSdzIGxvY2F0aW9uIHdpbGwgbmV2ZXIgc2F5IHNvbWV0aGluZyB1c2VmdWwgYWJvdXQgeW91IGFs bCBieQ0KPiBpdHNlbGYuDQo+ID4NCj4gPiBUaGlzIG1lY2hhbmlzbSB3b24ndCB3b3JrIGlmIHRo ZSB1c2VyIGlzIHJvYW1pbmcuDQo+IA0KPiBIb3cgZG9lcyBpdCBub3Qgd29yayBpZiB0aGUgdXNl ciBpcyByb2FtaW5nPyBJdCB3b24ndCBnaXZlIGdvb2QgcGVyZm9ybWFuY2UsDQo+IGJ1dCBJIG1h aW50YWluIHRoYXQgcGVyZm9ybWFuY2UgZ29hbHMgYW5kIHByaXZhY3kgZ29hbHMgYXJlIGluIGNv bmZsaWN0IGFzIGxvbmcNCj4gYXMgeW91IG11c3QgZGlzY2xvc2UgdGhlIHJlbGF5IGFkZHJlc3Mg dG8gdGhlIHJlbW90ZSBwZWVyLiBUaGUgcG9pbnQgb2YNCj4gYWx3YXlzIHVzaW5nIHRoZSBzYW1l IHJlbGF5IHNlcnZlciwgZXZlbiB3aGVuIHJvYW1pbmcsIGlzIHRvIGhpZGUgZGV0YWlscw0KPiBh Ym91dCB5b3VyIGxvY2F0aW9uIChzdWNoIGFzIHRoZSBmYWN0IHRoYXQgeW91J3JlIHJvYW1pbmcp Lg0KPiANCj4gLS1CcmFuZG9uDQo+IA0KPiA+DQo+ID4gLVRpcnUNCj4gPg0KPiA+Pg0KPiA+PiAt LUJyYW5kb24NCj4gPj4NCj4gPj4gT24gMDIvMDkvMjAxNSAwMToxMCBQTSwgVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KSB3cm90ZToNCj4gPj4+IElubGluZSBbVFIyXQ0KPiA+Pj4NCj4gPj4+ ICpGcm9tOipCZW5qYW1pbiBTY2h3YXJ0eiBbbWFpbHRvOmJlbWFzY0B3ZWJydGMub3JnXQ0KPiA+ Pj4gKlNlbnQ6KiBGcmlkYXksIEZlYnJ1YXJ5IDA2LCAyMDE1IDk6NDkgUE0NCj4gPj4+ICpUbzoq IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4gPj4+ICpDYzoqIEp1c3RpbiBVYmVydGk7 IHRyYW1AaWV0Zi5vcmc7IFNpbW9uIFBlcnJlYXVsdA0KPiA+Pj4gKlN1YmplY3Q6KiBSRTogW3Ry YW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4+PiBkcmFmdC1yZWRkeS10 cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDAudHh0DQo+ID4+Pg0KPiA+Pj4gSSBhcHByZWNp YXRlIHRoZSBnb2FsIG9mIHRoaXMgd29yay4gIE1heWJlIGEgc2xpZ2h0bHkgZGlmZmVyZW50DQo+ ID4+PiBzdHJhdGVneSB3b3VsZCBiZSBtb3JlIGVhc2lseSBhY2NlcHRlZCBpbiB0aGUgd29ya2lu ZyBncm91cC4gIFdoYXQNCj4gPj4+IGlmIHRoZSBjbGllbnQgY291bGQgcXVlcnkgdGhlIHNlcnZl ciBmb3IgYSBsaXN0IG9mIGFsdGVybmF0ZSBUVVJODQo+ID4+PiBzZXJ2ZXJzPyAgVGhlbiB0aGUg Y2xpZW50IGNvdWxkIGhhdmUgdGhlIG9wdGlvbiBvZiBzZWxlY3RpbmcgYQ0KPiA+Pj4gc2VydmVy IGJhc2VkIG9uIGdlb2xvY2F0aW9uLCBidXQgdGhlIGNsaWVudCB3b3VsZCBub3QgaGF2ZSB0byBj b252ZXkNCj4gPj4+IGl0cyBwcml2YWN5IGdvYWxzIHRvIHRoZSBzZXJ2ZXIgZXhwbGljaXRseS4N Cj4gPj4+DQo+ID4+PiBbVFIyXSBJbnRlcmVzdGluZyBhbHRlcm5hdGl2ZSwgaXQgaGFzIHByb3Mg YW5kIGNvbnMgdGhhdCBjbGllbnQgd2lsbA0KPiA+Pj4gbm90IGhhdmUgdG8gY29udmV5IGl0cyBw cml2YWN5IGdvYWxzIHRvIHNlcnZlciBleHBsaWNpdGx5IGJ1dCBpZiBpdA0KPiA+Pj4gcmVjZWl2 ZXMgTk5OIG51bWJlciBvZiBhbHRlcm5hdGUgc2VydmVycyBpdCB3aWxsIGhhdmUgdG8gdHJ5IGFs bCBvZg0KPiA+Pj4gdGhlbSBhbmQgcGljayB0aGUgb25lIHdoaWNoIHN1aXRlcyBpdHMgcHJpdmFj eSBuZWVkcyAoVFVSTiBzZXJ2ZXINCj4gPj4+IGNhbiBwcm9iYWJseSBnaXZlIGFkZGl0aW9uYWwg aW5mb3JtYXRpb24gb24gdGhlIHByaXZhY3kgbGV2ZWxzIHRoYXQNCj4gPj4+IGNhbiBiZSBwcm92 aWRlZCBieSBlYWNoIG9mIHRoZSBhbHRlcm5hdGUgc2VydmVycyB0byBhZGRyZXNzIHRoaXMNCj4g Pj4+IHByb2JsZW0pDQo+ID4+Pg0KPiA+Pj4gLVRpcnUNCj4gPj4+DQo+ID4+PiBJbmxpbmUgW1RS XQ0KPiA+Pj4NCj4gPj4+ICpGcm9tOipKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29n bGUuY29tDQo+ID4+PiA8bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT5dDQo+ID4+PiAqU2VudDoq IEZyaWRheSwgRmVicnVhcnkgMDYsIDIwMTUgNjoyMSBBTQ0KPiA+Pj4gKlRvOiogVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KQ0KPiA+Pj4gKkNjOiogQmVuamFtaW4gU2Nod2FydHo7IFNpbW9u IFBlcnJlYXVsdDsgdHJhbUBpZXRmLm9yZw0KPiA+Pj4gPG1haWx0bzp0cmFtQGlldGYub3JnPg0K PiA+Pj4gKlN1YmplY3Q6KiBSZTogW3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yDQo+ID4+PiBkcmFmdC1yZWRkeS10cmFtLXR1cm4taXBhZGRyZXNzLXByaXZhY3ktMDAudHh0 DQo+ID4+Pg0KPiA+Pj4gSSBhZ3JlZSB3aXRoIFNpbW9uIGFuZCBCZW4gaW4gYmVpbmcgc2tlcHRp Y2FsIGFib3V0IHRoaXMgcHJvcG9zYWwuDQo+ID4+Pg0KPiA+Pj4gVGhlIGNsaWVudCBpcyB0aGUg b25seSBwYXJ0eSB3aGljaCBrbm93cyBleGFjdGx5IHdoYXQgJ3ByaXZhY3knDQo+ID4+PiBtZWFu cywgYW5kIHRoZXJlIGlzIG5vIHRyaXZpYWwgd2F5IHRvIHNlcmlhbGl6ZSB0aGlzIGludG8gYSBz aW5nbGUNCj4gPj4+IGF0dHJpYnV0ZSBmb3IgdGhlIFRVUk4gc2VydmVyLg0KPiA+Pj4NCj4gPj4+ IFtUUl0gV2UgYXJlIGV2YWx1YXRpbmcgaG93IHRoZSBjbGllbnQgY2FuIGNvdmV5IGl0cyDigJhw cml2YWN54oCZIG5lZWRzDQo+ID4+PiBpbiB0aGlzIG5ldyBhdHRyaWJ1dGUgdG8gdGhlIFRVUk4g c2VydmVyIHNvIHRoYXQgaXQgY2FuIHRha2UNCj4gPj4+IGFwcHJvcHJpYXRlIGFjdGlvbiBhbmQg dGhlIHNlcnZlciByZXNwb25kcyBpZiB0aGUgY2xpZW50IOKAmHByaXZhY3nigJkNCj4gPj4+IHJl cXVpcmVtZW50IGNhbiBiZSBtZXQgZnVsbHkgb3IgcGFydGlhbGx5Lg0KPiA+Pj4NCj4gPj4+IC1U aXJ1DQo+ID4+Pg0KPiA+Pj4gQXMgc3VjaCwgSSB0aGluayB0aGlzIGRlY2lzaW9uIHNob3VsZCBi ZSBsZWZ0IGVudGlyZWx5IHRvIHRoZSBjbGllbnQuDQo+ID4+Pg0KPiA+Pj4gT24gV2VkLCBGZWIg NCwgMjAxNSBhdCAxMDo1MCBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KPiA+Pj4g PHRpcmVkZHlAY2lzY28uY29tIDxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+PiB3cm90ZToNCj4g Pj4+DQo+ID4+PiBJIGFncmVlIHRoYXQgdGhlIGNsaWVudCBjYW4gZG8gZXF1YWxseSB3ZWxsIGl0 c2VsZiwgYnkgc2VuZGluZyBhDQo+ID4+PiBTVFVOIEJpbmRpbmcgUmVxdWVzdCBhbmQgY29tcGFy aW5nIHRoZSByZXNwb25zZSB0byB0aGUgVFVSTiBzZXJ2ZXIncw0KPiA+Pj4gb3duIElQIGFkZHJl c3MuDQo+ID4+Pg0KPiA+Pj4gW1RSM10gVGhlIGRpZmZlcmVuY2UgdGhpcyBkcmFmdCBicmluZ3Mg aW4gaXMgdGhhdCBpdCBoZWxwcyB0aGUgVFVSTg0KPiA+Pj4gc2VydmVyIChvZmZlcmVkIGJ5IGEg Z2xvYmFsIG9yIGNsb3VkIHNlcnZpY2UpIHRvIGRldGVybWluZSB0aGF0IHRoZQ0KPiA+Pj4gY2xp ZW50IHdhbnRzIHByaXZhY3kgYW5kIGxldmVsIG9mIHByaXZhY3kgcmVxdWlyZWQgY29udmV5ZWQg aW4gdGhlDQo+ID4+PiBuZXcgU1RVTiBhdHRyaWJ1dGUsIHRoZSBUVVJOIHNlcnZlciBkZXRlcm1p bmVzIHN1aXRhYmxlIGFsdGVybmF0ZQ0KPiA+Pj4gVFVSTiBzZXJ2ZXIgdGhhdCBjYW4gb2ZmZXIg dGhlIHJlcXVpcmVkIGxldmVsIG9mIHByaXZhY3kuDQo+ID4+Pg0KPiA+Pj4gLVRpcnUNCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4+IHRyYW0gbWFpbGluZyBsaXN0DQo+ID4+PiB0cmFtQGlldGYub3JnIDxtYWls dG86dHJhbUBpZXRmLm9yZz4NCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHJhbQ0KPiA+Pj4NCj4gPj4NCj4gPj4gLS0NCj4gPj4gQnJhbmRvbiBXaWxsaWFtczsg U2VuaW9yIFByaW5jaXBhbCBTb2Z0d2FyZSBFbmdpbmVlciBFbWVyZ2luZw0KPiA+PiBQcm9kdWN0 cyBFbmdpbmVlcmluZzsgQWthbWFpIFRlY2hub2xvZ2llcyBJbmMuDQo+ID4+DQo+ID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHRyYW0gbWFp bGluZyBsaXN0DQo+ID4+IHRyYW1AaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90cmFtDQo+IA0KPiAtLQ0KPiBCcmFuZG9uIFdpbGxpYW1zOyBTZW5p b3IgUHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2luZWVyIEVtZXJnaW5nIFByb2R1Y3RzDQo+IEVuZ2lu ZWVyaW5nOyBBa2FtYWkgVGVjaG5vbG9naWVzIEluYy4NCg== From nobody Tue Feb 10 16:48:11 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8351A06FD for ; Tue, 10 Feb 2015 16:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 EqxY2fR5kKxT for ; Tue, 10 Feb 2015 16:48:02 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 129B21A03A8 for ; Tue, 10 Feb 2015 16:47:59 -0800 (PST) Received: from ctbriwangaij (unknown [124.127.116.138]) by app1 (Coremail) with SMTP id Z0GX06DLvACYj9pU7FM_Ag==.50886S2; Wed, 11 Feb 2015 07:09:14 +0800 (CST) From: "Aijun Wang" To: "'Simon Perreault'" References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <000001d03f8a$010c89a0$03259ce0$@org.cn> <007401d04024$0ee0d3c0$2ca27b40$@org.cn> <37F58EB6-2CAE-4CA5-B286-D622DC33B139@cisco.com> <00ed01d04110$1ca32340$55e969c0$@org.cn> <5F8B3F40-2232-4827-8904-2562CF447497@cisco.com> <000c01d0440b$483c1310$d8b43930$@org.cn> In-Reply-To: Date: Wed, 11 Feb 2015 08:47:46 +0800 Message-ID: <003001d04594$5bbdb4e0$13391ea0$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01D045D7.69E0F4E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdBEYFLFjw4G7g+CShmCcIZQR/AowwBMycyw Content-Language: zh-cn X-CM-TRANSID: Z0GX06DLvACYj9pU7FM_Ag==.50886S2 X-Coremail-Antispam: 1U3129KBjvdXoW7XF1kGF1xWF4fJrW5Kw1DGFg_yoW3Xrg_u3 W3XFyxCr45Jayxt39xJF4rWryag3y8Zw18J3yDGw1xK34kZF15Zas5GrykAry8J3s29F9r Gr9a9r129r9xujkaLaAFLSUrUUUUjbIjqfuFe4nvWSU5nxnvy29KBjDU0xBIdaVrnpxYjs xI4VWUJwAqx4xG67k08I80eVW8JVW5JwAqx4xG6c804VAFz4xC04v7Mc02F40Ew4AK048I F2xKxVWUJVW8JwAqx4xG6xAIxVCFxsxG0wAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1I0E4x 80FVCIwcAKzIAtM7C26IkvcIIF6IxKo4kEV4ylYx0E74AGY7Cv6cx26r47MxkF7I0En4kS 14v26r126r1DMI8E67AF67kF1VAFwI0_JF0_JwUI43ZEXa7VUbhSdDUUUUU== Archived-At: Cc: "'Pal Martinsen \(palmarti\)'" , tram@ietf.org, 'Oleg Moskalenko' , "'Tirumaleswar Reddy \(tireddy\)'" , 'Brandon Williams' Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 11 Feb 2015 00:48:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0031_01D045D7.69E0F4E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 From: Simon Perreault [mailto:sperreault@jive.com]=20 Sent: Monday, February 09, 2015 9:34 PM To: Aijun Wang Cc: Pal Martinsen (palmarti); Oleg Moskalenko; Tirumaleswar Reddy = (tireddy); Brandon Williams; tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt =20 It is well known that using a single TURN server may not always work for = NATs that have arbitrary IP address pooling behaviour (see REQ-2 in RFC = 4787). In that case it is necessary that two TURN servers be used. This = was a deliberate design decision favouring simplicity over completeness. =20 Then it is needed in the current turn-bis draft to cover this = scenarios(can we named TURN2TURN?) and give the guidance procedures to = overcome this problem. =20 Simon ------=_NextPart_000_0031_01D045D7.69E0F4E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

From:= Simon = Perreault [mailto:sperreault@jive.com]
Sent: Monday, February = 09, 2015 9:34 PM
To: Aijun Wang
Cc: Pal Martinsen = (palmarti); Oleg Moskalenko; Tirumaleswar Reddy (tireddy); Brandon = Williams; tram@ietf.org
Subject: Re: [tram] I-D Action: = draft-ietf-tram-turnbis-01.txt

 


It is well known that using a = single TURN server may not always work for NATs that have arbitrary IP = address pooling behaviour (see REQ-2 in RFC 4787). In that case it is = necessary that two TURN servers be used. This was a deliberate design = decision favouring simplicity over completeness.

 

Then it is needed in the current turn-bis draft to cover this = scenarios(can we named TURN2TURN?) and give the guidance procedures to = overcome this problem.

 

Simon

------=_NextPart_000_0031_01D045D7.69E0F4E0-- From nobody Tue Feb 10 17:35:38 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389D31A1B18 for ; Tue, 10 Feb 2015 17:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_72=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlKQ4vxaIiOQ for ; Tue, 10 Feb 2015 17:35:33 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 84C791A1B0B for ; Tue, 10 Feb 2015 17:35:32 -0800 (PST) Received: from ctbriwangaij (unknown [124.127.116.138]) by app1 (Coremail) with SMTP id Z0GX06CbAx66mtpUs8xDAg==.52367S2; Wed, 11 Feb 2015 07:56:43 +0800 (CST) From: "Aijun Wang" To: "'Pal Martinsen \(palmarti\)'" References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <000001d03f8a$010c89a0$03259ce0$@org.cn> <007401d04024$0ee0d3c0$2ca27b40$@org.cn> <37F58EB6-2CAE-4CA5-B286-D622DC33B139@cisco.com> <00ed01d04110$1ca32340$55e969c0$@org.cn> <5F8B3F40-2232-4827-8904-2562CF447497@cisco.com> <000c01d0440b$483c1310$d8b43930$@org.cn> <438D1571-86AF-4E48-B606-2191348617CE@cisco.com> In-Reply-To: <438D1571-86AF-4E48-B606-2191348617CE@cisco.com> Date: Wed, 11 Feb 2015 09:35:17 +0800 Message-ID: <000601d0459a$fdb0b1c0$f9121540$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01D045DE.0BD3F1C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQPEw3iE7SBHjBP02Pt2UimDWYDJze//0AgAAJBACAASsYAIAAf8SAgADkaWCAAKRNgIAFVvSQgADloYCAAjp8oA== Content-Language: zh-cn X-CM-TRANSID: Z0GX06CbAx66mtpUs8xDAg==.52367S2 X-Coremail-Antispam: 1U3129KBjvJXoW3Xr4fJryxZrykuF4rXryrZwb_yoWxGrWfpF ZxXw17Kr1kJrnFyw4kAr1UXFyrZrWkJ3W3Gr15Gr9Yk398AFyS9rWakw4FkFWUWr9Yqw1Y vr1j9r4rCFyrAaDanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjHCb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Gr0_Xr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r1j6r4UM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwCY1x0262kK e7AKxVWUAVWUtwC2zVAF1VAY17CE14v26r126r1D0xZFpf9x0JUBBT5UUUUU= Archived-At: Cc: 'Oleg Moskalenko' , "'Tirumaleswar Reddy \(tireddy\)'" , 'Brandon Williams' , tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 11 Feb 2015 01:35:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01D045DE.0BD3F1C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen = (palmarti) Sent: Monday, February 09, 2015 4:58 PM To: Aijun Wang Cc: Oleg Moskalenko; Brandon Williams; Tirumaleswar Reddy (tireddy); = tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt =20 =20 I think the idea is to mimic how a =E2=80=9Cgood NAT=E2=80=9D would = work.=20 =20 This behaviour is needed for ICE to work. Typical you wold set = permissions on you TURN server to allow traffic from the remote RFLX and = RELAY addresses. Since the remote agent probably learnt his RFLX address = when allocating a RELAY address on his TURN server, the connectivity = checks reaching your TURN server might come from a different port on the = remote side NAT then what he signalled as a RFLX candidate in the SDP. =20 [Aijun] The remote peer will always use one different port to connect = the other side. Then current permission mechanism is somehow loose and = can easily be bypassed. And on the other hand, if the remote peer is = given one new RLFX address(ip address part is also different), then = current permission mechanism will block the real data that came from the = desired peer. =20 Section 17.2 explains this a bit more. But some more text in TURNbis = explaining that setting permissions with would break ICE might come in = handy. Tiru, any thoughts? =20 =20 When the CGN(Carrier Grade NAT) are deployed by the service provider, = many hosts may share one public addresses. Then in such environment, the = client is prone to be attacked by hosts that under the same CGN = coverage? The TURN server will also relay many traffic that is not the = client=E2=80=99s desirable data. =20 I am not very familiar with how a CGN NAT would differ from a = =E2=80=9Cnormal=E2=80=9D NAT in ICE/TURN scenarios. The answers below = might reflect that.=20 [Aijun] The CGN NATs are normally deployed at the exit of MAN(Metro = Area Network) or located inside the BRAS device, all the hosts under one = CGN NAT will share one public IP address pool, then these hosts are very = likely be assigned one same IP address, but use different TCP/UDP port. =20 Also in such situation, even with the cooperation of TURN and ICE, there = will likely be failure for the communication between two hosts, = lets=E2=80=99 consider the following diagram: A---------EDM NAT 1-------------TURN Server--------EDM NAT = 2(CGN)------------------------B =20 1. Let=E2=80=99s suppose A=E3=80=81B Send ICE packet to each other and = punch hole in the EDM NAT 1 and EDM NAT 2(this process should be added = in current draft = = http://tools.ietf.org/html/draft-ietf-tram-turnbis-02#section-10.2) Isn=E2=80=99t this described in RFC5245? This is how ICE does it RFLX to = RFLX checks? Is the point that if two CGN NATs are involved ICE would = always fail in the RFLX to RFLX scenario, and have to fall back to using = TURN? (Again, I do not know how CGN NATS operate) =20 [Aijun]: This step is actually the process of ICE. For completeness, I = think the turn-bis draft should mentioned it here, or else some TURN = packet can=E2=80=99t pass through the NAT devices. CGN NAT can operate = in different mode, for example in =E2=80=9CFullCone=E2=80=9D mode, or in = =E2=80=9CSymmetric=E2=80=9D mode. In the latter mode, it behaves like = one EDM NAT. =20 2. A send =E2=80=9CSendIndicatiion=E2=80=9D to TURN Server, TURN Server = send UDP packet to B, using A=E2=80=99s Relay Address(RA) as the source = address. 3. B will send response UDP packet to TURN Server=EF=BC=8Cuse RA as the = destination address. When one EDM NAT lies between the TURN server and = host B, TURN Server will see this response UDP packet come from one new = reflex address(we call XB=E2=80=99), not the reflex address(we call XB) = when B send binding request to TURN Server=E2=80=99s well-known address. You are forgetting that as part of ICE B will also send a connectivity = check towards RA. This should open up the pinhole in EDM NAT 2.=20 [Aijun]: it is true, I had assumed this step will be completed in step1. = The problem of step 2 is that B get one new RFLX address, XB=E2=80=99 4. So, if the IP address portion of XB=E2=80=99 is same as that of XB, = this packet will be relayed by TURN Server; if not, this packet will = dropped by TURN Server. This will lead to the communication failure = between A and B. =20 How do you think about this scenarios? =20 ICE will fix this. Remember A and B have exchanged all candidates and = crated a similar checklist that will run simultaneously form both sides. = Some packets will be blocked at the remote NAT, but they still have = opened up a pinhole on the local NAT. So with some synchronisation and = retransmits al the necessary ports will be opened up. In ICE there is = also the concept of peer RFLX addresses that the agents learn when they = do the connectivity checks. Understanding how those work is probably = important to understand how ICE solves your above scenario. Also keep in = mind that the connectivity checks also are =E2=80=9Ctunnelled=E2=80=9D = via the TURN server and appears to be sent by the RELAY address. =20 [Aijun]: So this is more complicated. Normally, every peer will get its = RFLX address via send STUN packet to the STUN server, and each peer will = exchange its RFLX addresses to the peer via SDP offer/response. The RFLX = address that gotten from the connectivity check is not authenticated, = and can=E2=80=99t be trust and used as the peer RFLX. =20 =20 Or is your intention to fix up TURN so it is independent of ICE. In that = case it would be interesting to hear more about your use case and = motivation for doing that.=20 =20 [Aijun]. Yeah, we are trying proposal one lightweight TURN solution in = coming IETF meeting. We have submitted the first version to this WG and = make a presentation in the Honolulu meeting. Maybe we did not describe = the solution very clearly in the first version, so did not get very = encouraging feedback. We are trying to revise it now.=20 =20 Wish will get more help from your commends later then. =20 .-. P=C3=A5l-Erik =20 =20 =20 =20 From: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]=20 Sent: Thursday, February 05, 2015 5:44 PM To: Aijun Wang Cc: Oleg Moskalenko; Brandon Williams; Tirumaleswar Reddy (tireddy); = tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt =20 Ok, I will try to explain. Would be nice if some others on the list can = verify what I say is correct. =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 ------=_NextPart_000_0007_01D045DE.0BD3F1C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen = (palmarti)
Sent: Monday, February 09, 2015 4:58 = PM
To: Aijun Wang
Cc: Oleg Moskalenko; Brandon = Williams; Tirumaleswar Reddy (tireddy); tram@ietf.org
Subject: = Re: [tram] I-D Action: = draft-ietf-tram-turnbis-01.txt

 

 

I think the idea is to mimic how a = =E2=80=9Cgood NAT=E2=80=9D would = work. 

 

This behaviour is needed for ICE to = work. Typical you wold set permissions on you TURN server to allow = traffic from the remote RFLX and RELAY addresses. Since the remote agent = probably learnt his RFLX address when allocating a RELAY address on his = TURN server, the connectivity checks reaching your TURN server might = come from a different port on the remote side NAT then what he signalled = as a RFLX candidate in the SDP.

 

[Aijun] The remote peer will always use one different port to connect = the other side. Then current permission mechanism is somehow loose and = can easily be bypassed. And on the other hand, if the remote peer is = given one new RLFX address(ip address part is also different), then = current permission mechanism will block the real data that came from the = desired peer.

 

Section 17.2 explains this a bit = more. But some more text in TURNbis explaining that setting permissions = with would break ICE might come in handy. Tiru, any = thoughts?

 

 

When the CGN(Carrier Grade NAT) are deployed by the service provider, = many hosts may share one public addresses. Then in such environment, the = client is prone to be attacked by hosts that under the same CGN = coverage? The TURN server will also relay many traffic that is not the = client=E2=80=99s  desirable data.

 

I am not very familiar with how a = CGN NAT would differ from a =E2=80=9Cnormal=E2=80=9D NAT in ICE/TURN = scenarios. The answers below might reflect that. 
[Aijun] =C2=A0The CGN NATs are normally deployed at the exit of = MAN(Metro Area Network) or located inside the BRAS device, all the hosts = under one CGN NAT will share one public IP address pool, then these = hosts are very likely be assigned one same IP address, but use different = TCP/UDP port.

 

Also in such situation, even with the cooperation of TURN and ICE, = there will likely be failure for the communication between two hosts, = lets=E2=80=99 consider the following diagram:

A---------EDM NAT 1-------------TURN Server--------EDM NAT = 2(CGN)------------------------B

 

1. Let=E2=80=99s suppose A=E3=80=81B Send ICE packet to each other and punch hole in the EDM NAT 1 and =
EDM NAT 2(this process should be added in current draft http://tools.ietf.org/html/draft-ietf-tram-turnbis=
-02#section-10.2)

Isn=E2=80=99t this described in = RFC5245? This is how ICE does it RFLX to RFLX checks? Is the point that = if two CGN NATs are involved ICE would always fail in the RFLX to RFLX = scenario, and have to fall back to using TURN? (Again, I do not know how = CGN NATS operate)

 

[Aijun]: This step is actually the process of ICE. For completeness, = I think the turn-bis draft should mentioned it here, or else some TURN = packet =C2=A0can=E2=80=99t pass through the NAT devices. CGN NAT can = operate in different mode, for example in =E2=80=9CFullCone=E2=80=9D = mode, or in =E2=80=9CSymmetric=E2=80=9D mode. In the latter mode, it = behaves like one EDM NAT.

 

2. A send =E2=80=9CSendIndicatiion=E2=80=9D to TURN Server, TURN = Server send UDP packet to B, using A=E2=80=99s Relay Address(RA) as the = source address.

3. B will send response UDP packet to TURN Server=EF=BC=8Cuse RA as the destination address. When one EDM NAT lies between the = TURN server and host B, TURN Server will see this response UDP packet = come from one new reflex address(we call XB=E2=80=99), not the reflex = address(we call XB) when B send binding request to TURN Server=E2=80=99s = well-known address.

You are forgetting that as part of = ICE B will also send a connectivity check towards RA. This should open = up the pinhole in EDM NAT 2. 

[Aijun]: it is true, I had assumed this step will be completed in = step1. The problem of step 2 is that B get one new RFLX address, = XB=E2=80=99



4. So, if the IP address portion of XB=E2=80=99 is same as that of = XB, this packet will be relayed by TURN Server; if not, this packet will = dropped by TURN Server. This will lead to the communication failure = between A and B.

 

How do you think about this scenarios?

 

ICE will fix this. Remember A and B = have exchanged all candidates and crated a similar checklist that will = run simultaneously form both sides. Some packets will be blocked at the = remote NAT, but they still have opened up a pinhole on the local NAT. So = with some synchronisation and retransmits al the necessary ports will be = opened up. In ICE there is also the concept of peer RFLX addresses that = the agents learn when they do the connectivity checks. Understanding how = those work is probably important to understand how ICE solves your above = scenario. Also keep in mind that the connectivity checks also are = =E2=80=9Ctunnelled=E2=80=9D via the TURN server and appears to be sent = by the RELAY address.

 

[Aijun]: So this is more complicated. Normally, every peer will get = its RFLX address via send STUN packet to the STUN server, and each peer = will exchange its RFLX addresses to the peer via SDP offer/response. The = RFLX address that gotten from the connectivity check is not = authenticated, and can=E2=80=99t be trust and used as the peer RFLX. = =C2=A0=C2=A0

 

Or is your intention to fix up TURN = so it is independent of ICE. In that case it would be interesting to = hear more about your use case and motivation for doing = that. 

 

[Aijun]. Yeah, we are trying proposal one lightweight TURN solution = in coming IETF meeting. We have submitted the first version to this WG = and make a presentation in the Honolulu meeting. =C2=A0Maybe we did not = describe the solution very clearly in the first version, so did not get = very encouraging feedback. We are trying to revise it now. =

 

Wish will get more help from your commends later then. = =C2=A0

.-.

P=C3=A5l-Erik

 

 



 

 

From:=  Pal = Martinsen (palmarti) [mailto:palmarti@cisco.com] 
Sent: Thursday, February 05, 2015 = 5:44 PM
To: Aijun Wang
Cc: Oleg Moskalenko; Brandon = Williams; Tirumaleswar Reddy (tireddy); tram@ietf.org
Subject: Re: [tram] I-D Action: = draft-ietf-tram-turnbis-01.txt

 

Ok, I will try to explain. Would be = nice if some others  on the list can verify what I say is = correct.

 

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

 

------=_NextPart_000_0007_01D045DE.0BD3F1C0-- From nobody Wed Feb 11 05:29:37 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978C01A020B for ; Wed, 11 Feb 2015 05:29:33 -0800 (PST) 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 qOMSAB_0CfcP for ; Wed, 11 Feb 2015 05:29:31 -0800 (PST) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190381A88E0 for ; Wed, 11 Feb 2015 05:29:25 -0800 (PST) Received: by labhs14 with SMTP id hs14so2901205lab.1 for ; Wed, 11 Feb 2015 05:29:23 -0800 (PST) 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=T76yqt24CgF1pjwJVoRpQ1xYqHmtoeTU56j0VWg68tI=; b=OCt2xUZ5sVhzBYWbT4UFy9nNc+nnBQJMhineOZOepSHC/W95OTCCq5ZrMB3stWvnCH /clRuzufXgsmIp06CCVauuDyLLjClXzgecrl6ZHT80nrAs5e3UjdPzJJ3clPqtuQtwaK UEG6lWUWKaP0s62RsaqEPpaCQM01BEPJQWNpmW2/6p7s9Dn0WFzRwaHgyKZJV4io5u7G jtt3T6ul/ti6hY+Nbql34Hg8mbNKdKKSoq7D/K0n//L+WOVZ20FkXm1SjnLyHT4NX9U0 Pro8tmwPqfgrF7G5d5oPV++zese6/ji50EM0cTfy/nwuMi9Sc3Fcvnq+v2ZkRvnRhIoi FDiQ== X-Gm-Message-State: ALoCoQmYGhWvaVRJ5+e7PBwhP9o4ucKcYJgV0xrmantq8Tg6KDLBLQWpj/MReshoWkNTDEJ8kDwN MIME-Version: 1.0 X-Received: by 10.112.126.98 with SMTP id mx2mr27723606lbb.84.1423661363452; Wed, 11 Feb 2015 05:29:23 -0800 (PST) Received: by 10.25.205.135 with HTTP; Wed, 11 Feb 2015 05:29:23 -0800 (PST) In-Reply-To: <003001d04594$5bbdb4e0$13391ea0$@org.cn> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <000001d03f8a$010c89a0$03259ce0$@org.cn> <007401d04024$0ee0d3c0$2ca27b40$@org.cn> <37F58EB6-2CAE-4CA5-B286-D622DC33B139@cisco.com> <00ed01d04110$1ca32340$55e969c0$@org.cn> <5F8B3F40-2232-4827-8904-2562CF447497@cisco.com> <000c01d0440b$483c1310$d8b43930$@org.cn> <003001d04594$5bbdb4e0$13391ea0$@org.cn> Date: Wed, 11 Feb 2015 08:29:23 -0500 Message-ID: From: Simon Perreault To: Aijun Wang Content-Type: multipart/alternative; boundary=001a11c374b8d978cc050ecffd1b Archived-At: Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , Oleg Moskalenko , "Tirumaleswar Reddy \(tireddy\)" , Brandon Williams Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-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, 11 Feb 2015 13:29:33 -0000 --001a11c374b8d978cc050ecffd1b Content-Type: text/plain; charset=UTF-8 On Tue, Feb 10, 2015 at 7:47 PM, Aijun Wang wrote: > It is well known that using a single TURN server may not always work for > NATs that have arbitrary IP address pooling behaviour (see REQ-2 in RFC > 4787). In that case it is necessary that two TURN servers be used. This was > a deliberate design decision favouring simplicity over completeness. > > > > Then it is needed in the current turn-bis draft to cover this > scenarios(can we named TURN2TURN?) and give the guidance procedures to > overcome this problem. > 1. Please send text! 2. Note that the protocols are not actually "missing" anything to cover this scenario. Although I agree it would be nice to give an informative example showing how things fall into place. Simon --001a11c374b8d978cc050ecffd1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Feb 10, 2015 at 7:47 PM, Aijun Wang <wangaijun@tsinghua.= org.cn> wrote:

It is well known that usin= g a single TURN server may not always work for NATs that have arbitrary IP = address pooling behaviour (see REQ-2 in RFC 4787). In that case it is neces= sary that two TURN servers be used. This was a deliberate design decision f= avouring simplicity over completeness.

=C2=A0

Then it is needed in the current turn-bis draft to cover this scenari= os(can we named TURN2TURN?) and give the guidance procedures to overcome th= is problem.


1. Please send text!

2. Note that th= e protocols are not actually "missing" anything to cover this sce= nario. Although I agree it would be nice to give an informative example sho= wing how things fall into place.

=
Simon
--001a11c374b8d978cc050ecffd1b-- From nobody Thu Feb 12 15:31:04 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840781A014D for ; Thu, 12 Feb 2015 15:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.088 X-Spam-Level: X-Spam-Status: No, score=-4.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 URMbZh-anNKJ for ; Thu, 12 Feb 2015 15:30:57 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFF61A01EA for ; Thu, 12 Feb 2015 15:30:57 -0800 (PST) Received: by iecar1 with SMTP id ar1so15847356iec.11 for ; Thu, 12 Feb 2015 15:30:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=P2CDi6DsiSlgyZz7Uy/xlhKT1kvaFa2uJTNurD9kykA=; b=W6j50JTEyKccmZXxaDQ7qcSrAyIBtxWrbonwlWs09uzUYEZeACOikH2K4KtLl+iH6P FzoHD4uw9Qnp864TUOfhFnX6vAvTa2TPo34jfCtSLp5LCHV/2tQ+2FqGZW3eaDMdJ1Ev oYm9dlBLCVcFj/GPuNBeA9lP53kBZUkrN0wP+M82JAkrL6BcsPFl8GhPTMe2K7TG2VGd vTUjiUUuO8uAj9rFieXldbaagRqajsIYKKRpKihxDKPMCdPE7qbIzLrCzLJ0DQdH4DoN d4Uma+SNtq6up/QZIRhTtyIJlyl20unxM3pSWtR94HklRaRww3Lx7eRohINkj0fpRnN9 IzxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=P2CDi6DsiSlgyZz7Uy/xlhKT1kvaFa2uJTNurD9kykA=; b=I+nWUqieie15lEx1t6qVQErADud2feNklLcqm9cO6RDZP5uoyZvkEXTUiqrT3xRnN5 p64RBzmhDzbYTwPP90w0khxB9Q9uAEbp1N6LVej5fmA8COzCuEMhf8NtnIBAkzI4n16A pF1ebxTXoF9UMHCCMYKoibgWAy8x2F+5FCqA3ZcDNKtfVBlT2jFahsCOc+XekyQ6HXNs SsNCg5MDAZ3S57VeC4HOqGMcBbEegq3lSyKJLPkLKk4CPdAKkI/CCmx8wUQ1VgOxS+JY ZOaLbTmmjfgCzVNIyq3Kj+7X+24bksFK4L9BwVDABiX7SBiapp4ruyPDcc8iheXPwmAg PLtA== X-Gm-Message-State: ALoCoQkIfiVP/Vpf4F8vjbxZQO6/xprMVqAQakxVpf1kJjiVL7YDq+0UDL7pcKwVLMw46p+6+Vx0 X-Received: by 10.50.114.71 with SMTP id je7mr74259igb.14.1423783856347; Thu, 12 Feb 2015 15:30:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.66 with HTTP; Thu, 12 Feb 2015 15:30:36 -0800 (PST) In-Reply-To: <54DA2311.7030009@akamai.com> References: <54D8E257.9000300@akamai.com> <913383AAA69FF945B8F946018B75898A355490E9@xmb-rcd-x10.cisco.com> <54DA2311.7030009@akamai.com> From: Justin Uberti Date: Thu, 12 Feb 2015 15:30:36 -0800 Message-ID: To: Brandon Williams Content-Type: multipart/alternative; boundary=047d7b2e3d06feb715050eec8271 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] location privacy considerations for TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 23:31:01 -0000 --047d7b2e3d06feb715050eec8271 Content-Type: text/plain; charset=UTF-8 Given that the mouth-to-ear target is 150ms (ITU recommendation), and the impact of selecting a non-local TURN server can easily be 50 ms (e.g. routing to us-central instead of us-west), it's pretty clear that the additional latency can be fatal regarding whether the application is able to hit the target or not. On Tue, Feb 10, 2015 at 7:26 AM, Brandon Williams < brandon.williams@akamai.com> wrote: > If you mean real-world data, then I could possibly provide some example > numbers for the impact on call setup, but I don't have numbers for the call > quality impact because I don't provide a true location privacy service > today. > > The impact of the rendezvous server's location during call setup will have > a lot to do with how far off path it is for the individual peer pair. I > have seen cases where the one way latency via the rendezvous server is a > few hundred msec. IOW, the privacy concern is probably not extending the > call setup time all that much. I have a hard time getting excited about > this one, though I've got a customer who cares about it. The one way in > which it's a problem for performance is that the additional delay to > starting the ICE check via the relay can cause the relay path to be > rejected as a result of the direct check completing first, even if the > relay provides significantly better latency. That issue can be resolved by > some of the work going on to improve ICE. > > The call quality issue is the one that I don't expect there would be much > question about, since it's fairly similar to the standard problem statement > for use of a relay ... if the relay isn't on-path, then it will negatively > impact performance to the degree that it isn't on-path. Client-side > implementers probably have a better sense of what kind of latency impact > would be observable by the user than I do. > > --Brandon > > > On 02/09/2015 02:50 PM, Tirumaleswar Reddy (tireddy) wrote: > >> Do you have any performance numbers to show the impact of the problem ? >> >> -Tiru >> >> >> -----Original Message----- >>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >>> Sent: Monday, February 09, 2015 10:08 PM >>> To: tram@ietf.org >>> Subject: [tram] location privacy considerations for TURN >>> >>> Hi all, >>> >>> There has been recent discussion about location privacy on the list. One >>> approach to location privacy has been to select a relay server that will >>> not >>> give away important location information, but one key issue has been how >>> to >>> determine whether an allocated relay address meets the peer's location >>> privacy requirements. If such a relay server can be identified, then the >>> location privacy requirements can be met, but this could sacrifice the >>> user's >>> performance expectations. >>> >>> We have been working on some ideas about how to address these privacy >>> concerns by adding a new channel binding mechanism to TURN that does not >>> require a peer to know even the relay address of the remote peer. Before >>> I >>> try to engage the WG on a possible solution, I first want to get some >>> sense of >>> whether I'm on target in the way that I'm framing the problem (location >>> privacy vs. performance). >>> >>> I've included a rough cut of the problem statement below (this seemed >>> better than publishing a draft just for the one page of content) and will >>> appreciate feedback from the list. Have I clearly stated the problem? Are >>> there other ways in which location privacy could negatively impact >>> performance? And is anyone else interested in trying to solve this >>> problem >>> within the WG? >>> >>> Thanks, >>> --Brandon >>> >>> ----- >>> 1. Introduction >>> >>> Traversal Using Relay around NAT (TURN) [RFC5766] defines a >>> mechanism >>> for establishment of peer-to-peer communication using a data relay >>> server. Although not part of the explicit intent of the protocol, a >>> TURN relay can also be used in a way that provides enhanced privacy >>> by hiding the network geographic location of one or both peers from >>> the other peer. However, location privacy considerations can have a >>> negative impact on latency, both during call setup and throughout >>> the >>> life of the session. >>> >>> 1.1. Location Privacy During Session Initiation >>> >>> Peer-to-peer session initiation typically involves relay of an >>> invitation via a rendezvous server. The initiating peer sends an >>> invitation to the rendezvous server, which relays the invitation to >>> the receiving peer for acceptance. Although the rendezvous server's >>> role requires it to maintain a registry of peer addresses, location >>> privacy demands that it should not send the receiving peer's address >>> to the initiating peer until the receiving peer has accepted the >>> call. >>> >>> When direct connectivity between the peers is possible, Interactive >>> Connectivity Establishment (ICE) [RFC5245] connectivity checks can >>> proceed and complete successfully as soon as the receiving peer has >>> received the invitation, since the initiating peer's host and >>> reflexive addresses can be delivered to the receiving peer along >>> with >>> the invitation. However, when the initiating peer requires a TURN >>> relay, the receiving peer's address information must be delivered >>> via >>> the rendezvous server with the invitation response in order for the >>> initiating peer to send a ChannelBind or CreatePermission request. >>> >>> Since the rendezvous server is often centrally located, even one-way >>> latency between the peers via the rendezvous server can be >>> significantly longer than the latency for direct connectivity, >>> meaning that initiation of successful peer-to-peer communication can >>> take significantly longer when a TURN relay is used, even if the >>> relay server is optimally selected for end-to-end performance. >>> >>> 1.2. Location Privacy and Call Quality >>> >>> Many peer-to-peer applications (e.g. voice or video calls) are >>> sensitive to path latency, with long one-way latencies often leading >>> to a negative impact on user experience. For this reason, it can be >>> important to select a relay server that is on-path between the peers >>> in order to prevent use of the relay from negatively impacting >>> latency. Achieving this goal can mean selecting the relay based on >>> its relative proximity to the associated peer. For this reason, the >>> relay address itself could provide information about the location of >>> the peer. In other words, a user who wishes not to disclose her/his >>> current location to the remote peer might have to intentionally >>> select a TURN relay that is suboptimal for performance. >>> ----- >>> >>> -- >>> 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 > --047d7b2e3d06feb715050eec8271 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Given that the mouth-to-ear target is 150ms (ITU recommend= ation), and the impact of selecting a non-local TURN server can easily be 5= 0 ms (e.g. routing to us-central instead of us-west), it's pretty clear= that the additional latency can be fatal regarding whether the application= is able to hit the target or not.

On Tue, Feb 10, 2015 at 7:26 AM, Brandon Williams <brandon.williams@akamai.com> wrote:
If you mean real-world data, then I could possibly provide= some example numbers for the impact on call setup, but I don't have nu= mbers for the call quality impact because I don't provide a true locati= on privacy service today.

The impact of the rendezvous server's location during call setup will h= ave a lot to do with how far off path it is for the individual peer pair. I= have seen cases where the one way latency via the rendezvous server is a f= ew hundred msec. IOW, the privacy concern is probably not extending the cal= l setup time all that much. I have a hard time getting excited about this o= ne, though I've got a customer who cares about it. The one way in which= it's a problem for performance is that the additional delay to startin= g the ICE check via the relay can cause the relay path to be rejected as a = result of the direct check completing first, even if the relay provides sig= nificantly better latency. That issue can be resolved by some of the work g= oing on to improve ICE.

The call quality issue is the one that I don't expect there would be mu= ch question about, since it's fairly similar to the standard problem st= atement for use of a relay ... if the relay isn't on-path, then it will= negatively impact performance to the degree that it isn't on-path. Cli= ent-side implementers probably have a better sense of what kind of latency = impact would be observable by the user than I do.

--Brandon


On 02/09/2015 02:50 PM, Tirumaleswar Reddy (tireddy) wrote:
Do you have any performance numbers to show the impact of the problem ?

-Tiru


-----Original Message-----
From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams
Sent: Monday, February 09, 2015 10:08 PM
To: tram@ietf.org Subject: [tram] location privacy considerations for TURN

Hi all,

There has been recent discussion about location privacy on the list. One approach to location privacy has been to select a relay server that will no= t
give away important location information, but one key issue has been how to=
determine whether an allocated relay address meets the peer's location<= br> privacy requirements. If such a relay server can be identified, then the location privacy requirements can be met, but this could sacrifice the user= 's
performance expectations.

We have been working on some ideas about how to address these privacy
concerns by adding a new channel binding mechanism to TURN that does not require a peer to know even the relay address of the remote peer. Before I<= br> try to engage the WG on a possible solution, I first want to get some sense= of
whether I'm on target in the way that I'm framing the problem (loca= tion
privacy vs. performance).

I've included a rough cut of the problem statement below (this seemed better than publishing a draft just for the one page of content) and will appreciate feedback from the list. Have I clearly stated the problem? Are there other ways in which location privacy could negatively impact
performance? And is anyone else interested in trying to solve this problem<= br> within the WG?

Thanks,
--Brandon

-----
1.=C2=A0 Introduction

=C2=A0 =C2=A0 =C2=A0Traversal Using Relay around NAT (TURN) [RFC5766] defin= es a mechanism
=C2=A0 =C2=A0 =C2=A0for establishment of peer-to-peer communication using a= data relay
=C2=A0 =C2=A0 =C2=A0server.=C2=A0 Although not part of the explicit intent = of the protocol, a
=C2=A0 =C2=A0 =C2=A0TURN relay can also be used in a way that provides enha= nced privacy
=C2=A0 =C2=A0 =C2=A0by hiding the network geographic location of one or bot= h peers from
=C2=A0 =C2=A0 =C2=A0the other peer.=C2=A0 However, location privacy conside= rations can have a
=C2=A0 =C2=A0 =C2=A0negative impact on latency, both during call setup and = throughout the
=C2=A0 =C2=A0 =C2=A0life of the session.

1.1.=C2=A0 Location Privacy During Session Initiation

=C2=A0 =C2=A0 =C2=A0Peer-to-peer session initiation typically involves rela= y of an
=C2=A0 =C2=A0 =C2=A0invitation via a rendezvous server.=C2=A0 The initiatin= g peer sends an
=C2=A0 =C2=A0 =C2=A0invitation to the rendezvous server, which relays the i= nvitation to
=C2=A0 =C2=A0 =C2=A0the receiving peer for acceptance.=C2=A0 Although the r= endezvous server's
=C2=A0 =C2=A0 =C2=A0role requires it to maintain a registry of peer address= es, location
=C2=A0 =C2=A0 =C2=A0privacy demands that it should not send the receiving p= eer's address
=C2=A0 =C2=A0 =C2=A0to the initiating peer until the receiving peer has acc= epted the
=C2=A0 =C2=A0 =C2=A0call.

=C2=A0 =C2=A0 =C2=A0When direct connectivity between the peers is possible,= Interactive
=C2=A0 =C2=A0 =C2=A0Connectivity Establishment (ICE) [RFC5245] connectivity= checks can
=C2=A0 =C2=A0 =C2=A0proceed and complete successfully as soon as the receiv= ing peer has
=C2=A0 =C2=A0 =C2=A0received the invitation, since the initiating peer'= s host and
=C2=A0 =C2=A0 =C2=A0reflexive addresses can be delivered to the receiving p= eer along with
=C2=A0 =C2=A0 =C2=A0the invitation.=C2=A0 However, when the initiating peer= requires a TURN
=C2=A0 =C2=A0 =C2=A0relay, the receiving peer's address information mus= t be delivered via
=C2=A0 =C2=A0 =C2=A0the rendezvous server with the invitation response in o= rder for the
=C2=A0 =C2=A0 =C2=A0initiating peer to send a ChannelBind or CreatePermissi= on request.

=C2=A0 =C2=A0 =C2=A0Since the rendezvous server is often centrally located,= even one-way
=C2=A0 =C2=A0 =C2=A0latency between the peers via the rendezvous server can= be
=C2=A0 =C2=A0 =C2=A0significantly longer than the latency for direct connec= tivity,
=C2=A0 =C2=A0 =C2=A0meaning that initiation of successful peer-to-peer comm= unication can
=C2=A0 =C2=A0 =C2=A0take significantly longer when a TURN relay is used, ev= en if the
=C2=A0 =C2=A0 =C2=A0relay server is optimally selected for end-to-end perfo= rmance.

1.2.=C2=A0 Location Privacy and Call Quality

=C2=A0 =C2=A0 =C2=A0Many peer-to-peer applications (e.g. voice or video cal= ls) are
=C2=A0 =C2=A0 =C2=A0sensitive to path latency, with long one-way latencies = often leading
=C2=A0 =C2=A0 =C2=A0to a negative impact on user experience.=C2=A0 For this= reason, it can be
=C2=A0 =C2=A0 =C2=A0important to select a relay server that is on-path betw= een the peers
=C2=A0 =C2=A0 =C2=A0in order to prevent use of the relay from negatively im= pacting
=C2=A0 =C2=A0 =C2=A0latency.=C2=A0 Achieving this goal can mean selecting t= he relay based on
=C2=A0 =C2=A0 =C2=A0its relative proximity to the associated peer.=C2=A0 Fo= r this reason, the
=C2=A0 =C2=A0 =C2=A0relay address itself could provide information about th= e location of
=C2=A0 =C2=A0 =C2=A0the peer.=C2=A0 In other words, a user who wishes not t= o disclose her/his
=C2=A0 =C2=A0 =C2=A0current location to the remote peer might have to inten= tionally
=C2=A0 =C2=A0 =C2=A0select a TURN relay that is suboptimal for performance.=
-----

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

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

--047d7b2e3d06feb715050eec8271-- From nobody Fri Feb 13 15:57:23 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8301A00A9 for ; Fri, 13 Feb 2015 15:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 xu9U0GoIYYov for ; Fri, 13 Feb 2015 15:57:18 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464291A0058 for ; Fri, 13 Feb 2015 15:57:18 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1DNvHhL064814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Feb 2015 17:57:17 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54DE8F5D.2030904@nostrum.com> Date: Fri, 13 Feb 2015 17:57:17 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: tram@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tram] Server discovery comments 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, 13 Feb 2015 23:57:20 -0000 In Hawaii, I volunteered to give feedback on the TURN server discovery draft (draft-ietf-tram-turn-server-discovery-01.txt). I apologize for the delay in getting around to this. After some pretty deep consideration, I'm very apprehensive about the mechanism proposed in section 4, which is the bulk of the text in this document. A lot of my worries are informed by the difficulties that web browsers would have in using this for WebRTC, but I think the issues do generalize to many other uses of TURN. The real showstopper is that the techniques for retrieving a domain name listed in section 4.1 provide no way for applications running on general purpose machines to acquire a domain name. In order: 4.1.1 DHCP: While this works for embedded devices (e.g., SIP hard phones), it's not something that a softphone or web browser will be able to access. In theory, the operating system could save this value and make it available to applications in general; however, this is unlikely to happen in the foreseeable future. It also precludes using the technique on any deployed operating systems, requiring us to wait for everyone to upgrade to newer OSes before they can use the feature. 4.1.2 IP Address: The overwhelming majority of clients who need to use TURN will be in private address spaces. I mean, if we didn't have NATs, then the need for TURN would be almost completely obviated. The approach of saying "use RFC7216 techniques to find your address" reduces this to the problem of STUN server discovery, which remains approximately as solved as TURN server discovery. (This approach also fails under the wide variety of circumstances that the PTR records cannot be delgated to the domain owner due to policy or technical reasons, but the other reasons that this won't work are so profound that this doesn't really matter). 4.1.3 From own identity: While this might work for SIP, if you're willing to make certain assumptions that aren't necessarily correct (namely that the organization hosting your registrar is the correct entity to provide your TURN server), it falls completely flat for WebRTC: we have no such identifier to fall back on. Maybe we could use the domain of the website serving up the script, but this really ties things together in a way that doesn't universally make sense. In the cases that we *do* use an identity (WebRTC has an optional identity service), it's very unlikely that the domain vouching for your identity would be willing to run your TURN traffic -- this would be akin to assuming that Verisign wants to run your website just because they issued you a cert. And that leaves us with... nothing. There's no feasible way for a WebRTC browser to make use of any of these three techniques. All of which is to say that I don't think a service-resolution discovery technique is likely to be successful here, and would propose removing it from the document. I do really like the anycast approach for its simplicity, and think we should keep it. At the same time, I'm concerned that the proposed approaches don't allow for discovery of resources on the local network that can act as TURN relays, or of network-level administrative provisioning of TURN server addresses. Interestingly, both of these can be addressed by adding a DNS-SD mechanism (cf. RFC 6763): if a local resource (say, one straddling the NAT and/or firewall) can provide TURN services, it can advertise these directly. And, if a network administrator wishes to point its users at a server outside the firewall, it can advertise a DNS-SD record pointing at the relevant IP address. If there's enough interest in this approach, I'd be happy to propose text for inclusion in a draft. /a From nobody Sun Feb 15 00:09:17 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310811A1A6E; Sun, 15 Feb 2015 00:09:11 -0800 (PST) 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 FyPLKzaPxwkH; Sun, 15 Feb 2015 00:09:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8BC1A1A60; Sun, 15 Feb 2015 00:09:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150215080909.2634.62903.idtracker@ietfa.amsl.com> Date: Sun, 15 Feb 2015 00:09:09 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-12.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: Sun, 15 Feb 2015 08:09:11 -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-12.txt Pages : 22 Date : 2015-02-15 Abstract: This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised. 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-12 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 Sun Feb 15 00:19:18 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D361A1A60 for ; Sun, 15 Feb 2015 00:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDYA8EdXtqZS for ; Sun, 15 Feb 2015 00:19:12 -0800 (PST) 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 C49B51A1A62 for ; Sun, 15 Feb 2015 00:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2035; q=dns/txt; s=iport; t=1423988352; x=1425197952; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=m815o613YRI9ueVWYSESZZQzYzpdOacL4VrpieffiPQ=; b=iP8g1oXtRNRlBfZxa/L+a/VtFGvXBJf+5Sx4EnniqJTiMorHRnjBGSh4 O7Kv1FEh3V21rhq46zdHzz9i1Icxrd4mO/DC1tq/UrcmUbBHfbwMstaPz Wii68wNUDurJT3YJ6nggGsJXi6vqY0X5YDP7JZz9D5D2SX/yV23MRaX9X Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DaBQAPVuBU/4wNJK1bgwZSVQUEwA2CIAyFbwKBDUMBAQEBAQF8hAwBAQEEAQEBNzQLDAQCAQgRBAEBCxQJBycLFAcBAQUDAgQOBQgBiCQIBc5tAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sMhDwxBwaDEIEUBY84g1eGeDiCVY5oIoNub4EEJBx/AQEB X-IronPort-AV: E=Sophos;i="5.09,580,1418083200"; d="scan'208";a="396091358" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP; 15 Feb 2015 08:19:12 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1F8JCnJ013553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Feb 2015 08:19:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Sun, 15 Feb 2015 02:19:11 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-12.txt Thread-Index: AQHQSPa5UJxEAOjee0GzgBI0q+aHHZzxW6OQ Date: Sun, 15 Feb 2015 08:19:11 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366A1083@xmb-rcd-x10.cisco.com> References: <20150215080909.2634.62903.idtracker@ietfa.amsl.com> In-Reply-To: <20150215080909.2634.62903.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.68.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "'Christer Holmberg' \(christer.holmberg@ericsson.com\)" Subject: [tram] FW: I-D Action: draft-ietf-tram-turn-third-party-authz-12.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: Sun, 15 Feb 2015 08:19:16 -0000 This revision addresses comments from Christer, updates section 4.1.2 -Tiru -----Original Message----- From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Sunday, February 15, 2015 1:39 PM To: i-d-announce@ietf.org Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-12.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TURN Revised and Modernized Working Group= of the IETF. Title : Session Traversal Utilities for NAT (STUN) Extens= ion for Third Party Authorization Authors : Tirumaleswar Reddy Prashanth Patil Ram Mohan Ravindranath Justin Uberti Filename : draft-ietf-tram-turn-third-party-authz-12.txt Pages : 22 Date : 2015-02-15 Abstract: This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised. 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-third-party-authz-1= 2 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Mon Feb 16 07:17:38 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC691A1ACE for ; Sun, 15 Feb 2015 03:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 3sMVFO8bnKxv for ; Sun, 15 Feb 2015 03:23:18 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D1B1A1AAE for ; Sun, 15 Feb 2015 03:23:17 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-40-54e081a28d26 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 22.67.04076.2A180E45; Sun, 15 Feb 2015 12:23:15 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Sun, 15 Feb 2015 12:23:14 +0100 From: Christer Holmberg To: "Tirumaleswar Reddy (tireddy)" , "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-12.txt Thread-Index: AQHQSPa5UJxEAOjee0GzgBI0q+aHHZzxW6OQgAA2At8= Date: Sun, 15 Feb 2015 11:23:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6F1CE5@ESESSMB209.ericsson.se> References: <20150215080909.2634.62903.idtracker@ietfa.amsl.com>, <913383AAA69FF945B8F946018B75898A366A1083@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366A1083@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D6F1CE5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje7ixgchBttOcVic2L2N0eLD2gts DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfGzP8vmAt+OFYc/cPRwLjAsouRg0NCwERi 7eb0LkZOIFNM4sK99WxdjFwcQgJHGCU6721jhnCWMEo8/juPFaSBTcBCovufNkiDiECkxII5 i5hBbGEBX4nNfxYyQsQDJFq2TmAGKRcRsJJ480oUJMwioCqxZNN7JhCbF6j877HHTBDjGxkl /i/aww6S4ARKTG18ATaHEeig76fWgDUwC4hLNH1ZyQpxqIDEkj3nmSFsUYmXj/+xQtTkSxyc vZUNYoGgxMmZT1gmMArPQtI+C0nZLCRlEHEDiS/vb0PZ2hLLFr5mhrD1Jbrfn2ZCFl/AyL6K UbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzB2Dm75bbWD8eBzx0OMAhyMSjy8BjUPQoRYE8uK K3MPMUpzsCiJ89oZHwoREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwOgQKCqXwcdiaFK+KJ+n 2O08A/Px22xLTd3y+R+67W7YP+3OHWGrC5Nv7f1pstxnU9tlQT+/t3cD2j0mqeg7S5pmbueX TpDoPXN90j6Pnx5nZFe/SG96yHSqc/nVdzZ1kdO3Tro9lePb9x0HeQp05y0v/71f8kX7zVQV 9UKGrbUOq/70qT59J6DEUpyRaKjFXFScCADekJlffgIAAA== Archived-At: X-Mailman-Approved-At: Mon, 16 Feb 2015 07:17:32 -0800 Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-12.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: Sun, 15 Feb 2015 11:23:22 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D6F1CE5ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, As far as my Gen-ART review is concerned, all issues have now been addresse= d. Regards, Christer Sent from my Windows Phone ________________________________ From: Tirumaleswar Reddy (tireddy) Sent: =FD15/=FD02/=FD2015 10:19 To: tram@ietf.org Cc: Christer Holmberg Subject: FW: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-12.t= xt This revision addresses comments from Christer, updates section 4.1.2 -Tiru -----Original Message----- From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Sunday, February 15, 2015 1:39 PM To: i-d-announce@ietf.org Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-12.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TURN Revised and Modernized Working Group= of the IETF. Title : Session Traversal Utilities for NAT (STUN) Extens= ion for Third Party Authorization Authors : Tirumaleswar Reddy Prashanth Patil Ram Mohan Ravindranath Justin Uberti Filename : draft-ietf-tram-turn-third-party-authz-12.txt Pages : 22 Date : 2015-02-15 Abstract: This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised. 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-third-party-authz-1= 2 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_7594FB04B1934943A5C02806D1A2204B1D6F1CE5ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

As far as my Gen-ART review is concerned, all issues have now been addresse= d.

Regards,

Christer


Sent from my Windows Phone
From: Tirumaleswar Reddy (tireddy)
Sent: =FD15= /=FD02/=FD2015 10:19
To: tram@ietf.org
Cc: Christer Holmberg Subject: FW: [= tram] I-D Action: draft-ietf-tram-turn-third-party-authz-12.txt

This revision addresses comments from Christer, up= dates section 4.1.2

-Tiru

-----Original Message-----
From: tram [mailto:tram-bounces@ie= tf.org] On Behalf Of internet-drafts@ietf.org
Sent: Sunday, February 15, 2015 1:39 PM
To: i-d-announce@ietf.org
Cc: tram@ietf.org
Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-12.txt

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 This draft is a work item of the TURN Revised and Modernized Working = Group of the IETF.

        Title    &nb= sp;      : Session Traversal Utilities for NAT (ST= UN) Extension for Third Party Authorization
        Authors    &= nbsp;    : Tirumaleswar Reddy
            &nb= sp;            = Prashanth Patil
            &nb= sp;            = Ram Mohan Ravindranath
            &nb= sp;            = Justin Uberti
        Filename    =     : draft-ietf-tram-turn-third-party-authz-12.txt
        Pages    &nb= sp;      : 22
        Date    &nbs= p;       : 2015-02-15

Abstract:
   This document proposes the use of OAuth 2.0 to obtain and vali= date
   ephemeral tokens that can be used for Session Traversal Utilit= ies for
   NAT (STUN) authentication.  The usage of ephemeral tokens= ensures
   that access to a STUN server can be controlled even if the tok= ens 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-12<= /a>

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-third= -party-authz-12


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

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

_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org= /mailman/listinfo/tram
 --_000_7594FB04B1934943A5C02806D1A2204B1D6F1CE5ESESSMB209erics_-- From nobody Tue Feb 17 08:32:46 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A441A8AEE; Tue, 17 Feb 2015 08:32:45 -0800 (PST) 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 OSb1R7AWOkQs; Tue, 17 Feb 2015 08:32:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1FB1A88A5; Tue, 17 Feb 2015 08:32:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 08:32:43 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stunbis-01.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: Tue, 17 Feb 2015 16:32:45 -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) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Jonathan Rosenberg Dan Wing Rohan Mahy Philip Matthews Filename : draft-ietf-tram-stunbis-01.txt Pages : 57 Date : 2015-02-17 Abstract: Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-stunbis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-01 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 Feb 18 02:47:00 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF7E1A911E for ; Wed, 18 Feb 2015 02:46:59 -0800 (PST) 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 ZjygMkOM-7Pq for ; Wed, 18 Feb 2015 02:46:57 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id B44C61A872E for ; Wed, 18 Feb 2015 02:46:57 -0800 (PST) Received: from [IPv6:2602:43:2a2:c600:e579:f7e3:850c:2b10] (unknown [IPv6:2602:43:2a2:c600:e579:f7e3:850c:2b10]) (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 0C0532025A for ; Wed, 18 Feb 2015 11:46:55 +0100 (CET) Message-ID: <54E46D9C.3010507@acm.org> Date: Wed, 18 Feb 2015 03:46:52 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> In-Reply-To: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 18 Feb 2015 10:47:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All, We have requested 40 minutes in Dallas to discuss the modifications summarized below. We plan to release -02 before the cutoff with minor edits for the remaining of the TODO list, but we wanted to release a first version with the most important modifications ahead of the meeting. We may not have the time to answer every email before Dallas, but we will collect the feedback and address it appropriately during the meeting. Thanks. Changelog: o Add negotiation mechanism for new password algorithms. o Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol. o Add support for SCTP to solve the fragmentation problem. o Merge RFC 7350: * Split the "Sending over..." sections in 3. * Add DTLS-over-UDP as transport. * Update the cipher suites and cipher/compression restrictions. * A stuns uri with an IP address is rejected. * Replace most of the RFC 3489 compatibility by a reference to the section in RFC 5389. * Update the STUN Usages list with transport applicability. o Merge RFC 7064: * DNS discovery is done from the URI. * Reorganized the text about default ports. o Add more C snippets. o Make clear that the cached RTO is discarded only if there is no new transactions for 10 minutes. On 02/17/2015 09:32 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 : Session Traversal Utilities for NAT (STUN) > Authors : Marc Petit-Huguenin > Gonzalo Salgueiro > Jonathan Rosenberg > Dan Wing > Rohan Mahy > Philip Matthews > Filename : draft-ietf-tram-stunbis-01.txt > Pages : 57 > Date : 2015-02-17 > > Abstract: > Session Traversal Utilities for NAT (STUN) is a protocol that serves > as a tool for other protocols in dealing with Network Address > Translator (NAT) traversal. It can be used by an endpoint to > determine the IP address and port allocated to it by a NAT. It can > also be used to check connectivity between two endpoints, and as a > keep-alive protocol to maintain NAT bindings. STUN works with many > existing NATs, and does not require any special behavior from them. > > STUN is not a NAT traversal solution by itself. Rather, it is a tool > to be used in the context of a NAT traversal solution. > > This document obsoletes RFC 5389. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-stunbis-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-01 > > > 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/ > - -- 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 iQIcBAEBCAAGBQJU5G2cAAoJECnERZXWan7ED1EP+gPP0+Xn+EcgqtGe/jxzGG6F iLmEt2GSjLMMLfoTZV5UaD4n7jUU0K3kL915PwP8ypoo750H/lh03K5Utsm9ZxeL nu7//dNyo1KsEB2cHNCAwLpXeVMnyes7RjiTUOtK8gf2TcvQjlOu9UksUJIy58E7 dxczH58sujoAjsLqg2ml7JJejKEUsowbGJtj6aaEGt61QYV7ojc1sNoNqF6tuGqY EhrDbzuu/SfeW0bxC/EOwitbpISBy9m289eMcOz9UdnoVRyOD14+gst/glizRU/2 X1v+4ABsv0TtEZrq8pf57FhI8ImMkseY/7A7nhft7zObUW2Lk67H9+KitoLtUiPn cPEolUvmA4RBAOnTpopR//o+4lUMnu4RbwZhlUdfBGxQsZ1iOWGmt7GYD6j+q5ow 9KxALPyuFUcm4Os3klGaCdZS2THEc6T4VIROMMifs3i1kCvCKnqPOPVF3GKeS4bw lLNwf+YuhS5m9WPylx1OMTsbfSVqzh+Bh9qekar57yUuNoAgnqqYMxAiWH7MlveS O3OiXI10papVe1UNfStmQX8SuYSb7DlsadQzldgOlMRveImKa3tRtzS7AXQ02Exj apv7o/j0uuEVr9NJE1CCKonfZqCzPnaU7LrTAHZZnQrz/lmN97spwCCyfbQcqOak 5RfMzQZxVJo6YFkWpseE =CmHq -----END PGP SIGNATURE----- From nobody Wed Feb 18 14:37:32 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5A71A1B56 for ; Wed, 18 Feb 2015 14:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hupaW968G4Bb for ; Wed, 18 Feb 2015 14:37:28 -0800 (PST) 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 555441A1AF4 for ; Wed, 18 Feb 2015 14:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9144; q=dns/txt; s=iport; t=1424299048; x=1425508648; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CbXoDViHj+tx3AnfoFEf+WITAMTGO3wF96M6VRU1lrI=; b=Eef7LbbyxUQr7pE+zYPpC5NrsmUpKXXaJ7IM96BdoHIFhg6cSzSiCQri raoOEdI8LKiyqWTAgVsmZyUmFUaB3IBGFQKkykBRnx/reC1DOgINywQ+g vtccp95ClhZewmAEwVBpaTrArxVMrJVkMoFUm0EdGeCsII5fGDxB9MbEl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BnBQBxE+VU/5BdJa1RCoMGUloEgwS9NYIgCoVxAhyBAkMBAQEBAQF8hAwBAQEDAQEBATE6BAwLAgEIGAQoAgIlCyUCBAESiCcIDZ1PnGQGmEcBAQEBAQEBAQIBAQEBAQEBFwSBG4h2foQSKRgigmKBSAWPQ4k8gRmJTYRugz4iggIcgVBvgQQkHH8BAQE X-IronPort-AV: E=Sophos;i="5.09,604,1418083200"; d="scan'208";a="124786006" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP; 18 Feb 2015 22:37:27 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t1IMbRsA027011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Feb 2015 22:37:27 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.58]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 18 Feb 2015 16:37:27 -0600 From: "Prashanth Patil (praspati)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] Comments on draft-patil-tram-turn-serv-selection-00 Thread-Index: AQHQS8t40xWQztazMECtFt7AUkFUkQ== Date: Wed, 18 Feb 2015 22:37:26 +0000 Message-ID: References: <1EA9BD83-A95A-427D-B007-6DADD43D998D@cisco.com> <54D8C81C.20608@akamai.com> In-Reply-To: <54D8C81C.20608@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.155.209.70] Content-Type: text/plain; charset="euc-kr" Content-ID: <55BA426F4230B64B92D3C2E3484FD29D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-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: Wed, 18 Feb 2015 22:37:31 -0000 SGkgQnJhbmRvbiwNClRoYW5rcyBmb3IgdGhlIHJldmlldy4NCg0KT24gMi85LzE1LCA2OjQ1IEFN LCAiQnJhbmRvbiBXaWxsaWFtcyIgPGJyYW5kb24ud2lsbGlhbXNAYWthbWFpLmNvbT4gd3JvdGU6 DQoNCj5Tb3JyeSBmb3IgdGhlIGRlbGF5ZWQgZmVlZGJhY2sgb24gdGhpcyBvbmUuIEkndmUgYmVl biBoYXZpbmcgYSBsaXR0bGUNCj50cm91YmxlIHRoaW5raW5nIGl0IHRocm91Z2gsIG1vc3RseSBh cm91bmQgdGhlIHF1ZXN0aW9uIG9mIHdoYXQgdHlwZSBvZg0KPmd1aWRhbmNlIEkgdGhpbmsgd291 bGQgYmUgdXNlZnVsIGhlcmUuIEF0IHRoaXMgcG9pbnQsIGl0J3MgdW5jbGVhciB0byBtZQ0KPndo ZXRoZXIgdGhlIGRvY3VtZW50IHNob3VsZCBiZSBnaXZpbmcgYW55IHJlY29tbWVuZGF0aW9ucyBh dCBhbGwuIEJ1dCBpZg0KPm5vdCwgdGhlbiB3aGF0IHB1cnBvc2UgY2FuIGl0IHNlcnZlPw0KPg0K PkkgYWdyZWUgd2l0aCBKdXN0aW4gdGhhdCBhbnkgcmVjb21tZW5kYXRpb25zIHByZXNlbnRlZCBp biB0aGUgZG9jdW1lbnQNCj5zaG91bGQgYmUgY2xlYXIgYW5kIHN0cmFpZ2h0LWZvcndhcmQuIElm IHRoZXkgYXJlbid0LCB0aGVuIHRoZXkgd2lsbCBiZQ0KPmRpZmZpY3VsdCBmb3IgYW4gaW1wbGVt ZW50b3IgdG8gYXBwbHkgYW5kIGVuZCB1cCBiZWluZyBtZWFuaW5nbGVzcy4gVGhhdA0KPnNhaWQs IGZvciBhIGNvdXBsZSBvZiByZWFzb25zLCBJJ20gbm90IGNlcnRhaW4gdGhhdCBpdCdzIHBvc3Np YmxlIHRvIHB1dA0KPmZvcndhcmQgYSBzdHJvbmcgYW5kIGNsZWFyIHNldCBvZiByZWNvbW1lbmRh dGlvbnMgZm9yIHNlcnZlciBzZWxlY3Rpb24uDQo+DQo+Rmlyc3QsIEkgdGhpbmsgc3VjaCByZWNv bW1lbmRhdGlvbnMgY291bGQgcXVpY2tseSBnbyBvdXQtb2YtZGF0ZSBhcyBuZXcNCj5tZWNoYW5p c21zIGFyZSBkZWZpbmVkIHRvIGV4dGVuZCB0aGUgcHJvY29sLiBGb3IgZXhhbXBsZSwgaWYgdGhp cw0KPmRvY3VtZW50IGhhZCBiZWVuIHdyaXR0ZW4gYSBjb3VwbGUgb2YgeWVhcnMgYWdvLCBpdCBt aWdodCBub3QgaGF2ZSBtYWRlDQo+cmVmZXJlbmNlIHRvIHJldHVybiwgbW9iaWxpdHksIG9yIERU TFMuDQoNCkFzIEp1c3RpbiBzdWdnZXN0cywgd2Ugd2FudCB0aGUgbmV4dCByZXZpc2lvbiB0byBw dXQgZm9ydGggZXhwbGljaXQgYmVzdA0KcHJhY3RpY2VzIGZvciBzZXJ2ZXIgc2VsZWN0aW9uLiBG b3IgZHluYW1pYyBwcm9wZXJ0aWVzLCBsZWF2ZSB0aGUgZGVjaXNpb24NCnRvIElDRS4NCg0KDQo+ DQo+U2Vjb25kLCBJIHRoaW5rIHRoZSBzZWxlY3Rpb24gY3JpdGVyaWEgY291bGQgaGF2ZSBkaWZm ZXJlbnQgcHJpb3JpdGllcw0KPmZvciBkaWZmZXJlbnQgdXNlcnMgYW5kL29yIGFwcGxpY2F0aW9u cywgbWFraW5nIHRoZSByZWNvbW1lbmRhdGlvbnMNCj5kaWZmaWN1bHQgdG8gYXBwbHkuIEZvciBl eGFtcGxlLCB0aGUgZ29hbHMgb2YgbG9jYXRpb24gcHJpdmFjeSBhbmQNCj5wZXJmb3JtYW5jZSBj b3VsZCBiZSBpbiBjb25mbGljdCwgc2luY2UgYSByZWxheSBzZXJ2ZXIgbW9yZSBjbG9zZWx5IHRp ZWQNCj50byB0aGUgcGVlcidzIG5ldHdvcmsgZ2VvZ3JhcGhpYyBsb2NhdGlvbiB3aWxsIG9mdGVu IHByb3ZpZGUgYmV0dGVyDQo+cGVyZm9ybWFuY2UuDQoNClllcywgYnV0IGZvciBhbiBhcHBsaWNh dGlvbiwgb25lIHBhcmFtZXRlciBpcyBhbHdheXMgbW9yZSBzaWduaWZpY2FudCB0aGF0DQphbm90 aGVyIHBhcmFtZXRlci4gRm9yIHRoZSBjYXNlIGFib3ZlLCBhbiBhcHBsaWNhdGlvbiBjaG9vc2Vz IGxvY2F0aW9uDQpwcml2YWN5IGlmIHRoYXSp9nMgb2YgdXRtb3N0IGltcG9ydGFuY2UuDQoNCiAg DQotUHJhc2hhbnRoDQoNCg0KPiBUaGUgc2FtZSBjb3VsZCBiZSBzYWlkIGZvciBhbnkgY2FwYWJp bGl0eSBub3QgZGlyZWN0bHkNCj5yZWxhdGVkIHRvIHRoZSByZWxheSBmdW5jdGlvbiwgc2luY2Ug aXQgYW55IGxpbWl0YXRpb24gb24gdGhlIGNhbmRpZGF0ZQ0KPnNldCBmb3IgcmVsYXkgc2VsZWN0 aW9uIGNvdWxkIHJlc3VsdCBpbiBhZGRlZCBsYXRlbmN5Lg0KPg0KPklmIGl0J3Mgbm90IHBvc3Np YmxlIHRvIGdpdmUgaW1wbGVtZW50YWJsZSByZWNvbW1lbmRhdGlvbnMgdGhhdCB3aWxsDQo+aGF2 ZSBvbmdvaW5nIHJlbGV2YW5jZSwgdGhlbiB3aGF0J3MgdGhlIHB1cnBvc2Ugb2YgdGhlIGRvY3Vt ZW50IGF0IGFsbD8NCj5PbmUgcG9zc2liaWxpdHkgaXMgdGhhdCBpdCBjb3VsZCBiZSB1c2VkIHRv IHByb3ZpZGUgZ3VpZGFuY2UgZm9yIGF1dGhvcnMNCj5vZiBvdGhlciBkcmFmdHMsIGhlbHBpbmcg dGhlbSB0byBpZGVudGlmeSBpbXBvcnRhbnQgYXJlYXMgb2YgZGlzY3Vzc2lvbg0KPnJlbGV2YW50 IHRvIG5ldyBUVVJOIG1lY2hhbmlzbXMgYW5kIHRoZWlyIGltcGFjdCBvbiBzZXJ2ZXIgc2VsZWN0 aW9uLg0KPlRoaXMgd291bGQgYWxzbyBoZWxwIHJldmlld2VycyB0byByZW1lbWJlciB0byBhc2sg aW1wb3J0YW50IHF1ZXN0aW9ucw0KPihlLmcuICJkb2VzIHRoaXMgZHJhZnQgZGlzY3VzcyB0aGUg aW1wYWN0IG9uIGxvY2F0aW9uIHByaXZhY3k/IikuDQo+DQo+SSd2ZSBnb3Qgc29tZSBjb21tZW50 IG9uIHRoZSBzcGVjaWZpY3Mgb2YgdGhlIGRyYWZ0IHRvbywgYnV0IEknbSBub3QNCj5zdXJlIGhv dyByZWxldmFudCB0aGV5IGFyZSB1bnRpbCBJJ20gbW9yZSBjb25maWRlbnQgYWJvdXQgdGhlIGlu dGVuZGVkDQo+cHVycG9zZS9nb2FscyBvZiB0aGUgZHJhZnQuDQo+DQo+LS1CcmFuZG9uDQo+DQo+ T24gMDEvMDkvMjAxNSAxMToyOCBBTSwgR29uemFsbyBTYWxndWVpcm8gKGdzYWxndWVpKSB3cm90 ZToNCj4+IFRoYW5rcywgSnVzdGluLiAgV2UnbGwgY29sbGVjdCBCcmFuZG9uJ3MgZmVlZGJhY2sg b24gdGhlIGRyYWZ0IHRvbyBhbmQNCj4+dGhlIGF1dGhvcnMgd2lsbCBkZWxpYmVyYXRlIG9uIHRl eHQgZWRpdHMgYW5kIHByb2R1Y2UgYSBuZXcgdmVyc2lvbiBmb3INCj4+eW91ciByZXZpZXcuDQo+ Pg0KPj4gLUcNCj4+DQo+Pg0KPj4+IE9uIEphbiA4LCAyMDE1LCBhdCA1OjM0IFBNLCBKdXN0aW4g VWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb20+IHdyb3RlOg0KPj4+DQo+Pj4gQXQgSUVURiA5MSwg SSBwcm9taXNlZCB0byBzZW5kIGZlZWRiYWNrIG9uIHRoaXMgZG9jdW1lbnQsIHNvIGhlcmUgZ29l cy4NCj4+Pg0KPj4+IEdlbmVyYWxseSwgSSB0aGluayBtYW55IG9mIHRoZSBpc3N1ZXMgbWVudGlv bmVkIGluIHRoaXMgZG9jdW1lbnQgYXJlDQo+Pj5pbXBvcnRhbnQsIGJ1dCB0aGUgcmVjb21tZW5k YXRpb25zIGFyZSBjb25mdXNpbmcgYW5kIHBvc3NpYmx5DQo+Pj5jb250cmFkaWN0b3J5OyBhIGRl dmVsb3BlciB3aXRoIGxpdHRsZSBrbm93bGVkZ2Ugb2YgVFVSTiB3aWxsIGhhdmUgYQ0KPj4+aGFy ZCB0aW1lIGZpZ3VyaW5nIG91dCBleGFjdGx5IHdoYXQgdG8gZG8uIEZ1cnRoZXJtb3JlLCBtYW55 IG9mIHRoZQ0KPj4+cHJvcGVydGllcyBkaXNjdXNzZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgZHlu YW1pYywgYW5kIHNob3VsZCBiZQ0KPj4+aGFuZGxlZCBieSB0aGUgSUNFIHByb2Nlc3MsIHJhdGhl ciB0aGFuIGluIFRVUk4gc2VydmVyIHNlbGVjdGlvbiAoZm9yDQo+Pj5leGFtcGxlLCB0aGUgbm90 aW9uIG9mIFJUVCBhcyBpdCByZWxhdGVzIHRvIHVzZXIgZXhwZXJpZW5jZSkuDQo+Pj4NCj4+PiBU aGVyZWZvcmUsIEkgdGhpbmsgdGhpcyBkb2N1bWVudCBzaG91bGQgdGFrZSBhIHN0cm9uZ2VyIHN0 YW5jZSBhbmQgcHV0DQo+Pj5mb3J0aCBleHBsaWNpdCBiZXN0IHByYWN0aWNlcyBmb3Igc2VsZWN0 aW9uIChhcyBvcHBvc2VkIHRvICJ0aGluZ3MgdG8NCj4+PmNvbnNpZGVyIiksIGZvciBub24tZHlu YW1pYyBwcm9wZXJ0aWVzLCBhbmQgbGVhdmUgdGhlIGRlY2lzaW9ucyBvbg0KPj4+ZHluYW1pYyBw cm9wZXJ0aWVzIHRvIGJlIHJlc29sdmVkIGJ5IElDRS4NCj4+Pg0KPj4+IEZvciBleGFtcGxlLCBJ IHRoaW5rIHdlIHNob3VsZCBvbWl0IHRoZSB0ZXh0IGluIFNlY3Rpb24gMyBhYm91dCB3aGF0DQo+ Pj50byBkbyB3aXRoIG5vbi13b3JraW5nIFRVUk4gc2VydmVycywgYW5kIG1lYXN1cmluZyBSVFQu IFNhbWUgZm9yDQo+Pj5TZWN0aW9uIDMuMywgd2hpY2ggYWxzbyBkaXNjdXNzZXMgUlRULCBhbmQg U2VjdGlvbiAzLjQsIHdoaWNoIHRhbGtzDQo+Pj5hYm91dCBtdWx0aXBsZSBpbnRlcmZhY2VzLiBU aGlzIGNhbiBhbGwgYmUgaGFuZGxlZCBieSBJQ0UuDQo+Pj4NCj4+PiBJbiBhZGRpdGlvbiwgdGhl IHNlY3Rpb25zIG9uIGxvY2FsIGNvbmZpZyBhbmQgbG9jYXRpb24gcHJpdmFjeSBhcmUNCj4+PnVu bmVjZXNzYXJ5IHdoZW4gUkVUVVJOIGlzIHVzZWQuIFdoZW4gUkVUVVJOIGlzIHVzZWQsIHRoZSBh cHBsaWNhdGlvbg0KPj4+Y2FuIGFsd2F5cyB1c2UgdGhlIGFwcCBUVVJOIHNlcnZlciBmb3IgbG9j YXRpb24gcHJpdmFjeSwgYW5kIHRoZQ0KPj4+cmVsYXRpb25zaGlwIGJldHdlZW4gbG9jYWwgVFVS TiBzZXJ2ZXIgYW5kIGFwcCBUVVJOIHNlcnZlciBpcyBmdWxseQ0KPj4+c3BlbGxlZCBvdXQsIHNv IHRoZXJlIGlzIG5vdGhpbmcgZm9yIHRoZSBhcHBsaWNhdGlvbiB0byBkZWNpZGUgb24uDQo+Pj4N Cj4+PiBUaGlzIGxlYXZlcyBvbmx5IHRoZSBTZWN1cml0eSwgQXV0aGVudGljYXRpb24sIGFuZCBN b2JpbGl0eSBzZWN0aW9ucy4NCj4+Pg0KPj4+IEZvciBzZWN1cml0eSwgSSB0aGluayB3ZSBjYW4g Z2l2ZSBzb21lIGNsZWFyIGd1aWRhbmNlIG9uIHdoYXQNCj4+PmFwcGxpY2F0aW9ucyBzaG91bGQg ZG8uIEZvciBzZWN1cml0eSwgSSB0aGluayB0aGUgZ3VpZGFuY2Ugc2hvdWxkIGJlIHRvDQo+Pj51 c2Ugb25seSBEVExTICsgVExTLCBpZiBib3RoIGFyZSBhdmFpbGFibGUsIHdpdGggZmFsbGJhY2sg dG8gVURQIG9yIFRDUA0KPj4+aWYgRFRMUyBvciBUTFMgYXJlbid0IGF2YWlsYWJsZS4gSWYgcHJp dmFjeSBpcyBwYXJhbW91bnQsIFVEUC9UQ1ANCj4+PmZhbGxiYWNrIG1heSBiZSBjb250cmFpbmRp Y2F0ZWQsIGJ1dCBhdCB0aGlzIHBvaW50IGluIHRpbWUsIERUTFMNCj4+PmRlcGxveW1lbnQgaXNu J3Qgd2lkZXNwcmVhZCBlbm91Z2ggdG8gdHJ1bHkgcmVjb21tZW5kIHRoaXMuDQo+Pj4NCj4+PiBU aGlzIHJlbGF0ZXMgdG8gdGhlIEF1dGhlbnRpY2F0aW9uIHNlY3Rpb24gLSBidXQgSSB0aGluayBh bnkgZmFpbHVyZXMNCj4+PnRvIGF1dGhlbnRpY2F0ZSB0aGUgc2VydmVyIGNlcnQgc2hvdWxkIGNh dXNlIHRoZSBUVVJOIGFsbG9jYXRpb24gdG8NCj4+PmZhaWwuIFRoaXMgaXMganVzdCBsaWtlIGFu eSBvdGhlciBtaXNjb25maWd1cmF0aW9uIG9uIHRoZSBUVVJOIHNlcnZlciAtDQo+Pj50aGVyZSdz IG5vIHJlYXNvbiB3ZSBzaG91bGQgZXZlbiBhbGxvdyB1c2Ugb2YgVFVSTiBzZXJ2ZXJzIHdob3Nl IGNlcnQNCj4+PmNoYWlucyBkb24ndCB2YWxpZGF0ZS4gU28sIHRoaXMgc2VjdGlvbiBjb3VsZCBw cm9iYWJseSBiZSByZW1vdmVkLg0KPj4+DQo+Pj4gTGFzdGx5LCB0aGUgTW9iaWxpdHkgc2VjdGlv biBzYXlzIHRoYXQgaWYgImFsbCBvdGhlciBwYXJhbWV0ZXJzIFthcmVdDQo+Pj5lcXVhbCIsIGEg VFVSTiBzZXJ2ZXIgd2l0aCBtb2JpbGl0eSBzaG91bGQgYmUgdXNlZC4gQ2xlYXJseSwgYWxsIG90 aGVyDQo+Pj5wYXJhbWV0ZXJzIHdpbGwgbm90IGJlIGVxdWFsIChlLmcuIFJUVCksIGFuZCBldmVu IGlmIHRoZXkgd2VyZSwgdGhlDQo+Pj5jbGllbnQgaGFzIG5vIHdheSB0byBrbm93IGlmIGEgc2Vy dmVyIGlzIG1vYmlsaXR5LWNhcGFibGUgYSBwcmlvcmkuIFNvDQo+Pj5JIHRoaW5rIHRoaXMgcmVj b21tZW5kYXRpb24gb3VnaHQgdG8gYmUgcmVtb3ZlZCwgb3IgcGVyaGFwcyB0dXJuZWQgaW50bw0K Pj4+c29tZSBzb3J0IG9mIHJlY29tbWVuZGF0aW9uIGZvciBUVVJOIHNlcnZlciBkZXZlbG9wZXJz IChlLmcuIFRVUk4NCj4+PnNlcnZlcnMgU0hPVUxEIHN1cHBvcnQgVExTL0RUTFMsIFNIT1VMRCBz dXBwb3J0IG1vYmlsaXR5LCBTSE9VTEQNCj4+PnN1cHBvcnQgcmVkaXJlY3QpLCBwcm9iYWJseSBp biBhIHNlcGFyYXRlIGRvYy4NCj4+Pg0KPj4+IFRoZXNlIHJlY29tbWVuZGF0aW9ucyBzaG91bGQg cmVkdWNlIHRoZSBzaXplIG9mIHRoaXMgZG9jdW1lbnQgYW5kDQo+Pj5wcm92aWRlIG11Y2ggY2xl YXJlciBhZHZpY2UgdG8gYXBwIGRldmVsb3BlcnMuDQo+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiB0cmFtIG1haWxpbmcgbGlzdA0KPj4+IHRy YW1AaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ry YW0NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4+IHRyYW1AaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPj4NCj4NCj4tLSANCj5CcmFuZG9uIFdp bGxpYW1zOyBTZW5pb3IgUHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2luZWVyDQo+RW1lcmdpbmcgUHJv ZHVjdHMgRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLg0KPg0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+dHJhbSBtYWlsaW5nIGxp c3QNCj50cmFtQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90cmFtDQoNCg== From nobody Wed Feb 18 14:40:11 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE211A1B60 for ; Wed, 18 Feb 2015 14:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvyZbvO90oWA for ; Wed, 18 Feb 2015 14:40:07 -0800 (PST) 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 8B8A31A1B5B for ; Wed, 18 Feb 2015 14:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4852; q=dns/txt; s=iport; t=1424299207; x=1425508807; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=uDjYjw5JEQh0WeZRu6vnzi2Dy3/x88IsN5AQyZl/w4E=; b=BbzgI2D25oty1eyUIclPvzohRxloIE9H5IZsUMjj3sxedB6LQi88AfM/ bIzGSiez9iIyv3UJNE9XHERlIIS6NpccWULoEp5kcGJxXPzlYQCrZL6Oc udeCkq6opgsYnhd1dx9LkSsfZKAE67uXOOLOBodpIWGIA68tKid1hNbs6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBgCqaeJU/4wNJK1SCYMGUloEwBKCIAyFJUoCgRhDAQEBAQEBfIQNAQEDAQEBAWsQCwIBCEYnCyUCBAESiCUIDc4oAQEBAQEBBAEBAQEBAQEbiwyEEig6hCoFhFaFNoNAgWyDV4ITg02BGDiNf4M+IoF9gXFvAYFDfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,604,1418083200"; d="scan'208";a="397097277" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP; 18 Feb 2015 22:40:06 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1IMe6NR002900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Feb 2015 22:40:06 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.58]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Wed, 18 Feb 2015 16:40:06 -0600 From: "Prashanth Patil (praspati)" To: Adam Roach , "tram@ietf.org" Thread-Topic: [tram] Server discovery comments Thread-Index: AQHQS8vXIDzsea64KUWjkp/SYap/JA== Date: Wed, 18 Feb 2015 22:40:06 +0000 Message-ID: References: <54DE8F5D.2030904@nostrum.com> In-Reply-To: <54DE8F5D.2030904@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.155.209.70] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <56B094D5B95A1F40AD036F0715A7380E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Server discovery comments 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, 18 Feb 2015 22:40:10 -0000 Hi Adam, Thanks for the review. On 2/13/15, 3:57 PM, "Adam Roach" wrote: >In Hawaii, I volunteered to give feedback on the TURN server discovery >draft (draft-ietf-tram-turn-server-discovery-01.txt). I apologize for >the delay in getting around to this. > >After some pretty deep consideration, I'm very apprehensive about the >mechanism proposed in section 4, which is the bulk of the text in this >document. A lot of my worries are informed by the difficulties that web >browsers would have in using this for WebRTC, but I think the issues do >generalize to many other uses of TURN. > >The real showstopper is that the techniques for retrieving a domain name >listed in section 4.1 provide no way for applications running on general >purpose machines to acquire a domain name. In order: > >4.1.1 DHCP: While this works for embedded devices (e.g., SIP hard >phones), it's not something that a softphone or web browser will be able >to access. In theory, the operating system could save this value and >make it available to applications in general; Windows, I believe, provides DHCP client APIs. See http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=3Dvs.85)= .a spx > however, this is unlikely >to happen in the foreseeable future. It also precludes using the >technique on any deployed operating systems, requiring us to wait for >everyone to upgrade to newer OSes before they can use the feature. Sure. > >4.1.2 IP Address: The overwhelming majority of clients who need to use >TURN will be in private address spaces. I mean, if we didn't have NATs, >then the need for TURN would be almost completely obviated. The approach >of saying "use RFC7216 techniques to find your address" reduces this to >the problem of STUN server discovery, which remains approximately as >solved as TURN server discovery. (This approach also fails under the >wide variety of circumstances that the PTR records cannot be delgated to >the domain owner due to policy or technical reasons, but the other >reasons that this won't work are so profound that this doesn't really >matter). > >4.1.3 From own identity: While this might work for SIP, if you're >willing to make certain assumptions that aren't necessarily correct >(namely that the organization hosting your registrar is the correct >entity to provide your TURN server), it falls completely flat for >WebRTC: we have no such identifier to fall back on. Maybe we could use >the domain of the website serving up the script, but this really ties >things together in a way that doesn't universally make sense. In the >cases that we *do* use an identity (WebRTC has an optional identity >service), it's very unlikely that the domain vouching for your identity >would be willing to run your TURN traffic -- this would be akin to >assuming that Verisign wants to run your website just because they >issued you a cert. > >And that leaves us with... nothing. There's no feasible way for a WebRTC >browser to make use of any of these three techniques. All of which is to >say that I don't think a service-resolution discovery technique is >likely to be successful here, and would propose removing it from the >document. Given that this is also meant to be a generic TURN server discovery draft (potentially used by applications other than browsers), we wanted to provide more than one mechanism to maximize opportunity for discovery. Also, RFC 5928 already defines TURN resolution mechanism - nothing new needs to be standardized for this discovery mechanism. > >I do really like the anycast approach for its simplicity, and think we >should keep it. Yes. It seems like the most acceptable choice for discovery. > >At the same time, I'm concerned that the proposed approaches don't allow >for discovery of resources on the local network that can act as TURN >relays, or of network-level administrative provisioning of TURN server >addresses.=20 Using anycast in the local network should work. >Interestingly, both of these can be addressed by adding a >DNS-SD mechanism (cf. RFC 6763): if a local resource (say, one >straddling the NAT and/or firewall) can provide TURN services, it can >advertise these directly. And, if a network administrator wishes to >point its users at a server outside the firewall, it can advertise a >DNS-SD record pointing at the relevant IP address. If there's enough >interest in this approach, I'd be happy to propose text for inclusion in >a draft. Sure, if there=B9s interest in this approach, we can certainly include it. Of course, we don=B9t want too many discovery mechanisms :-) -Prashanth > >/a > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Wed Feb 18 14:57:21 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5161A1B91; Wed, 18 Feb 2015 14:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] 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 n2EmM5y_HEYg; Wed, 18 Feb 2015 14:57:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B421A1B12; Wed, 18 Feb 2015 14:57:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218225717.29443.73374.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 14:57:17 -0800 Archived-At: Cc: draft-ietf-tram-turn-third-party-authz@tools.ietf.org, tram@ietf.org, Gonzalo Camarillo Subject: [tram] Alissa Cooper's No Objection on draft-ietf-tram-turn-third-party-authz-12: (with COMMENT) 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: Wed, 18 Feb 2015 22:57:19 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-tram-turn-third-party-authz-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 4 = Is it assumed that once a particular STUN server indicates support for third party authorization, the client should include an OAuth token in all future requests to that server? Or is the client expected to check for support again at some point in the future by sending a request without authorization? Just wondering if the case where a server enables and later disables support for third party authz (for some operational reason) is covered. = Section 6.2 = "the client MUST NOT examine the ticket" I think you meant token, not ticket. From nobody Wed Feb 18 15:16:27 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7771A1BCA for ; Wed, 18 Feb 2015 15:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ILxJ_kkRovMu for ; Wed, 18 Feb 2015 15:16:24 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676421A1B8E for ; Wed, 18 Feb 2015 15:16:24 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t1INGHZR026620 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2015 17:16:18 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54E51D40.5010407@nostrum.com> Date: Wed, 18 Feb 2015 17:16:16 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "tram@ietf.org" References: <54DE8F5D.2030904@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] Server discovery comments 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, 18 Feb 2015 23:16:25 -0000 On 2/18/15 16:40, Prashanth Patil (praspati) wrote: > Given that this is also meant to be a generic TURN server discovery draft > (potentially used by applications other than browsers), we wanted to > provide more than one mechanism to maximize opportunity for discovery. Sure, that's great. I'm not asking that they all be applicable. I'm just pointing out that, right now, *none* of them are, and that's not really okay. The other point that I was trying to make -- that 4.1.1 is only narrowly applicable, that 4.1.2 reduces an unsolved discovery problem to the *same* unsolved discovery problem, and that 4.1.3 will frequently have the wrong properties -- is probably the more important one. Basically, I'm pretty sure that all of 4.1 is fatally flawed in a wide variety of ways. If you can clarify how 4.1.1 is generally applicable or how 4.1.2 can bootstrap itself when the client is in an RFC 1918 address space (i.e., virtually always) or how 4.1.3 can deal with topologies where the SIP service provider is topologically in the wrong place to proxy media (i.e., often), then maybe there's some path forward. Otherwise, it's not obvious that there's any way to salvage any of section 4.1. /a From nobody Wed Feb 18 15:59:34 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633FC1A1BAC for ; Wed, 18 Feb 2015 15:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 e2HhrnS3ov0n for ; Wed, 18 Feb 2015 15:59:30 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA211A1B98 for ; Wed, 18 Feb 2015 15:59:30 -0800 (PST) Received: from [192.168.1.28] (unknown [180.216.105.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 019AF509BC; Wed, 18 Feb 2015 18:59:27 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <54DE8F5D.2030904@nostrum.com> Date: Thu, 19 Feb 2015 07:59:22 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <65CA8009-0B61-4A2E-85B8-89B50A022B1F@iii.ca> References: <54DE8F5D.2030904@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: tram@ietf.org Subject: Re: [tram] Server discovery comments 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, 18 Feb 2015 23:59:32 -0000 > On Feb 14, 2015, at 7:57 AM, Adam Roach wrote: >=20 > The approach of saying "use RFC7216 techniques to find your address" = reduces this to the problem of STUN server discovery, which remains = approximately as solved as TURN server discovery. in fairness - STUN servers are cheap enough to run and without the = latency issues, someone might just hardcode in a single stun server that = used as part of the process to discover a TURN server - but that level = of completing is not making me feel good=20= From nobody Wed Feb 18 15:59:41 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D201A1BC3 for ; Wed, 18 Feb 2015 15:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 LbrMFBrkw4C5 for ; Wed, 18 Feb 2015 15:59:34 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A41C21A1BB5 for ; Wed, 18 Feb 2015 15:59:34 -0800 (PST) Received: from [192.168.1.28] (unknown [180.216.105.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1901C509BE; Wed, 18 Feb 2015 18:59:31 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <54DE8F5D.2030904@nostrum.com> Date: Thu, 19 Feb 2015 07:59:26 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8120ABEA-F2EA-4A55-9322-44586A3A6D0D@iii.ca> References: <54DE8F5D.2030904@nostrum.com> To: tram@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Adam Roach Subject: Re: [tram] Server discovery comments 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, 18 Feb 2015 23:59:36 -0000 > On Feb 14, 2015, at 7:57 AM, Adam Roach wrote: >=20 > And that leaves us with... nothing. Seems about right.... one other things I wonder is given you do fine the = address for a TURN server, how do you know what credentials to use ? > There's no feasible way for a WebRTC browser to make use of any of = these three techniques. All of which is to say that I don't think a = service-resolution discovery technique is likely to be successful here, = and would propose removing it from the document. >=20 > I do really like the anycast approach for its simplicity, and think we = should keep it. >=20 > At the same time, I'm concerned that the proposed approaches don't = allow for discovery of resources on the local network that can act as = TURN relays, or of network-level administrative provisioning of TURN = server addresses. Interestingly, both of these can be addressed by = adding a DNS-SD mechanism (cf. RFC 6763): if a local resource (say, one = straddling the NAT and/or firewall) can provide TURN services, it can = advertise these directly. And, if a network administrator wishes to = point its users at a server outside the firewall, it can advertise a = DNS-SD record pointing at the relevant IP address. If there's enough = interest in this approach, I'd be happy to propose text for inclusion in = a draft. I think using a well known existing mechanisms like DNS-SD is likely to = work out better than many roll your own. I'd certainly be interested in = seeing a DNS-SD based approach.=20 From nobody Wed Feb 18 16:13:35 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00331A1B0D for ; Wed, 18 Feb 2015 16:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzyCk_I42EFj for ; Wed, 18 Feb 2015 16:13:31 -0800 (PST) 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 016501A0AC8 for ; Wed, 18 Feb 2015 16:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2603; q=dns/txt; s=iport; t=1424304811; x=1425514411; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BaCWjd1AhLAOQunMHA/HsyPhGi1dkA57J+DmlOsSFF4=; b=QL5LR0yu1cHc6MIHSE3HIfiacz4w/69mHWiieriPZDausEGNV50bAKHB OwxIHpZNWBVU8vluTGGz25NWTIpiE2bnlCtie2sXTOEvFgTn/sZ3BizcS IU3aZBzG9fSPK4GJ4OkBuuvblHtM6dlvNtZUCSkyTnxWD8fa1F+qTEfxa g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CWBQAfKuVU/5xdJa1bgwZSWgTAOoIshW8CgR9DAQEBAQEBfIQMAQEBAwF+CwIBCBguMiUCBAESiCcIDdJ7AQEBAQYCIIoRfoQ7OoQqBY9Eg1qFZYFRkUYig25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,605,1418083200"; d="scan'208";a="124887684" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 19 Feb 2015 00:13:30 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t1J0DUph021076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Feb 2015 00:13:30 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.58]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Wed, 18 Feb 2015 18:13:30 -0600 From: "Prashanth Patil (praspati)" To: Adam Roach , "tram@ietf.org" Thread-Topic: [tram] Server discovery comments Thread-Index: AQHQS9DkIDzsea64KUWjkp/SYap/JJz2+JuA Date: Thu, 19 Feb 2015 00:13:29 +0000 Message-ID: References: <54DE8F5D.2030904@nostrum.com> <54E51D40.5010407@nostrum.com> In-Reply-To: <54E51D40.5010407@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.155.209.70] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3E6D4B28636DE84F8B3117D5BE36B357@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Server discovery comments 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, 19 Feb 2015 00:13:33 -0000 Hi Adam, On 2/18/15, 3:16 PM, "Adam Roach" wrote: >On 2/18/15 16:40, Prashanth Patil (praspati) wrote: >> Given that this is also meant to be a generic TURN server discovery >>draft >> (potentially used by applications other than browsers), we wanted to >> provide more than one mechanism to maximize opportunity for discovery. > >Sure, that's great. I'm not asking that they all be applicable. I'm just >pointing out that, right now, *none* of them are, and that's not really >okay. > >The other point that I was trying to make -- that 4.1.1 is only narrowly >applicable, that 4.1.2 reduces an unsolved discovery problem to the >*same* unsolved discovery problem, and that 4.1.3 will frequently have >the wrong properties -- is probably the more important one. > >Basically, I'm pretty sure that all of 4.1 is fatally flawed in a wide >variety of ways. > >If you can clarify how 4.1.1 is generally applicable It is not. It is best effort. > or how 4.1.2 can=20 >bootstrap itself when the client is in an RFC 1918 address space (i.e., >virtually always)=20 It can=B9t. As you point out, 4.1.2 does rely on techniques defined in RFC7216, which is not quite ideal. It=B9s simpler with IPv6. TURN is required even with IPv6 for Enterprise firewall traversal use cases discussed in http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14# section-3.3.5=20 >or how 4.1.3 can deal with topologies where the SIP >service provider is topologically in the wrong place to proxy media >(i.e., often), That would be a matter of server selection, really. If the only server that the client discovered was via this mechanism, there isn=B9t much you could do - it=B9s better to have discovered something than not having discovered anything at all. But if an application were to discover multiple TURN servers, the application needs to choose the one that suits best. One of the options suggested (which we=B9re attempting to tackle in the server selection draft) is to rely on ICE to help pick one with the best dynamic properties (RTT). If an application had the =8Cdomain=B9 configured (or learned it using by s= ome other means), then it could do 4.2 straightaway. The idea was to be able to use 4.2 (which is readily available via RFC5928). We could simplify all of this by suggesting that an application use 4.2 if a domain is known/available somehow. -Prashanth > then maybe there's some path forward. > >Otherwise, it's not obvious that there's any way to salvage any of >section 4.1. > >/a From nobody Wed Feb 18 22:26:28 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C391A8857; Wed, 18 Feb 2015 22:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sI5jlYoEwV7Y; Wed, 18 Feb 2015 22:26:14 -0800 (PST) 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 4B6D21A885C; Wed, 18 Feb 2015 22:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2141; q=dns/txt; s=iport; t=1424327174; x=1425536774; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Y/zd3EJ2eKB8YJsXHst31Sm4sdJQqISZTLhPzZSq6xs=; b=kNUrloS1nlbR4TjipAnDLwjU9XOE4jtqK9P1H+yiZzrwuJKP57bFUnQE QQrFZfc5haZpUd8ReMYZ9XSshkUTLHrCdvRuWqMcqC2824mc24jXQxSYu e8XCuInW+A1TuPvHaQJwDBzk8KS8yNMjxFWXHCGjaKJ4V+i4YV0MH7RIn 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CZBQCbgOVU/4ENJK1bgwZSWgTAPIIgDIVvAoEeQwEBAQEBAXyEDAEBAQMBAQEBNzQLBQcEAgEIEQQBAQsUBQQHJwsUCQgCBAENBQgBiB4IDdI1AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sPhAwRAQsUMQIFBoMQgRQFhV6JZoNahn44gliObiKCMoE8bwGBCjl/AQEB X-IronPort-AV: E=Sophos;i="5.09,607,1418083200"; d="scan'208";a="124959531" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP; 19 Feb 2015 06:26:13 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t1J6QDI3031999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Feb 2015 06:26:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Thu, 19 Feb 2015 00:26:13 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Alissa Cooper , The IESG Thread-Topic: [tram] Alissa Cooper's No Objection on draft-ietf-tram-turn-third-party-authz-12: (with COMMENT) Thread-Index: AQHQS85C3LBHL+qDwEOg4TP5UlPMgJz3gBbA Date: Thu, 19 Feb 2015 06:26:12 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366A341F@xmb-rcd-x10.cisco.com> References: <20150218225717.29443.73374.idtracker@ietfa.amsl.com> In-Reply-To: <20150218225717.29443.73374.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.46.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tram-turn-third-party-authz@tools.ietf.org" , "tram@ietf.org" , Gonzalo Camarillo Subject: Re: [tram] Alissa Cooper's No Objection on draft-ietf-tram-turn-third-party-authz-12: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 06:26:24 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Alissa Cooper > Sent: Thursday, February 19, 2015 4:27 AM > To: The IESG > Cc: draft-ietf-tram-turn-third-party-authz@tools.ietf.org; tram@ietf.org; > Gonzalo Camarillo > Subject: [tram] Alissa Cooper's No Objection on draft-ietf-tram-turn-thir= d- > party-authz-12: (with COMMENT) >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-tram-turn-third-party-authz-12: No Objection >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =3D Section 4 =3D > Is it assumed that once a particular STUN server indicates support for th= ird > party authorization, the client should include an OAuth token in all futu= re > requests to that server?=20 No. > Or is the client expected to check for support again > at some point in the future by sending a request without authorization?=20 Yes, the client for subsequent Allocate requests has to first check if the = server supports third party authorization or not. > Just > wondering if the case where a server enables and later disables support f= or > third party authz (for some operational > reason) is covered. >=20 > =3D Section 6.2 =3D > "the client MUST NOT examine the ticket" >=20 > I think you meant token, not ticket. Yes, fixed. -Tiru >=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Feb 19 07:03:24 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB261A1B4F for ; Thu, 19 Feb 2015 07:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 hnGNDWQ9j-ay for ; Thu, 19 Feb 2015 07:03:19 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id B2D501A8820 for ; Thu, 19 Feb 2015 07:02:17 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 771BC28517; Thu, 19 Feb 2015 15:02:16 +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 640632850F; Thu, 19 Feb 2015 15:02: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 5E5C58003C; Thu, 19 Feb 2015 15:02:16 +0000 (GMT) Message-ID: <54E5FAF8.8000207@akamai.com> Date: Thu, 19 Feb 2015 10:02:16 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "tram@ietf.org" References: <1EA9BD83-A95A-427D-B007-6DADD43D998D@cisco.com> <54D8C81C.20608@akamai.com> In-Reply-To: Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-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, 19 Feb 2015 15:03:23 -0000 Hi Prashanth, I'm not certain that your responses actually address my comments. On the one hand, you appear to agree that user priorities have a significant impact on server selection, and you haven't responded at all to my point about how quickly recommendations will go out of date as new mechanisms are developed. I can certainly wait for the next draft to see what you have in mind, but I don't clearly see what BCPs you could document that will actually be useful to an implementer over the long term. --Brandon On 02/18/2015 05:37 PM, Prashanth Patil (praspati) wrote: > Hi Brandon, > Thanks for the review. > > On 2/9/15, 6:45 AM, "Brandon Williams" wrote: > >> Sorry for the delayed feedback on this one. I've been having a little >> trouble thinking it through, mostly around the question of what type of >> guidance I think would be useful here. At this point, it's unclear to me >> whether the document should be giving any recommendations at all. But if >> not, then what purpose can it serve? >> >> I agree with Justin that any recommendations presented in the document >> should be clear and straight-forward. If they aren't, then they will be >> difficult for an implementor to apply and end up being meaningless. That >> said, for a couple of reasons, I'm not certain that it's possible to put >> forward a strong and clear set of recommendations for server selection. >> >> First, I think such recommendations could quickly go out-of-date as new >> mechanisms are defined to extend the procol. For example, if this >> document had been written a couple of years ago, it might not have made >> reference to return, mobility, or DTLS. > > As Justin suggests, we want the next revision to put forth explicit best > practices for server selection. For dynamic properties, leave the decision > to ICE. > > >> >> Second, I think the selection criteria could have different priorities >> for different users and/or applications, making the recommendations >> difficult to apply. For example, the goals of location privacy and >> performance could be in conflict, since a relay server more closely tied >> to the peer's network geographic location will often provide better >> performance. > > Yes, but for an application, one parameter is always more significant that > another parameter. For the case above, an application chooses location > privacy if that©ös of utmost importance. > > > -Prashanth > > >> The same could be said for any capability not directly >> related to the relay function, since it any limitation on the candidate >> set for relay selection could result in added latency. >> >> If it's not possible to give implementable recommendations that will >> have ongoing relevance, then what's the purpose of the document at all? >> One possibility is that it could be used to provide guidance for authors >> of other drafts, helping them to identify important areas of discussion >> relevant to new TURN mechanisms and their impact on server selection. >> This would also help reviewers to remember to ask important questions >> (e.g. "does this draft discuss the impact on location privacy?"). >> >> I've got some comment on the specifics of the draft too, but I'm not >> sure how relevant they are until I'm more confident about the intended >> purpose/goals of the draft. >> >> --Brandon >> >> On 01/09/2015 11:28 AM, Gonzalo Salgueiro (gsalguei) wrote: >>> Thanks, Justin. We'll collect Brandon's feedback on the draft too and >>> the authors will deliberate on text edits and produce a new version for >>> your review. >>> >>> -G >>> >>> >>>> On Jan 8, 2015, at 5:34 PM, Justin Uberti wrote: >>>> >>>> At IETF 91, I promised to send feedback on this document, so here goes. >>>> >>>> Generally, I think many of the issues mentioned in this document are >>>> important, but the recommendations are confusing and possibly >>>> contradictory; a developer with little knowledge of TURN will have a >>>> hard time figuring out exactly what to do. Furthermore, many of the >>>> properties discussed in this document are dynamic, and should be >>>> handled by the ICE process, rather than in TURN server selection (for >>>> example, the notion of RTT as it relates to user experience). >>>> >>>> Therefore, I think this document should take a stronger stance and put >>>> forth explicit best practices for selection (as opposed to "things to >>>> consider"), for non-dynamic properties, and leave the decisions on >>>> dynamic properties to be resolved by ICE. >>>> >>>> For example, I think we should omit the text in Section 3 about what >>>> to do with non-working TURN servers, and measuring RTT. Same for >>>> Section 3.3, which also discusses RTT, and Section 3.4, which talks >>>> about multiple interfaces. This can all be handled by ICE. >>>> >>>> In addition, the sections on local config and location privacy are >>>> unnecessary when RETURN is used. When RETURN is used, the application >>>> can always use the app TURN server for location privacy, and the >>>> relationship between local TURN server and app TURN server is fully >>>> spelled out, so there is nothing for the application to decide on. >>>> >>>> This leaves only the Security, Authentication, and Mobility sections. >>>> >>>> For security, I think we can give some clear guidance on what >>>> applications should do. For security, I think the guidance should be to >>>> use only DTLS + TLS, if both are available, with fallback to UDP or TCP >>>> if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP >>>> fallback may be contraindicated, but at this point in time, DTLS >>>> deployment isn't widespread enough to truly recommend this. >>>> >>>> This relates to the Authentication section - but I think any failures >>>> to authenticate the server cert should cause the TURN allocation to >>>> fail. This is just like any other misconfiguration on the TURN server - >>>> there's no reason we should even allow use of TURN servers whose cert >>>> chains don't validate. So, this section could probably be removed. >>>> >>>> Lastly, the Mobility section says that if "all other parameters [are] >>>> equal", a TURN server with mobility should be used. Clearly, all other >>>> parameters will not be equal (e.g. RTT), and even if they were, the >>>> client has no way to know if a server is mobility-capable a priori. So >>>> I think this recommendation ought to be removed, or perhaps turned into >>>> some sort of recommendation for TURN server developers (e.g. TURN >>>> servers SHOULD support TLS/DTLS, SHOULD support mobility, SHOULD >>>> support redirect), probably in a separate doc. >>>> >>>> These recommendations should reduce the size of this document and >>>> provide much clearer advice to app developers. >>>> _______________________________________________ >>>> 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. >> >> _______________________________________________ >> 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 Feb 19 11:31:45 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F104D1A00C5; Thu, 19 Feb 2015 11:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 ZzNgY1HlVHg7; Thu, 19 Feb 2015 11:31:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 747371A005C; Thu, 19 Feb 2015 11:31:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219193139.28097.40666.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:31:39 -0800 From: IETF Secretariat Archived-At: Subject: [tram] ID Tracker State Update Notice: 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, 19 Feb 2015 19:31:42 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ From nobody Thu Feb 19 11:37:07 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4591A006B for ; Thu, 19 Feb 2015 11:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26QRViMw4tJT for ; Thu, 19 Feb 2015 11:37:04 -0800 (PST) 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 BCD7D1A797C for ; Thu, 19 Feb 2015 11:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11792; q=dns/txt; s=iport; t=1424374616; x=1425584216; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+nby5BeIo9FawsyjrBnUnzY+xoSRuKklbdF59LxSQGU=; b=i18DGFBOQhQJSnsH+5X8fOsNlJS9Z1XrwHpXVh8jSOXMH36uyYSydh0z Ha91WFPsZdabn5gujUibCOK+TYVaakcQam4tdGeHJZZzq9KUkaEjwSh8v I024WLMo+YOJpHtxamO9rRsab8GhyU9CxXKLdAyIsOOdZg2f0bAPkbcRY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CIBQAUOuZU/4gNJK1RCoMGUloEgwW9OoIgCoVxAhyBB0MBAQEBAQF8hA8BAQEDAQEBATE6BAwLAgEIGAQRFwICJQslAgQBEognCA2eeZxkBpgmAQEBAQEBAQMBAQEBAQEBFwSBG4h2foQSKRgiCoJYgUgFj0uJQYEZjkuDPiKCAhyBUG+BBCQcfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,610,1418083200"; d="scan'208";a="397558077" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP; 19 Feb 2015 19:36:55 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1JJatM7006179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Feb 2015 19:36:55 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.58]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 19 Feb 2015 13:36:55 -0600 From: "Prashanth Patil (praspati)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] Comments on draft-patil-tram-turn-serv-selection-00 Thread-Index: AQHQTFUPJ8fkOa21xkKOLgQ5OMk/Kpz4PKAA Date: Thu, 19 Feb 2015 19:36:54 +0000 Message-ID: References: <1EA9BD83-A95A-427D-B007-6DADD43D998D@cisco.com> <54D8C81C.20608@akamai.com> <54E5FAF8.8000207@akamai.com> In-Reply-To: <54E5FAF8.8000207@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.155.209.70] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-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, 19 Feb 2015 19:37:06 -0000 SGkgQnJhbmRvbiwNCg0KT24gMi8xOS8xNSwgNzowMiBBTSwgIkJyYW5kb24gV2lsbGlhbXMiIDxi cmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20+DQp3cm90ZToNCg0KPkhpIFByYXNoYW50aCwNCj4N Cj5JJ20gbm90IGNlcnRhaW4gdGhhdCB5b3VyIHJlc3BvbnNlcyBhY3R1YWxseSBhZGRyZXNzIG15 IGNvbW1lbnRzLiBPbiB0aGUNCj5vbmUgaGFuZCwgeW91IGFwcGVhciB0byBhZ3JlZSB0aGF0IHVz ZXIgcHJpb3JpdGllcyBoYXZlIGEgc2lnbmlmaWNhbnQNCj5pbXBhY3Qgb24gc2VydmVyIHNlbGVj dGlvbiwNCg0KWWVzLCBhbmQgaXShr3Mgb25lIG9mIHRoZSByZWFzb25zIHdlIGNhbiBvbmx5IG9m ZmVyIGJlc3QgcHJhY3RpY2VzIGFuZCBub3QNCnByaW9yaXRpZXMuIFRoZSBmaW5hbCBjaG9pY2Ug aXMgYWx3YXlzIG1hZGUgYnkgYW4gYXBwbGljYXRpb24sIHdlaWdoaW5nIGluDQp3aXRoIGl0cyBw cmlvcml0aWVzLg0KDQpBbHNvLCBiZXN0IHByYWN0aWNlcyBhcmUgd2l0aCB3aGF0IHdlIGtub3cg dG9kYXkuIFlvdaGvcmUgcmlnaHQsIHRoZXJlDQpjb3VsZCBiZSBuZXcgcGFyYW1ldGVycyB0aGF0 IGVtZXJnZSBpbiB0aGUgZnV0dXJlIHdoaWNoIHdlIGNhbm5vdCBhY2NvdW50DQpmb3IsIGluIGFu eSBjdXJyZW50IGRvY3VtZW50LiBTb21lIHJlY29tbWVuZGF0aW9ucyBtYXkgYmUgYnJvYWQgZW5v dWdoIHRvDQphY2NvbW1vZGF0ZSBuZXcgcGFyYW1ldGVycywgYnV0IG5vdCBhbGwuDQoNCkFsbCBv ZiB0aGlzIG1heSB0cmFuc2xhdGUgdG8gaW1wbGVtZW50YWJsZSByZWNvbW1lbmRhdGlvbnMsIG9y IChhcyB5b3UNCnBvaW50IG91dCkgbWF5IGVuZCB1cCBsb29raW5nIGxpa2UgQkNQIGZvciBuZXcg VFVSTiBtZWNoYW5pc21zIGFuZCB0aGVpcg0KaW1wYWN0IG9uIHNlcnZlciBzZWxlY3Rpb24uDQoN Ci1QcmFzaGFudGgNCg0KPiBhbmQgeW91IGhhdmVuJ3QgcmVzcG9uZGVkIGF0IGFsbCB0byBteSBw b2ludA0KPmFib3V0IGhvdyBxdWlja2x5IHJlY29tbWVuZGF0aW9ucyB3aWxsIGdvIG91dCBvZiBk YXRlIGFzIG5ldyBtZWNoYW5pc21zDQo+YXJlIGRldmVsb3BlZC4gDQo+IEkgY2FuIGNlcnRhaW5s eSB3YWl0IGZvciB0aGUgbmV4dCBkcmFmdCB0byBzZWUgd2hhdCB5b3UNCj5oYXZlIGluIG1pbmQs IGJ1dCBJIGRvbid0IGNsZWFybHkgc2VlIHdoYXQgQkNQcyB5b3UgY291bGQgZG9jdW1lbnQgdGhh dA0KPndpbGwgYWN0dWFsbHkgYmUgdXNlZnVsIHRvIGFuIGltcGxlbWVudGVyIG92ZXIgdGhlIGxv bmcgdGVybS4NCj4NCj4tLUJyYW5kb24NCj4NCj5PbiAwMi8xOC8yMDE1IDA1OjM3IFBNLCBQcmFz aGFudGggUGF0aWwgKHByYXNwYXRpKSB3cm90ZToNCj4+IEhpIEJyYW5kb24sDQo+PiBUaGFua3Mg Zm9yIHRoZSByZXZpZXcuDQo+PiANCj4+IE9uIDIvOS8xNSwgNjo0NSBBTSwgIkJyYW5kb24gV2ls bGlhbXMiIDxicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20+DQo+Pndyb3RlOg0KPj4gDQo+Pj4g U29ycnkgZm9yIHRoZSBkZWxheWVkIGZlZWRiYWNrIG9uIHRoaXMgb25lLiBJJ3ZlIGJlZW4gaGF2 aW5nIGEgbGl0dGxlDQo+Pj4gdHJvdWJsZSB0aGlua2luZyBpdCB0aHJvdWdoLCBtb3N0bHkgYXJv dW5kIHRoZSBxdWVzdGlvbiBvZiB3aGF0IHR5cGUgb2YNCj4+PiBndWlkYW5jZSBJIHRoaW5rIHdv dWxkIGJlIHVzZWZ1bCBoZXJlLiBBdCB0aGlzIHBvaW50LCBpdCdzIHVuY2xlYXIgdG8NCj4+Pm1l DQo+Pj4gd2hldGhlciB0aGUgZG9jdW1lbnQgc2hvdWxkIGJlIGdpdmluZyBhbnkgcmVjb21tZW5k YXRpb25zIGF0IGFsbC4gQnV0DQo+Pj5pZg0KPj4+IG5vdCwgdGhlbiB3aGF0IHB1cnBvc2UgY2Fu IGl0IHNlcnZlPw0KPj4+DQo+Pj4gSSBhZ3JlZSB3aXRoIEp1c3RpbiB0aGF0IGFueSByZWNvbW1l bmRhdGlvbnMgcHJlc2VudGVkIGluIHRoZSBkb2N1bWVudA0KPj4+IHNob3VsZCBiZSBjbGVhciBh bmQgc3RyYWlnaHQtZm9yd2FyZC4gSWYgdGhleSBhcmVuJ3QsIHRoZW4gdGhleSB3aWxsIGJlDQo+ Pj4gZGlmZmljdWx0IGZvciBhbiBpbXBsZW1lbnRvciB0byBhcHBseSBhbmQgZW5kIHVwIGJlaW5n IG1lYW5pbmdsZXNzLg0KPj4+VGhhdA0KPj4+IHNhaWQsIGZvciBhIGNvdXBsZSBvZiByZWFzb25z LCBJJ20gbm90IGNlcnRhaW4gdGhhdCBpdCdzIHBvc3NpYmxlIHRvDQo+Pj5wdXQNCj4+PiBmb3J3 YXJkIGEgc3Ryb25nIGFuZCBjbGVhciBzZXQgb2YgcmVjb21tZW5kYXRpb25zIGZvciBzZXJ2ZXIg c2VsZWN0aW9uLg0KPj4+DQo+Pj4gRmlyc3QsIEkgdGhpbmsgc3VjaCByZWNvbW1lbmRhdGlvbnMg Y291bGQgcXVpY2tseSBnbyBvdXQtb2YtZGF0ZSBhcyBuZXcNCj4+PiBtZWNoYW5pc21zIGFyZSBk ZWZpbmVkIHRvIGV4dGVuZCB0aGUgcHJvY29sLiBGb3IgZXhhbXBsZSwgaWYgdGhpcw0KPj4+IGRv Y3VtZW50IGhhZCBiZWVuIHdyaXR0ZW4gYSBjb3VwbGUgb2YgeWVhcnMgYWdvLCBpdCBtaWdodCBu b3QgaGF2ZSBtYWRlDQo+Pj4gcmVmZXJlbmNlIHRvIHJldHVybiwgbW9iaWxpdHksIG9yIERUTFMu DQo+PiANCj4+IEFzIEp1c3RpbiBzdWdnZXN0cywgd2Ugd2FudCB0aGUgbmV4dCByZXZpc2lvbiB0 byBwdXQgZm9ydGggZXhwbGljaXQgYmVzdA0KPj4gcHJhY3RpY2VzIGZvciBzZXJ2ZXIgc2VsZWN0 aW9uLiBGb3IgZHluYW1pYyBwcm9wZXJ0aWVzLCBsZWF2ZSB0aGUNCj4+ZGVjaXNpb24NCj4+IHRv IElDRS4NCj4+IA0KPj4gDQo+Pj4NCj4+PiBTZWNvbmQsIEkgdGhpbmsgdGhlIHNlbGVjdGlvbiBj cml0ZXJpYSBjb3VsZCBoYXZlIGRpZmZlcmVudCBwcmlvcml0aWVzDQo+Pj4gZm9yIGRpZmZlcmVu dCB1c2VycyBhbmQvb3IgYXBwbGljYXRpb25zLCBtYWtpbmcgdGhlIHJlY29tbWVuZGF0aW9ucw0K Pj4+IGRpZmZpY3VsdCB0byBhcHBseS4gRm9yIGV4YW1wbGUsIHRoZSBnb2FscyBvZiBsb2NhdGlv biBwcml2YWN5IGFuZA0KPj4+IHBlcmZvcm1hbmNlIGNvdWxkIGJlIGluIGNvbmZsaWN0LCBzaW5j ZSBhIHJlbGF5IHNlcnZlciBtb3JlIGNsb3NlbHkNCj4+PnRpZWQNCj4+PiB0byB0aGUgcGVlcidz IG5ldHdvcmsgZ2VvZ3JhcGhpYyBsb2NhdGlvbiB3aWxsIG9mdGVuIHByb3ZpZGUgYmV0dGVyDQo+ Pj4gcGVyZm9ybWFuY2UuDQo+PiANCj4+IFllcywgYnV0IGZvciBhbiBhcHBsaWNhdGlvbiwgb25l IHBhcmFtZXRlciBpcyBhbHdheXMgbW9yZSBzaWduaWZpY2FudA0KPj50aGF0DQo+PiBhbm90aGVy IHBhcmFtZXRlci4gRm9yIHRoZSBjYXNlIGFib3ZlLCBhbiBhcHBsaWNhdGlvbiBjaG9vc2VzIGxv Y2F0aW9uDQo+PiBwcml2YWN5IGlmIHRoYXSp9nMgb2YgdXRtb3N0IGltcG9ydGFuY2UuDQo+PiAN Cj4+ICAgIA0KPj4gLVByYXNoYW50aA0KPj4gDQo+PiANCj4+PiBUaGUgc2FtZSBjb3VsZCBiZSBz YWlkIGZvciBhbnkgY2FwYWJpbGl0eSBub3QgZGlyZWN0bHkNCj4+PiByZWxhdGVkIHRvIHRoZSBy ZWxheSBmdW5jdGlvbiwgc2luY2UgaXQgYW55IGxpbWl0YXRpb24gb24gdGhlIGNhbmRpZGF0ZQ0K Pj4+IHNldCBmb3IgcmVsYXkgc2VsZWN0aW9uIGNvdWxkIHJlc3VsdCBpbiBhZGRlZCBsYXRlbmN5 Lg0KPj4+DQo+Pj4gSWYgaXQncyBub3QgcG9zc2libGUgdG8gZ2l2ZSBpbXBsZW1lbnRhYmxlIHJl Y29tbWVuZGF0aW9ucyB0aGF0IHdpbGwNCj4+PiBoYXZlIG9uZ29pbmcgcmVsZXZhbmNlLCB0aGVu IHdoYXQncyB0aGUgcHVycG9zZSBvZiB0aGUgZG9jdW1lbnQgYXQgYWxsPw0KPj4+IE9uZSBwb3Nz aWJpbGl0eSBpcyB0aGF0IGl0IGNvdWxkIGJlIHVzZWQgdG8gcHJvdmlkZSBndWlkYW5jZSBmb3IN Cj4+PmF1dGhvcnMNCj4+PiBvZiBvdGhlciBkcmFmdHMsIGhlbHBpbmcgdGhlbSB0byBpZGVudGlm eSBpbXBvcnRhbnQgYXJlYXMgb2YgZGlzY3Vzc2lvbg0KPj4+IHJlbGV2YW50IHRvIG5ldyBUVVJO IG1lY2hhbmlzbXMgYW5kIHRoZWlyIGltcGFjdCBvbiBzZXJ2ZXIgc2VsZWN0aW9uLg0KPj4+IFRo aXMgd291bGQgYWxzbyBoZWxwIHJldmlld2VycyB0byByZW1lbWJlciB0byBhc2sgaW1wb3J0YW50 IHF1ZXN0aW9ucw0KPj4+IChlLmcuICJkb2VzIHRoaXMgZHJhZnQgZGlzY3VzcyB0aGUgaW1wYWN0 IG9uIGxvY2F0aW9uIHByaXZhY3k/IikuDQo+Pj4NCj4+PiBJJ3ZlIGdvdCBzb21lIGNvbW1lbnQg b24gdGhlIHNwZWNpZmljcyBvZiB0aGUgZHJhZnQgdG9vLCBidXQgSSdtIG5vdA0KPj4+IHN1cmUg aG93IHJlbGV2YW50IHRoZXkgYXJlIHVudGlsIEknbSBtb3JlIGNvbmZpZGVudCBhYm91dCB0aGUg aW50ZW5kZWQNCj4+PiBwdXJwb3NlL2dvYWxzIG9mIHRoZSBkcmFmdC4NCj4+Pg0KPj4+IC0tQnJh bmRvbg0KPj4+DQo+Pj4gT24gMDEvMDkvMjAxNSAxMToyOCBBTSwgR29uemFsbyBTYWxndWVpcm8g KGdzYWxndWVpKSB3cm90ZToNCj4+Pj4gVGhhbmtzLCBKdXN0aW4uICBXZSdsbCBjb2xsZWN0IEJy YW5kb24ncyBmZWVkYmFjayBvbiB0aGUgZHJhZnQgdG9vIGFuZA0KPj4+PiB0aGUgYXV0aG9ycyB3 aWxsIGRlbGliZXJhdGUgb24gdGV4dCBlZGl0cyBhbmQgcHJvZHVjZSBhIG5ldyB2ZXJzaW9uDQo+ Pj4+Zm9yDQo+Pj4+IHlvdXIgcmV2aWV3Lg0KPj4+Pg0KPj4+PiAtRw0KPj4+Pg0KPj4+Pg0KPj4+ Pj4gT24gSmFuIDgsIDIwMTUsIGF0IDU6MzQgUE0sIEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29v Z2xlLmNvbT4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4gQXQgSUVURiA5MSwgSSBwcm9taXNlZCB0byBz ZW5kIGZlZWRiYWNrIG9uIHRoaXMgZG9jdW1lbnQsIHNvIGhlcmUNCj4+Pj4+Z29lcy4NCj4+Pj4+ DQo+Pj4+PiBHZW5lcmFsbHksIEkgdGhpbmsgbWFueSBvZiB0aGUgaXNzdWVzIG1lbnRpb25lZCBp biB0aGlzIGRvY3VtZW50IGFyZQ0KPj4+Pj4gaW1wb3J0YW50LCBidXQgdGhlIHJlY29tbWVuZGF0 aW9ucyBhcmUgY29uZnVzaW5nIGFuZCBwb3NzaWJseQ0KPj4+Pj4gY29udHJhZGljdG9yeTsgYSBk ZXZlbG9wZXIgd2l0aCBsaXR0bGUga25vd2xlZGdlIG9mIFRVUk4gd2lsbCBoYXZlIGENCj4+Pj4+ IGhhcmQgdGltZSBmaWd1cmluZyBvdXQgZXhhY3RseSB3aGF0IHRvIGRvLiBGdXJ0aGVybW9yZSwg bWFueSBvZiB0aGUNCj4+Pj4+IHByb3BlcnRpZXMgZGlzY3Vzc2VkIGluIHRoaXMgZG9jdW1lbnQg YXJlIGR5bmFtaWMsIGFuZCBzaG91bGQgYmUNCj4+Pj4+IGhhbmRsZWQgYnkgdGhlIElDRSBwcm9j ZXNzLCByYXRoZXIgdGhhbiBpbiBUVVJOIHNlcnZlciBzZWxlY3Rpb24gKGZvcg0KPj4+Pj4gZXhh bXBsZSwgdGhlIG5vdGlvbiBvZiBSVFQgYXMgaXQgcmVsYXRlcyB0byB1c2VyIGV4cGVyaWVuY2Up Lg0KPj4+Pj4NCj4+Pj4+IFRoZXJlZm9yZSwgSSB0aGluayB0aGlzIGRvY3VtZW50IHNob3VsZCB0 YWtlIGEgc3Ryb25nZXIgc3RhbmNlIGFuZA0KPj4+Pj5wdXQNCj4+Pj4+IGZvcnRoIGV4cGxpY2l0 IGJlc3QgcHJhY3RpY2VzIGZvciBzZWxlY3Rpb24gKGFzIG9wcG9zZWQgdG8gInRoaW5ncyB0bw0K Pj4+Pj4gY29uc2lkZXIiKSwgZm9yIG5vbi1keW5hbWljIHByb3BlcnRpZXMsIGFuZCBsZWF2ZSB0 aGUgZGVjaXNpb25zIG9uDQo+Pj4+PiBkeW5hbWljIHByb3BlcnRpZXMgdG8gYmUgcmVzb2x2ZWQg YnkgSUNFLg0KPj4+Pj4NCj4+Pj4+IEZvciBleGFtcGxlLCBJIHRoaW5rIHdlIHNob3VsZCBvbWl0 IHRoZSB0ZXh0IGluIFNlY3Rpb24gMyBhYm91dCB3aGF0DQo+Pj4+PiB0byBkbyB3aXRoIG5vbi13 b3JraW5nIFRVUk4gc2VydmVycywgYW5kIG1lYXN1cmluZyBSVFQuIFNhbWUgZm9yDQo+Pj4+PiBT ZWN0aW9uIDMuMywgd2hpY2ggYWxzbyBkaXNjdXNzZXMgUlRULCBhbmQgU2VjdGlvbiAzLjQsIHdo aWNoIHRhbGtzDQo+Pj4+PiBhYm91dCBtdWx0aXBsZSBpbnRlcmZhY2VzLiBUaGlzIGNhbiBhbGwg YmUgaGFuZGxlZCBieSBJQ0UuDQo+Pj4+Pg0KPj4+Pj4gSW4gYWRkaXRpb24sIHRoZSBzZWN0aW9u cyBvbiBsb2NhbCBjb25maWcgYW5kIGxvY2F0aW9uIHByaXZhY3kgYXJlDQo+Pj4+PiB1bm5lY2Vz c2FyeSB3aGVuIFJFVFVSTiBpcyB1c2VkLiBXaGVuIFJFVFVSTiBpcyB1c2VkLCB0aGUgYXBwbGlj YXRpb24NCj4+Pj4+IGNhbiBhbHdheXMgdXNlIHRoZSBhcHAgVFVSTiBzZXJ2ZXIgZm9yIGxvY2F0 aW9uIHByaXZhY3ksIGFuZCB0aGUNCj4+Pj4+IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGxvY2FsIFRV Uk4gc2VydmVyIGFuZCBhcHAgVFVSTiBzZXJ2ZXIgaXMgZnVsbHkNCj4+Pj4+IHNwZWxsZWQgb3V0 LCBzbyB0aGVyZSBpcyBub3RoaW5nIGZvciB0aGUgYXBwbGljYXRpb24gdG8gZGVjaWRlIG9uLg0K Pj4+Pj4NCj4+Pj4+IFRoaXMgbGVhdmVzIG9ubHkgdGhlIFNlY3VyaXR5LCBBdXRoZW50aWNhdGlv biwgYW5kIE1vYmlsaXR5IHNlY3Rpb25zLg0KPj4+Pj4NCj4+Pj4+IEZvciBzZWN1cml0eSwgSSB0 aGluayB3ZSBjYW4gZ2l2ZSBzb21lIGNsZWFyIGd1aWRhbmNlIG9uIHdoYXQNCj4+Pj4+IGFwcGxp Y2F0aW9ucyBzaG91bGQgZG8uIEZvciBzZWN1cml0eSwgSSB0aGluayB0aGUgZ3VpZGFuY2Ugc2hv dWxkIGJlDQo+Pj4+PnRvDQo+Pj4+PiB1c2Ugb25seSBEVExTICsgVExTLCBpZiBib3RoIGFyZSBh dmFpbGFibGUsIHdpdGggZmFsbGJhY2sgdG8gVURQIG9yDQo+Pj4+PlRDUA0KPj4+Pj4gaWYgRFRM UyBvciBUTFMgYXJlbid0IGF2YWlsYWJsZS4gSWYgcHJpdmFjeSBpcyBwYXJhbW91bnQsIFVEUC9U Q1ANCj4+Pj4+IGZhbGxiYWNrIG1heSBiZSBjb250cmFpbmRpY2F0ZWQsIGJ1dCBhdCB0aGlzIHBv aW50IGluIHRpbWUsIERUTFMNCj4+Pj4+IGRlcGxveW1lbnQgaXNuJ3Qgd2lkZXNwcmVhZCBlbm91 Z2ggdG8gdHJ1bHkgcmVjb21tZW5kIHRoaXMuDQo+Pj4+Pg0KPj4+Pj4gVGhpcyByZWxhdGVzIHRv IHRoZSBBdXRoZW50aWNhdGlvbiBzZWN0aW9uIC0gYnV0IEkgdGhpbmsgYW55IGZhaWx1cmVzDQo+ Pj4+PiB0byBhdXRoZW50aWNhdGUgdGhlIHNlcnZlciBjZXJ0IHNob3VsZCBjYXVzZSB0aGUgVFVS TiBhbGxvY2F0aW9uIHRvDQo+Pj4+PiBmYWlsLiBUaGlzIGlzIGp1c3QgbGlrZSBhbnkgb3RoZXIg bWlzY29uZmlndXJhdGlvbiBvbiB0aGUgVFVSTg0KPj4+Pj5zZXJ2ZXIgLQ0KPj4+Pj4gdGhlcmUn cyBubyByZWFzb24gd2Ugc2hvdWxkIGV2ZW4gYWxsb3cgdXNlIG9mIFRVUk4gc2VydmVycyB3aG9z ZSBjZXJ0DQo+Pj4+PiBjaGFpbnMgZG9uJ3QgdmFsaWRhdGUuIFNvLCB0aGlzIHNlY3Rpb24gY291 bGQgcHJvYmFibHkgYmUgcmVtb3ZlZC4NCj4+Pj4+DQo+Pj4+PiBMYXN0bHksIHRoZSBNb2JpbGl0 eSBzZWN0aW9uIHNheXMgdGhhdCBpZiAiYWxsIG90aGVyIHBhcmFtZXRlcnMgW2FyZV0NCj4+Pj4+ IGVxdWFsIiwgYSBUVVJOIHNlcnZlciB3aXRoIG1vYmlsaXR5IHNob3VsZCBiZSB1c2VkLiBDbGVh cmx5LCBhbGwNCj4+Pj4+b3RoZXINCj4+Pj4+IHBhcmFtZXRlcnMgd2lsbCBub3QgYmUgZXF1YWwg KGUuZy4gUlRUKSwgYW5kIGV2ZW4gaWYgdGhleSB3ZXJlLCB0aGUNCj4+Pj4+IGNsaWVudCBoYXMg bm8gd2F5IHRvIGtub3cgaWYgYSBzZXJ2ZXIgaXMgbW9iaWxpdHktY2FwYWJsZSBhIHByaW9yaS4N Cj4+Pj4+U28NCj4+Pj4+IEkgdGhpbmsgdGhpcyByZWNvbW1lbmRhdGlvbiBvdWdodCB0byBiZSBy ZW1vdmVkLCBvciBwZXJoYXBzIHR1cm5lZA0KPj4+Pj5pbnRvDQo+Pj4+PiBzb21lIHNvcnQgb2Yg cmVjb21tZW5kYXRpb24gZm9yIFRVUk4gc2VydmVyIGRldmVsb3BlcnMgKGUuZy4gVFVSTg0KPj4+ Pj4gc2VydmVycyBTSE9VTEQgc3VwcG9ydCBUTFMvRFRMUywgU0hPVUxEIHN1cHBvcnQgbW9iaWxp dHksIFNIT1VMRA0KPj4+Pj4gc3VwcG9ydCByZWRpcmVjdCksIHByb2JhYmx5IGluIGEgc2VwYXJh dGUgZG9jLg0KPj4+Pj4NCj4+Pj4+IFRoZXNlIHJlY29tbWVuZGF0aW9ucyBzaG91bGQgcmVkdWNl IHRoZSBzaXplIG9mIHRoaXMgZG9jdW1lbnQgYW5kDQo+Pj4+PiBwcm92aWRlIG11Y2ggY2xlYXJl ciBhZHZpY2UgdG8gYXBwIGRldmVsb3BlcnMuDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4+Pj4+ IHRyYW1AaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdHJhbQ0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+PiB0cmFtIG1haWxpbmcgbGlzdA0KPj4+PiB0cmFtQGlldGYub3JnDQo+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPj4+Pg0KPj4+ DQo+Pj4gLS0gDQo+Pj4gQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBhbCBTb2Z0d2Fy ZSBFbmdpbmVlcg0KPj4+IEVtZXJnaW5nIFByb2R1Y3RzIEVuZ2luZWVyaW5nOyBBa2FtYWkgVGVj aG5vbG9naWVzIEluYy4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4+PiB0cmFtQGlldGYub3Jn DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQo+PiANCj4N Cj4tLSANCj5CcmFuZG9uIFdpbGxpYW1zOyBTZW5pb3IgUHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2lu ZWVyDQo+RW1lcmdpbmcgUHJvZHVjdHMgRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMg SW5jLg0KDQo= From nobody Thu Feb 19 13:44:16 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01331A0264; Thu, 19 Feb 2015 13:44:14 -0800 (PST) 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 LURF4R9W2MQs; Thu, 19 Feb 2015 13:44:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 605BF1A0278; Thu, 19 Feb 2015 13:44:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219214411.1732.95401.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 13:44:11 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-origin-05.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, 19 Feb 2015 21:44:15 -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 : An Origin Attribute for the STUN Protocol Authors : Alan Johnston Justin Uberti John Yoakum Kundan Singh Filename : draft-ietf-tram-stun-origin-05.txt Pages : 13 Date : 2015-02-19 Abstract: STUN, or Session Traversal Utilities for NAT, is a protocol used to assist other protocols traverse Network Address Translators or NATs. This specification defines an ORIGIN attribute for STUN that can be used in similar ways to the HTTP header field of the same name. WebRTC browsers utilizing STUN and TURN would include this attribute which would provide servers with additional information about the STUN and TURN requests they receive. This specification defines the usage of the STUN ORIGIN attribute for web, SIP, and XMPP contexts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-stun-origin-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-origin-05 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 Thu Feb 19 14:36:10 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E151A19FA for ; Thu, 19 Feb 2015 14:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD17eZEMkkri for ; Thu, 19 Feb 2015 14:35:58 -0800 (PST) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9BB1A1A03 for ; Thu, 19 Feb 2015 14:35:58 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id hy4so2311130vcb.10 for ; Thu, 19 Feb 2015 14:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZsDqymBObYsL9gIJWQvbmmiPzgKn1oufvpj3VmM49C8=; b=OK9FKwOnc63Kuoww9Y6yHHCZLmvDjoxR/5iQUYDKyRsRJ7Cs793xDz5SLqeh99CqYO FvyIQftMtbfgKl+G2ESCHiijBhxSa8gjPh3ZVmBA1WlNUUMqfRJjkBiMg2cJUbEg+M7k T5UN2gVVpwScSg6RBIpqLU7pdqxRLz5tj7J8MljcyMbrbfJZoGsFgoqcHfyONxqqz6xC TZNpG8Cg+6NGNVagO+sSCTFNDYdPpo8HJiGfVbkPZ46+WrRW8SE9x3YmXuBZQ0hg2vcl oFtEDeq7A+6s3K3wkZPhewbUcGFrBWAvfNWI3dVDvq7g7t5gVwTzzyalomRPlRLWr1rv 0XNA== MIME-Version: 1.0 X-Received: by 10.52.155.39 with SMTP id vt7mr3567244vdb.43.1424385357469; Thu, 19 Feb 2015 14:35:57 -0800 (PST) Received: by 10.52.121.111 with HTTP; Thu, 19 Feb 2015 14:35:57 -0800 (PST) In-Reply-To: <20150219214411.1732.95401.idtracker@ietfa.amsl.com> References: <20150219214411.1732.95401.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 16:35:57 -0600 Message-ID: From: Alan Johnston To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=089e0160cdfa415d3e050f788f8a Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stun-origin-05.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, 19 Feb 2015 22:36:01 -0000 --089e0160cdfa415d3e050f788f8a Content-Type: text/plain; charset=UTF-8 We have made a number of edits to the draft based on feedback and questions from our friendly neighborhood AD. Here are the major ones: 1. We made including ORIGIN a MUST for web origins (i.e. browsers) and a SHOULD for other origins (SIP, XMPP, etc.) 2. Instead of allowing the ORIGIN to be omitted for privacy, an empty ORIGIN is sent. 3. Clarified the usage scenarios. STUN binding and TURN allocate usages are a MUST, ICE and media keep-alive are a MUST NOT, and the others are NOT RECOMMENDED. 4. For browsers, JavaScript MUST NOT be able to modify the ORIGIN. - Alan - On Thu, Feb 19, 2015 at 3:44 PM, 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 : An Origin Attribute for the STUN Protocol > Authors : Alan Johnston > Justin Uberti > John Yoakum > Kundan Singh > Filename : draft-ietf-tram-stun-origin-05.txt > Pages : 13 > Date : 2015-02-19 > > Abstract: > STUN, or Session Traversal Utilities for NAT, is a protocol used to > assist other protocols traverse Network Address Translators or NATs. > This specification defines an ORIGIN attribute for STUN that can be > used in similar ways to the HTTP header field of the same name. > WebRTC browsers utilizing STUN and TURN would include this attribute > which would provide servers with additional information about the > STUN and TURN requests they receive. This specification defines the > usage of the STUN ORIGIN attribute for web, SIP, and XMPP contexts. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-stun-origin-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-origin-05 > > > 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 > --089e0160cdfa415d3e050f788f8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We have made a number of edits to the draft based on feedb= ack and questions from our friendly neighborhood AD.=C2=A0 Here are the maj= or ones:

1. We made including ORIGIN a MUST for web orig= ins (i.e. browsers) and a SHOULD for other origins (SIP, XMPP, etc.) =C2=A0=

2. Instead of allowing the ORIGIN to be omitted f= or privacy, an empty ORIGIN =C2=A0is sent. =C2=A0

= 3. Clarified the usage scenarios.=C2=A0 STUN binding and TURN allocate usag= es are a MUST, ICE and media keep-alive are a MUST NOT, and the others are = NOT RECOMMENDED.

4. For browsers, JavaScript MUST = NOT be able to modify the ORIGIN.

- Alan -


On Thu, Feb 19, 2015 at 3:44 PM, <internet-drafts@ietf.org&g= t; wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the TURN Revised and Modernized Working = Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= An Origin Attribute for the STUN Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Alan= Johnston
=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 Justin Uberti
=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 John Yoakum
=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 Kundan Singh
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tram-stun-origin-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 13
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-02-19

Abstract:
=C2=A0 =C2=A0STUN, or Session Traversal Utilities for NAT, is a protocol us= ed to
=C2=A0 =C2=A0assist other protocols traverse Network Address Translators or= NATs.
=C2=A0 =C2=A0This specification defines an ORIGIN attribute for STUN that c= an be
=C2=A0 =C2=A0used in similar ways to the HTTP header field of the same name= .
=C2=A0 =C2=A0WebRTC browsers utilizing STUN and TURN would include this att= ribute
=C2=A0 =C2=A0which would provide servers with additional information about = the
=C2=A0 =C2=A0STUN and TURN requests they receive.=C2=A0 This specification = defines the
=C2=A0 =C2=A0usage of the STUN ORIGIN attribute for web, SIP, and XMPP cont= exts.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tram-stun-orig= in/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tram-stun-origin-05<= br>
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-stu= n-origin-05


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

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

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

--089e0160cdfa415d3e050f788f8a-- From nobody Thu Feb 19 19:04:02 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0B81A1BA4 for ; Thu, 19 Feb 2015 19:04:01 -0800 (PST) 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 VTgzHktD4VaW for ; Thu, 19 Feb 2015 19:04:00 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48FBD1A1B5D for ; Thu, 19 Feb 2015 19:04:00 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id wp4so21832751obc.0 for ; Thu, 19 Feb 2015 19:03:59 -0800 (PST) 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=h1NwiNfCBZtkkLbt2wHo5ZbvZQROJQJKG55idInEOMU=; b=SboBWO8dbgQafTcdYjrYwrRMBO3lwGKNFAYQDJlyWIzFAEO/LhwrxLffpZHi7rh+tz ugoDHo+WxzAwKR+5Hrb5w/cfF6wsqQ4rFMZ/5wPAYRPeui5X3sWa8E3tZ2wdb8/Cbaxh R9tHfL4PPc+jAq1U95yRQhl8KJW+eLDE1cNOLOpu8bn4G7uPFhI014huH3xcl7eSe9O9 J+3ByypXCEBoCXy0biCqZ3ykrF0jrJR+BKR9spV3KgRCiYQknX/ktHRuH97/W2mRuxN7 Rm2lXOh8bCuQfTlLqQ0wv1suHsybc2mnEkMMCwjV9gp0rz35WTP1SZVo0XjxwFqedPgV mfIQ== MIME-Version: 1.0 X-Received: by 10.202.7.1 with SMTP id 1mr4824538oih.16.1424401439516; Thu, 19 Feb 2015 19:03:59 -0800 (PST) Received: by 10.202.225.135 with HTTP; Thu, 19 Feb 2015 19:03:59 -0800 (PST) In-Reply-To: <8120ABEA-F2EA-4A55-9322-44586A3A6D0D@iii.ca> References: <54DE8F5D.2030904@nostrum.com> <8120ABEA-F2EA-4A55-9322-44586A3A6D0D@iii.ca> Date: Fri, 20 Feb 2015 16:03:59 +1300 Message-ID: From: Martin Thomson To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Roach , "tram@ietf.org" Subject: Re: [tram] Server discovery comments 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, 20 Feb 2015 03:04:01 -0000 On 19 February 2015 at 12:59, Cullen Jennings wrote: > Seems about right.... one other things I wonder is given you do fine the address for a TURN server, how do you know what credentials to use ? I think that this is an important point to consider. If we consider that there is *some* preconfiguration involved, much of the framework might be unnecessary. For instance, if this were reduced to finding an instance of a TURN server, so that an enterprise user could find the server that covers the office that they are currently in, that produces a very different outcome. From nobody Fri Feb 20 05:59:39 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818F51A86E0 for ; Fri, 20 Feb 2015 05:59:38 -0800 (PST) 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 bgVd46uU2RGe for ; Fri, 20 Feb 2015 05:59:36 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C16A1A802E for ; Fri, 20 Feb 2015 05:59:36 -0800 (PST) Received: by lbiz11 with SMTP id z11so6379903lbi.8 for ; Fri, 20 Feb 2015 05:59:34 -0800 (PST) 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=0kp+riJOyhjIGJU2aSGDHlrpSqDxh5KS/aSg3Lc42pM=; b=bKY9IoqkngJhZ9/iUyxRR3zz0ynOcoPoAEX+gWDq9a70k6edj7OJ0tTx29gTY2ZVsz Bm2QDZRzs+ubuuZ3uzfCOOwsUzMtYAvLbZuTHGPChDY/QobzDGrQJ++Qy4LFHHWZYUVE EEBGiuFrc4aa0NymCjdYNKAPoqlr/2eFhYB5nnrHPG9pu1xm62IW3DITWMvYghP4Rnfo 3gAfibqs//RYxv9DtC/lPKjNrQN53+kONOaq7CtsjdYOiw6dWMcgsC0ssAAVeFNBYLlD WrFQ4QKsoeff0i5gu/a0txcC1it6VRnVwyITGfZt+8TXjJkihSxW0KuRi06NzQBskOiq AO0A== X-Gm-Message-State: ALoCoQkKo2zLifd6/Dn9miM9F/5jyleKaTj63zeuIxvNKIZya14X+tvpUPz4M2DpcmfUGIrs9lGl MIME-Version: 1.0 X-Received: by 10.112.132.67 with SMTP id os3mr8670819lbb.90.1424440774404; Fri, 20 Feb 2015 05:59:34 -0800 (PST) Received: by 10.25.205.144 with HTTP; Fri, 20 Feb 2015 05:59:34 -0800 (PST) In-Reply-To: References: <54DE8F5D.2030904@nostrum.com> <8120ABEA-F2EA-4A55-9322-44586A3A6D0D@iii.ca> Date: Fri, 20 Feb 2015 08:59:34 -0500 Message-ID: From: Simon Perreault To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b3a81925cc32d050f8576d2 Archived-At: Cc: Adam Roach , "tram@ietf.org" , Cullen Jennings Subject: Re: [tram] Server discovery comments 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, 20 Feb 2015 13:59:38 -0000 --047d7b3a81925cc32d050f8576d2 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 19, 2015 at 10:03 PM, Martin Thomson wrote: > On 19 February 2015 at 12:59, Cullen Jennings wrote: > > Seems about right.... one other things I wonder is given you do fine the > address for a TURN server, how do you know what credentials to use ? > > > I think that this is an important point to consider. > > If we consider that there is *some* preconfiguration involved, much of > the framework might be unnecessary. > > For instance, if this were reduced to finding an instance of a TURN > server, so that an enterprise user could find the server that covers > the office that they are currently in, that produces a very different > outcome. Well, the purpose of discovery is finding a "network-provided" server. It's not just any server in the cloud. It's not unrealistic to consider that access to a network-provided server could be "network-restricted", as in "if you can talk to it then you're implicitly authenticated". I know that doesn't equate authentication at all, but it would be good enough for the use cases I can think of. In any case, I agree that discovery must depend on no preconfiguration. Simon --047d7b3a81925cc32d050f8576d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Feb 19, 2015 at 10:03 PM, Martin Thomson <martin.thomson@gm= ail.com> wrote:
On 19 February 2015 at 12:59, Cullen Jennings <fluffy@iii.ca> wrote:
> Seems about right.... one other things I wonder is given you do fine t= he address for a TURN server, how do you know what credentials to use ?


I think that this is an important point to consider.

If we consider that there is *some* preconfiguration involved, much of
the framework might be unnecessary.

For instance, if this were reduced to finding an instance of a TURN
server, so that an enterprise user could find the server that covers
the office that they are currently in, that produces a very different
outcome.

Well, the purpose of discovery is finding a = "network-provided" server. It's not just any server in the cl= oud. It's not unrealistic to consider that access to a network-provided= server could be "network-restricted", as in "if you can tal= k to it then you're implicitly authenticated". I know that doesn&#= 39;t equate authentication at all, but it would be good enough for the use = cases I can think of.

In any case, I agree that discovery must depend on no prec= onfiguration.

Simon
--047d7b3a81925cc32d050f8576d2-- From nobody Fri Feb 20 13:41:54 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597101A017E for ; Fri, 20 Feb 2015 13:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 Rv6fOH-TqwKV for ; Fri, 20 Feb 2015 13:41:47 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8301A0193 for ; Fri, 20 Feb 2015 13:41:47 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t1KLfh0U092452 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Feb 2015 15:41:43 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54E7AA17.9010700@nostrum.com> Date: Fri, 20 Feb 2015 15:41:43 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Simon Perreault , Martin Thomson References: <54DE8F5D.2030904@nostrum.com> <8120ABEA-F2EA-4A55-9322-44586A3A6D0D@iii.ca> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080309090600020804010903" Archived-At: Cc: "tram@ietf.org" , Cullen Jennings Subject: Re: [tram] Server discovery comments 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, 20 Feb 2015 21:41:49 -0000 This is a multi-part message in MIME format. --------------080309090600020804010903 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/20/15 07:59, Simon Perreault wrote: > > On Thu, Feb 19, 2015 at 10:03 PM, Martin Thomson > > wrote: > > On 19 February 2015 at 12:59, Cullen Jennings > wrote: > > Seems about right.... one other things I wonder is given you do > fine the address for a TURN server, how do you know what > credentials to use ? > > > I think that this is an important point to consider. > > If we consider that there is *some* preconfiguration involved, much of > the framework might be unnecessary. > > For instance, if this were reduced to finding an instance of a TURN > server, so that an enterprise user could find the server that covers > the office that they are currently in, that produces a very different > outcome. > > > Well, the purpose of discovery is finding a "network-provided" server. > It's not just any server in the cloud. It's not unrealistic to > consider that access to a network-provided server could be > "network-restricted", as in "if you can talk to it then you're > implicitly authenticated". I know that doesn't equate authentication > at all, but it would be good enough for the use cases I can think of. Thanks; I was going to make this point. Much of the rationale for authenticating to TURN servers is because providing TURN service can cost non-trivial amounts of money due to the bandwidth involved. In some cases, there's a secondary rationale of being able to track users to prevent abusive traffic proxying. For the circumstances where auto discovery makes sense, these aren't really considerations. Considering the bandwidth involved: the autodiscovery cases I'm familiar with here are those where the TURN server is either on customers' premises (i.e., "on the edge" of the network), or where it's provided by the same entity responsible a customer's default route. For both of those cases, the bandwidth involved is effectively "free" -- or, at the very least, no more costly than an IP router. Similarly, the arguments for tracking traffic back to a user in these cases is approximately the same problem as tracking traffic back to a user through a NAT. All of which is to say: in the case of autodiscovery, I don't think delivering credentials is really a requirement. /a --------------080309090600020804010903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 2/20/15 07:59, Simon Perreault wrote:

On Thu, Feb 19, 2015 at 10:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 19 February 2015 at 12:59, Cullen Jennings <fluffy@iii.ca> wrote:
> Seems about right.... one other things I wonder is given you do fine the address for a TURN server, how do you know what credentials to use ?


I think that this is an important point to consider.

If we consider that there is *some* preconfiguration involved, much of
the framework might be unnecessary.

For instance, if this were reduced to finding an instance of a TURN
server, so that an enterprise user could find the server that covers
the office that they are currently in, that produces a very different
outcome.

Well, the purpose of discovery is finding a "network-provided" server. It's not just any server in the cloud. It's not unrealistic to consider that access to a network-provided server could be "network-restricted", as in "if you can talk to it then you're implicitly authenticated". I know that doesn't equate authentication at all, but it would be good enough for the use cases I can think of.

Thanks; I was going to make this point. Much of the rationale for authenticating to TURN servers is because providing TURN service can cost non-trivial amounts of money due to the bandwidth involved. In some cases, there's a secondary rationale of being able to track users to prevent abusive traffic proxying.

For the circumstances where auto discovery makes sense, these aren't really considerations.

Considering the bandwidth involved: the autodiscovery cases I'm familiar with here are those where the TURN server is either on customers' premises (i.e., "on the edge" of the network), or where it's provided by the same entity responsible a customer's default route. For both of those cases, the bandwidth involved is effectively "free" -- or, at the very least, no more costly than an IP router.

Similarly, the arguments for tracking traffic back to a user in these cases is approximately the same problem as tracking traffic back to a user through a NAT.

All of which is to say: in the case of autodiscovery, I don't think delivering credentials is really a requirement.

/a
--------------080309090600020804010903-- From nobody Tue Feb 24 10:48:00 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7ED1A8793 for ; Tue, 24 Feb 2015 10:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-lLQGw_K6GQ for ; Tue, 24 Feb 2015 10:47:57 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26CC1A1DE1 for ; Tue, 24 Feb 2015 10:47:56 -0800 (PST) Received: by wesw62 with SMTP id w62so27012700wes.12 for ; Tue, 24 Feb 2015 10:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=o6tE52/bVryMBJU/quvB426bP4ifO96FctCV82XYqQQ=; b=Kk0C45OBs4Pi2/ciqA0ImV1EjlBt7SZF602BpEO9ZKYek4Wx+T34ThYbzPxlf9/Bmf 7u0snCus8lNKrC9jFy+d2BIuaTdnE3POaOExJL8YwXuSl4CcoLR4AvRCARZ1nn2LBOdT X9Sb0vHXgTpg34zNdx7cgHbFQB5bZkjm5e2EvmJVIGAKwlM38eXXIMRUfZBBNthgIxQi 7UjzAEBXnhgozRbwHoQM8gR+6ACwHnxtj4mC/o2wiB2Fbxuc6L/j4ZPumwvteZEXTcFw 25miIFmueWxGQahlTDGkZvTulxLCp39Zk8RFe/swR6bWR49zHYwintXCHocfUGYl+v3d Iq8w== MIME-Version: 1.0 X-Received: by 10.194.6.228 with SMTP id e4mr34718186wja.63.1424803675468; Tue, 24 Feb 2015 10:47:55 -0800 (PST) Received: by 10.194.190.18 with HTTP; Tue, 24 Feb 2015 10:47:55 -0800 (PST) In-Reply-To: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> Date: Tue, 24 Feb 2015 10:47:55 -0800 Message-ID: From: Oleg Moskalenko To: "tram@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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: Tue, 24 Feb 2015 18:47:58 -0000 I checked the text and I am not sure that SCTP - over DTLS - over UDP is the right tunneling sequence. This is a typo or a mistake, I believe. I suppose that the right sequence is DTLS - over SCTP - over UDP. That would be easier to implement, it is closer to the "true" SCTP, and I see no security benefits in hiding SCTP inside DTLS. Thanks Oleg On Tue, Feb 17, 2015 at 8:32 AM, 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 : Session Traversal Utilities for NAT (STUN) > Authors : Marc Petit-Huguenin > Gonzalo Salgueiro > Jonathan Rosenberg > Dan Wing > Rohan Mahy > Philip Matthews > Filename : draft-ietf-tram-stunbis-01.txt > Pages : 57 > Date : 2015-02-17 > > Abstract: > Session Traversal Utilities for NAT (STUN) is a protocol that serves > as a tool for other protocols in dealing with Network Address > Translator (NAT) traversal. It can be used by an endpoint to > determine the IP address and port allocated to it by a NAT. It can > also be used to check connectivity between two endpoints, and as a > keep-alive protocol to maintain NAT bindings. STUN works with many > existing NATs, and does not require any special behavior from them. > > STUN is not a NAT traversal solution by itself. Rather, it is a tool > to be used in the context of a NAT traversal solution. > > This document obsoletes RFC 5389. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-stunbis-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-01 > > > 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 From nobody Tue Feb 24 11:01:11 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B4D1A87B8 for ; Tue, 24 Feb 2015 11:01:10 -0800 (PST) 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 k0nGMaCBvNgk for ; Tue, 24 Feb 2015 11:01:08 -0800 (PST) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4254E1A87B2 for ; Tue, 24 Feb 2015 11:01:08 -0800 (PST) Received: by qcvp6 with SMTP id p6so18259741qcv.12 for ; Tue, 24 Feb 2015 11:01:07 -0800 (PST) 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=6dZABwfjgaRcf3kb7caHtE6mCUMpz0w+Y9NpKuJIvMA=; b=brOlza2ZGIYEv9LInlWCjiAe9RQyBZiteW4WQ8uuGyjJso5ZCunxsCqnBw/igkjQYq AYjwJpTBzMGYAN1ourYrnHAH/Giw2JPsv3epLPXNfp0k1ITOM//nitgABUYp7hXJOI8p /WmD/W26s3u7XeWmWZK5u5wdOvH9LhCOE2R+u61vyxBr4O8TWWnOScTtEyyR8XneYt1Z UAGsRoHH0aTPLDN0/fpFF4i6+w8JXdKTDtvUaxQvP48QntEghOVYH77iypOFH3ClkrB9 yZrgWt2HWkZepmugONNYb3iGFVo8E0LgrjxGRagMd3TRGfTiyoXO9ZI2CKbyQc/oBzZ9 uwmg== X-Gm-Message-State: ALoCoQnN6PLibrAVcH8yF5YLX7eF22giSX+LmAkGvgnAQ2vvyFJ8+Qv40phkBdfX2P65Hx1Hc8oE X-Received: by 10.140.234.136 with SMTP id f130mr40729281qhc.49.1424804467434; Tue, 24 Feb 2015 11:01:07 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com. [209.85.216.45]) by mx.google.com with ESMTPSA id j190sm20022325qhc.33.2015.02.24.11.01.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 11:01:06 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id j7so28562193qaq.4 for ; Tue, 24 Feb 2015 11:01:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.17.9 with SMTP id 9mr37366676qgc.21.1424804466444; Tue, 24 Feb 2015 11:01:06 -0800 (PST) Received: by 10.229.160.201 with HTTP; Tue, 24 Feb 2015 11:01:06 -0800 (PST) In-Reply-To: References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> Date: Tue, 24 Feb 2015 14:01:06 -0500 Message-ID: From: Benjamin Schwartz To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a11c0b36a18ff17050fda245c Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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: Tue, 24 Feb 2015 19:01:10 -0000 --001a11c0b36a18ff17050fda245c Content-Type: text/plain; charset=UTF-8 WebRTC uses UDP/DTLS/SCTP, not the other way. On Tue, Feb 24, 2015 at 1:47 PM, Oleg Moskalenko wrote: > I checked the text and I am not sure that SCTP - over DTLS - over UDP > is the right tunneling sequence. This is a typo or a mistake, I > believe. > > I suppose that the right sequence is DTLS - over SCTP - over UDP. That > would be easier to implement, it is closer to the "true" SCTP, and I > see no security benefits in hiding SCTP inside DTLS. > > Thanks > Oleg > > > On Tue, Feb 17, 2015 at 8:32 AM, 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 : Session Traversal Utilities for NAT (STUN) > > Authors : Marc Petit-Huguenin > > Gonzalo Salgueiro > > Jonathan Rosenberg > > Dan Wing > > Rohan Mahy > > Philip Matthews > > Filename : draft-ietf-tram-stunbis-01.txt > > Pages : 57 > > Date : 2015-02-17 > > > > Abstract: > > Session Traversal Utilities for NAT (STUN) is a protocol that serves > > as a tool for other protocols in dealing with Network Address > > Translator (NAT) traversal. It can be used by an endpoint to > > determine the IP address and port allocated to it by a NAT. It can > > also be used to check connectivity between two endpoints, and as a > > keep-alive protocol to maintain NAT bindings. STUN works with many > > existing NATs, and does not require any special behavior from them. > > > > STUN is not a NAT traversal solution by itself. Rather, it is a tool > > to be used in the context of a NAT traversal solution. > > > > This document obsoletes RFC 5389. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-tram-stunbis-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-01 > > > > > > 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 > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a11c0b36a18ff17050fda245c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
WebRTC uses UDP/DTLS/SCTP, not the other way.

On Tue, Feb 24, 2015 at = 1:47 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">I checked the text and I am not sure that SCT= P - over DTLS - over UDP
is the right tunneling sequence. This is a typo or a mistake, I
believe.

I suppose that the right sequence is DTLS - over SCTP - over UDP. That
would be easier to implement, it is closer to the "true" SCTP, an= d I
see no security benefits in hiding SCTP inside DTLS.

Thanks
Oleg


On Tue, Feb 17, 2015 at 8:32 AM,=C2=A0 <internet-drafts@ietf.org> wrote:
>
> 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: Session Traversal Utilities for NAT (STUN)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Marc Petit-Huguenin
>=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=A0Gonzalo Salgueiro
>=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=A0Jonathan Rosenberg
>=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=A0Dan Wing
>=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=A0Rohan Mahy
>=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=A0Philip Matthews
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 := draft-ietf-tram-stunbis-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 57
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2015-02-17
>
> Abstract:
>=C2=A0 =C2=A0 Session Traversal Utilities for NAT (STUN) is a protocol = that serves
>=C2=A0 =C2=A0 as a tool for other protocols in dealing with Network Add= ress
>=C2=A0 =C2=A0 Translator (NAT) traversal.=C2=A0 It can be used by an en= dpoint to
>=C2=A0 =C2=A0 determine the IP address and port allocated to it by a NA= T.=C2=A0 It can
>=C2=A0 =C2=A0 also be used to check connectivity between two endpoints,= and as a
>=C2=A0 =C2=A0 keep-alive protocol to maintain NAT bindings.=C2=A0 STUN = works with many
>=C2=A0 =C2=A0 existing NATs, and does not require any special behavior = from them.
>
>=C2=A0 =C2=A0 STUN is not a NAT traversal solution by itself.=C2=A0 Rat= her, it is a tool
>=C2=A0 =C2=A0 to be used in the context of a NAT traversal solution. >
>=C2=A0 =C2=A0 This document obsoletes RFC 5389.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/=
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tram-stunbis-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-st= unbis-01
>
>
> 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

--001a11c0b36a18ff17050fda245c-- From nobody Tue Feb 24 11:08:19 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551371A1BCB for ; Tue, 24 Feb 2015 11:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yV4MNHb24_Xe for ; Tue, 24 Feb 2015 11:08:17 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08A21A1B7F for ; Tue, 24 Feb 2015 11:08:16 -0800 (PST) Received: by wesw62 with SMTP id w62so27120199wes.12 for ; Tue, 24 Feb 2015 11:08:15 -0800 (PST) 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=G2BVBafRODhFuB1mEzoQjjnZ85lQhBgW7/m3GlW//RU=; b=hZ+NmHAc0Ac4nmc3LsC51QG7CbzHbaHz1v8PO476dQas896S4Tztql6f3/3k9gYR63 qpofIkCpEgR86Jfq+mW7nUEBkbwEeQ1rJeLxaOoVsgQ9ZODZbQeDYWQZsBf3RE5xivcP uX8Uc7NsPFnwi9MidDu04WS6DNoTvxNcNejUtA07JqKxhkVAHFYxFbskY3ptMW74udud i5oj/By4K/2EWzBQPs8ZV2QfdlCVNIHjcdP0CZG+HruYKCldUdTM0FKR/4CM/7WwXbyD l1+k/nDN9qRBow549lxEupfiWbyrDDgzHBIMaKlYoNxiF+YvbgMaTQIhyZhRBfU6qn7H nPyw== MIME-Version: 1.0 X-Received: by 10.194.58.209 with SMTP id t17mr35554245wjq.156.1424804895369; Tue, 24 Feb 2015 11:08:15 -0800 (PST) Received: by 10.194.190.18 with HTTP; Tue, 24 Feb 2015 11:08:15 -0800 (PST) In-Reply-To: References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> Date: Tue, 24 Feb 2015 11:08:15 -0800 Message-ID: From: Oleg Moskalenko To: Benjamin Schwartz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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: Tue, 24 Feb 2015 19:08:18 -0000 I do not see word "webrtc" anywhere in the text. We are discussing STUN protocol here, right ? From the networking point of view, DTLS/SCTP/UDP makes much more sense. Thanks Oleg On Tue, Feb 24, 2015 at 11:01 AM, Benjamin Schwartz wrote: > WebRTC uses UDP/DTLS/SCTP, not the other way. > > On Tue, Feb 24, 2015 at 1:47 PM, Oleg Moskalenko > wrote: >> >> I checked the text and I am not sure that SCTP - over DTLS - over UDP >> is the right tunneling sequence. This is a typo or a mistake, I >> believe. >> >> I suppose that the right sequence is DTLS - over SCTP - over UDP. That >> would be easier to implement, it is closer to the "true" SCTP, and I >> see no security benefits in hiding SCTP inside DTLS. >> >> Thanks >> Oleg >> >> >> On Tue, Feb 17, 2015 at 8:32 AM, 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 : Session Traversal Utilities for NAT (STUN) >> > Authors : Marc Petit-Huguenin >> > Gonzalo Salgueiro >> > Jonathan Rosenberg >> > Dan Wing >> > Rohan Mahy >> > Philip Matthews >> > Filename : draft-ietf-tram-stunbis-01.txt >> > Pages : 57 >> > Date : 2015-02-17 >> > >> > Abstract: >> > Session Traversal Utilities for NAT (STUN) is a protocol that serves >> > as a tool for other protocols in dealing with Network Address >> > Translator (NAT) traversal. It can be used by an endpoint to >> > determine the IP address and port allocated to it by a NAT. It can >> > also be used to check connectivity between two endpoints, and as a >> > keep-alive protocol to maintain NAT bindings. STUN works with many >> > existing NATs, and does not require any special behavior from them. >> > >> > STUN is not a NAT traversal solution by itself. Rather, it is a tool >> > to be used in the context of a NAT traversal solution. >> > >> > This document obsoletes RFC 5389. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-tram-stunbis-01 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-01 >> > >> > >> > 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 >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram > > From nobody Tue Feb 24 11:12:11 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1150C1A1B4B for ; Tue, 24 Feb 2015 11:12:10 -0800 (PST) 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 tSq9LHNi4adH for ; Tue, 24 Feb 2015 11:12:08 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD211A886C for ; Tue, 24 Feb 2015 11:12:08 -0800 (PST) Received: by lams18 with SMTP id s18so27950287lam.11 for ; Tue, 24 Feb 2015 11:12:06 -0800 (PST) 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=tAFYsSqNQ7siJWHHK/Si+8j78X54OolsqlHajpPerSA=; b=kIYI4TvT8y6qKWBVMi2iK/HD8G/tVLF6PxwyGRWDSJeOTqDEQW0OjSXBtgo7Lq3g4w DCBmkVWM2WPEkgNguBMHIHiryTIRnNoJo1fvmeHO4Rru0akUAa+ET5JFb57S97I1uZQN 7DjEuRqFWwSbLRHrv2DGUhhxvDzy/rauYcEp/TJJBGiA0buM/p9tR8SXeQ+RFRDvOuY+ DRnDmHDJT7GCY7IEUc8cvGdjkpT4pUIcxPeJf4QfJI6gZzgIpej5eNUrjcdIdEgeifho Iww5WH3Pf50vFAoEs/yhZj/R9SD/TRvGW5fXME1ml93WR4Z7zqm7a50QYYUqIHjrFwLv VgUw== X-Gm-Message-State: ALoCoQkm3d3sLsGx+mAZhmQbrYb9WWeofBRDT6DcxmnHdmXA7ZrvDa1NJSsELetECU52iE3p1zLR MIME-Version: 1.0 X-Received: by 10.112.12.134 with SMTP id y6mr15957207lbb.34.1424805126664; Tue, 24 Feb 2015 11:12:06 -0800 (PST) Received: by 10.25.205.144 with HTTP; Tue, 24 Feb 2015 11:12:06 -0800 (PST) In-Reply-To: References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> Date: Tue, 24 Feb 2015 14:12:06 -0500 Message-ID: From: Simon Perreault To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a11c3a0e873097f050fda4b5a Archived-At: Cc: Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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: Tue, 24 Feb 2015 19:12:10 -0000 --001a11c3a0e873097f050fda4b5a Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 2:08 PM, Oleg Moskalenko wrote: > I do not see word "webrtc" anywhere in the text. We are discussing > STUN protocol here, right ? From the networking point of view, > DTLS/SCTP/UDP makes much more sense. > Is SCTP demultiplexing specified anywhere? Simon --001a11c3a0e873097f050fda4b5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Simon
--001a11c3a0e873097f050fda4b5a-- From nobody Tue Feb 24 11:22:19 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53021A8851 for ; Tue, 24 Feb 2015 11:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00gyRmeb5xgv for ; Tue, 24 Feb 2015 11:22:17 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EABD51A8887 for ; Tue, 24 Feb 2015 11:22:06 -0800 (PST) Received: by wggx12 with SMTP id x12so7418946wgg.11 for ; Tue, 24 Feb 2015 11:22:05 -0800 (PST) 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=vMrqoxaMwz0jPfA0svOaavJ5Zg/a+aoJy8rFWr8Nz18=; b=BnSSzJTBu3zlanqNHhHAAen+BS2Q8hMi2V5VG3mEFHh4yfA+fef5b6oQdY/o0cMcKC 2GsLSqE/6rnZRvP2SwFOzeWI4ycEs+7HonK9KQFv8sypPJjiDabyiA4VeBLm2u8Vj7Rn HsOa7+COSFtvlfchTRcOOmiACQpj7QSEvj91EB/sgm+whEWqRz0KoddDKoG7nrbxGS+S +NNZyZrNiNOhwCGBAw8wfj9uqgJihjIIcCzKuVoAAkYvuC9hsu4yiytV7fhbE0MIKAGT DP4R9IlYCZyAptVJFAOoZqi5btXi2PetqQ4PabvLCe/fXlta4kEjwD5iXKulzJxA4Uzw E62w== MIME-Version: 1.0 X-Received: by 10.194.205.138 with SMTP id lg10mr34138683wjc.130.1424805724330; Tue, 24 Feb 2015 11:22:04 -0800 (PST) Received: by 10.194.190.18 with HTTP; Tue, 24 Feb 2015 11:22:04 -0800 (PST) In-Reply-To: References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> Date: Tue, 24 Feb 2015 11:22:04 -0800 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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: Tue, 24 Feb 2015 19:22:17 -0000 I did not find any reference. But from the networking point of view, SCTP is supposed to be between IP and DTLS. If we cannot use IP directly and we substitute it for UDP, that's fine and that can be explained; but switching SCTP and DTLS looks like a bizarre and temporary hack. On Tue, Feb 24, 2015 at 11:12 AM, Simon Perreault wrote: > > On Tue, Feb 24, 2015 at 2:08 PM, Oleg Moskalenko > wrote: >> >> I do not see word "webrtc" anywhere in the text. We are discussing >> STUN protocol here, right ? From the networking point of view, >> DTLS/SCTP/UDP makes much more sense. > > > Is SCTP demultiplexing specified anywhere? > > Simon From nobody Tue Feb 24 11:48:46 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026891A889D for ; Tue, 24 Feb 2015 11:48:45 -0800 (PST) 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 byI_DfPJXHnj for ; Tue, 24 Feb 2015 11:48:40 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 1148D1A88A3 for ; Tue, 24 Feb 2015 11:48:40 -0800 (PST) Received: from [IPv6:2602:43:2a2:c600:d042:c91f:1d4e:8558] (unknown [IPv6:2602:43:2a2:c600:d042:c91f:1d4e:8558]) (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 3C1862002A; Tue, 24 Feb 2015 20:48:38 +0100 (CET) Message-ID: <54ECD593.9060502@acm.org> Date: Tue, 24 Feb 2015 12:48:35 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Benjamin Schwartz , Oleg Moskalenko References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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: Tue, 24 Feb 2015 19:48:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Yes, the intent is "whatever the WebRTC guys are using", so experience and code (and bugs) can be shared. On 02/24/2015 12:01 PM, Benjamin Schwartz wrote: > WebRTC uses UDP/DTLS/SCTP, not the other way. > > On Tue, Feb 24, 2015 at 1:47 PM, Oleg Moskalenko > wrote: > > I checked the text and I am not sure that SCTP - over DTLS - over UDP > is the right tunneling sequence. This is a typo or a mistake, I > believe. > > I suppose that the right sequence is DTLS - over SCTP - over UDP. That > would be easier to implement, it is closer to the "true" SCTP, and I > see no security benefits in hiding SCTP inside DTLS. > > Thanks > Oleg > > > On Tue, Feb 17, 2015 at 8:32 AM, > 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 : Session Traversal Utilities for NAT (STUN) > > Authors : Marc Petit-Huguenin > > Gonzalo Salgueiro > > Jonathan Rosenberg > > Dan Wing > > Rohan Mahy > > Philip Matthews > > Filename : draft-ietf-tram-stunbis-01.txt > > Pages : 57 > > Date : 2015-02-17 > > > > Abstract: > > Session Traversal Utilities for NAT (STUN) is a protocol that serves > > as a tool for other protocols in dealing with Network Address > > Translator (NAT) traversal. It can be used by an endpoint to > > determine the IP address and port allocated to it by a NAT. It can > > also be used to check connectivity between two endpoints, and as a > > keep-alive protocol to maintain NAT bindings. STUN works with many > > existing NATs, and does not require any special behavior from them. > > > > STUN is not a NAT traversal solution by itself. Rather, it is a tool > > to be used in the context of a NAT traversal solution. > > > > This document obsoletes RFC 5389. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-tram-stunbis-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-01 > > > > > > 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 > > _______________________________________________ > 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 > - -- 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 iQIcBAEBCAAGBQJU7NWTAAoJECnERZXWan7E8BgQAJhUAi0vuO0roBaIAX4nwPjJ Ry386jUj7FHM77pLz6sD8MpmGJUceSwqBnznTIbPk3A9hmcVxjVXDWRQ6YectUnG /FcDhChKbesOJOGfMWBss/5nRv1Y5PvJZeLLmfbE4B2Mbw5NVv+OMHfaZ0QSd4tv nep794r/oAAyz37mxNiL0mLYH9xfG6ZSPx+aHVGt9MA8e3xNE8SZx7SQJPeG/9/s CF/79wwVXZ050gzXez0WTX2t8ZQ+xURpBqMCVa8tudHt6ouhGBS1NYY/8lyALKsA 0nI5NXv/XPYnldKoxYQEMbeq+CYKsVUNecLHd3IJnU3PIBiN0hgKn12bqWoqvL/w WA1BxcGGrpvwG75UrESlGpLQ7l7V4N/n0FozwEIjy96vIVw/GfWAHDFUkFB8MwTf fheNu1kUbwj+2VPLxdyVvVDNmVFsPrCuGB24gARWI0Wmta0LB7iFqlnNauE+k5Te exs21nl6PineZBXPbVmsfk/oEMyKQILu4YQbBTMKrFoLywdP9yDQ48gS+ZVIeRnH 9/NJDP4fjaO5jzdWFYeNy3hRLu7M631ICl05vt7n29z7p8ZYhBX0tr9FcmZ897wC 3D74h00yPilsKZnDWDn1o8de5KQa3oNOvLBMVJ0vj+k4ebPGWzXbQAzeT+QD7o1j Lz7vrcTBn6dk26B7RRJV =cvQY -----END PGP SIGNATURE----- From nobody Tue Feb 24 11:51:05 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7688A1A889D for ; Tue, 24 Feb 2015 11:51:03 -0800 (PST) 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 Mk14WqgBLuBD for ; Tue, 24 Feb 2015 11:51:01 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id D7D4D1A8898 for ; Tue, 24 Feb 2015 11:51:01 -0800 (PST) Received: from [IPv6:2602:43:2a2:c600:d042:c91f:1d4e:8558] (unknown [IPv6:2602:43:2a2:c600:d042:c91f:1d4e:8558]) (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 0FF3A2002A; Tue, 24 Feb 2015 20:51:00 +0100 (CET) Message-ID: <54ECD623.9060500@acm.org> Date: Tue, 24 Feb 2015 12:50:59 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Simon Perreault , Oleg Moskalenko References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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: Tue, 24 Feb 2015 19:51:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/24/2015 12:12 PM, Simon Perreault wrote: > > On Tue, Feb 24, 2015 at 2:08 PM, Oleg Moskalenko > wrote: > > I do not see word "webrtc" anywhere in the text. We are discussing > STUN protocol here, right ? From the networking point of view, > DTLS/SCTP/UDP makes much more sense. > > > Is SCTP demultiplexing specified anywhere? > Section 6.2.3: "... the SCTP source and destination ports MUST be chosen so the two most significant bits are 0b11." - -- 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 iQIcBAEBCAAGBQJU7NYiAAoJECnERZXWan7Ec0MQAMqFI6T0q2+xSyG333/yfENP +GoV9J2Xqe/7Rk2O6ojwZheL/8SIc2dnbryIex4/k/qOjxNCdsIkjRLMPwVX0e0l rQ8eFjHjpeT4VQBNzs5J7AcJtEVmUQzSVlpZGnFfQdNhg87GmBkqpDFlIw+CkmVJ j55RSekRVziBEEShToIn6s8pVrf0NUf2Wg/w+NtN4DS/GqiDhrUAfPDfwSq+lPtT qitQx0tg9znLeYtsJli+zpozX/Su2KqHIy5u0HzRdRpKAV6pkOhcJXAR2Zc0sn6u UaGP3qoMGR/ku7DMSD7eC7q6zQQhBzUbotHPbVZSg5m7H1A/k0GXQkoqGiwB9zNA yMLX4XmdpjYAl1RFeaX0kQtsHpv3MY8irfW873AHSJiyc2fQKQGBxdhpyQVAJXPA 7pAeYv9h64B20dvN+EPJuvQ/Ujv/Rrgxzn3kIqp9ppntwJm4VXRa7iNIU3PMGdhI fSAJyENkhxHZ/CKCs3GUOBqa+5cgNKOAAVIYN9a4S7Jzm1bp3wbV789FB2K4uVAi YcQVMT3/GXLHPnEO6VADPeUxaqie2pR8g6t47zBVabEZ83ag56zcTimCEOho8MFE WWdaopqZPMY3cshMGEkZxhihWiyWRdB4CD301+HMzgY06w+O/9y8VhPtV39DIirQ gI2hcxiyV7rgEKjaXneY =Bfjb -----END PGP SIGNATURE----- From nobody Tue Feb 24 12:11:16 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39B61A1EFF for ; Tue, 24 Feb 2015 12:11:14 -0800 (PST) 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 lgfjgq-8q513 for ; Tue, 24 Feb 2015 12:11:10 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2281A88A7 for ; Tue, 24 Feb 2015 12:11:10 -0800 (PST) Received: by lbiz11 with SMTP id z11so27523396lbi.5 for ; Tue, 24 Feb 2015 12:11:08 -0800 (PST) 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=uAyYj//c4x00/4fsL6n70U7L1HW4J67FbOk0HDekPuI=; b=jKg7GTE6l1f08ShF29VrzuGos4Z74oCX4zcdWPOMFeaeYMSM3WzALuNXai1TzgQPI4 vDUfdOBdgTWgIWaTKxE9UbVQXlwvSiMV8i35DQpYqbvQC8dmrY/gyINFmhqT9gnlHcyu JZDVhFCBbllWbjD5qg9Pa6nEup9vU2c89waxWtVhqzeiVj1XSImt/Xp/s1eIK/Y/xjrA xUm7+Fbk0cnXsOSXBvvPzOpfdVoLDAOecFC6C+BeqzsASp5JD1aVDmFLrDI5aqPECkXt i2eE2vAl6qBh+880evHkUJQX2U/jtycsVq3lUCNWqmez3/qV43Cx8++cvzc2dQ1Vqs4Q uxNQ== X-Gm-Message-State: ALoCoQnXSO2m73iXX3ABH57nz9I3osxCqD0BHXwj7q3VXJxtVmzBlgxgrI5GWaF77Q+7OpUcMc/g MIME-Version: 1.0 X-Received: by 10.152.36.101 with SMTP id p5mr4518807laj.34.1424808668676; Tue, 24 Feb 2015 12:11:08 -0800 (PST) Received: by 10.25.205.144 with HTTP; Tue, 24 Feb 2015 12:11:08 -0800 (PST) In-Reply-To: <54ECD623.9060500@acm.org> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54ECD623.9060500@acm.org> Date: Tue, 24 Feb 2015 15:11:08 -0500 Message-ID: From: Simon Perreault To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=089e0158b5bc91daff050fdb1ee1 Archived-At: Cc: Oleg Moskalenko , Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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: Tue, 24 Feb 2015 20:11:14 -0000 --089e0158b5bc91daff050fdb1ee1 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 2:50 PM, Marc Petit-Huguenin wrote: > > Is SCTP demultiplexing specified anywhere? > > Section 6.2.3: "... the SCTP source and destination ports MUST be chosen > so the two most significant bits are 0b11." > I see! Clever. It would be awesome if you could update draft-petithuguenin-avtcore-rfc5764-mux-fixes to match this before the deadline! Simon --089e0158b5bc91daff050fdb1ee1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Feb 24, 2015 at 2:50 PM, Marc Petit-Huguenin <= petithug@acm.org&= gt; wrote:
> Is SCTP demulti= plexing specified anywhere?

Section 6.2.3: "... the SCTP source and destination ports MUST = be chosen so the two most significant bits are 0b11."
=

I see! Clever.

It would be awesome if you could update draft-petithugue= nin-avtcore-rfc5764-mux-fixes to match this before the deadline!

Simon
--089e0158b5bc91daff050fdb1ee1-- From nobody Tue Feb 24 12:17:09 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1601A88AE for ; Tue, 24 Feb 2015 12:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jyfjr6nbISvP for ; Tue, 24 Feb 2015 12:17:07 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22631A6EDE for ; Tue, 24 Feb 2015 12:17:06 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id h11so28368120wiw.3 for ; Tue, 24 Feb 2015 12:17:05 -0800 (PST) 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=dBN1m+d7/wBOFebrZUv/qenTYVxWabktyPOQwuc0T9E=; b=zp5qfzlsVx8V8IZGGkXt4Ug6kcOhs4Wrr2jWKcJkIWbeH4w91ZiUaaCBWcJkb3mX6s 8FxuM8sf/2mvvbw5BlRso0w/mMU7SvcmtoGJDTuUNqso0pOADdzk9g+kCby0CACZZDiQ OYbkAVHeRQYY/vdT7mD0aVCkAA9209yom0IXUGRQVjPQp4Kfnes7MLWpm4FOp/GchRA3 7/g7WJ4iV8TqGX9QKT0TMpeyRirZj7LTI0fl9Pu3JnZAz0t2L/4GMnoK0PeuKlsUU7vq slN8CfJ9i5FeNzmwM42KsPt06cPjOCowO9gBeG4mTcwfS2ScyX+e6iawtscLJCbjU7ml dKoQ== MIME-Version: 1.0 X-Received: by 10.194.6.228 with SMTP id e4mr35394702wja.63.1424809025485; Tue, 24 Feb 2015 12:17:05 -0800 (PST) Received: by 10.194.190.18 with HTTP; Tue, 24 Feb 2015 12:17:05 -0800 (PST) In-Reply-To: <54ECD623.9060500@acm.org> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54ECD623.9060500@acm.org> Date: Tue, 24 Feb 2015 12:17:05 -0800 Message-ID: From: Oleg Moskalenko To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Simon Perreault , Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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: Tue, 24 Feb 2015 20:17:08 -0000 > Section 6.2.3: "... the SCTP source and destination ports MUST be chosen so the two most significant bits are 0b11." 0b11 looks more like bytes than bits. From nobody Tue Feb 24 12:20:46 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951321A6EDE for ; Tue, 24 Feb 2015 12:20:44 -0800 (PST) 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 5JXEDcPpoFhG for ; Tue, 24 Feb 2015 12:20:43 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 20FCD1A8861 for ; Tue, 24 Feb 2015 12:20:43 -0800 (PST) Received: from [IPv6:2602:43:2a2:c600:d042:c91f:1d4e:8558] (unknown [IPv6:2602:43:2a2:c600:d042:c91f:1d4e:8558]) (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 D7DCE2002A; Tue, 24 Feb 2015 21:20:41 +0100 (CET) Message-ID: <54ECDD17.5020608@acm.org> Date: Tue, 24 Feb 2015 13:20:39 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Simon Perreault References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54ECD623.9060500@acm.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Oleg Moskalenko , Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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: Tue, 24 Feb 2015 20:20:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/24/2015 01:11 PM, Simon Perreault wrote: > > On Tue, Feb 24, 2015 at 2:50 PM, Marc Petit-Huguenin > wrote: > > > Is SCTP demultiplexing specified anywhere? > > Section 6.2.3: "... the SCTP source and destination ports MUST be chosen so the two most significant bits are 0b11." > > > I see! Clever. With thanks to Michael Tuexen for his help on this. > > It would be awesome if you could update draft-petithuguenin-avtcore-rfc5764-mux-fixes to match this before the deadline! We plan to do so. 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 iQIcBAEBCAAGBQJU7N0XAAoJECnERZXWan7ERTcQAIZoN83ph4FPlXK+3L63q44D 6902VGQOhdit8QVQIn7pTuIZbAa0Of4nEzgHYtPPSEm/b1j2Rw2LXU2m3dCJmM+X N342p3KGMt0+GC3uuuytsEzQxJkFfo4PANcyY/DkGd7DOrU29F70QWR8Zn2tZ7KN XsbjOyBwpwgjoW3/mW0r1UqP/UAsE8FVL9tAxYW7kkSplYAF2iS6mPe84fe9jzxu t6xtDni9G1jM472eXMhQI2VxrUrVxb+9iNrSkxGP5zmfxPtEE+HpNTAE5SoCSFU2 x8i2tnX2tprkD3WX0jEmxQXhHzL6i2F2wOzPGqSZD+1SfT67qvUZyFXTJ3A+j133 qP7GkqAWzioJNFf8ciVdFpm5jIKaEYUE+BDi1z8lKm2AzkUQetUacrRobIg580kv d1K2RncVVAv4tpFWkMvbTvy1hKlQDsa//NTGOxTzxW5Ln6uVxvg9M/BB5m3iZKPi egWoXmDRtFul7Ym+SWDYWhqtxxwIa2nsakK9nIKJGd54w/5M81jikIuXV9amek4b Ew1EjquZeOj24Ki0xy8AD8t52psz9nESSsDQ9UuihjBCuoh4l+RFk2MxocfEuniy uoeP3Ap2MrLo5kLo7N/0FvdcH5g41MOLDRYSDI6WCMx11vPlAtWVKCp5AIsbLjMp OzmRV8UJ131h5uU7OGDn =GUi3 -----END PGP SIGNATURE----- From nobody Tue Feb 24 12:26:19 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACA11A88C5 for ; Tue, 24 Feb 2015 12:26:17 -0800 (PST) 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 5zL4Gmz3XcgP for ; Tue, 24 Feb 2015 12:26:16 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 578DB1A88C3 for ; Tue, 24 Feb 2015 12:26:16 -0800 (PST) Received: from [IPv6:2602:43:2a2:c600:d042:c91f:1d4e:8558] (unknown [IPv6:2602:43:2a2:c600:d042:c91f:1d4e:8558]) (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 73C152002A; Tue, 24 Feb 2015 21:26:15 +0100 (CET) Message-ID: <54ECDE65.1070803@acm.org> Date: Tue, 24 Feb 2015 13:26:13 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54ECD623.9060500@acm.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Simon Perreault , Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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: Tue, 24 Feb 2015 20:26:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/24/2015 01:17 PM, Oleg Moskalenko wrote: >> Section 6.2.3: "... the SCTP source and destination ports MUST be chosen so the two most significant bits are 0b11." > > 0b11 looks more like bytes than bits. Java binary literal. Will fix. - -- 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 iQIcBAEBCAAGBQJU7N5lAAoJECnERZXWan7EYToP/3z6PAAnf+bsbnsXYKow5k/L MVg9w9QrHyXNGhyHIs1giLb7iaLsBKw3LikIUc90tb4644yWdJ9WyRAYxMPg09QG GMNx4bne/CfiOPWUtLfBmZw5+v1Qz5l7AwAs1T+pAJx2jpt+HGrQAllfcfVgbMXD bdwO/ZV4JEibragKoegQ6/CmGELK2c/sjkSQPTMsRrrh2eRWaJQHo065E1B5fdwX TcjXojv/FBGFeJ6pjL1CzxWHfMYJLU4s0YSGq+fvlCd1/x3U5YogDHKqhI44UYPl iSTFVFglHNUuNj5J9n+V4uonpefO8aKzfbp1ox5WvHnaKv7rKmxFF2QrsLYT1E2O Xai3HunLMx4ENKlQ+brrOCVea2GRHiv4/brabLyPd/wiPbMV5X+DxnwTLaOuoPgg TJGrIrFnLc2zuYXFZQBsosOlqGwiiEy5kh8Lc1W50tkpuhMPYhphOuGTOtF4ECD4 IhB3at8015fXJLeavAmkCNE2ieDaRmNuKvmcLF3AFMxV1VSUEHkjk1+pzQhYtti3 Qixc7Wb3/JMVqXc8RjcLPsPY5XZuc50d/PbQ+8hpQJuhbJE11MBwUi9lKQuat6d3 WNV6etnffrpYC6ne6qsfAT9hp86BkNGeZJPpCg8fKrXwCWp3wuD0/lwnkGpV0Oc+ 4kysS2Z8wld1kKcKGaqV =+FJI -----END PGP SIGNATURE----- From nobody Tue Feb 24 20:45:36 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0118F1A9084 for ; Tue, 24 Feb 2015 20:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i_GbYWenXzO for ; Tue, 24 Feb 2015 20:45:34 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD481A0126 for ; Tue, 24 Feb 2015 20:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4009; q=dns/txt; s=iport; t=1424839534; x=1426049134; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j4PKN8k96GXzL/XQ4WanX9stLfz5jtk3dZQO87UzMDU=; b=T+0tj2nQI8a/7pWCARcYLzbjymz7EFWIGOfVonEOCv7XWJHIAvwLqGP9 wY04QkkO6+kUHp+j7em/eXaf3Az7et7WaO46cO+VGFjjCBGsanvxTl/MB gynQxnxHHyDgz4sJdOmNKU2/mrnGeh8sJHNGv6AoiZefxWJTMtacDTtbD A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BABQDsUu1U/4UNJK1bgwVSVQUEwHqCIAqFcAKBKEMBAQEBAQF8hA8BAQEEAQEBNzQLDAQCAQgOAwQBAQEKFAkHIQYLFAkIAgQBDQUIARKIAAMRCAXPAQ2FMQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLE4JEgXkxBwaDEYEUBY9bg2CEH4JhOYJgiQCGByKDbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,643,1418083200"; d="scan'208";a="398877157" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP; 25 Feb 2015 04:45:33 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t1P4jXKD025793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Feb 2015 04:45:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Tue, 24 Feb 2015 22:45:33 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , Benjamin Schwartz Thread-Topic: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt Thread-Index: AQHQSs9eowAbQmERAkOzA1uv2nxY/J0Ak8OAgAADrwCAAAH/gIAAPEbg Date: Wed, 25 Feb 2015 04:45:32 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366A7389@xmb-rcd-x10.cisco.com> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.56.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 25 Feb 2015 04:45:36 -0000 Even in WebRTC why should STUN messages be sent over SCTP over DTLS over UD= P ? -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko > Sent: Wednesday, February 25, 2015 12:38 AM > To: Benjamin Schwartz > Cc: tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >=20 > I do not see word "webrtc" anywhere in the text. We are discussing STUN > protocol here, right ? From the networking point of view, DTLS/SCTP/UDP > makes much more sense. >=20 > Thanks > Oleg >=20 >=20 > On Tue, Feb 24, 2015 at 11:01 AM, Benjamin Schwartz > wrote: > > WebRTC uses UDP/DTLS/SCTP, not the other way. > > > > On Tue, Feb 24, 2015 at 1:47 PM, Oleg Moskalenko > > > wrote: > >> > >> I checked the text and I am not sure that SCTP - over DTLS - over UDP > >> is the right tunneling sequence. This is a typo or a mistake, I > >> believe. > >> > >> I suppose that the right sequence is DTLS - over SCTP - over UDP. > >> That would be easier to implement, it is closer to the "true" SCTP, > >> and I see no security benefits in hiding SCTP inside DTLS. > >> > >> Thanks > >> Oleg > >> > >> > >> On Tue, Feb 17, 2015 at 8:32 AM, 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 : Session Traversal Utilities for NAT (STUN) > >> > Authors : Marc Petit-Huguenin > >> > Gonzalo Salgueiro > >> > Jonathan Rosenberg > >> > Dan Wing > >> > Rohan Mahy > >> > Philip Matthews > >> > Filename : draft-ietf-tram-stunbis-01.txt > >> > Pages : 57 > >> > Date : 2015-02-17 > >> > > >> > Abstract: > >> > Session Traversal Utilities for NAT (STUN) is a protocol that ser= ves > >> > as a tool for other protocols in dealing with Network Address > >> > Translator (NAT) traversal. It can be used by an endpoint to > >> > determine the IP address and port allocated to it by a NAT. It c= an > >> > also be used to check connectivity between two endpoints, and as = a > >> > keep-alive protocol to maintain NAT bindings. STUN works with ma= ny > >> > existing NATs, and does not require any special behavior from the= m. > >> > > >> > STUN is not a NAT traversal solution by itself. Rather, it is a = tool > >> > to be used in the context of a NAT traversal solution. > >> > > >> > This document obsoletes RFC 5389. > >> > > >> > > >> > The IETF datatracker status page for this draft is: > >> > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ > >> > > >> > There's also a htmlized version available at: > >> > http://tools.ietf.org/html/draft-ietf-tram-stunbis-01 > >> > > >> > A diff from the previous version is available at: > >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-stunbis-01 > >> > > >> > > >> > 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 > >> > >> _______________________________________________ > >> tram mailing list > >> tram@ietf.org > >> https://www.ietf.org/mailman/listinfo/tram > > > > >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Feb 24 20:51:27 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7088C1A908D for ; Tue, 24 Feb 2015 20:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyMs5H9lyNkZ for ; Tue, 24 Feb 2015 20:51:24 -0800 (PST) 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 4BB3D1A908C for ; Tue, 24 Feb 2015 20:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5246; q=dns/txt; s=iport; t=1424839884; x=1426049484; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IHyEyOhLL8ZGAD2BNm1fPOtnU1Q4uIG19AKiTBesE6s=; b=URjN2vfozDtwp0uHvXqNc18Yhzswppppm/4j48/5OrBrvgb9UhB2VkQa V09LX8tv9DJGJr3o5yyV+miNGfeEgqc9GsThLlLLK69G6FNu5jQBMDgfZ ioClQ2v4qfqrW7bNRVqiq9rNuSHG9H29d2tTn/g/XhFTpAFT7Weh4/e5i s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BABQCHVO1U/5BdJa1bgwVSVQUEwHqCIAqFcAKBKEMBAQEBAQF8hA8BAQEEAQEBNzQXBAIBCBEEAQEBCg4GCQcnCxQJCAIEARIIARKIFAgF1EEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixOCNYFXEQEfOAYSgn+BFAWPW4NghwA5gmCIOYZOIoIBHYFQbwGBCjl/AQEB X-IronPort-AV: E=Sophos;i="5.09,643,1418083200"; d="scan'208";a="126676192" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 25 Feb 2015 04:51:16 +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 t1P4pGH1011684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Feb 2015 04:51:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 24 Feb 2015 22:51:15 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Marc Petit-Huguenin , "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt Thread-Index: AQHQSs9eowAbQmERAkOzA1uv2nxY/Jz2n18AgAo3ZZA= Date: Wed, 25 Feb 2015 04:51:15 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366A73A5@xmb-rcd-x10.cisco.com> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54E46D9C.3010507@acm.org> In-Reply-To: <54E46D9C.3010507@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.56.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 25 Feb 2015 04:51:26 -0000 The cipher suites and other recommendations in http://tools.ietf.org/html/d= raft-ietf-uta-tls-bcp-09 must be used and there is no need explicitly menti= on the subset in section 6.2.4 -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Marc Petit- > Huguenin > Sent: Wednesday, February 18, 2015 4:17 PM > To: tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > All, >=20 > We have requested 40 minutes in Dallas to discuss the modifications > summarized below. We plan to release -02 before the cutoff with minor > edits for the remaining of the TODO list, but we wanted to release a firs= t > version with the most important modifications ahead of the meeting. We > may not have the time to answer every email before Dallas, but we will > collect the feedback and address it appropriately during the meeting. >=20 > Thanks. >=20 > Changelog: >=20 > o Add negotiation mechanism for new password algorithms. > o Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol. > o Add support for SCTP to solve the fragmentation problem. > o Merge RFC 7350: > * Split the "Sending over..." sections in 3. > * Add DTLS-over-UDP as transport. > * Update the cipher suites and cipher/compression restrictions. > * A stuns uri with an IP address is rejected. > * Replace most of the RFC 3489 compatibility by a reference to > the section in RFC 5389. > * Update the STUN Usages list with transport applicability. > o Merge RFC 7064: > * DNS discovery is done from the URI. > * Reorganized the text about default ports. > o Add more C snippets. > o Make clear that the cached RTO is discarded only if there is no > new transactions for 10 minutes. >=20 > On 02/17/2015 09:32 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 : Session Traversal Utilities for NAT (STUN) > > Authors : Marc Petit-Huguenin > > Gonzalo Salgueiro > > Jonathan Rosenberg > > Dan Wing > > Rohan Mahy > > Philip Matthews > > Filename : draft-ietf-tram-stunbis-01.txt > > Pages : 57 > > Date : 2015-02-17 > > > > Abstract: > > Session Traversal Utilities for NAT (STUN) is a protocol that serves > > as a tool for other protocols in dealing with Network Address > > Translator (NAT) traversal. It can be used by an endpoint to > > determine the IP address and port allocated to it by a NAT. It can > > also be used to check connectivity between two endpoints, and as a > > keep-alive protocol to maintain NAT bindings. STUN works with many > > existing NATs, and does not require any special behavior from them. > > > > STUN is not a NAT traversal solution by itself. Rather, it is a too= l > > to be used in the context of a NAT traversal solution. > > > > This document obsoletes RFC 5389. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-tram-stunbis-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-stunbis-01 > > > > > > 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/ > > >=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 > iQIcBAEBCAAGBQJU5G2cAAoJECnERZXWan7ED1EP+gPP0+Xn+EcgqtGe/jxzGG > 6F > iLmEt2GSjLMMLfoTZV5UaD4n7jUU0K3kL915PwP8ypoo750H/lh03K5Utsm9Zxe > L > nu7//dNyo1KsEB2cHNCAwLpXeVMnyes7RjiTUOtK8gf2TcvQjlOu9UksUJIy58E7 > dxczH58sujoAjsLqg2ml7JJejKEUsowbGJtj6aaEGt61QYV7ojc1sNoNqF6tuGqY > EhrDbzuu/SfeW0bxC/EOwitbpISBy9m289eMcOz9UdnoVRyOD14+gst/glizRU/ > 2 > X1v+4ABsv0TtEZrq8pf57FhI8ImMkseY/7A7nhft7zObUW2Lk67H9+KitoLtUiPn > cPEolUvmA4RBAOnTpopR//o+4lUMnu4RbwZhlUdfBGxQsZ1iOWGmt7GYD6j+ > q5ow > 9KxALPyuFUcm4Os3klGaCdZS2THEc6T4VIROMMifs3i1kCvCKnqPOPVF3GKeS4 > bw > lLNwf+YuhS5m9WPylx1OMTsbfSVqzh+Bh9qekar57yUuNoAgnqqYMxAiWH7M > lveS > O3OiXI10papVe1UNfStmQX8SuYSb7DlsadQzldgOlMRveImKa3tRtzS7AXQ02Exj > apv7o/j0uuEVr9NJE1CCKonfZqCzPnaU7LrTAHZZnQrz/lmN97spwCCyfbQcqOa > k > 5RfMzQZxVJo6YFkWpseE > =3DCmHq > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Feb 24 21:04:15 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F871A9090 for ; Tue, 24 Feb 2015 21:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjCGjojfqmAj for ; Tue, 24 Feb 2015 21:04:13 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D81BD1A908F for ; Tue, 24 Feb 2015 21:04:12 -0800 (PST) Received: by pabkq14 with SMTP id kq14so2367603pab.3 for ; Tue, 24 Feb 2015 21:04:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bayxOcdmIiNGkrmgW9DEOuI3JBObMUNYppZPIaBkv50=; b=wX3W9xUF7LKcVdzZgrtZDm+Yw6E/6tOPJJO+bUxhsAfDV021KIXV2J+8sPVdkF2nFC wDmQlyQtjm2ObOrrmXxbs7Y0hQ/muNHOsYykhYX1QbI27bx6B1lGeVki7IE5PcixFbxy 0lT1ZoKf4md3uVAWBMMDFCkBSe3RFtKEVc72no1RGTR2yG6THpH5ddS8PNCT5IKk8VpN 0EMoYFFMAMJzMr56lQyZHGoW3wA/vqXxZQeR1sqILhXDWVAOzd8VSn1c77tkAae8Skkr q5GKqN5LevANXwF73Gcz4FVsGcetcNwwLRyxuHCXBu4eOnxpJrxoZ+LqVZUPEKFqtnpq JD0A== X-Received: by 10.66.119.193 with SMTP id kw1mr2460173pab.64.1424840652042; Tue, 24 Feb 2015 21:04:12 -0800 (PST) Received: from [22.3.89.193] (mab0436d0.tmodns.net. [208.54.4.171]) by mx.google.com with ESMTPSA id fi5sm889029pdb.44.2015.02.24.21.04.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 21:04:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Oleg Moskalenko X-Mailer: iPhone Mail (12F39) In-Reply-To: <913383AAA69FF945B8F946018B75898A366A7389@xmb-rcd-x10.cisco.com> Date: Tue, 24 Feb 2015 21:04:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <08621C7F-AA09-4A4F-BBDB-C0460BEFC3B8@gmail.com> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A366A7389@xmb-rcd-x10.cisco.com> To: "Tirumaleswar Reddy (tireddy)" Archived-At: Cc: Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 25 Feb 2015 05:04:14 -0000 Tiru, that is exactly what I am trying to understand - why ? I have a feelin= g that we are trying to stretch the RFC to cover a proprietary library or el= se. I d like to hear more arguments from the authors. Thanks Oleg > On Feb 24, 2015, at 8:45 PM, Tirumaleswar Reddy (tireddy) wrote: >=20 > Even in WebRTC why should STUN messages be sent over SCTP over DTLS over U= DP ? >=20 > -Tiru >=20 >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko >> Sent: Wednesday, February 25, 2015 12:38 AM >> To: Benjamin Schwartz >> Cc: tram@ietf.org >> Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >>=20 >> I do not see word "webrtc" anywhere in the text. We are discussing STUN >> protocol here, right ? =46rom the networking point of view, DTLS/SCTP/UDP= >> makes much more sense. >>=20 >> Thanks >> Oleg >>=20 >>=20 >> On Tue, Feb 24, 2015 at 11:01 AM, Benjamin Schwartz >> wrote: >>> WebRTC uses UDP/DTLS/SCTP, not the other way. >>>=20 >>> On Tue, Feb 24, 2015 at 1:47 PM, Oleg Moskalenko >> >>> wrote: >>>>=20 >>>> I checked the text and I am not sure that SCTP - over DTLS - over UDP >>>> is the right tunneling sequence. This is a typo or a mistake, I >>>> believe. >>>>=20 >>>> I suppose that the right sequence is DTLS - over SCTP - over UDP. >>>> That would be easier to implement, it is closer to the "true" SCTP, >>>> and I see no security benefits in hiding SCTP inside DTLS. >>>>=20 >>>> Thanks >>>> Oleg >>>>=20 >>>>=20 >>>>> On Tue, Feb 17, 2015 at 8:32 AM, wrote: >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Title : Session Traversal Utilities for NAT (STUN) >>>>> Authors : Marc Petit-Huguenin >>>>> Gonzalo Salgueiro >>>>> Jonathan Rosenberg >>>>> Dan Wing >>>>> Rohan Mahy >>>>> Philip Matthews >>>>> Filename : draft-ietf-tram-stunbis-01.txt >>>>> Pages : 57 >>>>> Date : 2015-02-17 >>>>>=20 >>>>> Abstract: >>>>> Session Traversal Utilities for NAT (STUN) is a protocol that serves= >>>>> as a tool for other protocols in dealing with Network Address >>>>> Translator (NAT) traversal. It can be used by an endpoint to >>>>> determine the IP address and port allocated to it by a NAT. It can >>>>> also be used to check connectivity between two endpoints, and as a >>>>> keep-alive protocol to maintain NAT bindings. STUN works with many >>>>> existing NATs, and does not require any special behavior from them. >>>>>=20 >>>>> STUN is not a NAT traversal solution by itself. Rather, it is a too= l >>>>> to be used in the context of a NAT traversal solution. >>>>>=20 >>>>> This document obsoletes RFC 5389. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-tram-stunbis-01 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-stunbis-01 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at >>>>> tools.ietf.org. >>>>>=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 >>>>=20 >>>> _______________________________________________ >>>> tram mailing list >>>> tram@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tram >>=20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram From nobody Wed Feb 25 01:45:23 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC87B1A6EF1 for ; Wed, 25 Feb 2015 01:45:21 -0800 (PST) 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 mN8_22FMmZDb for ; Wed, 25 Feb 2015 01:45:20 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 144581A0318 for ; Wed, 25 Feb 2015 01:45:20 -0800 (PST) Received: from [IPv6:2602:43:2a2:c600:d042:c91f:1d4e:8558] (unknown [IPv6:2602:43:2a2:c600:d042:c91f:1d4e:8558]) (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 664272013A; Wed, 25 Feb 2015 10:45:18 +0100 (CET) Message-ID: <54ED99AC.9050809@acm.org> Date: Wed, 25 Feb 2015 02:45:16 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Oleg Moskalenko , Benjamin Schwartz References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A366A7389@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366A7389@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 25 Feb 2015 09:45:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/24/2015 09:45 PM, Tirumaleswar Reddy (tireddy) wrote: > Even in WebRTC why should STUN messages be sent over SCTP over DTLS over UDP ? Nobody said anything like this. > > -Tiru > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko >> Sent: Wednesday, February 25, 2015 12:38 AM >> To: Benjamin Schwartz >> Cc: tram@ietf.org >> Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >> >> I do not see word "webrtc" anywhere in the text. We are discussing STUN >> protocol here, right ? From the networking point of view, DTLS/SCTP/UDP >> makes much more sense. >> >> Thanks >> Oleg >> >> >> On Tue, Feb 24, 2015 at 11:01 AM, Benjamin Schwartz >> wrote: >>> WebRTC uses UDP/DTLS/SCTP, not the other way. >>> >>> On Tue, Feb 24, 2015 at 1:47 PM, Oleg Moskalenko >> >>> wrote: >>>> >>>> I checked the text and I am not sure that SCTP - over DTLS - over UDP >>>> is the right tunneling sequence. This is a typo or a mistake, I >>>> believe. >>>> >>>> I suppose that the right sequence is DTLS - over SCTP - over UDP. >>>> That would be easier to implement, it is closer to the "true" SCTP, >>>> and I see no security benefits in hiding SCTP inside DTLS. >>>> >>>> Thanks >>>> Oleg >>>> >>>> >>>> On Tue, Feb 17, 2015 at 8:32 AM, 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 : Session Traversal Utilities for NAT (STUN) >>>>> Authors : Marc Petit-Huguenin >>>>> Gonzalo Salgueiro >>>>> Jonathan Rosenberg >>>>> Dan Wing >>>>> Rohan Mahy >>>>> Philip Matthews >>>>> Filename : draft-ietf-tram-stunbis-01.txt >>>>> Pages : 57 >>>>> Date : 2015-02-17 >>>>> >>>>> Abstract: >>>>> Session Traversal Utilities for NAT (STUN) is a protocol that serves >>>>> as a tool for other protocols in dealing with Network Address >>>>> Translator (NAT) traversal. It can be used by an endpoint to >>>>> determine the IP address and port allocated to it by a NAT. It can >>>>> also be used to check connectivity between two endpoints, and as a >>>>> keep-alive protocol to maintain NAT bindings. STUN works with many >>>>> existing NATs, and does not require any special behavior from them. >>>>> >>>>> STUN is not a NAT traversal solution by itself. Rather, it is a tool >>>>> to be used in the context of a NAT traversal solution. >>>>> >>>>> This document obsoletes RFC 5389. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-tram-stunbis-01 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-01 >>>>> >>>>> >>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJU7ZmsAAoJECnERZXWan7Ewa4QAK2B74KwKoTNH+7ScIFzFKwC k99A2Ip3DN8avwpYcSOau8WP/7MGInzfIRfpLlemNPi368TJiUXIADQ2CMRndCZu 0ewuzn9OH4x3zzsfNSwPq0pMG8GU4nQ5F+0b46lk4fj+9z/LH74EdQhD84wVw+TC +Oc+2VPz3AtfyDztk4AQwHwfVSiAQbWBh0yPCON+q9YNRtiOMRzR2bKTrwX9mEjl VGv7D9n/+96YrriIEG+jfM5AO1418yI/OTmyGLlKkhA3KDe729INSHi3NQzKXNUw AAaCLf1PYXePngA0abMj0us3O9AGCiR35IHacG0K9mZ+6HPLFPGbLiMZxwMUz3TN 9Ee8n6gbs5FFwXHGEdzqkrYZ0LkRS6HaZ6RY8kaKgWGXJKvuGVEr8j2sIxajcUH1 u/ZQpjhPaBZL0dyfSNHXWRKwkPgm5f9/Tw+LzP217FGpPYoCFmgp1X0/yLwtdZ/N nO7UgP9Ue80qPh3TSa24RPvGTCwGUk314vl4g+wfYZfUu9q7bVtQoaUN70nmcKph XfbZRGoe5iepVYEDzk2ulpmFFAIcDOeXG4XqZ/YvFxAl5HvlgLK70ubp+1ly4fp5 qICj/fecTi1sGCtrj1HMghSWPM/xxDr2msP0BZ04jC2A50i5Xx0IldJXPepMIWjQ n6qZPY8xvYbNQFlX5rBh =C/AN -----END PGP SIGNATURE----- From nobody Wed Feb 25 02:01:06 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B4F1A8750 for ; Wed, 25 Feb 2015 02:00:59 -0800 (PST) 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 Lwt8HU8HL3A9 for ; Wed, 25 Feb 2015 02:00:57 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id A60461A86FC for ; Wed, 25 Feb 2015 02:00:33 -0800 (PST) Received: from [IPv6:2602:43:2a2:c600:d042:c91f:1d4e:8558] (unknown [IPv6:2602:43:2a2:c600:d042:c91f:1d4e:8558]) (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 2C1592013A; Wed, 25 Feb 2015 11:00:32 +0100 (CET) Message-ID: <54ED9D3E.4080503@acm.org> Date: Wed, 25 Feb 2015 03:00:30 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Oleg Moskalenko , "Tirumaleswar Reddy (tireddy)" References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A366A7389@xmb-rcd-x10.cisco.com> <08621C7F-AA09-4A4F-BBDB-C0460BEFC3B8@gmail.com> In-Reply-To: <08621C7F-AA09-4A4F-BBDB-C0460BEFC3B8@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 25 Feb 2015 10:00:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/24/2015 10:04 PM, Oleg Moskalenko wrote: > Tiru, that is exactly what I am trying to understand - why ? I have a feeling that we are trying to stretch the RFC to cover a proprietary library or else. I d like to hear more arguments from the authors. I resent this accusation. I am here only to "make the Internet work better". WebRTC is sending *data* over SCTP over DTLS over UDP. > > Thanks > Oleg > >> On Feb 24, 2015, at 8:45 PM, Tirumaleswar Reddy (tireddy) wrote: >> >> Even in WebRTC why should STUN messages be sent over SCTP over DTLS over UDP ? >> >> -Tiru >> >>> -----Original Message----- >>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko >>> Sent: Wednesday, February 25, 2015 12:38 AM >>> To: Benjamin Schwartz >>> Cc: tram@ietf.org >>> Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >>> >>> I do not see word "webrtc" anywhere in the text. We are discussing STUN >>> protocol here, right ? From the networking point of view, DTLS/SCTP/UDP >>> makes much more sense. >>> >>> Thanks >>> Oleg >>> >>> >>> On Tue, Feb 24, 2015 at 11:01 AM, Benjamin Schwartz >>> wrote: >>>> WebRTC uses UDP/DTLS/SCTP, not the other way. >>>> >>>> On Tue, Feb 24, 2015 at 1:47 PM, Oleg Moskalenko >>> >>>> wrote: >>>>> >>>>> I checked the text and I am not sure that SCTP - over DTLS - over UDP >>>>> is the right tunneling sequence. This is a typo or a mistake, I >>>>> believe. >>>>> >>>>> I suppose that the right sequence is DTLS - over SCTP - over UDP. >>>>> That would be easier to implement, it is closer to the "true" SCTP, >>>>> and I see no security benefits in hiding SCTP inside DTLS. >>>>> >>>>> Thanks >>>>> Oleg >>>>> >>>>> >>>>>> On Tue, Feb 17, 2015 at 8:32 AM, 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 : Session Traversal Utilities for NAT (STUN) >>>>>> Authors : Marc Petit-Huguenin >>>>>> Gonzalo Salgueiro >>>>>> Jonathan Rosenberg >>>>>> Dan Wing >>>>>> Rohan Mahy >>>>>> Philip Matthews >>>>>> Filename : draft-ietf-tram-stunbis-01.txt >>>>>> Pages : 57 >>>>>> Date : 2015-02-17 >>>>>> >>>>>> Abstract: >>>>>> Session Traversal Utilities for NAT (STUN) is a protocol that serves >>>>>> as a tool for other protocols in dealing with Network Address >>>>>> Translator (NAT) traversal. It can be used by an endpoint to >>>>>> determine the IP address and port allocated to it by a NAT. It can >>>>>> also be used to check connectivity between two endpoints, and as a >>>>>> keep-alive protocol to maintain NAT bindings. STUN works with many >>>>>> existing NATs, and does not require any special behavior from them. >>>>>> >>>>>> STUN is not a NAT traversal solution by itself. Rather, it is a tool >>>>>> to be used in the context of a NAT traversal solution. >>>>>> >>>>>> This document obsoletes RFC 5389. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-tram-stunbis-01 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-01 >>>>>> >>>>>> >>>>>> 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/ >>>>>> - -- 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 iQIcBAEBCAAGBQJU7Z0+AAoJECnERZXWan7EEq0P/RJWEevndW8KFVf9IYOumZEP y3AS8Z7GkIaxf/a8wh2y5MCb/gwslFqlAP9Lv1JGRx8NCQJSdvr/2u1H8tRO5ZRq wSKpcE+9fGCx81SVLE5/5Zt1hq2sTWKFc9l56LKMA1Y1M1enus51SXekb9D+txh9 8XmZnyaIwioB4wHuGn6VEfKl+Gn+lNCj1Azqe93EhZf8C1CKKbHkJezitIBFRvgJ RUjNOhgaZBnFkd9MbhDT89rFQUib3zq8/VOMMM4cyX1app8NA8zYjoDahoUwvw9e 86UEvrxBWPBHzmWr8PVVWfE/HiK9FmRYJuPcRnoyuojLC3eOHkj50flXQByb4Hk6 PBfmTR4EyBsFuJFRyPe9YkaH+36vsY7wFXDCkuXxenOjA1EKUuG/l+FX2bOxwWmL sMZJ9rpm217ne9laeuyzJbF6ufAM6WklRA1TXMsu0dFwvbBEBypzl92um0DvG4UZ iXfKop1i1bWvnPbkiU7EpcRcJq+wofybUdTQLCc3zuqnT/WI3jOyhZ61DrQ1aZlc kuDWq3U4pfFs/EDku24jTPJ7jJ8o94G9fE8jDhujLgP5rPA3YZdrCna1OtHgtIOe ZsQ9e2VNmgnZH4TgzVUzZ/dGnLeMY7FNdHA6yydGVZrO4O9M0eosTXgqQPONxlLD VToqYDwIVbXf0jUyEDW9 =dIVm -----END PGP SIGNATURE----- From nobody Wed Feb 25 03:04:00 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C73B1A03AB for ; Wed, 25 Feb 2015 03:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXfefXls4pfJ for ; Wed, 25 Feb 2015 03:03:56 -0800 (PST) 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 B71681A7025 for ; Wed, 25 Feb 2015 03:03:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8520; q=dns/txt; s=iport; t=1424862236; x=1426071836; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+tOOV3HKLL0Ze5ZsNPAwbKeFQ7hi0nswLTvP7gICilQ=; b=ZpZEw8j5WRbdEpQmSsVUT3FhLD0FvRggGFDuzAqMvw7Y4Eh+o7oaR6uv zUBvuCum14ID6VXIWIWfAN4yfWMzLPqgUHqaGKBS2enwyLhNtArC62gKv nhQosz2IqWY3tLtVKS56uVOhShYVqQxvUlUro3aWiWmcLH2jc7T0BR+vB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BtBQA8q+1U/4sNJK1bgwRSVQUEgwS9bYIgCoVwAhyBBUMBAQEBAQF8hA8BAQEEAQEBIBE6CwwEAgEIEQQBAQECAgYdAwICAh8GCxQBCAgCBAENBQgBEogAAxEIBbspk20NhTEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJcoI1D4FIEQEfFhsHBoJiL4EUBY9bg2CEH4JhOYJgiQCGByKCAQEcgVBvAYEKOX8BAQE X-IronPort-AV: E=Sophos;i="5.09,644,1418083200"; d="scan'208";a="126760090" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP; 25 Feb 2015 11:03:55 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t1PB3sQu016108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Feb 2015 11:03:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 05:03:54 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Marc Petit-Huguenin , Oleg Moskalenko , Benjamin Schwartz Thread-Topic: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt Thread-Index: AQHQSs9eowAbQmERAkOzA1uv2nxY/J0Ak8OAgAADrwCAAAH/gIAAPEbggAC4wwD//66ioA== Date: Wed, 25 Feb 2015 11:03:53 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366A7836@xmb-rcd-x10.cisco.com> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A366A7389@xmb-rcd-x10.cisco.com> <54ED99AC.9050809@acm.org> In-Reply-To: <54ED99AC.9050809@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.18.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 25 Feb 2015 11:03:58 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJjIFBldGl0LUh1Z3Vlbmlu IFttYWlsdG86cGV0aXRodWdAYWNtLm9yZ10NCj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAy NSwgMjAxNSAzOjE1IFBNDQo+IFRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBPbGVn IE1vc2thbGVua287IEJlbmphbWluIFNjaHdhcnR6DQo+IENjOiB0cmFtQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXMtMDEu dHh0DQo+IA0KPiAtLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQo+IEhhc2g6IFNI QTI1Ng0KPiANCj4gT24gMDIvMjQvMjAxNSAwOTo0NSBQTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0 aXJlZGR5KSB3cm90ZToNCj4gPiBFdmVuIGluIFdlYlJUQyB3aHkgc2hvdWxkIFNUVU4gbWVzc2Fn ZXMgYmUgc2VudCBvdmVyIFNDVFAgb3ZlciBEVExTDQo+IG92ZXIgVURQID8NCj4gDQo+IE5vYm9k eSBzYWlkIGFueXRoaW5nIGxpa2UgdGhpcy4NCg0KRGF0YSBjaGFubmVsIHRyYWZmaWMgaXMgc2Vu dCBvdmVyIFNDVFAgb3ZlciBEVExTIG92ZXIgVURQIGFmdGVyIElDRSBjaGVja3MgYW5kIGNhbmRp ZGF0ZSBzZWxlY3Rpb24gd2hpY2ggaGFwcGVucyBlaXRoZXIgb3ZlciBUQ1Agb3IgVURQLiBJQ0Ug a2VlcGFsaXZlcyBhbmQgY29uc2VudCBjaGVja3MgYWZ0ZXIgbWVkaWEgc2Vzc2lvbiBpcyBlc3Rh Ymxpc2hlZCBhcmUgc2VudCBvdmVyIFVEUC9UQ1AgYnV0IG5vdCBvdmVyIFNDVFAuIFlvdSBtYXkg d2FudCB0byByZWZlciB0byB0aGUgZmlndXJlIDUgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtcnRjd2ViLWRhdGEtY2hhbm5lbC0xMyNzZWN0aW9uLTUgDQoNCi1UaXJ1 DQoNCj4gDQo+ID4NCj4gPiAtVGlydQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4+IEZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBPbGVnDQo+IE1vc2thbGVua28NCj4gPj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFy eSAyNSwgMjAxNSAxMjozOCBBTQ0KPiA+PiBUbzogQmVuamFtaW4gU2Nod2FydHoNCj4gPj4gQ2M6 IHRyYW1AaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFt0cmFtXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLXRyYW0tc3R1bmJpcy0wMS50eHQNCj4gPj4NCj4gPj4gSSBkbyBub3Qgc2VlIHdvcmQg IndlYnJ0YyIgYW55d2hlcmUgaW4gdGhlIHRleHQuIFdlIGFyZSBkaXNjdXNzaW5nIFNUVU4NCj4g Pj4gcHJvdG9jb2wgaGVyZSwgcmlnaHQgPyBGcm9tIHRoZSBuZXR3b3JraW5nIHBvaW50IG9mIHZp ZXcsIERUTFMvU0NUUC9VRFANCj4gPj4gbWFrZXMgbXVjaCBtb3JlIHNlbnNlLg0KPiA+Pg0KPiA+ PiBUaGFua3MNCj4gPj4gT2xlZw0KPiA+Pg0KPiA+Pg0KPiA+PiBPbiBUdWUsIEZlYiAyNCwgMjAx NSBhdCAxMTowMSBBTSwgQmVuamFtaW4gU2Nod2FydHoNCj4gPGJlbWFzY0B3ZWJydGMub3JnPg0K PiA+PiB3cm90ZToNCj4gPj4+IFdlYlJUQyB1c2VzIFVEUC9EVExTL1NDVFAsIG5vdCB0aGUgb3Ro ZXIgd2F5Lg0KPiA+Pj4NCj4gPj4+IE9uIFR1ZSwgRmViIDI0LCAyMDE1IGF0IDE6NDcgUE0sIE9s ZWcgTW9za2FsZW5rbw0KPiA+PiA8bW9tMDQwMjY3QGdtYWlsLmNvbT4NCj4gPj4+IHdyb3RlOg0K PiA+Pj4+DQo+ID4+Pj4gSSBjaGVja2VkIHRoZSB0ZXh0IGFuZCBJIGFtIG5vdCBzdXJlIHRoYXQg U0NUUCAtIG92ZXIgRFRMUyAtIG92ZXIgVURQDQo+ID4+Pj4gaXMgdGhlIHJpZ2h0IHR1bm5lbGlu ZyBzZXF1ZW5jZS4gVGhpcyBpcyBhIHR5cG8gb3IgYSBtaXN0YWtlLCBJDQo+ID4+Pj4gYmVsaWV2 ZS4NCj4gPj4+Pg0KPiA+Pj4+IEkgc3VwcG9zZSB0aGF0IHRoZSByaWdodCBzZXF1ZW5jZSBpcyBE VExTIC0gb3ZlciBTQ1RQIC0gb3ZlciBVRFAuDQo+ID4+Pj4gVGhhdCB3b3VsZCBiZSBlYXNpZXIg dG8gaW1wbGVtZW50LCBpdCBpcyBjbG9zZXIgdG8gdGhlICJ0cnVlIiBTQ1RQLA0KPiA+Pj4+IGFu ZCBJIHNlZSBubyBzZWN1cml0eSBiZW5lZml0cyBpbiBoaWRpbmcgU0NUUCBpbnNpZGUgRFRMUy4N Cj4gPj4+Pg0KPiA+Pj4+IFRoYW5rcw0KPiA+Pj4+IE9sZWcNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+ Pj4gT24gVHVlLCBGZWIgMTcsIDIwMTUgYXQgODozMiBBTSwgIDxpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+IHdyb3RlOg0KPiA+Pj4+Pg0KPiA+Pj4+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gPj4+Pj4gZGlyZWN0 b3JpZXMuDQo+ID4+Pj4+ICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUVVJOIFJl dmlzZWQgYW5kIE1vZGVybml6ZWQNCj4gPj4+Pj4gV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4N Cj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBTZXNzaW9uIFRyYXZl cnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikNCj4gPj4+Pj4gICAgICAgICBBdXRob3JzICAg ICAgICAgOiBNYXJjIFBldGl0LUh1Z3VlbmluDQo+ID4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgR29uemFsbyBTYWxndWVpcm8NCj4gPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICBKb25hdGhhbiBSb3NlbmJlcmcNCj4gPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICBE YW4gV2luZw0KPiA+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvaGFuIE1haHkNCj4g Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICBQaGlsaXAgTWF0dGhld3MNCj4gPj4+Pj4g ICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXRyYW0tc3R1bmJpcy0wMS50eHQN Cj4gPj4+Pj4gICAgICAgICBQYWdlcyAgICAgICAgICAgOiA1Nw0KPiA+Pj4+PiAgICAgICAgIERh dGUgICAgICAgICAgICA6IDIwMTUtMDItMTcNCj4gPj4+Pj4NCj4gPj4+Pj4gQWJzdHJhY3Q6DQo+ ID4+Pj4+ICAgIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChTVFVOKSBpcyBh IHByb3RvY29sIHRoYXQgc2VydmVzDQo+ID4+Pj4+ICAgIGFzIGEgdG9vbCBmb3Igb3RoZXIgcHJv dG9jb2xzIGluIGRlYWxpbmcgd2l0aCBOZXR3b3JrIEFkZHJlc3MNCj4gPj4+Pj4gICAgVHJhbnNs YXRvciAoTkFUKSB0cmF2ZXJzYWwuICBJdCBjYW4gYmUgdXNlZCBieSBhbiBlbmRwb2ludCB0bw0K PiA+Pj4+PiAgICBkZXRlcm1pbmUgdGhlIElQIGFkZHJlc3MgYW5kIHBvcnQgYWxsb2NhdGVkIHRv IGl0IGJ5IGEgTkFULiAgSXQgY2FuDQo+ID4+Pj4+ICAgIGFsc28gYmUgdXNlZCB0byBjaGVjayBj b25uZWN0aXZpdHkgYmV0d2VlbiB0d28gZW5kcG9pbnRzLCBhbmQgYXMgYQ0KPiA+Pj4+PiAgICBr ZWVwLWFsaXZlIHByb3RvY29sIHRvIG1haW50YWluIE5BVCBiaW5kaW5ncy4gIFNUVU4gd29ya3Mg d2l0aA0KPiBtYW55DQo+ID4+Pj4+ICAgIGV4aXN0aW5nIE5BVHMsIGFuZCBkb2VzIG5vdCByZXF1 aXJlIGFueSBzcGVjaWFsIGJlaGF2aW9yIGZyb20gdGhlbS4NCj4gPj4+Pj4NCj4gPj4+Pj4gICAg U1RVTiBpcyBub3QgYSBOQVQgdHJhdmVyc2FsIHNvbHV0aW9uIGJ5IGl0c2VsZi4gIFJhdGhlciwg aXQgaXMgYSB0b29sDQo+ID4+Pj4+ICAgIHRvIGJlIHVzZWQgaW4gdGhlIGNvbnRleHQgb2YgYSBO QVQgdHJhdmVyc2FsIHNvbHV0aW9uLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICBUaGlzIGRvY3VtZW50 IG9ic29sZXRlcyBSRkMgNTM4OS4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4+Pj4+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS1zdHVuYmlzLw0KPiA+ Pj4+Pg0KPiA+Pj4+PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBh dDoNCj4gPj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXN0 dW5iaXMtMDENCj4gPj4+Pj4NCj4gPj4+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNp b24gaXMgYXZhaWxhYmxlIGF0Og0KPiA+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLXRyYW0tc3R1bmJpcy0wMQ0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+ PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZg0KPiA+Pj4+PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gPj4+Pj4gdG9vbHMuaWV0Zi5vcmcuDQo+ID4+ Pj4+DQo+ID4+Pj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnlt b3VzIEZUUCBhdDoNCj4gPj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N Cj4gPj4+Pj4NCj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPj4+Pj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4gdHJhbUBpZXRmLm9y Zw0KPiA+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCj4g Pj4+Pg0KPiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+Pj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gPj4+PiB0cmFtQGlldGYub3JnDQo+ID4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQo+ID4+Pg0KPiA+ Pj4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gPj4gdHJhbUBpZXRmLm9yZw0KPiA+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCj4gPg0KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gdHJhbSBtYWls aW5nIGxpc3QNCj4gPiB0cmFtQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90cmFtDQo+ID4NCj4gDQo+IA0KPiAtIC0tDQo+IE1hcmMgUGV0aXQtSHVn dWVuaW4NCj4gRW1haWw6IG1hcmNAcGV0aXQtaHVndWVuaW4ub3JnDQo+IEJsb2c6IGh0dHA6Ly9i bG9nLm1hcmMucGV0aXQtaHVndWVuaW4ub3JnDQo+IFByb2ZpbGU6IGh0dHA6Ly93d3cubGlua2Vk aW4uY29tL2luL3BldGl0aHVnDQo+IC0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQo+IFZl cnNpb246IEdudVBHIHYxDQo+IA0KPiBpUUljQkFFQkNBQUdCUUpVN1ptc0FBb0pFQ25FUlpYV2Fu N0V3YTRRQUsyQjc0S3dLb1ROSCs3U2NJRnoNCj4gRkt3Qw0KPiBrOTlBMklwM0ROOGF2d3BZY1NP YXU4V1AvN01HSW56ZklSZnBMbGVtTlBpMzY4VEppVVhJQURRMkNNUm5kQw0KPiBadQ0KPiAwZXd1 em45T0g0eDN6enNmTlN3UHEwcE1HOEdVNG5RNUYrMGI0NmxrNGZqKzl6L0xINzRFZFFoRDg0d1Z3 DQo+ICtUQw0KPiArT2MrMlZQejNBdGZ5RHp0azRBUXdId2ZWU2lBUWJXQmgweVBDT04rcTlZTlJ0 aU9NUnpSMmJLVHJ3WDkNCj4gbUVqbA0KPiBWR3Y3RDluLys5NllycmlJRUcramZNNUFPMTQxOHlJ L09UbXlHTGxLa2hBM0tEZTcyOUlOU0hpM05RektYTlUNCj4gdw0KPiBBQWFDTGYxUFlYZVBuZ0Ew YWJNajB1czNPOUFHQ2lSMzVJSGFjRzBLOW1aKzZIUExGUEdiTGlNWnh3TVV6DQo+IDNUTg0KPiA5 RWU4bjZnYnM1RkZ3WEhHRWR6cWtyWVowTGtSUzZIYVo2Ulk4a2FLZ1dHWEpLdnVHVkVyOGoyc0l4 YWpjVUgxDQo+IHUvWlFwamhQYUJaTDBkeWZTTkhYV1JLd2tQZ201ZjkvVHcrTHpQMjE3RkdwUFlv Q0ZtZ3AxWDAveUx3dGRaDQo+IC9ODQo+IG5PN1VnUDlVZTgwcVBoM1RTYTI0UlB2R1RDd0dVazMx NHZsNGcrd2ZZWmZVdTlxN2JWdFFvYVVONzBubWMNCj4gS3BoDQo+IFhmYlpSR29lNWllcFZZRUR6 azJ1bHBtRkZBSWNET2VYRzRYcVovWXZGeEFsNUh2bGdMSzcwdWJwKzFseTRmcDUNCj4gcUlDai9m ZWNUaTFzR0N0cmoxSE1naFNXUE0veHhEcjJtc1AwQlowNGpDMkE1MGk1WHgwSWxkSlhQZXBNSVdq UQ0KPiBuNnFaUFk4eHZZYk5RRmxYNXJCaA0KPiA9Qy9BTg0KPiAtLS0tLUVORCBQR1AgU0lHTkFU VVJFLS0tLS0NCg== From nobody Wed Feb 25 03:45:44 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20551A0010 for ; Wed, 25 Feb 2015 03:45:42 -0800 (PST) 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 VxAETZJ7r3CY for ; Wed, 25 Feb 2015 03:45:37 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5F81A000D for ; Wed, 25 Feb 2015 03:45:37 -0800 (PST) Received: from [IPv6:2602:43:2a2:c600:d855:6329:bfc1:723a] (unknown [IPv6:2602:43:2a2:c600:d855:6329:bfc1:723a]) (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 4397D2013A; Wed, 25 Feb 2015 12:45:36 +0100 (CET) Message-ID: <54EDB5DE.4090608@acm.org> Date: Wed, 25 Feb 2015 04:45:34 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Oleg Moskalenko , Benjamin Schwartz References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A366A7389@xmb-rcd-x10.cisco.com> <54ED99AC.9050809@acm.org> <913383AAA69FF945B8F946018B75898A366A7836@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366A7836@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 25 Feb 2015 11:45:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The choice of SCTP [over DTLS] over UDP to solve the STUN fragmentation problem has nothing to do with WebRTC. The stack order is aligned with WebRTC's because of the probability that the two stacks will be collocated, and so can share code. There is no other reason than this one. On 02/25/2015 04:03 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Marc Petit-Huguenin [mailto:petithug@acm.org] >> Sent: Wednesday, February 25, 2015 3:15 PM >> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko; Benjamin Schwartz >> Cc: tram@ietf.org >> Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >> > On 02/24/2015 09:45 PM, Tirumaleswar Reddy (tireddy) wrote: >>>> Even in WebRTC why should STUN messages be sent over SCTP over DTLS > over UDP ? > > Nobody said anything like this. > >> Data channel traffic is sent over SCTP over DTLS over UDP after ICE checks and candidate selection which happens either over TCP or UDP. ICE keepalives and consent checks after media session is established are sent over UDP/TCP but not over SCTP. You may want to refer to the figure 5 in https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 > >> -Tiru > > >>>> >>>> -Tiru >>>> >>>>> -----Original Message----- >>>>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg > Moskalenko >>>>> Sent: Wednesday, February 25, 2015 12:38 AM >>>>> To: Benjamin Schwartz >>>>> Cc: tram@ietf.org >>>>> Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >>>>> >>>>> I do not see word "webrtc" anywhere in the text. We are discussing STUN >>>>> protocol here, right ? From the networking point of view, DTLS/SCTP/UDP >>>>> makes much more sense. >>>>> >>>>> Thanks >>>>> Oleg >>>>> >>>>> >>>>> On Tue, Feb 24, 2015 at 11:01 AM, Benjamin Schwartz > >>>>> wrote: >>>>>> WebRTC uses UDP/DTLS/SCTP, not the other way. >>>>>> >>>>>> On Tue, Feb 24, 2015 at 1:47 PM, Oleg Moskalenko >>>>> >>>>>> wrote: >>>>>>> >>>>>>> I checked the text and I am not sure that SCTP - over DTLS - over UDP >>>>>>> is the right tunneling sequence. This is a typo or a mistake, I >>>>>>> believe. >>>>>>> >>>>>>> I suppose that the right sequence is DTLS - over SCTP - over UDP. >>>>>>> That would be easier to implement, it is closer to the "true" SCTP, >>>>>>> and I see no security benefits in hiding SCTP inside DTLS. >>>>>>> >>>>>>> Thanks >>>>>>> Oleg >>>>>>> >>>>>>> >>>>>>> On Tue, Feb 17, 2015 at 8:32 AM, 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 : Session Traversal Utilities for NAT (STUN) >>>>>>>> Authors : Marc Petit-Huguenin >>>>>>>> Gonzalo Salgueiro >>>>>>>> Jonathan Rosenberg >>>>>>>> Dan Wing >>>>>>>> Rohan Mahy >>>>>>>> Philip Matthews >>>>>>>> Filename : draft-ietf-tram-stunbis-01.txt >>>>>>>> Pages : 57 >>>>>>>> Date : 2015-02-17 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> Session Traversal Utilities for NAT (STUN) is a protocol that serves >>>>>>>> as a tool for other protocols in dealing with Network Address >>>>>>>> Translator (NAT) traversal. It can be used by an endpoint to >>>>>>>> determine the IP address and port allocated to it by a NAT. It can >>>>>>>> also be used to check connectivity between two endpoints, and as a >>>>>>>> keep-alive protocol to maintain NAT bindings. STUN works with > many >>>>>>>> existing NATs, and does not require any special behavior from them. >>>>>>>> >>>>>>>> STUN is not a NAT traversal solution by itself. Rather, it is a tool >>>>>>>> to be used in the context of a NAT traversal solution. >>>>>>>> >>>>>>>> This document obsoletes RFC 5389. >>>>>>>> >>>>>>>> >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ >>>>>>>> >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-ietf-tram-stunbis-01 >>>>>>>> >>>>>>>> A diff from the previous version is available at: >>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-01 >>>>>>>> >>>>>>>> >>>>>>>> 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/ >>>>>>>> - -- 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 iQIcBAEBCAAGBQJU7bXeAAoJECnERZXWan7Ev4gP/33DmMToWknKxh9TuP3MTVRd 257/ScCHjQ6aQwKZWnCJFZj8uEmwqhXxEazH3ue9iwxxCqy1tM95divok+uezB6N eGuBTVUqKPjze5LgvGlOMQoXiSnmbh+w1Aa/gA+V41f3dEL7y65S1WSIpIl5bD4H HXF7sVP/R35nL3oqWbuz+PutgB+nDoNygdBJR5ta5C1uyx+bn7pJo924sq+8lU9w D77GlP7ToDO2zK6M69cWuXBq2/7Hf9l4yOveKnYoNyb1sDCuEFkdUn8xCqyl3Kz3 f7AB/zpBjWYBjvSur9c/PkiT90B43xti9gZlv/lJYWT+gEdarNqOgGPouZ1iyRbz PJCuAVN+xkJ0vzyIC8t5wD4ZSgLfoLcQJYURTRFZHash079hgfYZ24P1HOHybDgG LQL7vbBYO+ET4EwWrM6ehrrZt9SqQJiTiwq0YUdOcICO4fT/UUrAgh9vJX0nYb+k z+ContphnZKSSyXjtk6wFpaCh/qIszYr2L1OFmpKxkRgcIVwfefOogs309YfrqlW SWVw51EX11bkkt8OVaJUB4mATaiB2YwMAE1t4wFC1Xr2F+k7BSNM9cFOpezToY9u zYkgtgWQ+2ztCPtd/RQhuSsT2NmcdE+xyFyD0FaPhKijlpnTM05Pz6sHZjScPWSc wKIiw6L2spNkTaZcFmA3 =Kfam -----END PGP SIGNATURE----- From nobody Wed Feb 25 06:14:37 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB391A0406 for ; Wed, 25 Feb 2015 06:14:36 -0800 (PST) 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 Uw8irf3iBKMy for ; Wed, 25 Feb 2015 06:14:35 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FCF21A0052 for ; Wed, 25 Feb 2015 06:14:34 -0800 (PST) Received: by lbiz11 with SMTP id z11so4074346lbi.8 for ; Wed, 25 Feb 2015 06:14:32 -0800 (PST) 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=9eFrZqwsr7VyJ/g0s9k0avqHmKmWXh/UeaKKWFLIubk=; b=BLSORXz7RrHqhnE824tC+92dg1oyJXi40DtYLP6pHKmrWIVapY4UNMHvMWVpyXqs6R MAkzSxPwC8J8JsKIp5Eo91irLoyQFu8VKBDJ/tnpqQydxpK/pWG9YdGpmnIKUFNfVazI FfRRfd9jxwjAlJPFRsgDEnPEopRsNxFGZjlneYOzj1s4K1X5cPMYNLXVDOkDYzCKrqaL qHxm2XjXvWWuYUaBuTiJlxcKhoMlrAMgNgpcwHALn8zTntFt1FA2X1pLVCOj8l2pJsxE ghhOpPBdwpiiBn7MEDpgwioAPJqfL/uSU+8bpwhY3kHSqY69Mu+yP5tyH1T9XItKlMoe VDCA== X-Gm-Message-State: ALoCoQnEZc+vNtIGXQdu/bJwJGorLOHFw2nZN069rD+hlszUNp6eIdMEUl0To0oU/+s8q0gn6Yol MIME-Version: 1.0 X-Received: by 10.112.12.134 with SMTP id y6mr3072597lbb.34.1424873672880; Wed, 25 Feb 2015 06:14:32 -0800 (PST) Received: by 10.25.205.144 with HTTP; Wed, 25 Feb 2015 06:14:32 -0800 (PST) In-Reply-To: <54EDB5DE.4090608@acm.org> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A366A7389@xmb-rcd-x10.cisco.com> <54ED99AC.9050809@acm.org> <913383AAA69FF945B8F946018B75898A366A7836@xmb-rcd-x10.cisco.com> <54EDB5DE.4090608@acm.org> Date: Wed, 25 Feb 2015 09:14:32 -0500 Message-ID: From: Simon Perreault To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=001a11c3a0e81f4a5f050fea4184 Archived-At: Cc: Oleg Moskalenko , Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 25 Feb 2015 14:14:36 -0000 --001a11c3a0e81f4a5f050fea4184 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 25, 2015 at 6:45 AM, Marc Petit-Huguenin wrote: > The choice of SCTP [over DTLS] over UDP to solve the STUN fragmentation > problem has nothing to do with WebRTC. The stack order is aligned with > WebRTC's because of the probability that the two stacks will be collocated, > and so can share code. There is no other reason than this one. Right. Technically, both possibilities would work, but the fact is that there is tons of code floating around for SCTP/DTLS/UDP, but not as much for DTLS/SCTP/UDP. So that reason makes sense to me. Another reason that I can think of is that it allows one to reuse the DTLS session in case you're also multiplexing DTLS-SRTP on the socket. That makes session establishment take fewer round-trips. Simon --001a11c3a0e81f4a5f050fea4184 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Feb 25, 2015 at 6:45 AM, Marc Petit-Huguenin <= petithug@acm.org&= gt; wrote:
The choice of SCTP [ove= r DTLS] over UDP to solve the STUN fragmentation problem has nothing to do = with WebRTC.=C2=A0 The stack order is aligned with WebRTC's because of = the probability that the two stacks will be collocated, and so can share co= de.=C2=A0 There is no other reason than this one.

Rig= ht. Technically, both possibilities would work, but the fact is that there = is tons of code floating around for SCTP/DTLS/UDP, but not as much for DTLS= /SCTP/UDP. So that reason makes sense to me.

Another reason that I can think of i= s that it allows one to reuse the DTLS session in case you're also mult= iplexing DTLS-SRTP on the socket. That makes session establishment take few= er round-trips.

Simon
--001a11c3a0e81f4a5f050fea4184-- From nobody Wed Feb 25 08:54:01 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A021A1AA5 for ; Wed, 25 Feb 2015 08:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub8sC0XvVRnd for ; Wed, 25 Feb 2015 08:53:57 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6361A1AAA for ; Wed, 25 Feb 2015 08:53:56 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so6545566wiv.2 for ; Wed, 25 Feb 2015 08:53:55 -0800 (PST) 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=88CP0fP981ByMBJpC9MgCtxruj28BGWJmljm4ZjDgWE=; b=oVfV1H9QkKxa266Cl3bFVsXeo4GTWYDQPyWm18zrVfUlpJILoqHF3h9I/GrvQ2f1IP 3SsUkNy2ykofuD2DS3q0ErTABMPFz+VCrLBIXFbD84xnyXXJkTZQa4K5ydL/drBHLUqL JGmNMYsSwnu6EKFtwqvGy2uqbaMVRhS24E8eVwEcVQiPmg5nrqLBLc+uCJY2miEWhMjW M8zdAAo6jZnUPmfPz6KW0wGjPgI3FmYEXn8RY7GAvkkF07v3LkqtQAAkIfRaWDRpXq0G knMeVa9qFXecyephqYq8n1EqWxac5lxsnvXzxESa8jiizRM2gB25bUmfxkilHsxuDqx/ iVdA== MIME-Version: 1.0 X-Received: by 10.194.6.228 with SMTP id e4mr7793266wja.63.1424883234602; Wed, 25 Feb 2015 08:53:54 -0800 (PST) Received: by 10.194.190.18 with HTTP; Wed, 25 Feb 2015 08:53:54 -0800 (PST) In-Reply-To: <54ED9D3E.4080503@acm.org> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A366A7389@xmb-rcd-x10.cisco.com> <08621C7F-AA09-4A4F-BBDB-C0460BEFC3B8@gmail.com> <54ED9D3E.4080503@acm.org> Date: Wed, 25 Feb 2015 08:53:54 -0800 Message-ID: From: Oleg Moskalenko To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 25 Feb 2015 16:53:58 -0000 On Wed, Feb 25, 2015 at 2:00 AM, Marc Petit-Huguenin wrote: > On 02/24/2015 10:04 PM, Oleg Moskalenko wrote: >> Tiru, that is exactly what I am trying to understand - why ? I have a feeling that we are trying to stretch the RFC to cover a proprietary library or else. I d like to hear more arguments from the authors. > > I resent this accusation. I am here only to "make the Internet work better". Marc, I am sorry if that sounded harsh, as an personal "accusation". I was referring to the impression that the written text makes, I did not mean anything personal. Oleg From nobody Wed Feb 25 09:04:52 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5001A8919 for ; Wed, 25 Feb 2015 09:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJYCwvog-gEL for ; Wed, 25 Feb 2015 09:04:49 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49EBD1A1B48 for ; Wed, 25 Feb 2015 09:04:49 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so6578670wid.5 for ; Wed, 25 Feb 2015 09:04:48 -0800 (PST) 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=GothG4silqNEjxcW9zOndfeiTYYUkt1C99Xm85Glzu4=; b=VQL0wo6v/tkMg+QbnXeK2t/YOwVWdlnEKW4g3HQ2qcFltJkeSUGROltIhPp42n6rCH /Wkrd9/Yji+EDF8oOqqeljxmeyN2/Sf2UrLbcXoJBgAdwswhorBG+2/AowdH5Rskr3rx oaiXbLaBbCBN5iBYJRItSICgNowDHjeb9JtDSa2v9YWymfscYupAMDzaADHHuZUuukiM GQl+NlPcEHECIB6xPnlErx2OHAnnF2iq/E95KSZmLWRaEhy/0f3lyHScDrWHahPFNuGI DLbPTyx3AeZpAo0tLavV68tzmXI1CuY+To6j5IWPB49MIj7XnvoBDNcddXwkJSEf+wP6 SWQQ== MIME-Version: 1.0 X-Received: by 10.180.211.235 with SMTP id nf11mr8538513wic.52.1424883887913; Wed, 25 Feb 2015 09:04:47 -0800 (PST) Received: by 10.194.190.18 with HTTP; Wed, 25 Feb 2015 09:04:47 -0800 (PST) In-Reply-To: <54ED99AC.9050809@acm.org> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A366A7389@xmb-rcd-x10.cisco.com> <54ED99AC.9050809@acm.org> Date: Wed, 25 Feb 2015 09:04:47 -0800 Message-ID: From: Oleg Moskalenko To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 25 Feb 2015 17:04:50 -0000 On Wed, Feb 25, 2015 at 1:45 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 02/24/2015 09:45 PM, Tirumaleswar Reddy (tireddy) wrote: >> Even in WebRTC why should STUN messages be sent over SCTP over DTLS over UDP ? > > Nobody said anything like this. > I am looking at the section 6.2.3 and it is clearly discussing STUN commands being sent over SCTP-over DTLS-over UDP. If that was not the authors intention, then the text has to be changed. We already have DTLS-over UDP. The TURN client is free to encapsulate into that protocol whatever they want, including SCTP, that is about a concrete application and that is totally fine. But putting a somewhat unnatural special case of encapsulation - SCTP-over-DTLS - into the standard text, and mandating the SCTP port choices, sounds like a somewhat un-clean approach. Even if there are tons of code out there. But that pre-existing code - does it require standardization, or everything probably is OK as-is with the current STUN DTLS specs ? Do we really have to add SCTP to the standard ? Thanks Oleg From nobody Wed Feb 25 09:56:03 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046E01A005A for ; Wed, 25 Feb 2015 09:55:55 -0800 (PST) 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 69BoXwpJ4Svz for ; Wed, 25 Feb 2015 09:55:53 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id AB6531A037A for ; Wed, 25 Feb 2015 09:55:52 -0800 (PST) Received: from [IPv6:2602:43:2a2:c600:d855:6329:bfc1:723a] (unknown [IPv6:2602:43:2a2:c600:d855:6329:bfc1:723a]) (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 C8E1F2013A; Wed, 25 Feb 2015 18:55:50 +0100 (CET) Message-ID: <54EE0CA4.5060002@acm.org> Date: Wed, 25 Feb 2015 10:55:48 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A366A7389@xmb-rcd-x10.cisco.com> <54ED99AC.9050809@acm.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 25 Feb 2015 17:55:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/25/2015 10:04 AM, Oleg Moskalenko wrote: > On Wed, Feb 25, 2015 at 1:45 AM, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 02/24/2015 09:45 PM, Tirumaleswar Reddy (tireddy) wrote: >>> Even in WebRTC why should STUN messages be sent over SCTP over DTLS over UDP ? >> >> Nobody said anything like this. >> > > I am looking at the section 6.2.3 and it is clearly discussing STUN > commands being sent over SCTP-over DTLS-over UDP. If that was not the > authors intention, then the text has to be changed. Again, that has nothing to do with WebRTC. Section 6.1: "If a STUN client needs to send requests that are larger than the MTU, or if an application envisions that a response would be larger then the MTU, then it MUST use SCTP-over-UDP or SCTP-over-DTLS-over-UDP as transport, unless the purpose of sending an oversized packet is to probe for MTU characteristics (see [RFC5780])." > > We already have DTLS-over UDP. The TURN client is free to encapsulate > into that protocol whatever they want, including SCTP, that is about a > concrete application and that is totally fine. But putting a somewhat > unnatural special case of encapsulation - SCTP-over-DTLS - into the > standard text, and mandating the SCTP port choices, sounds like a > somewhat un-clean approach. Even if there are tons of code out there. > But that pre-existing code - does it require standardization, or > everything probably is OK as-is with the current STUN DTLS specs ? Do > we really have to add SCTP to the standard ? > > Thanks > Oleg > - -- 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 iQIcBAEBCAAGBQJU7gykAAoJECnERZXWan7E+CkP/3k9HZObBhJdFqzpVpAFO/QQ ZIXBSFLiqfltacvERdGazJwKq5Qjgvpm22IFKw/vzITHUPtqeH7s5EmlT07WRQjJ wYTreJNz0hyDKwdpMPZDdkohz2WIQFj341U39lETyk3fn4uGTEyM7j1Nu6OIQvvy DgWGZb0X/GL8SbCxLWUL4gsmkWRVGU5RqJtQughpkuNuhPBq9YYH+xnmvkdSDYwz yP4Uw70crxEVZgx+QN/d2zw5p4xYNnWP0UUb60hg88DF9AeFgbderBLkD1FqpPCf Eyl3qJzWN/PqSdQDGWt2rt52lBXUoIbIACq2c/zivqmwZH5Uma16wyL9J9Sy5R3l stl4/i2rOLnqb5F1iqyDhfD3xEcyIbCUYcTpGIkJVPKwGJh4ir7pG++WZ3ysWyqS +Pj6DNb7a0Q0qCwxPpAj5YG1bO3fECQFjP+bBlhkk8Y5JI4QYMWywYC7/ffKe2+I hpBz+3+iCThIFcSTKr6AFYWI7Nl+WK0oHPpR05yHBd4iA22ZoxvgoJmwf9ugFvfQ d99XLw5zxlYbrATf++ZE4IeHaJp9cjPC92w0fNOD1SdSZctCyq8twyAl+1iKI6XY 8NXGQC0aCe0qXwMS0XthKV+9/EuOt2lYB95F1VrMYq51YiqnrYG6Kr5bqgLDeQex cn9z5wH5bwZwL08Pej6r =z0R8 -----END PGP SIGNATURE----- From nobody Wed Feb 25 10:57:51 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7D91A1A4B for ; Wed, 25 Feb 2015 10:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zELCT8YxV6B for ; Wed, 25 Feb 2015 10:57:49 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD9D1A00D1 for ; Wed, 25 Feb 2015 10:57:49 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id ex7so15167751wid.4 for ; Wed, 25 Feb 2015 10:57:48 -0800 (PST) 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=VaarmsFcFhoFxtkeUTCEUiJWpSApJJXUmT1c4srEVwc=; b=vvxX5PJbAo0cn717kM+Um4gEP1d1znQT4cJZp67n/8a+OVyKs7Kd6Xo+9lGivpYyi0 LxP0IzmGqxeqf+MG18Ej2uG//NAsbNtCW1DKqUHqQzdlZMs/IWzFUdJeYmutvQKA5LHX oz4hnUfh5Nx5KekmP2tbEGkXTqXQP7VQNySru6qXZHIQ4/se+YUKpRsujPIydh9yCB0w MzPH6k7nHw4YDHsK0rjhzHylLEYFdKSEUGzrMjsCjt+tyS/d02IDzsObYg6T+CFO7Uxo seVNmKlpvzFD5belbGWZHndqq5maOhZ7VYcoq81wssSVBgPpsyKCxrdzGmG+H/1s9xLG 2jRw== MIME-Version: 1.0 X-Received: by 10.194.205.138 with SMTP id lg10mr8791292wjc.130.1424890667881; Wed, 25 Feb 2015 10:57:47 -0800 (PST) Received: by 10.194.190.18 with HTTP; Wed, 25 Feb 2015 10:57:47 -0800 (PST) In-Reply-To: <54EE0CA4.5060002@acm.org> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A366A7389@xmb-rcd-x10.cisco.com> <54ED99AC.9050809@acm.org> <54EE0CA4.5060002@acm.org> Date: Wed, 25 Feb 2015 10:57:47 -0800 Message-ID: From: Oleg Moskalenko To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 25 Feb 2015 18:57:50 -0000 On Wed, Feb 25, 2015 at 9:55 AM, Marc Petit-Huguenin wrote: >>> Hash: SHA256 >>> >>> On 02/24/2015 09:45 PM, Tirumaleswar Reddy (tireddy) wrote: >>>> Even in WebRTC why should STUN messages be sent over SCTP over DTLS over UDP ? >>> >>> Nobody said anything like this. >>> >> >> I am looking at the section 6.2.3 and it is clearly discussing STUN >> commands being sent over SCTP-over DTLS-over UDP. If that was not the >> authors intention, then the text has to be changed. > > Again, that has nothing to do with WebRTC. I did not say that it has. WebRTC point was raised by somebody else. > > Section 6.1: > > "If a STUN client needs to send requests that are larger than the MTU, > or if an application envisions that a response would be larger then > the MTU, then it MUST use SCTP-over-UDP or SCTP-over-DTLS-over-UDP as > transport, unless the purpose of sending an oversized packet is to > probe for MTU characteristics (see [RFC5780])." So, SCTP is used here purely as a tool to solve the fragmentation problem ? Right ? Thanks Oleg From nobody Wed Feb 25 11:23:16 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D164A1A701C for ; Wed, 25 Feb 2015 11:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufd7mwUzay2b for ; Wed, 25 Feb 2015 11:23:09 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8C51A6F3C for ; Wed, 25 Feb 2015 11:23:08 -0800 (PST) Received: by wesx3 with SMTP id x3so5696052wes.6 for ; Wed, 25 Feb 2015 11:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CTEWTzS6/16UjSwuzcsppBDuPId14GseBOw/+6HAnVU=; b=oCb06dsMxl2M0z4ufbiexKrrVW+lyLla0L8NSCBsouR0ixQfq7Iqs/8B4STZId/xM1 nvisToZnmGrjuwkB9rnJ5ZU7zf7A72ktkKYdGgi+H92c5f3jyjvA7u7ZAh9ZlB2aooLD S2fwHTx1DBbZEesrQRbn13Q9VDheFck+ppbirWE7xBBxzi819vgxOlOtrnFY9JAsv8Tm vnbjHJravjfoCvqiztz1xXwy481gwbm1AiUDIef+dta+IXFkehIq/ZoHgpu1T6uxxpZC +1zDNBCRwDwTAavETvLJbSkYpl5j3Ncg4mu8+mo7U9os8DoPbKOVmA2VBBDNPqydwXgt MG7w== MIME-Version: 1.0 X-Received: by 10.194.58.209 with SMTP id t17mr9356306wjq.156.1424892186424; Wed, 25 Feb 2015 11:23:06 -0800 (PST) Received: by 10.194.190.18 with HTTP; Wed, 25 Feb 2015 11:23:06 -0800 (PST) In-Reply-To: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> Date: Wed, 25 Feb 2015 11:23:06 -0800 Message-ID: From: Oleg Moskalenko To: "tram@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 25 Feb 2015 19:23:11 -0000 I'd like to clarify the necessity of the MESSAGE-INTEGRITY2 attribute. My opinion is that we can avoid introducing a new MESSAGE-INTEGRITY[X] attribute for every new used hash algorithm. What if we decide to use SHA-384 ? Introduce MESSAGE-INTEGRITY3, and so on ? I think that this is redundant, messy and unnecessary. There is a well-defined association between the hash length and the algorithm. SHA-1 produce 20 bytes, SHA-256 produce 32 bytes, SHA-384 produce 48 bytes and SHA-512 produce 64 bytes. Why we cannot use the MESSAGE-INTEGRITY length to determine the algorithm that the peer is using ? If we want to support algorithm negotiation (vs the out-of-band negotiation) then we can introduce a new error code "too weak credentials" or something (and possibly another code "too strong credentials") and use that error code in the negotiation stage. That may mean a possible extra round trip on connection establishment. But in most cases the client and the server will have a mutual understanding which algorithm to be used. Or, we may require that all new STUN agents SHOULD support SHA-1 through SHA-512 algorithms. It is not a problem these days, giving current available libraries state. That would actually eliminate the necessity of a new error code, new attribute and extra round-trip. The client can propose an algorithm in the initial authenticated message; if the server is not happy about the algorithm chosen by client, then the server may reply OK but sign the message with a different hash size. Then, the client must use the algorithm chosen by server, or cancel the session. The server can always abort the session if the algorithm strength does not match the server policy and if the client is not cooperating. Thanks Oleg On Tue, Feb 17, 2015 at 8:32 AM, 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 : Session Traversal Utilities for NAT (STUN) > Authors : Marc Petit-Huguenin > Gonzalo Salgueiro > Jonathan Rosenberg > Dan Wing > Rohan Mahy > Philip Matthews > Filename : draft-ietf-tram-stunbis-01.txt > Pages : 57 > Date : 2015-02-17 > > Abstract: > Session Traversal Utilities for NAT (STUN) is a protocol that serves > as a tool for other protocols in dealing with Network Address > Translator (NAT) traversal. It can be used by an endpoint to > determine the IP address and port allocated to it by a NAT. It can > also be used to check connectivity between two endpoints, and as a > keep-alive protocol to maintain NAT bindings. STUN works with many > existing NATs, and does not require any special behavior from them. > > STUN is not a NAT traversal solution by itself. Rather, it is a tool > to be used in the context of a NAT traversal solution. > > This document obsoletes RFC 5389. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-stunbis-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-01 > > > 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 From nobody Wed Feb 25 20:55:52 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24A81A1A97; Wed, 25 Feb 2015 20:55:49 -0800 (PST) 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 xs_-sUGAWgrf; Wed, 25 Feb 2015 20:55:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5395D1A000F; Wed, 25 Feb 2015 20:55:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150226045548.32511.93805.idtracker@ietfa.amsl.com> Date: Wed, 25 Feb 2015 20:55:48 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-13.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, 26 Feb 2015 04:55:49 -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-13.txt Pages : 23 Date : 2015-02-25 Abstract: This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised. 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-13 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 Feb 25 20:55:54 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD86B1A0366; Wed, 25 Feb 2015 20:55:50 -0800 (PST) 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 IRJJnjgvPeE2; Wed, 25 Feb 2015 20:55:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B361A0373; Wed, 25 Feb 2015 20:55:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150226045548.32511.53326.idtracker@ietfa.amsl.com> Date: Wed, 25 Feb 2015 20:55:48 -0800 Archived-At: Subject: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 26 Feb 2015 04:55:50 -0000 A new version (-13) has been submitted for draft-ietf-tram-turn-third-party-authz: http://www.ietf.org/internet-drafts/draft-ietf-tram-turn-third-party-authz-13.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-13 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. IETF Secretariat. From nobody Thu Feb 26 07:05:05 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D7B1A0222 for ; Thu, 26 Feb 2015 07:05:03 -0800 (PST) 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 OETJCfPSWlq0 for ; Thu, 26 Feb 2015 07:05:01 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 83B241A016B for ; Thu, 26 Feb 2015 07:04:57 -0800 (PST) Received: from [IPv6:2602:43:2a2:c600:c4cf:cee8:9f06:5d65] (unknown [IPv6:2602:43:2a2:c600:c4cf:cee8:9f06:5d65]) (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 253A92013C; Thu, 26 Feb 2015 16:04:56 +0100 (CET) Message-ID: <54EF3616.4040704@acm.org> Date: Thu, 26 Feb 2015 08:04:54 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Oleg Moskalenko , "tram@ietf.org" References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 26 Feb 2015 15:05:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/25/2015 12:23 PM, Oleg Moskalenko wrote: > I'd like to clarify the necessity of the MESSAGE-INTEGRITY2 attribute. > My opinion is that we can avoid introducing a new MESSAGE-INTEGRITY[X] > attribute for every new used hash algorithm. What if we decide to use > SHA-384 ? Introduce MESSAGE-INTEGRITY3, and so on ? I think that this > is redundant, messy and unnecessary. > > There is a well-defined association between the hash length and the > algorithm. SHA-1 produce 20 bytes, SHA-256 produce 32 bytes, SHA-384 > produce 48 bytes and SHA-512 produce 64 bytes. Why we cannot use the > MESSAGE-INTEGRITY length to determine the algorithm that the peer is > using ? Does not work with SHA-3. > > If we want to support algorithm negotiation (vs the out-of-band > negotiation) then we can introduce a new error code "too weak > credentials" or something (and possibly another code "too strong > credentials") and use that error code in the negotiation stage. That > may mean a possible extra round trip on connection establishment. But > in most cases the client and the server will have a mutual > understanding which algorithm to be used. > > Or, we may require that all new STUN agents SHOULD support SHA-1 > through SHA-512 algorithms. It is not a problem these days, giving > current available libraries state. That would actually eliminate the > necessity of a new error code, new attribute and extra round-trip. The > client can propose an algorithm in the initial authenticated message; > if the server is not happy about the algorithm chosen by client, then > the server may reply OK but sign the message with a different hash > size. Then, the client must use the algorithm chosen by server, or > cancel the session. The server can always abort the session if the > algorithm strength does not match the server policy and if the client > is not cooperating. > - -- 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 iQIcBAEBCAAGBQJU7zYWAAoJECnERZXWan7EEhAQALW7XBjov+PX8fL1Lcth8ofu Yn0AbAiUgspdfAuxN6fnOv+skR28AQXCExLoKMQiiLzU1CZY4mijVRWn0c9eXEW2 RKfhYn3FacXk3P46raoHAV5qI3P09gRuQt1Oxj4vGiurQZBcw5dLaDhN42fwFrCn CIdpDyqIBuwgigq6NsDBLLjebu30N9m+5g2a2dP+9xLRTICk5/oot+3mhlaQinNv uOv9/HGM9JVTZwkomK6+HIDSKaXfKFRlQ7OB/Qn7MHFJLWq9At338jb72vAsI333 8UPPesdVazIfR9xW7/0FIo7aq+92iu9mhyLQIgIcnnUZS2xvwCYFyAdDlwhWUopX BpfiJ9sVthiAqOwYU7uIQ++GtFIfBITh+ferfwzSbrVsDLlGmtV3ktYeh3IzbOQK yIrOcmHWn1peaXqzNtqP9LwXP+WKvYtq84RLykSmYcDldDUpbmyejWj7ok06EbHo x0VKtx6UMLLqG339hSRFNIiixlbaQIZrkIc9rmuuglFxS4jwhavlPvG0NxA9GBl2 YpjPOzwIxY10hFGXz5YhaFTHHDbMPAAgyr8G8JXgR9KrC7FRxl1Bd6IRpTI9eYGc FbvPktsAYgRByI0pIHLulp2OhcCYV6jU/v8vfHP75P4dUtdAlp4rfP9OpitosaPb xX6iQsjbNTzZlhx3dFpZ =Wz3i -----END PGP SIGNATURE----- From nobody Thu Feb 26 08:56:28 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6917E1A90C1 for ; Thu, 26 Feb 2015 08:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liJ64g8B89mq for ; Thu, 26 Feb 2015 08:56:26 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E7D1A90CF for ; Thu, 26 Feb 2015 08:56:21 -0800 (PST) Received: by wesk11 with SMTP id k11so12685687wes.11 for ; Thu, 26 Feb 2015 08:56:20 -0800 (PST) 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=n0c6l6igxEpcbKarpsz2UUkayHCSwTRxQIkVuwBQ644=; b=WNfxYmBCu1axkOOf8QDocKgYhKbcapCj0JE+z5IiAUqFinTgF6fBPLVL5GCfvtOxBw DhiQZAK/Y3gDKsjv4kCvP6c8Yw6RXFMWqD7gHEJpBIrBBMKMmFHbfHXJMIInsw6zZE/x H1Cz/YixViPzVtRg8rH8+m0feemb8H63OLBr6ocG35zhGDcBFfAvdFQdQ3ukB0GrdCPr xCixvFWLTMDM9/84rq4ZMVWW+LAC91h/b+44+U0x6nQ3QyW4uRaNkAQY009oep014dAe DhN6QXAObJDUjlvwSpNIIc44gnOa01q+eJoHJ7PigLsTjaIPItVqO02x1p1qD38Mqdrh jaHQ== MIME-Version: 1.0 X-Received: by 10.194.58.209 with SMTP id t17mr18749845wjq.156.1424969780239; Thu, 26 Feb 2015 08:56:20 -0800 (PST) Received: by 10.194.190.18 with HTTP; Thu, 26 Feb 2015 08:56:20 -0800 (PST) In-Reply-To: <54EF3616.4040704@acm.org> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> Date: Thu, 26 Feb 2015 08:56:20 -0800 Message-ID: From: Oleg Moskalenko To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 26 Feb 2015 16:56:27 -0000 On Thu, Feb 26, 2015 at 7:04 AM, Marc Petit-Huguenin wrote: >> There is a well-defined association between the hash length and the >> algorithm. SHA-1 produce 20 bytes, SHA-256 produce 32 bytes, SHA-384 >> produce 48 bytes and SHA-512 produce 64 bytes. Why we cannot use the >> MESSAGE-INTEGRITY length to determine the algorithm that the peer is >> using ? > > Does not work with SHA-3. > If there is a requirement to support wide multiplicity of algorithms, even SHA-3, then I see two clear choices: 1) Leave the algorithm negotiation to the out-of-bound communication channel between the client and the server. They can negotiate what kind of hash is used, and what is the size of the MESSAGE-INTEGRITY to be. 2) Implement a usual negotiation scheme, like in TLS. We can introduce a new attribute that contains "algorithm ID" and optionally "algorithm attribute(s)" (specific to algorithm). The client sends a number of supported algorithm attributes to the server, server either rejects or picks one and sends back authenticated response with the chosen algorithm attribute. If no attribute is included in the client or server message, that means default "SHA-1, 160 bits". If a variable length hash algorithm chosen, then that's fine, the message recipient will just use the MESSAGE-INTEGRITY attribute length (given they already agree on a particular algorithm). I'd vote for the second approach. That way, we introduce no extra round trips, we cover multiple algorithms (including the future ones), and we have full backward compatibility. From nobody Fri Feb 27 04:20:13 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7C51AC3E0 for ; Fri, 27 Feb 2015 04:20:11 -0800 (PST) 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 ORs_PPnAREtq for ; Fri, 27 Feb 2015 04:20:10 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 18E581A871A for ; Fri, 27 Feb 2015 04:19:57 -0800 (PST) Received: from [IPv6:2602:43:2a2:c600:7887:c143:c7bc:aa03] (unknown [IPv6:2602:43:2a2:c600:7887:c143:c7bc:aa03]) (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 9D36E2013D; Fri, 27 Feb 2015 13:19:55 +0100 (CET) Message-ID: <54F060E8.5080004@acm.org> Date: Fri, 27 Feb 2015 05:19:52 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54ECD623.9060500@acm.org> <54ECDE65.1070803@acm.org> In-Reply-To: <54ECDE65.1070803@acm.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Simon Perreault , Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 27 Feb 2015 12:20:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/24/2015 01:26 PM, Marc Petit-Huguenin wrote: > On 02/24/2015 01:17 PM, Oleg Moskalenko wrote: >>> Section 6.2.3: "... the SCTP source and destination ports MUST be chosen so the two most significant bits are 0b11." > >> 0b11 looks more like bytes than bits. > > Java binary literal. Will fix. > In fact this is the same exact notation that is used in RFC 5389 section 6, so unless the WG wants us to also change section 6, the binary literal in stunbis section 6.2.3 will stay the same. - -- 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 iQIcBAEBCAAGBQJU8GDoAAoJECnERZXWan7EkLMQALXPCU1p/1Gh+kY5qg6Okesq Thp1gIs7/y6r7aBnyGPN+ab35b9nueJMiz1CoWhPg5dm015KQ6VoxM/ohD4aQYCi FKp1wxk2YWOcRN1PMLUDffC75qIyTbVEEd9vZBtDXpnkGzq4Z1zMb8BNlC//0r7B Ls1kIhjwhGsXLBqVXSaN3m8b+UguEaizsfWlrdObxqiEJ7Elqp71lYyvHXHzkdyB 6zqlfJUzs/SX2aIyAroye/cWUkAnY/QTArpo1XbD2P+q0Pn9IkDiVaKEvE5pz8F1 KqyJkBFM3GJODKGDLEAQWDHju0fqQMnIMo7c2Zk06JnsYmSxpRtHya9eRA7dvb0O zpwuM44lyzsmpRMN4iPgu7iDR0jGaMCDji+Kg2MAwzuwqYlfuKy4qL6ji4NDbLyy RCgFKJWwjLIFcBitb/vSbD1FQEHmMQ0vGG3D4XQjs30NxuvhOzqaXbDshV9cI986 f/pX/LlJbfl8nJk4qIvwLoMeqIWVvq5D2/hZpYnXaCQDom0x4SIFNFa+BEX0uXVR 0b2FEBnMyDYo1AlCTNO+tYeDqp4PJS0FF0ciWEY10LIg5d21aKZqoTcWELrBGyZl Frf6figCPv/pRFFhZRvpwq6oq9AV+9zcKnvid/kSibvz3h2kM3tLHEqWsPdVTXQL SCXxiojRrlUr4WoB5ljq =n1Zf -----END PGP SIGNATURE----- From nobody Fri Feb 27 07:39:19 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26261ACD47 for ; Fri, 27 Feb 2015 07:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olvLxl20urZa for ; Fri, 27 Feb 2015 07:39:15 -0800 (PST) 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 108401ACD3E for ; Fri, 27 Feb 2015 07:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9522; q=dns/txt; s=iport; t=1425051552; x=1426261152; h=from:to:subject:date:message-id:references:mime-version; bh=a1A8Xk5CL06t2JdQhdHJOmBd9jNX0K6iIqnOaQDvOaI=; b=cEhpp+SrHmZCck+Obus/IUnpeS7z7TMCwVu7GiJQvb2FPOpcjYLK8EwW +cKzRRnoN/91Zly2JDDAGIhJMtWSXPeWWBTuip5cysZwp/4SuV5tWCNBM Fl1r/3oFklCatUcmLdX55oC9naJzTaZZvmvanxOX1NcVqD8Vo06xETlxV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DkBwA8j/BU/51dJa1bgwJSWgSDBr0hgWoBC4VuHoEITQEBAQEBAXyEEAEBBCNmAgFKAgICMBcBDQIEHIgmDb0vmhEBAQEBAQUBAQEBAQEBARqPfII4OxIdgRQFj3SDYIVmgRs5gmWPGCODbm8BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.09,660,1418083200"; d="scan'208,217";a="127558155" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 27 Feb 2015 15:39:11 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t1RFdB6c032341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Feb 2015 15:39:11 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Fri, 27 Feb 2015 09:39:11 -0600 From: "Pal Martinsen (palmarti)" To: "tram@ietf.org" Thread-Topic: STUNTrace Draft Thread-Index: AQHQUqOHsfB2hrwh90Gd8Ygz4gVbaQ== Date: Fri, 27 Feb 2015 15:39:10 +0000 Message-ID: <5BD9B28E-26D7-4E2A-838B-4D788454D079@cisco.com> References: <20150227152034.989.5946.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.169.231] Content-Type: multipart/alternative; boundary="_000_5BD9B28E26D74E2A838B4D788454D079ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [tram] STUNTrace Draft 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, 27 Feb 2015 15:39:17 -0000 --_000_5BD9B28E26D74E2A838B4D788454D079ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldlIGp1c3QgdXBsb2FkZWQgYSBuZXcgZHJhZnQsIFNUVU5UcmFjZSAoaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFydGluc2VuLXRyYW0tc3R1bnRyYWNlLTAwKS4gSXQg ZGVzY3JpYmVzIGhvdyB0byBkdSDigJxpbi1iYW5k4oCdIHRyYWNyZW91dGUgb24gdGhlIHNhbWUg NS10dXBsZSBhcyB5b3Ugc2VuZCBtZWRpYSB1c2luZyBTVFVOIHByb2JlIHBhY2tldHMgYW5kIElD TVAgcmVzcG9uc2VzLg0KDQpJdCBhbGlnbnMgd2l0aCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtcGV0aXRodWd1ZW5pbi10cmFtLXN0dW4tcG10dWQtMDAgdXNpbmcgU1RVTiBhcyBh IHByb2JlIHRvIGRpc2NvdmVyIG5ldHdvcmsgcHJvcGVydGllcy4NCg0KV2UgYWRkZWQgY29kZSBl eGFtcGxlcyBpbiB0aGUgYXBwZW5kaXggdG8gY2xhcmlmeSBob3cgSUNNUCBjYW4gYmUgcmVjZWl2 ZWQgYnkgYXBwbGljYXRpb25zIHdpdGhvdXQgcmVxdWlyaW5nIGFkbWluIHByaXZpbGVnZXMuIFdl IHN0aWxsIGxhY2sgV2luZG93cyBleGFtcGxlcywgc28gaGVscCB3aXRoIHRoYXQgaXMgYXBwcmVj aWF0ZWQuIElDTVAgdGVzdCBjb2RlIChub3QgaW1wbGVtZW50aW5nIHRoaXMgZHJhZnQpIGNhbiBi ZSBmb3VuZCBhdDogaHR0cHM6Ly9naXRodWIuY29tL3BhbGVyaWttL0lDTVBUZXN0DQoNClF1ZXN0 aW9ucyBhbmQgY29tbWVudHMgYXJlIG9mIGNvdXJzZSB3ZWxjb21lLg0KDQouLS4NClDDpWwtRXJp aw0KDQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtbWFydGluc2VuLXRyYW0tc3R1bnRyYWNlLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBQYWFsLUVyaWsgTWFydGluc2VuIGFuZCBwb3N0ZWQgdG8gdGhlDQpJ RVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6IGRyYWZ0LW1hcnRpbnNlbi10cmFtLXN0dW50cmFjZQ0K UmV2aXNpb246IDAwDQpUaXRsZTogU1RVTiBUcmFjZXJvdXRlDQpEb2N1bWVudCBkYXRlOiAyMDE1 LTAyLTI3DQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogMTINClVSTDogICAg ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXJ0aW5z ZW4tdHJhbS1zdHVudHJhY2UtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWFydGluc2VuLXRyYW0tc3R1bnRyYWNlLw0KSHRtbGl6 ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hcnRpbnNlbi10cmFt LXN0dW50cmFjZS0wMA0KDQoNCkFic3RyYWN0Og0KICBBZnRlciBhIFVEUCBwcm90b2NvbCBzdWNo IGFzIFJUUCBkZXRlcm1pbmVzIGEgbmV0d29yayBwYXRoIGlzDQogIGV4cGVyaWVuY2luZyBwcm9i bGVtcywgYSB0cmFjZXJvdXRlIGlzIG9mdGVuIHVzZWZ1bCB0byBkZXRlcm1pbmUNCiAgd2hpY2gg cm91dGVyIG9yIHdoaWNoIGxpbmsgaXMgY29udHJpYnV0aW5nIHRvIHRoZSBwcm9ibGVtLiAgSG93 ZXZlciwNCiAgb3BlcmF0aW5nIHN5c3RlbSB0cmFjZXJvdXRlIGNvbW1hbmRzIGZvbGxvdyBhIGRp ZmZlcmVudCBwYXRoIHRoYW4gdGhlDQogIGFjdHVhbCBVRFAgZmxvdyB3aGljaCBjb21wbGljYXRl cyB0cm91Ymxlc2hvb3RpbmcuICBBIHN1cGVyaW9yIG1ldGhvZA0KICBpcyBzaG93biB3aGljaCBp cyBhYnNvbHV0ZWx5IHBhdGgtY29uZ3J1ZW50IHdpdGggdGhlIFVEUCBwcm90b2NvbA0KICBpdHNl bGYsIHdvcmtzIG9uIElQdjQgYW5kIElQdjYsIGFuZCBkb2VzIG5vdCByZXF1aXJlIGFkbWluaXN0 cmF0aXZlDQogIHByaXZpbGVnZXMgb24gbW9zdCBvcGVyYXRpbmcgc3lzdGVtcy4NCg0KDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_5BD9B28E26D74E2A838B4D788454D079ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4053188C1B0C604AB4D2125249992175@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSBqdXN0IHVwbG9hZGVkIGEgbmV3 IGRyYWZ0LCBTVFVOVHJhY2UgKDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LW1hcnRpbnNlbi10cmFtLXN0dW50cmFjZS0wMCIgY2xhc3M9IiI+aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbWFydGluc2VuLXRyYW0tc3R1bnRyYWNlLTAwPC9hPikuIEl0IGRl c2NyaWJlcyBob3cgdG8gZHUg4oCcaW4tYmFuZOKAnSB0cmFjcmVvdXRlIG9uIHRoZSBzYW1lDQog NS10dXBsZSBhcyB5b3Ugc2VuZCBtZWRpYSB1c2luZyBTVFVOIHByb2JlIHBhY2tldHMgYW5kIElD TVAgcmVzcG9uc2VzLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SXQgYWxpZ25zIHdpdGgmbmJzcDs8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGV0aXRodWd1ZW5pbi10cmFtLXN0dW4tcG10dWQt MDAiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZXRpdGh1Z3Vl bmluLXRyYW0tc3R1bi1wbXR1ZC0wMDwvYT4mbmJzcDt1c2luZyBTVFVOIGFzIGEgcHJvYmUgdG8g ZGlzY292ZXIgbmV0d29yayBwcm9wZXJ0aWVzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2UgYWRkZWQgY29kZSBleGFtcGxlcyBpbiB0 aGUgYXBwZW5kaXggdG8gY2xhcmlmeSBob3cgSUNNUCBjYW4gYmUgcmVjZWl2ZWQgYnkgYXBwbGlj YXRpb25zIHdpdGhvdXQgcmVxdWlyaW5nIGFkbWluIHByaXZpbGVnZXMuIFdlIHN0aWxsIGxhY2sg V2luZG93cyBleGFtcGxlcywgc28gaGVscCB3aXRoIHRoYXQgaXMgYXBwcmVjaWF0ZWQuIElDTVAg dGVzdCBjb2RlIChub3QgaW1wbGVtZW50aW5nIHRoaXMgZHJhZnQpIGNhbiBiZQ0KIGZvdW5kIGF0 OiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9wYWxlcmlrbS9JQ01QVGVzdCIgY2xh c3M9IiI+aHR0cHM6Ly9naXRodWIuY29tL3BhbGVyaWttL0lDTVBUZXN0PC9hPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UXVlc3Rpb25z IGFuZCBjb21tZW50cyBhcmUgb2YgY291cnNlIHdlbGNvbWUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4uLS48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+UMOlbC1FcmlrPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtbWFydGluc2VuLXRyYW0tc3R1bnRyYWNlLTAwLnR4dDxiciBjbGFzcz0iIj4NCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGFhbC1FcmlrIE1hcnRpbnNlbiBhbmQgcG9z dGVkIHRvIHRoZTxiciBjbGFzcz0iIj4NCklFVEYgcmVwb3NpdG9yeS48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpOYW1lOjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9Indo aXRlLXNwYWNlOnByZSI+IDwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxl PSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5kcmFmdC1tYXJ0aW5zZW4tdHJhbS1zdHVudHJhY2U8 YnIgY2xhc3M9IiI+DQpSZXZpc2lvbjo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxl PSJ3aGl0ZS1zcGFjZTpwcmUiPiA8L3NwYW4+MDA8YnIgY2xhc3M9IiI+DQpUaXRsZTo8c3BhbiBj bGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPiA8L3NwYW4+PHNw YW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+ U1RVTiBUcmFjZXJvdXRlPGJyIGNsYXNzPSIiPg0KRG9jdW1lbnQgZGF0ZTo8c3BhbiBjbGFzcz0i QXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPiA8L3NwYW4+MjAxNS0wMi0y NzxiciBjbGFzcz0iIj4NCkdyb3VwOjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9 IndoaXRlLXNwYWNlOnByZSI+IDwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5JbmRpdmlkdWFsIFN1Ym1pc3Npb248YnIgY2xh c3M9IiI+DQpQYWdlczo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1z cGFjZTpwcmUiPiA8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hp dGUtc3BhY2U6cHJlIj48L3NwYW4+MTI8YnIgY2xhc3M9IiI+DQpVUkw6ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1hcnRpbnNlbi10 cmFtLXN0dW50cmFjZS0wMC50eHQiIGNsYXNzPSIiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LW1hcnRpbnNlbi10cmFtLXN0dW50cmFjZS0wMC50eHQ8L2E+PGJyIGNs YXNzPSIiPg0KU3RhdHVzOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1t YXJ0aW5zZW4tdHJhbS1zdHVudHJhY2UvIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1zdHVudHJhY2UvPC9hPjxiciBjbGFzcz0i Ij4NCkh0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1zdHVudHJh Y2UtMDAiIGNsYXNzPSIiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hcnRpbnNl bi10cmFtLXN0dW50cmFjZS0wMDwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpBYnN0cmFjdDo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtBZnRlciBhIFVE UCBwcm90b2NvbCBzdWNoIGFzIFJUUCBkZXRlcm1pbmVzIGEgbmV0d29yayBwYXRoIGlzPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7ZXhwZXJpZW5jaW5nIHByb2JsZW1zLCBhIHRyYWNlcm91dGUg aXMgb2Z0ZW4gdXNlZnVsIHRvIGRldGVybWluZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3do aWNoIHJvdXRlciBvciB3aGljaCBsaW5rIGlzIGNvbnRyaWJ1dGluZyB0byB0aGUgcHJvYmxlbS4g Jm5ic3A7SG93ZXZlciw8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtvcGVyYXRpbmcgc3lzdGVt IHRyYWNlcm91dGUgY29tbWFuZHMgZm9sbG93IGEgZGlmZmVyZW50IHBhdGggdGhhbiB0aGU8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDthY3R1YWwgVURQIGZsb3cgd2hpY2ggY29tcGxpY2F0ZXMg dHJvdWJsZXNob290aW5nLiAmbmJzcDtBIHN1cGVyaW9yIG1ldGhvZDxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwO2lzIHNob3duIHdoaWNoIGlzIGFic29sdXRlbHkgcGF0aC1jb25ncnVlbnQgd2l0 aCB0aGUgVURQIHByb3RvY29sPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7aXRzZWxmLCB3b3Jr cyBvbiBJUHY0IGFuZCBJUHY2LCBhbmQgZG9lcyBub3QgcmVxdWlyZSBhZG1pbmlzdHJhdGl2ZTxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3ByaXZpbGVnZXMgb24gbW9zdCBvcGVyYXRpbmcgc3lz dGVtcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyIGNsYXNzPSIiPg0K dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIGNsYXNzPSIiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+ LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5BD9B28E26D74E2A838B4D788454D079ciscocom_-- From nobody Fri Feb 27 08:02:29 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685471ACD4A for ; Fri, 27 Feb 2015 08:02:28 -0800 (PST) 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 58fghM4s7sab for ; Fri, 27 Feb 2015 08:02:26 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421881A88EC for ; Fri, 27 Feb 2015 08:02:26 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id n4so13342775qaq.5 for ; Fri, 27 Feb 2015 08:02:25 -0800 (PST) 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=Eg5krj/90SM4BgNCgZ3Blkle6fGsMkmvoGqgQrW4+0E=; b=SmYBk8OcAGixpIVMcV5wFgluubJQCsW0rL0E8hyODjR+5RQC++x0BcUrX5UjwEWslQ DiFO+EgMC08trNARcPnqYFA2L0DWoRMQ8vS/jiTw4/AtZNNyUbsWmu6UdlOZBZCc9S9D xwHxEGvVUgv1Fn3Pno2sts5dvfsGEieHcrYVMN+lkwJqn0OZW8JfOxL61eSh8V0dCk/n xW7QlF/Iam3BlkEipECjaMSPRjdIguS2DZqAH+8BtWZQKh8RvCIxdajMwVjoR/BIyOlb 3HQJ9HakwRjtDECbcCKDGX4jxjVlI8Gx+U+tVpQWS5kQbPzgbitlIYcqxlOloEbkRV/l Yznw== X-Gm-Message-State: ALoCoQnNoiTTVVIMnajNWF1rnp9MNfMw5yqs96ZL1T/kty6rb4xh6R9xagdk+4PCJoyOnf2ZfLIJ X-Received: by 10.55.41.38 with SMTP id p38mr677573qkh.9.1425052945439; Fri, 27 Feb 2015 08:02:25 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com. [209.85.216.170]) by mx.google.com with ESMTPSA id b107sm2469180qge.49.2015.02.27.08.02.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Feb 2015 08:02:24 -0800 (PST) Received: by qcwr17 with SMTP id r17so14548786qcw.1 for ; Fri, 27 Feb 2015 08:02:24 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.229.139.194 with SMTP id f2mr29631348qcu.14.1425052944345; Fri, 27 Feb 2015 08:02:24 -0800 (PST) Received: by 10.229.160.201 with HTTP; Fri, 27 Feb 2015 08:02:24 -0800 (PST) In-Reply-To: <5BD9B28E-26D7-4E2A-838B-4D788454D079@cisco.com> References: <20150227152034.989.5946.idtracker@ietfa.amsl.com> <5BD9B28E-26D7-4E2A-838B-4D788454D079@cisco.com> Date: Fri, 27 Feb 2015 11:02:24 -0500 Message-ID: From: Benjamin Schwartz To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=001a1133dea88901aa051013fe11 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] STUNTrace Draft 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, 27 Feb 2015 16:02:28 -0000 --001a1133dea88901aa051013fe11 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How widely deployed (and enabled) is this kind of ICMP error reporting (e.g. TTL exceeded)? My impression, consistent with your security section, is that many network administrators disable this functionality. On Fri, Feb 27, 2015 at 10:39 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > Hi, > > We just uploaded a new draft, STUNTrace ( > http://tools.ietf.org/html/draft-martinsen-tram-stuntrace-00). It > describes how to du =E2=80=9Cin-band=E2=80=9D tracreoute on the same 5-tu= ple as you send > media using STUN probe packets and ICMP responses. > > It aligns with > https://tools.ietf.org/html/draft-petithuguenin-tram-stun-pmtud-00 using > STUN as a probe to discover network properties. > > We added code examples in the appendix to clarify how ICMP can be > received by applications without requiring admin privileges. We still lac= k > Windows examples, so help with that is appreciated. ICMP test code (not > implementing this draft) can be found at: > https://github.com/palerikm/ICMPTest > > Questions and comments are of course welcome. > > .-. > P=C3=A5l-Erik > > > Begin forwarded message: > > A new version of I-D, draft-martinsen-tram-stuntrace-00.txt > has been successfully submitted by Paal-Erik Martinsen and posted to the > IETF repository. > > Name: draft-martinsen-tram-stuntrace > Revision: 00 > Title: STUN Traceroute > Document date: 2015-02-27 > Group: Individual Submission > Pages: 12 > URL: > http://www.ietf.org/internet-drafts/draft-martinsen-tram-stuntrace-00.txt > Status: > https://datatracker.ietf.org/doc/draft-martinsen-tram-stuntrace/ > Htmlized: > http://tools.ietf.org/html/draft-martinsen-tram-stuntrace-00 > > > Abstract: > After a UDP protocol such as RTP determines a network path is > experiencing problems, a traceroute is often useful to determine > which router or which link is contributing to the problem. However, > operating system traceroute commands follow a different path than the > actual UDP flow which complicates troubleshooting. A superior method > is shown which is absolutely path-congruent with the UDP protocol > itself, works on IPv4 and IPv6, and does not require administrative > privileges on most operating systems. > > > > > 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 > > --001a1133dea88901aa051013fe11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How widely deployed (and enabled) is this kind of ICMP err= or reporting (e.g. TTL exceeded)?=C2=A0 My impression, consistent with your= security section, is that many network administrators disable this functio= nality.

On F= ri, Feb 27, 2015 at 10:39 AM, Pal Martinsen (palmarti) &l= t;palmarti@cisco.co= m> wrote:
Hi,

We just uploaded a new draft, STUNTrace (http://tools.= ietf.org/html/draft-martinsen-tram-stuntrace-00). It describes how to d= u =E2=80=9Cin-band=E2=80=9D tracreoute on the same 5-tuple as you send media using STUN probe packets and ICMP responses.=C2= =A0

It aligns with=C2=A0https://tools.ietf.org/html/= draft-petithuguenin-tram-stun-pmtud-00=C2=A0using STUN as a probe to di= scover network properties.

We added code examples in the appendix to clarify how ICMP can be rece= ived by applications without requiring admin privileges. We still lack Wind= ows examples, so help with that is appreciated. ICMP test code (not impleme= nting this draft) can be found at:=C2=A0https://github.com/palerikm/ICMPTest

Questions and comments are of course welcome.

.-.
P=C3=A5l-Erik


Begin forwarded message:

A new version of I-D, draft-martinsen-tram-stuntrace-00.txt
has been successfully submitted by Paal-Erik Martinsen and posted to the IETF repository.

Name: draft-martinsen-tram-stuntrace
Revision: 00
Title: STUN Traceroute
Document date: 2015-02-27
Group: Individual Submission
Pages: 12
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/internet-drafts/draft-martinse= n-tram-stuntrace-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-martinsen-tram-stuntrace/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://tools.= ietf.org/html/draft-martinsen-tram-stuntrace-00


Abstract:
=C2=A0=C2=A0After a UDP protocol such as RTP determines a network path is =C2=A0=C2=A0experiencing problems, a traceroute is often useful to determin= e
=C2=A0=C2=A0which router or which link is contributing to the problem.=C2= =A0 However,
=C2=A0=C2=A0operating system traceroute commands follow a different path th= an the
=C2=A0=C2=A0actual UDP flow which complicates troubleshooting.=C2=A0 A supe= rior method
=C2=A0=C2=A0is shown which is absolutely path-congruent with the UDP protoc= ol
=C2=A0=C2=A0itself, works on IPv4 and IPv6, and does not require administra= tive
=C2=A0=C2=A0privileges on most operating systems.




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

The IETF Secretariat



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


--001a1133dea88901aa051013fe11-- From nobody Fri Feb 27 19:10:17 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1E71A1B77; Fri, 27 Feb 2015 19:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO89DN9VS3Kr; Fri, 27 Feb 2015 19:10:15 -0800 (PST) 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 3DBB21A1B6C; Fri, 27 Feb 2015 19:10:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1824; q=dns/txt; s=iport; t=1425093016; x=1426302616; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Fa1QV8nO+z+GwdjIuV1zFCrJs/JewcnFCtv/oIITyqU=; b=OdRA+3zpIU/xE3RX15ETF+x4a4POce9V77mkPsgg5YFW42rE17xo9baW JeR/jEsY1U+hUOnXoXf6qBetMFfoI9C0dZ29GQPkIAIuXlKb1Y7a99pJu nz1heRLRtc6YVif3GEy+Zv4Wiy/ZqaaPCK8VwO1P0o6AEc6L/hmvgkK2l E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BUCQCDMPFU/4cNJK1bgwJSVQUEgwa8aYIyhW4CHIEITQEBAQEBAXyEDwEBAQQjEUMOBgEIEQQBAQMCBh0DAgQfERQBCAkBBAESCAGIEgMRCAW8XZQJDYUzAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXGCRIF5FiiCYi+BFAWPdoNfhB+CYTmCZokQhgojg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,664,1418083200"; d="scan'208";a="399791079" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP; 28 Feb 2015 03:10:15 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t1S3AEhW023044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 28 Feb 2015 03:10:14 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Fri, 27 Feb 2015 21:10:14 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "gonzalo.camarillo@ericsson.com" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" , "stephen.farrell@cs.tcd.ie" Thread-Topic: New Version Notification - draft-ietf-tram-turn-third-party-authz-13.txt Thread-Index: AdBTBA4y4KcyM1WqQy+n0K4q1vICBA== Date: Sat, 28 Feb 2015 03:10:13 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366AA244@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.63.161] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 28 Feb 2015 03:10:17 -0000 V2UgaGF2ZSByZXNwb25kZWQgdG8gY29tbWVudHMgZnJvbSBJU0VHIGFuZCBwdWJsaXNoZWQgdXBk YXRlZCBkcmFmdC4gDQoNCi1UaXJ1DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjYsIDIwMTUgMTA6MjYgQU0NCj4g VG86IHRyYW0tY2hhaXJzQGlldGYub3JnOyB0cmFtQGlldGYub3JnOyBkcmFmdC1pZXRmLXRyYW0t dHVybi10aGlyZC1wYXJ0eS0NCj4gYXV0aHpAaWV0Zi5vcmc7IGdvbnphbG8uY2FtYXJpbGxvQGVy aWNzc29uLmNvbTsgZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtDQo+IHBhcnR5LWF1dGh6LmFk QGlldGYub3JnOyBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS0NCj4gYXV0aHouc2hl cGhlcmRAaWV0Zi5vcmc7IHNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tOyBybGJAaXB2LnN4 Ow0KPiBzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiAtIGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LQ0KPiAx My50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uICgtMTMpIGhhcyBiZWVuIHN1Ym1pdHRlZCBm b3IgZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktDQo+IGF1dGh6Og0KPiBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1w YXJ0eS1hdXRoei0NCj4gMTMudHh0DQo+IA0KPiBTdWIgc3RhdGUgaGFzIGJlZW4gY2hhbmdlZCB0 byBBRCBGb2xsb3d1cCBmcm9tIFJldmlzZWQgSUQgTmVlZGVkDQo+IA0KPiANCj4gVGhlIElFVEYg ZGF0YXRyYWNrZXIgcGFnZSBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHkt YXV0aHovDQo+IA0KPiBEaWZmIGZyb20gcHJldmlvdXMgdmVyc2lvbjoNCj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0 aHotMTMNCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IElF VEYgU2VjcmV0YXJpYXQuDQoNCg== From nobody Sat Feb 28 10:28:43 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAE91A7D81 for ; Sat, 28 Feb 2015 10:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmunqAAGRl9y for ; Sat, 28 Feb 2015 10:28:40 -0800 (PST) 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 06BA41A7113 for ; Sat, 28 Feb 2015 10:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9953; q=dns/txt; s=iport; t=1425148121; x=1426357721; h=from:to:subject:date:message-id:mime-version; bh=2ziuLzrvJsi9MbO89M1fZBAQznsojFsMk43xdsyZ8Dg=; b=EBNR804WgePmYJCFto7ELqQ8U3aO2vgZAA5hvP1B2jmioZUV2yLvxPAY UJ5so67qwFxgsfVU4Gj8Gs2eG9v4aJ+6MoZtnRObppLdBOu+rRbC0E7bj S9hBoUIqyzqvyGdd4/VTP5kPffj5dkqRIAh7aU10DPw32+FAdcNM2PG1j U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C2BgB/CPJU/5JdJa1bgj9DUloEwC2BdoVuAoEZTQEBAQEBAXyEDwECBIELAQgRAwECKDkUAwEFCgQBEgmIJg3VBAEBCAIBH4sShB0BAT4NEYQlBY94g1+FZ4EaOYJnjx0jg25vAYEKOX8BAQE X-IronPort-AV: E=Sophos;i="5.09,668,1418083200"; d="scan'208,217";a="399929091" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP; 28 Feb 2015 18:28:39 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t1SISc1q005983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 28 Feb 2015 18:28:38 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.45]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Sat, 28 Feb 2015 12:28:37 -0600 From: "Charles Eckel (eckelcu)" To: "Pal Martinsen (palmarti)" , "tram@ietf.org" Thread-Topic: [tram] STUNTrace Draft Thread-Index: AQHQU4RdsfB2hrwh90Gd8Ygz4gVbaQ== Date: Sat, 28 Feb 2015 18:28:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.82.231.168] Content-Type: multipart/alternative; boundary="_000_D11772443F386eckelcuciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [tram] STUNTrace Draft 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, 28 Feb 2015 18:28:42 -0000 --_000_D11772443F386eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: "Pal Martinsen (palmarti)" > Date: Friday, February 27, 2015 at 9:39 AM To: "tram@ietf.org" > Subject: [tram] STUNTrace Draft Hi, We just uploaded a new draft, STUNTrace (http://tools.ietf.org/html/draft-m= artinsen-tram-stuntrace-00). It describes how to du =93in-band=94 tracreout= e on the same 5-tuple as you send media using STUN probe packets and ICMP r= esponses. It aligns with https://tools.ietf.org/html/draft-petithuguenin-tram-stun-pm= tud-00 using STUN as a probe to discover network properties. We added code examples in the appendix to clarify how ICMP can be received = by applications without requiring admin privileges. We still lack Windows e= xamples, so help with that is appreciated. ICMP test code (not implementing= this draft) can be found at: https://github.com/palerikm/ICMPTest I also believe there are plans to do some hacking in this area at the Hacka= thon. It would be great if Windows examples were an output produced by this= event. http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13823.html Cheers, Charles Questions and comments are of course welcome. .-. P=E5l-Erik Begin forwarded message: A new version of I-D, draft-martinsen-tram-stuntrace-00.txt has been successfully submitted by Paal-Erik Martinsen and posted to the IETF repository. Name: draft-martinsen-tram-stuntrace Revision: 00 Title: STUN Traceroute Document date: 2015-02-27 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-martinsen-tram-st= untrace-00.txt Status: https://datatracker.ietf.org/doc/draft-martinsen-tram-stunt= race/ Htmlized: http://tools.ietf.org/html/draft-martinsen-tram-stuntrace-0= 0 Abstract: After a UDP protocol such as RTP determines a network path is experiencing problems, a traceroute is often useful to determine which router or which link is contributing to the problem. However, operating system traceroute commands follow a different path than the actual UDP flow which complicates troubleshooting. A superior method is shown which is absolutely path-congruent with the UDP protocol itself, works on IPv4 and IPv6, and does not require administrative privileges on most operating systems. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_D11772443F386eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

From: "Pal Martinsen (palmarti= )" <palmarti@cisco.com>= ;
Date: Friday, February 27, 2015 at = 9:39 AM
To: "tram@ietf.org" <tram@i= etf.org>
Subject: [tram] STUNTrace Draft

Hi,

We just uploaded a new draft, STUNTrace (http://to= ols.ietf.org/html/draft-martinsen-tram-stuntrace-00). It describes how = to du =93in-band=94 tracreoute on the same 5-tuple as you send media using STUN probe packets and ICMP responses.&nbs= p;

It aligns with https://tools.ietf.org/h= tml/draft-petithuguenin-tram-stun-pmtud-00 using STUN as a probe t= o discover network properties.

We added code examples in the appendix to clarify how ICMP = can be received by applications without requiring admin privileges. We stil= l lack Windows examples, so help with that is appreciated. ICMP test code (= not implementing this draft) can be found at: https://github.com/palerikm/ICMPTest

I also believe there are plans to do some hacking in this area at the = Hackathon. It would be great if Windows examples were an output produced by= this event.

Cheers,
Charles


Questions and comments are of course welcome.

.-.
P=E5l-Erik


Begin forwarded message:

A new version of I-D, draft-martinsen-tram-stuntrace-00.txt
has been successfully submitted by Paal-Erik Martinsen and posted to the IETF repository.

Name: draft-martinsen-= tram-stuntrace
Revision: 0= 0
Title: STUN Traceroute=
Document date: 2015-02-27
Group: Individual Subm= ission
Pages: 12
URL:            http://www.ietf.org/internet-drafts/draft-martinsen-tram-= stuntrace-00.txt
Status:         https:= //datatracker.ietf.org/doc/draft-martinsen-tram-stuntrace/
Htmlized:       http://tools.ietf.or= g/html/draft-martinsen-tram-stuntrace-00


Abstract:
  After a UDP protocol such as RTP determines a network path is   experiencing problems, a traceroute is often useful to determin= e
  which router or which link is contributing to the problem. &nbs= p;However,
  operating system traceroute commands follow a different path th= an the
  actual UDP flow which complicates troubleshooting.  A supe= rior method
  is shown which is absolutely path-congruent with the UDP protoc= ol
  itself, works on IPv4 and IPv6, and does not require administra= tive
  privileges on most operating systems.




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

The IETF Secretariat


 --_000_D11772443F386eckelcuciscocom_--