IETF Logo Mail Archive

Re: [radext] Extended IDs

Alan DeKok <aland@deployingradius.com> Wed, 13 December 2017 13:20 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15162126B6D for <radext@ietfa.amsl.com>; Wed, 13 Dec 2017 05:20:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TkEmuJu9iL7 for <radext@ietfa.amsl.com>; Wed, 13 Dec 2017 05:20:08 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id C0F4C126CD8 for <radext@ietf.org>; Wed, 13 Dec 2017 05:20:05 -0800 (PST)
Received: from [192.168.2.25] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id A680216A; Wed, 13 Dec 2017 13:20:04 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com>
Date: Wed, 13 Dec 2017 08:20:03 -0500
Cc: Peter Deacon <peterd@iea-software.com>, "radext@ietf.org" <radext@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4AE47D4-C76E-470E-BBB6-110F69278A0B@deployingradius.com>
References: <fef698a5-9802-c9be-04d7-1e869651c988@restena.lu> <dfd0ff02-c9e8-7253-4fb4-1e6def3e93b2@restena.lu> <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> <AE2036D0-1294-45B5-A0D7-16F91E0B4248@cisco.com> <alpine.WNT.2.21.1.1712121615090.2252@smurf> <EE3BB1A7-EAD9-4BE1-9EA2-B780580E5C95@cisco.com> <alpine.WNT.2.21.1.1712121704430.2252@smurf> <B41EF4CD-309C-4E0F-BE7A-B77A244DA421@cisco.com> <alpine.WNT.2.21.1.1712121824110.2252@smurf> <313FEFCE-FD61-4394-804D-91BAE98CA687@cisco.com> <alpine.WNT.2.21.1.1712121947300.2252@smurf> <38A550CE-C1E5-441E-B25E-7E87D266F627@cisco.com>
To: "Naiming Shen (naiming)" <naiming@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/LWlGhKLJuy9iTPSIvMul12U-qX4>
Subject: Re: [radext] Extended IDs
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Dec 2017 13:20:11 -0000

On Dec 13, 2017, at 1:08 AM, Naiming Shen (naiming) <naiming@cisco.com> wrote:
> 
> When I say “check the status of the server”, sorry I didn’t mean the server-status
> message. When an operator decides to do manual configuration of a new feature
> and override the normal automated discovery procedure, he/she needs to check
> the radius server and/or radius proxy server software version, status, etc. He/she would
> not just blindly configure the new feature, and go home to sleep and assume
> everything is fine. That's just common sense. 

  I agree.  Many administrators don't. :(  I've seen some "inventive" administrative practices.

  It would be good to have a solution that is robust in the event of misconfiguration, or software changes.

  i.e. I upgrade my RADIUS server, but don't tell people who send packets to it.  If those servers are statically configured to do extended-ID, then the extended-id attribute will "leak" to my server, and to any later proxy servers.

  My concern is that the Extended-ID is intended for signalling in one hop, and should not leak across proxy chains.

> BTW, Status-server is not supported universally is not a problem here.
> When the server software supports this draft, then it MUST implement the
> Status-server message at least for this feature.

 Then I would also suggest mandating that manually enabling it on the client is forbidden.

  And should the negotiation be done on every connection from client to server?  If not, why not?

  The bulk of draft-dekok goes through all of these issues and tries to give explanations.  Much of that text is applicable to both drafts.

  And because draft-dekok is largely implemented on the server, manually enabling it on the client doesn't really do much.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email