Re: [radext] [OPSAWG] RADIUS Extension, Getting Started

Alan DeKok <aland@deployingradius.com> Fri, 10 July 2020 12:25 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 CFB263A0C98; Fri, 10 Jul 2020 05:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGYNqqyADvIs; Fri, 10 Jul 2020 05:25:57 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420BD3A0C70; Fri, 10 Jul 2020 05:25:55 -0700 (PDT)
Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id CDA7AA9; Fri, 10 Jul 2020 12:25:53 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <MN2PR08MB62230BDA9D5B4D78FEA5ADD790650@MN2PR08MB6223.namprd08.prod.outlook.com>
Date: Fri, 10 Jul 2020 08:25:52 -0400
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, "radext@ietf.org" <radext@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <17C2C808-E3B3-48D5-ACC8-1C8F93734A9C@deployingradius.com>
References: <BN7PR08MB44514D8E033B685D8BA64F83909A0@BN7PR08MB4451.namprd08.prod.outlook.com> <2064d9a1a5d54aa1899664f1f55d59aa@cert.org> <MN2PR11MB4366092A6A09FCA16421216BB5980@MN2PR11MB4366.namprd11.prod.outlook.com> <BN7PR08MB44513A5EF09B09171A852C1B90980@BN7PR08MB4451.namprd08.prod.outlook.com> <20200621024216.GF11992@kduck.mit.edu> <MN2PR11MB4366AD732CED678128212133B5970@MN2PR11MB4366.namprd11.prod.outlook.com> <CAHw9_i+a=Wi0brygvrweDO5883+teDR9Femi7aEMbF1MQURAtg@mail.gmail.com> <BN7PR08MB4451E5A877FC5DCDBACB42FC90920@BN7PR08MB4451.namprd08.prod.outlook.com> <BN7PR08MB4451E395E39AF0326A6819F7906F0@BN7PR08MB4451.namprd08.prod.outlook.com> <CE88D9AF-F9DC-485C-B47C-20DCB55F0181@cisco.com> <87adbd01-a100-7192-5b0d-fdc180ac2f5d@restena.lu> <MN2PR08MB62233158A0D7A7EA1B35AE9690690@MN2PR08MB6223.namprd08.prod.outlook.com> <1D54DD45-8F8A-4691-87C2-DC1BB5BE5C9F@deployingradius.com> <MN2PR08MB62230BDA9D5B4D78FEA5ADD790650@MN2PR08MB6223.namprd08.prod.outlook.com>
To: "Massameno, Dan" <dan.massameno@yale.edu>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/6CBz750HTYmr-0xhg51KEB-qwxM>
Subject: Re: [radext] [OPSAWG] RADIUS Extension, Getting Started
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <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: Fri, 10 Jul 2020 12:26:07 -0000

On Jul 10, 2020, at 8:08 AM, Massameno, Dan <dan.massameno@yale.edu> wrote:
> Thank you for your thorough review.  I am completely new to the IETF process (I don't even know what a "nit" is) and I'm looking forward to the process.

  "nitpick".  i.e. minor point which should be fix, but isn't very important.

  The IETF process is long, but generally worth it.

> I did want to dive into one of the last comments you made.  
> 
>        Even if the various nits and and issues above were fixed, this proposal would have serious security issues.  Even 
>        if those security issues were addressed, I believe that load balancing is simply not appropriate for 
>        the NAS.  Even if it was appropriate for the NAS, the vendors have spoken: NAS implementations 
>        are simple, and server implementations are complex.
>        As such, load balancing more properly belongs in the server.
> 
> If I have N number of RADIUS servers, how are the servers supposed to load balance if the load balancing function "belongs in the server"?

  You run a load-balancer.  This is either a hardware device which does UDP load balancing, or a dedicated RADIUS server which does nothing more than load balancing.

>  Won't the NAS need to know about all the RADIUS servers?  If yes, how does it decided on which one to user for any one particular session?

  The NAS knows about one server: the load balancing one.  Typically the load balancer can be set up in an HA pair, using VRRP to share an IP address.

  My experience is that this scenario is robust, stable, and gives the admin a great amount of control over the system.  My experience also has been that you just can't rely on the NAS to do anything sane with RADIUS.  The implementations are terrible, naive, simplistic, etc.  Just give up on fixing them, and patch over the problem with a RADIUS server that's under your control.

  It's easier for me to say, of course, having written a RADIUS server.  That does bias me a bit, I think.  But practical experience validates this approach.

  A different explanation for the NAS behaviour is that the NAS vendors are incentivized to make the core functionality work well.  e.g. switching, WiFi, etc.  Features such as RADIUS are an after-thought.  Issues with RADIUS are only fixed if a sufficient number of customers demand changes.

  In contrast, a RADIUS server vendor is strongly incentivized to implement RADIUS correctly.  And, to do load balancing correctly.  With many parameters that can be tweaked for your exact situation.

  So independent of anything else, NAS vendors simply aren't motivated to implement complex RADIUS load balancing.  Whereas RADIUS server vendors have been shipping it for decades.

> My experience with Cisco devices indicates that if multiple RADIUS servers are listed it simply uses the first one exclusively until it fails.  So, there is failover, but no load balancing.  The list of RADIUS servers are also statically configured via CLI, which is cumbersome when there is a large fleet of devices to configure.  These two overly sophomoric features were the ones I was endeavoring to fix.

  Most RADIUS clients behave the same way.  My recommendation for a long time has been to just punt on the problem of fixing the NAS.  Instead, run a RADIUS server that you control.

  One benefit is that you can upgrade the NAS, or change vendors without changing the way that load balancing works.

  And to re-iterate... RFC 5080 Section 2.1 defines retransmission behaviour for RADIUS clients.  Implementing this would make customers lives easier.  It would make RADIUS systems better and more stable.  But the incremental benefit is simply not high enough for NAS vendors to implement it.  So instead, they use fixed-count and fixed-time retransmission behaviours which were first implemented in 1993.

  In order for your proposal to gain traction, the NAS vendors MUST have strong incentive to implement it.  And I'm not sure what that incentive is.  Right now, they can just say "buy a load balancer", or "download FreeRADIUS and run it in a VM".  Problem solved.

  Alan DeKok.