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

From: Alan DeKok <[email-masked]>
Date: Mon, 6 Jul 2020 16:16:15 -0400

On Jul 6, 2020, at 11:40 AM, Massameno, Dan <[email-masked]> wrote:
> 
> Dear Ops and Management Area WG,
> 
> There have been a number of great suggestions on where to post this document (Thanks Stefan!).   I'm now emailing [email-masked] and cc'ing [email-masked].  
> 
> The draft is posted here... https://tools.ietf.org/html/draft-massameno-radius-lb-00
> 
> Do I need an official IETF sponsor?  Would it help to try and get a vendor interested in implementing the protocol?  Cisco is our primary vendor at Yale University.  I was wondering if there is anyone on either of these working groups that communicates with Cisco people on a regular basis?

  There are lots of Cisco people.  I'm sure some of those people have opinions.

  There are a few things ongoing here.  The RADEXT WG is still alive, but inactive.  There is a still an open discussion in the WG about previous documents which addressed shortcomings in the base RADIUS protocol.  The polite version is that the long-term RADEXT participants supported one draft.  Many people who had never been involved with RADEXT supported a competing draft.  There was never any resolution.  The RADEXT WG was left in limbo.

  I'll avoid the subject of the best place for this draft.

  Overall, I would oppose this draft.  For the simple reason that brains belong in the RADIUS server, not in the NAS.  NAS vendors haven't even implemented the retransmission behaviours suggested in RFC 5080 Section 2.1, which is well over a decade old at this point.  If they can't do that, how can they implement an even more complex load-balancing system?

  Further, there is no standard in RADIUS for load-balancing with fail-over and fail-back.  Every NAS vendor and RADIUS vendor does something different.  While this document tries to address that issue, it does not address a number of key points.

  I do have a review, as follows.  Many of these issues given below are nits, and can be fixed by rewording the document, or moving to an approach which follows existing standards (RFC 6158, RFC 6929, RFC 8044).  However, for reasons given above, I don't think it's useful to move ahead with this document.

* Section 2 - Message Summary

   I recommend deleting this part.  The RADIUS packet format is well known.  There's no need to repeat the definition here.  Just refer to RFC 5997.

* Section 2.2 - nitpick: 191 is not defined, so it's likely best to leave this attribute value as TBD, even if IANA is likely to choose 191.

  Further, RADIUS definitions use consistent names for attributes.  The names do not change when they're used in different packet types.  The attribute should just be called something like "Load-Balance-Status"

* Section 2.3.2 - the text here is simply wrong.  The Request-Authenticator is not "hashed with the identity material from the calling-station
   and the RADIUS shared secret."

   RFC 5997 Section 5 already mandates the use of Message-Authenticator with Status-Server.

  I suggest deleting 2.3.2 entirely.

* Section 3 - the definition of the LB-Request does not satisfy the requirements of RFC 6929 Section 5.2.  There is no reason to use a 16-bit data type here.

  https://tools.ietf.org/html/rfc6929#section-6.2

  RFC 8044 also defines data types which are appropriate for use in RADIUS.  That RFC also suggests that there is no longer need for ASCII art in most cases, as attribute definitions can just use predefined data types.

  Also in general, reserved bits should go at the top of an integer attribute.  Status bits should be in the lower bits.

* Section 4.1 redefines attribute 191 to contain completely different data.  This definition violates the prohibition on polymorphic attributes given in RFC 6159 Section 3.4

https://tools.ietf.org/html/rfc6158#section-3.4

  I suggest using two different attributes, one for signalling client to server, and another for responding server to client.

  The text in this section is also unclear:

Server_Info
     The String field is one or more server_info PDUs.  Each PDU defines
     the status of a single server and its defining characteristics.

  What does that mean?  Is the intent to carry the SVR-Record attributes inside of attribute 191?  If so, then using attribute 191 as both a 16-bit bitfield, and as a TLV carrier is very odd.  It's safe to say that nothing will ever support this.  I suggest using two different attrributes.

  I suggest simply relying on the existence of one or more SRV-Record attributes in the reply.  There is no need to repeat the LB-* attribute.

* Section 5 The SRV-Record TLV

  This section does not define any TLV attribute.  It's not clear what this means.

* Section 5.1 and 5.2

 It's not clear why two different attributes are needed.  Why not just use SRV-Record?

  And there's no need to repeat ASCII art.  RFC 8044 Section 3.13 already defines the TLV data type, and format.  You should just reference that.

