RE: RADIUS Calling-Station-Id for WiMAX

[Avi Lior <avi@bridgewatersystems.com>]

Hi

> -----Original Message-----
> From: Stefan Winter [mailto:stefan.winter@restena.lu]
> Sent: September 12, 2008 2:25 AM
> To: David B. Nelson
> Cc: Avi Lior; 'David B. Nelson'; 'Glen Zorn'; 'Ray Bell';
> 'Matt Holdrege'; 'Bernard Aboba'; 'Congdon, Paul T
> (ProCurve)'; 'Mike Bean'; radiusext@ops.ietf.org; 'Dan Romascanu'
> Subject: Re: RADIUS Calling-Station-Id for WiMAX
>
> Hi,
>
> > All the rest is positioning in defense of one fielded
> implementation
> > or the other.
>
>
> Being in the lucky position of not having to defend any
> particular implementation, my two currency-neutral cents.
>
> > The issue at hand is whether RFC 3580 created a "standard" for the
> > on-the-wire encoding format of the Calling-Station-Id
> Attribute, and
> > whether or not it matters that WiMAX adopted a different
> on-the-wire encoding.
>
>
> Reading RFC3280:
>
> 3.21.  Calling-Station-Id
>
>    For IEEE 802.1X Authenticators, this attribute is used to store the
>    Supplicant MAC address in ASCII format (upper case only),
> with octet
>    values separated by a "-".  Example: "00-10-A4-23-19-C0".
>
> This sounds pretty definitive to me. I agree with Avi that there is no
> RFC2119 wording here, but nevertheless the wording is quite strong.

It becomes dangerous when we start equating non-normative text to normative text.
In the context of standards when we say "X is 5"  we are also saying that it could be something else.  But when we say "X SHALL BE 5" we are saying that X cannot take anyother value.  There is a huge difference right?

3580 is a recommendation.  It is one way to do things.  But I am not arguing against it at all.

>  From what I've read over various RADIUS mailing lists over
> the last couple of years, the wording above didn't get the
> attention it should, where I also agree with Avi. Yes,
> there's - notation, : notation, capitals, no capitals, and
> now there's obviously also a binary encoding.
> People exchange funny regular expressions to convert from one
> format to another in various server products when MAC
> authentication is in use already now. Not anywhere near a
> homogenous situation.
>
> That's why I have to disagree with Avi's point: "That is why
> I stated that it is best to keep the format in RADIUS in its
> lowest common form
> (binary) and do the conversion to a particular format at the
> last moment. It is less error prone - as you can see by all
> of these exchanges." - Why would the binary form be a "common
> form" across the RADIUS landscape? Or on the wire/less, given
> that you argued yourself that some 802 flavours use different
> formats than others?

You are misreading or I am not being clear enough about my statement.
What I mean by the "lowest common form" is that all of the encoding that people use for MAC address are ultimately derived from the binary value - the lowest common form.

Thus having the NAS convert the binary format to some TEXT representation is a waste of time since the Application at the RADIUS server would have to transform the TEXT representation again so that it can be used for whatever purpose.

So the approach I would have taken is to have RADIUS transport the MAC address in binary as it was received over the wire without the any transformation.  The receiver (RADIUS Server) would  transform the MAC address to the form it needs.  If bit-ordering is important it can use the NAS-Port-Type to determine which 802 technology is being used and thus determine the bit ordering.

But this is water under the bridge.  I am not proposing we change anything in 3580 with respect to binary or text coding.

>
> I also have to disagree with another argument: that RFC3580
> is only informational. Well technically it is, but that
> doesn't mean its content is void and can be disregarded. That
> would be a very dangerous path to follow. Take for example
> RFC3579: "RADIUS (Remote Authentication Dial In User Service)
> Support For Extensible Authentication Protocol (EAP)".
> This is informational "only" as well, but nevertheless a)
> important and
> b) implemented halfways thoroughly. If one were to dismiss
> informational status RFCs, we couldn't "legally" do EAP
> authentication at all.

I never said it should be ignored or disregarded.  I just said don't call it "a violation of a Standard".  3580 is not a standard for a reason.  And to raise its contents to "standard-dome" is not appropriate.

>
> Having said all that, there obviously is confusion about what
> to put into the attribute, and the attribute may need to be
> consumed by a AAA server to make authorisation decisions - so
> a normative, fixed-format answer would be a very good thing
> to have. Whichever is chosen, I don't really care. But it
> should be only *one* format.

I have no problem following 3580's recommendation.  It is after all all we have today.  I still thing that 3580's definition of a MAC address format is missing some information and I will raise an Errata.

With respect to WiMAX, the issue is not a technical issue but rather one of backwards compatibility.  Do we break backwards compatibility or not.  If WiMAX folks would have brought this encoding issue to the our attention we would have fixed the problem.

> 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
>
>

--
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/>