From nobody Mon Aug 6 05:59:51 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 759BC130DDA; Mon, 6 Aug 2018 05:59:48 -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 QiwS219vY3WX; Mon, 6 Aug 2018 05:59:43 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id A4A96130DFD; Mon, 6 Aug 2018 05:59:43 -0700 (PDT) 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 9E8C32C6; Mon, 6 Aug 2018 12:59:41 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Alan DeKok X-Priority: Medium In-Reply-To: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> Date: Mon, 6 Aug 2018 08:59:39 -0400 Cc: dime , iana , radext@ietf.org, Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: References: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> To: Denis Ovsienko X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] [Dime] error in IANA allocations for RFC 5447 (attributes 124 and 125) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 12:59:49 -0000 On Aug 6, 2018, at 8:01 AM, Denis Ovsienko wrote: > Recently I was reviewing some code that adds support for two RFC 5447 = RADIUS AVPs below: >=20 > The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString > The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and >=20 > It turned out, the current RADIUS Types registry at = https://www.iana.org/assignments/radius-types/radius-types.xhtml lists = both attributes with wrong types: >=20 > 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] That is definitely wrong. The "ipv6prefix" format is different than = the one used by MIP6-Home-Link-Prefix in RFC 5337. > 124 MIP6-Feature-Vector string [RFC5447] That issue is a bit different. 64-bit integers were defined in RFC = 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after RFC = 5447 was published. So at the time RFC 5447 was published, "string" was the correct = definition. > Those incorrect types had propagated from the IANA registry into = FreeRADIUS and Wireshark (both have been fixed now for = MIP6-Home-Link-Prefix, see the discussion and the follow-ups at = https://github.com/the-tcpdump-group/tcpdump/pull/636 if interested). >=20 > Having studied this discrepancy thoroughly, I had concluded the AVP = definitions are correct in RFC 5447, so I did not file an erratum. The = problem seems to be with those IANA allocations only. Could somebody = review this issue and put the IANA allocations right? In the end, I think that the incorrect IANA allocations were a result = of the updates done in RFC 8044. The early drafts had a table which = updated all of the IANA data types, e.g.: https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section-4.2 The MIP6 attributes are listed there as "ipv6prefix" and "string". As = the author of RFC 8044, I think that's my mistake. Updating hundreds of = attributes required reading many RFCs, and it's understandable that a = few mistakes were made. Unless there are objections from DIME or RADEXT, I think it would be = best for IANA to update the registry as follows: 125 MIP6-Home-Link-Prefix string [RFC5447] 124 MIP6-Feature-Vector integer64 [RFC5447] We may need approval from the AD (Ben). Explicit consensus from the = WG would also be helpful. Alan DeKok. From nobody Mon Aug 6 13:33:31 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 D8412130E05; Mon, 6 Aug 2018 13:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, 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 YSN0G5NsEDFx; Mon, 6 Aug 2018 13:33:27 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 83AB6130DCE; Mon, 6 Aug 2018 13:33:27 -0700 (PDT) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id C4C16E0256; Mon, 6 Aug 2018 20:33:26 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id 8B829207E6; Mon, 6 Aug 2018 20:33:26 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" Reply-To: iana-matrix@iana.org In-Reply-To: References: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1118137 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org CC: kaduk@mit.edu, dime@ietf.org, radext@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 06 Aug 2018 20:33:26 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [radext] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 20:33:30 -0000 Hi, On Mon Aug 06 13:00:05 2018, aland@deployingradius.com wrote: > On Aug 6, 2018, at 8:01 AM, Denis Ovsienko > wrote: > > Recently I was reviewing some code that adds support for two RFC 5447 > > RADIUS AVPs below: > > > > The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString > > The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and > > > > It turned out, the current RADIUS Types registry at > > https://www.iana.org/assignments/radius-types/radius-types.xhtml > > lists both attributes with wrong types: > > > > 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] > > That is definitely wrong. The "ipv6prefix" format is different than > the one used by MIP6-Home-Link-Prefix in RFC 5337. > > > 124 MIP6-Feature-Vector string [RFC5447] > > That issue is a bit different. 64-bit integers were defined in RFC > 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after RFC > 5447 was published. > > So at the time RFC 5447 was published, "string" was the correct > definition. > > > Those incorrect types had propagated from the IANA registry into > > FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home- > > Link-Prefix, see the discussion and the follow-ups at > > https://github.com/the-tcpdump-group/tcpdump/pull/636 if interested). > > > > Having studied this discrepancy thoroughly, I had concluded the AVP > > definitions are correct in RFC 5447, so I did not file an erratum. > > The problem seems to be with those IANA allocations only. Could > > somebody review this issue and put the IANA allocations right? > > In the end, I think that the incorrect IANA allocations were a result > of the updates done in RFC 8044. The early drafts had a table which > updated all of the IANA data types, e.g.: > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section-4.2 Right, we took the entries from here when the document was approved: https://tools.ietf.org/html/draft-ietf-radext-datatypes-08#section-4.2 > The MIP6 attributes are listed there as "ipv6prefix" and "string". As > the author of RFC 8044, I think that's my mistake. Updating hundreds > of attributes required reading many RFCs, and it's understandable that > a few mistakes were made. > > Unless there are objections from DIME or RADEXT, I think it would be > best for IANA to update the registry as follows: > > 125 MIP6-Home-Link-Prefix string [RFC5447] > 124 MIP6-Feature-Vector integer64 [RFC5447] > > We may need approval from the AD (Ben). Explicit consensus from the > WG would also be helpful. > > Alan DeKok. If there's no errata report required, we can move ahead once the AD lets us know that any appropriate consensus has been reached (if we haven't heard from the chairs first) and gives us the go-ahead. Best regards, Amanda Baber Lead IANA Services Specialist From nobody Tue Aug 7 01:03:38 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 38313130F59; Tue, 7 Aug 2018 01:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 bvCaG5oXbvym; Tue, 7 Aug 2018 01:03:29 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC9D130F5C; Tue, 7 Aug 2018 01:03:28 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 41l6TW27lczFqB4; Tue, 7 Aug 2018 10:03:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 41l6TV6QQdzBrLG; Tue, 7 Aug 2018 10:03:26 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0399.000; Tue, 7 Aug 2018 10:03:26 +0200 From: To: "iana-matrix@iana.org" CC: "radext@ietf.org" , "dime@ietf.org" , "kaduk@mit.edu" Thread-Topic: [radext] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125) Thread-Index: AQHULcTBi7dJI32kEUmBqiAVfP2o6aSz7LsA Date: Tue, 7 Aug 2018 08:03:26 +0000 Message-ID: <11227_1533629007_5B69524E_11227_192_1_6B7134B31289DC4FAF731D844122B36E3951AE20@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [radext] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 08:03:31 -0000 I agree with the proposal. It is important that the types defined in RFC5447 are the ones listed in th= e IANA registry. For information, there are existing implementations relying on these AVPs a= nd it is important to be consistent between the RFC and registry. Regards, Lionel > -----Message d'origine----- > De=A0: radext [mailto:radext-bounces@ietf.org] De la part de Amanda Baber= via > RT > Envoy=E9=A0: lundi 6 ao=FBt 2018 22:33 > Cc=A0: radext@ietf.org; dime@ietf.org; kaduk@mit.edu > Objet=A0: [radext] [IANA #1118137] error in IANA allocations for RFC 5447 > (attributes 124 and 125) >=20 > Hi, >=20 > On Mon Aug 06 13:00:05 2018, aland@deployingradius.com wrote: > > On Aug 6, 2018, at 8:01 AM, Denis Ovsienko > > wrote: > > > Recently I was reviewing some code that adds support for two RFC 5447 > > > RADIUS AVPs below: > > > > > > The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString > > > The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and > > > > > > It turned out, the current RADIUS Types registry at > > > https://www.iana.org/assignments/radius-types/radius-types.xhtml > > > lists both attributes with wrong types: > > > > > > 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] > > > > That is definitely wrong. The "ipv6prefix" format is different than > > the one used by MIP6-Home-Link-Prefix in RFC 5337. > > > > > 124 MIP6-Feature-Vector string [RFC5447] > > > > That issue is a bit different. 64-bit integers were defined in RFC > > 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after RFC > > 5447 was published. > > > > So at the time RFC 5447 was published, "string" was the correct > > definition. > > > > > Those incorrect types had propagated from the IANA registry into > > > FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home- > > > Link-Prefix, see the discussion and the follow-ups at > > > https://github.com/the-tcpdump-group/tcpdump/pull/636 if interested). > > > > > > Having studied this discrepancy thoroughly, I had concluded the AVP > > > definitions are correct in RFC 5447, so I did not file an erratum. > > > The problem seems to be with those IANA allocations only. Could > > > somebody review this issue and put the IANA allocations right? > > > > In the end, I think that the incorrect IANA allocations were a result > > of the updates done in RFC 8044. The early drafts had a table which > > updated all of the IANA data types, e.g.: > > > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section-4.2 >=20 > Right, we took the entries from here when the document was approved: >=20 > https://tools.ietf.org/html/draft-ietf-radext-datatypes-08#section-4.2 >=20 > > The MIP6 attributes are listed there as "ipv6prefix" and "string". As > > the author of RFC 8044, I think that's my mistake. Updating hundreds > > of attributes required reading many RFCs, and it's understandable that > > a few mistakes were made. > > > > Unless there are objections from DIME or RADEXT, I think it would be > > best for IANA to update the registry as follows: > > > > 125 MIP6-Home-Link-Prefix string [RFC5447] > > 124 MIP6-Feature-Vector integer64 [RFC5447] > > > > We may need approval from the AD (Ben). Explicit consensus from the > > WG would also be helpful. > > > > Alan DeKok. >=20 > If there's no errata report required, we can move ahead once the AD lets = us > know that any appropriate consensus has been reached (if we haven't heard > from the chairs first) and gives us the go-ahead. >=20 > Best regards, >=20 > Amanda Baber > Lead IANA Services Specialist >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Aug 7 13:01:54 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 4D8F51310C2; Tue, 7 Aug 2018 13:01:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carlos Pignataro To: Cc: radext@ietf.org, draft-ietf-radext-coa-proxy.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153367210026.2186.4924333337071965276@ietfa.amsl.com> Date: Tue, 07 Aug 2018 13:01:40 -0700 Archived-At: Subject: [radext] Opsdir last call review of draft-ietf-radext-coa-proxy-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 20:01:41 -0000 Reviewer: Carlos Pignataro Review result: Has Nits As part of the Ops Directorate (opsdir) review, this document has some Nits and is otherwise Ready. https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-radext-coa-proxy-05.txt The Downref was appropriate called out during last call, but the Abstract, header, and disclaimers need fixing. Thanks, Carlos Pignataro. From nobody Tue Aug 7 18:59:42 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 A96C3130DDA; Tue, 7 Aug 2018 18:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.18 X-Spam-Level: X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 52_t-2vea8Kt; Tue, 7 Aug 2018 18:59:32 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 24E34127332; Tue, 7 Aug 2018 18:59:32 -0700 (PDT) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 46B2DE0158; Wed, 8 Aug 2018 01:59:31 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id 0D710207E6; Wed, 8 Aug 2018 01:59:31 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" Reply-To: iana-matrix@iana.org In-Reply-To: References: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> <11227_1533629007_5B69524E_11227_192_1_6B7134B31289DC4FAF731D844122B36E3951AE20@OPEXCLILM43.corporate.adroot.infra.ftgroup> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1118137 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org CC: radext@ietf.org, lionel.morand@orange.com, kaduk@mit.edu, dime@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 08 Aug 2018 01:59:31 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [radext] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 01:59:35 -0000 Hi Benjamin, Given Lionel's confirmation, should we go ahead and make these changes at https://www.iana.org/assignments/radius-types? OLD: 124 MIP6-Feature-Vector string [RFC5447] 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] NEW: 124 MIP6-Feature-Vector integer64 [RFC5447] 125 MIP6-Home-Link-Prefix string [RFC5447] thanks, Amanda On Tue Aug 07 08:03:49 2018, lionel.morand@orange.com wrote: > I agree with the proposal. > It is important that the types defined in RFC5447 are the ones listed > in the IANA registry. > For information, there are existing implementations relying on these > AVPs and it is important to be consistent between the RFC and > registry. > > Regards, > > Lionel > > > -----Message d'origine----- > > De : radext [mailto:radext-bounces@ietf.org] De la part de Amanda > > Baber via > > RT > > Envoyé : lundi 6 août 2018 22:33 > > Cc : radext@ietf.org; dime@ietf.org; kaduk@mit.edu > > Objet : [radext] [IANA #1118137] error in IANA allocations for RFC > > 5447 > > (attributes 124 and 125) > > > > Hi, > > > > On Mon Aug 06 13:00:05 2018, aland@deployingradius.com wrote: > > > On Aug 6, 2018, at 8:01 AM, Denis Ovsienko > > > wrote: > > > > Recently I was reviewing some code that adds support for two RFC > > > > 5447 > > > > RADIUS AVPs below: > > > > > > > > The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type > > > > OctetString > > > > The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 > > > > and > > > > > > > > It turned out, the current RADIUS Types registry at > > > > https://www.iana.org/assignments/radius-types/radius-types.xhtml > > > > lists both attributes with wrong types: > > > > > > > > 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] > > > > > > That is definitely wrong. The "ipv6prefix" format is different > > > than > > > the one used by MIP6-Home-Link-Prefix in RFC 5337. > > > > > > > 124 MIP6-Feature-Vector string [RFC5447] > > > > > > That issue is a bit different. 64-bit integers were defined in RFC > > > 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after > > > RFC > > > 5447 was published. > > > > > > So at the time RFC 5447 was published, "string" was the correct > > > definition. > > > > > > > Those incorrect types had propagated from the IANA registry into > > > > FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home- > > > > Link-Prefix, see the discussion and the follow-ups at > > > > https://github.com/the-tcpdump-group/tcpdump/pull/636 if > > > > interested). > > > > > > > > Having studied this discrepancy thoroughly, I had concluded the > > > > AVP > > > > definitions are correct in RFC 5447, so I did not file an > > > > erratum. > > > > The problem seems to be with those IANA allocations only. Could > > > > somebody review this issue and put the IANA allocations right? > > > > > > In the end, I think that the incorrect IANA allocations were a > > > result > > > of the updates done in RFC 8044. The early drafts had a table > > > which > > > updated all of the IANA data types, e.g.: > > > > > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section- > > > 4.2 > > > > Right, we took the entries from here when the document was approved: > > > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-08#section- > > 4.2 > > > > > The MIP6 attributes are listed there as "ipv6prefix" and "string". > > > As > > > the author of RFC 8044, I think that's my mistake. Updating > > > hundreds > > > of attributes required reading many RFCs, and it's understandable > > > that > > > a few mistakes were made. > > > > > > Unless there are objections from DIME or RADEXT, I think it would > > > be > > > best for IANA to update the registry as follows: > > > > > > 125 MIP6-Home-Link-Prefix string [RFC5447] > > > 124 MIP6-Feature-Vector integer64 [RFC5447] > > > > > > We may need approval from the AD (Ben). Explicit consensus from > > > the > > > WG would also be helpful. > > > > > > Alan DeKok. > > > > If there's no errata report required, we can move ahead once the AD > > lets us > > know that any appropriate consensus has been reached (if we haven't > > heard > > from the chairs first) and gives us the go-ahead. > > > > Best regards, > > > > Amanda Baber > > Lead IANA Services Specialist > > > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. From nobody Sat Aug 11 09:07:14 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 A973D130DD9; Sat, 11 Aug 2018 09:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 SDAYZ0HeKLGO; Sat, 11 Aug 2018 09:07:09 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 558791277C8; Sat, 11 Aug 2018 09:07:09 -0700 (PDT) X-AuditID: 1209190f-f1fff7000000159e-9c-5b6f09aba35b Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 0D.30.05534.BA90F6B5; Sat, 11 Aug 2018 12:07:08 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w7BG760f027679; Sat, 11 Aug 2018 12:07:06 -0400 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.13.8/8.12.4) with ESMTP id w7BG710w017821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 11 Aug 2018 12:07:04 -0400 Date: Sat, 11 Aug 2018 11:07:01 -0500 From: Benjamin Kaduk To: Amanda Baber via RT Cc: ;, radext@ietf.org, lionel.morand@orange.com, dime@ietf.org Message-ID: <20180811160701.GP40887@kduck.kaduk.org> References: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> <11227_1533629007_5B69524E_11227_192_1_6B7134B31289DC4FAF731D844122B36E3951AE20@OPEXCLILM43.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUixCmqrbuGMz/a4OwMTou5vSvYLPr2NLBY 3N6eadHyaiabA4tHj7zHkiU/mTxanp1kC2CO4rJJSc3JLEst0rdL4MpYNH8eY8Fb/Yqv766z NDDeVeli5OSQEDCRmPzyLmMXIxeHkMBiJokDh6czgySEBDYySvRPzoRIXGWSuPXsMhtIgkVA VWLxnG4WEJtNQEWiofsyWIOIgJ7EipalTCA2s4C9xNLNp1lBbGGBOIn537exg9i8QNsmrnjN CrHgLLPEq7klEHFBiZMzn7BA9OpI7Nx6B2gXB5AtLbH8HwdEWF6ieetssFWcAo4Sbx98ABsp KqAssbfvEPsERsFZSCbNQjJpFsKkWUgmLWBkWcUom5JbpZubmJlTnJqsW5ycmJeXWqRropeb WaKXmlK6iREc7JL8OxjnNHgfYhTgYFTi4b2wMTdaiDWxrLgy9xCjJAeTkiiv2Ny8aCG+pPyU yozE4oz4otKc1OJDjBIczEoivGffA+V4UxIrq1KL8mFS0hwsSuK892rCo4UE0hNLUrNTUwtS i2CyMhwcShK80zjyo4UEi1LTUyvSMnNKENJMHJwgw3mAhpeB1PAWFyTmFmemQ+RPMdpzvFjU M4mZ48JjEDnv6FQg+ec9kBRiycvPS5US520AaRMAacsozYObDEpkEtn7a14xigM9Ksy7BqSK B5gE4Wa/AlrLBLQ2WzMXZG1JIkJKqoFxmez13xUik276vkhb2Deh6PXet7YuP+MLdBoT5RUs TjEuPrHsvqJgzC4tmTuOCj6/jq2ZdTjD+c8+Jt0d9f4nXvbc36p+YPPBs28lPs1rXr13pauh 6GMNKfFj7jenJnpevBz9+OvnW3vn5dstqi2e+udMZi/PngPpMiwsjPf/SumbJ8/+xZP0RIml OCPRUIu5qDgRABDiffU/AwAA Archived-At: Subject: Re: [radext] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 11 Aug 2018 16:07:12 -0000 Hi Amanda, On Wed, Aug 08, 2018 at 01:59:31AM +0000, Amanda Baber via RT wrote: > Hi Benjamin, > > Given Lionel's confirmation, should we go ahead and make these changes at https://www.iana.org/assignments/radius-types? Yes, please make those changes. Thanks, Benjamin > OLD: > > 124 MIP6-Feature-Vector string [RFC5447] > 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] > > NEW: > > 124 MIP6-Feature-Vector integer64 [RFC5447] > 125 MIP6-Home-Link-Prefix string [RFC5447] > > thanks, > Amanda > > On Tue Aug 07 08:03:49 2018, lionel.morand@orange.com wrote: > > I agree with the proposal. > > It is important that the types defined in RFC5447 are the ones listed > > in the IANA registry. > > For information, there are existing implementations relying on these > > AVPs and it is important to be consistent between the RFC and > > registry. > > > > Regards, > > > > Lionel > > > > > -----Message d'origine----- > > > De : radext [mailto:radext-bounces@ietf.org] De la part de Amanda > > > Baber via > > > RT > > > Envoyé : lundi 6 août 2018 22:33 > > > Cc : radext@ietf.org; dime@ietf.org; kaduk@mit.edu > > > Objet : [radext] [IANA #1118137] error in IANA allocations for RFC > > > 5447 > > > (attributes 124 and 125) > > > > > > Hi, > > > > > > On Mon Aug 06 13:00:05 2018, aland@deployingradius.com wrote: > > > > On Aug 6, 2018, at 8:01 AM, Denis Ovsienko > > > > wrote: > > > > > Recently I was reviewing some code that adds support for two RFC > > > > > 5447 > > > > > RADIUS AVPs below: > > > > > > > > > > The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type > > > > > OctetString > > > > > The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 > > > > > and > > > > > > > > > > It turned out, the current RADIUS Types registry at > > > > > https://www.iana.org/assignments/radius-types/radius-types.xhtml > > > > > lists both attributes with wrong types: > > > > > > > > > > 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] > > > > > > > > That is definitely wrong. The "ipv6prefix" format is different > > > > than > > > > the one used by MIP6-Home-Link-Prefix in RFC 5337. > > > > > > > > > 124 MIP6-Feature-Vector string [RFC5447] > > > > > > > > That issue is a bit different. 64-bit integers were defined in RFC > > > > 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after > > > > RFC > > > > 5447 was published. > > > > > > > > So at the time RFC 5447 was published, "string" was the correct > > > > definition. > > > > > > > > > Those incorrect types had propagated from the IANA registry into > > > > > FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home- > > > > > Link-Prefix, see the discussion and the follow-ups at > > > > > https://github.com/the-tcpdump-group/tcpdump/pull/636 if > > > > > interested). > > > > > > > > > > Having studied this discrepancy thoroughly, I had concluded the > > > > > AVP > > > > > definitions are correct in RFC 5447, so I did not file an > > > > > erratum. > > > > > The problem seems to be with those IANA allocations only. Could > > > > > somebody review this issue and put the IANA allocations right? > > > > > > > > In the end, I think that the incorrect IANA allocations were a > > > > result > > > > of the updates done in RFC 8044. The early drafts had a table > > > > which > > > > updated all of the IANA data types, e.g.: > > > > > > > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section- > > > > 4.2 > > > > > > Right, we took the entries from here when the document was approved: > > > > > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-08#section- > > > 4.2 > > > > > > > The MIP6 attributes are listed there as "ipv6prefix" and "string". > > > > As > > > > the author of RFC 8044, I think that's my mistake. Updating > > > > hundreds > > > > of attributes required reading many RFCs, and it's understandable > > > > that > > > > a few mistakes were made. > > > > > > > > Unless there are objections from DIME or RADEXT, I think it would > > > > be > > > > best for IANA to update the registry as follows: > > > > > > > > 125 MIP6-Home-Link-Prefix string [RFC5447] > > > > 124 MIP6-Feature-Vector integer64 [RFC5447] > > > > > > > > We may need approval from the AD (Ben). Explicit consensus from > > > > the > > > > WG would also be helpful. > > > > > > > > Alan DeKok. > > > > > > If there's no errata report required, we can move ahead once the AD > > > lets us > > > know that any appropriate consensus has been reached (if we haven't > > > heard > > > from the chairs first) and gives us the go-ahead. > > > > > > Best regards, > > > > > > Amanda Baber > > > Lead IANA Services Specialist > > > > > > _______________________________________________ > > > radext mailing list > > > radext@ietf.org > > > https://www.ietf.org/mailman/listinfo/radext > > > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > > recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > > messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, > > deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > > been modified, changed or falsified. > > Thank you. > From nobody Mon Aug 13 04:52:30 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 0A7A3128C65; Mon, 13 Aug 2018 04:52:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= 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.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153416114103.25041.1808333930520958934.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2018 04:52:21 -0700 Archived-At: Subject: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-radext-coa-proxy-05=3A_=28with_COMMENT=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 11:52:21 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-radext-coa-proxy-05: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this well-written doc. One nit in sec 3.1: s/activee/active/ One quick question on sec 3.3: "Operator-NAS-Identifier MUST NOT occur more than once in a packet." What happens if it occurs more than once? Just ignore or send an error? From nobody Mon Aug 13 05:41:04 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 BD28B130EED; Mon, 13 Aug 2018 05:40:55 -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 SJa7-wQGw_1m; Mon, 13 Aug 2018 05:40:53 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id A7BAC128CF3; Mon, 13 Aug 2018 05:40:50 -0700 (PDT) Received: from [192.168.20.32] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 2BCDFD1; Mon, 13 Aug 2018 12:40:49 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <153416114103.25041.1808333930520958934.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2018 08:40:48 -0400 Cc: The IESG , Winter Stefan , radext-chairs@ietf.org, draft-ietf-radext-coa-proxy@ietf.org, radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7C61E065-2EFD-431B-923C-C130B32E35FA@deployingradius.com> References: <153416114103.25041.1808333930520958934.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-radext-coa-proxy-05=3A_=28with_COMMENT=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 13 Aug 2018 12:40:56 -0000 > On Aug 13, 2018, at 7:52 AM, Mirja K=C3=BChlewind = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-radext-coa-proxy-05: No Objection > Thanks for this well-written doc. >=20 > One nit in sec 3.1: s/activee/active/ Fixed/ > One quick question on sec 3.3: > "Operator-NAS-Identifier MUST NOT occur more than once in a packet." > What happens if it occurs more than once? Just ignore or send an = error? Ignore it. I'll add some text: If a packet contains more than one Operator-NAS-Identifier, implementations MUST treat the second and subsequent attributes as "invalid attributes", as discussed in [RFC6929] Section 2.8.= From nobody Mon Aug 13 06:32:40 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 AA0C3130DE6 for ; Mon, 13 Aug 2018 06:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 3294hBAeMHkc for ; Mon, 13 Aug 2018 06:32:36 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF0D130F12 for ; Mon, 13 Aug 2018 06:32:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=BlnTx3XlgX47MJqPHvh7/BoUWxx6KNjVrcOro6TCzu5T4It/bJ2tvN8w37LoLlXuLfjQzVNtODTwZqXkGN5JIqNDwEspx+TXk4oyMWetzkhWUyPQOXdSDqXHSGiBqiF8GbJIiLArGeWa2oOP4Wiq/ZDi7xW3w9DK924HX0wABJs=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 2650 invoked from network); 13 Aug 2018 15:25:53 +0200 Received: from mue-88-130-61-222.dsl.tropolys.de (HELO ?192.168.178.24?) (88.130.61.222) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Aug 2018 15:25:53 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <7C61E065-2EFD-431B-923C-C130B32E35FA@deployingradius.com> Date: Mon, 13 Aug 2018 15:25:52 +0200 Cc: Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153416114103.25041.1808333930520958934.idtracker@ietfa.amsl.com> <7C61E065-2EFD-431B-923C-C130B32E35FA@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.3445.9.1) X-PPP-Message-ID: <20180813132553.2641.5140@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-radext-coa-proxy-05=3A_=28with_COMMENT=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 13 Aug 2018 13:32:38 -0000 > Am 13.08.2018 um 14:40 schrieb Alan DeKok : >=20 >=20 >> On Aug 13, 2018, at 7:52 AM, Mirja K=C3=BChlewind = wrote: >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-radext-coa-proxy-05: No Objection >=20 >> Thanks for this well-written doc. >>=20 >> One nit in sec 3.1: s/activee/active/ >=20 > Fixed/ >=20 >> One quick question on sec 3.3: >> "Operator-NAS-Identifier MUST NOT occur more than once in a packet." >> What happens if it occurs more than once? Just ignore or send an = error? >=20 > Ignore it. I'll add some text: >=20 >=20 > If a packet contains more than one Operator-NAS-Identifier, > implementations MUST treat the second and subsequent attributes as > "invalid attributes", as discussed in [RFC6929] Section 2.8. Thanks, I didn=E2=80=99t check RFC6929 but it probably doesn=E2=80=99t = hurt to be clear about this in this document as well. Mirja= From nobody Mon Aug 13 15:35:14 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 9A82E1310EE; Mon, 13 Aug 2018 15:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, 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 sJlT-NnrT4bW; Mon, 13 Aug 2018 15:35:05 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 2FEE81310D8; Mon, 13 Aug 2018 15:35:05 -0700 (PDT) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 77B39E0445; Mon, 13 Aug 2018 22:35:04 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id 39A2020705; Mon, 13 Aug 2018 22:35:04 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" Reply-To: iana-matrix@iana.org In-Reply-To: References: <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1118137 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org CC: radext@ietf.org, lionel.morand@orange.com, kaduk@mit.edu, dime@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 13 Aug 2018 22:35:04 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [radext] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 22:35:08 -0000 Hi all, These RADIUS Attribute Type registrations now read as follows: Value: 124 Description: MIP6-Feature-Vector Data Type: integer64 Reference: [RFC5447] Value: 125 Description: MIP6-Home-Link-Prefix Data Type: string Reference: [RFC5447] Please see https://www.iana.org/assignments/radius-types These updates were made after we received confirmation from Lionel Morand and Benjamin Kaduk. Best regards, Amanda Baber Lead IANA Services Specialist On Mon Aug 06 13:00:05 2018, aland@deployingradius.com wrote: > On Aug 6, 2018, at 8:01 AM, Denis Ovsienko > wrote: > > Recently I was reviewing some code that adds support for two RFC 5447 > > RADIUS AVPs below: > > > > The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString > > The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and > > > > It turned out, the current RADIUS Types registry at > > https://www.iana.org/assignments/radius-types/radius-types.xhtml > > lists both attributes with wrong types: > > > > 125 MIP6-Home-Link-Prefix ipv6prefix [RFC5447] > > That is definitely wrong. The "ipv6prefix" format is different than > the one used by MIP6-Home-Link-Prefix in RFC 5337. > > > 124 MIP6-Feature-Vector string [RFC5447] > > That issue is a bit different. 64-bit integers were defined in RFC > 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after RFC > 5447 was published. > > So at the time RFC 5447 was published, "string" was the correct > definition. > > > Those incorrect types had propagated from the IANA registry into > > FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home- > > Link-Prefix, see the discussion and the follow-ups at > > https://github.com/the-tcpdump-group/tcpdump/pull/636 if interested). > > > > Having studied this discrepancy thoroughly, I had concluded the AVP > > definitions are correct in RFC 5447, so I did not file an erratum. > > The problem seems to be with those IANA allocations only. Could > > somebody review this issue and put the IANA allocations right? > > In the end, I think that the incorrect IANA allocations were a result > of the updates done in RFC 8044. The early drafts had a table which > updated all of the IANA data types, e.g.: > > https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section-4.2 > > The MIP6 attributes are listed there as "ipv6prefix" and "string". As > the author of RFC 8044, I think that's my mistake. Updating hundreds > of attributes required reading many RFCs, and it's understandable that > a few mistakes were made. > > Unless there are objections from DIME or RADEXT, I think it would be > best for IANA to update the registry as follows: > > 125 MIP6-Home-Link-Prefix string [RFC5447] > 124 MIP6-Feature-Vector integer64 [RFC5447] > > We may need approval from the AD (Ben). Explicit consensus from the > WG would also be helpful. > > Alan DeKok. From nobody Mon Aug 13 17:25:13 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 9685C1310FE; Mon, 13 Aug 2018 17:24:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tim Evens To: Cc: radext@ietf.org, draft-ietf-radext-coa-proxy.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153420629857.24982.2722057727598250846@ietfa.amsl.com> Date: Mon, 13 Aug 2018 17:24:58 -0700 Archived-At: Subject: [radext] Genart last call review of draft-ietf-radext-coa-proxy-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 00:24:59 -0000 Reviewer: Tim Evens Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-radext-coa-proxy-?? Reviewer: Tim Evens Review Date: 2018-08-13 IETF LC End Date: 2018-08-13 IESG Telechat date: 2018-08-16 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Major issues: Minor issues: Nits/editorial comments: Abstract contains "Section 3.1" which becomes an HTML reference link. This incorrectly links to the current draft section 3.1, not the intended RFC5176 Section 3.1. This is repeated in the introduction. IMO, that last sentence would read better with "corrects the omission" instead of "that." Code points are not summarized in IANA Considerations section. The references are not formatted per RFC7322. The HTML rendering of Section 2.2 CoA Processing does not render the RFC5176 link correctly. Bracketed references normally are followed by some text. IMO, considering this draft updates 5176, I feel it would be better for the problem statement to be clearer on updates and clarifications. In section 3.3, while humorous, I suggest dropping "on the planet." Section 6 Security Considerations link for Section 11 of RFC6929 is missing keyword "of." This results in two links instead of the correct link. From nobody Mon Aug 13 19:06:54 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 7DE20130E5B; Mon, 13 Aug 2018 19:06:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2018 19:06:51 -0700 Archived-At: Subject: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 02:06:51 -0000 Adam Roach has entered the following ballot position for draft-ietf-radext-coa-proxy-05: 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: ---------------------------------------------------------------------- I'd like to thank the author and all other involved parties for the work that has gone into making CoA transactions work across multiple domains. I have a couple of DISCUSS points that I think need to be cleared up. --------------------------------------------------------------------------- This is a concern with the general mechanism, and might be due to a misunderstanding on my part (which I hope you can clear up); but if I'm not wrong, then I'm concerned that the mechanism as described can introduce RADIUS message routing loops in some very common deployment scenarios. Consider a setup involving three networks: a Visited network (with its NAS and a Radius server), a Clearinghouse network (with one or more proxies), and a Home network (with a border proxy and a Home Server). Both the Home and Visited network also have federated networks that they communicate directly with without traversing the Clearinghouse network. The Clearinghouse determines the destination of any request message by looking at the realm portion of the NAI present in the "User-Name" attribute, which I believe is pretty common routing logic in these kinds of cases. Now, consider what happens when the Home network updates to use this mechanism (in order to better work with their federated partners), and the Visited network also updates to use this mechanism (for the same reason), but the Clearinghouse is not yet updated. I'll try to step through section 5 with this scenario: 1) The NAS in the Visited network sends an Access-Request packet to the Visited Radius server. The visited RADIUS server will see that the user is roaming, and will add an Operator-Name attribute, with value "1" followed by it's own realm name. e.g. "1example.com". 2) The visited RADIUS server will then proxy the authentication request to the Clearinghouse network, which uses the NAI in the User-Name to forward it to the Home network. 3) The Home Server records the Operator-Name along with other information about the users session 4) When the Home Server determines that a user should be disconnected, it looks up the Operator-Name, along with other user session identifiers as described in [RFC5176]. 5) The Home Server sends the Disconnect-Request to the Home domain's border proxy. 6) The Home domain's border proxy looks up the Operator-Name in the Disconnect-Request message, determines that it is an operator that it is not federated with, and consequently sends the Disconnect-Request to the Clearinghouse. 7) The Clearinghouse receives the Disconnect-Request message. Since it has not yet been updated to handle the Operator-Name attribute as described in this document, it follows its normal logic of routing according to the NAI in the User-Name attribute. 8) Go to 6 --------------------------------------------------------------------------- §4.2: > The value SHOULD be cryptographically strong, and SHOULD be > verifiable by the Visited Network, without requiring it to track in a > database every individual value of Operator-NAS-identifier which was > issued. I don't think this is really phrased in a way that means what you want to say. If I had to guess, you mean to say that the value must be encrypted, and that it must be integrity-protected. If integrity protection is important, then you also need to consider techniques to avoid replay of previously-seen tokens (e.g., the integrity protection needs to be over not just the Operator-NAS-Identifier, but also over some portion of the session that prevents its replay). Most notably, this desire for encryption and integrity protection is almost certainly at odds with the assertion (in §3.3) that "A twenty octet string is more than sufficient to individually address all of the NASes on the planet." For example, the naïve approach of appending a SHA-256 hash to the end of an encrypted, salted index into a table of NAS devices would require over 32 bytes at its absolute minimum. So, if integrity protection is something that any operator might ever want, you need to revisit the 20-byte limit. > Exactly how this requirement is implemented is outside of the scope > of this document. That's fair, but I think you need a proof-of-concept example of how it could be done, so that you find any additional corner cases beyond the one I've identified above. I think these aspects of this attribute need a lot more treatment in Section 6. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- All of my comments are editorial nits. --------------------------------------------------------------------------- ID Nits reports: ** The abstract seems to contain references ([RFC7542]), which it shouldn't. Please replace those with straight textual mentions of the documents in question (e.g., "RFC 7542"). --------------------------------------------------------------------------- §2.1: > Other methods are > possible, but we restrict ourselves to this usage, as it is the most > common one. This needs to be clear whether the *description* is restricted to NAI-based routing, or whether the *mechanism* is. I suspect it's the former; in any case, please add text. --------------------------------------------------------------------------- §2.1: > Once > a response has been received by the proxy, it can discard all > information about the request packet. Nit: "Once a response has been sent by the proxy..." ^^^^ --------------------------------------------------------------------------- §3.2: > We therefore need a way to identifier a NAS in the Visited Network, Nit: "...to identify a NAS..." --------------------------------------------------------------------------- §3.3: > We suggest that the contents of the NAS-Identifier be the Realm name > of the Visited Network. That is, for everyone outside of the Visited > Network, there is only one NAS: the Visited Network itself. For the > Visited Network, the identity of the NAS is private information, > which is opaque to everyone else. Please be clear that this recommendation is for the (existing) NAS-Identifier attribute rather than the (new) Operator-NAS-Identifier attribute. --------------------------------------------------------------------------- §3.3: > This token MUST allow the Visited Network to direct the packet to > the NAS for the users session. Nit: "...user's session..." --------------------------------------------------------------------------- §4.2: > CoA server (i.e. NAS). This requirement is phrase more generically > below, in Section 4.3.2. Nit: "...phrased..." --------------------------------------------------------------------------- §4.3.1: > it SHOULD return a > CoA-NAK or Disconnect-NAK packet, that contains an Error-Cause > attribute having value 503 ("Session Context Not Found"). Nit: "...packet that contains..." From nobody Tue Aug 14 06:02:43 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 DABE5130DDA; Tue, 14 Aug 2018 06:02:34 -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 MRk1Y6Rm9lPX; Tue, 14 Aug 2018 06:02:32 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 26C4A130DF7; Tue, 14 Aug 2018 06:02:32 -0700 (PDT) Received: from [192.168.20.32] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 5D278D1; Tue, 14 Aug 2018 13:02:30 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> Date: Tue, 14 Aug 2018 09:02:30 -0400 Cc: The IESG , Winter Stefan , radext-chairs@ietf.org, draft-ietf-radext-coa-proxy@ietf.org, radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 14 Aug 2018 13:02:35 -0000 On Aug 13, 2018, at 10:06 PM, Adam Roach wrote: > This is a concern with the general mechanism, and might be due to a > misunderstanding on my part (which I hope you can clear up); but if = I'm not > wrong, then I'm concerned that the mechanism as described can = introduce RADIUS > message routing loops in some very common deployment scenarios. I don't think so, for the simple reason that clearing houses don't = accept CoA packets right now. There are other reasons. > 5) The Home Server sends the Disconnect-Request to the Home domain's = border > proxy. >=20 > 6) The Home domain's border proxy looks up the Operator-Name in the > Disconnect-Request message, determines that it is an operator that = it is > not federated with, and consequently sends the Disconnect-Request to = the > Clearinghouse. Note that 6 depends on 5. i.e. the Home domain border proxy should = *not* accept random packets, even from trusted parties, and proxy them = to random destinations. Doing so would be a violation of a host of = security issues. The Home domain border proxy MUST implement the following rules: - CoA packets from inside the network (i.e. trusted packets) can be = proxied externally - CoA packets from outside the network (i.e. less trusted packets) MUST = contain the realm of the Home domain. All other packets MUST be NAKd. These rules are already applied for Access-Request and = Accounting-Request packets. > 7) The Clearinghouse receives the Disconnect-Request message. Since it = has not > yet been updated to handle the Operator-Name attribute as described = in this > document, ... it discards the packet as unknown. At the *network* layer, = because nothing is even listening on the CoA port (3759). If the clearing house receives the CoA packet on one of the normal = RADIUS ports (1812 or 1813), it also discards the packet, as those ports = are only supposed to be for Access-Request and Accounting-Request = packets. If the clearing house implements RADIUS over TCP/TLS, then it's = permitted to accept any packet (CoA or otherwise) on that port. = However... it must also have processing rules for those packets in = place. And since there is currently no way to proxy CoA packets, it = will discard the packet. > it follows its normal logic of routing according to the NAI in the > User-Name attribute. It should not follow the normal logic of routing according to the NAI. = For one, clearing houses currently only deal with Access-Request and = Accounting-Request packets. Any *other* packet they receive is silently = discarded. So in order for a loop to exist, multiple things have to go wrong: - the clearing house has to accept CoA packets (none do right now) - the clearing house has to be configured to use the NAI for forwarding = CoA packets (no RADIUS server does this) - the home domain proxy has to accept external packets for third-party = domains, and forward them (all these systems have rules in place now to = prevent this). I'll see if I can clarify this issue in the document. >> The value SHOULD be cryptographically strong, and SHOULD be >> verifiable by the Visited Network, without requiring it to track in a >> database every individual value of Operator-NAS-identifier which was >> issued. >=20 > I don't think this is really phrased in a way that means what you want = to say. > If I had to guess, you mean to say that the value must be encrypted, = and that it > must be integrity-protected. If integrity protection is important, = then you also > need to consider techniques to avoid replay of previously-seen tokens Why is replay an issue? The point of obfuscating the information is = to hide internal / private information about the network. e.g. private = IP of the NAS. If a home server replays a previously-seen token, then one of two = things will happen: - the packet will go to the NAS which hosts the user session, and will = be processed normally - the packet will go to a different NAS, and will be NAKd > (e.g., the > integrity protection needs to be over not just the = Operator-NAS-Identifier, > but also over some portion of the session that prevents its replay). = Most > notably, this desire for encryption and integrity protection is almost > certainly at odds with the assertion (in =C2=A73.3) that "A twenty = octet string is > more than sufficient to individually address all of the NASes on the = planet." > For example, the na=C3=AFve approach of appending a SHA-256 hash to = the end of an > encrypted, salted index into a table of NAS devices would require over = 32 bytes > at its absolute minimum. So, if integrity protection is something that = any > operator might ever want, you need to revisit the 20-byte limit. 32 bytes is fine. I'll update that. >> Exactly how this requirement is implemented is outside of the scope >> of this document. >=20 > That's fair, but I think you need a proof-of-concept example of how it = could be > done, so that you find any additional corner cases beyond the one I've > identified above. Fair enough. > I think these aspects of this attribute need a lot more treatment in = Section 6. I'll add some text. > ** The abstract seems to contain references ([RFC7542]), which it > shouldn't. Please replace those with straight textual mentions of = the > documents in question (e.g., "RFC 7542"). Fixed. >> Other methods are >> possible, but we restrict ourselves to this usage, as it is the most >> common one. >=20 > This needs to be clear whether the *description* is restricted to = NAI-based > routing, or whether the *mechanism* is. I suspect it's the former; in = any case, > please add text. This spec documents NAI-based CoA proxying. Other methods can be = used, but aren't discussed here. The mechanism for discovering next hop is specific to NAI-based = proxying. > = --------------------------------------------------------------------------= - >=20 > =C2=A72.1: >=20 >> Once >> a response has been received by the proxy, it can discard all >> information about the request packet. >=20 > Nit: "Once a response has been sent by the proxy..." > ^^^^ Fixed. > = --------------------------------------------------------------------------= - >=20 > =C2=A73.2: >=20 >> We therefore need a way to identifier a NAS in the Visited Network, >=20 > Nit: "...to identify a NAS..." Fixed. > = --------------------------------------------------------------------------= - >=20 > =C2=A73.3: >=20 >> We suggest that the contents of the NAS-Identifier be the Realm name >> of the Visited Network. That is, for everyone outside of the Visited >> Network, there is only one NAS: the Visited Network itself. For the >> Visited Network, the identity of the NAS is private information, >> which is opaque to everyone else. >=20 > Please be clear that this recommendation is for the (existing) = NAS-Identifier > attribute rather than the (new) Operator-NAS-Identifier attribute. I'll update the text. > = --------------------------------------------------------------------------= - >=20 > =C2=A73.3: >=20 >> This token MUST allow the Visited Network to direct the packet to >> the NAS for the users session. >=20 > Nit: "...user's session..." Fixed. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.2: >=20 >> CoA server (i.e. NAS). This requirement is phrase more generically >> below, in Section 4.3.2. >=20 > Nit: "...phrased..." Fixed. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.3.1: >=20 >> it SHOULD return a >> CoA-NAK or Disconnect-NAK packet, that contains an Error-Cause >> attribute having value 503 ("Session Context Not Found"). >=20 > Nit: "...packet that contains..." Fixed. Alan DeKok. From nobody Tue Aug 14 06:17:02 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 129A11277D2 for ; Tue, 14 Aug 2018 06:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 bQQrl5mXm79g for ; Tue, 14 Aug 2018 06:16:58 -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 B607A130DDA for ; Tue, 14 Aug 2018 06:16:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6C8BCB80AF1; Tue, 14 Aug 2018 06:16:50 -0700 (PDT) To: aland@freeradius.org, ibagdona@gmail.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: <20180814131650.6C8BCB80AF1@rfc-editor.org> Date: Tue, 14 Aug 2018 06:16:50 -0700 (PDT) Archived-At: Subject: [radext] [Technical Errata Reported] RFC7542 (5462) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 14 Aug 2018 13:17:00 -0000 The following errata report has been submitted for RFC7542, "The Network Access Identifier". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5462 -------------------------------------- Type: Technical Reported by: Alan DeKok Section: 3 Original Text ------------- The "utf8-realm" SHOULD be supplied by the "next hop" or "home" system that also supplies the routing information necessary for packets to reach the next hop. Corrected Text -------------- The "utf8-realm" SHOULD be supplied by the "next hop" or "home" system that also supplies the routing information necessary for packets to reach the next hop. The final home system SHOULD validate the NAI in the received packet against the list of Realms hosted by the home system. If no match is found, the request SHOULD be rejected. Notes ----- It doesn't explicitly say that home systems only authenticate users for their own realms. It may help to have this stated explicitly. Some text will also be added to draft-ietf-radext-coa-proxy in order to make this clearer. 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. -------------------------------------- RFC7542 (draft-ietf-radext-nai-15) -------------------------------------- Title : The Network Access Identifier Publication Date : May 2015 Author(s) : A. DeKok Category : PROPOSED STANDARD Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Aug 14 06:18:39 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 3CDC7130EA6; Tue, 14 Aug 2018 06:18:37 -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 15F42y3Jnwtx; Tue, 14 Aug 2018 06:18:35 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8B680130E98; Tue, 14 Aug 2018 06:18:35 -0700 (PDT) Received: from [192.168.20.32] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 0BE3DD1; Tue, 14 Aug 2018 13:18: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: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> Date: Tue, 14 Aug 2018 09:18:32 -0400 Cc: The IESG , Winter Stefan , radext-chairs@ietf.org, draft-ietf-radext-coa-proxy@ietf.org, radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5590E330-FF45-450E-9324-22CB403EA477@deployingradius.com> References: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 14 Aug 2018 13:18:37 -0000 On Aug 13, 2018, at 10:06 PM, Adam Roach wrote: >=20 > This is a concern with the general mechanism, and might be due to a > misunderstanding on my part (which I hope you can clear up); but if = I'm not > wrong, then I'm concerned that the mechanism as described can = introduce RADIUS > message routing loops in some very common deployment scenarios. Just to be clear: RFC 7542 (NAI) doesn't say that home networks only = accept packets for their own Realms. This could perhaps be said = explicitly. I've submitted an errata to RFC 7542 with some text. I'll also update this document to clarify this situation. Alan DeKok. From nobody Tue Aug 14 06:43: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 E7061130E98; Tue, 14 Aug 2018 06:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 isi2bHqzEkDN; Tue, 14 Aug 2018 06:43:49 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 38C9E12F1A6; Tue, 14 Aug 2018 06:43:49 -0700 (PDT) Received: from Orochi.local (c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7EDhNHl030901 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Aug 2018 08:43:24 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7] claimed to be Orochi.local To: Alan DeKok Cc: Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org References: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <0d9cc14c-d065-87fa-5ea1-f76fde1c9c2f@nostrum.com> Date: Tue, 14 Aug 2018 08:43:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 14 Aug 2018 13:43:51 -0000 On 8/14/18 08:02, Alan DeKok wrote: > On Aug 13, 2018, at 10:06 PM, Adam Roach wrote: >> This is a concern with the general mechanism, and might be due to a >> misunderstanding on my part (which I hope you can clear up); but if I'm not >> wrong, then I'm concerned that the mechanism as described can introduce RADIUS >> message routing loops in some very common deployment scenarios. > I don't think so, for the simple reason that clearing houses don't accept CoA packets right now. > > There are other reasons. Thanks. This (and the rest of your explanation) makes sense. >>> The value SHOULD be cryptographically strong, and SHOULD be >>> verifiable by the Visited Network, without requiring it to track in a >>> database every individual value of Operator-NAS-identifier which was >>> issued. >> I don't think this is really phrased in a way that means what you want to say. >> If I had to guess, you mean to say that the value must be encrypted, and that it >> must be integrity-protected. If integrity protection is important, then you also >> need to consider techniques to avoid replay of previously-seen tokens > Why is replay an issue? The point of obfuscating the information is to hide internal / private information about the network. e.g. private IP of the NAS. Generally, when integrity is important, so is anti-replay. If you care that remote parties can't create their own novel values, it would be surprising not to care about them squirreling away values they've seen before and using them later. Conversely, if you don't care about replay, you probably need to think really hard about why you care about integrity. Of course, it's completely possible that I'm misunderstanding what you mean by "verifiable" in the original text (which gets to the heart of my original comment: there are terms of art for the properties that cryptography provides, and you really want to use them for the purpose of clarity.) > If a home server replays a previously-seen token, then one of two things will happen: > > - the packet will go to the NAS which hosts the user session, and will be processed normally > > - the packet will go to a different NAS, and will be NAKd Sure. If that's the answer, then it seems like it's the same answer if the home server creates a new, invalid token; and that would mean that integrity isn't needed. I'm afraid you need to go back and figure out what your actual security requirements are here by asking what attacks might exist, and what their consequences are. The current text seems to be kind of an afterthought without any real analysis. > >> (e.g., the >> integrity protection needs to be over not just the Operator-NAS-Identifier, >> but also over some portion of the session that prevents its replay). Most >> notably, this desire for encryption and integrity protection is almost >> certainly at odds with the assertion (in §3.3) that "A twenty octet string is >> more than sufficient to individually address all of the NASes on the planet." >> For example, the naïve approach of appending a SHA-256 hash to the end of an >> encrypted, salted index into a table of NAS devices would require over 32 bytes >> at its absolute minimum. So, if integrity protection is something that any >> operator might ever want, you need to revisit the 20-byte limit. > 32 bytes is fine. I'll update that. Sorry, by "more than 32 bytes," I meant that the hash itself would take 32 bytes. You'd also have however long the Visited domain's identifier for the NAS is (which you originally thought would take 20 bytes), plus some number of nonce bytes (to prevent other networks from simply counting unique token values). You're really looking at more like 96 bytes or so. Note that this gets somewhat smaller if integrity protection isn't important. >>> Other methods are >>> possible, but we restrict ourselves to this usage, as it is the most >>> common one. >> This needs to be clear whether the *description* is restricted to NAI-based >> routing, or whether the *mechanism* is. I suspect it's the former; in any case, >> please add text. > This spec documents NAI-based CoA proxying. Other methods can be used, but aren't discussed here. > > The mechanism for discovering next hop is specific to NAI-based proxying. Okay; make this clearer, please. Thanks! /a From nobody Tue Aug 14 08:01:34 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 B9F7812426A; Tue, 14 Aug 2018 08:01:32 -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 XpQ7VMOsrKHR; Tue, 14 Aug 2018 08:01:30 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6B1130DC8; Tue, 14 Aug 2018 08:01:30 -0700 (PDT) Received: from [192.168.20.32] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id C10F14DB; Tue, 14 Aug 2018 15:01:28 +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: <0d9cc14c-d065-87fa-5ea1-f76fde1c9c2f@nostrum.com> Date: Tue, 14 Aug 2018 11:01:27 -0400 Cc: Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> <0d9cc14c-d065-87fa-5ea1-f76fde1c9c2f@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 14 Aug 2018 15:01:33 -0000 On Aug 14, 2018, at 9:43 AM, Adam Roach wrote: > Generally, when integrity is important, so is anti-replay. If you care = that remote parties can't create their own novel values, it would be = surprising not to care about them squirreling away values they've seen = before and using them later. Conversely, if you don't care about replay, = you probably need to think really hard about why you care about = integrity. >=20 > Of course, it's completely possible that I'm misunderstanding what you = mean by "verifiable" in the original text (which gets to the heart of my = original comment: there are terms of art for the properties that = cryptography provides, and you really want to use them for the purpose = of clarity.) In this situation, all we really care about is that the opaque token = is known. And it really should be opaque. It's just bits, and not = necessarily containing anything in particular. >> If a home server replays a previously-seen token, then one of two = things will happen: >>=20 >> - the packet will go to the NAS which hosts the user session, and = will be processed normally >>=20 >> - the packet will go to a different NAS, and will be NAKd >=20 > Sure. If that's the answer, then it seems like it's the same answer if = the home server creates a new, invalid token; and that would mean that = integrity isn't needed. Yes. > I'm afraid you need to go back and figure out what your actual = security requirements are here by asking what attacks might exist, and = what their consequences are. The current text seems to be kind of an = afterthought without any real analysis. Maybe I'm missing something, but it's pretty hard to "attack" an = opaque token. It can be (a) modified, or (b) replayed. If it's = modified, it doesn't match anything and it gets ignored. If it's = replayed, it's still a recognized token, and that's OK. All of the attacks here *also* depend on systems knowing the RADIUS = shared secret. i.e. these systems are already part of a trusted = network. They are already trusted to not replay accounting packets, = authentication packets, forge accounting traffic (to increase bills), = etc. The attacks for CoA here are nothing new. The security is terrible, = but we've lived with it for 25+ years, and it's what we have. Finally, if trusted parties attack you, the fix is usually legal, not = technical. I'll update the Security Considerations section with some text on why = roaming consortiums are open to forging. But I think the risks here are = fairly well known. > Sorry, by "more than 32 bytes," I meant that the hash itself would = take 32 bytes. You'd also have however long the Visited domain's = identifier for the NAS is (which you originally thought would take 20 = bytes), plus some number of nonce bytes (to prevent other networks from = simply counting unique token values). You're really looking at more like = 96 bytes or so. >=20 > Note that this gets somewhat smaller if integrity protection isn't = important. Integrity protection isn't important. Alan DeKok. From nobody Tue Aug 14 08:51:42 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 37335130E22; Tue, 14 Aug 2018 08:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 6VVg_q1VIPnL; Tue, 14 Aug 2018 08:51:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 ADE16130E0A; Tue, 14 Aug 2018 08:51:32 -0700 (PDT) Received: from Orochi.local (c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7EFpKRq052077 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Aug 2018 10:51:21 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7] claimed to be Orochi.local To: Alan DeKok Cc: Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org References: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> <0d9cc14c-d065-87fa-5ea1-f76fde1c9c2f@nostrum.com> From: Adam Roach Message-ID: Date: Tue, 14 Aug 2018 10:51:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 14 Aug 2018 15:51:35 -0000 On 8/14/18 10:01, Alan DeKok wrote: > On Aug 14, 2018, at 9:43 AM, Adam Roach wrote: >> Generally, when integrity is important, so is anti-replay. If you care that remote parties can't create their own novel values, it would be surprising not to care about them squirreling away values they've seen before and using them later. Conversely, if you don't care about replay, you probably need to think really hard about why you care about integrity. >> >> Of course, it's completely possible that I'm misunderstanding what you mean by "verifiable" in the original text (which gets to the heart of my original comment: there are terms of art for the properties that cryptography provides, and you really want to use them for the purpose of clarity.) > In this situation, all we really care about is that the opaque token is known. And it really should be opaque. It's just bits, and not necessarily containing anything in particular. I think we're getting off in the weeds here exactly because the language in the document is ambiguous. I think I made some assumptions that might not match yours. Let's try a level set. The document says that the token "SHOULD be cryptographically strong." What does this mean, and why do you need it? The document says that the token "SHOULD be verifiable by the Visited Network." What does this mean, and why do you need it? /a From nobody Tue Aug 14 09:11:18 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 A9023130E58; Tue, 14 Aug 2018 09:11: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 ySG6JyaYF1zz; Tue, 14 Aug 2018 09:11:07 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 82BB0130934; Tue, 14 Aug 2018 09:11:07 -0700 (PDT) Received: from [192.168.20.32] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 0451CD1; Tue, 14 Aug 2018 16:11:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Tue, 14 Aug 2018 12:11:04 -0400 Cc: Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <44429A5F-F978-4D7B-8330-C6A665E8BF53@deployingradius.com> References: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> <0d9cc14c-d065-87fa-5ea1-f76fde1c9c2f@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 14 Aug 2018 16:11:10 -0000 On Aug 14, 2018, at 11:51 AM, Adam Roach wrote: > I think we're getting off in the weeds here exactly because the = language in the document is ambiguous. I think I made some assumptions = that might not match yours. Let's try a level set. >=20 > The document says that the token "SHOULD be cryptographically strong." = What does this mean, and why do you need it? The Operator-NAS-Identifier may contain information, such as an = encrypted IP address. In which case it should use sane encryption = methods. If it's just an opaque token, then the token value should be created = via some sane method. Mainly to avoid accidental re-use. > The document says that the token "SHOULD be verifiable by the Visited = Network." What does this mean, and why do you need it? The visited network needs to know that the token maps to an actual = NAS. If the token is an encrypted blob, it can decrypt the blob and verify = it that way. If the token is an opaque value, then the network needs to = store the values it sends out. Incoming values are then checked against = the list to see if they're known. I think part of the confusion is that I don't want to restrict how = people use it. It might be simpler to just give one recommendation, and = leave it at that. Alan DeKok. From nobody Tue Aug 14 10:16:49 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 6EE24130934; Tue, 14 Aug 2018 10:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 G_kMpI8Gtyri; Tue, 14 Aug 2018 10:16:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 78708128CB7; Tue, 14 Aug 2018 10:16:45 -0700 (PDT) Received: from Orochi.local (c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7EHGTdF066169 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Aug 2018 12:16:30 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7] claimed to be Orochi.local To: Alan DeKok Cc: Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org References: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> <0d9cc14c-d065-87fa-5ea1-f76fde1c9c2f@nostrum.com> <44429A5F-F978-4D7B-8330-C6A665E8BF53@deployingradius.com> From: Adam Roach Message-ID: <680f1611-e86a-abd1-fb5f-63f27a265226@nostrum.com> Date: Tue, 14 Aug 2018 12:16:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <44429A5F-F978-4D7B-8330-C6A665E8BF53@deployingradius.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 14 Aug 2018 17:16:47 -0000 On 8/14/18 11:11, Alan DeKok wrote: > On Aug 14, 2018, at 11:51 AM, Adam Roach wrote: >> I think we're getting off in the weeds here exactly because the language in the document is ambiguous. I think I made some assumptions that might not match yours. Let's try a level set. >> >> The document says that the token "SHOULD be cryptographically strong." What does this mean, and why do you need it? > The Operator-NAS-Identifier may contain information, such as an encrypted IP address. In which case it should use sane encryption methods. > > If it's just an opaque token, then the token value should be created via some sane method. Mainly to avoid accidental re-use. You've described what you mean, without saying why you need it, and so I'm not sure what you mean achieves what you think you need -- and I have have a creeping suspicion that it does not. I *think* the idea here is hiding things like how many NASes you have deployed in your network [1]. If that's the case, you'll minimally need some guidance here about each token being encrypted separately, using a unique nonce. I'll note that the creation of opaque tokens that don't differ between requests (as you seem to suggest above) doesn't achieve the goal of hiding the number of NASes -- it's not harder to count unique opaque tokens than it is to count IP addresses. >> The document says that the token "SHOULD be verifiable by the Visited Network." What does this mean, and why do you need it? > The visited network needs to know that the token maps to an actual NAS. > > If the token is an encrypted blob, it can decrypt the blob and verify it that way. Sorry, verify it how? Let's say my token generation scheme is to take the IP address of the NAS, pack it up in network byte order, and run it through some encryption algorithm. So, I get a blob in a Disconnect-Request message, run it through decryption, and get four bytes:  136, 35, 8, and 43. That looks like a valid IP address to me. I still can't tell whether I generated the blob, or whether someone else just created a random blob and that's what it happened to decrypt to -- because most four-byte sequences are valid IPv4 addresses. And, as for needing to know that it maps to an actual NAS: why? If the something is messing up these tokens and the worst thing that happens is that the transaction fails, that seems to be fine. /a ____ [1] I'm basing this in part on the text from §6: "This ensures that anyone observing unencrypted RADIUS traffic gains no information about the internals of the Visited Network." From nobody Tue Aug 14 10:31:55 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 CD305130EFC; Tue, 14 Aug 2018 10:31:43 -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 Arav3fquW1i1; Tue, 14 Aug 2018 10:31:42 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id B4051130EEC; Tue, 14 Aug 2018 10:31:41 -0700 (PDT) Received: from [192.168.20.32] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 380FF610; Tue, 14 Aug 2018 17:31:40 +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: <680f1611-e86a-abd1-fb5f-63f27a265226@nostrum.com> Date: Tue, 14 Aug 2018 13:31:38 -0400 Cc: Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> <0d9cc14c-d065-87fa-5ea1-f76fde1c9c2f@nostrum.com> <44429A5F-F978-4D7B-8330-C6A665E8BF53@deployingradius.com> <680f1611-e86a-abd1-fb5f-63f27a265226@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 14 Aug 2018 17:31:48 -0000 On Aug 14, 2018, at 1:16 PM, Adam Roach wrote: > You've described what you mean, without saying why you need it, and so = I'm not sure what you mean achieves what you think you need -- and I = have have a creeping suspicion that it does not. Let me back up. The scheme could work just as well if Operator-NAS-Identifier = contained the actual IP address of the NAS. The main reason to make it private is that there is no compelling = reason to make it public. And as a general rule, keeping private things = private is a good idea. > I *think* the idea here is hiding things like how many NASes you have = deployed in your network [1]. If that's the case, you'll minimally need = some guidance here about each token being encrypted separately, using a = unique nonce. I don't think that's necessary. See below. > I'll note that the creation of opaque tokens that don't differ between = requests (as you seem to suggest above) doesn't achieve the goal of = hiding the number of NASes -- it's not harder to count unique opaque = tokens than it is to count IP addresses. Of course. That being said... Access-Request and Accounting-Request = packets typically contain the MAC address of the NAS. So the number of = NASes is already public information. >>> The document says that the token "SHOULD be verifiable by the = Visited Network." What does this mean, and why do you need it? >> The visited network needs to know that the token maps to an actual = NAS. >>=20 >> If the token is an encrypted blob, it can decrypt the blob and = verify it that way. >=20 > Sorry, verify it how? It's probably better to just not refer to verifying the value. > Let's say my token generation scheme is to take the IP address of the = NAS, pack it up in network byte order, and run it through some = encryption algorithm. So, I get a blob in a Disconnect-Request message, = run it through decryption, and get four bytes: 136, 35, 8, and 43. That = looks like a valid IP address to me. I still can't tell whether I = generated the blob, or whether someone else just created a random blob = and that's what it happened to decrypt to -- because most four-byte = sequences are valid IPv4 addresses. >=20 > And, as for needing to know that it maps to an actual NAS: why? If the = something is messing up these tokens and the worst thing that happens is = that the transaction fails, that seems to be fine. Sure. To be honest, this is really getting into details which I don't think = matter in the real world. CoA packets are only accepted from trusted = parties. Or transitively, from parties they trust. All of those = parties have access to all of the user session identification = information. If the parties mangle the Operator-NAS-Identfifier, then = the transaction fails. So they have no reason to do so. And much of = the information about a NAS (and their number) is already public. Which means that there is substantially less reason to make the = Operator-NAS-Identifier unique, verifiable, etc. Just encrypt the IP = address, and it's fine. Or, create an opaque token per NAS, store = token/IP in a table, and it's fine. Any security issues with the contents of Operator-NAS-Identifier are = largely mitigated by the utter crap-fest that's the rest of RADIUS. = Which means that it doesn't really matter how the values of = Operator-NAS-Identifier are created, stored, or used. Alan DeKok. From nobody Tue Aug 14 10:33: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 40790130EE5; Tue, 14 Aug 2018 10:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 DK_xNyypWR9F; Tue, 14 Aug 2018 10:32:57 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 908F0130F13; Tue, 14 Aug 2018 10:32:56 -0700 (PDT) X-AuditID: 12074424-f17ff70000000202-25-5b731245b854 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 63.17.00514.642137B5; Tue, 14 Aug 2018 13:32:54 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w7EHWp0F015249; Tue, 14 Aug 2018 13:32:52 -0400 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.13.8/8.12.4) with ESMTP id w7EHWima030228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Aug 2018 13:32:48 -0400 Date: Tue, 14 Aug 2018 12:32:44 -0500 From: Benjamin Kaduk To: Adam Roach Cc: Alan DeKok , radext-chairs@ietf.org, Winter Stefan , The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext@ietf.org Message-ID: <20180814173244.GE40887@kduck.kaduk.org> References: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> <0d9cc14c-d065-87fa-5ea1-f76fde1c9c2f@nostrum.com> <44429A5F-F978-4D7B-8330-C6A665E8BF53@deployingradius.com> <680f1611-e86a-abd1-fb5f-63f27a265226@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <680f1611-e86a-abd1-fb5f-63f27a265226@nostrum.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIKsWRmVeSWpSXmKPExsUixCmqresmVBxt0PJJz2LP30XsFk2fm9gt 5j15ymox489EZounHV+YLFpezWSzmNfQyO7A7tFytIXFY8mSn0wes3Y+YfFY3uUTwBLFZZOS mpNZllqkb5fAlXH6wxHWggnSFV07t7I0MC4W7WLk5JAQMJHoXNnN2MXIxSEksJhJ4tqt7cwQ zkZGiZuLPrNCOFeZJHZ8eMkC0sIioCpx8cspdhCbTUBFoqH7MjOILSKgKNF2+CZYN7PAeUaJ kyv2AhVxcAgLZEk0P3YCMXmB1l3+qgG1jVmic8o5JpBeXgFBiZMzn4DNZxbQkdi59Q4bSD2z gLTE8n8cEGF5ieats8FWcQrYSxyef4INxBYVUJbY23eIfQKj4Cwkk2YhmTQLYdIsJJMWMLKs YpRNya3SzU3MzClOTdYtTk7My0st0jXXy80s0UtNKd3ECIoNdheVHYzdPd6HGAU4GJV4eAMu FUULsSaWFVfmHmKU5GBSEuVNZyuOFuJLyk+pzEgszogvKs1JLT7EKMHBrCTCK8MIlONNSays Si3Kh0lJc7AoifPerQmPFhJITyxJzU5NLUgtgsnKcHAoSfBmCgI1ChalpqdWpGXmlCCkmTg4 QYbzAA2fD1LDW1yQmFucmQ6RP8Woy/Hn/dRJzEIsefl5qVLivOcEgIoEQIoySvPg5oBSmkT2 /ppXjOJAbwnzvgOp4gGmQ7hJr4CWMAEtSRYpBFlSkoiQkmpgrKisqkrZt2HisfKmq019VczH 70099Djg0RtVsW1C+39NdElLevpq78aWvS9+nj3KxhdpIvCVjf8fn+E/W83AxwmPW9TspwfW l3zRNcl7LOFzKmRK45uuBfvP34g8HcwoV/l5nctNyRK9qg92UTFVz9jehmz+ka614PoKjimy Xfwzoq8EPdNdocRSnJFoqMVcVJwIACDvMXBEAwAA Archived-At: Subject: Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 14 Aug 2018 17:33:09 -0000 On Tue, Aug 14, 2018 at 12:16:28PM -0500, Adam Roach wrote: > On 8/14/18 11:11, Alan DeKok wrote: > > On Aug 14, 2018, at 11:51 AM, Adam Roach wrote: > >> I think we're getting off in the weeds here exactly because the language in the document is ambiguous. I think I made some assumptions that might not match yours. Let's try a level set. > >> > >> The document says that the token "SHOULD be cryptographically strong." What does this mean, and why do you need it? > > The Operator-NAS-Identifier may contain information, such as an encrypted IP address. In which case it should use sane encryption methods. > > > > If it's just an opaque token, then the token value should be created via some sane method. Mainly to avoid accidental re-use. > > You've described what you mean, without saying why you need it, and so > I'm not sure what you mean achieves what you think you need -- and I > have have a creeping suspicion that it does not. > > I *think* the idea here is hiding things like how many NASes you have > deployed in your network [1]. If that's the case, you'll minimally need > some guidance here about each token being encrypted separately, using a > unique nonce. I think when I read this, I was thinking "I don't want to expose the specific IP addresses of my NASes". Maybe because I'm squatting on some IP space that I shouldn't be, or maybe because I'm trying to set up a crisp shell around a soft gooey interior, or maybe something else. The mindset would then be more of a lookup table than "real" encryption. And if someone wants to muck around with my lookup table, they either miss and get NAK or they go to the wrong NAS and also get a NAK. -Benjamin > I'll note that the creation of opaque tokens that don't differ between > requests (as you seem to suggest above) doesn't achieve the goal of > hiding the number of NASes -- it's not harder to count unique opaque > tokens than it is to count IP addresses. > > > >> The document says that the token "SHOULD be verifiable by the Visited Network." What does this mean, and why do you need it? > > The visited network needs to know that the token maps to an actual NAS. > > > > If the token is an encrypted blob, it can decrypt the blob and verify it that way. > > Sorry, verify it how? > > Let's say my token generation scheme is to take the IP address of the > NAS, pack it up in network byte order, and run it through some > encryption algorithm. So, I get a blob in a Disconnect-Request message, > run it through decryption, and get four bytes:  136, 35, 8, and 43. That > looks like a valid IP address to me. I still can't tell whether I > generated the blob, or whether someone else just created a random blob > and that's what it happened to decrypt to -- because most four-byte > sequences are valid IPv4 addresses. > > And, as for needing to know that it maps to an actual NAS: why? If the > something is messing up these tokens and the worst thing that happens is > that the transaction fails, that seems to be fine. > > /a > > ____ > [1] I'm basing this in part on the text from §6: "This ensures that > anyone observing unencrypted RADIUS traffic gains no information about > the internals of the Visited Network." > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Aug 14 10:44:15 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 E2F36130E92; Tue, 14 Aug 2018 10:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 sjYP-U3khtxv; Tue, 14 Aug 2018 10:44:05 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8D1021277C8; Tue, 14 Aug 2018 10:44:05 -0700 (PDT) Received: from Orochi.local (c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7EHhnWb070678 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Aug 2018 12:43:51 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7] claimed to be Orochi.local To: Alan DeKok Cc: Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org References: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> <0d9cc14c-d065-87fa-5ea1-f76fde1c9c2f@nostrum.com> <44429A5F-F978-4D7B-8330-C6A665E8BF53@deployingradius.com> <680f1611-e86a-abd1-fb5f-63f27a265226@nostrum.com> From: Adam Roach Message-ID: Date: Tue, 14 Aug 2018 12:43:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 14 Aug 2018 17:44:07 -0000 On 8/14/18 12:31, Alan DeKok wrote: > Any security issues with the contents of Operator-NAS-Identifier are largely mitigated by the utter crap-fest that's the rest of RADIUS. Which means that it doesn't really matter how the values of Operator-NAS-Identifier are created, stored, or used. Perfect! That's what the document should say. Mostly, I was taking issue with language that implies that there is some level of security being applied to this token, and that the guidance and mechanisms in this draft were sufficient to even allow doing so (see, e.g., my comment on field sizes). Securing this field would be fine, if done correctly. Leaving it unsecured -- as is done with similar information in Radius -- is fine also. It's the middle-ground of security theater -- and, in this case, RFC-2119-language normative security theater --  that I think is dangerous. /a From nobody Tue Aug 14 13:00:25 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 16786130EB9; Tue, 14 Aug 2018 13:00:24 -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 VBZrLHyp3Jpk; Tue, 14 Aug 2018 13:00:22 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 22B30130EC7; Tue, 14 Aug 2018 13:00:21 -0700 (PDT) Received: from [192.168.20.32] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 5E5FD62; Tue, 14 Aug 2018 20:00:20 +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: <153420629857.24982.2722057727598250846@ietfa.amsl.com> Date: Tue, 14 Aug 2018 16:00:18 -0400 Cc: gen-art@ietf.org, radext@ietf.org, draft-ietf-radext-coa-proxy.all@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3333032E-47BC-4AF9-97D5-F02F7FC260D8@deployingradius.com> References: <153420629857.24982.2722057727598250846@ietfa.amsl.com> To: Tim Evens X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Genart last call review of draft-ietf-radext-coa-proxy-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 14 Aug 2018 20:00:24 -0000 On Aug 13, 2018, at 8:24 PM, Tim Evens = wrote: > Minor issues: >=20 > Nits/editorial comments:=20 > Abstract contains "Section 3.1" which becomes an HTML reference > link. This incorrectly links to the current draft section 3.1, > not the intended RFC5176 Section 3.1. This is repeated in=20 > the introduction. =20 Fixed. > IMO, that last sentence would read better with "corrects the omission" > instead of "that." It's been reworded to be clearer over all. > Code points are not summarized in IANA Considerations section.=20 Fixed. > The references are not formatted per RFC7322. >=20 > The HTML rendering of Section 2.2 CoA Processing does not render > the RFC5176 link correctly. Bracketed references normally are = followed > by some text. I'll fix that. > IMO, considering this draft updates 5176, I feel it would be better = for the > problem statement to be clearer on updates and clarifications.=20 Perhaps you could suggest text? My understanding is that the problem = statement is fairly clear: * CoA proxying is currently impossible And the solution: * define a method for doing CoA proxying > In section 3.3, while humorous, I suggest dropping "on the planet."=20 Done. And clarified substantially as a result of IESG feedback. > Section 6 Security Considerations link for Section 11 of RFC6929 is=20 > missing keyword "of." This results in two links instead of the correct > link.=20 Fixed. From nobody Tue Aug 14 20:18:19 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 DE4A0128C65; Tue, 14 Aug 2018 20:18:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell 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.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153430309790.27225.13672171828804687460.idtracker@ietfa.amsl.com> Date: Tue, 14 Aug 2018 20:18:17 -0700 Archived-At: Subject: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 03:18:18 -0000 Ben Campbell has entered the following ballot position for draft-ietf-radext-coa-proxy-05: 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: ---------------------------------------------------------------------- (This is a procedural DISCUSS. Hopefully it can be resolved easily, but I do think it needs to be resolved prior to publication..) This draft is standards track, yet it primarily serves to extend RFC 5176. That RFC is informational. The shepherd writeup argues that this is okay because it seems like 5176 should have been standards track. But the applicability statement RFC 5176 explains why it was informational, and the reasons seem convincing. Therefore I do not think it is appropriate to publish this draft as Standards Track. I think it would be fine to progress it as Informational (or even Experimental) if it included an applicability statement explaining why in order to avoid the appearance of a standard masquerading as an Informational RFC. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (My review is not yet complete; I wanted to get the DISUSS point out with as much discussion time as possible. I expect to follow up with an update sometime before the telechat.) From nobody Wed Aug 15 04:45:29 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 AD106127148; Wed, 15 Aug 2018 04:45:19 -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 UwASFgl8BhVI; Wed, 15 Aug 2018 04:45:17 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 72A76126DBF; Wed, 15 Aug 2018 04:45:17 -0700 (PDT) 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 15B7C4DB; Wed, 15 Aug 2018 11:45:14 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D6F3E677-762C-4078-877C-97793AC60838"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: <153430309790.27225.13672171828804687460.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 07:45:13 -0400 Cc: The IESG , draft-ietf-radext-coa-proxy@ietf.org, Winter Stefan , radext-chairs@ietf.org, radext@ietf.org Message-Id: <4D83C0DB-8A53-408D-9CDE-D4B11D27DD30@freeradius.org> References: <153430309790.27225.13672171828804687460.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 11:45:20 -0000 --Apple-Mail=_D6F3E677-762C-4078-877C-97793AC60838 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 14, 2018, at 11:18 PM, Ben Campbell wrote: > This draft is standards track, yet it primarily serves to extend RFC = 5176. By adding new capabilities which are not implemented anywhere. > That > RFC is informational. The shepherd writeup argues that this is okay = because it > seems like 5176 should have been standards track. But the = applicability > statement RFC 5176 explains why it was informational, and the reasons = seem > convincing. Those reasons apply to RFC 5176. They don't apply to this document. Can we have a standards track document which defines *new* = capabilities? Capabilities which do not affect any existing = implementation or deployment? Can we have a standards track document which depends on an = informational document? > Therefore I do not think it is appropriate to publish this draft as > Standards Track. I think it would be fine to progress it as = Informational (or > even Experimental) if it included an applicability statement = explaining why in > order to avoid the appearance of a standard masquerading as an = Informational > RFC. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > (My review is not yet complete; I wanted to get the DISUSS point out = with as > much discussion time as possible. I expect to follow up with an update = sometime > before the telechat.) >=20 >=20 --Apple-Mail=_D6F3E677-762C-4078-877C-97793AC60838 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----- iQEcBAEBCAAGBQJbdBJJAAoJEH0Oec13Yh7N9jMIAJOuvjDnJoySEJVJVQ1SmCDn 4KnDSn4MMR6biO1Ir0lexVWoxb8tWipMGHE1QfR0lY/EHlH1aNSmPBu/do/ZrifQ 9Ivf0x4jZD7n8AaqMSAlkDTIY8r9dEnu/Lb3jxvFfnPZt12y+cHrmmJRscU5A2Vx HieRSCNKo29xK+5B2Y/sFxTEGPvfSCZWwdH9rpYZpOuFXbbUfwiljqfwlAFkGpCz she8kLgyizBKwYLmoEmyNilEBYrZzlgRLUKtd1tak7DqFXwy97WG2MRabnpO4c91 GwDf0TD6DKyy4Tc6/dMYF67sggGDuuz/+BlKhMo+35y3mYyujiIn0zcdb/rpKb8= =bLlQ -----END PGP SIGNATURE----- --Apple-Mail=_D6F3E677-762C-4078-877C-97793AC60838-- From nobody Wed Aug 15 07:46:48 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 D6B03130F7F; Wed, 15 Aug 2018 07:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 l7Uo_CVnj3eH; Wed, 15 Aug 2018 07:46:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D8AC4130E42; Wed, 15 Aug 2018 07:46:43 -0700 (PDT) Received: from [10.0.1.95] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7FEkcg7080133 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Aug 2018 09:46:39 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <22938F82-F957-4356-AC12-5DECE2926260@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_30DEA916-08CB-40B9-8D81-DD911D1B1E66"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 15 Aug 2018 09:46:37 -0500 In-Reply-To: <4D83C0DB-8A53-408D-9CDE-D4B11D27DD30@freeradius.org> Cc: The IESG , draft-ietf-radext-coa-proxy@ietf.org, Winter Stefan , radext-chairs@ietf.org, radext@ietf.org To: Alan DeKok References: <153430309790.27225.13672171828804687460.idtracker@ietfa.amsl.com> <4D83C0DB-8A53-408D-9CDE-D4B11D27DD30@freeradius.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 14:46:46 -0000 --Apple-Mail=_30DEA916-08CB-40B9-8D81-DD911D1B1E66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 15, 2018, at 6:45 AM, Alan DeKok wrote: >=20 > On Aug 14, 2018, at 11:18 PM, Ben Campbell wrote: >> This draft is standards track, yet it primarily serves to extend RFC = 5176. >=20 > By adding new capabilities which are not implemented anywhere. Granted. >=20 >> That >> RFC is informational. The shepherd writeup argues that this is okay = because it >> seems like 5176 should have been standards track. But the = applicability >> statement RFC 5176 explains why it was informational, and the reasons = seem >> convincing. >=20 > Those reasons apply to RFC 5176. They don't apply to this document. >=20 Yes, but as you allude to below, this document depends on 5176. Given = that it is an extension to 5176, I=E2=80=99d say that it effectively = incorporates 5176 by reference. > Can we have a standards track document which defines *new* = capabilities? Capabilities which do not affect any existing = implementation or deployment? Sure, that defines many, if not most, standards track documents. >=20 > Can we have a standards track document which depends on an = informational document? There=E2=80=99s the problem. According to RFC 2026, we cannot. The IESG = can make exceptions under specific circumstances (see RFCs 3967 and = 4897). The point of my DISCUSS is to force discussion of whether it is = appropriate to make an exception for this draft. My initial thoughts is that it is not appropriate to do so. This draft = is a relatively small extension to 5176. It might be different if this = draft incidentally depended on 5176, but in this case the informational = RFC is the entire foundation of this draft. If it=E2=80=99s important to make this draft standards track, then we = should look into promoting 5176 to standards track. Thanks, Ben. >=20 >> Therefore I do not think it is appropriate to publish this draft as >> Standards Track. I think it would be fine to progress it as = Informational (or >> even Experimental) if it included an applicability statement = explaining why in >> order to avoid the appearance of a standard masquerading as an = Informational >> RFC. >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> (My review is not yet complete; I wanted to get the DISUSS point out = with as >> much discussion time as possible. I expect to follow up with an = update sometime >> before the telechat.) >>=20 >>=20 >=20 --Apple-Mail=_30DEA916-08CB-40B9-8D81-DD911D1B1E66 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlt0PM0ACgkQgFZKbJXz 1A3pww//cGPsagdGkgYawAD5zVkH6fEJZfjAoe+fP8IDwnEmhN64fXibjDScdZEh 1N0j84g/0rQKss5vdqUxYW3CKQT18RitKVwjUeW7eT4UenFXVn69WOoSOpN4oXCm +NsOIXzRT0YAEr2gyCqg2J7EJjjlRuoyFCik8Aq+BYfiw+poD2vGxS1G32e8pKxH GXJMX2usxEz5QW/GWvQVzUaQiqzZaXdXye4vSitSxmHU+vuIkU5pZyci78TWzg9r 4J0s/h8gm/EJi/U+Ph0KK9mG6SHObJaVLJbyvktg6O6AXYc5G8yfEN1w1+GsATWa uLpAePP96JNiQuVfgH5u5/PQ9gfJ1oSt6LmDSKo0pm8S+C2VipbDTrvQAPz3ykZW UJBXGTGNL5zzGiYTpGz9QPs9dMiHmluLBU9FcHdcgrSRGpvz06eXqIgnDipF4pjl QEJpguWHDdW6IrFgI8q5I/hv2OwbclmH2LRS6B+yEBVg9HC3+AB+hd0/NsYRZYWM c91tS6YjTtI0XcDSlpbZeUrKycuY6VIk8sh/zmCjL+cSvGG7NWLAhs846lz6Pmcb YlYScmsyaLF8EcG/Q0dNEF9twdSEnP3JL8t0fiRQVizlz9VAZdkZ1rxZY3sjX2ai vwRsBPsgRwn6uN//PUTNdbbVXvhLJMfJ2f+Y+SQjg0ugQCj1TQo= =3xrz -----END PGP SIGNATURE----- --Apple-Mail=_30DEA916-08CB-40B9-8D81-DD911D1B1E66-- From nobody Wed Aug 15 08:15: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 4368D131031; Wed, 15 Aug 2018 08:15:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: radext@ietf.org, stefan.winter@restena.lu, radext-chairs@ietf.org, draft-ietf-radext-coa-proxy@ietf.org, Stefan Winter X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153434610726.14442.18102779548524907034.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 08:15:07 -0700 Archived-At: Subject: [radext] Eric Rescorla's No Objection on draft-ietf-radext-coa-proxy-05: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 15:15:10 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-radext-coa-proxy-05: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5085 I concur with Adam's DISCUSS (but marking no-objection to let him manage this). Specifically, you need to describe what the security expectations are for the Operator-NAS-Identifier. Need it be unguessable? Should separate identifiers that refer to the same NAS be unlinkable? "Cryptographically strong" is not a sufficiently specific term to determine what the requirements are here. COMMENTS S 6. > issues. > > The Operator-NAS-Identifier SHOULD be created by the Visited Network > such that its contents are opaque to all other parties. This ensures > that anyone observing unencrypted RADIUS traffic gains no information > about the internals of the Visited Network. See above about the requirements here. Does there need to be an unlinkable identifier each time? From nobody Wed Aug 15 08:24:33 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 1B88E130DDA; Wed, 15 Aug 2018 08:24:26 -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 Txg_qTzEw6_Y; Wed, 15 Aug 2018 08:24:24 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 49708130DCD; Wed, 15 Aug 2018 08:24:24 -0700 (PDT) Received: from [192.168.20.38] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id A228E2C6; Wed, 15 Aug 2018 15:24:22 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F2E1C6B8-2B04-41D9-83BA-9CF953AF4F0F"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: <22938F82-F957-4356-AC12-5DECE2926260@nostrum.com> Date: Wed, 15 Aug 2018 11:24:20 -0400 Cc: Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org Message-Id: <92D694EE-B9AF-4DE9-85AF-78334E9CD8C8@freeradius.org> References: <153430309790.27225.13672171828804687460.idtracker@ietfa.amsl.com> <4D83C0DB-8A53-408D-9CDE-D4B11D27DD30@freeradius.org> <22938F82-F957-4356-AC12-5DECE2926260@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 15:24:26 -0000 --Apple-Mail=_F2E1C6B8-2B04-41D9-83BA-9CF953AF4F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 15, 2018, at 10:46 AM, Ben Campbell wrote: > Yes, but as you allude to below, this document depends on 5176. Given = that it is an extension to 5176, I=E2=80=99d say that it effectively = incorporates 5176 by reference. Which means what? That this document is really part of 5176, and that = the caveats given in Section 1.1 should be applied, even though they = don't apply to this document? I'm not sure I follow that logic. "IF A then B" means that if A is = false, then B is also false. >> Can we have a standards track document which depends on an = informational document? >=20 > There=E2=80=99s the problem. According to RFC 2026, we cannot. The = IESG can make exceptions under specific circumstances (see RFCs 3967 and = 4897). The point of my DISCUSS is to force discussion of whether it is = appropriate to make an exception for this draft. We already have RFC 5080 (proposed standard) which updates RFC 2866 = (informational). Even more strongly, RFC 5080 points out errors in both the spec *and* = in implementations. Which means that RFC 5080 took the opposite decision of 5176. It = marked existing implementations as non-compliant. The reasons for that = decision are historical. > My initial thoughts is that it is not appropriate to do so. This draft = is a relatively small extension to 5176. It might be different if this = draft incidentally depended on 5176, but in this case the informational = RFC is the entire foundation of this draft. >=20 > If it=E2=80=99s important to make this draft standards track, then we = should look into promoting 5176 to standards track. Along with RFC 2866 (RADIUS accounting), RFC 2867, RFC 2868, RC 5997, = RFC 6613 (TCP transport), RFC 6614 (TLS transport), and RFC 7360 (DTLS = transport). And probably more. All of those documents are = informational. There have been discussions over the years about making = them all standards track. However, the sad truth is that the RADIUS WG is essentially dead at = this point. There is little interest in revisiting 20 year-old specs, = just to have them promoted to standards track. And even if they were = made standards track, the consensus has been that little of the content = would change. As for this document, the WG was in favour of making it standards = track, and it had support from the previous AD. Exceptions have been = made in the past in similar circumstances. I'm arguing this point simply because I'm not convinced by the = counter-arguments. Alan DeKok. --Apple-Mail=_F2E1C6B8-2B04-41D9-83BA-9CF953AF4F0F 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----- iQEcBAEBCAAGBQJbdEWlAAoJEH0Oec13Yh7NNv4H/2uuVbRDdW5LHXCJgSyrcIBW SZcZ9shr984robWhd8YN6Si23ALsNU5brJgyR1RTIQ+meVsnNJ4telB1s8Vc4VKv 7Wp9Pti/nKieqITVdg747mkgkYMS+L2788wPOBDG2zBIcgvlH84SvC7gb2fFquvV 6FXMUTSrLdpxEZa9oiJVFnGkPW/cFQw3BA8wTprzqZ0ryeK93Fd966X87FbngReP IQByN0flqSWI1rK02F8q/8JGhv+jJQzTCJ4XsPMtzsZmEa4ZnW2OTM6qvxTrDx2f FriR0HG7JiXIrLHQJT1f32zU45GV0zj1/VX7yvlUKdERknEt3+FUHPFUuoY10K4= =3HUd -----END PGP SIGNATURE----- --Apple-Mail=_F2E1C6B8-2B04-41D9-83BA-9CF953AF4F0F-- From nobody Wed Aug 15 08:26:47 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 425FE130DDA; Wed, 15 Aug 2018 08:26:40 -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 JoDwsSN4ShWt; Wed, 15 Aug 2018 08:26:39 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 26E8F130DD5; Wed, 15 Aug 2018 08:26:39 -0700 (PDT) Received: from [192.168.20.38] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 6611954E; Wed, 15 Aug 2018 15:26:37 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DA3D82D7-B23E-4D21-AB92-14C0B85A824F"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: <153434610726.14442.18102779548524907034.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 11:26:36 -0400 Cc: The IESG , radext@ietf.org, Winter Stefan , radext-chairs@ietf.org, draft-ietf-radext-coa-proxy@ietf.org Message-Id: <885EEC1B-966C-4B97-8556-43527C051956@freeradius.org> References: <153434610726.14442.18102779548524907034.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Eric Rescorla's No Objection on draft-ietf-radext-coa-proxy-05: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 15:26:40 -0000 --Apple-Mail=_DA3D82D7-B23E-4D21-AB92-14C0B85A824F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 15, 2018, at 11:15 AM, Eric Rescorla wrote: >=20 > I concur with Adam's DISCUSS (but marking no-objection to let him > manage this). Specifically, you need to describe what the security > expectations are for the Operator-NAS-Identifier. Need it be > unguessable? Should separate identifiers that refer to the same NAS be > unlinkable? "Cryptographically strong" is not a sufficiently specific > term to determine what the requirements are here. I've rewritten the problem text in order to (a) avoid these issues, = and (b) discuss the security implications in more detail. > COMMENTS > S 6. >> issues. >>=20 >> The Operator-NAS-Identifier SHOULD be created by the Visited = Network >> such that its contents are opaque to all other parties. This = ensures >> that anyone observing unencrypted RADIUS traffic gains no = information >> about the internals of the Visited Network. >=20 > See above about the requirements here. Does there need to be an > unlinkable identifier each time? No. External parties already know the identity and number of NASes in a = Visited Network. The Operator-NAS-Identifier attribute here is opaque = simply because there is no compelling reason for giving it a public = meaning. As such, there is no need for integrity checks, replay detection, = privacy, etc. Alan DeKok. --Apple-Mail=_DA3D82D7-B23E-4D21-AB92-14C0B85A824F 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----- iQEcBAEBCAAGBQJbdEYsAAoJEH0Oec13Yh7NFIMIAI8VKVHTjIfbTobRDbjZxN38 q/wK+YIw9lESWhQJgUrlRqSzxQ1n296fbzQqtOJ96Y0b0YbVR1t+bnhdHJD7Fdbz KIfWuiAddKR63Xmhkp1DyNzwHMyEP9qUivzsPYWpfyYVbI5NYx2VecQC687ZNNg3 GbjNjMXm3acBT82cN5cQprTg4zb5IsHh1scu1QB9ujRK97oWEQy4OJxDZYVlouB3 Q+esqzwE/zHidbxO4TTPybSwbVOhWQxkgu3NG5qb8lJ3rYo80Dlzp+Yzn8dtoyLx /gqYRVfXhyRxGdx5eEtq1NGHx1oTEJHZ/7JYnkxa3KuDpoLD+KX4n+BFtgMFui0= =ZoQl -----END PGP SIGNATURE----- --Apple-Mail=_DA3D82D7-B23E-4D21-AB92-14C0B85A824F-- From nobody Wed Aug 15 09:13:31 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 52834130FFF for ; Wed, 15 Aug 2018 09:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WB731cFxubY for ; Wed, 15 Aug 2018 09:13:27 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 291D6130DC7 for ; Wed, 15 Aug 2018 09:13:27 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id 95-v6so1252254lfy.9 for ; Wed, 15 Aug 2018 09:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4qPafgW+wD6MNksu8yUcd87uNTZjB83g2QWGEGXpe3k=; b=PciciDr5UIff5RI3UAgDbHENumvgt+P8nNzeAGHqsxBrKKSmpgxj6EIDYwQFgvprZo fOGWTrst4RoBiXrd+IJt4bDeP6VNDzAk5DKaer4+B9bkJV8GlN6n4JnoxIxhnq7MNheb 4s92oH+Q3t/o3k2feYvo4dA6TKczwSwivgUvxC9Kp+9D/YanlIjTeAuxX/W+PQ8pS68b NhzD0H88dXqU7ogsy23ZPyBiw5BXPOkF05TPZDqnSasKCi9xeULvLib7Ne4avV3l8osd W6ORKBaktnFYQutuCRe0hv4V7vN5MpDxtsOixjeD23LIzWAz7hTbovjewERnutyK0FHz C+/g== 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=4qPafgW+wD6MNksu8yUcd87uNTZjB83g2QWGEGXpe3k=; b=NrFOxBYDRn9zcgIf2N0Vyl1q/oUPXg0uxBcDdeH5JOKzq2waMTwjzmdlQy6azKurVU QH6B9d1hGupuXA5DUZtO6AKjKImdA8xv/4gQRuwMeRE8fuhIrEiAiYX4EmatpnRl7tfp 1XIYd3OHYLzYWDaQp3YiMWSu0k67qfMztswFqjXkkBzBD2Gp0ojVUHdyA8yBx2lVekz4 Ti3QijkHezFnEuoPxxp/8JsTE2wDmoT24G2FhumwXjfbPrVb9uE+0+1lKNBUInF1QXzS mN+OlcyHjTQwLM5jigvekx7WP3x5y2I1oqbCrmlq9Qz12haYKsdZqd+cXZw1bshmOYZB ou1Q== X-Gm-Message-State: AOUpUlHH7C3KKPhetA9Uq4iVosPh9GdxKCahA0djz9biHLp9FxBr71d5 SQ/gI2jd9MHX+XQXG73lTfvwg2BBcvrHPCAoY8sZ9A== X-Google-Smtp-Source: AA+uWPzdZpXG/B2LpN2CKdpYxjMzEe0oPEuwdxMdmHRUduid/9Bpc7OzOoOEqoNHzmsYIG+pUZXM94Fkuc1sAZoYiGA= X-Received: by 2002:a19:e307:: with SMTP id a7-v6mr16634703lfh.125.1534349605468; Wed, 15 Aug 2018 09:13:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Wed, 15 Aug 2018 09:12:44 -0700 (PDT) In-Reply-To: <885EEC1B-966C-4B97-8556-43527C051956@freeradius.org> References: <153434610726.14442.18102779548524907034.idtracker@ietfa.amsl.com> <885EEC1B-966C-4B97-8556-43527C051956@freeradius.org> From: Eric Rescorla Date: Wed, 15 Aug 2018 09:12:44 -0700 Message-ID: To: Alan DeKok Cc: The IESG , radext@ietf.org, Winter Stefan , radext-chairs@ietf.org, draft-ietf-radext-coa-proxy@ietf.org Content-Type: multipart/alternative; boundary="0000000000003211c605737b9bb7" Archived-At: Subject: Re: [radext] Eric Rescorla's No Objection on draft-ietf-radext-coa-proxy-05: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 16:13:29 -0000 --0000000000003211c605737b9bb7 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 15, 2018 at 8:26 AM, Alan DeKok wrote: > On Aug 15, 2018, at 11:15 AM, Eric Rescorla wrote: > > > > I concur with Adam's DISCUSS (but marking no-objection to let him > > manage this). Specifically, you need to describe what the security > > expectations are for the Operator-NAS-Identifier. Need it be > > unguessable? Should separate identifiers that refer to the same NAS be > > unlinkable? "Cryptographically strong" is not a sufficiently specific > > term to determine what the requirements are here. > > I've rewritten the problem text in order to (a) avoid these issues, and > (b) discuss the security implications in more detail. > > > COMMENTS > > S 6. > >> issues. > >> > >> The Operator-NAS-Identifier SHOULD be created by the Visited Network > >> such that its contents are opaque to all other parties. This > ensures > >> that anyone observing unencrypted RADIUS traffic gains no > information > >> about the internals of the Visited Network. > > > > See above about the requirements here. Does there need to be an > > unlinkable identifier each time? > > No. > > External parties already know the identity and number of NASes in a > Visited Network. The Operator-NAS-Identifier attribute here is opaque > simply because there is no compelling reason for giving it a public meaning. > > As such, there is no need for integrity checks, replay detection, > privacy, etc. > OK, well, the text needs to say this, because the existing text implies otherwise. -Ekr > Alan DeKok. > > --0000000000003211c605737b9bb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 15, 2018 at 8:26 AM, Alan DeKok <aland@freeradius.org> wrote:
On = Aug 15, 2018, at 11:15 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> I concur with Adam's DISCUSS (but marking no-objection to let him<= br> > manage this). Specifically, you need to describe what the security
> expectations are for the Operator-NAS-Identifier. Need it be
> unguessable? Should separate identifiers that refer to the same NAS be=
> unlinkable? "Cryptographically strong" is not a sufficiently= specific
> term to determine what the requirements are here.

