Subject: [radext] Client ID exhaustion

From: Stefan Winter <[email-masked]>
Date: Wed, 26 Apr 2017 14:43:16 +0200

Hello,

we keep hearing assertions on the list that change is needed regarding
the ID field in RADIUS.

I would like to recall RFC2865's section 2.5

"If a

   NAS needs more than 256 IDs for outstanding requests, it MAY use
   additional source ports to send requests from, and keep track of IDs
   for each source port.  This allows up to 16 million or so outstanding
   requests at one time to a single server."

It's fairly clear that implementations which do not follow the MAY will
run into exhaustion problems rather soon.

It's less clear that implementations which do follow this MAY still do.
We've heard finger-in-the-air calculations on the list that this may
become a problem earlier than one might think. But is there actual
evidence to that end in deployed reality?

Can someone please share their experience regarding a deployment and
implementation which DOES implement the MAY above but STILL runs out of
RADIUS packet IDs?

Obviously, for those implementors which do not implement the MAY, the
suggestion would be to implement that before trying to make protocol
changes. The corresponding advice in RFC2865 may be 17 years old now,
but that doesn't mean it is not good advice.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Alan DeKok <[email-masked]>
Date: Wed, 26 Apr 2017 08:55:05 -0400

> run into exhaustion problems rather soon.

  I think implementations which don't open new source ports are few and far between.  They are typically simple and small.

> evidence to that end in deployed reality?

  All RADIUS servers open new ports.  All NAS equipment that costs more than $20 opens new ports.

> implementation which DOES implement the MAY above but STILL runs out of

  I've never seen one.

  The issue for me is really TCP, and accounting.  It would be useful to be able to send many accounting packets to a server.  It would be useful to "fill" a TCP connection with RADIUS traffic.  The 256 packet limit makes that impossible.

  Whether or not this proposal gets approval, I think it's useful.  If nothing else, I will likely add it as a configurable (not negotiable) extension to my implementation.

  Alan DeKok.

---

From: Enke Chen <[email-masked]>
Date: Wed, 26 Apr 2017 12:17:01 -0700

Hi, Stefan:

The case we have is with the wireless controller that needs to manage
thousands of APs and tens of thousands of clients. The wireless world
uses "centralized" management model.  The scaling requirements keep
increasing every year.

Though RADIUS is an old protocol, it is a critical piece in the wireless
world.

Thanks.  -- Enke

On 4/26/17 5:43 AM, Stefan Winter wrote:
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
>

---

From: Stefan Winter <[email-masked]>
Date: Thu, 27 Apr 2017 11:00:43 +0200

Hello,

> Though RADIUS is an old protocol, it is a critical piece in the wireless

Your reply did not indicate whether the wireless controller implements
the MAY in RFC2865 (a piece of information I specifically asked for).
Does it?

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Thu, 27 Apr 2017 11:09:29 -0400

> uses "centralized" management model.  The scaling requirements keep

  FYI, I'm aware of multiple vendors with similar use-cases.  The other vendors are using software which will open multiple source ports.

  But... there is a limit.  Depending on the version, a FreeRADIUS proxy will open 32-256 outgoing ports, and then decide that's too many ports.  Fixing that involves code changes and upgrades.

  I've seen multiple situations where a high load RADIUS proxy continually has 32 or more source ports in use.  At that point, you have to ask if it isn't more efficient to just update RADIUS.

  i.e. Asking implementations to open 1-4 source ports is reasonable.  Asking them to implement 2000 source ports for a high load situation is possible, but is less reasonable.

  Alan DeKok.

---

From: Enke Chen <[email-masked]>
Date: Thu, 27 Apr 2017 10:32:31 -0700

Hi, Stefan:

Yes, it does use multiple source ports.

Regards,   -- Enke

---

From: Ignacio Goyret <[email-masked]>
Date: Thu, 27 Apr 2017 11:46:36 -0700

>  I've seen multiple situations where a high load RADIUS proxy continually has 32 or more source ports in use.  At that point, you have to ask if it isn't more efficient to just update RADIUS.

A better alternative is to use a more appropriate tool like Diameter
which solves all these issues quite well.

>  i.e. Asking implementations to open 1-4 source ports is reasonable.  Asking them to implement 2000 source ports for a high load situation is possible, but is less reasonable.

Dealing with thousands of ports requires extra care but it is not
an impossible task.

-Ignacio

---

From: Alan DeKok <[email-masked]>
Date: Thu, 27 Apr 2017 16:09:32 -0400

> which solves all these issues quite well.

  There are multiple reasons why that's not going to happen.

  One is technical.  Diameter is rather more complex than RADIUS.  People won't implement a massive new protocol just to get incremental benefits.

  Another is economic.  There are millions of deployments of open source RADIUS solutions.  I include in this multiple WiFI equipment vendors, whose products simply wouldn't exist without open source.  They and their customers are just not going to pay six figures for a commercial Diameter implementation.

  The biggest single failure of Diameter is it's inability to provide a smooth upgrade path from RADIUS.

> Dealing with thousands of ports requires extra care but it is not

  I used said "less reasonable", not "impossible".

  The additional gyrations required to scale an application to 1000's of ports are the same, or maybe slightly more complex than the changes required by my proposal.

  While opening multiple source ports is a technical solution, proposals from multiple people seem to indicate it's not a good solution.  You can believe that the people making these proposals are incompetent, or you can believe that they have good reasons for their proposals.

  Alan DeKok.