I hope this is the right place to post such questions=

From RFC 2865 section 5.1, user-name MUST be = sent in access-request packets and MAY be sent in access-accept.

The question is, in case it is decided to include this attri= bute in the access-accept packet, does it have to be identical to the value= received in the access-request relative to the same session or can it be d= ifferent?

Any reference to where this is documente= d would be highly appreciated.

Thanks.

<= /div>

Fadi

--000000000000d599e2057a4d0a22-- From nobody Sat Nov 10 11:07:07 2018 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 C683D128CE4 for ; Sat, 10 Nov 2018 11:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEz5-z5ia7hH for ; Sat, 10 Nov 2018 11:07:05 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0A88A124408 for ; Sat, 10 Nov 2018 11:07:04 -0800 (PST) Received: from [192.168.46.58] (198-84-237-221.cpe.teksavvy.com [198.84.237.221]) by mail.networkradius.com (Postfix) with ESMTPSA id BE3DA31C; Sat, 10 Nov 2018 19:07:03 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 $3445.100.39$) From: Alan DeKok In-Reply-To: Date: Sat, 10 Nov 2018 14:07:02 -0500 Cc: radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Fadi Bushnaq X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [radext] Basic question about user-name attribute X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 19:07:07 -0000 On Nov 10, 2018, at 5:36 AM, Fadi Bushnaq wrote: >=20 > I hope this is the right place to post such questions Yes. > =46rom RFC 2865 section 5.1, user-name MUST be sent in access-request = packets and MAY be sent in access-accept. >=20 > The question is, in case it is decided to include this attribute in = the access-accept packet, does it have to be identical to the value = received in the access-request relative to the same session or can it be = different? I suspect that the intention was for the values to be identical. = Since the RFC doesn't say that, they're allowed to be different. In practice, people do send Access-Accepts where the User-Name is = different than the one in the Access-Request. > Any reference to where this is documented would be highly appreciated. If it's not in the RFCs, it's not documented anywhere. Alan DeKok. From nobody Mon Nov 12 04:20:01 2018 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 B20A0130DFC for ; Mon, 12 Nov 2018 04:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 eT3r5-0rj48D for ; Mon, 12 Nov 2018 04:19:58 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB09F130E01 for ; Mon, 12 Nov 2018 04:19:57 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 0876943968; Mon, 12 Nov 2018 13:19:56 +0100 (CET) To: Alan DeKok , Fadi Bushnaq Cc: radext@ietf.org References:

