From nobody Fri Dec 1 06:23:08 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAC812708C for ; Fri, 1 Dec 2017 06:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 TfD0qzVK8v4W for ; Fri, 1 Dec 2017 06:23:06 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id A2012126C19 for ; Fri, 1 Dec 2017 06:23:06 -0800 (PST) Received: from [192.168.20.53] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [99.248.225.186]) by mail.networkradius.com (Postfix) with ESMTPSA id A29A3161; Fri, 1 Dec 2017 14:23:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Fri, 1 Dec 2017 09:23:04 -0500 Cc: "radext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <285C5C94-578E-4293-81A2-9D73E1105ABE@deployingradius.com> References: <8BD2C2F2-D42E-4B84-8F86-3A803160DD74@cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 14:23:07 -0000 On Nov 30, 2017, at 9:02 PM, Jakob Heitz (jheitz) = wrote: >=20 > I generally don't like overloading a field with different semantics, I do agree it's weird.. but it *is* the minimal possible change to the = protocol. > because if one of the semantics needs to change in the future, the = dependency > on the other semantic will complicate the change. I'm not sure what that means... we are absolutely *not* going to = change the meaning of the Request Authenticator field. Doing so would = mean RADIUS would be changed into something else entirely. > For that reason, I prefer draft-chen-radext-identifier-attr-02. > I do like some of the detailed discussion of the issues in > draft-dekok-radext-request-authenticator-02. > I think the final document should include some of these discussions. One large point for me is the subject of "conflicting packets". i.e. = what does a RADIUS server do when it's currently processing one packet, = and it receives another one with the same src/dst ip/port, code, and ID? All of the specs are silent on this topic, despite implementations = having to handle such a corner case. So far as I can tell, all = implementations have chosen a similar solution. Even RFC 5080 ignores = this topic... despite FreeRADIUS (among others) have explicit code to = handle this situation. It was thinking about these "conflicting packets" that led me to my = draft. What if they *weren't* discarded / rejected, and instead the = server could process them?=20 The conclusion was not only that it was possible, but that it wasn't = much work, and wasn't a large change to the RADIUS protocol. It just = requirements agreement between the client and server to just behave = differently. In contrast, adding an extended ID as an attribute to every packet is = arguably changing the RADIUS header... while pretending we're not = changing the RADIUS header. We've avoided that for 20+ years because = it's a slippery slope to just changing all of RADIUS... Alan DeKok. From nobody Fri Dec 1 08:15:54 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3761C127011 for ; Fri, 1 Dec 2017 08:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 3x3ndmgnUdaS for ; Fri, 1 Dec 2017 08:15:51 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657E0126C2F for ; Fri, 1 Dec 2017 08:15:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11197; q=dns/txt; s=iport; t=1512144951; x=1513354551; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=o3o/c7otpbfEoOFq8ThsDoE3UHSnucFN0tkNSxvC1i8=; b=MBevsQBscaDCt4kth3kwIEhgnPi4/5KRUpWk794ewVudhfz5ACF4/oYG P6ill0ShMGqk3vq0+szSZvXBejzpqqjq72TUvpIZCcnmtHmU3k9zQW8Fz 8iv1OZdxWNOaTIqJ6Y6RhIICgIHeyB1M7DVfn28BniovQAhl0WDT/xlZI A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AgAzfyFa/4cNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8gVQng3+ZFIFXkViHYAqFOwIahRFDFAEBAQEBAQEBAWsohSM?= =?us-ascii?q?GI1YQAgEIPwMCAgIwFBECBA4FG4kjZKcGgieKZAEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAR2DQYIKgVaBaSkLgneDMoFZgysxgjIFilqJG4VAiS0ClQ+TVZYcAhEZAYE?= =?us-ascii?q?5ATYigU1vFWQBgX6CUR2BZ3iKAwEBAQ?= X-IronPort-AV: E=Sophos; i="5.45,344,1508803200"; d="scan'208,217"; a="38464585" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Dec 2017 16:15:50 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vB1GFo3U011647 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Dec 2017 16:15:50 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 1 Dec 2017 10:15:49 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Fri, 1 Dec 2017 10:15:49 -0600 From: "Jakob Heitz (jheitz)" To: Alan DeKok CC: "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTaFBwqtJDphnIu0Ga679ujWV4vKMsVBUAgAFpdmCAATY1AP//uuzY Date: Fri, 1 Dec 2017 16:15:49 +0000 Message-ID: <8DE62B3C-D2FA-4467-9CCE-7F8D039B87E2@cisco.com> References: <8BD2C2F2-D42E-4B84-8F86-3A803160DD74@cisco.com> , <285C5C94-578E-4293-81A2-9D73E1105ABE@deployingradius.com> In-Reply-To: <285C5C94-578E-4293-81A2-9D73E1105ABE@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_8DE62B3CD2FA44679CCE7F8D039B87E2ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 16:15:53 -0000 --_000_8DE62B3CD2FA44679CCE7F8D039B87E2ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBpZiB0aGUgcXVhbnR1bSBjb21wdXRlcnMgdHVybiBvdXQgdG8gbGl2ZSB1cCB0byB0aGVp ciBwcm9taXNlcz8gVGhlbiB3ZSBjYW4gdGhyb3cgb3V0IGFsbCB0aGlzIGF1dGhlbnRpY2F0aW9u IHN0dWZmIGFuZCBkZWNpZGUgdG8gbm90IHNoYXJlIG91ciBFdGhlcm5ldHMgd2l0aCB0aGUgYXR0 YWNrZXJzIGluc3RlYWQuIE5vIG1vcmUgcmVxdWVzdCBhdXRoZW50aWNhdG9yLg0KDQpUaGUgcmVx dWVzdCBhdXRoZW50aWNhdG9yIGlzIGFscmVhZHkgb3ZlcmxvYWRlZC4gSXQgbWF5IGJlIHVzZWQg Zm9yIHRoZSBDSEFQIGNoYWxsZW5nZS4gTm93LCB5b3Ugd2FudCBhbm90aGVyIG92ZXJsb2FkPw0K DQpUaGUgcmVxdWVzdCBhdXRoZW50aWNhdG9yIGlzIG5vdCByZWZsZWN0ZWQgYmFjayBpbiBhbnkg cmV0dXJuIHBhY2tldHMuIFRoZSByZXNwb25zZSBhdXRoZW50aWNhdG9yIGlzIGEgZGlmZmVyZW50 IG51bWJlci4gU3VwcG9zZSB0aGUgY2xpZW50IGhhcyBzZXZlcmFsIHJlcXVlc3RzIG91dHN0YW5k aW5nIHdpdGggdGhlIHNhbWUgaWQuIFdoZW4gaXQgcmVjZWl2ZXMgYSByZXNwb25zZSwgaXQgaGFz IHRvIGhhc2ggaXQgd2l0aCBldmVyeSByZXF1ZXN0IGF1dGhlbnRpY2F0b3IgZnJvbSB0aGVzZSBv dXRzdGFuZGluZyByZXF1ZXN0cyB0byBmaWd1cmUgb3V0IHdoaWNoIG9uZSB0aGUgcmVzcG9uc2Ug aXMgZm9yLiBUaGlzIGxvb2tzIGxpa2UgYSBsb3Qgb2YgdW5uZWNlc3NhcnkgaGFyZCB3b3JrLg0K DQpDb25mbGljdGluZyByZXF1ZXN0czogaWYgdGhlIHNlcnZlciByZWNlaXZlcyBhIHJlcXVlc3Qg aWRlbnRpY2FsIHRvIG9uZSBpdCByZWNlaXZlZCBiZWZvcmUgYW5kIGhhcyBhIGNhY2hlZCByZXNw b25zZSwgdGhlbiByZXRyYW5zbWl0IHRoZSBjYWNoZSwgZWxzZSBwcm9jZXNzIGl0IGFnYWluLiBI b3cgdG8gZGV0ZXJtaW5lIOKAnGlkZW50aWNhbCByZXF1ZXN04oCdIGlzIGEgbG9jYWwgbWF0dGVy LiBDb21wYXJpbmcgSUQgYWxvbmUgaXMgY2xlYXJseSBub3QgZW5vdWdoLiBDb21wYXJpbmcgYW55 dGhpbmcgbGVzcyB0aGFuIHRoZSB3aG9sZSByZXF1ZXN0IHBhY2tldCByaXNrcyBtaXNpZGVudGlm aWVkIGR1cGxpY2F0ZXMuIElmIHRoZSBzaG9ydCBjdXQgbWlzbGVhZHMsIHRoZW4gZG9u4oCZdCB0 YWtlIHRoZSBzaG9ydCBjdXQuDQoNClRoYW5rcywNCkpha29iLg0KDQoNCk9uIERlYyAxLCAyMDE3 LCBhdCA2OjIzIEFNLCBBbGFuIERlS29rIDxhbGFuZEBkZXBsb3lpbmdyYWRpdXMuY29tPG1haWx0 bzphbGFuZEBkZXBsb3lpbmdyYWRpdXMuY29tPj4gd3JvdGU6DQoNCk9uIE5vdiAzMCwgMjAxNywg YXQgOTowMiBQTSwgSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRv OmpoZWl0ekBjaXNjby5jb20+PiB3cm90ZToNCg0KSSBnZW5lcmFsbHkgZG9uJ3QgbGlrZSBvdmVy bG9hZGluZyBhIGZpZWxkIHdpdGggZGlmZmVyZW50IHNlbWFudGljcywNCg0KIEkgZG8gYWdyZWUg aXQncyB3ZWlyZC4uIGJ1dCBpdCAqaXMqIHRoZSBtaW5pbWFsIHBvc3NpYmxlIGNoYW5nZSB0byB0 aGUgcHJvdG9jb2wuDQoNCmJlY2F1c2UgaWYgb25lIG9mIHRoZSBzZW1hbnRpY3MgbmVlZHMgdG8g Y2hhbmdlIGluIHRoZSBmdXR1cmUsIHRoZSBkZXBlbmRlbmN5DQpvbiB0aGUgb3RoZXIgc2VtYW50 aWMgd2lsbCBjb21wbGljYXRlIHRoZSBjaGFuZ2UuDQoNCiBJJ20gbm90IHN1cmUgd2hhdCB0aGF0 IG1lYW5zLi4uIHdlIGFyZSBhYnNvbHV0ZWx5ICpub3QqIGdvaW5nIHRvIGNoYW5nZSB0aGUgbWVh bmluZyBvZiB0aGUgUmVxdWVzdCBBdXRoZW50aWNhdG9yIGZpZWxkLiAgRG9pbmcgc28gd291bGQg bWVhbiBSQURJVVMgd291bGQgYmUgY2hhbmdlZCBpbnRvIHNvbWV0aGluZyBlbHNlIGVudGlyZWx5 Lg0KDQpGb3IgdGhhdCByZWFzb24sIEkgcHJlZmVyIGRyYWZ0LWNoZW4tcmFkZXh0LWlkZW50aWZp ZXItYXR0ci0wMi4NCkkgZG8gbGlrZSBzb21lIG9mIHRoZSBkZXRhaWxlZCBkaXNjdXNzaW9uIG9m IHRoZSBpc3N1ZXMgaW4NCmRyYWZ0LWRla29rLXJhZGV4dC1yZXF1ZXN0LWF1dGhlbnRpY2F0b3It MDIuDQpJIHRoaW5rIHRoZSBmaW5hbCBkb2N1bWVudCBzaG91bGQgaW5jbHVkZSBzb21lIG9mIHRo ZXNlIGRpc2N1c3Npb25zLg0KDQogT25lIGxhcmdlIHBvaW50IGZvciBtZSBpcyB0aGUgc3ViamVj dCBvZiAiY29uZmxpY3RpbmcgcGFja2V0cyIuICBpLmUuIHdoYXQgZG9lcyBhIFJBRElVUyBzZXJ2 ZXIgZG8gd2hlbiBpdCdzIGN1cnJlbnRseSBwcm9jZXNzaW5nIG9uZSBwYWNrZXQsIGFuZCBpdCBy ZWNlaXZlcyBhbm90aGVyIG9uZSB3aXRoIHRoZSBzYW1lIHNyYy9kc3QgaXAvcG9ydCwgY29kZSwg YW5kIElEPw0KDQogQWxsIG9mIHRoZSBzcGVjcyBhcmUgc2lsZW50IG9uIHRoaXMgdG9waWMsIGRl c3BpdGUgaW1wbGVtZW50YXRpb25zIGhhdmluZyB0byBoYW5kbGUgc3VjaCBhIGNvcm5lciBjYXNl LiAgU28gZmFyIGFzIEkgY2FuIHRlbGwsIGFsbCBpbXBsZW1lbnRhdGlvbnMgaGF2ZSBjaG9zZW4g YSBzaW1pbGFyIHNvbHV0aW9uLiAgRXZlbiBSRkMgNTA4MCBpZ25vcmVzIHRoaXMgdG9waWMuLi4g ZGVzcGl0ZSBGcmVlUkFESVVTIChhbW9uZyBvdGhlcnMpIGhhdmUgZXhwbGljaXQgY29kZSB0byBo YW5kbGUgdGhpcyBzaXR1YXRpb24uDQoNCiBJdCB3YXMgdGhpbmtpbmcgYWJvdXQgdGhlc2UgImNv bmZsaWN0aW5nIHBhY2tldHMiIHRoYXQgbGVkIG1lIHRvIG15IGRyYWZ0LiAgV2hhdCBpZiB0aGV5 ICp3ZXJlbid0KiBkaXNjYXJkZWQgLyByZWplY3RlZCwgYW5kIGluc3RlYWQgdGhlIHNlcnZlciBj b3VsZCBwcm9jZXNzIHRoZW0/DQoNCiBUaGUgY29uY2x1c2lvbiB3YXMgbm90IG9ubHkgdGhhdCBp dCB3YXMgcG9zc2libGUsIGJ1dCB0aGF0IGl0IHdhc24ndCBtdWNoIHdvcmssIGFuZCB3YXNuJ3Qg YSBsYXJnZSBjaGFuZ2UgdG8gdGhlIFJBRElVUyBwcm90b2NvbC4gIEl0IGp1c3QgcmVxdWlyZW1l bnRzIGFncmVlbWVudCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHNlcnZlciB0byBqdXN0IGJlaGF2 ZSBkaWZmZXJlbnRseS4NCg0KIEluIGNvbnRyYXN0LCBhZGRpbmcgYW4gZXh0ZW5kZWQgSUQgYXMg YW4gYXR0cmlidXRlIHRvIGV2ZXJ5IHBhY2tldCBpcyBhcmd1YWJseSBjaGFuZ2luZyB0aGUgUkFE SVVTIGhlYWRlci4uLiB3aGlsZSBwcmV0ZW5kaW5nIHdlJ3JlIG5vdCBjaGFuZ2luZyB0aGUgUkFE SVVTIGhlYWRlci4gIFdlJ3ZlIGF2b2lkZWQgdGhhdCBmb3IgMjArIHllYXJzIGJlY2F1c2UgaXQn cyBhIHNsaXBwZXJ5IHNsb3BlIHRvIGp1c3QgY2hhbmdpbmcgYWxsIG9mIFJBRElVUy4uLg0KDQog QWxhbiBEZUtvay4NCg0K --_000_8DE62B3CD2FA44679CCE7F8D039B87E2ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpX aGF0IGlmIHRoZSBxdWFudHVtIGNvbXB1dGVycyB0dXJuIG91dCB0byBsaXZlIHVwIHRvIHRoZWly IHByb21pc2VzPyBUaGVuIHdlIGNhbiB0aHJvdyBvdXQgYWxsIHRoaXMgYXV0aGVudGljYXRpb24g c3R1ZmYgYW5kIGRlY2lkZSB0byBub3Qgc2hhcmUgb3VyIEV0aGVybmV0cyB3aXRoIHRoZSBhdHRh Y2tlcnMgaW5zdGVhZC4gTm8gbW9yZSByZXF1ZXN0IGF1dGhlbnRpY2F0b3IuDQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5UaGUgcmVxdWVzdCBhdXRoZW50aWNhdG9yIGlzIGFscmVhZHkgb3Zlcmxv YWRlZC4gSXQgbWF5IGJlIHVzZWQgZm9yIHRoZSBDSEFQIGNoYWxsZW5nZS4gTm93LCB5b3Ugd2Fu dCBhbm90aGVyIG92ZXJsb2FkPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIHJl cXVlc3QgYXV0aGVudGljYXRvciBpcyBub3QgcmVmbGVjdGVkIGJhY2sgaW4gYW55IHJldHVybiBw YWNrZXRzLiBUaGUgcmVzcG9uc2UgYXV0aGVudGljYXRvciBpcyBhIGRpZmZlcmVudCBudW1iZXIu IFN1cHBvc2UgdGhlIGNsaWVudCBoYXMgc2V2ZXJhbCByZXF1ZXN0cyBvdXRzdGFuZGluZyB3aXRo IHRoZSBzYW1lIGlkLiBXaGVuIGl0IHJlY2VpdmVzIGEgcmVzcG9uc2UsIGl0IGhhcyB0byBoYXNo IGl0IHdpdGggZXZlcnkgcmVxdWVzdA0KIGF1dGhlbnRpY2F0b3IgZnJvbSB0aGVzZSBvdXRzdGFu ZGluZyByZXF1ZXN0cyB0byBmaWd1cmUgb3V0IHdoaWNoIG9uZSB0aGUgcmVzcG9uc2UgaXMgZm9y LiBUaGlzIGxvb2tzIGxpa2UgYSBsb3Qgb2YgdW5uZWNlc3NhcnkgaGFyZCB3b3JrLjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q29uZmxpY3RpbmcgcmVxdWVzdHM6IGlmIHRoZSBzZXJ2 ZXIgcmVjZWl2ZXMgYSByZXF1ZXN0IGlkZW50aWNhbCB0byBvbmUgaXQgcmVjZWl2ZWQgYmVmb3Jl IGFuZCBoYXMgYSBjYWNoZWQgcmVzcG9uc2UsIHRoZW4gcmV0cmFuc21pdCB0aGUgY2FjaGUsIGVs c2UgcHJvY2VzcyBpdCBhZ2Fpbi4gSG93IHRvIGRldGVybWluZSDigJxpZGVudGljYWwgcmVxdWVz dOKAnSBpcyBhIGxvY2FsIG1hdHRlci4gQ29tcGFyaW5nIElEIGFsb25lIGlzIGNsZWFybHkNCiBu b3QgZW5vdWdoLiBDb21wYXJpbmcgYW55dGhpbmcgbGVzcyB0aGFuIHRoZSB3aG9sZSByZXF1ZXN0 IHBhY2tldCByaXNrcyBtaXNpZGVudGlmaWVkIGR1cGxpY2F0ZXMuIElmIHRoZSBzaG9ydCBjdXQg bWlzbGVhZHMsIHRoZW4gZG9u4oCZdCB0YWtlIHRoZSBzaG9ydCBjdXQuPGJyPg0KPGJyPg0KPGRp diBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5UaGFua3MsPGJyPg0KPGRpdj5KYWtvYi48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gRGVjIDEsIDIwMTcsIGF0 IDY6MjMgQU0sIEFsYW4gRGVLb2sgJmx0OzxhIGhyZWY9Im1haWx0bzphbGFuZEBkZXBsb3lpbmdy YWRpdXMuY29tIj5hbGFuZEBkZXBsb3lpbmdyYWRpdXMuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0K PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+T24gTm92 IDMwLCAyMDE3LCBhdCA5OjAyIFBNLCBKYWtvYiBIZWl0eiAoamhlaXR6KSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmpoZWl0ekBjaXNjby5jb20iPmpoZWl0ekBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 L3NwYW4+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkkgZ2VuZXJhbGx5IGRv bid0IGxpa2Ugb3ZlcmxvYWRpbmcgYSBmaWVsZCB3aXRoIGRpZmZlcmVudCBzZW1hbnRpY3MsPC9z cGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDtJ IGRvIGFncmVlIGl0J3Mgd2VpcmQuLiBidXQgaXQgKmlzKiB0aGUgbWluaW1hbCBwb3NzaWJsZSBj aGFuZ2UgdG8gdGhlIHByb3RvY29sLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+YmVjYXVzZSBpZiBvbmUgb2YgdGhlIHNlbWFudGlj cyBuZWVkcyB0byBjaGFuZ2UgaW4gdGhlIGZ1dHVyZSwgdGhlIGRlcGVuZGVuY3k8L3NwYW4+PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+b24gdGhlIG90 aGVyIHNlbWFudGljIHdpbGwgY29tcGxpY2F0ZSB0aGUgY2hhbmdlLjwvc3Bhbj48YnI+DQo8L2Js b2NrcXVvdGU+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7SSdtIG5vdCBzdXJlIHdo YXQgdGhhdCBtZWFucy4uLiB3ZSBhcmUgYWJzb2x1dGVseSAqbm90KiBnb2luZyB0byBjaGFuZ2Ug dGhlIG1lYW5pbmcgb2YgdGhlIFJlcXVlc3QgQXV0aGVudGljYXRvciBmaWVsZC4gJm5ic3A7RG9p bmcgc28gd291bGQgbWVhbiBSQURJVVMgd291bGQgYmUgY2hhbmdlZCBpbnRvIHNvbWV0aGluZyBl bHNlIGVudGlyZWx5Ljwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PHNwYW4+Rm9yIHRoYXQgcmVhc29uLCBJIHByZWZlciBkcmFmdC1jaGVuLXJh ZGV4dC1pZGVudGlmaWVyLWF0dHItMDIuPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkkgZG8gbGlrZSBzb21lIG9mIHRoZSBkZXRhaWxlZCBk aXNjdXNzaW9uIG9mIHRoZSBpc3N1ZXMgaW48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ZHJhZnQtZGVrb2stcmFkZXh0LXJlcXVlc3QtYXV0 aGVudGljYXRvci0wMi48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PHNwYW4+SSB0aGluayB0aGUgZmluYWwgZG9jdW1lbnQgc2hvdWxkIGluY2x1ZGUg c29tZSBvZiB0aGVzZSBkaXNjdXNzaW9ucy48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPHNw YW4+PC9zcGFuPjxicj4NCjxzcGFuPiZuYnNwO09uZSBsYXJnZSBwb2ludCBmb3IgbWUgaXMgdGhl IHN1YmplY3Qgb2YgJnF1b3Q7Y29uZmxpY3RpbmcgcGFja2V0cyZxdW90Oy4gJm5ic3A7aS5lLiB3 aGF0IGRvZXMgYSBSQURJVVMgc2VydmVyIGRvIHdoZW4gaXQncyBjdXJyZW50bHkgcHJvY2Vzc2lu ZyBvbmUgcGFja2V0LCBhbmQgaXQgcmVjZWl2ZXMgYW5vdGhlciBvbmUgd2l0aCB0aGUgc2FtZSBz cmMvZHN0IGlwL3BvcnQsIGNvZGUsIGFuZCBJRD88L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxi cj4NCjxzcGFuPiZuYnNwO0FsbCBvZiB0aGUgc3BlY3MgYXJlIHNpbGVudCBvbiB0aGlzIHRvcGlj LCBkZXNwaXRlIGltcGxlbWVudGF0aW9ucyBoYXZpbmcgdG8gaGFuZGxlIHN1Y2ggYSBjb3JuZXIg Y2FzZS4gJm5ic3A7U28gZmFyIGFzIEkgY2FuIHRlbGwsIGFsbCBpbXBsZW1lbnRhdGlvbnMgaGF2 ZSBjaG9zZW4gYSBzaW1pbGFyIHNvbHV0aW9uLiAmbmJzcDtFdmVuIFJGQyA1MDgwIGlnbm9yZXMg dGhpcyB0b3BpYy4uLiBkZXNwaXRlIEZyZWVSQURJVVMgKGFtb25nIG90aGVycykNCiBoYXZlIGV4 cGxpY2l0IGNvZGUgdG8gaGFuZGxlIHRoaXMgc2l0dWF0aW9uLjwvc3Bhbj48YnI+DQo8c3Bhbj48 L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7SXQgd2FzIHRoaW5raW5nIGFib3V0IHRoZXNlICZxdW90 O2NvbmZsaWN0aW5nIHBhY2tldHMmcXVvdDsgdGhhdCBsZWQgbWUgdG8gbXkgZHJhZnQuICZuYnNw O1doYXQgaWYgdGhleSAqd2VyZW4ndCogZGlzY2FyZGVkIC8gcmVqZWN0ZWQsIGFuZCBpbnN0ZWFk IHRoZSBzZXJ2ZXIgY291bGQgcHJvY2VzcyB0aGVtPw0KPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bh bj48YnI+DQo8c3Bhbj4mbmJzcDtUaGUgY29uY2x1c2lvbiB3YXMgbm90IG9ubHkgdGhhdCBpdCB3 YXMgcG9zc2libGUsIGJ1dCB0aGF0IGl0IHdhc24ndCBtdWNoIHdvcmssIGFuZCB3YXNuJ3QgYSBs YXJnZSBjaGFuZ2UgdG8gdGhlIFJBRElVUyBwcm90b2NvbC4gJm5ic3A7SXQganVzdCByZXF1aXJl bWVudHMgYWdyZWVtZW50IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgc2VydmVyIHRvIGp1c3QgYmVo YXZlIGRpZmZlcmVudGx5Ljwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+Jm5i c3A7SW4gY29udHJhc3QsIGFkZGluZyBhbiBleHRlbmRlZCBJRCBhcyBhbiBhdHRyaWJ1dGUgdG8g ZXZlcnkgcGFja2V0IGlzIGFyZ3VhYmx5IGNoYW5naW5nIHRoZSBSQURJVVMgaGVhZGVyLi4uIHdo aWxlIHByZXRlbmRpbmcgd2UncmUgbm90IGNoYW5naW5nIHRoZSBSQURJVVMgaGVhZGVyLiAmbmJz cDtXZSd2ZSBhdm9pZGVkIHRoYXQgZm9yIDIwJiM0MzsgeWVhcnMgYmVjYXVzZSBpdCdzIGEgc2xp cHBlcnkgc2xvcGUgdG8ganVzdCBjaGFuZ2luZyBhbGwgb2YNCiBSQURJVVMuLi48L3NwYW4+PGJy Pg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPiZuYnNwO0FsYW4gRGVLb2suPC9zcGFuPjxicj4N CjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_8DE62B3CD2FA44679CCE7F8D039B87E2ciscocom_-- From nobody Fri Dec 1 08:40:00 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C241712940B for ; Fri, 1 Dec 2017 08:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 ryccUzRV6_a0 for ; Fri, 1 Dec 2017 08:39:56 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id C1518128A32 for ; Fri, 1 Dec 2017 08:39:56 -0800 (PST) Received: from [192.168.20.53] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [99.248.225.186]) by mail.networkradius.com (Postfix) with ESMTPSA id C303A4D9; Fri, 1 Dec 2017 16:39:55 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <8DE62B3C-D2FA-4467-9CCE-7F8D039B87E2@cisco.com> Date: Fri, 1 Dec 2017 11:39:54 -0500 Cc: "radext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8D51B0BA-8F24-437D-B841-7F796F1174CF@deployingradius.com> References: <8BD2C2F2-D42E-4B84-8F86-3A803160DD74@cisco.com> <285C5C94-578E-4293-81A2-9D73E1105ABE@deployingradius.com> <8DE62B3C-D2FA-4467-9CCE-7F8D039B87E2@cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 16:39:59 -0000 On Dec 1, 2017, at 11:15 AM, Jakob Heitz (jheitz) = wrote: >=20 > What if the quantum computers turn out to live up to their promises? = Then we can throw out all this authentication stuff and decide to not = share our Ethernets with the attackers instead. No more request = authenticator. I'm sorry, but that just isn't realistic. If quantum computers can crack encryption, then RADIUS security will = be the least of our issues. > The request authenticator is already overloaded. It may be used for = the CHAP challenge. Now, you want another overload? I'd like to use an existing field, yes. The draft explains why this works. In detail. > The request authenticator is not reflected back in any return packets. = The response authenticator is a different number. Suppose the client has = several requests outstanding with the same id. When it receives a = response, it has to hash it with every request authenticator from these = outstanding requests to figure out which one the response is for. Please don't claim there are problems with the draft until you read = it. The draft EXPLICITLY STATES that the request authenticator is echoed = back in a new attribute. It has many, many, pages to discuss all = possible issues with that practice. > Conflicting requests: if the server receives a request identical to = one it received before and has a cached response, then retransmit the = cache, else process it again. How to determine =E2=80=9Cidentical = request=E2=80=9D is a local matter. Those are duplicate requests. They were defined 10 years ago in RFC = 5080, Section 2.2.2, including how to determine what a "duplicate = request" is. https://tools.ietf.org/html/rfc5080#section-2.2.2 RFC 5080 also defines what RADIUS servers should do with these = requests. My comment was about *conflicts*. i.e. a RADIUS server receives an Access-Request from a client = (src/dst, IP/port, ID 0, request authenticator A). While the server is = processing that packet, the client (for whatever reason) sends a = *different* packet with the same src/dst IP/port. ID 0, but a = *different* request authenticator. Should be server respond to the first packet? Or should the server = respond to the second packet? Or should it respond to both? Again... this issue is discussed in detail in my draft. > Comparing ID alone is clearly not enough. Comparing anything less than = the whole request packet risks misidentified duplicates. That simply isn't true. Again, please read the draft. This is discussed in excruciating = detail. Including the possibility of false positives, false negatives, = etc. > If the short cut misleads, then don=E2=80=99t take the short cut. I think the only short cut here is the decision to skip reading the = draft before commenting on it. Alan DeKok. From nobody Fri Dec 1 13:52:30 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F18B1270A3 for ; Fri, 1 Dec 2017 13:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=f5.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 jWPKibOC4SGQ for ; Fri, 1 Dec 2017 13:52:28 -0800 (PST) Received: from mail15.f5.com (mail15.f5.com [104.219.107.14]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4656127419 for ; Fri, 1 Dec 2017 13:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=f5; t=1512165148; x=1543701148; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=VXR8siHYQ9UpbgAs0ZiEed4S8RO8gZxbfm8sbiLNfyY=; b=lQ06q0jYghgfoB0loDwOExaqRAK72jN7yHsU8RMcohgaHWxZTFQ5YbfX frAr53OPCeZljb/D/WJjc82cwXh4TfwxdNIgGy6gtm9xNhAQRgbCOz+8u VjOCoa/QFkLNc/vEgbxy6YIgeyTpIgJjtz0T7PT7Vc/CYhxPiKFcDCmTc a5L7ZsH90rou2rlnJWTaDEQJkeMBGN7pHF25lvJ/KampcU30drajzIQVQ DS7ZnNpZhzkFkONh5AVaqZ12pPXDT+DGRokee+RJXhQdvjdvyph+LPI9N sGWcQ2aatNIkoUOMAKuh0lX8CvXeQgluNsaYlEs/W+SdvOllCs1M97jsY A==; X-IronPort-AV: E=McAfee;i="5900,7806,8732"; a="28621939" X-IronPort-AV: E=Sophos;i="5.45,347,1508828400"; d="scan'208";a="28621939" X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from seadev21.olympus.f5net.com ([192.168.180.71]) by mail.f5net.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Dec 2017 13:52:27 -0800 Received: from seadev21.olympus.f5net.com (localhost [127.0.0.1]) by seadev21.olympus.f5net.com (8.14.4/8.14.4) with ESMTP id vASKIs7B029114; Tue, 28 Nov 2017 12:18:54 -0800 Received: (from aesmith@localhost) by seadev21.olympus.f5net.com (8.14.4/8.14.4/Submit) id vASKIrJg029106; Tue, 28 Nov 2017 12:18:53 -0800 X-Authentication-Warning: seadev21.olympus.f5net.com: aesmith set sender to AE.Smith@f5.com using -f Date: Tue, 28 Nov 2017 12:18:53 -0800 From: Astrid Smith To: Stefan Winter Cc: radext@ietf.org Message-ID: <20171128201853.GD17201@seadev21.f5.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 21:52:29 -0000 Hello, I prefer the option laid out in draft-dekok-radext-request-authenticator-02, due to deficiencies in the other proposal (draft-chen-radext-identifier-attr-02). I'm concerned about the extended Code field it defines: How should implementations treat messages where this Code differs from the Code in the RADIUS header? The precedence is poorly defined and liable to cause issues. The proposal also requires all proxies to explicitly support (by parsing and passing through, or by stripping) the Identifier Attribute; this requires protocol users to upgrade and test all the software in their RADIUS deployment before any clients may safely attempt to use the attribute. It feels half-baked. The request-authenticator proposal appears safe to deploy without upgrading the software of any proxies in the network. As a maintainer of a RADIUS proxy I prefer this, and I suspect my customers would agree :) -- astrid smith ------------------- --<[ c y b e r | s o f t w a r e | e n g i n e e r ]>-- ------------ ------------------ On Tue, Nov 28, 2017 at 02:54:32PM +0100, Stefan Winter wrote: > Hello, > > > thanks all for raising the awareness of these two drafts. > > > > > > I think it would be good if all remaining readers of this list who care > > enough now take some time to read both drafts and make up their mind on > > what the preferred approach is. > > > > > > In approx. two weeks' time I will start a call for adoption on both > > drafts, and hopefully there are enough responses to make the exercise > > meaningful. If so, the one with more votes wins. > > Now that was a relaxed "two weeks" delay. My apologies, I've been on and > off work for a while, with substantial backlogs. > > This email starts a two week call for adoption of at most one of the > following two drafts: > > * draft-chen-radext-identifier-attr-02 > * draft-dekok-radext-request-authenticator-02 > > Since the two drafts treat the same topic, at most one can be selected > to serve as the basis for future work. > > In your reply to this call for adoption, please indicate which of the > two drafts you think should be adopted. You can of course also indicate > that none of the two are fit for purpose. The only thing you really > shouldn't do is to vote for both; that wouldn't help the discussion move on. > > Please reply by 12 dec 2017 2400 UTC. > > Greetings, > > Stefan Winter From nobody Fri Dec 1 14:06:24 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EB5128B88 for ; Fri, 1 Dec 2017 14:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 aw7PZw5879rS for ; Fri, 1 Dec 2017 14:06:20 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1189128768 for ; Fri, 1 Dec 2017 14:06:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3493; q=dns/txt; s=iport; t=1512165977; x=1513375577; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=L9i3GxPzuiKcZiqL/Mw43xR9jI5R1HdKYf3ucaLBplA=; b=EIfztGGsChwD3StENmnkAyQk9xAaGAbtgvah18F00DDZkRe1lma5NaXN vFqvgBkv4wWFUlFFd9P38jmBOlSTvIJtw7v50RupM9FW5ldzM5tAuHo4b 1mK/Xq38UddA//EiSYDChQszYd3LGlBLuKijqVy4jjdJgmxDDHtBuEafl 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwAQBN0SFa/4gNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm4nB44YjnaBVyaWfRSCAQoYC4FegmtPAoUrPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUiAQEBAwEBARsdNAsFCwIBCA4KHhAnCyUCBA4FihoIEKk6ilgBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYVLg2gLgneDMoE8ARIBEg2DRoIyBYpCmCACi12?= =?us-ascii?q?JMgyCCoYQhAiHJ5YcAhEZAYE5AR85YWxvFToqAYF+glIcgWd4h2cNGIEMgRQBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.45,347,1508803200"; d="scan'208";a="331081502" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Dec 2017 22:06:16 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vB1M6GhV005612 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Dec 2017 22:06:16 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 1 Dec 2017 16:06:16 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Fri, 1 Dec 2017 16:06:16 -0600 From: "Naiming Shen (naiming)" To: Astrid Smith CC: Stefan Winter , "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTaFBwqtJDphnIu0Ga679ujWV4vKMqoCyAgATU/oA= Date: Fri, 1 Dec 2017 22:06:16 +0000 Message-ID: References: <20171128201853.GD17201@seadev21.f5.com> In-Reply-To: <20171128201853.GD17201@seadev21.f5.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.173.198] Content-Type: text/plain; charset="us-ascii" Content-ID: <3A4E74264725F84AA3B5F030D3A00F96@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 22:06:22 -0000 Hi Astrid, When you say draft-chin-radext-identifier-attr requires all proxies to explicitly support this and test all the software; what do you think of draft-dekok-radext-request-authticator would do to the proxy servers? the connection is hop by hop, each hop has to support the new mechanism in order to have nas-proxy-home_server working with the extended-id in all the mechanisms. Just because the draft-dekok-radext-request-authticator does not explain how to do that, does not mean it can have the original software working unchanged:-) We are talking about the feeling of half-baked;-) Cheers, - Naiming > On Nov 28, 2017, at 12:18 PM, Astrid Smith wrote: >=20 > Hello, >=20 > I prefer the option laid out in > draft-dekok-radext-request-authenticator-02, due to deficiencies in > the other proposal (draft-chen-radext-identifier-attr-02). >=20 > I'm concerned about the extended Code field it defines: How should > implementations treat messages where this Code differs from the Code > in the RADIUS header? The precedence is poorly defined and liable to > cause issues. >=20 > The proposal also requires all proxies to explicitly support (by > parsing and passing through, or by stripping) the Identifier > Attribute; this requires protocol users to upgrade and test all the > software in their RADIUS deployment before any clients may safely > attempt to use the attribute. >=20 > It feels half-baked. >=20 > The request-authenticator proposal appears safe to deploy without > upgrading the software of any proxies in the network. As a maintainer > of a RADIUS proxy I prefer this, and I suspect my customers would > agree :) >=20 > --=20 > astrid smith ------------------- > --<[ c y b e r | s o f t w a r e | e n g i n e e r ]>-- > ------------ ------------------ >=20 >=20 >=20 > On Tue, Nov 28, 2017 at 02:54:32PM +0100, Stefan Winter wrote: >> Hello, >>=20 >>> thanks all for raising the awareness of these two drafts. >>>=20 >>>=20 >>> I think it would be good if all remaining readers of this list who care >>> enough now take some time to read both drafts and make up their mind on >>> what the preferred approach is. >>>=20 >>>=20 >>> In approx. two weeks' time I will start a call for adoption on both >>> drafts, and hopefully there are enough responses to make the exercise >>> meaningful. If so, the one with more votes wins. >>=20 >> Now that was a relaxed "two weeks" delay. My apologies, I've been on and >> off work for a while, with substantial backlogs. >>=20 >> This email starts a two week call for adoption of at most one of the >> following two drafts: >>=20 >> * draft-chen-radext-identifier-attr-02 >> * draft-dekok-radext-request-authenticator-02 >>=20 >> Since the two drafts treat the same topic, at most one can be selected >> to serve as the basis for future work. >>=20 >> In your reply to this call for adoption, please indicate which of the >> two drafts you think should be adopted. You can of course also indicate >> that none of the two are fit for purpose. The only thing you really >> shouldn't do is to vote for both; that wouldn't help the discussion move= on. >>=20 >> Please reply by 12 dec 2017 2400 UTC. >>=20 >> Greetings, >>=20 >> Stefan Winter >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Fri Dec 1 14:16:43 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96AC1270A0 for ; Fri, 1 Dec 2017 14:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 EkD2ofAOTI_k for ; Fri, 1 Dec 2017 14:16:40 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEBF1205F1 for ; Fri, 1 Dec 2017 14:16:40 -0800 (PST) Received: from [192.168.2.9] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id D147125D; Fri, 1 Dec 2017 22:16:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <20171128201853.GD17201@seadev21.f5.com> Date: Fri, 1 Dec 2017 17:16:36 -0500 Cc: Winter Stefan , radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <990F2F84-4C13-4A5B-A6B2-8D61C4029E79@deployingradius.com> References: <20171128201853.GD17201@seadev21.f5.com> To: Astrid Smith X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 22:16:42 -0000 On Nov 28, 2017, at 3:18 PM, Astrid Smith wrote: > I'm concerned about the extended Code field it defines: How should > implementations treat messages where this Code differs from the Code > in the RADIUS header? The precedence is poorly defined and liable to > cause issues. That is a concern. What happens if the same Extended ID is used in = two different packets from the same src/dst IP/port + Code + ID? > The proposal also requires all proxies to explicitly support (by > parsing and passing through, or by stripping) the Identifier > Attribute; this requires protocol users to upgrade and test all the > software in their RADIUS deployment before any clients may safely > attempt to use the attribute. There are provisions for negotiation in both drafts. > The request-authenticator proposal appears safe to deploy without > upgrading the software of any proxies in the network. As a maintainer > of a RADIUS proxy I prefer this, and I suspect my customers would > agree :) The one benefit of the request authenticator draft is that even in the = case of misconfiguration, it's *impossible* for the extended IDs to leak = across a proxy boundary. draft-chen, on the other hand, would have the extended ID leaked = across old-style proxies if the client was statically misconfigured. Alan DeKok. From nobody Sun Dec 3 00:22:38 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8206120713 for ; Sun, 3 Dec 2017 00:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 HORIoTgx5cRV for ; Sun, 3 Dec 2017 00:22:36 -0800 (PST) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id DF5DA1201F8 for ; Sun, 3 Dec 2017 00:22:35 -0800 (PST) Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 3 Dec 2017 00:22:35 -0800 Date: Sun, 3 Dec 2017 00:22:35 -0800 (Pacific Standard Time) From: Peter Deacon To: Stefan Winter cc: radext@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21.1 (WNT 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 08:22:38 -0000 On Tue, 28 Nov 2017, Stefan Winter wrote: >> I think it would be good if all remaining readers of this list who care >> enough now take some time to read both drafts and make up their mind on >> what the preferred approach is. >> In approx. two weeks' time I will start a call for adoption on both >> drafts, and hopefully there are enough responses to make the exercise >> meaningful. If so, the one with more votes wins. > * draft-chen-radext-identifier-attr-02 > * draft-dekok-radext-request-authenticator-02 > Since the two drafts treat the same topic, at most one can be selected > to serve as the basis for future work. > In your reply to this call for adoption, please indicate which of the > two drafts you think should be adopted. You can of course also indicate > that none of the two are fit for purpose. The only thing you really While both approaches achieve the same thing using similar means and similar properties of the two draft-dekok-radext-request-authenticator-02 is my preference. Details below for those interested. ---- draft-chen-radext-identifier-attr-02 While I have some minor concerns: - structure of attribute Please make it a normal integer? - ordering requirement Only one specification can ever demand its attribute be "first". You have to check the rest anyway to enforce stated constraint. This should be relaxed. - lack of details The approach at a high level is reasonable and makes sense to me. A very minor issue I see is behavior in face of misconfigured clients by allowing for manual configuration: Consider client /w extended id support enabled sends Request to immediate upstream server in proxy chain not supporting extended id. In this case some things may happen: 1. No server in the chain support extended id resulting in client never seeing a response. This seems acceptable enough to me because the client is after-all misconfigured. 2. One or more servers in the chain support extended id. What happens in this case is implementation specific. A. Best case the benefits of extended id space are successfully tunneled back to requesting client thru servers that don't support it. This is actually kind of cool assuming it's what actually happens. B. Second best extended id attribute is dropped due to proxy specific policy restrictions causing client to never see response. No response is an acceptable response to client misconfiguration. C. Not so good proxy server is only checking srcaddr/srcport/id for duplicate requests resulting in a ton of dropped requests and a potentially difficult problem for operators to understand or troubleshoot. ---- draft-dekok-radext-request-authenticator-02 This approach also makes sense conceptually and seems to be marginally easier to manage. No changes to request attributes, no worry about dynamic auth req and no sequence counter to maintain when generating ORA response. This approach offers a small benefit ORA response always unambiguously correlated with requesting peer avoiding possibility of (C.) behavior in proxy chains. I don't agree with client behavior when ORA is expected yet missing. The response should always be to silently ignore request. Certainly mandatory fallback mechanism for static configuration is going way too far in dictating behavior / controlling operator preference. Wouldn't count on those who elect to implement a mechanism like this to also spend too much time working viable scalable connection management to provide useful interop with servers that don't support ORA otherwise to be honest likely wouldn't be much point in implementing this draft in the first place. In my view it should not be assumed fallback is harmless or even a viable option. regards, Peter From nobody Sun Dec 3 06:18:57 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862581243FE for ; Sun, 3 Dec 2017 06:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 OuoGd1Nl24a2 for ; Sun, 3 Dec 2017 06:18:53 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id DBBC2124234 for ; Sun, 3 Dec 2017 06:18:52 -0800 (PST) Received: from [192.168.2.25] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id C42094D4; Sun, 3 Dec 2017 14:18:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Sun, 3 Dec 2017 09:18:50 -0500 Cc: Winter Stefan , radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8C4CACF8-3940-4209-B44F-C501DAE945CA@deployingradius.com> References: To: Peter Deacon X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 14:18:55 -0000 On Dec 3, 2017, at 3:22 AM, Peter Deacon = wrote: > draft-dekok-radext-request-authenticator-02 >=20 > This approach also makes sense conceptually and seems to be marginally = easier to manage. No changes to request attributes, no worry about = dynamic auth req and no sequence counter to maintain when generating ORA = response. That was a major goal in the design. > This approach offers a small benefit ORA response always unambiguously = correlated with requesting peer avoiding possibility of (C.) behavior in = proxy chains. It does have the possibility of a server sending the ORA attribute = back in a response when it's not supposed to. In that case, an = old-style proxy *could* forward that attribute downstream. We then have = two cases: - the downstream proxy / client doesn't implement the draft, in which = case the attribute is ignored - the downstream proxy / client does implement the draft, but hasn't = negotiated it with the upstream (which doesn't implement it), and = therefore the attribute is ignored. So the change is compatible with existing servers for all possible = scenarios. > I don't agree with client behavior when ORA is expected yet missing. = The response should always be to silently ignore request. Certainly = mandatory fallback mechanism for static configuration is going way too = far in dictating behavior / controlling operator preference. That's certainly a good option. I tried to cover all possible = scenarios in the draft, with recommended behaviour. But I'm open to = changing the recommendations. > Wouldn't count on those who elect to implement a mechanism like this = to also spend too much time working viable scalable connection = management to provide useful interop with servers that don't support ORA = otherwise to be honest likely wouldn't be much point in implementing = this draft in the first place. In my view it should not be assumed = fallback is harmless or even a viable option. I'm happy with that. i.e. if the server sends bad packets, the client should ignore them. Alan DeKok. From nobody Mon Dec 4 10:48:58 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F3C128891 for ; Mon, 4 Dec 2017 10:48:56 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20150623.gappssmtp.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 tCskmoo4QIcT for ; Mon, 4 Dec 2017 10:48:54 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 260E61287A3 for ; Mon, 4 Dec 2017 10:48:54 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id i40so23422563qti.8 for ; Mon, 04 Dec 2017 10:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=K9WoO3KkLsV5RiU7sbBClBBo99fWjIWPKNdLM2v7sqA=; b=cGARINs+dRjnCsGZvqN1QeZGhyXdGBvfuLp0Bqdy9+OuOfA4da/o52ttDWi8OnOTpP bSL5brcolACFaBeQ5Aq0ZITwvelJ6FESIE/0ath/MwX/VJEb3TC0V5cxiZR59uYLdis9 h1xpLuycfjo58Jb9zzO7NhbMz0cC9u3T5Skv0HCMWbqVuXJenY/0p/NQoF7Pjm32wMnv Cxsc5L6DGw8OTlV7JeMtrskN0jODn8enZY2ejUtw/3JRVtoiYR7Byhc8uempmZaQEFVQ DOHrGDISOv1lVCMZI5iratMjYqYycwoqsad+/FC34gHVooFyDirahnRTO9uvfS2bgPxu Deag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=K9WoO3KkLsV5RiU7sbBClBBo99fWjIWPKNdLM2v7sqA=; b=YsQrkr9ei0+DV0kLJdz15sR0AAYeDJZXXd7a/W4J25Xmz8dwIZxaabYE23D84/0GuE xxJBW2skpAHqa4jrdgxEpVeOf4mkdeVHTufDY/Xnib+17gEmTTvxXT+lFJkOJvqLtvwg 0YAQIVsPUEzSmKf8iGQnVeDu8rVK7K5by56dyjkmjw23ZkrsHtiI/voGuj+E4xI2xIUU RrHtOcgeFMVbcBCKkG+xNpoa4GHHkcvS+62xjgr3yHz73O+xAaVJ9zSXFPng1ivzs83X uqSnXnNYHyna0dyuCqRvqirP6MQUK5CaABHWgSTlCGv9rX/M21vKam95hsppUypStRCt NBXg== X-Gm-Message-State: AKGB3mL2R+TVLwpY7adlabFQ3Nz4G8a/IliC6/x3Ut9d4D86rX9gAh6T +MFPJq/AqfVV6j4XHj5gnM2gZlvbiLhoHDi1ZXhxpg== X-Google-Smtp-Source: AGs4zMZokWyrPR1km2jPHuH7W4PHLM56RgXKvrsS1l/h/wBiZGt2RGePrhZCjETLoUyuozVcoeYWhtF9TtGHnJtR6Lo= X-Received: by 10.200.56.34 with SMTP id q31mr8850qtb.64.1512413333108; Mon, 04 Dec 2017 10:48:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.20.81 with HTTP; Mon, 4 Dec 2017 10:48:52 -0800 (PST) In-Reply-To: <8C4CACF8-3940-4209-B44F-C501DAE945CA@deployingradius.com> References: <8C4CACF8-3940-4209-B44F-C501DAE945CA@deployingradius.com> From: Stig Venaas Date: Mon, 4 Dec 2017 10:48:52 -0800 Message-ID: To: Alan DeKok Cc: Peter Deacon , Winter Stefan , radext@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 18:48:56 -0000 I prefer draft-chen-radext-identifier-attr-02. While both approaches can work, I prefer not to overload the RA. The draft needs some more work, but I believe it is ready for adoption. Stig On Sun, Dec 3, 2017 at 6:18 AM, Alan DeKok wrot= e: > On Dec 3, 2017, at 3:22 AM, Peter Deacon wrote: >> draft-dekok-radext-request-authenticator-02 >> >> This approach also makes sense conceptually and seems to be marginally e= asier to manage. No changes to request attributes, no worry about dynamic = auth req and no sequence counter to maintain when generating ORA response. > > That was a major goal in the design. > >> This approach offers a small benefit ORA response always unambiguously c= orrelated with requesting peer avoiding possibility of (C.) behavior in pro= xy chains. > > It does have the possibility of a server sending the ORA attribute back= in a response when it's not supposed to. In that case, an old-style proxy= *could* forward that attribute downstream. We then have two cases: > > - the downstream proxy / client doesn't implement the draft, in which cas= e the attribute is ignored > > - the downstream proxy / client does implement the draft, but hasn't nego= tiated it with the upstream (which doesn't implement it), and therefore the= attribute is ignored. > > So the change is compatible with existing servers for all possible scen= arios. > >> I don't agree with client behavior when ORA is expected yet missing. Th= e response should always be to silently ignore request. Certainly mandator= y fallback mechanism for static configuration is going way too far in dicta= ting behavior / controlling operator preference. > > That's certainly a good option. I tried to cover all possible scenario= s in the draft, with recommended behaviour. But I'm open to changing the r= ecommendations. > >> Wouldn't count on those who elect to implement a mechanism like this to = also spend too much time working viable scalable connection management to p= rovide useful interop with servers that don't support ORA otherwise to be h= onest likely wouldn't be much point in implementing this draft in the first= place. In my view it should not be assumed fallback is harmless or even a= viable option. > > I'm happy with that. > > i.e. if the server sends bad packets, the client should ignore them. > > Alan DeKok. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Mon Dec 4 11:51:16 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41CF12894A for ; Mon, 4 Dec 2017 11:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 7q4BRCQDeeht for ; Mon, 4 Dec 2017 11:51:14 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E50128891 for ; Mon, 4 Dec 2017 11:51:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2200; q=dns/txt; s=iport; t=1512417073; x=1513626673; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=pE0V6cdBJN/F73lHurkQWGPGuQnNzr45+f8HvnGUMZo=; b=R9PomCzH4O3EzD5azqg/JL80HC2o/nQMBSQF/uNRiZD36VzK+z1zm4BH qBSYOc/wpqPOFXxCEqcUXPPw6EyNHcETreu2znYs7fj/CpECC+Wn/HeSU N2f+X0jG8IiIfblrImvzRXUiYuY0mHAdNiTEHEUTJd+dw2Ej5xa7Nd3Ak o=; X-IronPort-AV: E=Sophos;i="5.45,361,1508803200"; d="scan'208";a="317951728" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Dec 2017 19:51:13 +0000 Received: from [10.156.165.134] ([10.156.165.134]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vB4JpCZh026675; Mon, 4 Dec 2017 19:51:13 GMT To: Stefan Winter References: Cc: radext@ietf.org, Enke Chen , Naiming Shen From: Enke Chen Message-ID: <8b7791e4-6328-ae4c-8dce-f77b32c321c1@cisco.com> Date: Mon, 4 Dec 2017 11:51:12 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 19:51:16 -0000 Hi, Stefan: 1) I prefer draft-chen-radext-identifier-attr-02. 2) I believe that the draft offers a simple, and straightforward solution to the problem without overloading any unrelated fields. 3) The implementation is pretty simple too, about 190 lines of C code for the complete implementation (client / server /proxy, and both UDP and TCP)) in FreeRadius as posted in April 2017 to the RADEXT WG: https://www.ietf.org/mail-archive/web/radext/current/msg09905.html 4) For a summary of the draft, please see the slides: https://datatracker.ietf.org/meeting/99/materials/slides-99-radext-radius-extended-identifier-attribute/ Thanks. -- Enke On 11/28/17 5:54 AM, Stefan Winter wrote: > Hello, > >> thanks all for raising the awareness of these two drafts. >> >> >> I think it would be good if all remaining readers of this list who care >> enough now take some time to read both drafts and make up their mind on >> what the preferred approach is. >> >> >> In approx. two weeks' time I will start a call for adoption on both >> drafts, and hopefully there are enough responses to make the exercise >> meaningful. If so, the one with more votes wins. > > Now that was a relaxed "two weeks" delay. My apologies, I've been on and > off work for a while, with substantial backlogs. > > This email starts a two week call for adoption of at most one of the > following two drafts: > > * draft-chen-radext-identifier-attr-02 > * draft-dekok-radext-request-authenticator-02 > > Since the two drafts treat the same topic, at most one can be selected > to serve as the basis for future work. > > In your reply to this call for adoption, please indicate which of the > two drafts you think should be adopted. You can of course also indicate > that none of the two are fit for purpose. The only thing you really > shouldn't do is to vote for both; that wouldn't help the discussion move on. > > Please reply by 12 dec 2017 2400 UTC. > > Greetings, > > Stefan Winter > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Mon Dec 4 20:26:54 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B63E124E15 for ; Mon, 4 Dec 2017 20:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 Y6H_CHcWkWpd for ; Mon, 4 Dec 2017 20:26:51 -0800 (PST) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 624EA120454 for ; Mon, 4 Dec 2017 20:26:51 -0800 (PST) Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 4 Dec 2017 20:26:51 -0800 Date: Mon, 4 Dec 2017 20:26:53 -0800 (Pacific Standard Time) From: Peter Deacon To: "Jakob Heitz (jheitz)" cc: "radext@ietf.org" In-Reply-To: <8DE62B3C-D2FA-4467-9CCE-7F8D039B87E2@cisco.com> Message-ID: References: <8BD2C2F2-D42E-4B84-8F86-3A803160DD74@cisco.com> , <285C5C94-578E-4293-81A2-9D73E1105ABE@deployingradius.com> <8DE62B3C-D2FA-4467-9CCE-7F8D039B87E2@cisco.com> User-Agent: Alpine 2.21.1 (WNT 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 04:26:53 -0000 On Fri, 1 Dec 2017, Jakob Heitz (jheitz) wrote: > What if the quantum computers turn out to live up to their promises? > Then we can throw out all this authentication stuff and decide to not > share our Ethernets with the attackers instead. No more request > authenticator. RADIUS security already lost cause no matter what :( Best practice for many years - use a secure transport and or RADIUS over (D)TLS. Regardless of selected security option in all cases operation of authenticator is maintained. > The request authenticator is already overloaded. It may be used for the > CHAP challenge. Now, you want another overload? Authenticator currently also used for at least following: Tunnel Passwords Message-Authenticator PAP CHAP MPPE Keys Clearly no possibility of authenticator ever changing in RADIUS protocol without creation of an incompatible replacement. In event of an incompatible replacement there would be no need for either of these two drafts. I am aware of no practical downside to "Overloading". regards, Peter From nobody Sat Dec 9 08:27:03 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF34126C25 for ; Sat, 9 Dec 2017 08:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 Uej-mFUYI6vr for ; Sat, 9 Dec 2017 08:26:57 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id E2733129353 for ; Sat, 9 Dec 2017 08:26:56 -0800 (PST) Received: from crashant.home (host31-53-99-35.range31-53.btcentralplus.com [31.53.99.35]) by mail.networkradius.com (Postfix) with ESMTPSA id BA81338D for ; Sat, 9 Dec 2017 16:26:55 +0000 (UTC) From: Arran Cudbard-Bell Content-Type: multipart/signed; boundary="Apple-Mail=_ACFD6EFE-375B-4CD8-8667-CAD71C9A6089"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 9 Dec 2017 16:26:54 +0000 References: To: radext@ietf.org In-Reply-To: Message-Id: <0A8C8EAE-BB3D-4751-AFFC-645AF662E28C@freeradius.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 16:27:02 -0000 --Apple-Mail=_ACFD6EFE-375B-4CD8-8667-CAD71C9A6089 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Stefan, My vote is for draft-dekok-radext-request-authenticator-02. I think the implementation will be simpler in the majority of cases and = I see no issues with overloading the authenticator field. -Arran --Apple-Mail=_ACFD6EFE-375B-4CD8-8667-CAD71C9A6089 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEE6VbEmJeQrF8361hu/6TVgp+218oFAlosDs4ACgkQ/6TVgp+2 18qTORAAgQ4uXYwgSGg9VQ/mWYumsKVclTiS0Lnd5BzCbokKE8Nz3YZN8PLTNdNc r+zsu2ya+nvNzOIi1ZoYIQgUZkWkkqmQqFvehmadbKiUDHVsMd7UpIgDCc1zcgiX 5qSZRlpQJ5vzRj1umdD7yodFIAKHemh8iBEj78RbFlWxoPYZ7sltH26WMdcJbtRS LvOgNf1PbYYhatZTXgH8RxkxlwFlGQMMZOO4TtOnlGWNZe5bJLV8mkNkUx8XPm0G qR+8n93a1Z+aaqpvGYq2oAlXjIHDzMW8xRT+ss3fRUNZnSK/bJ9KnpwB/6mTh/fp GtfdEMdfUyuiB/VPaaJXlMEmSNNZhAhcgJi/o4PcvUY4b5N42MAbFqsY08MAgz6w oryV/dI8+8s9aAho5p8gLecM4XRAiO/LPc16dWER0Cdf4/lgVPhE4g7hzmebIiVq Th9mFiPAzmRwX+ap8YWW7Qua+7pMxOMSHsYLzBHnP1bRd//HNXyEhirILfe/kSfB J4ifddqHRIndfgjZH6dAKkSQEkhodtmjI6KDVWfRxVSB5ImLbcS8JS0fqwXyE+r0 37mu1DDaUAePob3FM2XG3qwCdKpsXP4t2jbKETqrv8uaTIkiJtzWtahD6Cfioqel cLdF0u7A5GWDWx3cxKA6TRGXDe9kT51b6wddYI7ls+dDsTp8Auo= =lYOk -----END PGP SIGNATURE----- --Apple-Mail=_ACFD6EFE-375B-4CD8-8667-CAD71C9A6089-- From nobody Sun Dec 10 06:17:07 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79A112785F for ; Sun, 10 Dec 2017 06:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=arberg-dk.20150623.gappssmtp.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 IqjmdQ3I1p8v for ; Sun, 10 Dec 2017 06:17:04 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 719B51273E2 for ; Sun, 10 Dec 2017 06:17:04 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id g75so10167730wme.0 for ; Sun, 10 Dec 2017 06:17:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arberg-dk.20150623.gappssmtp.com; s=20150623; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=K6fDZz1ISgBM7PfKcQpqggBIBxLi0jMwfiBdyYq5cnU=; b=NQU7UaWNr10XC0L1FV2eC/U4rz1Yif67RkPFu2sx1ttpMNkNCaHBT2wS/mEnmigNAQ 6/hFjOC8LsRkX1fOsKplCvfkV+0Gqwy+/Ypys9HFNl3ScZmR3tYlZUt0lv5vAz921ni+ 8HBb33JnIUfIJFZnKe5qJUPgg6uDqKQbm6e1fMqQ5awQiMDg+paJ/NClCwtNt6A0m+Yw WrKaPBDDlEj4TrsU4sgK1YwdAZZIXdDdmkE3Ende/zT/caLn97dYIkmSfKSXIduR69tq 1jp94K8AIvEcdh5hyuvnmnNNWFq7nn1CYwzuCWK37vAE8+vz9fNQAv5K5pBoYjJs7La9 gRtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=K6fDZz1ISgBM7PfKcQpqggBIBxLi0jMwfiBdyYq5cnU=; b=KHAsH4r7fV7YUdMqGP+ZaxSSVbRdOpJbW2WBF5UDJ+QFjo/KBwDvxhHTNFC1X++uGi ib9f6aeUJ+YHbcCRl+3YuHhxz0Qi3IwthaRDyhs9y8es+/GdjJ0Tq6B9fAbN5z6qXbcg kiS/VTDkuQUqHZ1XP5tjo4yTG1mwfFgtVfJLt9Yn6I7l0FXGFIVSKJNZB//W9cX5umjB PQp1aGhQRkRS+8bhMLQ5RmWLOJ5c0M/OqJ4cXeiCjxdssiWX4hWcGgfMdgC4a4uciFpa 29OwU2DYL+dusKfgG5P6j6QyU3zx3aFr6ptEt1apqEWdSjrMjp4QpHh+EO/yZMRPFmoM hBfA== X-Gm-Message-State: AJaThX4rQ9NY/A/VrspvKD5M7SkaMUiMsIs6W4kfEIa9A47JCLGGrOvR 64LyAe2MpA1UOC+3vupJXZnRhVDI X-Google-Smtp-Source: AGs4zMaSxyFPHfW05/SIkbJsIJetawc+NAHTszkUxPfZd0ybtK9b6p64qYh5H5IXzHZr2CGqv/HJkw== X-Received: by 10.80.222.1 with SMTP id z1mr52508332edk.277.1512915422688; Sun, 10 Dec 2017 06:17:02 -0800 (PST) Received: from PAX1G5 ([85.191.21.234]) by smtp.gmail.com with ESMTPSA id d5sm5503822edj.65.2017.12.10.06.17.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Dec 2017 06:17:02 -0800 (PST) From: To: References: In-Reply-To: Date: Sun, 10 Dec 2017 15:17:01 +0100 Message-ID: <073d01d371c1$8ca72f30$a5f58d90$@arberg.dk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_073E_01D371C9.EE6E0830" X-Mailer: Microsoft Outlook 16.0 thread-index: AdNxv7+gY98521XaSJablhe31FzrWQAAW6vQ Content-Language: da Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 14:17:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_073E_01D371C9.EE6E0830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Stefan: I prefer draft-chen-radext-identifier-attr-02. I believe that the draft offers a simple, and straightforward solution to the problem without overloading any unrelated fields. Thanks, Peter ------=_NextPart_000_073E_01D371C9.EE6E0830 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Stefan:

 

I prefer = draft-chen-radext-identifier-attr-02.

 

I believe that the draft offers a = simple, and straightforward solution to the problem =

without = overloading any unrelated fields.

 

Thanks,

Peter

------=_NextPart_000_073E_01D371C9.EE6E0830-- From nobody Sun Dec 10 08:31:14 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5C5128B93 for ; Sun, 10 Dec 2017 08:31:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lG6Si8Z_IUUN for ; Sun, 10 Dec 2017 08:31:11 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 D830E124D6C for ; Sun, 10 Dec 2017 08:31:10 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id g9so32329732qth.9 for ; Sun, 10 Dec 2017 08:31:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7Rbh0+iCP09RRSWz/0YR8olFacuR1zZSG2F14tdVeSc=; b=rOWlnTwAYsx7ozaDhLITPbT6d6799ORkv/zAVQmold1ycZnBmCFf6yP9gKtMPuZMnA BgiafVfOi985araDPRunKG1veDIa3GOxh8ftQOF5q03WmVAqoWUjz/2+Wznmwu3Diw75 UWeZ1c0sOjpatQnJPLlZ0bQ2dZB1onSejWVGg+BJxGtrYbMqvqxUPXL6DJ+RxNWEt5h3 88+28x7xLMnx2zS3stPbrXmfajxarylNW7hs8BDs9T0hQux+AEZjN4KD6JRvqiIuNbru 73vjU+A1bvSxQwjbuzLJm8Zh/tEzuzXM2T3a+XvUf49CTi8oVQ9j0Cgndd2syrMK8ixD LD9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7Rbh0+iCP09RRSWz/0YR8olFacuR1zZSG2F14tdVeSc=; b=c2uN7LoSfAXWumLL4RLF1AqX79C5tXVEilITcQ7DnxLnXTUSH8kt8E6fRrtVw5R8lb FF1l5Ga9D++Rhe+gIyUJdXhmYRYuL5S0OQrI4SnpEbYyEQJZvQRmWKo+otGdUpMF1FwM KgELovtlxgXBnsq/E/0xkH13wqW5OT/iSBDmOV4kEFeYFsry/qPiVRZS9FQcj0ttxkJT uSMBF7UBWLWzBLj/lDqH5QxtuW74p9sbfvwf4iQzuL+iAPVY/gZbxhL/J5/kzWam+W+C 3004tPbLiB4vzdt01QkDYhBY+1AQni2ueBpevQtZMOeHa9JKMTtvIwLqhNi9RP+dT+6p ai7A== X-Gm-Message-State: AJaThX4zQliXtuo3G8UPkOQFzz645U3F6oaImtWs+0iY9HwGkXSShTQo W9lllGoty/V+IqF15FuB4lvtsDPR X-Google-Smtp-Source: AGs4zMb2tK1df0GPVlO8A8bNmqUX6HCCJYTs8I3vkIivOdb+fPGdWk22b+RIa7WMPkAPueNryQmQhg== X-Received: by 10.129.78.73 with SMTP id c70mr24949426ywb.300.1512923469595; Sun, 10 Dec 2017 08:31:09 -0800 (PST) Received: from [10.152.76.136] (mobile-166-172-185-140.mycingular.net. [166.172.185.140]) by smtp.gmail.com with ESMTPSA id k16sm5393841ywh.88.2017.12.10.08.31.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Dec 2017 08:31:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (15C114) In-Reply-To: Date: Sun, 10 Dec 2017 11:31:06 -0500 Cc: Winter Stefan , radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9B25ADF9-CBAF-4A1D-937E-13532C2D7B06@gmail.com> References: To: Alan DeKok Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 16:31:13 -0000 I strongly prefer draft-dekok. draft-chen takes approaches outside the mainstream of RADIUS implementations= and previous standards, and is very under-specified.=20 As a result its implementation will be much more difficult than is necessary= .=20 It extends the Status-Server message for the purpose of capability discovery= which is inappropriate and utilizes an adhoc complex data type which violat= es RFC 6929.=20 > On Nov 28, 2017, at 11:16 AM, Alan DeKok wrote= : >=20 >> On Nov 28, 2017, at 8:54 AM, Stefan Winter wro= te: >> In your reply to this call for adoption, please indicate which of the >> two drafts you think should be adopted. You can of course also indicate >> that none of the two are fit for purpose. The only thing you really >> shouldn't do is to vote for both; that wouldn't help the discussion move o= n. >=20 > I prefer draft-dekok-radext-request-authenticator-02 >=20 > If the WG decides to use draft-chen-radext-identifier-attr-02, then I bel= ieve it needs significant changes before it's ready for publication: >=20 > - use of "ad hoc" complex data type violates RFC 6929 Section 6.3 >=20 > - the negotiation can be simplified with no loss of functionality. See my= draft for examples. >=20 > - there is minimal discussion as to how this affects proxies, TCP, UDP, et= c.=20 >=20 > - there is minimal discussion of inter-operability considerations with exi= sting RADIUS solutions >=20 > - there are few guidelines for implementors >=20 > While some WG members may prefer the technical solution in draft-chen-rad= ext-identifier-attr-02, I think everyone can agree that the other proposal h= as these issues exhaustively enumerated and discussed. >=20 > Alan DeKok. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Sun Dec 10 10:23:02 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7D8126DD9 for ; Sun, 10 Dec 2017 10:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 vuDVX-ZYfvqD for ; Sun, 10 Dec 2017 10:22:58 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 24B0B126BFD for ; Sun, 10 Dec 2017 10:22:58 -0800 (PST) Received: from [192.168.2.25] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id BAF1E16B; Sun, 10 Dec 2017 18:22:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <9B25ADF9-CBAF-4A1D-937E-13532C2D7B06@gmail.com> Date: Sun, 10 Dec 2017 13:22:54 -0500 Cc: Winter Stefan , radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <447FB656-5BF9-4A58-A801-1BE1943A854A@deployingradius.com> References: <9B25ADF9-CBAF-4A1D-937E-13532C2D7B06@gmail.com> To: Bernard Aboba X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 18:23:00 -0000 On Dec 10, 2017, at 11:31 AM, Bernard Aboba = wrote: >=20 > I strongly prefer draft-dekok. >=20 > draft-chen takes approaches outside the mainstream of RADIUS = implementations and previous standards, and is very under-specified.=20 > As a result its implementation will be much more difficult than is = necessary.=20 >=20 > It extends the Status-Server message for the purpose of capability = discovery which is inappropriate and utilizes an adhoc complex data type = which violates RFC 6929.=20 My draft has that too. Though looking at it some more, it's not = strictly necessary. I would prefer explicit negotiation, even if overloading Status-Server = is ugly. Alan DeKok. From nobody Sun Dec 10 12:54:13 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2383A127522 for ; Sun, 10 Dec 2017 12:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, WEIRD_PORT=0.001] 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 XVFi5vnQQkbR for ; Sun, 10 Dec 2017 12:54:09 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 84972124217 for ; Sun, 10 Dec 2017 12:54:09 -0800 (PST) X-AuditID: c618062d-8efff70000004288-bd-5a2d9eefe771 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id AF.91.17032.FEE9D2A5; Sun, 10 Dec 2017 21:54:08 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0352.000; Sun, 10 Dec 2017 15:54:06 -0500 From: Albert Tian To: "radext@ietf.org" CC: "albert.tian@ercisson.com" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTcfkEe06hzIa0vUur41f77feu7A== Date: Sun, 10 Dec 2017 20:54:06 +0000 Message-ID: <5E3E39D8-DF21-4BBF-980F-AC2E1EE4A661@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_5E3E39D8DF214BBF980FAC2E1EE4A661ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZXLonXPfDPN0og6/dwhbnDpxjsmh5NZPN gcmjYf4ONo8lS34yBTBFcdmkpOZklqUW6dslcGXs2d3EVDB9DWPFzl/N7A2Mp5YzdjFyckgI mEgc6r3P3sXIxSEkcIRR4veaXawQznJGiba+32wgVWwCOhKvZj8A6xARUJe49PMaM4jNLGAp 8f7LXVYQW1hASeLljS9QNcoSnZ+mQdl6Ev1rOtlBbBYBVYlz12+CzeQVsJd4PfkhmM0oICbx /dQaJoiZ4hK3nsxngrhOQGLJnvPMELaoxMvH/8B2iQLN/HR7NQtEXEni4+/57BC9yRJ7u0+w Q8wXlDg58wnLBEbhWUjGzkJSNgtJ2SxGDqC4psT6XfoQJYoSU7ofskPYGhKtc+ZC2dYSZxZN ZENWs4CRYxUjR2lxQU5uupHBJkZgBB2TYNPdwXh/uuchRgEORiUe3mWtulFCrIllxZW5hxgl OJiVRHhN/YBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEec948kYJCaQnlqRmp6YWpBbBZJk4OKUa GC3+iL8+cXYXl6SqUsa8m3WtHi5LBH2V7b++PGz8ebOBTSlrv4rsryt3M1cpmf/j2+YhuMNh 7m6RA5zbDWZ5Tdv5sqJ6zrobX92ZE0y3GFruvL2rbsmdG1su3HjjsKPI/9Lx81e9D82eXl9o yCt2+ugya/1ZNZnXvtvEbJ4Tvdvkz+QCVbsk5U4lluKMREMt5qLiRACvmL+7nAIAAA== Archived-At: Subject: [radext] FW: Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 20:54:12 -0000 --_000_5E3E39D8DF214BBF980FAC2E1EE4A661ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KSSBoYXZlIHJlYWQgYm90aCBzb2x1dGlvbnMsIGFuZCBJIHRoaW5rIGJvdGggd291bGQg d29yay4gU3RpbGwgSSBwcmVmZXIgZHJhZnQtY2hlbi1yYWRleHQtaWRlbnRpZmllci1hdHRyLTAy LCBhcyBJIHRoaW5rIGFuIGV4cGxpY2l0IGV4dGVuZGVkIElEIGF0dHJpYnV0ZSB3b3VsZCBoZWxw IHRyb3VibGUtc2hvb3RpbmcgaW4gZGVwbG95bWVudHMuDQoNClRoYW5rcywNCkFsYmVydA0KDQoN Cg0KDQotLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDogUmU6IFty YWRleHRdIEV4dGVuZGVkIElEcw0KRGF0ZTogVHVlLCAyOCBOb3YgMjAxNyAxNDo1NDozMiArMDEw MA0KRnJvbTogU3RlZmFuIFdpbnRlciA8c3RlZmFuLndpbnRlckByZXN0ZW5hLmx1PG1haWx0bzpz dGVmYW4ud2ludGVyQHJlc3RlbmEubHU+Pg0KVG86IHJhZGV4dEBpZXRmLm9yZzxtYWlsdG86cmFk ZXh0QGlldGYub3JnPg0KDQpIZWxsbywNCg0KPiB0aGFua3MgYWxsIGZvciByYWlzaW5nIHRoZSBh d2FyZW5lc3Mgb2YgdGhlc2UgdHdvIGRyYWZ0cy4NCj4NCj4NCj4gSSB0aGluayBpdCB3b3VsZCBi ZSBnb29kIGlmIGFsbCByZW1haW5pbmcgcmVhZGVycyBvZiB0aGlzIGxpc3Qgd2hvIGNhcmUNCj4g ZW5vdWdoIG5vdyB0YWtlIHNvbWUgdGltZSB0byByZWFkIGJvdGggZHJhZnRzIGFuZCBtYWtlIHVw IHRoZWlyIG1pbmQgb24NCj4gd2hhdCB0aGUgcHJlZmVycmVkIGFwcHJvYWNoIGlzLg0KPg0KPg0K PiBJbiBhcHByb3guIHR3byB3ZWVrcycgdGltZSBJIHdpbGwgc3RhcnQgYSBjYWxsIGZvciBhZG9w dGlvbiBvbiBib3RoDQo+IGRyYWZ0cywgYW5kIGhvcGVmdWxseSB0aGVyZSBhcmUgZW5vdWdoIHJl c3BvbnNlcyB0byBtYWtlIHRoZSBleGVyY2lzZQ0KPiBtZWFuaW5nZnVsLiBJZiBzbywgdGhlIG9u ZSB3aXRoIG1vcmUgdm90ZXMgd2lucy4NCg0KTm93IHRoYXQgd2FzIGEgcmVsYXhlZCAidHdvIHdl ZWtzIiBkZWxheS4gTXkgYXBvbG9naWVzLCBJJ3ZlIGJlZW4gb24gYW5kDQpvZmYgd29yayBmb3Ig YSB3aGlsZSwgd2l0aCBzdWJzdGFudGlhbCBiYWNrbG9ncy4NCg0KVGhpcyBlbWFpbCBzdGFydHMg YSB0d28gd2VlayBjYWxsIGZvciBhZG9wdGlvbiBvZiBhdCBtb3N0IG9uZSBvZiB0aGUNCmZvbGxv d2luZyB0d28gZHJhZnRzOg0KDQoqIGRyYWZ0LWNoZW4tcmFkZXh0LWlkZW50aWZpZXItYXR0ci0w Mg0KKiBkcmFmdC1kZWtvay1yYWRleHQtcmVxdWVzdC1hdXRoZW50aWNhdG9yLTAyDQoNClNpbmNl IHRoZSB0d28gZHJhZnRzIHRyZWF0IHRoZSBzYW1lIHRvcGljLCBhdCBtb3N0IG9uZSBjYW4gYmUg c2VsZWN0ZWQNCnRvIHNlcnZlIGFzIHRoZSBiYXNpcyBmb3IgZnV0dXJlIHdvcmsuDQoNCkluIHlv dXIgcmVwbHkgdG8gdGhpcyBjYWxsIGZvciBhZG9wdGlvbiwgcGxlYXNlIGluZGljYXRlIHdoaWNo IG9mIHRoZQ0KdHdvIGRyYWZ0cyB5b3UgdGhpbmsgc2hvdWxkIGJlIGFkb3B0ZWQuIFlvdSBjYW4g b2YgY291cnNlIGFsc28gaW5kaWNhdGUNCnRoYXQgbm9uZSBvZiB0aGUgdHdvIGFyZSBmaXQgZm9y IHB1cnBvc2UuIFRoZSBvbmx5IHRoaW5nIHlvdSByZWFsbHkNCnNob3VsZG4ndCBkbyBpcyB0byB2 b3RlIGZvciBib3RoOyB0aGF0IHdvdWxkbid0IGhlbHAgdGhlIGRpc2N1c3Npb24gbW92ZSBvbi4N Cg0KUGxlYXNlIHJlcGx5IGJ5IDEyIGRlYyAyMDE3IDI0MDAgVVRDLg0KDQpHcmVldGluZ3MsDQoN ClN0ZWZhbiBXaW50ZXINCg0KLS0NClN0ZWZhbiBXSU5URVINCkluZ2VuaWV1ciBkZSBSZWNoZXJj aGUNCkZvbmRhdGlvbiBSRVNURU5BIC0gUsOpc2VhdSBUw6lsw6lpbmZvcm1hdGlxdWUgZGUgbCdF ZHVjYXRpb24gTmF0aW9uYWxlIGV0IGRlIGxhIFJlY2hlcmNoZQ0KMiwgYXZlbnVlIGRlIGwnVW5p dmVyc2l0w6kNCkwtNDM2NSBFc2NoLXN1ci1BbHpldHRlDQoNClRlbDogKzM1MiA0MjQ0MDkgMQ0K RmF4OiArMzUyIDQyMjQ3Mw0KDQpQR1Aga2V5IHVwZGF0ZWQgdG8gNDA5NiBCaXQgUlNBIC0gSSB3 aWxsIGVuY3J5cHQgYWxsIG1haWxzIGlmIHRoZSByZWNpcGllbnQncyBrZXkgaXMga25vd24gdG8g bWUNCg0KaHR0cDovL3BncC5taXQuZWR1OjExMzcxL3Brcy9sb29rdXA/b3A9Z2V0JnNlYXJjaD0w eEMwREU2QTM1OEEzOURDNjYNCg0KDQoNCg== --_000_5E3E39D8DF214BBF980FAC2E1EE4A661ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2Eg TmV1ZSI7DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1z b0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzI2MjgyQSI+SGk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xv cjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj5JIGhhdmUgcmVhZCBib3RoIHNvbHV0aW9u cywgYW5kIEkgdGhpbmsgYm90aCB3b3VsZCB3b3JrLiBTdGlsbCBJIHByZWZlciBkcmFmdC1jaGVu LXJhZGV4dC1pZGVudGlmaWVyLWF0dHItMDIsIGFzIEkgdGhpbmsgYW4gZXhwbGljaXQgZXh0ZW5k ZWQgSUQgYXR0cmlidXRlIHdvdWxkIGhlbHANCiB0cm91YmxlLXNob290aW5nIGluIGRlcGxveW1l bnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1 b3Q7O2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMyNjI4MkEiPlRoYW5rcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYy ODJBIj5BbGJlcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Eg TmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xv cjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzI2Mjgy QSI+LS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xv cjojMjYyODJBIj5TdWJqZWN0OiBSZTogW3JhZGV4dF0gRXh0ZW5kZWQgSURzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVv dDs7Y29sb3I6IzI2MjgyQSI+RGF0ZTogVHVlLCAyOCBOb3YgMjAxNyAxNDo1NDozMiAmIzQzOzAx MDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj5Gcm9tOiBTdGVmYW4gV2ludGVyICZsdDs8 YSBocmVmPSJtYWlsdG86c3RlZmFuLndpbnRlckByZXN0ZW5hLmx1IiB0YXJnZXQ9Il9ibGFuayI+ c3RlZmFuLndpbnRlckByZXN0ZW5hLmx1PC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYy ODJBIj5UbzoNCjxhIGhyZWY9Im1haWx0bzpyYWRleHRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5yYWRleHRAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzI2MjgyQSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzI2MjgyQSI+SGVsbG8sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6 IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzI2MjgyQSI+Jmd0OyB0aGFua3Mg YWxsIGZvciByYWlzaW5nIHRoZSBhd2FyZW5lc3Mgb2YgdGhlc2UgdHdvIGRyYWZ0cy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1 ZSZxdW90Oztjb2xvcjojMjYyODJBIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzI2 MjgyQSI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMyNjI4MkEiPiZndDsgSSB0aGlu ayBpdCB3b3VsZCBiZSBnb29kIGlmIGFsbCByZW1haW5pbmcgcmVhZGVycyBvZiB0aGlzIGxpc3Qg d2hvIGNhcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj4mZ3Q7IGVub3VnaCBub3cgdGFr ZSBzb21lIHRpbWUgdG8gcmVhZCBib3RoIGRyYWZ0cyBhbmQgbWFrZSB1cCB0aGVpciBtaW5kIG9u PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzI2MjgyQSI+Jmd0OyB3aGF0IHRoZSBwcmVmZXJyZWQgYXBw cm9hY2ggaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzI2MjgyQSI+Jmd0OzxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVl JnF1b3Q7O2NvbG9yOiMyNjI4MkEiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYy ODJBIj4mZ3Q7IEluIGFwcHJveC4gdHdvIHdlZWtzJyB0aW1lIEkgd2lsbCBzdGFydCBhIGNhbGwg Zm9yIGFkb3B0aW9uIG9uIGJvdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj4mZ3Q7IGRy YWZ0cywgYW5kIGhvcGVmdWxseSB0aGVyZSBhcmUgZW5vdWdoIHJlc3BvbnNlcyB0byBtYWtlIHRo ZSBleGVyY2lzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMyNjI4MkEiPiZndDsgbWVhbmluZ2Z1bC4g SWYgc28sIHRoZSBvbmUgd2l0aCBtb3JlIHZvdGVzIHdpbnMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6 IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzI2MjgyQSI+Tm93IHRoYXQgd2Fz IGEgcmVsYXhlZCAmcXVvdDt0d28gd2Vla3MmcXVvdDsgZGVsYXkuIE15IGFwb2xvZ2llcywgSSd2 ZSBiZWVuIG9uIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMyNjI4MkEiPm9mZiB3b3JrIGZvciBh IHdoaWxlLCB3aXRoIHN1YnN0YW50aWFsIGJhY2tsb2dzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMy NjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMyNjI4MkEiPlRoaXMgZW1haWwgc3Rh cnRzIGEgdHdvIHdlZWsgY2FsbCBmb3IgYWRvcHRpb24gb2YgYXQgbW9zdCBvbmUgb2YgdGhlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh IE5ldWUmcXVvdDs7Y29sb3I6IzI2MjgyQSI+Zm9sbG93aW5nIHR3byBkcmFmdHM6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUm cXVvdDs7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzI2MjgyQSI+ KiBkcmFmdC1jaGVuLXJhZGV4dC1pZGVudGlmaWVyLWF0dHItMDI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xv cjojMjYyODJBIj4qIGRyYWZ0LWRla29rLXJhZGV4dC1yZXF1ZXN0LWF1dGhlbnRpY2F0b3ItMDI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EgTmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjoj MjYyODJBIj5TaW5jZSB0aGUgdHdvIGRyYWZ0cyB0cmVhdCB0aGUgc2FtZSB0b3BpYywgYXQgbW9z dCBvbmUgY2FuIGJlIHNlbGVjdGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzI2MjgyQSI+dG8gc2Vy dmUgYXMgdGhlIGJhc2lzIGZvciBmdXR1cmUgd29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYy ODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj5JbiB5b3VyIHJlcGx5IHRv IHRoaXMgY2FsbCBmb3IgYWRvcHRpb24sIHBsZWFzZSBpbmRpY2F0ZSB3aGljaCBvZiB0aGU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Eg TmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj50d28gZHJhZnRzIHlvdSB0aGluayBzaG91bGQgYmUg YWRvcHRlZC4gWW91IGNhbiBvZiBjb3Vyc2UgYWxzbyBpbmRpY2F0ZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2Nv bG9yOiMyNjI4MkEiPnRoYXQgbm9uZSBvZiB0aGUgdHdvIGFyZSBmaXQgZm9yIHB1cnBvc2UuIFRo ZSBvbmx5IHRoaW5nIHlvdSByZWFsbHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj5zaG91 bGRuJ3QgZG8gaXMgdG8gdm90ZSBmb3IgYm90aDsgdGhhdCB3b3VsZG4ndCBoZWxwIHRoZSBkaXNj dXNzaW9uIG1vdmUgb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5l dWUmcXVvdDs7Y29sb3I6IzI2MjgyQSI+UGxlYXNlIHJlcGx5IGJ5IDEyIGRlYyAyMDE3IDI0MDAg VVRDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2Nv bG9yOiMyNjI4MkEiPkdyZWV0aW5ncyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj5TdGVmYW4gV2ludGVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVv dDs7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzI2MjgyQSI+LS0N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMyNjI4MkEiPlN0ZWZhbiBXSU5URVI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90 Oztjb2xvcjojMjYyODJBIj5JbmdlbmlldXIgZGUgUmVjaGVyY2hlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29s b3I6IzI2MjgyQSI+Rm9uZGF0aW9uIFJFU1RFTkEgLSBSw6lzZWF1IFTDqWzDqWluZm9ybWF0aXF1 ZSBkZSBsJ0VkdWNhdGlvbiBOYXRpb25hbGUgZXQgZGUgbGEgUmVjaGVyY2hlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVv dDs7Y29sb3I6IzI2MjgyQSI+MiwgYXZlbnVlIGRlIGwnVW5pdmVyc2l0w6k8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90 Oztjb2xvcjojMjYyODJBIj5MLTQzNjUgRXNjaC1zdXItQWx6ZXR0ZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2Nv bG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMyNjI4MkEiPlRlbDogJiM0 MzszNTIgNDI0NDA5IDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj5GYXg6ICYjNDM7MzUy IDQyMjQ3MzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7 O2NvbG9yOiMyNjI4MkEiPlBHUCBrZXkgdXBkYXRlZCB0byA0MDk2IEJpdCBSU0EgLSBJIHdpbGwg ZW5jcnlwdCBhbGwgbWFpbHMgaWYgdGhlIHJlY2lwaWVudCdzIGtleSBpcyBrbm93biB0byBtZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSBOZXVlJnF1b3Q7O2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMy NjI4MkEiPjxhIGhyZWY9Imh0dHA6Ly9wZ3AubWl0LmVkdToxMTM3MS9wa3MvbG9va3VwP29wPWdl dCZhbXA7c2VhcmNoPTB4QzBERTZBMzU4QTM5REM2NiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9w Z3AubWl0LmVkdToxMTM3MS9wa3MvbG9va3VwP29wPWdldCZhbXA7c2VhcmNoPTB4QzBERTZBMzU4 QTM5REM2NjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZx dW90Oztjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMjYyODJBIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_5E3E39D8DF214BBF980FAC2E1EE4A661ericssoncom_-- From sudhirjain@outlook.com Mon Dec 11 15:40:24 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A180128BB7 for ; Mon, 11 Dec 2017 15:40:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 gDYmdCqGDcFD for ; Mon, 11 Dec 2017 15:40:22 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-oln040092009079.outbound.protection.outlook.com [40.92.9.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63FF4128B91 for ; Mon, 11 Dec 2017 15:40:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y9tzRKcG4mFyLzTEHJKZukhf7lz9LWNSfeSXwDFl6T0=; b=cK450cS/lJ5FyvBfsSnjeIALSsenkIxufiH+W9jYFi8Vzr433/8rOLELBEqgSDN4Jrek7eIN/4RUKy1hSw2a9Klsft19FV8lki26OpmP+8/DGzkTksvnynWTWFiwp+JXYGFmUxO52pNq33c7G1uS5alx5RVHVmY+pgkucMbft6ZTy9B3OPqaGo2LCrM2ZTUeH7fusU6NRIxUjjaja495RLIUuIJFxoFHiOtQ8zPlppbMLKJ6xRVXppL6a49MLo1VlkoPOEfR/eXfoqS16lRcJBIprLI8w0q9Ua0Wv5njslqI3EzUxZsqYHxDC0n7b0oyReRFEFiSBr3tHq3WWsIcWw== Received: from CO1NAM04FT052.eop-NAM04.prod.protection.outlook.com (10.152.90.57) by CO1NAM04HT179.eop-NAM04.prod.protection.outlook.com (10.152.90.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.282.5; Mon, 11 Dec 2017 23:40:21 +0000 Received: from DM5PR0401MB3622.namprd04.prod.outlook.com (10.152.90.59) by CO1NAM04FT052.mail.protection.outlook.com (10.152.91.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.282.5 via Frontend Transport; Mon, 11 Dec 2017 23:40:20 +0000 Received: from DM5PR0401MB3622.namprd04.prod.outlook.com ([fe80::c472:107b:d8af:cf25]) by DM5PR0401MB3622.namprd04.prod.outlook.com ([fe80::c472:107b:d8af:cf25%13]) with mapi id 15.20.0302.013; Mon, 11 Dec 2017 23:40:21 +0000 From: sudhir jain To: Stefan Winter , "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTctkqbu9YZA8FtU21lpYBjBrmEQ== Date: Mon, 11 Dec 2017 23:40:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:2BB7A2B3BD7EF70B42AD0F147ED9DD08A5452C90446E3CF14B4DEF72056D9841; UpperCasedChecksum:ECA744A1E13B10468E0D1C613959395ECC5BF2572D1E5864B89B83503FAA3FF1; SizeAsReceived:6878; Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [7wYM0oqTpQ3/sn63KJskIn8LSwcaqDKDV4QhXgyHX58=] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM04HT179; 6:jPqGXhAmfPKNIrfcDH3xLVKuXWxMLl4SR3yxt2xTMz8yF16ewVgwXThx+5ztZk5OK5CPzWu8LzDvjNEbhG/BYO8FGb82z/W0g3mmTiw4er/Y5AO6aqJY2t81iOTe9OXJ00QEtgaeg06kbcFz3/3BtAY2DuvazzVwjuIIwI1sFUIM9T70TKgKvXfvpRkoUoc2qED3EBW8vq8HcaXpndChMQHfjDaktm0AYgsjHCXQIMCBo+z8/vg9EBJ4IvWVMnqsp5nfsQjvtrCf0zGw5gqQdGG0WOpt9KfbQWJi+cxEAV1bMH8R0NmRMWs3bn1zbq8/+hrDbxd6jHG7iO4R2LkomnZuJxKwu4m80bBC1Qb9U4U=; 5:ShusoJg8XrfkYLxa2Ikok/ZZ2WqcmQaNlWtj0hGTF45dD/+PY+CCjO0abNyGBWXlmRP9d1prHtiT1lOamN6nzx3kjYIsfe6PKp/7kjp1kaK8OgxP70tfBsj0Mq7qi8mh9tZ5uQ1NiEqm7W/qv2Yq4ntvDh/hbDvCHE9ntCbQLs0=; 24:eB3cdM7LuO1gY7uZoZt7WrA9IW0bkmSD+HZxfucqR85LfayliA2NGsnctEWa/GtoLoRmcl+v8xZsF1DzpAL8/hsCRfaCTwxCbQtzo3QPV/E=; 7:E4HpTx0ti8AqznVWnWVjEQt19ZpW3BLB/73xur+dn3aWyJ6Rll2todCtIJT5Ech3eZHa/QXtm73NGNbL2/MiNZjMBU3V8DPI2vrKaFmPBWFTwhuZfN9z/Nq51rEre2mKMf8FYsyIG/hFKgCwCfa09W/HfMevVTYxqcBcmN4sGz6V9kSRqN0k/9xfya2o7mK31TS4Lzp/eoZdcLfqgHG0WrBGCC2MBFg1mQffgRggYy4u/wBpqy3gzHX1uCGCjmqz x-incomingheadercount: 44 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:CO1NAM04HT179; x-ms-traffictypediagnostic: CO1NAM04HT179: x-ms-office365-filtering-correlation-id: 260ea675-ae22-4aa9-5b11-08d540f08af5 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:CO1NAM04HT179; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CO1NAM04HT179; x-forefront-prvs: 0518EEFB48 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM04HT179; H:DM5PR0401MB3622.namprd04.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR0401MB3622AC75AB58E9A10890F49BC1370DM5PR0401MB3622_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 260ea675-ae22-4aa9-5b11-08d540f08af5 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2017 23:40:21.0144 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT179 Archived-At: Subject: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 23:47:38 -0000 --_000_DM5PR0401MB3622AC75AB58E9A10890F49BC1370DM5PR0401MB3622_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I support adoption of draft-chen-radext-identifier-attr-02. I think this is a batter approach compare to other proposal. Thanks, Sudhir Jain --_000_DM5PR0401MB3622AC75AB58E9A10890F49BC1370DM5PR0401MB3622_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,


I support adopt= ion of draft-chen-radext-identifier-attr-02. I think this

is a batter app= roach compare to other proposal. 


Thanks,<= /p>


Sudhir Jain


--_000_DM5PR0401MB3622AC75AB58E9A10890F49BC1370DM5PR0401MB3622_-- From nobody Mon Dec 11 16:55:22 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC874128D0D for ; Mon, 11 Dec 2017 16:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 vJDswtyocyGV for ; Mon, 11 Dec 2017 16:55:20 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B1F126DFE for ; Mon, 11 Dec 2017 16:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1710; q=dns/txt; s=iport; t=1513040120; x=1514249720; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=uAwujpKx2r4PkHycVfHNqFLTOLm6RREwzbkrSSB6MFY=; b=LUBiWS47mu4PHWQfJAWJnt1LMv2PjbLxfp2jlW62avX9XFywJJ9TBByn 1W97AE2Kg2PjAmQ7//k0cMkc1rdMAjy/0YWaL+ZWpOjTyZaaR9D4E0FDm c5oVBHJFQ+p8HwGxdA6SFx27qjINi8r/KHXlLG2RLV93Ntqdh0nDsQDRH U=; X-IronPort-AV: E=Sophos;i="5.45,393,1508803200"; d="scan'208";a="43318768" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Dec 2017 00:55:19 +0000 Received: from [10.156.165.56] ([10.156.165.56]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vBC0tI1Q024172; Tue, 12 Dec 2017 00:55:19 GMT To: Winter Stefan References: Cc: Alan DeKok , radext@ietf.org, Enke Chen , Naiming Shen From: Enke Chen Message-ID: <963470f4-8cd5-e278-c5f1-bfeff41c6a5f@cisco.com> Date: Mon, 11 Dec 2017 16:55:18 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 00:55:22 -0000 Hi, Folks: Apologies for not being able to reply earlier. We are certainly open to revising the draft based on suggestions from Alan and other members, and will start working on it should draft-chen-radext-identifier-attr-02 be adopted by the WG. Thanks. -- Enke On 11/28/17 8:16 AM, Alan DeKok wrote: > On Nov 28, 2017, at 8:54 AM, Stefan Winter wrote: >> In your reply to this call for adoption, please indicate which of the >> two drafts you think should be adopted. You can of course also indicate >> that none of the two are fit for purpose. The only thing you really >> shouldn't do is to vote for both; that wouldn't help the discussion move on. > > I prefer draft-dekok-radext-request-authenticator-02 > > If the WG decides to use draft-chen-radext-identifier-attr-02, then I believe it needs significant changes before it's ready for publication: > > - use of "ad hoc" complex data type violates RFC 6929 Section 6.3 > > - the negotiation can be simplified with no loss of functionality. See my draft for examples. > > - there is minimal discussion as to how this affects proxies, TCP, UDP, etc. > > - there is minimal discussion of inter-operability considerations with existing RADIUS solutions > > - there are few guidelines for implementors > > While some WG members may prefer the technical solution in draft-chen-radext-identifier-attr-02, I think everyone can agree that the other proposal has these issues exhaustively enumerated and discussed. > > Alan DeKok. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Mon Dec 11 17:09:00 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80049126DFE for ; Mon, 11 Dec 2017 17:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 F-lEgS8dliPI for ; Mon, 11 Dec 2017 17:08:57 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FAD5128D44 for ; Mon, 11 Dec 2017 17:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5408; q=dns/txt; s=iport; t=1513040937; x=1514250537; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=be3wrjeGQLA0QCSqQ5Pn/BioH4UdewCR7rjZRwvpkYY=; b=BF945BU+xxGHeyGfrtG7aHhM810+yV6hAMiN7ff2HA+J2LxAS7BXcO/s N53jAN1fMCyQki+/kHVzX1qx3tDGK0YMsbPt6T552DJd/WNBoogWCNA9u nr3FiS0qk2VuPaG7BDC+iEC277P9I9O0sx3NQc+fyn1xKpQVdVGJwmJRP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAgB8Ky9a/5ldJa1RBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgw8vZnQnB4M4Q5khgVcmlwwUggEKGAuDX1UVTwIahFhBFgE?= =?us-ascii?q?BAQEBAQEBAWsohSIBAQEBAgEBAQoRBhEzBwsFCwIBBgIYAgImAgICJQsVEAIED?= =?us-ascii?q?gUWigoIEIoVnWyCJ4ppAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYEPglmBaSKDaAu?= =?us-ascii?q?Cd4NJgSMBCAoBCRYXCiaCTjGCMgWjEQKHd40oghaGEoQNhy6WMQIRGQGBOgEmD?= =?us-ascii?q?CZhbm8VOioBgX4JhEx4iCWBJIEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,393,1508803200"; d="scan'208";a="334208176" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2017 01:08:51 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBC18pVc026806 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Dec 2017 01:08:51 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 11 Dec 2017 20:08:50 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1320.000; Mon, 11 Dec 2017 20:08:50 -0500 From: "Brian Weis (bew)" To: Stefan Winter CC: "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTKHKmN0OvqHUzwEy8+4sqgJSsZaMqo8EAgBUquQA= Date: Tue, 12 Dec 2017 01:08:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.173.230] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 01:08:59 -0000 SeKAmXZlIHJlYWQgdGhyb3VnaCB0aGUgbGF0ZXN0IHZlcnNpb25zIG9mIGJvdGggZHJhZnRzLCBh bmQgSSBkbyBwcmVmZXIgdGhlIGFwcHJvYWNoIHRha2VuIGluIGRyYWZ0LWNoZW4tcmFkZXh0LWlk ZW50aWZpZXItYXR0ci4NCg0KRnJvbSBhIHByb3RvY29sIHBlcnNwZWN0aXZlLCB0aGUgdHdvIGFw cHJvYWNoZXMgZG8gbm90IHNlZW0gdmVyeSBmYXIgYXBhcnQgdG8gbWUuIFRoZXkgYm90aCBzZWVt IHRvIGRvIHRoZSBmb2xsb3dpbmcuICgxKSBEZWZpbmUgYSBuZXcgcGVyLWNvbm5lY3Rpb24gYXR0 cmlidXRlIGFzIHBhcnQgb2YgYSBTdGF0dXMtU2VydmVyIG1lc3NhZ2UuICgyKSBTcGVjaWZ5IHRo YXQgYSBjbGllbnQgY2hvb3NlcyB3aGVuIHRvIHVzZSBhIGxhcmdlciBpZGVudGlmaWVyLiAoMykg U3BlY2lmeSB0aGF0IHdoZW4gdGhlIHNlcnZlciByZWNvZ25pemVzIHRoZSDigJxuZXcgZXh0ZW5k ZWQgZmllbGTigJ0sIHRoZW4gaXQgaXMgb2JsaWdhdGVkIHRvIHJldHVybiB0aGUgb3JpZ2luYWwg dmFsdWVzIG9mIGJvdGggaWRlbnRpdHkgZmllbGQgYW5kIHRoZSDigJxuZXcgZXh0ZW5kZWQgZmll bGTigJ0uICg0KSBUaGUgc2VydmVyIG5lZWQgbm90IGhhdmUgYW55IGtub3dsZWRnZSBhcyB0byBo b3cgdGhlIOKAnG5ldyBleHRlbmRlZCBmaWVsZOKAnSBpcyBkZXRlcm1pbmVkLiAgKDUpIElmIHRo ZSBzZXJ2ZXIgZG9lcyBub3QgcmVjb2duaXplIHRoZSBuZXcgYXR0cmlidXRlLCBpdCBpZ25vcmVz IGl0LiBTbyBpbiBuZWl0aGVyIGNhc2UgZG8gdGhhdCB0aGUgbWVjaGFuaXNtIHNlZW0gdG8gdW5k dWx5IG1vZGlmeSBSQURJVVMuDQoNCkl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIHJlYWwgZGlmZmVy ZW5jZSBjb21lcyBkb3duIHRvIGhvdyB0aGUg4oCcbmV3IGV4dGVuZGVkIGZpZWxk4oCdIGlzIGNh cnJpZWQg4oCUIGVpdGhlciBpbiB0aGUgbmV3IHBlci1jb25uZWN0aW9uIGF0dHJpYnV0ZSwgb3Ig Ynkgb3ZlcmxvYWRpbmcgdGhlIFJlcXVlc3QgSWRlbnRpZmllci4gSSBhcHByZWNpYXRlIHRoZSBh cmd1bWVudHMgaW4gZHJhZnQtZGVrb2sgdGhhdCBpbmRpY2F0ZSB0aGF0IHRoZXJlIHNob3VsZCBu b3QgYmUgYSBwcm9ibGVtIHdpdGggb3ZlcmxvYWRpbmcsIGJ1dCBiZWNhdXNlIG92ZXJsb2FkaW5n IHByb3RvY29sIGZpZWxkcyBjYW4gY2FycnkgdW5leHBlY3RlZCByaXNrcyBteSBwcmVmZXJlbmNl IGlzIHRvIGFkb3B0IHRoZSBleHBsaWNpdCBhcHByb2FjaCBpbiBkcmFmdC1jaGVuLiBXaXRoIHRo ZSBzYW1lIHRob3VnaHQgcHJvY2VzcyBJ4oCZbSBhIGxpdHRsZSB3b3JyaWVkIGFib3V0IGRlZmlu aW5nICJiZWhhdmlvciBwcmV2aW91c2x5IGxlZnQgb3BlbiB0byBpbXBsZW1lbnRhdGlvbiBpbnRl cnByZXRhdGlvbuKAnSAoYXMgbWVudGlvbmVkIGluIFNlY3Rpb24gMi4xIG9mIGRyYWZ0LWRla29r KS4gSSBjYW5ub3QgZGlzYWdyZWUgdGhhdCBpdCDigJxzaG91bGQiIGJlIE9LLCBidXQgdGhlIGxh Y2sgb2YgY2VydGFpbmx5IGRvZXMgYWRkIHNvbWUgcmlzay4NCg0KSG93ZXZlciwgSSBhbHNvIGJl bGlldmUgdGhhdCB0aGVyZSBpcyBhIGxvdCBvZiBnb29kIGJhY2tncm91bmQgYW5kIGV4cGxhbmF0 b3J5IHRleHQgaW4gZHJhZnQtZGVrb2sgdGhhdCBpcyB2YWx1YWJsZSBhbmQgaWYgdGhlIHdvcmtp bmcgZ3JvdXAgdGFrZXMgZHJhZnQtY2hlbiBhcyB0aGUgYmFzZSB0aGVuIHNvbWUgb2YgdGhpcyB3 b3VsZCBiZSB2YWx1YWJsZSB0byBicmluZyB0aGF0IGludG8gdGhlIGRyYWZ0LiBUaGlzIG1pZ2h0 IGFkZHJlc3Mgc29tZSBvZiB0aGUgY29uY2VybnMgdGhhdCBkcmFmdC1jaGVuIGlzIHVuZGVyLXNw ZWNpZmllZC4NCg0KVGhhbmtzLA0KQnJpYW4NCg0KPiBPbiBOb3YgMjgsIDIwMTcsIGF0IDU6NTQg QU0sIFN0ZWZhbiBXaW50ZXIgPHN0ZWZhbi53aW50ZXJAcmVzdGVuYS5sdT4gd3JvdGU6DQo+IA0K PiBIZWxsbywNCj4gDQo+PiB0aGFua3MgYWxsIGZvciByYWlzaW5nIHRoZSBhd2FyZW5lc3Mgb2Yg dGhlc2UgdHdvIGRyYWZ0cy4NCj4+IA0KPj4gDQo+PiBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2Qg aWYgYWxsIHJlbWFpbmluZyByZWFkZXJzIG9mIHRoaXMgbGlzdCB3aG8gY2FyZQ0KPj4gZW5vdWdo IG5vdyB0YWtlIHNvbWUgdGltZSB0byByZWFkIGJvdGggZHJhZnRzIGFuZCBtYWtlIHVwIHRoZWly IG1pbmQgb24NCj4+IHdoYXQgdGhlIHByZWZlcnJlZCBhcHByb2FjaCBpcy4NCj4+IA0KPj4gDQo+ PiBJbiBhcHByb3guIHR3byB3ZWVrcycgdGltZSBJIHdpbGwgc3RhcnQgYSBjYWxsIGZvciBhZG9w dGlvbiBvbiBib3RoDQo+PiBkcmFmdHMsIGFuZCBob3BlZnVsbHkgdGhlcmUgYXJlIGVub3VnaCBy ZXNwb25zZXMgdG8gbWFrZSB0aGUgZXhlcmNpc2UNCj4+IG1lYW5pbmdmdWwuIElmIHNvLCB0aGUg b25lIHdpdGggbW9yZSB2b3RlcyB3aW5zLg0KPiANCj4gTm93IHRoYXQgd2FzIGEgcmVsYXhlZCAi dHdvIHdlZWtzIiBkZWxheS4gTXkgYXBvbG9naWVzLCBJJ3ZlIGJlZW4gb24gYW5kDQo+IG9mZiB3 b3JrIGZvciBhIHdoaWxlLCB3aXRoIHN1YnN0YW50aWFsIGJhY2tsb2dzLg0KPiANCj4gVGhpcyBl bWFpbCBzdGFydHMgYSB0d28gd2VlayBjYWxsIGZvciBhZG9wdGlvbiBvZiBhdCBtb3N0IG9uZSBv ZiB0aGUNCj4gZm9sbG93aW5nIHR3byBkcmFmdHM6DQo+IA0KPiAqIGRyYWZ0LWNoZW4tcmFkZXh0 LWlkZW50aWZpZXItYXR0ci0wMg0KPiAqIGRyYWZ0LWRla29rLXJhZGV4dC1yZXF1ZXN0LWF1dGhl bnRpY2F0b3ItMDINCj4gDQo+IFNpbmNlIHRoZSB0d28gZHJhZnRzIHRyZWF0IHRoZSBzYW1lIHRv cGljLCBhdCBtb3N0IG9uZSBjYW4gYmUgc2VsZWN0ZWQNCj4gdG8gc2VydmUgYXMgdGhlIGJhc2lz IGZvciBmdXR1cmUgd29yay4NCj4gDQo+IEluIHlvdXIgcmVwbHkgdG8gdGhpcyBjYWxsIGZvciBh ZG9wdGlvbiwgcGxlYXNlIGluZGljYXRlIHdoaWNoIG9mIHRoZQ0KPiB0d28gZHJhZnRzIHlvdSB0 aGluayBzaG91bGQgYmUgYWRvcHRlZC4gWW91IGNhbiBvZiBjb3Vyc2UgYWxzbyBpbmRpY2F0ZQ0K PiB0aGF0IG5vbmUgb2YgdGhlIHR3byBhcmUgZml0IGZvciBwdXJwb3NlLiBUaGUgb25seSB0aGlu ZyB5b3UgcmVhbGx5DQo+IHNob3VsZG4ndCBkbyBpcyB0byB2b3RlIGZvciBib3RoOyB0aGF0IHdv dWxkbid0IGhlbHAgdGhlIGRpc2N1c3Npb24gbW92ZSBvbi4NCj4gDQo+IFBsZWFzZSByZXBseSBi eSAxMiBkZWMgMjAxNyAyNDAwIFVUQy4NCj4gDQo+IEdyZWV0aW5ncywNCj4gDQo+IFN0ZWZhbiBX aW50ZXINCj4gDQo+IC0tIA0KPiBTdGVmYW4gV0lOVEVSDQo+IEluZ2VuaWV1ciBkZSBSZWNoZXJj aGUNCj4gRm9uZGF0aW9uIFJFU1RFTkEgLSBSw6lzZWF1IFTDqWzDqWluZm9ybWF0aXF1ZSBkZSBs J0VkdWNhdGlvbiBOYXRpb25hbGUgZXQgZGUgbGEgUmVjaGVyY2hlDQo+IDIsIGF2ZW51ZSBkZSBs J1VuaXZlcnNpdMOpDQo+IEwtNDM2NSBFc2NoLXN1ci1BbHpldHRlDQo+IA0KPiBUZWw6ICszNTIg NDI0NDA5IDENCj4gRmF4OiArMzUyIDQyMjQ3Mw0KPiANCj4gUEdQIGtleSB1cGRhdGVkIHRvIDQw OTYgQml0IFJTQSAtIEkgd2lsbCBlbmNyeXB0IGFsbCBtYWlscyBpZiB0aGUgcmVjaXBpZW50J3Mg a2V5IGlzIGtub3duIHRvIG1lDQo+IA0KPiBodHRwOi8vcGdwLm1pdC5lZHU6MTEzNzEvcGtzL2xv b2t1cD9vcD1nZXQmc2VhcmNoPTB4QzBERTZBMzU4QTM5REM2Ng0KPiANCj4gPDB4OEEzOURDNjYu YXNjPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHJh ZGV4dCBtYWlsaW5nIGxpc3QNCj4gcmFkZXh0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0DQoNCi0tIA0KQnJpYW4gV2Vpcw0KU2VjdXJpdHks IENTRywgQ2lzY28gU3lzdGVtcw0KVGVsZXBob25lOiArMSA0MDggNTI2IDQ3OTYNCkVtYWlsOiBi ZXdAY2lzY28uY29tDQoNCg== From nobody Mon Dec 11 17:52:57 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988F61270B4 for ; Mon, 11 Dec 2017 17:52:55 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 hfo0PplWGaa9 for ; Mon, 11 Dec 2017 17:52:53 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1B596126D05 for ; Mon, 11 Dec 2017 17:52:53 -0800 (PST) Received: from [192.168.2.25] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id 1E4F75F3; Tue, 12 Dec 2017 01:52:51 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Mon, 11 Dec 2017 20:52:50 -0500 Cc: "radext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2D707CD0-5C6D-4ABE-9829-820D6145E98F@deployingradius.com> References: To: "Brian Weis (bew)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 01:52:56 -0000 > On Dec 11, 2017, at 8:08 PM, Brian Weis (bew) wrote: >=20 > I=E2=80=99ve read through the latest versions of both drafts, and I do = prefer the approach taken in draft-chen-radext-identifier-attr. >=20 > =46rom a protocol perspective, the two approaches do not seem very far = apart to me. They both seem to do the following. (1) Define a new = per-connection attribute as part of a Status-Server message. (2) Specify = that a client chooses when to use a larger identifier. (3) Specify that = when the server recognizes the =E2=80=9Cnew extended field=E2=80=9D, = then it is obligated to return the original values of both identity = field and the =E2=80=9Cnew extended field=E2=80=9D. (4) The server need = not have any knowledge as to how the =E2=80=9Cnew extended field=E2=80=9D = is determined. (5) If the server does not recognize the new attribute, = it ignores it. So in neither case do that the mechanism seem to unduly = modify RADIUS. The differences are that the draft-chen proposal effectively modifies = the RADIUS header, and that it has the opportunity for "leakage" of = extended IDs in the case of error or misconfiguration. My draft has none of these issues. > It seems to me that the real difference comes down to how the =E2=80=9Cn= ew extended field=E2=80=9D is carried =E2=80=94 either in the new = per-connection attribute, or by overloading the Request Identifier. I = appreciate the arguments in draft-dekok that indicate that there should = not be a problem with overloading, but because overloading protocol = fields can carry unexpected risks Risks like... ? I must admit to being a little surprised at the dislike of = "overloading" the Request Authenticator field. As Peter Deacon pointed = out, it's already "overloaded" for many, many, other things. Given the existing definition of the Request Authenticator field, it = is *impossible* at this time to change how it's calculated. Similarly, = it's impossible to change the meaning of the field for packet = signatures. And, it's impossible to change the usage of the field = within other attributes. So we're left with a field that we cannot change, but we can look at. = What is the risk in looking at it? What is the risk in echoing it = verbatim in a response packet? I understand that saying "we add a 32-bit ID" is conceptually simpler. = But I still don't get where any "risk" or concern with "overloading" of = the field comes from. Some additional explanation would be useful here. > my preference is to adopt the explicit approach in draft-chen. With = the same thought process I=E2=80=99m a little worried about defining = "behavior previously left open to implementation interpretation=E2=80=9D = (as mentioned in Section 2.1 of draft-dekok). I cannot disagree that it = =E2=80=9Cshould" be OK, but the lack of certainly does add some risk. How? The draft goes through exhaustive enumeration of the possibilities. = It shows that the proposal is no worse than existing RADIUS, and in some = cases is substantially better. > However, I also believe that there is a lot of good background and = explanatory text in draft-dekok that is valuable and if the working = group takes draft-chen as the base then some of this would be valuable = to bring that into the draft. This might address some of the concerns = that draft-chen is under-specified. I agree. I think a large part of the concern here is due to the background and = explanatory text in my document. i.e. a proposal which describes the = risks seems risky. A proposal which ignores the risks seems less = risky. But I would still like to understand (a) what the risks are here, and = (b) why there's a concern with "overloading" a field that cannot be = changed, and is already used for many things. Alan DeKok. From nobody Mon Dec 11 18:39:50 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB05C128E19 for ; Mon, 11 Dec 2017 18:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 itMagdsxPg8N for ; Mon, 11 Dec 2017 18:39:45 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1B11270B4 for ; Mon, 11 Dec 2017 18:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6980; q=dns/txt; s=iport; t=1513046384; x=1514255984; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gIUr4DUhOVD9CbZ96hB7gOISs4kuQW1jtHVhpysubu8=; b=htEERnsVmYF3R7dSlxgPv+HaPtoo86Ls6HV/osAkm/5pYkCjfqrL/Bp+ YB9V6HkwXvYxjnSUweTSPq1xwsoFyIbmsL02jNepKQTBBcCcyLSLlt7pl gnGGxsSrLQ8cFpnPr9RLWlHoaxdnah8EWRIVsf9DpXuadqO3XDP4C0YBk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAgAQQS9a/51dJa1RBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgw8vgVonB4N7mSOBfX6WDxSCAQqFOwIahFhBFgEBAQEBAQE?= =?us-ascii?q?BAWsohSIBAQEBAgEjETMSBQsCAQgYAgImAgICMBUQAgQOBYogCKgxgieKbwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2BD4JZgguDPymCTDaEbAEICgEHAhYXCiaCTjG?= =?us-ascii?q?CMgWjEwKVH4IWiiCHMJYxAhEZAYE6ASYCMGFubxVkAYF+glIcgWd4iBiBJIEVA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.45,393,1508803200"; d="scan'208";a="42814704" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2017 02:39:44 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vBC2dhAP022046 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Dec 2017 02:39:44 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 11 Dec 2017 21:39:43 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1320.000; Mon, 11 Dec 2017 21:39:42 -0500 From: "Brian Weis (bew)" To: Alan DeKok CC: "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTKHKmN0OvqHUzwEy8+4sqgJSsZaMqo8EAgBUquQCAAAxHAIAADR6A Date: Tue, 12 Dec 2017 02:39:42 +0000 Message-ID: <1465D072-52D7-4FC3-88A6-E1A97740B753@cisco.com> References: <2D707CD0-5C6D-4ABE-9829-820D6145E98F@deployingradius.com> In-Reply-To: <2D707CD0-5C6D-4ABE-9829-820D6145E98F@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.173.230] Content-Type: text/plain; charset="utf-8" Content-ID: <620501025AE95045ADCCA54556D86A1E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 02:39:47 -0000 SGkgQWxhbiwNCg0KPiBPbiBEZWMgMTEsIDIwMTcsIGF0IDU6NTIgUE0sIEFsYW4gRGVLb2sgPGFs YW5kQGRlcGxveWluZ3JhZGl1cy5jb20+IHdyb3RlOg0KPiANCj4gDQo+PiBPbiBEZWMgMTEsIDIw MTcsIGF0IDg6MDggUE0sIEJyaWFuIFdlaXMgKGJldykgPGJld0BjaXNjby5jb20+IHdyb3RlOg0K Pj4gDQo+PiBJ4oCZdmUgcmVhZCB0aHJvdWdoIHRoZSBsYXRlc3QgdmVyc2lvbnMgb2YgYm90aCBk cmFmdHMsIGFuZCBJIGRvIHByZWZlciB0aGUgYXBwcm9hY2ggdGFrZW4gaW4gZHJhZnQtY2hlbi1y YWRleHQtaWRlbnRpZmllci1hdHRyLg0KPj4gDQo+PiBGcm9tIGEgcHJvdG9jb2wgcGVyc3BlY3Rp dmUsIHRoZSB0d28gYXBwcm9hY2hlcyBkbyBub3Qgc2VlbSB2ZXJ5IGZhciBhcGFydCB0byBtZS4g VGhleSBib3RoIHNlZW0gdG8gZG8gdGhlIGZvbGxvd2luZy4gKDEpIERlZmluZSBhIG5ldyBwZXIt Y29ubmVjdGlvbiBhdHRyaWJ1dGUgYXMgcGFydCBvZiBhIFN0YXR1cy1TZXJ2ZXIgbWVzc2FnZS4g KDIpIFNwZWNpZnkgdGhhdCBhIGNsaWVudCBjaG9vc2VzIHdoZW4gdG8gdXNlIGEgbGFyZ2VyIGlk ZW50aWZpZXIuICgzKSBTcGVjaWZ5IHRoYXQgd2hlbiB0aGUgc2VydmVyIHJlY29nbml6ZXMgdGhl IOKAnG5ldyBleHRlbmRlZCBmaWVsZOKAnSwgdGhlbiBpdCBpcyBvYmxpZ2F0ZWQgdG8gcmV0dXJu IHRoZSBvcmlnaW5hbCB2YWx1ZXMgb2YgYm90aCBpZGVudGl0eSBmaWVsZCBhbmQgdGhlIOKAnG5l dyBleHRlbmRlZCBmaWVsZOKAnS4gKDQpIFRoZSBzZXJ2ZXIgbmVlZCBub3QgaGF2ZSBhbnkga25v d2xlZGdlIGFzIHRvIGhvdyB0aGUg4oCcbmV3IGV4dGVuZGVkIGZpZWxk4oCdIGlzIGRldGVybWlu ZWQuICAoNSkgSWYgdGhlIHNlcnZlciBkb2VzIG5vdCByZWNvZ25pemUgdGhlIG5ldyBhdHRyaWJ1 dGUsIGl0IGlnbm9yZXMgaXQuIFNvIGluIG5laXRoZXIgY2FzZSBkbyB0aGF0IHRoZSBtZWNoYW5p c20gc2VlbSB0byB1bmR1bHkgbW9kaWZ5IFJBRElVUy4NCj4gDQo+ICBUaGUgZGlmZmVyZW5jZXMg YXJlIHRoYXQgdGhlIGRyYWZ0LWNoZW4gcHJvcG9zYWwgZWZmZWN0aXZlbHkgbW9kaWZpZXMgdGhl IFJBRElVUyBoZWFkZXIsIGFuZCB0aGF0IGl0IGhhcyB0aGUgb3Bwb3J0dW5pdHkgZm9yICJsZWFr YWdlIiBvZiBleHRlbmRlZCBJRHMgaW4gdGhlIGNhc2Ugb2YgZXJyb3Igb3IgbWlzY29uZmlndXJh dGlvbi4NCg0KRnJvbSB5b3VyIGNvbW1lbnRzIEkgc2VlIHRoYXQgdGhlIHBvaW50IHRoYXQgdGhl IGRyYWZ0IGVmZmVjdGl2ZWx5IG1vZGlmeWluZyB0aGUgUkFESVVTIGhlYWRlciBpcyBkdWUgdG8g cmVxdWlyaW5nIHRoYXQgdGhlIEV4dGVuZGVkLUlkZW50aWZpZXIgYmUgdGhlIGZpcnN0IGF0dHJp YnV0ZS4gVGhhdCBzZWVtcyB0byBiZSBhbiBvcHRpbWl6YXRpb24gdGhhdCBkb2VzIG5vdCBhcHBl YXIgdG8gYmUgbmVjZXNzYXJ5LCBhbmQgY291bGQgYmUgcmVtb3ZlZCB0byBhZGRyZXNzIHRoaXMg cG9pbnQuIChJIGFzc3VtZSBlaXRoZXIgZHJhZnQgd291bGQgdW5kZXJnbyBjaGFuZ2UgaWYgaXQg YmVjYW1lIGEgV0cgZHJhZnQuKQ0KDQo+IA0KPiAgTXkgZHJhZnQgaGFzIG5vbmUgb2YgdGhlc2Ug aXNzdWVzLg0KDQpSZWdhcmRpbmcgbGVha2FnZSwgZG9lcyBhIHByb3h5IG5vcm1hbGx5IHJlcGxh Y2UgdGhlIFJlcXVlc3QgQXV0aGVudGljYXRvciBmaWVsZCB3aXRoIGEgbmV3IHZhbHVlPyAoSeKA mW0gYXNraW5nIGZvciBpbmZvcm1hdGlvbi4pDQoNCj4gDQo+PiBJdCBzZWVtcyB0byBtZSB0aGF0 IHRoZSByZWFsIGRpZmZlcmVuY2UgY29tZXMgZG93biB0byBob3cgdGhlIOKAnG5ldyBleHRlbmRl ZCBmaWVsZOKAnSBpcyBjYXJyaWVkIOKAlCBlaXRoZXIgaW4gdGhlIG5ldyBwZXItY29ubmVjdGlv biBhdHRyaWJ1dGUsIG9yIGJ5IG92ZXJsb2FkaW5nIHRoZSBSZXF1ZXN0IElkZW50aWZpZXIuIEkg YXBwcmVjaWF0ZSB0aGUgYXJndW1lbnRzIGluIGRyYWZ0LWRla29rIHRoYXQgaW5kaWNhdGUgdGhh dCB0aGVyZSBzaG91bGQgbm90IGJlIGEgcHJvYmxlbSB3aXRoIG92ZXJsb2FkaW5nLCBidXQgYmVj YXVzZSBvdmVybG9hZGluZyBwcm90b2NvbCBmaWVsZHMgY2FuIGNhcnJ5IHVuZXhwZWN0ZWQgcmlz a3MNCj4gDQo+ICBSaXNrcyBsaWtlLi4uID8NCj4gDQo+ICBJIG11c3QgYWRtaXQgdG8gYmVpbmcg YSBsaXR0bGUgc3VycHJpc2VkIGF0IHRoZSBkaXNsaWtlIG9mICJvdmVybG9hZGluZyIgdGhlIFJl cXVlc3QgQXV0aGVudGljYXRvciBmaWVsZC4gIEFzIFBldGVyIERlYWNvbiBwb2ludGVkIG91dCwg aXQncyBhbHJlYWR5ICJvdmVybG9hZGVkIiBmb3IgbWFueSwgbWFueSwgb3RoZXIgdGhpbmdzLg0K PiANCj4gIEdpdmVuIHRoZSBleGlzdGluZyBkZWZpbml0aW9uIG9mIHRoZSBSZXF1ZXN0IEF1dGhl bnRpY2F0b3IgZmllbGQsIGl0IGlzICppbXBvc3NpYmxlKiBhdCB0aGlzIHRpbWUgdG8gY2hhbmdl IGhvdyBpdCdzIGNhbGN1bGF0ZWQuICBTaW1pbGFybHksIGl0J3MgaW1wb3NzaWJsZSB0byBjaGFu Z2UgdGhlIG1lYW5pbmcgb2YgdGhlIGZpZWxkIGZvciBwYWNrZXQgc2lnbmF0dXJlcy4gIEFuZCwg aXQncyBpbXBvc3NpYmxlIHRvIGNoYW5nZSB0aGUgdXNhZ2Ugb2YgdGhlIGZpZWxkIHdpdGhpbiBv dGhlciBhdHRyaWJ1dGVzLg0KDQpJ4oCZbSBtaXNzaW5nIHdoZXJlIGRyYWZ0LWNoZW4gZG9lcyBh bnkgb2YgdGhlc2UgdGhpbmdzIChhc3N1bWluZyB0aGF0IHRoZSDigJxNVVNUIGJlIGZpcnN0IGF0 dHJpYnV0ZeKAnSBpcyByZW1vdmVkKS4NCg0KPiANCj4gIFNvIHdlJ3JlIGxlZnQgd2l0aCBhIGZp ZWxkIHRoYXQgd2UgY2Fubm90IGNoYW5nZSwgYnV0IHdlIGNhbiBsb29rIGF0LiAgV2hhdCBpcyB0 aGUgcmlzayBpbiBsb29raW5nIGF0IGl0PyAgV2hhdCBpcyB0aGUgcmlzayBpbiBlY2hvaW5nIGl0 IHZlcmJhdGltIGluIGEgcmVzcG9uc2UgcGFja2V0Pw0KPiANCj4gIEkgdW5kZXJzdGFuZCB0aGF0 IHNheWluZyAid2UgYWRkIGEgMzItYml0IElEIiBpcyBjb25jZXB0dWFsbHkgc2ltcGxlci4gIEJ1 dCBJIHN0aWxsIGRvbid0IGdldCB3aGVyZSBhbnkgInJpc2siIG9yIGNvbmNlcm4gd2l0aCAib3Zl cmxvYWRpbmciIG9mIHRoZSBmaWVsZCBjb21lcyBmcm9tLiAgU29tZSBhZGRpdGlvbmFsIGV4cGxh bmF0aW9uIHdvdWxkIGJlIHVzZWZ1bCBoZXJlLg0KPiANCj4+IG15IHByZWZlcmVuY2UgaXMgdG8g YWRvcHQgdGhlIGV4cGxpY2l0IGFwcHJvYWNoIGluIGRyYWZ0LWNoZW4uIFdpdGggdGhlIHNhbWUg dGhvdWdodCBwcm9jZXNzIEnigJltIGEgbGl0dGxlIHdvcnJpZWQgYWJvdXQgZGVmaW5pbmcgImJl aGF2aW9yIHByZXZpb3VzbHkgbGVmdCBvcGVuIHRvIGltcGxlbWVudGF0aW9uIGludGVycHJldGF0 aW9u4oCdIChhcyBtZW50aW9uZWQgaW4gU2VjdGlvbiAyLjEgb2YgZHJhZnQtZGVrb2spLiBJIGNh bm5vdCBkaXNhZ3JlZSB0aGF0IGl0IOKAnHNob3VsZCIgYmUgT0ssIGJ1dCB0aGUgbGFjayBvZiBj ZXJ0YWlubHkgZG9lcyBhZGQgc29tZSByaXNrLg0KPiANCj4gIEhvdz8NCj4gDQo+ICBUaGUgZHJh ZnQgZ29lcyB0aHJvdWdoIGV4aGF1c3RpdmUgZW51bWVyYXRpb24gb2YgdGhlIHBvc3NpYmlsaXRp ZXMuICBJdCBzaG93cyB0aGF0IHRoZSBwcm9wb3NhbCBpcyBubyB3b3JzZSB0aGFuIGV4aXN0aW5n IFJBRElVUywgYW5kIGluIHNvbWUgY2FzZXMgaXMgc3Vic3RhbnRpYWxseSBiZXR0ZXIuDQoNCkkg YXBwcmVjaWF0ZSB0aGUgZW51bWVyYXRpb24sIGFuZCBJ4oCZbSBub3QgaW1wbHlpbmcgdGhhdCB5 b3XigJl2ZSBtaXNzZWQgYW55IGtub3duIHJpc2suIEJ1dCBzbyBvZnRlbiBvdmVybG9hZGluZyBm aWVsZHMgbGVhZHMgdG8gdW5mb3Jlc2VlbiByZXN1bHRzIChkdWUgdG8gYmFkIGFzc3VtcHRpb25z IGJ5IGEgZGV2ZWxvcGVyIG9yIGZ1dHVyZSBzcGVjaWZpY2F0aW9uIHdyaXRlcikgYW5kIHRoYXTi gJlzIHRoZSBiYXNpcyBmb3IgbXkgY29uY2Vybi4NCg0KPj4gSG93ZXZlciwgSSBhbHNvIGJlbGll dmUgdGhhdCB0aGVyZSBpcyBhIGxvdCBvZiBnb29kIGJhY2tncm91bmQgYW5kIGV4cGxhbmF0b3J5 IHRleHQgaW4gZHJhZnQtZGVrb2sgdGhhdCBpcyB2YWx1YWJsZSBhbmQgaWYgdGhlIHdvcmtpbmcg Z3JvdXAgdGFrZXMgZHJhZnQtY2hlbiBhcyB0aGUgYmFzZSB0aGVuIHNvbWUgb2YgdGhpcyB3b3Vs ZCBiZSB2YWx1YWJsZSB0byBicmluZyB0aGF0IGludG8gdGhlIGRyYWZ0LiBUaGlzIG1pZ2h0IGFk ZHJlc3Mgc29tZSBvZiB0aGUgY29uY2VybnMgdGhhdCBkcmFmdC1jaGVuIGlzIHVuZGVyLXNwZWNp ZmllZC4NCj4gDQo+ICBJIGFncmVlLg0KPiANCj4gIEkgdGhpbmsgYSBsYXJnZSBwYXJ0IG9mIHRo ZSBjb25jZXJuIGhlcmUgaXMgZHVlIHRvIHRoZSBiYWNrZ3JvdW5kIGFuZCBleHBsYW5hdG9yeSB0 ZXh0IGluIG15IGRvY3VtZW50LiAgaS5lLiBhIHByb3Bvc2FsIHdoaWNoIGRlc2NyaWJlcyB0aGUg cmlza3Mgc2VlbXMgcmlza3kuICAgQSBwcm9wb3NhbCB3aGljaCBpZ25vcmVzIHRoZSByaXNrcyBz ZWVtcyBsZXNzIHJpc2t5Lg0KDQpQZXJzb25hbGx5LCBJIGRpZCBub3QgZmluZCB0aGUgYmFja2dy b3VuZCBhbmQgZXhwbGFuYXRvcnkgdGV4dCB0byBtYWtlIGRyYWZ0LWRla29rIHNlZW0gc2VlbSBt b3JlIHJpc2t5LiBJ4oCZbSByZWFjdGluZyB0byB0aGUgb3ZlcmxvYWRpbmcsIHdoZXJlIGdpdmVu IHNpbWlsYXIgb3V0Y29tZXMgSSBwcmVmZXIgbm90IHRvIGludHJvZHVjZSBhZGRpdGlvbmFsIHNl bWFudGljcyB0byBhbiBleGlzdGluZyBmaWVsZC4NCg0KVGhhbmtzLA0KQnJpYW4NCg0KPiANCj4g IEJ1dCBJIHdvdWxkIHN0aWxsIGxpa2UgdG8gdW5kZXJzdGFuZCAoYSkgd2hhdCB0aGUgcmlza3Mg YXJlIGhlcmUsIGFuZCAoYikgd2h5IHRoZXJlJ3MgYSBjb25jZXJuIHdpdGggIm92ZXJsb2FkaW5n IiBhIGZpZWxkIHRoYXQgY2Fubm90IGJlIGNoYW5nZWQsIGFuZCBpcyBhbHJlYWR5IHVzZWQgZm9y IG1hbnkgdGhpbmdzLg0KPiANCj4gIEFsYW4gRGVLb2suDQo+IA0KDQotLSANCkJyaWFuIFdlaXMN ClNlY3VyaXR5LCBDU0csIENpc2NvIFN5c3RlbXMNClRlbGVwaG9uZTogKzEgNDA4IDUyNiA0Nzk2 DQpFbWFpbDogYmV3QGNpc2NvLmNvbQ0KDQo= From david@carrel.net Mon Dec 11 20:22:05 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441DC1293DB for ; Mon, 11 Dec 2017 20:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipsec-org.20150623.gappssmtp.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 P7OfKQxlcASV for ; Mon, 11 Dec 2017 20:22:03 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 4DD60126DED for ; Mon, 11 Dec 2017 20:22:03 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id 74so21693774lfs.0 for ; Mon, 11 Dec 2017 20:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipsec-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Jtc+7z5uZWMMWVSnZKiGk0ZSj331qGmId8s3Qgy+EjY=; b=K5JAwue/znB46orce7HoYOfohpoo6sUrvv32NNUOu9ijWM987hGATH2SP1qHPGpgTB RDqReo8ICXccJZYb28KxkWrrEqer2dUx3jsRey4rKLnFmAiRUTR9IInuSyy/XXiord+3 0YeM4A0MWiVq2hTLoQ7s1i5ruKwfWOUp29RrzGSoPnEdaICG7lQbmevGuf07EC9h+gaL cyt8LfBveH9mhMWgkS4FNPawYBYIsPfkPBPVnWFs6vp6pBiiUJjVD19T8UibrCy1wP22 NWYvwEGdr9PbU6DHNda7mw05TLyZh5LIn+HFpQKM2TVJOU9XkLJR4d0sIG3BACQTPLRW GQVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Jtc+7z5uZWMMWVSnZKiGk0ZSj331qGmId8s3Qgy+EjY=; b=kAnEjOWJpeOlM6cLS14QkkcYmZ1lT9FBlIxCtr6YZYt7hEFYKDgHAJOCzXzVbZKDkk ts5cLdjBmCWO2Arh7id4ekQOgrRkXNiCdyrRz7UEIDi1A/EUA+Zp45PUY579CfzMXHG6 vm5X1gNdUNrE4YjvZrFidzVG0RrLTKiSb852V9RMLOMqpXJQhDIL/on8VhRQbXNW1TcR h4WN4w09+Ax4UMJbyd3/f8VASeAeyXMyPgWODZ8Ql2TugNttR/aQNsDvRkXeGXsoDq2J qOhzUztCMtje1Q7o66+077Qx2GA/4x6GziFb3nUTgiARzbs1lM+gWz15ggDEyVXJKz/w ZJdA== X-Gm-Message-State: AKGB3mLCEyaJ7UHZrhhnXcQlmrs4F60JqR1lcRHbYa4VeKmybs3SMHoO fdRRCbFGpVlwvIrV+OIOIHomUsD1IuAJOsXWlZKtxF9P X-Google-Smtp-Source: ACJfBot9RVO6ke2BbQwaTMIAHQQoJDGoeBiomN+VxNVT+xrophYtzuLRdLJ9GhVrcR9er7yVXkegvHaYF1tFzfyk6wo= X-Received: by 10.46.116.1 with SMTP id p1mr1325020ljc.103.1513052520864; Mon, 11 Dec 2017 20:22:00 -0800 (PST) MIME-Version: 1.0 References: <2D707CD0-5C6D-4ABE-9829-820D6145E98F@deployingradius.com> <1465D072-52D7-4FC3-88A6-E1A97740B753@cisco.com> In-Reply-To: <1465D072-52D7-4FC3-88A6-E1A97740B753@cisco.com> From: David Carrel Date: Tue, 12 Dec 2017 04:21:50 +0000 Message-ID: To: "radext@ietf.org" Content-Type: multipart/alternative; boundary="089e0827b3d408778d05601cfe31" Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 05:17:08 -0000 --089e0827b3d408778d05601cfe31 Content-Type: text/plain; charset="UTF-8" I also support moving forward with draft-chen-radext-identifier-attr as the base for future work. To me it seems to be a cleaner solution and that it will be easier to create interoperability. Adding additional semantic meanings to an existing field (the Authenticator) does seem to be fraught with potential risk. Certainly either of these could move forward to address the scalability issue, but I prefer draft-chen- As others have mentioned, I think we should look at removing the requirement for this attribute to be in a fixed position (first). Dave --089e0827b3d408778d05601cfe31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also support moving forward with draft-chen-radext-ident= ifier-attr as the base for future work.=C2=A0 To me it seems to be a cleane= r solution and that it will be easier to create interoperability.=C2=A0 Add= ing additional semantic meanings to an existing field (the Authenticator) d= oes seem to be fraught with potential risk. Certainly either of these could= move forward to address the scalability issue, but I prefer draft-chen-
As others have mentioned, I think we should look at removi= ng the requirement for this attribute to be in a fixed position (first).

Dave

--089e0827b3d408778d05601cfe31-- From nobody Mon Dec 11 22:11:27 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EF7126CD6 for ; Mon, 11 Dec 2017 22:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 m-dJZoPPhEEH for ; Mon, 11 Dec 2017 22:11:25 -0800 (PST) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8B6126C26 for ; Mon, 11 Dec 2017 22:11:24 -0800 (PST) Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 11 Dec 2017 22:11:24 -0800 Date: Mon, 11 Dec 2017 22:11:26 -0800 (Pacific Standard Time) From: Peter Deacon To: "Brian Weis (bew)" cc: "radext@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21.1 (WNT 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1092297921-7599-1513050747=:2252" Content-ID: Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 06:11:27 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1092297921-7599-1513050747=:2252 Content-Type: text/plain; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Tue, 12 Dec 2017, Brian Weis (bew) wrote: > draft-chen. With the same thought process I’m a little worried about > defining "behavior previously left open to implementation > interpretation” (as mentioned in Section 2.1 of draft-dekok). I cannot > disagree that it “should" be OK, but the lack of certainly does add some > risk. Partially why I prefer draft-dekok-radext-request-authenticator. Mitigates existing ambiguity that remains intact /w draft-chen-radext-identifier-attr. > I appreciate the arguments in draft-dekok that indicate that there > should not be a problem with overloading, but because overloading > protocol fields can carry unexpected risks my preference is to adopt the > explicit approach in draft-chen. Both drafts are "overloading" payload of RADIUS packets to carry identifiers that clearly belong in header. This has objectively articulable consequences. Due to "overloading" it is no longer possible to route and correlate packets based on header information. Implementations are now required to decode attribute payloads to perform this function. Possible new risks of request and response attributes being mishandled or misinterpreted in mixed environments. Of the two draft-dekok-radext-request-authenticator appears to carry LESS "overload" risks as only responses are modified. Most importantly ORA is native header information being used for header purposes unique to one and only one specific request packet. The major reason I support draft-dekok-radext-request-authenticator it is intentionally designed to mitigate "overload" risk. On "Overloading" invoked by transmission of ORA.. RFC2865 Section 3 describes RA: --- "In Access-Request Packets, the Authenticator value is a 16 octet random number" ... "The value SHOULD be unpredictable and unique over the lifetime of a secret" ... "Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the Request Authenticator field SHOULD exhibit global and temporal uniqueness." --- For acct/dyn auth MD5 sum over packet. I am aware of no objectively articulable consequences of using authenticator for this purpose. There are no architecturally pure options on the table except time honored tradition of throwing more connections at the problem. regards, Peter ---1092297921-7599-1513050747=:2252-- From nobody Tue Dec 12 05:28:04 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EF1129459 for ; Tue, 12 Dec 2017 05:28:02 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 IwpHD01f6oA8 for ; Tue, 12 Dec 2017 05:28:00 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 86267129453 for ; Tue, 12 Dec 2017 05:28:00 -0800 (PST) Received: from [192.168.2.25] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id 8B047CC; Tue, 12 Dec 2017 13:27:59 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <1465D072-52D7-4FC3-88A6-E1A97740B753@cisco.com> Date: Tue, 12 Dec 2017 08:27:58 -0500 Cc: "radext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D707CD0-5C6D-4ABE-9829-820D6145E98F@deployingradius.com> <1465D072-52D7-4FC3-88A6-E1A97740B753@cisco.com> To: "Brian Weis (bew)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 13:28:03 -0000 On Dec 11, 2017, at 9:39 PM, Brian Weis (bew) wrote: > =46rom your comments I see that the point that the draft effectively = modifying the RADIUS header is due to requiring that the = Extended-Identifier be the first attribute. That seems to be an = optimization that does not appear to be necessary, and could be removed = to address this point. (I assume either draft would undergo change if it = became a WG draft.) It still is effectively a modification of the RADIUS header. i.e. the = 25 year-history of "look at the first 20 octets" is now changed. In contrast, draft-dekok changes *nothing* about request packets. > Regarding leakage, does a proxy normally replace the Request = Authenticator field with a new value? (I=E2=80=99m asking for = information.) Yes. draft-dekok is hop-local by design. There is no possibility to = leak data which is never in the packet... >> Given the existing definition of the Request Authenticator field, it = is *impossible* at this time to change how it's calculated. Similarly, = it's impossible to change the meaning of the field for packet = signatures. And, it's impossible to change the usage of the field = within other attributes. >=20 > I=E2=80=99m missing where draft-chen does any of these things = (assuming that the =E2=80=9CMUST be first attribute=E2=80=9D is = removed). It doesn't. But neither does draft-dekok. My comment was about risk, = not about draft-chen. i.e. draft-dekok changes nothing about Request Authenticator, but it's = risky. Or, draft-chen adds a 32-bit ID which may leak across proxy = boundaries, and has undefined behavior when an extended ID is re-used. = But that's less risky. > I appreciate the enumeration, and I=E2=80=99m not implying that = you=E2=80=99ve missed any known risk. But so often overloading fields = leads to unforeseen results (due to bad assumptions by a developer or = future specification writer) and that=E2=80=99s the basis for my = concern. The exhaustive enumeration of possibilities was intended to mitigate = the risk, by explaining and understanding all possible situations. As for unforeseen results, RFC 2865 Section 3 says: ... the Request Authenticator field SHOULD exhibit global and temporal uniqueness. That sure sounds like a unique ID to me. The draft then proposes = that: 1) if a server receives a request that matches a "live" one (src/dst = IP/port, code, ID), then it MAY also use the Request Authenticator to = differentiate the packets 2) as a result of (1), the original Request Authenticator is echoed back = in response packets. That's really it. I'll remind the WG that the behaviour of (1) is = currently *undefined* in RADIUS. So the draft is arguably mitigating = the existing risk by defining that behaviour. Not only for the new = proposal, but also for existing RADIUS. > Personally, I did not find the background and explanatory text to make = draft-dekok seem seem more risky. I=E2=80=99m reacting to the = overloading, where given similar outcomes I prefer not to introduce = additional semantics to an existing field. The concern here is that we *already* have these semantics on the = Request Authenticator. Implementations *cannot* inter-operate without = choosing some semantics for Request Authenticator. =20 So draft-dekok just explains these semantics, documents existing = practice, and explains how existing semantics can be leveraged to gain = new functionality. I think the main difference here is that it's simple to say "add a = 32-bit attribute". In contrast, it seems weird to use the Request = Authenticator like this. But as an implementor... it's already being = used like this in ever server implementation in the world. Alan DeKok. From nobody Tue Dec 12 12:39:20 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA34C12954B for ; Tue, 12 Dec 2017 12:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyUJNh6IMwbK for ; Tue, 12 Dec 2017 12:39:16 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0F81287A5 for ; Tue, 12 Dec 2017 12:39:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1513111154; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=cX6q+AFZjMZW8oWHAhilUs9ZQrahKrBGfzWM9QpHCsY=; b=DkASJr8e15H0T7V4/KS7BzvwBCORbQd5y0oCqHE2FLTIodjFW0C1uM9Bqv5BL+J27ubE88j/SPSgvc8f9NQ/DZhpTprLCCykQNLddTaqNEPRH4eZqoQm+rYYOxfXq7e0VkyloaC/Nz3ZbXMT/yWBGpgG+tLRoMPI0gKDrocNee0= Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp0149.outbound.protection.outlook.com [213.199.154.149]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-1-9ouSTVpkPJGYq0igA8hYWw-1; Tue, 12 Dec 2017 20:39:10 +0000 Received: from AM4PR07MB3508.eurprd07.prod.outlook.com (10.171.190.33) by AM4PR07MB3508.eurprd07.prod.outlook.com (10.171.190.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Tue, 12 Dec 2017 20:39:06 +0000 Received: from AM4PR07MB3508.eurprd07.prod.outlook.com ([fe80::fceb:5817:13c1:1678]) by AM4PR07MB3508.eurprd07.prod.outlook.com ([fe80::fceb:5817:13c1:1678%13]) with mapi id 15.20.0323.011; Tue, 12 Dec 2017 20:39:06 +0000 From: Adam Bishop To: "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTKHKrqEQLrXT090aiKN4ZjCjQD6MqT+8AgBZxrIA= Date: Tue, 12 Dec 2017 20:39:06 +0000 Message-ID: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) x-originating-ip: [2a00:23c4:2713:4710:38ce:a8f7:eb4a:8afa] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB3508; 20:gMRJXOD8N/uwipXwl0LrySG+36o+iKxg4MeHLbtphFfu3gXmzcBRylJxTZ2rdkCta5eTJnCy0AbCoHE4OdYq75D8srW7YHpD4N41Wcuz5lkDCENOtIeCm+eXEPrG516X010o6JDCTCEtTJgIyLf9Z6+bvPOfaUMtJgX60wekSI4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f9a9ecb4-fbf7-4c79-dcbd-08d541a063d9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:AM4PR07MB3508; x-ms-traffictypediagnostic: AM4PR07MB3508: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672)(35073007944872); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231023)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(201708071742011); SRVR:AM4PR07MB3508; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR07MB3508; x-forefront-prvs: 051900244E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(199004)(24454002)(189003)(3280700002)(14454004)(36756003)(229853002)(83716003)(53546010)(478600001)(76176011)(25786009)(68736007)(2501003)(7736002)(305945005)(5250100002)(57306001)(6506007)(6116002)(102836003)(6512007)(2900100001)(53936002)(72206003)(50226002)(8936002)(6486002)(6246003)(316002)(786003)(74482002)(105586002)(99286004)(97736004)(33656002)(86362001)(106356001)(2351001)(82746002)(81166006)(6436002)(2906002)(5660300001)(2950100002)(6916009)(42882006)(5640700003)(1730700003)(81156014)(8676002)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3508; H:AM4PR07MB3508.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: f9a9ecb4-fbf7-4c79-dcbd-08d541a063d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2017 20:39:06.7806 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3508 X-MC-Unique: 9ouSTVpkPJGYq0igA8hYWw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 20:39:19 -0000 T24gMjggTm92IDIwMTcsIGF0IDEzOjU0LCBTdGVmYW4gV2ludGVyIDxzdGVmYW4ud2ludGVyQHJl c3RlbmEubHU+IHdyb3RlOg0KPiBJbiB5b3VyIHJlcGx5IHRvIHRoaXMgY2FsbCBmb3IgYWRvcHRp b24sIHBsZWFzZSBpbmRpY2F0ZSB3aGljaCBvZiB0aGUNCj4gdHdvIGRyYWZ0cyB5b3UgdGhpbmsg c2hvdWxkIGJlIGFkb3B0ZWQuIFlvdSBjYW4gb2YgY291cnNlIGFsc28gaW5kaWNhdGUNCj4gdGhh dCBub25lIG9mIHRoZSB0d28gYXJlIGZpdCBmb3IgcHVycG9zZS4gVGhlIG9ubHkgdGhpbmcgeW91 IHJlYWxseQ0KPiBzaG91bGRuJ3QgZG8gaXMgdG8gdm90ZSBmb3IgYm90aDsgdGhhdCB3b3VsZG4n dCBoZWxwIHRoZSBkaXNjdXNzaW9uIG1vdmUgb24uDQoNCkhhdmluZyByZWFkIGJvdGggZHJhZnRz LCBJIHRoaW5rIHRoZSBhcHByb2FjaCBpbiBkcmFmdC1kZWtvayBpcyBtb3JlIHN1aXRhYmxlIGZv ciBhZG9wdGlvbi4NCg0KV2hpbGUgYXNzaWduaW5nIGFkZGl0aW9uYWwgbWVhbmluZyB0byBleGlz dGluZyB2YWx1ZXMgY2FuIGJlIHByb2JsZW1hdGljLCB0aGVyZSBpcyBzdWZmaWNpZW50IGV4cGxh bmF0aW9uIGFscmVhZHkgcHJlc2VudCBpbiB0aGUgZHJhZnQgdG8gcmVhc3N1cmUgbWUgdGhhdCB0 aGlzIHNob3VsZG7igJl0IGludGVyYWN0IG5lZ2F0aXZlbHkgd2l0aCBleGlzdGluZyBpbXBsZW1l bnRhdGlvbnMsIGFuZCBhdm9pZHMgY2hhbmdpbmcgb3IgZXh0ZW5kaW5nIHRoZSBoZWFkZXIuDQoN CkkgYWdyZWUgd2l0aCB0aGUgb2JzZXJ2YXRpb24gdGhhdCBkcmFmdC1jaGVuIGNvdWxkIGJlIHBy b2JsZW1hdGljIGluIGZlZGVyYXRlZCBkZXBsb3ltZW50cyBkdWUgdG8gdGhlIHBvdGVudGlhbCBm b3IgdGhlIGlkZW50aWZpZXIgdG8gbGVhayBiZXR3ZWVuIGhvcHMuDQoNClJlZ2FyZHMsDQoNCkFk YW0gQmlzaG9wDQoNCiAgZ3BnOiBFNzVCIDFGOTIgNjQwNyBERkRGIDlGMUMgIEJGMTAgQzk5MyAy NTA0IDY2MDkgRDQ2MA0KDQpqaXNjLmFjLnVrDQoNCkppc2MgaXMgYSByZWdpc3RlcmVkIGNoYXJp dHkgKG51bWJlciAxMTQ5NzQwKSBhbmQgYSBjb21wYW55IGxpbWl0ZWQgYnkgZ3VhcmFudGVlIHdo aWNoIGlzIHJlZ2lzdGVyZWQgaW4gRW5nbGFuZCB1bmRlciBDb21wYW55IE5vLiA1NzQ3MzM5LCBW QVQgTm8uIEdCIDE5NyAwNjMyIDg2LiBKaXNj4oCZcyByZWdpc3RlcmVkIG9mZmljZSBpczogT25l IENhc3RsZXBhcmssIFRvd2VyIEhpbGwsIEJyaXN0b2wsIEJTMiAwSkEuIFQgMDIwMyA2OTcgNTgw MC4NCg0KSmlzYyBTZXJ2aWNlcyBMaW1pdGVkIGlzIGEgd2hvbGx5IG93bmVkIEppc2Mgc3Vic2lk aWFyeSBhbmQgYSBjb21wYW55IGxpbWl0ZWQgYnkgZ3VhcmFudGVlIHdoaWNoIGlzIHJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCB1bmRlciBjb21wYW55IG51bWJlciAyODgxMDI0LCBWQVQgbnVtYmVyIEdC IDE5NyAwNjMyIDg2LiBUaGUgcmVnaXN0ZXJlZCBvZmZpY2UgaXM6IE9uZSBDYXN0bGUgUGFyaywg VG93ZXIgSGlsbCwgQnJpc3RvbCBCUzIgMEpBLiBUIDAyMDMgNjk3IDU4MDAuICANCg== From nobody Tue Dec 12 15:27:50 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9025D126DC2 for ; Tue, 12 Dec 2017 15:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 gJp7iEn0qClL for ; Tue, 12 Dec 2017 15:27:46 -0800 (PST) Received: from sonic305-22.consmr.mail.ne1.yahoo.com (sonic305-22.consmr.mail.ne1.yahoo.com [66.163.185.148]) (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 99DBE124234 for ; Tue, 12 Dec 2017 15:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1513121265; bh=Kon+K3KpZSzB0yEK7Bv4l6Imz3k1lu5HQqmPq0RydWg=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=k4wP8DkKajf6DcNC9KxreiU/32hsAlqM75WcGUE4vXSSp4J9mvIh95mgUnp/grZZm9+YTpETuHDrh64qOvrbfarexsYWKPyiRMg75wZg+YnBY2pI2gn8lfWY+wbMwJvTYtJGKi2Ko3J2yy+s+qnNW8i/wVzgdc8m1Mcz1D9m1L51iXsTfn8VGQ6i+Wv4bqBZBVeW7phRqYErDvDn4bzoD6khSH2Hgqe/FqwbdVJqYtnXXuos/c9F/CDRwWXbKZe1wsx68He8i/o1osBhABGn0nMk+WnBFYHJEUy5QNs4iKSKtIfibGT7+sSw7d8i4e8RIDNLcnYerI0x4Mq0ZImTxg== X-YMail-OSG: AdEYxhoVM1mGbzOmN.nDakIKsNHZpG4sFp0VxnXiCYWrdF._f2t0xTnvK4OZnhT 8OADNa6.qo4zl4OyHNMVo8ypCx_.ACK9WauedZglypW9u_N89xurwbLYUxX3.HEibOqVn5kql0sd GJFYQUs_1V70GxurYM9fasR7yZiBF4AjmYE9x.9I1oqVZDbDKAX6kv.zBJZTEc4bbsO80UvSgdqn c_y3p9QsI_IEqR0sM8ndQ1PyQrwqrFmbgd_tNv9ZrACFXXSlnkkimuK8kYOkDzFjsPhHHnVeBx0t pO1dZMVSqniTUTpJ9BvKkIrwOEnXY0jWtyuTHtoW8kpW9Nuie3Bd7fv4UcJo7WoxxCGAG88.Q2jM E.iZSIWw80eNfVAcU6T1JjbtJaSjz.4w2dl_FhlsYy9M7BnIaSxMXd_PYfd2MoW_q4pyDKIZkqlL JAyotghJSXlij5Y15.wz4KEhwIhinFxD215Jc4yEjvJpDmvm2sidKoR8hGAPUjyHXr8_pRIWN3Mo gIruJsAP1rcwbPSD8t8BmIxPoM1U- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Tue, 12 Dec 2017 23:27:45 +0000 Date: Tue, 12 Dec 2017 23:27:27 +0000 (UTC) From: Jun Zhuang To: "radext@ietf.org" Message-ID: <966900709.4100660.1513121247433@mail.yahoo.com> In-Reply-To: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4100659_1705029524.1513121247430" X-Mailer: WebService/1.1.11051 YMailNorrin Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 23:27:49 -0000 ------=_Part_4100659_1705029524.1513121247430 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =20 Hi, After reading both drafts, I prefer draft-chen-radex-identifier-attr-02 ove= r draft-dekok-radex-request-authenticator-02, as I think it is cleaner solu= tion and will be easier to debug and deploy.=C2=A0=20 Also, I noticed that draft-chen-radex-identifier-attr-02 was published last= July to address the problem. The draft-dekok-radex-request-authenticator-0= 2 was published this April this year, an interval of more than 10 months. S= ince both are open to revising and improvement, I vote for adopting the dra= ft-chen-radex-identifier-attr-02 as the base and go forward. Regards, James Zhuang On Tuesday, December 12, 2017, 12:39:22 PM PST, Adam Bishop wrote: =20 =20 On 28 Nov 2017, at 13:54, Stefan Winter wrote: > In your reply to this call for adoption, please indicate which of the > two drafts you think should be adopted. You can of course also indicate > that none of the two are fit for purpose. The only thing you really > shouldn't do is to vote for both; that wouldn't help the discussion move = on. Having read both drafts, I think the approach in draft-dekok is more suitab= le for adoption. While assigning additional meaning to existing values can be problematic, t= here is sufficient explanation already present in the draft to reassure me = that this shouldn=E2=80=99t interact negatively with existing implementatio= ns, and avoids changing or extending the header. I agree with the observation that draft-chen could be problematic in federa= ted deployments due to the potential for the identifier to leak between hop= s. Regards, Adam Bishop =C2=A0 gpg: E75B 1F92 6407 DFDF 9F1C=C2=A0 BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guar= antee which is registered in England under Company No. 5747339, VAT No. GB = 197 0632 86. Jisc=E2=80=99s registered office is: One Castlepark, Tower Hil= l, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limit= ed by guarantee which is registered in England under company number 2881024= , VAT number GB 197 0632 86. The registered office is: One Castle Park, Tow= er Hill, Bristol BS2 0JA. T 0203 697 5800.=C2=A0=20 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext =20 ------=_Part_4100659_1705029524.1513121247430 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi= ,

= After reading both drafts, I prefer draft-chen-radex-identifier-attr-02 ove= r draft-dekok-radex-request-authenticator-02, as I think it is cleaner solu= tion and will be easier to debug and deploy. 

Also, I = noticed that draft-chen-radex-identifier-attr-02 was published last = July to address the problem. The draft-dekok-radex-request= -authenticator-02 was published this April this year, an interval of more t= han 10 months. Since both are open to revising and improvement, I vote for = adopting the draft-chen-radex-identifier-attr-02 as= the base and go forward.

Regards,

James Zhuang
=20
=20
On Tuesday, December 12, 2017, 12:39:22 PM PST, Ada= m Bishop <Adam.Bishop@jisc.ac.uk> wrote:


On 28 Nov 2017, at 13:54, Stefan = Winter <stefan.winter@restena.lu> wrote:
> In your reply to this call for adoption, please indicat= e which of the
> two drafts you think should b= e adopted. You can of course also indicate
> t= hat none of the two are fit for purpose. The only thing you really
> shouldn't do is to vote for both; that wouldn't help= the discussion move on.

Having read both drafts, I think the approach in draft-dekok is more sui= table for adoption.

Wh= ile assigning additional meaning to existing values can be problematic, the= re is sufficient explanation already present in the draft to reassure me th= at this shouldn=E2=80=99t interact negatively with existing implementations= , and avoids changing or extending the header.
I agree with the observation that draft-chen could= be problematic in federated deployments due to the potential for the ident= ifier to leak between hops.

Regards,

Adam Bi= shop

  gpg: E75B = 1F92 6407 DFDF 9F1C  BF10 C993 2504 6609 D460

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a compa= ny limited by guarantee which is registered in England under Company No. 57= 47339, VAT No. GB 197 0632 86. Jisc=E2=80=99s registered office is: One Cas= tlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned= Jisc subsidiary and a company limited by guarantee which is registered in = England under company number 2881024, VAT number GB 197 0632 86. The regist= ered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 58= 00. 
______________________________________= _________
radext mailing list
------=_Part_4100659_1705029524.1513121247430-- From nobody Tue Dec 12 15:47:35 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F351270AE for ; Tue, 12 Dec 2017 15:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 cGeusMZ_2nfL for ; Tue, 12 Dec 2017 15:47:31 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B308812704A for ; Tue, 12 Dec 2017 15:47:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3178; q=dns/txt; s=iport; t=1513122451; x=1514332051; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=y03jX4Xn6s0vz6gNpkYbe4OkK/efwBnW7lXXnEzTTvo=; b=C9YMbenqTJUxQNrg+rnqxLk55tlL6yQO7prJOLue9tpCfuGQa04Jy9ZE k1GLVW0Y+9ToWvjAA9/jneG2IPT+ylVfRZAPPlCyyNrrhjxdp5rZ3McUc badzbVSrsCj2B5gcOmpySe4PH8BfgxWIs5uXoc1mmoqVatGD1zy0kTOPa w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAQBaaTBa/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4M4Q5kmgX2XJYIBChgLg19VFU8CGoRuQhUBAQEBAQE?= =?us-ascii?q?BAQFrKIUjAQEBAQIBAQEKEQYROgsFCwIBBgIYAgImAgICJQsVEAIEDgUWigoIE?= =?us-ascii?q?IsDnWyCJ4pgAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYEPglSBaSKDaIMCgy4BGIE?= =?us-ascii?q?jARIBHxeCfjGCMgWjFwKHeY0rghaGEoQOhzGKQ4t0AhEZAYE6ATUjYG5vFToqA?= =?us-ascii?q?YF+CYRMeIgWgSSBFQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,395,1508803200"; d="scan'208";a="43944261" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2017 23:47:30 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vBCNlUG3030847 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Dec 2017 23:47:30 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 12 Dec 2017 17:47:29 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Tue, 12 Dec 2017 17:47:29 -0600 From: "Naiming Shen (naiming)" To: Stefan Winter CC: "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTc6OSqtJDphnIu0Ga679ujWV4vA== Date: Tue, 12 Dec 2017 23:47:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.173.17] Content-Type: text/plain; charset="utf-8" Content-ID: <3A67CF003E1D7446B7CFB21F4BEE9B68@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 23:47:33 -0000 DQpTdGVmYW4sDQoNCkFzIGEgY28tYXV0aGVyLCBJIHZvdGUgZm9yIGRyYWZ0LWNoZW4tcmFkZXh0 LWlkZW50aWZpZXItYXR0ci0wMi4NCg0KQXMgZm9yIHRoZSBhdHRyaWJ1dGUgYmVpbmcgdGhlIGZp cnN0IGF0dHJpYnV0ZSBvciBub3QsIGlmIHRoZSB3b3JraW5nIGdyb3VwDQpkb2VzIG5vdCB0aGlu ayBpdOKAmXMgbmVjZXNzYXJ5LCB0aGVuIHdlIGNhbiBjaGFuZ2UgdGhhdCB0byBiZSBnZW5lcmFs Lg0KV2Ugd2lsbCBsb29rIHRocm91Z2ggYWxsIHRoZSBjb21tZW50cyB0byBoYXZlIGFuIHVwZGF0 ZSBzb29uLg0KDQpCZXN0IFJlZ2FyZHMsDQotIE5haW1pbmcNCg0KPiBPbiBOb3YgMjgsIDIwMTcs IGF0IDU6NTQgQU0sIFN0ZWZhbiBXaW50ZXIgPHN0ZWZhbi53aW50ZXJAcmVzdGVuYS5sdT4gd3Jv dGU6DQo+IA0KPiBIZWxsbywNCj4gDQo+PiB0aGFua3MgYWxsIGZvciByYWlzaW5nIHRoZSBhd2Fy ZW5lc3Mgb2YgdGhlc2UgdHdvIGRyYWZ0cy4NCj4+IA0KPj4gDQo+PiBJIHRoaW5rIGl0IHdvdWxk IGJlIGdvb2QgaWYgYWxsIHJlbWFpbmluZyByZWFkZXJzIG9mIHRoaXMgbGlzdCB3aG8gY2FyZQ0K Pj4gZW5vdWdoIG5vdyB0YWtlIHNvbWUgdGltZSB0byByZWFkIGJvdGggZHJhZnRzIGFuZCBtYWtl IHVwIHRoZWlyIG1pbmQgb24NCj4+IHdoYXQgdGhlIHByZWZlcnJlZCBhcHByb2FjaCBpcy4NCj4+ IA0KPj4gDQo+PiBJbiBhcHByb3guIHR3byB3ZWVrcycgdGltZSBJIHdpbGwgc3RhcnQgYSBjYWxs IGZvciBhZG9wdGlvbiBvbiBib3RoDQo+PiBkcmFmdHMsIGFuZCBob3BlZnVsbHkgdGhlcmUgYXJl IGVub3VnaCByZXNwb25zZXMgdG8gbWFrZSB0aGUgZXhlcmNpc2UNCj4+IG1lYW5pbmdmdWwuIElm IHNvLCB0aGUgb25lIHdpdGggbW9yZSB2b3RlcyB3aW5zLg0KPiANCj4gTm93IHRoYXQgd2FzIGEg cmVsYXhlZCAidHdvIHdlZWtzIiBkZWxheS4gTXkgYXBvbG9naWVzLCBJJ3ZlIGJlZW4gb24gYW5k DQo+IG9mZiB3b3JrIGZvciBhIHdoaWxlLCB3aXRoIHN1YnN0YW50aWFsIGJhY2tsb2dzLg0KPiAN Cj4gVGhpcyBlbWFpbCBzdGFydHMgYSB0d28gd2VlayBjYWxsIGZvciBhZG9wdGlvbiBvZiBhdCBt b3N0IG9uZSBvZiB0aGUNCj4gZm9sbG93aW5nIHR3byBkcmFmdHM6DQo+IA0KPiAqIGRyYWZ0LWNo ZW4tcmFkZXh0LWlkZW50aWZpZXItYXR0ci0wMg0KPiAqIGRyYWZ0LWRla29rLXJhZGV4dC1yZXF1 ZXN0LWF1dGhlbnRpY2F0b3ItMDINCj4gDQo+IFNpbmNlIHRoZSB0d28gZHJhZnRzIHRyZWF0IHRo ZSBzYW1lIHRvcGljLCBhdCBtb3N0IG9uZSBjYW4gYmUgc2VsZWN0ZWQNCj4gdG8gc2VydmUgYXMg dGhlIGJhc2lzIGZvciBmdXR1cmUgd29yay4NCj4gDQo+IEluIHlvdXIgcmVwbHkgdG8gdGhpcyBj YWxsIGZvciBhZG9wdGlvbiwgcGxlYXNlIGluZGljYXRlIHdoaWNoIG9mIHRoZQ0KPiB0d28gZHJh ZnRzIHlvdSB0aGluayBzaG91bGQgYmUgYWRvcHRlZC4gWW91IGNhbiBvZiBjb3Vyc2UgYWxzbyBp bmRpY2F0ZQ0KPiB0aGF0IG5vbmUgb2YgdGhlIHR3byBhcmUgZml0IGZvciBwdXJwb3NlLiBUaGUg b25seSB0aGluZyB5b3UgcmVhbGx5DQo+IHNob3VsZG4ndCBkbyBpcyB0byB2b3RlIGZvciBib3Ro OyB0aGF0IHdvdWxkbid0IGhlbHAgdGhlIGRpc2N1c3Npb24gbW92ZSBvbi4NCj4gDQo+IFBsZWFz ZSByZXBseSBieSAxMiBkZWMgMjAxNyAyNDAwIFVUQy4NCj4gDQo+IEdyZWV0aW5ncywNCj4gDQo+ IFN0ZWZhbiBXaW50ZXINCj4gDQo+IC0tIA0KPiBTdGVmYW4gV0lOVEVSDQo+IEluZ2VuaWV1ciBk ZSBSZWNoZXJjaGUNCj4gRm9uZGF0aW9uIFJFU1RFTkEgLSBSw6lzZWF1IFTDqWzDqWluZm9ybWF0 aXF1ZSBkZSBsJ0VkdWNhdGlvbiBOYXRpb25hbGUgZXQgZGUgbGEgUmVjaGVyY2hlDQo+IDIsIGF2 ZW51ZSBkZSBsJ1VuaXZlcnNpdMOpDQo+IEwtNDM2NSBFc2NoLXN1ci1BbHpldHRlDQo+IA0KPiBU ZWw6ICszNTIgNDI0NDA5IDENCj4gRmF4OiArMzUyIDQyMjQ3Mw0KPiANCj4gUEdQIGtleSB1cGRh dGVkIHRvIDQwOTYgQml0IFJTQSAtIEkgd2lsbCBlbmNyeXB0IGFsbCBtYWlscyBpZiB0aGUgcmVj aXBpZW50J3Mga2V5IGlzIGtub3duIHRvIG1lDQo+IA0KPiBodHRwOi8vcGdwLm1pdC5lZHU6MTEz NzEvcGtzL2xvb2t1cD9vcD1nZXQmc2VhcmNoPTB4QzBERTZBMzU4QTM5REM2Ng0KPiANCj4gPDB4 OEEzOURDNjYuYXNjPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IHJhZGV4dCBtYWlsaW5nIGxpc3QNCj4gcmFkZXh0QGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0DQoNCg== From nobody Tue Dec 12 16:08:06 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F151270AE for ; Tue, 12 Dec 2017 16:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 IaQgFFyl0p3M for ; Tue, 12 Dec 2017 16:08:02 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F698126CBF for ; Tue, 12 Dec 2017 16:08:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3954; q=dns/txt; s=iport; t=1513123682; x=1514333282; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4ggkjwO/bV/qPgVLXIvd5MJJBIaGNypAHDXMeUZJoro=; b=SacZymR1vE3qN7L2wWBZIvT2bs8draK/nhSz6/RmLn835uW+k5U1Xean 5ooHtO4KZlvnOrgJzCPQoRNq626tSRsaUNIYvnKOIYZDrYRxU1T7B6eHO mC9O42SNfqEL6IjOCidU8jruBUi1HC5+xcsgUdmfImGoZ0aB0htmYti4m M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BJAgAGbzBa/4gNJK1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPmZ0JweDe5kmgVcmlxGCFQoYC4RJTwIahG5AFwEBAQEBAQE?= =?us-ascii?q?BAWsohSMBAQEBAgEBARsGEToLBQsCAQgYAgImAgICJQsVEAIEDgWKIAgQqD+CJ?= =?us-ascii?q?4pgAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYEPglSCC4M/KQuBaYEOgy4BgUcRLSO?= =?us-ascii?q?CWzGCMgWjFwKHeY0rghZjhS+EDocxljcCERkBgToBIQI1gU5vFToqAYF+CYQNP?= =?us-ascii?q?3iIB4EzgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,395,1508803200"; d="scan'208";a="321237950" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2017 00:08:01 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vBD081YU018813 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 00:08:01 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 12 Dec 2017 18:08:00 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Tue, 12 Dec 2017 18:08:00 -0600 From: "Naiming Shen (naiming)" To: Adam Bishop CC: "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTKHKrqtJDphnIu0Ga679ujWV4vKMqT+8AgBZxrICAAJ7zgA== Date: Wed, 13 Dec 2017 00:08:00 +0000 Message-ID: References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> In-Reply-To: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.173.17] Content-Type: text/plain; charset="utf-8" Content-ID: <7414E7FCE9118642BA581CAF1C27871D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 00:08:05 -0000 DQpJIGhhdmUgc2VlbiBzb21lIGNvbW1lbnRzIGFib3V0IHRoZSBkcmFmdC1jaGVuIHByb3Bvc2Fs IGhhcyB0aGUgcG90ZW50aWFsIG9mDQpsZWFraW5nIHRoZSBleHRlbmRlZC1JRCBieSB0aGUgcHJv eHkgc2VydmVyLg0KDQpGaXJzdCBvZiBhbGwsIGlmIGFuIGltcGxlbWVudGF0aW9uIGhhcyBidWdz IG9yIHRoZSBjb25maWd1cmF0aW9uIGlzIG1pc2hhbmRsZWQsDQp0aGVuIHdlIG5lZWQgaGF2ZSB3 YXlzIHRvIGRlYnVnIGFuZCB0cm91Ymxlc2hvb3QuIEJlaW5nIGFuIGF0dHJpYnV0ZSBnaXZlcw0K ZXhwbGljaXRseSB3YXlzIGZvciBkZWJ1Z2dpbmc7IEFuIGltcGxlbWVudGF0aW9uIHNob3VsZCBh bHNvIGhhdmUgaW5zdHJ1c3RtZW50DQpmb3IgYmV0dGVyIGRlYnVnIGluIHJhZGl1cyBwcm9ncmFt cy4NCg0KU2Vjb25kLCBzaW1pbGFyIHRvIHNvbWUgdHlwZXMgb2YgYXR0cmlidXRlcywgYSBwcm94 eSBjYW4gYmUgY29uZmlndXJlZCB0bw0KZXhwbGljaXRseSBmaWx0ZXIgdGhlbSBvdXQgKEZpbHRl ciBSYWRpdXMgQXR0cmlidXRlcykuIElmIHdlIGFyZSBhcmd1aW5nIHdlIGNhbg0Kbm90IHJlbHkg b24gdGhlIHByb3h5IHRvIGZpbHRlciB0aGVtIG91dCwgc2luY2UgdGhlcmUgbWlnaHQgYmUgYnVn cyBvcg0KbWlzY29uZmlndXJhdGlvbiwgdGh1cyB3ZSBzaG91bGQgbm90IGV2ZW4gYWxsb3cgdGhv c2UgYXR0cmlidXRlcyBpbiByYWRpdXMNCnBhY2tldHMsIHRoYXQgbG9naWMgZG9lcyBub3Qgc291 bmQgcmVhc29uYWJsZTsNCg0KVGhpcmQsIGlmIGFzc3VtZSBhbiBvcGVyYXRpb24gY29tcGxldGVs eSBtZXNzZWQgdXAsIGFuZCBsZWFraW5nIHRoaXMNCmV4dGVuZGVkLUlEIHRvd2FyZHMgdGhlIGhv bWUtc2VydmVyLCBJIHN0aWxsIG5lZWQgdG8gc2VlIGEgZ29vZCBleGFtcGxlDQpvbiB3aGF0IHRo ZSBoYXJtIGlzIHRoYXQsIGFuZCB3aHkgdGhpcyBjYW4gbm90IGJlIGRlYnVnZ2VkLiBUaGUgZHJh ZnQNCkkgYWdyZWUgbmVlZHMgdG8gYWRkIHNvbWUgdGV4dCBvbiB2YXJpb3VzIGNhc2VzIGFuZCBo b3cgdG8gZGVidWcNCnRob3NlIGluIGVhY2ggb2YgdGhlbS4NCg0KQmVzdCBSZWdhcmRzLA0KLSBO YWltaW5nDQoNCj4gT24gRGVjIDEyLCAyMDE3LCBhdCAxMjozOSBQTSwgQWRhbSBCaXNob3AgPEFk YW0uQmlzaG9wQGppc2MuYWMudWs+IHdyb3RlOg0KPiANCj4gT24gMjggTm92IDIwMTcsIGF0IDEz OjU0LCBTdGVmYW4gV2ludGVyIDxzdGVmYW4ud2ludGVyQHJlc3RlbmEubHU+IHdyb3RlOg0KPj4g SW4geW91ciByZXBseSB0byB0aGlzIGNhbGwgZm9yIGFkb3B0aW9uLCBwbGVhc2UgaW5kaWNhdGUg d2hpY2ggb2YgdGhlDQo+PiB0d28gZHJhZnRzIHlvdSB0aGluayBzaG91bGQgYmUgYWRvcHRlZC4g WW91IGNhbiBvZiBjb3Vyc2UgYWxzbyBpbmRpY2F0ZQ0KPj4gdGhhdCBub25lIG9mIHRoZSB0d28g YXJlIGZpdCBmb3IgcHVycG9zZS4gVGhlIG9ubHkgdGhpbmcgeW91IHJlYWxseQ0KPj4gc2hvdWxk bid0IGRvIGlzIHRvIHZvdGUgZm9yIGJvdGg7IHRoYXQgd291bGRuJ3QgaGVscCB0aGUgZGlzY3Vz c2lvbiBtb3ZlIG9uLg0KPiANCj4gSGF2aW5nIHJlYWQgYm90aCBkcmFmdHMsIEkgdGhpbmsgdGhl IGFwcHJvYWNoIGluIGRyYWZ0LWRla29rIGlzIG1vcmUgc3VpdGFibGUgZm9yIGFkb3B0aW9uLg0K PiANCj4gV2hpbGUgYXNzaWduaW5nIGFkZGl0aW9uYWwgbWVhbmluZyB0byBleGlzdGluZyB2YWx1 ZXMgY2FuIGJlIHByb2JsZW1hdGljLCB0aGVyZSBpcyBzdWZmaWNpZW50IGV4cGxhbmF0aW9uIGFs cmVhZHkgcHJlc2VudCBpbiB0aGUgZHJhZnQgdG8gcmVhc3N1cmUgbWUgdGhhdCB0aGlzIHNob3Vs ZG7igJl0IGludGVyYWN0IG5lZ2F0aXZlbHkgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMs IGFuZCBhdm9pZHMgY2hhbmdpbmcgb3IgZXh0ZW5kaW5nIHRoZSBoZWFkZXIuDQo+IA0KPiBJIGFn cmVlIHdpdGggdGhlIG9ic2VydmF0aW9uIHRoYXQgZHJhZnQtY2hlbiBjb3VsZCBiZSBwcm9ibGVt YXRpYyBpbiBmZWRlcmF0ZWQgZGVwbG95bWVudHMgZHVlIHRvIHRoZSBwb3RlbnRpYWwgZm9yIHRo ZSBpZGVudGlmaWVyIHRvIGxlYWsgYmV0d2VlbiBob3BzLg0KPiANCj4gUmVnYXJkcywNCj4gDQo+ IEFkYW0gQmlzaG9wDQo+IA0KPiAgZ3BnOiBFNzVCIDFGOTIgNjQwNyBERkRGIDlGMUMgIEJGMTAg Qzk5MyAyNTA0IDY2MDkgRDQ2MA0KPiANCj4gamlzYy5hYy51aw0KPiANCj4gSmlzYyBpcyBhIHJl Z2lzdGVyZWQgY2hhcml0eSAobnVtYmVyIDExNDk3NDApIGFuZCBhIGNvbXBhbnkgbGltaXRlZCBi eSBndWFyYW50ZWUgd2hpY2ggaXMgcmVnaXN0ZXJlZCBpbiBFbmdsYW5kIHVuZGVyIENvbXBhbnkg Tm8uIDU3NDczMzksIFZBVCBOby4gR0IgMTk3IDA2MzIgODYuIEppc2PigJlzIHJlZ2lzdGVyZWQg b2ZmaWNlIGlzOiBPbmUgQ2FzdGxlcGFyaywgVG93ZXIgSGlsbCwgQnJpc3RvbCwgQlMyIDBKQS4g VCAwMjAzIDY5NyA1ODAwLg0KPiANCj4gSmlzYyBTZXJ2aWNlcyBMaW1pdGVkIGlzIGEgd2hvbGx5 IG93bmVkIEppc2Mgc3Vic2lkaWFyeSBhbmQgYSBjb21wYW55IGxpbWl0ZWQgYnkgZ3VhcmFudGVl IHdoaWNoIGlzIHJlZ2lzdGVyZWQgaW4gRW5nbGFuZCB1bmRlciBjb21wYW55IG51bWJlciAyODgx MDI0LCBWQVQgbnVtYmVyIEdCIDE5NyAwNjMyIDg2LiBUaGUgcmVnaXN0ZXJlZCBvZmZpY2UgaXM6 IE9uZSBDYXN0bGUgUGFyaywgVG93ZXIgSGlsbCwgQnJpc3RvbCBCUzIgMEpBLiBUIDAyMDMgNjk3 IDU4MDAuICANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gcmFkZXh0IG1haWxpbmcgbGlzdA0KPiByYWRleHRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYWRleHQNCg0K From himanshu@viptela.com Tue Dec 12 15:18:24 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874DD12421A for ; Tue, 12 Dec 2017 15:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viptela-com.20150623.gappssmtp.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 7Xm5VnzHmwLT for ; Tue, 12 Dec 2017 15:18:23 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680A11200F1 for ; Tue, 12 Dec 2017 15:18:23 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id y187so189392ywd.12 for ; Tue, 12 Dec 2017 15:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viptela-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=WMILYBSpvDegyxxpqKCg4RZPh8aYvSRzQCY9jiZMb1g=; b=umCj/1xA9ucdNjcEljnC8BX0z9HAnLrTAjqd+/wCXhltyR92lwZRH1DYgcrD+lN4Zb LxBEKHEODMDM5k3zcISsWk50C80Q0XwCY2NJHcOEZ/YeMU6kMMzqT2osv17ci3RrzSSU Adgjgo/NTAc/aihDukqEWAlTeuStntKq3B64JjMa1lNY/MgL/6grsrCw+8ggAzL3LRxQ 9sWDO8t3Uj5NbpCzNQNZ+KPwYtNfQ3TilWginlZ0G3kYl9+qwRC0AMcKPI2znXgkZiO+ 4h8vM5mWsrvg4BsivfVaK6bJlKg7d2fytZgT67I1+D42SMAxMxM/I9njP9SXPO3ardw0 VulA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WMILYBSpvDegyxxpqKCg4RZPh8aYvSRzQCY9jiZMb1g=; b=TzcKBpoMqHRW/m8ImWqsgySoaQmEkEIv5utzc4o0DHwVK7MORGy+Q0NwOd78pHC0mK /QGlk22woQwhp2JjC9PSTwX78JgGhKAw/0J/IbVDZIHDEciTaIOv/ZWadsqgjKwbARXt tA28ujgxY7GVNk01JYoLi07Y4M0RQCLj3iGU2g0tyqhrjxAB0RSmKoa/F9sM5HFcZFR5 CyrthJhOzmWPsbxobZV7S7QwyhMiq9ixmIwkMqjbYTRIBXAdckyIB3q54UntA+p6gCgM AfFtpIDWCwXTSAvnroxnY5tvRCt18sG1yBVgjL9gZ45N756crWNQhZfjTEglSMknwMez vUZw== X-Gm-Message-State: AKGB3mJwyaiEO8bL/zv6SZvZndj+x9zjfaiVPN//M7pUSIEkht/rS+JL wKEVQSgrdTQdlIlY8D+4Ar4SOlHIQLWkkJ/5O+Ix2WMJx7w= X-Google-Smtp-Source: ACJfBout2aB7yY4ykES2ziRp6aiE8+bpmK+jEpeZg6zEK9fJHY7ANKG8Nklnx9XLBzx9f1vCbhRvtcy34zqJ6TK1eds= X-Received: by 10.129.172.13 with SMTP id k13mr378289ywh.275.1513120702493; Tue, 12 Dec 2017 15:18:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.2 with HTTP; Tue, 12 Dec 2017 15:17:52 -0800 (PST) From: Himanshu Shah Date: Tue, 12 Dec 2017 15:17:52 -0800 Message-ID: To: radext@ietf.org Content-Type: multipart/alternative; boundary="f403045e4800f98eb605602cdd4d" Archived-At: Subject: [radext] Extended IDs draft X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 00:26:22 -0000 --f403045e4800f98eb605602cdd4d Content-Type: text/plain; charset="UTF-8" While both draft-chen & draft-dekok works, I vote for draft-chen as it cleanly extends the existing behavior. It is more trouble-shooting friendly approach. Best -Himanshu --f403045e4800f98eb605602cdd4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While both draft-chen & draft-dekok works, I vote for = draft-chen as it cleanly extends the existing behavior. It is more trouble-= shooting friendly approach.

Best
-Himanshu
--f403045e4800f98eb605602cdd4d-- From nobody Tue Dec 12 16:52:53 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E9C12711D for ; Tue, 12 Dec 2017 16:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 46SPeuWfRU1G for ; Tue, 12 Dec 2017 16:52:50 -0800 (PST) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 21D0C126CBF for ; Tue, 12 Dec 2017 16:52:48 -0800 (PST) Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 12 Dec 2017 16:52:47 -0800 Date: Tue, 12 Dec 2017 16:52:50 -0800 (Pacific Standard Time) From: Peter Deacon To: "Naiming Shen (naiming)" cc: "radext@ietf.org" In-Reply-To: Message-ID: References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> User-Agent: Alpine 2.21.1 (WNT 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 00:52:52 -0000 On Wed, 13 Dec 2017, Naiming Shen (naiming) wrote: > Third, if assume an operation completely messed up, and leaking this > extended-ID towards the home-server, I still need to see a good example > on what the harm is that, and why this can not be debugged. The draft > I agree needs to add some text on various cases and how to debug > those in each of them. Offered an example in my initial response. More detail below. Request: [+Client] ---> [-Proxy A] ---> [+Proxy B] --> ... Response: ... ---> [+Proxy B] ---> [-Proxy A] ---> [+Client] + supports extended id - does not support extended id Assumptions: - Proxy A performs duplicate detection over (src ip/port) + id. - Requests transmitted from Client /w extended ID. - Client receives responses /w extended ID courtesy of Proxy B. This scenario can easily result in high numbers of intermittently dropped packets because Proxy A is intentionally dropping what it believes are duplicates. Proxy A does not implement extended id and so has no idea what is going on nor instrumented to know anything about extended id. Client is similarly clueless. It sees extended id requests AND extended id responses /w intermittent packet loss. It has no clue the upstream proxy it is directly communicating does not support extended id. There is no way for it to know. >From the client perspective it would in my experience likely be very difficult for an operator to troubleshoot this kind of intermittent failure one that gets progressively worse as load increases unless they had an unrealistically high degree of technical knowledge. This problem DOES NOT exist /w ORA because any and all such misconfiguration always results in client seeing no valid response at all. This is an acceptable response to misconfiguration. A client receiving bogus ORA from some other peer or no ORA at all is free to complain loudly explicitly alerting operators of misconfiguration. This option simply is not possible /w extended id. regards, Peter From nobody Tue Dec 12 17:00:28 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C138C12711D for ; Tue, 12 Dec 2017 17:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 LIqn_oZlKv9J for ; Tue, 12 Dec 2017 17:00:25 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE538126CBF for ; Tue, 12 Dec 2017 17:00:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3478; q=dns/txt; s=iport; t=1513126825; x=1514336425; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SYQK8zEdzHEw3RRrH2Tcs/7YsIWg3DTUbACXATeVHSA=; b=VSKZ5lcHEAzXJQ6DA/x+tWVkhiE4HKBGGl1AEK9SR1+vU5ZUtvtbOL01 fW1iWf7VZLaCQvRQm730rsleqZbmSJFcB2w7+gBKlIV/pCXIcQveAuxtg wqmgyST4LGSS3gFDWSAnqWXf/Io/fF2Lld5ow240QslqV9e9/z3AYfQSw s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DZAQCHejBa/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMPL4FaJweDe5kmgX2ZJgqCAYM6AhqEbkIVAQEBAQEBAQEBayi?= =?us-ascii?q?FIwEBAQECASMEDUUFCwIBCBgCAiYCAgIwFRACBA4FiiAIqEaBbTqKYAEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2BD4JUgguDaIMCgy+BWIMrMYIyAQSjFwKVJAyTW5Y?= =?us-ascii?q?3AhEZAYE6ATUjgU5vFWQBgX6EVXiJOoEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,395,1508803200"; d="scan'208";a="43844586" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2017 01:00:24 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vBD10O5V014261 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 01:00:24 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 12 Dec 2017 19:00:23 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Tue, 12 Dec 2017 19:00:23 -0600 From: "Naiming Shen (naiming)" To: Peter Deacon CC: "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTKHKrqtJDphnIu0Ga679ujWV4vKMqT+8AgBZxrICAAJ7zgIAADIgAgAACGYA= Date: Wed, 13 Dec 2017 01:00:23 +0000 Message-ID: References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.173.17] Content-Type: text/plain; charset="utf-8" Content-ID: <9A229043DF36FA4BA7ECB9959B2A9613@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 01:00:27 -0000 DQp0aGVuIHRoZSBDbGllbnQgd2hpY2ggaW5pdGlhdGVkIHRoaXMgY2FuIGRldGVjdCB0aGUgcmV0 dXJuZWQgcGFja2V0cywgYW5kDQp0ZXJtaW5hdGUgdGhlIGV4dGVuZGVkLUlEIHNjaGVtZS4gaXTi gJlzIHVwIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiB0byBkZXRlY3QNCnRoaXMuIGFsc28gSSBjYW4g bm90IGltYWdpbmcgdGhlIHNlcnZlci1zdGF0dXMgd2lsbCBiZSByZXR1cm5lZCB0byB0aGUgQ2xp ZW50DQpjb3JyZWN0bHkgaW4gdGhpcyBjYXNlIHRvIOKAmGZvb2zigJkgdGhlIENsaWVudCB0aGUg UHJveHktQSBzdXBwb3J0cyB0aGlzIGZlYXR1cmUuDQoNClJlZ2FyZHMsDQotIE5haW1pbmcNCg0K PiBPbiBEZWMgMTIsIDIwMTcsIGF0IDQ6NTIgUE0sIFBldGVyIERlYWNvbiA8cGV0ZXJkQGllYS1z b2Z0d2FyZS5jb20+IHdyb3RlOg0KPiANCj4gT24gV2VkLCAxMyBEZWMgMjAxNywgTmFpbWluZyBT aGVuIChuYWltaW5nKSB3cm90ZToNCj4gDQo+PiBUaGlyZCwgaWYgYXNzdW1lIGFuIG9wZXJhdGlv biBjb21wbGV0ZWx5IG1lc3NlZCB1cCwgYW5kIGxlYWtpbmcgdGhpcw0KPj4gZXh0ZW5kZWQtSUQg dG93YXJkcyB0aGUgaG9tZS1zZXJ2ZXIsIEkgc3RpbGwgbmVlZCB0byBzZWUgYSBnb29kIGV4YW1w bGUNCj4+IG9uIHdoYXQgdGhlIGhhcm0gaXMgdGhhdCwgYW5kIHdoeSB0aGlzIGNhbiBub3QgYmUg ZGVidWdnZWQuIFRoZSBkcmFmdA0KPj4gSSBhZ3JlZSBuZWVkcyB0byBhZGQgc29tZSB0ZXh0IG9u IHZhcmlvdXMgY2FzZXMgYW5kIGhvdyB0byBkZWJ1Zw0KPj4gdGhvc2UgaW4gZWFjaCBvZiB0aGVt Lg0KPiANCj4gT2ZmZXJlZCBhbiBleGFtcGxlIGluIG15IGluaXRpYWwgcmVzcG9uc2UuICBNb3Jl IGRldGFpbCBiZWxvdy4NCj4gDQo+IFJlcXVlc3Q6DQo+IFsrQ2xpZW50XSAgLS0tPiBbLVByb3h5 IEFdIC0tLT4gWytQcm94eSBCXSAtLT4gLi4uDQo+IA0KPiBSZXNwb25zZToNCj4gLi4uIC0tLT4g WytQcm94eSBCXSAtLS0+IFstUHJveHkgQV0gLS0tPiBbK0NsaWVudF0NCj4gDQo+ICsgc3VwcG9y dHMgZXh0ZW5kZWQgaWQNCj4gLSBkb2VzIG5vdCBzdXBwb3J0IGV4dGVuZGVkIGlkDQo+IA0KPiAN Cj4gQXNzdW1wdGlvbnM6DQo+IA0KPiAtIFByb3h5IEEgcGVyZm9ybXMgZHVwbGljYXRlIGRldGVj dGlvbiBvdmVyIChzcmMgaXAvcG9ydCkgKyBpZC4NCj4gLSBSZXF1ZXN0cyB0cmFuc21pdHRlZCBm cm9tIENsaWVudCAvdyBleHRlbmRlZCBJRC4NCj4gLSBDbGllbnQgcmVjZWl2ZXMgcmVzcG9uc2Vz IC93IGV4dGVuZGVkIElEIGNvdXJ0ZXN5IG9mIFByb3h5IEIuDQo+IA0KPiANCj4gVGhpcyBzY2Vu YXJpbyBjYW4gZWFzaWx5IHJlc3VsdCBpbiBoaWdoIG51bWJlcnMgb2YgaW50ZXJtaXR0ZW50bHkg ZHJvcHBlZCBwYWNrZXRzIGJlY2F1c2UgUHJveHkgQSBpcyBpbnRlbnRpb25hbGx5IGRyb3BwaW5n IHdoYXQgaXQgYmVsaWV2ZXMgYXJlIGR1cGxpY2F0ZXMuICBQcm94eSBBIGRvZXMgbm90IGltcGxl bWVudCBleHRlbmRlZCBpZCBhbmQgc28gaGFzIG5vIGlkZWEgd2hhdCBpcyBnb2luZyBvbiBub3Ig aW5zdHJ1bWVudGVkIHRvIGtub3cgYW55dGhpbmcgYWJvdXQgZXh0ZW5kZWQgaWQuDQo+IA0KPiBD bGllbnQgaXMgc2ltaWxhcmx5IGNsdWVsZXNzLiAgSXQgc2VlcyBleHRlbmRlZCBpZCByZXF1ZXN0 cyBBTkQgZXh0ZW5kZWQgaWQgcmVzcG9uc2VzIC93IGludGVybWl0dGVudCBwYWNrZXQgbG9zcy4g IEl0IGhhcyBubyBjbHVlIHRoZSB1cHN0cmVhbSBwcm94eSBpdCBpcyBkaXJlY3RseSBjb21tdW5p Y2F0aW5nIGRvZXMgbm90IHN1cHBvcnQgZXh0ZW5kZWQgaWQuICBUaGVyZSBpcyBubyB3YXkgZm9y IGl0IHRvIGtub3cuDQo+IA0KPiBGcm9tIHRoZSBjbGllbnQgcGVyc3BlY3RpdmUgaXQgd291bGQg aW4gbXkgZXhwZXJpZW5jZSBsaWtlbHkgYmUgdmVyeSBkaWZmaWN1bHQgZm9yIGFuIG9wZXJhdG9y IHRvIHRyb3VibGVzaG9vdCB0aGlzIGtpbmQgb2YgaW50ZXJtaXR0ZW50IGZhaWx1cmUgb25lIHRo YXQgZ2V0cyBwcm9ncmVzc2l2ZWx5IHdvcnNlIGFzIGxvYWQgaW5jcmVhc2VzIHVubGVzcyB0aGV5 IGhhZCBhbiB1bnJlYWxpc3RpY2FsbHkgaGlnaCBkZWdyZWUgb2YgdGVjaG5pY2FsIGtub3dsZWRn ZS4NCj4gDQo+IA0KPiBUaGlzIHByb2JsZW0gRE9FUyBOT1QgZXhpc3QgL3cgT1JBIGJlY2F1c2Ug YW55IGFuZCBhbGwgc3VjaCBtaXNjb25maWd1cmF0aW9uIGFsd2F5cyByZXN1bHRzIGluIGNsaWVu dCBzZWVpbmcgbm8gdmFsaWQgcmVzcG9uc2UgYXQgYWxsLiBUaGlzIGlzIGFuIGFjY2VwdGFibGUg cmVzcG9uc2UgdG8gbWlzY29uZmlndXJhdGlvbi4NCj4gDQo+IEEgY2xpZW50IHJlY2VpdmluZyBi b2d1cyBPUkEgZnJvbSBzb21lIG90aGVyIHBlZXIgb3Igbm8gT1JBIGF0IGFsbCBpcyBmcmVlIHRv IGNvbXBsYWluIGxvdWRseSBleHBsaWNpdGx5IGFsZXJ0aW5nIG9wZXJhdG9ycyBvZiBtaXNjb25m aWd1cmF0aW9uLiBUaGlzIG9wdGlvbiBzaW1wbHkgaXMgbm90IHBvc3NpYmxlIC93IGV4dGVuZGVk IGlkLg0KPiANCj4gcmVnYXJkcywNCj4gUGV0ZXINCg0K From nobody Tue Dec 12 17:41:52 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C83126CBF for ; Tue, 12 Dec 2017 17:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 zf5PxHAYd9Yl for ; Tue, 12 Dec 2017 17:41:49 -0800 (PST) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 87AEE120727 for ; Tue, 12 Dec 2017 17:41:49 -0800 (PST) Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 12 Dec 2017 17:41:49 -0800 Date: Tue, 12 Dec 2017 17:41:52 -0800 (Pacific Standard Time) From: Peter Deacon To: "Naiming Shen (naiming)" cc: "radext@ietf.org" In-Reply-To: Message-ID: References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> User-Agent: Alpine 2.21.1 (WNT 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1014921081-9837-1513128124=:2252" Content-ID: Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 01:41:51 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1014921081-9837-1513128124=:2252 Content-Type: text/plain; CHARSET=ISO-8859-7; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Wed, 13 Dec 2017, Naiming Shen (naiming) wrote: > then the Client which initiated this can detect the returned packets, > and terminate the extended-ID scheme. its up to the implementation to > detect this. How specifically can this be achieved? What is your proposal? Risks? Implementation complexity? > also I can not imaging the server-status will be returned to the Client > correctly in this case to fool the Client the Proxy-A supports this > feature. Does extended id draft support manual configuration? The question on the table is not whether extended id is good or bad in a vacuum. The question is which of the options is technically the better option on the merits. regards, Peter ---1014921081-9837-1513128124=:2252-- From nobody Tue Dec 12 18:07:41 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D051127909 for ; Tue, 12 Dec 2017 18:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 pvGdjlupxc02 for ; Tue, 12 Dec 2017 18:07:37 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88838126CBF for ; Tue, 12 Dec 2017 18:07:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2292; q=dns/txt; s=iport; t=1513130857; x=1514340457; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nSZQpeGEnyfc1JlZ2K5Hi5FO/MnUdLRysgK5CN53jJY=; b=U1sE+Hca2A0Fl3+LP/Bg146blLrs3kRUZTgAluZXZclp+fKElB55PD3I UjIaAzfcagg+1zujd5GfFsm85Bq8UqokTD4zdvmeZ8+IM7b5lCiMOKocI bBjAB2zbFrzu33hoVQs7X1d07zy0zsSQ2jBcXIaASAai88BPL/v3M0+wu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAQCSijBa/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+gVonB4N7mSaBfZcRghUKggGDOgIahG5BFgEBAQEBAQEBAWs?= =?us-ascii?q?ohSMBAQEBAgEjEToLBQsCAQgYAgImAgICMBUQAgQOBYogCKg2gieKYAEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2BD4JUgguDaIMCgy+BWBaDFTGCMgEEoxcClSSTZ5Y?= =?us-ascii?q?3AhEZAYE6ASYKKIFObxU6KgGBfoRVeIk6gRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,396,1508803200"; d="scan'208";a="113758052" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2017 02:07:36 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vBD27aTV017225 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 02:07:36 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 12 Dec 2017 20:07:36 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Tue, 12 Dec 2017 20:07:36 -0600 From: "Naiming Shen (naiming)" To: Peter Deacon CC: "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTKHKrqtJDphnIu0Ga679ujWV4vKMqT+8AgBZxrICAAJ7zgIAADIgAgAACGYCAAAuaAIAABy4A Date: Wed, 13 Dec 2017 02:07:36 +0000 Message-ID: References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.173.17] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 02:07:40 -0000 DQo+IE9uIERlYyAxMiwgMjAxNywgYXQgNTo0MSBQTSwgUGV0ZXIgRGVhY29uIDxwZXRlcmRAaWVh LXNvZnR3YXJlLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiBXZWQsIDEzIERlYyAyMDE3LCBOYWltaW5n IFNoZW4gKG5haW1pbmcpIHdyb3RlOg0KPiANCj4+IHRoZW4gdGhlIENsaWVudCB3aGljaCBpbml0 aWF0ZWQgdGhpcyBjYW4gZGV0ZWN0IHRoZSByZXR1cm5lZCBwYWNrZXRzLCBhbmQgdGVybWluYXRl IHRoZSBleHRlbmRlZC1JRCBzY2hlbWUuIGl04oCZcyB1cCB0byB0aGUgaW1wbGVtZW50YXRpb24g dG8gZGV0ZWN0IHRoaXMuDQo+IA0KPiBIb3cgc3BlY2lmaWNhbGx5IGNhbiB0aGlzIGJlIGFjaGll dmVkPyAgV2hhdCBpcyB5b3VyIHByb3Bvc2FsPyAgUmlza3M/IEltcGxlbWVudGF0aW9uIGNvbXBs ZXhpdHk/DQoNCkFzIHRoZSBkcmFmdCBjdXJyZW50bHkgc3BlY2lmaWVkLCB0aGUgc2VydmVyLXN0 YXR1cyBtZXNzYWdlIHJldHVybmVkIGJ5IHRoZSBwcm94eS9zZXJ2ZXIgaGFzIHRvIG1hdGNoDQp0 aGUgc3BlY2lmaWVkIHBhdHRlcm4vYml0czsgdGhlIHJldHVybmVkIGF1dGhlbnRpY2F0aW9uLXJl cGx5IG1lc3NhZ2UgaGFzIHRvIG1hdGNoIHRoZSBpZCwgZXh0ZW5kZWQtaWQsDQppZiBub3QgdGhl cmUgaXMgYW4gZXJyb3IuIGlmIHRoZSBlcnJvciBpcyBhY2N1bXVsYXRlZCwgdGhlIHJhZGl1cy1j bGllbnQgc2hvdWxkIGtub3cuIHNpbXBsZSB0byBpbXBsZW1lbnQuDQoNCj4gDQo+PiBhbHNvIEkg Y2FuIG5vdCBpbWFnaW5nIHRoZSBzZXJ2ZXItc3RhdHVzIHdpbGwgYmUgcmV0dXJuZWQgdG8gdGhl IENsaWVudCBjb3JyZWN0bHkgaW4gdGhpcyBjYXNlIHRvIOKAmGZvb2zigJkgdGhlIENsaWVudCB0 aGUgUHJveHktQSBzdXBwb3J0cyB0aGlzIGZlYXR1cmUuDQo+IA0KPiBEb2VzIGV4dGVuZGVkIGlk IGRyYWZ0IHN1cHBvcnQgbWFudWFsIGNvbmZpZ3VyYXRpb24/DQoNClRoZSBkcmFmdCBzcGVjaWZp aWVzIHRoZSBtZWNoYW5pc20sIG5vdCB0aGUgb3BlcmF0aW9ucy4gQnV0IG15IHBhdGNoIGZvciB0 aGlzIGRyYWZ0IG9uIEZyZWVSYWRpdXMsDQpkb2VzIHN1cHBvcnQgbWFudWFsIGNvbmZpZ3VyYXRp b24gb24gdGhlIGNsaWVudCBhbmQgcHJveHkuIEkgc2VudCBteSBwYXRjaCB0byB0aGlzIG1haWxp bmcgbGlzdA0KbW9udGhzIGFnby4gVGhpcyBpcyB0aGUgd2F5IHRvIHNob3cgaG93IHNpbXBsZSB0 aGlzIG1lY2hhbmlzbS4gV2l0aCBjbGllbnQvcHJveHkvc2VydmVyLCB3aXRoDQp0ZXN0ZWQgb24g VURQL1RDUCwgdG90YWwgb2YgMjAwIGxpbmVzIG9mIEMgY29kZS4NCg0KPiANCj4gVGhlIHF1ZXN0 aW9uIG9uIHRoZSB0YWJsZSBpcyBub3Qgd2hldGhlciBleHRlbmRlZCBpZCBpcyBnb29kIG9yIGJh ZCBpbiBhIHZhY3V1bS4gIFRoZSBxdWVzdGlvbiBpcyB3aGljaCBvZiB0aGUgb3B0aW9ucyBpcyB0 ZWNobmljYWxseSB0aGUgYmV0dGVyIG9wdGlvbiBvbiB0aGUgbWVyaXRzLg0KDQpJIHVuZGVyc3Rh bmQuIFRoaXMgaXMgd2h5IEkgdGhpbmsgZHJhZnQtY2hlbiBpcyB0aGUgYmV0dGVyIG9uZS4gc2lt cGxlLCBub3Qgb3ZlcmxvYWRpbmcNCnRoZSBvcmlnaW5hbCByYWRpdXMgaGVhZGVyIGRlZmluaXRp b25zLCBlYXN5IHRvIGltcGxlbWVudC4NCg0KUmVnYXJkcywNCi0gTmFpbWluZw0KDQo+IA0KPiBy ZWdhcmRzLA0KPiBQZXRlcg0KDQo= From nobody Tue Dec 12 18:49:27 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E48A1289B5 for ; Tue, 12 Dec 2017 18:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 wzA44TFqMIx2 for ; Tue, 12 Dec 2017 18:49:25 -0800 (PST) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id EABED126CBF for ; Tue, 12 Dec 2017 18:49:24 -0800 (PST) Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 12 Dec 2017 18:49:24 -0800 Date: Tue, 12 Dec 2017 18:49:27 -0800 (Pacific Standard Time) From: Peter Deacon To: "Naiming Shen (naiming)" cc: "radext@ietf.org" In-Reply-To: Message-ID: References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> User-Agent: Alpine 2.21.1 (WNT 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII; FORMAT=flowed Content-ID: Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 02:49:26 -0000 On Wed, 13 Dec 2017, Naiming Shen (naiming) wrote: >> How specifically can this be achieved? What is your proposal? Risks? >> Implementation complexity? > As the draft currently specified, the server-status message returned by > the proxy/server has to match the specified pattern/bits; the returned Please assume status server is NOT being used and all configuration is manual as allowed per section 2.2: " Unless specified by configuration, a client MUST NOT send a RADIUS packet (other than the Status-Server request) with the "Extended Identifier Attribute" to a server until it has received a response from the server confirming its support for the Extended Identifier feature using the "Extended Identifier Attribute"." I failed to explicitly state this when responding to your question regarding misconfiguration and ability for clients to detect problems. I apologize for any confusion this has caused. > authentication-reply message has to match the id, extended-id, if not > there is an error. if the error is accumulated, the radius-client should > know. simple to implement. Unfortunately it's not this simple. The problem described is one in which packets are being dropped while at the same time the client is also receiving exact extended-id attribute and values it expects to see during normal successful operation. How does detection algorithm work so client can detect this misconfiguration? How does it know lack of any response packet is caused by misconfiguration vs packet loss and or system issues? Can you offer technical details? regards, Peter From nobody Tue Dec 12 19:19:53 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C991270B4 for ; Tue, 12 Dec 2017 19:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 1vDAWwUJPGuT for ; Tue, 12 Dec 2017 19:19:49 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82923126CBF for ; Tue, 12 Dec 2017 19:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3408; q=dns/txt; s=iport; t=1513135189; x=1514344789; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ptAHJ1aiJQ7bBWn9fU6tv1wA0z7KOWalVDw7G5BCUp4=; b=lGmZJYvCQig34APTrWi7Jz65ooyNRZ1ic4rFMS6pP70exHLe3Q+74Brh RniW58f6/Y4G9polAN/kF/u6moedJ+LN+LU5I6zFIRX7QWkR5ECrUnj09 WIiG6wOycXx1l27tPWAnQwTBi2dv85E+MWemfCqqwOTfsp6/cgkaMqQJP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAAA/mzBa/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMPL4FaJweDe4ohjwWBVyaXEYIVCoIBgzoCGoRuPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUjAQEBAQIBIxFFBQsCAQgYAgImAgICMBUQAgQOBYogCKg0gieKYAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2BD4JUgguDaAuCd4MvgVgWgxUxgjIBBIpAiUO?= =?us-ascii?q?PFAKVJIIWhhKLP5Y3AhEZAYE6AR85gU5vFToqAYF+hFV4iTqBFQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,396,1508803200"; d="scan'208";a="43348810" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2017 03:19:48 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vBD3JmJk031642 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 03:19:48 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 12 Dec 2017 21:19:47 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Tue, 12 Dec 2017 21:19:48 -0600 From: "Naiming Shen (naiming)" To: Peter Deacon CC: "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTKHKrqtJDphnIu0Ga679ujWV4vKMqT+8AgBZxrICAAJ7zgIAADIgAgAACGYCAAAuaAIAABy4AgAALtICAAAh4AA== Date: Wed, 13 Dec 2017 03:19:48 +0000 Message-ID: <313FEFCE-FD61-4394-804D-91BAE98CA687@cisco.com> References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.173.17] Content-Type: text/plain; charset="utf-8" Content-ID: <83EBA377EB80EE47A53B0BB52AA0A721@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 03:19:51 -0000 DQpJZiB5b3UgaW5zaXN0IG1pc2NvbmZpZ3VyYXRpb24gaXMgdGhlIGdyZWF0ZXN0IHRoaW5nIHdl IGhhdmUgdG8gZGVhbCB3aXRoLA0KdGhlbiBJIGNhbiBpbWFnaW5lIHlvdSBtaXNjb25maWd1cmFl IHlvdXIgc2VydmVyIGlwIGFkZHJlc3MgYW5kIHByb3h5IGlwIGFkZHJlc3MsDQphbmQgcGFja2V0 cyB3aWxsIG5vdCBiZSByZXR1cm5lZCwgaG93IHRvIHlvdSB0cm91Ymxlc2hvb3QgdGhhdD8gaWYg eW91IGRvDQpoYXZlIHdheXMsIGFuZCB0aGlzIGRyYWZ0IGFsc28gaGF2ZSB3YXlzLiBDYW4geW91 IGltYWdpbmcgYW4gb3BlcmF0b3INCmluc2lzdCB0byBkbyBhIG1hbnVhbCBjb25maWd1cmF0aW9u IHdpdGhvdXQgY2hlY2sgdGhlIHN0YXR1cyBvZiB0aGUgc2VydmVyLA0KYW5kIHdpdGhvdXQgZG9p bmcgYW55IGNoZWNraW5nIGFmdGVyIG1hbnVhbCB0dXJuaW5nIG9uIGEgbmV3IGZlYXR1cmUsIGFu ZA0KanVzdCBoYXZlIHRvIG1pc2NvbmZpZ3VyZSBoaXMvaGVyIHJhZGl1cyBjbGllbnQ/IGFtYXpp bmcuLi4NCg0KYW55IHRleHQgeW91IG1lbnRpb24gY2FuIGNoYW5nZSBhbHNvLCBpdOKAmXMgdXAg dG8gdGhlIHdvcmtpbmcgZ3JvdXAgaG93IGl0DQpzdXBwb3J0cyB0byB3b3JrIGV2ZW50dWFsbHku DQoNCmFzIEkgbWVudGlvbmVkLCB0aGUgZHJhZnQtY2hlbiBuZWVkcyB0byBiZSB1cGRhdGVkIGZy b20gdGhlIGNvbW1lbnRzIG9mIHRoaXMNCmVtYWlsaW5nIGxpc3QuDQoNClJlZ2FyZHMsDQotIE5h aW1pbmcNCg0KPiBPbiBEZWMgMTIsIDIwMTcsIGF0IDY6NDkgUE0sIFBldGVyIERlYWNvbiA8cGV0 ZXJkQGllYS1zb2Z0d2FyZS5jb20+IHdyb3RlOg0KPiANCj4gT24gV2VkLCAxMyBEZWMgMjAxNywg TmFpbWluZyBTaGVuIChuYWltaW5nKSB3cm90ZToNCj4gDQo+Pj4gSG93IHNwZWNpZmljYWxseSBj YW4gdGhpcyBiZSBhY2hpZXZlZD8gIFdoYXQgaXMgeW91ciBwcm9wb3NhbD8gIFJpc2tzPyBJbXBs ZW1lbnRhdGlvbiBjb21wbGV4aXR5Pw0KPiANCj4+IEFzIHRoZSBkcmFmdCBjdXJyZW50bHkgc3Bl Y2lmaWVkLCB0aGUgc2VydmVyLXN0YXR1cyBtZXNzYWdlIHJldHVybmVkIGJ5IHRoZSBwcm94eS9z ZXJ2ZXIgaGFzIHRvIG1hdGNoIHRoZSBzcGVjaWZpZWQgcGF0dGVybi9iaXRzOyB0aGUgcmV0dXJu ZWQNCj4gDQo+IFBsZWFzZSBhc3N1bWUgc3RhdHVzIHNlcnZlciBpcyBOT1QgYmVpbmcgdXNlZCBh bmQgYWxsIGNvbmZpZ3VyYXRpb24gaXMgbWFudWFsIGFzIGFsbG93ZWQgcGVyIHNlY3Rpb24gMi4y Og0KPiANCj4gIiAgVW5sZXNzIHNwZWNpZmllZCBieSBjb25maWd1cmF0aW9uLCBhIGNsaWVudCBN VVNUIE5PVCBzZW5kIGEgUkFESVVTDQo+ICAgcGFja2V0IChvdGhlciB0aGFuIHRoZSBTdGF0dXMt U2VydmVyIHJlcXVlc3QpIHdpdGggdGhlICJFeHRlbmRlZA0KPiAgIElkZW50aWZpZXIgQXR0cmli dXRlIiB0byBhIHNlcnZlciB1bnRpbCBpdCBoYXMgcmVjZWl2ZWQgYSByZXNwb25zZQ0KPiAgIGZy b20gdGhlIHNlcnZlciBjb25maXJtaW5nIGl0cyBzdXBwb3J0IGZvciB0aGUgRXh0ZW5kZWQgSWRl bnRpZmllcg0KPiAgIGZlYXR1cmUgdXNpbmcgdGhlICJFeHRlbmRlZCBJZGVudGlmaWVyIEF0dHJp YnV0ZSIuIg0KPiANCj4gSSBmYWlsZWQgdG8gZXhwbGljaXRseSBzdGF0ZSB0aGlzIHdoZW4gcmVz cG9uZGluZyB0byB5b3VyIHF1ZXN0aW9uIHJlZ2FyZGluZyBtaXNjb25maWd1cmF0aW9uIGFuZCBh YmlsaXR5IGZvciBjbGllbnRzIHRvIGRldGVjdCBwcm9ibGVtcy4gIEkgYXBvbG9naXplIGZvciBh bnkgY29uZnVzaW9uIHRoaXMgaGFzIGNhdXNlZC4NCj4gDQo+PiBhdXRoZW50aWNhdGlvbi1yZXBs eSBtZXNzYWdlIGhhcyB0byBtYXRjaCB0aGUgaWQsIGV4dGVuZGVkLWlkLCBpZiBub3QgdGhlcmUg aXMgYW4gZXJyb3IuIGlmIHRoZSBlcnJvciBpcyBhY2N1bXVsYXRlZCwgdGhlIHJhZGl1cy1jbGll bnQgc2hvdWxkIGtub3cuIHNpbXBsZSB0byBpbXBsZW1lbnQuDQo+IA0KPiBVbmZvcnR1bmF0ZWx5 IGl0J3Mgbm90IHRoaXMgc2ltcGxlLiAgVGhlIHByb2JsZW0gZGVzY3JpYmVkIGlzIG9uZSBpbiB3 aGljaCBwYWNrZXRzIGFyZSBiZWluZyBkcm9wcGVkIHdoaWxlIGF0IHRoZSBzYW1lIHRpbWUgdGhl IGNsaWVudCBpcyBhbHNvIHJlY2VpdmluZyBleGFjdCBleHRlbmRlZC1pZCBhdHRyaWJ1dGUgYW5k IHZhbHVlcyBpdCBleHBlY3RzIHRvIHNlZSBkdXJpbmcgbm9ybWFsIHN1Y2Nlc3NmdWwgb3BlcmF0 aW9uLg0KPiANCj4gSG93IGRvZXMgZGV0ZWN0aW9uIGFsZ29yaXRobSB3b3JrIHNvIGNsaWVudCBj YW4gZGV0ZWN0IHRoaXMgbWlzY29uZmlndXJhdGlvbj8gIEhvdyBkb2VzIGl0IGtub3cgbGFjayBv ZiBhbnkgcmVzcG9uc2UgcGFja2V0IGlzIGNhdXNlZCBieSBtaXNjb25maWd1cmF0aW9uIHZzIHBh Y2tldCBsb3NzIGFuZCBvciBzeXN0ZW0gaXNzdWVzPyAgQ2FuIHlvdSBvZmZlciB0ZWNobmljYWwg ZGV0YWlscz8NCj4gDQo+IHJlZ2FyZHMsDQo+IFBldGVyDQoNCg== From nobody Tue Dec 12 21:58:49 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25AD126DFE for ; Tue, 12 Dec 2017 21:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 Nfx7qBVcvrzm for ; Tue, 12 Dec 2017 21:58:47 -0800 (PST) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 67122124BE8 for ; Tue, 12 Dec 2017 21:58:47 -0800 (PST) Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 12 Dec 2017 21:58:47 -0800 Date: Tue, 12 Dec 2017 21:58:50 -0800 (Pacific Standard Time) From: Peter Deacon To: "Naiming Shen (naiming)" cc: "radext@ietf.org" In-Reply-To: <313FEFCE-FD61-4394-804D-91BAE98CA687@cisco.com> Message-ID: References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> <313FEFCE-FD61-4394-804D-91BAE98CA687@cisco.com> User-Agent: Alpine 2.21.1 (WNT 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 05:58:48 -0000 On Wed, 13 Dec 2017, Naiming Shen (naiming) wrote: > If you insist misconfiguration is the greatest thing we have to deal with, Decision to expand on original remarks in response to call for adoption was result of your inquiry: "Third, if assume an operation completely messed up, and leaking this extended-ID towards the home-server, I still need to see a good example on what the harm is that, and why this can not be debugged. The draft I agree needs to add some text on various cases and how to debug those in each of them." Otherwise I am happy with the relative strength of my remarks in their original context. > then I can imagine you misconfigurae your server ip address and proxy ip address, > and packets will not be returned, how to you troubleshoot that? if you do If when manually switched on in an environment where it should not be the result is not working at all that would be perfectly fine. Unfortunatly as I have shown this is not the case with extended-id. In this aspect of consideration ORA clearly has an advantage both in ability to detect and report failure and nature of failure itself. > have ways, and this draft also have ways. Can you imaging an operator > insist to do a manual configuration without check the status of the server, Yes absolutely. This will defiantly occur. Status-server is not universally supported. regards, Peter From nobody Tue Dec 12 22:08:12 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B97128DF3 for ; Tue, 12 Dec 2017 22:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 WwwLbVDksbcM for ; Tue, 12 Dec 2017 22:08:09 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F1A124BE8 for ; Tue, 12 Dec 2017 22:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3038; q=dns/txt; s=iport; t=1513145288; x=1514354888; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JQsYoaMpb6mNiXtGEquImU6oa1zsNJBT1vZuA2kXbh0=; b=KM611ivO2IV4vxPpwPlrHAk8HFsL6lRobY5ljhti/52PIIuTpKK0WPZU tg/ZLedQlQQEDT48PmoVnNg7UddZIuOki2agB4fPk1B9JGr63U7StE7sH ph+ffizpJwOgojATiuHcxWlLHpwg7kDcG49pFGOiRcUc6Dw9ew+z0t8yN M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAgA7wzBa/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+gVonB4N7mSaBfZkmCoIBgzoCGoRuQhUBAQEBAQEBAQFrKIU?= =?us-ascii?q?jAQEBAQIBHQYRRQULAgEIGAICJgICAjAVEAIEDgWKIAioKoInimEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR6BD4JUgguDPymDAoMvgVgWgxUxgjIFoxkClSSTZ5Y5AhE?= =?us-ascii?q?ZAYE6ATUjgU5vFWQBgX6EVXiJLoEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,397,1508803200"; d="scan'208";a="43922199" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2017 06:08:08 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vBD688p6017017 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 06:08:08 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Dec 2017 00:08:07 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Wed, 13 Dec 2017 00:08:07 -0600 From: "Naiming Shen (naiming)" To: Peter Deacon CC: "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTKHKrqtJDphnIu0Ga679ujWV4vKMqT+8AgBZxrICAAJ7zgIAADIgAgAACGYCAAAuaAIAABy4AgAALtICAAAh4AIAALHEAgAAClwA= Date: Wed, 13 Dec 2017 06:08:07 +0000 Message-ID: <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com> References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> <313FEFCE-FD61-4394-804D-91BAE98CA687@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.71.8] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 06:08:10 -0000 DQpXaGVuIEkgc2F5IOKAnGNoZWNrIHRoZSBzdGF0dXMgb2YgdGhlIHNlcnZlcuKAnSwgc29ycnkg SSBkaWRu4oCZdCBtZWFuIHRoZSBzZXJ2ZXItc3RhdHVzDQptZXNzYWdlLiBXaGVuIGFuIG9wZXJh dG9yIGRlY2lkZXMgdG8gZG8gbWFudWFsIGNvbmZpZ3VyYXRpb24gb2YgYSBuZXcgZmVhdHVyZQ0K YW5kIG92ZXJyaWRlIHRoZSBub3JtYWwgYXV0b21hdGVkIGRpc2NvdmVyeSBwcm9jZWR1cmUsIGhl L3NoZSBuZWVkcyB0byBjaGVjaw0KdGhlIHJhZGl1cyBzZXJ2ZXIgYW5kL29yIHJhZGl1cyBwcm94 eSBzZXJ2ZXIgc29mdHdhcmUgdmVyc2lvbiwgc3RhdHVzLCBldGMuIEhlL3NoZSB3b3VsZA0Kbm90 IGp1c3QgYmxpbmRseSBjb25maWd1cmUgdGhlIG5ldyBmZWF0dXJlLCBhbmQgZ28gaG9tZSB0byBz bGVlcCBhbmQgYXNzdW1lDQpldmVyeXRoaW5nIGlzIGZpbmUuIFRoYXQncyBqdXN0IGNvbW1vbiBz ZW5zZS4gDQoNCkJUVywgU3RhdHVzLXNlcnZlciBpcyBub3Qgc3VwcG9ydGVkIHVuaXZlcnNhbGx5 IGlzIG5vdCBhIHByb2JsZW0gaGVyZS4NCldoZW4gdGhlIHNlcnZlciBzb2Z0d2FyZSBzdXBwb3J0 cyB0aGlzIGRyYWZ0LCB0aGVuIGl0IE1VU1QgaW1wbGVtZW50IHRoZQ0KU3RhdHVzLXNlcnZlciBt ZXNzYWdlIGF0IGxlYXN0IGZvciB0aGlzIGZlYXR1cmUuDQoNClJlZ2FyZHMsDQotIE5haW1pbmcN Cg0KPiBPbiBEZWMgMTIsIDIwMTcsIGF0IDk6NTggUE0sIFBldGVyIERlYWNvbiA8cGV0ZXJkQGll YS1zb2Z0d2FyZS5jb20+IHdyb3RlOg0KPiANCj4gT24gV2VkLCAxMyBEZWMgMjAxNywgTmFpbWlu ZyBTaGVuIChuYWltaW5nKSB3cm90ZToNCj4gDQo+PiBJZiB5b3UgaW5zaXN0IG1pc2NvbmZpZ3Vy YXRpb24gaXMgdGhlIGdyZWF0ZXN0IHRoaW5nIHdlIGhhdmUgdG8gZGVhbCB3aXRoLA0KPiANCj4g RGVjaXNpb24gdG8gZXhwYW5kIG9uIG9yaWdpbmFsIHJlbWFya3MgaW4gcmVzcG9uc2UgdG8gY2Fs bCBmb3IgYWRvcHRpb24gd2FzIHJlc3VsdCBvZiB5b3VyIGlucXVpcnk6DQo+IA0KPiAiVGhpcmQs IGlmIGFzc3VtZSBhbiBvcGVyYXRpb24gY29tcGxldGVseSBtZXNzZWQgdXAsIGFuZCBsZWFraW5n IHRoaXMgZXh0ZW5kZWQtSUQgdG93YXJkcyB0aGUgaG9tZS1zZXJ2ZXIsIEkgc3RpbGwgbmVlZCB0 byBzZWUgYSBnb29kIGV4YW1wbGUgb24gd2hhdCB0aGUgaGFybSBpcyB0aGF0LCBhbmQgd2h5IHRo aXMgY2FuIG5vdCBiZSBkZWJ1Z2dlZC4gVGhlIGRyYWZ0IEkgYWdyZWUgbmVlZHMgdG8gYWRkIHNv bWUgdGV4dCBvbiB2YXJpb3VzIGNhc2VzIGFuZCBob3cgdG8gZGVidWcgdGhvc2UgaW4gZWFjaCBv ZiB0aGVtLiINCj4gDQo+IE90aGVyd2lzZSBJIGFtIGhhcHB5IHdpdGggdGhlIHJlbGF0aXZlIHN0 cmVuZ3RoIG9mIG15IHJlbWFya3MgaW4gdGhlaXIgb3JpZ2luYWwgY29udGV4dC4NCj4gDQo+PiB0 aGVuIEkgY2FuIGltYWdpbmUgeW91IG1pc2NvbmZpZ3VyYWUgeW91ciBzZXJ2ZXIgaXAgYWRkcmVz cyBhbmQgcHJveHkgaXAgYWRkcmVzcywNCj4+IGFuZCBwYWNrZXRzIHdpbGwgbm90IGJlIHJldHVy bmVkLCBob3cgdG8geW91IHRyb3VibGVzaG9vdCB0aGF0PyBpZiB5b3UgZG8NCj4gDQo+IElmIHdo ZW4gbWFudWFsbHkgc3dpdGNoZWQgb24gaW4gYW4gZW52aXJvbm1lbnQgd2hlcmUgaXQgc2hvdWxk IG5vdCBiZSB0aGUgcmVzdWx0IGlzIG5vdCB3b3JraW5nIGF0IGFsbCB0aGF0IHdvdWxkIGJlIHBl cmZlY3RseSBmaW5lLiAgVW5mb3J0dW5hdGx5IGFzIEkgaGF2ZSBzaG93biB0aGlzIGlzIG5vdCB0 aGUgY2FzZSB3aXRoIGV4dGVuZGVkLWlkLg0KPiANCj4gSW4gdGhpcyBhc3BlY3Qgb2YgY29uc2lk ZXJhdGlvbiBPUkEgY2xlYXJseSBoYXMgYW4gYWR2YW50YWdlIGJvdGggaW4gYWJpbGl0eSB0byBk ZXRlY3QgYW5kIHJlcG9ydCBmYWlsdXJlIGFuZCBuYXR1cmUgb2YgZmFpbHVyZSBpdHNlbGYuDQo+ IA0KPj4gaGF2ZSB3YXlzLCBhbmQgdGhpcyBkcmFmdCBhbHNvIGhhdmUgd2F5cy4gQ2FuIHlvdSBp bWFnaW5nIGFuIG9wZXJhdG9yDQo+PiBpbnNpc3QgdG8gZG8gYSBtYW51YWwgY29uZmlndXJhdGlv biB3aXRob3V0IGNoZWNrIHRoZSBzdGF0dXMgb2YgdGhlIHNlcnZlciwNCj4gDQo+IFllcyBhYnNv bHV0ZWx5LiAgVGhpcyB3aWxsIGRlZmlhbnRseSBvY2N1ci4gIFN0YXR1cy1zZXJ2ZXIgaXMgbm90 IHVuaXZlcnNhbGx5IHN1cHBvcnRlZC4NCj4gDQo+IHJlZ2FyZHMsDQo+IFBldGVyDQoNCg== From nobody Tue Dec 12 22:34:36 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBF2128CDC for ; Tue, 12 Dec 2017 22:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 VzDX4Qh0XT8q for ; Tue, 12 Dec 2017 22:34:32 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375AF1271FD for ; Tue, 12 Dec 2017 22:34:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4056; q=dns/txt; s=iport; t=1513146872; x=1514356472; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KPArTQNMN5tzD8SSbsJsMNhO+0jK0GB8LyazHyvhSws=; b=chCSlX0PLOE/5ha4Z/9jOfFEwjlY4BQsfbtH7dvWTOHQuzaQsKLIGR8t k/kcRY6xjLLF7JviPepJwNRt3QlKSWGxAapPIut/xcCnJcmakh21hrPzS 0cUVPMwgEDGHfBZheHDAPS/yC9VspEkvqTS4dbws3yMpWa/rr1EHqQQzv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjAAAGyTBa/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7iiGPBYF9lxGCFQoYC4FegmtPAhqEbj8YAQEBAQE?= =?us-ascii?q?BAQEBayiFIwEBAQECAQEBGwYROgsFBwQCAQgRBAEBAQICIwMCAgIlCxQBCAgCB?= =?us-ascii?q?AENBQiKGAgQqB+CJ4phAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4JUgguBVoF?= =?us-ascii?q?pgyuDLgGBWC2CfoJjBaMZApUbk3CWOQIRGQGBOgEfOYFObxU6gimEVXiJLoEVA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.45,397,1508803200"; d="scan'208";a="43931686" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2017 06:34:31 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vBD6YUhQ024465 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 06:34:31 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Dec 2017 00:34:30 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Wed, 13 Dec 2017 00:34:30 -0600 From: "Jakob Heitz (jheitz)" To: "Naiming Shen (naiming)" , Peter Deacon CC: "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTKHKr27AOb9kvt06qaVfqXSaI2qMqT+8AgBZxrICAAJ70AIAADIcAgAACHICAAAuXAIAABzAAgAALsoCAAAh6AIAALG8AgAACmID//6GqsA== Date: Wed, 13 Dec 2017 06:34:30 +0000 Message-ID: <677f41484d9f413aab126b623141d729@XCH-ALN-014.cisco.com> References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> <313FEFCE-FD61-4394-804D-91BAE98CA687@cisco.com> <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com> In-Reply-To: <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.87.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 06:34:35 -0000 T25jZSB3ZSBhcmUgYXJndWluZyAiSXQgZG9lc24ndCB3b3JrIHdoZW4gdGhlcmUncyBidWdzIG9y IG1pc2NvbmZpZ3MiLA0KdGhlbiB3ZSd2ZSBzdW5rIHByZXR0eSBsb3cuIEJ1dCBub3cgdGhhdCB3 ZSdyZSB0aGVyZSwgaGVyZSBpcyBhIG1vcmUNCmxpa2VseSBidWc6IFJldHJhbnNtaXNzaW9uIHdp dGggYSBuZXcgcmVxdWVzdC1hdXRoZW50aWNhdG9yLg0KZHJhZnQtZGVrb2sgd2lsbCBpbnRlcnBy ZXQgdGhhdCBhcyBhbiBlbnRpcmVseSBuZXcgcmVxdWVzdC4NClRoYXQgaXMgd2h5IGtlZXBpbmcg dGhlIGlkIGFuZCBhdXRoZW50aWNhdG9yIHNlcGFyYXRlIGlzIGNsZWFuZXIuDQoNClRoYW5rcywN Ckpha29iDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJhZGV4dCBbbWFp bHRvOnJhZGV4dC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTmFpbWluZyBTaGVuIChu YWltaW5nKQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMTIsIDIwMTcgMTA6MDggUE0NClRvOiBQ ZXRlciBEZWFjb24gPHBldGVyZEBpZWEtc29mdHdhcmUuY29tPg0KQ2M6IHJhZGV4dEBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtyYWRleHRdIEV4dGVuZGVkIElEcw0KDQoNCldoZW4gSSBzYXkg4oCc Y2hlY2sgdGhlIHN0YXR1cyBvZiB0aGUgc2VydmVy4oCdLCBzb3JyeSBJIGRpZG7igJl0IG1lYW4g dGhlIHNlcnZlci1zdGF0dXMNCm1lc3NhZ2UuIFdoZW4gYW4gb3BlcmF0b3IgZGVjaWRlcyB0byBk byBtYW51YWwgY29uZmlndXJhdGlvbiBvZiBhIG5ldyBmZWF0dXJlDQphbmQgb3ZlcnJpZGUgdGhl IG5vcm1hbCBhdXRvbWF0ZWQgZGlzY292ZXJ5IHByb2NlZHVyZSwgaGUvc2hlIG5lZWRzIHRvIGNo ZWNrDQp0aGUgcmFkaXVzIHNlcnZlciBhbmQvb3IgcmFkaXVzIHByb3h5IHNlcnZlciBzb2Z0d2Fy ZSB2ZXJzaW9uLCBzdGF0dXMsIGV0Yy4gSGUvc2hlIHdvdWxkDQpub3QganVzdCBibGluZGx5IGNv bmZpZ3VyZSB0aGUgbmV3IGZlYXR1cmUsIGFuZCBnbyBob21lIHRvIHNsZWVwIGFuZCBhc3N1bWUN CmV2ZXJ5dGhpbmcgaXMgZmluZS4gVGhhdCdzIGp1c3QgY29tbW9uIHNlbnNlLiANCg0KQlRXLCBT dGF0dXMtc2VydmVyIGlzIG5vdCBzdXBwb3J0ZWQgdW5pdmVyc2FsbHkgaXMgbm90IGEgcHJvYmxl bSBoZXJlLg0KV2hlbiB0aGUgc2VydmVyIHNvZnR3YXJlIHN1cHBvcnRzIHRoaXMgZHJhZnQsIHRo ZW4gaXQgTVVTVCBpbXBsZW1lbnQgdGhlDQpTdGF0dXMtc2VydmVyIG1lc3NhZ2UgYXQgbGVhc3Qg Zm9yIHRoaXMgZmVhdHVyZS4NCg0KUmVnYXJkcywNCi0gTmFpbWluZw0KDQo+IE9uIERlYyAxMiwg MjAxNywgYXQgOTo1OCBQTSwgUGV0ZXIgRGVhY29uIDxwZXRlcmRAaWVhLXNvZnR3YXJlLmNvbT4g d3JvdGU6DQo+IA0KPiBPbiBXZWQsIDEzIERlYyAyMDE3LCBOYWltaW5nIFNoZW4gKG5haW1pbmcp IHdyb3RlOg0KPiANCj4+IElmIHlvdSBpbnNpc3QgbWlzY29uZmlndXJhdGlvbiBpcyB0aGUgZ3Jl YXRlc3QgdGhpbmcgd2UgaGF2ZSB0byBkZWFsIHdpdGgsDQo+IA0KPiBEZWNpc2lvbiB0byBleHBh bmQgb24gb3JpZ2luYWwgcmVtYXJrcyBpbiByZXNwb25zZSB0byBjYWxsIGZvciBhZG9wdGlvbiB3 YXMgcmVzdWx0IG9mIHlvdXIgaW5xdWlyeToNCj4gDQo+ICJUaGlyZCwgaWYgYXNzdW1lIGFuIG9w ZXJhdGlvbiBjb21wbGV0ZWx5IG1lc3NlZCB1cCwgYW5kIGxlYWtpbmcgdGhpcyBleHRlbmRlZC1J RCB0b3dhcmRzIHRoZSBob21lLXNlcnZlciwgSSBzdGlsbCBuZWVkIHRvIHNlZSBhIGdvb2QgZXhh bXBsZSBvbiB3aGF0IHRoZSBoYXJtIGlzIHRoYXQsIGFuZCB3aHkgdGhpcyBjYW4gbm90IGJlIGRl YnVnZ2VkLiBUaGUgZHJhZnQgSSBhZ3JlZSBuZWVkcyB0byBhZGQgc29tZSB0ZXh0IG9uIHZhcmlv dXMgY2FzZXMgYW5kIGhvdyB0byBkZWJ1ZyB0aG9zZSBpbiBlYWNoIG9mIHRoZW0uIg0KPiANCj4g T3RoZXJ3aXNlIEkgYW0gaGFwcHkgd2l0aCB0aGUgcmVsYXRpdmUgc3RyZW5ndGggb2YgbXkgcmVt YXJrcyBpbiB0aGVpciBvcmlnaW5hbCBjb250ZXh0Lg0KPiANCj4+IHRoZW4gSSBjYW4gaW1hZ2lu ZSB5b3UgbWlzY29uZmlndXJhZSB5b3VyIHNlcnZlciBpcCBhZGRyZXNzIGFuZCBwcm94eSBpcCBh ZGRyZXNzLA0KPj4gYW5kIHBhY2tldHMgd2lsbCBub3QgYmUgcmV0dXJuZWQsIGhvdyB0byB5b3Ug dHJvdWJsZXNob290IHRoYXQ/IGlmIHlvdSBkbw0KPiANCj4gSWYgd2hlbiBtYW51YWxseSBzd2l0 Y2hlZCBvbiBpbiBhbiBlbnZpcm9ubWVudCB3aGVyZSBpdCBzaG91bGQgbm90IGJlIHRoZSByZXN1 bHQgaXMgbm90IHdvcmtpbmcgYXQgYWxsIHRoYXQgd291bGQgYmUgcGVyZmVjdGx5IGZpbmUuICBV bmZvcnR1bmF0bHkgYXMgSSBoYXZlIHNob3duIHRoaXMgaXMgbm90IHRoZSBjYXNlIHdpdGggZXh0 ZW5kZWQtaWQuDQo+IA0KPiBJbiB0aGlzIGFzcGVjdCBvZiBjb25zaWRlcmF0aW9uIE9SQSBjbGVh cmx5IGhhcyBhbiBhZHZhbnRhZ2UgYm90aCBpbiBhYmlsaXR5IHRvIGRldGVjdCBhbmQgcmVwb3J0 IGZhaWx1cmUgYW5kIG5hdHVyZSBvZiBmYWlsdXJlIGl0c2VsZi4NCj4gDQo+PiBoYXZlIHdheXMs IGFuZCB0aGlzIGRyYWZ0IGFsc28gaGF2ZSB3YXlzLiBDYW4geW91IGltYWdpbmcgYW4gb3BlcmF0 b3INCj4+IGluc2lzdCB0byBkbyBhIG1hbnVhbCBjb25maWd1cmF0aW9uIHdpdGhvdXQgY2hlY2sg dGhlIHN0YXR1cyBvZiB0aGUgc2VydmVyLA0KPiANCj4gWWVzIGFic29sdXRlbHkuICBUaGlzIHdp bGwgZGVmaWFudGx5IG9jY3VyLiAgU3RhdHVzLXNlcnZlciBpcyBub3QgdW5pdmVyc2FsbHkgc3Vw cG9ydGVkLg0KPiANCj4gcmVnYXJkcywNCj4gUGV0ZXINCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnJhZGV4dCBtYWlsaW5nIGxpc3QNCnJhZGV4dEBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYWRleHQNCg== From nobody Tue Dec 12 22:40:40 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CFA128D8B for ; Tue, 12 Dec 2017 22:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 inahEIjgWyq8 for ; Tue, 12 Dec 2017 22:40:37 -0800 (PST) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 147EF127011 for ; Tue, 12 Dec 2017 22:40:37 -0800 (PST) Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 12 Dec 2017 22:40:36 -0800 Date: Tue, 12 Dec 2017 22:40:39 -0800 (Pacific Standard Time) From: Peter Deacon To: "Naiming Shen (naiming)" cc: "radext@ietf.org" In-Reply-To: <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com> Message-ID: References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> <313FEFCE-FD61-4394-804D-91BAE98CA687@cisco.com> <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com> User-Agent: Alpine 2.21.1 (WNT 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 06:40:38 -0000 On Wed, 13 Dec 2017, Naiming Shen (naiming) wrote: > BTW, Status-server is not supported universally is not a problem here. > When the server software supports this draft, then it MUST implement the > Status-server message at least for this feature. This is not my understanding based on text. Can you offer relevant citation in draft-chen-radext-identifier-attr-02.txt supporting this position? I don't support making status-server mandatory. regards, Peter From nobody Tue Dec 12 23:03:25 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB56A1271FD for ; Tue, 12 Dec 2017 23:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 wEogfGwdD8ra for ; Tue, 12 Dec 2017 23:03:22 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BFF3126E64 for ; Tue, 12 Dec 2017 23:03:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1355; q=dns/txt; s=iport; t=1513148602; x=1514358202; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Z/gRB4kISWXfpUHCDwH/zvEdJNK6vXbh4SSDxhaYCo4=; b=Mr0CWR3EfqMl7geYIUKEJvsDUn4OzC0hG0DjwbyVni1kv/3MrvNihyRz LDBBgqibTOH7E9/D/oG2D/iDwoykbU65+YjRNQ9wJnLwMOyJJ6k7L8QBS I9UX7EwfmT+LqI/cKNbq/OBucIwMXjAjOteKkcm8ANqHORCZq65eQlryN c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAACmzzBa/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB44cjwWBVyaXEYIVChgLgV6Ca08ChQg/GAEBAQEBAQE?= =?us-ascii?q?BAWsohSMBAQEBAgEBATg0CwULAgEIGB4QJwslAgQOBYogCBCqSophAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWDY4ILgz8pC4J3gy4BgVgWg0aCMgWjGQKVJJNnljk?= =?us-ascii?q?CERkBgToBHzmBTm8VOioBgX6EVXiJLoEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,397,1508803200"; d="scan'208";a="329906720" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2017 07:03:21 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vBD73L06002186 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 07:03:21 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Dec 2017 01:03:20 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Wed, 13 Dec 2017 01:03:20 -0600 From: "Naiming Shen (naiming)" To: Peter Deacon CC: "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTKHKrqtJDphnIu0Ga679ujWV4vKMqT+8AgBZxrICAAJ7zgIAADIgAgAACGYCAAAuaAIAABy4AgAALtICAAAh4AIAALHEAgAAClwCAAAkYgIAABlaA Date: Wed, 13 Dec 2017 07:03:20 +0000 Message-ID: <551F795A-7385-401F-881A-EB46C9242DCC@cisco.com> References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> <313FEFCE-FD61-4394-804D-91BAE98CA687@cisco.com> <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.71.8] Content-Type: text/plain; charset="us-ascii" Content-ID: <5B8A39297452A74F88F2503DC5B5FFC1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 07:03:24 -0000 The text of draft-chen currently assumes server-status is an supported option. If the radius server software does not even support th= is, then this extended-ID scheme more likely is not even relavent in the environment. The design and implmenetation of the software should alway= s consider the ease of operational burden as the first priority, in particula= r this automated discovery has been around for many years. One can always develop its own discovery with each additional new feature/attributes, but we should always try to maximize and share the existing mechanism. Regards, - Naiming > On Dec 12, 2017, at 10:40 PM, Peter Deacon wrot= e: >=20 > On Wed, 13 Dec 2017, Naiming Shen (naiming) wrote: >=20 >> BTW, Status-server is not supported universally is not a problem here. W= hen the server software supports this draft, then it MUST implement the Sta= tus-server message at least for this feature. >=20 > This is not my understanding based on text. Can you offer relevant citat= ion in draft-chen-radext-identifier-attr-02.txt supporting this position? >=20 > I don't support making status-server mandatory. >=20 > regards, > Peter >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Dec 12 23:15:16 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC87A126E64 for ; Tue, 12 Dec 2017 23:15: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, RCVD_IN_DNSWL_NONE=-0.0001] 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 367F-3zJxlWp for ; Tue, 12 Dec 2017 23:15:13 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (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 16656126BF3 for ; Tue, 12 Dec 2017 23:15:13 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 322A443B0C; Wed, 13 Dec 2017 08:15:11 +0100 (CET) To: "Jakob Heitz (jheitz)" , "Naiming Shen (naiming)" , Peter Deacon Cc: "radext@ietf.org" References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> <313FEFCE-FD61-4394-804D-91BAE98CA687@cisco.com> <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com> <677f41484d9f413aab126b623141d729@XCH-ALN-014.cisco.com> From: Stefan Winter Organization: RESTENA Message-ID: <97bb93d9-8006-9143-fe81-dd654a7c1960@restena.lu> Date: Wed, 13 Dec 2017 08:15:11 +0100 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: <677f41484d9f413aab126b623141d729@XCH-ALN-014.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: lb-LU Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 07:15:15 -0000 Hello, > Once we are arguing "It doesn't work when there's bugs or misconfigs", > then we've sunk pretty low. As a chair: I do not think that was the point made in this (sub)thread. The substantial part of the discussion was about misconfiguration (not bugs in implementation), and the *extent* to which a misconfiguration does harm. The argument was that draft-dekok has a more gentle failure consequence: communication between a client and its communication target (server or proxy) does not work, and deterministically so. The breakage is local between the two. Contrary to that, draft-chen's failure mode is that confusion about the state of communication peers may transpire along all proxies and the final server along the proxy chain, with the ability to debug and isolate the problem becoming difficult. It is a configuration problem because nobody is required to implement this new RFC - so if a request comes in with the new attribute, it's by default treated like any other unknown attribute in RADIUS: ignore as a server, forward unchanged as a proxy. This simple "do-nothing" is what triggers the unpleasant failure mode in draft-chen draft. To prevent it, every proxy operator has to take action and configure this attribute as to-be-deleted when proxying. That appears to be a very strong argument against a new attribute. As an individual: Operating a global-scale proxy environment with hundreds of proxies across hundreds of different administrative domains, I think I can say with some certainty that a) proxies without support for the new RFC will be around for timescales best measured in decades, and b) such misconfigurations WILL occur. Greetings, Stefan Winter > But now that we're there, here is a more > likely bug: Retransmission with a new request-authenticator. > draft-dekok will interpret that as an entirely new request. > That is why keeping the id and authenticator separate is cleaner. > > Thanks, > Jakob > > > -----Original Message----- > From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Naiming Shen (naiming) > Sent: Tuesday, December 12, 2017 10:08 PM > To: Peter Deacon > Cc: radext@ietf.org > Subject: Re: [radext] Extended IDs > > > When I say “check the status of the server”, sorry I didn’t mean the server-status > message. When an operator decides to do manual configuration of a new feature > and override the normal automated discovery procedure, he/she needs to check > the radius server and/or radius proxy server software version, status, etc. He/she would > not just blindly configure the new feature, and go home to sleep and assume > everything is fine. That's just common sense. > > BTW, Status-server is not supported universally is not a problem here. > When the server software supports this draft, then it MUST implement the > Status-server message at least for this feature. > > Regards, > - Naiming > >> On Dec 12, 2017, at 9:58 PM, Peter Deacon wrote: >> >> On Wed, 13 Dec 2017, Naiming Shen (naiming) wrote: >> >>> If you insist misconfiguration is the greatest thing we have to deal with, >> Decision to expand on original remarks in response to call for adoption was result of your inquiry: >> >> "Third, if assume an operation completely messed up, and leaking this extended-ID towards the home-server, I still need to see a good example on what the harm is that, and why this can not be debugged. The draft I agree needs to add some text on various cases and how to debug those in each of them." >> >> Otherwise I am happy with the relative strength of my remarks in their original context. >> >>> then I can imagine you misconfigurae your server ip address and proxy ip address, >>> and packets will not be returned, how to you troubleshoot that? if you do >> If when manually switched on in an environment where it should not be the result is not working at all that would be perfectly fine. Unfortunatly as I have shown this is not the case with extended-id. >> >> In this aspect of consideration ORA clearly has an advantage both in ability to detect and report failure and nature of failure itself. >> >>> have ways, and this draft also have ways. Can you imaging an operator >>> insist to do a manual configuration without check the status of the server, >> Yes absolutely. This will defiantly occur. Status-server is not universally supported. >> >> regards, >> Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Dec 12 23:22:19 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0565E1292C5 for ; Tue, 12 Dec 2017 23:22:09 -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 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 p9Wsty1JZkLW for ; Tue, 12 Dec 2017 23:22:07 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (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 71D4F128BBB for ; Tue, 12 Dec 2017 23:22:07 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id E972943B0C for ; Wed, 13 Dec 2017 08:22:05 +0100 (CET) To: radext@ietf.org References: <8BD2C2F2-D42E-4B84-8F86-3A803160DD74@cisco.com> <285C5C94-578E-4293-81A2-9D73E1105ABE@deployingradius.com> <8DE62B3C-D2FA-4467-9CCE-7F8D039B87E2@cisco.com> From: Stefan Winter Organization: RESTENA Message-ID: Date: Wed, 13 Dec 2017 08:22:05 +0100 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: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: lb-LU Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 07:22:09 -0000 Hello, again as a chair: regarding the question of whether overloading of Request-Authenticator should be considered harmful, I think the message from Peter below best summarises the deployed reality in RADIUS. Basically, it makes clear that the decision to overload Message-Authenticator or not is not on our table. That decision has been taken ages ago, by this working group, and for a good number of RADIUS attributes. So, for the discussion at hand, fears about overloading the Request-Authenticator can safely be considered a non-argument. Greetings, Stefan Winter > On Fri, 1 Dec 2017, Jakob Heitz (jheitz) wrote: > >> What if the quantum computers turn out to live up to their promises? >> Then we can throw out all this authentication stuff and decide to not >> share our Ethernets with the attackers instead. No more request >> authenticator. > > RADIUS security already lost cause no matter what :( > > Best practice for many years - use a secure transport and or RADIUS > over (D)TLS.  Regardless of selected security option in all cases > operation of authenticator is maintained. > >> The request authenticator is already overloaded. It may be used for >> the CHAP challenge. Now, you want another overload? > > Authenticator currently also used for at least following: > > Tunnel Passwords > Message-Authenticator > PAP > CHAP > MPPE Keys > > Clearly no possibility of authenticator ever changing in RADIUS > protocol without creation of an incompatible replacement.  In event of > an incompatible replacement there would be no need for either of these > two drafts. > > I am aware of no practical downside to "Overloading". > > regards, > Peter > From nobody Tue Dec 12 23:40:48 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF24F12700F for ; Tue, 12 Dec 2017 23:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 ddMgFqHn7jn7 for ; Tue, 12 Dec 2017 23:40:45 -0800 (PST) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 40B2B126C26 for ; Tue, 12 Dec 2017 23:40:45 -0800 (PST) Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 12 Dec 2017 23:40:44 -0800 Date: Tue, 12 Dec 2017 23:40:48 -0800 (Pacific Standard Time) From: Peter Deacon To: "Naiming Shen (naiming)" cc: "radext@ietf.org" In-Reply-To: <551F795A-7385-401F-881A-EB46C9242DCC@cisco.com> Message-ID: References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> <313FEFCE-FD61-4394-804D-91BAE98CA687@cisco.com> <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com> <551F795A-7385-401F-881A-EB46C9242DCC@cisco.com> User-Agent: Alpine 2.21.1 (WNT 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 07:40:47 -0000 On Wed, 13 Dec 2017, Naiming Shen (naiming) wrote: > The text of draft-chen currently assumes server-status is > an supported option. If the radius server software does not even support this, I will assume this means the answer to my question is nothing in the text requires status-server. > then this extended-ID scheme more likely is not even relavent in > the environment. The design and implmenetation of the software should always What is the linkage between status-server and expanded id space? > consider the ease of operational burden as the first priority, in particular > this automated discovery has been around for many years. One can always Certainly not my understanding. The only RFC I know of "overloading" status-server for any sort of capability negotiation is RFC7930 and at least that has sense enough to be limited to stream transports. regards, Peter From nobody Tue Dec 12 23:48:18 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B1F12700F for ; Tue, 12 Dec 2017 23:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 VTSc4gsS_XQ8 for ; Tue, 12 Dec 2017 23:48:15 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1021E126C26 for ; Tue, 12 Dec 2017 23:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1330; q=dns/txt; s=iport; t=1513151295; x=1514360895; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ZUXksyxnt2g2l++P96S84p1ZFd2CIf7R37lSLz/tsPQ=; b=YW10MF8p8J2+xlbEYhKQkwZVqJsiq5qjUcEletGDoipGu/F+D/0mnG3n VytVMQdnizpxcdWu/oDol3oLoq7BIxsuirPq+mjVZq1xQv6AXU43+jnpp 0+Sj6H2YYTW89XjtD7pCdSTix5iJFMrX37bafbt5oOHNymlmMF74i+nUD Y=; X-IronPort-AV: E=Sophos;i="5.45,397,1508803200"; d="scan'208";a="334753625" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2017 07:48:14 +0000 Received: from [10.24.55.251] ([10.24.55.251]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vBD7mDIU028966; Wed, 13 Dec 2017 07:48:13 GMT To: Peter Deacon References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> <313FEFCE-FD61-4394-804D-91BAE98CA687@cisco.com> <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com> <551F795A-7385-401F-881A-EB46C9242DCC@cisco.com> Cc: "Naiming Shen (naiming)" , "radext@ietf.org" , Enke Chen From: Enke Chen Message-ID: Date: Tue, 12 Dec 2017 23:48:13 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 07:48:17 -0000 Peter, The "Status-Server" is used for capability negotiation by both drafts. Neither mechanism will work with an ancient server that does not support the "Status-server" properly. Regards, -- Enke On 12/12/17 11:40 PM, Peter Deacon wrote: > On Wed, 13 Dec 2017, Naiming Shen (naiming) wrote: > >> The text of draft-chen currently assumes server-status is >> an supported option. If the radius server software does not even support this, > > I will assume this means the answer to my question is nothing in the text requires status-server. > >> then this extended-ID scheme more likely is not even relavent in >> the environment. The design and implmenetation of the software should always > > What is the linkage between status-server and expanded id space? > >> consider the ease of operational burden as the first priority, in particular >> this automated discovery has been around for many years. One can always > > Certainly not my understanding. The only RFC I know of "overloading" status-server for any sort of capability negotiation is RFC7930 and at least that has sense enough to be limited to stream transports. > > regards, > Peter > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Wed Dec 13 00:21:46 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457F31275FD for ; Wed, 13 Dec 2017 00:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 tmhkscebvEbR for ; Wed, 13 Dec 2017 00:21:43 -0800 (PST) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 3867212700F for ; Wed, 13 Dec 2017 00:21:43 -0800 (PST) Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 13 Dec 2017 00:21:42 -0800 Date: Wed, 13 Dec 2017 00:21:46 -0800 (Pacific Standard Time) From: Peter Deacon To: Enke Chen cc: "Naiming Shen (naiming)" , "radext@ietf.org" In-Reply-To: Message-ID: References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> <313FEFCE-FD61-4394-804D-91BAE98CA687@cisco.com> <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com> <551F795A-7385-401F-881A-EB46C9242DCC@cisco.com> User-Agent: Alpine 2.21.1 (WNT 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 08:21:45 -0000 On Tue, 12 Dec 2017, Enke Chen wrote: > The "Status-Server" is used for capability negotiation by both drafts. Completely agree. None of my comments regarding status server are unique to either draft. > Neither mechanism will work with an ancient server that does not support > the "Status-server" properly. This is not my understanding. I see nothing in text precluding anyone from manually configuring support for extended-id or ORA and never using status-server if they prefer not to for whatever reason. Welcome specific citation saying I'm wrong or logical argument explaining why extended-id is not possible without status-server /w relevant citations. Opinions of usefulness of status-server for capability negotiation NOT welcome. What's the point of explicitly referencing the possibility of manual enablement if not to support extended-id without status-server? " Unless specified by configuration, a client MUST NOT send a RADIUS packet (other than the Status-Server request) with the "Extended Identifier Attribute" to a server until it has received a response from the server confirming its support for the Extended Identifier feature using the "Extended Identifier Attribute"." regards, Peter From nobody Wed Dec 13 05:05:28 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000AF126CD8 for ; Wed, 13 Dec 2017 05:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 ixDR-Tz65yAq for ; Wed, 13 Dec 2017 05:05:25 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id DB11B124319 for ; Wed, 13 Dec 2017 05:05:24 -0800 (PST) Received: from [192.168.2.25] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id D82FE16B; Wed, 13 Dec 2017 13:05:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <677f41484d9f413aab126b623141d729@XCH-ALN-014.cisco.com> Date: Wed, 13 Dec 2017 08:05:22 -0500 Cc: "radext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <924BF9DB-CE34-46F9-A8D1-CA6601BB7FFF@deployingradius.com> References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> <313FEFCE-FD61-4394-804D-91BAE98CA687@cisco.com> <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com> <677f41484d9f413aab126b623141d729@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 13:05:27 -0000 > On Dec 13, 2017, at 1:34 AM, Jakob Heitz (jheitz) = wrote: >=20 > Once we are arguing "It doesn't work when there's bugs or misconfigs", > then we've sunk pretty low. Insults aren't appropriate. Discussing how the proposal behaves in the event of misconfiguration = is entirely appropriate. In fact, that discussion can strongly = influence the design of a solution. > But now that we're there, here is a more > likely bug: Retransmission with a new request-authenticator. > draft-dekok will interpret that as an entirely new request. That's not how RADIUS works.=20 Quoting RFC 2059, from 1997: ... For retransmissions where the contents are identical, the Identifier MUST remain unchanged. Note that if Acct-Delay-Time is included in the attributes of an Accounting-Request then the Acct-Delay-Time value will be updated when the packet is retransmitted, changing the content of the Attributes field and requiring a new Identifier and Request Authenticator. See also RFC 5080, as I suggested in an earlier response. If a packet is a *retransmission*, then all of it's contents are the = same. Including the header. So both drafts will see the packet as a = duplicate, as per RFC 5080 Section 2.2.2. If the packet contents are not the same, then it's not a = retransmission. And going back to 20 year-old standards, the Request = Authenticator (among other fields) also changes. > That is why keeping the id and authenticator separate is cleaner. Both drafts behave identically in the situation when a duplicate = packet is retransmitted. Both drafts behave identically when the packet = contents change. And in both situations, both drafts follow the existing RADIUS = standards. Please go back and read the standards to see how RADIUS works. Alan DeKok. From nobody Wed Dec 13 05:20:12 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15162126B6D for ; Wed, 13 Dec 2017 05:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 8TkEmuJu9iL7 for ; Wed, 13 Dec 2017 05:20:08 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id C0F4C126CD8 for ; Wed, 13 Dec 2017 05:20:05 -0800 (PST) Received: from [192.168.2.25] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id A680216A; Wed, 13 Dec 2017 13:20:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com> Date: Wed, 13 Dec 2017 08:20:03 -0500 Cc: Peter Deacon , "radext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> <313FEFCE-FD61-4394-804D-91BAE98CA687@cisco.com> <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com> To: "Naiming Shen (naiming)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 13:20:11 -0000 On Dec 13, 2017, at 1:08 AM, Naiming Shen (naiming) = wrote: >=20 > When I say =E2=80=9Ccheck the status of the server=E2=80=9D, sorry I = didn=E2=80=99t mean the server-status > message. When an operator decides to do manual configuration of a new = feature > and override the normal automated discovery procedure, he/she needs to = check > the radius server and/or radius proxy server software version, status, = etc. He/she would > not just blindly configure the new feature, and go home to sleep and = assume > everything is fine. That's just common sense.=20 I agree. Many administrators don't. :( I've seen some "inventive" = administrative practices. It would be good to have a solution that is robust in the event of = misconfiguration, or software changes. i.e. I upgrade my RADIUS server, but don't tell people who send = packets to it. If those servers are statically configured to do = extended-ID, then the extended-id attribute will "leak" to my server, = and to any later proxy servers. My concern is that the Extended-ID is intended for signalling in one = hop, and should not leak across proxy chains. > BTW, Status-server is not supported universally is not a problem here. > When the server software supports this draft, then it MUST implement = the > Status-server message at least for this feature. Then I would also suggest mandating that manually enabling it on the = client is forbidden. And should the negotiation be done on every connection from client to = server? If not, why not? The bulk of draft-dekok goes through all of these issues and tries to = give explanations. Much of that text is applicable to both drafts. And because draft-dekok is largely implemented on the server, manually = enabling it on the client doesn't really do much. Alan DeKok. From nobody Wed Dec 13 05:21:30 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E762126B6D for ; Wed, 13 Dec 2017 05:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 S7RjRo9klQAP for ; Wed, 13 Dec 2017 05:21:27 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2755124319 for ; Wed, 13 Dec 2017 05:21:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3048; q=dns/txt; s=iport; t=1513171286; x=1514380886; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BJ1qF7rRGI2PpZD4qbdyXCf+vhIp+6dzZl8LAjge1iY=; b=H4E3pEiSkUkaHmwO/2qpDomDdN/lvbQ4TBhK0nZUAZPZQheJf6LHsvbX fhm0wrJI3x65eTHQhEokOBRQmFTfppPXo/oImL6xiyYMpKMkh4gpd9ms4 dzF9gSchNSHX+/7fmJo6vEQw6dCaiglnTqApVZX9Mhxsby+Wb2E4P7aTi 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DGAQB9KDFa/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7mSaBfZcRghUKGAuESU8CGoR5QRYBAQEBAQEBAQF?= =?us-ascii?q?rKIUkAQEBAwEBIRE6GwIBCBgCAiYCAgIlCxUQAgQBEoooEKhogieKXQEBAQEBA?= =?us-ascii?q?QEBAgEBAQEBAQEcBYEPglGCC4M/gyuDLgGBboMVgmMFox8ClSWTaJY5AhEZAYE?= =?us-ascii?q?6ASYIKoFObxU6gimEVXiJMIEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,397,1508803200"; d="scan'208";a="321455345" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2017 13:21:25 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id vBDDLPMD020961 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 13:21:25 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Dec 2017 08:21:24 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Wed, 13 Dec 2017 08:21:24 -0500 From: "Acee Lindem (acee)" To: Stefan Winter , "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTaFBxQlK83f2iTECUdzRYa7wpJqMsVBUAgAFpdmCAASVyAIAAH4CAgAWDQYCADMOagIAAEIWA Date: Wed, 13 Dec 2017 13:21:24 +0000 Message-ID: References: <8BD2C2F2-D42E-4B84-8F86-3A803160DD74@cisco.com> <285C5C94-578E-4293-81A2-9D73E1105ABE@deployingradius.com> <8DE62B3C-D2FA-4467-9CCE-7F8D039B87E2@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: text/plain; charset="utf-8" Content-ID: <462EA8928A0B8748834EFB05CCCB543B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 13:21:29 -0000 U3RlZmFuLCANCg0KSSBiZWxpZXZlIHlvdSBhcmUgc3BlYWtpbmcgYXMgYSBjb250cmlidXRvciBh bmQgbm90IGFzIGEgY2hhaXIgd2hlbiBtYWtpbmcNCnRlY2huaWNhbCBjb250cmlidXRpb25zIHRv IHRoaXMgZGlzY3Vzc2lvbiAobGFzdCB0d28gRS1tYWlscykuDQoNClRoYW5rcywNCkFjZWUgDQoN Ck9uIDEyLzEzLzE3LCAyOjIyIEFNLCAicmFkZXh0IG9uIGJlaGFsZiBvZiBTdGVmYW4gV2ludGVy Ig0KPHJhZGV4dC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzdGVmYW4ud2ludGVyQHJl c3RlbmEubHU+IHdyb3RlOg0KDQo+SGVsbG8sDQo+DQo+YWdhaW4gYXMgYSBjaGFpcjoNCj4NCj5y ZWdhcmRpbmcgdGhlIHF1ZXN0aW9uIG9mIHdoZXRoZXIgb3ZlcmxvYWRpbmcgb2YgUmVxdWVzdC1B dXRoZW50aWNhdG9yDQo+c2hvdWxkIGJlIGNvbnNpZGVyZWQgaGFybWZ1bCwgSSB0aGluayB0aGUg bWVzc2FnZSBmcm9tIFBldGVyIGJlbG93IGJlc3QNCj5zdW1tYXJpc2VzIHRoZSBkZXBsb3llZCBy ZWFsaXR5IGluIFJBRElVUy4NCj4NCj5CYXNpY2FsbHksIGl0IG1ha2VzIGNsZWFyIHRoYXQgdGhl IGRlY2lzaW9uIHRvIG92ZXJsb2FkDQo+TWVzc2FnZS1BdXRoZW50aWNhdG9yIG9yIG5vdCBpcyBu b3Qgb24gb3VyIHRhYmxlLiBUaGF0IGRlY2lzaW9uIGhhcyBiZWVuDQo+dGFrZW4gYWdlcyBhZ28s IGJ5IHRoaXMgd29ya2luZyBncm91cCwgYW5kIGZvciBhIGdvb2QgbnVtYmVyIG9mIFJBRElVUw0K PmF0dHJpYnV0ZXMuDQo+DQo+U28sIGZvciB0aGUgZGlzY3Vzc2lvbiBhdCBoYW5kLCBmZWFycyBh Ym91dCBvdmVybG9hZGluZyB0aGUNCj5SZXF1ZXN0LUF1dGhlbnRpY2F0b3IgY2FuIHNhZmVseSBi ZSBjb25zaWRlcmVkIGEgbm9uLWFyZ3VtZW50Lg0KPg0KPkdyZWV0aW5ncywNCj4NCj5TdGVmYW4g V2ludGVyDQo+DQo+PiBPbiBGcmksIDEgRGVjIDIwMTcsIEpha29iIEhlaXR6IChqaGVpdHopIHdy b3RlOg0KPj4NCj4+PiBXaGF0IGlmIHRoZSBxdWFudHVtIGNvbXB1dGVycyB0dXJuIG91dCB0byBs aXZlIHVwIHRvIHRoZWlyIHByb21pc2VzPw0KPj4+IFRoZW4gd2UgY2FuIHRocm93IG91dCBhbGwg dGhpcyBhdXRoZW50aWNhdGlvbiBzdHVmZiBhbmQgZGVjaWRlIHRvIG5vdA0KPj4+IHNoYXJlIG91 ciBFdGhlcm5ldHMgd2l0aCB0aGUgYXR0YWNrZXJzIGluc3RlYWQuIE5vIG1vcmUgcmVxdWVzdA0K Pj4+IGF1dGhlbnRpY2F0b3IuDQo+Pg0KPj4gUkFESVVTIHNlY3VyaXR5IGFscmVhZHkgbG9zdCBj YXVzZSBubyBtYXR0ZXIgd2hhdCA6KA0KPj4NCj4+IEJlc3QgcHJhY3RpY2UgZm9yIG1hbnkgeWVh cnMgLSB1c2UgYSBzZWN1cmUgdHJhbnNwb3J0IGFuZCBvciBSQURJVVMNCj4+IG92ZXIgKEQpVExT LiAgUmVnYXJkbGVzcyBvZiBzZWxlY3RlZCBzZWN1cml0eSBvcHRpb24gaW4gYWxsIGNhc2VzDQo+ PiBvcGVyYXRpb24gb2YgYXV0aGVudGljYXRvciBpcyBtYWludGFpbmVkLg0KPj4NCj4+PiBUaGUg cmVxdWVzdCBhdXRoZW50aWNhdG9yIGlzIGFscmVhZHkgb3ZlcmxvYWRlZC4gSXQgbWF5IGJlIHVz ZWQgZm9yDQo+Pj4gdGhlIENIQVAgY2hhbGxlbmdlLiBOb3csIHlvdSB3YW50IGFub3RoZXIgb3Zl cmxvYWQ/DQo+Pg0KPj4gQXV0aGVudGljYXRvciBjdXJyZW50bHkgYWxzbyB1c2VkIGZvciBhdCBs ZWFzdCBmb2xsb3dpbmc6DQo+Pg0KPj4gVHVubmVsIFBhc3N3b3Jkcw0KPj4gTWVzc2FnZS1BdXRo ZW50aWNhdG9yDQo+PiBQQVANCj4+IENIQVANCj4+IE1QUEUgS2V5cw0KPj4NCj4+IENsZWFybHkg bm8gcG9zc2liaWxpdHkgb2YgYXV0aGVudGljYXRvciBldmVyIGNoYW5naW5nIGluIFJBRElVUw0K Pj4gcHJvdG9jb2wgd2l0aG91dCBjcmVhdGlvbiBvZiBhbiBpbmNvbXBhdGlibGUgcmVwbGFjZW1l bnQuICBJbiBldmVudCBvZg0KPj4gYW4gaW5jb21wYXRpYmxlIHJlcGxhY2VtZW50IHRoZXJlIHdv dWxkIGJlIG5vIG5lZWQgZm9yIGVpdGhlciBvZiB0aGVzZQ0KPj4gdHdvIGRyYWZ0cy4NCj4+DQo+ PiBJIGFtIGF3YXJlIG9mIG5vIHByYWN0aWNhbCBkb3duc2lkZSB0byAiT3ZlcmxvYWRpbmciLg0K Pj4NCj4+IHJlZ2FyZHMsDQo+PiBQZXRlcg0KPj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPnJhZGV4dCBtYWlsaW5nIGxpc3QNCj5yYWRleHRA aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JhZGV4dA0K DQo= From nobody Wed Dec 13 14:38:28 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7933D128990 for ; Wed, 13 Dec 2017 14:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbJgrpC0JRIe for ; Wed, 13 Dec 2017 14:38:19 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6051287A3 for ; Wed, 13 Dec 2017 14:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1513204696; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=XenHSMwxXW0CmxgA2wfacfDAl4CN3GPjXGxY7JA+oYk=; b=DccfbGGYaJN3X0/gw9UZIqiX7dOPqVzyPiVsSWcvX0noMb4V6UltH9HaCrV5qhK3XpANFWdLhgPX9OejpnMhLYuHfJrqkHSasLGVd9+6WLrp61Lo80XrVcdI5A4wZi54diVhVsHqoN12ln5O8nwWazYAuRv06O1/67KJXT4yYys= Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp0151.outbound.protection.outlook.com [213.199.154.151]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-107-28M6iZwxMqir430KnQVVrg-1; Wed, 13 Dec 2017 22:38:13 +0000 Received: from AM4PR07MB3508.eurprd07.prod.outlook.com (10.171.190.33) by AM4PR07MB3507.eurprd07.prod.outlook.com (10.171.190.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Wed, 13 Dec 2017 22:38:09 +0000 Received: from AM4PR07MB3508.eurprd07.prod.outlook.com ([fe80::fceb:5817:13c1:1678]) by AM4PR07MB3508.eurprd07.prod.outlook.com ([fe80::fceb:5817:13c1:1678%13]) with mapi id 15.20.0323.011; Wed, 13 Dec 2017 22:38:09 +0000 From: Adam Bishop To: "radext@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTKHKrqEQLrXT090aiKN4ZjCjQD6MqT+8AgBZxrICAADpfAIABeTqA Date: Wed, 13 Dec 2017 22:38:09 +0000 Message-ID: References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) x-originating-ip: [2a00:23c4:2713:4710:ddf8:a8ad:e885:f53f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB3507; 20:R7zirSEc/LORkM0bdc/DX1rawm7b/BT46WzRna80sTvyD6q1gY+6FgJoEqSu7Qp8HxcEmZ7sCA6/iSDWcEZp03tTUwXz5BDB5umvNZTjs3twPeEVHPChbH1fJdhD2P+7s4HGMasHnx1TR3jWqhecZv3tk0q2vsf+7aGHoWQFQ7Q= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6f934a22-1450-4e18-31c9-08d5427a2fd2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:AM4PR07MB3507; x-ms-traffictypediagnostic: AM4PR07MB3507: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231023)(6041248)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011); SRVR:AM4PR07MB3507; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR07MB3507; x-forefront-prvs: 052017CAF1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(376002)(366004)(346002)(396003)(24454002)(199004)(189003)(6486002)(1730700003)(81156014)(8936002)(50226002)(36756003)(81166006)(93886005)(57306001)(7736002)(8676002)(5660300001)(305945005)(6116002)(53936002)(6512007)(74482002)(6246003)(229853002)(105586002)(5640700003)(6436002)(68736007)(102836003)(42882006)(2950100002)(2351001)(6916009)(106356001)(25786009)(33656002)(2501003)(478600001)(3660700001)(83716003)(2906002)(86362001)(99286004)(5250100002)(82746002)(3280700002)(14454004)(316002)(2900100001)(76176011)(53546011)(97736004)(59450400001)(6506007)(786003)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3507; H:AM4PR07MB3508.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <6DCBE7C1FBCB234DBA15308050188B95@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 6f934a22-1450-4e18-31c9-08d5427a2fd2 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2017 22:38:09.7915 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3507 X-MC-Unique: 28M6iZwxMqir430KnQVVrg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 22:38:21 -0000 T24gMTMgRGVjIDIwMTcsIGF0IDAwOjA4LCBOYWltaW5nIFNoZW4gKG5haW1pbmcpIDxuYWltaW5n QGNpc2NvLmNvbT4gd3JvdGU6DQo+IEZpcnN0IG9mIGFsbCwgaWYgYW4gaW1wbGVtZW50YXRpb24g aGFzIGJ1Z3Mgb3IgdGhlIGNvbmZpZ3VyYXRpb24gaXMgbWlzaGFuZGxlZA0KDQpNeSBjb25jZXJu IGlzIGxlc3MgYXJvdW5kIGltcGxlbWVudGF0aW9uIGJ1Z3MsIGFuZCBtb3JlIGFyb3VuZCB0aGUg a2luZCBvZiBiZWhhdmlvdXIgdGhhdCBjYW4gaGFwcGVuIHVwc3RyZWFtIC0gaXTigJlzIG9uZSB0 aGluZyB0byBtYWtlIHlvdXIgb3duIGRlcGxveW1lbnQgbWlzYmVoYXZlLCBpdOKAmXMgYW5vdGhl ciB0byB0cmlnZ2VyIG1pc2JlaGF2aW91ciBpbiBzb21ldGhpbmcgdGhhdCBpc27igJl0IHVuZGVy IHlvdXIgY29udHJvbCAoYW5kIHRoZXJlZm9yZSwgY2Fubm90IGJlIGRlYnVnZ2VkLCBvciBwb3Rl bnRpYWxseSwgZXZlbiByZXNvbHZlZCB3aXRob3V0IG91dHNpZGUgYXNzaXN0YW5jZSkuDQoNCkFz IGEgcGFydGljaXBhbnQgaW4gYSByb2FtaW5nIGNvbnNvcnRpdW0sIHRoYXQgbWFrZXMgbWUgdW5j b21mb3J0YWJsZS4NCg0KPiBUaGUgZHJhZnQgSSBhZ3JlZSBuZWVkcyB0byBhZGQgc29tZSB0ZXh0 IG9uIHZhcmlvdXMgY2FzZXMgYW5kIGhvdyB0byBkZWJ1Zw0KPiB0aG9zZSBpbiBlYWNoIG9mIHRo ZW0uDQoNCkkgY2Fu4oCZdCBtYWtlIGEgY2hvaWNlIGJhc2VkIG9uIHRleHQgdGhhdCBkb2VzbuKA mXQgeWV0IGV4aXN0LCBidXQgSSB3b3VsZCBnaXZlIGl0IGR1ZSBjb25zaWRlcmF0aW9uIGlmIGl0 IHdlcmUgdG8gYXBwZWFyLg0KDQpTb21ld2hlcmUgaW4gdGhlIHRocmVhZCBzaW1wbGVyIGRlYnVn Z2luZyB3YXMgY2l0ZWQgYXMgYSBkZXNpcmFibGUgcHJvcGVydHkgb2YgZHJhZnQtY2hlbiAgLSBJ 4oCZbSBub3Qgc3VyZSBJIGdyYXNwZWQgdGhlIGFyZ3VtZW50IHRob3VnaC4gV2hhdCBtYWtlcyBh IGJ5dGUgc3RyaW5nIGluIHRoZSBoZWFkZXIgbW9yZSBkaWZmaWN1bHQgdG8gdmFsaWRhdGUvcHJp bnRmIHRoYW4gYW4gYnl0ZSBzdHJpbmcgZW5jYXBzdWxhdGVkIGluIGEgVExWPw0KDQpSZWdhcmRz LA0KDQpBZGFtIEJpc2hvcA0KDQogIGdwZzogRTc1QiAxRjkyIDY0MDcgREZERiA5RjFDICBCRjEw IEM5OTMgMjUwNCA2NjA5IEQ0NjANCg0KamlzYy5hYy51aw0KDQpKaXNjIGlzIGEgcmVnaXN0ZXJl ZCBjaGFyaXR5IChudW1iZXIgMTE0OTc0MCkgYW5kIGEgY29tcGFueSBsaW1pdGVkIGJ5IGd1YXJh bnRlZSB3aGljaCBpcyByZWdpc3RlcmVkIGluIEVuZ2xhbmQgdW5kZXIgQ29tcGFueSBOby4gNTc0 NzMzOSwgVkFUIE5vLiBHQiAxOTcgMDYzMiA4Ni4gSmlzY+KAmXMgcmVnaXN0ZXJlZCBvZmZpY2Ug aXM6IE9uZSBDYXN0bGVwYXJrLCBUb3dlciBIaWxsLCBCcmlzdG9sLCBCUzIgMEpBLiBUIDAyMDMg Njk3IDU4MDAuDQoNCkppc2MgU2VydmljZXMgTGltaXRlZCBpcyBhIHdob2xseSBvd25lZCBKaXNj IHN1YnNpZGlhcnkgYW5kIGEgY29tcGFueSBsaW1pdGVkIGJ5IGd1YXJhbnRlZSB3aGljaCBpcyBy ZWdpc3RlcmVkIGluIEVuZ2xhbmQgdW5kZXIgY29tcGFueSBudW1iZXIgMjg4MTAyNCwgVkFUIG51 bWJlciBHQiAxOTcgMDYzMiA4Ni4gVGhlIHJlZ2lzdGVyZWQgb2ZmaWNlIGlzOiBPbmUgQ2FzdGxl IFBhcmssIFRvd2VyIEhpbGwsIEJyaXN0b2wgQlMyIDBKQS4gVCAwMjAzIDY5NyA1ODAwLiAgDQo= From nobody Wed Dec 13 14:50:59 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FBF1274A5 for ; Wed, 13 Dec 2017 14:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 m0Gg2Uucm36i for ; Wed, 13 Dec 2017 14:50:56 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B961201F8 for ; Wed, 13 Dec 2017 14:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1702; q=dns/txt; s=iport; t=1513205455; x=1514415055; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/DAsYuuhvIX6oyY8u9tLxM/fPI1JXHboaa5GxvkKnZA=; b=NRw+xjYK/4uBdU7HWOdcaUTyfeP1DLnRCxaMQNLG7ug8PVtOtaM3+hUX F7/Mtwb7H8hCa6IpoI0pV6juKN0P0Ocybjcq6x98B4alFommIMRLddSYA Wtp+XaUcbVBJ45/zXLomj+gmvxvj4BVKQaaIT1x/6P7mlWTQQXfUZhCaN M=; X-IronPort-AV: E=Sophos;i="5.45,398,1508803200"; d="scan'208";a="43759632" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2017 22:50:55 +0000 Received: from [10.156.165.56] ([10.156.165.56]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vBDMosoC022680; Wed, 13 Dec 2017 22:50:55 GMT To: Stefan Winter References: Cc: radext@ietf.org, Enke Chen From: Enke Chen Message-ID: Date: Wed, 13 Dec 2017 14:50:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 22:50:58 -0000 Hi, Stefan: Here is my count of the votes: 13 for draft-chen-radext-identifier-attr-02 6 for draft-dekok-radext-request-authenticator-02 Is this correct? Thanks. -- Enke On 11/28/17 5:54 AM, Stefan Winter wrote: > Hello, > >> thanks all for raising the awareness of these two drafts. >> >> >> I think it would be good if all remaining readers of this list who care >> enough now take some time to read both drafts and make up their mind on >> what the preferred approach is. >> >> >> In approx. two weeks' time I will start a call for adoption on both >> drafts, and hopefully there are enough responses to make the exercise >> meaningful. If so, the one with more votes wins. > > Now that was a relaxed "two weeks" delay. My apologies, I've been on and > off work for a while, with substantial backlogs. > > This email starts a two week call for adoption of at most one of the > following two drafts: > > * draft-chen-radext-identifier-attr-02 > * draft-dekok-radext-request-authenticator-02 > > Since the two drafts treat the same topic, at most one can be selected > to serve as the basis for future work. > > In your reply to this call for adoption, please indicate which of the > two drafts you think should be adopted. You can of course also indicate > that none of the two are fit for purpose. The only thing you really > shouldn't do is to vote for both; that wouldn't help the discussion move on. > > Please reply by 12 dec 2017 2400 UTC. > > Greetings, > > Stefan Winter > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Wed Dec 13 18:05:45 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6681279EB for ; Wed, 13 Dec 2017 18:05:43 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Y3V7dL_7BEEZ for ; Wed, 13 Dec 2017 18:05:41 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id B945B127517 for ; Wed, 13 Dec 2017 18:05:41 -0800 (PST) Received: from [192.168.2.9] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id 6F4504D6; Thu, 14 Dec 2017 02:05:40 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Wed, 13 Dec 2017 21:05:38 -0500 Cc: "radext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9E698F12-57CD-4E3F-B100-5A7AF2D20108@deployingradius.com> References: <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> To: Adam Bishop X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 02:05:44 -0000 On Dec 13, 2017, at 5:38 PM, Adam Bishop wrote: > Somewhere in the thread simpler debugging was cited as a desirable = property of draft-chen - I=E2=80=99m not sure I grasped the argument = though. What makes a byte string in the header more difficult to = validate/printf than an byte string encapsulated in a TLV? I think the opinion is that looking at one packet, an *explicit* = Extended-ID attribute is easier to see than the idea that the Request = Authenticator is *implicitly* also used as an ID. But... it's 2017. There are many, many, solutions for correlating = requests and responses. Doing this in software is easy. There are many = free / open source products that will be available. And both proposals will confuse existing packet sniffing software. = That can't be helped, unfortunately. Alan DeKok. From nobody Thu Dec 14 06:39:04 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0969C126C89 for ; Thu, 14 Dec 2017 06:39:03 -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, URIBL_BLOCKED=0.001] 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 utLlPfriNprt for ; Thu, 14 Dec 2017 06:39:01 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (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 465621201F2 for ; Thu, 14 Dec 2017 06:39:01 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 48BDE43A65 for ; Thu, 14 Dec 2017 15:38:59 +0100 (CET) To: radext@ietf.org References: <8BD2C2F2-D42E-4B84-8F86-3A803160DD74@cisco.com> <285C5C94-578E-4293-81A2-9D73E1105ABE@deployingradius.com> <8DE62B3C-D2FA-4467-9CCE-7F8D039B87E2@cisco.com> From: Stefan Winter Organization: RESTENA Message-ID: Date: Thu, 14 Dec 2017 15:38:59 +0100 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: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: lb-LU Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 14:39:03 -0000 Hello, > I believe you are speaking as a contributor and not as a chair when making > technical contributions to this discussion (last two E-mails). Your belief if wrong. There are two obvious reasons: - I stated "as a chair" when beginning my mails - I am not a contributor to either of the two drafts Greetings, Stefan Winter > > Thanks, > Acee > > On 12/13/17, 2:22 AM, "radext on behalf of Stefan Winter" > wrote: > >> Hello, >> >> again as a chair: >> >> regarding the question of whether overloading of Request-Authenticator >> should be considered harmful, I think the message from Peter below best >> summarises the deployed reality in RADIUS. >> >> Basically, it makes clear that the decision to overload >> Message-Authenticator or not is not on our table. That decision has been >> taken ages ago, by this working group, and for a good number of RADIUS >> attributes. >> >> So, for the discussion at hand, fears about overloading the >> Request-Authenticator can safely be considered a non-argument. >> >> Greetings, >> >> Stefan Winter >> >>> On Fri, 1 Dec 2017, Jakob Heitz (jheitz) wrote: >>> >>>> What if the quantum computers turn out to live up to their promises? >>>> Then we can throw out all this authentication stuff and decide to not >>>> share our Ethernets with the attackers instead. No more request >>>> authenticator. >>> RADIUS security already lost cause no matter what :( >>> >>> Best practice for many years - use a secure transport and or RADIUS >>> over (D)TLS. Regardless of selected security option in all cases >>> operation of authenticator is maintained. >>> >>>> The request authenticator is already overloaded. It may be used for >>>> the CHAP challenge. Now, you want another overload? >>> Authenticator currently also used for at least following: >>> >>> Tunnel Passwords >>> Message-Authenticator >>> PAP >>> CHAP >>> MPPE Keys >>> >>> Clearly no possibility of authenticator ever changing in RADIUS >>> protocol without creation of an incompatible replacement. In event of >>> an incompatible replacement there would be no need for either of these >>> two drafts. >>> >>> I am aware of no practical downside to "Overloading". >>> >>> regards, >>> Peter >>> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext From nobody Thu Dec 14 06:43:50 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98A5126C89 for ; Thu, 14 Dec 2017 06:43:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, WEIRD_PORT=0.001] 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 ciF1aDC9X-mq for ; Thu, 14 Dec 2017 06:43:47 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (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 DB0E2126B6E for ; Thu, 14 Dec 2017 06:43:46 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 8971443A65 for ; Thu, 14 Dec 2017 15:43:45 +0100 (CET) To: "radext@ietf.org" From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: Date: Thu, 14 Dec 2017 15:43:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cMKfM6JMPeD8MvKJhCuCh2XxQROmfNSEs" Archived-At: Subject: [radext] Extended Identifiers: is manual configuration in scope? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 14:43:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cMKfM6JMPeD8MvKJhCuCh2XxQROmfNSEs Content-Type: multipart/mixed; boundary="28vklXIjTXNO4I2TDM4MRSGOdTqQRfppO"; protected-headers="v1" From: Stefan Winter To: "radext@ietf.org" Message-ID: Subject: Extended Identifiers: is manual configuration in scope? --28vklXIjTXNO4I2TDM4MRSGOdTqQRfppO Content-Type: multipart/mixed; boundary="------------A925CF8C338872440CE3A78D" Content-Language: lb-LU This is a multi-part message in MIME format. --------------A925CF8C338872440CE3A78D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, there is one question to which the answer did not become entirely clear in the discussion so far. Could the authors of the respective drafts please clearly indicate the answer to this question: Is a manually configured mode of operation considered in scope? I.e. do you consider it a valid use case that an implementation presents administrators with a configuration option "Enable Extended Identifiers", and that the implementation starts making use of that feature /without/ a capability negotiation using Status-Server with its next-hop peer? Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------A925CF8C338872440CE3A78D Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------A925CF8C338872440CE3A78D-- --28vklXIjTXNO4I2TDM4MRSGOdTqQRfppO-- --cMKfM6JMPeD8MvKJhCuCh2XxQROmfNSEs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJaMo4hAAoJEMDeajWKOdxmfHkP/jau2wCErPvPER1Q9YqiHGej AuYOHYZV2On3szI6jmC2kOUoJC7l/bCaXfB4Gm8b0fvwFO6caJi7sbuHAM5WNvuT WxPZFqfkRvsHbtG5c2cZ4O7viLLDhpzStUtXx7ZmrcqgaI7QvFPssyDqCKi2YU7Y eLNCX2qYBqPtmhgcyzIcfh9DeqIDdPsJSSD3yqZ0XfPBltx9xBnHw8yFtWs0i0KM ydYAD8OPKdiEjATNaFCJ0+N/W6UMbK0ZBPwQnitm7uXY4mldtd3vqJ0Nfm1tGHhs QNuDk+zA7Y6DaxCN7KFk/Q0RN2Biexw6rK9zjpukFySbPVkwMkjwxUT28jVKkxoP HsnF/NGR2ITW9VFU/VacUkUX1LzfpmhSbzvvCihN4U155UeckO6GxtRFKxVfF+/L G1qiA28AtfiuclN03+2ag1QVRtP4dW7akPm9YmJCm/1A1rXRN+XlCD1EflMbqijE KxpmZomF88V2B3kJ7ksRvUUtUFKBTeNvC/oSPNsGzpOTyK8ld+AaNyp7CYgiQAgN fPd+PPJsnJKUVnUbTHVrx3WUASB5p1Vm6CAzwCzbJ5nWC0C3w9ig2GVlUWbZ6b6c AJAidxmI4bKe23BelMNdGLyIpSEqwzJ2WJ+jkPDfVnI0n54wjny6VQUqYb829ckD HhXrlTQGh5hjW9Ypogox =0+Xo -----END PGP SIGNATURE----- --cMKfM6JMPeD8MvKJhCuCh2XxQROmfNSEs-- From nobody Thu Dec 14 07:13:25 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45614126DED; Thu, 14 Dec 2017 07:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 dOQJEIpUjMPy; Thu, 14 Dec 2017 07:13:17 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21626126D3F; Thu, 14 Dec 2017 07:13:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4222; q=dns/txt; s=iport; t=1513264397; x=1514473997; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ggh4jFc3RGGv7Ru5gpAlHQw7pL1wS/fm8sU1O2sT39w=; b=cEYzCS+GJWD4dKqQ0NscpGtdbaj3YD3Ontb9jGnecGLIx8sYfqQkQwCc 1oRode1N1tGibDOPXJREoHMXUo0uYLwi0ezWwOgW2l6KY0RLBa9pnjseZ 3Xtr7qkHMAh/3skGBjcH4xO0cx9FvAfWBhiiRG0Wr/GNnWD0CzmN57v6L w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AgCYkzJa/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7mSeBfZkrChgLhElPAhqEXUIVAQEBAQEBAQEBayi?= =?us-ascii?q?FJAEBAQMBASEROgsQAgEIGAICJgICAiULFRACBAENBYoqEKhzgieKXgEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgQ+CUYIOgz+DK4MuAYUDgmMFoyUClSiTbJZAAhE?= =?us-ascii?q?ZAYE6ATUjgU5vFTqCKYRWeIk2gRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,400,1508803200"; d="scan'208";a="335374526" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 15:13:15 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBEFDEku032179 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Dec 2017 15:13:15 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Dec 2017 10:13:14 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Thu, 14 Dec 2017 10:13:14 -0500 From: "Acee Lindem (acee)" To: Stefan Winter , "radext@ietf.org" CC: "radext-ads@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTaFBxQlK83f2iTECUdzRYa7wpJqMsVBUAgAFpdmCAASVyAIAAH4CAgAWDQYCADMOagIAAEIWAgAH74YD//7W0AA== Date: Thu, 14 Dec 2017 15:13:14 +0000 Message-ID: References: <8BD2C2F2-D42E-4B84-8F86-3A803160DD74@cisco.com> <285C5C94-578E-4293-81A2-9D73E1105ABE@deployingradius.com> <8DE62B3C-D2FA-4467-9CCE-7F8D039B87E2@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: text/plain; charset="utf-8" Content-ID: <8159315267447C4CA2FD7A635BFE556B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 15:13:24 -0000 DQpPbiAxMi8xNC8xNywgOTozOCBBTSwgInJhZGV4dCBvbiBiZWhhbGYgb2YgU3RlZmFuIFdpbnRl ciINCjxyYWRleHQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygc3RlZmFuLndpbnRlckBy ZXN0ZW5hLmx1PiB3cm90ZToNCg0KPkhlbGxvLA0KPg0KPj4gSSBiZWxpZXZlIHlvdSBhcmUgc3Bl YWtpbmcgYXMgYSBjb250cmlidXRvciBhbmQgbm90IGFzIGEgY2hhaXIgd2hlbg0KPj5tYWtpbmcN Cj4+IHRlY2huaWNhbCBjb250cmlidXRpb25zIHRvIHRoaXMgZGlzY3Vzc2lvbiAobGFzdCB0d28g RS1tYWlscykuDQo+DQo+WW91ciBiZWxpZWYgaWYgd3JvbmcuIFRoZXJlIGFyZSB0d28gb2J2aW91 cyByZWFzb25zOg0KPg0KPi0gSSBzdGF0ZWQgImFzIGEgY2hhaXIiIHdoZW4gYmVnaW5uaW5nIG15 IG1haWxzDQo+LSBJIGFtIG5vdCBhIGNvbnRyaWJ1dG9yIHRvIGVpdGhlciBvZiB0aGUgdHdvIGRy YWZ0cw0KDQpPZiBjb3Vyc2UsIEkgbWVhbnQgYSBXRyBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yIGFu ZCBub3QgYSBjb250cmlidXRvciB0bw0KdGhlIGRvY3VtZW50cy4gTm9ybWFsbHksIHlvdeKAmWQg c3BlYWsgImFzIGEgY2hhaXIiIG9ubHkgd2hlbiB5b3UgYXJlDQphZGRyZXNzaW5nIFdHIHByb2Nl c3MgYW5kIG5vdCB3aGVuIHlvdSBhcmUgbWFraW5nIHRlY2huaWNhbCBjb21tZW50cy4NCg0KQWNl ZSANCg0KPg0KPkdyZWV0aW5ncywNCj4NCj5TdGVmYW4gV2ludGVyDQo+DQo+Pg0KPj4gVGhhbmtz LA0KPj4gQWNlZSANCj4+DQo+PiBPbiAxMi8xMy8xNywgMjoyMiBBTSwgInJhZGV4dCBvbiBiZWhh bGYgb2YgU3RlZmFuIFdpbnRlciINCj4+IDxyYWRleHQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2Ygc3RlZmFuLndpbnRlckByZXN0ZW5hLmx1PiB3cm90ZToNCj4+DQo+Pj4gSGVsbG8sDQo+ Pj4NCj4+PiBhZ2FpbiBhcyBhIGNoYWlyOg0KPj4+DQo+Pj4gcmVnYXJkaW5nIHRoZSBxdWVzdGlv biBvZiB3aGV0aGVyIG92ZXJsb2FkaW5nIG9mIFJlcXVlc3QtQXV0aGVudGljYXRvcg0KPj4+IHNo b3VsZCBiZSBjb25zaWRlcmVkIGhhcm1mdWwsIEkgdGhpbmsgdGhlIG1lc3NhZ2UgZnJvbSBQZXRl ciBiZWxvdyBiZXN0DQo+Pj4gc3VtbWFyaXNlcyB0aGUgZGVwbG95ZWQgcmVhbGl0eSBpbiBSQURJ VVMuDQo+Pj4NCj4+PiBCYXNpY2FsbHksIGl0IG1ha2VzIGNsZWFyIHRoYXQgdGhlIGRlY2lzaW9u IHRvIG92ZXJsb2FkDQo+Pj4gTWVzc2FnZS1BdXRoZW50aWNhdG9yIG9yIG5vdCBpcyBub3Qgb24g b3VyIHRhYmxlLiBUaGF0IGRlY2lzaW9uIGhhcw0KPj4+YmVlbg0KPj4+IHRha2VuIGFnZXMgYWdv LCBieSB0aGlzIHdvcmtpbmcgZ3JvdXAsIGFuZCBmb3IgYSBnb29kIG51bWJlciBvZiBSQURJVVMN Cj4+PiBhdHRyaWJ1dGVzLg0KPj4+DQo+Pj4gU28sIGZvciB0aGUgZGlzY3Vzc2lvbiBhdCBoYW5k LCBmZWFycyBhYm91dCBvdmVybG9hZGluZyB0aGUNCj4+PiBSZXF1ZXN0LUF1dGhlbnRpY2F0b3Ig Y2FuIHNhZmVseSBiZSBjb25zaWRlcmVkIGEgbm9uLWFyZ3VtZW50Lg0KPj4+DQo+Pj4gR3JlZXRp bmdzLA0KPj4+DQo+Pj4gU3RlZmFuIFdpbnRlcg0KPj4+DQo+Pj4+IE9uIEZyaSwgMSBEZWMgMjAx NywgSmFrb2IgSGVpdHogKGpoZWl0eikgd3JvdGU6DQo+Pj4+DQo+Pj4+PiBXaGF0IGlmIHRoZSBx dWFudHVtIGNvbXB1dGVycyB0dXJuIG91dCB0byBsaXZlIHVwIHRvIHRoZWlyIHByb21pc2VzPw0K Pj4+Pj4gVGhlbiB3ZSBjYW4gdGhyb3cgb3V0IGFsbCB0aGlzIGF1dGhlbnRpY2F0aW9uIHN0dWZm IGFuZCBkZWNpZGUgdG8gbm90DQo+Pj4+PiBzaGFyZSBvdXIgRXRoZXJuZXRzIHdpdGggdGhlIGF0 dGFja2VycyBpbnN0ZWFkLiBObyBtb3JlIHJlcXVlc3QNCj4+Pj4+IGF1dGhlbnRpY2F0b3IuDQo+ Pj4+IFJBRElVUyBzZWN1cml0eSBhbHJlYWR5IGxvc3QgY2F1c2Ugbm8gbWF0dGVyIHdoYXQgOigN Cj4+Pj4NCj4+Pj4gQmVzdCBwcmFjdGljZSBmb3IgbWFueSB5ZWFycyAtIHVzZSBhIHNlY3VyZSB0 cmFuc3BvcnQgYW5kIG9yIFJBRElVUw0KPj4+PiBvdmVyIChEKVRMUy4gIFJlZ2FyZGxlc3Mgb2Yg c2VsZWN0ZWQgc2VjdXJpdHkgb3B0aW9uIGluIGFsbCBjYXNlcw0KPj4+PiBvcGVyYXRpb24gb2Yg YXV0aGVudGljYXRvciBpcyBtYWludGFpbmVkLg0KPj4+Pg0KPj4+Pj4gVGhlIHJlcXVlc3QgYXV0 aGVudGljYXRvciBpcyBhbHJlYWR5IG92ZXJsb2FkZWQuIEl0IG1heSBiZSB1c2VkIGZvcg0KPj4+ Pj4gdGhlIENIQVAgY2hhbGxlbmdlLiBOb3csIHlvdSB3YW50IGFub3RoZXIgb3ZlcmxvYWQ/DQo+ Pj4+IEF1dGhlbnRpY2F0b3IgY3VycmVudGx5IGFsc28gdXNlZCBmb3IgYXQgbGVhc3QgZm9sbG93 aW5nOg0KPj4+Pg0KPj4+PiBUdW5uZWwgUGFzc3dvcmRzDQo+Pj4+IE1lc3NhZ2UtQXV0aGVudGlj YXRvcg0KPj4+PiBQQVANCj4+Pj4gQ0hBUA0KPj4+PiBNUFBFIEtleXMNCj4+Pj4NCj4+Pj4gQ2xl YXJseSBubyBwb3NzaWJpbGl0eSBvZiBhdXRoZW50aWNhdG9yIGV2ZXIgY2hhbmdpbmcgaW4gUkFE SVVTDQo+Pj4+IHByb3RvY29sIHdpdGhvdXQgY3JlYXRpb24gb2YgYW4gaW5jb21wYXRpYmxlIHJl cGxhY2VtZW50LiAgSW4gZXZlbnQgb2YNCj4+Pj4gYW4gaW5jb21wYXRpYmxlIHJlcGxhY2VtZW50 IHRoZXJlIHdvdWxkIGJlIG5vIG5lZWQgZm9yIGVpdGhlciBvZiB0aGVzZQ0KPj4+PiB0d28gZHJh ZnRzLg0KPj4+Pg0KPj4+PiBJIGFtIGF3YXJlIG9mIG5vIHByYWN0aWNhbCBkb3duc2lkZSB0byAi T3ZlcmxvYWRpbmciLg0KPj4+Pg0KPj4+PiByZWdhcmRzLA0KPj4+PiBQZXRlcg0KPj4+Pg0KPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gcmFk ZXh0IG1haWxpbmcgbGlzdA0KPj4+IHJhZGV4dEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0DQo+DQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5yYWRleHQgbWFpbGluZyBsaXN0DQo+cmFk ZXh0QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYWRl eHQNCg0K From nobody Thu Dec 14 07:14:08 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EF4126DED for ; Thu, 14 Dec 2017 07:14:07 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ufyFTjTnJ020 for ; Thu, 14 Dec 2017 07:14:04 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id AE7B012932A for ; Thu, 14 Dec 2017 07:14:04 -0800 (PST) Received: from [192.168.2.25] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id 895D9AC4; Thu, 14 Dec 2017 15:14:03 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Thu, 14 Dec 2017 10:14:01 -0500 Cc: "radext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Winter Stefan X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended Identifiers: is manual configuration in scope? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 15:14:07 -0000 On Dec 14, 2017, at 9:43 AM, Stefan Winter = wrote: > Is a manually configured mode of operation considered in scope? Yes. = https://tools.ietf.org/html/draft-dekok-radext-request-authenticator-03#se= ction-8.1 Clients SHOULD have an configuration flag which lets administators statically configure this behavior for a server. Clients MUST otherwise negotiate this functionality before using it. > I.e. do you consider it a valid use case that an implementation = presents > administrators with a configuration option "Enable Extended > Identifiers", and that the implementation starts making use of that > feature /without/ a capability negotiation using Status-Server with = its > next-hop peer? Yes. We have manual configuration for many other things in RADIUS. I think = it should be allowed unless there is a strong technical reason to forbid = it. On a related note, I'd like a more detailed discussion about the = subject of negotiation. What happens during negotiation? i.e. it's easy to say "send status-server and wait for access-accept = with ACK or NACK". But what *else* happens? - are all *other* packets blocked until the client receives an ACK or a = NACK? - i.e. does the client sit on all outgoing packets until such time as = it receives a response? - what if the server doesn't support Status-Server and never responds? - when should the client time out? - should the client do the negotiation per connection (or for UDP = src/dst IP/port combination) - if not, why not? - if so, why? - what happens if the client stops sending packets for a while? - should it restart negotiation if there have been no packets? - if so, what are the timeouts? - if the server sends an old-style reply after negotiating the = functionality, can it be matched to an outstanding packet? My concern is that it's easy to say "negotiate functionality". The = code changes may even be small. But the hard part of coding isn't = implementing a particular piece of functionality. It's ensuring that = the program behaves correctly in corner cases, or when things go wrong. Taking a look at the patch posted earlier: https://mailarchive.ietf.org/arch/msg/radext/BkXgD68MASxqD4vjXV1M2CaRWAY None of these issues are handled. I suspect that dealing with these = corner cases will make the code much more complex. Much of the verbiage in draft-dekok is there in order to deal with = these issues. As an implementor, the draft is written with an eye to = dealing with *all* corner cases. It gives technical reasons for the = decisions, it discusses the pros and cons of these decisions, and it = gives guidelines for implementors. The result is a draft which is *much* more complex than "add a 32-bit = ID to a packet". But that complexity highlights the complex nature of = the protocol, instead of waving it away. I'd be happier with draft-chen if it could be shown that all of these = issues are addressed in a *simpler* manner than in draft-dekok. While = I'm concerned with the possibility of "leaking" the extended-ID, = implementation simplicity should be a serious consideration, too. Alan DeKok. From nobody Thu Dec 14 07:15:33 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C1A128896; Thu, 14 Dec 2017 07:15:31 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 WSdvC1CzchMv; Thu, 14 Dec 2017 07:15:30 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id E4FC0126D3F; Thu, 14 Dec 2017 07:15:24 -0800 (PST) Received: from [192.168.2.25] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id 1E60D11C0; Thu, 14 Dec 2017 15:15:21 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Thu, 14 Dec 2017 10:15:20 -0500 Cc: "radext@ietf.org" , "radext-ads@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3DD57A26-3B4F-4EAB-AC6E-CB2F0126B917@deployingradius.com> References: <8BD2C2F2-D42E-4B84-8F86-3A803160DD74@cisco.com> <285C5C94-578E-4293-81A2-9D73E1105ABE@deployingradius.com> <8DE62B3C-D2FA-4467-9CCE-7F8D039B87E2@cisco.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 15:15:31 -0000 On Dec 14, 2017, at 10:13 AM, Acee Lindem (acee) wrote: > Of course, I meant a WG individual contributor and not a contributor = to > the documents. Normally, you=E2=80=99d speak "as a chair" only when = you are > addressing WG process and not when you are making technical comments. To be fair, deciding which topics are on point is part of the WG = process, and within the bounds of a chairs discretion. Alan DeKok. From nobody Thu Dec 14 07:33:02 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB76712940D; Thu, 14 Dec 2017 07:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 m25aHO5eMqH4; Thu, 14 Dec 2017 07:32:50 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C508124319; Thu, 14 Dec 2017 07:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1014; q=dns/txt; s=iport; t=1513265570; x=1514475170; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Un5rWqSXQH1gZxEJ3wHh4nasAGgCXKkhS4aby/n9wR4=; b=SdQTBTUI8IEgfxMnBMPIukMpgMnJef5ivrAcw2rB1U2klERiVWwmyGSv KqDm9NfRg+WUPIswdhIRkzTgIwoix5d5DwlAv3VkvLtHfKFAZfxZJDTTd O9PYCq+K0znjBwCaLI+Au1ZIxIjzfdYwaJMHwhpDZ2pTArdbthsYUY89Q I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4AgCbmDJa/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+gVonB4N7mSeBfZcWghUKhTsCGoRdQRYBAQEBAQEBAQFrKIU?= =?us-ascii?q?jAQEBAQIBIxFFEAIBCBgCAiYCAgIwFRACBA4FiiIIqH2CJ4peAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYEPglGCDoZqgy+BbheCfoJjBaMlApUok2yWQAIRGQGBOgE?= =?us-ascii?q?mAy+BTm8VgmOEVniJNoEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,400,1508803200"; d="scan'208";a="321979031" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2017 15:32:49 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vBEFWnAA016469 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Dec 2017 15:32:49 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Dec 2017 10:32:48 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Thu, 14 Dec 2017 10:32:48 -0500 From: "Acee Lindem (acee)" To: Alan DeKok CC: "radext@ietf.org" , "radext-ads@ietf.org" Thread-Topic: [radext] Extended IDs Thread-Index: AQHTaFBxQlK83f2iTECUdzRYa7wpJqMsVBUAgAFpdmCAASVyAIAAH4CAgAWDQYCADMOagIAAEIWAgAH74YD//7W0AIAAVHQA//+w/QA= Date: Thu, 14 Dec 2017 15:32:48 +0000 Message-ID: References: <8BD2C2F2-D42E-4B84-8F86-3A803160DD74@cisco.com> <285C5C94-578E-4293-81A2-9D73E1105ABE@deployingradius.com> <8DE62B3C-D2FA-4467-9CCE-7F8D039B87E2@cisco.com> <3DD57A26-3B4F-4EAB-AC6E-CB2F0126B917@deployingradius.com> In-Reply-To: <3DD57A26-3B4F-4EAB-AC6E-CB2F0126B917@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 15:33:01 -0000 DQoNCk9uIDEyLzE0LzE3LCAxMDoxNSBBTSwgIkFsYW4gRGVLb2siIDxhbGFuZEBkZXBsb3lpbmdy YWRpdXMuY29tPiB3cm90ZToNCg0KPk9uIERlYyAxNCwgMjAxNywgYXQgMTA6MTMgQU0sIEFjZWUg TGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPj4gT2YgY291cnNlLCBJIG1l YW50IGEgV0cgaW5kaXZpZHVhbCBjb250cmlidXRvciBhbmQgbm90IGEgY29udHJpYnV0b3IgdG8N Cj4+IHRoZSBkb2N1bWVudHMuIE5vcm1hbGx5LCB5b3XigJlkIHNwZWFrICJhcyBhIGNoYWlyIiBv bmx5IHdoZW4geW91IGFyZQ0KPj4gYWRkcmVzc2luZyBXRyBwcm9jZXNzIGFuZCBub3Qgd2hlbiB5 b3UgYXJlIG1ha2luZyB0ZWNobmljYWwgY29tbWVudHMuDQo+DQo+ICBUbyBiZSBmYWlyLCBkZWNp ZGluZyB3aGljaCB0b3BpY3MgYXJlIG9uIHBvaW50IGlzIHBhcnQgb2YgdGhlIFdHDQo+cHJvY2Vz cywgYW5kIHdpdGhpbiB0aGUgYm91bmRzIG9mIGEgY2hhaXJzIGRpc2NyZXRpb24uDQoNCldoaWxl IHRoZXkgYXJlIG5vIGxvbmdlciBpbiB0aGUgdGhyZWFkLCB0aGVzZSB3ZXJlIGNsZWFybHkgdGVj aG5pY2FsDQpjb21tZW50cyBhcyB0byBob3cgUkFESVVTIHdvcmtzIGFuZCBpcyBkZXBsb3llZC4g VGhlc2UgY29tbWVudHMgc2hvdWxkDQpzdGFuZCBvbiB0aGVpciBvd24gbWVyaXQgYW5kIG5vdCB0 aGUgY2hhaXIgcG9zaXRpb24uDQoNCkFjZWUgIA0KDQo+DQo+ICBBbGFuIERlS29rLg0KPg0KDQo= From nobody Thu Dec 14 12:00:37 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A636F129463 for ; Thu, 14 Dec 2017 12:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Yojpnmw_XAH8 for ; Thu, 14 Dec 2017 12:00:34 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47FBD1294E9 for ; Thu, 14 Dec 2017 12:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1402; q=dns/txt; s=iport; t=1513281627; x=1514491227; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=28Bk0JpVuZImdRXLGti8rb6GCdi9c9GMSKUf+iAo5b4=; b=gOPjRPF+QSkQVbNtSrP6VULAFSHn1NytX4vr99kJHi04dFMX5KbjHd/U k4WUuYGhrrG8VwHaNmSn3HEyFMAS6aBOtHd1ZY7mTApvNryy2smNf8yRS PKEqGrI61T/z74b1ru3TkD6ElgDNZ14KwdDcC2DicRjVFA/9LptzKuhsG E=; X-IronPort-AV: E=Sophos;i="5.45,401,1508803200"; d="scan'208";a="336102650" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2017 20:00:26 +0000 Received: from [10.156.165.92] ([10.156.165.92]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBEK0QSs001965; Thu, 14 Dec 2017 20:00:26 GMT To: Stefan Winter References: Cc: "radext@ietf.org" , Naiming Shen From: Enke Chen Message-ID: <2e4a6be6-114f-4556-67ae-aac371c57e7b@cisco.com> Date: Thu, 14 Dec 2017 12:00:27 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [radext] Extended Identifiers: is manual configuration in scope? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 20:00:37 -0000 Hi, Stefan: Yes, it is, and such a config is allowed in the following section of draft-chen-radext-identifier-attr-02.txt. ---- 2.2. Status-Server Considerations Unless specified by configuration, a client MUST NOT send a RADIUS packet (other than the Status-Server request) with the "Extended Identifier Attribute" to a server until it has received a response from the server confirming its support for the Extended Identifier feature using the "Extended Identifier Attribute". Thanks. -- Enke On 12/14/17 6:43 AM, Stefan Winter wrote: > Hello, > > > there is one question to which the answer did not become entirely clear > in the discussion so far. > > > Could the authors of the respective drafts please clearly indicate the > answer to this question: > > > Is a manually configured mode of operation considered in scope? > > > I.e. do you consider it a valid use case that an implementation presents > administrators with a configuration option "Enable Extended > Identifiers", and that the implementation starts making use of that > feature /without/ a capability negotiation using Status-Server with its > next-hop peer? > > > Greetings, > > > Stefan Winter > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Thu Dec 14 23:07:57 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC9C1274A5; Thu, 14 Dec 2017 23:07:56 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 9nLAXLsE1RhS; Thu, 14 Dec 2017 23:07:55 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (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 32F9C12714F; Thu, 14 Dec 2017 23:07:55 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9674543A65; Fri, 15 Dec 2017 08:07:53 +0100 (CET) To: "Acee Lindem (acee)" , Alan DeKok Cc: "radext@ietf.org" , "radext-ads@ietf.org" References: <8BD2C2F2-D42E-4B84-8F86-3A803160DD74@cisco.com> <285C5C94-578E-4293-81A2-9D73E1105ABE@deployingradius.com> <8DE62B3C-D2FA-4467-9CCE-7F8D039B87E2@cisco.com> <3DD57A26-3B4F-4EAB-AC6E-CB2F0126B917@deployingradius.com> From: Stefan Winter Organization: RESTENA Message-ID: <4a200e86-1c07-40cf-ea5a-44f4cd705300@restena.lu> Date: Fri, 15 Dec 2017 08:07:53 +0100 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: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: lb-LU Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 07:07:56 -0000 Hi, > While they are no longer in the thread, these were clearly technical > comments as to how RADIUS works and is deployed. These comments should > stand on their own merit and not the chair position. Much rather, these were statements regarding past working group practice. There are several RFCs overloading the Request-Authenticator for a number of reasons. By issuing those RFCs, the working group has repeatedly (either implicitly or explicitly; feel free to browse the mail archive for details) made the decision that this is not an issue. It is also an easy observation that the sky has not fallen onto RADIUS as a result of those decisions back then. The sentences above are not an opinion; they are merely statements reminding the working group participants of our collective past. It is part of the "moderate discussions" job of a chair to point out such things. Greetings, Stefan Winter From nobody Thu Dec 14 23:30:44 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1872126FB3 for ; Thu, 14 Dec 2017 23:30:41 -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 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 gIzs_Q4FsunT for ; Thu, 14 Dec 2017 23:30:40 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (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 2714D124BFA for ; Thu, 14 Dec 2017 23:30:40 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id C4CA443A65 for ; Fri, 15 Dec 2017 08:30:38 +0100 (CET) From: Stefan Winter To: "radext@ietf.org" References: Organization: RESTENA Message-ID: Date: Fri, 15 Dec 2017 08:30:38 +0100 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: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: lb-LU Archived-At: Subject: Re: [radext] Extended Identifiers: failure modes X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 07:30:42 -0000 Hello, thanks for the clarification. In this case - manual configuration is considered in scope -, both need to be prepared for particular scrutiny of their respective failure modes. The considerations in RFC5706 are of course valid for every draft in the IETF; but they are even more in the focus of the Operations & Management area, as the Appendix A of that RFC is what the Ops Directorate uses for its OPSDIR reviews during IETF Last Call. Failure Management is an explicit item to look out for, and the pertinent question is: "Does the solution have failure modes that are difficult to diagnose or correct?" If there were only one draft, I'd happily care about this after WG adoption. But considering that there are two competing concepts where one of the main differences is apparently on this very question, and where the difference is rooted in the /concept/ (i.e. not easy to fix with draft revisions later on), I believe it makes sense to highlight this right now. We have seen many arguments going back and forth on this topic. I'm trying to summarise those below. The failure modes possible in draft-dekok a) are always local to the client/server pair that tries to communicate b) are harder to see during packet inspection of the request; need to correlate request and response c) correction of faulty configuration requires action of admnistrators of two adjacent RADIUS nodes who are usually in contact with each other, or even in the same administrative domain The failure modes possible in draft-chen a) possibly transpire over an arbitrary amount of proxies b) are easier to see in a packet inspection in the request; no need to correlate request and response c) correction of faulty configuration requires interaction of all administrators along the affected proxy chain, who are not necessarily otherwise in direct contact (IOW, two distinct arguments made earlier, "easier to debug" vs. "stay local", actually both relate to the same topic of failure modes and their remediation) In that light, it would seem that neither of the two drafts are perfect. draft-dekok has harder debugging on the local link, draft-chen may involve parties across "the internet" (or rather the subset of RADIUS servers on it).  In the end, the question is which failure mode is "less difficult" to handle. Greetings, Stefan Winter Am 14.12.2017 um 15:43 schrieb Stefan Winter: > Hello, > > > there is one question to which the answer did not become entirely clear > in the discussion so far. > > > Could the authors of the respective drafts please clearly indicate the > answer to this question: > > > Is a manually configured mode of operation considered in scope? > > > I.e. do you consider it a valid use case that an implementation presents > administrators with a configuration option "Enable Extended > Identifiers", and that the implementation starts making use of that > feature /without/ a capability negotiation using Status-Server with its > next-hop peer? > > > Greetings, > > > Stefan Winter > > From nobody Fri Dec 15 03:53:18 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99D7126C26 for ; Fri, 15 Dec 2017 03:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 OG3WeQKMjD0b for ; Fri, 15 Dec 2017 03:53:15 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id B311C126557 for ; Fri, 15 Dec 2017 03:53:14 -0800 (PST) Received: from [192.168.2.25] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id AEA5854C; Fri, 15 Dec 2017 11:53:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Fri, 15 Dec 2017 06:53:11 -0500 Cc: "radext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <45DD19BE-C331-4EBA-9EB2-44630716AEB2@deployingradius.com> References: To: Winter Stefan X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended Identifiers: failure modes X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 11:53:17 -0000 On Dec 15, 2017, at 2:30 AM, Stefan Winter = wrote: > If there were only one draft, I'd happily care about this after WG > adoption. But considering that there are two competing concepts where > one of the main differences is apparently on this very question, and > where the difference is rooted in the /concept/ (i.e. not easy to fix > with draft revisions later on), I believe it makes sense to highlight > this right now. I'd like to have a larger discussion of not only failure modes, but = implementation issues. I really do suspect that a large part of the push-back against = draft-dekok is not just the "overloading" issue, but that the failure = modes and implementation issues are *described*. Whereas in draft-chen, = they're not. I also suspect that once we get into details, the issues with = draft-chen won't be that different from draft-dekok. > We have seen many arguments going back and forth on this topic. I'm > trying to summarise those below. >=20 > The failure modes possible in draft-dekok > a) are always local to the client/server pair that tries to = communicate > b) are harder to see during packet inspection of the request; need to > correlate request and response I would phrase that as "there's no explicit indication in the request = that the new method is being used". But all you need to do is observe one response containing the = Original-Request-Authenticator, and you know that the draft is being = used. If there is no such attribute... it's just traditional RADIUS. And if you can't see responses, well, you have other issues. So I = would label (b) here as a non-issue. > c) correction of faulty configuration requires action of = administrators The draft goes through fall-back in detail. Implementations are = mandated to have failure modes that are compatible with existing RADIUS. i.e. no administrator intervention is required. > The failure modes possible in draft-chen > a) possibly transpire over an arbitrary amount of proxies To be fair, most of the time the attribute "leaks", nothing bad = happens. But it does seem unfriendly. > b) are easier to see in a packet inspection in the request; no need to > correlate request and response You can see the new attribute in the request. But to track packets, = you'd still need to correlate requests and responses. > c) correction of faulty configuration requires interaction of all > administrators along the affected proxy chain, who are not necessarily > otherwise in direct contact It's also not clear what the failure modes or fallback behaviour is = for a client/server that communicate directly with each other. > In that light, it would seem that neither of the two drafts are = perfect. Anything RADIUS is far from perfect. > draft-dekok has harder debugging on the local link, draft-chen may > involve parties across "the internet" (or rather the subset of RADIUS > servers on it). In the end, the question is which failure mode is = "less > difficult" to handle. Implementation issues matter, too. If implementors are left to their own devices, we will have all kinds = of deployment and inter-operability issues. If we leave these = discussions until *after* we've chosen a draft, then we might discover = that the draft has had unseen issues all along. Alan DeKok. From nobody Fri Dec 15 06:22:37 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC391252BA for ; Fri, 15 Dec 2017 06:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=digriz.org.uk header.b=GewLWpk7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=R8LTrAtq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE1O4eU03wBh for ; Fri, 15 Dec 2017 06:22:33 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BCA2128D3E for ; Fri, 15 Dec 2017 06:22:33 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C6C53208B8 for ; Fri, 15 Dec 2017 09:22:32 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 15 Dec 2017 09:22:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digriz.org.uk; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=z/L3WYPyP4jV6Cvi0DdCtHmZFEOb0/RU+cDsybsUm us=; b=GewLWpk7XOslgigYkSy35oss27bAfGl8NKhk9epwGoio1UFOKfqV91ylU uYIxnnbnRUL70b5dBUFYu9EnwpaZ2s0hl6Br+csg6hHH5xd9SM7LpO+nuMGPyweQ b6EAgxqEJYhU8jfOZgdBdeZFwhA1WGIcwfcCDMdfPfFhfS+LwcGcmJYHpP13Zkky NeBs+gH8cw/VYXjM3OPtqn3a2ZPylEvCcJNTWIbC7EtupEFIO1jRYi7GwSTJe/xB WXkNb8l9KcxImSPPVw6jWHXLDS5khVOsbJysp/zkzPEz2WF9Rkk/9Nq2iqkb1MRl V0lqDzf3p7x6k4aOrxV2hj9fXIYGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=z/L3WYPyP4jV6Cvi0 DdCtHmZFEOb0/RU+cDsybsUmus=; b=R8LTrAtqD9wi4hn/At/xsS3t6BRSXSmKR 3sUMDjhpy8N3rmOFpvVm/N1A809nkNvHPRbVh6VndScXYz9GLTJnT3WkRl0DHuU4 JYjz1rXQLHHxnykyeiFdG9+/ojZqgDyB8C0ux7t74LJfkFYfqnrbghqo7vPEwND/ 4zANm3JZDKGFUwUuYt5BTeVlJvWKphHAv8befiSd0mVc9UgpH9s/oG6q044wYQbT 7C9JBCWZ3bEWSoMvDTARChpsiVTV7CqtnLKKwpUpdWK1xcy2AfIyojxLu4pqmlMx VJkB5OUgLqIp60GXJzoE4KwngCzRddfxm7FEP0TRsMCqV9mXbTTcA== X-ME-Sender: Received: from quatermain.digriz.wormnet.eu (waffles.digriz.wormnet.eu [77.75.106.34]) by mail.messagingengine.com (Postfix) with ESMTPA id 512097E3D8 for ; Fri, 15 Dec 2017 09:22:32 -0500 (EST) Date: Fri, 15 Dec 2017 14:22:31 +0000 From: Alexander Clouter To: radext@ietf.org Message-ID: <20171215142231.rtwmryojskykwxj6@quatermain.digriz.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Auto-Response-Suppress: OOF User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 14:22:35 -0000 > This email starts a two week call for adoption of at most one of the > following two drafts: > > * draft-chen-radext-identifier-attr-02 > * draft-dekok-radext-request-authenticator-02 > > Since the two drafts treat the same topic, at most one can be selected > to serve as the basis for future work. My post deadline 0.02... Though on every ones lips is extending the ID, I would disagree that the drafts cover the same topic and that draft-dekok only solves this problem indirectly. draft-dekok covers a real problem, not considered by draft-chen, on how to handle late responses to authentications where the ID collides, this is something that should be firmed up. Firming up with draft-dekok happens to mean there is no need to also push ahead with draft-chen. Pushing with draft-chen, still leaves everyone with this ambiguity around ID collisions. I do not perceive anything to indicate that draft-chen is easier to reason about than draft-dekok, they strike me as in effect identical as both return a special attribute in the *response*. The request packet though is less interesting and for me irrelevant where the extra entropy appears from. From an implementation perspective the difficulty exists at the NAS/proxy rather than the server. The impact of doing duplicate work at the server is negligible compare to a NAS/proxy not being able to reconcile replies to their requests. In regards to the draft its self, draft-chen looks straight forward, but having had the unsavoury experience of implementing a specification that states only the 'what' rather than the 'why' or 'how' (TACACS, I am looking at you...) I find it hard to rally behind something I am hesitant to believe is as simple as it looks. draft-chen reads as "this is what is baked in an existing codebase" with no information on the 'what if' or detailing any edge cases the implementers experienced. I need to know about problems and caveats I need to know about, I do not need to know how to clone an existing implementation, I have tcpdump for that :) ...draft-dekok gets my, no doubt too late for consideration, vote.