=C2=A0 I've rewritten the problem text in order to (a) avoid the= se issues, and (b) discuss the security implications in more detail.

> COMMENTS
> S 6.
>>=C2=A0 =C2=A0 =C2=A0issues.
>>
>>=C2=A0 =C2=A0 =C2=A0The Operator-NAS-Identifier SHOULD be created b= y the Visited Network
>>=C2=A0 =C2=A0 =C2=A0such that its contents are opaque to all other = parties.=C2=A0 This ensures
>>=C2=A0 =C2=A0 =C2=A0that anyone observing unencrypted RADIUS traffi= c gains no information
>>=C2=A0 =C2=A0 =C2=A0about the internals of the Visited Network.
>
> See above about the requirements here. Does there need to be an
> unlinkable identifier each time?

=C2=A0 No.

=C2=A0 External parties already know the identity and number of NASes in a = Visited Network.=C2=A0 The Operator-NAS-Identifier attribute here is opaque= simply because there is no compelling reason for giving it a public meanin= g.

=C2=A0 As such, there is no need for integrity checks, replay detection, pr= ivacy, etc.

OK, well, the text needs to= say this, because the existing text implies otherwise.

<= /div>
-Ekr


=C2=A0 Alan DeKok.


--0000000000003211c605737b9bb7-- From nobody Wed Aug 15 09:14:46 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 2F58C13104D; Wed, 15 Aug 2018 09:14:28 -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 9njOVk-g6jOs; Wed, 15 Aug 2018 09:14:27 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7F013101E; Wed, 15 Aug 2018 09:14:25 -0700 (PDT) Received: from [192.168.20.38] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 126D5DA; Wed, 15 Aug 2018 16:14:23 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_09E1B292-5E37-41A3-B1AB-20C010AA2439"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: Date: Wed, 15 Aug 2018 12:14:21 -0400 Cc: The IESG , radext@ietf.org, Winter Stefan , radext-chairs@ietf.org, draft-ietf-radext-coa-proxy@ietf.org Message-Id: References: <153434610726.14442.18102779548524907034.idtracker@ietfa.amsl.com> <885EEC1B-966C-4B97-8556-43527C051956@freeradius.org> To: Eric Rescorla X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Eric Rescorla's No Objection on draft-ietf-radext-coa-proxy-05: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 16:14:34 -0000 --Apple-Mail=_09E1B292-5E37-41A3-B1AB-20C010AA2439 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 15, 2018, at 12:12 PM, Eric Rescorla wrote: >=20 > As such, there is no need for integrity checks, replay detection, = privacy, etc. >=20 > OK, well, the text needs to say this, because the existing text = implies otherwise. I will issue a new version shortly with the offending text removed, = and the above text added. Alan DeKok. --Apple-Mail=_09E1B292-5E37-41A3-B1AB-20C010AA2439 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----- iQEcBAEBCAAGBQJbdFFeAAoJEH0Oec13Yh7Nes0H/R1GqGWz70PGBwBDXZszPkyJ 4v1NRMQQ4U6NmPuWzA4lKTp0kWCAAvwYrOYnwbi6HRteC4lR+pJ+TaJ1htdhxLa9 p67y7eOq0eoAies81V9Ausr6TmHgvgfnAeekjfsYcDKKKjzdEjAFuNvaKbgiolnM xq1+RyWnMGbqicllAYAJRinlJzMcGHRO3d4ffUtCbKqGAEnpa5OWR0cxqA/MFmKD ulFCYPY0JW6WemeKAJ1U4cQU+CLkE+Io+2aQVQVet0hUqEbtoRwVlji3BrmIn1oA LYBD+DDtykXrCJhc9g24UoLCIc/Lo7gQ+6bImVOwAPan0kVo+nSLIWq6KMjyCKo= =CN0h -----END PGP SIGNATURE----- --Apple-Mail=_09E1B292-5E37-41A3-B1AB-20C010AA2439-- From nobody Wed Aug 15 09:38:38 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 9EE7713101E for ; Wed, 15 Aug 2018 09:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36pguBT8FoA3 for ; Wed, 15 Aug 2018 09:38:34 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 81AB913100F for ; Wed, 15 Aug 2018 09:38:34 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id v22-v6so1303693lfe.8 for ; Wed, 15 Aug 2018 09:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KeHTxuRSwVfiAg9bjA8iQKyYHQRPat//rxaZBZUHYK8=; b=nBQDLuKml0Hg34xGd/akM/oVE8HyGnNAG79E6ykSC3gDk63gxer6A41WcR7DTCAfCG 8d3s+BFsw1TZTONyGLT8mjMP91bn89lemRX9/O1CaQ2ZwCNZRwEL27bTLFbDLdQQdWrp 3CvNCgCoWbnc9tm0sLiEFi/UkcLofvCWQsz04unhDOduH4mjrkV2IzWxGsNQFlOUWyZ5 SY6KoWK2+Txwz9f/FM4STaZ2m16mCZAda1We32W9jaN3u3voMhEPvwcKrLOhUZgA1PtA m6yzl/4g+l8XM6RYHiYZSESRBWPhH7jb7PQLlvBr4CUP4bXIO6AYnruJkyA9KkKqPb6o FrpA== 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=KeHTxuRSwVfiAg9bjA8iQKyYHQRPat//rxaZBZUHYK8=; b=e2mrr55GJAvIdsxy9mzZoBAOzecf9wghQ2aY3dyxDrVmi/WRZgooBU1nG7UHFjZMo9 QyIC/F936pJVxfE1NVpwz4onMM3Q2BKS+FtLUaEuvNx4kSLtVHrztoVagWSV7OjcnssU /UT8hh82P6/DsCtksD+sWBNba6wbteMAWOKXzWZRId+XbqQtCT7jsOe7Jhis7oeQv8hj w7f/DCrE0DtCBsgR83awUUF2KeKRaLKlv0FwZlIHx7zVNAxCUdeovdYKyn1BCU8qq0V5 Bs+58PECnyry6+NODYJuMiZ8j8uALdIvebu08A2aGTOGxej3VR8F/gF1LlyD8kdS8FIN qt4g== X-Gm-Message-State: AOUpUlHI9hirBS0Eyk7AhPLSWzDJxhO+tA5BQjUbAUlRQDD1j9u7kxFq zqpH4nDmEKqCBNWOfPyehA2Q0KocqM0YKApPXlbgPw== X-Google-Smtp-Source: AA+uWPwWgw4gyhEX3grzBGbXGpX3SBl74XqJFuyk3qXC7qzsCGAXq0ENMKcPkmC+UsbQiGZC7OHwlpBFQWkIVAPMqL8= X-Received: by 2002:a19:a915:: with SMTP id s21-v6mr2192575lfe.92.1534351112797; Wed, 15 Aug 2018 09:38:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Wed, 15 Aug 2018 09:37:52 -0700 (PDT) In-Reply-To: References: <153434610726.14442.18102779548524907034.idtracker@ietfa.amsl.com> <885EEC1B-966C-4B97-8556-43527C051956@freeradius.org> From: Eric Rescorla Date: Wed, 15 Aug 2018 09:37:52 -0700 Message-ID: To: Alan DeKok Cc: The IESG , radext@ietf.org, Winter Stefan , radext-chairs@ietf.org, draft-ietf-radext-coa-proxy@ietf.org Content-Type: multipart/alternative; boundary="0000000000000a32cf05737bf5ad" Archived-At: Subject: Re: [radext] Eric Rescorla's No Objection on draft-ietf-radext-coa-proxy-05: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 16:38:36 -0000 --0000000000000a32cf05737bf5ad Content-Type: text/plain; charset="UTF-8" Fantastic. Thanks! -Ekr On Wed, Aug 15, 2018 at 9:14 AM, Alan DeKok wrote: > On Aug 15, 2018, at 12:12 PM, Eric Rescorla wrote: > > > > As such, there is no need for integrity checks, replay detection, > privacy, etc. > > > > OK, well, the text needs to say this, because the existing text implies > otherwise. > > I will issue a new version shortly with the offending text removed, and > the above text added. > > Alan DeKok. > > --0000000000000a32cf05737bf5ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Fantastic. Thanks!

