From nobody Fri Dec 1 01:45:55 2017 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0F412778D for ; Fri, 1 Dec 2017 01:45:53 -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, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 uoWKfaL2PY4x for ; Fri, 1 Dec 2017 01:45:51 -0800 (PST) Received: from linzer.ki.iif.hu (linzer.ki.iif.hu [193.224.163.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CC5127333 for ; Fri, 1 Dec 2017 01:45:50 -0800 (PST) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by linzer.ki.iif.hu (Postfix) with ESMTP id 1C2754060D6 for ; Fri, 1 Dec 2017 10:45:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from linzer.ki.iif.hu ([IPv6:::ffff:193.224.163.7]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id FKGapRjEPtQb for ; Fri, 1 Dec 2017 10:45:47 +0100 (CET) Received: from [IPv6:2001:738:0:401:216:e6ff:fe88:b8a] (alma6.ki.iif.hu [IPv6:2001:738:0:401:216:e6ff:fe88:b8a]) by linzer.ki.iif.hu (Postfix) with ESMTPSA id ACF684060C4 for ; Fri, 1 Dec 2017 10:45:46 +0100 (CET) To: tram@ietf.org References: From: =?UTF-8?B?TcOpc3rDoXJvcyBNaWjDoWx5?= Message-ID: <0b1fbac7-e54e-1ba6-f0a2-9a7a3cccd3f5@niif.hu> Date: Fri, 1 Dec 2017 10:45:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Archived-At: Subject: Re: [tram] Possible inconsistency with RFC-7635 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is 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, 01 Dec 2017 09:45:53 -0000 Hi Kevin, 2017-11-30 17:30 keltez=C3=A9ssel, Kevin Wooten =C3=ADrta: > All, > > We have just implemented a STUN/TURN server in Java/Kotlin using Netty= =2E It was originally done after examining =E2=80=9Ccoturn=E2=80=9D as a = possible solution and deciding we would roll our own for a number of reas= ons and have completed a working version. /I am little bit sorry about that you didn't considered to invest the time in coTURN or similar public efforts instead of opened a new own private development. My belief that open joint efforts are always more beneficial. :-) / > One of the biggest reasons for rolling our own server was to be able t= o implement proper accounting, traffic shaping and statistics. During th= e implementation we realized that we might have an issue with OAuth authe= ntication. > > As we implemented RFC-7635 there seems to be an inconsistency we canno= t reconcile with the way credentials are required to be handled throughou= t the spec and those provided by the OAuth spec. Specifically that OAuth = POP never provides the server an actual username (and possibly realm) to = the server. This has shown us what appears to be an inconsistency with t= he original TURN spec (RFC-5766) and it happens to be very limiting when = implementing our accounting, shaping and statistics. > > -- Inconsistency between RFC-7635 and RFC-5766 =E2=80=94 > > First I=E2=80=99ll inquire about the possible inconsistency... In RFC-= 5766 section 17.3.3 titled ("Manipulating Other Allocations=E2=80=9D) it = details an insider attack that is prevented by =E2=80=9Crequiring that th= e credentials used in CreatePermission, Refresh, and ChannelBind messages= match those used to create the initial allocation=E2=80=9D. The requirem= ents for storing and comparing the credentials are mentioned throughout 5= 766 spec and does not appear to be an =E2=80=9Coptional=E2=80=9D part of = the spec as Section 4 paragraph 5 details this as a requirement. I also think that this is an inconsistency, but because mac_keys have short lifetime /are ephemeral/, and mac_key is unique /generated/ value , so it may narrow down very much the attack window. Comparing to LTC, may it could be enough to address this issue. IMHO the to check this is requirement is meaningless in case of oauth, and you should skip it. All in all I think You ought to open an errata on 7635 side.. > > For long term credentials this is fairly easy as the USERNAME uniquely= identifies a specific user. When implementing OAuth we cannot figure ou= t how to do this reliably. The OAuth POP token, provided in ACCESS-TOKEN,= only provides the session/mac key, lifetime and timestamp; it doesn=E2=80= =99t identify a specific user. The USERNAME only identifies the key id re= quired to decrypt the ACCESS-TOKEN. We tried using the session/mac key a= s the =E2=80=9Ccredentials=E2=80=9D but since each call to the OAuth AS w= ill produce a difference session/mac key (and possibly even use a differe= nt key id) it causes subsequent requests (e.g. REFRESH) to fail; this was= proven when we ran interoperation tests with coturn=E2=80=99s test clien= t. This is especially prevalent when the ACCESS-TOKEN expires and needs = to be refreshed because it will definitely generate a new session/mac key= =2E Essentially, this means anybody who was issued a token with the same = key id (kid) is considered to be the same user and therefore _could_ mani= pulate another=E2=80=99s allocation; although the attack seems remote and= requires spoofing it nonetheless is detailed as a requirement. > > I=E2=80=99d like to know if our interpretation is wrong, if we=E2=80=99= re missing something or if this is a valid inconsistency in specs. In any= case, it does seem a proper username and possibly realm should be retrie= vable _somewhere_ in an OAuth authenticated request; whether in a new att= ribute, the original attribute (and key id moved someplace else), in the = ACCESS-TOKEN, or maybe it=E2=80=99s there and we=E2=80=99ve missed exactl= y how to derive it. > > -- Impediment related to accounting and statistics =E2=80=94 I see the same way... You are right RFC7635 does not signal any additional data in access_token just what you have mentioned.. This allows only a grant/deny service classification. To add more information may in other hand adds some possibility for servers to log and fingerprint the user. IMHO we should not stick it to user ID directly. I agree that there is no fine grained classification, and so there is no possibility for traffic shaping/limiting based on username or similar id.= =2E > This is basically a follow on to the previous.. One of our stated goal= s was proper accounting, shaping, and statistics. This is not easily done= in the current form of RFC-7635 as we only have the key id (in USERNAME)= to identify clients. As you might imagine this is not useful for out sta= ted purposes. For example, trying to traffic shape (e.g. bandwidth thrott= ling) per user is pretty hard when the user isn=E2=80=99t known.=20 > > The only work arounds we seem to have are using a unique long term key= per user or some form of communication between the TURN server and the A= S server to exchange a session/mac key for proper user identification; we= =E2=80=99d really love to avoid either of those as they corrupt many of t= he advantages of using the OAuth mechanism. If we are able to resolve the= inconsistency stated in the previous section, this issue resolves itself= because we would have a proper username/userid in the request. I think it is needed to update RFC7635 anyhow (e.g. to support CWT tokens. , many erratas etc.) To work on an update may solve all of your issues. Just my 2 cents.. Misi Ps. I am pretty sure I am not as well informed and smart and precise etc., as the most people on this list, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 so take my opinions with care.. !!! From nobody Wed Dec 13 23:10:06 2017 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C34124D37 for ; Wed, 13 Dec 2017 23:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tng6V_LvlELP for ; Wed, 13 Dec 2017 23:10:01 -0800 (PST) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [63.128.21.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC789124BE8 for ; Wed, 13 Dec 2017 23:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=W9cyj8mP30EvFeyIHkVhsIPym0Hqs8T6rZBiTstZn7k=; b=sqFZ5N00siVTlpGAFe56pxHNFxF6wrf0h/ZyHrX11rr4NMwNmCLB45UCH7SzwigQm/jvDIwpsXi/m8JkDZj0zD9szN6d+xG3poQ8P3M2LCLwJmupaGlITC91E/yI1sUKytbpKtFvGS1dpaXHjIwhICTIgCzVuuDdhCIU7+T3yDg= Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0017.outbound.protection.outlook.com [216.32.181.17]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-74-HNK0Z0MsMz6w0H7-LESCOQ-1; Thu, 14 Dec 2017 02:09:57 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Thu, 14 Dec 2017 07:09:54 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([fe80::7559:6508:9a18:437]) by SN2PR03MB2350.namprd03.prod.outlook.com ([fe80::7559:6508:9a18:437%18]) with mapi id 15.20.0302.014; Thu, 14 Dec 2017 07:09:54 +0000 From: "Asveren, Tolga" To: Marc Petit-Huguenin , "tram@ietf.org" Thread-Topic: [tram] WGLC comments for draft-ietf-tram-stunbis-12 Thread-Index: AQHTWhBzPIfWvpa9i0CkORuH7DYC6qNCnpGA Date: Thu, 14 Dec 2017 07:09:54 +0000 Message-ID: References: <3a280b4c-f780-4f96-d47a-08ea764f514b@acm.org> In-Reply-To: <3a280b4c-f780-4f96-d47a-08ea764f514b@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 20:vpfFmm8UDzJbPwRt/OX1Y7AkmWTGyGkWrju7lKeGwlLXuewxwCB1xlMOLlEc7j42Vzi6nUfLFnfkOc5AQ+f2BvVI/ucZ5SHZHmzCfbN76fsDR3w/svuhI8L009LT+cybeBPNoal0uoF8KEes4O0gOa0rfIqjH0lLjLTB/jxtoi4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b14c6307-f89f-4f67-e671-08d542c1ad28 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:SN2PR03MB2352; x-ms-traffictypediagnostic: SN2PR03MB2352: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(128460861657000)(81160342030619); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231023)(3002001)(6041248)(20161123555025)(20161123560025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN2PR03MB2352; x-forefront-prvs: 05214FD68E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39850400004)(346002)(366004)(252514010)(51914003)(199004)(189003)(24454002)(13464003)(14454004)(8936002)(55016002)(9686003)(6436002)(106356001)(110136005)(7696005)(25786009)(2900100001)(316002)(105586002)(76176011)(966005)(59450400001)(6506007)(53546011)(45080400002)(478600001)(68736007)(229853002)(6306002)(86362001)(33656002)(551934003)(8676002)(305945005)(66066001)(81156014)(81166006)(5250100002)(2501003)(6116002)(7736002)(230783001)(74316002)(2906002)(2950100002)(6246003)(3280700002)(53936002)(3660700001)(5660300001)(102836003)(99286004)(3846002)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-Network-Message-Id: b14c6307-f89f-4f67-e671-08d542c1ad28 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 07:09:54.3428 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 X-MC-Unique: HNK0Z0MsMz6w0H7-LESCOQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tram] WGLC comments for draft-ietf-tram-stunbis-12 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is 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, 14 Dec 2017 07:10:04 -0000 SGkgTWFyYywNCg0KSSBhbSBmaW5lIHdpdGggbm90IG1vZGlmeWluZyB0aGUgZG9jdW1lbnQgZm9y IGFueSBpdGVtIHlvdSBtYXJrZWQgYXMgIk5ldyB3b3JrIiBhbHRob3VnaCBJIHdvdWxkIHByZWZl ciB0aGVtIHRvIGJlIGFkZHJlc3NlZCBhcyBhdCBsZWFzdCBzb21lIG9mIHRoZW0gYXJlIHJlYWxs eSBjb25mdXNpbmcsIGUuZy4gd2hhdCBhICJiYXNpYyBzZXJ2ZXIiIGlzLg0KDQpSZWdhcmRpbmcg dmlpLSBiZWxvdzsNClRoZSBjaGFuZ2UgSSBhbSBzdWdnZXN0aW5nIGlzOg0KQWx0ZXJuYXRpdmVs eSwgYSBjbGllbnQgTUFZIGJlIGNvbmZpZ3VyZWQgd2l0aCBhIHNldCBvZiBkb21haW5zIG9yIElQ IGFkZHJlc3NlcyB0aGF0IGFyZSB0cnVzdGVkOw0KPT0+DQpBbHRlcm5hdGl2ZWx5LCBhIGNsaWVu dCBNQVkgYmUgY29uZmlndXJlZCB3aXRoIGEgc2V0IG9mIElQIGFkZHJlc3NlcyB0aGF0IGFyZSB0 cnVzdGVkOw0KDQpUaGUgcmVhc29uIGJlaW5nIHRoYXQgUkZDNjEyNSBhbHJlYWR5IGNvdmVyaW5n ICJ0cnVzdGVkIHNldCBvZiBkb21haW5zIi4gSSBhbSBub3QgZmVlbGluZyBzdHJvbmdseSBhYm91 dCB0aGlzIGNoYW5nZSB0aHJvdWdoOyB5b3VyIGNhbGwuDQoNCg0KQ291bGQgeW91IHN1Ym1pdCBh IG5ldyB2ZXJzaW9uLCBhdCBsZWFzdCB3aXRoIHRoZSBjaGFuZ2VzIHlvdSBhZ3JlZWQgYmVsb3cs IHNvIHRoYXQgd2UgY2FuIGdldCBjbG9zZXIgdG8gY29uY2x1ZGluZyB0aGUgV0dMQz8NCg0KVGhh bmtzLA0KVG9sZ2ENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHRyYW0gW21h aWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJjIFBldGl0LUh1Z3Vl bmluDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDEwLCAyMDE3IDU6NDEgQU0NClRvOiBBc3ZlcmVu LCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPjsgdHJhbUBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFt0cmFtXSBXR0xDIGNvbW1lbnRzIGZvciBkcmFmdC1pZXRmLXRyYW0tc3R1bmJpcy0xMg0K DQpIaSBUb2xnYSwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3Lg0KDQpNeSBtYWluIGNvbmNlcm4g YWJvdXQgbW9zdCBvZiB5b3VyIGNvbW1lbnRzIGlzIHRoYXQgdGhleSBhcmUgbm90IHJlbGV2YW50 IHRvIC1zdHVuYmlzLCBidXQgdG8gUkZDIDUzODksIGkuZS4gdGhhdCB0aGV5IHdhbnQgdG8gcmV2 aXNpdCB0ZXh0IHRoYXQgd2FzIGFscmVhZHkgYXBwcm92ZWQgYnkgdGhlIElFU0cgYmFjayB3aGVu IFJGQyA1Mzg5IHdhcyBwdWJsaXNoZWQuDQoNCk5vdyB0aGVyZSBpcyBub3RoaW5nIHdyb25nIGFi b3V0IHRoaXMsIGFzIHRoZSBwdXJwb3NlIG9mIHN0dW5iaXMgd2FzIHRvIHJldmlzaXQgdGhlIHBh cnRzIG9mIFJGQyA1Mzg5IHRoYXQgbmVlZGVkIGFuIHVwZGF0ZS4gIEJ1dCB3aGF0IHlvdSBhcmUg YXNraW5nIGlzIGV4cGFuZGluZyB0aGUgc2NvcGUgb2Ygc3R1bmJpcywgd2hpY2ggbWVhbnMgYW5v dGhlciByb3VuZCBvZiByZXZpZXdzIGZvciB0aGUgV29ya2luZyBHcm91cC4gIFRoZSBXRyBhY3Rp dml0eSBpcyB2ZXJ5IGxvdywgc28gSSB3b3VsZCBsaWtlIGZpcnN0IHRvIGFzayB0aGUgV0cgaWYg dGhleSB3YW50IHVzIHRvIHRha2Ugb24gdGhlc2UgbW9kaWZpY2F0aW9ucy4NCg0KSSBhbm5vdGF0 ZWQgdGhlIGNvbW1lbnRzIGJlbG93IHdpdGggIk5ldyB3b3JrIiB0byBzaWduYWwgd2hlbiB0aGlz IGlzIHRoZSBjYXNlLiAgSSdsbCBwdWJsaXNoIGEgbmV3IHZlcnNpb24gb2Ygc3R1bmJpcyBhcyBz b29uIHRoZSBzdWJtaXNzaW9uIHRvb2wgcmVvcGVuLg0KDQpPbiAwOS8zMC8yMDE3IDA1OjMxIEFN LCBBc3ZlcmVuLCBUb2xnYSB3cm90ZToNCj4gSGVyZSBhcmUgbXkgY29tbWVudHMgZm9yIGRyYWZ0 LWlldGYtdHJhbS1zdHVuYmlzLTEyIFdHTEM6DQo+IChJdCBjb3VsZCBiZSBlYXNpZXIgZm9yIHRy YWNraW5nIHB1cnBvc2VzIGlmIGF1dGhvcnMgcmVwbHkgaW4gc2VwYXJhdGUgDQo+IHRocmVhZHMv YnVuZGxlIHJlbGV2YW50IG9uZXMgaW50byBzZXBhcmF0ZSB0aHJlYWRzKQ0KPiBpLSBQbGVhc2Ug cmVmZXJlbmNlIGxhdGVzdCB2ZXJzaW9uIG9mIFtJLUQuaWV0Zi1pY2UtcmZjNTI0NWJpc10sIGFu ZCANCj4gaW5kaWNhdGUgdGhhdCBpdCBzaG91bGQgYmUgdXBkYXRlZCBieSBSRkMgRWRpdG9yIHdp dGggdGhlIGxhdGVzdCANCj4gdmVyc2lvbi9SRkMgbnVtYmVyIChpZg0KPiBwcmVzZW50KSBiZWZv cmUgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudA0KDQpEb25lLiAgTm90ZSB0aGF0IHRoaXMg aXMgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlLCBzbyBpdCBpcyBub3QgYmxvY2tpbmcgdGhlIGRv Y3VtZW50LiAgQWxzbyB0aGVyZSBpcyBubyBwbGFjZSB0byBzaWduYWwgdGhhdCB0byB0aGUgUkZD IEVkaXRvciwgYnkgdGhleSBrbm93IGhvdyB0byBkbyB0aGF0Lg0KDQo+IGlpLQ0KPiBTVFVOIGlz IGludGVuZGVkIHRvIGJlIHVzZWQgaW4gY29udGV4dCBvZiBvbmUgb3IgbW9yZSBOQVQgdHJhdmVy c2FsDQo+ICAgICBzb2x1dGlvbnMuICBUaGVzZSBzb2x1dGlvbnMgYXJlIGtub3duIGFzIFNUVU4g dXNhZ2VzLiAgRWFjaCB1c2FnZQ0KPiAgICAgZGVzY3JpYmVzIGhvdyBTVFVOIGlzIHV0aWxpemVk IHRvIGFjaGlldmUgdGhlIE5BVCB0cmF2ZXJzYWwgc29sdXRpb24uDQo+IEkgdGhpbmsgdGhlcmUg YXJlIHVzZSBjYXNlcyBmb3Igbm9uLU5BVCBlbnZpcm9ubWVudHMgYXMgd2VsbCwgZS5nLiANCj4g UkZDNTYyNiBrZWVwLWFsaXZlIGZvciBmbG93cyB3aXRob3V0IE5BVCB0byBkZXRlY3QgRWRnZSBQ cm94eSBjcmFzaC4gDQo+IE1heWJlIGFkZGluZyBhIHNlbnRlbmNlIGFsb25nIHRoZSBmb2xsb3dp bmcgbGluZXMgY291bGQgYmUgZ29vZDoNCj4g4oCcU1RVTiBtYXkgYWxzbyBiZSB1c2VkIGZvciBj YXNlcyB3aGVyZSBhIE5BVCBpcyBub3QgcHJlc2VudCwgZS5nLiwgdG8gDQo+IGRldGVjdCBjcmFz aCBvZiBhbiBFZGdlIFByb3h5IGJhc2VkIG9uIHByb2NlZHVyZXMgZGVmaW5lZCBpbiBSRkM1NjI2 IDxyZWZlcmVuY2UgUkZDNTYyNj4u4oCdDQoNCk5ldyB3b3JrLg0KDQo+IGlpaS0NCj4gQm90aCB0 eXBlcyBvZiB0cmFuc2FjdGlvbnMgaW5jbHVkZSBhIHRyYW5zYWN0aW9uIElELCB3aGljaA0KPiAg ICAgaXMgYSByYW5kb21seSBzZWxlY3RlZCA5Ni1iaXQgbnVtYmVyLg0KPiBJdCBtYXkgYmUgdXNl ZnVsIHRvIHByb3ZpZGUgc29tZSBndWlkYW5jZSBob3cgdGhpcyBjb3VsZCBiZSBtYWRlIA0KPiAo Y2xvc2UgdG8pIGdsb2JhbGx5IHVuaXF1ZT8NCg0KTmV3IHdvcmsuDQoNCj4gaXYtDQo+IFRoZSBz ZXJ2ZXIgYWxzbyB1c2VzDQo+ICAgICB0aGUgdHJhbnNhY3Rpb24gSUQgYXMgYSBrZXkgdG8gaWRl bnRpZnkgZWFjaCB0cmFuc2FjdGlvbiB1bmlxdWVseQ0KPiAgICAgYWNyb3NzIGFsbCBjbGllbnRz LiAgQXMgc3VjaCwgdGhlIHRyYW5zYWN0aW9uIElEIE1VU1QgYmUgdW5pZm9ybWx5DQo+ICAgICBh bmQgcmFuZG9tbHkgY2hvc2VuIGZyb20gdGhlIGludGVydmFsIDAgLi4gMioqOTYtMSwgYW5kIFNI T1VMRCBiZQ0KPiAgICAgY3J5cHRvZ3JhcGhpY2FsbHkgcmFuZG9tLg0KPiBUaGVyZSBzdGlsbCBp cyB0aGUgcG9zc2liaWxpdHkgb2YgYSBjbGFzaC4gV2hhdCBhcmUgdGhlIGltcGxpY2F0aW9ucyAN Cj4gaWYgdGhhdCBoYXBwZW5zPyBBIHNob3J0IGNsYXJpZmljYXRpb24gY291bGQgYmUgdXNlZnVs Lg0KDQpOZXcgd29yay4NCg0KPiB2LSBTdHJ1Y3R1cmFsbHksIGl0IHdvdWxkIGJlIGJldHRlciB0 byBzcGVjaWZ5IOKAnGJpbmRpbmfigJ0gYXMgYSDigJxtZXRob2TigJ0gDQo+IGluIGl0cyBvd24v c2VwYXJhdGUgc2VjdGlvbiByYXRoZXIgdGhhbiBpbiB0aGUgc2VjdGlvbnMgcGVydGFpbmluZyB0 byANCj4gZ2VuZXJhbCBtZXNzYWdlIHByb2Nlc3NpbmcuDQoNCk5ldyB3b3JrLg0KDQo+IHZpLQ0K PiBBYnNlbnQgb3RoZXIgbGltaXRzIHRvDQo+ICAgICB0aGUgcmF0ZSBvZiBuZXcgdHJhbnNhY3Rp b25zIChzdWNoIGFzIHRob3NlIHNwZWNpZmllZCBieSBJQ0UgZm9yDQo+ICAgICBjb25uZWN0aXZp dHkgY2hlY2tzIG9yIHdoZW4gU1RVTiBpcyBydW4gb3ZlciBUQ1ApLCBhIGNsaWVudCBTSE9VTEQN Cj4gICAgIGxpbWl0IGl0c2VsZiB0byB0ZW4gb3V0c3RhbmRpbmcgdHJhbnNhY3Rpb25zIHRvIHRo ZSBzYW1lIHNlcnZlci4NCj4gV2hhdCBpcyB0aGUganVzdGlmaWNhdGlvbiBmb3IgdGhpcz8NCg0K TmV3IHdvcmsuDQoNCj4gdmlpLQ0KPiBBbHRlcm5hdGl2ZWx5LCBhDQo+ICAgICBjbGllbnQgTUFZ IGJlIGNvbmZpZ3VyZWQgd2l0aCBhIHNldCBvZiBkb21haW5zIG9yIElQIGFkZHJlc3NlcyB0aGF0 DQo+ICAgICBhcmUgdHJ1c3RlZDsgaWYgYSBjZXJ0aWZpY2F0ZSBpcyByZWNlaXZlZCB0aGF0IGlk ZW50aWZpZXMgb25lIG9mDQo+ICAgICB0aG9zZSBkb21haW5zIG9yIElQIGFkZHJlc3NlcywgdGhl IGNsaWVudCBjb25zaWRlcnMgdGhlIGlkZW50aXR5IG9mDQo+ICAgICB0aGUgc2VydmVyIHRvIGJl IHZlcmlmaWVkLg0KPiBJc27igJl0IHRoaXMgYWxyZWFkeSBjb3ZlcmVkIGJ5IGZvbGxvd2luZyBm cm9tIFJGQzYxMjUgKGF0IGxlYXN0IHRoZSANCj4g4oCcZG9tYWlu4oCdKSAxLiAgVGhlIGNsaWVu dCBjb25zdHJ1Y3RzIGEgbGlzdCBvZiBhY2NlcHRhYmxlIHJlZmVyZW5jZSBpZGVudGlmaWVycw0K PiAgICAgICAgIGJhc2VkIG9uIHRoZSBzb3VyY2UgZG9tYWluIGFuZCwgb3B0aW9uYWxseSwgdGhl IHR5cGUgb2Ygc2VydmljZQ0KPiAgICAgICAgIHRvIHdoaWNoIHRoZSBjbGllbnQgaXMgY29ubmVj dGluZy4NCj4gLi4uDQo+IEFzIHByZXZpb3VzbHkgbWVudGlvbmVkLCB0aGlzIGRvY3VtZW50IHNw ZWNpZmllcyB0aGF0DQo+ICAgICAgICBhIFVSSS1JRCBhbHdheXMgY29udGFpbnMgYSAiaG9zdCIg Y29tcG9uZW50IChvciBpdHMgZXF1aXZhbGVudCkNCj4gICAgICAgIGNvbnRhaW5pbmcgYSAicmVn LW5hbWUiLiAgKE1hdGNoaW5nIG9ubHkgdGhlICJyZWctbmFtZSIgcnVsZSBmcm9tDQo+ICAgICAg ICBbX1VSSV8gPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MTI1Pl0gbGltaXRzIA0K PiB2ZXJpZmljYXRpb24gdG8gRE5TIGRvbWFpbiBuYW1lcywgdGhlcmVieQ0KPiAgICAgICAgZGlm ZmVyZW50aWF0aW5nIGEgVVJJLUlEIGZyb20gYSB1bmlmb3JtUmVzb3VyY2VJZGVudGlmaWVyIGVu dHJ5DQo+ICAgICAgICB0aGF0IGNvbnRhaW5zIGFuIElQIGFkZHJlc3Mgb3IgYSBtZXJlIGhvc3Qg bmFtZSwgb3IgdGhhdCBkb2VzIG5vdA0KPiAgICAgICAgY29udGFpbiBhICJob3N0IiBjb21wb25l bnQgYXQgYWxsLikgSXQgc2VlbXMgb25seSDigJxJUOKAnSBpcyANCj4gZXhjbHVkZWQuDQoNCldo YXQgbW9kaWZpY2F0aW9uIGFyZSB5b3Ugc3VnZ2VzdGluZz8NCg0KPiB2aWlpLQ0KPiBJdCBjaGVj a3MgdGhhdCB0aGUgZmlyc3QgdHdvDQo+ICAgICBiaXRzIGFyZSAwLCB0aGF0IHRoZSBtYWdpYyBj b29raWUgZmllbGQgaGFzIHRoZSBjb3JyZWN0IHZhbHVlLCB0aGF0DQo+ICAgICB0aGUgbWVzc2Fn ZSBsZW5ndGggaXMgc2Vuc2libGUsIGFuZCB0aGF0IHRoZSBtZXRob2QgdmFsdWUgaXMgYQ0KPiAg ICAgc3VwcG9ydGVkIG1ldGhvZC4NCj4gV2hhdCBkb2VzIOKAnHNlbnNpYmxl4oCdIG1lYW4gaW4g dGhpcyBjb250ZXh0Pw0KDQpOZXcgd29yay4NCg0KPiBpeC0NCj4gSWYgdGhlIHN1Y2Nlc3MgcmVz cG9uc2UgY29udGFpbnMgdW5rbm93biBjb21wcmVoZW5zaW9uLXJlcXVpcmVkDQo+ICAgICBhdHRy aWJ1dGVzLCB0aGUgcmVzcG9uc2UgaXMgZGlzY2FyZGVkIGFuZCB0aGUgdHJhbnNhY3Rpb24gaXMN Cj4gICAgIGNvbnNpZGVyZWQgdG8gaGF2ZSBmYWlsZWQuDQo+IFdoZW4gd291bGQgc3VjaCBhIHJl c3BvbnNlIGJlIGdlbmVyYXRlZD8NCg0KTmV3IHdvcmsuDQoNCj4geC0NCj4gSWYgdGhlIGVycm9y IGNvZGUgaXMgNTAwIHRocm91Z2ggNTk5LCB0aGUgY2xpZW50IE1BWSByZXNlbmQgdGhlDQo+ICAg ICAgICByZXF1ZXN0OyBjbGllbnRzIHRoYXQgZG8gc28gTVVTVCBsaW1pdCB0aGUgbnVtYmVyIG9m IHRpbWVzIHRoZXkgZG8NCj4gICAgICAgIHRoaXMuDQo+IEl0IG1heSBiZSB1c2VmdWwgdG8gcHJv dmlkZSBzb21lIGd1aWRhbmNlL3JlY29tbWVuZGVkIHZhbHVlcz8NCg0KTmV3IHdvcmsuDQoNCj4g eGktDQo+IElmIHRoZSA8aG9zdD4gcGFydCBjb250YWlucyBhbiBJUCBhZGRyZXNzLCB0aGVuIHRo aXMgSVAgYWRkcmVzcyBpcw0KPiAgICAgdXNlZCBkaXJlY3RseSB0byBjb250YWN0IHRoZSBzZXJ2 ZXIuICBBICJzdHVucyIgVVJJIGNvbnRhaW5pbmcgYW4gSVANCj4gICAgIGFkZHJlc3MgTVVTVCBi ZSByZWplY3RlZCwgdW5sZXNzIHRoZSBkb21haW4gbmFtZSBpcyBwcm92aWRlZCBieSB0aGUNCj4g ICAgIHNhbWUgbWVjaGFuaXNtIHRoYXQgcHJvdmlkZWQgdGhlIFNUVU4gVVJJLCBhbmQgdGhhdCBk b21haW4gbmFtZSBjYW4NCj4gICAgIGJlIHBhc3NlZCB0byB0aGUgdmVyaWZpY2F0aW9uIGNvZGUu DQo+IElzbuKAmXQgdGhpcyBpbiBjb25mbGljdCB3aXRoIHRoZSBzdGF0ZW1lbnQgQWx0ZXJuYXRp dmVseSwgYQ0KPiAgICAgY2xpZW50IE1BWSBiZSBjb25maWd1cmVkIHdpdGggYSBzZXQgb2YgZG9t YWlucyBvciBJUCBhZGRyZXNzZXMgdGhhdA0KPiAgICAgYXJlIHRydXN0ZWQ7IGlmIGEgY2VydGlm aWNhdGUgaXMgcmVjZWl2ZWQgdGhhdCBpZGVudGlmaWVzIG9uZSBvZg0KPiAgICAgdGhvc2UgZG9t YWlucyBvciBJUCBhZGRyZXNzZXMsIHRoZSBjbGllbnQgY29uc2lkZXJzIHRoZSBpZGVudGl0eSBv Zg0KPiAgICAgdGhlIHNlcnZlciB0byBiZSB2ZXJpZmllZC4NClRoZSBmaXJzdCBzZW50ZW5jZSBj b3VsZCBzdGF0ZSB0aGF0IGl0IGlzIG9ubHkgZm9yICJzdHVuIiBVUkkuICBJIG1vZGlmaWVkIHRo YXQuDQoNCkkgZG8gbm90IHRoaW5rIHRoYXQgdGhlcmUgaXMgYSBjb25mbGljdC4gIFRoZSBmb3Jt ZXIgc3RhdGVzIHRoYXQgaWYgdGhlIFNUVU4gVVJJIHdhcyByZWNlaXZlZCBmcm9tIGFuIEhUVFBT IHJlcXVlc3QsIHRoZW4gdGhlIElQIGFkZHJlc3MgY2FuIGJlIHRydXN0ZWQuICBUaGUgbGF0dGVy IHN0YXRlcyB0aGF0IHRoZXJlIGNhbiBiZSBhIGNvbmZpZ3VyZWQgbGlzdCBvZiBJUCBhZGRyZXNz ZXMgdGhhdCBhcmUgdHJ1c3RlZC4NCg0KTm93IEkgYWdyZWUgdGhhdCBmb3IgdGhlIGZvcm1lciwg dGhlIHRleHQgaXMgbm90IHZlcnkgZ29vZC4gIEkgZml4ZWQgdGhhdC4NCg0KDQo+IHhpaS0gV291 bGQgaXQgYmUgdXNlZnVsIHRvIGRlZmluZSBhIERIQ1Agb3B0aW9uIGZvciBTVFVOIFNlcnZlcnMg DQo+IHNpbWlsYXIgdG8gU0lQIGluIFJGQzMzNjE/DQoNCk5ldyB3b3JrLg0KDQo+IHhpaWktDQo+ IElmIHRoZSByZXF1ZXN0IHdhcyBzZW50IG92ZXIgYW4gdW5yZWxpYWJsZSB0cmFuc3BvcnQsIHRo ZSByZXNwb25zZQ0KPiAgICAgTVVTVCBiZSBkaXNjYXJkZWQsIGFzIGlmIGl0IHdhcyBuZXZlciBy ZWNlaXZlZC4gIFRoaXMgbWVhbnMgdGhhdA0KPiAgICAgcmV0cmFuc21pdHMsIGlmIGFwcGxpY2Fi bGUsIHdpbGwgY29udGludWUuICBJZiBhbGwgdGhlIHJlcG9uc2VzDQo+ICAgICByZWNlaXZlZCBh cmUgZGlzY2FyZGVkIHRoZW4gaW5zdGVhZCBvZiBzaWduYWxsaW5nIGEgdGltZW91dCBhZnRlcg0K PiAgICAgZW5kaW5nIHRoZSB0cmFuc2FjdGlvbiB0aGUgbGF5ZXIgTVVTVCBzaWduYWwgdGhhdCBh biBhdHRhY2sgdG9vaw0KPiAgICAgcGxhY2UuDQo+IFdoeSBzaWduYWwgYXR0YWNrIG9ubHkgaWYg YWxsIHJldHJhbnNtaXNzaW9ucyBhcmUgcHJvYmxlbWF0aWM/IA0KPiBTaG91bGRu4oCZdCB0aGlz IGhhcHBlbiBldmVuIGlmIG9ubHkgb25lIGlzIGRpc2NhcmRlZD8NCg0KTm8sIG9uZSBwYWNrZXQg Y2FuIGdldCBkaXNjYXJkZWQgYmVjYXVzZSBvZiBhIHRyYW5zbWlzc2lvbiBlcnJvciB0aGF0IHdh cyBub3QgZGV0ZWN0ZWQgYnkgYSBjaGVja3N1bS4gIElmIGFsbCB3ZXJlIG1vZGlmaWVkLCB0aGVu IGl0IGlzIGFuIGF0dGFjay4NCg0KPiB4aXYtIOKAnEJhc2ljIFNlcnZlcuKAnSwgd2hhdCBkb2Vz IGl0IHJlYWxseSByZWZlciB0bz8gV2hhdCBhcmUgDQo+IGFsdGVybmF0aXZlcz8gV2FzIHRoZSBn b2FsIGhlcmUgdG8gZGVzY3JpYmUgYmVoYXZpb3Igb2YgYSDigJxTVFVOIA0KPiBCaW5kaW5nIFNl cnZlcuKAnT8gSWYgc28sIHNob3VsZG7igJl0IGl0IGJlIHJlbmFtZWQgYXMgc3VjaCByYXRoZXIg dGhhbiBhcyANCj4g4oCcQmFzaWMgU2VydmVy4oCdPyBPciBhcmUgdGhlcmUgcHJvY2VkdXJlcyB3 aGljaCBwZXJ0YWluIHRvIOKAnEJhc2ljIFNlcnZlcnMgaW4gZ2VuZXJhbOKAnSAoYWdhaW4gd2hh dGV2ZXIgYSBCYXNpYyBTZXJ2ZXIgaXMpPw0KPiBJcyBkZWZpbmluZyBiZWhhdmlvciBmb3IgYSDi gJxiYWNrd2FyZCBjb21wYXRpYmxlIHNlcnZlcuKAnSB0aGUgcmVhbCBnb2FsIGhlcmU/DQoNCk5l dyB3b3JrLg0KDQo+IHh2LQ0KPiAxMC4gIEFMVEVSTkFURS1TRVJWRVIgTWVjaGFuaXNtDQo+IFdo YXQgaXMgcmFpc29uIGTigJlldHJlIGZvciBkZWZpbmluZyBzdWNoIGEgbWVjaGFuaXNtPyBJcyB0 aGVyZSBhbiANCj4gYWxyZWFkeSBrbm93biB1c2UgY2FzZT8NCg0KTmV3IHdvcmsuDQoNCj4geHZp LQ0KPiBJdCBTSE9VTEQgTk9UDQo+ICAgICB1dGlsaXplIHRoZSBzaG9ydC10ZXJtIG9yIGxvbmct dGVybSBjcmVkZW50aWFsIG1lY2hhbmlzbS4gIFRoaXMgaXMNCj4gICAgIGJlY2F1c2UgdGhlIHdv cmsgaW52b2x2ZWQgaW4gYXV0aGVudGljYXRpbmcgdGhlIHJlcXVlc3QgaXMgbW9yZSB0aGFuDQo+ ICAgICB0aGUgd29yayBpbiBzaW1wbHkgcHJvY2Vzc2luZyBpdC4gIEl0IFNIT1VMRCBOT1QgdXRp bGl6ZSB0aGUNCj4gICAgIEFMVEVSTkFURS1TRVJWRVIgbWVjaGFuaXNtIGZvciB0aGUgc2FtZSBy ZWFzb24uDQo+IElzbuKAmXQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB0aGUgcmVhbCByZWFzb24g Zm9yIG5vdCB1c2luZyBjcmVkZW50aWFscyANCj4gYW5kIEFMVEVSVE5BVEUtU0VSVkVSPyBPdGhl cndpc2UgdGhlcmUgY291bGQgYmUgcmVhc29ucyBvdGhlciB0aGFuIA0KPiBwcm9jZXNzaW5nIGNv c3Qgd2hpY2ggY291bGQgbWFrZSB0aGVtIGFwcGxpY2FibGUsIGUuZy4gZm9yIA0KPiBjcmVkZW50 aWFscywgbm90IHdhbnRpbmcgdG8gc2VydmUgaWxsZWdpdGltYXRlIHVzZXJzLCBhbmQgZm9yIEFM VEVSTkFURS1TRVJWRVIgZ2V0dGluZyByZWFkeSBmb3IgYW4gdXBncmFkZS4NCg0KTmV3IHdvcmsu DQoNCj4geHZpaS0gRnJvbSBpZG5pdHM6DQo+ICoqIERvd25yZWY6IE5vcm1hdGl2ZSByZWZlcmVu Y2UgdG8gYW4gSW5mb3JtYXRpb25hbCBSRkM6IFJGQyAxMzIxDQoNClNhbWUgdGhhbiBSRkMgNTM4 OS4NCg0KPiAgICAqKiBEb3ducmVmOiBOb3JtYXRpdmUgcmVmZXJlbmNlIHRvIGFuIEluZm9ybWF0 aW9uYWwgUkZDOiBSRkMgMjEwNA0KDQpTYW1lIHRoYW4gUkZDIDUzODkuDQoNCj4gICAgKiogT2Jz b2xldGUgbm9ybWF0aXZlIHJlZmVyZW5jZTogUkZDIDI0NjANCg0KVXBkYXRlZC4NCg0KPiAgICAq KiBPYnNvbGV0ZSBub3JtYXRpdmUgcmVmZXJlbmNlOiBSRkMgMjYxNyAoT2Jzb2xldGVkIGJ5IFJG QyA3MjM1LCBSRkMgNzYxNSwNCj4gICAgICAgUkZDIDc2MTYsIFJGQyA3NjE3KQ0KDQpVcGRhdGVk Lg0KDQo+ICAgID09IE91dGRhdGVkIHJlZmVyZW5jZTogQSBsYXRlciB2ZXJzaW9uICgtMTIpIGV4 aXN0cyBvZg0KPiAgICAgICBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLTAxDQoNClVwZGF0ZWQu DQoNCj4gICAgLS0gT2Jzb2xldGUgaW5mb3JtYXRpb25hbCByZWZlcmVuY2UgKGlzIHRoaXMgaW50 ZW50aW9uYWw/KTogUkZDIDI2MTYNCj4gICAgICAgKE9ic29sZXRlZCBieSBSRkMgNzIzMCwgUkZD IDcyMzEsIFJGQyA3MjMyLCBSRkMgNzIzMywgUkZDIDcyMzQsIA0KPiBSRkMgNzIzNSkNCg0KVXBk YXRlZC4NCg0KPiAgICAtLSBPYnNvbGV0ZSBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZSAoaXMgdGhp cyBpbnRlbnRpb25hbD8pOiBSRkMgMzQ4OQ0KPiAgICAgICAoT2Jzb2xldGVkIGJ5IFJGQyA1Mzg5 KQ0KDQpJbnRlbnNpb25hbC4NCg0KPiAgICAtLSBPYnNvbGV0ZSBpbmZvcm1hdGlvbmFsIHJlZmVy ZW5jZSAoaXMgdGhpcyBpbnRlbnRpb25hbD8pOiBSRkMgDQo+IDUyMjYNCg0KVXBkYXRlZC4NCg0K LS0NCk1hcmMgUGV0aXQtSHVndWVuaW4NCkVtYWlsOiBtYXJjQHBldGl0LWh1Z3VlbmluLm9yZw0K QmxvZzogaHR0cHM6Ly9tYXJjLnBldGl0LWh1Z3VlbmluLm9yZw0KUHJvZmlsZTogaHR0cHM6Ly93 d3cubGlua2VkaW4uY29tL2luL3BldGl0aHVnDQoNCg== From nobody Fri Dec 15 07:18:56 2017 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C811201F2 for ; Fri, 15 Dec 2017 07:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 2ST0ltlYpkD4 for ; Fri, 15 Dec 2017 07:18:51 -0800 (PST) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B70A128B93 for ; Fri, 15 Dec 2017 07:18:51 -0800 (PST) Received: from [IPv6:2601:648:8301:730f:585:86dd:b6f3:67bd] (unknown [IPv6:2601:648:8301:730f:585:86dd:b6f3:67bd]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id BC203AE814; Fri, 15 Dec 2017 16:18:47 +0100 (CET) To: "Asveren, Tolga" , "tram@ietf.org" References: <3a280b4c-f780-4f96-d47a-08ea764f514b@acm.org> From: Marc Petit-Huguenin Message-ID: Date: Fri, 15 Dec 2017 07:18:41 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JvQHSioklbAlNrLkdf4DNiHHsu4jXGAO7" Archived-At: Subject: Re: [tram] WGLC comments for draft-ietf-tram-stunbis-12 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is 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, 15 Dec 2017 15:18:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JvQHSioklbAlNrLkdf4DNiHHsu4jXGAO7 Content-Type: multipart/mixed; boundary="O4QkwCwETOK4gfO7kmCvjdAegLe3AfGQA"; protected-headers="v1" From: Marc Petit-Huguenin To: "Asveren, Tolga" , "tram@ietf.org" Message-ID: Subject: Re: [tram] WGLC comments for draft-ietf-tram-stunbis-12 References: <3a280b4c-f780-4f96-d47a-08ea764f514b@acm.org> In-Reply-To: --O4QkwCwETOK4gfO7kmCvjdAegLe3AfGQA Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12/13/2017 11:09 PM, Asveren, Tolga wrote: > Hi Marc, >=20 > I am fine with not modifying the document for any item you marked as "N= ew work" although I would prefer them to be addressed as at least some of= them are really confusing, e.g. what a "basic server" is. All right, I replaced the first paragraph with this: "This section defines the behavior of a basic, stand-alone STUN server. Historically Classic STUN [RFC3489] only defined the behavior of a server that was providing clients with server reflexive transport addresses by receiving and replying to STUN Binding requests. [RFC5389] redefined the protocol as an extensible framework and the server functionality became the sole STUN Usage defined in that document. This STUN Usage is also known as Basic STUN Server." >=20 > Regarding vii- below; > The change I am suggesting is: > Alternatively, a client MAY be configured with a set of domains or IP a= ddresses that are trusted; > =3D=3D> > Alternatively, a client MAY be configured with a set of IP addresses th= at are trusted; >=20 > The reason being that RFC6125 already covering "trusted set of domains"= =2E I am not feeling strongly about this change through; your call. Done. >=20 >=20 > Could you submit a new version, at least with the changes you agreed be= low, so that we can get closer to concluding the WGLC? I have a call scheduled with my co-author Monday afternoon to do some cle= anup on the text, so I'll publish the new version after that. Thanks. >=20 > Thanks, > Tolga >=20 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Marc Petit-Hugue= nin > Sent: Friday, November 10, 2017 5:41 AM > To: Asveren, Tolga ; tram@ietf.org > Subject: Re: [tram] WGLC comments for draft-ietf-tram-stunbis-12 >=20 > Hi Tolga, >=20 > Thanks for the review. >=20 > My main concern about most of your comments is that they are not releva= nt to -stunbis, but to RFC 5389, i.e. that they want to revisit text that= was already approved by the IESG back when RFC 5389 was published. >=20 > Now there is nothing wrong about this, as the purpose of stunbis was to= revisit the parts of RFC 5389 that needed an update. But what you are a= sking is expanding the scope of stunbis, which means another round of rev= iews for the Working Group. The WG activity is very low, so I would like= first to ask the WG if they want us to take on these modifications. >=20 > I annotated the comments below with "New work" to signal when this is t= he case. I'll publish a new version of stunbis as soon the submission to= ol reopen. >=20 > On 09/30/2017 05:31 AM, Asveren, Tolga wrote: >> Here are my comments for draft-ietf-tram-stunbis-12 WGLC: >> (It could be easier for tracking purposes if authors reply in separate= =20 >> threads/bundle relevant ones into separate threads) >> i- Please reference latest version of [I-D.ietf-ice-rfc5245bis], and=20 >> indicate that it should be updated by RFC Editor with the latest=20 >> version/RFC number (if >> present) before publication of this document >=20 > Done. Note that this is an informative reference, so it is not blockin= g the document. Also there is no place to signal that to the RFC Editor,= by they know how to do that. >=20 >> ii- >> STUN is intended to be used in context of one or more NAT traversal >> solutions. These solutions are known as STUN usages. Each usage >> describes how STUN is utilized to achieve the NAT traversal soluti= on. >> I think there are use cases for non-NAT environments as well, e.g.=20 >> RFC5626 keep-alive for flows without NAT to detect Edge Proxy crash.=20 >> Maybe adding a sentence along the following lines could be good: >> =E2=80=9CSTUN may also be used for cases where a NAT is not present, e= =2Eg., to=20 >> detect crash of an Edge Proxy based on procedures defined in RFC5626 <= reference RFC5626>.=E2=80=9D >=20 > New work. >=20 >> iii- >> Both types of transactions include a transaction ID, which >> is a randomly selected 96-bit number. >> It may be useful to provide some guidance how this could be made=20 >> (close to) globally unique? >=20 > New work. >=20 >> iv- >> The server also uses >> the transaction ID as a key to identify each transaction uniquely >> across all clients. As such, the transaction ID MUST be uniformly= >> and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be >> cryptographically random. >> There still is the possibility of a clash. What are the implications=20 >> if that happens? A short clarification could be useful. >=20 > New work. >=20 >> v- Structurally, it would be better to specify =E2=80=9Cbinding=E2=80=9D= as a =E2=80=9Cmethod=E2=80=9D=20 >> in its own/separate section rather than in the sections pertaining to = >> general message processing. >=20 > New work. >=20 >> vi- >> Absent other limits to >> the rate of new transactions (such as those specified by ICE for >> connectivity checks or when STUN is run over TCP), a client SHOULD= >> limit itself to ten outstanding transactions to the same server. >> What is the justification for this? >=20 > New work. >=20 >> vii- >> Alternatively, a >> client MAY be configured with a set of domains or IP addresses tha= t >> are trusted; if a certificate is received that identifies one of >> those domains or IP addresses, the client considers the identity o= f >> the server to be verified. >> Isn=E2=80=99t this already covered by following from RFC6125 (at least= the=20 >> =E2=80=9Cdomain=E2=80=9D) 1. The client constructs a list of acceptab= le reference identifiers >> based on the source domain and, optionally, the type of servic= e >> to which the client is connecting. >> ... >> As previously mentioned, this document specifies that >> a URI-ID always contains a "host" component (or its equivalent)= >> containing a "reg-name". (Matching only the "reg-name" rule fr= om >> [_URI_ ] limits=20 >> verification to DNS domain names, thereby >> differentiating a URI-ID from a uniformResourceIdentifier entry= >> that contains an IP address or a mere host name, or that does n= ot >> contain a "host" component at all.) It seems only =E2=80=9CIP=E2= =80=9D is=20 >> excluded. >=20 > What modification are you suggesting? >=20 >> viii- >> It checks that the first two >> bits are 0, that the magic cookie field has the correct value, tha= t >> the message length is sensible, and that the method value is a >> supported method. >> What does =E2=80=9Csensible=E2=80=9D mean in this context? >=20 > New work. >=20 >> ix- >> If the success response contains unknown comprehension-required >> attributes, the response is discarded and the transaction is >> considered to have failed. >> When would such a response be generated? >=20 > New work. >=20 >> x- >> If the error code is 500 through 599, the client MAY resend the >> request; clients that do so MUST limit the number of times they= do >> this. >> It may be useful to provide some guidance/recommended values? >=20 > New work. >=20 >> xi- >> If the part contains an IP address, then this IP address is >> used directly to contact the server. A "stuns" URI containing an = IP >> address MUST be rejected, unless the domain name is provided by th= e >> same mechanism that provided the STUN URI, and that domain name ca= n >> be passed to the verification code. >> Isn=E2=80=99t this in conflict with the statement Alternatively, a >> client MAY be configured with a set of domains or IP addresses tha= t >> are trusted; if a certificate is received that identifies one of >> those domains or IP addresses, the client considers the identity o= f >> the server to be verified. > The first sentence could state that it is only for "stun" URI. I modif= ied that. >=20 > I do not think that there is a conflict. The former states that if the= STUN URI was received from an HTTPS request, then the IP address can be = trusted. The latter states that there can be a configured list of IP add= resses that are trusted. >=20 > Now I agree that for the former, the text is not very good. I fixed th= at. >=20 >=20 >> xii- Would it be useful to define a DHCP option for STUN Servers=20 >> similar to SIP in RFC3361? >=20 > New work. >=20 >> xiii- >> If the request was sent over an unreliable transport, the response >> MUST be discarded, as if it was never received. This means that >> retransmits, if applicable, will continue. If all the reponses >> received are discarded then instead of signalling a timeout after >> ending the transaction the layer MUST signal that an attack took >> place. >> Why signal attack only if all retransmissions are problematic?=20 >> Shouldn=E2=80=99t this happen even if only one is discarded? >=20 > No, one packet can get discarded because of a transmission error that w= as not detected by a checksum. If all were modified, then it is an attac= k. >=20 >> xiv- =E2=80=9CBasic Server=E2=80=9D, what does it really refer to? Wha= t are=20 >> alternatives? Was the goal here to describe behavior of a =E2=80=9CSTU= N=20 >> Binding Server=E2=80=9D? If so, shouldn=E2=80=99t it be renamed as suc= h rather than as=20 >> =E2=80=9CBasic Server=E2=80=9D? Or are there procedures which pertain = to =E2=80=9CBasic Servers in general=E2=80=9D (again whatever a Basic Ser= ver is)? >> Is defining behavior for a =E2=80=9Cbackward compatible server=E2=80=9D= the real goal here? >=20 > New work. >=20 >> xv- >> 10. ALTERNATE-SERVER Mechanism >> What is raison d=E2=80=99etre for defining such a mechanism? Is there = an=20 >> already known use case? >=20 > New work. >=20 >> xvi- >> It SHOULD NOT >> utilize the short-term or long-term credential mechanism. This is= >> because the work involved in authenticating the request is more th= an >> the work in simply processing it. It SHOULD NOT utilize the >> ALTERNATE-SERVER mechanism for the same reason. >> Isn=E2=80=99t backward compatibility the real reason for not using cre= dentials=20 >> and ALTERTNATE-SERVER? Otherwise there could be reasons other than=20 >> processing cost which could make them applicable, e.g. for=20 >> credentials, not wanting to serve illegitimate users, and for ALTERNAT= E-SERVER getting ready for an upgrade. >=20 > New work. >=20 >> xvii- From idnits: >> ** Downref: Normative reference to an Informational RFC: RFC 1321 >=20 > Same than RFC 5389. >=20 >> ** Downref: Normative reference to an Informational RFC: RFC 2104 >=20 > Same than RFC 5389. >=20 >> ** Obsolete normative reference: RFC 2460 >=20 > Updated. >=20 >> ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, R= FC 7615, >> RFC 7616, RFC 7617) >=20 > Updated. >=20 >> =3D=3D Outdated reference: A later version (-12) exists of >> draft-ietf-ice-rfc5245bis-01 >=20 > Updated. >=20 >> -- Obsolete informational reference (is this intentional?): RFC 261= 6 >> (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, = >> RFC 7235) >=20 > Updated. >=20 >> -- Obsolete informational reference (is this intentional?): RFC 348= 9 >> (Obsoleted by RFC 5389) >=20 > Intensional. >=20 >> -- Obsolete informational reference (is this intentional?): RFC=20 >> 5226 >=20 > Updated. >=20 > -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: https://marc.petit-huguenin.org > Profile: https://www.linkedin.com/in/petithug >=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --O4QkwCwETOK4gfO7kmCvjdAegLe3AfGQA-- --JvQHSioklbAlNrLkdf4DNiHHsu4jXGAO7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAloz59EACgkQKcRFldZq fsTYug/9Er51dqKnxzd+HpWU7Ex8202C5hPKRzNlv/+Syn6Kil969yzNR29GpSi7 w8qQDQyXaj5yfjaI8/3b/NtXl5oG8ahzJyaYwlDA3H8DXz8A/y21N3Y+pOHPXDEK 5LzV5XY+hgMZ8HbiEOAShlK/DSzim5gKblScpiDZ6cJACc2/yVoaSAPBxASNM/GR D/p1RgOwral4K/rGa3vUWnN1ida8HUySGWMzmjT1cyuZDiCunDlYltJ5rh2qzf8v C89F3ANH5h2q5fbaAyAgysP9F5MB/QRSprUdBBZJN0wwh/QE+VvkhhS5KZoucOkq qM9wYKIGyuEps0CWC/+VzEpTP/6aBH9ROzTrfdWTjtlKTCUH/5Ts+yPoO5nuBlgQ wlKfn1ycxQez0PS0TQ0PBfbXOEdnpZE/sLCCb3panSrJYorsA3UFv3oFwlZkavQG 3nEWk9WjLhSF55zjaE4E/O/z2LeFx2GmXgLzJvpGbl1QkBLRjmpFWSNZkxkFWsQq KXW4efzFcoGPhC20AUp7ZTroR4t157kfW4D1KmNb7EV/Vtcf4sjkOJgNi93wqEti xe2q76pDvnG0C4nf4kM444h+lDug/WJhoxP0BxtPUvMoa1dITNDchxJMfU8cjrjB fHF4yXPCjGKK3cqhShdjQB+zUs19E2exHHxwliEkZgKQms4Czpg= =dut1 -----END PGP SIGNATURE----- --JvQHSioklbAlNrLkdf4DNiHHsu4jXGAO7-- From nobody Mon Dec 18 14:49:14 2017 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FAB126C23; Mon, 18 Dec 2017 14:49:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151363735310.7372.5251375128419879453@ietfa.amsl.com> Date: Mon, 18 Dec 2017 14:49:13 -0800 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-stunbis-13.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is 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, 18 Dec 2017 22:49:13 -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 WG 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-13.txt Pages : 67 Date : 2017-12-18 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tram-stunbis-13 https://datatracker.ietf.org/doc/html/draft-ietf-tram-stunbis-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-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/