If you want to go in this direction: build a control-plane application. You could use a variant of the data-plane whitelist/blacklist applet to punt / drop / forward traffic from a given source-IP address.
Add a policer to rate-limit punts to what the external application can handle. Its job is to do the RADIUS dance, and to program whitelist/blacklist tables to forward traffic. Adding a full RADIUS stack data plane plugin could be made to work, but I suspect that you won’t find any takers for that idea. HTH… Dave From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of init via Lists.Fd.Io Sent: Friday, February 23, 2018 12:36 AM To: vpp-dev@lists.fd.io Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] RADIUS authentication #vpp I think, RADIUS should accept following attributes: 1) Login IP address (private address, for mapping NAT 1:1) 2) Framed IP address (public address, if NAT 1:1 is required) 3) Downstream speed (for speed limit, of course, VPP should work as speed shaper, or NAT plugin should work with speed shaper) 4) Upstream speed (according to the above-mentioned) 5) State (allow, disallow) for next actions: 5.1 - redirect to another host:port (if we are talking about ISP, for redirect to a host with http page with payment) 5.2 - allow NAT to limited ip list Yep, i understand, this difficult, but this is not so bad idea for authentication, let me know if anybody know best idea to authenicate client :)