-Ekr


On Wed, Aug 15, 2018 at 9:14 AM, Alan DeKok <aland@freeradius.org<= /a>> wrote:
On= Aug 15, 2018, at 12:12 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>=C2=A0 =C2=A0As such, there is no need for integrity checks, replay det= ection, privacy, etc.
>
> OK, well, the text needs to say this, because the existing text implie= s otherwise.

=C2=A0 I will issue a new version shortly with the offending text re= moved, and the above text added.

=C2=A0 Alan DeKok.


--0000000000000a32cf05737bf5ad-- From nobody Wed Aug 15 11:09:26 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 B5DD61277C8; Wed, 15 Aug 2018 11:09:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: radext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: radext@ietf.org Message-ID: <153435656468.3040.11103339656733903067@ietfa.amsl.com> Date: Wed, 15 Aug 2018 11:09:24 -0700 Archived-At: Subject: [radext] I-D Action: draft-ietf-radext-coa-proxy-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 18:09:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions WG of the IETF. Title : Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS) Authors : Alan DeKok Jouni Korhonen Filename : draft-ietf-radext-coa-proxy-06.txt Pages : 21 Date : 2018-08-15 Abstract: RFC 5176 defines Change of Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. That document suggests that proxying these messages is possible, but gives no guidance as to how it is done. This specification corrects that omission for scenarios where networks use Realm-based proxying as defined in RFC 7542. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-radext-coa-proxy-06 https://datatracker.ietf.org/doc/html/draft-ietf-radext-coa-proxy-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-coa-proxy-06 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/ From nobody Wed Aug 15 11:10:46 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 6FA2C130DEF for ; Wed, 15 Aug 2018 11:10:38 -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 GuqDGfP2D1ZS for ; Wed, 15 Aug 2018 11:10:33 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 12DC2130E85 for ; Wed, 15 Aug 2018 11:10:33 -0700 (PDT) Received: from [192.168.20.38] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 1D8723AC for ; Wed, 15 Aug 2018 18:10: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: <153435656468.3040.11103339656733903067@ietfa.amsl.com> Date: Wed, 15 Aug 2018 14:10:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3E724BD8-290F-48AC-93EA-3384187C2A91@deployingradius.com> References: <153435656468.3040.11103339656733903067@ietfa.amsl.com> To: radext@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] I-D Action: draft-ietf-radext-coa-proxy-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 18:10:44 -0000 A few more changes with this draft: * updates as per IESG review * note that we update Section 5 of RFC 5580 to allow Operator-Name in CoA-Request and Disconnect-Request packets * update the discussion of Operator-NAS-Identifier to remove text on "verification", and to note that it is simply an opaque token with minimal other meaning. And no requirement for privacy, integrity checks, or replay prevention. * note that when the Visited Server removes the Operator-Name and Operator-NAS-Identifier attribute, it MUST add a NAS-Identifier, or NAS-IP-Address, or NAS-IPv6-Address attribute. i.e. On the reverse path, it MUST undo the editing it did on the forward path. > On Aug 15, 2018, at 2:09 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the RADIUS EXTensions WG of the IETF. >=20 > Title : Dynamic Authorization Proxying in Remote = Authorization Dial-In User Service Protocol (RADIUS) > Authors : Alan DeKok > Jouni Korhonen > Filename : draft-ietf-radext-coa-proxy-06.txt > Pages : 21 > Date : 2018-08-15 >=20 > Abstract: > RFC 5176 defines Change of Authorization (CoA) and Disconnect = Message > (DM) behavior for RADIUS. That document suggests that proxying = these > messages is possible, but gives no guidance as to how it is done. > This specification corrects that omission for scenarios where > networks use Realm-based proxying as defined in RFC 7542. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-radext-coa-proxy-06 > https://datatracker.ietf.org/doc/html/draft-ietf-radext-coa-proxy-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-coa-proxy-06 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Wed Aug 15 11:33:46 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 673B1130DF6; Wed, 15 Aug 2018 11:33:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper 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.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153435801941.3053.15907114318025420750.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 11:33:39 -0700 Archived-At: Subject: [radext] Alissa Cooper's No Objection on draft-ietf-radext-coa-proxy-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 18:33:40 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-radext-coa-proxy-06: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 3.3. > The new Operator-NAS-Identifier attribute is defined as follows. I suggest adding the depiction of the fields and their lengths in bytes, as is done in RFC 5580. I was a little confused about whether the fields in the attribute are just the TLV. From nobody Wed Aug 15 11:35:09 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 9723613107B; Wed, 15 Aug 2018 11:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=np+ajRdg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Y8ocFlSR 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 kbMrz3zKkGd7; Wed, 15 Aug 2018 11:34:51 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59FA130E0A; Wed, 15 Aug 2018 11:34:51 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id C8E702DA; Wed, 15 Aug 2018 14:34:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 15 Aug 2018 14:34:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=K5Ff+d+2Dhxq9Nxx3OBOLKdS8mkqu nkHGs8XSDvuI1U=; b=np+ajRdg6xSGh0yRwil3naVvXre5xSzraJk30PZxUuc2x Q4Z3wX5jpQZfTiPUxTOHzrZkSKVhM69D27ydJftZI+sTZKk2pWjk+/WxwkCkD4Am bR43FB8PWX427ejfEwhtmjoFu2efBA5Gi/+FNSEBvaKXE2pdqqCznj94sGMvUwwS diFFjV+t8hBAYF17cELXcI74SeuXSVj6vMF3dE01t4+kmlWVZBlxnTMi1D4Ucf/4 YzGZHN5rS8GFQASd3WVeabT+rGlRUVL8gLejAMyCRYx7Az8D7CP6Fzgi4jaiKBxz LfpM2EoEWCrIrPSJyiT7jU2N0TO+p9BLtHI52Pejg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=K5Ff+d +2Dhxq9Nxx3OBOLKdS8mkqunkHGs8XSDvuI1U=; b=Y8ocFlSRUjeVgEkoVgbCO6 R/FxEiQ/8x+qW0xNz9ffMofb+97a/6lKxm46q/XO88p8BfaPT2x/KL21T72NRu2I 3JlPd88c8zeeXbWJN1KT3Dan8JlFkJfjVDh2CB5l2Hj+T5cQzZw1n6bYvPeIUCa2 /GfteTse7k/5BDYqpwT1qslY1lugI6pGlg1lxOp5gIVW/2c8DyJOJSue0xhWOYLy vzjCmEcPOgwtoVt/W8/yXcAeVKwCxv5pwzR2uREQBuFcJXKFVO1ZIQS1TTOclU9W xJGwrQUlSiec19+bvRC303GA5RuGFeTJ4f+8XQhuRCKQqCHAYEAnKnnXj+2TvSKQ == X-ME-Proxy: X-ME-Sender: Received: from dhcp-10-150-9-145.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id 74F45E463E; Wed, 15 Aug 2018 14:34:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <3333032E-47BC-4AF9-97D5-F02F7FC260D8@deployingradius.com> Date: Wed, 15 Aug 2018 14:34:48 -0400 Cc: Tim Evens , radext@ietf.org, gen-art , draft-ietf-radext-coa-proxy.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6B111A9A-A84D-4CE2-A6E9-E4059784195C@cooperw.in> References: <153420629857.24982.2722057727598250846@ietfa.amsl.com> <3333032E-47BC-4AF9-97D5-F02F7FC260D8@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [radext] [Gen-art] Genart last call review of draft-ietf-radext-coa-proxy-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 18:34:59 -0000 Tim, thanks for your review. Alan, thanks for your responses. I have = entered a No Objection ballot. Alissa > On Aug 14, 2018, at 4:00 PM, Alan DeKok = wrote: >=20 > On Aug 13, 2018, at 8:24 PM, Tim Evens = wrote: >> Minor issues: >>=20 >> Nits/editorial comments:=20 >> Abstract contains "Section 3.1" which becomes an HTML reference >> link. This incorrectly links to the current draft section 3.1, >> not the intended RFC5176 Section 3.1. This is repeated in=20 >> the introduction. =20 >=20 > Fixed. >=20 >> IMO, that last sentence would read better with "corrects the = omission" >> instead of "that." >=20 > It's been reworded to be clearer over all. >=20 >> Code points are not summarized in IANA Considerations section.=20 >=20 > Fixed. >=20 >> The references are not formatted per RFC7322. >>=20 >> The HTML rendering of Section 2.2 CoA Processing does not render >> the RFC5176 link correctly. Bracketed references normally are = followed >> by some text. >=20 > I'll fix that. >=20 >> IMO, considering this draft updates 5176, I feel it would be better = for the >> problem statement to be clearer on updates and clarifications.=20 >=20 > Perhaps you could suggest text? My understanding is that the problem = statement is fairly clear: >=20 > * CoA proxying is currently impossible >=20 > And the solution: >=20 > * define a method for doing CoA proxying >=20 >> In section 3.3, while humorous, I suggest dropping "on the planet."=20= >=20 > Done. And clarified substantially as a result of IESG feedback. >=20 >> Section 6 Security Considerations link for Section 11 of RFC6929 is=20= >> missing keyword "of." This results in two links instead of the = correct >> link.=20 >=20 > Fixed. >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Aug 15 12:25:56 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 877D5130FF9; Wed, 15 Aug 2018 12:25:55 -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 6Zr4qhD72-d0; Wed, 15 Aug 2018 12:25:53 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 9A619130E09; Wed, 15 Aug 2018 12:25:53 -0700 (PDT) Received: from [192.168.20.38] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 13CAD40D; Wed, 15 Aug 2018 19:25:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <153435801941.3053.15907114318025420750.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 15:25:50 -0400 Cc: The IESG , Winter Stefan , radext-chairs@ietf.org, draft-ietf-radext-coa-proxy@ietf.org, radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <926C796E-1339-488F-812C-27A003DF1D27@deployingradius.com> References: <153435801941.3053.15907114318025420750.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Alissa Cooper's No Objection on draft-ietf-radext-coa-proxy-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 19:25:55 -0000 On Aug 15, 2018, at 2:33 PM, Alissa Cooper wrote: > S 3.3. >=20 >> The new Operator-NAS-Identifier attribute is defined as follows. >=20 > I suggest adding the depiction of the fields and their lengths in > bytes, as is done in RFC 5580. I was a little confused about whether > the fields in the attribute are just the TLV. There are no fields in the Operator-NAS-Identifier attribute. it's = just an opaque blob. Maybe you were thinking of the Operator-Name attribute? That's = defined already in RFC 5580. I don't think there's a need to re-use = that text here. Alan DeKok. From nobody Wed Aug 15 12:44:56 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 C1629130FF9 for ; Wed, 15 Aug 2018 12:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrd5PckWkJ6H for ; Wed, 15 Aug 2018 12:44:52 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 3F4CC130F1D for ; Wed, 15 Aug 2018 12:44:52 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id u7-v6so1841114lji.3 for ; Wed, 15 Aug 2018 12:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oL9TqKtj/ZmLYaNmscnBLuzjviZOiddaKtEVaJA64uc=; b=RY1oTY0ooKBgHz2ij3i9ixLQftXt6m4W/HocJ/Nq59YsBftChWeWymhqBhTFCsnZJ4 /XfYYGbA8TY8tREpIglLSGpAgInuSbHxkOC/Jqk9JqBJm882IqFUBGL0s0FlxdmUttrl PuPGk2xkXoe5FF+ncm8l9GBI5HsV3WSG0XpC2BxlLWpC6li/ARnIQcb2xxVCJ8CdIzYE dzC463K6Yv7G+WD/iLmNEPllIfhNMQrDD993KRf9QA1w9cCbnXFQM9lmq6f6sr9gzVsb 9RXfFkrQrdVE5fCKJegHNTdQ/dpnBFw3RNrI855ktq0ldLMDzVq0Dk1UKV+vyoBchjXT Rrpw== 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=oL9TqKtj/ZmLYaNmscnBLuzjviZOiddaKtEVaJA64uc=; b=iR3Ttv9dzRNPsJ8w34z6xbLOE5Cg6s7xK94pje++JsNQQDN5zqQaebWVyZMTAh15KY l4y36hAIjHJrWDfyJ8VjDXZ3i67KiS/YGa/hYnS1VUWmfs3DGvhjXQxzACzJbLQQguCi BXdhy0WSDKlQjXgHmHGc3D98GcXGL7/QUMZ8ubzXA/AH8JjdcCTI2w+NhB9clt9BWn3u mhjS9NSMkC8bpl+mkZi+ZaLoPEXbefXC7UsbwHA3coADHsKT8c/0wp1R5XuaNjLjZyVJ VGE1hGbgX980iR4iHskj6dWNZpr1kKM3F83MD6VmHMBwwaYArpLaa1PyvzbDwFv8W8gW oFjw== X-Gm-Message-State: AOUpUlEOvUcavQP/U4to7/UkqMUhBuweNahaO7fEGIIwW3VNmsZ4/HG5 GJVBTuyGdfy7a7zoi4gNHq5b8h5y3l2vQ9kGmMBp5A== X-Google-Smtp-Source: AA+uWPyL6RNMpqs0DznB48lGdSGl/zzs1w4Uh/qOIMoEOnryCyDncPuUzuXpx35r9eewV1PWzbqpYN66o3boTPXIrbs= X-Received: by 2002:a2e:9c4d:: with SMTP id t13-v6mr18299349ljj.153.1534362290558; Wed, 15 Aug 2018 12:44:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Wed, 15 Aug 2018 12:44:09 -0700 (PDT) In-Reply-To: <926C796E-1339-488F-812C-27A003DF1D27@deployingradius.com> References: <153435801941.3053.15907114318025420750.idtracker@ietfa.amsl.com> <926C796E-1339-488F-812C-27A003DF1D27@deployingradius.com> From: Eric Rescorla Date: Wed, 15 Aug 2018 12:44:09 -0700 Message-ID: To: Alan DeKok Cc: Alissa Cooper , Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000492d8d05737e8f0d" Archived-At: Subject: Re: [radext] Alissa Cooper's No Objection on draft-ietf-radext-coa-proxy-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 19:44:55 -0000 --000000000000492d8d05737e8f0d Content-Type: text/plain; charset="UTF-8" On Wed, Aug 15, 2018 at 12:25 PM, Alan DeKok wrote: > On Aug 15, 2018, at 2:33 PM, Alissa Cooper wrote: > > S 3.3. > > > >> The new Operator-NAS-Identifier attribute is defined as follows. > > > > I suggest adding the depiction of the fields and their lengths in > > bytes, as is done in RFC 5580. I was a little confused about whether > > the fields in the attribute are just the TLV. > > There are no fields in the Operator-NAS-Identifier attribute. it's just > an opaque blob. > I believe what Alissa means is that it's variable length and therefore must be somehow delimited. -Ekr > Maybe you were thinking of the Operator-Name attribute? That's defined > already in RFC 5580. I don't think there's a need to re-use that text here. > > Alan DeKok. > > --000000000000492d8d05737e8f0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 15, 2018 at 12:25 PM, Alan DeKok <aland@deployingr= adius.com> wrote:
On Aug 15, 2018, at 2:33 PM, Alissa Cooper <alissa@cooperw.in> wrote:
> S 3.3.
>
>>=C2=A0 =C2=A0 =C2=A0The new Operator-NAS-Identifier attribute is de= fined as follows.
>
> I suggest adding the depiction of the fields and their lengths in
> bytes, as is done in RFC 5580. I was a little confused about whether > the fields in the attribute are just the TLV.