* Section 5.3 defines a table of attributes, including attributes not previously seen in the document.

  I suggest moving the table of attributes to later in the document, *after* the relevant attributes have been defined.

* Section 6

 There's no need for ASCII art.  RFC 8044 Section 2.1.2 makes this clear.  Just reference the data types.

* Section 7.1

  The document says:

   ...  Under these
   Status-Server-LB rules the NAS MUST send all RADIUS messages relative
   to a particular session to the same RADIUS server to maximize the
   probability of a cache-hit.

  What then, is the utility of land balancing?  If one RADIUS server goes down, cannot the NAS send packets for a session to a different, but *equivalent* RADIUS server?  This recommendation seems to drastically increase the likelihood of losing accounting packets, which seems bad.

  In addition, the discussion of "caching" seems odd, and uncommon.  Databases do user replication, not RADIUS servers.  We should not expose implementation details in a standard document.

  i.e. the RADIUS servers should be treated as identical, and local balancing should be done on a packet by packet basis.

* Section 7.2

  The document says:

   The weight field specifies a relative weight for entries with the
   same priority.  Larger weights SHOULD be given a proportionately
   higher probability of being used for AAA services. 

  Ok, *how* is this to be done?  Specifying this behaviour seems important.  Perhaps adding up all weights of a similar priority, and choosing a "W_i" at random, with probability W_i / Sum(W_0. ... W_n)

* Missing: discussion of shared secrets, authentication vs accounting, ports, TLS, TCP, etc.

  What shared secret is used for these different RADIUS servers?  The same one as used in the original Status-Server?

  What ports should the NAS send packets to?  Does this load balancing work for all packet types?

  What about TCP, UDP, TLS, etc.?  How does this proposal interact with dynamic discovery? (RFC 7585)

* Section 8

  The document says:

   RADIUS Server Load Balancing has many of the same security
   implications as the base RADIUS protocol.

  There are many additional security issues opened up by this new capability.  They should be discussed.

* Section 10

  The document says:

   The Vendor Specified Attribute 26 may be used to encapsulate the LB-
   Request and LB-Response PDU where no vendor interoperability is
   required.

   It is very odd to put standards text inside of an "IANA considerations" section.  Further, this text appears to be confused about the purpose of the RADIUS attribute numbers.  These numbers are location-sensitive. i.e. vendor attribute "191" has no relation whatsoever to attribute "191" in the main RADIUS space.  Similarly, it has no relation to an attribute "191" from another vendor.

  This text is wrong and should be deleted.

Summary:

  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.

  Alan DeKok.

---

From: "Massameno, Dan" <[email-masked]>
Date: Mon, 6 Jul 2020 15:40:56 +0000

Thank you for your help.

--Dan

-----Original Message-----
From: Stefan Winter <[email-masked]> 
Sent: Friday, July 3, 2020 01:52
To: Joe Clarke (jclarke) <[email-masked]>; Massameno, Dan <[email-masked]>
Cc: [email-masked]; Benjamin Kaduk <[email-masked]>; Roman Danyliw <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; OpsAWG-Chairs <[email-masked]>; [email-masked]
Subject: Re: RADIUS Extension, Getting Started

Hello Joe,

thanks for reaching out. RADEXT is dormant since a number of years already. I'm afraid if you were to send the document that way, you would get little to no review.

I think the best way forward is to take this to OPSAWG and send a mail to radext about the draft just in case.

Greetings,

Stefan Winter