From: Stefan Winter Organization: RESTENA Message-ID: Date: Mon, 12 Nov 2018 13:19:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [radext] Basic question about user-name attribute X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 12:20:01 -0000 Hello, > I suspect that the intention was for the values to be identical. Since the RFC doesn't say that, they're allowed to be different. > > In practice, people do send Access-Accepts where the User-Name is different than the one in the Access-Request. This is especially relevant for EAP authentications. The User-Name in the request could be an identifier supporting identity privacy ("anonymous@realm", "@realm", etc.), while the actual username inside the EAP method is different from that. It sometimes happens that RADIUS administrators are rude to their users in that they send back the actual username in the Accept while the user was trying to maintain his privacy when connecting. >From what I've seen in the field, this is sometimes used in interplay with Accounting-Request: if the session that was being authenticated contains a User-Name in the Accept, that User-Name is sometimes used as the User-Name for subsequent Accounting-Requests for the same session. Nothing in the RFCs forbids either of these practices. Greetings, Stefan Winter From nobody Mon Nov 12 04:25:17 2018 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 C7551130E12; Mon, 12 Nov 2018 04:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcqZFcU91Jyd; Mon, 12 Nov 2018 04:25:14 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48FB130E0E; Mon, 12 Nov 2018 04:25:13 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 2A66343A9C; Mon, 12 Nov 2018 13:25:12 +0100 (CET) References: <0E3D879F-E131-47FE-A5E7-CC700F04A51B@tsinghua.edu.cn> To: "radext@ietf.org" Cc: draft-ietf-softwire-map-radius@ietf.org From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Autocrypt: addr=stefan.winter@restena.lu; prefer-encrypt=mutual; keydata= xsFNBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5jemiS88Gxf iDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zObFjgog01WWQV5Sihl wc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYrb7zJWPwmegTFwE093uBFvC39 waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOajl18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/ 1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnBe9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv 9ur+1kN+TNU2XE436jVpnnY/3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92 T68Od82CFxuZqPAgBCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndj pmo+lo2asmBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8CBSQQJ+cG 9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQABzTxTdGVmYW4gV2lu dGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50ZXJAcmVzdGVuYS5sdT7CwXkE EwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/ D/99hVS+mJr8dSPCaDaUFFxBiT2eI1LoR8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO 91bNZ+oZGgyoNohcBAI7p+r0qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2Z FokeUsecoRVJF/++/qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVH lWC+bymty/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22lHiSQWgP 8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2CzLYsyeKySAtYJEH FVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa9q6LwquWKS5+MXlUXe/3oZUc gpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aYn5M+iJTQSj4vzqtkQaJTpSspRZoKa66H Zt3IwSYiDiYZqtM83ynuj9kjnZzGfnuTaNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483 q/qrJwh5ES8Q9xY7aat/ZcSl8fKubW4TlfVr8c7BTQRSKZRMARAAvBPpn7FQq7LQ5glohtbL 6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHeqdon7v+SLtR4WngzMR9toupK cFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveKBHEsDn00ThTcPsvtXpnnzET16pXIvOXO 0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFT dMPUgjKuubfAeaDNCOrVt4RjmFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqC FInzIXDx7aRW2+JCiqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ 2/MOQCgUdwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqrNkxgC6pe mZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/PofAXhJW7I9mAs+H dWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR4EWFn9vvoFDAIqD10h3FSd3D 59HGtdSsNn4XaCsAEQEAAcLBXwQYAQIACQUCUimUTAIbDAAKCRDA3mo1ijncZhBtEACL036d djc5pFoYIdoUY1vT8SMXJNquewCnL1quDADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZ wUZtoa1Pgfr8nU6KOgrXPHbNjS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPV l3dUQyDa/lzc1chKUIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDS hCb+BxJv/o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIvJyUt5yYP KfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqfC2ZjIbBtZg9ylHU8 u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+od3TXFIFjszSU3NgMPKrWNhF LLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xiu4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+ 7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ +XAfN46u1Xjjv1/AkkA4IA6m5zP5og== X-Forwarded-Message-Id: <0E3D879F-E131-47FE-A5E7-CC700F04A51B@tsinghua.edu.cn> Message-ID: Date: Mon, 12 Nov 2018 13:25:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <0E3D879F-E131-47FE-A5E7-CC700F04A51B@tsinghua.edu.cn> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="P4enTRdh7bXFljFMZyuNQMHGF0yZGbVAB" Archived-At: Subject: [radext] Review request for draft-ietf-softwire-map-radius X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 12:25:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P4enTRdh7bXFljFMZyuNQMHGF0yZGbVAB Content-Type: multipart/mixed; boundary="8YymnSP73nuV3tjg5O5kOJhlznpBFr6c7"; protected-headers="v1" From: Stefan Winter To: "radext@ietf.org" Cc: draft-ietf-softwire-map-radius@ietf.org Message-ID: Subject: Review request for draft-ietf-softwire-map-radius References: <0E3D879F-E131-47FE-A5E7-CC700F04A51B@tsinghua.edu.cn> In-Reply-To: <0E3D879F-E131-47FE-A5E7-CC700F04A51B@tsinghua.edu.cn> --8YymnSP73nuV3tjg5O5kOJhlznpBFr6c7 Content-Type: multipart/mixed; boundary="------------7CED8EDF3E8373559E1B0E7A" Content-Language: en-US This is a multi-part message in MIME format. --------------7CED8EDF3E8373559E1B0E7A Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello radext, we have received a request for review of an I-D from the softwire working group, please see below. I would appreciate if you could take a few moments of your time to review this document and respond here to the working group, with the draft's mail address in cc. Greetings, Stefan Winter -------- Weitergeleitete Nachricht -------- We have the following wg document, RADIUS Attributes for Address plus Port (A+P) based Software Mechanisms. https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/ There has been a lot of work on getting draft ready for publication from the opinion of softwire wg. However, because there are several new attributes and a lot of sub-TLVs, we think we need to get RADEXT to help review, before we advance this doc to IESG. --------------7CED8EDF3E8373559E1B0E7A Content-Type: application/pgp-keys; name="0xC0DE6A358A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xC0DE6A358A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- 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----- --------------7CED8EDF3E8373559E1B0E7A-- --8YymnSP73nuV3tjg5O5kOJhlznpBFr6c7-- --P4enTRdh7bXFljFMZyuNQMHGF0yZGbVAB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEErTCR86sk4F9PciwDwN5qNYo53GYFAlvpcSgACgkQwN5qNYo5 3GbzXBAAt8gnvVM1tzb/jQ9Ax443/XIThgZQO2cIGfX8gNjAVoX2/stwKcofIr4/ jTCvOIAcvA5w8eGA8ELWmuWijsJPZ/2bar5NbTo1QCl3qfu7f8cUhgIuI7WKz6ZP qXKsxtn/vM4xRAIab0M0PVIhJPlos0kaFukE0UZFm4Qxioy6XHz1qKiO8/DzDRzW 35ZKWPEIY1diAC8uJ6a4jLayLq6cAWlEHJDEa5t0cMrpK820Q76xXtsKmNl6tESY I9PHJ72jmykrKkCvh0t8Aidj4GxPgnMmr4h7gWDlQHw7sv2gYgHA095YvNFonHo7 pCZ7vVKzY63qAw/LcCdLeroTkjrS/4FYR+V5K7NrMAPKTsUmLxTdEE2dnDXDUEP+ Q5f2YJqpQsSO/APzArWsk7BITzAkHhBWPXHphCDz2p1FwuK4yk32DVpEULwe+/8Q KCXjo20r7tmYiMJ06Vnu370uHzF1beiSguhKGOmkXo1luN48CYVpsDAa86UxnajN HRGYtw91tl7jEa8Xgix2CQDOc0gteGh4fGj6v/ly48eW4urEWYYVfaQLv1sXVFjW ZLc7H3cts36ZH4ETjicfv61zvamtw64EvrGZR+mFiUxqJV5X0dcnHE7b/j6ljNNZ NOxH8iU4he5W3w90OJ8pdRq1ulICBUuzNRYP/cW0frcyYee64Ss= =N6Xt -----END PGP SIGNATURE----- --P4enTRdh7bXFljFMZyuNQMHGF0yZGbVAB-- From nobody Mon Nov 12 04:29:50 2018 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 4D4F2130E14; Mon, 12 Nov 2018 04:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 7bUO8P-bS8Fz; Mon, 12 Nov 2018 04:29:47 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6796130E0E; Mon, 12 Nov 2018 04:29:46 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9606643968; Mon, 12 Nov 2018 13:29:45 +0100 (CET) From: Stefan Winter To: "radext@ietf.org" Cc: draft-ietf-softwire-map-radius@ietf.org References: <0E3D879F-E131-47FE-A5E7-CC700F04A51B@tsinghua.edu.cn> Organization: RESTENA Message-ID: <8590fa3f-b179-2910-4034-b22ac858c786@restena.lu> Date: Mon, 12 Nov 2018 13:29:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [radext] Review request for draft-ietf-softwire-map-radius X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 12:29:48 -0000 Hello, and here is a quick question to begin with: the document states that the attributes can occur in an Accounting-Request packet. However, nowhere in the document is the corresponding semantics of that transmission defined. I.e. why would a BNG or other RADIUS Client send this in an Accounting-Request? What would it want to achieve? And how does the RADIUS server react if it gets conflicting information there (say, IP addresses in the sub-TLVs differ in the Accounting-Request from what was sent in the preceding Access-Accept)? Greetings, Stefan Winter Am 12.11.18 um 13:25 schrieb Stefan Winter: > Hello radext, > > we have received a request for review of an I-D from the softwire > working group, please see below. > > I would appreciate if you could take a few moments of your time to > review this document and respond here to the working group, with the > draft's mail address in cc. > > Greetings, > > Stefan Winter > > -------- Weitergeleitete Nachricht -------- > > We have the following wg document, RADIUS Attributes for Address plus > Port (A+P) based Software Mechanisms. > https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/ > > There has been a lot of work on getting draft ready for publication from > the opinion of softwire wg. However, because there are several new > attributes and a lot of sub-TLVs, we think we need to get RADEXT to help > review, before we advance this doc to IESG. > From nobody Mon Nov 12 04:30:58 2018 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 6019E130E14 for ; Mon, 12 Nov 2018 04:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MWJncgopRloI for ; Mon, 12 Nov 2018 04:30:54 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id DB6CB130E0E for ; Mon, 12 Nov 2018 04:30:53 -0800 (PST) Received: from [192.168.46.58] (198-84-237-221.cpe.teksavvy.com [198.84.237.221]) by mail.networkradius.com (Postfix) with ESMTPSA id D0A6F4BD; Mon, 12 Nov 2018 12:30:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 $3445.100.39$) From: Alan DeKok In-Reply-To: Date: Mon, 12 Nov 2018 07:30:51 -0500 Cc: Fadi Bushnaq , radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <95F65DC7-9CED-4899-B97F-C6FCD248A454@deployingradius.com> References:

To: Winter Stefan X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [radext] Basic question about user-name attribute X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 12:30:56 -0000 On Nov 12, 2018, at 7:19 AM, Stefan Winter = wrote: > It sometimes happens that RADIUS administrators are rude to their = users > in that they send back the actual username in the Accept while the = user > was trying to maintain his privacy when connecting. That happens a lot, unfortunately. The reality is that it's just too = useful in most situations to have a "real" name for the users session. The Chargeable-User-Identifier was created to address that issue. But = most NASes don't support it. >> =46rom what I've seen in the field, this is sometimes used in = interplay > with Accounting-Request: if the session that was being authenticated > contains a User-Name in the Accept, that User-Name is sometimes used = as > the User-Name for subsequent Accounting-Requests for the same session. That is the behaviour suggested by RFC 2865 Section 5.1, about = User-Name It MAY be sent in an Access-Accept packet, in which case the client SHOULD use the name returned in the Access-Accept packet in all Accounting-Request packets for this session. Without that practice, EAP would have users log in with anonymized = User-Names, and then all of the Accounting-Request packets would contain = the same anonymized User-Name. Since most wireless NASes set "NAS-Port = =3D 0", it becomes difficult to distinguish user sessions from one = another. In hindsight, what RADIUS *should* have supported was the ability for = the server to send an Acct-Session-Id in the Access-Accept. The NAS = could then use that in subsequent accounting packets. Anonymity would = be preserved, *and* servers wouldn't have to deal with broken NASes that = re-use Acct-Session-Id after a reboot. I suppose a similar approach could be taken with the User-Name = attribute. But doing so would take not changing not only the server = software, but changing databases and business practices by the = administrators. That's a difficult proposition. > Nothing in the RFCs forbids either of these practices. The text in RFC 2865 *could* be interpreted to mean that the User-Name = in Access-Accept can be anything. i.e. unrelated to the User-Name in = the Access-Request. Alan DeKok. From nobody Mon Nov 12 04:33:36 2018 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 A2898130E1A for ; Mon, 12 Nov 2018 04:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBkWZrBROOqI for ; Mon, 12 Nov 2018 04:33:34 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 7E922130E0E for ; Mon, 12 Nov 2018 04:33:34 -0800 (PST) Received: from [192.168.46.58] (198-84-237-221.cpe.teksavvy.com [198.84.237.221]) by mail.networkradius.com (Postfix) with ESMTPSA id 8E1404BD; Mon, 12 Nov 2018 12:33:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 $3445.100.39$) From: Alan DeKok In-Reply-To: Date: Mon, 12 Nov 2018 07:33:32 -0500 Cc: "radext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E3D879F-E131-47FE-A5E7-CC700F04A51B@tsinghua.edu.cn> To: Winter Stefan X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [radext] Review request for draft-ietf-softwire-map-radius X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 12:33:35 -0000 On Nov 12, 2018, at 7:25 AM, Stefan Winter = wrote: >=20 > Hello radext, >=20 > we have received a request for review of an I-D from the softwire > working group, please see below. >=20 > I would appreciate if you could take a few moments of your time to > review this document and respond here to the working group, with the > draft's mail address in cc. The "aaa-doctors@ietf.org" mailing list was set up for precisely this = kind of review. Sadly, it seems to have languished, like much else of = the AAA ecosystem. As both RADEXT and DIME are winding down, it may be worth reviving = aaa-doctors. In fact, once the two WGs are closed, the aaa-doctors list = will be the only place for AAA reviews. Alan DeKok. From nobody Mon Nov 12 05:37:57 2018 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 083B0130E25; Mon, 12 Nov 2018 05:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACLLKh3gfEQS; Mon, 12 Nov 2018 05:37:52 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id BF7E81292AD; Mon, 12 Nov 2018 05:37:52 -0800 (PST) Received: from [192.168.46.58] (198-84-237-221.cpe.teksavvy.com [198.84.237.221]) by mail.networkradius.com (Postfix) with ESMTPSA id 5624DEF; Mon, 12 Nov 2018 13:37:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 $3445.100.39$) From: Alan DeKok In-Reply-To: Date: Mon, 12 Nov 2018 08:37:49 -0500 Cc: "radext@ietf.org" , draft-ietf-softwire-map-radius@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <380CA6BF-5401-4567-80F4-B31B388C81A4@deployingradius.com> References: <0E3D879F-E131-47FE-A5E7-CC700F04A51B@tsinghua.edu.cn> To: Winter Stefan X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [radext] Review request for draft-ietf-softwire-map-radius X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 13:37:55 -0000 > There has been a lot of work on getting draft ready for publication = from > the opinion of softwire wg. However, because there are several new > attributes and a lot of sub-TLVs, we think we need to get RADEXT to = help > review, before we advance this doc to IESG. At a high level: * Please remove all ASCII art. RFC 8044 (RADIUS data types) Section 2.1 = suggests that this is no longer necessary. * Please use the attribute definition format suggested in RFC 8044 = Section 2.1.3. Doing so will make the document clearer * Most of the data types in this document fit the data types in RFC = 8044. If not, the considerations of RFC 6158 Section 3.2.3 on "Complex = Data Types" need to be addressed. * Please decrease the use of "TLV" An attribute can be referred to by = name. e.g. "S46-MAP-E". It does not need to be referred to as = "S46-MAP-E TLV" And a review in detail: 3. Extensions of RADIUS Attributes and TLVs I suggest just calling this "New RADIUS Attributes". There already = exists "RADIUS extensions" documents, which do radically different = things. The Softwire46-Configuration Attribute MUST contain one or more of the following: S46-MAP-E TLV, S46-MAP-T TLV, and/or S46- Lightweight-4over6 TLV. "the following... " what? I suggest: The Softwire46-Configuration Attribute MUST contain one or more of the following attributes: S46-MAP-E, S46-MAP-T, and/or S46- Lightweight-4over6. Similar comments apply to many other places in the document. Also, is there any reason to shorten the attribute names? = "Softwire46-MAP-E" would be clearer than "S46-MAP-E". Figure 1 is useful and informative. NIT: I would remove the repeated = use of "TLV" and "sub-TLV". Which attribute contains what is clear from = the diagram. 3.1.1.1. S46-MAP-E TLV Format I would rename this section "S46-MAP-E Attribute". The section = describes the attribute, not just it's format. If RFC 8044 is = referenced, the formats are defined there. And don't need to be copied = here. The section also doesn't say what the attribute is *for*. While that = description is alluded to in the rest of the document, it it not clear. = Again, using the layout recommended by RFC 8044 would be useful. That = layout includes a portion for a description of what the attribute does. Similar comments apply to many other places in the document. Table 2: Softwire46 Sub-TLVs The use of "M - Mandatory, O - Optional, N/P - Not Permitted" is = unusual. I suggest using a table format similar to RFC 2865 Section = 5.44, as is done with other RADIUS RFCs. e.g. use "0", "0-1", "0+". = etc. For number assignment, the TLVs create a new number space, and can = likely be assigned directly in the document. e.g. if "Foo" contains = "Bar" and "Baz", then you can assign "1" to "Bar", and "2" to "Baz". = This is what IANA will do anyways, and it helps clarify the document, = and prevent mistakes. 3.1.4.3. EA-Length Sub-TLV This section defines an attribute that contains a 16 bit number. Such = attributes are discouraged by RFC 6158. This definition should be = corrected to be a 32-bit integer, or an explanation should be given as = to why 16 bits is required here. Similar comments apply for Sections 3.1.6.1, 3.1.6.2, and 3.1.6.3. Section 3.2. defines an attribute that contains an array of 16-bit = integers. Please follow the guidelines of RFC 6158 here.= From nobody Mon Nov 12 15:48:36 2018 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 1DAE2130EA2; Mon, 12 Nov 2018 15:48:35 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 QyoGVD513EMv; Mon, 12 Nov 2018 15:48:33 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 C612F130E46; Mon, 12 Nov 2018 15:48:29 -0800 (PST) X-AuditID: 1209190d-6cfff7000000358a-d8-5bea114bdb3a Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id C4.46.13706.C411AEB5; Mon, 12 Nov 2018 18:48:28 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.14.7/8.9.2) with ESMTP id wACNmQHg024141; Mon, 12 Nov 2018 18:48:27 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) śby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wACNmNZZ006268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Nov 2018 18:48:25 -0500 Date: Mon, 12 Nov 2018 17:48:23 -0600 From: Benjamin Kaduk To: draft-ietf-radext-coa-proxy.all@ietf.org Cc: radext@ietf.org Message-ID: <20181112234823.GG99562@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUixCmqresj+Cra4OkvXovzb/6zW7S8msnm wOSxZMlPpgDGKC6blNSczLLUIn27BK6Mn0uPMRV8Falo65/N3sC4XqCLkZNDQsBE4tjrh2xd jFwcQgJrmCQ+7p7LBOFsZJR4c/QuC4Rzl0li1qrtLCAtLAKqEps23WEHsdkEVCQaui8zg9gi AjoSdxZdBathFhCW2HhqPROILSxgIbHx3WmwOC/QurXf/rBB2IISJ2c+garXkrjx7yVQPQeQ LS2x/B8HSFhUQFlib98h9gmMfLOQdMxC0jELoWMBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQi XSO93MwSvdSU0k2M4GCT5N3B+O+u1yFGAQ5GJR7eC/NeRguxJpYVV+YeYpTkYFIS5c18BBTi S8pPqcxILM6ILyrNSS0+xCjBwawkwsvHA5TjTUmsrEotyodJSXOwKInz/hZ5HC0kkJ5Ykpqd mlqQWgSTleHgUJLgfcr/KlpIsCg1PbUiLTOnBCHNxMEJMpwHaPg3kBre4oLE3OLMdIj8KUZF KXHeFyAJAZBERmkeXC8oGUhk7695xSgO9Iow71eQKh5gIoHrfgU0mAlocMnL5yCDSxIRUlIN jIK7Hll+OjXP0uqm4e/eNJP4+zPbXhnMcuaSqT3ZdNPqaXF/uNjFs0ELn1pIvHjpYPv34JEQ RteoX/3Vrxl97j1S3bJry7KaQ+0pa9j31rAZpDJLHzlnOPutlsOl4jIBpekbIvevzFH/0b58 0cNpz1s+e591vPfwW97xj89XMOYL68fMeRZ9cYISS3FGoqEWc1FxIgBuwaIY4QIAAA== Archived-At: Subject: [radext] moving forward with draft-ietf-radext-coa-proxy X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 23:48:35 -0000 Hi all, Thanks to Alan for submitting a new revision(s) of the draft; I believe that the -07 contains sufficient changes to resolve the last DISCUSS poinits open against the document. I also plan to change the target status to Informational (from Proposed Standard); it is a little unfortunate to need to do so, but the IESG's discussions convinced me that this is the sort of thing that the downref policy was intended to avoid. There were a few things in the diff between the -05 and -07 that stuck out to me, though, and might require further changes. In Section 3.2, We also update Section 5 of [RFC5580] to permit CoA-Request and Disconnect-Request packets to contain zero or one instances of the Operator-Name attribute. is not reflected in the Updates header and would require WG confirmation and potentially re-running the IETF LC. (Also, 5580 is Proposed Standard, so we'd have trouble doing this update from an Informational document.) It's somewhat unclear to me exactly what is being Updated, too, so I'd appreciate a bit of explanation (here in the email thread). Section 3.3 introduces a new normative requirement: Some Home Networks will not have permission to send CoA packets to the Visited Network. The CoA server SHOULD therefore also validate the NAI contained in the User-Name attribute. If the Home Network is not permitted to send CoA packets to this Visited Network, then the CoA server MUST return a NAK packet that contains an Error-Cause attribute having value 502 ("Request Not Routable"). Can the chairs confirm there is WG consensus for it? In Section 3.4: Implementations supporting this attribute MUST be able to handle between one (1) and thirty-two (32) octets of data. Implementations creating an Operator-NAS-Identifier MUST NOT create attributes with more than sixty-four octets of data. A thirty-two octet string should be more than sufficient for future uses. The bump from 20 to 32 octest is fine, but now we have MUST be able to handle 32 and MUST NOT generate more than 64, which are different numbers. (In the -05 the numbers were both 20.) Where did the 64 come from? Section 4.2 introduces a new normative requirement: The Visited Network MUST also ensure that the CoA packet sent to the NAS contains one of the following attributes: NAS-IP-Address, NAS- IPv6-Address, or NAS-Identifier. This step is the inverse of the removal required above in Section 3.4. First off, is this "at least one" or "exactly one"? And the same question of WG consensus applies. Thanks, Ben From nobody Tue Nov 13 01:31:58 2018 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 8D68E12F1A5 for ; Tue, 13 Nov 2018 01:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 0tUSzlB77AlK for ; Tue, 13 Nov 2018 01:31:55 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA4112F1A2 for ; Tue, 13 Nov 2018 01:31:55 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 80C4243AB1 for ; Tue, 13 Nov 2018 10:31:52 +0100 (CET) To: radext@ietf.org References: <0E3D879F-E131-47FE-A5E7-CC700F04A51B@tsinghua.edu.cn>

From: Stefan Winter Organization: RESTENA Message-ID: <22469dab-1530-2706-0e8a-b339be66e60d@restena.lu> Date: Tue, 13 Nov 2018 10:31:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [radext] Review request for draft-ietf-softwire-map-radius X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 09:31:56 -0000 Hi, >> The "aaa-doctors@ietf.org" mailing list was set up for precisely this kind of review. Sadly, it seems to have languished, like much else of the AAA ecosystem. >> >> As both RADEXT and DIME are winding down, it may be worth reviving aaa-doctors. In fact, once the two WGs are closed, the aaa-doctors list will be the only place for AAA reviews. There is indeed not a lot going on on that mailing list. I can always send the request there as well though. Greetings, Stefan Winter From nobody Tue Nov 13 04:14:16 2018 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 9911412D4EE; Tue, 13 Nov 2018 04:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjS0XzKV8UEa; Tue, 13 Nov 2018 04:14:12 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEA5129619; Tue, 13 Nov 2018 04:14:12 -0800 (PST) Received: from [192.168.46.58] (198-84-237-221.cpe.teksavvy.com [198.84.237.221]) by mail.networkradius.com (Postfix) with ESMTPSA id E369C332; Tue, 13 Nov 2018 12:14:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 $3445.100.39$) From: Alan DeKok In-Reply-To: <20181112234823.GG99562@kduck.kaduk.org> Date: Tue, 13 Nov 2018 07:14:09 -0500 Cc: draft-ietf-radext-coa-proxy.all@ietf.org, radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <650E5AB0-662D-4A9D-95A3-54C1C9CFB3B0@deployingradius.com> References: <20181112234823.GG99562@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [radext] moving forward with draft-ietf-radext-coa-proxy X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 12:14:15 -0000 On Nov 12, 2018, at 6:48 PM, Benjamin Kaduk wrote: > I also plan to change the target status to Informational (from = Proposed > Standard); it is a little unfortunate to need to do so, but the IESG's > discussions convinced me that this is the sort of thing that the = downref > policy was intended to avoid. OK. > There were a few things in the diff between the -05 and -07 that stuck = out > to me, though, and might require further changes. >=20 > In Section 3.2, >=20 > We also update Section 5 of [RFC5580] to permit CoA-Request and > Disconnect-Request packets to contain zero or one instances of the > Operator-Name attribute. >=20 > is not reflected in the Updates header and would require WG = confirmation > and potentially re-running the IETF LC. > (Also, 5580 is Proposed Standard, so we'd have trouble doing this = update > from an Informational document.) It's somewhat unclear to me exactly = what > is being Updated, too, so I'd appreciate a bit of explanation (here in = the > email thread). RFC 5580 defined, Operator-Name, and Section 5 forbade Operator-Name = from occurring in CoA-Request packets. So something needs to be updated in order to allow it. > Section 3.3 introduces a new normative requirement: >=20 > Some Home Networks will not have permission to send CoA packets to > the Visited Network. The CoA server SHOULD therefore also validate > the NAI contained in the User-Name attribute. If the Home Network = is > not permitted to send CoA packets to this Visited Network, then the > CoA server MUST return a NAK packet that contains an Error-Cause > attribute having value 502 ("Request Not Routable"). >=20 > Can the chairs confirm there is WG consensus for it? I'll leave that for the chairs. My $0.02 is that it's useful to = signal routing errors. Tho this specific error number may or may not be = appropriate. > In Section 3.4: >=20 > Implementations supporting this attribute MUST be able to handle > between one (1) and thirty-two (32) octets of data. > Implementations creating an Operator-NAS-Identifier MUST NOT > create attributes with more than sixty-four octets of data. A > thirty-two octet string should be more than sufficient for future > uses. >=20 > The bump from 20 to 32 octest is fine, but now we have MUST be able to > handle 32 and MUST NOT generate more than 64, which are different = numbers. > (In the -05 the numbers were both 20.) Where did the 64 come from? IIRC, Adam Roaches discussion of creating tokens using modern ciphers. = 64 bytes would be needed for that to occur. > Section 4.2 introduces a new normative requirement: >=20 > The Visited Network MUST also ensure that the CoA packet sent to the > NAS contains one of the following attributes: NAS-IP-Address, NAS- > IPv6-Address, or NAS-Identifier. This step is the inverse of the > removal required above in Section 3.4. >=20 > First off, is this "at least one" or "exactly one"? At least one. > And the same question of WG consensus applies. WG consensus is nice, but that text is required in order for this = specification to be compatible with RFC 5176, and with NAS = implementations. Failure to include *any* of those attributes in a CoA = packet means that the NAS will reject the packet entirely. Alan DeKok. From nobody Thu Nov 15 14:35:15 2018 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C86124BAA; Thu, 15 Nov 2018 14:35:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-radext-coa-proxy@ietf.org, Stefan Winter , radext-chairs@ietf.org, stefan.winter@restena.lu, radext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154232130652.10055.17092640658047506715.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2018 14:35:06 -0800 Archived-At: Subject: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-07: (with DISCUSS) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.29 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 22:35:07 -0000 Adam Roach has entered the following ballot position for draft-ietf-radext-coa-proxy-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS points.