=C2=A0 There are no fields in the Operator-NAS-Identifier attribute.= =C2=A0 it's just an opaque blob.

I = believe what Alissa means is that it's variable length and therefore mu= st be somehow delimited.

-Ekr

=

=C2=A0 Maybe you were thinking of the Operator-Name attribute?=C2=A0 That&#= 39;s defined already in RFC 5580.=C2=A0 I don't think there's a nee= d to re-use that text here.

=C2=A0 Alan DeKok.


--000000000000492d8d05737e8f0d-- From nobody Wed Aug 15 12:47:30 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 A3F46130FD4; Wed, 15 Aug 2018 12:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 qUi7EehefvJD; Wed, 15 Aug 2018 12:47:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 923D6130F6D; Wed, 15 Aug 2018 12:47:25 -0700 (PDT) Received: from Orochi.local (c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7FJlNJG030111 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Aug 2018 14:47:24 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7] claimed to be Orochi.local To: Eric Rescorla , Alan DeKok Cc: radext-chairs@ietf.org, radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, Winter Stefan References: <153434610726.14442.18102779548524907034.idtracker@ietfa.amsl.com> <885EEC1B-966C-4B97-8556-43527C051956@freeradius.org> From: Adam Roach Message-ID: Date: Wed, 15 Aug 2018 14:47:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9A2B477B68AB4505018C69FE" Content-Language: en-US Archived-At: Subject: Re: [radext] Eric Rescorla's No Objection on draft-ietf-radext-coa-proxy-05: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 19:47:28 -0000 This is a multi-part message in MIME format. --------------9A2B477B68AB4505018C69FE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Alan -- Thanks for the new text. This is a nice set of improvements overall, but I still have concerns relating to the contents of the Operator-NAS-Identifier attribute. --------------------------------------------------------------------------- §3.4: >  Length > >     4 to 23. > >     Implementations supporting this attribute MUST be able to handle >     between one (1) and thirty-two (32) octets of data. It seems to me that "4 to 23" needs updating here. I'll note that 32 octets is still too short for modern block-based ciphers (the "more than" in my "more than 32 bytes" suggestion probably should have said "much more than."). For example, if someone wanted to use GCM here (as the text still says "encrypt"), you'd need 32 bytes for the ciphertext, 4 to 32 bytes for the tag, and something on the order of 12 bytes for the IV. So it would be more like 76 bytes rather than 32. Alternately, and this is my suggestion, remove "encrypt" entirely from this section, replacing it with "obfuscate." Concretely:       The second method is to obfuscate the NAS IP address using information       known locally by the Visited network; for example, by XORing it with a       bitmask.  The output of that obfuscation operation is data that can be       used as the value of Operator-NAS-Identifier.  On reception of a CoA       packet, the locally-known information can be used to un-obfuscate the       value of Operator-NAS-Identifier, in order to determine the actual NAS       IP address. Given that we've established that actual encryption isn't necessary here, this seems easier than expanding the field to be large enough to actually encrypt stuff. --------------------------------------------------------------------------- §2.1: >  In order to determing the "next hop" for a packet, the proxying Nit: "...determine..." Thanks! /a On 8/15/18 11:37, Eric Rescorla wrote: > Fantastic. Thanks! > > -Ekr > > > On Wed, Aug 15, 2018 at 9:14 AM, Alan DeKok > wrote: > > On Aug 15, 2018, at 12:12 PM, Eric Rescorla > wrote: > > > >   As such, there is no need for integrity checks, replay > detection, privacy, etc. > > > > OK, well, the text needs to say this, because the existing text > implies otherwise. > >   I will issue a new version shortly with the offending text > removed, and the above text added. > >   Alan DeKok. > > --------------9A2B477B68AB4505018C69FE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Alan --

