Re: Extending RADIUS Attribute Space

[Jari Arkko <jari.arkko@piuha.net>]

Avi Lior wrote:
> I can't give you an example because its not possible to do this today using
> RADIUS attribute.
>
> However, EAP/TLS and EAP/PEAP, both are sending attributes that transcend
> the boundary of a RADIUS packet.  So its not hard to imagine the need for
> this.
I'm not sure I follow. EAP TLS supports fragmentation, so it will really
send its messages piece-by-piece to the peer. In this case the limiting
factor is not typically RADIUS, its the link layer which might not support
very long packets. And EAP layer does not support fragmentation in a
general sense, so the methods are responsible for this.

But it has been discussed that if you use EAP TLS in a context where EAP
is run over IP, then IP could take care of fragmentation. Thus there could
be large packets. For instance when running EAP TLS under IKEv2 (a weird
combination by anyone's standards), the IKEv2 GW might be talking over
RADIUS to a AAA server, and require 10K messages, because the GW indicated
to AAA server EAP module that 10K was OK. However, even in this case the
AAA server EAP module should be able to figure out that 10K is not OK,
given that it knows it is running over RADIUS.

So I'm not certain if EAP TLS support is an argument. But there
might be other cases.

> As well, we have been involved in a case where someone wanted to do a packet
> audit against a wireless session where a counter is reported against a range
> of IP addresses. These counters and Ipaddress are stored in a container
> attribute.  This container attribute would span a RADIUS accounting packet.
> Note: The issue was dropped for other reasons.
Yes, a per-destination accounting record would be quite interesting.
The transport issues of this are quite interesting, too...

--Jari



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>