RFC7499 support

[Arran Cudbard-Bell]

> On Apr 21, 2016, at 2:26 PM, Peter Lambrechtsen <peter at crypt.nz> wrote:
> 
> On Apr 21, 2016 9:14 PM, "Sergey V. Lobanov" <sergey at lobanov.in> wrote:
>> 
>> Hi, Alan
>> 
>> In our setup radius-reply (access-accept) is very long (>4096 bytes),
> because we need to send the information for each end customer device is
> subscriber's context.
> 
> Sounds like a very inefficient NAS you are using or have configured it in a
> bizarre way.
> For our deployment which handles 500k+ broadband customers the Access
> Accept is 500 bytes. It could have been smaller if we had chosen shorter
> plan names as a number rather than something human readable that are
> configured on the NAS and customers are mapped to and shorter unique
> subscribe ids rather than the 20 digit one we use. The response packet size
> was all determined by how complicated we wanted to make it.
> 
> I was recently asked by capacity planners when I thought we were going to
> need to move from a 1gb lan port to 10gb. My response was never as there
> juat simply isn't that much traffic generated by radius. 1500 bytes for the
> request, accept, two starts and the acks.
> 
> A 4k Access Accepts sounds like you're doing something incredibly complex
> when I'm sure something simple will work more effectively.

SAML or PCRF maybe?

A fair few NAS also support dynamic firewall rules.  Much nicer to do this stuff
at the edge where you can distribute the load between hundreds or thousands
of devices, than have central firewall that can break or become overloaded.

The obvious solution to the firewall issue without resorting to massive packets
is a hybrid approach between collections of boilerplate rules that you can
reference, and user specific rules.

-Arran
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20160421/5444e546/attachment.sig>