Thanks for the new text. This is a nice set of improvements overall, but I still
have concerns relating to the contents of the Operator-NAS-Identifier attribute.

---------------------------------------------------------------------------

§3.4:

>  Length
>
>     4 to 23.
>
>     Implementations supporting this attribute MUST be able to handle
>     between one (1) and thirty-two (32) octets of data.

It seems to me that "4 to 23" needs updating here.

I'll note that 32 octets is still too short for modern block-based ciphers
(the "more than" in my "more than 32 bytes" suggestion probably should have
said "much more than."). For example, if someone wanted to use GCM here (as
the text still says "encrypt"), you'd need 32 bytes for the ciphertext, 4 to
32 bytes for the tag, and something on the order of 12 bytes for the IV. So it
would be more like 76 bytes rather than 32.

Alternately, and this is my suggestion, remove "encrypt" entirely from this
section, replacing it with "obfuscate." Concretely:

      The second method is to obfuscate the NAS IP address using information
      known locally by the Visited network; for example, by XORing it with a
      bitmask.  The output of that obfuscation operation is data that can be
      used as the value of Operator-NAS-Identifier.  On reception of a CoA
      packet, the locally-known information can be used to un-obfuscate the
      value of Operator-NAS-Identifier, in order to determine the actual NAS
      IP address.

Given that we've established that actual encryption isn't necessary here, this
seems easier than expanding the field to be large enough to actually encrypt
stuff.

---------------------------------------------------------------------------

§2.1:

>  In order to determing the "next hop" for a packet, the proxying

Nit: "...determine..."


Thanks!

/a

On 8/15/18 11:37, Eric Rescorla wrote:
Fantastic. Thanks!

-Ekr


On Wed, Aug 15, 2018 at 9:14 AM, Alan DeKok <aland@freeradius.org> wrote:
On Aug 15, 2018, at 12:12 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>   As such, there is no need for integrity checks, replay detection, privacy, etc.
>
> OK, well, the text needs to say this, because the existing text implies otherwise.

  I will issue a new version shortly with the offending text removed, and the above text added.

  Alan DeKok.



