[c-nsp] Cisco ASR 9k and Windows RADIUS server

[Nathan Ward]

> On 9/05/2016, at 19:58, Kimaru Mansour <kimaru at gmail.com> wrote:
> 
> So I did some more experimenting with this in the lab and I can confirm
> that it is not broken in XR 4.3.2
> I took PCAPs to compare 5.3.2 based Access-req with 4.3.2 based Access-req
> and one thing that stands out, is that in the 5.3.2 Access-req the
> NAS-IPv6-Address attribute is sent out with an invalid/wrong length and
> that a bug was raised for that with ID CSCuy37396
> Furthermore I did some research on NPS handling of errors and I am fairly
> confident at this time that the bad NAS-IPv6-Address length is causing it
> after reading this: https://technet.microsoft.com/en-us/library/cc735403
> I am thinking that the NPS is sensitive to that "broken" attribute and I
> have not found a way yet to filter it out or ignore it in NPS. Not even
> sure if it is possible.


Hi,

I have had this problem as well, we use FreeRADIUS. We write out to disk, then read the files in before proxying to a backend server. FreeRADIUS was writing them out as Attr-95 rather than NAS-IPv6-Address, and was steadily chewing up memory creating new ‘Attr-95’ attribute names in memory when reading them in. So, we hit both a Cisco bug, and a FreeRADIUS bug at the same time. The FreeRADIUS bug is fixed, but we also developed a workaround in the interim. Actual to be honest, I haven’t tested the latest, fix - I really should do that. A job for later on this evening perhaps.

Anyway, the idea was we wanted the attribute to be recognised so we could filter it before dealing with the rest of the packet (i.e. in our case, before writing it to disk). In order to do this, we changed the type for a NAS-IPv6-Address in the dictionary to be Octets, which allows an arbitrary length string of obviously, octets. Once FreeRADIUS could ‘see’ the attribute, we could filter it.

I am not familiar with NPS, but perhaps you can do something like this tweaking the dictionary. Failing that, it would be a trivial FreeRADIUS configuration to proxy this through and filter it until this (totally bone-headed) bug is fixed.

Here is the start of the thread on this, on the FreeRADIUS list.
http://lists.freeradius.org/pipermail/freeradius-users/2016-March/082547.html

--
Nathan Ward