Am 30.06.20 um 17:21 schrieb Joe Clarke (jclarke):
> Thanks, Dan.  I’m also copying the radext-chairs to get their perspective on this.
>
> Joe
>
>> On Jun 30, 2020, at 11:03, Massameno, Dan <[email-masked]> wrote:
>>
>> Warren,
>>
>> I have the RADIUS extension draft now posted:
>> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo
>> ls.ietf.org%2Fhtml%2Fdraft-massameno-radius-lb-00&amp;data=02%7C01%7C
>> dan.massameno%40yale.edu%7Cc0b3c01a3a9d44d004c308d81f152ef2%7Cdd8cbeb
>> b21394df8b4114e3e87abeb5c%7C0%7C0%7C637293523139392341&amp;sdata=7dOp
>> ZmU5Xsj2tusf2Fiukqv1oxd2b8uL4Po%2BI04hw%2BE%3D&amp;reserved=0
>>
>> Abstract
>>
>>   This document describes a method for a Network Access Server (NAS) to
>>   dynamically discover all available RADIUS servers.  It defines a new
>>   message type within the STATUS-SERVER message, which is requested by
>>   the NAS and provided by the RADIUS server.  The NAS is then able to
>>   load balance its RADIUS messages across multiple RADIUS servers based
>>   on priority and weight supplied by the initial server.
>>
>> Base on the draft do you have a better idea on if this should be posed into RADEXT or OPSAWG?  I must admit I am not familiar with either of these groups.
>>
>> Thank you for your help.
>>
>> --Dan
>>
>> -----Original Message-----
>> From: Massameno, Dan
>> Sent: Thursday, June 25, 2020 10:56
>> To: Rob Wilton (rwilton) <[email-masked]>
>> Cc: Benjamin Kaduk <[email-masked]>; Roman Danyliw <[email-masked]>; 
>> OpsAWG-Chairs <[email-masked]>; Warren Kumari 
>> <[email-masked]>
>> Subject: RE: RADIUS Extension, Getting Started
>>
>> Rob,
>> Thank you and the extended team for all your help.  I have uploaded draft-massameno-radius-lb to the I-D Submission system.  Also attached is the PDF version.
>>
>> I'm very much interested in seeing how the process goes from here.  Please let me know how I may be of assistance.
>>
>> --Dan
>>
>> -----Original Message-----
>> From: Warren Kumari <[email-masked]>
>> Sent: Monday, June 22, 2020 18:00
>> To: Rob Wilton (rwilton) <[email-masked]>
>> Cc: Benjamin Kaduk <[email-masked]>; Massameno, Dan 
>> <[email-masked]>; Roman Danyliw <[email-masked]>; OpsAWG-Chairs 
>> <[email-masked]>
>> Subject: Re: RADIUS Extension, Getting Started
>>
>> On Mon, Jun 22, 2020 at 1:06 PM Rob Wilton (rwilton) <[email-masked]> wrote:
>>> Hi Ben,
>>>
>>> Good catch re Radext, copying Warren.  Warren, the question is whether RADEXT is still active and taking new work, or whether it should go to OPSAWG instead?  I have a slight concern whether we will get enough interest for this work in OPSAWG ...
>> Without knowing a bunch more about the draft I don't really think that this is a question that I can usefully weigh in on.
>>
>> If it is an extension to RADIUS/is heavily RADIUS focused, then RADEXT is probably the right place -- but, it could always be aimed at RADEXT (put -radext- in the draft name), but we can try and stir up some interest in OPSAWG. If it turns out that it is RADIUS related, and RADEXT doesn't want to pick it up and run with it, perhaps that's a strong signal that RADEXT should be closed...?
>>
>> W
>>
>>> Regards,
>>> Rob
>>>
>>>
>>>> -----Original Message-----
>>>> From: Benjamin Kaduk <[email-masked]>
>>>> Sent: 21 June 2020 03:42
>>>> To: Massameno, Dan <[email-masked]>
>>>> Cc: Rob Wilton (rwilton) <[email-masked]>; Roman Danyliw 
>>>> <[email-masked]>; OpsAWG-Chairs <[email-masked]>
>>>> Subject: Re: RADIUS Extension, Getting Started
>>>>
>>>> On Fri, Jun 19, 2020 at 12:58:12PM +0000, Massameno, Dan wrote:
>>>>> Rob,
>>>>> This sounds great.  With the links provided by Roman I am 
>>>>> reviewing the
>>>> literature to make sure my draft has everything it needs to start 
>>>> the process.  I found references to xml2rfc and kramdown, which I 
>>>> also want to run it through.
>>>>> Thank you for your help.  I would be happy to have someone take a 
>>>>> look
>>>> before it's posted.  As soon as I have it formatted correctly I'll 
>>>> send it over.  Is there someone in particular I should send it to?
>>>>
>>>> I would recommend uploading the internet-draft to the IETF 
>>>> datatracker at 
>>>> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd
>>>> a 
>>>> tatracker.ietf.org%2Fsubmit%2F&amp;data=02%7C01%7Cdan.massameno%40y
>>>> a 
>>>> le.edu%7C112cacc6da6a40e6560708d816f7c0b9%7Cdd8cbebb21394df8b4114e3
>>>> e
>>>> 87abeb5c%7C0%7C0%7C637284600637313249&amp;sdata=EkkSwHAB%2BAV3XQDz%2FsYJMsBLiKymz6n4BROVWGbg7Yg%3D&amp;reserved=0 and then sending a link to that document to both [email-masked] and [email-masked].  It's also okay to skip the first part and send the document itself to those addresses.
>>>>
>>>> The radext (RADIUS Extensions) working group is not very active at 
>>>> the moment, which is why I agree with the others' recommendations 
>>>> to ask the OPSAWG working group chairs' advice as well.
>>>>
>>>> Hope this helps,
>>>>
>>>> Ben
>>
>>
>> --
>> I don't think the execution is relevant when it was obviously a bad idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
>>   ---maf