--------------9A2B477B68AB4505018C69FE-- From nobody Wed Aug 15 12:50:12 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 50D4C130DE3; Wed, 15 Aug 2018 12:50: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 Tz5-7-eFSvol; Wed, 15 Aug 2018 12:50:10 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0B21C1274D0; Wed, 15 Aug 2018 12:50:10 -0700 (PDT) Received: from [192.168.20.38] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 61FAD3AC; Wed, 15 Aug 2018 19:50:08 +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, 15 Aug 2018 15:50:06 -0400 Cc: Alissa Cooper , Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9BC9E9E6-1B18-4BA0-A8BF-CBA95954EBA2@deployingradius.com> References: <153435801941.3053.15907114318025420750.idtracker@ietfa.amsl.com> <926C796E-1339-488F-812C-27A003DF1D27@deployingradius.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Alissa Cooper's No Objection on draft-ietf-radext-coa-proxy-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 19:50:11 -0000 On Aug 15, 2018, at 3:44 PM, Eric Rescorla wrote: >=20 > On Wed, Aug 15, 2018 at 12:25 PM, Alan DeKok = wrote: > On Aug 15, 2018, at 2:33 PM, Alissa Cooper wrote: > > S 3.3. > >=20 > >> The new Operator-NAS-Identifier attribute is defined as = follows. > >=20 > > I suggest adding the depiction of the fields and their lengths in > > bytes, as is done in RFC 5580. I was a little confused about whether > > the fields in the attribute are just the TLV. >=20 > There are no fields in the Operator-NAS-Identifier attribute. it's = just an opaque blob. >=20 > I believe what Alissa means is that it's variable length and therefore = must be somehow delimited. The encapsulating RADIUS attribute header has a "Length" field. That = delimits the Operator-NAS-Identifier value. The value itself is (again) just an opaque blob. The value can have = any length, 1 to 32 octets. There is no intrinsic meaning in any one = octet of the value. There is no need for the *contents* of the attribute to have any = delimitation whatsoever. Alan DeKok. =20= From nobody Wed Aug 15 12:52: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 45390131055; Wed, 15 Aug 2018 12:52:00 -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 w2bqaxMZWreK; Wed, 15 Aug 2018 12:51:58 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4491274D0; Wed, 15 Aug 2018 12:51:58 -0700 (PDT) Received: from [192.168.20.38] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 749673AC; Wed, 15 Aug 2018 19:51:56 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1995326C-0F3C-4BD4-8B6F-CE61897BB573"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: Date: Wed, 15 Aug 2018 15:51:54 -0400 Cc: Eric Rescorla , radext-chairs@ietf.org, radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, Winter Stefan Message-Id: References: <153434610726.14442.18102779548524907034.idtracker@ietfa.amsl.com> <885EEC1B-966C-4B97-8556-43527C051956@freeradius.org> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Eric Rescorla's No Objection on draft-ietf-radext-coa-proxy-05: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 19:52:01 -0000 --Apple-Mail=_1995326C-0F3C-4BD4-8B6F-CE61897BB573 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 15, 2018, at 3:47 PM, Adam Roach wrote: >=20 > Alan -- >=20 > Thanks for the new text. This is a nice set of improvements overall, = but I still > have concerns relating to the contents of the Operator-NAS-Identifier = attribute. >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A73.4: >=20 > > Length > > > > 4 to 23. > > > > Implementations supporting this attribute MUST be able to handle > > between one (1) and thirty-two (32) octets of data. >=20 > It seems to me that "4 to 23" needs updating here. Yes. I'll fix that. > Alternately, and this is my suggestion, remove "encrypt" entirely from = this > section, replacing it with "obfuscate." Concretely: >=20 > The second method is to obfuscate the NAS IP address using = information > known locally by the Visited network; for example, by XORing it = with a > bitmask. The output of that obfuscation operation is data that = can be > used as the value of Operator-NAS-Identifier. On reception of a = CoA > packet, the locally-known information can be used to = un-obfuscate the > value of Operator-NAS-Identifier, in order to determine the = actual NAS > IP address. >=20 > Given that we've established that actual encryption isn't necessary = here, this > seems easier than expanding the field to be large enough to actually = encrypt > stuff. That sounds better. > = --------------------------------------------------------------------------= - >=20 > =C2=A72.1: >=20 > > In order to determing the "next hop" for a packet, the proxying >=20 > Nit: "...determine..." Fixed. Alan DeKok. --Apple-Mail=_1995326C-0F3C-4BD4-8B6F-CE61897BB573 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----- iQEcBAEBCAAGBQJbdIRaAAoJEH0Oec13Yh7NtEAH/1Oo/MCFjwz1cmfIh3rUzbGx hU1d30D0a74EmfvjukBvcGFT+47jRGD+1kHLoYa+zaYtWwbFTak/zPDmEnxWMnSA 6V/0Aj0g6LBLY1uQjAH6dPkwK5qp5u0qfEovfq/R7ZC3dP+NV7IRZyY8TYzdS+qJ uMJOZbkDHxUQGgyeM0qkGrGBRzjQPMscOZ3/ukiORCZopMV6AqvwScG0fsbsyrb7 05qnOc9PlrKOJtvj1YXNEeuTTzA1iezkmvQTNvx6inIb5BHArtMQJPXM6pIpjdrT S9KhTp9tVoyEd1ICzLmNvDOU0OHWh/WPWFOuX2MaPISSF22vtfFO87NraaJ6/HY= =1lHm -----END PGP SIGNATURE----- --Apple-Mail=_1995326C-0F3C-4BD4-8B6F-CE61897BB573-- From nobody Wed Aug 15 12:55:17 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 2846813111F; Wed, 15 Aug 2018 12:55:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell 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.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153436290915.3118.1227345371925581329.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 12:55:09 -0700 Archived-At: Subject: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-06: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 19:55:15 -0000 Ben Campbell has entered the following ballot position for draft-ietf-radext-coa-proxy-06: 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: ---------------------------------------------------------------------- (This is a procedural DISCUSS. Hopefully it can be resolved easily, but I do think it needs to be resolved prior to publication..) This draft is standards track, yet it primarily serves to extend RFC 5176. That RFC is informational. The shepherd writeup argues that this is okay because it seems like 5176 should have been standards track. But the applicability statement RFC 5176 explains why it was informational, and the reasons seem convincing. Therefore I do not think it is appropriate to publish this draft as Standards Track. I think it would be fine to progress it as Informational (or even Experimental) if it included an applicability statement explaining why in order to avoid the appearance of a standard masquerading as an Informational RFC. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a readable and understandable drafts. I have some additional comments that do not rise to the level of a DISCUSS Substantive Comments: - I support Adam's DISCUSS point concerning the security properties of Operator-NAS-Identifier. But I will let that play out in Adam's thread. §3.1 and §3,3: Do the normative changes to Access-Request and Accounting-Request mean that this draft needs to update documents other than just RFC 5176? Editorial Comments: - The abstract and introduction explain how this draft updates 5176, which is good. However, they avoid using the explicit term-of-art "Updates RFC 5176". Doing so would help make things more explicit. (The RFC style guide recommends doing this at least in the abstract.) - Please expand PPTP and L2TP on first mention. §3.1: I suspect some of the normative keywords in this section refer to previously existing requirements rather than new requirements. If so, they should not be capitalized except in literal quotes. §6: I think it would be helpful to mention the discussion in §4.3 in the security considerations. §7: It would be helpful for the IANA considerations to briefly summarize the new attributes, so that a reader that started out reading the IANA considerations doesn't have to flip back to §3.3 just to find out what they are. From nobody Wed Aug 15 13:04:14 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 5D90C1310A6; Wed, 15 Aug 2018 13:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 gcBnVwt-RpOH; Wed, 15 Aug 2018 13:01:31 -0700 (PDT) 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 E745D131109; Wed, 15 Aug 2018 13:01:30 -0700 (PDT) X-AuditID: 1209190d-1fdff700000016c8-a5-5b748699ab66 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 2A.E2.05832.996847B5; Wed, 15 Aug 2018 16:01:29 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w7FK1RLm001972; Wed, 15 Aug 2018 16:01:28 -0400 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.13.8/8.12.4) with ESMTP id w7FK1LT6021316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Aug 2018 16:01:24 -0400 Date: Wed, 15 Aug 2018 15:01:21 -0500 From: Benjamin Kaduk To: Alan DeKok Cc: Ben Campbell , radext-chairs@ietf.org, Winter Stefan , The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext@ietf.org Message-ID: <20180815200121.GS40887@kduck.kaduk.org> References: <153430309790.27225.13672171828804687460.idtracker@ietfa.amsl.com> <4D83C0DB-8A53-408D-9CDE-D4B11D27DD30@freeradius.org> <22938F82-F957-4356-AC12-5DECE2926260@nostrum.com> <92D694EE-B9AF-4DE9-85AF-78334E9CD8C8@freeradius.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <92D694EE-B9AF-4DE9-85AF-78334E9CD8C8@freeradius.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMKsWRmVeSWpSXmKPExsUixCmqrDuzrSTa4GS3gcWZjdNYLOZ3nma3 mPfkKavFjD8TmS2ednxhsmh5NZPNYl5DI7sDu8eziZMZPZYs+cnkMWvnExaP5V0+ASxRXDYp qTmZZalF+nYJXBkPH11jL9gqWtE0/RJ7A2OPYBcjJ4eEgInEy30n2LsYuTiEBBYzSUyd/4MN wtnIKHHvxmcmCOcqk8Tqw3dYQFpYBFQlfn36yQhiswmoSDR0X2YGsUWA4tuWXAYbxSxwnFFi 17O5YA3CAjkSzWdXs4PYvED7/k4/DrXvM6PE0wO/GSESghInZz4Ba2AWUJf4M+8S0FQOIFta Yvk/DoiwvETz1tlgyzgFnCS2nDjDCmKLCihL7O07xD6BUXAWkkmzkEyahTBpFpJJCxhZVjHK puRW6eYmZuYUpybrFicn5uWlFuka6eVmluilppRuYgTHhyTvDsZ/d70OMQpwMCrx8D4wLIkW Yk0sK67MPcQoycGkJMqrX10cLcSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEV40PqJw3JbGyKrUo HyYlzcGiJM57ryY8WkggPbEkNTs1tSC1CCYrw8GhJMHLB0wDQoJFqempFWmZOSUIaSYOTpDh PEDDP7aCDC8uSMwtzkyHyJ9i1OX4837qJGYhlrz8vFQpcd55IEUCIEUZpXlwc0BpTSJ7f80r RnGgt4R5zUHW8QBTItykV0BLmICWJIsUgiwpSURISTUwnlFa6mCXGODnNjvH6cZUQa/mWQld yj+mfb/t73J+haWVq2/d456c2feWJ1QeV4g91Gr+evECxZYDDyWMuJ8mmxZ6zdDfNIl7/QOn HSZndp95WrtC5FHSzv4Z0w7NMLM1q3f/fdtkjcH0gybsWjqf1WxXaKydtJxlS9CenIZ9X6bm pp8yiP3Ur8RSnJFoqMVcVJwIAKzq3jZGAwAA Archived-At: Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 20:01:39 -0000 On Wed, Aug 15, 2018 at 11:24:20AM -0400, Alan DeKok wrote: > On Aug 15, 2018, at 10:46 AM, Ben Campbell wrote: > > Yes, but as you allude to below, this document depends on 5176. Given that it is an extension to 5176, I’d say that it effectively incorporates 5176 by reference. > > Which means what? That this document is really part of 5176, and that the caveats given in Section 1.1 should be applied, even though they don't apply to this document? > > I'm not sure I follow that logic. "IF A then B" means that if A is false, then B is also false. > > >> Can we have a standards track document which depends on an informational document? > > > > There’s the problem. According to RFC 2026, we cannot. The IESG can make exceptions under specific circumstances (see RFCs 3967 and 4897). The point of my DISCUSS is to force discussion of whether it is appropriate to make an exception for this draft. > > We already have RFC 5080 (proposed standard) which updates RFC 2866 (informational). > > Even more strongly, RFC 5080 points out errors in both the spec *and* in implementations. > > Which means that RFC 5080 took the opposite decision of 5176. It marked existing implementations as non-compliant. The reasons for that decision are historical. > > > My initial thoughts is that it is not appropriate to do so. This draft is a relatively small extension to 5176. It might be different if this draft incidentally depended on 5176, but in this case the informational RFC is the entire foundation of this draft. > > > > If it’s important to make this draft standards track, then we should look into promoting 5176 to standards track. > > Along with RFC 2866 (RADIUS accounting), RFC 2867, RFC 2868, RC 5997, RFC 6613 (TCP transport), RFC 6614 (TLS transport), and RFC 7360 (DTLS transport). And probably more. All of those documents are informational. There have been discussions over the years about making them all standards track. > > However, the sad truth is that the RADIUS WG is essentially dead at this point. There is little interest in revisiting 20 year-old specs, just to have them promoted to standards track. And even if they were made standards track, the consensus has been that little of the content would change. > > As for this document, the WG was in favour of making it standards track, and it had support from the previous AD. Exceptions have been made in the past in similar circumstances. > > I'm arguing this point simply because I'm not convinced by the counter-arguments. Ultimately this is a decision for the IESG to make; it's seeming like we'll need to have a conversation on tomorrow's telechat. -Benjamin From nobody Wed Aug 15 13:04: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 7ECBF130DEB; Wed, 15 Aug 2018 13:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=aBEQw37G; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fMYOcdrL 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 1lS3UL2Qn2CN; Wed, 15 Aug 2018 13:02:40 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E131310EC; Wed, 15 Aug 2018 13:02:40 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 7D2E92B4; Wed, 15 Aug 2018 16:02:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 15 Aug 2018 16:02:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=G7HMF8aZxBvbtyYXfmDVy2FY/c4wb oSOhLtKCM7ojZw=; b=aBEQw37GIx5mO9Br5NGP++2W302jhGAKomku/ECTMpp9d c8f5fRiuSEXjyadFPbq8ePdvG5uZ1DmPxrOSsB/MGvi6y2gWovZ2+zfQxDSZVNBD uj4BtPCx4HN/YFWdlhuVqclbIy/T04C+rwi7/6NRE/MItz+qQKjmx+V3vqTasn9D tChQmSJrN5o3gSSlIPDPuIwL/lzsY4VwUEcpsQGsn5nI5JXvo7aD/ABpvzBoIfZk FKpQxWWUQWn73Ea5kzLKtI3o//eIowbcbGEAdITDsS8gwDzSZ4X5g5NB3tXmMuk1 ZhcYW4n+7bPqfEpHliitl0/FhXBDdru1+gM00axzQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=G7HMF8 aZxBvbtyYXfmDVy2FY/c4wboSOhLtKCM7ojZw=; b=fMYOcdrLTNBlJVNxtyFLZJ elflzKZ8yxGKgiQN5S706zhw0PCa4ChPSBB4ambXOiwnbzoVN7x2XgrwsWY3eygZ Oi375mxR80/8dkr3gLHTdQ6D8vSYOEp7VsB33jynAIxyGgj/0iOKeBi4yb7YrGi1 hJPPzClJXuqbHk8vyaM9qPmMKoIx9adi8aX7XK+QrE4l40m1gjZT2XQI4QbczkbT pQPKWXUjRdc9kUldOIj9QekYHUjSIVrSAGee2S+AAm5it+RGFszNAsb+6gTCLmDC Xmbhn0P/Mi6rRf1MaA3Pcym8kRUbFhK4yVueY805LbJ0AmALWXA2jkjg0laEa+Vw == X-ME-Proxy: X-ME-Sender: Received: from dhcp-10-150-9-145.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id 0B3D810261; Wed, 15 Aug 2018 16:02:37 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <9BC9E9E6-1B18-4BA0-A8BF-CBA95954EBA2@deployingradius.com> Date: Wed, 15 Aug 2018 16:02:36 -0400 Cc: Eric Rescorla , Winter Stefan , radext@ietf.org, IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <202C0FD8-8B63-4A14-92B9-299810EDAD19@cooperw.in> References: <153435801941.3053.15907114318025420750.idtracker@ietfa.amsl.com> <926C796E-1339-488F-812C-27A003DF1D27@deployingradius.com> <9BC9E9E6-1B18-4BA0-A8BF-CBA95954EBA2@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [radext] Alissa Cooper's No Objection on draft-ietf-radext-coa-proxy-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 20:02:50 -0000 > On Aug 15, 2018, at 3:50 PM, Alan DeKok = wrote: >=20 > On Aug 15, 2018, at 3:44 PM, Eric Rescorla wrote: >>=20 >> On Wed, Aug 15, 2018 at 12:25 PM, Alan DeKok = wrote: >> On Aug 15, 2018, at 2:33 PM, Alissa Cooper wrote: >>> S 3.3. >>>=20 >>>> The new Operator-NAS-Identifier attribute is defined as follows. >>>=20 >>> I suggest adding the depiction of the fields and their lengths in >>> bytes, as is done in RFC 5580. I was a little confused about whether >>> the fields in the attribute are just the TLV. >>=20 >> There are no fields in the Operator-NAS-Identifier attribute. it's = just an opaque blob. >>=20 >> I believe what Alissa means is that it's variable length and = therefore must be somehow delimited. >=20 > The encapsulating RADIUS attribute header has a "Length" field. That = delimits the Operator-NAS-Identifier value. >=20 > The value itself is (again) just an opaque blob. The value can have = any length, 1 to 32 octets. There is no intrinsic meaning in any one = octet of the value. Acknowledging my limited recall of how RADIUS attributes are defined, I = think what is tripping me up is the definition of the Length field, = which says =E2=80=9C4 to 23.=E2=80=9D If I assume that length is = measured in octets, that the type field requires 1 octet, that the = length field requires 1 octet, and that the value can be between 1 and = 32 octets long, I would conclude that valid length values would be = between 3 and 34, not between 4 and 23. Can you clarify why not? This is I guess the root of why I thought the octet diagram would help. Alissa =20 >=20 > There is no need for the *contents* of the attribute to have any = delimitation whatsoever. >=20 > Alan DeKok. >=20 >=20 From nobody Wed Aug 15 13:05:19 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 1D567130DE7; Wed, 15 Aug 2018 13:05:14 -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 2fJqG89D9ZjI; Wed, 15 Aug 2018 13:05:12 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1A935130E14; Wed, 15 Aug 2018 13:05:10 -0700 (PDT) Received: from [192.168.20.38] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 7500840D; Wed, 15 Aug 2018 20:05:08 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <202C0FD8-8B63-4A14-92B9-299810EDAD19@cooperw.in> Date: Wed, 15 Aug 2018 16:05:06 -0400 Cc: Eric Rescorla , Winter Stefan , radext@ietf.org, IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153435801941.3053.15907114318025420750.idtracker@ietfa.amsl.com> <926C796E-1339-488F-812C-27A003DF1D27@deployingradius.com> <9BC9E9E6-1B18-4BA0-A8BF-CBA95954EBA2@deployingradius.com> <202C0FD8-8B63-4A14-92B9-299810EDAD19@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Alissa Cooper's No Objection on draft-ietf-radext-coa-proxy-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 20:05:14 -0000 On Aug 15, 2018, at 4:02 PM, Alissa Cooper wrote: >=20 > Acknowledging my limited recall of how RADIUS attributes are defined, = I think what is tripping me up is the definition of the Length field, = which says =E2=80=9C4 to 23.=E2=80=9D If I assume that length is = measured in octets, that the type field requires 1 octet, that the = length field requires 1 octet, and that the value can be between 1 and = 32 octets long, I would conclude that valid length values would be = between 3 and 34, not between 4 and 23. Can you clarify why not? The Length of the attribute typically refers to allowed values of the = Length field in the RADIUS attribute header. That Length includes the = octets of the header. In this case, 3. > This is I guess the root of why I thought the octet diagram would = help. >=20 > Alissa =20 >=20 >>=20 >> There is no need for the *contents* of the attribute to have any = delimitation whatsoever. >>=20 >> Alan DeKok. From nobody Wed Aug 15 13:11:37 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 AB089130F23; Wed, 15 Aug 2018 13:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=LZSKy/lF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NKdI7isu 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 T1bsApVKD1OS; Wed, 15 Aug 2018 13:11:34 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F6D130DE3; Wed, 15 Aug 2018 13:11:34 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 66007207; Wed, 15 Aug 2018 16:11:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 15 Aug 2018 16:11:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=ALS7Cs2UXgJkNh4WNOnw9D4jfCy/k h5WHpEqHEk1AM8=; b=LZSKy/lFVmlcpPCfPLTq/f0bUMhqckqBP8Vsuv8pg817/ ZEdMZMCXtw1tKWTO5Y5Fuy2uJR5iILsSlCqrgZ16O6NJzHz0zCusvRSEF1+vIktY Wv893saJMQWHTy8k8XDRyhOvSPwMWKBUsxIrOv3wSrN4mvFSfhCEboB2x2jsBd2O PWjtUqpgi5Bz5hucy0KKzNqSK6jlqrBo6hYQqroIYnd83G/i4RGuqEWW1xK/56AC BzU9p4PDt3QyjqwnyUu/iBto4lx71+8pn8ZLAYUSy8wrNQwBlTbKvXGKB+YFRXGI uyetuI4B0Vg68zmw8oxNfx3O+wa9E5F3Vgl0PnFhw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ALS7Cs 2UXgJkNh4WNOnw9D4jfCy/kh5WHpEqHEk1AM8=; b=NKdI7isu9At5hEFHgcSU+Q 8PV2Ni+Zx4jjEYO8jve6GrOvCsCT8OeAkN8uWhIbp131e/+Kpsdntt32AETksyBH s2lWKADU3zaxCXG1bvzqbbTPXMBKCyoCQRGjwozykpP93XkYOLcx/LRso36ihuFp q3J+YvgN2vFDi+be/yYYjt68sK+DHAG98l5kA8+5g2Y8ToaGn4WImR1qWn6krP0t X0+W406ItJPyxF+hAJdh4Ekpj38HceQ+FnRzamHMgo8NkeyqDRU2fiMPeUKjsGBQ uGLxf8F0yJ2dd1gk+pt9o2l9HZRG0cszM51iE2p70iUj6Vwe6lwwcHBZmerQ7xug == X-ME-Proxy: X-ME-Sender: Received: from dhcp-10-150-9-145.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id 83C5C1025C; Wed, 15 Aug 2018 16:11:31 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: Date: Wed, 15 Aug 2018 16:11:30 -0400 Cc: Eric Rescorla , Winter Stefan , radext@ietf.org, IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <033BD213-ACAA-42AC-AFE1-5DB58EA17D1A@cooperw.in> References: <153435801941.3053.15907114318025420750.idtracker@ietfa.amsl.com> <926C796E-1339-488F-812C-27A003DF1D27@deployingradius.com> <9BC9E9E6-1B18-4BA0-A8BF-CBA95954EBA2@deployingradius.com> <202C0FD8-8B63-4A14-92B9-299810EDAD19@cooperw.in> To: Alan DeKok X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [radext] Alissa Cooper's No Objection on draft-ietf-radext-coa-proxy-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 20:11:36 -0000 > On Aug 15, 2018, at 4:05 PM, Alan DeKok = wrote: >=20 > On Aug 15, 2018, at 4:02 PM, Alissa Cooper wrote: >>=20 >> Acknowledging my limited recall of how RADIUS attributes are defined, = I think what is tripping me up is the definition of the Length field, = which says =E2=80=9C4 to 23.=E2=80=9D If I assume that length is = measured in octets, that the type field requires 1 octet, that the = length field requires 1 octet, and that the value can be between 1 and = 32 octets long, I would conclude that valid length values would be = between 3 and 34, not between 4 and 23. Can you clarify why not? >=20 > The Length of the attribute typically refers to allowed values of the = Length field in the RADIUS attribute header. That Length includes the = octets of the header. >=20 > In this case, 3. Ok, I see you=E2=80=99ve agreed to fix this in another thread. Thanks, Alissa >=20 >> This is I guess the root of why I thought the octet diagram would = help. >>=20 >> Alissa =20 >>=20 >>>=20 >>> There is no need for the *contents* of the attribute to have any = delimitation whatsoever. >>>=20 >>> Alan DeKok. >=20 From nobody Wed Aug 15 18:14:42 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 7AF67130E28; Wed, 15 Aug 2018 18:14:33 -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 5fiP9aeyo_wD; Wed, 15 Aug 2018 18:14:30 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id BD057130E26; Wed, 15 Aug 2018 18:14:30 -0700 (PDT) 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 D8A963AC; Thu, 16 Aug 2018 01:14:28 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7C7CB85E-8295-4FA8-B614-2545F4B26BD1"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: <153436290915.3118.1227345371925581329.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 21:14:26 -0400 Cc: The IESG , draft-ietf-radext-coa-proxy@ietf.org, Winter Stefan , radext-chairs@ietf.org, radext@ietf.org Message-Id: <78BEFFD7-2B87-4EC1-A1A3-8BDD7AB97C5F@freeradius.org> References: <153436290915.3118.1227345371925581329.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-06: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 16 Aug 2018 01:14:33 -0000 --Apple-Mail=_7C7CB85E-8295-4FA8-B614-2545F4B26BD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 15, 2018, at 3:55 PM, Ben Campbell wrote: > (This is a procedural DISCUSS. Hopefully it can be resolved easily, = but I do > think it needs to be resolved prior to publication..) >=20 > This draft is standards track, yet it primarily serves to extend RFC = 5176. That > RFC is informational. The shepherd writeup argues that this is okay = because it > seems like 5176 should have been standards track. But the = applicability > statement RFC 5176 explains why it was informational, and the reasons = seem > convincing. Therefore I do not think it is appropriate to publish this = draft as > Standards Track. We may choose Informational for this document, because it has a = normative dependency on RFC 5176. But I don't see how those two last sentences are related. The = argument which is convincing for 5176 is not applicable to this = document. So conflating the two applicability statements is simply not = appropriate. i.e. the issues highlighted in Section 1.1 of RFC 5176 do not apply to = this document. Any applicability statement here would be *false* if it = repeated (or even normatively referenced) the discussion in RFC 5176. > I think it would be fine to progress it as Informational (or > even Experimental) If it's Experimental, then any possible subsequent Standards track = document would run into the same problem: 5176 is Informational. And if we're being realistic... I think we're past the point where we = can expect RADIUS Information or Experimental documents to progress to = Standards track. I can't for the life of me think of a single RADIUS = document which has progressed from Informational or Experimental to = Proposed Standard. And, the RADIUS WG is on the verge of shutting down, = with no new work envisioned. And if 20+ years isn't enough to make RFC 2866 (RADIUS accounting) a = Proposed Standard, then I suspect no further progress will be made in = the next 20 years. > if it included an applicability statement explaining why in > order to avoid the appearance of a standard masquerading as an = Informational > RFC. "This document is Informational because it updates RFC 5176, which is = itself Informational. None of the applicability statements in Section = 1.1 of RFC 5176 apply to this document." > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for a readable and understandable drafts. I have some = additional > comments that do not rise to the level of a DISCUSS >=20 > Substantive Comments: >=20 > - I support Adam's DISCUSS point concerning the security properties of > Operator-NAS-Identifier. But I will let that play out in Adam's = thread. >=20 > =C2=A73.1 and =C2=A73,3: Do the normative changes to Access-Request = and > Accounting-Request mean that this draft needs to update documents = other than > just RFC 5176? The document does not provide for normative changes to Access-Request = or Accounting-Request packets. As with other RFCs that define new = RADIUS attributes (e.g. 5580), it does not update RFC 2865 or 2866. i.e. simply carrying a new attribute is not a normative change to = those packets. > Editorial Comments: >=20 > - The abstract and introduction explain how this draft updates 5176, = which is > good. However, they avoid using the explicit term-of-art "Updates RFC = 5176". > Doing so would help make things more explicit. (The RFC style guide = recommends > doing this at least in the abstract.) Fixed. > - Please expand PPTP and L2TP on first mention. Fixed. > =C2=A73.1: I suspect some of the normative keywords in this section = refer to > previously existing requirements rather than new requirements. If so, = they > should not be capitalized except in literal quotes. The normative keywords do not refer to previously existing = requirements. > =C2=A76: I think it would be helpful to mention the discussion in = =C2=A74.3 in the > security considerations. Sure. > =C2=A77: It would be helpful for the IANA considerations to briefly = summarize the > new attributes, so that a reader that started out reading the IANA > considerations doesn't have to flip back to =C2=A73.3 just to find out = what they are. The latest draft has the updates. IANA has the allocation ready, and = it has been reviewed. Alan DeKok. --Apple-Mail=_7C7CB85E-8295-4FA8-B614-2545F4B26BD1 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----- iQEcBAEBCAAGBQJbdM/zAAoJEH0Oec13Yh7N0LUH/3Teo4g5hXF1I6i267FE9z8x 8Bz52LkATLrFaZumH+xt6Fkdk2XmLwuq0iDjP7PlRa/7n5w00d/7NM2pLAGkjND3 DLFyrgqa9nhJ15308V8EtpnTejZA+5qhtkRIqimIE5d554rrJeAk89JZ2M3MQHMh +LIcnGaIotjnA/iu3GPvk+MDlqxv8sVif9Idge+yweYS+Nn3eZvUUv7kpSk1XtTS 0P6qnN2e109XiSAMIYAcH0pFVMN9mxFSZO+XPe8+Sa424Bpwzn2yI4/eIHPDqm1e glYZjVP/7phSzqsvSNt/1HSc4Kli6UZJCLKzmMwdjQ9saatdOoQ+AwT62ZJ1XTQ= =EcyN -----END PGP SIGNATURE----- --Apple-Mail=_7C7CB85E-8295-4FA8-B614-2545F4B26BD1-- From nobody Wed Aug 15 19:44: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 A3C50130E72; Wed, 15 Aug 2018 19:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 P1RujPds1s64; Wed, 15 Aug 2018 19:44:08 -0700 (PDT) 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 9E855130E82; Wed, 15 Aug 2018 19:44:07 -0700 (PDT) X-AuditID: 1209190d-1fdff700000016c8-11-5b74e4f6d7c7 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id D0.37.05832.6F4E47B5; Wed, 15 Aug 2018 22:44:06 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w7G2i4Ch017977; Wed, 15 Aug 2018 22:44:04 -0400 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.13.8/8.12.4) with ESMTP id w7G2hwFY004901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Aug 2018 22:44:00 -0400 Date: Wed, 15 Aug 2018 21:43:58 -0500 From: Benjamin Kaduk To: Alan DeKok Cc: Ben Campbell , Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org Message-ID: <20180816024358.GC40887@kduck.kaduk.org> References: <153436290915.3118.1227345371925581329.idtracker@ietfa.amsl.com> <78BEFFD7-2B87-4EC1-A1A3-8BDD7AB97C5F@freeradius.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JSkcQAAxhB1h8DcT" Content-Disposition: inline In-Reply-To: <78BEFFD7-2B87-4EC1-A1A3-8BDD7AB97C5F@freeradius.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEKsWRmVeSWpSXmKPExsUixCmqrfvtSUm0Qcd+eYszG6exWMzvPM1u Me/JU1aLGX8mMls87fjCZNHyaiabxbyGRnYHdo9nEyczeixZ8pPJY9bOJywey7t8AliiuGxS UnMyy1KL9O0SuDJW3jUv6NavWHpiBksD4ya1LkYODgkBE4k9W1W7GDk5hAQWM0m8vyTRxcgF ZG9klJi2vIMFwrnKJLF2+wcmkCoWAVWJB3P2s4HYbAIqEg3dl5lBbBGg+LYll9lBGpgFjjNK rPqyBCwhLJAscXJrA1gDL9C2zQufMUFMbWGUOLPiEBNEQlDi5MwnLCA2s0CZxLYHG9hBzmMW kJZY/o8DxOQUcJJYcEcKpEJUQFlib98h9gmMArOQNM9C0jwLoRkirCOxc+sdNgxhbYllC18z Q9i2EuvWvWdZwMi+ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdILzezRC81pXQTIziKJHl3MP67 63WIUYCDUYmH94FhSbQQa2JZcWXuIUZJDiYlUV796uJoIb6k/JTKjMTijPii0pzU4kOMKkC7 Hm1YfYFRiiUvPy9VSYT31zGgVt6UxMqq1KJ8mDJpDhYlcd57NeHRQgLpiSWp2ampBalFMFkZ Dg4lCd5/j4EaBYtS01Mr0jJzShDSTBychxglOHiAhp8HqeEtLkjMLc5Mh8ifYtTl+PN+6iRm IbALpMR5O0CKBECKMkrz4OaAkqJE9v6aV4ziQC8K8/4HqeIBJlS4Sa+AljABLUkWKQRZUpKI kJJqYGSY8XJ+tJXkJPZtcwVVgGnusKFRz1qry4uEdjx69bpiR+iR3urpizrE0lbf6EwR3rX1 SpOm3qYv8rF/xKbfD/EyffV/zoPmFQ7/Lq8Lr1iy4j0vd5Z2KMuLG790VM/X+en9Tfmur1qn 1VovMeO++KGd6RF/y4Iquy17T35QO91XHGr71PnvEyWW4oxEQy3mouJEAMkVGV5lAwAA Archived-At: Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-06: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 16 Aug 2018 02:44:10 -0000 --JSkcQAAxhB1h8DcT Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 15, 2018 at 09:14:26PM -0400, Alan DeKok wrote: > On Aug 15, 2018, at 3:55 PM, Ben Campbell wrote: > > (This is a procedural DISCUSS. Hopefully it can be resolved easily, but= I do > > think it needs to be resolved prior to publication..) > >=20 > > This draft is standards track, yet it primarily serves to extend RFC 51= 76. That > > RFC is informational. The shepherd writeup argues that this is okay bec= ause it > > seems like 5176 should have been standards track. But the applicability > > statement RFC 5176 explains why it was informational, and the reasons s= eem > > convincing. Therefore I do not think it is appropriate to publish this = draft as > > Standards Track. >=20 > We may choose Informational for this document, because it has a normati= ve dependency on RFC 5176. >=20 > But I don't see how those two last sentences are related. The argument= which is convincing for 5176 is not applicable to this document. So confl= ating the two applicability statements is simply not appropriate. Yes ... but you can't use this document at all without using 5176, and 5176 can't be standards-track as it discusses. This is basically a philosophical question of whether we can require strict compliance for just a part of or an extension to a protocol that itself is not as strictly defined. -Benjamin > i.e. the issues highlighted in Section 1.1 of RFC 5176 do not apply to = this document. Any applicability statement here would be *false* if it rep= eated (or even normatively referenced) the discussion in RFC 5176. >=20 > > I think it would be fine to progress it as Informational (or > > even Experimental) >=20 > If it's Experimental, then any possible subsequent Standards track docu= ment would run into the same problem: 5176 is Informational. >=20 > And if we're being realistic... I think we're past the point where we c= an expect RADIUS Information or Experimental documents to progress to Stand= ards track. I can't for the life of me think of a single RADIUS document w= hich has progressed from Informational or Experimental to Proposed Standard= =2E And, the RADIUS WG is on the verge of shutting down, with no new work = envisioned. >=20 > And if 20+ years isn't enough to make RFC 2866 (RADIUS accounting) a Pr= oposed Standard, then I suspect no further progress will be made in the nex= t 20 years. >=20 > > if it included an applicability statement explaining why in > > order to avoid the appearance of a standard masquerading as an Informat= ional > > RFC. >=20 > "This document is Informational because it updates RFC 5176, which is i= tself Informational. None of the applicability statements in Section 1.1 o= f RFC 5176 apply to this document." >=20 > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > >=20 > > Thanks for a readable and understandable drafts. I have some additional > > comments that do not rise to the level of a DISCUSS > >=20 > > Substantive Comments: > >=20 > > - I support Adam's DISCUSS point concerning the security properties of > > Operator-NAS-Identifier. But I will let that play out in Adam's thread. > >=20 > > =A73.1 and =A73,3: Do the normative changes to Access-Request and > > Accounting-Request mean that this draft needs to update documents other= than > > just RFC 5176? >=20 > The document does not provide for normative changes to Access-Request o= r Accounting-Request packets. As with other RFCs that define new RADIUS at= tributes (e.g. 5580), it does not update RFC 2865 or 2866. >=20 > i.e. simply carrying a new attribute is not a normative change to those= packets. >=20 > > Editorial Comments: > >=20 > > - The abstract and introduction explain how this draft updates 5176, wh= ich is > > good. However, they avoid using the explicit term-of-art "Updates RFC 5= 176". > > Doing so would help make things more explicit. (The RFC style guide rec= ommends > > doing this at least in the abstract.) >=20 > Fixed. >=20 > > - Please expand PPTP and L2TP on first mention. >=20 > Fixed. >=20 > > =A73.1: I suspect some of the normative keywords in this section refer = to > > previously existing requirements rather than new requirements. If so, = they > > should not be capitalized except in literal quotes. >=20 > The normative keywords do not refer to previously existing requirements. >=20 > > =A76: I think it would be helpful to mention the discussion in =A74.3 i= n the > > security considerations. >=20 > Sure. >=20 > > =A77: It would be helpful for the IANA considerations to briefly summar= ize the > > new attributes, so that a reader that started out reading the IANA > > considerations doesn't have to flip back to =A73.3 just to find out wha= t they are. >=20 > The latest draft has the updates. IANA has the allocation ready, and i= t has been reviewed. >=20 > Alan DeKok. >=20 --JSkcQAAxhB1h8DcT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlt05N4ACgkQKNmm82Tr dRLGswwfQtijt/WnqXljoekZHYui+C/nG9eQ6Dy2DUdVnh6dbMkFQY91m4LyyLeZ 5IbI3cpdiwJOFpJVdxV+7P2ienlXjn6hN6AJTH8TBHCnlMudb/hGLCHJ0PzfUS2O Q7nkNxvnTmuY8FBmrMERKAiesSAwzLb1MMaBXSp4qV8sb4QIpMLSO9w8UrXxHL+f P9d7tfR27MQ2AolsjirgxhxcvnRKJAzQvC0m+ebgJ7l+cmbJ9mpWi97m1Tg7I8H3 hCg+kRNyRGVVAymT6ARCLkQzbSDQdjAnkWC1SQuoZfK9lr0xaSN43z3N91XQoN7p +ZR6Zc48KMoyf6wFU+Po+aB/VELPF9Rl7/zmw6OxrhOTTS3cK+TLfAEWKQxBxVOE 4dukhSt1L9jCHs63KsBjqXeT1AHZirTsbmtSwocHwGZPSrU0wWlHGRTZ1uHLxGo/ fBKtoJmgZBPQJ3ENwWIirkjAqaWCjYMxJAt/uMC89Kg87IxfiVXnBxYQwwKzAAdF BE+amwA4qwI4eQ== =P6Iq -----END PGP SIGNATURE----- --JSkcQAAxhB1h8DcT-- From nobody Wed Aug 15 21:07:37 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 E8FA8128C65; Wed, 15 Aug 2018 21:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 cNQ3YeWWjyGe; Wed, 15 Aug 2018 21:07:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BC347124C04; Wed, 15 Aug 2018 21:07:27 -0700 (PDT) Received: from [10.0.1.95] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7G47HID009787 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Aug 2018 23:07:18 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EE508420-3884-44F4-946B-8CF6494655DD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 15 Aug 2018 23:05:40 -0500 In-Reply-To: <78BEFFD7-2B87-4EC1-A1A3-8BDD7AB97C5F@freeradius.org> Cc: The IESG , draft-ietf-radext-coa-proxy@ietf.org, Winter Stefan , radext-chairs@ietf.org, radext@ietf.org To: Alan DeKok References: <153436290915.3118.1227345371925581329.idtracker@ietfa.amsl.com> <78BEFFD7-2B87-4EC1-A1A3-8BDD7AB97C5F@freeradius.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-06: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 16 Aug 2018 04:07:30 -0000 --Apple-Mail=_EE508420-3884-44F4-946B-8CF6494655DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 15, 2018, at 8:14 PM, Alan DeKok wrote: >=20 > On Aug 15, 2018, at 3:55 PM, Ben Campbell wrote: >> (This is a procedural DISCUSS. Hopefully it can be resolved easily, = but I do >> think it needs to be resolved prior to publication..) >>=20 >> This draft is standards track, yet it primarily serves to extend RFC = 5176. That >> RFC is informational. The shepherd writeup argues that this is okay = because it >> seems like 5176 should have been standards track. But the = applicability >> statement RFC 5176 explains why it was informational, and the reasons = seem >> convincing. Therefore I do not think it is appropriate to publish = this draft as >> Standards Track. >=20 > We may choose Informational for this document, because it has a = normative dependency on RFC 5176. >=20 > But I don't see how those two last sentences are related. The = argument which is convincing for 5176 is not applicable to this = document. So conflating the two applicability statements is simply not = appropriate. >=20 > i.e. the issues highlighted in Section 1.1 of RFC 5176 do not apply = to this document. Any applicability statement here would be *false* if = it repeated (or even normatively referenced) the discussion in RFC 5176. What I had in mind was just a statement to the effect that, while this = extension includes normative language, it is informational because it is = based on RFC 5176, which is also informational. However, I do not understand your point that the applicability statement = from 5176 does not apply to this draft. It basically says that 5176 is = informational because CoA has (or had) issues (security, architectural, = etc) that made it inappropriate for standards track. Since this draft is = fundamentally based on 5176, it seems like it would inherit those = issues. Or do you think all those issues have been mitigated, either by = this draft or others? (The answer is probably academic, in that it = addresses the question about whether 5176 _should_ still be = informational, which doesn=E2=80=99t change the fact that it _is_.) >=20 >> I think it would be fine to progress it as Informational (or >> even Experimental) >=20 > If it's Experimental, then any possible subsequent Standards track = document would run into the same problem: 5176 is Informational. >=20 > And if we're being realistic... I think we're past the point where we = can expect RADIUS Information or Experimental documents to progress to = Standards track. I can't for the life of me think of a single RADIUS = document which has progressed from Informational or Experimental to = Proposed Standard. And, the RADIUS WG is on the verge of shutting down, = with no new work envisioned. >=20 > And if 20+ years isn't enough to make RFC 2866 (RADIUS accounting) a = Proposed Standard, then I suspect no further progress will be made in = the next 20 years. >=20 >> if it included an applicability statement explaining why in >> order to avoid the appearance of a standard masquerading as an = Informational >> RFC. >=20 > "This document is Informational because it updates RFC 5176, which is = itself Informational. None of the applicability statements in Section = 1.1 of RFC 5176 apply to this document." >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Thanks for a readable and understandable drafts. I have some = additional >> comments that do not rise to the level of a DISCUSS >>=20 >> Substantive Comments: >>=20 >> - I support Adam's DISCUSS point concerning the security properties = of >> Operator-NAS-Identifier. But I will let that play out in Adam's = thread. >>=20 >> =C2=A73.1 and =C2=A73,3: Do the normative changes to Access-Request = and >> Accounting-Request mean that this draft needs to update documents = other than >> just RFC 5176? >=20 > The document does not provide for normative changes to Access-Request = or Accounting-Request packets. As with other RFCs that define new = RADIUS attributes (e.g. 5580), it does not update RFC 2865 or 2866. >=20 > i.e. simply carrying a new attribute is not a normative change to = those packets. >=20 >> Editorial Comments: >>=20 >> - The abstract and introduction explain how this draft updates 5176, = which is >> good. However, they avoid using the explicit term-of-art "Updates RFC = 5176". >> Doing so would help make things more explicit. (The RFC style guide = recommends >> doing this at least in the abstract.) >=20 > Fixed. >=20 >> - Please expand PPTP and L2TP on first mention. >=20 > Fixed. >=20 >> =C2=A73.1: I suspect some of the normative keywords in this section = refer to >> previously existing requirements rather than new requirements. If = so, they >> should not be capitalized except in literal quotes. >=20 > The normative keywords do not refer to previously existing = requirements. >=20 >> =C2=A76: I think it would be helpful to mention the discussion in = =C2=A74.3 in the >> security considerations. >=20 > Sure. >=20 >> =C2=A77: It would be helpful for the IANA considerations to briefly = summarize the >> new attributes, so that a reader that started out reading the IANA >> considerations doesn't have to flip back to =C2=A73.3 just to find = out what they are. >=20 > The latest draft has the updates. IANA has the allocation ready, and = it has been reviewed. >=20 > Alan DeKok. --Apple-Mail=_EE508420-3884-44F4-946B-8CF6494655DD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlt0+BQACgkQgFZKbJXz 1A1qZg/7BldkScbH0EZNe+v9T1FAHQNFyck5hECmR16OynRGDBVEz8LOQ+YwMrKE KCpHy/ciKwLAKe/zyFaw06tle0vnt/p0nnIbh0ZT8WGYMRNZbo6k2rHlgH7XvweQ XWgYeVUSAGlK4kwO1ms0Qbz2ks5A+mgbAk15lBWGfY/t26ekjEqimNOtCCdCjH3P y9Ubgxv3P8LJovyvzVGvnIDbve/eL+XkQhitOJzfH00nIB7Ng3imxo5Ms3ASbIVw Xk6WW5jrQL8ZW6lD693xu/RjAyn/3eHqbnRT0lXj9cs0K/TJ36pATcbULBwKAoYF 2mvbdK//HcXOk9+JTApfVEnoVi6eGt1UaxVQWqPQse0Aa6Kq4f9mP5U/1QNrA5tV UKyCgZHBa0DxD8ZUdEsuFm0o53a2cUt9dPCUlaOOkpxNir1HslC+4Ie19exyCnVO I2NQNlhdqqIBFNNdF2FmTsp0EZuc6ktdWbwYEetUsWYOIsGXVF//2+xwMP+975DH Ri2JTC3aLgB3g3eEWguEZ8dFZlIXh5q/E/qtdujqZfdECxKizKSBqRga8wz809M4 p6dtRo/3XH547LxARNF+iyQPsYAf/zdAQfkFijuhJIKDSj04Pu96heC7EQL960iN Rj5itMgAHqU1mUem84GII2+6UUVT7I452x+T+APk7mBdfXXzTyo= =oqFc -----END PGP SIGNATURE----- --Apple-Mail=_EE508420-3884-44F4-946B-8CF6494655DD-- From nobody Thu Aug 16 03:54:08 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 B925212F1AC; Thu, 16 Aug 2018 03:54:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux 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.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153441684674.8074.4532722405251933171.idtracker@ietfa.amsl.com> Date: Thu, 16 Aug 2018 03:54:06 -0700 Archived-At: Subject: [radext] Martin Vigoureux's No Objection on draft-ietf-radext-coa-proxy-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2018 10:54:07 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-radext-coa-proxy-06: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a minor comment, the intended status is STD Track but the footer says Informational. The disconnect will need to be resolved at some point. -m From nobody Thu Aug 16 04:08: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 83637130F00; Thu, 16 Aug 2018 04:08:48 -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 6MinyjjX9Cw7; Thu, 16 Aug 2018 04:08:46 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 162B8130EFF; Thu, 16 Aug 2018 04:08:46 -0700 (PDT) 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 8262940D; Thu, 16 Aug 2018 11:08:44 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_18B9E403-065F-4F7B-B0B9-FDE9648B3FFB"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: Date: Thu, 16 Aug 2018 07:08:42 -0400 Cc: The IESG , draft-ietf-radext-coa-proxy@ietf.org, Winter Stefan , radext-chairs@ietf.org, radext@ietf.org Message-Id: <458094D6-96C1-4EC1-9CDB-DFE47F5F5C4F@freeradius.org> References: <153436290915.3118.1227345371925581329.idtracker@ietfa.amsl.com> <78BEFFD7-2B87-4EC1-A1A3-8BDD7AB97C5F@freeradius.org> To: Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-06: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 16 Aug 2018 11:08:49 -0000 --Apple-Mail=_18B9E403-065F-4F7B-B0B9-FDE9648B3FFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 16, 2018, at 12:05 AM, Ben Campbell wrote: > What I had in mind was just a statement to the effect that, while this = extension includes normative language, it is informational because it is = based on RFC 5176, which is also informational. That makes sense. > However, I do not understand your point that the applicability = statement from 5176 does not apply to this draft. It b > asically says that 5176 is informational because CoA has (or had) = issues (security, architectural, etc) that made it inappropriate for = standards track. Since this draft is fundamentally based on 5176, it = seems like it would inherit those issues. Perhaps this is a matter of semantics. On one hand, any spec built on 5176 inherits it's properties, good or = bad. On the other hand, it would be inappropriate for the coa-proxy = draft to have the same applicability text as 5176. i.e. saying "this = document is informational, because implementations of this document have = issues". That statement is simply false. > Or do you think all those issues have been mitigated, either by this = draft or others? (The answer is probably academic, in that it addresses = the question about whether 5176 _should_ still be informational, which = doesn=E2=80=99t change the fact that it _is_.) I think those issues are largely illusory, or have been mitigated = since 5176 was published. Since there is a complex topic, let me = explain by quoting Section 1.1 of RFC 5176, and commenting on it: ... While fixes are recommended, they cannot be made mandatory since this would be incompatible with existing implementations. I think we've moved on in the 10 years since that draft was published. = At this point, if implementations are insecure, it is entirely = appropriate to mark them as non-compatible. RFC 5176 was *not* simply documenting a pre-existing proprietary = protocol. It was developed in the IETF, based on RFC 3576, which was = also developed within the IETF. The "compatibility with existing = implementations" issue is a polite statement that there was no WG = consensus to make it standards track. i.e. the vendors with incompatible / insecure implementations did not = want their products to me marked as such. Existing implementations of this protocol do not support authorization checks, so that an ISP sharing a NAS with another ISP could disconnect or change authorizations for another ISP's users. That's called "trusting people you work with". The cos-proxy document = makes it clear that there are limited technical means to address abuses = by trusted parties. The limited security of RADIUS is the root cause of = this problem. However, 20+ years of practice in roman environments = shows that this trust is warranted. Abuses have been negligible, or = non-existent. The coa-proxy specification mandates not only reverse path checks, but = *additional* checks not mentioned in 5176. That would seem to mitigate = the above security issues. Existing implementations utilize per-packet authentication and integrity protection algorithms with known weaknesses [MD5Attack]. That statement is describing a fundamental property of RADIUS. i.e. it = could be applied to every single RADIUS specification, resulting in = *zero* standards-track RADIUS specifications. i.e. I think it's safe to ignore that rationale as a reason for making = the document Informational. Existing implementations lack replay protection. That statement is also describing a fundamental property of RADIUS. The approach taken with CoA commands in existing implementations results in a semantic ambiguity. Existing implementations of the CoA-Request identify the affected session, as well as supply the authorization changes. Since RADIUS Attributes included within existing implementations of the CoA-Request can be used for session identification or authorization change, it may not be clear which function a given attribute is serving. That statement is still true, and there was much discussion in the WG = about it. The WG refused even to make recommendations here, because = vendors refused to have a spec that marked their implementations as = incompatible. In practice, this ambiguity is not much of a problem. The vendor = documents what is needed, and RADIUS clients send it. In short, the reasons given in Section 1.1 of RFC 5176 are illusory in = practice. Or, they're a fundamental part of the RADIUS protocol, and = applicable to all RADIUS specifications. Further, even if those reasons *are* true, issues of "compatibility = with existing implementations" do not apply to the coa-proxy draft, = because there are few existing implementations of it. (i.e. FreeRADIUS, = which does do sane things...) On top of that, the coa-proxy draft = leverages existing implementations... whatever they are. And those = implementations (while perhaps ambiguous) manifestly work. As such, IMHO, the applicability statement of RFC 5176 can be ignored = in it's entirety. Alan DeKok. --Apple-Mail=_18B9E403-065F-4F7B-B0B9-FDE9648B3FFB 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----- iQEcBAEBCAAGBQJbdVs6AAoJEH0Oec13Yh7NZ3oH/16xkNhnfkjGOUX43y6iZnS0 7vgqq4hFEyylNlO4rrbp9U/ykj/MvuejfZdGSbzS2jzUSqUC3QIoNHFot99cNBrW y7R/OvNKjWB+nKjVn3SH0+PfhhxR2UAVRryw2LiL0uz8S6qMM0fIc6PCnRnxLqko OooiQ4pin/9Ux3HARyBEx+2thKrAvxn7Am80FQPmjoRgEgVQCiGX+Jdv9VkEhLqO lIBh7xVo1XZI4KnKpQ5ZEqK1hhx/5JIMyfMxMchyhPYe/N4alH9MdcmcHWUNSmda UfxLqlJumUsYu4Rr9ons+mA2sgBxNrpe0vgXzvacTOHTpYKKd1iwg0aguBvChBk= =KL2H -----END PGP SIGNATURE----- --Apple-Mail=_18B9E403-065F-4F7B-B0B9-FDE9648B3FFB-- From nobody Thu Aug 16 04:11:37 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 40B1B130F00; Thu, 16 Aug 2018 04:11: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 AfY_QAW43CsW; Thu, 16 Aug 2018 04:11:26 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4F268130EFF; Thu, 16 Aug 2018 04:11:26 -0700 (PDT) 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 A56C440D; Thu, 16 Aug 2018 11:11:24 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_301B6D71-BDDE-42A3-B222-519AD761DA2A"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: <458094D6-96C1-4EC1-9CDB-DFE47F5F5C4F@freeradius.org> Date: Thu, 16 Aug 2018 07:11:23 -0400 Cc: Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org Message-Id: <0FF000CF-77EE-499B-9D50-D0C0BF0CFA4A@freeradius.org> References: <153436290915.3118.1227345371925581329.idtracker@ietfa.amsl.com> <78BEFFD7-2B87-4EC1-A1A3-8BDD7AB97C5F@freeradius.org> <458094D6-96C1-4EC1-9CDB-DFE47F5F5C4F@freeradius.org> To: Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-06: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 16 Aug 2018 11:11:28 -0000 --Apple-Mail=_301B6D71-BDDE-42A3-B222-519AD761DA2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hmm... typos. "roaming" environments. not "roman" ones. Among = others. I trust the reader will read past the typos to infer the = intent. > On Aug 16, 2018, at 7:08 AM, Alan DeKok wrote: >=20 > On Aug 16, 2018, at 12:05 AM, Ben Campbell wrote: >> What I had in mind was just a statement to the effect that, while = this extension includes normative language, it is informational because = it is based on RFC 5176, which is also informational. >=20 > That makes sense. >=20 >> However, I do not understand your point that the applicability = statement from 5176 does not apply to this draft. It b >> asically says that 5176 is informational because CoA has (or had) = issues (security, architectural, etc) that made it inappropriate for = standards track. Since this draft is fundamentally based on 5176, it = seems like it would inherit those issues. >=20 > Perhaps this is a matter of semantics. >=20 > On one hand, any spec built on 5176 inherits it's properties, good or = bad. On the other hand, it would be inappropriate for the coa-proxy = draft to have the same applicability text as 5176. i.e. saying "this = document is informational, because implementations of this document have = issues". That statement is simply false. >=20 >> Or do you think all those issues have been mitigated, either by this = draft or others? (The answer is probably academic, in that it addresses = the question about whether 5176 _should_ still be informational, which = doesn=E2=80=99t change the fact that it _is_.) >=20 > I think those issues are largely illusory, or have been mitigated = since 5176 was published. Since there is a complex topic, let me = explain by quoting Section 1.1 of RFC 5176, and commenting on it: >=20 > ... While fixes are recommended, > they cannot be made mandatory since this would be incompatible with > existing implementations. >=20 > I think we've moved on in the 10 years since that draft was = published. At this point, if implementations are insecure, it is = entirely appropriate to mark them as non-compatible. >=20 > RFC 5176 was *not* simply documenting a pre-existing proprietary = protocol. It was developed in the IETF, based on RFC 3576, which was = also developed within the IETF. The "compatibility with existing = implementations" issue is a polite statement that there was no WG = consensus to make it standards track. >=20 > i.e. the vendors with incompatible / insecure implementations did not = want their products to me marked as such. >=20 > Existing implementations of this protocol do not support > authorization checks, so that an ISP sharing a NAS with another ISP > could disconnect or change authorizations for another ISP's users. >=20 > That's called "trusting people you work with". The cos-proxy = document makes it clear that there are limited technical means to = address abuses by trusted parties. The limited security of RADIUS is the = root cause of this problem. However, 20+ years of practice in roman = environments shows that this trust is warranted. Abuses have been = negligible, or non-existent. >=20 > The coa-proxy specification mandates not only reverse path checks, = but *additional* checks not mentioned in 5176. That would seem to = mitigate the above security issues. >=20 > Existing implementations utilize per-packet authentication and > integrity protection algorithms with known weaknesses [MD5Attack]. >=20 > That statement is describing a fundamental property of RADIUS. i.e. = it could be applied to every single RADIUS specification, resulting in = *zero* standards-track RADIUS specifications. >=20 > i.e. I think it's safe to ignore that rationale as a reason for = making the document Informational. >=20 > Existing implementations lack replay protection. >=20 > That statement is also describing a fundamental property of RADIUS. >=20 > The approach taken with CoA commands in existing implementations > results in a semantic ambiguity. Existing implementations of the > CoA-Request identify the affected session, as well as supply the > authorization changes. Since RADIUS Attributes included within > existing implementations of the CoA-Request can be used for session > identification or authorization change, it may not be clear which > function a given attribute is serving. >=20 > That statement is still true, and there was much discussion in the WG = about it. The WG refused even to make recommendations here, because = vendors refused to have a spec that marked their implementations as = incompatible. >=20 > In practice, this ambiguity is not much of a problem. The vendor = documents what is needed, and RADIUS clients send it. >=20 > In short, the reasons given in Section 1.1 of RFC 5176 are illusory = in practice. Or, they're a fundamental part of the RADIUS protocol, and = applicable to all RADIUS specifications. >=20 > Further, even if those reasons *are* true, issues of "compatibility = with existing implementations" do not apply to the coa-proxy draft, = because there are few existing implementations of it. (i.e. FreeRADIUS, = which does do sane things...) On top of that, the coa-proxy draft = leverages existing implementations... whatever they are. And those = implementations (while perhaps ambiguous) manifestly work. >=20 > As such, IMHO, the applicability statement of RFC 5176 can be ignored = in it's entirety. >=20 > Alan DeKok. >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --Apple-Mail=_301B6D71-BDDE-42A3-B222-519AD761DA2A 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----- iQEcBAEBCAAGBQJbdVvbAAoJEH0Oec13Yh7Nh4YIAIuwq4iF0ToYC1evVt8DQKGo w325YnUs58rOsQrpEcM9yFQ9/VSq0L+84Sraszt9YuIS8KgyD0XH+0Uyz84FQDov pEuXZGyKr+IcFUI+sMWouk3pXUo8lX1VPHe7w0KC5F1hx77xhRwQ+/FRJiNKb4BC Omej6JMChhnPVYOS58o177lmXrd0qJgGczSU5h8BstMt5aGtvGcI4ZIZB4t/HqZy OYSY8eXaY9pcvn3MdAKRE8hmnYMz1EydjpdK5Ky5YF7VjGH/k6aSR+9f88mvUzF9 doODu4lb2J7zJuo1/qscOPbQcdFAFCrx8Lkb7Dftu4tsBYPcPrx7oyY6mMeKfbM= =klRT -----END PGP SIGNATURE----- --Apple-Mail=_301B6D71-BDDE-42A3-B222-519AD761DA2A-- From nobody Thu Aug 16 07:24:26 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 C3B88130E8C; Thu, 16 Aug 2018 07:24:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell 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.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153442946379.12176.4452818330392864054.idtracker@ietfa.amsl.com> Date: Thu, 16 Aug 2018 07:24:23 -0700 Archived-At: Subject: [radext] Ben Campbell's No Objection on draft-ietf-radext-coa-proxy-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2018 14:24:24 -0000 Ben Campbell has entered the following ballot position for draft-ietf-radext-coa-proxy-06: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm clearing my DISCUSS based on discussion over email and in the telechat. I am happy to leave the outcome to Benjamin's discretion. I'm including the original text below for reference: (This is a procedural DISCUSS. Hopefully it can be resolved easily, but I do think it needs to be resolved prior to publication..) This draft is standards track, yet it primarily serves to extend RFC 5176. That RFC is informational. The shepherd writeup argues that this is okay because it seems like 5176 should have been standards track. But the applicability statement RFC 5176 explains why it was informational, and the reasons seem convincing. Therefore I do not think it is appropriate to publish this draft as Standards Track. I think it would be fine to progress it as Informational (or even Experimental) if it included an applicability statement explaining why in order to avoid the appearance of a standard masquerading as an Informational RFC. Thanks for a readable and understandable drafts. I have some additional comments that do not rise to the level of a DISCUSS Substantive Comments: - I support Adam's DISCUSS point concerning the security properties of Operator-NAS-Identifier. But I will let that play out in Adam's thread. §3.1 and §3,3: Do the normative changes to Access-Request and Accounting-Request mean that this draft needs to update documents other than just RFC 5176? Editorial Comments: - The abstract and introduction explain how this draft updates 5176, which is good. However, they avoid using the explicit term-of-art "Updates RFC 5176". Doing so would help make things more explicit. (The RFC style guide recommends doing this at least in the abstract.) - Please expand PPTP and L2TP on first mention. §3.1: I suspect some of the normative keywords in this section refer to previously existing requirements rather than new requirements. If so, they should not be capitalized except in literal quotes. §6: I think it would be helpful to mention the discussion in §4.3 in the security considerations. §7: It would be helpful for the IANA considerations to briefly summarize the new attributes, so that a reader that started out reading the IANA considerations doesn't have to flip back to §3.3 just to find out what they are. From nobody Thu Aug 16 10:35:05 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 581A4130E22; Thu, 16 Aug 2018 10:35:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: radext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: radext@ietf.org Message-ID: <153444090433.12128.11365656578196883768@ietfa.amsl.com> Date: Thu, 16 Aug 2018 10:35:04 -0700 Archived-At: Subject: [radext] I-D Action: draft-ietf-radext-coa-proxy-07.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2018 17:35:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions WG of the IETF. Title : Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS) Authors : Alan DeKok Jouni Korhonen Filename : draft-ietf-radext-coa-proxy-07.txt Pages : 21 Date : 2018-08-16 Abstract: RFC 5176 defines Change of Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. That document suggests that proxying these messages is possible, but gives no guidance as to how it is done. This specification updates RFC 5176 to correct that omission for scenarios where networks use Realm-based proxying as defined in RFC 7542. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-radext-coa-proxy-07 https://datatracker.ietf.org/doc/html/draft-ietf-radext-coa-proxy-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-coa-proxy-07 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/ From nobody Thu Aug 16 11:39:35 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 662BA130E40 for ; Thu, 16 Aug 2018 11:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 tJoDXshomDyU for ; Thu, 16 Aug 2018 11:39:23 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4755A128CFD for ; Thu, 16 Aug 2018 11:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1534444761; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=REN/iga79XkAEqdRHcq97GYrqQbAMocMCtKonH3D9jo=; b=YHthxByK0/QDLc2ucjelQ3BqXg+JkGGakLdEJ0a+pO/OhhTfsUHj3HG7Vg9GTZtp w2fXqkGx2552iiMyq9Sl7eJa3PjG2vmo2suJSMLsqEDPs61M5/Gy4OLTZmhXORm4 ALXvCKcupztwbTggNS579FJv0KQqajIXyOyAz5HMWHc=; X-AuditID: c1b4fb2d-223ff700000055ff-33-5b75c4d9a230 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 40.C9.22015.9D4C57B5; Thu, 16 Aug 2018 20:39:21 +0200 (CEST) Received: from ESESSMR502.ericsson.se (153.88.183.110) by ESESSMB501.ericsson.se (153.88.183.119) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 16 Aug 2018 20:39:21 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMR502.ericsson.se (153.88.183.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 16 Aug 2018 20:39:21 +0200 Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.185) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Thu, 16 Aug 2018 20:39:20 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 1D8ED481870; Thu, 16 Aug 2018 21:39:21 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 892F8480F3E; Thu, 16 Aug 2018 21:39:20 +0300 (EEST) To: , , , , Eric Rescorla , Benjamin Kaduk , From: Mohit Sethi Message-ID: <473c4665-0b08-05ca-c56c-2b37c4710280@ericsson.com> Date: Thu, 16 Aug 2018 21:39:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-AV-Checked: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbG9XPfmkdJog+/vNSz2/F3EbjHvyVNW ixWvz7FbzPgzkdli+caZTBZPO74wWbS8msnmwO6xZMlPJo+mM0eZPWbtfMLiMflxG3MASxSX TUpqTmZZapG+XQJXxtV/R1gLDilU7H17hLGB8ZNUFyMnh4SAicTa5S/Zuxi5OIQEjjJKLDh6 iA3C+cYocW/5RxY452HzHiYI5yKjxOXWZ1Blmxklup4eZIRwFjJKrL36DGyaiMA+RonDvbeY QdawCehJdJ47DmYLC+hKHJ3yiBHE5hWwl5j7dw8LiM0ioCrxccUJMFtUIEJi9fIXrBA1ghIn Zz4BizMLWEjMnH+eEcLWlli28DUzhC0ucevJfCaIl5QlFrQsAqsRElCX2NpxgHECo/AsJKNm IRk1C8moWUhGLWBkWcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGEkHt/zW3cG4+rXjIUYB DkYlHt6ze0qjhVgTy4orcw8xSnAwK4nwntsMFOJNSaysSi3Kjy8qzUktPsQozcGiJM6rt2pP lJBAemJJanZqakFqEUyWiYNTqoGxdkJcV/jVhSEf3C+na3HMXdAxxd6YpeZG2tl30zM32rQe f7urdY2AHQvrFU15jYfCbJOLZp0o0Qpcs1l7s71S6cyWxg2/fFdmTfxTENu9W9vLtPtse4Nz xad9rO+3Scpnxmd/PbMrztlvWUfSl0tLtd6dfOb2QOzU+91e3VPuv7226BDXj3uXlFiKMxIN tZiLihMBL6eHk6ACAAA= Archived-At: Subject: [radext] Concerns with Operator-NAS-Identifer X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 16 Aug 2018 18:39:26 -0000 Hi all, I have been a quiet observer on the radext list because of my interest=20 in EAP, RADIUS and DIAMETER deployments. Recent comments from Adam and Ekr got me to look at this draft and its=20 text on Operator-NAS-Identifer in more detail. Let me preface by first admitting that I certainly do not have as much=20 deployment experience as some others on the list. So take my comments=20 with tons of skepticism and please be a little gentle when shooting me do= wn. The draft version -06 says that visited network SHOULD add=20 Operator-NAS-Identifer attribute to the Access-Request or=20 Accounting-Request packets. And when it is added, other attributes such=20 as NAS-IP-Address, NAS-IPv6-Address, NAS-Identifier MUST be deleted. The = text also says that for meeting the requirements of Section 4.1 of=20 [RFC2865], a NAS-Identifier is added anyway. Finally, the draft says the following "We suggest that the contents of=20 the NAS-Identifier be the Realm name of the Visited Network.=C2=A0 That i= s,=20 for everyone outside of the Visited Network, there is only one NAS: the=20 Visited Network itself.=C2=A0 For the Visited Network, the identity of th= e=20 NAS is private information, which is opaque to everyone else." "We suggest" leaves a lot to interpretation in a standards document.=20 Besides, this suggestion might break some deployments. Let me explain=20 this a bit with an example: Many enterprises (rightly or wrongly) want to control which users can=20 connect to which NAS. For example, employees of ACME should be allowed=20 to connect to NAS A which allows access to the internal network and=20 resources. Guests of ACME should only be allowed to connect to NAS B=20 which allows restricted access to the Internet. Of course the situation=20 gets more complex when a shared NAS is used and access separation is=20 done with VLANs. Let's say that ACME has offices in London, Bangkok and San Jose with=20 local AAA servers and users in realms acme.uk (for London), acme.th (for = Bangkok) and acme.com (for San Jose). Employees often roam to different=20 sites of ACME. When an employee from San Jose is in London, his/her=20 authentication requests are forwarded to the AAA for acme.com based on=20 the realm in the Network Access Identifier (NAI)/Radius User-Name=20 attribute. Depending on which NAS the user is trying to connect through, the AAA=20 would decide whether to send an Access-Accept or Access-Reject. In cases = like this, the visited networks belongs to the same enterprise. The=20 visited network can choose to hide some its internal network setup by=20 using the same NAS-Identifier for a WLAN profile, VLAN interface, or AP=20 group. I found Cisco describing this scenario at this page (please see=20 the bottom of the page where it says "The NAS-ID is sent to the RADIUS=20 server by the controller through an authentication request to classify=20 users to different groups so that the RADIUS server can send a=20 customized authentication response."): https://www.cisco.com/c/en/us/td/docs/wireless/controller/7-4/configurati= on/guides/consolidated/b_cg74_CONSOLIDATED/b_cg74_CONSOLIDATED_chapter_01= 000111.html and here I found Juniper describing something similar: https://www.juniper.net/documentation/en_US/junos/topics/concept/subscrib= er-management-nas-port-id-overview.html I know of 1 deployment where such access control is done (the network=20 administrator for this deployment has changed jobs and is not a regular=20 participant but I can try and ask him to chime in). Of course there=20 might be other deployments as well. In summary, there are situations when the visited network would want to=20 differentiate the NAS classes through which a user is trying to connect=20 and reveal that to the remote AAA making the access decision. The=20 visited network is still in control of what and how much information it=20 reveals. The NAS-Identifier string provides a lot of flexibility to=20 network operators and suggesting some change to its use perhaps needs=20 more thorough reasoning. --Mohit From nobody Fri Aug 17 15:27:12 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 22DE8130E31; Fri, 17 Aug 2018 15:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 HPUG-hNIXFqq; Fri, 17 Aug 2018 15:27:11 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 80FB7130E12; Fri, 17 Aug 2018 15:27:10 -0700 (PDT) X-AuditID: 1209190f-e91ff70000004442-28-5b774bbcf4fc Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 30.27.17474.CBB477B5; Fri, 17 Aug 2018 18:27:08 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w7HMR6VQ019230; Fri, 17 Aug 2018 18:27:06 -0400 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.13.8/8.12.4) with ESMTP id w7HMR0TK008793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Aug 2018 18:27:02 -0400 Date: Fri, 17 Aug 2018 17:27:00 -0500 From: Benjamin Kaduk To: Alan DeKok Cc: Mohit Sethi , radext-chairs@ietf.org, radext@ietf.org, draft-ietf-radext-coa-proxy@ietf.org, iesg@ietf.org, Eric Rescorla , adam@nostrum.com Message-ID: <20180817222700.GU40887@kduck.kaduk.org> References: <473c4665-0b08-05ca-c56c-2b37c4710280@ericsson.com> <2804F208-BAF7-469C-8BFE-896EE30F8674@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2804F208-BAF7-469C-8BFE-896EE30F8674@deployingradius.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsUixCmqrbvHuzza4NU2OYs9fxexWzR9bmK3 mPfkKavFitfn2C1m/JnIbLHl40Zmi6cdX5gsWl7NZHPg8Gg52sLi8evrVTaPJUt+MnnM2vmE xWPy4zbmANYoLpuU1JzMstQifbsErozrv5+wFrTxVZzf2cnewLiUu4uRk0NCwESi6cQBpi5G Lg4hgcVMEovnzmaDcDYySlz7sw3KucokcevQfmaQFhYBVYndiw+yg9hsAioSDd2XweIiAloS C9YvYgFpYBY4wyix8stnVpCEsICVxIze40wgNi/Qvt073oE1CwnUSCz++o4VIi4ocXLmExYQ mxlo0I1/L4HqOYBsaYnl/zhATE4Bd4k3L0xBKkQFlCX29h1in8AoMAtJ8ywkzbMQmhcwMq9i lE3JrdLNTczMKU5N1i1OTszLSy3SNdHLzSzRS00p3cQIjgBJ/h2Mcxq8DzEKcDAq8fC+UCuP FmJNLCuuzD3EKMnBpCTK2+kBFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCG7m8LFqINyWxsiq1 KB8mJc3BoiTOe68mPFpIID2xJDU7NbUgtQgmK8PBoSTBywyMdCHBotT01Iq0zJwShDQTByfI cB6g4ae8gGp4iwsSc4sz0yHypxh1Of68nzqJWYglLz8vVUqc9w1IkQBIUUZpHtwcUOKSyN5f 84pRHOgtYd4+kCoeYNKDm/QKaAkT0JJpAqUgS0oSEVJSDYw54ZxRvoINZrGeK/cYhqyyM5X+ ntTOtnP7VKan/1gXvplV1lhatvDB3qtRJtqRVQ3rO2/IpCto+lz+/6GS4YHjtXe/g+4ufuHj d6ks4L60XL7kJJZHbTw7W1Onrt8VYZtYunp/ZZtHspx++os9rnkiFTN6//Ctz3RKvXjqV8qp kk0Tb1xXeKvEUpyRaKjFXFScCAAQIRfiNwMAAA== Archived-At: Subject: Re: [radext] Concerns with Operator-NAS-Identifer X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 17 Aug 2018 22:27:12 -0000 On Thu, Aug 16, 2018 at 02:55:00PM -0400, Alan DeKok wrote: > On Aug 16, 2018, at 2:39 PM, Mohit Sethi wrote: > > Recent comments from Adam and Ekr got me to look at this draft and its text on Operator-NAS-Identifer in more detail. Thanks for taking a look! > > In summary, there are situations when the visited network would want to differentiate the NAS classes through which a user is trying to connect and reveal that to the remote AAA making the access decision. The visited network is still in control of what and how much information it reveals. The NAS-Identifier string provides a lot of flexibility to network operators and suggesting some change to its use perhaps needs more thorough reasoning. > > I think the situation you're concerned with isn't the use-case defined in coa-proxy. So that avoids any problems. > > There is nothing in the coa-proxy that says you *must* remove NAS-Identifier, etc. I could make that clearer, I suppose. I see (in both -05 and -07) in the "Operator-NAS-Identifier" section (3.3 or 3.4, respectively): [...] When the Operator- NAS-Identifer attribute is added to a packet, the following attributes MUST be deleted: NAS-IP-Address, NAS-IPv6-Address, NAS- Identifier. The proxy MUST then add a NAS-Identifier attribute, in order satisfy the requirements of Section 4.1 of [RFC2865], and Section 4.1 of [RFC2866]. The contents of the NAS-Identifier SHOULD be the Realm name of the visited network. Does that not do what you want? (There isn't exactly anything that precludes the contents of this "newly added" NAS-Identifier from being the same value that was removed or something that would fit the use case described by Mohit, though, is there?) -Benjamin From nobody Fri Aug 17 17:49: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 527AB130F97; Fri, 17 Aug 2018 17:49:08 -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 D1r0lCo6VnfQ; Fri, 17 Aug 2018 17:49:06 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD5A130F1F; Fri, 17 Aug 2018 17:49:06 -0700 (PDT) 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 48E982E1B; Sat, 18 Aug 2018 00:49:03 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <20180817222700.GU40887@kduck.kaduk.org> Date: Fri, 17 Aug 2018 20:49:01 -0400 Cc: Mohit Sethi , radext-chairs@ietf.org, radext@ietf.org, draft-ietf-radext-coa-proxy@ietf.org, The IESG , Eric Rescorla , adam@nostrum.com Content-Transfer-Encoding: quoted-printable Message-Id: <57080C37-C7AD-4E3E-9A5C-E7613C89221F@deployingradius.com> References: <473c4665-0b08-05ca-c56c-2b37c4710280@ericsson.com> <2804F208-BAF7-469C-8BFE-896EE30F8674@deployingradius.com> <20180817222700.GU40887@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Concerns with Operator-NAS-Identifer X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 18 Aug 2018 00:49:09 -0000 On Aug 17, 2018, at 6:27 PM, Benjamin Kaduk wrote: >> There is nothing in the coa-proxy that says you *must* remove = NAS-Identifier, etc. I could make that clearer, I suppose. >=20 > I see (in both -05 and -07) in the "Operator-NAS-Identifier" section = (3.3 > or 3.4, respectively): Yes... I saw that after sending the message > [...] When the Operator- > NAS-Identifer attribute is added to a packet, the following > attributes MUST be deleted: NAS-IP-Address, NAS-IPv6-Address, NAS- > Identifier. The proxy MUST then add a NAS-Identifier attribute, in > order satisfy the requirements of Section 4.1 of [RFC2865], and > Section 4.1 of [RFC2866]. The contents of the NAS-Identifier SHOULD > be the Realm name of the visited network. >=20 > Does that not do what you want? >=20 > (There isn't exactly anything that precludes the contents of this = "newly > added" NAS-Identifier from being the same value that was removed or > something that would fit the use case described by Mohit, though, is > there?) I think it's OK to change that to a SHOULD. With a comment that not = doing so may leak private information. Alan DeKok. From nobody Mon Aug 20 14:45:34 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 055A9129619; Mon, 20 Aug 2018 14:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 oBKKDYEcvu3f; Mon, 20 Aug 2018 14:45:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5CA4F128BAC; Mon, 20 Aug 2018 14:45:30 -0700 (PDT) Received: from [10.0.1.95] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7KLjKwB047500 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 Aug 2018 16:45:23 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_896EAB4A-F625-4752-AC28-6144463CAF85"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 20 Aug 2018 16:45:19 -0500 In-Reply-To: <78BEFFD7-2B87-4EC1-A1A3-8BDD7AB97C5F@freeradius.org> Cc: Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org To: Alan DeKok References: <153436290915.3118.1227345371925581329.idtracker@ietfa.amsl.com> <78BEFFD7-2B87-4EC1-A1A3-8BDD7AB97C5F@freeradius.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-06: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 21:45:32 -0000 --Apple-Mail=_896EAB4A-F625-4752-AC28-6144463CAF85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Oops, I failed to scroll down when reading this the first time. I have = one comment on a comment: > On Aug 15, 2018, at 8:14 PM, Alan DeKok wrote: >=20 >> =C2=A73.1 and =C2=A73,3: Do the normative changes to Access-Request = and >> Accounting-Request mean that this draft needs to update documents = other than >> just RFC 5176? >=20 > The document does not provide for normative changes to Access-Request = or Accounting-Request packets. As with other RFCs that define new = RADIUS attributes (e.g. 5580), it does not update RFC 2865 or 2866. Just to be clear, I was thinking about actual normative text, not just = the adding of a new attribute. The first paragraph of =C2=A73.1 says: " When a Visited Network proxies an Access-Request or Accounting-Request = packet outside of its network, it SHOULD include an Operator-Name = attribute in the packet, as discussed in Section 4.1 of[RFC5580]=E2=80=9D The SHOULD is a new normative requirement that relates to Access-Request = of Accounting-Request. I can accept that we are talking about =E2=80=9Cpro= xies that implement this extension=E2=80=9D, if that is the intent. But = if the intent was that proxies in general SHOULD do this, that seems = different. Thanks, Ben. --Apple-Mail=_896EAB4A-F625-4752-AC28-6144463CAF85 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIyBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlt7Nm8ACgkQgFZKbJXz 1A1abg/4+sjK6+Ed48VULwW5ZFSXIQSL5CMGVI/w560qQyZtsPv2Y7CizbBXMf5G ysm6FVOeyzRyDW4BZ4du9Fio58pYOmiWOSTZqF7ECp+rQzqhD/nTwV/va5mixabp Wtvrxqtr4W4uLD+ZiIm+cJ9mQFfPpxLdnG8AFzdacLI2NYiWMngsiiVL03OMmx/V hXnX/C2ER116zxN0arAZXOf8mPJe2iVGFLLUMeCZv8PVTVrf66wQzwIooEygDSDW 0hoydi5BuUR6vLCHJ5vOTq3QwIkvYrlVnfA6YQvj9qsi2HjQr5nyotoOoT64+g1g tj0273tzR1Cp29Hora9UPiSrDj24xyFJBfJAhDVs0VQUpGOC9/Oqe6j23r+gMIXn ed3KQ8FpGZSwAf6zf1ztyiEoFm5yFICUWYkJy7pfTa40M3VyEntcyx/44rn1U+ky ASbgC7uaz4y1zsRLd8+fpPgNHKzI5e5GX08u7JXPRaMFT6BP7pubHTdzlvHYncSn 3Q7Gebjg2ZbqwOPRnzH+1Hdiogm6lZNGs7ngPeOqylZYm6hogdziWuTWS+JXikHY JxagvlRml4QyxqRH8RW258ag0iJGcQMYPZBYNa2giEbk0DcPKhyN1Srrt1MmSbMV 7IAiEH0L4gZTWWy2kVWa2hhNP+9naOfZQci6Rnoh/1pfNbF59Q== =S76y -----END PGP SIGNATURE----- --Apple-Mail=_896EAB4A-F625-4752-AC28-6144463CAF85-- From nobody Mon Aug 20 14:50:55 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 8F02B128CF3; Mon, 20 Aug 2018 14:50:49 -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 X33M-FQ6WT1Z; Mon, 20 Aug 2018 14:50:47 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1F11252B7; Mon, 20 Aug 2018 14:50:47 -0700 (PDT) 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 F33E13953; Mon, 20 Aug 2018 21:50:45 +0000 (UTC) From: Alan DeKok Message-Id: <5B036BBE-CFF6-4311-8DDE-286FF6323B9E@freeradius.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F109D5C2-4FE6-4B88-8BB0-D4F3F8983FA1"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 20 Aug 2018 17:50:42 -0400 In-Reply-To: Cc: Winter Stefan , radext@ietf.org, The IESG , draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org To: Ben Campbell References: <153436290915.3118.1227345371925581329.idtracker@ietfa.amsl.com> <78BEFFD7-2B87-4EC1-A1A3-8BDD7AB97C5F@freeradius.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-06: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 21:50:50 -0000 --Apple-Mail=_F109D5C2-4FE6-4B88-8BB0-D4F3F8983FA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 20, 2018, at 5:45 PM, Ben Campbell wrote: >=20 > Just to be clear, I was thinking about actual normative text, not just = the adding of a new attribute. The first paragraph of =C2=A73.1 says: >=20 > " When a Visited Network proxies an Access-Request or = Accounting-Request packet outside of its network, it SHOULD include an = Operator-Name attribute in the packet, as discussed in Section 4.1 = of[RFC5580]=E2=80=9D >=20 > The SHOULD is a new normative requirement that relates to = Access-Request of Accounting-Request. I can accept that we are talking = about =E2=80=9Cproxies that implement this extension=E2=80=9D, if that = is the intent. But if the intent was that proxies in general SHOULD do = this, that seems different. The intent was that the quoted sentence applied to implementations of = this document. Not to all RADIUS proxies, even if they didn't implement = this spec. Alan DeKok. --Apple-Mail=_F109D5C2-4FE6-4B88-8BB0-D4F3F8983FA1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE8n1lTTL4FC4LtEWpfQ55zXdiHs0FAlt7N7IACgkQfQ55zXdi Hs31jQgAinYyPbb2ZZuvHOns4MQImWaJL6z+oNOxvaWdFj2ehx6rOoTizaoDHoPf 4nl8N6ri8X4ut0TPct02lTs4FYIDUnQ3+Lyx7XdSEKnVM0GJs9gTMIekJqBRbZzf rrfPWHfs1vCot2v4oDEQOJwm+jU1HRM9R0k5J4ela93oDLhruGIaRLcp4ZO/nxSH HhGRr29yg5QdSMVxNlb5wGj/HmwJ0U18XPnWJ+fIv9ofHKqAdLToEtpYyF6j14la X44tPM+xttpTRLI/PRt8r9atQRiktSBq1QbzwEYwemBmoXokmtnIvlZlKF/PCWnR JFC/ExhyJzvzcBBIuQuTfpcbtnRWjA== =5fLZ -----END PGP SIGNATURE----- --Apple-Mail=_F109D5C2-4FE6-4B88-8BB0-D4F3F8983FA1--