From nobody Mon Jul 6 13:16:24 2020 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 2180A3A0A49; Mon, 6 Jul 2020 13:16:23 -0700 (PDT) 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, SPF_HELO_NONE=0.001, 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 ez6W5xSRra5I; Mon, 6 Jul 2020 13:16:20 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28603A0A40; Mon, 6 Jul 2020 13:16:19 -0700 (PDT) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id EA606719; Mon, 6 Jul 2020 20:16:16 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Alan DeKok In-Reply-To: Date: Mon, 6 Jul 2020 16:16:15 -0400 Cc: "opsawg@ietf.org" , "radext@ietf.org" , OpsAWG-Chairs , Benjamin Kaduk , "radext-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1D54DD45-8F8A-4691-87C2-DC1BB5BE5C9F@deployingradius.com> References: <2064d9a1a5d54aa1899664f1f55d59aa@cert.org> <20200621024216.GF11992@kduck.mit.edu> <87adbd01-a100-7192-5b0d-fdc180ac2f5d@restena.lu> To: "Massameno, Dan" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [radext] [OPSAWG] RADIUS Extension, Getting Started X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jul 2020 20:16:23 -0000 On Jul 6, 2020, at 11:40 AM, Massameno, Dan = wrote: >=20 > Dear Ops and Management Area WG, >=20 > There have been a number of great suggestions on where to post this = document (Thanks Stefan!). I'm now emailing opsawg@ietf.org and cc'ing = radext@ietf.org. =20 >=20 > The draft is posted here... = https://tools.ietf.org/html/draft-massameno-radius-lb-00 >=20 > Do I need an official IETF sponsor? Would it help to try and get a = vendor interested in implementing the protocol? Cisco is our primary = vendor at Yale University. I was wondering if there is anyone on either = of these working groups that communicates with Cisco people on a regular = basis? There are lots of Cisco people. I'm sure some of those people have = opinions. There are a few things ongoing here. The RADEXT WG is still alive, = but inactive. There is a still an open discussion in the WG about = previous documents which addressed shortcomings in the base RADIUS = protocol. The polite version is that the long-term RADEXT participants = supported one draft. Many people who had never been involved with = RADEXT supported a competing draft. There was never any resolution. = The RADEXT WG was left in limbo. I'll avoid the subject of the best place for this draft. Overall, I would oppose this draft. For the simple reason that brains = belong in the RADIUS server, not in the NAS. NAS vendors haven't even = implemented the retransmission behaviours suggested in RFC 5080 Section = 2.1, which is well over a decade old at this point. If they can't do = that, how can they implement an even more complex load-balancing system? Further, there is no standard in RADIUS for load-balancing with = fail-over and fail-back. Every NAS vendor and RADIUS vendor does = something different. While this document tries to address that issue, = it does not address a number of key points. I do have a review, as follows. Many of these issues given below are = nits, and can be fixed by rewording the document, or moving to an = approach which follows existing standards (RFC 6158, RFC 6929, RFC = 8044). However, for reasons given above, I don't think it's useful to = move ahead with this document. * Section 2 - Message Summary I recommend deleting this part. The RADIUS packet format is well = known. There's no need to repeat the definition here. Just refer to = RFC 5997. * Section 2.2 - nitpick: 191 is not defined, so it's likely best to = leave this attribute value as TBD, even if IANA is likely to choose 191. Further, RADIUS definitions use consistent names for attributes. The = names do not change when they're used in different packet types. The = attribute should just be called something like "Load-Balance-Status" * Section 2.3.2 - the text here is simply wrong. The = Request-Authenticator is not "hashed with the identity material from the = calling-station and the RADIUS shared secret." RFC 5997 Section 5 already mandates the use of Message-Authenticator = with Status-Server. I suggest deleting 2.3.2 entirely. * Section 3 - the definition of the LB-Request does not satisfy the = requirements of RFC 6929 Section 5.2. There is no reason to use a = 16-bit data type here. https://tools.ietf.org/html/rfc6929#section-6.2 RFC 8044 also defines data types which are appropriate for use in = RADIUS. That RFC also suggests that there is no longer need for ASCII = art in most cases, as attribute definitions can just use predefined data = types. Also in general, reserved bits should go at the top of an integer = attribute. Status bits should be in the lower bits. * Section 4.1 redefines attribute 191 to contain completely different = data. This definition violates the prohibition on polymorphic = attributes given in RFC 6159 Section 3.4 https://tools.ietf.org/html/rfc6158#section-3.4 I suggest using two different attributes, one for signalling client to = server, and another for responding server to client. The text in this section is also unclear: Server_Info The String field is one or more server_info PDUs. Each PDU defines the status of a single server and its defining characteristics. What does that mean? Is the intent to carry the SVR-Record attributes = inside of attribute 191? If so, then using attribute 191 as both a = 16-bit bitfield, and as a TLV carrier is very odd. It's safe to say = that nothing will ever support this. I suggest using two different = attrributes. I suggest simply relying on the existence of one or more SRV-Record = attributes in the reply. There is no need to repeat the LB-* attribute. * Section 5 The SRV-Record TLV This section does not define any TLV attribute. It's not clear what = this means. * Section 5.1 and 5.2 It's not clear why two different attributes are needed. Why not just = use SRV-Record? And there's no need to repeat ASCII art. RFC 8044 Section 3.13 = already defines the TLV data type, and format. You should just = reference that. * Section 5.3 defines a table of attributes, including attributes not = previously seen in the document. I suggest moving the table of attributes to later in the document, = *after* the relevant attributes have been defined. * Section 6 There's no need for ASCII art. RFC 8044 Section 2.1.2 makes this = clear. Just reference the data types. * Section 7.1 The document says: ... Under these Status-Server-LB rules the NAS MUST send all RADIUS messages relative to a particular session to the same RADIUS server to maximize the probability of a cache-hit. What then, is the utility of land balancing? If one RADIUS server = goes down, cannot the NAS send packets for a session to a different, but = *equivalent* RADIUS server? This recommendation seems to drastically = increase the likelihood of losing accounting packets, which seems bad. In addition, the discussion of "caching" seems odd, and uncommon. = Databases do user replication, not RADIUS servers. We should not expose = implementation details in a standard document. i.e. the RADIUS servers should be treated as identical, and local = balancing should be done on a packet by packet basis. * Section 7.2 The document says: The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being used for AAA services.=20 Ok, *how* is this to be done? Specifying this behaviour seems = important. Perhaps adding up all weights of a similar priority, and = choosing a "W_i" at random, with probability W_i / Sum(W_0. ... W_n) * Missing: discussion of shared secrets, authentication vs accounting, = ports, TLS, TCP, etc. What shared secret is used for these different RADIUS servers? The = same one as used in the original Status-Server? What ports should the NAS send packets to? Does this load balancing = work for all packet types? What about TCP, UDP, TLS, etc.? How does this proposal interact with = dynamic discovery? (RFC 7585) * Section 8 The document says: RADIUS Server Load Balancing has many of the same security implications as the base RADIUS protocol. There are many additional security issues opened up by this new = capability. They should be discussed. * Section 10 The document says: The Vendor Specified Attribute 26 may be used to encapsulate the LB- Request and LB-Response PDU where no vendor interoperability is required. It is very odd to put standards text inside of an "IANA = considerations" section. Further, this text appears to be confused = about the purpose of the RADIUS attribute numbers. These numbers are = location-sensitive. i.e. vendor attribute "191" has no relation = whatsoever to attribute "191" in the main RADIUS space. Similarly, it = has no relation to an attribute "191" from another vendor. This text is wrong and should be deleted. Summary: Even if the various nits and and issues above were fixed, this = proposal would have serious security issues. Even if those security = issues were addressed, I believe that load balancing is simply not = appropriate for the NAS. Even if it was appropriate for the NAS, the = vendors have spoken: NAS implementations are simple, and server = implementations are complex. As such, load balancing more properly belongs in the server. Alan DeKok. From nobody Tue Jul 7 02:13:44 2020 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 DF1083A1636; Mon, 6 Jul 2020 08:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yale.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUFwbg6yNnO9; Mon, 6 Jul 2020 08:41:01 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2094.outbound.protection.outlook.com [40.107.243.94]) (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 AE7EA3A15F8; Mon, 6 Jul 2020 08:40:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b2vk1W/rI4/qY259UtrwfJuSkqBBxbhjjuzejkJPinToPKiDBiVD34OHHCJ8/sSGvEwM6pd4dOVYrK74IqZK69fz8v9RJL8pCBi8WARjSVgZzQE24S3yDHzXbAVdsXU3w46GhsTumkCEBBUIYT7M6jqmmR6vdV29cToa/hMVDG2Ipsnb0SF1awDwGdeScdgcV0fTwRKAVa2NPy3Y9PvQ7heHjpLqRc4J8I+XMpu3B8But3HozpouU0FT8+0WyyMd2UY35f8qzL0gMQBPgTqFcNT/sC5NWN6yLnNyM30wSJ5DBPRgIzufun5EEL4mnEGm9nCOD8TExhu8n8GESnJN8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iXBc5aQhPwO/ZZFlHjE4zRxxwewyObNgXxO9ZCtBkk8=; b=HXLF06EiJHjAG/5YUEijMn2tAX6XgpeMjokF1ZVRkJiRsGYVdR2EsRf7Fh3297KxABdMD2kTnPblPWrydppLsyAQL/3/poKejGtiALez8A1yGUIacdt/iQbPLX+PpCIknqhuLCK0MqcHAeCT54XD3sl1FwTRKYMXcnN1WjJDpmu3OdvhbQhtxyDULDaFJ2RGJX3iyHYKUXt9ZEYIJRZEjCjxtP2e/AuZVUuJWwTWI5c967QR/SHFV1jO1sP4S1f9RcBQVF22YXg1PftOv0xedMdS77vyl6o1ps9r8uYKyGEZZPo5z4hgnhkHv8ifjoH4aFTeQM/mbBfAVeQKZEW5aQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=yale.edu; dmarc=pass action=none header.from=yale.edu; dkim=pass header.d=yale.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iXBc5aQhPwO/ZZFlHjE4zRxxwewyObNgXxO9ZCtBkk8=; b=npJ+KqFTkmr7SF8pmrMhkunFgVYP2qOBBtDh3fHMeq6wPpFENGv+qm8+v1ipXIBNZVPu1QWrKuQ0EObSpSBXIqu0Gtv3PcnufPGPeBSoBCjnTF+3688H9EUkHgYn5VOdFjst4XvFuaeCUWUWR/42QLk44NLRBLv7LITXWuRs978= Received: from MN2PR08MB6223.namprd08.prod.outlook.com (2603:10b6:208:1a1::21) by MN2PR08MB6208.namprd08.prod.outlook.com (2603:10b6:208:1a7::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.28; Mon, 6 Jul 2020 15:40:56 +0000 Received: from MN2PR08MB6223.namprd08.prod.outlook.com ([fe80::ecc3:9854:f30f:fc9]) by MN2PR08MB6223.namprd08.prod.outlook.com ([fe80::ecc3:9854:f30f:fc9%3]) with mapi id 15.20.3153.029; Mon, 6 Jul 2020 15:40:56 +0000 From: "Massameno, Dan" To: "opsawg@ietf.org" CC: "warren@kumari.net" , Benjamin Kaduk , Roman Danyliw , "Rob Wilton (rwilton)" , Stefan Winter , "Joe Clarke (jclarke)" , OpsAWG-Chairs , "radext-chairs@ietf.org" , "radext@ietf.org" Thread-Topic: RADIUS Extension, Getting Started Thread-Index: AdZEnvKQAaU5dfBlRUu7icTII+cjdABGQyjQABvIqNAAA7YgEABP5jcAAFBdPqAACl9JAACH358gAPvKPlAAALjLgACC/lEAAKs6acA= Date: Mon, 6 Jul 2020 15:40:56 +0000 Message-ID: References: <2064d9a1a5d54aa1899664f1f55d59aa@cert.org> <20200621024216.GF11992@kduck.mit.edu> <87adbd01-a100-7192-5b0d-fdc180ac2f5d@restena.lu> In-Reply-To: <87adbd01-a100-7192-5b0d-fdc180ac2f5d@restena.lu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=yale.edu; x-originating-ip: [107.3.32.193] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ec62fc57-4c66-4bc3-a10e-08d821c2f9a1 x-ms-traffictypediagnostic: MN2PR08MB6208: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04569283F9 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kf1b5s/TBbWGdQYYEkCzSx8YpTHv4EoX6iz/MPFbYZ7fb6WqrwkeaMlJsJlYVCLRnM9pYrdLPKR38Khr/Y0dlnx53hRieb7roN5Jo0lvS+KYwHYKpwfZZessoM6Mz3XTRtiwqaprUKNDuOvAaTIoohMg+oCJ6z3oGPYj7wjNtnXLajDC16oSWlTsBcJ14ZLcHbi2lqttSSYTryXXjsNodEXav7qw8hvSksqhRKmlntcz6tFL5ndoFQotqtuqFC0yB543Xj+gcyVzY0R5EzZDxBYo7qNolhwtmWR0VFdZdxLitW2bwjZb7+O6fpdD3/8EcAydDRGFcybS6u3V0xBDWjkg8W67enyoAu5POT1QRQLvh0FusblP+yN5340tbjVGwII+91BxrUf1XaUWnWCnwA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR08MB6223.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(396003)(346002)(39860400002)(136003)(4326008)(86362001)(71200400001)(5660300002)(83080400001)(83380400001)(33656002)(7696005)(9686003)(7416002)(55016002)(26005)(186003)(2906002)(53546011)(6506007)(8936002)(8676002)(478600001)(6916009)(54906003)(75432002)(66476007)(316002)(786003)(52536014)(66574015)(66946007)(45080400002)(66446008)(64756008)(76116006)(966005)(66556008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: alu51uoCQPH+RJ3VmCCNvFpBIpDorTSBoEI5+2UXDaKvSll/FSRpvExkvj5JFB4ED1r9IJzQqrH6PeNeXp7i/UZ+9Seqwuo4Tgid3oUZoYJ3zCWEBbhlTkixP1RNcUZd30IkUNeef5lJLwoTUwYJQi8QyTxb7z8PeMKxKVyPeNnQvJhOdtk9RdCoulLwa8esHSIdlbDsDZcae+JcnvlN/J9xkgFzGD5KQq+xYTkYuyR/3+wMsRyAUR8aU/uTzYXQmorixXr5a1FlANVptG2sWfJXnLRyIgNwXyE228leIY6iSZnaQOHcLrizhFD/Ta3xQN81t4a//KzFF4AAiKg+qjyOMbpra9C1rk/Qo6s0KaJEPKcft74kHzqwOmEiGOgd/ixsgnp7kT4d0m36rNNFSQNAV82uISbdvGig8xZr742NI440lKF38W75mjkLJ4R4CqgeGjgVUMyJ8VDNXXtARopXrFqflg6O2QYXxPWgh0g= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: yale.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR08MB6223.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec62fc57-4c66-4bc3-a10e-08d821c2f9a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2020 15:40:56.7291 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: dd8cbebb-2139-4df8-b411-4e3e87abeb5c X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VCxi7RR8Rh6ebksCMMqJyG2k/qpGAjFZoS3O0640Yyw8crjN0MypGKWSithwaE6tE9l/GOGMF0ut20xNxAMzog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR08MB6208 Archived-At: X-Mailman-Approved-At: Tue, 07 Jul 2020 02:13:44 -0700 Subject: Re: [radext] RADIUS Extension, Getting Started X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jul 2020 15:41:05 -0000 RGVhciBPcHMgYW5kIE1hbmFnZW1lbnQgQXJlYSBXRywNCg0KVGhlcmUgaGF2ZSBiZWVuIGEgbnVt YmVyIG9mIGdyZWF0IHN1Z2dlc3Rpb25zIG9uIHdoZXJlIHRvIHBvc3QgdGhpcyBkb2N1bWVudCAo VGhhbmtzIFN0ZWZhbiEpLiAgIEknbSBub3cgZW1haWxpbmcgb3BzYXdnQGlldGYub3JnIGFuZCBj YydpbmcgcmFkZXh0QGlldGYub3JnLiAgDQoNClRoZSBkcmFmdCBpcyBwb3N0ZWQgaGVyZS4uLiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFzc2FtZW5vLXJhZGl1cy1sYi0wMA0K DQpEbyBJIG5lZWQgYW4gb2ZmaWNpYWwgSUVURiBzcG9uc29yPyAgV291bGQgaXQgaGVscCB0byB0 cnkgYW5kIGdldCBhIHZlbmRvciBpbnRlcmVzdGVkIGluIGltcGxlbWVudGluZyB0aGUgcHJvdG9j b2w/ICBDaXNjbyBpcyBvdXIgcHJpbWFyeSB2ZW5kb3IgYXQgWWFsZSBVbml2ZXJzaXR5LiAgSSB3 YXMgd29uZGVyaW5nIGlmIHRoZXJlIGlzIGFueW9uZSBvbiBlaXRoZXIgb2YgdGhlc2Ugd29ya2lu ZyBncm91cHMgdGhhdCBjb21tdW5pY2F0ZXMgd2l0aCBDaXNjbyBwZW9wbGUgb24gYSByZWd1bGFy IGJhc2lzPw0KDQpUaGFuayB5b3UgZm9yIHlvdXIgaGVscC4NCg0KLS1EYW4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZWZhbiBXaW50ZXIgPHN0ZWZhbi53aW50ZXJAcmVz dGVuYS5sdT4gDQpTZW50OiBGcmlkYXksIEp1bHkgMywgMjAyMCAwMTo1Mg0KVG86IEpvZSBDbGFy a2UgKGpjbGFya2UpIDxqY2xhcmtlQGNpc2NvLmNvbT47IE1hc3NhbWVubywgRGFuIDxkYW4ubWFz c2FtZW5vQHlhbGUuZWR1Pg0KQ2M6IHdhcnJlbkBrdW1hcmkubmV0OyBCZW5qYW1pbiBLYWR1ayA8 a2FkdWtAbWl0LmVkdT47IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47IFJvYiBXaWx0b24g KHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47IE9wc0FXRy1DaGFpcnMgPG9wc2F3Zy1jaGFp cnNAaWV0Zi5vcmc+OyByYWRleHQtY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogUkFESVVT IEV4dGVuc2lvbiwgR2V0dGluZyBTdGFydGVkDQoNCkhlbGxvIEpvZSwNCg0KDQp0aGFua3MgZm9y IHJlYWNoaW5nIG91dC4gUkFERVhUIGlzIGRvcm1hbnQgc2luY2UgYSBudW1iZXIgb2YgeWVhcnMg YWxyZWFkeS4gSSdtIGFmcmFpZCBpZiB5b3Ugd2VyZSB0byBzZW5kIHRoZSBkb2N1bWVudCB0aGF0 IHdheSwgeW91IHdvdWxkIGdldCBsaXR0bGUgdG8gbm8gcmV2aWV3Lg0KDQoNCkkgdGhpbmsgdGhl IGJlc3Qgd2F5IGZvcndhcmQgaXMgdG8gdGFrZSB0aGlzIHRvIE9QU0FXRyBhbmQgc2VuZCBhIG1h aWwgdG8gcmFkZXh0IGFib3V0IHRoZSBkcmFmdCBqdXN0IGluIGNhc2UuDQoNCg0KR3JlZXRpbmdz LA0KDQoNClN0ZWZhbiBXaW50ZXINCg0KDQpBbSAzMC4wNi4yMCB1bSAxNzoyMSBzY2hyaWViIEpv ZSBDbGFya2UgKGpjbGFya2UpOg0KPiBUaGFua3MsIERhbi4gIEnigJltIGFsc28gY29weWluZyB0 aGUgcmFkZXh0LWNoYWlycyB0byBnZXQgdGhlaXIgcGVyc3BlY3RpdmUgb24gdGhpcy4NCj4NCj4g Sm9lDQo+DQo+PiBPbiBKdW4gMzAsIDIwMjAsIGF0IDExOjAzLCBNYXNzYW1lbm8sIERhbiA8ZGFu Lm1hc3NhbWVub0B5YWxlLmVkdT4gd3JvdGU6DQo+Pg0KPj4gV2FycmVuLA0KPj4NCj4+IEkgaGF2 ZSB0aGUgUkFESVVTIGV4dGVuc2lvbiBkcmFmdCBub3cgcG9zdGVkOg0KPj4gaHR0cHM6Ly9uYW0w NS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9v DQo+PiBscy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1tYXNzYW1lbm8tcmFkaXVzLWxiLTAwJmFt cDtkYXRhPTAyJTdDMDElN0MNCj4+IGRhbi5tYXNzYW1lbm8lNDB5YWxlLmVkdSU3Q2MwYjNjMDFh M2E5ZDQ0ZDAwNGMzMDhkODFmMTUyZWYyJTdDZGQ4Y2JlYg0KPj4gYjIxMzk0ZGY4YjQxMTRlM2U4 N2FiZWI1YyU3QzAlN0MwJTdDNjM3MjkzNTIzMTM5MzkyMzQxJmFtcDtzZGF0YT03ZE9wDQo+PiBa bVU1WHNqMnR1c2YyRml1a3F2MW94ZDJiOHVMNFBvJTJCSTA0aHclMkJFJTNEJmFtcDtyZXNlcnZl ZD0wDQo+Pg0KPj4gQWJzdHJhY3QNCj4+DQo+PiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEg bWV0aG9kIGZvciBhIE5ldHdvcmsgQWNjZXNzIFNlcnZlciAoTkFTKSB0bw0KPj4gICBkeW5hbWlj YWxseSBkaXNjb3ZlciBhbGwgYXZhaWxhYmxlIFJBRElVUyBzZXJ2ZXJzLiAgSXQgZGVmaW5lcyBh IG5ldw0KPj4gICBtZXNzYWdlIHR5cGUgd2l0aGluIHRoZSBTVEFUVVMtU0VSVkVSIG1lc3NhZ2Us IHdoaWNoIGlzIHJlcXVlc3RlZCBieQ0KPj4gICB0aGUgTkFTIGFuZCBwcm92aWRlZCBieSB0aGUg UkFESVVTIHNlcnZlci4gIFRoZSBOQVMgaXMgdGhlbiBhYmxlIHRvDQo+PiAgIGxvYWQgYmFsYW5j ZSBpdHMgUkFESVVTIG1lc3NhZ2VzIGFjcm9zcyBtdWx0aXBsZSBSQURJVVMgc2VydmVycyBiYXNl ZA0KPj4gICBvbiBwcmlvcml0eSBhbmQgd2VpZ2h0IHN1cHBsaWVkIGJ5IHRoZSBpbml0aWFsIHNl cnZlci4NCj4+DQo+PiBCYXNlIG9uIHRoZSBkcmFmdCBkbyB5b3UgaGF2ZSBhIGJldHRlciBpZGVh IG9uIGlmIHRoaXMgc2hvdWxkIGJlIHBvc2VkIGludG8gUkFERVhUIG9yIE9QU0FXRz8gIEkgbXVz dCBhZG1pdCBJIGFtIG5vdCBmYW1pbGlhciB3aXRoIGVpdGhlciBvZiB0aGVzZSBncm91cHMuDQo+ Pg0KPj4gVGhhbmsgeW91IGZvciB5b3VyIGhlbHAuDQo+Pg0KPj4gLS1EYW4NCj4+DQo+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogTWFzc2FtZW5vLCBEYW4NCj4+IFNlbnQ6 IFRodXJzZGF5LCBKdW5lIDI1LCAyMDIwIDEwOjU2DQo+PiBUbzogUm9iIFdpbHRvbiAocndpbHRv bikgPHJ3aWx0b25AY2lzY28uY29tPg0KPj4gQ2M6IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQu ZWR1PjsgUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPjsgDQo+PiBPcHNBV0ctQ2hhaXJzIDxv cHNhd2ctY2hhaXJzQGlldGYub3JnPjsgV2FycmVuIEt1bWFyaSANCj4+IDx3YXJyZW5Aa3VtYXJp Lm5ldD4NCj4+IFN1YmplY3Q6IFJFOiBSQURJVVMgRXh0ZW5zaW9uLCBHZXR0aW5nIFN0YXJ0ZWQN Cj4+DQo+PiBSb2IsDQo+PiBUaGFuayB5b3UgYW5kIHRoZSBleHRlbmRlZCB0ZWFtIGZvciBhbGwg eW91ciBoZWxwLiAgSSBoYXZlIHVwbG9hZGVkIGRyYWZ0LW1hc3NhbWVuby1yYWRpdXMtbGIgdG8g dGhlIEktRCBTdWJtaXNzaW9uIHN5c3RlbS4gIEFsc28gYXR0YWNoZWQgaXMgdGhlIFBERiB2ZXJz aW9uLg0KPj4NCj4+IEknbSB2ZXJ5IG11Y2ggaW50ZXJlc3RlZCBpbiBzZWVpbmcgaG93IHRoZSBw cm9jZXNzIGdvZXMgZnJvbSBoZXJlLiAgUGxlYXNlIGxldCBtZSBrbm93IGhvdyBJIG1heSBiZSBv ZiBhc3Npc3RhbmNlLg0KPj4NCj4+IC0tRGFuDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+IEZyb206IFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmkubmV0Pg0KPj4gU2Vu dDogTW9uZGF5LCBKdW5lIDIyLCAyMDIwIDE4OjAwDQo+PiBUbzogUm9iIFdpbHRvbiAocndpbHRv bikgPHJ3aWx0b25AY2lzY28uY29tPg0KPj4gQ2M6IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQu ZWR1PjsgTWFzc2FtZW5vLCBEYW4gDQo+PiA8ZGFuLm1hc3NhbWVub0B5YWxlLmVkdT47IFJvbWFu IERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47IE9wc0FXRy1DaGFpcnMgDQo+PiA8b3BzYXdnLWNoYWly c0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBSQURJVVMgRXh0ZW5zaW9uLCBHZXR0aW5nIFN0 YXJ0ZWQNCj4+DQo+PiBPbiBNb24sIEp1biAyMiwgMjAyMCBhdCAxOjA2IFBNIFJvYiBXaWx0b24g KHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4gSGkgQmVuLA0KPj4+DQo+ Pj4gR29vZCBjYXRjaCByZSBSYWRleHQsIGNvcHlpbmcgV2FycmVuLiAgV2FycmVuLCB0aGUgcXVl c3Rpb24gaXMgd2hldGhlciBSQURFWFQgaXMgc3RpbGwgYWN0aXZlIGFuZCB0YWtpbmcgbmV3IHdv cmssIG9yIHdoZXRoZXIgaXQgc2hvdWxkIGdvIHRvIE9QU0FXRyBpbnN0ZWFkPyAgSSBoYXZlIGEg c2xpZ2h0IGNvbmNlcm4gd2hldGhlciB3ZSB3aWxsIGdldCBlbm91Z2ggaW50ZXJlc3QgZm9yIHRo aXMgd29yayBpbiBPUFNBV0cgLi4uDQo+PiBXaXRob3V0IGtub3dpbmcgYSBidW5jaCBtb3JlIGFi b3V0IHRoZSBkcmFmdCBJIGRvbid0IHJlYWxseSB0aGluayB0aGF0IHRoaXMgaXMgYSBxdWVzdGlv biB0aGF0IEkgY2FuIHVzZWZ1bGx5IHdlaWdoIGluIG9uLg0KPj4NCj4+IElmIGl0IGlzIGFuIGV4 dGVuc2lvbiB0byBSQURJVVMvaXMgaGVhdmlseSBSQURJVVMgZm9jdXNlZCwgdGhlbiBSQURFWFQg aXMgcHJvYmFibHkgdGhlIHJpZ2h0IHBsYWNlIC0tIGJ1dCwgaXQgY291bGQgYWx3YXlzIGJlIGFp bWVkIGF0IFJBREVYVCAocHV0IC1yYWRleHQtIGluIHRoZSBkcmFmdCBuYW1lKSwgYnV0IHdlIGNh biB0cnkgYW5kIHN0aXIgdXAgc29tZSBpbnRlcmVzdCBpbiBPUFNBV0cuIElmIGl0IHR1cm5zIG91 dCB0aGF0IGl0IGlzIFJBRElVUyByZWxhdGVkLCBhbmQgUkFERVhUIGRvZXNuJ3Qgd2FudCB0byBw aWNrIGl0IHVwIGFuZCBydW4gd2l0aCBpdCwgcGVyaGFwcyB0aGF0J3MgYSBzdHJvbmcgc2lnbmFs IHRoYXQgUkFERVhUIHNob3VsZCBiZSBjbG9zZWQuLi4/DQo+Pg0KPj4gVw0KPj4NCj4+PiBSZWdh cmRzLA0KPj4+IFJvYg0KPj4+DQo+Pj4NCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+Pj4gRnJvbTogQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+DQo+Pj4+IFNlbnQ6IDIx IEp1bmUgMjAyMCAwMzo0Mg0KPj4+PiBUbzogTWFzc2FtZW5vLCBEYW4gPGRhbi5tYXNzYW1lbm9A eWFsZS5lZHU+DQo+Pj4+IENjOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5j b20+OyBSb21hbiBEYW55bGl3IA0KPj4+PiA8cmRkQGNlcnQub3JnPjsgT3BzQVdHLUNoYWlycyA8 b3BzYXdnLWNoYWlyc0BpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUmU6IFJBRElVUyBFeHRlbnNp b24sIEdldHRpbmcgU3RhcnRlZA0KPj4+Pg0KPj4+PiBPbiBGcmksIEp1biAxOSwgMjAyMCBhdCAx Mjo1ODoxMlBNICswMDAwLCBNYXNzYW1lbm8sIERhbiB3cm90ZToNCj4+Pj4+IFJvYiwNCj4+Pj4+ IFRoaXMgc291bmRzIGdyZWF0LiAgV2l0aCB0aGUgbGlua3MgcHJvdmlkZWQgYnkgUm9tYW4gSSBh bSANCj4+Pj4+IHJldmlld2luZyB0aGUNCj4+Pj4gbGl0ZXJhdHVyZSB0byBtYWtlIHN1cmUgbXkg ZHJhZnQgaGFzIGV2ZXJ5dGhpbmcgaXQgbmVlZHMgdG8gc3RhcnQgDQo+Pj4+IHRoZSBwcm9jZXNz LiAgSSBmb3VuZCByZWZlcmVuY2VzIHRvIHhtbDJyZmMgYW5kIGtyYW1kb3duLCB3aGljaCBJIA0K Pj4+PiBhbHNvIHdhbnQgdG8gcnVuIGl0IHRocm91Z2guDQo+Pj4+PiBUaGFuayB5b3UgZm9yIHlv dXIgaGVscC4gIEkgd291bGQgYmUgaGFwcHkgdG8gaGF2ZSBzb21lb25lIHRha2UgYSANCj4+Pj4+ IGxvb2sNCj4+Pj4gYmVmb3JlIGl0J3MgcG9zdGVkLiAgQXMgc29vbiBhcyBJIGhhdmUgaXQgZm9y bWF0dGVkIGNvcnJlY3RseSBJJ2xsIA0KPj4+PiBzZW5kIGl0IG92ZXIuICBJcyB0aGVyZSBzb21l b25lIGluIHBhcnRpY3VsYXIgSSBzaG91bGQgc2VuZCBpdCB0bz8NCj4+Pj4NCj4+Pj4gSSB3b3Vs ZCByZWNvbW1lbmQgdXBsb2FkaW5nIHRoZSBpbnRlcm5ldC1kcmFmdCB0byB0aGUgSUVURiANCj4+ Pj4gZGF0YXRyYWNrZXIgYXQgDQo+Pj4+IGh0dHBzOi8vbmFtMDUuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmQNCj4+Pj4gYSANCj4+Pj4gdGF0cmFj a2VyLmlldGYub3JnJTJGc3VibWl0JTJGJmFtcDtkYXRhPTAyJTdDMDElN0NkYW4ubWFzc2FtZW5v JTQweQ0KPj4+PiBhIA0KPj4+PiBsZS5lZHUlN0MxMTJjYWNjNmRhNmE0MGU2NTYwNzA4ZDgxNmY3 YzBiOSU3Q2RkOGNiZWJiMjEzOTRkZjhiNDExNGUzDQo+Pj4+IGUNCj4+Pj4gODdhYmViNWMlN0Mw JTdDMCU3QzYzNzI4NDYwMDYzNzMxMzI0OSZhbXA7c2RhdGE9RWtrU3dIQUIlMkJBVjNYUUR6JTJG c1lKTXNCTGlLeW16Nm40QlJPVldHYmc3WWclM0QmYW1wO3Jlc2VydmVkPTAgYW5kIHRoZW4gc2Vu ZGluZyBhIGxpbmsgdG8gdGhhdCBkb2N1bWVudCB0byBib3RoIG9wc2F3Zy1jaGFpcnNAaWV0Zi5v cmcgYW5kIHJhZGV4dC1jaGFpcnNAaWV0Zi5vcmcuICBJdCdzIGFsc28gb2theSB0byBza2lwIHRo ZSBmaXJzdCBwYXJ0IGFuZCBzZW5kIHRoZSBkb2N1bWVudCBpdHNlbGYgdG8gdGhvc2UgYWRkcmVz c2VzLg0KPj4+Pg0KPj4+PiBUaGUgcmFkZXh0IChSQURJVVMgRXh0ZW5zaW9ucykgd29ya2luZyBn cm91cCBpcyBub3QgdmVyeSBhY3RpdmUgYXQgDQo+Pj4+IHRoZSBtb21lbnQsIHdoaWNoIGlzIHdo eSBJIGFncmVlIHdpdGggdGhlIG90aGVycycgcmVjb21tZW5kYXRpb25zIA0KPj4+PiB0byBhc2sg dGhlIE9QU0FXRyB3b3JraW5nIGdyb3VwIGNoYWlycycgYWR2aWNlIGFzIHdlbGwuDQo+Pj4+DQo+ Pj4+IEhvcGUgdGhpcyBoZWxwcywNCj4+Pj4NCj4+Pj4gQmVuDQo+Pg0KPj4NCj4+IC0tDQo+PiBJ IGRvbid0IHRoaW5rIHRoZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2aW91 c2x5IGEgYmFkIGlkZWEgaW4gdGhlIGZpcnN0IHBsYWNlLg0KPj4gVGhpcyBpcyBsaWtlIHB1dHRp bmcgcmFiaWQgd2Vhc2VscyBpbiB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZyByZWdy ZXQgYXQgaGF2aW5nIGNob3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRo YXQgcGFpciBvZiBwYW50cy4NCj4+ICAgLS0tbWFmDQo= From nobody Thu Jul 9 01:46:33 2020 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 BE9C13A0CA3; Tue, 7 Jul 2020 06:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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=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 qVqE-MemChOc; Tue, 7 Jul 2020 06:35:43 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 496323A0C7F; Tue, 7 Jul 2020 06:35:43 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id 5so32288472oty.11; Tue, 07 Jul 2020 06:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wkTAxW3THElWTdhNppRGk5mqpoRtmBik7EYp9YdSSL0=; b=UTlevLTkW6i1Cg9KusGiR9DpEqAkbZNvxXQAF5Gu5SI3TDK+mMbUmS3hRkj6BzdUe/ iHdPD+DeSl/z0PVoSiVWC9FqfNEXKTOE/xjrrV/cbIRMHRvtSy9+kJD0D/Oo7nwlI52A oh2rb+uulcHM/rt8rebIxhnstd3RMXv8zNW2E1avIta6apxw+BP9Mr8Uj3WlvmehCxf+ FXWeURYPgqx9bKpSlUjxF4Y4oJy6x4PQwigH70a9CYnlr93tt8WmwOdUAHEo6em3KxJV zo0ftFM0WetPJNXpOsGJ1Jl1/75sZDkGvxbJHz2DdztEoldYdLaMPywmVmOSIs8BizmN B9FA== 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:cc:content-transfer-encoding; bh=wkTAxW3THElWTdhNppRGk5mqpoRtmBik7EYp9YdSSL0=; b=NxLnTbBRJoYnxrzpxkfOr5t1cjiRRVONNqlFXsRVfR+mr13LiyoTj8Rw/VP1t/PXrA ZAuAYrHAzPQizcn6rlzRv8rTOtz9Px11OJI8XJXht/899jkxfLgKFELl5zsuWHZj9X1k memHNGgE/Bbp1tbI3RFvzHG7M9goCTYd2oNjZhkQFS8l9K8JQBertEzTAOvD+tGD9ksf VNsqGpEpFGeNrUfVBOMsnINij/lFohgj02dt/o0cGN03NtitK/O+xvvbicBOrq8RSMBL aihDrBGxuHptjXCsP141crbT7jMfS2y+RQkG4tNIshQtQwuY/U79JKCfDhSnLMlfQa5I A2Ww== X-Gm-Message-State: AOAM531U59R/jHy28hUoXpCQgsKDm6x3Iln40TDlwTdcJcIFjIdRIASb oDP4Ob5QjAC6MADlCo36Tn+/U0GEg/edLH4mpxU= X-Google-Smtp-Source: ABdhPJxhnafwqS0dieQNNKBvEMuqoyC6qCtO1xDhfmBF7aKKIe8DzVem1vTDAB4VfBk9s6qunx8IezvQ9HzOEMcXZdc= X-Received: by 2002:a05:6830:204d:: with SMTP id f13mr17278351otp.341.1594128942363; Tue, 07 Jul 2020 06:35:42 -0700 (PDT) MIME-Version: 1.0 References: <2064d9a1a5d54aa1899664f1f55d59aa@cert.org> <20200621024216.GF11992@kduck.mit.edu> <87adbd01-a100-7192-5b0d-fdc180ac2f5d@restena.lu> In-Reply-To: From: Oleg Pekar Date: Tue, 7 Jul 2020 16:35:30 +0300 Message-ID: To: "Massameno, Dan" Cc: "opsawg@ietf.org" , Roman Danyliw , "radext@ietf.org" , "Rob Wilton (rwilton)" , Stefan Winter , "Joe Clarke (jclarke)" , OpsAWG-Chairs , Benjamin Kaduk , "warren@kumari.net" , "radext-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Thu, 09 Jul 2020 01:46:32 -0700 Subject: Re: [radext] RADIUS Extension, Getting Started X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 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, 07 Jul 2020 13:35:46 -0000 Hi Dan, So the draft describes how a NAS connected to a specific RADIUS server can obtain from that server information about other RADIUS servers on the deployment, together with their priorities. Usually the RADIUS traffic distribution is configured and conducted by a Load Balancer network component (e.g. F5 Load Balancer). The mechanism described in this draft allows RADIUS servers on the deployment to balance traffic between them dynamically according to their load or other characteristics. However it requires implementation on both sides - on NAS and RADIUS server. Is my understanding correct? Thanks Oleg On Tue, Jul 7, 2020 at 12:13 PM Massameno, Dan wro= te: > > Dear Ops and Management Area WG, > > There have been a number of great suggestions on where to post this docum= ent (Thanks Stefan!). I'm now emailing opsawg@ietf.org and cc'ing radext@= ietf.org. > > The draft is posted here... https://tools.ietf.org/html/draft-massameno-r= adius-lb-00 > > Do I need an official IETF sponsor? Would it help to try and get a vendo= r interested in implementing the protocol? Cisco is our primary vendor at = Yale University. I was wondering if there is anyone on either of these wor= king groups that communicates with Cisco people on a regular basis? > > Thank you for your help. > > --Dan > > -----Original Message----- > From: Stefan Winter > Sent: Friday, July 3, 2020 01:52 > To: Joe Clarke (jclarke) ; Massameno, Dan > Cc: warren@kumari.net; Benjamin Kaduk ; Roman Danyliw ; Rob Wilton (rwilton) ; OpsAWG-Chairs ; radext-chairs@ietf.org > Subject: Re: RADIUS Extension, Getting Started > > Hello Joe, > > > thanks for reaching out. RADEXT is dormant since a number of years alread= y. I'm afraid if you were to send the document that way, you would get litt= le to no review. > > > I think the best way forward is to take this to OPSAWG and send a mail to= radext about the draft just in case. > > > Greetings, > > > Stefan Winter > > > Am 30.06.20 um 17:21 schrieb Joe Clarke (jclarke): > > Thanks, Dan. I=E2=80=99m also copying the radext-chairs to get their p= erspective on this. > > > > Joe > > > >> On Jun 30, 2020, at 11:03, Massameno, Dan wro= te: > >> > >> Warren, > >> > >> I have the RADIUS extension draft now posted: > >> https://nam05.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fto= o > >> ls.ietf.org%2Fhtml%2Fdraft-massameno-radius-lb-00&data=3D02%7C01%7= C > >> dan.massameno%40yale.edu%7Cc0b3c01a3a9d44d004c308d81f152ef2%7Cdd8cbeb > >> b21394df8b4114e3e87abeb5c%7C0%7C0%7C637293523139392341&sdata=3D7dO= p > >> ZmU5Xsj2tusf2Fiukqv1oxd2b8uL4Po%2BI04hw%2BE%3D&reserved=3D0 > >> > >> Abstract > >> > >> This document describes a method for a Network Access Server (NAS) t= o > >> dynamically discover all available RADIUS servers. It defines a new > >> message type within the STATUS-SERVER message, which is requested by > >> the NAS and provided by the RADIUS server. The NAS is then able to > >> load balance its RADIUS messages across multiple RADIUS servers base= d > >> on priority and weight supplied by the initial server. > >> > >> Base on the draft do you have a better idea on if this should be posed= into RADEXT or OPSAWG? I must admit I am not familiar with either of thes= e groups. > >> > >> Thank you for your help. > >> > >> --Dan > >> > >> -----Original Message----- > >> From: Massameno, Dan > >> Sent: Thursday, June 25, 2020 10:56 > >> To: Rob Wilton (rwilton) > >> Cc: Benjamin Kaduk ; Roman Danyliw ; > >> OpsAWG-Chairs ; Warren Kumari > >> > >> Subject: RE: RADIUS Extension, Getting Started > >> > >> Rob, > >> Thank you and the extended team for all your help. I have uploaded dr= aft-massameno-radius-lb to the I-D Submission system. Also attached is the= PDF version. > >> > >> I'm very much interested in seeing how the process goes from here. Pl= ease let me know how I may be of assistance. > >> > >> --Dan > >> > >> -----Original Message----- > >> From: Warren Kumari > >> Sent: Monday, June 22, 2020 18:00 > >> To: Rob Wilton (rwilton) > >> Cc: Benjamin Kaduk ; Massameno, Dan > >> ; Roman Danyliw ; OpsAWG-Chairs > >> > >> Subject: Re: RADIUS Extension, Getting Started > >> > >> On Mon, Jun 22, 2020 at 1:06 PM Rob Wilton (rwilton) wrote: > >>> Hi Ben, > >>> > >>> Good catch re Radext, copying Warren. Warren, the question is whethe= r RADEXT is still active and taking new work, or whether it should go to OP= SAWG instead? I have a slight concern whether we will get enough interest = for this work in OPSAWG ... > >> Without knowing a bunch more about the draft I don't really think that= this is a question that I can usefully weigh in on. > >> > >> If it is an extension to RADIUS/is heavily RADIUS focused, then RADEXT= is probably the right place -- but, it could always be aimed at RADEXT (pu= t -radext- in the draft name), but we can try and stir up some interest in = OPSAWG. If it turns out that it is RADIUS related, and RADEXT doesn't want = to pick it up and run with it, perhaps that's a strong signal that RADEXT s= hould be closed...? > >> > >> W > >> > >>> Regards, > >>> Rob > >>> > >>> > >>>> -----Original Message----- > >>>> From: Benjamin Kaduk > >>>> Sent: 21 June 2020 03:42 > >>>> To: Massameno, Dan > >>>> Cc: Rob Wilton (rwilton) ; Roman Danyliw > >>>> ; OpsAWG-Chairs > >>>> Subject: Re: RADIUS Extension, Getting Started > >>>> > >>>> On Fri, Jun 19, 2020 at 12:58:12PM +0000, Massameno, Dan wrote: > >>>>> Rob, > >>>>> This sounds great. With the links provided by Roman I am > >>>>> reviewing the > >>>> literature to make sure my draft has everything it needs to start > >>>> the process. I found references to xml2rfc and kramdown, which I > >>>> also want to run it through. > >>>>> Thank you for your help. I would be happy to have someone take a > >>>>> look > >>>> before it's posted. As soon as I have it formatted correctly I'll > >>>> send it over. Is there someone in particular I should send it to? > >>>> > >>>> I would recommend uploading the internet-draft to the IETF > >>>> datatracker at > >>>> https://nam05.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= d > >>>> a > >>>> tatracker.ietf.org%2Fsubmit%2F&data=3D02%7C01%7Cdan.massameno%40= y > >>>> a > >>>> le.edu%7C112cacc6da6a40e6560708d816f7c0b9%7Cdd8cbebb21394df8b4114e3 > >>>> e > >>>> 87abeb5c%7C0%7C0%7C637284600637313249&sdata=3DEkkSwHAB%2BAV3XQDz= %2FsYJMsBLiKymz6n4BROVWGbg7Yg%3D&reserved=3D0 and then sending a link t= o that document to both opsawg-chairs@ietf.org and radext-chairs@ietf.org. = It's also okay to skip the first part and send the document itself to thos= e addresses. > >>>> > >>>> The radext (RADIUS Extensions) working group is not very active at > >>>> the moment, which is why I agree with the others' recommendations > >>>> to ask the OPSAWG working group chairs' advice as well. > >>>> > >>>> Hope this helps, > >>>> > >>>> Ben > >> > >> > >> -- > >> I don't think the execution is relevant when it was obviously a bad id= ea in the first place. > >> This is like putting rabid weasels in your pants, and later expressing= regret at having chosen those particular rabid weasels and that pair of pa= nts. > >> ---maf > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Thu Jul 9 01:46:37 2020 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 DD9073A0B0B; Tue, 7 Jul 2020 14:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yale.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqYTogxYd8Ft; Tue, 7 Jul 2020 14:11:44 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2124.outbound.protection.outlook.com [40.107.236.124]) (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 BCB673A0AEC; Tue, 7 Jul 2020 14:11:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bRpvEHJVb+Q/1q26FsRp2rSDo1aSHlcveG4kGMPXWT3iNywMQhVrDsyAC19cv96uhJvDX02X56vmwCEAm8JSWtdSilqyBjnKET54DnUaDsesA0r0q5n/NKTVmE+QKNZ+LlGqTInbnfQrwkzM4GdbQW9U8W3B/6mgpqqzVr4IBjAG4w99+2Pyc/pk/yULCn2A6LPW/DVXv3YENSlH00JtMBP0plEX6IWVenMQ5U7TfoQNAH6uoF83Wf9hhrHPrz50Ql57nToG/KDQsYrB2sGpPOg2ZDlv5siCo4Rqw2svs89tchjQQpgnq7z1VOtQF6DaaGB4iJTyNIaSrl/sfHD/Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r1EB6Esm/UV7xvIDr4KJTukjULnnWSKiowYIFnWQtgg=; b=Plh5auNrJMYAyYkkevo4b1AFC55vgKtY8vw8zqtBhNKZiqcH0KUBuVeFEATtBlOzYDZYkOL5s8It6J7cVH1oUpOO0rThyN2kkuvOlM7T8fMRijf3Zqp5ZJPV9Ox8sG/afSXplPUJHNCW8tT3uXQxF349Q3pl1SGSqhGeteq7O6SP3WCAue7sz4lGIBoQ3WSDeQWcNQhq2/1w7IgjaoWI+spBKqPwrrpcsZUf2kiz2CrBYJy7iPf0JyFw0wvVkS1Hb5+uzy2T2BAvUW4pbiQZkF+bKzAYAKfeQs3sDfciNNrvZecNOohXJGoFW0UTduOwnNawbyxbNgrRGCLcKR0t6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=yale.edu; dmarc=pass action=none header.from=yale.edu; dkim=pass header.d=yale.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r1EB6Esm/UV7xvIDr4KJTukjULnnWSKiowYIFnWQtgg=; b=B+v8vizt4lPxALIVyZqb8lTy55sDiEVU8LjXUSHIYL2fwO/AEUTZkj99K3wBELLZjgZS9/UXw+gfDsqYJyTcOgfubKYMguNIeSRMI0yXCq077e7WATrcFk62j2X5x0QD7OMDC9IXb4ZZMSlzVAFvC1RXBQEsDeMyt6OxEqCpXFg= Received: from MN2PR08MB6223.namprd08.prod.outlook.com (2603:10b6:208:1a1::21) by BL0PR08MB5284.namprd08.prod.outlook.com (2603:10b6:208:53::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23; Tue, 7 Jul 2020 21:11:41 +0000 Received: from MN2PR08MB6223.namprd08.prod.outlook.com ([fe80::ecc3:9854:f30f:fc9]) by MN2PR08MB6223.namprd08.prod.outlook.com ([fe80::ecc3:9854:f30f:fc9%3]) with mapi id 15.20.3153.029; Tue, 7 Jul 2020 21:11:41 +0000 From: "Massameno, Dan" To: Oleg Pekar CC: "opsawg@ietf.org" , Roman Danyliw , "radext@ietf.org" , "Rob Wilton (rwilton)" , Stefan Winter , "Joe Clarke (jclarke)" , OpsAWG-Chairs , Benjamin Kaduk , "warren@kumari.net" , "radext-chairs@ietf.org" Thread-Topic: [radext] RADIUS Extension, Getting Started Thread-Index: AdZEnvKQAaU5dfBlRUu7icTII+cjdABGQyjQABvIqNAAA7YgEABP5jcAAFBdPqAACl9JAACH358gAPvKPlAAALjLgACC/lEAAKs6acAALiIaAAAPse2g Date: Tue, 7 Jul 2020 21:11:41 +0000 Message-ID: References: <2064d9a1a5d54aa1899664f1f55d59aa@cert.org> <20200621024216.GF11992@kduck.mit.edu> <87adbd01-a100-7192-5b0d-fdc180ac2f5d@restena.lu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=yale.edu; x-originating-ip: [2601:199:c200:bb23:9525:e174:163:111a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 43271799-92cc-4cdb-c836-08d822ba58a5 x-ms-traffictypediagnostic: BL0PR08MB5284: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0457F11EAF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: owtVhZxo7DppdeRao7SItZNs1/DlzLh5Du0VRZohY2vzg9Qb4vBOpihDR9pBo64/cMza3I+ekibULCNSUEToFVle7Slwuxi6ctkoZlZEqTbqQ8KufPGsWqROCRikAO58UgDDazgclO+f3jiDwxRwb/JghAgOBTNYYUOCtZGb56vLxQO2vD9JpQjpBtOCtB7Zex2Qpsx7MpZzvU1WhKDmUVEirxR1Pysj919FSptcwaqxOyNl2fGN+PdV7HU9kjxUgWuRp4sMBdvxd7pjCxM1YJS07UT8q7SVHCyTwZbza19GLXhK70i4F6UgXEvQCUa0ACbJznLDYJLl1zNphtM4V5o/q44OSr1Uo6vxzuCLOpyaxak8+v53QkWUeSEok5XnVeU4RRTR7xOHxVfnitGGyA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR08MB6223.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(346002)(376002)(396003)(136003)(53546011)(8936002)(2906002)(186003)(52536014)(8676002)(66574015)(76116006)(86362001)(786003)(7696005)(54906003)(66946007)(316002)(66446008)(33656002)(66556008)(6506007)(66476007)(64756008)(83080400001)(71200400001)(478600001)(55016002)(966005)(75432002)(9686003)(5660300002)(6916009)(7416002)(83380400001)(4326008)(45080400002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: NVyUbfgF+320KuNwKTnoweMoTqSBBB4riSgEPgnhxLjpYyB61IJy0cj5z8blbJndAJiLCV7EREl1VyeCjpHMXSrk+lkEPwDJeUKfNNjWHXVbx23SMOCB7E3Rk5Dye2JLf7305e5NZbdHxvZNzyIxL2xhedW/ePC2DygFDKQCYMZFf7WUdUynXdpacroEyRwlrS6o15rfGG4phpfa1PaEMdOH425t4aWpBpfww1ookQlIDufAw9ijoBgnvbgZsBpLHX/meCTEJL0QMzxjEBDV/Te7YRQvCo2K3HXjJjt17K1wpX2u8XXF2YIk91ZtiYQ+BvLuTP8op4G9YQdBdifOleGMRTu0KAPVIY4Jy6D8vE+wIAtqDayYAGXNzHiflvuxm1Bz64Xh9uyAptS9p0pzywW+rv0jJgQwXZY1a3w0vpruWfJ1Rs9R3Qm8GUpnQe6Heslor0aglsoeovuNJBThMdZGuQegb5+/0u6rcWfV07ZfsfajPfhT8y30GkjQogSgPzDUtgDMxYL8daUWjaDCc4dOQN3yDzu4x0SCyCX8gaRzIRCAYR6W3isosxImxx0/ x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: yale.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR08MB6223.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43271799-92cc-4cdb-c836-08d822ba58a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2020 21:11:41.8540 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: dd8cbebb-2139-4df8-b411-4e3e87abeb5c X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BkxF4VcOitiRso5f3oNTWzsXWft0qvC/c8ShKvIbjoEaIc77gz+MsqTBk6iYgtWo0zdUfBT78GY2pSKuYSfNig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR08MB5284 Archived-At: X-Mailman-Approved-At: Thu, 09 Jul 2020 01:46:32 -0700 Subject: Re: [radext] RADIUS Extension, Getting Started X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 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, 07 Jul 2020 21:11:54 -0000 T2xlZywNCllvdSBhcmUgY29ycmVjdC4gIFdoZW4gYSBwcm90b2NvbCAoc2VydmljZSkgd2FudHMg dG8gc2NhbGUgb3V0IEkgYmVsaWV2ZSB0aGUgbGVhc3QgZWZmZWN0aXZlIHdheSBpcyB0byB0aHJv dyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IGNvbXBvbmVudHMgKGxvYWQgYmFsYW5jZXJzKSBhdCB0 aGUgcHJvYmxlbSwgd2hpY2ggY3JlYXRlcyBhZGRpdGlvbmFsIGNvbXBvbmVudHMgdGhhdCBuZXR3 b3JrIG9wZXJhdG9ycyBuZWVkIHRvIG1haW50YWluLiANCg0KTG9hZCBiYWxhbmNpbmcgd2l0aCBE TlMgU1JWIHJlY29yZHMgb3IgKG9wdGltYWxseSkgbG9hZCBiYWxhbmNpbmcgcmlnaHQgd2l0aGlu IHRoZSBwcm90b2NvbCBzZWVtcyB0byBoYXZlIG11bHRpcGxlIG9wZXJhdGlvbmFsIGFkdmFudGFn ZXMuICBUaGlzIGRyYWZ0IHRha2VzIHRoZSBsYXR0ZXIgYXBwcm9hY2guDQoNCi0tRGFuDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPbGVnIFBla2FyIDxvbGVnLnBla2FyLjIw MTdAZ21haWwuY29tPiANClNlbnQ6IFR1ZXNkYXksIEp1bHkgNywgMjAyMCAwOTozNg0KVG86IE1h c3NhbWVubywgRGFuIDxkYW4ubWFzc2FtZW5vQHlhbGUuZWR1Pg0KQ2M6IG9wc2F3Z0BpZXRmLm9y ZzsgUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPjsgcmFkZXh0QGlldGYub3JnOyBSb2IgV2ls dG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+OyBTdGVmYW4gV2ludGVyIDxzdGVmYW4u d2ludGVyQHJlc3RlbmEubHU+OyBKb2UgQ2xhcmtlIChqY2xhcmtlKSA8amNsYXJrZUBjaXNjby5j b20+OyBPcHNBV0ctQ2hhaXJzIDxvcHNhd2ctY2hhaXJzQGlldGYub3JnPjsgQmVuamFtaW4gS2Fk dWsgPGthZHVrQG1pdC5lZHU+OyB3YXJyZW5Aa3VtYXJpLm5ldDsgcmFkZXh0LWNoYWlyc0BpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtyYWRleHRdIFJBRElVUyBFeHRlbnNpb24sIEdldHRpbmcgU3Rh cnRlZA0KDQpIaSBEYW4sDQpTbyB0aGUgZHJhZnQgZGVzY3JpYmVzIGhvdyBhIE5BUyBjb25uZWN0 ZWQgdG8gYSBzcGVjaWZpYyBSQURJVVMgc2VydmVyIGNhbiBvYnRhaW4gZnJvbSB0aGF0IHNlcnZl ciBpbmZvcm1hdGlvbiBhYm91dCBvdGhlciBSQURJVVMgc2VydmVycyBvbiB0aGUgZGVwbG95bWVu dCwgdG9nZXRoZXIgd2l0aCB0aGVpciBwcmlvcml0aWVzLiBVc3VhbGx5IHRoZSBSQURJVVMgdHJh ZmZpYyBkaXN0cmlidXRpb24gaXMgY29uZmlndXJlZCBhbmQgY29uZHVjdGVkIGJ5IGEgTG9hZCBC YWxhbmNlciBuZXR3b3JrIGNvbXBvbmVudCAoZS5nLiBGNSBMb2FkIEJhbGFuY2VyKS4gVGhlIG1l Y2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdCBhbGxvd3MgUkFESVVTIHNlcnZlcnMgb24g dGhlIGRlcGxveW1lbnQgdG8gYmFsYW5jZSB0cmFmZmljIGJldHdlZW4gdGhlbSBkeW5hbWljYWxs eSBhY2NvcmRpbmcgdG8gdGhlaXIgbG9hZCBvciBvdGhlciBjaGFyYWN0ZXJpc3RpY3MuIEhvd2V2 ZXIgaXQgcmVxdWlyZXMgaW1wbGVtZW50YXRpb24gb24gYm90aCBzaWRlcyAtIG9uIE5BUyBhbmQg UkFESVVTIHNlcnZlci4NCg0KSXMgbXkgdW5kZXJzdGFuZGluZyBjb3JyZWN0Pw0KDQpUaGFua3MN Ck9sZWcNCg0KT24gVHVlLCBKdWwgNywgMjAyMCBhdCAxMjoxMyBQTSBNYXNzYW1lbm8sIERhbiA8 ZGFuLm1hc3NhbWVub0B5YWxlLmVkdT4gd3JvdGU6DQo+DQo+IERlYXIgT3BzIGFuZCBNYW5hZ2Vt ZW50IEFyZWEgV0csDQo+DQo+IFRoZXJlIGhhdmUgYmVlbiBhIG51bWJlciBvZiBncmVhdCBzdWdn ZXN0aW9ucyBvbiB3aGVyZSB0byBwb3N0IHRoaXMgZG9jdW1lbnQgKFRoYW5rcyBTdGVmYW4hKS4g ICBJJ20gbm93IGVtYWlsaW5nIG9wc2F3Z0BpZXRmLm9yZyBhbmQgY2MnaW5nIHJhZGV4dEBpZXRm Lm9yZy4NCj4NCj4gVGhlIGRyYWZ0IGlzIHBvc3RlZCBoZXJlLi4uIA0KPiBodHRwczovL25hbTA1 LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29s DQo+IHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtbWFzc2FtZW5vLXJhZGl1cy1sYi0wMCZhbXA7 ZGF0YT0wMiU3QzAxJTdDZGENCj4gbi5tYXNzYW1lbm8lNDB5YWxlLmVkdSU3QzM0ZTM0Y2ZhYzU3 MDRhOWM3NmM4MDhkODIyN2FhNjZjJTdDZGQ4Y2JlYmIyMQ0KPiAzOTRkZjhiNDExNGUzZTg3YWJl YjVjJTdDMCU3QzAlN0M2MzcyOTcyNTc0NjIwODc2NzMmYW1wO3NkYXRhPWdYdFFvbG9XDQo+IHF2 WHNqVGR3ayUyQiUyRnVCZTdXZnBOczRMWllCZUFwS1lOd3FqUSUzRCZhbXA7cmVzZXJ2ZWQ9MA0K Pg0KPiBEbyBJIG5lZWQgYW4gb2ZmaWNpYWwgSUVURiBzcG9uc29yPyAgV291bGQgaXQgaGVscCB0 byB0cnkgYW5kIGdldCBhIHZlbmRvciBpbnRlcmVzdGVkIGluIGltcGxlbWVudGluZyB0aGUgcHJv dG9jb2w/ICBDaXNjbyBpcyBvdXIgcHJpbWFyeSB2ZW5kb3IgYXQgWWFsZSBVbml2ZXJzaXR5LiAg SSB3YXMgd29uZGVyaW5nIGlmIHRoZXJlIGlzIGFueW9uZSBvbiBlaXRoZXIgb2YgdGhlc2Ugd29y a2luZyBncm91cHMgdGhhdCBjb21tdW5pY2F0ZXMgd2l0aCBDaXNjbyBwZW9wbGUgb24gYSByZWd1 bGFyIGJhc2lzPw0KPg0KPiBUaGFuayB5b3UgZm9yIHlvdXIgaGVscC4NCj4NCj4gLS1EYW4NCj4N Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3RlZmFuIFdpbnRlciA8c3Rl ZmFuLndpbnRlckByZXN0ZW5hLmx1Pg0KPiBTZW50OiBGcmlkYXksIEp1bHkgMywgMjAyMCAwMTo1 Mg0KPiBUbzogSm9lIENsYXJrZSAoamNsYXJrZSkgPGpjbGFya2VAY2lzY28uY29tPjsgTWFzc2Ft ZW5vLCBEYW4gDQo+IDxkYW4ubWFzc2FtZW5vQHlhbGUuZWR1Pg0KPiBDYzogd2FycmVuQGt1bWFy aS5uZXQ7IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PjsgUm9tYW4gRGFueWxpdyANCj4g PHJkZEBjZXJ0Lm9yZz47IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47 IA0KPiBPcHNBV0ctQ2hhaXJzIDxvcHNhd2ctY2hhaXJzQGlldGYub3JnPjsgcmFkZXh0LWNoYWly c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogUkFESVVTIEV4dGVuc2lvbiwgR2V0dGluZyBTdGFy dGVkDQo+DQo+IEhlbGxvIEpvZSwNCj4NCj4NCj4gdGhhbmtzIGZvciByZWFjaGluZyBvdXQuIFJB REVYVCBpcyBkb3JtYW50IHNpbmNlIGEgbnVtYmVyIG9mIHllYXJzIGFscmVhZHkuIEknbSBhZnJh aWQgaWYgeW91IHdlcmUgdG8gc2VuZCB0aGUgZG9jdW1lbnQgdGhhdCB3YXksIHlvdSB3b3VsZCBn ZXQgbGl0dGxlIHRvIG5vIHJldmlldy4NCj4NCj4NCj4gSSB0aGluayB0aGUgYmVzdCB3YXkgZm9y d2FyZCBpcyB0byB0YWtlIHRoaXMgdG8gT1BTQVdHIGFuZCBzZW5kIGEgbWFpbCB0byByYWRleHQg YWJvdXQgdGhlIGRyYWZ0IGp1c3QgaW4gY2FzZS4NCj4NCj4NCj4gR3JlZXRpbmdzLA0KPg0KPg0K PiBTdGVmYW4gV2ludGVyDQo+DQo+DQo+IEFtIDMwLjA2LjIwIHVtIDE3OjIxIHNjaHJpZWIgSm9l IENsYXJrZSAoamNsYXJrZSk6DQo+ID4gVGhhbmtzLCBEYW4uICBJ4oCZbSBhbHNvIGNvcHlpbmcg dGhlIHJhZGV4dC1jaGFpcnMgdG8gZ2V0IHRoZWlyIHBlcnNwZWN0aXZlIG9uIHRoaXMuDQo+ID4N Cj4gPiBKb2UNCj4gPg0KPiA+PiBPbiBKdW4gMzAsIDIwMjAsIGF0IDExOjAzLCBNYXNzYW1lbm8s IERhbiA8ZGFuLm1hc3NhbWVub0B5YWxlLmVkdT4gd3JvdGU6DQo+ID4+DQo+ID4+IFdhcnJlbiwN Cj4gPj4NCj4gPj4gSSBoYXZlIHRoZSBSQURJVVMgZXh0ZW5zaW9uIGRyYWZ0IG5vdyBwb3N0ZWQ6 DQo+ID4+IGh0dHBzOi8vbmFtMDUuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnQNCj4gPj4gb28gDQo+ID4+IGxzLmlldGYub3JnJTJGaHRtbCUyRmRy YWZ0LW1hc3NhbWVuby1yYWRpdXMtbGItMDAmYW1wO2RhdGE9MDIlN0MwMSUNCj4gPj4gN0MgDQo+ ID4+IGRhbi5tYXNzYW1lbm8lNDB5YWxlLmVkdSU3Q2MwYjNjMDFhM2E5ZDQ0ZDAwNGMzMDhkODFm MTUyZWYyJTdDZGQ4Y2INCj4gPj4gZWIgDQo+ID4+IGIyMTM5NGRmOGI0MTE0ZTNlODdhYmViNWMl N0MwJTdDMCU3QzYzNzI5MzUyMzEzOTM5MjM0MSZhbXA7c2RhdGE9N2QNCj4gPj4gT3ANCj4gPj4g Wm1VNVhzajJ0dXNmMkZpdWtxdjFveGQyYjh1TDRQbyUyQkkwNGh3JTJCRSUzRCZhbXA7cmVzZXJ2 ZWQ9MA0KPiA+Pg0KPiA+PiBBYnN0cmFjdA0KPiA+Pg0KPiA+PiAgIFRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIGEgbWV0aG9kIGZvciBhIE5ldHdvcmsgQWNjZXNzIFNlcnZlciAoTkFTKSB0bw0KPiA+ PiAgIGR5bmFtaWNhbGx5IGRpc2NvdmVyIGFsbCBhdmFpbGFibGUgUkFESVVTIHNlcnZlcnMuICBJ dCBkZWZpbmVzIGEgbmV3DQo+ID4+ICAgbWVzc2FnZSB0eXBlIHdpdGhpbiB0aGUgU1RBVFVTLVNF UlZFUiBtZXNzYWdlLCB3aGljaCBpcyByZXF1ZXN0ZWQgYnkNCj4gPj4gICB0aGUgTkFTIGFuZCBw cm92aWRlZCBieSB0aGUgUkFESVVTIHNlcnZlci4gIFRoZSBOQVMgaXMgdGhlbiBhYmxlIHRvDQo+ ID4+ICAgbG9hZCBiYWxhbmNlIGl0cyBSQURJVVMgbWVzc2FnZXMgYWNyb3NzIG11bHRpcGxlIFJB RElVUyBzZXJ2ZXJzIGJhc2VkDQo+ID4+ICAgb24gcHJpb3JpdHkgYW5kIHdlaWdodCBzdXBwbGll ZCBieSB0aGUgaW5pdGlhbCBzZXJ2ZXIuDQo+ID4+DQo+ID4+IEJhc2Ugb24gdGhlIGRyYWZ0IGRv IHlvdSBoYXZlIGEgYmV0dGVyIGlkZWEgb24gaWYgdGhpcyBzaG91bGQgYmUgcG9zZWQgaW50byBS QURFWFQgb3IgT1BTQVdHPyAgSSBtdXN0IGFkbWl0IEkgYW0gbm90IGZhbWlsaWFyIHdpdGggZWl0 aGVyIG9mIHRoZXNlIGdyb3Vwcy4NCj4gPj4NCj4gPj4gVGhhbmsgeW91IGZvciB5b3VyIGhlbHAu DQo+ID4+DQo+ID4+IC0tRGFuDQo+ID4+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+IEZyb206IE1hc3NhbWVubywgRGFuDQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDI1 LCAyMDIwIDEwOjU2DQo+ID4+IFRvOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNj by5jb20+DQo+ID4+IENjOiBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdT47IFJvbWFuIERh bnlsaXcgPHJkZEBjZXJ0Lm9yZz47IA0KPiA+PiBPcHNBV0ctQ2hhaXJzIDxvcHNhd2ctY2hhaXJz QGlldGYub3JnPjsgV2FycmVuIEt1bWFyaSANCj4gPj4gPHdhcnJlbkBrdW1hcmkubmV0Pg0KPiA+ PiBTdWJqZWN0OiBSRTogUkFESVVTIEV4dGVuc2lvbiwgR2V0dGluZyBTdGFydGVkDQo+ID4+DQo+ ID4+IFJvYiwNCj4gPj4gVGhhbmsgeW91IGFuZCB0aGUgZXh0ZW5kZWQgdGVhbSBmb3IgYWxsIHlv dXIgaGVscC4gIEkgaGF2ZSB1cGxvYWRlZCBkcmFmdC1tYXNzYW1lbm8tcmFkaXVzLWxiIHRvIHRo ZSBJLUQgU3VibWlzc2lvbiBzeXN0ZW0uICBBbHNvIGF0dGFjaGVkIGlzIHRoZSBQREYgdmVyc2lv bi4NCj4gPj4NCj4gPj4gSSdtIHZlcnkgbXVjaCBpbnRlcmVzdGVkIGluIHNlZWluZyBob3cgdGhl IHByb2Nlc3MgZ29lcyBmcm9tIGhlcmUuICBQbGVhc2UgbGV0IG1lIGtub3cgaG93IEkgbWF5IGJl IG9mIGFzc2lzdGFuY2UuDQo+ID4+DQo+ID4+IC0tRGFuDQo+ID4+DQo+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmku bmV0Pg0KPiA+PiBTZW50OiBNb25kYXksIEp1bmUgMjIsIDIwMjAgMTg6MDANCj4gPj4gVG86IFJv YiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT4NCj4gPj4gQ2M6IEJlbmphbWlu IEthZHVrIDxrYWR1a0BtaXQuZWR1PjsgTWFzc2FtZW5vLCBEYW4gDQo+ID4+IDxkYW4ubWFzc2Ft ZW5vQHlhbGUuZWR1PjsgUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPjsgDQo+ID4+IE9wc0FX Ry1DaGFpcnMgPG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc+DQo+ID4+IFN1YmplY3Q6IFJlOiBSQURJ VVMgRXh0ZW5zaW9uLCBHZXR0aW5nIFN0YXJ0ZWQNCj4gPj4NCj4gPj4gT24gTW9uLCBKdW4gMjIs IDIwMjAgYXQgMTowNiBQTSBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+ IHdyb3RlOg0KPiA+Pj4gSGkgQmVuLA0KPiA+Pj4NCj4gPj4+IEdvb2QgY2F0Y2ggcmUgUmFkZXh0 LCBjb3B5aW5nIFdhcnJlbi4gIFdhcnJlbiwgdGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgUkFERVhU IGlzIHN0aWxsIGFjdGl2ZSBhbmQgdGFraW5nIG5ldyB3b3JrLCBvciB3aGV0aGVyIGl0IHNob3Vs ZCBnbyB0byBPUFNBV0cgaW5zdGVhZD8gIEkgaGF2ZSBhIHNsaWdodCBjb25jZXJuIHdoZXRoZXIg d2Ugd2lsbCBnZXQgZW5vdWdoIGludGVyZXN0IGZvciB0aGlzIHdvcmsgaW4gT1BTQVdHIC4uLg0K PiA+PiBXaXRob3V0IGtub3dpbmcgYSBidW5jaCBtb3JlIGFib3V0IHRoZSBkcmFmdCBJIGRvbid0 IHJlYWxseSB0aGluayB0aGF0IHRoaXMgaXMgYSBxdWVzdGlvbiB0aGF0IEkgY2FuIHVzZWZ1bGx5 IHdlaWdoIGluIG9uLg0KPiA+Pg0KPiA+PiBJZiBpdCBpcyBhbiBleHRlbnNpb24gdG8gUkFESVVT L2lzIGhlYXZpbHkgUkFESVVTIGZvY3VzZWQsIHRoZW4gUkFERVhUIGlzIHByb2JhYmx5IHRoZSBy aWdodCBwbGFjZSAtLSBidXQsIGl0IGNvdWxkIGFsd2F5cyBiZSBhaW1lZCBhdCBSQURFWFQgKHB1 dCAtcmFkZXh0LSBpbiB0aGUgZHJhZnQgbmFtZSksIGJ1dCB3ZSBjYW4gdHJ5IGFuZCBzdGlyIHVw IHNvbWUgaW50ZXJlc3QgaW4gT1BTQVdHLiBJZiBpdCB0dXJucyBvdXQgdGhhdCBpdCBpcyBSQURJ VVMgcmVsYXRlZCwgYW5kIFJBREVYVCBkb2Vzbid0IHdhbnQgdG8gcGljayBpdCB1cCBhbmQgcnVu IHdpdGggaXQsIHBlcmhhcHMgdGhhdCdzIGEgc3Ryb25nIHNpZ25hbCB0aGF0IFJBREVYVCBzaG91 bGQgYmUgY2xvc2VkLi4uPw0KPiA+Pg0KPiA+PiBXDQo+ID4+DQo+ID4+PiBSZWdhcmRzLA0KPiA+ Pj4gUm9iDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+Pj4+IEZyb206IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1Pg0KPiA+Pj4+IFNlbnQ6 IDIxIEp1bmUgMjAyMCAwMzo0Mg0KPiA+Pj4+IFRvOiBNYXNzYW1lbm8sIERhbiA8ZGFuLm1hc3Nh bWVub0B5YWxlLmVkdT4NCj4gPj4+PiBDYzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25A Y2lzY28uY29tPjsgUm9tYW4gRGFueWxpdyANCj4gPj4+PiA8cmRkQGNlcnQub3JnPjsgT3BzQVdH LUNoYWlycyA8b3BzYXdnLWNoYWlyc0BpZXRmLm9yZz4NCj4gPj4+PiBTdWJqZWN0OiBSZTogUkFE SVVTIEV4dGVuc2lvbiwgR2V0dGluZyBTdGFydGVkDQo+ID4+Pj4NCj4gPj4+PiBPbiBGcmksIEp1 biAxOSwgMjAyMCBhdCAxMjo1ODoxMlBNICswMDAwLCBNYXNzYW1lbm8sIERhbiB3cm90ZToNCj4g Pj4+Pj4gUm9iLA0KPiA+Pj4+PiBUaGlzIHNvdW5kcyBncmVhdC4gIFdpdGggdGhlIGxpbmtzIHBy b3ZpZGVkIGJ5IFJvbWFuIEkgYW0gDQo+ID4+Pj4+IHJldmlld2luZyB0aGUNCj4gPj4+PiBsaXRl cmF0dXJlIHRvIG1ha2Ugc3VyZSBteSBkcmFmdCBoYXMgZXZlcnl0aGluZyBpdCBuZWVkcyB0byBz dGFydCANCj4gPj4+PiB0aGUgcHJvY2Vzcy4gIEkgZm91bmQgcmVmZXJlbmNlcyB0byB4bWwycmZj IGFuZCBrcmFtZG93biwgd2hpY2ggSSANCj4gPj4+PiBhbHNvIHdhbnQgdG8gcnVuIGl0IHRocm91 Z2guDQo+ID4+Pj4+IFRoYW5rIHlvdSBmb3IgeW91ciBoZWxwLiAgSSB3b3VsZCBiZSBoYXBweSB0 byBoYXZlIHNvbWVvbmUgdGFrZSANCj4gPj4+Pj4gYSBsb29rDQo+ID4+Pj4gYmVmb3JlIGl0J3Mg cG9zdGVkLiAgQXMgc29vbiBhcyBJIGhhdmUgaXQgZm9ybWF0dGVkIGNvcnJlY3RseSANCj4gPj4+ PiBJJ2xsIHNlbmQgaXQgb3Zlci4gIElzIHRoZXJlIHNvbWVvbmUgaW4gcGFydGljdWxhciBJIHNo b3VsZCBzZW5kIGl0IHRvPw0KPiA+Pj4+DQo+ID4+Pj4gSSB3b3VsZCByZWNvbW1lbmQgdXBsb2Fk aW5nIHRoZSBpbnRlcm5ldC1kcmFmdCB0byB0aGUgSUVURiANCj4gPj4+PiBkYXRhdHJhY2tlciBh dCANCj4gPj4+PiBodHRwczovL25hbTA1LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMg0KPiA+Pj4+IEZkDQo+ID4+Pj4gYQ0KPiA+Pj4+IHRhdHJhY2tl ci5pZXRmLm9yZyUyRnN1Ym1pdCUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdDZGFuLm1hc3NhbWVubyU0 DQo+ID4+Pj4gMHkNCj4gPj4+PiBhDQo+ID4+Pj4gbGUuZWR1JTdDMTEyY2FjYzZkYTZhNDBlNjU2 MDcwOGQ4MTZmN2MwYjklN0NkZDhjYmViYjIxMzk0ZGY4YjQxMTQNCj4gPj4+PiBlMw0KPiA+Pj4+ IGUNCj4gPj4+PiA4N2FiZWI1YyU3QzAlN0MwJTdDNjM3Mjg0NjAwNjM3MzEzMjQ5JmFtcDtzZGF0 YT1Fa2tTd0hBQiUyQkFWM1hRRHolMkZzWUpNc0JMaUt5bXo2bjRCUk9WV0diZzdZZyUzRCZhbXA7 cmVzZXJ2ZWQ9MCBhbmQgdGhlbiBzZW5kaW5nIGEgbGluayB0byB0aGF0IGRvY3VtZW50IHRvIGJv dGggb3BzYXdnLWNoYWlyc0BpZXRmLm9yZyBhbmQgcmFkZXh0LWNoYWlyc0BpZXRmLm9yZy4gIEl0 J3MgYWxzbyBva2F5IHRvIHNraXAgdGhlIGZpcnN0IHBhcnQgYW5kIHNlbmQgdGhlIGRvY3VtZW50 IGl0c2VsZiB0byB0aG9zZSBhZGRyZXNzZXMuDQo+ID4+Pj4NCj4gPj4+PiBUaGUgcmFkZXh0IChS QURJVVMgRXh0ZW5zaW9ucykgd29ya2luZyBncm91cCBpcyBub3QgdmVyeSBhY3RpdmUgDQo+ID4+ Pj4gYXQgdGhlIG1vbWVudCwgd2hpY2ggaXMgd2h5IEkgYWdyZWUgd2l0aCB0aGUgb3RoZXJzJyAN Cj4gPj4+PiByZWNvbW1lbmRhdGlvbnMgdG8gYXNrIHRoZSBPUFNBV0cgd29ya2luZyBncm91cCBj aGFpcnMnIGFkdmljZSBhcyB3ZWxsLg0KPiA+Pj4+DQo+ID4+Pj4gSG9wZSB0aGlzIGhlbHBzLA0K PiA+Pj4+DQo+ID4+Pj4gQmVuDQo+ID4+DQo+ID4+DQo+ID4+IC0tDQo+ID4+IEkgZG9uJ3QgdGhp bmsgdGhlIGV4ZWN1dGlvbiBpcyByZWxldmFudCB3aGVuIGl0IHdhcyBvYnZpb3VzbHkgYSBiYWQg aWRlYSBpbiB0aGUgZmlyc3QgcGxhY2UuDQo+ID4+IFRoaXMgaXMgbGlrZSBwdXR0aW5nIHJhYmlk IHdlYXNlbHMgaW4geW91ciBwYW50cywgYW5kIGxhdGVyIGV4cHJlc3NpbmcgcmVncmV0IGF0IGhh dmluZyBjaG9zZW4gdGhvc2UgcGFydGljdWxhciByYWJpZCB3ZWFzZWxzIGFuZCB0aGF0IHBhaXIg b2YgcGFudHMuDQo+ID4+ICAgLS0tbWFmDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IHJhZGV4dCBtYWlsaW5nIGxpc3QNCj4gcmFkZXh0QGlldGYu b3JnDQo+IGh0dHBzOi8vbmFtMDUuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnd3dy4NCj4gaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZy YWRleHQmYW1wO2RhdGE9MDIlN0MwMSU3Q2Rhbi5tYXNzYW1lbg0KPiBvJTQweWFsZS5lZHUlN0Mz NGUzNGNmYWM1NzA0YTljNzZjODA4ZDgyMjdhYTY2YyU3Q2RkOGNiZWJiMjEzOTRkZjhiNDExDQo+ IDRlM2U4N2FiZWI1YyU3QzAlN0MwJTdDNjM3Mjk3MjU3NDYyMDg3NjczJmFtcDtzZGF0YT1qYWFW Vm1nVWU4WTJ1T2VybXANCj4gQUtZcTZpTTZPUWNFSkNVTU5aJTJGOENHdzZrJTNEJmFtcDtyZXNl cnZlZD0wDQo= From nobody Fri Jul 10 05:08:17 2020 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 A82B83A0BFD; Fri, 10 Jul 2020 05:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=yale.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Usnd3znpVl_E; Fri, 10 Jul 2020 05:08:07 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2130.outbound.protection.outlook.com [40.107.244.130]) (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 7EA6D3A0BFE; Fri, 10 Jul 2020 05:08:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M+l4piKjyPF87INHFM4O7zmH1zx0s9WONrrHvxPmm82kBD2+rG4fgLyHYANx52TM5QjYBxRcN7tB3Tza/RU061wxvdjWyZObWvepZl0yCkbs+rmW2gLXkcrvwcwSMcIvhykuEcgaV77Op6GlZfRUiIBNYGUrZi88jOoIS5Wn8odWMqLhDNZTDXccp0Pmeh2pskG3B2fPQOTHZia8LPrZXOcqjHNFim8O6BgWpnLy3+cAKoHN98cgMoAThwrQ41O0RuxwL7uNrCq0qwSY3lRhN7U8j+RurtQXwRjhP/4zQ4juazkr19vU7Sd9Jr9CyCmWU7hEDXEU1DvrgWIwlVlnRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3XVh174Lpx//YynuLfu2LN0pN6WkpyQZWtCUojfEUqI=; b=P/L2LY3VmZBSiPjI5cXNa4ddsjzBShDMCKtEm1qfgzkbdByUvvXU56NtXKT2YYuqweY5P1Xo7Tqt7xCqDqS3fT9ZJh7VOgnySTlK1KEnWpVvTFRI1IXG/thTH2+jHr9F3LyB7eEd1bLm4sWz/Ter82R10ZY+tdiAD9lwhEC0HFquQNSBOluHY+6KGInGC399I/teDn0B5ZfJHVGZQSBDKJZMOIld3kvjQDRkqNIPNL0o+dyFihW04+HrYNS8W1dJRIS0eUZEMK3BaJhrmSnz+0Ov6j2nTPhz2Nhf8V9Fr0/0rKJ09pBrGaMeDjLdpekLLK1hL06IMrZL0Yc8oQ46gg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=yale.edu; dmarc=pass action=none header.from=yale.edu; dkim=pass header.d=yale.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3XVh174Lpx//YynuLfu2LN0pN6WkpyQZWtCUojfEUqI=; b=BSGFL5gIwYsauAVudeWzsUEf/2eLht+HbBqJUoRBKccdzURQPlo/nqg1AJa2lGLSWnyCU4YzTa4XunKHhAYQKXhTjfaSCeN61VCXpxIkV2wwCiviowcf1Ed20Kf+pB4H+pieaKc6HXDuDyn9uGnMTJtlUL5hl07VJZ0UWEHMkLQ= Received: from MN2PR08MB6223.namprd08.prod.outlook.com (2603:10b6:208:1a1::21) by MN2PR08MB6208.namprd08.prod.outlook.com (2603:10b6:208:1a7::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.22; Fri, 10 Jul 2020 12:08:05 +0000 Received: from MN2PR08MB6223.namprd08.prod.outlook.com ([fe80::ecc3:9854:f30f:fc9]) by MN2PR08MB6223.namprd08.prod.outlook.com ([fe80::ecc3:9854:f30f:fc9%3]) with mapi id 15.20.3174.022; Fri, 10 Jul 2020 12:08:05 +0000 From: "Massameno, Dan" To: Alan DeKok CC: "opsawg@ietf.org" , "radext@ietf.org" Thread-Topic: [OPSAWG] RADIUS Extension, Getting Started Thread-Index: AdZEnvKQAaU5dfBlRUu7icTII+cjdABGQyjQABvIqNAAA7YgEABP5jcAAFBdPqAACl9JAACH358gAPvKPlAAALjLgACC/lEAAKs6acAACdZ8gAC3tN1A Date: Fri, 10 Jul 2020 12:08:05 +0000 Message-ID: References: <2064d9a1a5d54aa1899664f1f55d59aa@cert.org> <20200621024216.GF11992@kduck.mit.edu> <87adbd01-a100-7192-5b0d-fdc180ac2f5d@restena.lu> <1D54DD45-8F8A-4691-87C2-DC1BB5BE5C9F@deployingradius.com> In-Reply-To: <1D54DD45-8F8A-4691-87C2-DC1BB5BE5C9F@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: deployingradius.com; dkim=none (message not signed) header.d=none;deployingradius.com; dmarc=none action=none header.from=yale.edu; x-originating-ip: [107.3.32.193] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 245b4541-f549-4e49-1c95-08d824c9e717 x-ms-traffictypediagnostic: MN2PR08MB6208: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rFEspuBSxbwQ8uI4PrWiZEVKBqgWetjbsRrSemAel5L5BVP9aIAkAaDzuXUIqP+1AUymXlxLbmOh6Ap3sbasbUJ5ARzvjfzML2ekWbtUjCk5rx65/nwr8MY/kNE4ZW4SE5d2RdP0RmYHU5OgHyYX/vHBscTqEqOjzrW8Rxya1AtxOkNLramHyQhRtBDOU9mcPHHrkd7faIsV8B7vqhTreoW/w9D8AKEMjI+KWrl7Ik7zw/AXk7wNBJfTw9EIy+vIAJg/Fymsz0vpyY1rUxneveyu0oB5pZds1/Hq00+hQBJqPU4g3ByP4f/8oCDhbjeA2gcBKpyQYQynoYvH66ftT6SS/NIaSfut5ca4wKVdlx4Eh0Z2eVolp9jNQB+RXH8vPc2DSy1Y4bEy1iu6ZE6G6Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR08MB6223.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(366004)(376002)(396003)(39860400002)(33656002)(6506007)(966005)(55016002)(26005)(66946007)(478600001)(9686003)(71200400001)(45080400002)(786003)(8936002)(76116006)(66556008)(53546011)(316002)(66446008)(64756008)(75432002)(66476007)(4326008)(30864003)(186003)(83380400001)(5660300002)(2906002)(86362001)(54906003)(6916009)(8676002)(52536014)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: FrnEICO0sUOFxMocmHqHJqxm2ppa8/QOz8i1v3NKUqCP2UFWB5veDrlPyoDzOfoUjIvasCDRH7XPWmaTYFzffs1+ZfNfnDxZlj8Up+/7pbmY89l3w7zLCFpLBFbuki3tUP0BEB2Ri8QNLyPyGE+WA0Z+yYXdy0xUju5xZBrg8I9J9ye3XkcwuLGgcbE18LTqZPnpuFK9ofgIh3qodmvMMQsJTc2cToiXC8Umx35YQ9ZwcXkSzPdK9FhJtk7htt2SA0izOC3zhYC4uHxaJCJe3oPdYnHSbMK2K9J8KoIo5af4yUnLD0d5fnurQaWu2SDeqAGSUWmii4asXq0PQImTWYTr+jNZnXlDN5CKra0QAMfgJhMHT2N/ALXJ605Mv46No8nLj3LoilxetL+U416AWSpdfdc6pewXRXgpdBls1EpPfEFMdXR2G/It3ZahYA2JTL/ZKvBpcN4RjrXO7N0AJprhbQRG2YHgjclzrdL57ug= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: yale.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR08MB6223.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 245b4541-f549-4e49-1c95-08d824c9e717 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2020 12:08:05.4514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: dd8cbebb-2139-4df8-b411-4e3e87abeb5c X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vQwmIaBY6fqkWJs7lcVRm8+oyeDSRhUIl3ztv7EnEXenKTva3KDeTiCjlbogQb/Pnh96wIVBpjLKrik+Nt0HAg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR08MB6208 Archived-At: Subject: Re: [radext] [OPSAWG] RADIUS Extension, Getting Started X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 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, 10 Jul 2020 12:08:11 -0000 Alan, Thank you for your thorough review. I am completely new to the IETF proces= s (I don't even know what a "nit" is) and I'm looking forward to the proces= s. I did want to dive into one of the last comments you made. =20 Even if the various nits and and issues above were fixed, this prop= osal would have serious security issues. Even=20 if those security issues were addressed, I believe that load balanc= ing is simply not appropriate for=20 the NAS. Even if it was appropriate for the NAS, the vendors have = spoken: NAS implementations=20 are simple, and server implementations are complex. As such, load balancing more properly belongs in the server. If I have N number of RADIUS servers, how are the servers supposed to load = balance if the load balancing function "belongs in the server"? Won't the = NAS need to know about all the RADIUS servers? If yes, how does it decided= on which one to user for any one particular session? My experience with Cisco devices indicates that if multiple RADIUS servers = are listed it simply uses the first one exclusively until it fails. So, th= ere is failover, but no load balancing. The list of RADIUS servers are als= o statically configured via CLI, which is cumbersome when there is a large = fleet of devices to configure. These two overly sophomoric features were t= he ones I was endeavoring to fix. --Dan=20 -----Original Message----- From: Alan DeKok =20 Sent: Monday, July 6, 2020 16:16 To: Massameno, Dan Cc: opsawg@ietf.org; radext@ietf.org; OpsAWG-Chairs ; Benjamin Kaduk ; radext-chairs@ietf.org Subject: Re: [OPSAWG] RADIUS Extension, Getting Started On Jul 6, 2020, at 11:40 AM, Massameno, Dan wrote: >=20 > Dear Ops and Management Area WG, >=20 > There have been a number of great suggestions on where to post this docum= ent (Thanks Stefan!). I'm now emailing opsawg@ietf.org and cc'ing radext@= ietf.org. =20 >=20 > The draft is posted here... https://nam05.safelinks.protection.outlook.co= m/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-massameno-radius-lb-00= &data=3D02%7C01%7Cdan.massameno%40yale.edu%7C6e11e17859e34020f10408d821= e9727e%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637296633820432892&= sdata=3DdiYmvpvWJyIfYY%2FCerbLRHgniQbbkgp%2BWxoLm9h9k5c%3D&reserved=3D0 >=20 > Do I need an official IETF sponsor? Would it help to try and get a vendo= r interested in implementing the protocol? Cisco is our primary vendor at = Yale University. I was wondering if there is anyone on either of these wor= king groups that communicates with Cisco people on a regular basis? There are lots of Cisco people. I'm sure some of those people have opini= ons. There are a few things ongoing here. The RADEXT WG is still alive, but i= nactive. There is a still an open discussion in the WG about previous docu= ments which addressed shortcomings in the base RADIUS protocol. The polite= version is that the long-term RADEXT participants supported one draft. Ma= ny people who had never been involved with RADEXT supported a competing dra= ft. There was never any resolution. The RADEXT WG was left in limbo. I'll avoid the subject of the best place for this draft. Overall, I would oppose this draft. For the simple reason that brains be= long in the RADIUS server, not in the NAS. NAS vendors haven't even implem= ented the retransmission behaviours suggested in RFC 5080 Section 2.1, whic= h is well over a decade old at this point. If they can't do that, how can = they implement an even more complex load-balancing system? Further, there is no standard in RADIUS for load-balancing with fail-over= and fail-back. Every NAS vendor and RADIUS vendor does something differen= t. While this document tries to address that issue, it does not address a = number of key points. I do have a review, as follows. Many of these issues given below are nit= s, and can be fixed by rewording the document, or moving to an approach whi= ch follows existing standards (RFC 6158, RFC 6929, RFC 8044). However, for= reasons given above, I don't think it's useful to move ahead with this doc= ument. * Section 2 - Message Summary I recommend deleting this part. The RADIUS packet format is well known.= There's no need to repeat the definition here. Just refer to RFC 5997. * Section 2.2 - nitpick: 191 is not defined, so it's likely best to leave t= his attribute value as TBD, even if IANA is likely to choose 191. Further, RADIUS definitions use consistent names for attributes. The nam= es do not change when they're used in different packet types. The attribut= e should just be called something like "Load-Balance-Status" * Section 2.3.2 - the text here is simply wrong. The Request-Authenticator= is not "hashed with the identity material from the calling-station and the RADIUS shared secret." RFC 5997 Section 5 already mandates the use of Message-Authenticator wit= h Status-Server. I suggest deleting 2.3.2 entirely. * Section 3 - the definition of the LB-Request does not satisfy the require= ments of RFC 6929 Section 5.2. There is no reason to use a 16-bit data typ= e here. https://nam05.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Frfc6929%23section-6.2&data=3D02%7C01%7Cdan.massameno= %40yale.edu%7C6e11e17859e34020f10408d821e9727e%7Cdd8cbebb21394df8b4114e3e87= abeb5c%7C0%7C0%7C637296633820432892&sdata=3DGz%2FOD3vyw1JpqYdvPTiLOzvf8= mpC5t4iRZixCdnkjyU%3D&reserved=3D0 RFC 8044 also defines data types which are appropriate for use in RADIUS.= That RFC also suggests that there is no longer need for ASCII art in most= cases, as attribute definitions can just use predefined data types. Also in general, reserved bits should go at the top of an integer attribu= te. Status bits should be in the lower bits. * Section 4.1 redefines attribute 191 to contain completely different data.= This definition violates the prohibition on polymorphic attributes given = in RFC 6159 Section 3.4 https://nam05.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i= etf.org%2Fhtml%2Frfc6158%23section-3.4&data=3D02%7C01%7Cdan.massameno%4= 0yale.edu%7C6e11e17859e34020f10408d821e9727e%7Cdd8cbebb21394df8b4114e3e87ab= eb5c%7C0%7C0%7C637296633820432892&sdata=3DfBLI70Az70EKFP5DiN%2FIsfjQfmA= Kl1ajetrhjqIQvRY%3D&reserved=3D0 I suggest using two different attributes, one for signalling client to se= rver, and another for responding server to client. The text in this section is also unclear: Server_Info The String field is one or more server_info PDUs. Each PDU defines the status of a single server and its defining characteristics. What does that mean? Is the intent to carry the SVR-Record attributes in= side of attribute 191? If so, then using attribute 191 as both a 16-bit bi= tfield, and as a TLV carrier is very odd. It's safe to say that nothing wi= ll ever support this. I suggest using two different attrributes. I suggest simply relying on the existence of one or more SRV-Record attri= butes in the reply. There is no need to repeat the LB-* attribute. * Section 5 The SRV-Record TLV This section does not define any TLV attribute. It's not clear what this= means. * Section 5.1 and 5.2 It's not clear why two different attributes are needed. Why not just use = SRV-Record? And there's no need to repeat ASCII art. RFC 8044 Section 3.13 already d= efines the TLV data type, and format. You should just reference that. * Section 5.3 defines a table of attributes, including attributes not previ= ously seen in the document. I suggest moving the table of attributes to later in the document, *after= * the relevant attributes have been defined. * Section 6 There's no need for ASCII art. RFC 8044 Section 2.1.2 makes this clear. = Just reference the data types. * Section 7.1 The document says: ... Under these Status-Server-LB rules the NAS MUST send all RADIUS messages relative to a particular session to the same RADIUS server to maximize the probability of a cache-hit. What then, is the utility of land balancing? If one RADIUS server goes d= own, cannot the NAS send packets for a session to a different, but *equival= ent* RADIUS server? This recommendation seems to drastically increase the = likelihood of losing accounting packets, which seems bad. In addition, the discussion of "caching" seems odd, and uncommon. Databa= ses do user replication, not RADIUS servers. We should not expose implemen= tation details in a standard document. i.e. the RADIUS servers should be treated as identical, and local balanci= ng should be done on a packet by packet basis. * Section 7.2 The document says: The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being used for AAA services.=20 Ok, *how* is this to be done? Specifying this behaviour seems important.= Perhaps adding up all weights of a similar priority, and choosing a "W_i"= at random, with probability W_i / Sum(W_0. ... W_n) * Missing: discussion of shared secrets, authentication vs accounting, port= s, TLS, TCP, etc. What shared secret is used for these different RADIUS servers? The same = one as used in the original Status-Server? What ports should the NAS send packets to? Does this load balancing work= for all packet types? What about TCP, UDP, TLS, etc.? How does this proposal interact with dyn= amic discovery? (RFC 7585) * Section 8 The document says: RADIUS Server Load Balancing has many of the same security implications as the base RADIUS protocol. There are many additional security issues opened up by this new capabilit= y. They should be discussed. * Section 10 The document says: The Vendor Specified Attribute 26 may be used to encapsulate the LB- Request and LB-Response PDU where no vendor interoperability is required. It is very odd to put standards text inside of an "IANA considerations" = section. Further, this text appears to be confused about the purpose of th= e RADIUS attribute numbers. These numbers are location-sensitive. i.e. ven= dor attribute "191" has no relation whatsoever to attribute "191" in the ma= in RADIUS space. Similarly, it has no relation to an attribute "191" from = another vendor. This text is wrong and should be deleted. Summary: Even if the various nits and and issues above were fixed, this proposal w= ould have serious security issues. Even if those security issues were addr= essed, I believe that load balancing is simply not appropriate for the NAS.= Even if it was appropriate for the NAS, the vendors have spoken: NAS impl= ementations are simple, and server implementations are complex. As such, load balancing more properly belongs in the server. Alan DeKok. From nobody Fri Jul 10 05:26:13 2020 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 CFB263A0C98; Fri, 10 Jul 2020 05:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 lGYNqqyADvIs; Fri, 10 Jul 2020 05:25:57 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420BD3A0C70; Fri, 10 Jul 2020 05:25:55 -0700 (PDT) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id CDA7AA9; Fri, 10 Jul 2020 12:25:53 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Alan DeKok In-Reply-To: Date: Fri, 10 Jul 2020 08:25:52 -0400 Cc: "opsawg@ietf.org" , "radext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <17C2C808-E3B3-48D5-ACC8-1C8F93734A9C@deployingradius.com> References: <2064d9a1a5d54aa1899664f1f55d59aa@cert.org> <20200621024216.GF11992@kduck.mit.edu> <87adbd01-a100-7192-5b0d-fdc180ac2f5d@restena.lu> <1D54DD45-8F8A-4691-87C2-DC1BB5BE5C9F@deployingradius.com> To: "Massameno, Dan" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [radext] [OPSAWG] RADIUS Extension, Getting Started X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 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, 10 Jul 2020 12:26:07 -0000 On Jul 10, 2020, at 8:08 AM, Massameno, Dan = wrote: > Thank you for your thorough review. I am completely new to the IETF = process (I don't even know what a "nit" is) and I'm looking forward to = the process. "nitpick". i.e. minor point which should be fix, but isn't very = important. The IETF process is long, but generally worth it. > I did want to dive into one of the last comments you made. =20 >=20 > Even if the various nits and and issues above were fixed, this = proposal would have serious security issues. Even=20 > if those security issues were addressed, I believe that load = balancing is simply not appropriate for=20 > the NAS. Even if it was appropriate for the NAS, the vendors = have spoken: NAS implementations=20 > are simple, and server implementations are complex. > As such, load balancing more properly belongs in the server. >=20 > If I have N number of RADIUS servers, how are the servers supposed to = load balance if the load balancing function "belongs in the server"? You run a load-balancer. This is either a hardware device which does = UDP load balancing, or a dedicated RADIUS server which does nothing more = than load balancing. > Won't the NAS need to know about all the RADIUS servers? If yes, how = does it decided on which one to user for any one particular session? The NAS knows about one server: the load balancing one. Typically the = load balancer can be set up in an HA pair, using VRRP to share an IP = address. My experience is that this scenario is robust, stable, and gives the = admin a great amount of control over the system. My experience also has = been that you just can't rely on the NAS to do anything sane with = RADIUS. The implementations are terrible, naive, simplistic, etc. Just = give up on fixing them, and patch over the problem with a RADIUS server = that's under your control. It's easier for me to say, of course, having written a RADIUS server. = That does bias me a bit, I think. But practical experience validates = this approach. A different explanation for the NAS behaviour is that the NAS vendors = are incentivized to make the core functionality work well. e.g. = switching, WiFi, etc. Features such as RADIUS are an after-thought. = Issues with RADIUS are only fixed if a sufficient number of customers = demand changes. In contrast, a RADIUS server vendor is strongly incentivized to = implement RADIUS correctly. And, to do load balancing correctly. With = many parameters that can be tweaked for your exact situation. So independent of anything else, NAS vendors simply aren't motivated = to implement complex RADIUS load balancing. Whereas RADIUS server = vendors have been shipping it for decades. > My experience with Cisco devices indicates that if multiple RADIUS = servers are listed it simply uses the first one exclusively until it = fails. So, there is failover, but no load balancing. The list of = RADIUS servers are also statically configured via CLI, which is = cumbersome when there is a large fleet of devices to configure. These = two overly sophomoric features were the ones I was endeavoring to fix. Most RADIUS clients behave the same way. My recommendation for a long = time has been to just punt on the problem of fixing the NAS. Instead, = run a RADIUS server that you control. One benefit is that you can upgrade the NAS, or change vendors without = changing the way that load balancing works. And to re-iterate... RFC 5080 Section 2.1 defines retransmission = behaviour for RADIUS clients. Implementing this would make customers = lives easier. It would make RADIUS systems better and more stable. But = the incremental benefit is simply not high enough for NAS vendors to = implement it. So instead, they use fixed-count and fixed-time = retransmission behaviours which were first implemented in 1993. In order for your proposal to gain traction, the NAS vendors MUST have = strong incentive to implement it. And I'm not sure what that incentive = is. Right now, they can just say "buy a load balancer", or "download = FreeRADIUS and run it in a VM". Problem solved. Alan DeKok. From nobody Wed Jul 15 05:09:35 2020 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 65B593A0C82 for ; Wed, 15 Jul 2020 05:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=yale.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggiSVTicfzvB for ; Wed, 15 Jul 2020 05:09:32 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2103.outbound.protection.outlook.com [40.107.93.103]) (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 A1C193A0A26 for ; Wed, 15 Jul 2020 05:09:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HFFZjSbF1QLyUsOtKLRAcwreKB36+V5YuQZHuqv0mxcNb2kiDqU7oMqLO7lPb/qF7FInHYIBO+KUNOdFapPNEB9TxReffWQ7ukhwgyQadSDwjZEGYt/Zpd5VACr9r+4O2omC47AFrfNTKMQ6ZnCja6ULbx9YP1YsYFt5iiCKSlntKF1FTc2Wa9m48fJT5gZ/KftvBTZUw/QhzLThR2945jDkEMCUXGDm4s7eI68JzBwHX668/9buH3f8W7k0An5Y2FiNuo35sP2cTSDjZUGKX0lh1hsE0wrs7md7Vlv0DQQCxUQVf5wprV7g48mBaGg3CiiRXTcr/AxL4/8WP5xQnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Oqbx8Y3c67aR6TWdFpoYr/6UheOnI2YTPZNk7kh90A4=; b=WOPmugsEZkTlspyHmv/AlqPl6sJvPz4+d4/LCYao7qC+qfXySXrNBwP4UAr6IM/VPWw/2f2lwjJKU1y7NwBwalwXZPZaryCzeC6na9a3lIHZkzWjfJMwtZlzRUtujBJS44wLKauRIVnQzQnVHN6Z3oQmGhEUsgJa1J8fX8SZN41TlJ6OCtxdjseQukOyzqkVr4Qn/UFC967Xc3TJ2fV8vMgYtKNiC1vTnJWgcW7vNyQpyYEU4IHZQ+WcEj7FXuR5DaNdOS0G2QFxS2UXWhsDqf6x3ogoOHBW7AaYipN7Q0B5XReDvei6ED2K/vSkeW1x6twoEn1W+vuDj4eKD3jWMA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=yale.edu; dmarc=pass action=none header.from=yale.edu; dkim=pass header.d=yale.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Oqbx8Y3c67aR6TWdFpoYr/6UheOnI2YTPZNk7kh90A4=; b=cZaJm6mCWX3v5//oa5el2uyz4Z6GCc2bX+euOxkfuTIuN6EAhCCTYmQZZRle7qHq4goEqxkXlIytoYnjr+oNsRU+XHrAwuC8nsm4234sSBCdfBaiiTsoS4odCDhRqYl1qyu7bkfnHmY111DZQZiyhp8WrOLMcuv0HXvqy3A0nyA= Received: from MN2PR08MB6223.namprd08.prod.outlook.com (2603:10b6:208:1a1::21) by MN2PR08MB6205.namprd08.prod.outlook.com (2603:10b6:208:1af::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.22; Wed, 15 Jul 2020 12:09:30 +0000 Received: from MN2PR08MB6223.namprd08.prod.outlook.com ([fe80::ecc3:9854:f30f:fc9]) by MN2PR08MB6223.namprd08.prod.outlook.com ([fe80::ecc3:9854:f30f:fc9%3]) with mapi id 15.20.3195.017; Wed, 15 Jul 2020 12:09:30 +0000 From: "Massameno, Dan" To: Alan DeKok CC: "radext@ietf.org" Thread-Topic: [OPSAWG] RADIUS Extension, Getting Started Thread-Index: AdZEnvKQAaU5dfBlRUu7icTII+cjdABGQyjQABvIqNAAA7YgEABP5jcAAFBdPqAACl9JAACH358gAPvKPlAAALjLgACC/lEAAKs6acAACdZ8gAC3tN1AAAEH/wAA+cZfoA== Date: Wed, 15 Jul 2020 12:09:30 +0000 Message-ID: References: <2064d9a1a5d54aa1899664f1f55d59aa@cert.org> <20200621024216.GF11992@kduck.mit.edu> <87adbd01-a100-7192-5b0d-fdc180ac2f5d@restena.lu> <1D54DD45-8F8A-4691-87C2-DC1BB5BE5C9F@deployingradius.com> <17C2C808-E3B3-48D5-ACC8-1C8F93734A9C@deployingradius.com> In-Reply-To: <17C2C808-E3B3-48D5-ACC8-1C8F93734A9C@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: deployingradius.com; dkim=none (message not signed) header.d=none;deployingradius.com; dmarc=none action=none header.from=yale.edu; x-originating-ip: [107.3.32.193] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 93fd1ae5-8b70-4afc-c3ab-08d828b7eddb x-ms-traffictypediagnostic: MN2PR08MB6205: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DxbRjz5YG92UBNd3NEuKCpmf/azzrpusztBB6rpn0XpQVIpD6PZmKC9b+ERaaUHKC95G5jnmOsmIJ7wFnAGI2qwX2EnaYLfHajK7yzmMcOobHcS9709hh597x7AwJGeLWGTyXYKzibE/3WuMEuou3I17hHchI6cGZPDTBaMRPSnPpmbNPAVvoFrhPGeZE1+S7uop2Qi2SLXroCV94OfxghJ/LATvQXvesWIQDiAGKhaay9tJUGgP20woce9U5IcWZO/mkHU0v072YwknsczsZmLsRcSpLgab2X21c5ZZFHU7P5IyC+omeKbXSXQH0WA3THH24m2NV+xMnt3gL/Y0oQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR08MB6223.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(39850400004)(396003)(366004)(55016002)(9686003)(26005)(2906002)(786003)(316002)(33656002)(478600001)(186003)(7696005)(6506007)(6916009)(53546011)(4326008)(66476007)(64756008)(5660300002)(66446008)(71200400001)(8676002)(52536014)(66946007)(83380400001)(76116006)(8936002)(86362001)(75432002)(66556008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: PFuPsZPMbGfLqW6gBrSukPEitJFdW2PZuOaq/DX8EK3JZOo26WPnPnMyvX+C/0U94dUgCks0qnW4/TVFsjjs3UqtguxDbM8FD4lFINNGfiW/z8YqJaxGL9UQKUuWIqPIHaiKuyCYqIJlMIc2ZjoW/fvjPXnhQC3IjI9iH2PrjO33WCjlC1pqdUfnwRuPJFKSPK3++US86nUgtaG1O/+emCu6bVJntL9cdt2P7bLYrvWhIKm/mybtvmPfqb0QdOqodRI7THlR5yZfezxByLWHVgvd/A1pFZGh/SQDWgJlmq+m6HuzOV6XriZQgWiTYk3yTNIB7HTa8pKnbbuj1FZjFWjtmhFg23zZnzEnZitua85uaDU5tT2Nc/4JVKXeCiUdJnw5DuNsgiT2UhhdONepIo3lQaCArBgtbWxKmx9hwUkz99I6AzA8+52m+NQLP8Qf2SgJKW8PV/PaH5outO0gUSk4kOuZ/VPuWn+yYIZVhrU= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: yale.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR08MB6223.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 93fd1ae5-8b70-4afc-c3ab-08d828b7eddb X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2020 12:09:30.6300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: dd8cbebb-2139-4df8-b411-4e3e87abeb5c X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2jJqsPobl1PjKMSgRhXMkUZUYN3U1hf19M9jD+d+aqJ4QCnudsD2qO7DtxwD3RW1P0OT+1ZyWi1CLu1nZQwnNg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR08MB6205 Archived-At: Subject: Re: [radext] [OPSAWG] RADIUS Extension, Getting Started X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 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, 15 Jul 2020 12:09:34 -0000 Alan, These are very interesting points. I had a couple of questions. 1. If a FreeRADIUS server was just setup to do proxy forwarding (no policy = decisions at all) and is designed to load balance across N number of back-e= nd Cisco ISE servers, how many auths/second do you think it could handle, g= iven modern hardware? I realized "given current hardware" is a loaded ques= tion. I just want to see if we're in the right ball park for something tha= t can handle the load we're talking about. We're expecting > 150 per secon= d. =20 2. When then authentication gets to its it's final Cisco ISE server and tha= t server then needs to send a CoA to the original NAS, would that work? Wo= uld it send it through the RADIUS Proxy or directly to the NAS? I'll have to read the RADIUS proxy RFCs. I have not dived deep into them b= ecause I didn't think we would be using any proxies in our deployment. --Dan -----Original Message----- From: Alan DeKok =20 Sent: Friday, July 10, 2020 08:26 To: Massameno, Dan Cc: opsawg@ietf.org; radext@ietf.org Subject: Re: [OPSAWG] RADIUS Extension, Getting Started On Jul 10, 2020, at 8:08 AM, Massameno, Dan wrote: > Thank you for your thorough review. I am completely new to the IETF proc= ess (I don't even know what a "nit" is) and I'm looking forward to the proc= ess. "nitpick". i.e. minor point which should be fix, but isn't very importan= t. The IETF process is long, but generally worth it. > I did want to dive into one of the last comments you made. =20 >=20 > Even if the various nits and and issues above were fixed, this pro= posal would have serious security issues. Even=20 > if those security issues were addressed, I believe that load balan= cing is simply not appropriate for=20 > the NAS. Even if it was appropriate for the NAS, the vendors have= spoken: NAS implementations=20 > are simple, and server implementations are complex. > As such, load balancing more properly belongs in the server. >=20 > If I have N number of RADIUS servers, how are the servers supposed to loa= d balance if the load balancing function "belongs in the server"? You run a load-balancer. This is either a hardware device which does UDP= load balancing, or a dedicated RADIUS server which does nothing more than = load balancing. > Won't the NAS need to know about all the RADIUS servers? If yes, how do= es it decided on which one to user for any one particular session? The NAS knows about one server: the load balancing one. Typically the lo= ad balancer can be set up in an HA pair, using VRRP to share an IP address. My experience is that this scenario is robust, stable, and gives the admi= n a great amount of control over the system. My experience also has been t= hat you just can't rely on the NAS to do anything sane with RADIUS. The im= plementations are terrible, naive, simplistic, etc. Just give up on fixing= them, and patch over the problem with a RADIUS server that's under your co= ntrol. It's easier for me to say, of course, having written a RADIUS server. Th= at does bias me a bit, I think. But practical experience validates this ap= proach. A different explanation for the NAS behaviour is that the NAS vendors are= incentivized to make the core functionality work well. e.g. switching, Wi= Fi, etc. Features such as RADIUS are an after-thought. Issues with RADIUS= are only fixed if a sufficient number of customers demand changes. In contrast, a RADIUS server vendor is strongly incentivized to implement= RADIUS correctly. And, to do load balancing correctly. With many paramet= ers that can be tweaked for your exact situation. So independent of anything else, NAS vendors simply aren't motivated to i= mplement complex RADIUS load balancing. Whereas RADIUS server vendors have= been shipping it for decades. > My experience with Cisco devices indicates that if multiple RADIUS server= s are listed it simply uses the first one exclusively until it fails. So, = there is failover, but no load balancing. The list of RADIUS servers are a= lso statically configured via CLI, which is cumbersome when there is a larg= e fleet of devices to configure. These two overly sophomoric features were= the ones I was endeavoring to fix. Most RADIUS clients behave the same way. My recommendation for a long ti= me has been to just punt on the problem of fixing the NAS. Instead, run a = RADIUS server that you control. One benefit is that you can upgrade the NAS, or change vendors without ch= anging the way that load balancing works. And to re-iterate... RFC 5080 Section 2.1 defines retransmission behaviou= r for RADIUS clients. Implementing this would make customers lives easier.= It would make RADIUS systems better and more stable. But the incremental= benefit is simply not high enough for NAS vendors to implement it. So ins= tead, they use fixed-count and fixed-time retransmission behaviours which w= ere first implemented in 1993. In order for your proposal to gain traction, the NAS vendors MUST have st= rong incentive to implement it. And I'm not sure what that incentive is. = Right now, they can just say "buy a load balancer", or "download FreeRADIUS= and run it in a VM". Problem solved. Alan DeKok. From nobody Wed Jul 15 08:55:46 2020 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 258D93A0CFF; Wed, 15 Jul 2020 08:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yale.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c--B4v4vzblL; Wed, 15 Jul 2020 08:30:18 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2117.outbound.protection.outlook.com [40.107.244.117]) (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 60A013A0486; Wed, 15 Jul 2020 08:29:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i9h9TgXF/dOAvgppLNk3fOsDsmD4fng/d8u0qRy9KxK/vXe5CDr34QPMNV5owOh2qdEYrKrGDuTRVhjKpomXUwiTR5gP/A0FXzMY7WfhMrSO7/tL8S4vbr19ufYl+2OjZsJvPomCDFdbdd3f6Y8Zaa1ysN07hirB08cudn6QSMM1gQ9GT/9eKNrE1bMxMDR9+mblAca4h7o3jpORbISTw2dmVoYXZtPUy3JoTy767CAn+/f5MnlwGzD1aPFqT7RmJQ8zMg48w2UnqVj1T5/Tn7EuZ0hwVTvXnTTbHRD1hdNgXyhznKgmw1rYIZ3+q0p1DUhfd52edKoMb/poeK6BWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z1mQv8kVvX3BwsNEPR7Qo7N3XZzxUSF7Lha4LxlrFI8=; b=V8juF1ArwKpM3+1IYPRmEgTmVlA1mdetTV+e65FTesP7VVJzlIls6JzkTxIesBcbrdDFiL94jK7KVYMCQ5dMMD+V3L5nvi9cke8gm0TuuR+WeQjMmZ7UWFTbWJAMaQcTsg3rpI7JeoaanzUCcDM9Rq/MU+KffcCwcfhskpHuTpxd21IrfHi1EsFgtq0ygjc/Pax34UsLVnN98NuFi8LxGnteUUNWJHLkUnYt4JwFNQEni2Eb3fb8FQK3Q9zea43ZtBfx49bwalTyVHGFe8PYCz7w5GVdzMtfIj1z0ojRSM2blrqGditJ24LVJOkhm1XuLQYDAbOgUZQCav/yOAz4+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=yale.edu; dmarc=pass action=none header.from=yale.edu; dkim=pass header.d=yale.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z1mQv8kVvX3BwsNEPR7Qo7N3XZzxUSF7Lha4LxlrFI8=; b=e8MOSnS++pNWQsCyTAMXg6gPld6BVU9+9yL8y59osVASDqGbVQDjjf+IKVH7dKidS+jYhj+qSxlqaN8zruZO9d2YpxDmxfOgYeFR2j3ph9EHE/RX3YcsCgGfpNdnhW+oGkcglc2/FQgn8O5oblCkUnRoDcbU54xkyHlBIo8DCwE= Received: from MN2PR08MB6223.namprd08.prod.outlook.com (2603:10b6:208:1a1::21) by MN2PR08MB6303.namprd08.prod.outlook.com (2603:10b6:208:1af::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20; Wed, 15 Jul 2020 15:29:41 +0000 Received: from MN2PR08MB6223.namprd08.prod.outlook.com ([fe80::ecc3:9854:f30f:fc9]) by MN2PR08MB6223.namprd08.prod.outlook.com ([fe80::ecc3:9854:f30f:fc9%3]) with mapi id 15.20.3195.017; Wed, 15 Jul 2020 15:29:41 +0000 From: "Massameno, Dan" To: Oleg Pekar CC: "opsawg@ietf.org" , Roman Danyliw , "radext@ietf.org" , "Rob Wilton (rwilton)" , Stefan Winter , "Joe Clarke (jclarke)" , OpsAWG-Chairs , Benjamin Kaduk , "warren@kumari.net" , "radext-chairs@ietf.org" Thread-Topic: [radext] RADIUS Extension, Getting Started Thread-Index: AdZEnvKQAaU5dfBlRUu7icTII+cjdABGQyjQABvIqNAAA7YgEABP5jcAAFBdPqAACl9JAACH358gAPvKPlAAALjLgACC/lEAAKs6acAALiIaAAGWNLsg Date: Wed, 15 Jul 2020 15:29:41 +0000 Message-ID: References: <2064d9a1a5d54aa1899664f1f55d59aa@cert.org> <20200621024216.GF11992@kduck.mit.edu> <87adbd01-a100-7192-5b0d-fdc180ac2f5d@restena.lu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=yale.edu; x-originating-ip: [2601:199:c200:bb23:accc:4b0d:5bd9:14e0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c0967725-a3fd-4598-9b03-08d828d3e4a0 x-ms-traffictypediagnostic: MN2PR08MB6303: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4VLSiEZOBiJUUTYT9P6zzjrJpKKtUKTeU7uq7j8AHLPB3ys7yDV4enaHtHMRR4+OIfII3yNfD5+w8hZEOH8NmuaXgZsBBsD8ZaduFtV1hQWlVwBDnSLGCYeIHB32Du/lMk/eQzval+fW+r1bF1tkgUdQHXRWkY+RI3f2JZTSVgnq2pjg7RzyBczp/zabTfvPOstAwxk2hj2OnKidSL0Tf5jreVtXU0FdQ++JL6VTt+eVt4InHN6+Bp3tbrR1L2ZgHIVmmKV8atUTuHAuoq0rE3Fd7PsWt+YwANlb4ES4CadYbZ3Uio0sJVkJiRMFD61SSvo87c8TCk8CwoWf6POsPCvMBkk1Iy0rFrg4Tz2ZgFYd+PQN2rLtZehtZta5V7WAU2t425kseyW2MVeMRomn6Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR08MB6223.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(396003)(346002)(366004)(136003)(52536014)(45080400002)(2906002)(86362001)(4326008)(8676002)(76116006)(66574015)(83380400001)(478600001)(53546011)(7696005)(33656002)(8936002)(6506007)(6916009)(75432002)(9686003)(786003)(316002)(55016002)(966005)(66946007)(5660300002)(66476007)(186003)(54906003)(83080400001)(66556008)(7416002)(64756008)(71200400001)(66446008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: oSluMUpem0RyIG232cmzz5tWLoN3fF3sqGVO2RaK//viANBcyWAtwUsv+tCRUES0WipEBT6PvyKDxGrjjopmpavD0jYUJaBhvqpIhqQSCnQAzt3g2OWvSdWb75PKADHEg4+pgOOOfSNFLHAvYmPtjNEZXTYzMl4R1MBbNVg8vOBm6i0Xfhm6EDO+lEra26Az7J5R4FLFqaUJIJnQN22N+pNxNTmOZe98EvwQWv05mQLdInGogFOjE1W+CKsuJtd3uTUVTBhAvmpXP7O39HboTFj/IoID/SOBUHo7dRpIm2ct272Ow7IsO47nK/kMa9oxL20guJHWSvlk7u8hQ4K9Og9xzVpeIN0t6jbU9VPurybzktm1zFZ4EDqm+pMJ0lzjouKFMDtvQkrYNtfFZvgByVSDCf/foKb56eD72wEC9fVEeLJFGZPCjDeeVUgdyYP+PsmQE3n4/sRW4PHByu5U5Yj3I/XEFwZpgXSDUQk6V2HDtZY0VZWJUa060ZT2X3uq3bOr3uR+3pVqwME1JTX7ZfeEWkdrLs0Sij01iTMJx7PUMTk9vA4TngtXsk/mKfxy x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: yale.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR08MB6223.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c0967725-a3fd-4598-9b03-08d828d3e4a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2020 15:29:41.0880 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: dd8cbebb-2139-4df8-b411-4e3e87abeb5c X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nNhohCq/U8f89kF6RHCaIjs+6VNt6CQJwTWTR/3C+cmC4wpgInAglAn/2pmOEKyCyQp9BALh7pnWsYCUS0uy4g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR08MB6303 Archived-At: X-Mailman-Approved-At: Wed, 15 Jul 2020 08:55:45 -0700 Subject: Re: [radext] RADIUS Extension, Getting Started X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 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, 15 Jul 2020 15:30:23 -0000 T2xlZywNCllvdXIgc3VtbWFyeSBpcyBjb3JyZWN0LiAgVGhlIGVuZC1nb2FsIHdvdWxkIGJlIHRv IHJlbW92ZSB0aGUgbG9hZCBiYWxhbmNlcyBmcm9tIHRoZSBlcXVhdGlvbiwgdGhlcmVieSBzaW1w bGlmeWluZyB0aGUgb3BlcmF0aW9uYWwgY29tcGxleGl0eSBvZiB0aGUgc3lzdGVtLg0KLS1EYW4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE9sZWcgUGVrYXIgPG9sZWcucGVr YXIuMjAxN0BnbWFpbC5jb20+IA0KU2VudDogVHVlc2RheSwgSnVseSA3LCAyMDIwIDA5OjM2DQpU bzogTWFzc2FtZW5vLCBEYW4gPGRhbi5tYXNzYW1lbm9AeWFsZS5lZHU+DQpDYzogb3BzYXdnQGll dGYub3JnOyBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyByYWRleHRAaWV0Zi5vcmc7IFJv YiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47IFN0ZWZhbiBXaW50ZXIgPHN0 ZWZhbi53aW50ZXJAcmVzdGVuYS5sdT47IEpvZSBDbGFya2UgKGpjbGFya2UpIDxqY2xhcmtlQGNp c2NvLmNvbT47IE9wc0FXRy1DaGFpcnMgPG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc+OyBCZW5qYW1p biBLYWR1ayA8a2FkdWtAbWl0LmVkdT47IHdhcnJlbkBrdW1hcmkubmV0OyByYWRleHQtY2hhaXJz QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3JhZGV4dF0gUkFESVVTIEV4dGVuc2lvbiwgR2V0dGlu ZyBTdGFydGVkDQoNCkhpIERhbiwNClNvIHRoZSBkcmFmdCBkZXNjcmliZXMgaG93IGEgTkFTIGNv bm5lY3RlZCB0byBhIHNwZWNpZmljIFJBRElVUyBzZXJ2ZXIgY2FuIG9idGFpbiBmcm9tIHRoYXQg c2VydmVyIGluZm9ybWF0aW9uIGFib3V0IG90aGVyIFJBRElVUyBzZXJ2ZXJzIG9uIHRoZSBkZXBs b3ltZW50LCB0b2dldGhlciB3aXRoIHRoZWlyIHByaW9yaXRpZXMuIFVzdWFsbHkgdGhlIFJBRElV UyB0cmFmZmljIGRpc3RyaWJ1dGlvbiBpcyBjb25maWd1cmVkIGFuZCBjb25kdWN0ZWQgYnkgYSBM b2FkIEJhbGFuY2VyIG5ldHdvcmsgY29tcG9uZW50IChlLmcuIEY1IExvYWQgQmFsYW5jZXIpLiBU aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0IGFsbG93cyBSQURJVVMgc2VydmVy cyBvbiB0aGUgZGVwbG95bWVudCB0byBiYWxhbmNlIHRyYWZmaWMgYmV0d2VlbiB0aGVtIGR5bmFt aWNhbGx5IGFjY29yZGluZyB0byB0aGVpciBsb2FkIG9yIG90aGVyIGNoYXJhY3RlcmlzdGljcy4g SG93ZXZlciBpdCByZXF1aXJlcyBpbXBsZW1lbnRhdGlvbiBvbiBib3RoIHNpZGVzIC0gb24gTkFT IGFuZCBSQURJVVMgc2VydmVyLg0KDQpJcyBteSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQoNClRo YW5rcw0KT2xlZw0KDQpPbiBUdWUsIEp1bCA3LCAyMDIwIGF0IDEyOjEzIFBNIE1hc3NhbWVubywg RGFuIDxkYW4ubWFzc2FtZW5vQHlhbGUuZWR1PiB3cm90ZToNCj4NCj4gRGVhciBPcHMgYW5kIE1h bmFnZW1lbnQgQXJlYSBXRywNCj4NCj4gVGhlcmUgaGF2ZSBiZWVuIGEgbnVtYmVyIG9mIGdyZWF0 IHN1Z2dlc3Rpb25zIG9uIHdoZXJlIHRvIHBvc3QgdGhpcyBkb2N1bWVudCAoVGhhbmtzIFN0ZWZh biEpLiAgIEknbSBub3cgZW1haWxpbmcgb3BzYXdnQGlldGYub3JnIGFuZCBjYydpbmcgcmFkZXh0 QGlldGYub3JnLg0KPg0KPiBUaGUgZHJhZnQgaXMgcG9zdGVkIGhlcmUuLi4gDQo+IGh0dHBzOi8v bmFtMDUuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy RnRvb2wNCj4gcy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1tYXNzYW1lbm8tcmFkaXVzLWxiLTAw JmFtcDtkYXRhPTAyJTdDMDElN0NkYQ0KPiBuLm1hc3NhbWVubyU0MHlhbGUuZWR1JTdDMzRlMzRj ZmFjNTcwNGE5Yzc2YzgwOGQ4MjI3YWE2NmMlN0NkZDhjYmViYjIxDQo+IDM5NGRmOGI0MTE0ZTNl ODdhYmViNWMlN0MwJTdDMCU3QzYzNzI5NzI1NzQ2MjA4NzY3MyZhbXA7c2RhdGE9Z1h0UW9sb1cN Cj4gcXZYc2pUZHdrJTJCJTJGdUJlN1dmcE5zNExaWUJlQXBLWU53cWpRJTNEJmFtcDtyZXNlcnZl ZD0wDQo+DQo+IERvIEkgbmVlZCBhbiBvZmZpY2lhbCBJRVRGIHNwb25zb3I/ICBXb3VsZCBpdCBo ZWxwIHRvIHRyeSBhbmQgZ2V0IGEgdmVuZG9yIGludGVyZXN0ZWQgaW4gaW1wbGVtZW50aW5nIHRo ZSBwcm90b2NvbD8gIENpc2NvIGlzIG91ciBwcmltYXJ5IHZlbmRvciBhdCBZYWxlIFVuaXZlcnNp dHkuICBJIHdhcyB3b25kZXJpbmcgaWYgdGhlcmUgaXMgYW55b25lIG9uIGVpdGhlciBvZiB0aGVz ZSB3b3JraW5nIGdyb3VwcyB0aGF0IGNvbW11bmljYXRlcyB3aXRoIENpc2NvIHBlb3BsZSBvbiBh IHJlZ3VsYXIgYmFzaXM/DQo+DQo+IFRoYW5rIHlvdSBmb3IgeW91ciBoZWxwLg0KPg0KPiAtLURh bg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGVmYW4gV2ludGVy IDxzdGVmYW4ud2ludGVyQHJlc3RlbmEubHU+DQo+IFNlbnQ6IEZyaWRheSwgSnVseSAzLCAyMDIw IDAxOjUyDQo+IFRvOiBKb2UgQ2xhcmtlIChqY2xhcmtlKSA8amNsYXJrZUBjaXNjby5jb20+OyBN YXNzYW1lbm8sIERhbiANCj4gPGRhbi5tYXNzYW1lbm9AeWFsZS5lZHU+DQo+IENjOiB3YXJyZW5A a3VtYXJpLm5ldDsgQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+OyBSb21hbiBEYW55bGl3 IA0KPiA8cmRkQGNlcnQub3JnPjsgUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28u Y29tPjsgDQo+IE9wc0FXRy1DaGFpcnMgPG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc+OyByYWRleHQt Y2hhaXJzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBSQURJVVMgRXh0ZW5zaW9uLCBHZXR0aW5n IFN0YXJ0ZWQNCj4NCj4gSGVsbG8gSm9lLA0KPg0KPg0KPiB0aGFua3MgZm9yIHJlYWNoaW5nIG91 dC4gUkFERVhUIGlzIGRvcm1hbnQgc2luY2UgYSBudW1iZXIgb2YgeWVhcnMgYWxyZWFkeS4gSSdt IGFmcmFpZCBpZiB5b3Ugd2VyZSB0byBzZW5kIHRoZSBkb2N1bWVudCB0aGF0IHdheSwgeW91IHdv dWxkIGdldCBsaXR0bGUgdG8gbm8gcmV2aWV3Lg0KPg0KPg0KPiBJIHRoaW5rIHRoZSBiZXN0IHdh eSBmb3J3YXJkIGlzIHRvIHRha2UgdGhpcyB0byBPUFNBV0cgYW5kIHNlbmQgYSBtYWlsIHRvIHJh ZGV4dCBhYm91dCB0aGUgZHJhZnQganVzdCBpbiBjYXNlLg0KPg0KPg0KPiBHcmVldGluZ3MsDQo+ DQo+DQo+IFN0ZWZhbiBXaW50ZXINCj4NCj4NCj4gQW0gMzAuMDYuMjAgdW0gMTc6MjEgc2Nocmll YiBKb2UgQ2xhcmtlIChqY2xhcmtlKToNCj4gPiBUaGFua3MsIERhbi4gIEnigJltIGFsc28gY29w eWluZyB0aGUgcmFkZXh0LWNoYWlycyB0byBnZXQgdGhlaXIgcGVyc3BlY3RpdmUgb24gdGhpcy4N Cj4gPg0KPiA+IEpvZQ0KPiA+DQo+ID4+IE9uIEp1biAzMCwgMjAyMCwgYXQgMTE6MDMsIE1hc3Nh bWVubywgRGFuIDxkYW4ubWFzc2FtZW5vQHlhbGUuZWR1PiB3cm90ZToNCj4gPj4NCj4gPj4gV2Fy cmVuLA0KPiA+Pg0KPiA+PiBJIGhhdmUgdGhlIFJBRElVUyBleHRlbnNpb24gZHJhZnQgbm93IHBv c3RlZDoNCj4gPj4gaHR0cHM6Ly9uYW0wNS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGdA0KPiA+PiBvbyANCj4gPj4gbHMuaWV0Zi5vcmclMkZodG1s JTJGZHJhZnQtbWFzc2FtZW5vLXJhZGl1cy1sYi0wMCZhbXA7ZGF0YT0wMiU3QzAxJQ0KPiA+PiA3 QyANCj4gPj4gZGFuLm1hc3NhbWVubyU0MHlhbGUuZWR1JTdDYzBiM2MwMWEzYTlkNDRkMDA0YzMw OGQ4MWYxNTJlZjIlN0NkZDhjYg0KPiA+PiBlYiANCj4gPj4gYjIxMzk0ZGY4YjQxMTRlM2U4N2Fi ZWI1YyU3QzAlN0MwJTdDNjM3MjkzNTIzMTM5MzkyMzQxJmFtcDtzZGF0YT03ZA0KPiA+PiBPcA0K PiA+PiBabVU1WHNqMnR1c2YyRml1a3F2MW94ZDJiOHVMNFBvJTJCSTA0aHclMkJFJTNEJmFtcDty ZXNlcnZlZD0wDQo+ID4+DQo+ID4+IEFic3RyYWN0DQo+ID4+DQo+ID4+ICAgVGhpcyBkb2N1bWVu dCBkZXNjcmliZXMgYSBtZXRob2QgZm9yIGEgTmV0d29yayBBY2Nlc3MgU2VydmVyIChOQVMpIHRv DQo+ID4+ICAgZHluYW1pY2FsbHkgZGlzY292ZXIgYWxsIGF2YWlsYWJsZSBSQURJVVMgc2VydmVy cy4gIEl0IGRlZmluZXMgYSBuZXcNCj4gPj4gICBtZXNzYWdlIHR5cGUgd2l0aGluIHRoZSBTVEFU VVMtU0VSVkVSIG1lc3NhZ2UsIHdoaWNoIGlzIHJlcXVlc3RlZCBieQ0KPiA+PiAgIHRoZSBOQVMg YW5kIHByb3ZpZGVkIGJ5IHRoZSBSQURJVVMgc2VydmVyLiAgVGhlIE5BUyBpcyB0aGVuIGFibGUg dG8NCj4gPj4gICBsb2FkIGJhbGFuY2UgaXRzIFJBRElVUyBtZXNzYWdlcyBhY3Jvc3MgbXVsdGlw bGUgUkFESVVTIHNlcnZlcnMgYmFzZWQNCj4gPj4gICBvbiBwcmlvcml0eSBhbmQgd2VpZ2h0IHN1 cHBsaWVkIGJ5IHRoZSBpbml0aWFsIHNlcnZlci4NCj4gPj4NCj4gPj4gQmFzZSBvbiB0aGUgZHJh ZnQgZG8geW91IGhhdmUgYSBiZXR0ZXIgaWRlYSBvbiBpZiB0aGlzIHNob3VsZCBiZSBwb3NlZCBp bnRvIFJBREVYVCBvciBPUFNBV0c/ICBJIG11c3QgYWRtaXQgSSBhbSBub3QgZmFtaWxpYXIgd2l0 aCBlaXRoZXIgb2YgdGhlc2UgZ3JvdXBzLg0KPiA+Pg0KPiA+PiBUaGFuayB5b3UgZm9yIHlvdXIg aGVscC4NCj4gPj4NCj4gPj4gLS1EYW4NCj4gPj4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4gRnJvbTogTWFzc2FtZW5vLCBEYW4NCj4gPj4gU2VudDogVGh1cnNkYXksIEp1 bmUgMjUsIDIwMjAgMTA6NTYNCj4gPj4gVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9u QGNpc2NvLmNvbT4NCj4gPj4gQ2M6IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PjsgUm9t YW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPjsgDQo+ID4+IE9wc0FXRy1DaGFpcnMgPG9wc2F3Zy1j aGFpcnNAaWV0Zi5vcmc+OyBXYXJyZW4gS3VtYXJpIA0KPiA+PiA8d2FycmVuQGt1bWFyaS5uZXQ+ DQo+ID4+IFN1YmplY3Q6IFJFOiBSQURJVVMgRXh0ZW5zaW9uLCBHZXR0aW5nIFN0YXJ0ZWQNCj4g Pj4NCj4gPj4gUm9iLA0KPiA+PiBUaGFuayB5b3UgYW5kIHRoZSBleHRlbmRlZCB0ZWFtIGZvciBh bGwgeW91ciBoZWxwLiAgSSBoYXZlIHVwbG9hZGVkIGRyYWZ0LW1hc3NhbWVuby1yYWRpdXMtbGIg dG8gdGhlIEktRCBTdWJtaXNzaW9uIHN5c3RlbS4gIEFsc28gYXR0YWNoZWQgaXMgdGhlIFBERiB2 ZXJzaW9uLg0KPiA+Pg0KPiA+PiBJJ20gdmVyeSBtdWNoIGludGVyZXN0ZWQgaW4gc2VlaW5nIGhv dyB0aGUgcHJvY2VzcyBnb2VzIGZyb20gaGVyZS4gIFBsZWFzZSBsZXQgbWUga25vdyBob3cgSSBt YXkgYmUgb2YgYXNzaXN0YW5jZS4NCj4gPj4NCj4gPj4gLS1EYW4NCj4gPj4NCj4gPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogV2FycmVuIEt1bWFyaSA8d2FycmVuQGt1 bWFyaS5uZXQ+DQo+ID4+IFNlbnQ6IE1vbmRheSwgSnVuZSAyMiwgMjAyMCAxODowMA0KPiA+PiBU bzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPg0KPiA+PiBDYzogQmVu amFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+OyBNYXNzYW1lbm8sIERhbiANCj4gPj4gPGRhbi5t YXNzYW1lbm9AeWFsZS5lZHU+OyBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyANCj4gPj4g T3BzQVdHLUNoYWlycyA8b3BzYXdnLWNoYWlyc0BpZXRmLm9yZz4NCj4gPj4gU3ViamVjdDogUmU6 IFJBRElVUyBFeHRlbnNpb24sIEdldHRpbmcgU3RhcnRlZA0KPiA+Pg0KPiA+PiBPbiBNb24sIEp1 biAyMiwgMjAyMCBhdCAxOjA2IFBNIFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2Nv LmNvbT4gd3JvdGU6DQo+ID4+PiBIaSBCZW4sDQo+ID4+Pg0KPiA+Pj4gR29vZCBjYXRjaCByZSBS YWRleHQsIGNvcHlpbmcgV2FycmVuLiAgV2FycmVuLCB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciBS QURFWFQgaXMgc3RpbGwgYWN0aXZlIGFuZCB0YWtpbmcgbmV3IHdvcmssIG9yIHdoZXRoZXIgaXQg c2hvdWxkIGdvIHRvIE9QU0FXRyBpbnN0ZWFkPyAgSSBoYXZlIGEgc2xpZ2h0IGNvbmNlcm4gd2hl dGhlciB3ZSB3aWxsIGdldCBlbm91Z2ggaW50ZXJlc3QgZm9yIHRoaXMgd29yayBpbiBPUFNBV0cg Li4uDQo+ID4+IFdpdGhvdXQga25vd2luZyBhIGJ1bmNoIG1vcmUgYWJvdXQgdGhlIGRyYWZ0IEkg ZG9uJ3QgcmVhbGx5IHRoaW5rIHRoYXQgdGhpcyBpcyBhIHF1ZXN0aW9uIHRoYXQgSSBjYW4gdXNl ZnVsbHkgd2VpZ2ggaW4gb24uDQo+ID4+DQo+ID4+IElmIGl0IGlzIGFuIGV4dGVuc2lvbiB0byBS QURJVVMvaXMgaGVhdmlseSBSQURJVVMgZm9jdXNlZCwgdGhlbiBSQURFWFQgaXMgcHJvYmFibHkg dGhlIHJpZ2h0IHBsYWNlIC0tIGJ1dCwgaXQgY291bGQgYWx3YXlzIGJlIGFpbWVkIGF0IFJBREVY VCAocHV0IC1yYWRleHQtIGluIHRoZSBkcmFmdCBuYW1lKSwgYnV0IHdlIGNhbiB0cnkgYW5kIHN0 aXIgdXAgc29tZSBpbnRlcmVzdCBpbiBPUFNBV0cuIElmIGl0IHR1cm5zIG91dCB0aGF0IGl0IGlz IFJBRElVUyByZWxhdGVkLCBhbmQgUkFERVhUIGRvZXNuJ3Qgd2FudCB0byBwaWNrIGl0IHVwIGFu ZCBydW4gd2l0aCBpdCwgcGVyaGFwcyB0aGF0J3MgYSBzdHJvbmcgc2lnbmFsIHRoYXQgUkFERVhU IHNob3VsZCBiZSBjbG9zZWQuLi4/DQo+ID4+DQo+ID4+IFcNCj4gPj4NCj4gPj4+IFJlZ2FyZHMs DQo+ID4+PiBSb2INCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4+Pj4gRnJvbTogQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+DQo+ID4+Pj4g U2VudDogMjEgSnVuZSAyMDIwIDAzOjQyDQo+ID4+Pj4gVG86IE1hc3NhbWVubywgRGFuIDxkYW4u bWFzc2FtZW5vQHlhbGUuZWR1Pg0KPiA+Pj4+IENjOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndp bHRvbkBjaXNjby5jb20+OyBSb21hbiBEYW55bGl3IA0KPiA+Pj4+IDxyZGRAY2VydC5vcmc+OyBP cHNBV0ctQ2hhaXJzIDxvcHNhd2ctY2hhaXJzQGlldGYub3JnPg0KPiA+Pj4+IFN1YmplY3Q6IFJl OiBSQURJVVMgRXh0ZW5zaW9uLCBHZXR0aW5nIFN0YXJ0ZWQNCj4gPj4+Pg0KPiA+Pj4+IE9uIEZy aSwgSnVuIDE5LCAyMDIwIGF0IDEyOjU4OjEyUE0gKzAwMDAsIE1hc3NhbWVubywgRGFuIHdyb3Rl Og0KPiA+Pj4+PiBSb2IsDQo+ID4+Pj4+IFRoaXMgc291bmRzIGdyZWF0LiAgV2l0aCB0aGUgbGlu a3MgcHJvdmlkZWQgYnkgUm9tYW4gSSBhbSANCj4gPj4+Pj4gcmV2aWV3aW5nIHRoZQ0KPiA+Pj4+ IGxpdGVyYXR1cmUgdG8gbWFrZSBzdXJlIG15IGRyYWZ0IGhhcyBldmVyeXRoaW5nIGl0IG5lZWRz IHRvIHN0YXJ0IA0KPiA+Pj4+IHRoZSBwcm9jZXNzLiAgSSBmb3VuZCByZWZlcmVuY2VzIHRvIHht bDJyZmMgYW5kIGtyYW1kb3duLCB3aGljaCBJIA0KPiA+Pj4+IGFsc28gd2FudCB0byBydW4gaXQg dGhyb3VnaC4NCj4gPj4+Pj4gVGhhbmsgeW91IGZvciB5b3VyIGhlbHAuICBJIHdvdWxkIGJlIGhh cHB5IHRvIGhhdmUgc29tZW9uZSB0YWtlIA0KPiA+Pj4+PiBhIGxvb2sNCj4gPj4+PiBiZWZvcmUg aXQncyBwb3N0ZWQuICBBcyBzb29uIGFzIEkgaGF2ZSBpdCBmb3JtYXR0ZWQgY29ycmVjdGx5IA0K PiA+Pj4+IEknbGwgc2VuZCBpdCBvdmVyLiAgSXMgdGhlcmUgc29tZW9uZSBpbiBwYXJ0aWN1bGFy IEkgc2hvdWxkIHNlbmQgaXQgdG8/DQo+ID4+Pj4NCj4gPj4+PiBJIHdvdWxkIHJlY29tbWVuZCB1 cGxvYWRpbmcgdGhlIGludGVybmV0LWRyYWZ0IHRvIHRoZSBJRVRGIA0KPiA+Pj4+IGRhdGF0cmFj a2VyIGF0IA0KPiA+Pj4+IGh0dHBzOi8vbmFtMDUuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyDQo+ID4+Pj4gRmQNCj4gPj4+PiBhDQo+ID4+Pj4gdGF0 cmFja2VyLmlldGYub3JnJTJGc3VibWl0JTJGJmFtcDtkYXRhPTAyJTdDMDElN0NkYW4ubWFzc2Ft ZW5vJTQNCj4gPj4+PiAweQ0KPiA+Pj4+IGENCj4gPj4+PiBsZS5lZHUlN0MxMTJjYWNjNmRhNmE0 MGU2NTYwNzA4ZDgxNmY3YzBiOSU3Q2RkOGNiZWJiMjEzOTRkZjhiNDExNA0KPiA+Pj4+IGUzDQo+ ID4+Pj4gZQ0KPiA+Pj4+IDg3YWJlYjVjJTdDMCU3QzAlN0M2MzcyODQ2MDA2MzczMTMyNDkmYW1w O3NkYXRhPUVra1N3SEFCJTJCQVYzWFFEeiUyRnNZSk1zQkxpS3ltejZuNEJST1ZXR2JnN1lnJTNE JmFtcDtyZXNlcnZlZD0wIGFuZCB0aGVuIHNlbmRpbmcgYSBsaW5rIHRvIHRoYXQgZG9jdW1lbnQg dG8gYm90aCBvcHNhd2ctY2hhaXJzQGlldGYub3JnIGFuZCByYWRleHQtY2hhaXJzQGlldGYub3Jn LiAgSXQncyBhbHNvIG9rYXkgdG8gc2tpcCB0aGUgZmlyc3QgcGFydCBhbmQgc2VuZCB0aGUgZG9j dW1lbnQgaXRzZWxmIHRvIHRob3NlIGFkZHJlc3Nlcy4NCj4gPj4+Pg0KPiA+Pj4+IFRoZSByYWRl eHQgKFJBRElVUyBFeHRlbnNpb25zKSB3b3JraW5nIGdyb3VwIGlzIG5vdCB2ZXJ5IGFjdGl2ZSAN Cj4gPj4+PiBhdCB0aGUgbW9tZW50LCB3aGljaCBpcyB3aHkgSSBhZ3JlZSB3aXRoIHRoZSBvdGhl cnMnIA0KPiA+Pj4+IHJlY29tbWVuZGF0aW9ucyB0byBhc2sgdGhlIE9QU0FXRyB3b3JraW5nIGdy b3VwIGNoYWlycycgYWR2aWNlIGFzIHdlbGwuDQo+ID4+Pj4NCj4gPj4+PiBIb3BlIHRoaXMgaGVs cHMsDQo+ID4+Pj4NCj4gPj4+PiBCZW4NCj4gPj4NCj4gPj4NCj4gPj4gLS0NCj4gPj4gSSBkb24n dCB0aGluayB0aGUgZXhlY3V0aW9uIGlzIHJlbGV2YW50IHdoZW4gaXQgd2FzIG9idmlvdXNseSBh IGJhZCBpZGVhIGluIHRoZSBmaXJzdCBwbGFjZS4NCj4gPj4gVGhpcyBpcyBsaWtlIHB1dHRpbmcg cmFiaWQgd2Vhc2VscyBpbiB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZyByZWdyZXQg YXQgaGF2aW5nIGNob3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRoYXQg cGFpciBvZiBwYW50cy4NCj4gPj4gICAtLS1tYWYNCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gcmFkZXh0IG1haWxpbmcgbGlzdA0KPiByYWRleHRA aWV0Zi5vcmcNCj4gaHR0cHM6Ly9uYW0wNS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lg0KPiBpZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5m byUyRnJhZGV4dCZhbXA7ZGF0YT0wMiU3QzAxJTdDZGFuLm1hc3NhbWVuDQo+IG8lNDB5YWxlLmVk dSU3QzM0ZTM0Y2ZhYzU3MDRhOWM3NmM4MDhkODIyN2FhNjZjJTdDZGQ4Y2JlYmIyMTM5NGRmOGI0 MTENCj4gNGUzZTg3YWJlYjVjJTdDMCU3QzAlN0M2MzcyOTcyNTc0NjIwODc2NzMmYW1wO3NkYXRh PWphYVZWbWdVZThZMnVPZXJtcA0KPiBBS1lxNmlNNk9RY0VKQ1VNTlolMkY4Q0d3NmslM0QmYW1w O3Jlc2VydmVkPTANCg==