---

From: Oleg Pekar <[email-masked]>
Date: Tue, 7 Jul 2020 16:35:30 +0300

Hi Dan,
So the draft describes how a NAS connected to a specific RADIUS server
can obtain from that server information about other RADIUS servers on
the deployment, together with their priorities. Usually the RADIUS
traffic distribution is configured and conducted by a Load Balancer
network component (e.g. F5 Load Balancer). The mechanism described in
this draft allows RADIUS servers on the deployment to balance traffic
between them dynamically according to their load or other
characteristics. However it requires implementation on both sides - on
NAS and RADIUS server.

Is my understanding correct?

Thanks
Oleg

On Tue, Jul 7, 2020 at 12:13 PM Massameno, Dan <[email-masked]> wrote:
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: "Massameno, Dan" <[email-masked]>
Date: Tue, 7 Jul 2020 21:11:41 +0000

Oleg,
You are correct.  When a protocol (service) wants to scale out I believe the least effective way is to throw a completely different components (load balancers) at the problem, which creates additional components that network operators need to maintain. 

Load balancing with DNS SRV records or (optimally) load balancing right within the protocol seems to have multiple operational advantages.  This draft takes the latter approach.

--Dan

-----Original Message-----
From: Oleg Pekar <[email-masked]> 
Sent: Tuesday, July 7, 2020 09:36
To: Massameno, Dan <[email-masked]>
Cc: [email-masked]; Roman Danyliw <[email-masked]>; [email-masked]; Rob Wilton (rwilton) <[email-masked]>; Stefan Winter <[email-masked]>; Joe Clarke (jclarke) <[email-masked]>; OpsAWG-Chairs <[email-masked]>; Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [radext] RADIUS Extension, Getting Started

Hi Dan,
So the draft describes how a NAS connected to a specific RADIUS server can obtain from that server information about other RADIUS servers on the deployment, together with their priorities. Usually the RADIUS traffic distribution is configured and conducted by a Load Balancer network component (e.g. F5 Load Balancer). The mechanism described in this draft allows RADIUS servers on the deployment to balance traffic between them dynamically according to their load or other characteristics. However it requires implementation on both sides - on NAS and RADIUS server.

Thanks
Oleg

On Tue, Jul 7, 2020 at 12:13 PM Massameno, Dan <[email-masked]> wrote:
> The draft is posted here... 
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-massameno-radius-lb-00&amp;data=02%7C01%7Cda
> n.massameno%40yale.edu%7C34e34cfac5704a9c76c808d8227aa66c%7Cdd8cbebb21
> 394df8b4114e3e87abeb5c%7C0%7C0%7C637297257462087673&amp;sdata=gXtQoloW
> qvXsjTdwk%2B%2FuBe7WfpNs4LZYBeApKYNwqjQ%3D&amp;reserved=0
>
> Cc: [email-masked]; Benjamin Kaduk <[email-masked]>; Roman Danyliw 
> <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; 
> OpsAWG-Chairs <[email-masked]>; [email-masked]
> >> <[email-masked]>; Roman Danyliw <[email-masked]>; 
> >> OpsAWG-Chairs <[email-masked]>
> >>>>> Thank you for your help.  I would be happy to have someone take 
> >>>>> a look
> >>>> before it's posted.  As soon as I have it formatted correctly 
> >>>> I'll send it over.  Is there someone in particular I should send it to?
> >>>>
> >>>> The radext (RADIUS Extensions) working group is not very active 
> >>>> at the moment, which is why I agree with the others' 
> >>>> recommendations to ask the OPSAWG working group chairs' advice as well.
> >>>>
> >>>> Hope this helps,
> >>>>
> >>>> Ben
> >>
> >>
> >> --
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fradext&amp;data=02%7C01%7Cdan.massamen
> o%40yale.edu%7C34e34cfac5704a9c76c808d8227aa66c%7Cdd8cbebb21394df8b411
> 4e3e87abeb5c%7C0%7C0%7C637297257462087673&amp;sdata=jaaVVmgUe8Y2uOermp
> AKYq6iM6OQcEJCUMNZ%2F8CGw6k%3D&amp;reserved=0

