Subject: [abfab] an attribute assignment unfortunateness

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Mar 2013 10:34:21 -0500

The IANA has assigned us 

ATTRIBUTE GSS-Acceptor-Service-Name                     164     string

for our service name.

Unfortunately, it looks like Ascend (remember them from times gone by)
squatted on this attribute:
root@debian:/usr/share/freeradius# grep -i X-Ascend-FR-DCE-N393 *
dictionary.ascend.illegal:ATTRIBUTE     X-Ascend-FR-DCE-N393
164      integer

do we care?
I don't have enough RADIUS experience to evaluate this.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 07 Mar 2013 10:47:00 -0500

> squatted on this attribute:
...
> do we care?

  No.

> I don't have enough RADIUS experience to evaluate this.

  Most of the equipment using that attribute is either dead, or can be
configured to *not* use it.

  There may be issues with broken RADIUS servers (see Operator-Name).
But the solution there is the same: fix the broken software.  It's not hard.

  This squatting issue will come up for *all* of the new RADIUS
attributes.  The only approach is to ignore it.  People still using
broken equipment need to upgrade before using new standards.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Thu, 07 Mar 2013 16:53:58 +0100

Hi,

> dictionary.ascend.illegal:ATTRIBUTE     X-Ascend-FR-DCE-N393

The same has happened (repeatedly) with other attributes - pretty much
all attributes from RFC5580 were in the "stolen" space from Ascend.

We've had actual deployment due to that: Operator-Name is a string, but
defined by Ascend as an Integer (for something totally different).

Some RADIUS servers found that an incoming packet with Operator-Name
set, and with a length that was different from 4 characters (i.e. 32 bit
"integer") was malformed and discarded the entire request! Others
truncated the value after 4 Bytes when proxying - an arguable
sanitisation. Others just left it as is - notably FreeRADIUS.

I guess all RADIUS servers can be convinced to operate correctly - a
simple change of dictionary is required (on MS IAS, the "simple" meant
editing an MS Access database with some strange GUI tool though).

We are meanwhile actively testing on this particular oddity and warn
operators when we find them dropping packets on the floor which have
Operator-Name set; and there are instructions for fixing.

Your case is the exact same - so I think you have some reason to be
slightly worried. It is not unsurmountable though.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Thu, 07 Mar 2013 16:54:55 +0100

> We've had actual deployment 

... issues

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Thu, 07 Mar 2013 11:10:19 -0500

Stefan Winter wrote:
> Operator-Name set; 

  Which is absolutely not supported by RFC 2865, or its precursors.

  The RADEXT extensions document has text to address this specific issue.

  Alan DeKok.