From nobody Fri Apr 7 08:36:39 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977111294BC for ; Fri, 7 Apr 2017 08:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 nSAidAsfRJOg for ; Fri, 7 Apr 2017 08:36:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5529129449 for ; Fri, 7 Apr 2017 08:36:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 79D17B80CE5; Fri, 7 Apr 2017 08:36:16 -0700 (PDT) To: stefan.winter@restena.lu, mikem@airspayce.com, bclaise@cisco.com, warren@kumari.net, lionel.morand@orange.com, stefan.winter@restena.lu X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aland@freeradius.org, radext@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170407153616.79D17B80CE5@rfc-editor.org> Date: Fri, 7 Apr 2017 08:36:16 -0700 (PDT) Archived-At: Subject: [radext] [Technical Errata Reported] RFC7585 (4991) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:36:38 -0000 The following errata report has been submitted for RFC7585, "Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7585&eid=4991 -------------------------------------- Type: Technical Reported by: Alan DeKok Section: GLOBAL Original Text ------------- Corrected Text -------------- Notes ----- The document describes how to look up realms, but doesn't describe what to do after that. i.e. are the lookups cached? Are the lookups done for every request that comes in? This gives little guidance for an implementor. I suggest leveraging the "logical AAA routing table" described in RFC 7542 Section 3. In short form: * a client MUST maintain a table of known dynamic realms. * the table MUST be keyed by the realm name, and the contents MUST be server-specific information as described in RFC 7542 Section 3 * when a realm is being looked up, the realm SHOULD be inserted into the table with a "pending" flag, so subsequent requests during the lookup process do not cause additional lookups to be made * if server validation fails, the realm SHOULD be updated with a "failed" state and a TTL, so that subsequent requests do not cause additional lookups for a period of time. No server information should be stored for this entry. i.e. the realm is marked as "failed", the corresponding server MUST NOT be marked as "failed". This prevents attacks where a malicious actor could point their realm to an unknowing third-party server, and cause poorly implemented proxies to mark it "failed". * if server validation succeeds, the realm MUST be updated with a "live" state (and a TTL), so that subsequent requests go to the same server without additional lookups * if server validation succeeds, all realms in the TLS "subject alternative names" presented by the server SHOULD be inserted into the realm table, all pointing to the same server definition, so that subsequent requests for those other realms do not cause additional lookups to be made. * servers which have been dynamically looked up MUST NOT be added to any global pool of servers. i.e. the lookup is always "realm -> server", and not "There's a known server at this IP address" I thought we had a short discussion of some of these topics on RADEXT, but I can't find it in the archives. I think these comments are substantial enough to warrant "wait for document update". I just wanted to ensure they weren't lost. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7585 (draft-ietf-radext-dynamic-discovery-15) -------------------------------------- Title : Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) Publication Date : October 2015 Author(s) : S. Winter, M. McCauley Category : EXPERIMENTAL Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Apr 7 08:38:29 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEB11294BC for ; Fri, 7 Apr 2017 08:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FolpDHp8KGO5 for ; Fri, 7 Apr 2017 08:38:25 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id CB9A5127444 for ; Fri, 7 Apr 2017 08:38:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 18CCB60B for ; Fri, 7 Apr 2017 15:38:24 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6VHy-0qM--S for ; Fri, 7 Apr 2017 15:38:24 +0000 (UTC) Received: from [192.168.20.91] (CPEf4cc552207f0-CM00fc8dce0fa0.cpe.net.cable.rogers.com [99.230.129.191]) by mail.networkradius.com (Postfix) with ESMTPSA id AE831B1 for ; Fri, 7 Apr 2017 15:38:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <20170407153616.79D17B80CE5@rfc-editor.org> Date: Fri, 7 Apr 2017 11:38:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170407153616.79D17B80CE5@rfc-editor.org> To: radext@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] [Technical Errata Reported] RFC7585 (4991) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:38:28 -0000 Me causing trouble again. :( I think this all makes sense, and I didn't see anywhere in the RFC = were these issues were discussed. > On Apr 7, 2017, at 11:36 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7585, > "Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the = Network Access Identifier (NAI)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7585&eid=3D4991 >=20 > -------------------------------------- > Type: Technical > Reported by: Alan DeKok >=20 > Section: GLOBAL >=20 > Original Text > ------------- >=20 >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- > The document describes how to look up realms, but doesn't describe = what to do after that. i.e. are the lookups cached? Are the lookups = done for every request that comes in? >=20 > This gives little guidance for an implementor. >=20 > I suggest leveraging the "logical AAA routing table" described in RFC = 7542 Section 3. In short form: >=20 > * a client MUST maintain a table of known dynamic realms. >=20 > * the table MUST be keyed by the realm name, and the contents MUST be = server-specific information as described in RFC 7542 Section 3 >=20 > * when a realm is being looked up, the realm SHOULD be inserted into = the table with a "pending" flag, so subsequent requests during the = lookup process do not cause additional lookups to be made >=20 > * if server validation fails, the realm SHOULD be updated with a = "failed" state and a TTL, so that subsequent requests do not cause = additional lookups for a period of time. No server information should = be stored for this entry. i.e. the realm is marked as "failed", the = corresponding server MUST NOT be marked as "failed". This prevents = attacks where a malicious actor could point their realm to an unknowing = third-party server, and cause poorly implemented proxies to mark it = "failed". >=20 > * if server validation succeeds, the realm MUST be updated with a = "live" state (and a TTL), so that subsequent requests go to the same = server without additional lookups >=20 > * if server validation succeeds, all realms in the TLS "subject = alternative names" presented by the server SHOULD be inserted into the = realm table, all pointing to the same server definition, so that = subsequent requests for those other realms do not cause additional = lookups to be made. >=20 > * servers which have been dynamically looked up MUST NOT be added to = any global pool of servers. i.e. the lookup is always "realm -> = server", and not "There's a known server at this IP address" >=20 > I thought we had a short discussion of some of these topics on RADEXT, = but I can't find it in the archives. >=20 > I think these comments are substantial enough to warrant "wait for = document update". I just wanted to ensure they weren't lost. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7585 (draft-ietf-radext-dynamic-discovery-15) > -------------------------------------- > Title : Dynamic Peer Discovery for RADIUS/TLS and = RADIUS/DTLS Based on the Network Access Identifier (NAI) > Publication Date : October 2015 > Author(s) : S. Winter, M. McCauley > Category : EXPERIMENTAL > Source : RADIUS EXTensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Fri Apr 7 10:59:17 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0771296EA for ; Fri, 7 Apr 2017 10:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 AAmFcPVSWQc8 for ; Fri, 7 Apr 2017 10:58:59 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5A8C1296CE for ; Fri, 7 Apr 2017 10:58:57 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id DBC0E40D7A for ; Fri, 7 Apr 2017 19:58:55 +0200 (CEST) To: radext@ietf.org References: <20170407153616.79D17B80CE5@rfc-editor.org> From: Stefan Winter Organization: RESTENA Message-ID: Date: Fri, 7 Apr 2017 19:58:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170407153616.79D17B80CE5@rfc-editor.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [radext] [Technical Errata Reported] RFC7585 (4991) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:59:08 -0000 Hello, Am 07.04.2017 um 17:36 schrieb RFC Errata System: > The following errata report has been submitted for RFC7585, > "Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7585&eid=4991 > > -------------------------------------- > Type: Technical > Reported by: Alan DeKok > > Section: GLOBAL > > Original Text > ------------- > > > Corrected Text > -------------- > > > Notes > ----- > The document describes how to look up realms, but doesn't describe what to do after that. i.e. are the lookups cached? Are the lookups done for every request that comes in? Well, there's section 3.4.4 "Validity of results" which has some amount of text on that topic: "After executing the above algorithm, the RADIUS server establishes a connection to a home server from the result set. [...] When a connection is open and the smallest of the Effective TTL value that was learned during discovering the server has not expired, subsequent new user sessions for the realm that corresponds to that open connection SHOULD reuse the existing connection and SHOULD NOT re-execute the discovery algorithm nor open a new connection. To allow for a change of configuration, a RADIUS server SHOULD re-execute the discovery algorithm after the Effective TTL that is associated with this connection has expired. The server SHOULD keep the session open during this reassessment to avoid closure and immediate reopening of the connection should the result not have changed." That's a probably slightly convoluted form of saying: * keep up sessions until DNS validity TTLs tell you to stop. * Then, re-check if DNS changed. * Do no drop connections on the floor until you're sure you've got to. > > This gives little guidance for an implementor. > > I suggest leveraging the "logical AAA routing table" described in RFC 7542 Section 3. In short form: > > * a client MUST maintain a table of known dynamic realms. > > * the table MUST be keyed by the realm name, and the contents MUST be server-specific information as described in RFC 7542 Section 3 > > * when a realm is being looked up, the realm SHOULD be inserted into the table with a "pending" flag, so subsequent requests during the lookup process do not cause additional lookups to be made With the text above, is this needed? I would think that internal housekeeping like deciding to store the data in a table, and that it has keys, and what this key has to be is *too* much implementation specific and does not need to be in an RFC? > * if server validation fails, the realm SHOULD be updated with a "failed" state and a TTL, so that subsequent requests do not cause additional lookups for a period of time. No server information should be stored for this entry. i.e. the realm is marked as "failed", the corresponding server MUST NOT be marked as "failed". This prevents attacks where a malicious actor could point their realm to an unknowing third-party server, and cause poorly implemented proxies to mark it "failed". The same section 3.4.4 goes on to state: "Should the algorithm above terminate with O-1 = { empty set }, the RADIUS server SHOULD NOT attempt another execution of this algorithm for the same target realm before the timeout O-2 has passed." Is that not enough? I you want to include a failed TLS connection setup phase result in the negative result state then that's probably more than an errata can do: it's not in scope of the RFC, it only defines the algorithm to find a set of servers to talk to. It hands off to RFC6614 once the server to talk to is known. A tighter integration between those two phases is certainly desirable (and a useful thing to consider when thinking about the update & move of the specs from Experimental to Standards Track). > * if server validation succeeds, the realm MUST be updated with a "live" state (and a TTL), so that subsequent requests go to the same server without additional lookups See above. > * if server validation succeeds, all realms in the TLS "subject alternative names" presented by the server SHOULD be inserted into the realm table, all pointing to the same server definition, so that subsequent requests for those other realms do not cause additional lookups to be made. That is in principle a good suggestion. However the discovery process also yielded some meta data about the server: there's a priority order of servers. For a different realm, there might be different discovery results with a different top-priority target; but the same server can still be configured to serve the realm, but with a lower priority. The mechanism above would mean that a client which has learned the target for one realm will also talk to that same target about another realm without validating that it is the one to talk to /in priority/. That may lead to results not expected by the owner of that realm. > * servers which have been dynamically looked up MUST NOT be added to any global pool of servers. i.e. the lookup is always "realm -> server", and not "There's a known server at this IP address" Well, that's how the algorithm is set up. The input is a realm, the output is a set of servers. It is implicit that there's a link between the input and the output of the algorithm. Any other interpretation of the algorithm's results appear counter-intuitive to me. > I thought we had a short discussion of some of these topics on RADEXT, but I can't find it in the archives. > > I think these comments are substantial enough to warrant "wait for document update". I just wanted to ensure they weren't lost. There certainly was discussion at some meetings. Many of those led to text updates; which is why section 3.4.4 has corresponding text. Can you re-check the document with section 3.4.4 in mind and provide a more narrow description on what text exactly you think needs to be corrected/added, and where? Greetings, Stefan Winter > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7585 (draft-ietf-radext-dynamic-discovery-15) > -------------------------------------- > Title : Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) > Publication Date : October 2015 > Author(s) : S. Winter, M. McCauley > Category : EXPERIMENTAL > Source : RADIUS EXTensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > From nobody Fri Apr 7 16:03:57 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B95126BF6 for ; Fri, 7 Apr 2017 16:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fP_ymlcOHdyi for ; Fri, 7 Apr 2017 16:03:37 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 699911294C1 for ; Fri, 7 Apr 2017 16:01:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id CC2F397C; Fri, 7 Apr 2017 23:01:53 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7XNwJPH5Kyg; Fri, 7 Apr 2017 23:01:53 +0000 (UTC) Received: from [10.255.251.140] (unknown [207.164.22.10]) by mail.networkradius.com (Postfix) with ESMTPSA id 080AEDE; Fri, 7 Apr 2017 23:01:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Fri, 7 Apr 2017 19:01:50 -0400 Cc: radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0EC0AC7E-04FE-416F-ABF3-92FFB07C8EA4@deployingradius.com> References: <20170407153616.79D17B80CE5@rfc-editor.org> To: Winter Stefan X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] [Technical Errata Reported] RFC7585 (4991) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 23:03:47 -0000 On Apr 7, 2017, at 1:58 PM, Stefan Winter = wrote: >=20 > Well, there's section 3.4.4 "Validity of results" which has some = amount > of text on that topic: Essentially "subsequent packets for an open connection should re-use = that connection". >> * when a realm is being looked up, the realm SHOULD be inserted into = the table with a "pending" flag, so subsequent requests during the = lookup process do not cause additional lookups to be made >=20 > With the text above, is this needed? I would think that internal > housekeeping like deciding to store the data in a table, and that it = has > keys, and what this key has to be is *too* much implementation = specific > and does not need to be in an RFC? It would be good to recommend that only one connection discover is = ongoing at a time. This is an issue of network overload, not = implementation IMHO. >> * if server validation fails, the realm SHOULD be updated with a = "failed" state and a TTL, so that subsequent requests do not cause = additional lookups for a period of time. No server information should = be stored for this entry. i.e. the realm is marked as "failed", the = corresponding server MUST NOT be marked as "failed". This prevents = attacks where a malicious actor could point their realm to an unknowing = third-party server, and cause poorly implemented proxies to mark it = "failed". >=20 > The same section 3.4.4 goes on to state: >=20 > "Should the algorithm above terminate with O-1 =3D { empty set }, the > RADIUS server SHOULD NOT attempt another execution of this algorithm > for the same target realm before the timeout O-2 has passed." >=20 > Is that not enough? Yes, it's largely the same thing. It also doesn't say what to do with = requests for that realm. Discard them? Reject them? RADIUS is bad that way. :( > I you want to include a failed TLS connection setup > phase result in the negative result state then that's probably more = than > an errata can do: it's not in scope of the RFC, it only defines the > algorithm to find a set of servers to talk to. It hands off to RFC6614 > once the server to talk to is known. The dynamic discovery RFC should also say what to do when thing go = wrong. This isn't an issue for RFC 6614, I think. > A tighter integration between those two phases is certainly desirable > (and a useful thing to consider when thinking about the update & move = of > the specs from Experimental to Standards Track) I agree. >> * if server validation succeeds, all realms in the TLS "subject = alternative names" presented by the server SHOULD be inserted into the = realm table, all pointing to the same server definition, so that = subsequent requests for those other realms do not cause additional = lookups to be made. >=20 > That is in principle a good suggestion. However the discovery process > also yielded some meta data about the server: there's a priority order > of servers. For a different realm, there might be different discovery > results with a different top-priority target; but the same server can > still be configured to serve the realm, but with a lower priority. Sure. > The mechanism above would mean that a client which has learned the > target for one realm will also talk to that same target about another > realm without validating that it is the one to talk to /in priority/. > That may lead to results not expected by the owner of that realm. Sure. It just would be nice to avoid the discovery phase in some = cases. >> * servers which have been dynamically looked up MUST NOT be added to = any global pool of servers. i.e. the lookup is always "realm -> = server", and not "There's a known server at this IP address" >=20 > Well, that's how the algorithm is set up. The input is a realm, the > output is a set of servers. It is implicit that there's a link between > the input and the output of the algorithm. Any other interpretation of > the algorithm's results appear counter-intuitive to me. It's described, but isn't as explicit as the text in RFC 7542. As an implementor, it's nice to know what information I need to track, = and what state changes I need to make in order to implement the = protocol. The existing document describes the lookup algorithm in detail, but is = a little more vague about what information is tracked, and what state = changes are made. >> I thought we had a short discussion of some of these topics on = RADEXT, but I can't find it in the archives. >>=20 >> I think these comments are substantial enough to warrant "wait for = document update". I just wanted to ensure they weren't lost. >=20 > There certainly was discussion at some meetings. Many of those led to > text updates; which is why section 3.4.4 has corresponding text. >=20 > Can you re-check the document with section 3.4.4 in mind and provide a > more narrow description on what text exactly you think needs to be > corrected/added, and where? I'd like more text on what to do as an implementor, and what to do = when things go wrong. I think we can leave the errata as "hold for document update", so that = the next rev can add some more text based on my comments. Alan DeKok. From nobody Tue Apr 18 12:54:54 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBB3127A91 for ; Tue, 18 Apr 2017 12:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pme5Iu3Ptktx for ; Tue, 18 Apr 2017 12:54:51 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 80E561201F2 for ; Tue, 18 Apr 2017 12:54:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 731E91653 for ; Tue, 18 Apr 2017 19:54:50 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xt5KwVKxJtm8 for ; Tue, 18 Apr 2017 19:54:50 +0000 (UTC) Received: from [192.168.20.234] (CPEf4cc552207f0-CM00fc8dce0fa0.cpe.net.cable.rogers.com [99.230.129.191]) by mail.networkradius.com (Postfix) with ESMTPSA id 0F96DB1 for ; Tue, 18 Apr 2017 19:54:49 +0000 (UTC) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <361AC9F2-4CFE-46D5-A893-CBEDAFFA85B8@deployingradius.com> Date: Tue, 18 Apr 2017 15:54:48 -0400 To: radext@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 19:54:53 -0000 I've been having offline conversations with the authors of the = draft-chen-radext-extended-header. My comments on the draft and process = are: * there's no need to add provisions for extending the Code field. = Having that in this document confuses people, and makes them less likely = to support the other parts of it * The "status" field should similarly be removed from the document. = Instead, just the presence of the attribute in a reply should be good = enough. * using the 4-octet identifier *instead of* the normal ID means the = protocol is being changed, this cannot be done. * the changes MUST interoperate with existing RADIUS clients and servers = that don't implement this. * i.e. the new systems MUST be able to either detect that the old = systems don't support the extended ID, *or* the old systems MUST be able = to work as before when sent "new" packets. It looks like it's hard to have a solution the problem which = satisfies all of the above. So I was thinking... What if the 8-bit IDs were *temporal*, in addition to tracking src/dst = ip/port? A simple approach would be put a "ID space timestamp" into = every packet. You'd want to send more than 256 packets per second, so = that's not good enough. What about using a simple sequence number instead? i.e. a RADIUS client sends 256 packets, each with sequence number 0. = The server is busy, and doesn't respond to them all. The client would like to send a second packet of (say) ID 0. It = notices that there's still a packet outstanding for ID 0, and increments = the sequence number. It can then send a packet containing { ID 0, SEQ 1 = }. The server will see this packet, and treat it differently from one = which contains { ID 0, SEQ 0 }. The sequence number should also be local to each src/dst ip/port = connection. I don't think there are technical reasons why this wouldn't work. It = may also be acceptable to the wider IETF as a minor variation to RADIUS. = (He said naively...) Alan DeKok. From nobody Tue Apr 18 13:29:37 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB8E12944B for ; Tue, 18 Apr 2017 13:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy2hoFJs_d0R for ; Tue, 18 Apr 2017 13:29:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C62127876 for ; Tue, 18 Apr 2017 13:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2131; q=dns/txt; s=iport; t=1492547375; x=1493756975; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Wl29c24OJQFsA+LWW/JSAp6I61pdYmYbeVFdSlUwRe8=; b=k/iTdn7HSKtX+bVVFLYKyS8C5hxi4oXLNfP4hxH8nluhAqh0u/JbQrdJ 1sOM2fXcogFvGDJrLVvEus7RhE6k78gJq04Oy1xTgR3/6POf3Bkte/K+Y xjpjsZ0OMMad6MBRNEShL3OooyTVHzR0i8zCAx958aliWAsQ4Vtvir+BO 0=; X-IronPort-AV: E=Sophos;i="5.37,219,1488844800"; d="scan'208";a="238128680" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2017 20:29:34 +0000 Received: from [10.41.56.28] ([10.41.56.28]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v3IKTXhr006154; Tue, 18 Apr 2017 20:29:34 GMT References: <149254265358.29077.17345225363228824406@ietfa.amsl.com> To: radext@ietf.org Cc: Enke Chen , Naiming Shen From: Enke Chen X-Forwarded-Message-Id: <149254265358.29077.17345225363228824406@ietfa.amsl.com> Message-ID: Date: Tue, 18 Apr 2017 13:29:33 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149254265358.29077.17345225363228824406@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: [radext] Fwd: I-D Action: draft-chen-radext-identifier-attr-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:29:37 -0000 Hi, Folks: The file handle has been renamed to better align with the proposed mechanism. --- 6. Document Change Log 6.1. Changes to draft-chen-radext-identifier-attr-00.txt o Posted the draft in April 2017. o Renamed it from draft-chen-radext-extended-header-02.txt with the "Status" field of the attribute changed to 2 bits, and the "Code" field changed to 14 bits. --- Thanks. -- Enke -------- Forwarded Message -------- Subject: I-D Action: draft-chen-radext-identifier-attr-00.txt Date: Tue, 18 Apr 2017 12:10:53 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RADIUS Identifier Attribute Authors : Enke Chen Naiming Shen Filename : draft-chen-radext-identifier-attr-00.txt Pages : 8 Date : 2017-04-18 Abstract: The limitation with the one-octet "Identifier" field in the RADIUS packet is well known. In this document we propose extensions to the RADIUS protocol to address this fundamental limitation, and thus allowing for more efficient and more scalable implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-radext-identifier-attr/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-chen-radext-identifier-attr-00 https://datatracker.ietf.org/doc/html/draft-chen-radext-identifier-attr-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Apr 18 15:47:28 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041761314AC for ; Tue, 18 Apr 2017 15:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgZj1KpnFHAi for ; Tue, 18 Apr 2017 15:47:26 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8773012945D for ; Tue, 18 Apr 2017 15:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4743; q=dns/txt; s=iport; t=1492555646; x=1493765246; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Y+YdQB8GhC8s+DfI8tU/zB1DzEFyOgIW7wpmIYBtANQ=; b=dLExJJVFnh3BO70lMnVnV9CA0Z+u0AVXpVa50n17zb6fn/xmrqyKyEDH Zeua7ssEAWptgMwm5G2h2j0qWN6ALk1ods48uuGRGMymFZGM/4SEMlQ2S 1CAC9pB2p+Vwe8bHD4nPoQSqC1ZtkcFEogghVDYbtyl1TyPLigFo29bn9 o=; X-IronPort-AV: E=Sophos;i="5.37,219,1488844800"; d="scan'208";a="234557358" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Apr 2017 22:47:25 +0000 Received: from [10.41.56.28] ([10.41.56.28]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3IMlOog005599; Tue, 18 Apr 2017 22:47:25 GMT To: Alan DeKok References: <361AC9F2-4CFE-46D5-A893-CBEDAFFA85B8@deployingradius.com> Cc: radext@ietf.org, Naiming Shen , Enke Chen From: Enke Chen Message-ID: Date: Tue, 18 Apr 2017 15:47:24 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <361AC9F2-4CFE-46D5-A893-CBEDAFFA85B8@deployingradius.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 22:47:28 -0000 Hi, Alan: Thanks for you comments. Please see my replies/comments inline. On 4/18/17 12:54 PM, Alan DeKok wrote: > I've been having offline conversations with the authors of the > draft-chen-radext-extended-header. My comments on the draft and process are: > > * there's no need to add provisions for extending the Code field. Having that > in this document confuses people, and makes them less likely to support the > other parts of it Out of 255 numbers for the Packet Type Codes, 52 are currently allocated. Given the popularity of RAIDUS, this number space may run out in the future. Although the Code field does not have to be enlarged together with the Identifier field, it just makes sense to do them together so that we go through the changes once and be done with it. There is little additional cost (in terms of development, memory and transmission) to cover the Code field, and its usage is optional until needed. > > * The "status" field should similarly be removed from the document. Instead, > just the presence of the attribute in a reply should be good enough. Without the "status" field, we are afraid that some implementation may just send back the unrecognized attribute. The field would certainly help make it more explicit and deterministic about whether the feature is supported by a device. > > * using the 4-octet identifier *instead of* the normal ID means the protocol > is being changed, this cannot be done. I am not sure what you mean by the statement "the protocol is being changed, this cannot be done". You seem to mean that "such change is not allowed"? If that is correct, then I am wondering what basis you have (other than personal opinion) for such a position. If there exists some official IETF rules that I am not aware of, please let me know. I have been involved in IETF (mostly in the routing area) for more than 20 years. AFAIK, any extension to an existing protocol is a change to the protocol, and such changes have been made and continue to be made all the time, and some by you in this radext working group :-) The existence of the the IETF and its Working Groups is to make protocol extensions and changes. > > * the changes MUST interoperate with existing RADIUS clients and servers that > don't implement this. Yes, absolutely. That is covered extensively in the draft using the "Status-Server" message for discovery of the feature before the larger Identifier field is carried in the attribute. Please let us know if you see any holes with backward compatibility. > > * i.e. the new systems MUST be able to either detect that the old systems don't > support the extended ID, *or* the old systems MUST be able to work as before when > sent "new" packets. That’s precisely the reason that the "Status-Server" message is used in the draft for discovery of the feature between a client and a server. > > It looks like it's hard to have a solution the problem which satisfies all of > the above. > > > So I was thinking... > > What if the 8-bit IDs were *temporal*, in addition to tracking src/dst ip/port? > A simple approach would be put a "ID space timestamp" into every packet. You'd > want to send more than 256 packets per second, so that's not good enough. > > What about using a simple sequence number instead? > > i.e. a RADIUS client sends 256 packets, each with sequence number 0. The server > is busy, and doesn't respond to them all. > > The client would like to send a second packet of (say) ID 0. It notices that > here's still a packet outstanding for ID 0, and increments the sequence number. > It can then send a packet containing { ID 0, SEQ 1 }. The server will see this > packet, and treat it differently from one which contains { ID 0, SEQ 0 }. > AFAIK, the RADIUS standard does not specify how the IDs are allocated, and that is completely left to the implementation and as a local matter on the sender. IMO deviation from such well-established practice will be challenging for backward compatibility and deployment. In addition, following the current RADIUS practice it remains an implementation decision how this new 4 bytes "ID" field is allocated. However, I do not see any value for combining this new 4-byte "ID" field with the existing one-byte "ID" field and using them both. Thanks again, -- Enke > The sequence number should also be local to each src/dst ip/port connection. > > I don't think there are technical reasons why this wouldn't work. It may also be > acceptable to the wider IETF as a minor variation to RADIUS. (He said naively...) > > Alan DeKok. > From nobody Tue Apr 18 17:16:43 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83CE129463 for ; Tue, 18 Apr 2017 17:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxlsSfUX8Cqn for ; Tue, 18 Apr 2017 17:16:39 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 140D81200C1 for ; Tue, 18 Apr 2017 17:16:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 253C51A89; Wed, 19 Apr 2017 00:16:38 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vab7gA2EklwC; Wed, 19 Apr 2017 00:16:37 +0000 (UTC) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id DE8F55B6; Wed, 19 Apr 2017 00:16:36 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Tue, 18 Apr 2017 20:16:34 -0400 Cc: radext@ietf.org, Naiming Shen Content-Transfer-Encoding: quoted-printable Message-Id: <1767D4FB-29BB-4E91-9339-1B40F3D3FC91@deployingradius.com> References: <361AC9F2-4CFE-46D5-A893-CBEDAFFA85B8@deployingradius.com> To: Enke Chen X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 00:16:42 -0000 On Apr 18, 2017, at 6:47 PM, Enke Chen wrote: > Out of 255 numbers for the Packet Type Codes, 52 are currently = allocated. Given > the popularity of RAIDUS, this number space may run out in the future. That's called "Diameter". :( > Although the Code field does not have to be enlarged together with the = Identifier > field, it just makes sense to do them together so that we go through = the changes > once and be done with it. There is little additional cost (in terms = of development, > memory and transmission) to cover the Code field, and its usage is = optional until > needed. The issue is solving one problem at a time. There is no *current* = need to extend the Code space. Therefore, there shouldn't be a proposal = to extend it. >>=20 >> * The "status" field should similarly be removed from the document. = Instead, >> just the presence of the attribute in a reply should be good enough. >=20 > Without the "status" field, we are afraid that some implementation may = just send > back the unrecognized attribute. The field would certainly help make = it more > explicit and deterministic about whether the feature is supported by a = device. I think it's safe to say that servers don't "echo" back attributes. If you need an explicit ACK, create one. Don't overload the contents = of an attribute. See RFC 6929 Section 6.3 for guidelines on using = Complex Data Types. >> * using the 4-octet identifier *instead of* the normal ID means the = protocol >> is being changed, this cannot be done. >=20 > I am not sure what you mean by the statement "the protocol is being = changed,=20 > this cannot be done". >=20 > You seem to mean that "such change is not allowed"? If that is = correct, then I > am wondering what basis you have (other than personal opinion) for = such a position. > If there exists some official IETF rules that I am not aware of, = please let me know. I mean that modifying RADIUS in minor ways is probably OK. Changing = the base RADIUS protocol is not. Making clients and servers change the meaning and interpretation of = the ID field is changing RADIUS. I don't think you will get consensus = from RADEXT, much less the IESG for this proposal. > I have been involved in IETF (mostly in the routing area) for more = than 20 years. > AFAIK, any extension to an existing protocol is a change to the = protocol, and such > changes have been made and continue to be made all the time, and some = by you in > this radext working group :-)=20 Sure. Except that *major* changes to RADIUS are called "Diameter". :( > AFAIK, the RADIUS standard does not specify how the IDs are allocated, = and that is > completely left to the implementation and as a local matter on the = sender. >=20 > IMO deviation from such well-established practice will be challenging = for backward > compatibility and deployment. It's no more challenging than your proposal to replace the ID field = entirely. > In addition, following the current RADIUS practice it remains an = implementation > decision how this new 4 bytes "ID" field is allocated. However, I do = not see any > value for combining this new 4-byte "ID" field with the existing = one-byte "ID" > field and using them both. There is likely no technical value. The issue is any change requires = consensus from RADEXT and IESG, which means the changes must be = *percieved* to be minor extensions to RADIUS. Alan DeKok. From nobody Tue Apr 18 17:52:52 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03B5129454 for ; Tue, 18 Apr 2017 17:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QfwMRtk_PY4 for ; Tue, 18 Apr 2017 17:52:49 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64CE126D74 for ; Tue, 18 Apr 2017 17:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4885; q=dns/txt; s=iport; t=1492563169; x=1493772769; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=hXBlJFj3b0z3w7ZRP9hO+FHu7sZLNXOXbLuZtiFJQa8=; b=OReDiHjb2Qfbj+RWCzrqK4sx4k66XzuB6vJwCKFPKqmpBZrrenmeHeMg QVLa9hykpKSPPTl5xBFCCAKZaP0OJ7gAZwwE+Z/5IWq9S6obDgpPDyoRX t1TGSH3A5YSYopqmnALZCCVb3xLCFO6J8KFdysty+kgtw/6Rm/pXcjPIO o=; X-IronPort-AV: E=Sophos;i="5.37,219,1488844800"; d="scan'208";a="232446462" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 00:52:48 +0000 Received: from [10.41.56.28] ([10.41.56.28]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3J0qmhS023431; Wed, 19 Apr 2017 00:52:48 GMT To: Alan DeKok References: <361AC9F2-4CFE-46D5-A893-CBEDAFFA85B8@deployingradius.com> <1767D4FB-29BB-4E91-9339-1B40F3D3FC91@deployingradius.com> Cc: radext@ietf.org, Naiming Shen , Enke Chen From: Enke Chen Message-ID: <6c0d923f-d27d-16f7-c1bc-65c96b98f228@cisco.com> Date: Tue, 18 Apr 2017 17:52:48 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1767D4FB-29BB-4E91-9339-1B40F3D3FC91@deployingradius.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 00:52:51 -0000 Hi, Alan: On 4/18/17 5:16 PM, Alan DeKok wrote: > On Apr 18, 2017, at 6:47 PM, Enke Chen wrote: >> Out of 255 numbers for the Packet Type Codes, 52 are currently allocated. Given >> the popularity of RAIDUS, this number space may run out in the future. > > That's called "Diameter". :( That is a different protocol :-) For better or worse RADIUS is not going away in enterprise anytime soon. > >> Although the Code field does not have to be enlarged together with the Identifier >> field, it just makes sense to do them together so that we go through the changes >> once and be done with it. There is little additional cost (in terms of development, >> memory and transmission) to cover the Code field, and its usage is optional until >> needed. > > The issue is solving one problem at a time. There is no *current* need to extend > the Code space. Therefore, there shouldn't be a proposal to extend it. I have to disagree. I do not see any benefits with the piecemeal approach in this case. > >>> >>> * The "status" field should similarly be removed from the document. Instead, >>> just the presence of the attribute in a reply should be good enough. >> >> Without the "status" field, we are afraid that some implementation may just send >> back the unrecognized attribute. The field would certainly help make it more >> explicit and deterministic about whether the feature is supported by a device. > > I think it's safe to say that servers don't "echo" back attributes. > > If you need an explicit ACK, create one. Don't overload the contents of an attribute. > See RFC 6929 Section 6.3 for guidelines on using Complex Data Types. There are tradeoffs. The question is, do we really want to burn another attribute when one can do? I would think that we want to preserve the attribute space and learn from the past. > >>> * using the 4-octet identifier *instead of* the normal ID means the protocol >>> is being changed, this cannot be done. >> >> I am not sure what you mean by the statement "the protocol is being changed, >> this cannot be done". >> >> You seem to mean that "such change is not allowed"? If that is correct, then I >> am wondering what basis you have (other than personal opinion) for such a position. >> If there exists some official IETF rules that I am not aware of, please let me know. > > I mean that modifying RADIUS in minor ways is probably OK. Changing the base > RADIUS protocol is not. > > Making clients and servers change the meaning and interpretation of the ID field > is changing RADIUS. I don't think you will get consensus from RADEXT, much less > the IESG for this proposal. "minor" vs "major" is just opinion, right? Also is there some IETF rule that states that a particular field can not be touched (even when needed), especially when it is done in a backward compatible way? I think that we will be better served if we just speak for ourselves (instead of for someone else or IESG), and stay on the technical issues. > >> I have been involved in IETF (mostly in the routing area) for more than 20 years. >> AFAIK, any extension to an existing protocol is a change to the protocol, and such >> changes have been made and continue to be made all the time, and some by you in >> this radext working group :-) > > Sure. Except that *major* changes to RADIUS are called "Diameter". :( Again, you consider this ID enlargement as "major", and I do not, but that does not really matter. RADIUS is not going away anytime soon, and we have to keep addressing issues we face. I guess that is the reason this WG still exists. > >> AFAIK, the RADIUS standard does not specify how the IDs are allocated, and that is >> completely left to the implementation and as a local matter on the sender. >> >> IMO deviation from such well-established practice will be challenging for backward >> compatibility and deployment. > > It's no more challenging than your proposal to replace the ID field entirely. > >> In addition, following the current RADIUS practice it remains an implementation >> decision how this new 4 bytes "ID" field is allocated. However, I do not see any >> value for combining this new 4-byte "ID" field with the existing one-byte "ID" >> field and using them both. > > There is likely no technical value. The issue is any change requires consensus > from RADEXT and IESG, which means the changes must be *percieved* to be minor > extensions to RADIUS. Our experiences may differ. My experience with IETF has been quite positive regarding addressing real world issues and making progress. No religious, and no kings, and "Rough consensus and running code" have got us this far. But that is probably off topic. Thanks. -- Enke From nobody Tue Apr 18 18:54:54 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5541205F1 for ; Tue, 18 Apr 2017 18:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Q2g8QioqDxBn for ; Tue, 18 Apr 2017 18:54:50 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6E31200DF for ; Tue, 18 Apr 2017 18:54:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id A5EC41A89; Wed, 19 Apr 2017 01:54:49 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taD5fZ3fnOvS; Wed, 19 Apr 2017 01:54:49 +0000 (UTC) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 15C9F5B6; Wed, 19 Apr 2017 01:54:48 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <6c0d923f-d27d-16f7-c1bc-65c96b98f228@cisco.com> Date: Tue, 18 Apr 2017 21:54:47 -0400 Cc: radext@ietf.org, Naiming Shen Content-Transfer-Encoding: quoted-printable Message-Id: <45205539-2F5B-4512-A40E-EF6B28E1A6A3@deployingradius.com> References: <361AC9F2-4CFE-46D5-A893-CBEDAFFA85B8@deployingradius.com> <1767D4FB-29BB-4E91-9339-1B40F3D3FC91@deployingradius.com> <6c0d923f-d27d-16f7-c1bc-65c96b98f228@cisco.com> To: Enke Chen X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 01:54:52 -0000 On Apr 18, 2017, at 8:52 PM, Enke Chen wrote: > That is a different protocol :-) For better or worse RADIUS is not = going away in > enterprise anytime soon. What I mean is that extending the Code space has already been done in = Diameter. There is no need to do it in RADIUS. Even worse, if there = *is* a need to do it in RADIUS, the answer should be "don't do it, just = use Diameter". >> The issue is solving one problem at a time. There is no *current* = need to extend >> the Code space. Therefore, there shouldn't be a proposal to extend = it. >=20 > I have to disagree. I do not see any benefits with the piecemeal = approach in this > case.=20 It's about doing what's necessary. It's not necessary to extend the = Code space at this time. Therefore, it shouldn't be done. > There are tradeoffs. The question is, do we really want to burn = another attribute > when one can do? I would think that we want to preserve the attribute = space and > learn from the past. My $0.02 is that a simpler approach will work just as well. > "minor" vs "major" is just opinion, right? Also is there some IETF = rule that > states that a particular field can not be touched (even when needed), = especially > when it is done in a backward compatible way? It's at least convention. I've had enough discussion with people that = I think there is wide-spread consensus that major changes to RADIUS = won't be approved. > I think that we will be better served if we just speak for ourselves = (instead of > for someone else or IESG), and stay on the technical issues. I've given my technical review of the document. > Again, you consider this ID enlargement as "major", and I do not, but = that does not > really matter. RADIUS is not going away anytime soon, and we have to = keep addressing > issues we face. I guess that is the reason this WG still exists. Yes... that's not my point. My point is that we've been patching = RADIUS in minor ways for a long time now. That's unpleasant, but part = of real-world engineering. Major changes to RADIUS have wide-spread opposition in the IETF. You = don't need to convince me that the changes will be OK. You need to = convince everyone else. Alan DeKok. From nobody Mon Apr 24 13:01:05 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3FF131592 for ; Mon, 24 Apr 2017 13:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tfjop7QUiWc for ; Mon, 24 Apr 2017 13:01:01 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id D02B5129502 for ; Mon, 24 Apr 2017 13:01:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id D20EC208E for ; Mon, 24 Apr 2017 20:00:59 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhzBvG3IOqcc for ; Mon, 24 Apr 2017 20:00:59 +0000 (UTC) Received: from [192.168.20.29] (CPEf4cc552207f0-CM00fc8dce0fa0.cpe.net.cable.rogers.com [99.230.129.191]) by mail.networkradius.com (Postfix) with ESMTPSA id 53AF5778 for ; Mon, 24 Apr 2017 20:00:59 +0000 (UTC) From: Alan DeKok X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_D0E06DB8-B848-4B95-ACBA-DDB7EB8082BF"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Mon, 24 Apr 2017 16:00:57 -0400 References: <149306333665.25840.6313986250597447759.idtracker@ietfa.amsl.com> To: radext@ietf.org Message-Id: <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [radext] A proposal to allow more than 256 packets on any connection X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 20:01:03 -0000 --Apple-Mail=_D0E06DB8-B848-4B95-ACBA-DDB7EB8082BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I've written a draft to allow more than 256 packets on any connection. = Note that I'm *not* proposing a change to the Id field, or to much else = in the protocol. The document is a first draft, and doesn't cover some of the protocol = details. But the concept is very simple: a) use Status-Server to negotiate the new functionality (see below for = details) b) allow clients to use Request Authenticator as a unique key for = packets, in addition to src/dst ip/port, Code, and Id i) For Access-Request packets, Request Authenticator is a bunch of = random numbers, which is fine. ii) for other packet types Request Authenticator is the signature of = the packet contents and the secret. So if the contents are the same, = the Request Authenticator is the same. If the contents are different, = it's different. c) have the server send a new attribute: Original-Request-Authenticator = in response packets. This allows clients to correlate responses with = requests, using the key mentioned in (b), above. For negotiation, a client sends Status-Server containing = Original-Request-Authenticator of all zeroes. If the server has the = functionality, it sends a response containing = Original-Request-Authenticator with value copied from the original = Request Authenticator. All other packet signing / Id management stays the same. I think this is the minimal possible change to RADIUS which solves the = underlying problem. As such, I hope it's also the least contentious. To do for the spec: - more text on how Original-Request-Authenticator works in response = packets - more text on why this works for all packet types - make the text less hacky (it was written in less than a day, after the = concept was worked out) - get WG review (I don't think we can achieve consensus quickly on this) Alan DeKok. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-dekok-radext-request-authenticator-00.txt > Date: April 24, 2017 at 3:48:56 PM EDT > To: "Alan DeKok" >=20 >=20 > A new version of I-D, draft-dekok-radext-request-authenticator-00.txt > has been successfully submitted by Alan DeKok and posted to the > IETF repository. >=20 > Name: draft-dekok-radext-request-authenticator > Revision: 00 > Title: Correlating requests and replies in the Remote = Authentication Dial In User Service (RADIUS) Protocol via the Request = Authenticator. > Document date: 2017-04-24 > Group: Individual Submission > Pages: 14 > URL: = https://www.ietf.org/internet-drafts/draft-dekok-radext-request-authentica= tor-00.txt > Status: = https://datatracker.ietf.org/doc/draft-dekok-radext-request-authenticator/= > Htmlized: = https://tools.ietf.org/html/draft-dekok-radext-request-authenticator-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-dekok-radext-request-authentic= ator-00 >=20 >=20 > Abstract: > RADIUS contains a one-octet Identifier field which is used to > correlate requests and replies. This field limits the number of > outstanding requests to 256. Experience shows that this limitation > is problematic for high load systems. This document proposes to use > the Request Authenticator field as an additional unique identifier. > The replies can then be correlated to requests by copying the = Request > Authenticator from the request to a new attribute in the response, > called the Original-Request-Authenticator. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_D0E06DB8-B848-4B95-ACBA-DDB7EB8082BF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY/ll5AAoJEH0Oec13Yh7NerQH/0sW9z98nQ/PO5gab2bXVymr RJNj4pnRgWz7Cd6eX8PZ4hK9Qy9wkVmwpPKCkvwejRE+qzgGtCT9HDSNneXZLIuK HgFeHozA+F0fX5BLglf3VAWwmFjCE94lhLFwU/8vrTCKCRjidxyHSDfhZUdRAIrV ZoQTQyPRI+MlGhqJHPO4TQciqpNb1zlLnPshKJC7OIGb85JAWOteA1asbRcSwOON 7ms08hGFfCViRGR70CiPJse82lWnZtYouw8VgEbZa+E6dWfIRIXuLSv/jUGgVbNS 4wSXA0faof23QWDtaYNdm1eTMzZ9gYtpW/ITIdD4Wrd6RqUpSgmI76a810uUKPc= =ni7f -----END PGP SIGNATURE----- --Apple-Mail=_D0E06DB8-B848-4B95-ACBA-DDB7EB8082BF-- From nobody Mon Apr 24 14:05:09 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E027129456 for ; Mon, 24 Apr 2017 14:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.701 X-Spam-Level: X-Spam-Status: No, score=-9.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI17Fn_EefBu for ; Mon, 24 Apr 2017 14:05:06 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 3578A1272E1 for ; Mon, 24 Apr 2017 14:05:06 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id F3023A24543D9; Mon, 24 Apr 2017 21:05:01 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id v3OL54pC026678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Apr 2017 21:05:04 GMT Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [192.207.23.55]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id v3OL538a022587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Apr 2017 21:05:04 GMT Received: from igoyret-c1.nokia.com (igoyret-pc [135.227.139.12]) by cliff.eng.ascend.com (8.13.1/8.13.1) with ESMTP id v3OL7GmV003413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Apr 2017 14:07:16 -0700 Message-Id: <201704242107.v3OL7GmV003413@cliff.eng.ascend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Apr 2017 14:04:56 -0700 To: Alan DeKok From: Ignacio Goyret Cc: In-Reply-To: <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> References: <149306333665.25840.6313986250597447759.idtracker@ietfa.amsl.com> <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [radext] A proposal to allow more than 256 packets on any connection X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 21:05:08 -0000 At what point would a new header be better instead of hacking new attributes into the uniqueness equation? And at what point RADIUS becomes Diameter? Since this proposal would require non-trivial changes to both servers and clients to agree on a new algorithm, they might as well agree on a new header, something like this: struct NewRadiusHeader { UINT8 code; UINT8 reserved_MBZ; UINT16 length; // length extended from 1 UINT8 authenticator[16]; UINT32 identifier; }; This way, the uniqueness function (src/dst ip/port + id) doesn't need to change. Just a thought, -Ignacio At 13:00 4/24/2017, Alan DeKok wrote: > I've written a draft to allow more than 256 packets on any connection. Note that I'm *not* proposing a change to the Id field, or to much else in the protocol. > > The document is a first draft, and doesn't cover some of the protocol details. But the concept is very simple: > >a) use Status-Server to negotiate the new functionality (see below for details) > >b) allow clients to use Request Authenticator as a unique key for packets, in addition to src/dst ip/port, Code, and Id > > i) For Access-Request packets, Request Authenticator is a bunch of random numbers, which is fine. > > ii) for other packet types Request Authenticator is the signature of the packet contents and the secret. So if the contents are the same, the Request Authenticator is the same. If the contents are different, it's different. > >c) have the server send a new attribute: Original-Request-Authenticator in response packets. This allows clients to correlate responses with requests, using the key mentioned in (b), above. > > For negotiation, a client sends Status-Server containing Original-Request-Authenticator of all zeroes. If the server has the functionality, it sends a response containing Original-Request-Authenticator with value copied from the original Request Authenticator. > > All other packet signing / Id management stays the same. > > I think this is the minimal possible change to RADIUS which solves the underlying problem. As such, I hope it's also the least contentious. > > To do for the spec: > >- more text on how Original-Request-Authenticator works in response packets > >- more text on why this works for all packet types > >- make the text less hacky (it was written in less than a day, after the concept was worked out) > >- get WG review (I don't think we can achieve consensus quickly on this) > > Alan DeKok. > >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-dekok-radext-request-authenticator-00.txt >> Date: April 24, 2017 at 3:48:56 PM EDT >> To: "Alan DeKok" >> >> >> A new version of I-D, draft-dekok-radext-request-authenticator-00.txt >> has been successfully submitted by Alan DeKok and posted to the >> IETF repository. >> >> Name: draft-dekok-radext-request-authenticator >> Revision: 00 >> Title: Correlating requests and replies in the Remote Authentication Dial In User Service (RADIUS) Protocol via the Request Authenticator. >> Document date: 2017-04-24 >> Group: Individual Submission >> Pages: 14 >> URL: https://www.ietf.org/internet-drafts/draft-dekok-radext-request-authenticator-00.txt >> Status: https://datatracker.ietf.org/doc/draft-dekok-radext-request-authenticator/ >> Htmlized: https://tools.ietf.org/html/draft-dekok-radext-request-authenticator-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-dekok-radext-request-authenticator-00 >> >> >> Abstract: >> RADIUS contains a one-octet Identifier field which is used to >> correlate requests and replies. This field limits the number of >> outstanding requests to 256. Experience shows that this limitation >> is problematic for high load systems. This document proposes to use >> the Request Authenticator field as an additional unique identifier. >> The replies can then be correlated to requests by copying the Request >> Authenticator from the request to a new attribute in the response, >> called the Original-Request-Authenticator. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> From nobody Mon Apr 24 14:20:50 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E921131943 for ; Mon, 24 Apr 2017 14:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 lPab3blTBb0C for ; Mon, 24 Apr 2017 14:20:45 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 406941294A6 for ; Mon, 24 Apr 2017 14:20:45 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id q78so45621958vke.3 for ; Mon, 24 Apr 2017 14:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ugd0xV3NY75Dk9JBwWtDhbwiN/a21b7vbkC1a91unoQ=; b=C/xgz+njurMqW8hoXfNksjMM11LVh1i7sjCKFe54Hxoc9zIYGQQ2s8U6ghQ7E7sioY 9hyccLGHYuUJzMw8xQwezrq4lC6JHKY2mRQGIaLaBQW5H4wFLMJD2aFDO85GosLnTzTh +VgL2EQoDApI3fio/OlTNNN3Xl5uU/VZWlTZWqxrImsTIWVXVtP3at37VgYZPuI5DfGa 1jzc8JLqvPP8z74WOf9e44qkr9aL1muToype0KSmsIGchjI7cRubaX4JylKS7RUZXwx4 r0U8WH+2boIRBhm6nBR3QlOgkx2DAa30fPZw5x9+bstAEilkuTrkqqBSPTRhjWFbaM5v iMCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ugd0xV3NY75Dk9JBwWtDhbwiN/a21b7vbkC1a91unoQ=; b=kMIdZ0/SaC+5ZsNs3qG/QhG3DILGwy/agOQo0yR0ArYgHCgCIBOYE7kOBbqSgzJBP9 FjZaP4W4LAb9Uj2AxHBNVFpi+SNztZSTO8LL63k+ZcziYE6vQL1n7nvmbzzfBs4h5Mqe VtoZ4FeljZwX1sVAxb++Nx4fn9/nEf7IJ/ZxD6U4kaOAz2g27wcoRjeSr4io+V/QWNHQ C8He++nKzoQdFJZ38N1k3FuqGSgoMkfVgxSisSk/YuntePEDpxsgIrslx9bw8KEREsT/ Az7agw9ttXf4LVuPGKclBMlaDEBwjlt8XIE3wZW4gCR+2SBy0NqlHJPxclvDYiDXYKA5 utFg== X-Gm-Message-State: AN3rC/6T91SP5Zdrq9/9B7EkvfgUj5Gc3f11wR0csvUH9OpEtX5n4fez 4VOpdTAzDR4194cvZY8IDDt2XbHuEtKfftk= X-Received: by 10.31.191.9 with SMTP id p9mr3074773vkf.50.1493068844172; Mon, 24 Apr 2017 14:20:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.23.100 with HTTP; Mon, 24 Apr 2017 14:20:23 -0700 (PDT) In-Reply-To: <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> References: <149306333665.25840.6313986250597447759.idtracker@ietfa.amsl.com> <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> From: Bernard Aboba Date: Mon, 24 Apr 2017 14:20:23 -0700 Message-ID: To: Alan DeKok Cc: radext@ietf.org Content-Type: multipart/alternative; boundary=001a114db700150bf0054df02eaf Archived-At: Subject: Re: [radext] A proposal to allow more than 256 packets on any connection X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 21:20:47 -0000 --001a114db700150bf0054df02eaf Content-Type: text/plain; charset=UTF-8 Alan said: "Note that I'm *not* proposing a change to the Id field, or to much else in the protocol." [BA] +1 to that. RADIUS is 25+ years old, and given the pace of change on the Internet, one can make a case that protocol age is somewhat akin to "dog years". That would make RADIUS 175 years old! Changing the Id field in RADIUS is somewhat akin to attempting a heart transplant on a 175 year-old. While some doctor might try this (more as a "cash-ectomy" than a legitimate procedure), let's not pretend that it is in the best interest of the patient. Carry on! On Mon, Apr 24, 2017 at 1:00 PM, Alan DeKok wrote: > I've written a draft to allow more than 256 packets on any connection. > Note that I'm *not* proposing a change to the Id field, or to much else in > the protocol. > > The document is a first draft, and doesn't cover some of the protocol > details. But the concept is very simple: > > a) use Status-Server to negotiate the new functionality (see below for > details) > > b) allow clients to use Request Authenticator as a unique key for packets, > in addition to src/dst ip/port, Code, and Id > > i) For Access-Request packets, Request Authenticator is a bunch of > random numbers, which is fine. > > ii) for other packet types Request Authenticator is the signature of the > packet contents and the secret. So if the contents are the same, the > Request Authenticator is the same. If the contents are different, it's > different. > > c) have the server send a new attribute: Original-Request-Authenticator in > response packets. This allows clients to correlate responses with > requests, using the key mentioned in (b), above. > > For negotiation, a client sends Status-Server containing > Original-Request-Authenticator of all zeroes. If the server has the > functionality, it sends a response containing > Original-Request-Authenticator with value copied from the original Request > Authenticator. > > All other packet signing / Id management stays the same. > > I think this is the minimal possible change to RADIUS which solves the > underlying problem. As such, I hope it's also the least contentious. > > To do for the spec: > > - more text on how Original-Request-Authenticator works in response packets > > - more text on why this works for all packet types > > - make the text less hacky (it was written in less than a day, after the > concept was worked out) > > - get WG review (I don't think we can achieve consensus quickly on this) > > Alan DeKok. > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for draft-dekok-radext-request- > authenticator-00.txt > > Date: April 24, 2017 at 3:48:56 PM EDT > > To: "Alan DeKok" > > > > > > A new version of I-D, draft-dekok-radext-request-authenticator-00.txt > > has been successfully submitted by Alan DeKok and posted to the > > IETF repository. > > > > Name: draft-dekok-radext-request-authenticator > > Revision: 00 > > Title: Correlating requests and replies in the Remote > Authentication Dial In User Service (RADIUS) Protocol via the Request > Authenticator. > > Document date: 2017-04-24 > > Group: Individual Submission > > Pages: 14 > > URL: https://www.ietf.org/internet-drafts/draft-dekok-radext- > request-authenticator-00.txt > > Status: https://datatracker.ietf.org/doc/draft-dekok-radext- > request-authenticator/ > > Htmlized: https://tools.ietf.org/html/draft-dekok-radext-request- > authenticator-00 > > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-dekok-radext-request-authenticator-00 > > > > > > Abstract: > > RADIUS contains a one-octet Identifier field which is used to > > correlate requests and replies. This field limits the number of > > outstanding requests to 256. Experience shows that this limitation > > is problematic for high load systems. This document proposes to use > > the Request Authenticator field as an additional unique identifier. > > The replies can then be correlated to requests by copying the Request > > Authenticator from the request to a new attribute in the response, > > called the Original-Request-Authenticator. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > --001a114db700150bf0054df02eaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alan said:=C2=A0

"Note that I'm *not* proposing a change to the Id field= , or to much else in the protocol."

[B= A] +1 to that.

RADIUS is 25+ years old, and given = the pace of change on the Internet, one can make a case that protocol age i= s somewhat akin to "dog years".=C2=A0

Th= at would make RADIUS 175 years old!

Changing the I= d field in RADIUS is somewhat akin to attempting a heart transplant on a 17= 5 year-old.=C2=A0

While some doctor might try this= (more as a "cash-ectomy" than a legitimate procedure), let's= not pretend that it is in the best interest of the patient.

=
Carry on!

<= br>
On Mon, Apr 24, 2017 at 1:00 PM, Alan DeKok <= span dir=3D"ltr"><aland@freeradius.org> wrote:
=C2=A0 I've written a draft to allow more than 256 packets on any= connection.=C2=A0 Note that I'm *not* proposing a change to the Id fie= ld, or to much else in the protocol.

=C2=A0 The document is a first draft, and doesn't cover some of the pro= tocol details.=C2=A0 But the concept is very simple:

a) use Status-Server to negotiate the new functionality (see below for deta= ils)

b) allow clients to use Request Authenticator as a unique key for packets, = in addition to src/dst ip/port, Code, and Id

=C2=A0 i) For Access-Request packets, Request Authenticator is a bunch of r= andom numbers, which is fine.

=C2=A0 ii) for other packet types Request Authenticator is the signature of= the packet contents and the secret.=C2=A0 So if the contents are the same,= the Request Authenticator is the same.=C2=A0 If the contents are different= , it's different.

c) have the server send a new attribute: Original-Request-Authenticator in = response packets.=C2=A0 This allows clients to correlate responses with req= uests, using the key mentioned in (b), above.

=C2=A0 For negotiation, a client sends Status-Server containing Original-Re= quest-Authenticator of all zeroes.=C2=A0 If the server has the functionalit= y, it sends a response containing Original-Request-Authenticator with value= copied from the original Request Authenticator.

=C2=A0 All other packet signing / Id management stays the same.

=C2=A0 I think this is the minimal possible change to RADIUS which solves t= he underlying problem.=C2=A0 As such, I hope it's also the least conten= tious.

=C2=A0 To do for the spec:

- more text on how Original-Request-Authenticator works in response packets=

- more text on why this works for all packet types

- make the text less hacky (it was written in less than a day, after the co= ncept was worked out)

- get WG review (I don't think we can achieve consensus quickly on this= )

=C2=A0 Alan DeKok.

> Begin forwarded message:
>
> From: internet-drafts@ietf= .org
> Subject: New Version Notification for draft-dekok-radext-request-= authenticator-00.txt
> Date: April 24, 2017 at 3:48:56 PM EDT
> To: "Alan DeKok" <aland@freeradius.org>
>
>
> A new version of I-D, draft-dekok-radext-request-authenticator-00= .txt
> has been successfully submitted by Alan DeKok and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-dekok-radext-request-authenticator
> Revision:=C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Correlat= ing requests and replies in the Remote Authentication Dial In User Service = (RADIUS) Protocol via the Request Authenticator.
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-04-24
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 14
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draft= s/draft-dekok-radext-request-authenticator-00.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-dekok-radex= t-request-authenticator/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-dekok-radext-request-authenticator-00
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-deko= k-radext-request-authenticator-00
>
>
> Abstract:
>=C2=A0 =C2=A0RADIUS contains a one-octet Identifier field which is used= to
>=C2=A0 =C2=A0correlate requests and replies.=C2=A0 This field limits th= e number of
>=C2=A0 =C2=A0outstanding requests to 256.=C2=A0 Experience shows that t= his limitation
>=C2=A0 =C2=A0is problematic for high load systems.=C2=A0 This document = proposes to use
>=C2=A0 =C2=A0the Request Authenticator field as an additional unique id= entifier.
>=C2=A0 =C2=A0The replies can then be correlated to requests by copying = the Request
>=C2=A0 =C2=A0Authenticator from the request to a new attribute in the r= esponse,
>=C2=A0 =C2=A0called the Original-Request-Authenticator.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>


_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

--001a114db700150bf0054df02eaf-- From nobody Mon Apr 24 14:57:56 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A9A131949 for ; Mon, 24 Apr 2017 14:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9o4RoqpZGvc for ; Mon, 24 Apr 2017 14:57:52 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id E6E71120227 for ; Mon, 24 Apr 2017 14:57:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 371E9B4F; Mon, 24 Apr 2017 21:57:51 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZVLn5aY_FHG; Mon, 24 Apr 2017 21:57:51 +0000 (UTC) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 995E1107; Mon, 24 Apr 2017 21:57:50 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_942380A3-FC50-401A-9CAB-92864AAE2315"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: <201704242107.v3OL7GmV003413@cliff.eng.ascend.com> Date: Mon, 24 Apr 2017 17:57:47 -0400 Message-Id: References: <149306333665.25840.6313986250597447759.idtracker@ietfa.amsl.com> <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> <201704242107.v3OL7GmV003413@cliff.eng.ascend.com> To: Ignacio Goyret , radext@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] A proposal to allow more than 256 packets on any connection X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 21:57:54 -0000 --Apple-Mail=_942380A3-FC50-401A-9CAB-92864AAE2315 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 24, 2017, at 5:04 PM, Ignacio Goyret = wrote: >=20 > At what point would a new header be better instead of hacking new = attributes > into the uniqueness equation? When you want to use Diameter. > And at what point RADIUS becomes Diameter? When you change the header. > Since this proposal would require non-trivial changes to both servers = and > clients to agree on a new algorithm, I don't know what you mean by "new algorithm". *Any* change to RADIUS = requires negotiation. And any change requires changes on both the = client and server. > they might as well agree on a new header, Which requires *more* changes to clients and servers than my proposal. > This way, the uniqueness function (src/dst ip/port + id) doesn't need = to change. I'm proposing to change (src/dst ip/port + id) to (src/dst ip/port = + id + request-authenticator) Which is a smaller change than the one you propose. In this proposal, all RADIUS request packets are *identical* to = existing RADIUS. All RADIUS response packets contain one new attribute. = The responses are otherwise 100% standard RADIUS. There are *implementation* changes on client and server. But again, = they are largely limited to using "Request Authenticator" in the key = that determines packet identity. The encoding and decoding procedures = are *exactly* the same as for standard RADIUS. Alan DeKok. --Apple-Mail=_942380A3-FC50-401A-9CAB-92864AAE2315 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY/nTcAAoJEH0Oec13Yh7NfGkH/1A/RlR687+ePeuhwj34hpR6 t9w64mgioQmUruvww7KFDbaov0uT1B9zquO8lz+ZkrYn2kLxa9XyEbGNh48u00n9 NSz/eIZSvg5rIE3ODoNyeBLN3yOKqPCUILT4d3FqC51ckVPQH0u2BpmATY266GJM 6aDTil35s6CR+XY8euggvMUg1Nqf7iEBPXZv9QYtOOEpe4EWnuWf18LkQxTOAXgM 20UlZLZTiU8Jbdv6Q1qy/Yk8zIY6O1K5A5Cxcw7uhjFPrq/R05ixlidfpID7hMN/ R8y4EHCIuEL3ejnDk2cVP5euR2pRyrY5KoYoUn3O+OB+va0/SaEFaadaKpq2hZE= =Ptov -----END PGP SIGNATURE----- --Apple-Mail=_942380A3-FC50-401A-9CAB-92864AAE2315-- From nobody Mon Apr 24 15:26:12 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB2813149B for ; Mon, 24 Apr 2017 15:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5iUQFAoEdIS for ; Mon, 24 Apr 2017 15:26:08 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 7ADB7120227 for ; Mon, 24 Apr 2017 15:26:06 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 0E76B7981F55B; Mon, 24 Apr 2017 22:26:03 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id v3OMQ4ht023548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Apr 2017 22:26:05 GMT Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [192.207.23.55]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id v3OMQ3nk007237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Apr 2017 22:26:04 GMT Received: from igoyret-c1.nokia.com (igoyret-pc [135.227.139.12]) by cliff.eng.ascend.com (8.13.1/8.13.1) with ESMTP id v3OMSGci005558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Apr 2017 15:28:16 -0700 Message-Id: <201704242228.v3OMSGci005558@cliff.eng.ascend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Apr 2017 15:25:51 -0700 To: Alan DeKok From: Ignacio Goyret Cc: Ignacio Goyret , In-Reply-To: References: <149306333665.25840.6313986250597447759.idtracker@ietfa.amsl.com> <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> <201704242107.v3OL7GmV003413@cliff.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [radext] A proposal to allow more than 256 packets on any connection X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 22:26:11 -0000 At 14:57 4/24/2017, Alan DeKok wrote: >On Apr 24, 2017, at 5:04 PM, Ignacio Goyret wrote: >> >> At what point would a new header be better instead of hacking new attributes >> into the uniqueness equation? > > When you want to use Diameter. Or you when you want to minimize changes to RADIUS. >> And at what point RADIUS becomes Diameter? > > When you change the header. Or when you change the equation that matches pending requests. A change is a change, regardless of how you want to paint it. >> Since this proposal would require non-trivial changes to both servers and >> clients to agree on a new algorithm, > > I don't know what you mean by "new algorithm". *Any* change to RADIUS requires negotiation. And any change requires changes on both the client and server. Well, you are proposing a new algorithm for handling more pending requests which requires a new matching function to be used only for certain peers. At any rate, the point is that changes are required on both ends. If you are going to change something, why not do a simpler change? >> they might as well agree on a new header, > > Which requires *more* changes to clients and servers than my proposal. Well, that's your assessment not mine. I see a lot more complex changes in your proposal since it requires two separate matching trees with different matching functions. My suggestion would require a single tree with a single function. Only the size of the id changes. Everything else stays the same. >> This way, the uniqueness function (src/dst ip/port + id) doesn't need to change. > > I'm proposing to change (src/dst ip/port + id) to (src/dst ip/port + id + request-authenticator) > > Which is a smaller change than the one you propose. Again, your assessment does not match my assessment. Your proposal requires significant changes in the matching of pending requests which is far from trivial. My suggestion requires trivial changes in deciding to use one type of header versus another when extracting or inserting the initial packet header. After extracting the packet header, the rest of the code, including attribute encoding and decoding, stays exactly the same. For example, this idea allows me to figure out if it is a duplicate without having to inspect any of the attributes, just like it is now possible. This looks to me like a much smaller and simpler change. At any rate, it is important to realize that either way, the change is not compatible with 25+ years of RADIUS. -Ignacio From nobody Mon Apr 24 16:07:30 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD81A131957 for ; Mon, 24 Apr 2017 16:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBojSjg-Qv3g for ; Mon, 24 Apr 2017 16:07:26 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id A54EF131956 for ; Mon, 24 Apr 2017 16:07:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 0B48917AA; Mon, 24 Apr 2017 23:07:26 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08ZztmbNfv6n; Mon, 24 Apr 2017 23:07:25 +0000 (UTC) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 83689107; Mon, 24 Apr 2017 23:07:25 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E9CA2A92-5ECB-430F-9063-0F0341CAEBD6"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: <201704242228.v3OMSGci005558@cliff.eng.ascend.com> Date: Mon, 24 Apr 2017 19:07:23 -0400 Cc: radext@ietf.org Message-Id: References: <149306333665.25840.6313986250597447759.idtracker@ietfa.amsl.com> <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> <201704242107.v3OL7GmV003413@cliff.eng.ascend.com> <201704242228.v3OMSGci005558@cliff.eng.ascend.com> To: Ignacio Goyret X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] A proposal to allow more than 256 packets on any connection X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 23:07:29 -0000 --Apple-Mail=_E9CA2A92-5ECB-430F-9063-0F0341CAEBD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 24, 2017, at 6:25 PM, Ignacio Goyret = wrote: > A change is a change, regardless of how you want to paint it. Some changes are smaller than others. As a general rule, RADEXT tends = to stay with smaller changes. > Well, you are proposing a new algorithm for handling more pending = requests > which requires a new matching function to be used only for certain = peers. Yes. > At any rate, the point is that changes are required on both ends. > If you are going to change something, why not do a simpler change? Because I disagree that your proposal is simpler. > My suggestion would require a single tree with a single function. > Only the size of the id changes. Everything else stays the same. The packet encoder / decoder changes. Don't ignore that. > Again, your assessment does not match my assessment. Your proposal = requires > significant changes in the matching of pending requests which is far > from trivial. Really? Implementing callback A versus callback B for key comparisons = is trivial. As someone who's written the most popular RADIUS server on the planet, = my experience counts for something. > My suggestion requires trivial changes in deciding to use one type of > header versus another when extracting or inserting the initial packet > header. Again, you're changing the packet encoding / decoding. You're proposing to use function A versus function B for packet = encoding... which is ends up being no different than using function A = versus function B for key comparison. > After extracting the packet header, the rest of the code, including > attribute encoding and decoding, stays exactly the same. I'm proposing that all attribute encoding / decoding stay the same. > For example, this idea allows me to figure out if it is a duplicate > without having to inspect any of the attributes, just like it is > now possible. >=20 > This looks to me like a much smaller and simpler change. That's your opinion. As an implementor, I disagree. > At any rate, it is important to realize that either way, the change > is not compatible with 25+ years of RADIUS. I suggest reading the draft. I go into detail on how my proposal *is* = compatible with 25+ years of RADIUS. Again: * nothing changes in packet encoding / decoding * nothing changes in attribute encoding / decoding * nothing changes in RADIUS security (what little there is) * nothing changes for existing clients and servers * there is a simple fallback to existing RADIUS. Even if I agreed with your arguments, I suspect that the wider RADIUS = community in the iETF (i.e. RADEXT, DIME, and the IESG) would oppose = changing the RADIUS header. Adding a new attribute is much simpler in = comparison. Even if the clients and servers use one more field for the = unique key. Your implementation arguments are largely that using two functions for = the packet encoder/decoder is more efficient than using two functions = for the key comparison. I just don't see that as being true. I suggest trying to convince everyone *else* that your proposal is = simpler than mine. I don't believe it is, until there's evidence to the = contrary. Alan DeKok. --Apple-Mail=_E9CA2A92-5ECB-430F-9063-0F0341CAEBD6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY/oUrAAoJEH0Oec13Yh7NzBkH/2U/xsgzrTEHChlyhz2KzQqD gKh2VrfICigBcg1sP3r3tMEYq0q2U81qj33q0+4WK6JQv5+ql9mJ702BqKRQS3+0 ATFOEfJhcRCDdDGqMdM3tUgViUorgkh89wjwRUXUXeTIVRGE1HkoO38vB2W99xwt 1Pwpx1U3QjuvDZ6fqvOEfIQY/MpsqO1RKyMSTA4OXrwz9/8owA+DtCwoAWDXd8bI 9BWqN+ozDNgt2d0p+zciYoPrETy3Y6xqj7BORswpq9Yibig4nwtkJAj9Z2+L+T3Q /9K4RvVC2YlxRPcEakprXZzG/IbWHRbIGEigXQNHUcU6/TdehzvgJ5PeewIcqCE= =gtHy -----END PGP SIGNATURE----- --Apple-Mail=_E9CA2A92-5ECB-430F-9063-0F0341CAEBD6-- From nobody Mon Apr 24 17:00:10 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734F7131973 for ; Mon, 24 Apr 2017 17:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.701 X-Spam-Level: X-Spam-Status: No, score=-9.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im6Hu8EO9PHw for ; Mon, 24 Apr 2017 17:00:07 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 BC61A131972 for ; Mon, 24 Apr 2017 17:00:07 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 30769F0184B3A; Tue, 25 Apr 2017 00:00:03 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id v3P006qQ010095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Apr 2017 00:00:06 GMT Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [192.207.23.55]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id v3P004gO003543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Apr 2017 00:00:05 GMT Received: from igoyret-c1.nokia.com (igoyret-pc [135.227.139.12]) by cliff.eng.ascend.com (8.13.1/8.13.1) with ESMTP id v3P02HOb007491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Apr 2017 17:02:17 -0700 Message-Id: <201704250002.v3P02HOb007491@cliff.eng.ascend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Apr 2017 16:59:37 -0700 To: Alan DeKok From: Ignacio Goyret Cc: In-Reply-To: References: <149306333665.25840.6313986250597447759.idtracker@ietfa.amsl.com> <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> <201704242107.v3OL7GmV003413@cliff.eng.ascend.com> <201704242228.v3OMSGci005558@cliff.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [radext] A proposal to allow more than 256 packets on any connection X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 00:00:09 -0000 >> At any rate, the point is that changes are required on both ends. >> If you are going to change something, why not do a simpler change? > > Because I disagree that your proposal is simpler. I guess we'll have to agree to disagree. Your proposal is complex, much more so than increasing the size of a header field. It requires protocol changes, a big no-no in RADIUS, as has been repeatedly stated many times by you. It also requires a lot more cpu cycles since it requires decoding every attribute before an incoming packet can be determined to be a duplicate or not, which also means a hardware implementation of the de-dup algorithm is out of the question. >> My suggestion would require a single tree with a single function. >> Only the size of the id changes. Everything else stays the same. > > The packet encoder / decoder changes. Don't ignore that. Note that may be a detail of your particular implementation which does not necessarily hold as a universal truth. Other implementations may be layered in ways that can handle my suggestion more easily. >> Again, your assessment does not match my assessment. Your proposal requires >> significant changes in the matching of pending requests which is far >> from trivial. > > Really? Implementing callback A versus callback B for key comparisons is trivial. You do realize that the same can be said about either proposal, right? >As someone who's written the most popular RADIUS server on the planet, my experience counts for something. I never said or implied otherwise. I have great respect for you and your contributions over the years. But let's keep it civil and on a technical level. You may not know me but I also have significant experience implementing and maintaining server, client and proxy implementations of RADIUS spanning over two decades. >> My suggestion requires trivial changes in deciding to use one type of >> header versus another when extracting or inserting the initial packet >> header. > > Again, you're changing the packet encoding / decoding. Again, that may be the case on a particular implementation, not on others. >You're proposing to use function A versus function B for packet encoding... which is ends up being no different than using function A versus function B for key comparison. Good, we are on the same page. >> This looks to me like a much smaller and simpler change. > > That's your opinion. As an implementor, I disagree. Precisely. And as another implementor, I disagree with you. >Your implementation arguments are largely that using two functions for the packet encoder/decoder is more efficient than using two functions for the key comparison. I just don't see that as being true. Note that the suggestion was strictly limited to the first 20/24 bytes of the packet. Once that header is extracted, the attribute handling remains identical. >I suggest trying to convince everyone *else* that your proposal is simpler than mine. I don't believe it is, until there's evidence to the contrary. I'm not going to try to convince anyone about either proposal because I personally believe that RADIUS shouldn't be changed at all. The point of my initial message was to highlight that if you are going to change something in RADIUS, there are cleaner and simpler alternatives. Your suggestion is better than others that have been floated around but it also fails on the basic issue of no protocol changes. The best solution still remains that if you need more than 255 pending requests, use another UDP port. And if you ran out of UDP ports, use another IP address. These are much simpler solutions than any other proposal so far. -Ignacio From nobody Mon Apr 24 17:41:14 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6160413197F for ; Mon, 24 Apr 2017 17:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 s-AYtWeaTX5A for ; Mon, 24 Apr 2017 17:41:11 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8E4126B72 for ; Mon, 24 Apr 2017 17:41:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 9CCC017AA; Tue, 25 Apr 2017 00:41:10 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWGR0q4oZz4G; Tue, 25 Apr 2017 00:41:10 +0000 (UTC) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id CADBA535; Tue, 25 Apr 2017 00:41:09 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C767FE0E-9EC9-401C-815C-17FF5E5735D5"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: <201704250002.v3P02HOb007491@cliff.eng.ascend.com> Date: Mon, 24 Apr 2017 20:41:08 -0400 Cc: radext@ietf.org Message-Id: References: <149306333665.25840.6313986250597447759.idtracker@ietfa.amsl.com> <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> <201704242107.v3OL7GmV003413@cliff.eng.ascend.com> <201704242228.v3OMSGci005558@cliff.eng.ascend.com> <201704250002.v3P02HOb007491@cliff.eng.ascend.com> To: Ignacio Goyret X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] A proposal to allow more than 256 packets on any connection X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 00:41:13 -0000 --Apple-Mail=_C767FE0E-9EC9-401C-815C-17FF5E5735D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 24, 2017, at 7:59 PM, Ignacio Goyret = wrote: > Your proposal is complex, much more so than increasing the size of > a header field. As I said... no. > It requires protocol changes, a big no-no in RADIUS, as has been > repeatedly stated many times by you. As the author or co-author of many RFC which require protocol changes, = this is simply not true. > It also requires a lot more cpu cycles since it requires decoding > every attribute before an incoming packet can be determined to be > a duplicate or not, which also means a hardware implementation of > the de-dup algorithm is out of the question. Please point me to a hardware implementation of RADIUS. And even if = one exists, why it matters. As I've pointed out, my proposal is 100% backwards compatible with all = existing RADIUS implementations So if you want to continue using = existing RADIUS (hardware or software implementations), you're free to = do so. > Note that may be a detail of your particular implementation which does = not > necessarily hold as a universal truth. >=20 > Other implementations may be layered in ways that can handle my = suggestion > more easily. Then show evidence for your assertions. If you can't, it's just my = opinion (backed by publicly available facts) against your opinion = (backed by vague assertions to proprietary implementations). >> Really? Implementing callback A versus callback B for key = comparisons is trivial. >=20 > You do realize that the same can be said about either proposal, right? I'm well aware of that. And... again... which is simpler? Adding an = attribute, or changing the RADIUS header? Honestly, every time I come up with a counter-argument, you just = re-assert your position, without additional evidence. It's circular = logic. >> As someone who's written the most popular RADIUS server on the = planet, my experience counts for something. >=20 > I never said or implied otherwise. I have great respect for you and > your contributions over the years. >=20 > But let's keep it civil and on a technical level. My comments *were* on a technical level. The insinuation that I was = uncivil is inappropriate. > You may not know me but I also have significant experience = implementing > and maintaining server, client and proxy implementations of RADIUS = spanning > over two decades. You have pretty much zero track record in RADEXT. Whatever you've = done, it's been in a walled garden, with minimal interaction with the = IETF or other implementors. Now, it *is* important to understand how this proposal affects = existing implementations. And as I've said repeatedly.. it doesn't. = What part of that is unclear? >> Again, you're changing the packet encoding / decoding. >=20 > Again, that may be the case on a particular implementation, not on = others. You're *explicitly* proposing to change the RADIUS header, and now are = claiming that it's not changing the packet encoding / decoding. One or the other statement is false. I find such arguments unconvincing. And, inappropriate for a = standards forum. >> That's your opinion. As an implementor, I disagree. >=20 > Precisely. And as another implementor, I disagree with you. Since your implementation doesn't exist for purposes of peer review, = we only have your naked assertion to go by. I suggest explaining *why* these changes are difficult in your = implementation. A naked assertion that "it's difficult" isn't much of = an argument. In contrast, my code is public. >> Your implementation arguments are largely that using two functions = for the packet encoder/decoder is more efficient than using two = functions for the key comparison. I just don't see that as being true. >=20 > Note that the suggestion was strictly limited to the first 20/24 bytes > of the packet. Once that header is extracted, the attribute handling > remains identical. That's disingenuous. Changing the header means changing how attributes are encoded and = decoded. Because attributes are encoded *after* the header. In my proposal, there are no changes to header encoding. There are no = changes to attribute encoding. Which, pretty much by definition, is = simpler than your proposal. >> I suggest trying to convince everyone *else* that your proposal is = simpler than mine. I don't believe it is, until there's evidence to the = contrary. >=20 > I'm not going to try to convince anyone about either proposal because > I personally believe that RADIUS shouldn't be changed at all. Then state that explicitly. Oppose any and all changes to RADIUS. = See how far that gets you. > The point of my initial message was to highlight that if you are going > to change something in RADIUS, there are cleaner and simpler = alternatives. Simply stating a contrary position isn't an argument. > Your suggestion is better than others that have been floated around > but it also fails on the basic issue of no protocol changes. That's ridiculous. If we couldn't make changes to RADIUS, we would = disband the RADEXT WG. > The best solution still remains that if you need more than 255 pending > requests, use another UDP port. And if you ran out of UDP ports, use > another IP address. >=20 > These are much simpler solutions than any other proposal so far. Then I don't think you've been paying attention. The existing implementations have problems with using multiple UDP = ports and/or multiple IP addresses. That's the sole reason why multiple = people are proposing changes that allow more than 256 packets on one = src/dst ip/port combination. Because allowing that is *simpler* and = *cheaper* than opening multiple source sockets. Honestly, this response makes it sounds like you haven't been paying = attention to the implementation problems and the reasons why people are = proposing these changes in the first place. Alan DeKok. --Apple-Mail=_C767FE0E-9EC9-401C-815C-17FF5E5735D5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY/pskAAoJEH0Oec13Yh7NfEQH/igQ4kYuMUjNhq+ydMnE1UO9 m9P+JWAX1diLCb5MpYjJ4oIjeuuCvAvukVYq/95jYlApO9X6lxYtGJmUxtAqgMZk qXRP1zqMj7NuMSWWJzM6JOeJqFsU+UqvkIONqrn18CnENLpuOXGJOC5q0fiSarfl CHfSEvWTLg8nKDw5QmSwJ+pOMTjeJKaId+1WJ+u8yBEoza6pc+FpzVrT20+Vx4Of OSsEpH1we0LTzYisiGoIaEM9puEJovQxZVo+pHFtVD9+lXxFbC39w8EdX7/v8SXB G8DV4GEhRxPuszgXG7Az5jsdd8H3kexMn8yW5U3NxeZKQgEbwEhOIk6BphnxMOY= =9CBh -----END PGP SIGNATURE----- --Apple-Mail=_C767FE0E-9EC9-401C-815C-17FF5E5735D5-- From nobody Mon Apr 24 18:45:07 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E939B1319A3 for ; Mon, 24 Apr 2017 18:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.701 X-Spam-Level: X-Spam-Status: No, score=-9.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OnbP_MWJJoM for ; Mon, 24 Apr 2017 18:45:05 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 206B01319A4 for ; Mon, 24 Apr 2017 18:45:05 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id D815FB6EF784E; Tue, 25 Apr 2017 01:45:03 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id v3P1j3tI002734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Apr 2017 01:45:03 GMT Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [192.207.23.55]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id v3P1j2fg019451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Apr 2017 01:45:03 GMT Received: from igoyret-c1.nokia.com (igoyret-pc [135.227.139.12]) by cliff.eng.ascend.com (8.13.1/8.13.1) with ESMTP id v3P1lEJE009334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Apr 2017 18:47:14 -0700 Message-Id: <201704250147.v3P1lEJE009334@cliff.eng.ascend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Apr 2017 18:44:40 -0700 To: Alan DeKok From: Ignacio Goyret Cc: In-Reply-To: References: <149306333665.25840.6313986250597447759.idtracker@ietfa.amsl.com> <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> <201704242107.v3OL7GmV003413@cliff.eng.ascend.com> <201704242228.v3OMSGci005558@cliff.eng.ascend.com> <201704250002.v3P02HOb007491@cliff.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [radext] A proposal to allow more than 256 packets on any connection X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 01:45:07 -0000 >>> As someone who's written the most popular RADIUS server on the planet, my experience counts for something. >> >> I never said or implied otherwise. I have great respect for you and >> your contributions over the years. >> >> But let's keep it civil and on a technical level. > >My comments *were* on a technical level. The insinuation that I was uncivil is inappropriate. Well, let's see: you followed that with these comments: >You have pretty much zero track record in RADEXT. Whatever you've done, it's been in a walled garden, with minimal interaction with the IETF or other implementors. >Since your implementation doesn't exist for purposes of peer review, we only have your naked assertion to go by. Either one of those comments are either ad-hominen attacks or dismissive, either way quiet inappropriate for the discussion at hand. Thus, my call for civility. Your opinion, very valuable without a doubt, is not the only opinion in the world, just like your implementation is not the only implementation in the world. I'm done arguing. -Ignacio From nobody Mon Apr 24 18:50:01 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D981319A2 for ; Mon, 24 Apr 2017 18:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6HGaGn9h7uE for ; Mon, 24 Apr 2017 18:49:57 -0700 (PDT) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 5551113199D for ; Mon, 24 Apr 2017 18:49:57 -0700 (PDT) Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 24 Apr 2017 18:49:57 -0700 Date: Mon, 24 Apr 2017 18:49:58 -0700 (Pacific Daylight Time) From: Peter Deacon To: Ignacio Goyret cc: Alan DeKok , radext@ietf.org In-Reply-To: <201704250002.v3P02HOb007491@cliff.eng.ascend.com> Message-ID: References: <149306333665.25840.6313986250597447759.idtracker@ietfa.amsl.com> <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> <201704242107.v3OL7GmV003413@cliff.eng.ascend.com> <201704242228.v3OMSGci005558@cliff.eng.ascend.com> <201704250002.v3P02HOb007491@cliff.eng.ascend.com> User-Agent: Alpine 2.20.1 (WNT 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [radext] A proposal to allow more than 256 packets on any connection X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 01:49:59 -0000 On Mon, 24 Apr 2017, Ignacio Goyret wrote: > The best solution still remains that if you need more than 255 pending > requests, use another UDP port. And if you ran out of UDP ports, use > another IP address. > These are much simpler solutions than any other proposal so far. Completely agree. Useful to look at the numbers. Assume a single src/dst IP with pool of 1000 src ports and an average round trip time of 100 ms. This translates to 256,000 concurrently "in-flight" requests or 2,560,000 RADIUS requests+responses per second. Who pushes anything approaching this from aclient? What specifically is your request/response rate per second and total number of concurrently outstanding requests from your clients? I would love to see actual figures justifying change rather than blanket assertions which for all anyone knows could well be entirely explained away by known or unknown implementation problems. There are defiantly problems. I don't think anyone believes the current situation is ideal. Managing source port or connection pools is inconvenient. If you don't have access to scalable method of listening on order of hundreds of "sockets" concurrently you begin to accumulate unreasonable overhead. Those using TCP and DTLS transports have a much better case. No doubt ID space is more inconvenient here leading to many times more TCP/TLS connections than optimal. With TCP there are inherent limits associated with too many requests dependent on a single head-of-line blocked stream. You don't want thousands of realtime authentication requests piling up generally or simultaneously delayed by single events (e.g. tail loss) Is it unreasonable to expect a system acting as a RADIUS client for what must be millions of concurrent users to not be resource limited by something as trivial as number of available source ports or lack a scalable mechanism to listen concurrently across them? Speaking for myself while clearly inconvenient the answer is no. regards, Peter From nobody Mon Apr 24 22:44:20 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A661319BE for ; Mon, 24 Apr 2017 22:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5hy5f1ii-cAg for ; Mon, 24 Apr 2017 22:44:16 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAC11319C4 for ; Mon, 24 Apr 2017 22:44:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id CF632535; Tue, 25 Apr 2017 05:44:13 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id te6wjY20cUgz; Tue, 25 Apr 2017 05:44:13 +0000 (UTC) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 4F728509; Tue, 25 Apr 2017 05:44:13 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_30EA84F3-0317-492A-92DB-6A61878EE90C"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: <201704250147.v3P1lEJE009334@cliff.eng.ascend.com> Date: Tue, 25 Apr 2017 01:44:11 -0400 Message-Id: <14CDDB22-8637-4B46-9C0F-6AB6A2A17429@freeradius.org> References: <149306333665.25840.6313986250597447759.idtracker@ietfa.amsl.com> <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> <201704242107.v3OL7GmV003413@cliff.eng.ascend.com> <201704242228.v3OMSGci005558@cliff.eng.ascend.com> <201704250002.v3P02HOb007491@cliff.eng.ascend.com> <201704250147.v3P1lEJE009334@cliff.eng.ascend.com> To: Ignacio Goyret , radext@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] A proposal to allow more than 256 packets on any connection X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 05:44:18 -0000 --Apple-Mail=_30EA84F3-0317-492A-92DB-6A61878EE90C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 24, 2017, at 9:44 PM, Ignacio Goyret = wrote: >> My comments *were* on a technical level. The insinuation that I was = uncivil is inappropriate. >=20 > Well, let's see: you followed that with these comments: >=20 >> You have pretty much zero track record in RADEXT. Whatever you've = done, it's been in a walled garden, with minimal interaction with the = IETF or other implementors. >=20 >=20 >> Since your implementation doesn't exist for purposes of peer review, = we only have your naked assertion to go by. >=20 > Either one of those comments are either ad-hominen attacks or = dismissive, Saying "your proposal is hard for my implementation" is a reasonable = argument. Saying "I've been doing this for over two decades" is a data point, = but isn't a convincing argument. Saying "my code is publicly available, and therefore I can demonstrate = the code changes are simple" is a reasonable argument. Saying "my code is private, so therefor you have to believe me" isn't = a convincing argument. My request for evidence-based discussion *is* me being dismissive of = appeals to authority. But it in no way is an ad hominem. > either way quiet inappropriate for the discussion at hand. Thus, my = call > for civility. Asking for evidence isn't being uncivil, and no reasonable person = would conclude otherwise. > Your opinion, very valuable without a doubt, is not the only opinion > in the world, just like your implementation is not the only = implementation > in the world. I never claimed my implementation was the only one in the world, and = no reasonable person would insinuate otherwise. That comment is a thinly-veiled insult. It shows that fi you can't = convince people based on appeals to authority, you resort to ad = hominems. > I'm done arguing. That's your prerogative. Alan DeKok. --Apple-Mail=_30EA84F3-0317-492A-92DB-6A61878EE90C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY/uIrAAoJEH0Oec13Yh7NNJAIAIsVmxzZP757/0P2bU9h10jP ZKZz0cAE4tihHyTxz+tFnDST58qBn3LNAUqa1Y+Wu/7+2Ffd39N2t2aYVJhOIXF0 l8GLM2+KG9geTenrh04i+E+8IBgRc64nKm5ZWURHpZ3tkaLrBiXkO5r4IfTltLym 2z+kSkmLtyIwQsoIlGugTcxb03DLdzohRTGGvp7AEIXYgaHzkaeO9mJr+y1VvQZa CboFrrVcZBU4tubXBE9gT+bQr/QSRT/vl6C2gburOut/T8y5XRIqGotY+JO/Ds2y pMJN+5MY9Uq9Li5lQoWGYDS30ZvzNrD78O4uIFJ57H5gavpYqaecdndIXAAIEos= =HC83 -----END PGP SIGNATURE----- --Apple-Mail=_30EA84F3-0317-492A-92DB-6A61878EE90C-- From nobody Mon Apr 24 23:01:13 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9347C127286 for ; Mon, 24 Apr 2017 23:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jRnxQbW2sn85 for ; Mon, 24 Apr 2017 23:01:10 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 91624127337 for ; Mon, 24 Apr 2017 23:01:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id F20CA91D; Tue, 25 Apr 2017 06:01:08 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XXA_D9_XngL; Tue, 25 Apr 2017 06:01:08 +0000 (UTC) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 6A902535; Tue, 25 Apr 2017 06:01:08 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_99D8C3F6-73AE-4231-A5EE-5FC8CB0AE8D0"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: Date: Tue, 25 Apr 2017 02:01:06 -0400 Cc: radext@ietf.org Message-Id: <9A5B8DCC-4515-44D9-BBE1-BB515BE88E53@freeradius.org> References: <149306333665.25840.6313986250597447759.idtracker@ietfa.amsl.com> <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> <201704242107.v3OL7GmV003413@cliff.eng.ascend.com> <201704242228.v3OMSGci005558@cliff.eng.ascend.com> <201704250002.v3P02HOb007491@cliff.eng.ascend.com> To: Peter Deacon X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] A proposal to allow more than 256 packets on any connection X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 06:01:12 -0000 --Apple-Mail=_99D8C3F6-73AE-4231-A5EE-5FC8CB0AE8D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 24, 2017, at 9:49 PM, Peter Deacon = wrote: >=20 > On Mon, 24 Apr 2017, Ignacio Goyret wrote: >=20 >> The best solution still remains that if you need more than 255 = pending >> requests, use another UDP port. And if you ran out of UDP ports, use >> another IP address. >=20 >> These are much simpler solutions than any other proposal so far. >=20 > Completely agree. Useful to look at the numbers. >=20 > Assume a single src/dst IP with pool of 1000 src ports and an average = round trip time of 100 ms. This translates to 256,000 concurrently = "in-flight" requests or 2,560,000 RADIUS requests+responses per second. >=20 > Who pushes anything approaching this from aclient? Not many systems. However... one problem with UDP is the ability to fill a network with = data. Networks are bounded both by per packet rates, and by total = throughput. RADIUS packets are small enough that they hit the network = limit on packets, long before they hit the limit on total throughput. This is mainly due to having small packets, and using UDP transport. You could use TCP to avoid the problem of "one RADIUS packet =3D=3D = one ethernet frame". But RADIUS allows only 256 packets outstanding at = a time. So if the packets are proxied, each TCP connection can only = have <100K of data sent before the client MUST open another source port. = Which again runs into the ethernet frame limit. Allowing many RADIUS packets over one TCP connection means that you = can fill a network with RADIUS traffic. This is just impossible with = RADIUS as it exists today. > What specifically is your request/response rate per second and total = number of concurrently outstanding requests from your clients? I would = love to see actual figures justifying change rather than blanket = assertions which for all anyone knows could well be entirely explained = away by known or unknown implementation problems. One word: proxying. Once a packet is proxied, the clients can see request / response time = frames of 100s of milliseconds, or even seconds That puts a much = stronger pressure on the number of packets outstanding. > Those using TCP and DTLS transports have a much better case. No doubt = ID space is more inconvenient here leading to many times more TCP/TLS = connections than optimal. >=20 > With TCP there are inherent limits associated with too many requests = dependent on a single head-of-line blocked stream. You don't want = thousands of realtime authentication requests piling up generally or = simultaneously delayed by single events (e.g. tail loss) The need for many RADIUS packets is largely driven by accounting = traffic, not authentication traffic. And TCP "head of line" blocking only affects the network side of the = transport. If the packets actually make it to the RADIUS server, it is = free to respond to the packets in any order it choses. Another counter-argument to TCP "head of line" blocking is that it's = 2017. The internet is large and fast. People download gigabytes of = traffic daily, and are minimally affected by packet loss. I think it's = reasonable to assume that packet loss won't affect RADIUS over TCP much, = either. > Is it unreasonable to expect a system acting as a RADIUS client for = what must be millions of concurrent users to not be resource limited by = something as trivial as number of available source ports or lack a = scalable mechanism to listen concurrently across them? Speaking for = myself while clearly inconvenient the answer is no. That's a reasonable argument. I'm not even disagreeing with it much. My draft is an attempt to address the stated need for allowing more = outstanding RADIUS packets on one UDP or TCP connection. There have = been multiple suggestions for a solution to the problem, most of which = involve changing the RADIUS header. As I've pointed out, I think such = changes will be rejected not only by RADEXT, but by the wider IETF = reviewers. My draft is an attempt to address both the technical requirements, and = the wider review. There's no question that it will work. The questions = are whether it's needed, and whether it will achieve larger consensus = that the solution is a reasonable one. Alan DeKok. --Apple-Mail=_99D8C3F6-73AE-4231-A5EE-5FC8CB0AE8D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY/uYjAAoJEH0Oec13Yh7NLUAH/ja8+s9BwftSKl47s0uRn0dR ZuK0cF1RYKrCZwKmUELBO1nLfvy/l8DNutoH47zlP9okcPSx+59btiPmLrs3kyrJ ZbCBNhjvCfRYSSHu6aMKrS3RKWrr5dAwY3eDqwoW/ySy9s0Hl1+C+8d5lK0tBX9M lEh0ldbNaZitPver5cyeFaeEXQFu7F4sUb90dXURBAsueA9klSgGiuYjZeYyV8pT x1l7a4zt7bjaqU+0ew91imBdavHhoMYIKC/lZtU2ppvgOoj4VuFKvJ3C2XJuIjkf 0SVUVDdpoLXNlfJK9KWQT5B4n2Rli3IYfoDKEmRcSxV/MiPz9UFfL+RgYQkNayY= =9lSk -----END PGP SIGNATURE----- --Apple-Mail=_99D8C3F6-73AE-4231-A5EE-5FC8CB0AE8D0-- From nobody Tue Apr 25 10:25:02 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A971D1316E8 for ; Tue, 25 Apr 2017 10:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVy2x02tlY88 for ; Tue, 25 Apr 2017 10:24:59 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA95C1316D6 for ; Tue, 25 Apr 2017 10:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2280; q=dns/txt; s=iport; t=1493141098; x=1494350698; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5O/IT32hSMhmOOhv4cHHIswtPcIlioP0uzCihNRIz1Q=; b=m/cbfSLcKmjtPMoYV6S6F3RNHqF1IlXOcq7ctf/CuWFTkZG48W1p/ton 1v1VXuIDRIRKP7e5oMBqw/as328iq0YVZJ0EwPsplXFPSNIXEdeQj7qc6 5pW0zAsbkXSzWyZ4WH+C8bQUEc66YUDzXna+BCYv4n+u1NzJ3IvOx1+LH E=; X-IronPort-AV: E=Sophos;i="5.37,250,1488844800"; d="scan'208";a="414564732" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Apr 2017 17:24:58 +0000 Received: from [10.82.234.250] (rtp-vpn5-760.cisco.com [10.82.234.250]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3PHOvXb020527; Tue, 25 Apr 2017 17:24:57 GMT References: <149314027943.13018.17075749372313672148@ietfa.amsl.com> To: radext@ietf.org Cc: Enke Chen , Naiming Shen From: Enke Chen X-Forwarded-Message-Id: <149314027943.13018.17075749372313672148@ietfa.amsl.com> Message-ID: <87a68340-384c-b904-1fbb-872e99ae3365@cisco.com> Date: Tue, 25 Apr 2017 10:24:57 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149314027943.13018.17075749372313672148@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: [radext] Fwd: I-D Action: draft-chen-radext-identifier-attr-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 17:25:01 -0000 Hi, Folks: This revised version includes the following changes: o Renamed the attribute as "Extended Identifier Attribute". o Removed the specification for the optional "Extended Code" as Alan suggested. o Relaxed the use of the two parameters "Identifier" and "Extended Identifier", from "OR" to "AND" for more flexible implementation. Finally, "no ID changes" according to Alan's definition :-) Regards, -- Enke -------- Forwarded Message -------- Subject: I-D Action: draft-chen-radext-identifier-attr-01.txt Date: Tue, 25 Apr 2017 10:11:19 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RADIUS Extended Identifier Attribute Authors : Enke Chen Naiming Shen Filename : draft-chen-radext-identifier-attr-01.txt Pages : 7 Date : 2017-04-25 Abstract: The limitation with the one-octet "Identifier" field in the RADIUS packet is well known. In this document we propose extensions to the RADIUS protocol to address this fundamental limitation, and thus allowing for more efficient and more scalable implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-radext-identifier-attr/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-chen-radext-identifier-attr-01 https://datatracker.ietf.org/doc/html/draft-chen-radext-identifier-attr-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-chen-radext-identifier-attr-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Apr 26 05:15:06 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D839129412 for ; Wed, 26 Apr 2017 05:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWbNuua0aEPx for ; Wed, 26 Apr 2017 05:15:03 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD0712704B for ; Wed, 26 Apr 2017 05:15:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id C824D165F; Wed, 26 Apr 2017 12:15:02 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2dEzT_9qbzD; Wed, 26 Apr 2017 12:15:02 +0000 (UTC) Received: from [10.1.2.225] (d72-38-204-8.commercial1.cgocable.net [72.38.204.8]) by mail.networkradius.com (Postfix) with ESMTPSA id 3C2F0B1; Wed, 26 Apr 2017 12:15:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <87a68340-384c-b904-1fbb-872e99ae3365@cisco.com> Date: Wed, 26 Apr 2017 08:15:00 -0400 Cc: radext@ietf.org, Naiming Shen Content-Transfer-Encoding: quoted-printable Message-Id: <824E4D53-9059-462A-A153-39E9191CA3DC@deployingradius.com> References: <149314027943.13018.17075749372313672148@ietfa.amsl.com> <87a68340-384c-b904-1fbb-872e99ae3365@cisco.com> To: Enke Chen X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Fwd: I-D Action: draft-chen-radext-identifier-attr-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 12:15:05 -0000 > On Apr 25, 2017, at 1:24 PM, Enke Chen wrote: >=20 > Hi, Folks: >=20 > This revised version includes the following changes: >=20 > o Renamed the attribute as "Extended Identifier Attribute". >=20 > o Removed the specification for the optional "Extended Code" as Alan > suggested. >=20 > o Relaxed the use of the two parameters "Identifier" and "Extended > Identifier", from "OR" to "AND" for more flexible implementation. >=20 > Finally, "no ID changes" according to Alan's definition :-) It looks reasonable. I'd like to see more text on how this proposal affects clients and = servers. Also, how it affects proxies. I also need to add more text to = my draft for proxies, too. i.e. it's best to describe not only the changes, but how those changes = affect existing systems. Alan DeKok. From nobody Wed Apr 26 05:43:23 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FCA129B7E for ; Wed, 26 Apr 2017 05:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ArZC64svteZ for ; Wed, 26 Apr 2017 05:43:20 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6E3129B37 for ; Wed, 26 Apr 2017 05:43:19 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 487264397C for ; Wed, 26 Apr 2017 14:43:17 +0200 (CEST) To: radext@ietf.org From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: Date: Wed, 26 Apr 2017 14:43:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="E2EPhuu5MGv8IEBJfPu7EO7Huq8D754pT" Archived-At: Subject: [radext] Client ID exhaustion X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 12:43:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E2EPhuu5MGv8IEBJfPu7EO7Huq8D754pT Content-Type: multipart/mixed; boundary="FbE6IKRwlv0Ak5w5UB6psu6ja6cbsRAng"; protected-headers="v1" From: Stefan Winter To: radext@ietf.org Message-ID: Subject: Client ID exhaustion --FbE6IKRwlv0Ak5w5UB6psu6ja6cbsRAng Content-Type: multipart/mixed; boundary="------------75FA59AAD78F6FA8C9690537" This is a multi-part message in MIME format. --------------75FA59AAD78F6FA8C9690537 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, we keep hearing assertions on the list that change is needed regarding the ID field in RADIUS. I would like to recall RFC2865's section 2.5 "If a NAS needs more than 256 IDs for outstanding requests, it MAY use additional source ports to send requests from, and keep track of IDs for each source port. This allows up to 16 million or so outstanding requests at one time to a single server." It's fairly clear that implementations which do not follow the MAY will run into exhaustion problems rather soon. It's less clear that implementations which do follow this MAY still do. We've heard finger-in-the-air calculations on the list that this may become a problem earlier than one might think. But is there actual evidence to that end in deployed reality? Can someone please share their experience regarding a deployment and implementation which DOES implement the MAY above but STILL runs out of RADIUS packet IDs? Obviously, for those implementors which do not implement the MAY, the suggestion would be to implement that before trying to make protocol changes. The corresponding advice in RFC2865 may be 17 years old now, but that doesn't mean it is not good advice. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------75FA59AAD78F6FA8C9690537 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------75FA59AAD78F6FA8C9690537-- --FbE6IKRwlv0Ak5w5UB6psu6ja6cbsRAng-- --E2EPhuu5MGv8IEBJfPu7EO7Huq8D754pT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJZAJXlAAoJEMDeajWKOdxmlcYQAJHwUMmn1h8AGoe85ye+Mizk IZgst2YIb1o0yiTPTOSLYk8ZL8AJm3fBi7/YecgJOUVdMMMGbvp0wmGdEqfDcGFz yUf2cDo4nYqSl1Z2YvxSUZGCHiKURxVeZB5bzSTLwPlRSRHKFgEvXdEYllVGweEQ uytRt29bLNYSdts8D1FyA7QqomvMC7tUQkwWVlWzhkpq5xQ8zIwGWanaHlxqxJis FKp9gi0AH3WdBrC6eHuAKaWOyeGvBuFka1e/Wr2/uLBjDJcliRSrnzsll+1uloWs lawYakP/1loBde9GA6lNlzRilK+6pJiyGVlo0Hy3e3g9cnkFIoVugsYOGRtYE4VS I5+cD6G3mTMjvFPCmClSOoCkGbJUqoVa3oM7648eMDRMyCt85q4Fw3O5a1TepOgZ 7PGhxeCFS50wKf8M0O3JQ+wPtLhl0wMwtnAXS34Pl24NDz40YtCPIus4xAx72FPO 5x36UQ6j8pBtWY7HUk5w8ywYsBgm7WUI7P6eLJxbUYw9HDmz8h+q1HKzMhCyKYks S/z5bQIs8yj2Lp/0Z4cPF58MWO759LGS82uSbNs1B5oXWpYNFQP3RzfYcEbrJCcr EKKAwVTeHNc0BcaB/Y4kJq53Gyhsqyvk7JVvVDAQru11Lmhc6TewUrvRlMIlCF0l WSGj4nmjJTpnMuIQ7BX6 =PPWq -----END PGP SIGNATURE----- --E2EPhuu5MGv8IEBJfPu7EO7Huq8D754pT-- From nobody Wed Apr 26 05:55:11 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C3B129B7E for ; Wed, 26 Apr 2017 05:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei_BRBXdA654 for ; Wed, 26 Apr 2017 05:55:07 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id AEF0E129B89 for ; Wed, 26 Apr 2017 05:55:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 17CE8B4F; Wed, 26 Apr 2017 12:55:07 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU9g1-EGc45c; Wed, 26 Apr 2017 12:55:06 +0000 (UTC) Received: from [10.1.2.225] (d72-38-204-8.commercial1.cgocable.net [72.38.204.8]) by mail.networkradius.com (Postfix) with ESMTPSA id 97BEE619; Wed, 26 Apr 2017 12:55:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Wed, 26 Apr 2017 08:55:05 -0400 Cc: radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Winter Stefan X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Client ID exhaustion X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 12:55:09 -0000 On Apr 26, 2017, at 8:43 AM, Stefan Winter = wrote: > It's fairly clear that implementations which do not follow the MAY = will > run into exhaustion problems rather soon. I think implementations which don't open new source ports are few and = far between. They are typically simple and small. > It's less clear that implementations which do follow this MAY still = do. > We've heard finger-in-the-air calculations on the list that this may > become a problem earlier than one might think. But is there actual > evidence to that end in deployed reality? All RADIUS servers open new ports. All NAS equipment that costs more = than $20 opens new ports. > Can someone please share their experience regarding a deployment and > implementation which DOES implement the MAY above but STILL runs out = of > RADIUS packet IDs? I've never seen one. The issue for me is really TCP, and accounting. It would be useful to = be able to send many accounting packets to a server. It would be useful = to "fill" a TCP connection with RADIUS traffic. The 256 packet limit = makes that impossible. Whether or not this proposal gets approval, I think it's useful. If = nothing else, I will likely add it as a configurable (not negotiable) = extension to my implementation. Alan DeKok. From nobody Wed Apr 26 12:17:06 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443531289C3 for ; Wed, 26 Apr 2017 12:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yeZ3N8Ugu7u for ; Wed, 26 Apr 2017 12:17:04 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD301293F4 for ; Wed, 26 Apr 2017 12:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1897; q=dns/txt; s=iport; t=1493234223; x=1494443823; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=GVKhaCGaIQ2Dpr+/sU9bkd24GsD/3bvsy8YaR3VeS28=; b=TmqoDsWUJHwd/BngAIVtl76xEavfI1NiPwR7YxCXFbG6Ye67oX9e0L+/ n+fO8a3XG2ZjjnySX4qfhmzDrfV3PKcTVRp//oocrNsRcw0fohcZrNodR YPvAgp3yz+L1RXX0nOH9T5cKMMhCoBOek81H4XliZhE4akingO8wxD7+w 0=; X-IronPort-AV: E=Sophos;i="5.37,255,1488844800"; d="scan'208";a="416396742" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2017 19:17:02 +0000 Received: from [10.82.220.141] (rtp-vpn3-1160.cisco.com [10.82.220.141]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3QJH2SA001343; Wed, 26 Apr 2017 19:17:02 GMT To: radext@ietf.org References: Cc: Enke Chen From: Enke Chen Message-ID: Date: Wed, 26 Apr 2017 12:17:01 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [radext] Client ID exhaustion X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 19:17:05 -0000 Hi, Stefan: The case we have is with the wireless controller that needs to manage thousands of APs and tens of thousands of clients. The wireless world uses "centralized" management model. The scaling requirements keep increasing every year. Though RADIUS is an old protocol, it is a critical piece in the wireless world. Thanks. -- Enke On 4/26/17 5:43 AM, Stefan Winter wrote: > Hello, > > > we keep hearing assertions on the list that change is needed regarding > the ID field in RADIUS. > > > I would like to recall RFC2865's section 2.5 > > > "If a > > NAS needs more than 256 IDs for outstanding requests, it MAY use > additional source ports to send requests from, and keep track of IDs > for each source port. This allows up to 16 million or so outstanding > requests at one time to a single server." > > > It's fairly clear that implementations which do not follow the MAY will > run into exhaustion problems rather soon. > > It's less clear that implementations which do follow this MAY still do. > We've heard finger-in-the-air calculations on the list that this may > become a problem earlier than one might think. But is there actual > evidence to that end in deployed reality? > > Can someone please share their experience regarding a deployment and > implementation which DOES implement the MAY above but STILL runs out of > RADIUS packet IDs? > > Obviously, for those implementors which do not implement the MAY, the > suggestion would be to implement that before trying to make protocol > changes. The corresponding advice in RFC2865 may be 17 years old now, > but that doesn't mean it is not good advice. > > Greetings, > > Stefan Winter > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Wed Apr 26 12:37:42 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07496129450 for ; Wed, 26 Apr 2017 12:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvykJLi18kUw for ; Wed, 26 Apr 2017 12:37:39 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF0C1293F4 for ; Wed, 26 Apr 2017 12:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5836; q=dns/txt; s=iport; t=1493235458; x=1494445058; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=divfo5pgQc8k+OZv8NiadeOu73l6NdoLLcPbpm70dqg=; b=TWkUhL45e5ufY9xS1qoSrjCXFC52NJaRw2fYotMQO7mO3E9Qw7yW+QRs DwQrkx1cHqJZxQ63R87kY3Ph1wB1H51ntTnMimMwLwPszUJW+2ZdJz/Z9 J9N93+DdBoSHhyVj5aj7mndmhE6D5b2x3izFM7JCfoBocx5bkvM6zYpED I=; X-IronPort-AV: E=Sophos;i="5.37,255,1488844800"; d="scan'208";a="418057522" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2017 19:37:38 +0000 Received: from [10.82.220.141] (rtp-vpn3-1160.cisco.com [10.82.220.141]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v3QJbb2j029180; Wed, 26 Apr 2017 19:37:37 GMT To: Bernard Aboba References: <149306333665.25840.6313986250597447759.idtracker@ietfa.amsl.com> <1AB9F08E-0739-4BE3-9827-3EA830DC113B@freeradius.org> Cc: Alan DeKok , radext@ietf.org, Enke Chen , Naiming Shen From: Enke Chen Message-ID: Date: Wed, 26 Apr 2017 12:37:36 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [radext] A proposal to allow more than 256 packets on any connection X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 19:37:41 -0000 Hi, Bernard: In this case it is more like a "wart removal" than a "heart transplant" :-) Regards, -- Enke On 4/24/17 2:20 PM, Bernard Aboba wrote: > Alan said: > > "Note that I'm *not* proposing a change to the Id field, or to much else in the protocol." > > [BA] +1 to that. > > RADIUS is 25+ years old, and given the pace of change on the Internet, one can make a case that protocol age is somewhat akin to "dog years". > > That would make RADIUS 175 years old! > > Changing the Id field in RADIUS is somewhat akin to attempting a heart transplant on a 175 year-old. > > While some doctor might try this (more as a "cash-ectomy" than a legitimate procedure), let's not pretend that it is in the best interest of the patient. > > Carry on! > > > On Mon, Apr 24, 2017 at 1:00 PM, Alan DeKok > wrote: > > I've written a draft to allow more than 256 packets on any connection. Note that I'm *not* proposing a change to the Id field, or to much else in the protocol. > > The document is a first draft, and doesn't cover some of the protocol details. But the concept is very simple: > > a) use Status-Server to negotiate the new functionality (see below for details) > > b) allow clients to use Request Authenticator as a unique key for packets, in addition to src/dst ip/port, Code, and Id > > i) For Access-Request packets, Request Authenticator is a bunch of random numbers, which is fine. > > ii) for other packet types Request Authenticator is the signature of the packet contents and the secret. So if the contents are the same, the Request Authenticator is the same. If the contents are different, it's different. > > c) have the server send a new attribute: Original-Request-Authenticator in response packets. This allows clients to correlate responses with requests, using the key mentioned in (b), above. > > For negotiation, a client sends Status-Server containing Original-Request-Authenticator of all zeroes. If the server has the functionality, it sends a response containing Original-Request-Authenticator with value copied from the original Request Authenticator. > > All other packet signing / Id management stays the same. > > I think this is the minimal possible change to RADIUS which solves the underlying problem. As such, I hope it's also the least contentious. > > To do for the spec: > > - more text on how Original-Request-Authenticator works in response packets > > - more text on why this works for all packet types > > - make the text less hacky (it was written in less than a day, after the concept was worked out) > > - get WG review (I don't think we can achieve consensus quickly on this) > > Alan DeKok. > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for draft-dekok-radext-request-authenticator-00.txt > > Date: April 24, 2017 at 3:48:56 PM EDT > > To: "Alan DeKok" > > > > > > > A new version of I-D, draft-dekok-radext-request-authenticator-00.txt > > has been successfully submitted by Alan DeKok and posted to the > > IETF repository. > > > > Name: draft-dekok-radext-request-authenticator > > Revision: 00 > > Title: Correlating requests and replies in the Remote Authentication Dial In User Service (RADIUS) Protocol via the Request Authenticator. > > Document date: 2017-04-24 > > Group: Individual Submission > > Pages: 14 > > URL: https://www.ietf.org/internet-drafts/draft-dekok-radext-request-authenticator-00.txt > > Status: https://datatracker.ietf.org/doc/draft-dekok-radext-request-authenticator/ > > Htmlized: https://tools.ietf.org/html/draft-dekok-radext-request-authenticator-00 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-dekok-radext-request-authenticator-00 > > > > > > Abstract: > > RADIUS contains a one-octet Identifier field which is used to > > correlate requests and replies. This field limits the number of > > outstanding requests to 256. Experience shows that this limitation > > is problematic for high load systems. This document proposes to use > > the Request Authenticator field as an additional unique identifier. > > The replies can then be correlated to requests by copying the Request > > Authenticator from the request to a new attribute in the response, > > called the Original-Request-Authenticator. > > > > > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org . > > > > The IETF Secretariat > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Thu Apr 27 02:00:48 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5DE128656 for ; Thu, 27 Apr 2017 02:00:47 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUORy6aLkIum for ; Thu, 27 Apr 2017 02:00:45 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849361273E2 for ; Thu, 27 Apr 2017 02:00:45 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9E3844397C for ; Thu, 27 Apr 2017 11:00:43 +0200 (CEST) To: radext@ietf.org References: From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: Date: Thu, 27 Apr 2017 11:00:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aRGRIDFxiQe6B2ln8F2sH5Hu33KGXboxp" Archived-At: Subject: Re: [radext] Client ID exhaustion X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 09:00:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aRGRIDFxiQe6B2ln8F2sH5Hu33KGXboxp Content-Type: multipart/mixed; boundary="wsGj5Q3OtRTsSdGDdUgCnB1Ki5lVbnKj1"; protected-headers="v1" From: Stefan Winter To: radext@ietf.org Message-ID: Subject: Re: [radext] Client ID exhaustion References: In-Reply-To: --wsGj5Q3OtRTsSdGDdUgCnB1Ki5lVbnKj1 Content-Type: multipart/mixed; boundary="------------53EB6DE0ECACE81956826AD6" This is a multi-part message in MIME format. --------------53EB6DE0ECACE81956826AD6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, > The case we have is with the wireless controller that needs to manage > thousands of APs and tens of thousands of clients. The wireless world > uses "centralized" management model. The scaling requirements keep > increasing every year. > > Though RADIUS is an old protocol, it is a critical piece in the wireles= s > world. Your reply did not indicate whether the wireless controller implements the MAY in RFC2865 (a piece of information I specifically asked for). Does it? Greetings, Stefan Winter > > Thanks. -- Enke > > On 4/26/17 5:43 AM, Stefan Winter wrote: >> Hello, >> >> >> we keep hearing assertions on the list that change is needed regarding= >> the ID field in RADIUS. >> >> >> I would like to recall RFC2865's section 2.5 >> >> >> "If a >> >> NAS needs more than 256 IDs for outstanding requests, it MAY use >> additional source ports to send requests from, and keep track of ID= s >> for each source port. This allows up to 16 million or so outstandi= ng >> requests at one time to a single server." >> >> >> It's fairly clear that implementations which do not follow the MAY wil= l >> run into exhaustion problems rather soon. >> >> It's less clear that implementations which do follow this MAY still do= =2E >> We've heard finger-in-the-air calculations on the list that this may >> become a problem earlier than one might think. But is there actual >> evidence to that end in deployed reality? >> >> Can someone please share their experience regarding a deployment and >> implementation which DOES implement the MAY above but STILL runs out o= f >> RADIUS packet IDs? >> >> Obviously, for those implementors which do not implement the MAY, the >> suggestion would be to implement that before trying to make protocol >> changes. The corresponding advice in RFC2865 may be 17 years old now, >> but that doesn't mean it is not good advice. >> >> Greetings, >> >> Stefan Winter >> >> >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------53EB6DE0ECACE81956826AD6 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------53EB6DE0ECACE81956826AD6-- --wsGj5Q3OtRTsSdGDdUgCnB1Ki5lVbnKj1-- --aRGRIDFxiQe6B2ln8F2sH5Hu33KGXboxp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJZAbM7AAoJEMDeajWKOdxmxIYQALg9XE0a43RCu2JYAXMGHamI WnkbhQPeABc5S3sVKqF+nVdjoWBngVfCSSpuDx9Ar6vcW/qotYerhd8OrOS1QahG RBNGXLDd8HapCc2tuHzZhfcr1MXuvEg4FB30jMVyF/LG4p8+7V9IfKdNXORQeGbK uZLWNMgMQzEIbBqINK1woDGHeVJ/X9ELMeyS0UyzysXaw5P1ALPsX7BYZ0Oh8J+B 2i1W3ZavF4i5Q1lNs1yssGIuYjGAmpz/B/uQ7g2zkJso/EepZS9KzKDmKyf3cz8h 8c1TdiPAk1+mFUrm5AnjPdCoPCyG9fYgMqIsZ4PRmsofnc05ZXKhyVg2pF8OrX13 NOxlouIdl/lvRgG+vOA2JRSuLHBysqJh5JLvtuJT09cDJ7i/MXd8YyjGOKU8a/4b AEQP3ugJoPhh7F/e5+yxmKJzaGr+klEMA6iWoAZkgKMEIC8nmPtMrOUWJ7cz+P1+ gcfnIiGbwOWr0+ts0e8VNbISQm9zi9pHO0ZR70LZom3IzXA0Sg58UM0IXz0vfSdr 23YkNS+MI/oihesSNRC4H2/GFZSX8V7cuCPBSpQ4pLpWx5LsBoQjea+deNe7xI0K c2rBEr4+2Uih60JG3jbs/IzNklNiJFePBuCoR1gofIq3lZW/2FyNn0cJcZL4ezVc aUCYP81B2L6B5HOXco+Y =Q4s9 -----END PGP SIGNATURE----- --aRGRIDFxiQe6B2ln8F2sH5Hu33KGXboxp-- From nobody Thu Apr 27 08:10:46 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F192129AFA for ; Thu, 27 Apr 2017 08:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LOj6kRjSytco for ; Thu, 27 Apr 2017 08:10:43 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id E3C41129B0E for ; Thu, 27 Apr 2017 08:09:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 299441287; Thu, 27 Apr 2017 15:09:32 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5s_gVTvJER0; Thu, 27 Apr 2017 15:09:32 +0000 (UTC) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id B53585BC; Thu, 27 Apr 2017 15:09:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Thu, 27 Apr 2017 11:09:29 -0400 Cc: radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Enke Chen X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Client ID exhaustion X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:10:45 -0000 On Apr 26, 2017, at 3:17 PM, Enke Chen wrote: >=20 > The case we have is with the wireless controller that needs to manage > thousands of APs and tens of thousands of clients. The wireless world > uses "centralized" management model. The scaling requirements keep > increasing every year. FYI, I'm aware of multiple vendors with similar use-cases. The other = vendors are using software which will open multiple source ports. But... there is a limit. Depending on the version, a FreeRADIUS proxy = will open 32-256 outgoing ports, and then decide that's too many ports. = Fixing that involves code changes and upgrades. I've seen multiple situations where a high load RADIUS proxy = continually has 32 or more source ports in use. At that point, you have = to ask if it isn't more efficient to just update RADIUS. i.e. Asking implementations to open 1-4 source ports is reasonable. = Asking them to implement 2000 source ports for a high load situation is = possible, but is less reasonable. Alan DeKok. From nobody Thu Apr 27 10:35:09 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE54129B57 for ; Thu, 27 Apr 2017 10:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXT7jiv_tQ9g for ; Thu, 27 Apr 2017 10:35:06 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625F5129B50 for ; Thu, 27 Apr 2017 10:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2489; q=dns/txt; s=iport; t=1493314353; x=1494523953; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=qNlhq7vdPsZGgBSveWzsiYKs6fOrGk35F9gC3ABdPGU=; b=XuVmyHW4vLzXGC9Dg/6Dwx6nIAyM9bMluozt4cuqAjXb7jyMnKVmOdn2 U2sL0fpmWzkdrVTj2Jx189vUS8YgLmO7mR8KDrRhXn+WmtJ7oaH0+9M0i sxo0lF+Eh0u7lwVEdO7y3xw7mu5lHNYvpTmCDswYaHQxuazsmsLJH2g6h 4=; X-IronPort-AV: E=Sophos;i="5.37,384,1488844800"; d="scan'208";a="413729518" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2017 17:32:32 +0000 Received: from [10.82.250.87] (rtp-vpn6-597.cisco.com [10.82.250.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3RHWVkr003826; Thu, 27 Apr 2017 17:32:32 GMT To: Stefan Winter References: Cc: radext@ietf.org, Enke Chen From: Enke Chen Message-ID: <689f37b3-e4e6-65ac-fd68-b4bacbd3a20f@cisco.com> Date: Thu, 27 Apr 2017 10:32:31 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [radext] Client ID exhaustion X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 17:35:08 -0000 Hi, Stefan: Yes, it does use multiple source ports. Regards, -- Enke On 4/27/17 2:00 AM, Stefan Winter wrote: > Hello, > >> The case we have is with the wireless controller that needs to manage >> thousands of APs and tens of thousands of clients. The wireless world >> uses "centralized" management model. The scaling requirements keep >> increasing every year. >> >> Though RADIUS is an old protocol, it is a critical piece in the wireless >> world. > > Your reply did not indicate whether the wireless controller implements > the MAY in RFC2865 (a piece of information I specifically asked for). > Does it? > > Greetings, > > Stefan Winter > >> >> Thanks. -- Enke >> >> On 4/26/17 5:43 AM, Stefan Winter wrote: >>> Hello, >>> >>> >>> we keep hearing assertions on the list that change is needed regarding >>> the ID field in RADIUS. >>> >>> >>> I would like to recall RFC2865's section 2.5 >>> >>> >>> "If a >>> >>> NAS needs more than 256 IDs for outstanding requests, it MAY use >>> additional source ports to send requests from, and keep track of IDs >>> for each source port. This allows up to 16 million or so outstanding >>> requests at one time to a single server." >>> >>> >>> It's fairly clear that implementations which do not follow the MAY will >>> run into exhaustion problems rather soon. >>> >>> It's less clear that implementations which do follow this MAY still do. >>> We've heard finger-in-the-air calculations on the list that this may >>> become a problem earlier than one might think. But is there actual >>> evidence to that end in deployed reality? >>> >>> Can someone please share their experience regarding a deployment and >>> implementation which DOES implement the MAY above but STILL runs out of >>> RADIUS packet IDs? >>> >>> Obviously, for those implementors which do not implement the MAY, the >>> suggestion would be to implement that before trying to make protocol >>> changes. The corresponding advice in RFC2865 may be 17 years old now, >>> but that doesn't mean it is not good advice. >>> >>> Greetings, >>> >>> Stefan Winter >>> >>> >>> >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >>> > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Thu Apr 27 11:51:55 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1FC12944A for ; Thu, 27 Apr 2017 11:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.701 X-Spam-Level: X-Spam-Status: No, score=-9.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80qhly6Rocjw for ; Thu, 27 Apr 2017 11:51:53 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 C6570129480 for ; Thu, 27 Apr 2017 11:48:47 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 8BA025A1E7186; Thu, 27 Apr 2017 18:48:44 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id v3RImkHY022934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Apr 2017 18:48:46 GMT Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [192.207.23.55]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id v3RImih3006571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Apr 2017 18:48:45 GMT Received: from igoyret-c1.nokia.com (igoyret-pc [135.227.139.12]) by cliff.eng.ascend.com (8.13.1/8.13.1) with ESMTP id v3RIowo6026896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Apr 2017 11:50:59 -0700 Message-Id: <201704271850.v3RIowo6026896@cliff.eng.ascend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 27 Apr 2017 11:46:36 -0700 To: Alan DeKok From: Ignacio Goyret Cc: Enke Chen , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [radext] Client ID exhaustion X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 18:51:55 -0000 At 08:09 4/27/2017, Alan DeKok wrote: > I've seen multiple situations where a high load RADIUS proxy continually has 32 or more source ports in use. At that point, you have to ask if it isn't more efficient to just update RADIUS. A better alternative is to use a more appropriate tool like Diameter which solves all these issues quite well. > i.e. Asking implementations to open 1-4 source ports is reasonable. Asking them to implement 2000 source ports for a high load situation is possible, but is less reasonable. Dealing with thousands of ports requires extra care but it is not an impossible task. -Ignacio From nobody Thu Apr 27 13:13:09 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362BF129C39 for ; Thu, 27 Apr 2017 13:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5cq_0aOTQzmw for ; Thu, 27 Apr 2017 13:13:06 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 86BE112956A for ; Thu, 27 Apr 2017 13:09:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id AB30F2888; Thu, 27 Apr 2017 20:09:34 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0pxly4yUMR3; Thu, 27 Apr 2017 20:09:34 +0000 (UTC) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 14D1C5BC; Thu, 27 Apr 2017 20:09:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <201704271850.v3RIowo6026896@cliff.eng.ascend.com> Date: Thu, 27 Apr 2017 16:09:32 -0400 Cc: radext@ietf.org, Enke Chen Content-Transfer-Encoding: quoted-printable Message-Id: <44D6E749-D8AF-4E34-BF03-F54D2911D486@deployingradius.com> References: <201704271850.v3RIowo6026896@cliff.eng.ascend.com> To: Ignacio Goyret X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Client ID exhaustion X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 20:13:08 -0000 On Apr 27, 2017, at 2:46 PM, Ignacio Goyret = wrote: > A better alternative is to use a more appropriate tool like Diameter > which solves all these issues quite well. There are multiple reasons why that's not going to happen. One is technical. Diameter is rather more complex than RADIUS. = People won't implement a massive new protocol just to get incremental = benefits. Another is economic. There are millions of deployments of open source = RADIUS solutions. I include in this multiple WiFI equipment vendors, = whose products simply wouldn't exist without open source. They and = their customers are just not going to pay six figures for a commercial = Diameter implementation. The biggest single failure of Diameter is it's inability to provide a = smooth upgrade path from RADIUS. >> i.e. Asking implementations to open 1-4 source ports is reasonable. = Asking them to implement 2000 source ports for a high load situation is = possible, but is less reasonable. >=20 > Dealing with thousands of ports requires extra care but it is not > an impossible task. I used said "less reasonable", not "impossible". The additional gyrations required to scale an application to 1000's of = ports are the same, or maybe slightly more complex than the changes = required by my proposal. While opening multiple source ports is a technical solution, proposals = from multiple people seem to indicate it's not a good solution. You can = believe that the people making these proposals are incompetent, or you = can believe that they have good reasons for their proposals. Alan DeKok. From nobody Thu Apr 27 17:27:32 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66F2129422 for ; Thu, 27 Apr 2017 17:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAp1Gm3NgxV8 for ; Thu, 27 Apr 2017 17:27:25 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34561129432 for ; Thu, 27 Apr 2017 17:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=103299; q=dns/txt; s=iport; t=1493339096; x=1494548696; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cI3NOjqp/pM0gH1Dp3Ti54lvjiTAfQ1FShWZlWQk4aw=; b=jydINCXPO2iGJimj6tIVDpSHdzqQzs8QjS5BSLvxNcwhhMkm6jJujuDl 1NrgHkcELLrf8iF78Dd/Yj2wzCSdRbaE/ulcZZ6+Wju3RHRck2SmxzLB5 ozy8G7aQmfPWPOwF5/MLE/LldmeB5+QF5dFrDLmQ8yQYJG+So27Zuubq3 E=; X-Files: fr-extended-id-patch.txt, fr-extid-test.txt, ATT00001.txt : 17847, 53738, 2490 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAABJiwJZ/5FdJa1YAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNVYYEMB4gGhXORTZVsggwDIQ2CQIM2AoQjPxgBAgEBAQEBAQF?= =?us-ascii?q?rHQuFFQEBAQECAQEBGAEMRwIJBQsCAQgRAwECARYBARYCJQsUCQgCBA4FCQWKB?= =?us-ascii?q?wgOsBI6iwYBAQEBAQEBAQEBAQEBAQEBAQEBAQEOD4gyK4JvgyCBKS0JAREMAwY?= =?us-ascii?q?BAQWCZoIxBYk2B4ZSgVWEboZ+AYQMghF7hkuFKIICVYRiiiWIdIJMiGYBHzg/S?= =?us-ascii?q?28VGioSAYReHIFjdQGGTwINFwSBBgGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,386,1488844800"; d="txt'?scan'208";a="416774133" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2017 00:24:52 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v3S0OqMG007654 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 28 Apr 2017 00:24:52 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Apr 2017 19:24:51 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Thu, 27 Apr 2017 19:24:51 -0500 From: "Naiming Shen (naiming)" To: "radext@ietf.org" CC: "Enke Chen (enkechen)" Thread-Topic: I-D Action: draft-chen-radext-identifier-attr-01.txt Thread-Index: AQHSvecVeRVSfOuHb0a3jOeYRQdG2qHWqbuAgAOZ+gA= Date: Fri, 28 Apr 2017 00:24:51 +0000 Message-ID: <4FF20399-6C6D-469C-85F0-E1161C1BDEFD@cisco.com> References: <149314027943.13018.17075749372313672148@ietfa.amsl.com> <87a68340-384c-b904-1fbb-872e99ae3365@cisco.com> In-Reply-To: <87a68340-384c-b904-1fbb-872e99ae3365@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.155.85] Content-Type: multipart/mixed; boundary="_004_4FF203996C6D469C85F0E1161C1BDEFDciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [radext] I-D Action: draft-chen-radext-identifier-attr-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 00:27:31 -0000 --_004_4FF203996C6D469C85F0E1161C1BDEFDciscocom_ Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi, Enclosed are two files of implementation on freeradius code base with this draft: draft-chen-radext-identifier-attr-01.txt. One is the patch and the other is the testing results of cases with multiple combinations of client, server, proxy, home-server support this feature. The diff is about 190 lines including the radtest file changes. Please take a look. Regards, - Naiming --_004_4FF203996C6D469C85F0E1161C1BDEFDciscocom_ Content-Type: text/plain; name="fr-extended-id-patch.txt" Content-Description: fr-extended-id-patch.txt Content-Disposition: attachment; filename="fr-extended-id-patch.txt"; size=17847; creation-date="Fri, 28 Apr 2017 00:24:51 GMT"; modification-date="Fri, 28 Apr 2017 00:24:51 GMT" Content-ID: <799520BE11F0974FB5033BBED5F1253B@emea.cisco.com> Content-Transfer-Encoding: base64 ICgxKSB0aGUgcGF0Y2ggaW1wbGVtZW50cyB0aGUgc3BlYyBvZiBkcmFmdC1jaGVuLXJhZGV4dC1p ZGVudGlmaWVyLWF0dHItMDEsDQogICAgIHBhdGNoIGNvZGUgYmFzZSB1c2luZyBmcmVlcmFkaXVz IDMuMS4xMg0KDQogKDIpIGR1ZSB0byB0aGUgZnJlZXJhZGl1cyB3YXkgb2YgY29kaW5nIHRoZSBh dHRyaWJ1dGVzIHVzaW5nIHRoZQ0KICAgICBSRkMgaW5jbHVkZSBmaWxlcy4gdGhlIHBhdGNoIHRl bXBvcmFyaWx5IGNyZWF0ZXMgYSBmYWtlIHJmYzkwMDAgZm9yDQogICAgIHRoaXMgSUQtQXR0ciBm ZWF0dXJlIGZvciB0aGUgcGF0Y2gsIHRoaXMgcGF0Y2ggdXNlcyB0aGUgcmFkaXVzDQogICAgIGF0 dHJpYnV0ZSBvZiAnMTkyJyAoUFdfRVhURU5ERURfSUQpIGZvciB0ZXN0aW5nDQoNCiAoMykgbmV3 IGNvbW1hbmRsaW5lIHBhcmFtZXRlcnMgb24gY2xpZW50IHNpZGUoZm9yIHBhdGNoIHRlc3RpbmcN CiAgICAgcHVycG9zZSkuIG9uIGJvdGggJ3JhZHRlc3QnIGFuZCAncmFkY2xpZW50JyBwcm9ncmFt cywgbmV3DQogICAgIHBhcmFtZXRlciAnLUknIHRvIGluZGljYXRlIHRoZSBjbGllbnQ8LT5zZXJ2 ZXIgcmFkaXVzIG1lc3NhZ2UNCiAgICAgdXNpbmcgdGhlIElELUF0dHIgZmVhdHVyZSwgYW5kIHRo ZSAnLVMnIHRvIGluZGljYXRlIGNsaWVudCB1c2luZw0KICAgICAnc3RhdHVzLXNlcnZlcicgdG8g cXVlcnkgdGhlIHNlcnZlciBzdXBwb3J0IG9mIHRoaXMgSUQtQXR0ciBmZWF0dXJlDQoNCiAoNCkg c2luY2UgdGhpcyBJRC1BdHRyIHVzZXMgdGhlICdzdGF0dXMtc2VydmVyJyBtZXNzYWdlIHRvIHF1 ZXJ5DQogICAgIHRoZSBzZXJ2ZXIgc2lkZSBzdXBwb3J0IG9mIHRoaXMgZmVhdHVyZS4gSW4gdGhp cyBwYXRjaCwgdHdvDQogICAgIGRpZmZlcmVudCB3YXlzIG9mIGRvaW5nICdzdGF0dXMtc2VydmVy JyBxdWVyeToNCg0KICAgICAtIGNsaWVudCB0byBzZXJ2ZXINCiAgICAgICByYWRjbGllbnQgdG8g dXNlICctUycgdG8gcXVlcnkgdGhlIHNlcnZlciB0byBtYWtlIHN1cmUgaXQNCiAgICAgICBzdXBw b3J0IHRoaXMgSUQtQXR0ciBmZWF0dXJlOyB0aGVuIGl0IGNhbiB1c2UgJy1JJyBmb3INCiAgICAg ICBhbnkgY29tbXVuaWNhdGlvbiB3aXRoIElELUF0dHIgZW5jb2RpbmcNCg0KICAgICAtIHByb3h5 IHRvIGhvbWUtc2VydmVyDQogICAgICAgaWYgdGhlIHByb3h5IHNlcnZlciBpcyBjb25maWd1cmVk IHRvIGFsbG93IElELUF0dHIgZmVhdHVyZSwNCiAgICAgICB3aGVuIHRoZSBwcm94eSByZWNlaXZl cyBhIG1lc3NhZ2UgZnJvbSBjbGllbnQgd2hpY2ggaXMgdGhlDQogICAgICAgZmlyc3QgdGltZSB0 byB0aGUgaG9tZS1zZXJ2ZXIsIGl0IHdpbGwgY29udmVydCBpdCB0byB0aGUNCiAgICAgICAnc3Rh dHVzLXNlcnZlcicgbWVzc2FnZSB0byBxdWVyeSB0aGlzIElELUF0dHIgc3VwcG9ydDsgVGhpcw0K ICAgICAgIGZpcnN0IG1lc3NhZ2Ugd2lsbCBiZSBkcm9wcGVkIGFuZCB0aGUgY2xpZW50IHdpbGwg cmVzZW5kIGFmdGVyDQogICAgICAgdGltZW91dC4gVGhlIHNlY29uZCBhbmQgdGhlIGxhdGVyIG1l c3NhZ2VzIGZyb20gdGhlIHByb3h5IHRvDQogICAgICAgdGhlIGhvbWUtc2VydmVyIHdpbGwgdXNl IHRoZSBJRC1BdHRyIGVuY29kaW5nIGlmIHRoZSBob21lLXNlcnZlcg0KICAgICAgIHN1cHBvcnRz IHRoYXQuDQogICAgICAgVGhpcyBpcyBzb3J0IG9mIGFuYWxvZ291cyB0byB0aGUgSUNNUCBQSU5H IHRoZSBmaXJzdCB0aW1lLCBpZg0KICAgICAgIHRoZSBBUlAgYWRkcmVzcyBpcyBub3QgcmVzb2x2 ZWQsIHRoZSBmaXJzdCBQSU5HIG1pZ2h0IGJlIGxvc3QuDQogICAgICAgQnV0IHRoZSBtZWNoYW5p c20gY2FuIGJlIGltcHJvdmVkIHdpdGggZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucy4NCg0KICg1 KSBpZiB0aGUgSUQtQXR0ciBpcyBzdXBwb3J0ZWQsIHRoZSAnZXh0LWlkJyBzdGFydHMgd2l0aCAy NTYgaW4gdGhpcw0KICAgICBwYXRjaCwgaXMgYWxsb2NhdGVkIHNlcXVlbnRpYWxseS4gIFRoZSBJ RCB3cmFwcGluZyBpcyBoYW5kbGVkLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpsZW5vdm86fi9yYWRpdXMvZnItMy4w LjEyJCBnaXQgZGlmZiAtLXN0YXQNCiBzaGFyZS9kaWN0aW9uYXJ5ICAgICAgICAgfCAgMSArDQog c2hhcmUvZGljdGlvbmFyeS5yZmM5MDAwIHwgIDYgKysrKw0KIHNyYy9pbmNsdWRlL2xpYnJhZGl1 cy5oICB8ICA2ICsrKysNCiBzcmMvaW5jbHVkZS9yYWRpdXMuaCAgICAgfCAgMSArDQogc3JjL2lu Y2x1ZGUvcmVhbG1zLmggICAgIHwgIDIgKysNCiBzcmMvbGliL3BhY2tldC5jICAgICAgICAgfCAy NyArKysrKysrKysrKysrKy0tDQogc3JjL2xpYi9yYWRpdXMuYyAgICAgICAgIHwgODIgKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tDQogc3JjL21haW4vbGlz dGVuLmMgICAgICAgIHwgIDUgKysrDQogc3JjL21haW4vcHJvY2Vzcy5jICAgICAgIHwgMjUgKysr KysrKysrKysrKy0tDQogc3JjL21haW4vcmFkY2xpZW50LmMgICAgIHwgMTYgKysrKysrKystLQ0K IHNyYy9tYWluL3JhZHRlc3QgICAgICAgICB8IDE4ICsrKysrKysrKystDQogMTEgZmlsZXMgY2hh bmdlZCwgMTc4IGluc2VydGlvbnMoKyksIDExIGRlbGV0aW9ucygtKQ0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KZGlmZiAt LWdpdCBhL3NoYXJlL2RpY3Rpb25hcnkgYi9zaGFyZS9kaWN0aW9uYXJ5DQppbmRleCAxYjM0Y2Nl Li42MGE5YmE1IDEwMDY0NA0KLS0tIGEvc2hhcmUvZGljdGlvbmFyeQ0KKysrIGIvc2hhcmUvZGlj dGlvbmFyeQ0KQEAgLTExNCw2ICsxMTQsNyBAQCAkSU5DTFVERSBkaWN0aW9uYXJ5LnJmYzcwNTUN CiAkSU5DTFVERSBkaWN0aW9uYXJ5LnJmYzcxNTUNCiAkSU5DTFVERSBkaWN0aW9uYXJ5LnJmYzcy NjgNCiAkSU5DTFVERSBkaWN0aW9uYXJ5LnJmYzc0OTkNCiskSU5DTFVERSBkaWN0aW9uYXJ5LnJm YzkwMDANCiANCiAjDQogIwlNb3N0bHkgdmFsdWVzIHdoaWNoIGhhdmUgYmVlbiBhbGxvY2F0ZWQg YnkgSUFOQSB1bmRlcg0KZGlmZiAtLWdpdCBhL3NoYXJlL2RpY3Rpb25hcnkucmZjOTAwMCBiL3No YXJlL2RpY3Rpb25hcnkucmZjOTAwMA0KaW5kZXggZTY5ZGUyOS4uNGVhOTdjYSAxMDA2NDQNCi0t LSBhL3NoYXJlL2RpY3Rpb25hcnkucmZjOTAwMA0KKysrIGIvc2hhcmUvZGljdGlvbmFyeS5yZmM5 MDAwDQpAQCAtMCwwICsxLDYgQEANCisjIC0qLSB0ZXh0IC0qLQ0KKyMgQ29weXJpZ2h0IChDKSAy MDE3IFRoZSBGcmVlUkFESVVTIFNlcnZlciBwcm9qZWN0IGFuZCBjb250cmlidXRvcnMNCisjCVRl bXAgdG8gdXNlIFJGQzkwMDAgZm9yIGNvZGUgdGVzdGluZy4gQXR0cmlidXRlIGRlZmluZWQgaW4g ZHJhZnQ6DQorIwlodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1yYWRleHQt aWRlbnRpZmllci1hdHRyLTAxLnR4dA0KKw0KK0FUVFJJQlVURQlFWFRFTkRFRC1JRAkJCQkxOTIJ b2N0ZXRzDQpkaWZmIC0tZ2l0IGEvc3JjL2luY2x1ZGUvbGlicmFkaXVzLmggYi9zcmMvaW5jbHVk ZS9saWJyYWRpdXMuaA0KaW5kZXggYTNjOGY1OC4uYjQ2MWNlYyAxMDA2NDQNCi0tLSBhL3NyYy9p bmNsdWRlL2xpYnJhZGl1cy5oDQorKysgYi9zcmMvaW5jbHVkZS9saWJyYWRpdXMuaA0KQEAgLTEz MCw2ICsxMzAsOCBAQCB0eXBlZGVmIHZvaWQgKCpzaWdfdCkoaW50KTsNCiAjZGVmaW5lIE1BWF9T VFJJTkdfTEVOCQkyNTQJLyogUkZDMjEzODogc3RyaW5nIDAtMjUzIG9jdGV0cyAqLw0KICNkZWZp bmUgRlJfTUFYX1ZFTkRPUgkJKDEgPDwgMjQpIC8qIFJGQyBsaW1pdGF0aW9ucyAqLw0KIA0KKyNk ZWZpbmUgTUFYX0VYVF9JRF9WQUxVRQkweDNmZmZmZmZmDQorI2RlZmluZSBFWFRJRF9TVEFUVVNf TUFTSwkweGMwMDAwMDAwDQogI2lmZGVmIF9MSUJSQURJVVMNCiAjICBkZWZpbmUgUkFESVVTX0hE Ul9MRU4JMjANCiAjICBkZWZpbmUgVkVORE9SUEVDX1VTUgkJNDI5DQpAQCAtMzk4LDYgKzQwMCwx MCBAQCB0eXBlZGVmIHN0cnVjdCByYWRpdXNfcGFja2V0IHsNCiAJc2l6ZV90CQkJZGF0YV9sZW47 DQogCVZBTFVFX1BBSVIJCSp2cHM7DQogCXNzaXplX3QJCQlvZmZzZXQ7DQorCXVpbnQ4X3QJCQl1 c2VfZXh0ZW5kZWRfaWQ7CS8vIHVzZSBleHRJRCBpbiBwa3QNCisJdWludDhfdAkJCWhkcl9pZDsJ CQkvLyBzYXZlIG9yaWcgSUQNCisJdWludDhfdAkJCWNsaWVudF9leHRpZF9yZXF1ZXN0OwkvLyBo YXMgc2VudCBxdWVyeQ0KKwl1aW50OF90CQkJc2VydmVyX2V4dGlkX3JlcGx5OwkvLyBzZXJ2ZXIg c3VwcG9ydCBleHRJRA0KICNpZmRlZiBXSVRIX1RDUA0KIAlzaXplX3QJCQlwYXJ0aWFsOw0KIAlp bnQJCQlwcm90bzsNCmRpZmYgLS1naXQgYS9zcmMvaW5jbHVkZS9yYWRpdXMuaCBiL3NyYy9pbmNs dWRlL3JhZGl1cy5oDQppbmRleCA0NGEyYzEzLi5jYTc0ZTRkIDEwMDY0NA0KLS0tIGEvc3JjL2lu Y2x1ZGUvcmFkaXVzLmgNCisrKyBiL3NyYy9pbmNsdWRlL3JhZGl1cy5oDQpAQCAtMTA5LDYgKzEw OSw3IEBAIHR5cGVkZWYgZW51bSB7DQogI2luY2x1ZGUgPGZyZWVyYWRpdXMtZGV2ZWwvcmZjNzA1 NS5oPg0KICNpbmNsdWRlIDxmcmVlcmFkaXVzLWRldmVsL3JmYzcxNTUuaD4NCiAjaW5jbHVkZSA8 ZnJlZXJhZGl1cy1kZXZlbC9yZmM3MjY4Lmg+DQorI2luY2x1ZGUgPGZyZWVyYWRpdXMtZGV2ZWwv cmZjOTAwMC5oPg0KIA0KIC8qDQogICoJQWxsIGludGVybmFsIGF0dHJpYnV0ZXMgYXJlIG5vdyBk ZWZpbmVkIGluIHRoaXMgZmlsZS4NCmRpZmYgLS1naXQgYS9zcmMvaW5jbHVkZS9yZWFsbXMuaCBi L3NyYy9pbmNsdWRlL3JlYWxtcy5oDQppbmRleCBkODU3MTE1Li5kYzBkM2M3IDEwMDY0NA0KLS0t IGEvc3JjL2luY2x1ZGUvcmVhbG1zLmgNCisrKyBiL3NyYy9pbmNsdWRlL3JlYWxtcy5oDQpAQCAt MTA1LDYgKzEwNSw4IEBAIHR5cGVkZWYgc3RydWN0IGhvbWVfc2VydmVyIHsNCiAJY2hhciBjb25z dAkJKnBpbmdfdXNlcl9uYW1lOw0KIAljaGFyIGNvbnN0CQkqcGluZ191c2VyX3Bhc3N3b3JkOw0K IA0KKwl1aW50OF90CQkJc2VudF9zdGF0dXNfc2VydmVyOwkvLyBTZW50IHF1ZXJ5IHRvIHNlcnZl cg0KKwl1aW50OF90CQkJc3VwcG9ydF9leHRpZDsJCS8vIEhvbWUgU2VydmVyIHN1cHBvcnRzDQog CXVpbnQzMl90CQlwaW5nX2ludGVydmFsOw0KIAl1aW50MzJfdAkJbnVtX3BpbmdzX3RvX2FsaXZl Ow0KIAl1aW50MzJfdAkJbnVtX3NlbnRfcGluZ3M7DQpkaWZmIC0tZ2l0IGEvc3JjL2xpYi9wYWNr ZXQuYyBiL3NyYy9saWIvcGFja2V0LmMNCmluZGV4IGMyNThjNjAuLjQ1OGNlNTUgMTAwNjQ0DQot LS0gYS9zcmMvbGliL3BhY2tldC5jDQorKysgYi9zcmMvbGliL3BhY2tldC5jDQpAQCAtMjQ5LDEw ICsyNDksMTMgQEAgdHlwZWRlZiBzdHJ1Y3QgZnJfcGFja2V0X3NvY2tldF90IHsNCiAJaW50CQlw cm90bzsNCiAjZW5kaWYNCiANCisJdWludDMyX3QJZXh0ZW5kZWRfaWQ7DQorCWJvb2wJCXNlcnZl cl9zdXBwb3J0X2V4dGlkOw0KIAl1aW50OF90CQlpZFszMl07DQogfSBmcl9wYWNrZXRfc29ja2V0 X3Q7DQogDQogDQorI2RlZmluZSBNQVhfSERSX0lEICgyNTUpDQogI2RlZmluZSBGTlZfTUFHSUNf UFJJTUUgKDB4MDEwMDAxOTMpDQogI2RlZmluZSBNQVhfU09DS0VUUyAoMjU2KQ0KICNkZWZpbmUg U09DS09GRlNFVF9NQVNLIChNQVhfU09DS0VUUyAtIDEpDQpAQCAtNDMwLDYgKzQzMyw3IEBAIGJv b2wgZnJfcGFja2V0X2xpc3Rfc29ja2V0X2FkZChmcl9wYWNrZXRfbGlzdF90ICpwbCwgaW50IHNv Y2tmZCwgaW50IHByb3RvLA0KIAkgKglBcyB0aGUgbGFzdCBzdGVwIGJlZm9yZSByZXR1cm5pbmcu DQogCSAqLw0KIAlwcy0+c29ja2ZkID0gc29ja2ZkOw0KKwlwcy0+ZXh0ZW5kZWRfaWQgPSBNQVhf SERSX0lEICsgMTsNCiAJcGwtPm51bV9zb2NrZXRzKys7DQogDQogCXJldHVybiB0cnVlOw0KQEAg LTc2MCw2ICs3NjQsMTggQEAgYm9vbCBmcl9wYWNrZXRfbGlzdF9pZF9hbGxvYyhmcl9wYWNrZXRf bGlzdF90ICpwbCwgaW50IHByb3RvLA0KIAkJICoJT3RoZXJ3aXNlLCB0aGlzIHNvY2tldCBpcyBP SyB0byB1c2UuDQogCQkgKi8NCiANCisJCWlmIChyZXF1ZXN0LT51c2VfZXh0ZW5kZWRfaWQgJiYN CisJCSAgICAocmVxdWVzdC0+Y29kZSAhPSBQV19DT0RFX1NUQVRVU19TRVJWRVIpKSB7DQorCQkJ cHMtPmV4dGVuZGVkX2lkKys7DQorCQkJaWYgKHBzLT5leHRlbmRlZF9pZCA+IE1BWF9FWFRfSURf VkFMVUUpIHsNCisJCQkJcHMtPmV4dGVuZGVkX2lkID0gTUFYX0hEUl9JRCArIDE7DQorCQkJfQ0K KwkJCWlkID0gcHMtPmV4dGVuZGVkX2lkOw0KKwkJCWZkID0gaTsNCisJCQlyZXF1ZXN0LT5oZHJf aWQgPSBNQVhfSERSX0lEOw0KKwkJCWJyZWFrOw0KKwkJfQ0KKw0KIAkJLyoNCiAJCSAqCUxvb2sg Zm9yIGEgZnJlZSBJZCwgc3RhcnRpbmcgZnJvbSBhIHJhbmRvbSBudW1iZXIuDQogCQkgKi8NCkBA IC04MTksNyArODM1LDkgQEAgYm9vbCBmcl9wYWNrZXRfbGlzdF9pZF9hbGxvYyhmcl9wYWNrZXRf bGlzdF90ICpwbCwgaW50IHByb3RvLA0KIAkgKglNYXJrIHRoZSBJRCBhcyBmcmVlLiAgVGhpcyBp cyB0aGUgb25lIGxpbmUgZnJvbQ0KIAkgKglpZF9mcmVlKCkgdGhhdCB3ZSBjYXJlIGFib3V0IGhl cmUuDQogCSAqLw0KLQlwcy0+aWRbKHJlcXVlc3QtPmlkID4+IDMpICYgMHgxZl0gJj0gfigxIDw8 IChyZXF1ZXN0LT5pZCAmIDB4MDcpKTsNCisJaWYgKHJlcXVlc3QtPmlkIDw9IE1BWF9IRFJfSUQp IHsNCisJCXBzLT5pZFsocmVxdWVzdC0+aWQgPj4gMykgJiAweDFmXSAmPSB+KDEgPDwgKHJlcXVl c3QtPmlkICYgMHgwNykpOw0KKwl9DQogDQogCXJlcXVlc3QtPmlkID0gLTE7DQogCXJlcXVlc3Qt PnNvY2tmZCA9IC0xOw0KQEAgLTg1Myw3ICs4NzEsMTIgQEAgYm9vbCBmcl9wYWNrZXRfbGlzdF9p ZF9mcmVlKGZyX3BhY2tldF9saXN0X3QgKnBsLA0KIAl9DQogI2VuZGlmDQogDQotCXBzLT5pZFso cmVxdWVzdC0+aWQgPj4gMykgJiAweDFmXSAmPSB+KDEgPDwgKHJlcXVlc3QtPmlkICYgMHgwNykp Ow0KKwlpZiAocmVxdWVzdC0+aWQgPD0gTUFYX0hEUl9JRCkgew0KKwkJcHMtPmlkWyhyZXF1ZXN0 LT5pZCA+PiAzKSAmIDB4MWZdICY9IH4oMSA8PCAocmVxdWVzdC0+aWQgJiAweDA3KSk7DQorCX0N CisJaWYgKHJlcXVlc3QtPnNlcnZlcl9leHRpZF9yZXBseSkgew0KKwkJcHMtPnNlcnZlcl9zdXBw b3J0X2V4dGlkID0gdHJ1ZTsNCisJfQ0KIA0KIAlwcy0+bnVtX291dGdvaW5nLS07DQogCXBsLT5u dW1fb3V0Z29pbmctLTsNCmRpZmYgLS1naXQgYS9zcmMvbGliL3JhZGl1cy5jIGIvc3JjL2xpYi9y YWRpdXMuYw0KaW5kZXggNTNkNDVlMi4uZjI4YTdiMCAxMDA2NDQNCi0tLSBhL3NyYy9saWIvcmFk aXVzLmMNCisrKyBiL3NyYy9saWIvcmFkaXVzLmMNCkBAIC04Niw2ICs4NiwxNiBAQCB0eXBlZGVm IHN0cnVjdCByYWRpdXNfcGFja2V0X3Qgew0KICAgdWludDhfdAlkYXRhWzFdOw0KIH0gcmFkaXVz X3BhY2tldF90Ow0KIA0KK3R5cGVkZWYgc3RydWN0IENDX0hJTlQoX19wYWNrZWRfXykgcmFkaXVz X2V4dGlkX3Qgew0KKwl1aW50MTZfdAlpZF9jb2RlX2xlbmd0aDsJCS8vIGF0dHIgY29kZSBhbmQg bGVuZ3RoDQorCXVpbnQzMl90CXN0YXR1c19leHRpZDsJCS8vIHN0YXR1cyBhbmQgZXh0LWlkIGZp ZWxkcw0KK30gcmFkaXVzX2V4dGlkX3Q7DQorDQorI2RlZmluZSBQV19FWFRJRF9DT0RFTEVOCShQ V19FWFRFTkRFRF9JRCA8PCA4KSArIHNpemVvZihyYWRpdXNfZXh0aWRfdCkNCisjZGVmaW5lIFJB RElVU19IRFJfQU5EX0VYVElEX0xFTglSQURJVVNfSERSX0xFTiArIHNpemVvZihyYWRpdXNfZXh0 aWRfdCkNCisjZGVmaW5lIEVYVElEX1JFUVVFU1QJCQlodG9ubCgxIDw8IDMwKQ0KKyNkZWZpbmUg RVhUSURfUkVTUE9ORF9BQ0sJCWh0b25sKDIgPDwgMzApDQorI2RlZmluZSBFWFRJRF9SRVNQT05E X05BSwkJaHRvbmwoMyA8PCAzMCkNCiBzdGF0aWMgZnJfcmFuZGN0eCBmcl9yYW5kX3Bvb2w7CS8q IGFjcm9zcyBtdWx0aXBsZSBjYWxscyAqLw0KIHN0YXRpYyBpbnQgZnJfcmFuZF9pbml0aWFsaXpl ZCA9IDA7DQogc3RhdGljIHVuc2lnbmVkIGludCBzYWx0X29mZnNldCA9IDA7DQpAQCAtMTc0NSw2 ICsxNzU1LDggQEAgaW50IHJhZF9lbmNvZGUoUkFESVVTX1BBQ0tFVCAqcGFja2V0LCBSQURJVVNf UEFDS0VUIGNvbnN0ICpvcmlnaW5hbCwNCiAJICoJQSA0SyBwYWNrZXQsIGFsaWduZWQgb24gNjQt Yml0cy4NCiAJICovDQogCXVpbnQ2NF90CWRhdGFbTUFYX1BBQ0tFVF9MRU4gLyBzaXplb2YodWlu dDY0X3QpXTsNCisJcmFkaXVzX2V4dGlkX3QJCWV4dGlkOw0KKwlib29sCQkJc3RhdHVzX3NlcnZl cl9leHRpZCA9IGZhbHNlOw0KIA0KIAkvKg0KIAkgKglEb3VibGUtY2hlY2sgc29tZSB0aGluZ3Mg YmFzZWQgb24gcGFja2V0IGNvZGUuDQpAQCAtMTc4MiwxNiArMTc5NCw1MCBAQCBpbnQgcmFkX2Vu Y29kZShSQURJVVNfUEFDS0VUICpwYWNrZXQsIFJBRElVU19QQUNLRVQgY29uc3QgKm9yaWdpbmFs LA0KIAkgKglCdWlsZCBzdGFuZGFyZCBoZWFkZXINCiAJICovDQogCWhkci0+Y29kZSA9IHBhY2tl dC0+Y29kZTsNCi0JaGRyLT5pZCA9IHBhY2tldC0+aWQ7DQorCWlmICghcGFja2V0LT51c2VfZXh0 ZW5kZWRfaWQpIHsNCisJCWhkci0+aWQgPSBwYWNrZXQtPmlkOw0KKwkJaWYgKG9yaWdpbmFsICYm IChvcmlnaW5hbC0+Y29kZSA9PSBQV19DT0RFX1NUQVRVU19TRVJWRVIpICYmDQorCQkgICAgKG9y aWdpbmFsLT5kYXRhX2xlbiA+PSBSQURJVVNfSERSX0FORF9FWFRJRF9MRU4pKSB7DQorCQkJbWVt Y3B5KCZleHRpZCwgJm9yaWdpbmFsLT5kYXRhW1JBRElVU19IRFJfTEVOXSwNCisJCQkgICAgICAg c2l6ZW9mKGV4dGlkKSk7DQorCQkJaWYgKChleHRpZC5pZF9jb2RlX2xlbmd0aCA9PQ0KKwkJCSAg ICAgaHRvbnMoUFdfRVhUSURfQ09ERUxFTikpICYmDQorCQkJICAgIChleHRpZC5zdGF0dXNfZXh0 aWQgPT0gRVhUSURfUkVRVUVTVCkpIHsNCisJCQkJcmFkaXVzX2V4dGlkX3QgKm5ld19leHRpZDsN CisJCQkJbmV3X2V4dGlkID0gKHJhZGl1c19leHRpZF90ICopJmhkci0+ZGF0YVswXTsNCisJCQkJ bmV3X2V4dGlkLT5pZF9jb2RlX2xlbmd0aCA9DQorCQkJCQlodG9ucyhQV19FWFRJRF9DT0RFTEVO KTsNCisJCQkJbmV3X2V4dGlkLT5zdGF0dXNfZXh0aWQgPSBFWFRJRF9SRVNQT05EX0FDSzsNCisJ CQkJc3RhdHVzX3NlcnZlcl9leHRpZCA9IHRydWU7DQorCQkJfQ0KKwkJfQ0KKwl9IGVsc2Ugew0K KwkJbWVtc2V0KCZleHRpZCwgMCwgc2l6ZW9mKGV4dGlkKSk7DQorCQlpZiAocGFja2V0LT5jb2Rl ID09IFBXX0NPREVfU1RBVFVTX1NFUlZFUikgew0KKwkJCWhkci0+aWQgPSBwYWNrZXQtPmlkOw0K KwkJCXBhY2tldC0+Y2xpZW50X2V4dGlkX3JlcXVlc3QgPSAxOw0KKwkJCWV4dGlkLnN0YXR1c19l eHRpZCA9IEVYVElEX1JFUVVFU1Q7DQorCQl9IGVsc2Ugew0KKwkJCWhkci0+aWQgPSBwYWNrZXQt Pmhkcl9pZDsNCisJCQlleHRpZC5zdGF0dXNfZXh0aWQgPSBodG9ubChwYWNrZXQtPmlkICYNCisJ CQkJCQkgICBNQVhfRVhUX0lEX1ZBTFVFKTsNCisJCX0NCisJCWV4dGlkLmlkX2NvZGVfbGVuZ3Ro ID0gaHRvbnMoUFdfRVhUSURfQ09ERUxFTik7DQorCQltZW1jcHkoJmhkci0+ZGF0YVswXSwgJmV4 dGlkLCBzaXplb2YoZXh0aWQpKTsNCisJfQ0KIA0KIAltZW1jcHkoaGRyLT52ZWN0b3IsIHBhY2tl dC0+dmVjdG9yLCBzaXplb2YoaGRyLT52ZWN0b3IpKTsNCiANCi0JdG90YWxfbGVuZ3RoID0gUkFE SVVTX0hEUl9MRU47DQorCXRvdGFsX2xlbmd0aCA9ICghcGFja2V0LT51c2VfZXh0ZW5kZWRfaWQg JiYgIXN0YXR1c19zZXJ2ZXJfZXh0aWQpID8NCisJCVJBRElVU19IRFJfTEVOIDogUkFESVVTX0hE Ul9MRU4gKyBzaXplb2YoZXh0aWQpOw0KIA0KIAkvKg0KIAkgKglMb2FkIHVwIHRoZSBjb25maWd1 cmF0aW9uIHZhbHVlcyBmb3IgdGhlIHVzZXINCiAJICovDQogCXB0ciA9IGhkci0+ZGF0YTsNCisJ aWYgKHBhY2tldC0+dXNlX2V4dGVuZGVkX2lkIHx8IHN0YXR1c19zZXJ2ZXJfZXh0aWQpIHsNCisJ CXB0ciArPSBzaXplb2YoZXh0aWQpOw0KKwl9DQogCXBhY2tldC0+b2Zmc2V0ID0gMDsNCiANCiAJ LyoNCkBAIC0xODUwLDYgKzE4OTYsMTIgQEAgaW50IHJhZF9lbmNvZGUoUkFESVVTX1BBQ0tFVCAq cGFja2V0LCBSQURJVVNfUEFDS0VUIGNvbnN0ICpvcmlnaW5hbCwNCiAJCQl9DQogCQl9DQogDQor CQlpZiAoKHJlcGx5LT52cF9sZW5ndGggPT0gNCkgJiYNCisJCSAgICAocmVwbHktPmRhLT5hdHRy ID09IFBXX0VYVEVOREVEX0lEKSkgew0KKwkJCXJlcGx5ID0gcmVwbHktPm5leHQ7DQorCQkJY29u dGludWU7DQorCQl9DQorDQogCQkvKg0KIAkJICoJU2V0IHRoZSBNZXNzYWdlLUF1dGhlbnRpY2F0 b3IgdG8gdGhlIGNvcnJlY3QNCiAJCSAqCWxlbmd0aCBhbmQgaW5pdGlhbCB2YWx1ZS4NCkBAIC0y MzQ0LDYgKzIzOTYsNyBAQCBib29sIHJhZF9wYWNrZXRfb2soUkFESVVTX1BBQ0tFVCAqcGFja2V0 LCBpbnQgZmxhZ3MsIGRlY29kZV9mYWlsX3QgKnJlYXNvbikNCiAJYm9vbAkJCXNlZW5fbWEgPSBm YWxzZTsNCiAJdWludDMyX3QJCW51bV9hdHRyaWJ1dGVzOw0KIAlkZWNvZGVfZmFpbF90CQlmYWls dXJlID0gREVDT0RFX0ZBSUxfTk9ORTsNCisJcmFkaXVzX2V4dGlkX3QJICAgICAgICAqZXh0aWQ7 DQogDQogCS8qDQogCSAqCUNoZWNrIGZvciBwYWNrZXRzIHNtYWxsZXIgdGhhbiB0aGUgcGFja2V0 IGhlYWRlci4NCkBAIC0yNTQzLDcgKzI1OTYsMTQgQEAgYm9vbCByYWRfcGFja2V0X29rKFJBRElV U19QQUNLRVQgKnBhY2tldCwgaW50IGZsYWdzLCBkZWNvZGVfZmFpbF90ICpyZWFzb24pDQogCQlk ZWZhdWx0OgkvKiBkb24ndCBkbyBhbnl0aGluZyBieSBkZWZhdWx0ICovDQogCQkJYnJlYWs7DQog DQotCQkJLyoNCisJCSAgY2FzZSBQV19FWFRFTkRFRF9JRDoNCisJCSAgICBleHRpZCA9IChyYWRp dXNfZXh0aWRfdCAqKSZhdHRyWzBdOw0KKwkJICAgIGlmIChleHRpZC0+c3RhdHVzX2V4dGlkID09 IEVYVElEX1JFU1BPTkRfQUNLKSB7DQorCQkJICAgIHBhY2tldC0+c2VydmVyX2V4dGlkX3JlcGx5 ID0gMTsNCisJCSAgICB9DQorCQkgICAgYnJlYWs7DQorDQorCQkgICAgLyoNCiAJCQkgKglJZiB0 aGVyZSdzIGFuIEVBUC1NZXNzYWdlLCB3ZSByZXF1aXJlDQogCQkJICoJYSBNZXNzYWdlLUF1dGhl bnRpY2F0b3IuDQogCQkJICovDQpAQCAtMjYzMCw3ICsyNjkwLDIxIEBAIGJvb2wgcmFkX3BhY2tl dF9vayhSQURJVVNfUEFDS0VUICpwYWNrZXQsIGludCBmbGFncywgZGVjb2RlX2ZhaWxfdCAqcmVh c29uKQ0KIAkgKglGaWxsIFJBRElVUyBoZWFkZXIgZmllbGRzDQogCSAqLw0KIAlwYWNrZXQtPmNv ZGUgPSBoZHItPmNvZGU7DQotCXBhY2tldC0+aWQgPSBoZHItPmlkOw0KKwlleHRpZCA9IChyYWRp dXNfZXh0aWRfdCAqKSAmcGFja2V0LT5kYXRhW1JBRElVU19IRFJfTEVOXTsNCisJaWYgKChwYWNr ZXQtPmRhdGFfbGVuID49IFJBRElVU19IRFJfQU5EX0VYVElEX0xFTikgJiYNCisJICAgIChoZHIt PmNvZGUgIT0gUFdfQ09ERV9TVEFUVVNfU0VSVkVSKSAmJg0KKwkgICAgKGV4dGlkLT5pZF9jb2Rl X2xlbmd0aCA9PSBodG9ucyhQV19FWFRJRF9DT0RFTEVOKSkpIHsNCisJCWlmICghKG50b2hsKGV4 dGlkLT5zdGF0dXNfZXh0aWQpICYgRVhUSURfU1RBVFVTX01BU0spKSB7DQorCQkJcGFja2V0LT5p ZCA9IG50b2hsKGV4dGlkLT5zdGF0dXNfZXh0aWQpICYNCisJCQkJTUFYX0VYVF9JRF9WQUxVRTsN CisJCQlwYWNrZXQtPmhkcl9pZCA9IGhkci0+aWQ7DQorCQkJcGFja2V0LT51c2VfZXh0ZW5kZWRf aWQgPSAxOw0KKwkJfSBlbHNlIHsNCisJCQlwYWNrZXQtPmlkID0gaGRyLT5pZDsNCisJCX0NCisJ fSBlbHNlIHsNCisJCXBhY2tldC0+aWQgPSBoZHItPmlkOw0KKwl9DQogCW1lbWNweShwYWNrZXQt PnZlY3RvciwgaGRyLT52ZWN0b3IsIEFVVEhfVkVDVE9SX0xFTik7DQogDQogDQpkaWZmIC0tZ2l0 IGEvc3JjL21haW4vbGlzdGVuLmMgYi9zcmMvbWFpbi9saXN0ZW4uYw0KaW5kZXggNjVlNWM4Yi4u NjVjYTczNSAxMDA2NDQNCi0tLSBhL3NyYy9tYWluL2xpc3Rlbi5jDQorKysgYi9zcmMvbWFpbi9s aXN0ZW4uYw0KQEAgLTIxNjcsNiArMjE2NywxMSBAQCBzdGF0aWMgaW50IGNsaWVudF9zb2NrZXRf ZGVjb2RlKFVOVVNFRCByYWRfbGlzdGVuX3QgKmxpc3RlbmVyLCBSRVFVRVNUICpyZXF1ZXN0KQ0K ICNpZmRlZiBXSVRIX1BST1hZDQogc3RhdGljIGludCBwcm94eV9zb2NrZXRfZW5jb2RlKFVOVVNF RCByYWRfbGlzdGVuX3QgKmxpc3RlbmVyLCBSRVFVRVNUICpyZXF1ZXN0KQ0KIHsNCisJaWYgKChy ZXF1ZXN0LT5wYWNrZXQtPmNvZGUgPT0gUFdfQ09ERV9BQ0NFU1NfUkVRVUVTVCkgJiYNCisJICAg ICFyZXF1ZXN0LT5ob21lX3NlcnZlci0+c2VudF9zdGF0dXNfc2VydmVyKSB7DQorCQlyZXF1ZXN0 LT5wcm94eS0+Y29kZSA9IFBXX0NPREVfU1RBVFVTX1NFUlZFUjsNCisJCXJlcXVlc3QtPnByb3h5 LT51c2VfZXh0ZW5kZWRfaWQgPSAxOw0KKwl9DQogCWlmIChyYWRfZW5jb2RlKHJlcXVlc3QtPnBy b3h5LCBOVUxMLCByZXF1ZXN0LT5ob21lX3NlcnZlci0+c2VjcmV0KSA8IDApIHsNCiAJCVJFUlJP UigiRmFpbGVkIGVuY29kaW5nIHByb3hpZWQgcGFja2V0OiAlcyIsIGZyX3N0cmVycm9yKCkpOw0K IA0KZGlmZiAtLWdpdCBhL3NyYy9tYWluL3Byb2Nlc3MuYyBiL3NyYy9tYWluL3Byb2Nlc3MuYw0K aW5kZXggNWVjMTZlNi4uY2FjNTY0OCAxMDA2NDQNCi0tLSBhL3NyYy9tYWluL3Byb2Nlc3MuYw0K KysrIGIvc3JjL21haW4vcHJvY2Vzcy5jDQpAQCAtMTQ0MSw2ICsxNDQxLDEwIEBAIHN0YXRpYyB2 b2lkIHJlcXVlc3RfZmluaXNoKFJFUVVFU1QgKnJlcXVlc3QsIGludCBhY3Rpb24pDQogI2VuZGlm DQogCX0NCiANCisJaWYgKHJlcXVlc3QtPnByb3h5ICYmIChyZXF1ZXN0LT5wcm94eS0+Y29kZSA9 PSBQV19DT0RFX1NUQVRVU19TRVJWRVIpKSB7DQorCQlyZXF1ZXN0X2NsZWFudXBfZGVsYXlfaW5p dChyZXF1ZXN0KTsNCisJCXJldHVybjsNCisJfQ0KIAkvKg0KIAkgKglTZW5kIHRoZSByZXBseS4N CiAJICovDQpAQCAtMTg3NCw2ICsxODc4LDggQEAgc3RhdGljIFJFUVVFU1QgKnJlcXVlc3Rfc2V0 dXAoVEFMTE9DX0NUWCAqY3R4LCByYWRfbGlzdGVuX3QgKmxpc3RlbmVyLCBSQURJVVNfUEENCiAJ cmVxdWVzdC0+cmVwbHktPnNyY19wb3J0ID0gcmVxdWVzdC0+cGFja2V0LT5kc3RfcG9ydDsNCiAJ cmVxdWVzdC0+cmVwbHktPmlkID0gcmVxdWVzdC0+cGFja2V0LT5pZDsNCiAJcmVxdWVzdC0+cmVw bHktPmNvZGUgPSAwOyAvKiBVTktOT1dOIGNvZGUgKi8NCisJcmVxdWVzdC0+cmVwbHktPnVzZV9l eHRlbmRlZF9pZCA9IHJlcXVlc3QtPnBhY2tldC0+dXNlX2V4dGVuZGVkX2lkOw0KKwlyZXF1ZXN0 LT5yZXBseS0+aGRyX2lkID0gcmVxdWVzdC0+cGFja2V0LT5oZHJfaWQ7DQogCW1lbWNweShyZXF1 ZXN0LT5yZXBseS0+dmVjdG9yLCByZXF1ZXN0LT5wYWNrZXQtPnZlY3RvciwNCiAJICAgICAgIHNp emVvZihyZXF1ZXN0LT5yZXBseS0+dmVjdG9yKSk7DQogCXJlcXVlc3QtPnJlcGx5LT52cHMgPSBO VUxMOw0KQEAgLTIxNzIsNiArMjE3OCwxMCBAQCBzdGF0aWMgaW50IGluc2VydF9pbnRvX3Byb3h5 X2hhc2goUkVRVUVTVCAqcmVxdWVzdCkNCiAJcmVxdWVzdC0+bnVtX3Byb3hpZWRfcmVxdWVzdHMg PSAxOw0KIAlyZXF1ZXN0LT5udW1fcHJveGllZF9yZXNwb25zZXMgPSAwOw0KIA0KKwlpZiAocmVx dWVzdC0+aG9tZV9zZXJ2ZXItPnN1cHBvcnRfZXh0aWQpIHsNCisJCXJlcXVlc3QtPnByb3h5LT51 c2VfZXh0ZW5kZWRfaWQgPSAxOw0KKwl9DQorDQogCWZvciAodHJpZXMgPSAwOyB0cmllcyA8IDI7 IHRyaWVzKyspIHsNCiAJCXJhZF9saXN0ZW5fdCAqdGhpczsNCiAJCWxpc3Rlbl9zb2NrZXRfdCAq c29jazsNCkBAIC0yNDM1LDYgKzI0NDUsMTMgQEAgc3RhdGljIHZvaWQgbWFya19ob21lX3NlcnZl cl9hbGl2ZShSRVFVRVNUICpyZXF1ZXN0LCBob21lX3NlcnZlcl90ICpob21lKQ0KIA0KIAlmcl9l dmVudF9kZWxldGUoZWwsICZob21lLT5ldik7DQogDQorCWlmIChyZXF1ZXN0LT5wcm94eS0+Y29k ZSA9PSBQV19DT0RFX1NUQVRVU19TRVJWRVIpIHsNCisJCWhvbWUtPnNlbnRfc3RhdHVzX3NlcnZl ciA9IHRydWU7DQorCQlpZiAocmVxdWVzdC0+cHJveHlfcmVwbHktPnNlcnZlcl9leHRpZF9yZXBs eSkgew0KKwkJCWhvbWUtPnN1cHBvcnRfZXh0aWQgPSAxOw0KKwkJCVJERUJVRygiSG9tZSBTZXJ2 ZXIgJXMgc3VwcG9ydHMgSUQgQXR0cmlidXRlIiwgaG9tZS0+bmFtZSk7DQorCQl9DQorCX0NCiAJ UlBST1hZKCJNYXJraW5nIGhvbWUgc2VydmVyICVzIHBvcnQgJWQgYWxpdmUiLA0KIAkgICAgICAg aW5ldF9udG9wKHJlcXVlc3QtPnByb3h5LT5kc3RfaXBhZGRyLmFmLA0KIAkJCSAmcmVxdWVzdC0+ cHJveHktPmRzdF9pcGFkZHIuaXBhZGRyLA0KQEAgLTM5ODIsOCArMzk5OSwxMiBAQCBzdGF0aWMg dm9pZCBwcm94eV93YWl0X2Zvcl9yZXBseShSRVFVRVNUICpyZXF1ZXN0LCBpbnQgYWN0aW9uKQ0K IAkJICoJV2UgcmVjZWl2ZWQgYSBuZXcgcmVwbHkuICBHbyBwcm9jZXNzIGl0Lg0KIAkJICovDQog CWNhc2UgRlJfQUNUSU9OX1BST1hZX1JFUExZOg0KLQkJcmVxdWVzdF9xdWV1ZV9vcl9ydW4ocmVx dWVzdCwgcHJveHlfcnVubmluZyk7DQotCQlicmVhazsNCisJICBpZiAocmVxdWVzdC0+cHJveHkt PmNvZGUgPT0gUFdfQ09ERV9TVEFUVVNfU0VSVkVSKSB7DQorCQkgIHJlcXVlc3RfcXVldWVfb3Jf cnVuKHJlcXVlc3QsIHByb3h5X25vX3JlcGx5KTsNCisJICB9IGVsc2Ugew0KKwkJICByZXF1ZXN0 X3F1ZXVlX29yX3J1bihyZXF1ZXN0LCBwcm94eV9ydW5uaW5nKTsNCisJICB9DQorCSAgYnJlYWs7 DQogDQogCWRlZmF1bHQ6DQogCQlSREVCVUczKCIlczogSWdub3JpbmcgYWN0aW9uICVzIiwgX19G VU5DVElPTl9fLCBhY3Rpb25fY29kZXNbYWN0aW9uXSk7DQpkaWZmIC0tZ2l0IGEvc3JjL21haW4v cmFkY2xpZW50LmMgYi9zcmMvbWFpbi9yYWRjbGllbnQuYw0KaW5kZXggNzU5NGVkNC4uZTQzMWJk NCAxMDA2NDQNCi0tLSBhL3NyYy9tYWluL3JhZGNsaWVudC5jDQorKysgYi9zcmMvbWFpbi9yYWRj bGllbnQuYw0KQEAgLTEwNzQsNyArMTA3NCw2IEBAIHN0YXRpYyBpbnQgcmVjdl9vbmVfcGFja2V0 KGludCB3YWl0X3RpbWUpDQogCQlSREVCVUcoIiVzIHJlc3BvbnNlIGNvZGUgJWQiLCByZXF1ZXN0 LT5maWxlcy0+cGFja2V0cywgcmVwbHktPmNvZGUpOw0KIAl9DQogDQotCWRlYWxsb2NhdGVfaWQo cmVxdWVzdCk7DQogCXJlcXVlc3QtPnJlcGx5ID0gcmVwbHk7DQogCXJlcGx5ID0gTlVMTDsNCiAN CkBAIC0xMTQwLDExICsxMTM5LDE4IEBAIHN0YXRpYyBpbnQgcmVjdl9vbmVfcGFja2V0KGludCB3 YWl0X3RpbWUpDQogCQl9DQogCX0NCiANCisJaWYgKHJlcXVlc3QtPnBhY2tldC0+Y2xpZW50X2V4 dGlkX3JlcXVlc3QgJiYNCisJICAgIHJlcXVlc3QtPnJlcGx5LT5zZXJ2ZXJfZXh0aWRfcmVwbHkp IHsNCisJCXJlcXVlc3QtPnBhY2tldC0+c2VydmVyX2V4dGlkX3JlcGx5ID0gMTsNCisJCVJERUJV RygiU2VydmVyIHN1cHBvcnRzIElEIEF0dHJpYnV0ZSIpOw0KKwl9DQorDQogCWlmIChyZXF1ZXN0 LT5yZXNlbmQgPT0gcmVzZW5kX2NvdW50KSB7DQogCQlyZXF1ZXN0LT5kb25lID0gdHJ1ZTsNCiAJ fQ0KIA0KIHBhY2tldF9kb25lOg0KKwlkZWFsbG9jYXRlX2lkKHJlcXVlc3QpOw0KIAlyYWRfZnJl ZSgmcmVxdWVzdC0+cmVwbHkpOw0KIAlyYWRfZnJlZSgmcmVwbHkpOwkvKiBtYXkgYmUgTlVMTCAq Lw0KIA0KQEAgLTExNjMsNiArMTE2OSw3IEBAIGludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJn dikNCiAJaW50CQlwYXJhbGxlbCA9IDE7DQogCXJjX3JlcXVlc3RfdAkqdGhpczsNCiAJaW50CQlm b3JjZV9hZiA9IEFGX1VOU1BFQzsNCisJaW50CQl1c2VfZXh0ZW5kZWRfaWQgPSAwOw0KIA0KIAkv Kg0KIAkgKglJdCdzIGVhc2llciBoYXZpbmcgdHdvIHNldHMgb2YgZmxhZ3MgdG8gc2V0IHRoZQ0K QEAgLTExODgsNyArMTE5NSw3IEBAIGludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndikNCiAJ CWV4aXQoMSk7DQogCX0NCiANCi0Jd2hpbGUgKChjID0gZ2V0b3B0KGFyZ2MsIGFyZ3YsICI0NmM6 ZDpEOmY6RmhpOm46cDpxcjpzUzp0OnZ4Ig0KKwl3aGlsZSAoKGMgPSBnZXRvcHQoYXJnYywgYXJn diwgIjQ2YzpkOkQ6ZjpGaGk6STpuOnA6cXI6c1M6dDp2eCINCiAjaWZkZWYgV0lUSF9UQ1ANCiAJ CSJQOiINCiAjZW5kaWYNCkBAIC0xMjQ5LDYgKzEyNTYsMTAgQEAgaW50IG1haW4oaW50IGFyZ2Ms IGNoYXIgKiphcmd2KQ0KIAkJCX0NCiAJCQlicmVhazsNCiANCisJCWNhc2UgJ0knOgkvKiBVc2Ug SUQtQXR0cmlidXRlICovDQorCQkJdXNlX2V4dGVuZGVkX2lkID0gMTsNCisJCQlicmVhazsNCisN CiAJCWNhc2UgJ24nOg0KIAkJCXBlcnNlYyA9IGF0b2kob3B0YXJnKTsNCiAJCQlpZiAocGVyc2Vj IDw9IDApIHVzYWdlKCk7DQpAQCAtMTQ3OCw2ICsxNDg5LDcgQEAgaW50IG1haW4oaW50IGFyZ2Ms IGNoYXIgKiphcmd2KQ0KIAlmb3IgKHRoaXMgPSByZXF1ZXN0X2hlYWQ7IHRoaXMgIT0gTlVMTDsg dGhpcyA9IHRoaXMtPm5leHQpIHsNCiAJCXRoaXMtPnBhY2tldC0+c3JjX2lwYWRkciA9IGNsaWVu dF9pcGFkZHI7DQogCQl0aGlzLT5wYWNrZXQtPnNyY19wb3J0ID0gY2xpZW50X3BvcnQ7DQorCQl0 aGlzLT5wYWNrZXQtPnVzZV9leHRlbmRlZF9pZCA9IHVzZV9leHRlbmRlZF9pZDsNCiAJCWlmIChy YWRjbGllbnRfc2FuZSh0aGlzKSAhPSAwKSB7DQogCQkJZXhpdCgxKTsNCiAJCX0NCmRpZmYgLS1n aXQgYS9zcmMvbWFpbi9yYWR0ZXN0IGIvc3JjL21haW4vcmFkdGVzdA0KaW5kZXggNjIxYmQ1ZS4u Y2MzZWQ2MiAxMDA3NTUNCi0tLSBhL3NyYy9tYWluL3JhZHRlc3QNCisrKyBiL3NyYy9tYWluL3Jh ZHRlc3QNCkBAIC0zNCw2ICszNCw3IEBAIHJhZGVhcGNsaWVudD0kYmluZGlyL3JhZGVhcGNsaWVu dA0KIE9QVElPTlM9DQogUEFTU1dPUkQ9IlVzZXItUGFzc3dvcmQiDQogTkFTX0FERFJfQVRUUj0i TkFTLUlQLUFkZHJlc3MiDQorU0VSVklDRT0iYXV0aCINCiANCiAjICBXZSBuZWVkIGF0IExFQVNU IHRoZXNlIG1hbnkgb3B0aW9ucw0KIGlmIFsgJCMgLWx0IDUgXQ0KQEAgLTY3LDYgKzY4LDE1IEBA IGRvDQogCQlPUFRJT05TPSIkT1BUSU9OUyAteCINCiAJCXNoaWZ0DQogCQk7Ow0KKwktSSkNCisJ CU9QVElPTlM9IiRPUFRJT05TIC1JIC14Ig0KKwkJc2hpZnQNCisJCTs7DQorCS1TKQ0KKwkJT1BU SU9OUz0iJE9QVElPTlMgLUkgLXgiDQorCQlTRVJWSUNFPSJzdGF0dXMiDQorCQlzaGlmdA0KKwkJ OzsNCiANCiAJLXQpDQogCQlzaGlmdDsNCkBAIC0xMTYsNiArMTI2LDggQEAgZWxzZQ0KIGZpDQog DQogKA0KKyAgICBpZiBbICIkU0VSVklDRSIgIT0gInN0YXR1cyIgXQ0KKyAgICAgICB0aGVuDQog CWVjaG8gIlVzZXItTmFtZSA9IFwiJDFcIiINCiAJZWNobyAiJFBBU1NXT1JEID0gXCIkMlwiIg0K IAllY2hvICIkTkFTX0FERFJfQVRUUiA9ICRuYXMiDQpAQCAtMTMwLDYgKzE0MiwxMCBAQCBmaQ0K IAl0aGVuDQogCQllY2hvICJGcmFtZWQtUHJvdG9jb2wgPSBQUFAiDQogCWZpDQotKSB8ICRyYWRj bGllbnQgJE9QVElPTlMgLXggJDMgYXV0aCAiJDUiDQorICAgIGVsc2UNCisJZWNobyAiTWVzc2Fn ZS1BdXRoZW50aWNhdG9yID0gMHgwMCINCisjCWVjaG8gIlVzZXItTmFtZSA9IFwiJDFcIiINCisJ ZmkNCispIHwgJHJhZGNsaWVudCAkT1BUSU9OUyAteCAkMyAkU0VSVklDRSAiJDUiDQogDQogZXhp dCAkPw0K --_004_4FF203996C6D469C85F0E1161C1BDEFDciscocom_ Content-Type: text/plain; name="fr-extid-test.txt" Content-Description: fr-extid-test.txt Content-Disposition: attachment; filename="fr-extid-test.txt"; size=53738; creation-date="Fri, 28 Apr 2017 00:24:51 GMT"; modification-date="Fri, 28 Apr 2017 00:24:51 GMT" Content-ID: <5CB22EAA63E4FC478CFB310292EB8432@emea.cisco.com> Content-Transfer-Encoding: base64 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQogVG9wb2xvZ3kgZm9yIEV4dGVuZGVkLUlEIEF0dHJpYnV0ZQ0KDQogIC0g dHdvIGxpbnV4IGJveGVzIHdpdGggbW9kaWZpZWQgZnJlZXJhZGl1cyBzb2Z0d2FyZS4NCiAgICBv bmUgcmFkaXVzIGNsaWVudCBhbmQgb25lIHJhZGl1cyBzZXJ2ZXIgb24gdGhlIHNhbWUgbGludXgg aG9zdChsZW5vdm8pOw0KICAgIG9uZSByYWRpdXMgaG9tZS1zZXJ2ZXIgb24gYW5vdGhlciBsaW51 eCBob3N0KHZhaW8pDQoNCiAgLSBsZW5vdm8sIElQIGFkZHJlc3MgMTkyLjE2OC4xLjEwMCwgVWJ1 bnR1IDE2LjA0LjEsIGZyZWVyYWRpdXMgMy4wLjEyDQogICAgdmFpbywgSVAgYWRkcmVzcyAxOTIu MTY4LjEuMzUsIENlbnRPUyA2LCBmcmVlcmFkaXVzIDMuMC4xMg0KDQogIC0gYWxpY2VAbXktb3Jn LmNvbSBpcyBwcm92aXNpb25lZCBvbiBsb2NhbCBzZXJ2ZXIgb24gbGVub3ZvLA0KICAgIGJvYkB5 b3VyLW9yZy5jb20gYW5kIGNhdGh5QHlvdXItb3JnLmNvbSBhcmUgcHJvdmlzaW9uZWQgYXQgcmVt b3RlDQogICAgaG9tZS1zZXJ2ZXIgb24gdmFpbyB3aXRoIHlvdXItb3JnLmNvbSBkb21haW4NCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KIFRvcG9sb2d5IGZvciBFeHRlbmRlZC1JRCBBdHRyaWJ1dGUNCg0KICAtIHR3 byBsaW51eCBib3hlcyB3aXRoIG1vZGlmaWVkIGZyZWVyYWRpdXMgc29mdHdhcmUuDQogICAgb25l IHJhZGl1cyBjbGllbnQgYW5kIG9uZSByYWRpdXMgc2VydmVyIG9uIHRoZSBzYW1lIGxpbnV4IGhv c3QobGVub3ZvKTsNCiAgICBvbmUgcmFkaXVzIGhvbWUtc2VydmVyIG9uIGFub3RoZXIgbGludXgg aG9zdCh2YWlvKQ0KDQogIC0gbGVub3ZvLCBJUCBhZGRyZXNzIDE5Mi4xNjguMS4xMDAsIFVidW50 dSAxNi4wNC4xLCBmcmVlcmFkaXVzIDMuMC4xMg0KICAgIHZhaW8sIElQIGFkZHJlc3MgMTkyLjE2 OC4xLjM1LCBDZW50T1MgNiwgZnJlZXJhZGl1cyAzLjAuMTINCg0KICAtIGFsaWNlQG15LW9yZy5j b20gaXMgcHJvdmlzaW9uZWQgb24gbG9jYWwgc2VydmVyIG9uIGxlbm92bywNCiAgICBib2JAeW91 ci1vcmcuY29tIGFuZCBjYXRoeUB5b3VyLW9yZy5jb20gYXJlIHByb3Zpc2lvbmVkIGF0IHJlbW90 ZQ0KICAgIGhvbWUtc2VydmVyIG9uIHZhaW8gd2l0aCB5b3VyLW9yZy5jb20gZG9tYWluDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCiAgVGVzdCBDYXNlczoNCg0KICgxKSBBdXRoIHdpdGggcmFkaXVzIHNlcnZlciAo d2l0aG91dCBleHQtSUQpDQogICAgICdyYWR0ZXN0IGFsaWNlQG15LW9yZy5jb20gcGFzc21lIDEy Ny4wLjAuMSAxMDAgdGVzdGluZzEyMycNCiAoMikgUXVlcnkgc2VydmVyIHN1cHBvcnQgb2YgZXh0 LUlEIChzZW5kaW5nIFN0YXR1cy1TZXJ2ZXIpDQogICAgICdyYWR0ZXN0IC1TIGFsaWNlQG15LW9y Zy5jb20gcGFzc21lIDEyNy4wLjAuMSAxMDAgdGVzdGluZzEyMycNCiAoMykgQXV0aCB3aXRoIHJh ZGl1cyBzZXJ2ZXIgKHVzaW5nIGV4dC1JRCkNCiAgICAgJ3JhZHRlc3QgLUkgYWxpY2VAbXktb3Jn LmNvbSBwYXNzbWUgMTI3LjAuMC4xIDEwMCB0ZXN0aW5nMTIzJw0KICg0KSBBdXRoIHdpdGggcHJv eHkgc2VydmVyICh1c2luZyBleHQtSUQgYmV0d2VlbiBwcm94eSBhbmQgaG9tZS1zZXJ2ZXIpDQog ICAgICdyYWR0ZXN0IC1JIGJvYkB5b3VyLW9yZy5jb20gcGFzc2JvYiAxMjcuMC4wLjEgMTAwIHRl c3RpbmcxMjMnDQogKDUpIEF1dGggYW5vdGhlciB1c2VyIHdpdGggdGhlIHNhbWUgaG9tZS1zZXJ2 ZXIgKHVzaW5nIGV4dC1JRCkNCiAgICAgJ3JhZHRlc3QgLUkgY2F0aHlAeW91ci1vcmcuY29tIHBh c3NjYXRoeSAxMjcuMC4wLjEgMTAwIHRlc3RpbmcxMjMnDQogKDYpIEF1dGggd2l0aCBwcm94eSBz ZXJ2ZXIgKG5vIGV4dC1JRCBiZXR3ZWVuIGNsaWVudCBhbmQgcHJveHksIGJ1dA0KICAgICAgIHdp dGggZXh0LUlEIGJldHdlZW4gcHJveHkgYW5kIGhvbWUtc2VydmVyKQ0KICAgICAncmFkdGVzdCBj YXRoeUB5b3VyLW9yZy5jb20gcGFzc2NhdGh5IDEyNy4wLjAuMSAxMDAgdGVzdGluZzEyMycNCiAo NykgQXV0aCB3aXRoIElQdjYgdHJhbnNwb3J0IHRvIHJhZGl1cyBzZXJ2ZXIgKGFuZCB3aXRoIGV4 dC1JRCkNCiAgICAgJ3JhZHRlc3QgLTYgLUkgYWxpY2VAbXktb3JnLmNvbSBwYXNzbWUgWzo6MV0g MTAwIHRlc3RpbmcxMjMnDQogKDgpIEF1dGggdXNpbmcgSVB2NiB0byBwcm94eSBzZXJ2ZXIsIGFu ZCBJUHY0IGJldHdlZW4gcHJveHkgYW5kIGhvbWUtc2VydmVyDQogICAgICdyYWR0ZXN0IC02IC1J IGJvYkB5b3VyLW9yZy5jb20gcGFzc2JvYiBbOjoxXSAxMDAgdGVzdGluZzEyMycNCiAgICAgDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiAgICAgDQogVGVzdCByZXN1bHRzIGFuZCBzY3JlZW4gb3V0cHV0KGNsaWVu dCwgc2VydmVyLCBwcm94eSkgaW4gZGVidWcgbW9kZToNCiANCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICgxKSBB dXRoIHdpdGggcmFkaXVzIHNlcnZlciAod2l0aG91dCBleHQtSUQpDQogICAgICdyYWR0ZXN0IGFs aWNlQG15LW9yZy5jb20gcGFzc21lIDEyNy4wLjAuMSAxMDAgdGVzdGluZzEyMycNCiAgICAgTm90 ZTogYXV0aGVudGljYXRlZCBPSw0KICAgICBPdXRwdXQgb2YgY2xpZW50IGFuZCBzZXJ2ZXIgYmVs b3c6DQoNCiBjbGllbnQ6DQoNCmxlbm92bzp+L3JhZGl1cy9mci0zLjAuMTIkIHJhZHRlc3QgYWxp Y2VAbXktb3JnLmNvbSBwYXNzbWUgMTI3LjAuMC4xIDEwMCB0ZXN0aW5nMTIzDQpTZW50IEFjY2Vz cy1SZXF1ZXN0IElkIDk3IGZyb20gMC4wLjAuMDozMzk0MSB0byAxMjcuMC4wLjE6MTgxMiBsZW5n dGggODYNCglVc2VyLU5hbWUgPSAiYWxpY2VAbXktb3JnLmNvbSINCglVc2VyLVBhc3N3b3JkID0g InBhc3NtZSINCglOQVMtSVAtQWRkcmVzcyA9IDEyNy4wLjAuMQ0KCU5BUy1Qb3J0ID0gMTAwDQoJ TWVzc2FnZS1BdXRoZW50aWNhdG9yID0gMHgwMA0KCUNsZWFydGV4dC1QYXNzd29yZCA9ICJwYXNz bWUiDQpSZWNlaXZlZCBBY2Nlc3MtQWNjZXB0IElkIDk3IGZyb20gMTI3LjAuMC4xOjE4MTIgdG8g MC4wLjAuMDowIGxlbmd0aCAzNw0KCVR1bm5lbC1UeXBlOjAgPSBWTEFODQoJVHVubmVsLU1lZGl1 bS1UeXBlOjAgPSBJRUVFLTgwMg0KCVR1bm5lbC1Qcml2YXRlLUdyb3VwLUlkOjAgPSAiMTAwIg0K bGVub3ZvOn4vcmFkaXVzL2ZyLTMuMC4xMiQgDQoNCiBzZXJ2ZXI6DQoNClJlYWR5IHRvIHByb2Nl c3MgcmVxdWVzdHMNCg0KDQooMCkgUmVjZWl2ZWQgQWNjZXNzLVJlcXVlc3QgSWQgOTcgZnJvbSAx MjcuMC4wLjE6MzM5NDEgdG8gMTI3LjAuMC4xOjE4MTIgbGVuZ3RoIDg2DQooMCkgICBVc2VyLU5h bWUgPSAiYWxpY2VAbXktb3JnLmNvbSINCigwKSAgIFVzZXItUGFzc3dvcmQgPSAicGFzc21lIg0K KDApICAgTkFTLUlQLUFkZHJlc3MgPSAxMjcuMC4wLjENCigwKSAgIE5BUy1Qb3J0ID0gMTAwDQoo MCkgICBNZXNzYWdlLUF1dGhlbnRpY2F0b3IgPSAweDMxYTIyMzhkZDZjMTg2YWMyYjM0NDYwMzk2 M2EyOTEyDQooMCkgIyBFeGVjdXRpbmcgc2VjdGlvbiBhdXRob3JpemUgZnJvbSBmaWxlIC91c3Iv bG9jYWwvZXRjL3JhZGRiL3NpdGVzLWVuYWJsZWQvZGVmYXVsdA0KKDApICAgYXV0aG9yaXplIHsN CigwKSAgICAgcG9saWN5IGZpbHRlcl91c2VybmFtZSB7DQooMCkgICAgICAgaWYgKCZVc2VyLU5h bWUpIHsNCigwKSAgICAgICBpZiAoJlVzZXItTmFtZSkgIC0+IFRSVUUNCigwKSAgICAgICBpZiAo JlVzZXItTmFtZSkgIHsNCigwKSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC8gLykgew0KKDAp ICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gLyAvKSAgLT4gRkFMU0UNCigwKSAgICAgICAgIGlm ICgmVXNlci1OYW1lID1+IC9AW15AXSpALyApIHsNCigwKSAgICAgICAgIGlmICgmVXNlci1OYW1l ID1+IC9AW15AXSpALyApICAtPiBGQUxTRQ0KKDApICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4g L1wuXC4vICkgew0KKDApICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL1wuXC4vICkgIC0+IEZB TFNFDQooMCkgICAgICAgICBpZiAoKCZVc2VyLU5hbWUgPX4gL0AvKSAmJiAoJlVzZXItTmFtZSAh fiAvQCguKylcLiguKykkLykpICB7DQooMCkgICAgICAgICBpZiAoKCZVc2VyLU5hbWUgPX4gL0Av KSAmJiAoJlVzZXItTmFtZSAhfiAvQCguKylcLiguKykkLykpICAgLT4gRkFMU0UNCigwKSAgICAg ICAgIGlmICgmVXNlci1OYW1lID1+IC9cLiQvKSAgew0KKDApICAgICAgICAgaWYgKCZVc2VyLU5h bWUgPX4gL1wuJC8pICAgLT4gRkFMU0UNCigwKSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9A XC4vKSAgew0KKDApICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL0BcLi8pICAgLT4gRkFMU0UN CigwKSAgICAgICB9ICMgaWYgKCZVc2VyLU5hbWUpICA9IG5vdGZvdW5kDQooMCkgICAgIH0gIyBw b2xpY3kgZmlsdGVyX3VzZXJuYW1lID0gbm90Zm91bmQNCigwKSAgICAgW3ByZXByb2Nlc3NdID0g b2sNCigwKSAgICAgW2NoYXBdID0gbm9vcA0KKDApICAgICBbbXNjaGFwXSA9IG5vb3ANCigwKSAg ICAgW2RpZ2VzdF0gPSBub29wDQooMCkgc3VmZml4OiBDaGVja2luZyBmb3Igc3VmZml4IGFmdGVy ICJAIg0KKDApIHN1ZmZpeDogTG9va2luZyB1cCByZWFsbSAibXktb3JnLmNvbSIgZm9yIFVzZXIt TmFtZSA9ICJhbGljZUBteS1vcmcuY29tIg0KKDApIHN1ZmZpeDogRm91bmQgcmVhbG0gIm15LW9y Zy5jb20iDQooMCkgc3VmZml4OiBBZGRpbmcgU3RyaXBwZWQtVXNlci1OYW1lID0gImFsaWNlIg0K KDApIHN1ZmZpeDogQWRkaW5nIFJlYWxtID0gIm15LW9yZy5jb20iDQooMCkgc3VmZml4OiBBdXRo ZW50aWNhdGlvbiByZWFsbSBpcyBMT0NBTA0KKDApICAgICBbc3VmZml4XSA9IG9rDQooMCkgICAg IGlmICggcmVxdWVzdDpSZWFsbSA9PSAiTlVMTCIgKXsNCigwKSAgICAgaWYgKCByZXF1ZXN0OlJl YWxtID09ICJOVUxMIiApIC0+IEZBTFNFDQooMCkgZWFwOiBObyBFQVAtTWVzc2FnZSwgbm90IGRv aW5nIEVBUA0KKDApICAgICBbZWFwXSA9IG5vb3ANCigwKSAgICAgW3VuaXhdID0gbm90Zm91bmQN CigwKSBmaWxlczogdXNlcnM6IE1hdGNoZWQgZW50cnkgYWxpY2UgYXQgbGluZSAxDQooMCkgICAg IFtmaWxlc10gPSBvaw0KKDApICAgICBbZXhwaXJhdGlvbl0gPSBub29wDQooMCkgICAgIFtsb2dp bnRpbWVdID0gbm9vcA0KKDApICAgICBbcGFwXSA9IHVwZGF0ZWQNCigwKSAgIH0gIyBhdXRob3Jp emUgPSB1cGRhdGVkDQooMCkgRm91bmQgQXV0aC1UeXBlID0gUEFQDQooMCkgIyBFeGVjdXRpbmcg Z3JvdXAgZnJvbSBmaWxlIC91c3IvbG9jYWwvZXRjL3JhZGRiL3NpdGVzLWVuYWJsZWQvZGVmYXVs dA0KKDApICAgQXV0aC1UeXBlIFBBUCB7DQooMCkgcGFwOiBMb2dpbiBhdHRlbXB0IHdpdGggcGFz c3dvcmQNCigwKSBwYXA6IENvbXBhcmluZyB3aXRoICJrbm93biBnb29kIiBDbGVhcnRleHQtUGFz c3dvcmQNCigwKSBwYXA6IFVzZXIgYXV0aGVudGljYXRlZCBzdWNjZXNzZnVsbHkNCigwKSAgICAg W3BhcF0gPSBvaw0KKDApICAgfSAjIEF1dGgtVHlwZSBQQVAgPSBvaw0KKDApICMgRXhlY3V0aW5n IHNlY3Rpb24gcG9zdC1hdXRoIGZyb20gZmlsZSAvdXNyL2xvY2FsL2V0Yy9yYWRkYi9zaXRlcy1l bmFibGVkL2RlZmF1bHQNCigwKSAgIHBvc3QtYXV0aCB7DQooMCkgICAgIHVwZGF0ZSB7DQooMCkg ICAgICAgTm8gYXR0cmlidXRlcyB1cGRhdGVkDQooMCkgICAgIH0gIyB1cGRhdGUgPSBub29wDQoo MCkgICAgIFtleGVjXSA9IG5vb3ANCigwKSAgICAgcG9saWN5IHJlbW92ZV9yZXBseV9tZXNzYWdl X2lmX2VhcCB7DQooMCkgICAgICAgaWYgKCZyZXBseTpFQVAtTWVzc2FnZSAmJiAmcmVwbHk6UmVw bHktTWVzc2FnZSkgew0KKDApICAgICAgIGlmICgmcmVwbHk6RUFQLU1lc3NhZ2UgJiYgJnJlcGx5 OlJlcGx5LU1lc3NhZ2UpICAtPiBGQUxTRQ0KKDApICAgICAgIGVsc2Ugew0KKDApICAgICAgICAg W25vb3BdID0gbm9vcA0KKDApICAgICAgIH0gIyBlbHNlID0gbm9vcA0KKDApICAgICB9ICMgcG9s aWN5IHJlbW92ZV9yZXBseV9tZXNzYWdlX2lmX2VhcCA9IG5vb3ANCigwKSAgIH0gIyBwb3N0LWF1 dGggPSBub29wDQooMCkgU2VudCBBY2Nlc3MtQWNjZXB0IElkIDk3IGZyb20gMTI3LjAuMC4xOjE4 MTIgdG8gMTI3LjAuMC4xOjMzOTQxIGxlbmd0aCAwDQooMCkgICBUdW5uZWwtVHlwZSA9IFZMQU4N CigwKSAgIFR1bm5lbC1NZWRpdW0tVHlwZSA9IElFRUUtODAyDQooMCkgICBUdW5uZWwtUHJpdmF0 ZS1Hcm91cC1JZCA9ICIxMDAiDQooMCkgRmluaXNoZWQgcmVxdWVzdA0KV2FraW5nIHVwIGluIDQu OSBzZWNvbmRzLg0KKDApIENsZWFuaW5nIHVwIHJlcXVlc3QgcGFja2V0IElEIDk3IHdpdGggdGlt ZXN0YW1wICs1Mw0KUmVhZHkgdG8gcHJvY2VzcyByZXF1ZXN0cw0KDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K ICgyKSBRdWVyeSBzZXJ2ZXIgc3VwcG9ydCBvZiBleHQtSUQgKHNlbmRpbmcgU3RhdHVzLVNlcnZl cikNCiAgICAgJ3JhZHRlc3QgLVMgYWxpY2VAbXktb3JnLmNvbSBwYXNzbWUgMTI3LjAuMC4xIDEw MCB0ZXN0aW5nMTIzJw0KICAgICBOb3RlOiBzZXJ2ZXIgZG9lcyBzdXBwb3J0IGV4dC1JRA0KICAg ICBPdXRwdXQgb2YgY2xpZW50IGFuZCBzZXJ2ZXIgYmVsb3c6DQoNCiBjbGllbnQ6DQoNCmxlbm92 bzp+L3JhZGl1cy9mci0zLjAuMTIkIHJhZHRlc3QgLVMgYWxpY2VAbXktb3JnLmNvbSBwYXNzbWUg MTI3LjAuMC4xIDEwMCB0ZXN0aW5nMTIzDQpTZW50IFN0YXR1cy1TZXJ2ZXIgSWQgMzUgZnJvbSAw LjAuMC4wOjMzODQ4IHRvIDEyNy4wLjAuMToxODEyIGxlbmd0aCA0NA0KCU1lc3NhZ2UtQXV0aGVu dGljYXRvciA9IDB4MDANClJlY2VpdmVkIEFjY2Vzcy1BY2NlcHQgSWQgMzUgZnJvbSAxMjcuMC4w LjE6MTgxMiB0byAwLjAuMC4wOjAgbGVuZ3RoIDI2DQoJRVhURU5ERUQtSUQgPSAweDgwMDAwMDAw DQooMCkgU2VydmVyIHN1cHBvcnRzIElEIEF0dHJpYnV0ZQ0KbGVub3ZvOn4vcmFkaXVzL2ZyLTMu MC4xMiQgDQoNCiBzZXJ2ZXI6DQoNClJlYWR5IHRvIHByb2Nlc3MgcmVxdWVzdHMNCigxKSBSZWNl aXZlZCBTdGF0dXMtU2VydmVyIElkIDM1IGZyb20gMTI3LjAuMC4xOjMzODQ4IHRvIDEyNy4wLjAu MToxODEyIGxlbmd0aCA0NA0KKDEpICAgRVhURU5ERUQtSUQgPSAweDQwMDAwMDAwDQooMSkgICBN ZXNzYWdlLUF1dGhlbnRpY2F0b3IgPSAweGNkOGYwMjFjM2YwOTgwOGU1NTY0ZWYyYzU3YjFkZThl DQooMSkgU2VudCBBY2Nlc3MtQWNjZXB0IElkIDM1IGZyb20gMTI3LjAuMC4xOjE4MTIgdG8gMTI3 LjAuMC4xOjMzODQ4IGxlbmd0aCAwDQooMSkgRmluaXNoZWQgcmVxdWVzdA0KV2FraW5nIHVwIGlu IDQuOSBzZWNvbmRzLg0KKDEpIENsZWFuaW5nIHVwIHJlcXVlc3QgcGFja2V0IElEIDM1IHdpdGgg dGltZXN0YW1wICsyNzENClJlYWR5IHRvIHByb2Nlc3MgcmVxdWVzdHMNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQogKDMpIEF1dGggd2l0aCByYWRpdXMgc2VydmVyICh1c2luZyBleHQtSUQpDQogICAgICdyYWR0 ZXN0IC1JIGFsaWNlQG15LW9yZy5jb20gcGFzc21lIDEyNy4wLjAuMSAxMDAgdGVzdGluZzEyMycN CiAgICAgTm90ZTogc2VydmVyIGF1dGhlbnRpY2F0ZWQgb2sgd2l0aCBleHQtSUQNCiAgICAgT3V0 cHV0IG9mIGNsaWVudCBhbmQgc2VydmVyIGJlbG93Og0KDQogY2xpZW50Og0KDQpuaW1pbmdAbGVu b3ZvOn4vcmFkaXVzL2ZyLTMuMC4xMiQgcmFkdGVzdCAtSSBhbGljZUBteS1vcmcuY29tIHBhc3Nt ZSAxMjcuMC4wLjEgMTAwIHRlc3RpbmcxMjMNClNlbnQgQWNjZXNzLVJlcXVlc3QgSWQgMjU3IGZy b20gMC4wLjAuMDo0OTM4NSB0byAxMjcuMC4wLjE6MTgxMiBsZW5ndGggOTINCglVc2VyLU5hbWUg PSAiYWxpY2VAbXktb3JnLmNvbSINCglVc2VyLVBhc3N3b3JkID0gInBhc3NtZSINCglOQVMtSVAt QWRkcmVzcyA9IDEyNy4wLjAuMQ0KCU5BUy1Qb3J0ID0gMTAwDQoJTWVzc2FnZS1BdXRoZW50aWNh dG9yID0gMHgwMA0KCUNsZWFydGV4dC1QYXNzd29yZCA9ICJwYXNzbWUiDQpSZWNlaXZlZCBBY2Nl c3MtQWNjZXB0IElkIDI1NyBmcm9tIDEyNy4wLjAuMToxODEyIHRvIDAuMC4wLjA6MCBsZW5ndGgg NDMNCglFWFRFTkRFRC1JRCA9IDB4MDAwMDAyMDENCglUdW5uZWwtVHlwZTowID0gVkxBTg0KCVR1 bm5lbC1NZWRpdW0tVHlwZTowID0gSUVFRS04MDINCglUdW5uZWwtUHJpdmF0ZS1Hcm91cC1JZDow ID0gIjEwMCINCmxlbm92bzp+L3JhZGl1cy9mci0zLjAuMTIkIA0KDQogc2VydmVyOg0KDQpSZWFk eSB0byBwcm9jZXNzIHJlcXVlc3RzDQoNCg0KKDIpIFJlY2VpdmVkIEFjY2Vzcy1SZXF1ZXN0IElk IDI1NyBmcm9tIDEyNy4wLjAuMTo0OTM4NSB0byAxMjcuMC4wLjE6MTgxMiBsZW5ndGggOTINCigy KSAgIEVYVEVOREVELUlEID0gMHgwMDAwMDIwMQ0KKDIpICAgVXNlci1OYW1lID0gImFsaWNlQG15 LW9yZy5jb20iDQooMikgICBVc2VyLVBhc3N3b3JkID0gInBhc3NtZSINCigyKSAgIE5BUy1JUC1B ZGRyZXNzID0gMTI3LjAuMC4xDQooMikgICBOQVMtUG9ydCA9IDEwMA0KKDIpICAgTWVzc2FnZS1B dXRoZW50aWNhdG9yID0gMHgyZDMxZjkyZWRhZjlmZTMyODExOGEzOWYyYjNiMDIyNw0KKDIpICMg RXhlY3V0aW5nIHNlY3Rpb24gYXV0aG9yaXplIGZyb20gZmlsZSAvdXNyL2xvY2FsL2V0Yy9yYWRk Yi9zaXRlcy1lbmFibGVkL2RlZmF1bHQNCigyKSAgIGF1dGhvcml6ZSB7DQooMikgICAgIHBvbGlj eSBmaWx0ZXJfdXNlcm5hbWUgew0KKDIpICAgICAgIGlmICgmVXNlci1OYW1lKSB7DQooMikgICAg ICAgaWYgKCZVc2VyLU5hbWUpICAtPiBUUlVFDQooMikgICAgICAgaWYgKCZVc2VyLU5hbWUpICB7 DQooMikgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvIC8pIHsNCigyKSAgICAgICAgIGlmICgm VXNlci1OYW1lID1+IC8gLykgIC0+IEZBTFNFDQooMikgICAgICAgICBpZiAoJlVzZXItTmFtZSA9 fiAvQFteQF0qQC8gKSB7DQooMikgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvQFteQF0qQC8g KSAgLT4gRkFMU0UNCigyKSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9cLlwuLyApIHsNCigy KSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9cLlwuLyApICAtPiBGQUxTRQ0KKDIpICAgICAg ICAgaWYgKCgmVXNlci1OYW1lID1+IC9ALykgJiYgKCZVc2VyLU5hbWUgIX4gL0AoLispXC4oLisp JC8pKSAgew0KKDIpICAgICAgICAgaWYgKCgmVXNlci1OYW1lID1+IC9ALykgJiYgKCZVc2VyLU5h bWUgIX4gL0AoLispXC4oLispJC8pKSAgIC0+IEZBTFNFDQooMikgICAgICAgICBpZiAoJlVzZXIt TmFtZSA9fiAvXC4kLykgIHsNCigyKSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9cLiQvKSAg IC0+IEZBTFNFDQooMikgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvQFwuLykgIHsNCigyKSAg ICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9AXC4vKSAgIC0+IEZBTFNFDQooMikgICAgICAgfSAj IGlmICgmVXNlci1OYW1lKSAgPSBub3Rmb3VuZA0KKDIpICAgICB9ICMgcG9saWN5IGZpbHRlcl91 c2VybmFtZSA9IG5vdGZvdW5kDQooMikgICAgIFtwcmVwcm9jZXNzXSA9IG9rDQooMikgICAgIFtj aGFwXSA9IG5vb3ANCigyKSAgICAgW21zY2hhcF0gPSBub29wDQooMikgICAgIFtkaWdlc3RdID0g bm9vcA0KKDIpIHN1ZmZpeDogQ2hlY2tpbmcgZm9yIHN1ZmZpeCBhZnRlciAiQCINCigyKSBzdWZm aXg6IExvb2tpbmcgdXAgcmVhbG0gIm15LW9yZy5jb20iIGZvciBVc2VyLU5hbWUgPSAiYWxpY2VA bXktb3JnLmNvbSINCigyKSBzdWZmaXg6IEZvdW5kIHJlYWxtICJteS1vcmcuY29tIg0KKDIpIHN1 ZmZpeDogQWRkaW5nIFN0cmlwcGVkLVVzZXItTmFtZSA9ICJhbGljZSINCigyKSBzdWZmaXg6IEFk ZGluZyBSZWFsbSA9ICJteS1vcmcuY29tIg0KKDIpIHN1ZmZpeDogQXV0aGVudGljYXRpb24gcmVh bG0gaXMgTE9DQUwNCigyKSAgICAgW3N1ZmZpeF0gPSBvaw0KKDIpICAgICBpZiAoIHJlcXVlc3Q6 UmVhbG0gPT0gIk5VTEwiICl7DQooMikgICAgIGlmICggcmVxdWVzdDpSZWFsbSA9PSAiTlVMTCIg KSAtPiBGQUxTRQ0KKDIpIGVhcDogTm8gRUFQLU1lc3NhZ2UsIG5vdCBkb2luZyBFQVANCigyKSAg ICAgW2VhcF0gPSBub29wDQooMikgICAgIFt1bml4XSA9IG5vdGZvdW5kDQooMikgZmlsZXM6IHVz ZXJzOiBNYXRjaGVkIGVudHJ5IGFsaWNlIGF0IGxpbmUgMQ0KKDIpICAgICBbZmlsZXNdID0gb2sN CigyKSAgICAgW2V4cGlyYXRpb25dID0gbm9vcA0KKDIpICAgICBbbG9naW50aW1lXSA9IG5vb3AN CigyKSAgICAgW3BhcF0gPSB1cGRhdGVkDQooMikgICB9ICMgYXV0aG9yaXplID0gdXBkYXRlZA0K KDIpIEZvdW5kIEF1dGgtVHlwZSA9IFBBUA0KKDIpICMgRXhlY3V0aW5nIGdyb3VwIGZyb20gZmls ZSAvdXNyL2xvY2FsL2V0Yy9yYWRkYi9zaXRlcy1lbmFibGVkL2RlZmF1bHQNCigyKSAgIEF1dGgt VHlwZSBQQVAgew0KKDIpIHBhcDogTG9naW4gYXR0ZW1wdCB3aXRoIHBhc3N3b3JkDQooMikgcGFw OiBDb21wYXJpbmcgd2l0aCAia25vd24gZ29vZCIgQ2xlYXJ0ZXh0LVBhc3N3b3JkDQooMikgcGFw OiBVc2VyIGF1dGhlbnRpY2F0ZWQgc3VjY2Vzc2Z1bGx5DQooMikgICAgIFtwYXBdID0gb2sNCigy KSAgIH0gIyBBdXRoLVR5cGUgUEFQID0gb2sNCigyKSAjIEV4ZWN1dGluZyBzZWN0aW9uIHBvc3Qt YXV0aCBmcm9tIGZpbGUgL3Vzci9sb2NhbC9ldGMvcmFkZGIvc2l0ZXMtZW5hYmxlZC9kZWZhdWx0 DQooMikgICBwb3N0LWF1dGggew0KKDIpICAgICB1cGRhdGUgew0KKDIpICAgICAgIE5vIGF0dHJp YnV0ZXMgdXBkYXRlZA0KKDIpICAgICB9ICMgdXBkYXRlID0gbm9vcA0KKDIpICAgICBbZXhlY10g PSBub29wDQooMikgICAgIHBvbGljeSByZW1vdmVfcmVwbHlfbWVzc2FnZV9pZl9lYXAgew0KKDIp ICAgICAgIGlmICgmcmVwbHk6RUFQLU1lc3NhZ2UgJiYgJnJlcGx5OlJlcGx5LU1lc3NhZ2UpIHsN CigyKSAgICAgICBpZiAoJnJlcGx5OkVBUC1NZXNzYWdlICYmICZyZXBseTpSZXBseS1NZXNzYWdl KSAgLT4gRkFMU0UNCigyKSAgICAgICBlbHNlIHsNCigyKSAgICAgICAgIFtub29wXSA9IG5vb3AN CigyKSAgICAgICB9ICMgZWxzZSA9IG5vb3ANCigyKSAgICAgfSAjIHBvbGljeSByZW1vdmVfcmVw bHlfbWVzc2FnZV9pZl9lYXAgPSBub29wDQooMikgICB9ICMgcG9zdC1hdXRoID0gbm9vcA0KKDIp IFNlbnQgQWNjZXNzLUFjY2VwdCBJZCAyNTcgZnJvbSAxMjcuMC4wLjE6MTgxMiB0byAxMjcuMC4w LjE6NDkzODUgbGVuZ3RoIDANCigyKSAgIFR1bm5lbC1UeXBlID0gVkxBTg0KKDIpICAgVHVubmVs LU1lZGl1bS1UeXBlID0gSUVFRS04MDINCigyKSAgIFR1bm5lbC1Qcml2YXRlLUdyb3VwLUlkID0g IjEwMCINCigyKSBGaW5pc2hlZCByZXF1ZXN0DQpXYWtpbmcgdXAgaW4gNC45IHNlY29uZHMuDQoo MikgQ2xlYW5pbmcgdXAgcmVxdWVzdCBwYWNrZXQgSUQgMjU3IHdpdGggdGltZXN0YW1wICs0NDQN ClJlYWR5IHRvIHByb2Nlc3MgcmVxdWVzdHMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICg0KSBBdXRoIHdpdGgg cHJveHkgc2VydmVyICh1c2luZyBleHQtSUQgYmV0d2VlbiBwcm94eSBhbmQgaG9tZS1zZXJ2ZXIp DQogICAgICdyYWR0ZXN0IC1JIGJvYkB5b3VyLW9yZy5jb20gcGFzc2JvYiAxMjcuMC4wLjEgMTAw IHRlc3RpbmcxMjMnDQogICAgIE5vdGU6IHRoZSBmaXJzdCBjbGllbnQgcmVxdWVzdCBwYWNrZXQg aXMgdXNlZCBmb3IgcHJveHktc2VydmVyIHRvDQogICAgICAgICAgIHF1ZXJ5IHRoZSBob21lLXNl cnZlciBleHQtSUQgc3VwcG9ydA0KICAgIE91dHB1dCBvZiBjbGllbnQgYW5kIHNlcnZlciBiZWxv dzoNCg0KIGNsaWVudDoNCg0KbGVub3ZvOn4vcmFkaXVzL2ZyLTMuMC4xMiQgcmFkdGVzdCAtSSBi b2JAeW91ci1vcmcuY29tIHBhc3Nib2IgMTI3LjAuMC4xIDEwMCB0ZXN0aW5nMTIzDQpTZW50IEFj Y2Vzcy1SZXF1ZXN0IElkIDI1NyBmcm9tIDAuMC4wLjA6NDk1OTYgdG8gMTI3LjAuMC4xOjE4MTIg bGVuZ3RoIDkyDQoJVXNlci1OYW1lID0gImJvYkB5b3VyLW9yZy5jb20iDQoJVXNlci1QYXNzd29y ZCA9ICJwYXNzYm9iIg0KCU5BUy1JUC1BZGRyZXNzID0gMTI3LjAuMC4xDQoJTkFTLVBvcnQgPSAx MDANCglNZXNzYWdlLUF1dGhlbnRpY2F0b3IgPSAweDAwDQoJQ2xlYXJ0ZXh0LVBhc3N3b3JkID0g InBhc3Nib2IiDQpTZW50IEFjY2Vzcy1SZXF1ZXN0IElkIDI1NyBmcm9tIDAuMC4wLjA6NDk1OTYg dG8gMTI3LjAuMC4xOjE4MTIgbGVuZ3RoIDkyDQoJVXNlci1OYW1lID0gImJvYkB5b3VyLW9yZy5j b20iDQoJVXNlci1QYXNzd29yZCA9ICJwYXNzYm9iIg0KCU5BUy1JUC1BZGRyZXNzID0gMTI3LjAu MC4xDQoJTkFTLVBvcnQgPSAxMDANCglNZXNzYWdlLUF1dGhlbnRpY2F0b3IgPSAweDAwDQoJQ2xl YXJ0ZXh0LVBhc3N3b3JkID0gInBhc3Nib2IiDQpSZWNlaXZlZCBBY2Nlc3MtQWNjZXB0IElkIDI1 NyBmcm9tIDEyNy4wLjAuMToxODEyIHRvIDAuMC4wLjA6MCBsZW5ndGggNDINCglFWFRFTkRFRC1J RCA9IDB4MDAwMDAyMDENCglUdW5uZWwtVHlwZTowID0gVkxBTg0KCVR1bm5lbC1NZWRpdW0tVHlw ZTowID0gSUVFRS04MDINCglUdW5uZWwtUHJpdmF0ZS1Hcm91cC1JZDowID0gIjU1Ig0KbGVub3Zv On4vcmFkaXVzL2ZyLTMuMC4xMiQgDQoNCiBwcm94eS1zZXJ2ZXI6DQoNClJlYWR5IHRvIHByb2Nl c3MgcmVxdWVzdHMNCg0KDQoNCigzKSBSZWNlaXZlZCBBY2Nlc3MtUmVxdWVzdCBJZCAyNTcgZnJv bSAxMjcuMC4wLjE6NDk1OTYgdG8gMTI3LjAuMC4xOjE4MTIgbGVuZ3RoIDkyDQooMykgICBFWFRF TkRFRC1JRCA9IDB4MDAwMDAyMDENCigzKSAgIFVzZXItTmFtZSA9ICJib2JAeW91ci1vcmcuY29t Ig0KKDMpICAgVXNlci1QYXNzd29yZCA9ICJwYXNzYm9iIg0KKDMpICAgTkFTLUlQLUFkZHJlc3Mg PSAxMjcuMC4wLjENCigzKSAgIE5BUy1Qb3J0ID0gMTAwDQooMykgICBNZXNzYWdlLUF1dGhlbnRp Y2F0b3IgPSAweDc3ODIwNjVkZDJiMTI2MDIzMWEyYWYwM2U5ZWQ5Yjc3DQooMykgIyBFeGVjdXRp bmcgc2VjdGlvbiBhdXRob3JpemUgZnJvbSBmaWxlIC91c3IvbG9jYWwvZXRjL3JhZGRiL3NpdGVz LWVuYWJsZWQvZGVmYXVsdA0KKDMpICAgYXV0aG9yaXplIHsNCigzKSAgICAgcG9saWN5IGZpbHRl cl91c2VybmFtZSB7DQooMykgICAgICAgaWYgKCZVc2VyLU5hbWUpIHsNCigzKSAgICAgICBpZiAo JlVzZXItTmFtZSkgIC0+IFRSVUUNCigzKSAgICAgICBpZiAoJlVzZXItTmFtZSkgIHsNCigzKSAg ICAgICAgIGlmICgmVXNlci1OYW1lID1+IC8gLykgew0KKDMpICAgICAgICAgaWYgKCZVc2VyLU5h bWUgPX4gLyAvKSAgLT4gRkFMU0UNCigzKSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9AW15A XSpALyApIHsNCigzKSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9AW15AXSpALyApICAtPiBG QUxTRQ0KKDMpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL1wuXC4vICkgew0KKDMpICAgICAg ICAgaWYgKCZVc2VyLU5hbWUgPX4gL1wuXC4vICkgIC0+IEZBTFNFDQooMykgICAgICAgICBpZiAo KCZVc2VyLU5hbWUgPX4gL0AvKSAmJiAoJlVzZXItTmFtZSAhfiAvQCguKylcLiguKykkLykpICB7 DQooMykgICAgICAgICBpZiAoKCZVc2VyLU5hbWUgPX4gL0AvKSAmJiAoJlVzZXItTmFtZSAhfiAv QCguKylcLiguKykkLykpICAgLT4gRkFMU0UNCigzKSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+ IC9cLiQvKSAgew0KKDMpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL1wuJC8pICAgLT4gRkFM U0UNCigzKSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9AXC4vKSAgew0KKDMpICAgICAgICAg aWYgKCZVc2VyLU5hbWUgPX4gL0BcLi8pICAgLT4gRkFMU0UNCigzKSAgICAgICB9ICMgaWYgKCZV c2VyLU5hbWUpICA9IG5vdGZvdW5kDQooMykgICAgIH0gIyBwb2xpY3kgZmlsdGVyX3VzZXJuYW1l ID0gbm90Zm91bmQNCigzKSAgICAgW3ByZXByb2Nlc3NdID0gb2sNCigzKSAgICAgW2NoYXBdID0g bm9vcA0KKDMpICAgICBbbXNjaGFwXSA9IG5vb3ANCigzKSAgICAgW2RpZ2VzdF0gPSBub29wDQoo Mykgc3VmZml4OiBDaGVja2luZyBmb3Igc3VmZml4IGFmdGVyICJAIg0KKDMpIHN1ZmZpeDogTG9v a2luZyB1cCByZWFsbSAieW91ci1vcmcuY29tIiBmb3IgVXNlci1OYW1lID0gImJvYkB5b3VyLW9y Zy5jb20iDQooMykgc3VmZml4OiBGb3VuZCByZWFsbSAieW91ci1vcmcuY29tIg0KKDMpIHN1ZmZp eDogQWRkaW5nIFJlYWxtID0gInlvdXItb3JnLmNvbSINCigzKSBzdWZmaXg6IFByb3h5aW5nIHJl cXVlc3QgZnJvbSB1c2VyIGJvYkB5b3VyLW9yZy5jb20gdG8gcmVhbG0geW91ci1vcmcuY29tDQoo Mykgc3VmZml4OiBQcmVwYXJpbmcgdG8gcHJveHkgYXV0aGVudGljYXRpb24gcmVxdWVzdCB0byBy ZWFsbSAieW91ci1vcmcuY29tIiANCigzKSAgICAgW3N1ZmZpeF0gPSB1cGRhdGVkDQooMykgICAg IGlmICggcmVxdWVzdDpSZWFsbSA9PSAiTlVMTCIgKXsNCigzKSAgICAgaWYgKCByZXF1ZXN0OlJl YWxtID09ICJOVUxMIiApIC0+IEZBTFNFDQooMykgZWFwOiBObyBFQVAtTWVzc2FnZSwgbm90IGRv aW5nIEVBUA0KKDMpICAgICBbZWFwXSA9IG5vb3ANCigzKSAgICAgW3VuaXhdID0gbm90Zm91bmQN CigzKSAgICAgW2ZpbGVzXSA9IG5vb3ANCigzKSAgICAgW2V4cGlyYXRpb25dID0gbm9vcA0KKDMp ICAgICBbbG9naW50aW1lXSA9IG5vb3ANCigzKSAgICAgW3BhcF0gPSBub29wDQooMykgICB9ICMg YXV0aG9yaXplID0gdXBkYXRlZA0KKDMpIFN0YXJ0aW5nIHByb3h5IHRvIGhvbWUgc2VydmVyIDE5 Mi4xNjguMS4xMDAgcG9ydCAxODEyDQooMykgUHJveHlpbmcgcmVxdWVzdCB0byBob21lIHNlcnZl ciAxOTIuMTY4LjEuMTAwIHBvcnQgMTgxMiB0aW1lb3V0IDMwLjAwMDAwMA0KKDMpIFNlbnQgU3Rh dHVzLVNlcnZlciBJZCAxNTkgZnJvbSAwLjAuMC4wOjQxMTYxIHRvIDE5Mi4xNjguMS4xMDA6MTgx MiBsZW5ndGggMTAzDQooMykgICBFWFRFTkRFRC1JRCA9IDB4MDAwMDAyMDENCigzKSAgIFVzZXIt TmFtZSA9ICJib2JAeW91ci1vcmcuY29tIg0KKDMpICAgVXNlci1QYXNzd29yZCA9ICJwYXNzYm9i Ig0KKDMpICAgTkFTLUlQLUFkZHJlc3MgPSAxMjcuMC4wLjENCigzKSAgIE5BUy1Qb3J0ID0gMTAw DQooMykgICBNZXNzYWdlLUF1dGhlbnRpY2F0b3IgPSAweDc3ODIwNjVkZDJiMTI2MDIzMWEyYWYw M2U5ZWQ5Yjc3DQooMykgICBFdmVudC1UaW1lc3RhbXAgPSAiQXByIDI2IDIwMTcgMTU6MTk6Mzkg UERUIg0KKDMpICAgUHJveHktU3RhdGUgPSAweDM1MzEzMw0KV2FraW5nIHVwIGluIDAuMyBzZWNv bmRzLg0KKDMpIEhvbWUgU2VydmVyIGhzXzFfeW91ci1vcmcuY29tIHN1cHBvcnRzIElEIEF0dHJp YnV0ZQ0KKDMpIE1hcmtpbmcgaG9tZSBzZXJ2ZXIgMTkyLjE2OC4xLjEwMCBwb3J0IDE4MTIgYWxp dmUNCigzKSBDbGVhcmluZyBleGlzdGluZyAmcmVwbHk6IGF0dHJpYnV0ZXMNCigzKSAjIEV4ZWN1 dGluZyBzZWN0aW9uIHBvc3QtcHJveHkgZnJvbSBmaWxlIC91c3IvbG9jYWwvZXRjL3JhZGRiL3Np dGVzLWVuYWJsZWQvZGVmYXVsdA0KKDMpICAgcG9zdC1wcm94eSB7DQooMykgZWFwOiBObyBwcmUt ZXhpc3RpbmcgaGFuZGxlciBmb3VuZA0KKDMpICAgICBbZWFwXSA9IG5vb3ANCigzKSAgIH0gIyBw b3N0LXByb3h5ID0gbm9vcA0KKDMpIEZvdW5kIEF1dGgtVHlwZSA9IEFjY2VwdA0KKDMpIEF1dGgt VHlwZSA9IEFjY2VwdCwgYWNjZXB0aW5nIHRoZSB1c2VyDQooMykgIyBFeGVjdXRpbmcgc2VjdGlv biBwb3N0LWF1dGggZnJvbSBmaWxlIC91c3IvbG9jYWwvZXRjL3JhZGRiL3NpdGVzLWVuYWJsZWQv ZGVmYXVsdA0KKDMpICAgcG9zdC1hdXRoIHsNCigzKSAgICAgdXBkYXRlIHsNCigzKSAgICAgICBO byBhdHRyaWJ1dGVzIHVwZGF0ZWQNCigzKSAgICAgfSAjIHVwZGF0ZSA9IG5vb3ANCigzKSAgICAg W2V4ZWNdID0gbm9vcA0KKDMpICAgICBwb2xpY3kgcmVtb3ZlX3JlcGx5X21lc3NhZ2VfaWZfZWFw IHsNCigzKSAgICAgICBpZiAoJnJlcGx5OkVBUC1NZXNzYWdlICYmICZyZXBseTpSZXBseS1NZXNz YWdlKSB7DQooMykgICAgICAgaWYgKCZyZXBseTpFQVAtTWVzc2FnZSAmJiAmcmVwbHk6UmVwbHkt TWVzc2FnZSkgIC0+IEZBTFNFDQooMykgICAgICAgZWxzZSB7DQooMykgICAgICAgICBbbm9vcF0g PSBub29wDQooMykgICAgICAgfSAjIGVsc2UgPSBub29wDQooMykgICAgIH0gIyBwb2xpY3kgcmVt b3ZlX3JlcGx5X21lc3NhZ2VfaWZfZWFwID0gbm9vcA0KKDMpICAgfSAjIHBvc3QtYXV0aCA9IG5v b3ANCldha2luZyB1cCBpbiA0Ljkgc2Vjb25kcy4NCigzKSBDbGVhbmluZyB1cCByZXF1ZXN0IHBh Y2tldCBJRCAyNTcgd2l0aCB0aW1lc3RhbXAgKzYxNg0KKDQpIFJlY2VpdmVkIEFjY2Vzcy1SZXF1 ZXN0IElkIDI1NyBmcm9tIDEyNy4wLjAuMTo0OTU5NiB0byAxMjcuMC4wLjE6MTgxMiBsZW5ndGgg OTINCig0KSAgIEVYVEVOREVELUlEID0gMHgwMDAwMDIwMQ0KKDQpICAgVXNlci1OYW1lID0gImJv YkB5b3VyLW9yZy5jb20iDQooNCkgICBVc2VyLVBhc3N3b3JkID0gInBhc3Nib2IiDQooNCkgICBO QVMtSVAtQWRkcmVzcyA9IDEyNy4wLjAuMQ0KKDQpICAgTkFTLVBvcnQgPSAxMDANCig0KSAgIE1l c3NhZ2UtQXV0aGVudGljYXRvciA9IDB4Nzc4MjA2NWRkMmIxMjYwMjMxYTJhZjAzZTllZDliNzcN Cig0KSAjIEV4ZWN1dGluZyBzZWN0aW9uIGF1dGhvcml6ZSBmcm9tIGZpbGUgL3Vzci9sb2NhbC9l dGMvcmFkZGIvc2l0ZXMtZW5hYmxlZC9kZWZhdWx0DQooNCkgICBhdXRob3JpemUgew0KKDQpICAg ICBwb2xpY3kgZmlsdGVyX3VzZXJuYW1lIHsNCig0KSAgICAgICBpZiAoJlVzZXItTmFtZSkgew0K KDQpICAgICAgIGlmICgmVXNlci1OYW1lKSAgLT4gVFJVRQ0KKDQpICAgICAgIGlmICgmVXNlci1O YW1lKSAgew0KKDQpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gLyAvKSB7DQooNCkgICAgICAg ICBpZiAoJlVzZXItTmFtZSA9fiAvIC8pICAtPiBGQUxTRQ0KKDQpICAgICAgICAgaWYgKCZVc2Vy LU5hbWUgPX4gL0BbXkBdKkAvICkgew0KKDQpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL0Bb XkBdKkAvICkgIC0+IEZBTFNFDQooNCkgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvXC5cLi8g KSB7DQooNCkgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvXC5cLi8gKSAgLT4gRkFMU0UNCig0 KSAgICAgICAgIGlmICgoJlVzZXItTmFtZSA9fiAvQC8pICYmICgmVXNlci1OYW1lICF+IC9AKC4r KVwuKC4rKSQvKSkgIHsNCig0KSAgICAgICAgIGlmICgoJlVzZXItTmFtZSA9fiAvQC8pICYmICgm VXNlci1OYW1lICF+IC9AKC4rKVwuKC4rKSQvKSkgICAtPiBGQUxTRQ0KKDQpICAgICAgICAgaWYg KCZVc2VyLU5hbWUgPX4gL1wuJC8pICB7DQooNCkgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAv XC4kLykgICAtPiBGQUxTRQ0KKDQpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL0BcLi8pICB7 DQooNCkgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvQFwuLykgICAtPiBGQUxTRQ0KKDQpICAg ICAgIH0gIyBpZiAoJlVzZXItTmFtZSkgID0gbm90Zm91bmQNCig0KSAgICAgfSAjIHBvbGljeSBm aWx0ZXJfdXNlcm5hbWUgPSBub3Rmb3VuZA0KKDQpICAgICBbcHJlcHJvY2Vzc10gPSBvaw0KKDQp ICAgICBbY2hhcF0gPSBub29wDQooNCkgICAgIFttc2NoYXBdID0gbm9vcA0KKDQpICAgICBbZGln ZXN0XSA9IG5vb3ANCig0KSBzdWZmaXg6IENoZWNraW5nIGZvciBzdWZmaXggYWZ0ZXIgIkAiDQoo NCkgc3VmZml4OiBMb29raW5nIHVwIHJlYWxtICJ5b3VyLW9yZy5jb20iIGZvciBVc2VyLU5hbWUg PSAiYm9iQHlvdXItb3JnLmNvbSINCig0KSBzdWZmaXg6IEZvdW5kIHJlYWxtICJ5b3VyLW9yZy5j b20iDQooNCkgc3VmZml4OiBBZGRpbmcgUmVhbG0gPSAieW91ci1vcmcuY29tIg0KKDQpIHN1ZmZp eDogUHJveHlpbmcgcmVxdWVzdCBmcm9tIHVzZXIgYm9iQHlvdXItb3JnLmNvbSB0byByZWFsbSB5 b3VyLW9yZy5jb20NCig0KSBzdWZmaXg6IFByZXBhcmluZyB0byBwcm94eSBhdXRoZW50aWNhdGlv biByZXF1ZXN0IHRvIHJlYWxtICJ5b3VyLW9yZy5jb20iIA0KKDQpICAgICBbc3VmZml4XSA9IHVw ZGF0ZWQNCig0KSAgICAgaWYgKCByZXF1ZXN0OlJlYWxtID09ICJOVUxMIiApew0KKDQpICAgICBp ZiAoIHJlcXVlc3Q6UmVhbG0gPT0gIk5VTEwiICkgLT4gRkFMU0UNCig0KSBlYXA6IE5vIEVBUC1N ZXNzYWdlLCBub3QgZG9pbmcgRUFQDQooNCkgICAgIFtlYXBdID0gbm9vcA0KKDQpICAgICBbdW5p eF0gPSBub3Rmb3VuZA0KKDQpICAgICBbZmlsZXNdID0gbm9vcA0KKDQpICAgICBbZXhwaXJhdGlv bl0gPSBub29wDQooNCkgICAgIFtsb2dpbnRpbWVdID0gbm9vcA0KKDQpICAgICBbcGFwXSA9IG5v b3ANCig0KSAgIH0gIyBhdXRob3JpemUgPSB1cGRhdGVkDQooNCkgU3RhcnRpbmcgcHJveHkgdG8g aG9tZSBzZXJ2ZXIgMTkyLjE2OC4xLjEwMCBwb3J0IDE4MTINCig0KSBQcm94eWluZyByZXF1ZXN0 IHRvIGhvbWUgc2VydmVyIDE5Mi4xNjguMS4xMDAgcG9ydCAxODEyIHRpbWVvdXQgMzAuMDAwMDAw DQooNCkgU2VudCBBY2Nlc3MtUmVxdWVzdCBJZCAyNTcgZnJvbSAwLjAuMC4wOjQxMTYxIHRvIDE5 Mi4xNjguMS4xMDA6MTgxMiBsZW5ndGggMTAzDQooNCkgICBFWFRFTkRFRC1JRCA9IDB4MDAwMDAy MDENCig0KSAgIFVzZXItTmFtZSA9ICJib2JAeW91ci1vcmcuY29tIg0KKDQpICAgVXNlci1QYXNz d29yZCA9ICJwYXNzYm9iIg0KKDQpICAgTkFTLUlQLUFkZHJlc3MgPSAxMjcuMC4wLjENCig0KSAg IE5BUy1Qb3J0ID0gMTAwDQooNCkgICBNZXNzYWdlLUF1dGhlbnRpY2F0b3IgPSAweDc3ODIwNjVk ZDJiMTI2MDIzMWEyYWYwM2U5ZWQ5Yjc3DQooNCkgICBFdmVudC1UaW1lc3RhbXAgPSAiQXByIDI2 IDIwMTcgMTU6MTk6NDQgUERUIg0KKDQpICAgUHJveHktU3RhdGUgPSAweDM1MzEzMw0KV2FraW5n IHVwIGluIDAuMyBzZWNvbmRzLg0KKDQpIENsZWFyaW5nIGV4aXN0aW5nICZyZXBseTogYXR0cmli dXRlcw0KKDQpIFJlY2VpdmVkIEFjY2Vzcy1BY2NlcHQgSWQgMjU3IGZyb20gMTkyLjE2OC4xLjEw MDoxODEyIHRvIDE5Mi4xNjguMS4zNTo0MTE2MSBsZW5ndGggNDcNCig0KSAgIEVYVEVOREVELUlE ID0gMHgwMDAwMDIwMQ0KKDQpICAgVHVubmVsLVR5cGU6MCA9IFZMQU4NCig0KSAgIFR1bm5lbC1N ZWRpdW0tVHlwZTowID0gSUVFRS04MDINCig0KSAgIFR1bm5lbC1Qcml2YXRlLUdyb3VwLUlkOjAg PSAiNTUiDQooNCkgICBQcm94eS1TdGF0ZSA9IDB4MzUzMTMzDQooNCkgIyBFeGVjdXRpbmcgc2Vj dGlvbiBwb3N0LXByb3h5IGZyb20gZmlsZSAvdXNyL2xvY2FsL2V0Yy9yYWRkYi9zaXRlcy1lbmFi bGVkL2RlZmF1bHQNCig0KSAgIHBvc3QtcHJveHkgew0KKDQpIGVhcDogTm8gcHJlLWV4aXN0aW5n IGhhbmRsZXIgZm91bmQNCig0KSAgICAgW2VhcF0gPSBub29wDQooNCkgICB9ICMgcG9zdC1wcm94 eSA9IG5vb3ANCig0KSBGb3VuZCBBdXRoLVR5cGUgPSBBY2NlcHQNCig0KSBBdXRoLVR5cGUgPSBB Y2NlcHQsIGFjY2VwdGluZyB0aGUgdXNlcg0KKDQpICMgRXhlY3V0aW5nIHNlY3Rpb24gcG9zdC1h dXRoIGZyb20gZmlsZSAvdXNyL2xvY2FsL2V0Yy9yYWRkYi9zaXRlcy1lbmFibGVkL2RlZmF1bHQN Cig0KSAgIHBvc3QtYXV0aCB7DQooNCkgICAgIHVwZGF0ZSB7DQooNCkgICAgICAgTm8gYXR0cmli dXRlcyB1cGRhdGVkDQooNCkgICAgIH0gIyB1cGRhdGUgPSBub29wDQooNCkgICAgIFtleGVjXSA9 IG5vb3ANCig0KSAgICAgcG9saWN5IHJlbW92ZV9yZXBseV9tZXNzYWdlX2lmX2VhcCB7DQooNCkg ICAgICAgaWYgKCZyZXBseTpFQVAtTWVzc2FnZSAmJiAmcmVwbHk6UmVwbHktTWVzc2FnZSkgew0K KDQpICAgICAgIGlmICgmcmVwbHk6RUFQLU1lc3NhZ2UgJiYgJnJlcGx5OlJlcGx5LU1lc3NhZ2Up ICAtPiBGQUxTRQ0KKDQpICAgICAgIGVsc2Ugew0KKDQpICAgICAgICAgW25vb3BdID0gbm9vcA0K KDQpICAgICAgIH0gIyBlbHNlID0gbm9vcA0KKDQpICAgICB9ICMgcG9saWN5IHJlbW92ZV9yZXBs eV9tZXNzYWdlX2lmX2VhcCA9IG5vb3ANCig0KSAgIH0gIyBwb3N0LWF1dGggPSBub29wDQooNCkg U2VudCBBY2Nlc3MtQWNjZXB0IElkIDI1NyBmcm9tIDEyNy4wLjAuMToxODEyIHRvIDEyNy4wLjAu MTo0OTU5NiBsZW5ndGggMA0KKDQpICAgRVhURU5ERUQtSUQgPSAweDAwMDAwMjAxDQooNCkgICBU dW5uZWwtVHlwZTowID0gVkxBTg0KKDQpICAgVHVubmVsLU1lZGl1bS1UeXBlOjAgPSBJRUVFLTgw Mg0KKDQpICAgVHVubmVsLVByaXZhdGUtR3JvdXAtSWQ6MCA9ICI1NSINCig0KSBGaW5pc2hlZCBy ZXF1ZXN0DQpXYWtpbmcgdXAgaW4gNC45IHNlY29uZHMuDQooNCkgQ2xlYW5pbmcgdXAgcmVxdWVz dCBwYWNrZXQgSUQgMjU3IHdpdGggdGltZXN0YW1wICs2MjENClJlYWR5IHRvIHByb2Nlc3MgcmVx dWVzdHMNCg0KDQogaG9tZS1zZXJ2ZXI6DQoNClJlYWR5IHRvIHByb2Nlc3MgcmVxdWVzdHMNCg0K DQooMCkgUmVjZWl2ZWQgU3RhdHVzLVNlcnZlciBJZCAyMjMgZnJvbSAxOTIuMTY4LjEuMzU6NDc3 OTIgdG8gMTkyLjE2OC4xLjEwMDoxODEyIGxlbmd0aCAxMDMNCigwKSAgIEVYVEVOREVELUlEID0g MHg0MDAwMDAwMA0KKDApICAgVXNlci1OYW1lID0gImJvYkB5b3VyLW9yZy5jb20iDQooMCkgICBV c2VyLVBhc3N3b3JkID0gInBhc3Nib2IiDQooMCkgICBOQVMtSVAtQWRkcmVzcyA9IDEyNy4wLjAu MQ0KKDApICAgTkFTLVBvcnQgPSAxMDANCigwKSAgIE1lc3NhZ2UtQXV0aGVudGljYXRvciA9IDB4 YmM1NDFkZTlhZGE0YTRhYmY3YmMyMTc3Y2I5YTYzY2QNCigwKSAgIEV2ZW50LVRpbWVzdGFtcCA9 ICJBcHIgMjYgMjAxNyAxNToyMjowNyBQRFQiDQooMCkgICBQcm94eS1TdGF0ZSA9IDB4MzUzMTMz DQooMCkgU2VudCBBY2Nlc3MtQWNjZXB0IElkIDIyMyBmcm9tIDE5Mi4xNjguMS4xMDA6MTgxMiB0 byAxOTIuMTY4LjEuMzU6NDc3OTIgbGVuZ3RoIDANCigwKSAgIFByb3h5LVN0YXRlID0gMHgzNTMx MzMNCigwKSBGaW5pc2hlZCByZXF1ZXN0DQpXYWtpbmcgdXAgaW4gNC45IHNlY29uZHMuDQooMCkg Q2xlYW5pbmcgdXAgcmVxdWVzdCBwYWNrZXQgSUQgMjIzIHdpdGggdGltZXN0YW1wICsxMA0KKDEp IFJlY2VpdmVkIEFjY2Vzcy1SZXF1ZXN0IElkIDI1NyBmcm9tIDE5Mi4xNjguMS4zNTo0Nzc5MiB0 byAxOTIuMTY4LjEuMTAwOjE4MTIgbGVuZ3RoIDEwMw0KKDEpICAgRVhURU5ERUQtSUQgPSAweDAw MDAwMjAxDQooMSkgICBVc2VyLU5hbWUgPSAiYm9iQHlvdXItb3JnLmNvbSINCigxKSAgIFVzZXIt UGFzc3dvcmQgPSAicGFzc2JvYiINCigxKSAgIE5BUy1JUC1BZGRyZXNzID0gMTI3LjAuMC4xDQoo MSkgICBOQVMtUG9ydCA9IDEwMA0KKDEpICAgTWVzc2FnZS1BdXRoZW50aWNhdG9yID0gMHg4YjJm MWU0MzNmNmUyMTc0MzU2MTRjZmYyM2VmNzcyYw0KKDEpICAgRXZlbnQtVGltZXN0YW1wID0gIkFw ciAyNiAyMDE3IDE1OjIyOjEyIFBEVCINCigxKSAgIFByb3h5LVN0YXRlID0gMHgzNTMxMzMNCigx KSAjIEV4ZWN1dGluZyBzZWN0aW9uIGF1dGhvcml6ZSBmcm9tIGZpbGUgL3Vzci9sb2NhbC9ldGMv cmFkZGIvc2l0ZXMtZW5hYmxlZC9kZWZhdWx0DQooMSkgICBhdXRob3JpemUgew0KKDEpICAgICBw b2xpY3kgZmlsdGVyX3VzZXJuYW1lIHsNCigxKSAgICAgICBpZiAoJlVzZXItTmFtZSkgew0KKDEp ICAgICAgIGlmICgmVXNlci1OYW1lKSAgLT4gVFJVRQ0KKDEpICAgICAgIGlmICgmVXNlci1OYW1l KSAgew0KKDEpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gLyAvKSB7DQooMSkgICAgICAgICBp ZiAoJlVzZXItTmFtZSA9fiAvIC8pICAtPiBGQUxTRQ0KKDEpICAgICAgICAgaWYgKCZVc2VyLU5h bWUgPX4gL0BbXkBdKkAvICkgew0KKDEpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL0BbXkBd KkAvICkgIC0+IEZBTFNFDQooMSkgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvXC5cLi8gKSB7 DQooMSkgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvXC5cLi8gKSAgLT4gRkFMU0UNCigxKSAg ICAgICAgIGlmICgoJlVzZXItTmFtZSA9fiAvQC8pICYmICgmVXNlci1OYW1lICF+IC9AKC4rKVwu KC4rKSQvKSkgIHsNCigxKSAgICAgICAgIGlmICgoJlVzZXItTmFtZSA9fiAvQC8pICYmICgmVXNl ci1OYW1lICF+IC9AKC4rKVwuKC4rKSQvKSkgICAtPiBGQUxTRQ0KKDEpICAgICAgICAgaWYgKCZV c2VyLU5hbWUgPX4gL1wuJC8pICB7DQooMSkgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvXC4k LykgICAtPiBGQUxTRQ0KKDEpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL0BcLi8pICB7DQoo MSkgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvQFwuLykgICAtPiBGQUxTRQ0KKDEpICAgICAg IH0gIyBpZiAoJlVzZXItTmFtZSkgID0gbm90Zm91bmQNCigxKSAgICAgfSAjIHBvbGljeSBmaWx0 ZXJfdXNlcm5hbWUgPSBub3Rmb3VuZA0KKDEpICAgICBbcHJlcHJvY2Vzc10gPSBvaw0KKDEpICAg ICBbY2hhcF0gPSBub29wDQooMSkgICAgIFttc2NoYXBdID0gbm9vcA0KKDEpICAgICBbZGlnZXN0 XSA9IG5vb3ANCigxKSBzdWZmaXg6IENoZWNraW5nIGZvciBzdWZmaXggYWZ0ZXIgIkAiDQooMSkg c3VmZml4OiBMb29raW5nIHVwIHJlYWxtICJ5b3VyLW9yZy5jb20iIGZvciBVc2VyLU5hbWUgPSAi Ym9iQHlvdXItb3JnLmNvbSINCigxKSBzdWZmaXg6IEZvdW5kIHJlYWxtICJ5b3VyLW9yZy5jb20i DQooMSkgc3VmZml4OiBBZGRpbmcgU3RyaXBwZWQtVXNlci1OYW1lID0gImJvYiINCigxKSBzdWZm aXg6IEFkZGluZyBSZWFsbSA9ICJ5b3VyLW9yZy5jb20iDQooMSkgc3VmZml4OiBBdXRoZW50aWNh dGlvbiByZWFsbSBpcyBMT0NBTA0KKDEpICAgICBbc3VmZml4XSA9IG9rDQooMSkgZWFwOiBObyBF QVAtTWVzc2FnZSwgbm90IGRvaW5nIEVBUA0KKDEpICAgICBbZWFwXSA9IG5vb3ANCigxKSBmaWxl czogdXNlcnM6IE1hdGNoZWQgZW50cnkgYm9iIGF0IGxpbmUgMQ0KKDEpICAgICBbZmlsZXNdID0g b2sNCigxKSAgICAgW2V4cGlyYXRpb25dID0gbm9vcA0KKDEpICAgICBbbG9naW50aW1lXSA9IG5v b3ANCigxKSAgICAgW3BhcF0gPSB1cGRhdGVkDQooMSkgICB9ICMgYXV0aG9yaXplID0gdXBkYXRl ZA0KKDEpIEZvdW5kIEF1dGgtVHlwZSA9IFBBUA0KKDEpICMgRXhlY3V0aW5nIGdyb3VwIGZyb20g ZmlsZSAvdXNyL2xvY2FsL2V0Yy9yYWRkYi9zaXRlcy1lbmFibGVkL2RlZmF1bHQNCigxKSAgIEF1 dGgtVHlwZSBQQVAgew0KKDEpIHBhcDogTG9naW4gYXR0ZW1wdCB3aXRoIHBhc3N3b3JkDQooMSkg cGFwOiBDb21wYXJpbmcgd2l0aCAia25vd24gZ29vZCIgQ2xlYXJ0ZXh0LVBhc3N3b3JkDQooMSkg cGFwOiBVc2VyIGF1dGhlbnRpY2F0ZWQgc3VjY2Vzc2Z1bGx5DQooMSkgICAgIFtwYXBdID0gb2sN CigxKSAgIH0gIyBBdXRoLVR5cGUgUEFQID0gb2sNCigxKSAjIEV4ZWN1dGluZyBzZWN0aW9uIHBv c3QtYXV0aCBmcm9tIGZpbGUgL3Vzci9sb2NhbC9ldGMvcmFkZGIvc2l0ZXMtZW5hYmxlZC9kZWZh dWx0DQooMSkgICBwb3N0LWF1dGggew0KKDEpICAgICB1cGRhdGUgew0KKDEpICAgICAgIE5vIGF0 dHJpYnV0ZXMgdXBkYXRlZA0KKDEpICAgICB9ICMgdXBkYXRlID0gbm9vcA0KKDEpICAgICBbZXhl Y10gPSBub29wDQooMSkgICAgIHBvbGljeSByZW1vdmVfcmVwbHlfbWVzc2FnZV9pZl9lYXAgew0K KDEpICAgICAgIGlmICgmcmVwbHk6RUFQLU1lc3NhZ2UgJiYgJnJlcGx5OlJlcGx5LU1lc3NhZ2Up IHsNCigxKSAgICAgICBpZiAoJnJlcGx5OkVBUC1NZXNzYWdlICYmICZyZXBseTpSZXBseS1NZXNz YWdlKSAgLT4gRkFMU0UNCigxKSAgICAgICBlbHNlIHsNCigxKSAgICAgICAgIFtub29wXSA9IG5v b3ANCigxKSAgICAgICB9ICMgZWxzZSA9IG5vb3ANCigxKSAgICAgfSAjIHBvbGljeSByZW1vdmVf cmVwbHlfbWVzc2FnZV9pZl9lYXAgPSBub29wDQooMSkgICB9ICMgcG9zdC1hdXRoID0gbm9vcA0K KDEpIFNlbnQgQWNjZXNzLUFjY2VwdCBJZCAyNTcgZnJvbSAxOTIuMTY4LjEuMTAwOjE4MTIgdG8g MTkyLjE2OC4xLjM1OjQ3NzkyIGxlbmd0aCAwDQooMSkgICBUdW5uZWwtVHlwZSA9IFZMQU4NCigx KSAgIFR1bm5lbC1NZWRpdW0tVHlwZSA9IElFRUUtODAyDQooMSkgICBUdW5uZWwtUHJpdmF0ZS1H cm91cC1JZCA9ICI1NSINCigxKSAgIFByb3h5LVN0YXRlID0gMHgzNTMxMzMNCigxKSBGaW5pc2hl ZCByZXF1ZXN0DQpXYWtpbmcgdXAgaW4gNC45IHNlY29uZHMuDQooMSkgQ2xlYW5pbmcgdXAgcmVx dWVzdCBwYWNrZXQgSUQgMjU3IHdpdGggdGltZXN0YW1wICsxNQ0KUmVhZHkgdG8gcHJvY2VzcyBy ZXF1ZXN0cw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICg1KSBBdXRoIGFub3RoZXIgdXNlciB3aXRoIHRo ZSBzYW1lIGhvbWUtc2VydmVyICh1c2luZyBleHQtSUQpDQogICAgICdyYWR0ZXN0IC1JIGNhdGh5 QHlvdXItb3JnLmNvbSBwYXNzY2F0aHkgMTI3LjAuMC4xIDEwMCB0ZXN0aW5nMTIzJw0KICAgICBO b3RlOiB0aGVyZSBpcyBubyBxdWVyeSBmcm9tIHByb3h5IHRvIGhvbWUtc2VydmVyIHNpbmNlIHRo ZSBwcm94eQ0KICAgICAgICAgICByZW1lbWJlcnMgdGhlIGhvbWUtc2VydmVyIHN1cHBvcnQgb2Yg ZXh0LUlEDQogICAgIE91dHB1dCBvZiBjbGllbnQgYW5kIHNlcnZlciBiZWxvdzoNCg0KIGNsaWVu dDoNCg0KbGVub3ZvOn4vcmFkaXVzL2ZyLTMuMC4xMiQgcmFkdGVzdCAtSSBjYXRoeUB5b3VyLW9y Zy5jb20gcGFzc2NhdGh5IDEyNy4wLjAuMSAxMDAgdGVzdGluZzEyMw0KU2VudCBBY2Nlc3MtUmVx dWVzdCBJZCAyNTcgZnJvbSAwLjAuMC4wOjQ3MjE2IHRvIDEyNy4wLjAuMToxODEyIGxlbmd0aCA5 NA0KCVVzZXItTmFtZSA9ICJjYXRoeUB5b3VyLW9yZy5jb20iDQoJVXNlci1QYXNzd29yZCA9ICJw YXNzY2F0aHkiDQoJTkFTLUlQLUFkZHJlc3MgPSAxMjcuMC4wLjENCglOQVMtUG9ydCA9IDEwMA0K CU1lc3NhZ2UtQXV0aGVudGljYXRvciA9IDB4MDANCglDbGVhcnRleHQtUGFzc3dvcmQgPSAicGFz c2NhdGh5Ig0KUmVjZWl2ZWQgQWNjZXNzLUFjY2VwdCBJZCAyNTcgZnJvbSAxMjcuMC4wLjE6MTgx MiB0byAwLjAuMC4wOjAgbGVuZ3RoIDQyDQoJRVhURU5ERUQtSUQgPSAweDAwMDAwMjAxDQoJVHVu bmVsLVR5cGU6MCA9IFZMQU4NCglUdW5uZWwtTWVkaXVtLVR5cGU6MCA9IElFRUUtODAyDQoJVHVu bmVsLVByaXZhdGUtR3JvdXAtSWQ6MCA9ICI1NSINCmxlbm92bzp+L3JhZGl1cy9mci0zLjAuMTIk IA0KDQogcHJveHktc2VydmVyOg0KDQpSZWFkeSB0byBwcm9jZXNzIHJlcXVlc3RzDQoNCg0KKDIp IFJlY2VpdmVkIEFjY2Vzcy1SZXF1ZXN0IElkIDI1NyBmcm9tIDEyNy4wLjAuMTo0NzIxNiB0byAx MjcuMC4wLjE6MTgxMiBsZW5ndGggOTQNCigyKSAgIEVYVEVOREVELUlEID0gMHgwMDAwMDIwMQ0K KDIpICAgVXNlci1OYW1lID0gImNhdGh5QHlvdXItb3JnLmNvbSINCigyKSAgIFVzZXItUGFzc3dv cmQgPSAicGFzc2NhdGh5Ig0KKDIpICAgTkFTLUlQLUFkZHJlc3MgPSAxMjcuMC4wLjENCigyKSAg IE5BUy1Qb3J0ID0gMTAwDQooMikgICBNZXNzYWdlLUF1dGhlbnRpY2F0b3IgPSAweDA3ZDM4MDFm ZDVhYjQwMWJkNGYyMjAyZDY5ZDJjYzFlDQooMikgIyBFeGVjdXRpbmcgc2VjdGlvbiBhdXRob3Jp emUgZnJvbSBmaWxlIC91c3IvbG9jYWwvZXRjL3JhZGRiL3NpdGVzLWVuYWJsZWQvZGVmYXVsdA0K KDIpICAgYXV0aG9yaXplIHsNCigyKSAgICAgcG9saWN5IGZpbHRlcl91c2VybmFtZSB7DQooMikg ICAgICAgaWYgKCZVc2VyLU5hbWUpIHsNCigyKSAgICAgICBpZiAoJlVzZXItTmFtZSkgIC0+IFRS VUUNCigyKSAgICAgICBpZiAoJlVzZXItTmFtZSkgIHsNCigyKSAgICAgICAgIGlmICgmVXNlci1O YW1lID1+IC8gLykgew0KKDIpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gLyAvKSAgLT4gRkFM U0UNCigyKSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9AW15AXSpALyApIHsNCigyKSAgICAg ICAgIGlmICgmVXNlci1OYW1lID1+IC9AW15AXSpALyApICAtPiBGQUxTRQ0KKDIpICAgICAgICAg aWYgKCZVc2VyLU5hbWUgPX4gL1wuXC4vICkgew0KKDIpICAgICAgICAgaWYgKCZVc2VyLU5hbWUg PX4gL1wuXC4vICkgIC0+IEZBTFNFDQooMikgICAgICAgICBpZiAoKCZVc2VyLU5hbWUgPX4gL0Av KSAmJiAoJlVzZXItTmFtZSAhfiAvQCguKylcLiguKykkLykpICB7DQooMikgICAgICAgICBpZiAo KCZVc2VyLU5hbWUgPX4gL0AvKSAmJiAoJlVzZXItTmFtZSAhfiAvQCguKylcLiguKykkLykpICAg LT4gRkFMU0UNCigyKSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9cLiQvKSAgew0KKDIpICAg ICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL1wuJC8pICAgLT4gRkFMU0UNCigyKSAgICAgICAgIGlm ICgmVXNlci1OYW1lID1+IC9AXC4vKSAgew0KKDIpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4g L0BcLi8pICAgLT4gRkFMU0UNCigyKSAgICAgICB9ICMgaWYgKCZVc2VyLU5hbWUpICA9IG5vdGZv dW5kDQooMikgICAgIH0gIyBwb2xpY3kgZmlsdGVyX3VzZXJuYW1lID0gbm90Zm91bmQNCigyKSAg ICAgW3ByZXByb2Nlc3NdID0gb2sNCigyKSAgICAgW2NoYXBdID0gbm9vcA0KKDIpICAgICBbbXNj aGFwXSA9IG5vb3ANCigyKSAgICAgW2RpZ2VzdF0gPSBub29wDQooMikgc3VmZml4OiBDaGVja2lu ZyBmb3Igc3VmZml4IGFmdGVyICJAIg0KKDIpIHN1ZmZpeDogTG9va2luZyB1cCByZWFsbSAieW91 ci1vcmcuY29tIiBmb3IgVXNlci1OYW1lID0gImNhdGh5QHlvdXItb3JnLmNvbSINCigyKSBzdWZm aXg6IEZvdW5kIHJlYWxtICJ5b3VyLW9yZy5jb20iDQooMikgc3VmZml4OiBBZGRpbmcgUmVhbG0g PSAieW91ci1vcmcuY29tIg0KKDIpIHN1ZmZpeDogUHJveHlpbmcgcmVxdWVzdCBmcm9tIHVzZXIg Y2F0aHlAeW91ci1vcmcuY29tIHRvIHJlYWxtIHlvdXItb3JnLmNvbQ0KKDIpIHN1ZmZpeDogUHJl cGFyaW5nIHRvIHByb3h5IGF1dGhlbnRpY2F0aW9uIHJlcXVlc3QgdG8gcmVhbG0gInlvdXItb3Jn LmNvbSIgDQooMikgICAgIFtzdWZmaXhdID0gdXBkYXRlZA0KKDIpICAgICBpZiAoIHJlcXVlc3Q6 UmVhbG0gPT0gIk5VTEwiICl7DQooMikgICAgIGlmICggcmVxdWVzdDpSZWFsbSA9PSAiTlVMTCIg KSAtPiBGQUxTRQ0KKDIpIGVhcDogTm8gRUFQLU1lc3NhZ2UsIG5vdCBkb2luZyBFQVANCigyKSAg ICAgW2VhcF0gPSBub29wDQooMikgICAgIFt1bml4XSA9IG5vdGZvdW5kDQooMikgICAgIFtmaWxl c10gPSBub29wDQooMikgICAgIFtleHBpcmF0aW9uXSA9IG5vb3ANCigyKSAgICAgW2xvZ2ludGlt ZV0gPSBub29wDQooMikgICAgIFtwYXBdID0gbm9vcA0KKDIpICAgfSAjIGF1dGhvcml6ZSA9IHVw ZGF0ZWQNCigyKSBTdGFydGluZyBwcm94eSB0byBob21lIHNlcnZlciAxOTIuMTY4LjEuMTAwIHBv cnQgMTgxMg0KKDIpIFByb3h5aW5nIHJlcXVlc3QgdG8gaG9tZSBzZXJ2ZXIgMTkyLjE2OC4xLjEw MCBwb3J0IDE4MTIgdGltZW91dCAzMC4wMDAwMDANCigyKSBTZW50IEFjY2Vzcy1SZXF1ZXN0IElk IDI1OCBmcm9tIDAuMC4wLjA6NDc3OTIgdG8gMTkyLjE2OC4xLjEwMDoxODEyIGxlbmd0aCAxMDUN CigyKSAgIEVYVEVOREVELUlEID0gMHgwMDAwMDIwMQ0KKDIpICAgVXNlci1OYW1lID0gImNhdGh5 QHlvdXItb3JnLmNvbSINCigyKSAgIFVzZXItUGFzc3dvcmQgPSAicGFzc2NhdGh5Ig0KKDIpICAg TkFTLUlQLUFkZHJlc3MgPSAxMjcuMC4wLjENCigyKSAgIE5BUy1Qb3J0ID0gMTAwDQooMikgICBN ZXNzYWdlLUF1dGhlbnRpY2F0b3IgPSAweDA3ZDM4MDFmZDVhYjQwMWJkNGYyMjAyZDY5ZDJjYzFl DQooMikgICBFdmVudC1UaW1lc3RhbXAgPSAiQXByIDI2IDIwMTcgMTU6MjQ6MjQgUERUIg0KKDIp ICAgUHJveHktU3RhdGUgPSAweDM1MzEzMw0KV2FraW5nIHVwIGluIDAuMyBzZWNvbmRzLg0KKDIp IENsZWFyaW5nIGV4aXN0aW5nICZyZXBseTogYXR0cmlidXRlcw0KKDIpIFJlY2VpdmVkIEFjY2Vz cy1BY2NlcHQgSWQgMjU4IGZyb20gMTkyLjE2OC4xLjEwMDoxODEyIHRvIDE5Mi4xNjguMS4zNTo0 Nzc5MiBsZW5ndGggNDcNCigyKSAgIEVYVEVOREVELUlEID0gMHgwMDAwMDIwMg0KKDIpICAgVHVu bmVsLVR5cGU6MCA9IFZMQU4NCigyKSAgIFR1bm5lbC1NZWRpdW0tVHlwZTowID0gSUVFRS04MDIN CigyKSAgIFR1bm5lbC1Qcml2YXRlLUdyb3VwLUlkOjAgPSAiNTUiDQooMikgICBQcm94eS1TdGF0 ZSA9IDB4MzUzMTMzDQooMikgIyBFeGVjdXRpbmcgc2VjdGlvbiBwb3N0LXByb3h5IGZyb20gZmls ZSAvdXNyL2xvY2FsL2V0Yy9yYWRkYi9zaXRlcy1lbmFibGVkL2RlZmF1bHQNCigyKSAgIHBvc3Qt cHJveHkgew0KKDIpIGVhcDogTm8gcHJlLWV4aXN0aW5nIGhhbmRsZXIgZm91bmQNCigyKSAgICAg W2VhcF0gPSBub29wDQooMikgICB9ICMgcG9zdC1wcm94eSA9IG5vb3ANCigyKSBGb3VuZCBBdXRo LVR5cGUgPSBBY2NlcHQNCigyKSBBdXRoLVR5cGUgPSBBY2NlcHQsIGFjY2VwdGluZyB0aGUgdXNl cg0KKDIpICMgRXhlY3V0aW5nIHNlY3Rpb24gcG9zdC1hdXRoIGZyb20gZmlsZSAvdXNyL2xvY2Fs L2V0Yy9yYWRkYi9zaXRlcy1lbmFibGVkL2RlZmF1bHQNCigyKSAgIHBvc3QtYXV0aCB7DQooMikg ICAgIHVwZGF0ZSB7DQooMikgICAgICAgTm8gYXR0cmlidXRlcyB1cGRhdGVkDQooMikgICAgIH0g IyB1cGRhdGUgPSBub29wDQooMikgICAgIFtleGVjXSA9IG5vb3ANCigyKSAgICAgcG9saWN5IHJl bW92ZV9yZXBseV9tZXNzYWdlX2lmX2VhcCB7DQooMikgICAgICAgaWYgKCZyZXBseTpFQVAtTWVz c2FnZSAmJiAmcmVwbHk6UmVwbHktTWVzc2FnZSkgew0KKDIpICAgICAgIGlmICgmcmVwbHk6RUFQ LU1lc3NhZ2UgJiYgJnJlcGx5OlJlcGx5LU1lc3NhZ2UpICAtPiBGQUxTRQ0KKDIpICAgICAgIGVs c2Ugew0KKDIpICAgICAgICAgW25vb3BdID0gbm9vcA0KKDIpICAgICAgIH0gIyBlbHNlID0gbm9v cA0KKDIpICAgICB9ICMgcG9saWN5IHJlbW92ZV9yZXBseV9tZXNzYWdlX2lmX2VhcCA9IG5vb3AN CigyKSAgIH0gIyBwb3N0LWF1dGggPSBub29wDQooMikgU2VudCBBY2Nlc3MtQWNjZXB0IElkIDI1 NyBmcm9tIDEyNy4wLjAuMToxODEyIHRvIDEyNy4wLjAuMTo0NzIxNiBsZW5ndGggMA0KKDIpICAg RVhURU5ERUQtSUQgPSAweDAwMDAwMjAyDQooMikgICBUdW5uZWwtVHlwZTowID0gVkxBTg0KKDIp ICAgVHVubmVsLU1lZGl1bS1UeXBlOjAgPSBJRUVFLTgwMg0KKDIpICAgVHVubmVsLVByaXZhdGUt R3JvdXAtSWQ6MCA9ICI1NSINCigyKSBGaW5pc2hlZCByZXF1ZXN0DQpXYWtpbmcgdXAgaW4gNC45 IHNlY29uZHMuDQooMikgQ2xlYW5pbmcgdXAgcmVxdWVzdCBwYWNrZXQgSUQgMjU3IHdpdGggdGlt ZXN0YW1wICsxNDMNClJlYWR5IHRvIHByb2Nlc3MgcmVxdWVzdHMNCg0KDQogaG9tZS1zZXJ2ZXI6 DQoNClJlYWR5IHRvIHByb2Nlc3MgcmVxdWVzdHMNCg0KDQooMikgUmVjZWl2ZWQgQWNjZXNzLVJl cXVlc3QgSWQgMjU4IGZyb20gMTkyLjE2OC4xLjM1OjQ3NzkyIHRvIDE5Mi4xNjguMS4xMDA6MTgx MiBsZW5ndGggMTA1DQooMikgICBFWFRFTkRFRC1JRCA9IDB4MDAwMDAyMDINCigyKSAgIFVzZXIt TmFtZSA9ICJjYXRoeUB5b3VyLW9yZy5jb20iDQooMikgICBVc2VyLVBhc3N3b3JkID0gInBhc3Nj YXRoeSINCigyKSAgIE5BUy1JUC1BZGRyZXNzID0gMTI3LjAuMC4xDQooMikgICBOQVMtUG9ydCA9 IDEwMA0KKDIpICAgTWVzc2FnZS1BdXRoZW50aWNhdG9yID0gMHg1MWNiZjFmNTJjYTRiZDQxZjA2 YjY0NDgzOTFkZmNiYQ0KKDIpICAgRXZlbnQtVGltZXN0YW1wID0gIkFwciAyNiAyMDE3IDE1OjI0 OjI0IFBEVCINCigyKSAgIFByb3h5LVN0YXRlID0gMHgzNTMxMzMNCigyKSAjIEV4ZWN1dGluZyBz ZWN0aW9uIGF1dGhvcml6ZSBmcm9tIGZpbGUgL3Vzci9sb2NhbC9ldGMvcmFkZGIvc2l0ZXMtZW5h YmxlZC9kZWZhdWx0DQooMikgICBhdXRob3JpemUgew0KKDIpICAgICBwb2xpY3kgZmlsdGVyX3Vz ZXJuYW1lIHsNCigyKSAgICAgICBpZiAoJlVzZXItTmFtZSkgew0KKDIpICAgICAgIGlmICgmVXNl ci1OYW1lKSAgLT4gVFJVRQ0KKDIpICAgICAgIGlmICgmVXNlci1OYW1lKSAgew0KKDIpICAgICAg ICAgaWYgKCZVc2VyLU5hbWUgPX4gLyAvKSB7DQooMikgICAgICAgICBpZiAoJlVzZXItTmFtZSA9 fiAvIC8pICAtPiBGQUxTRQ0KKDIpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL0BbXkBdKkAv ICkgew0KKDIpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL0BbXkBdKkAvICkgIC0+IEZBTFNF DQooMikgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvXC5cLi8gKSB7DQooMikgICAgICAgICBp ZiAoJlVzZXItTmFtZSA9fiAvXC5cLi8gKSAgLT4gRkFMU0UNCigyKSAgICAgICAgIGlmICgoJlVz ZXItTmFtZSA9fiAvQC8pICYmICgmVXNlci1OYW1lICF+IC9AKC4rKVwuKC4rKSQvKSkgIHsNCigy KSAgICAgICAgIGlmICgoJlVzZXItTmFtZSA9fiAvQC8pICYmICgmVXNlci1OYW1lICF+IC9AKC4r KVwuKC4rKSQvKSkgICAtPiBGQUxTRQ0KKDIpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL1wu JC8pICB7DQooMikgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvXC4kLykgICAtPiBGQUxTRQ0K KDIpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL0BcLi8pICB7DQooMikgICAgICAgICBpZiAo JlVzZXItTmFtZSA9fiAvQFwuLykgICAtPiBGQUxTRQ0KKDIpICAgICAgIH0gIyBpZiAoJlVzZXIt TmFtZSkgID0gbm90Zm91bmQNCigyKSAgICAgfSAjIHBvbGljeSBmaWx0ZXJfdXNlcm5hbWUgPSBu b3Rmb3VuZA0KKDIpICAgICBbcHJlcHJvY2Vzc10gPSBvaw0KKDIpICAgICBbY2hhcF0gPSBub29w DQooMikgICAgIFttc2NoYXBdID0gbm9vcA0KKDIpICAgICBbZGlnZXN0XSA9IG5vb3ANCigyKSBz dWZmaXg6IENoZWNraW5nIGZvciBzdWZmaXggYWZ0ZXIgIkAiDQooMikgc3VmZml4OiBMb29raW5n IHVwIHJlYWxtICJ5b3VyLW9yZy5jb20iIGZvciBVc2VyLU5hbWUgPSAiY2F0aHlAeW91ci1vcmcu Y29tIg0KKDIpIHN1ZmZpeDogRm91bmQgcmVhbG0gInlvdXItb3JnLmNvbSINCigyKSBzdWZmaXg6 IEFkZGluZyBTdHJpcHBlZC1Vc2VyLU5hbWUgPSAiY2F0aHkiDQooMikgc3VmZml4OiBBZGRpbmcg UmVhbG0gPSAieW91ci1vcmcuY29tIg0KKDIpIHN1ZmZpeDogQXV0aGVudGljYXRpb24gcmVhbG0g aXMgTE9DQUwNCigyKSAgICAgW3N1ZmZpeF0gPSBvaw0KKDIpIGVhcDogTm8gRUFQLU1lc3NhZ2Us IG5vdCBkb2luZyBFQVANCigyKSAgICAgW2VhcF0gPSBub29wDQooMikgZmlsZXM6IHVzZXJzOiBN YXRjaGVkIGVudHJ5IGNhdGh5IGF0IGxpbmUgNQ0KKDIpICAgICBbZmlsZXNdID0gb2sNCigyKSAg ICAgW2V4cGlyYXRpb25dID0gbm9vcA0KKDIpICAgICBbbG9naW50aW1lXSA9IG5vb3ANCigyKSAg ICAgW3BhcF0gPSB1cGRhdGVkDQooMikgICB9ICMgYXV0aG9yaXplID0gdXBkYXRlZA0KKDIpIEZv dW5kIEF1dGgtVHlwZSA9IFBBUA0KKDIpICMgRXhlY3V0aW5nIGdyb3VwIGZyb20gZmlsZSAvdXNy L2xvY2FsL2V0Yy9yYWRkYi9zaXRlcy1lbmFibGVkL2RlZmF1bHQNCigyKSAgIEF1dGgtVHlwZSBQ QVAgew0KKDIpIHBhcDogTG9naW4gYXR0ZW1wdCB3aXRoIHBhc3N3b3JkDQooMikgcGFwOiBDb21w YXJpbmcgd2l0aCAia25vd24gZ29vZCIgQ2xlYXJ0ZXh0LVBhc3N3b3JkDQooMikgcGFwOiBVc2Vy IGF1dGhlbnRpY2F0ZWQgc3VjY2Vzc2Z1bGx5DQooMikgICAgIFtwYXBdID0gb2sNCigyKSAgIH0g IyBBdXRoLVR5cGUgUEFQID0gb2sNCigyKSAjIEV4ZWN1dGluZyBzZWN0aW9uIHBvc3QtYXV0aCBm cm9tIGZpbGUgL3Vzci9sb2NhbC9ldGMvcmFkZGIvc2l0ZXMtZW5hYmxlZC9kZWZhdWx0DQooMikg ICBwb3N0LWF1dGggew0KKDIpICAgICB1cGRhdGUgew0KKDIpICAgICAgIE5vIGF0dHJpYnV0ZXMg dXBkYXRlZA0KKDIpICAgICB9ICMgdXBkYXRlID0gbm9vcA0KKDIpICAgICBbZXhlY10gPSBub29w DQooMikgICAgIHBvbGljeSByZW1vdmVfcmVwbHlfbWVzc2FnZV9pZl9lYXAgew0KKDIpICAgICAg IGlmICgmcmVwbHk6RUFQLU1lc3NhZ2UgJiYgJnJlcGx5OlJlcGx5LU1lc3NhZ2UpIHsNCigyKSAg ICAgICBpZiAoJnJlcGx5OkVBUC1NZXNzYWdlICYmICZyZXBseTpSZXBseS1NZXNzYWdlKSAgLT4g RkFMU0UNCigyKSAgICAgICBlbHNlIHsNCigyKSAgICAgICAgIFtub29wXSA9IG5vb3ANCigyKSAg ICAgICB9ICMgZWxzZSA9IG5vb3ANCigyKSAgICAgfSAjIHBvbGljeSByZW1vdmVfcmVwbHlfbWVz c2FnZV9pZl9lYXAgPSBub29wDQooMikgICB9ICMgcG9zdC1hdXRoID0gbm9vcA0KKDIpIFNlbnQg QWNjZXNzLUFjY2VwdCBJZCAyNTggZnJvbSAxOTIuMTY4LjEuMTAwOjE4MTIgdG8gMTkyLjE2OC4x LjM1OjQ3NzkyIGxlbmd0aCAwDQooMikgICBUdW5uZWwtVHlwZSA9IFZMQU4NCigyKSAgIFR1bm5l bC1NZWRpdW0tVHlwZSA9IElFRUUtODAyDQooMikgICBUdW5uZWwtUHJpdmF0ZS1Hcm91cC1JZCA9 ICI1NSINCigyKSAgIFByb3h5LVN0YXRlID0gMHgzNTMxMzMNCigyKSBGaW5pc2hlZCByZXF1ZXN0 DQpXYWtpbmcgdXAgaW4gNC45IHNlY29uZHMuDQooMikgQ2xlYW5pbmcgdXAgcmVxdWVzdCBwYWNr ZXQgSUQgMjU4IHdpdGggdGltZXN0YW1wICsxNDcNClJlYWR5IHRvIHByb2Nlc3MgcmVxdWVzdHMN Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCiAoNikgQXV0aCB3aXRoIHByb3h5IHNlcnZlciAobm8gZXh0LUlE IGJldHdlZW4gY2xpZW50IGFuZCBwcm94eSwgYnV0DQogICAgICAgd2l0aCBleHQtSUQgYmV0d2Vl biBwcm94eSBhbmQgaG9tZS1zZXJ2ZXIpDQogICAgICdyYWR0ZXN0IGNhdGh5QHlvdXItb3JnLmNv bSBwYXNzY2F0aHkgMTI3LjAuMC4xIDEwMCB0ZXN0aW5nMTIzJw0KICAgICBOb3RlOiB0aGUgSWQg ZnJvbSBjbGllbnQgdG8gcHJveHkgaXMgMTc5LCBhbmQgdGhlIGV4dC1pZCBmcm9tDQogICAgICAg ICAgIHByb3h5IHRvIGhvbWUtc2VydmVyIGlzIDI1OQ0KICAgICBPdXRwdXQgb2YgY2xpZW50IGFu ZCBzZXJ2ZXIgYmVsb3c6DQoNCiBjbGllbnQ6DQoNCmxlbm92bzp+L3JhZGl1cy9mci0zLjAuMTIk IHJhZHRlc3QgY2F0aHlAeW91ci1vcmcuY29tIHBhc3NjYXRoeSAxMjcuMC4wLjEgMTAwIHRlc3Rp bmcxMjMNClNlbnQgQWNjZXNzLVJlcXVlc3QgSWQgMTc5IGZyb20gMC4wLjAuMDo0ODE3MCB0byAx MjcuMC4wLjE6MTgxMiBsZW5ndGggODgNCglVc2VyLU5hbWUgPSAiY2F0aHlAeW91ci1vcmcuY29t Ig0KCVVzZXItUGFzc3dvcmQgPSAicGFzc2NhdGh5Ig0KCU5BUy1JUC1BZGRyZXNzID0gMTI3LjAu MC4xDQoJTkFTLVBvcnQgPSAxMDANCglNZXNzYWdlLUF1dGhlbnRpY2F0b3IgPSAweDAwDQoJQ2xl YXJ0ZXh0LVBhc3N3b3JkID0gInBhc3NjYXRoeSINClJlY2VpdmVkIEFjY2Vzcy1BY2NlcHQgSWQg MTc5IGZyb20gMTI3LjAuMC4xOjE4MTIgdG8gMC4wLjAuMDowIGxlbmd0aCAzNg0KCVR1bm5lbC1U eXBlOjAgPSBWTEFODQoJVHVubmVsLU1lZGl1bS1UeXBlOjAgPSBJRUVFLTgwMg0KCVR1bm5lbC1Q cml2YXRlLUdyb3VwLUlkOjAgPSAiNTUiDQpsZW5vdm86fi9yYWRpdXMvZnItMy4wLjEyJCANCg0K IHByb3h5LXNlcnZlcjoNCg0KUmVhZHkgdG8gcHJvY2VzcyByZXF1ZXN0cw0KDQoNCigzKSBSZWNl aXZlZCBBY2Nlc3MtUmVxdWVzdCBJZCAxNzkgZnJvbSAxMjcuMC4wLjE6NDgxNzAgdG8gMTI3LjAu MC4xOjE4MTIgbGVuZ3RoIDg4DQooMykgICBVc2VyLU5hbWUgPSAiY2F0aHlAeW91ci1vcmcuY29t Ig0KKDMpICAgVXNlci1QYXNzd29yZCA9ICJwYXNzY2F0aHkiDQooMykgICBOQVMtSVAtQWRkcmVz cyA9IDEyNy4wLjAuMQ0KKDMpICAgTkFTLVBvcnQgPSAxMDANCigzKSAgIE1lc3NhZ2UtQXV0aGVu dGljYXRvciA9IDB4ZWU3NDJjM2Y5YWUzZTYzMTcyOTZiNDQ0NzUwYTE2NWINCigzKSAjIEV4ZWN1 dGluZyBzZWN0aW9uIGF1dGhvcml6ZSBmcm9tIGZpbGUgL3Vzci9sb2NhbC9ldGMvcmFkZGIvc2l0 ZXMtZW5hYmxlZC9kZWZhdWx0DQooMykgICBhdXRob3JpemUgew0KKDMpICAgICBwb2xpY3kgZmls dGVyX3VzZXJuYW1lIHsNCigzKSAgICAgICBpZiAoJlVzZXItTmFtZSkgew0KKDMpICAgICAgIGlm ICgmVXNlci1OYW1lKSAgLT4gVFJVRQ0KKDMpICAgICAgIGlmICgmVXNlci1OYW1lKSAgew0KKDMp ICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gLyAvKSB7DQooMykgICAgICAgICBpZiAoJlVzZXIt TmFtZSA9fiAvIC8pICAtPiBGQUxTRQ0KKDMpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL0Bb XkBdKkAvICkgew0KKDMpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL0BbXkBdKkAvICkgIC0+ IEZBTFNFDQooMykgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvXC5cLi8gKSB7DQooMykgICAg ICAgICBpZiAoJlVzZXItTmFtZSA9fiAvXC5cLi8gKSAgLT4gRkFMU0UNCigzKSAgICAgICAgIGlm ICgoJlVzZXItTmFtZSA9fiAvQC8pICYmICgmVXNlci1OYW1lICF+IC9AKC4rKVwuKC4rKSQvKSkg IHsNCigzKSAgICAgICAgIGlmICgoJlVzZXItTmFtZSA9fiAvQC8pICYmICgmVXNlci1OYW1lICF+ IC9AKC4rKVwuKC4rKSQvKSkgICAtPiBGQUxTRQ0KKDMpICAgICAgICAgaWYgKCZVc2VyLU5hbWUg PX4gL1wuJC8pICB7DQooMykgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvXC4kLykgICAtPiBG QUxTRQ0KKDMpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL0BcLi8pICB7DQooMykgICAgICAg ICBpZiAoJlVzZXItTmFtZSA9fiAvQFwuLykgICAtPiBGQUxTRQ0KKDMpICAgICAgIH0gIyBpZiAo JlVzZXItTmFtZSkgID0gbm90Zm91bmQNCigzKSAgICAgfSAjIHBvbGljeSBmaWx0ZXJfdXNlcm5h bWUgPSBub3Rmb3VuZA0KKDMpICAgICBbcHJlcHJvY2Vzc10gPSBvaw0KKDMpICAgICBbY2hhcF0g PSBub29wDQooMykgICAgIFttc2NoYXBdID0gbm9vcA0KKDMpICAgICBbZGlnZXN0XSA9IG5vb3AN CigzKSBzdWZmaXg6IENoZWNraW5nIGZvciBzdWZmaXggYWZ0ZXIgIkAiDQooMykgc3VmZml4OiBM b29raW5nIHVwIHJlYWxtICJ5b3VyLW9yZy5jb20iIGZvciBVc2VyLU5hbWUgPSAiY2F0aHlAeW91 ci1vcmcuY29tIg0KKDMpIHN1ZmZpeDogRm91bmQgcmVhbG0gInlvdXItb3JnLmNvbSINCigzKSBz dWZmaXg6IEFkZGluZyBSZWFsbSA9ICJ5b3VyLW9yZy5jb20iDQooMykgc3VmZml4OiBQcm94eWlu ZyByZXF1ZXN0IGZyb20gdXNlciBjYXRoeUB5b3VyLW9yZy5jb20gdG8gcmVhbG0geW91ci1vcmcu Y29tDQooMykgc3VmZml4OiBQcmVwYXJpbmcgdG8gcHJveHkgYXV0aGVudGljYXRpb24gcmVxdWVz dCB0byByZWFsbSAieW91ci1vcmcuY29tIiANCigzKSAgICAgW3N1ZmZpeF0gPSB1cGRhdGVkDQoo MykgICAgIGlmICggcmVxdWVzdDpSZWFsbSA9PSAiTlVMTCIgKXsNCigzKSAgICAgaWYgKCByZXF1 ZXN0OlJlYWxtID09ICJOVUxMIiApIC0+IEZBTFNFDQooMykgZWFwOiBObyBFQVAtTWVzc2FnZSwg bm90IGRvaW5nIEVBUA0KKDMpICAgICBbZWFwXSA9IG5vb3ANCigzKSAgICAgW3VuaXhdID0gbm90 Zm91bmQNCigzKSAgICAgW2ZpbGVzXSA9IG5vb3ANCigzKSAgICAgW2V4cGlyYXRpb25dID0gbm9v cA0KKDMpICAgICBbbG9naW50aW1lXSA9IG5vb3ANCigzKSAgICAgW3BhcF0gPSBub29wDQooMykg ICB9ICMgYXV0aG9yaXplID0gdXBkYXRlZA0KKDMpIFN0YXJ0aW5nIHByb3h5IHRvIGhvbWUgc2Vy dmVyIDE5Mi4xNjguMS4xMDAgcG9ydCAxODEyDQooMykgUHJveHlpbmcgcmVxdWVzdCB0byBob21l IHNlcnZlciAxOTIuMTY4LjEuMTAwIHBvcnQgMTgxMiB0aW1lb3V0IDMwLjAwMDAwMA0KKDMpIFNl bnQgQWNjZXNzLVJlcXVlc3QgSWQgMjU5IGZyb20gMC4wLjAuMDo0Nzc5MiB0byAxOTIuMTY4LjEu MTAwOjE4MTIgbGVuZ3RoIDEwNQ0KKDMpICAgVXNlci1OYW1lID0gImNhdGh5QHlvdXItb3JnLmNv bSINCigzKSAgIFVzZXItUGFzc3dvcmQgPSAicGFzc2NhdGh5Ig0KKDMpICAgTkFTLUlQLUFkZHJl c3MgPSAxMjcuMC4wLjENCigzKSAgIE5BUy1Qb3J0ID0gMTAwDQooMykgICBNZXNzYWdlLUF1dGhl bnRpY2F0b3IgPSAweGVlNzQyYzNmOWFlM2U2MzE3Mjk2YjQ0NDc1MGExNjViDQooMykgICBFdmVu dC1UaW1lc3RhbXAgPSAiQXByIDI2IDIwMTcgMTU6MjY6MjEgUERUIg0KKDMpICAgUHJveHktU3Rh dGUgPSAweDMxMzczOQ0KV2FraW5nIHVwIGluIDAuMyBzZWNvbmRzLg0KKDMpIENsZWFyaW5nIGV4 aXN0aW5nICZyZXBseTogYXR0cmlidXRlcw0KKDMpIFJlY2VpdmVkIEFjY2Vzcy1BY2NlcHQgSWQg MjU5IGZyb20gMTkyLjE2OC4xLjEwMDoxODEyIHRvIDE5Mi4xNjguMS4zNTo0Nzc5MiBsZW5ndGgg NDcNCigzKSAgIEVYVEVOREVELUlEID0gMHgwMDAwMDIwMw0KKDMpICAgVHVubmVsLVR5cGU6MCA9 IFZMQU4NCigzKSAgIFR1bm5lbC1NZWRpdW0tVHlwZTowID0gSUVFRS04MDINCigzKSAgIFR1bm5l bC1Qcml2YXRlLUdyb3VwLUlkOjAgPSAiNTUiDQooMykgICBQcm94eS1TdGF0ZSA9IDB4MzEzNzM5 DQooMykgIyBFeGVjdXRpbmcgc2VjdGlvbiBwb3N0LXByb3h5IGZyb20gZmlsZSAvdXNyL2xvY2Fs L2V0Yy9yYWRkYi9zaXRlcy1lbmFibGVkL2RlZmF1bHQNCigzKSAgIHBvc3QtcHJveHkgew0KKDMp IGVhcDogTm8gcHJlLWV4aXN0aW5nIGhhbmRsZXIgZm91bmQNCigzKSAgICAgW2VhcF0gPSBub29w DQooMykgICB9ICMgcG9zdC1wcm94eSA9IG5vb3ANCigzKSBGb3VuZCBBdXRoLVR5cGUgPSBBY2Nl cHQNCigzKSBBdXRoLVR5cGUgPSBBY2NlcHQsIGFjY2VwdGluZyB0aGUgdXNlcg0KKDMpICMgRXhl Y3V0aW5nIHNlY3Rpb24gcG9zdC1hdXRoIGZyb20gZmlsZSAvdXNyL2xvY2FsL2V0Yy9yYWRkYi9z aXRlcy1lbmFibGVkL2RlZmF1bHQNCigzKSAgIHBvc3QtYXV0aCB7DQooMykgICAgIHVwZGF0ZSB7 DQooMykgICAgICAgTm8gYXR0cmlidXRlcyB1cGRhdGVkDQooMykgICAgIH0gIyB1cGRhdGUgPSBu b29wDQooMykgICAgIFtleGVjXSA9IG5vb3ANCigzKSAgICAgcG9saWN5IHJlbW92ZV9yZXBseV9t ZXNzYWdlX2lmX2VhcCB7DQooMykgICAgICAgaWYgKCZyZXBseTpFQVAtTWVzc2FnZSAmJiAmcmVw bHk6UmVwbHktTWVzc2FnZSkgew0KKDMpICAgICAgIGlmICgmcmVwbHk6RUFQLU1lc3NhZ2UgJiYg JnJlcGx5OlJlcGx5LU1lc3NhZ2UpICAtPiBGQUxTRQ0KKDMpICAgICAgIGVsc2Ugew0KKDMpICAg ICAgICAgW25vb3BdID0gbm9vcA0KKDMpICAgICAgIH0gIyBlbHNlID0gbm9vcA0KKDMpICAgICB9 ICMgcG9saWN5IHJlbW92ZV9yZXBseV9tZXNzYWdlX2lmX2VhcCA9IG5vb3ANCigzKSAgIH0gIyBw b3N0LWF1dGggPSBub29wDQooMykgU2VudCBBY2Nlc3MtQWNjZXB0IElkIDE3OSBmcm9tIDEyNy4w LjAuMToxODEyIHRvIDEyNy4wLjAuMTo0ODE3MCBsZW5ndGggMA0KKDMpICAgRVhURU5ERUQtSUQg PSAweDAwMDAwMjAzDQooMykgICBUdW5uZWwtVHlwZTowID0gVkxBTg0KKDMpICAgVHVubmVsLU1l ZGl1bS1UeXBlOjAgPSBJRUVFLTgwMg0KKDMpICAgVHVubmVsLVByaXZhdGUtR3JvdXAtSWQ6MCA9 ICI1NSINCigzKSBGaW5pc2hlZCByZXF1ZXN0DQpXYWtpbmcgdXAgaW4gNC45IHNlY29uZHMuDQoo MykgQ2xlYW5pbmcgdXAgcmVxdWVzdCBwYWNrZXQgSUQgMTc5IHdpdGggdGltZXN0YW1wICsyNjAN ClJlYWR5IHRvIHByb2Nlc3MgcmVxdWVzdHMNCg0KIGhvbWUtc2VydmVyOg0KDQpSZWFkeSB0byBw cm9jZXNzIHJlcXVlc3RzDQoNCg0KKDMpIFJlY2VpdmVkIEFjY2Vzcy1SZXF1ZXN0IElkIDI1OSBm cm9tIDE5Mi4xNjguMS4zNTo0Nzc5MiB0byAxOTIuMTY4LjEuMTAwOjE4MTIgbGVuZ3RoIDEwNQ0K KDMpICAgRVhURU5ERUQtSUQgPSAweDAwMDAwMjAzDQooMykgICBVc2VyLU5hbWUgPSAiY2F0aHlA eW91ci1vcmcuY29tIg0KKDMpICAgVXNlci1QYXNzd29yZCA9ICJwYXNzY2F0aHkiDQooMykgICBO QVMtSVAtQWRkcmVzcyA9IDEyNy4wLjAuMQ0KKDMpICAgTkFTLVBvcnQgPSAxMDANCigzKSAgIE1l c3NhZ2UtQXV0aGVudGljYXRvciA9IDB4Y2IyZTE3OWEwZTRiM2MxNDEwZDQxNTg1ZjU0YjBkZWQN CigzKSAgIEV2ZW50LVRpbWVzdGFtcCA9ICJBcHIgMjYgMjAxNyAxNToyNjoyMSBQRFQiDQooMykg ICBQcm94eS1TdGF0ZSA9IDB4MzEzNzM5DQooMykgIyBFeGVjdXRpbmcgc2VjdGlvbiBhdXRob3Jp emUgZnJvbSBmaWxlIC91c3IvbG9jYWwvZXRjL3JhZGRiL3NpdGVzLWVuYWJsZWQvZGVmYXVsdA0K KDMpICAgYXV0aG9yaXplIHsNCigzKSAgICAgcG9saWN5IGZpbHRlcl91c2VybmFtZSB7DQooMykg ICAgICAgaWYgKCZVc2VyLU5hbWUpIHsNCigzKSAgICAgICBpZiAoJlVzZXItTmFtZSkgIC0+IFRS VUUNCigzKSAgICAgICBpZiAoJlVzZXItTmFtZSkgIHsNCigzKSAgICAgICAgIGlmICgmVXNlci1O YW1lID1+IC8gLykgew0KKDMpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gLyAvKSAgLT4gRkFM U0UNCigzKSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9AW15AXSpALyApIHsNCigzKSAgICAg ICAgIGlmICgmVXNlci1OYW1lID1+IC9AW15AXSpALyApICAtPiBGQUxTRQ0KKDMpICAgICAgICAg aWYgKCZVc2VyLU5hbWUgPX4gL1wuXC4vICkgew0KKDMpICAgICAgICAgaWYgKCZVc2VyLU5hbWUg PX4gL1wuXC4vICkgIC0+IEZBTFNFDQooMykgICAgICAgICBpZiAoKCZVc2VyLU5hbWUgPX4gL0Av KSAmJiAoJlVzZXItTmFtZSAhfiAvQCguKylcLiguKykkLykpICB7DQooMykgICAgICAgICBpZiAo KCZVc2VyLU5hbWUgPX4gL0AvKSAmJiAoJlVzZXItTmFtZSAhfiAvQCguKylcLiguKykkLykpICAg LT4gRkFMU0UNCigzKSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9cLiQvKSAgew0KKDMpICAg ICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL1wuJC8pICAgLT4gRkFMU0UNCigzKSAgICAgICAgIGlm ICgmVXNlci1OYW1lID1+IC9AXC4vKSAgew0KKDMpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4g L0BcLi8pICAgLT4gRkFMU0UNCigzKSAgICAgICB9ICMgaWYgKCZVc2VyLU5hbWUpICA9IG5vdGZv dW5kDQooMykgICAgIH0gIyBwb2xpY3kgZmlsdGVyX3VzZXJuYW1lID0gbm90Zm91bmQNCigzKSAg ICAgW3ByZXByb2Nlc3NdID0gb2sNCigzKSAgICAgW2NoYXBdID0gbm9vcA0KKDMpICAgICBbbXNj aGFwXSA9IG5vb3ANCigzKSAgICAgW2RpZ2VzdF0gPSBub29wDQooMykgc3VmZml4OiBDaGVja2lu ZyBmb3Igc3VmZml4IGFmdGVyICJAIg0KKDMpIHN1ZmZpeDogTG9va2luZyB1cCByZWFsbSAieW91 ci1vcmcuY29tIiBmb3IgVXNlci1OYW1lID0gImNhdGh5QHlvdXItb3JnLmNvbSINCigzKSBzdWZm aXg6IEZvdW5kIHJlYWxtICJ5b3VyLW9yZy5jb20iDQooMykgc3VmZml4OiBBZGRpbmcgU3RyaXBw ZWQtVXNlci1OYW1lID0gImNhdGh5Ig0KKDMpIHN1ZmZpeDogQWRkaW5nIFJlYWxtID0gInlvdXIt b3JnLmNvbSINCigzKSBzdWZmaXg6IEF1dGhlbnRpY2F0aW9uIHJlYWxtIGlzIExPQ0FMDQooMykg ICAgIFtzdWZmaXhdID0gb2sNCigzKSBlYXA6IE5vIEVBUC1NZXNzYWdlLCBub3QgZG9pbmcgRUFQ DQooMykgICAgIFtlYXBdID0gbm9vcA0KKDMpIGZpbGVzOiB1c2VyczogTWF0Y2hlZCBlbnRyeSBj YXRoeSBhdCBsaW5lIDUNCigzKSAgICAgW2ZpbGVzXSA9IG9rDQooMykgICAgIFtleHBpcmF0aW9u XSA9IG5vb3ANCigzKSAgICAgW2xvZ2ludGltZV0gPSBub29wDQooMykgICAgIFtwYXBdID0gdXBk YXRlZA0KKDMpICAgfSAjIGF1dGhvcml6ZSA9IHVwZGF0ZWQNCigzKSBGb3VuZCBBdXRoLVR5cGUg PSBQQVANCigzKSAjIEV4ZWN1dGluZyBncm91cCBmcm9tIGZpbGUgL3Vzci9sb2NhbC9ldGMvcmFk ZGIvc2l0ZXMtZW5hYmxlZC9kZWZhdWx0DQooMykgICBBdXRoLVR5cGUgUEFQIHsNCigzKSBwYXA6 IExvZ2luIGF0dGVtcHQgd2l0aCBwYXNzd29yZA0KKDMpIHBhcDogQ29tcGFyaW5nIHdpdGggImtu b3duIGdvb2QiIENsZWFydGV4dC1QYXNzd29yZA0KKDMpIHBhcDogVXNlciBhdXRoZW50aWNhdGVk IHN1Y2Nlc3NmdWxseQ0KKDMpICAgICBbcGFwXSA9IG9rDQooMykgICB9ICMgQXV0aC1UeXBlIFBB UCA9IG9rDQooMykgIyBFeGVjdXRpbmcgc2VjdGlvbiBwb3N0LWF1dGggZnJvbSBmaWxlIC91c3Iv bG9jYWwvZXRjL3JhZGRiL3NpdGVzLWVuYWJsZWQvZGVmYXVsdA0KKDMpICAgcG9zdC1hdXRoIHsN CigzKSAgICAgdXBkYXRlIHsNCigzKSAgICAgICBObyBhdHRyaWJ1dGVzIHVwZGF0ZWQNCigzKSAg ICAgfSAjIHVwZGF0ZSA9IG5vb3ANCigzKSAgICAgW2V4ZWNdID0gbm9vcA0KKDMpICAgICBwb2xp Y3kgcmVtb3ZlX3JlcGx5X21lc3NhZ2VfaWZfZWFwIHsNCigzKSAgICAgICBpZiAoJnJlcGx5OkVB UC1NZXNzYWdlICYmICZyZXBseTpSZXBseS1NZXNzYWdlKSB7DQooMykgICAgICAgaWYgKCZyZXBs eTpFQVAtTWVzc2FnZSAmJiAmcmVwbHk6UmVwbHktTWVzc2FnZSkgIC0+IEZBTFNFDQooMykgICAg ICAgZWxzZSB7DQooMykgICAgICAgICBbbm9vcF0gPSBub29wDQooMykgICAgICAgfSAjIGVsc2Ug PSBub29wDQooMykgICAgIH0gIyBwb2xpY3kgcmVtb3ZlX3JlcGx5X21lc3NhZ2VfaWZfZWFwID0g bm9vcA0KKDMpICAgfSAjIHBvc3QtYXV0aCA9IG5vb3ANCigzKSBTZW50IEFjY2Vzcy1BY2NlcHQg SWQgMjU5IGZyb20gMTkyLjE2OC4xLjEwMDoxODEyIHRvIDE5Mi4xNjguMS4zNTo0Nzc5MiBsZW5n dGggMA0KKDMpICAgVHVubmVsLVR5cGUgPSBWTEFODQooMykgICBUdW5uZWwtTWVkaXVtLVR5cGUg PSBJRUVFLTgwMg0KKDMpICAgVHVubmVsLVByaXZhdGUtR3JvdXAtSWQgPSAiNTUiDQooMykgICBQ cm94eS1TdGF0ZSA9IDB4MzEzNzM5DQooMykgRmluaXNoZWQgcmVxdWVzdA0KV2FraW5nIHVwIGlu IDQuOSBzZWNvbmRzLg0KKDMpIENsZWFuaW5nIHVwIHJlcXVlc3QgcGFja2V0IElEIDI1OSB3aXRo IHRpbWVzdGFtcCArMjY0DQpSZWFkeSB0byBwcm9jZXNzIHJlcXVlc3RzDQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQogKDcpIEF1dGggd2l0aCBJUHY2IHRyYW5zcG9ydCB0byByYWRpdXMgc2VydmVyIChhbmQg d2l0aCBleHQtSUQpDQogICAgICdyYWR0ZXN0IC02IC1JIGFsaWNlQG15LW9yZy5jb20gcGFzc21l IFs6OjFdIDEwMCB0ZXN0aW5nMTIzJw0KICAgICBOb3RlOiBJUHY2IHdpdGggZXh0LUlEIGJldHdl ZW4gY2xpZW50IGFuZCBzZXJ2ZXINCiAgICAgT3V0cHV0IG9mIGNsaWVudCBhbmQgc2VydmVyIGJl bG93Og0KDQogY2xpZW50Og0KDQpsZW5vdm86fi9yYWRpdXMvZnItMy4wLjEyJCByYWR0ZXN0IC02 IC1JIGFsaWNlQG15LW9yZy5jb20gcGFzc21lIFs6OjFdIDEwMCB0ZXN0aW5nMTIzDQpTZW50IEFj Y2Vzcy1SZXF1ZXN0IElkIDI1NyBmcm9tIFs6Ol06MzMyOTYgdG8gWzo6MV06MTgxMiBsZW5ndGgg MTA0DQoJVXNlci1OYW1lID0gImFsaWNlQG15LW9yZy5jb20iDQoJVXNlci1QYXNzd29yZCA9ICJw YXNzbWUiDQoJTkFTLUlQdjYtQWRkcmVzcyA9IDo6MQ0KCU5BUy1Qb3J0ID0gMTAwDQoJTWVzc2Fn ZS1BdXRoZW50aWNhdG9yID0gMHgwMA0KCUNsZWFydGV4dC1QYXNzd29yZCA9ICJwYXNzbWUiDQpS ZWNlaXZlZCBBY2Nlc3MtQWNjZXB0IElkIDI1NyBmcm9tIFs6OjFdOjE4MTIgdG8gWzo6XTowIGxl bmd0aCA0Mw0KCUVYVEVOREVELUlEID0gMHgwMDAwMDIwMQ0KCVR1bm5lbC1UeXBlOjAgPSBWTEFO DQoJVHVubmVsLU1lZGl1bS1UeXBlOjAgPSBJRUVFLTgwMg0KCVR1bm5lbC1Qcml2YXRlLUdyb3Vw LUlkOjAgPSAiMTAwIg0KbGVub3ZvOn4vcmFkaXVzL2ZyLTMuMC4xMiQgDQoNCiBzZXJ2ZXI6DQoN ClJlYWR5IHRvIHByb2Nlc3MgcmVxdWVzdHMNCg0KDQooNCkgUmVjZWl2ZWQgQWNjZXNzLVJlcXVl c3QgSWQgMjU3IGZyb20gWzo6MV06MzMyOTYgdG8gWzo6MV06MTgxMiBsZW5ndGggMTA0DQooNCkg ICBFWFRFTkRFRC1JRCA9IDB4MDAwMDAyMDENCig0KSAgIFVzZXItTmFtZSA9ICJhbGljZUBteS1v cmcuY29tIg0KKDQpICAgVXNlci1QYXNzd29yZCA9ICJwYXNzbWUiDQooNCkgICBOQVMtSVB2Ni1B ZGRyZXNzID0gOjoxDQooNCkgICBOQVMtUG9ydCA9IDEwMA0KKDQpICAgTWVzc2FnZS1BdXRoZW50 aWNhdG9yID0gMHgzOGI0ZGRmZTQ3ODRkMWIyMmRmMDJjZWU0ODMzOGQ1Ng0KKDQpICMgRXhlY3V0 aW5nIHNlY3Rpb24gYXV0aG9yaXplIGZyb20gZmlsZSAvdXNyL2xvY2FsL2V0Yy9yYWRkYi9zaXRl cy1lbmFibGVkL2RlZmF1bHQNCig0KSAgIGF1dGhvcml6ZSB7DQooNCkgICAgIHBvbGljeSBmaWx0 ZXJfdXNlcm5hbWUgew0KKDQpICAgICAgIGlmICgmVXNlci1OYW1lKSB7DQooNCkgICAgICAgaWYg KCZVc2VyLU5hbWUpICAtPiBUUlVFDQooNCkgICAgICAgaWYgKCZVc2VyLU5hbWUpICB7DQooNCkg ICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvIC8pIHsNCig0KSAgICAgICAgIGlmICgmVXNlci1O YW1lID1+IC8gLykgIC0+IEZBTFNFDQooNCkgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvQFte QF0qQC8gKSB7DQooNCkgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvQFteQF0qQC8gKSAgLT4g RkFMU0UNCig0KSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9cLlwuLyApIHsNCig0KSAgICAg ICAgIGlmICgmVXNlci1OYW1lID1+IC9cLlwuLyApICAtPiBGQUxTRQ0KKDQpICAgICAgICAgaWYg KCgmVXNlci1OYW1lID1+IC9ALykgJiYgKCZVc2VyLU5hbWUgIX4gL0AoLispXC4oLispJC8pKSAg ew0KKDQpICAgICAgICAgaWYgKCgmVXNlci1OYW1lID1+IC9ALykgJiYgKCZVc2VyLU5hbWUgIX4g L0AoLispXC4oLispJC8pKSAgIC0+IEZBTFNFDQooNCkgICAgICAgICBpZiAoJlVzZXItTmFtZSA9 fiAvXC4kLykgIHsNCig0KSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9cLiQvKSAgIC0+IEZB TFNFDQooNCkgICAgICAgICBpZiAoJlVzZXItTmFtZSA9fiAvQFwuLykgIHsNCig0KSAgICAgICAg IGlmICgmVXNlci1OYW1lID1+IC9AXC4vKSAgIC0+IEZBTFNFDQooNCkgICAgICAgfSAjIGlmICgm VXNlci1OYW1lKSAgPSBub3Rmb3VuZA0KKDQpICAgICB9ICMgcG9saWN5IGZpbHRlcl91c2VybmFt ZSA9IG5vdGZvdW5kDQooNCkgICAgIFtwcmVwcm9jZXNzXSA9IG9rDQooNCkgICAgIFtjaGFwXSA9 IG5vb3ANCig0KSAgICAgW21zY2hhcF0gPSBub29wDQooNCkgICAgIFtkaWdlc3RdID0gbm9vcA0K KDQpIHN1ZmZpeDogQ2hlY2tpbmcgZm9yIHN1ZmZpeCBhZnRlciAiQCINCig0KSBzdWZmaXg6IExv b2tpbmcgdXAgcmVhbG0gIm15LW9yZy5jb20iIGZvciBVc2VyLU5hbWUgPSAiYWxpY2VAbXktb3Jn LmNvbSINCig0KSBzdWZmaXg6IEZvdW5kIHJlYWxtICJteS1vcmcuY29tIg0KKDQpIHN1ZmZpeDog QWRkaW5nIFN0cmlwcGVkLVVzZXItTmFtZSA9ICJhbGljZSINCig0KSBzdWZmaXg6IEFkZGluZyBS ZWFsbSA9ICJteS1vcmcuY29tIg0KKDQpIHN1ZmZpeDogQXV0aGVudGljYXRpb24gcmVhbG0gaXMg TE9DQUwNCig0KSAgICAgW3N1ZmZpeF0gPSBvaw0KKDQpICAgICBpZiAoIHJlcXVlc3Q6UmVhbG0g PT0gIk5VTEwiICl7DQooNCkgICAgIGlmICggcmVxdWVzdDpSZWFsbSA9PSAiTlVMTCIgKSAtPiBG QUxTRQ0KKDQpIGVhcDogTm8gRUFQLU1lc3NhZ2UsIG5vdCBkb2luZyBFQVANCig0KSAgICAgW2Vh cF0gPSBub29wDQooNCkgICAgIFt1bml4XSA9IG5vdGZvdW5kDQooNCkgZmlsZXM6IHVzZXJzOiBN YXRjaGVkIGVudHJ5IGFsaWNlIGF0IGxpbmUgMQ0KKDQpICAgICBbZmlsZXNdID0gb2sNCig0KSAg ICAgW2V4cGlyYXRpb25dID0gbm9vcA0KKDQpICAgICBbbG9naW50aW1lXSA9IG5vb3ANCig0KSAg ICAgW3BhcF0gPSB1cGRhdGVkDQooNCkgICB9ICMgYXV0aG9yaXplID0gdXBkYXRlZA0KKDQpIEZv dW5kIEF1dGgtVHlwZSA9IFBBUA0KKDQpICMgRXhlY3V0aW5nIGdyb3VwIGZyb20gZmlsZSAvdXNy L2xvY2FsL2V0Yy9yYWRkYi9zaXRlcy1lbmFibGVkL2RlZmF1bHQNCig0KSAgIEF1dGgtVHlwZSBQ QVAgew0KKDQpIHBhcDogTG9naW4gYXR0ZW1wdCB3aXRoIHBhc3N3b3JkDQooNCkgcGFwOiBDb21w YXJpbmcgd2l0aCAia25vd24gZ29vZCIgQ2xlYXJ0ZXh0LVBhc3N3b3JkDQooNCkgcGFwOiBVc2Vy IGF1dGhlbnRpY2F0ZWQgc3VjY2Vzc2Z1bGx5DQooNCkgICAgIFtwYXBdID0gb2sNCig0KSAgIH0g IyBBdXRoLVR5cGUgUEFQID0gb2sNCig0KSAjIEV4ZWN1dGluZyBzZWN0aW9uIHBvc3QtYXV0aCBm cm9tIGZpbGUgL3Vzci9sb2NhbC9ldGMvcmFkZGIvc2l0ZXMtZW5hYmxlZC9kZWZhdWx0DQooNCkg ICBwb3N0LWF1dGggew0KKDQpICAgICB1cGRhdGUgew0KKDQpICAgICAgIE5vIGF0dHJpYnV0ZXMg dXBkYXRlZA0KKDQpICAgICB9ICMgdXBkYXRlID0gbm9vcA0KKDQpICAgICBbZXhlY10gPSBub29w DQooNCkgICAgIHBvbGljeSByZW1vdmVfcmVwbHlfbWVzc2FnZV9pZl9lYXAgew0KKDQpICAgICAg IGlmICgmcmVwbHk6RUFQLU1lc3NhZ2UgJiYgJnJlcGx5OlJlcGx5LU1lc3NhZ2UpIHsNCig0KSAg ICAgICBpZiAoJnJlcGx5OkVBUC1NZXNzYWdlICYmICZyZXBseTpSZXBseS1NZXNzYWdlKSAgLT4g RkFMU0UNCig0KSAgICAgICBlbHNlIHsNCig0KSAgICAgICAgIFtub29wXSA9IG5vb3ANCig0KSAg ICAgICB9ICMgZWxzZSA9IG5vb3ANCig0KSAgICAgfSAjIHBvbGljeSByZW1vdmVfcmVwbHlfbWVz c2FnZV9pZl9lYXAgPSBub29wDQooNCkgICB9ICMgcG9zdC1hdXRoID0gbm9vcA0KKDQpIFNlbnQg QWNjZXNzLUFjY2VwdCBJZCAyNTcgZnJvbSBbOjoxXToxODEyIHRvIFs6OjFdOjMzMjk2IGxlbmd0 aCAwDQooNCkgICBUdW5uZWwtVHlwZSA9IFZMQU4NCig0KSAgIFR1bm5lbC1NZWRpdW0tVHlwZSA9 IElFRUUtODAyDQooNCkgICBUdW5uZWwtUHJpdmF0ZS1Hcm91cC1JZCA9ICIxMDAiDQooNCkgRmlu aXNoZWQgcmVxdWVzdA0KV2FraW5nIHVwIGluIDQuOSBzZWNvbmRzLg0KKDQpIENsZWFuaW5nIHVw IHJlcXVlc3QgcGFja2V0IElEIDI1NyB3aXRoIHRpbWVzdGFtcCArNDUzDQpSZWFkeSB0byBwcm9j ZXNzIHJlcXVlc3RzDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogKDgpIEF1dGggdXNpbmcgSVB2NiB0byBw cm94eSBzZXJ2ZXIsIGFuZCBJUHY0IGJldHdlZW4gcHJveHkgYW5kIGhvbWUtc2VydmVyDQogICAg ICdyYWR0ZXN0IC02IC1JIGJvYkB5b3VyLW9yZy5jb20gcGFzc2JvYiBbOjoxXSAxMDAgdGVzdGlu ZzEyMycNCiAgICAgTm90ZTogSVB2NiBmcm9tIGNsaWVudCB0byBwcm94eSwgSVB2NCBmcm9tIHBy b3h5IHRvIGhvbWUtc2VydmVyLA0KICAgICAgICAgICBib3RoIHVzaW5nIGV4dC1JRA0KICAgICBP dXRwdXQgb2YgY2xpZW50IGFuZCBzZXJ2ZXIgYmVsb3c6DQoNCiBjbGllbnQ6DQoNCmxlbm92bzp+ L3JhZGl1cy9mci0zLjAuMTIkIHJhZHRlc3QgLTYgLUkgYm9iQHlvdXItb3JnLmNvbSBwYXNzYm9i IFs6OjFdIDEwMCB0ZXN0aW5nMTIzDQpTZW50IEFjY2Vzcy1SZXF1ZXN0IElkIDI1NyBmcm9tIFs6 Ol06NDc2MDIgdG8gWzo6MV06MTgxMiBsZW5ndGggMTA0DQoJVXNlci1OYW1lID0gImJvYkB5b3Vy LW9yZy5jb20iDQoJVXNlci1QYXNzd29yZCA9ICJwYXNzYm9iIg0KCU5BUy1JUHY2LUFkZHJlc3Mg PSA6OjENCglOQVMtUG9ydCA9IDEwMA0KCU1lc3NhZ2UtQXV0aGVudGljYXRvciA9IDB4MDANCglD bGVhcnRleHQtUGFzc3dvcmQgPSAicGFzc2JvYiINClJlY2VpdmVkIEFjY2Vzcy1BY2NlcHQgSWQg MjU3IGZyb20gWzo6MV06MTgxMiB0byBbOjpdOjAgbGVuZ3RoIDQyDQoJRVhURU5ERUQtSUQgPSAw eDAwMDAwMjAxDQoJVHVubmVsLVR5cGU6MCA9IFZMQU4NCglUdW5uZWwtTWVkaXVtLVR5cGU6MCA9 IElFRUUtODAyDQoJVHVubmVsLVByaXZhdGUtR3JvdXAtSWQ6MCA9ICI1NSINCmxlbm92bzp+L3Jh ZGl1cy9mci0zLjAuMTIkIA0KDQogcHJveHktc2VydmVyOg0KDQpSZWFkeSB0byBwcm9jZXNzIHJl cXVlc3RzDQoNCg0KKDUpIFJlY2VpdmVkIEFjY2Vzcy1SZXF1ZXN0IElkIDI1NyBmcm9tIFs6OjFd OjQ3NjAyIHRvIFs6OjFdOjE4MTIgbGVuZ3RoIDEwNA0KKDUpICAgRVhURU5ERUQtSUQgPSAweDAw MDAwMjAxDQooNSkgICBVc2VyLU5hbWUgPSAiYm9iQHlvdXItb3JnLmNvbSINCig1KSAgIFVzZXIt UGFzc3dvcmQgPSAicGFzc2JvYiINCig1KSAgIE5BUy1JUHY2LUFkZHJlc3MgPSA6OjENCig1KSAg IE5BUy1Qb3J0ID0gMTAwDQooNSkgICBNZXNzYWdlLUF1dGhlbnRpY2F0b3IgPSAweDVhNGMwYzQy NGI3ZTFiYjE1YzlmNjZmMTYwZDI5ZTg3DQooNSkgIyBFeGVjdXRpbmcgc2VjdGlvbiBhdXRob3Jp emUgZnJvbSBmaWxlIC91c3IvbG9jYWwvZXRjL3JhZGRiL3NpdGVzLWVuYWJsZWQvZGVmYXVsdA0K KDUpICAgYXV0aG9yaXplIHsNCig1KSAgICAgcG9saWN5IGZpbHRlcl91c2VybmFtZSB7DQooNSkg ICAgICAgaWYgKCZVc2VyLU5hbWUpIHsNCig1KSAgICAgICBpZiAoJlVzZXItTmFtZSkgIC0+IFRS VUUNCig1KSAgICAgICBpZiAoJlVzZXItTmFtZSkgIHsNCig1KSAgICAgICAgIGlmICgmVXNlci1O YW1lID1+IC8gLykgew0KKDUpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gLyAvKSAgLT4gRkFM U0UNCig1KSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9AW15AXSpALyApIHsNCig1KSAgICAg ICAgIGlmICgmVXNlci1OYW1lID1+IC9AW15AXSpALyApICAtPiBGQUxTRQ0KKDUpICAgICAgICAg aWYgKCZVc2VyLU5hbWUgPX4gL1wuXC4vICkgew0KKDUpICAgICAgICAgaWYgKCZVc2VyLU5hbWUg PX4gL1wuXC4vICkgIC0+IEZBTFNFDQooNSkgICAgICAgICBpZiAoKCZVc2VyLU5hbWUgPX4gL0Av KSAmJiAoJlVzZXItTmFtZSAhfiAvQCguKylcLiguKykkLykpICB7DQooNSkgICAgICAgICBpZiAo KCZVc2VyLU5hbWUgPX4gL0AvKSAmJiAoJlVzZXItTmFtZSAhfiAvQCguKylcLiguKykkLykpICAg LT4gRkFMU0UNCig1KSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9cLiQvKSAgew0KKDUpICAg ICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL1wuJC8pICAgLT4gRkFMU0UNCig1KSAgICAgICAgIGlm ICgmVXNlci1OYW1lID1+IC9AXC4vKSAgew0KKDUpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4g L0BcLi8pICAgLT4gRkFMU0UNCig1KSAgICAgICB9ICMgaWYgKCZVc2VyLU5hbWUpICA9IG5vdGZv dW5kDQooNSkgICAgIH0gIyBwb2xpY3kgZmlsdGVyX3VzZXJuYW1lID0gbm90Zm91bmQNCig1KSAg ICAgW3ByZXByb2Nlc3NdID0gb2sNCig1KSAgICAgW2NoYXBdID0gbm9vcA0KKDUpICAgICBbbXNj aGFwXSA9IG5vb3ANCig1KSAgICAgW2RpZ2VzdF0gPSBub29wDQooNSkgc3VmZml4OiBDaGVja2lu ZyBmb3Igc3VmZml4IGFmdGVyICJAIg0KKDUpIHN1ZmZpeDogTG9va2luZyB1cCByZWFsbSAieW91 ci1vcmcuY29tIiBmb3IgVXNlci1OYW1lID0gImJvYkB5b3VyLW9yZy5jb20iDQooNSkgc3VmZml4 OiBGb3VuZCByZWFsbSAieW91ci1vcmcuY29tIg0KKDUpIHN1ZmZpeDogQWRkaW5nIFJlYWxtID0g InlvdXItb3JnLmNvbSINCig1KSBzdWZmaXg6IFByb3h5aW5nIHJlcXVlc3QgZnJvbSB1c2VyIGJv YkB5b3VyLW9yZy5jb20gdG8gcmVhbG0geW91ci1vcmcuY29tDQooNSkgc3VmZml4OiBQcmVwYXJp bmcgdG8gcHJveHkgYXV0aGVudGljYXRpb24gcmVxdWVzdCB0byByZWFsbSAieW91ci1vcmcuY29t IiANCig1KSAgICAgW3N1ZmZpeF0gPSB1cGRhdGVkDQooNSkgICAgIGlmICggcmVxdWVzdDpSZWFs bSA9PSAiTlVMTCIgKXsNCig1KSAgICAgaWYgKCByZXF1ZXN0OlJlYWxtID09ICJOVUxMIiApIC0+ IEZBTFNFDQooNSkgZWFwOiBObyBFQVAtTWVzc2FnZSwgbm90IGRvaW5nIEVBUA0KKDUpICAgICBb ZWFwXSA9IG5vb3ANCig1KSAgICAgW3VuaXhdID0gbm90Zm91bmQNCig1KSAgICAgW2ZpbGVzXSA9 IG5vb3ANCig1KSAgICAgW2V4cGlyYXRpb25dID0gbm9vcA0KKDUpICAgICBbbG9naW50aW1lXSA9 IG5vb3ANCig1KSAgICAgW3BhcF0gPSBub29wDQooNSkgICB9ICMgYXV0aG9yaXplID0gdXBkYXRl ZA0KKDUpIFN0YXJ0aW5nIHByb3h5IHRvIGhvbWUgc2VydmVyIDE5Mi4xNjguMS4xMDAgcG9ydCAx ODEyDQooNSkgUHJveHlpbmcgcmVxdWVzdCB0byBob21lIHNlcnZlciAxOTIuMTY4LjEuMTAwIHBv cnQgMTgxMiB0aW1lb3V0IDMwLjAwMDAwMA0KKDUpIFNlbnQgQWNjZXNzLVJlcXVlc3QgSWQgMjMw IGZyb20gMC4wLjAuMDo0Nzc5MiB0byAxOTIuMTY4LjEuMTAwOjE4MTIgbGVuZ3RoIDExNQ0KKDUp ICAgRVhURU5ERUQtSUQgPSAweDAwMDAwMjAxDQooNSkgICBVc2VyLU5hbWUgPSAiYm9iQHlvdXIt b3JnLmNvbSINCig1KSAgIFVzZXItUGFzc3dvcmQgPSAicGFzc2JvYiINCig1KSAgIE5BUy1JUHY2 LUFkZHJlc3MgPSA6OjENCig1KSAgIE5BUy1Qb3J0ID0gMTAwDQooNSkgICBNZXNzYWdlLUF1dGhl bnRpY2F0b3IgPSAweDVhNGMwYzQyNGI3ZTFiYjE1YzlmNjZmMTYwZDI5ZTg3DQooNSkgICBFdmVu dC1UaW1lc3RhbXAgPSAiQXByIDI2IDIwMTcgMTU6MzI6MDAgUERUIg0KKDUpICAgUHJveHktU3Rh dGUgPSAweDM1MzEzMw0KV2FraW5nIHVwIGluIDAuMyBzZWNvbmRzLg0KKDUpIENsZWFyaW5nIGV4 aXN0aW5nICZyZXBseTogYXR0cmlidXRlcw0KKDUpIFJlY2VpdmVkIEFjY2Vzcy1BY2NlcHQgSWQg MjMwIGZyb20gMTkyLjE2OC4xLjEwMDoxODEyIHRvIDE5Mi4xNjguMS4zNTo0Nzc5MiBsZW5ndGgg NDcNCig1KSAgIEVYVEVOREVELUlEID0gMHgwMDAwMDIwNA0KKDUpICAgVHVubmVsLVR5cGU6MCA9 IFZMQU4NCig1KSAgIFR1bm5lbC1NZWRpdW0tVHlwZTowID0gSUVFRS04MDINCig1KSAgIFR1bm5l bC1Qcml2YXRlLUdyb3VwLUlkOjAgPSAiNTUiDQooNSkgICBQcm94eS1TdGF0ZSA9IDB4MzUzMTMz DQooNSkgIyBFeGVjdXRpbmcgc2VjdGlvbiBwb3N0LXByb3h5IGZyb20gZmlsZSAvdXNyL2xvY2Fs L2V0Yy9yYWRkYi9zaXRlcy1lbmFibGVkL2RlZmF1bHQNCig1KSAgIHBvc3QtcHJveHkgew0KKDUp IGVhcDogTm8gcHJlLWV4aXN0aW5nIGhhbmRsZXIgZm91bmQNCig1KSAgICAgW2VhcF0gPSBub29w DQooNSkgICB9ICMgcG9zdC1wcm94eSA9IG5vb3ANCig1KSBGb3VuZCBBdXRoLVR5cGUgPSBBY2Nl cHQNCig1KSBBdXRoLVR5cGUgPSBBY2NlcHQsIGFjY2VwdGluZyB0aGUgdXNlcg0KKDUpICMgRXhl Y3V0aW5nIHNlY3Rpb24gcG9zdC1hdXRoIGZyb20gZmlsZSAvdXNyL2xvY2FsL2V0Yy9yYWRkYi9z aXRlcy1lbmFibGVkL2RlZmF1bHQNCig1KSAgIHBvc3QtYXV0aCB7DQooNSkgICAgIHVwZGF0ZSB7 DQooNSkgICAgICAgTm8gYXR0cmlidXRlcyB1cGRhdGVkDQooNSkgICAgIH0gIyB1cGRhdGUgPSBu b29wDQooNSkgICAgIFtleGVjXSA9IG5vb3ANCig1KSAgICAgcG9saWN5IHJlbW92ZV9yZXBseV9t ZXNzYWdlX2lmX2VhcCB7DQooNSkgICAgICAgaWYgKCZyZXBseTpFQVAtTWVzc2FnZSAmJiAmcmVw bHk6UmVwbHktTWVzc2FnZSkgew0KKDUpICAgICAgIGlmICgmcmVwbHk6RUFQLU1lc3NhZ2UgJiYg JnJlcGx5OlJlcGx5LU1lc3NhZ2UpICAtPiBGQUxTRQ0KKDUpICAgICAgIGVsc2Ugew0KKDUpICAg ICAgICAgW25vb3BdID0gbm9vcA0KKDUpICAgICAgIH0gIyBlbHNlID0gbm9vcA0KKDUpICAgICB9 ICMgcG9saWN5IHJlbW92ZV9yZXBseV9tZXNzYWdlX2lmX2VhcCA9IG5vb3ANCig1KSAgIH0gIyBw b3N0LWF1dGggPSBub29wDQooNSkgU2VudCBBY2Nlc3MtQWNjZXB0IElkIDI1NyBmcm9tIFs6OjFd OjE4MTIgdG8gWzo6MV06NDc2MDIgbGVuZ3RoIDANCig1KSAgIEVYVEVOREVELUlEID0gMHgwMDAw MDIwNA0KKDUpICAgVHVubmVsLVR5cGU6MCA9IFZMQU4NCig1KSAgIFR1bm5lbC1NZWRpdW0tVHlw ZTowID0gSUVFRS04MDINCig1KSAgIFR1bm5lbC1Qcml2YXRlLUdyb3VwLUlkOjAgPSAiNTUiDQoo NSkgRmluaXNoZWQgcmVxdWVzdA0KV2FraW5nIHVwIGluIDQuOSBzZWNvbmRzLg0KKDUpIENsZWFu aW5nIHVwIHJlcXVlc3QgcGFja2V0IElEIDI1NyB3aXRoIHRpbWVzdGFtcCArNTk5DQpSZWFkeSB0 byBwcm9jZXNzIHJlcXVlc3RzDQoNCg0KIGhvbWUtc2VydmVyOg0KDQpSZWFkeSB0byBwcm9jZXNz IHJlcXVlc3RzDQoNCg0KDQooNCkgUmVjZWl2ZWQgQWNjZXNzLVJlcXVlc3QgSWQgMjMwIGZyb20g MTkyLjE2OC4xLjM1OjQ3NzkyIHRvIDE5Mi4xNjguMS4xMDA6MTgxMiBsZW5ndGggMTE1DQooNCkg ICBFWFRFTkRFRC1JRCA9IDB4MDAwMDAyMDQNCig0KSAgIFVzZXItTmFtZSA9ICJib2JAeW91ci1v cmcuY29tIg0KKDQpICAgVXNlci1QYXNzd29yZCA9ICJwYXNzYm9iIg0KKDQpICAgTkFTLUlQdjYt QWRkcmVzcyA9IDo6MQ0KKDQpICAgTkFTLVBvcnQgPSAxMDANCig0KSAgIE1lc3NhZ2UtQXV0aGVu dGljYXRvciA9IDB4NzI4ZTRmYzgwNGE2OTdhYjY1NjVhNmY0MTUxMTU5ODgNCig0KSAgIEV2ZW50 LVRpbWVzdGFtcCA9ICJBcHIgMjYgMjAxNyAxNTozMjowMCBQRFQiDQooNCkgICBQcm94eS1TdGF0 ZSA9IDB4MzUzMTMzDQooNCkgIyBFeGVjdXRpbmcgc2VjdGlvbiBhdXRob3JpemUgZnJvbSBmaWxl IC91c3IvbG9jYWwvZXRjL3JhZGRiL3NpdGVzLWVuYWJsZWQvZGVmYXVsdA0KKDQpICAgYXV0aG9y aXplIHsNCig0KSAgICAgcG9saWN5IGZpbHRlcl91c2VybmFtZSB7DQooNCkgICAgICAgaWYgKCZV c2VyLU5hbWUpIHsNCig0KSAgICAgICBpZiAoJlVzZXItTmFtZSkgIC0+IFRSVUUNCig0KSAgICAg ICBpZiAoJlVzZXItTmFtZSkgIHsNCig0KSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC8gLykg ew0KKDQpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gLyAvKSAgLT4gRkFMU0UNCig0KSAgICAg ICAgIGlmICgmVXNlci1OYW1lID1+IC9AW15AXSpALyApIHsNCig0KSAgICAgICAgIGlmICgmVXNl ci1OYW1lID1+IC9AW15AXSpALyApICAtPiBGQUxTRQ0KKDQpICAgICAgICAgaWYgKCZVc2VyLU5h bWUgPX4gL1wuXC4vICkgew0KKDQpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL1wuXC4vICkg IC0+IEZBTFNFDQooNCkgICAgICAgICBpZiAoKCZVc2VyLU5hbWUgPX4gL0AvKSAmJiAoJlVzZXIt TmFtZSAhfiAvQCguKylcLiguKykkLykpICB7DQooNCkgICAgICAgICBpZiAoKCZVc2VyLU5hbWUg PX4gL0AvKSAmJiAoJlVzZXItTmFtZSAhfiAvQCguKylcLiguKykkLykpICAgLT4gRkFMU0UNCig0 KSAgICAgICAgIGlmICgmVXNlci1OYW1lID1+IC9cLiQvKSAgew0KKDQpICAgICAgICAgaWYgKCZV c2VyLU5hbWUgPX4gL1wuJC8pICAgLT4gRkFMU0UNCig0KSAgICAgICAgIGlmICgmVXNlci1OYW1l ID1+IC9AXC4vKSAgew0KKDQpICAgICAgICAgaWYgKCZVc2VyLU5hbWUgPX4gL0BcLi8pICAgLT4g RkFMU0UNCig0KSAgICAgICB9ICMgaWYgKCZVc2VyLU5hbWUpICA9IG5vdGZvdW5kDQooNCkgICAg IH0gIyBwb2xpY3kgZmlsdGVyX3VzZXJuYW1lID0gbm90Zm91bmQNCig0KSAgICAgW3ByZXByb2Nl c3NdID0gb2sNCig0KSAgICAgW2NoYXBdID0gbm9vcA0KKDQpICAgICBbbXNjaGFwXSA9IG5vb3AN Cig0KSAgICAgW2RpZ2VzdF0gPSBub29wDQooNCkgc3VmZml4OiBDaGVja2luZyBmb3Igc3VmZml4 IGFmdGVyICJAIg0KKDQpIHN1ZmZpeDogTG9va2luZyB1cCByZWFsbSAieW91ci1vcmcuY29tIiBm b3IgVXNlci1OYW1lID0gImJvYkB5b3VyLW9yZy5jb20iDQooNCkgc3VmZml4OiBGb3VuZCByZWFs bSAieW91ci1vcmcuY29tIg0KKDQpIHN1ZmZpeDogQWRkaW5nIFN0cmlwcGVkLVVzZXItTmFtZSA9 ICJib2IiDQooNCkgc3VmZml4OiBBZGRpbmcgUmVhbG0gPSAieW91ci1vcmcuY29tIg0KKDQpIHN1 ZmZpeDogQXV0aGVudGljYXRpb24gcmVhbG0gaXMgTE9DQUwNCig0KSAgICAgW3N1ZmZpeF0gPSBv aw0KKDQpIGVhcDogTm8gRUFQLU1lc3NhZ2UsIG5vdCBkb2luZyBFQVANCig0KSAgICAgW2VhcF0g PSBub29wDQooNCkgZmlsZXM6IHVzZXJzOiBNYXRjaGVkIGVudHJ5IGJvYiBhdCBsaW5lIDENCig0 KSAgICAgW2ZpbGVzXSA9IG9rDQooNCkgICAgIFtleHBpcmF0aW9uXSA9IG5vb3ANCig0KSAgICAg W2xvZ2ludGltZV0gPSBub29wDQooNCkgICAgIFtwYXBdID0gdXBkYXRlZA0KKDQpICAgfSAjIGF1 dGhvcml6ZSA9IHVwZGF0ZWQNCig0KSBGb3VuZCBBdXRoLVR5cGUgPSBQQVANCig0KSAjIEV4ZWN1 dGluZyBncm91cCBmcm9tIGZpbGUgL3Vzci9sb2NhbC9ldGMvcmFkZGIvc2l0ZXMtZW5hYmxlZC9k ZWZhdWx0DQooNCkgICBBdXRoLVR5cGUgUEFQIHsNCig0KSBwYXA6IExvZ2luIGF0dGVtcHQgd2l0 aCBwYXNzd29yZA0KKDQpIHBhcDogQ29tcGFyaW5nIHdpdGggImtub3duIGdvb2QiIENsZWFydGV4 dC1QYXNzd29yZA0KKDQpIHBhcDogVXNlciBhdXRoZW50aWNhdGVkIHN1Y2Nlc3NmdWxseQ0KKDQp ICAgICBbcGFwXSA9IG9rDQooNCkgICB9ICMgQXV0aC1UeXBlIFBBUCA9IG9rDQooNCkgIyBFeGVj dXRpbmcgc2VjdGlvbiBwb3N0LWF1dGggZnJvbSBmaWxlIC91c3IvbG9jYWwvZXRjL3JhZGRiL3Np dGVzLWVuYWJsZWQvZGVmYXVsdA0KKDQpICAgcG9zdC1hdXRoIHsNCig0KSAgICAgdXBkYXRlIHsN Cig0KSAgICAgICBObyBhdHRyaWJ1dGVzIHVwZGF0ZWQNCig0KSAgICAgfSAjIHVwZGF0ZSA9IG5v b3ANCig0KSAgICAgW2V4ZWNdID0gbm9vcA0KKDQpICAgICBwb2xpY3kgcmVtb3ZlX3JlcGx5X21l c3NhZ2VfaWZfZWFwIHsNCig0KSAgICAgICBpZiAoJnJlcGx5OkVBUC1NZXNzYWdlICYmICZyZXBs eTpSZXBseS1NZXNzYWdlKSB7DQooNCkgICAgICAgaWYgKCZyZXBseTpFQVAtTWVzc2FnZSAmJiAm cmVwbHk6UmVwbHktTWVzc2FnZSkgIC0+IEZBTFNFDQooNCkgICAgICAgZWxzZSB7DQooNCkgICAg ICAgICBbbm9vcF0gPSBub29wDQooNCkgICAgICAgfSAjIGVsc2UgPSBub29wDQooNCkgICAgIH0g IyBwb2xpY3kgcmVtb3ZlX3JlcGx5X21lc3NhZ2VfaWZfZWFwID0gbm9vcA0KKDQpICAgfSAjIHBv c3QtYXV0aCA9IG5vb3ANCig0KSBTZW50IEFjY2Vzcy1BY2NlcHQgSWQgMjMwIGZyb20gMTkyLjE2 OC4xLjEwMDoxODEyIHRvIDE5Mi4xNjguMS4zNTo0Nzc5MiBsZW5ndGggMA0KKDQpICAgVHVubmVs LVR5cGUgPSBWTEFODQooNCkgICBUdW5uZWwtTWVkaXVtLVR5cGUgPSBJRUVFLTgwMg0KKDQpICAg VHVubmVsLVByaXZhdGUtR3JvdXAtSWQgPSAiNTUiDQooNCkgICBQcm94eS1TdGF0ZSA9IDB4MzUz MTMzDQooNCkgRmluaXNoZWQgcmVxdWVzdA0KV2FraW5nIHVwIGluIDQuOSBzZWNvbmRzLg0KKDQp IENsZWFuaW5nIHVwIHJlcXVlc3QgcGFja2V0IElEIDIzMCB3aXRoIHRpbWVzdGFtcCArNjAzDQpS ZWFkeSB0byBwcm9jZXNzIHJlcXVlc3RzDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo= --_004_4FF203996C6D469C85F0E1161C1BDEFDciscocom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=2490; creation-date="Fri, 28 Apr 2017 00:24:51 GMT"; modification-date="Fri, 28 Apr 2017 00:24:51 GMT" Content-ID: <9894F48BFBE90C4CBFACB77F29375142@emea.cisco.com> Content-Transfer-Encoding: base64 DQoNCj4gT24gQXByIDI1LCAyMDE3LCBhdCAxMDoyNCBBTSwgRW5rZSBDaGVuIChlbmtlY2hlbikg PGVua2VjaGVuQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwgRm9sa3M6DQo+IA0KPiBUaGlz IHJldmlzZWQgdmVyc2lvbiBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIGNoYW5nZXM6DQo+IA0KPiAg IG8gUmVuYW1lZCB0aGUgYXR0cmlidXRlIGFzICJFeHRlbmRlZCBJZGVudGlmaWVyIEF0dHJpYnV0 ZSIuDQo+IA0KPiAgIG8gUmVtb3ZlZCB0aGUgc3BlY2lmaWNhdGlvbiBmb3IgdGhlIG9wdGlvbmFs ICJFeHRlbmRlZCBDb2RlIiBhcyBBbGFuDQo+ICAgICBzdWdnZXN0ZWQuDQo+IA0KPiAgIG8gUmVs YXhlZCB0aGUgdXNlIG9mIHRoZSB0d28gcGFyYW1ldGVycyAiSWRlbnRpZmllciIgYW5kICJFeHRl bmRlZA0KPiAgICAgSWRlbnRpZmllciIsIGZyb20gIk9SIiB0byAiQU5EIiBmb3IgbW9yZSBmbGV4 aWJsZSBpbXBsZW1lbnRhdGlvbi4NCj4gDQo+IEZpbmFsbHksICJubyBJRCBjaGFuZ2VzIiBhY2Nv cmRpbmcgdG8gQWxhbidzIGRlZmluaXRpb24gOi0pDQo+IA0KPiBSZWdhcmRzLCAgLS0gRW5rZQ0K PiANCj4gLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NCj4gU3ViamVjdDogSS1E IEFjdGlvbjogZHJhZnQtY2hlbi1yYWRleHQtaWRlbnRpZmllci1hdHRyLTAxLnR4dA0KPiBEYXRl OiBUdWUsIDI1IEFwciAyMDE3IDEwOjExOjE5IC0wNzAwDQo+IEZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZw0KPiBSZXBseS1UbzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+IFRvOiBp LWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ IA0KPiANCj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IFJBRElVUyBFeHRlbmRlZCBJZGVudGlm aWVyIEF0dHJpYnV0ZQ0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogRW5rZSBDaGVuDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICBOYWltaW5nIFNoZW4NCj4gCUZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWNoZW4tcmFkZXh0LWlkZW50aWZpZXItYXR0ci0wMS50eHQNCj4gCVBhZ2VzICAgICAg ICAgICA6IDcNCj4gCURhdGUgICAgICAgICAgICA6IDIwMTctMDQtMjUNCj4gDQo+IEFic3RyYWN0 Og0KPiAgIFRoZSBsaW1pdGF0aW9uIHdpdGggdGhlIG9uZS1vY3RldCAiSWRlbnRpZmllciIgZmll bGQgaW4gdGhlIFJBRElVUw0KPiAgIHBhY2tldCBpcyB3ZWxsIGtub3duLiBJbiB0aGlzIGRvY3Vt ZW50IHdlIHByb3Bvc2UgZXh0ZW5zaW9ucyB0byB0aGUNCj4gICBSQURJVVMgcHJvdG9jb2wgdG8g YWRkcmVzcyB0aGlzIGZ1bmRhbWVudGFsIGxpbWl0YXRpb24sIGFuZCB0aHVzDQo+ICAgYWxsb3dp bmcgZm9yIG1vcmUgZWZmaWNpZW50IGFuZCBtb3JlIHNjYWxhYmxlIGltcGxlbWVudGF0aW9ucy4N Cj4gDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg ZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNoZW4t cmFkZXh0LWlkZW50aWZpZXItYXR0ci8NCj4gDQo+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZl cnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWNoZW4tcmFkZXh0LWlkZW50aWZpZXItYXR0ci0wMQ0KPiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWNoZW4tcmFkZXh0LWlkZW50aWZpZXItYXR0ci0wMQ0KPiAN Cj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtY2hlbi1yYWRleHQtaWRlbnRp Zmllci1hdHRyLTAxDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMg RlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSS1ELUFubm91 bmNlIG1haWxpbmcgbGlzdA0KPiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4gSW50ZXJuZXQtRHJhZnQg ZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4gb3IgZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCg0K --_004_4FF203996C6D469C85F0E1161C1BDEFDciscocom_-- From nobody Fri Apr 28 07:03:55 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8E0129C48 for ; Fri, 28 Apr 2017 07:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVCD0hqCMNom for ; Fri, 28 Apr 2017 07:03:51 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8F06812949A for ; Fri, 28 Apr 2017 06:59:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id F12021976 for ; Fri, 28 Apr 2017 13:59:56 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayl9l-PBPFNP for ; Fri, 28 Apr 2017 13:59:56 +0000 (UTC) Received: from [192.168.20.102] (CPEf4cc552207f0-CM00fc8dce0fa0.cpe.net.cable.rogers.com [99.230.129.191]) by mail.networkradius.com (Postfix) with ESMTPSA id 91D15107 for ; Fri, 28 Apr 2017 13:59:56 +0000 (UTC) From: Alan DeKok X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_31136752-2511-417D-B616-4064084CD5A2"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Fri, 28 Apr 2017 09:59:55 -0400 References: <149338794340.2889.11704995078164156454.idtracker@ietfa.amsl.com> To: radext@ietf.org Message-Id: <19014447-FC9F-450F-8365-78068699A4B9@freeradius.org> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [radext] Fwd: New Version Notification for draft-dekok-radext-request-authenticator-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 14:03:54 -0000 --Apple-Mail=_31136752-2511-417D-B616-4064084CD5A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I've added more text describing how it works, requirements, = limitations, caveats, etc. I think I'll leave it here for a while. We can see at the next = in-person meeting whether sticks and stones are warranted. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-dekok-radext-request-authenticator-01.txt > Date: April 28, 2017 at 9:59:03 AM EDT > To: "Alan DeKok" >=20 >=20 > A new version of I-D, draft-dekok-radext-request-authenticator-01.txt > has been successfully submitted by Alan DeKok and posted to the > IETF repository. >=20 > Name: draft-dekok-radext-request-authenticator > Revision: 01 > Title: Correlating requests and replies in the Remote = Authentication Dial In User Service (RADIUS) Protocol via the Request = Authenticator. > Document date: 2017-04-28 > Group: Individual Submission > Pages: 17 > URL: = https://www.ietf.org/internet-drafts/draft-dekok-radext-request-authentica= tor-01.txt > Status: = https://datatracker.ietf.org/doc/draft-dekok-radext-request-authenticator/= > Htmlized: = https://tools.ietf.org/html/draft-dekok-radext-request-authenticator-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-dekok-radext-request-authentic= ator-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-dekok-radext-request-authenticat= or-01 >=20 > Abstract: > RADIUS contains a one-octet Identifier field which is used to > correlate requests and replies. This field limits the number of > outstanding requests to 256. Experience shows that this limitation > is problematic for high load systems. This document proposes to use > the Request Authenticator field as an additional unique identifier. > The replies can then be correlated to requests by copying the = Request > Authenticator from the request to a new attribute in the response, > called the Original-Request-Authenticator. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_31136752-2511-417D-B616-4064084CD5A2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZA0rbAAoJEH0Oec13Yh7NSnIH/jqK7MDso6NackkINUCRPUSX MAVbFcgdm7hmggtiil4EEdluxOKNrcdEnkmJYzAhgheg3mQGpQYo0JTmTG4rTq9L q9s92cTbIG4zq4XoiAGshIrXwinSZo9UvvohtcKcWqKmRrHBA6wQCA/8/OrQLk71 ned6FwJYZCOIUVF9pI+d90Q0bnU53Z/Nfez/W8Qzqtv7eXtsGShihadz/OYQe7+a VrQ2TFyqIHInNyEoGOGOOrMeXAU9PIDqTc2+P7DuECBBTEAYmC+P3X1k3tVjvLOP PmeJg/XLEUTE+VlgI3Ky9BUNsbzjNC1e9iNjvI8Q1RzQH2RjkJEpizg/z8NY81E= =6sBa -----END PGP SIGNATURE----- --Apple-Mail=_31136752-2511-417D-B616-4064084CD5A2--