---

From: "Massameno, Dan" <[email-masked]>
Date: Fri, 10 Jul 2020 12:08:05 +0000

Alan,
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.

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"?  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?

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.

--Dan 

-----Original Message-----
From: Alan DeKok <[email-masked]> 
Sent: Monday, July 6, 2020 16:16
To: Massameno, Dan <[email-masked]>
Cc: [email-masked]; [email-masked]; OpsAWG-Chairs <[email-masked]>; Benjamin Kaduk <[email-masked]>; [email-masked]
Subject: Re: [OPSAWG] RADIUS Extension, Getting Started

On Jul 6, 2020, at 11:40 AM, Massameno, Dan <[email-masked]> wrote:
> The draft is posted here... https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-massameno-radius-lb-00&amp;data=02%7C01%7Cdan.massameno%40yale.edu%7C6e11e17859e34020f10408d821e9727e%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637296633820432892&amp;sdata=diYmvpvWJyIfYY%2FCerbLRHgniQbbkgp%2BWxoLm9h9k5c%3D&amp;reserved=0
> 

  https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6929%23section-6.2&amp;data=02%7C01%7Cdan.massameno%40yale.edu%7C6e11e17859e34020f10408d821e9727e%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637296633820432892&amp;sdata=Gz%2FOD3vyw1JpqYdvPTiLOzvf8mpC5t4iRZixCdnkjyU%3D&amp;reserved=0

https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6158%23section-3.4&amp;data=02%7C01%7Cdan.massameno%40yale.edu%7C6e11e17859e34020f10408d821e9727e%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637296633820432892&amp;sdata=fBLI70Az70EKFP5DiN%2FIsfjQfmAKl1ajetrhjqIQvRY%3D&amp;reserved=0

Server_Info

* Section 5.1 and 5.2

* Section 6

* Section 7.1

  The document says:

   ...  Under these

* Section 7.2

  The document says:

* Section 8

  The document says:

* Section 10

  The document says:

Summary:

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 10 Jul 2020 08:25:52 -0400

> 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.

> 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 li…

  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.

---

From: "Massameno, Dan" <[email-masked]>
Date: Wed, 15 Jul 2020 12:09:30 +0000

Alan,

These are very interesting points.  I had a couple of questions.

1. If a FreeRADIUS server was just setup to do proxy forwarding (no policy decisions at all) and is designed to load balance across N number of back-end Cisco ISE servers, how many auths/second do you think it could handle, given modern hardware?  I realized "given current hardware" is a loaded question.  I just want to see if we're in the right ball park for something that can handle the load we're talking about.  We're expecting > 150 per second.  

2. When then authentication gets to its it's final Cisco ISE server and that server then needs to send a CoA to the original NAS, would that work?  Would it send it through the RADIUS Proxy or directly to the NAS?

I'll have to read the RADIUS proxy RFCs.  I have not dived deep into them because I didn't think we would be using any proxies in our deployment.

--Dan

-----Original Message-----
From: Alan DeKok <[email-masked]> 
Sent: Friday, July 10, 2020 08:26
To: Massameno, Dan <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [OPSAWG] RADIUS Extension, Getting Started

  Alan DeKok.

---

From: "Massameno, Dan" <[email-masked]>
Date: Wed, 15 Jul 2020 15:29:41 +0000

Oleg,
Your summary is correct.  The end-goal would be to remove the load balances from the equation, thereby simplifying the operational complexity of the system.
--Dan

-----Original Message-----
From: Oleg Pekar <[email-masked]> 
Sent: Tuesday, July 7, 2020 09:36
To: Massameno, Dan <[email-masked]>
Cc: [email-masked]; Roman Danyliw <[email-masked]>; [email-masked]; Rob Wilton (rwilton) <[email-masked]>; Stefan Winter <[email-masked]>; Joe Clarke (jclarke) <[email-masked]>; OpsAWG-Chairs <[email-masked]>; Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [radext] RADIUS Extension, Getting Started

Hi Dan,

Thanks
Oleg