Subject: RE: RADIUS Calling-Station-Id for WiMAX

From: "Ray Bell" <[email-masked]>
Date: Wed, 10 Sep 2008 08:14:58 -0700

True mobility and roaming...

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Matt Holdrege
Sent: Wednesday, September 10, 2008 1:44 AM
To: Bernard Aboba; Congdon, Paul T (ProCurve); Mike Bean; David Nelson;
[email-masked]; Dan Romascanu
Subject: RE: RADIUS Calling-Station-Id for WiMAX

I don't see any reason why RADIUS should differentiate between 802.16
and 802.11 or any other 802. 

-Matt

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Wednesday, September 10, 2008 12:40 AM
To: Congdon, Paul T (ProCurve); Mike Bean; David Nelson;
[email-masked]; Dan Romascanu
Subject: RADIUS Calling-Station-Id for WiMAX

Some questions have arisen about the format of the Calling-Station-Id
Attribute when used with WiMAX. 

Since WiMAX is based on IEEE 802.16, and RFC 3580 applies to IEEE 802
technology, it would seem that the RFC 3580 Calling-Station-Id
definition would apply to WiMAX.  

Are there reasons why this would not be the case?

---

From: "Matt Holdrege" <[email-masked]>
Date: Wed, 10 Sep 2008 10:20:22 -0700

Um, 802.11 supports true mobility and roaming. Even before 802.11r was
finished plenty of vendors have done pre-standard versions of mobility. 

But what does this have to do with RADIUS? There should be no reason to
have different attributes for .11 and .16, right?

-Matt

From: Ray Bell [mailto:[email-masked]] 
Sent: Wednesday, September 10, 2008 5:15 PM
To: Matt Holdrege; Bernard Aboba; Congdon, Paul T (ProCurve); Mike Bean;
David Nelson; [email-masked]; Dan Romascanu
Subject: RE: RADIUS Calling-Station-Id for WiMAX

-Matt

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 10 Sep 2008 10:42:23 -0700

Ray Bell  <mailto:[mailto://[email-masked]%5d> [mailto://[email-masked]]
writes:

True mobility and roaming.

OK, I give: how does representing a MAC address is binary vs. ASCII enhance
mobility or roaming?

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Matt Holdrege

I don't see any reason why RADIUS should differentiate between 802.16 and
802.11 or any other 802. 

-Matt

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bernard Aboba

Since WiMAX is based on IEEE 802.16, and RFC 3580 applies to IEEE 802
technology, it would seem that the RFC 3580 Calling-Station-Id definition
would apply to WiMAX.

---

From: Avi Lior <[email-masked]>
Date: Wed, 10 Sep 2008 14:39:01 -0400

WoW lots of discussion on this issue.

So it was an oversight.  If someone would have reminded us about 3580 then we would have just adopted that.

Since we didnt.  It seems to me that a binary representation would be a more appropriate treatment for this value.  The human presentation of the MAC address is just that for humans and RADIUS couldnt give care.  Besides, the presentation of the MAC address has more then one format - one using ":" and one using "-".  So it is best to leave the presentation to a presentation layer and not the RADIUS layer.

So 3580 IMO got it wrong.  But as I said if one of you brought that up to our attention we would have fixed it to match 3580.

Which brings me to another point.  It isn't busted.  And changing it now will break backwards compatibility.  And breaking backwards compatibility is being viewed as a very bad thing.

Actually if we want to open this up again, the I propose getting rid of the MAC address or encrypting it since it violates one of the WiMAX and of the IETF tenents which is identity hidding.  We have the means to hide the user's identity but yet the MAC address is exposed.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Zorn
Sent: September 10, 2008 1:42 PM
To: 'Ray Bell'; 'Matt Holdrege'; 'Bernard Aboba'; 'Congdon, Paul T (ProCurve)'; 'Mike Bean'; 'David Nelson'; [email-masked]; 'Dan Romascanu'
Subject: RE: RADIUS Calling-Station-Id for WiMAX

Ray Bell [mailto://[email-masked]]<mailto:[mailto://[email-masked]%5d> writes:

True mobility and roaming...
OK, I give: how does representing a MAC address is binary vs. ASCII enhance mobility or roaming?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt Holdrege
Sent: Wednesday, September 10, 2008 1:44 AM
To: Bernard Aboba; Congdon, Paul T (ProCurve); Mike Bean; David Nelson; [email-masked]; Dan Romascanu
Subject: RE: RADIUS Calling-Station-Id for WiMAX

I don't see any reason why RADIUS should differentiate between 802.16 and 802.11 or any other 802.

-Matt

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Wednesday, September 10, 2008 12:40 AM
To: Congdon, Paul T (ProCurve); Mike Bean; David Nelson; [email-masked]; Dan Romascanu
Subject: RADIUS Calling-Station-Id for WiMAX

Some questions have arisen about the format of the Calling-Station-Id Attribute when used with WiMAX.

Since WiMAX is based on IEEE 802.16, and RFC 3580 applies to IEEE 802 technology, it would seem that the RFC 3580 Calling-Station-Id definition would apply to WiMAX.

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 10 Sep 2008 15:24:58 -0400

Avi Lior writes...

> It seems to me that a binary representation would be a more 
> appropriate treatment for this value.

Perhaps, but RFC 3580 followed many years of tradition in choosing the
dashed-ASCII representation.

> So it is best to leave the presentation to a presentation layer 
> and not the RADIUS layer.

Well, no.  The syntax and semantics of RADIUS attribute are a matter of the
RADIUS protocol.  There is no presentation layer, and contrary to commonly
held belief, RADIUS is not simply a transport protocol.  :-)

> It isn't busted.

Not within the "walled garden" of WiMAX.  On a global interoperability
scale, I claim that it is broken. 

> And changing it now will break backwards compatibility.

Yes.  The question is whether to "cowboy up" and fix it now.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Mike Bean <[email-masked]>
Date: Thu, 11 Sep 2008 07:55:03 -0700

All,

I think backwards compatibility is poor excuse to preserve 6 octet 
Calling-Station-Id given Alcatel-Lucent and, according to ASN-GW 
documentation, Cisco use RFC 3580 Calling-Station-Id format with WiMAX.  
I have a trace that shows Huawei ASN-GW sends Calling-Station-Id as 12 
hex characters lowercase, not binary.  Not sure what other vendors send 
but at least there is some confusion among some vendors.  I think a 
survey of additional WiMAX ASN-GW vendors would show whether there is an 
actual backwards compatibility issue.

BR,

Mike

Michael Bean (Mike)
Alcatel-Lucent
AAA Product Group
3461 Robin Ln, Ste 1
Cameron Park, CA 95682
Email: [email-masked]
Phone: 530 672 7577
Fax: 530 676 3442

---

From: "Matt Holdrege" <[email-masked]>
Date: Thu, 11 Sep 2008 08:30:29 -0700

If your RADIUS server only needs to work with those devices, then you
are fine. However Alcatel-Lucent (as one example) has thousands upon
thousands of other installed NAS ports that use octets. If network
operators want a RADIUS server that serves both these NAS ports as well
as WiMax devices, you had better be thinking about backwards
compatibility.

-Matt

-----Original Message-----
From: Mike Bean [mailto:[email-masked]] 
Sent: Thursday, September 11, 2008 4:55 PM
To: David B. Nelson
Cc: 'Avi Lior'; 'Glen Zorn'; 'Ray Bell'; Matt Holdrege; 'Bernard Aboba';
'Congdon, Paul T (ProCurve)'; [email-masked]; 'Dan Romascanu'
Subject: Re: RADIUS Calling-Station-Id for WiMAX

All,

BR,

Mike

Michael Bean (Mike)
Alcatel-Lucent
AAA Product Group
3461 Robin Ln, Ste 1
Cameron Park, CA 95682

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Sep 2008 18:25:46 +0200

> as WiMax devices, you had better be thinking about backwards

  In the interim, your AAA server could see the 6-octet format, and
auto-convert it to the RFC 3580 format for standards compliance.

  This is the path taken by at least one server I know of. :)

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Thu, 11 Sep 2008 13:10:10 -0400

BTW, I think RFC 3580 has an issue that needs to be fixed.

Apparently there isn't single standard MAC address format for presenting a MAC address in a human readable fashion.  Forgeting the use of "-" and ":" there is - Bit reversed and none bit reversed methods.  RFC 3580 needs to state which one is being encoded. Right?  See RFC 2469 for a discussion.

The MAC over-the-wire is different for different technogologies.  802.3 and 802.4 send the bits with the least siginificant bit first, while 802.5 and 802.6 send the most significant bit first.

RADIUS would have to do some mapping based on access technology anyway. Right?

And how is the MAC presented to the crypto-layer when it is part of some crypto-binding.  Is that specified correctly.

Another point worth meantioning is that there is no STANDARD definition in IETF for a MAC representation in a Calling-Station-ID.  So when Alan is stating "to the RFC 3580 format for standards compliance" he is a little bit wrong.  First there is no SHALL or MUST or a SHOULD anywhere near the worlds MAC address and Calling-Station-ID.  And RFC 3580 is INFORMATIONAL.

So please lets call it what it is, a RECOMMENDATION, a common practice which is, judging by the emails being exchanged not exacly as common as we would think.

> From: Alan DeKok [mailto:[email-masked]]
> Sent: September 11, 2008 12:26 PM
> To: Matt Holdrege
> Cc: Mike Bean; David B. Nelson; Avi Lior; Glen Zorn; Ray
> Bell; Bernard Aboba; Congdon, Paul T (ProCurve);
> > operators want a RADIUS server that serves both these NAS ports as
> > well as WiMax devices, you had better be thinking about backwards
> > compatibility.
>
>   In the interim, your AAA server could see the 6-octet
> format, and auto-convert it to the RFC 3580 format for
> standards compliance.
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 11 Sep 2008 10:13:13 -0700

Existing RADIUS servers typically expect the Calling-Station-Id Attribute in
ASCII format, and apparently some ASN-GWs are also sending it this way.
This seems counter to the argument that RFC 3580 somehow breaks "backward
compatibility".  Backward compatibility with what, exactly? 

-----Original Message-----
From: Mike Bean [mailto:[email-masked]] 
Sent: Thursday, September 11, 2008 7:55 AM
To: David B. Nelson
Cc: 'Avi Lior'; 'Glen Zorn'; 'Ray Bell'; 'Matt Holdrege'; 'Bernard Aboba';

All,

BR,

Mike

Michael Bean (Mike)
Alcatel-Lucent
AAA Product Group
3461 Robin Ln, Ste 1
Cameron Park, CA 95682

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 11 Sep 2008 13:23:12 -0400

> The MAC over-the-wire is different for different technogologies.
> 802.3 and 802.4 send the bits with the least siginificant bit
> first, while 802.5 and 802.6 send the most significant bit first.

Isn't this just the "host order" vs. "network order" issue?  In my
experience, application layer protocols such as RADIUS always deal with data
in host order.

---

From: Avi Lior <[email-masked]>
Date: Thu, 11 Sep 2008 13:29:59 -0400

See inline....

> From: David B. Nelson [mailto:[email-masked]]
> Sent: September 10, 2008 3:25 PM
> To: Avi Lior; 'Glen Zorn'; 'Ray Bell'; 'Matt Holdrege';
> 'Bernard Aboba'; 'Congdon, Paul T (ProCurve)'; 'Mike Bean';
> [email-masked]; 'Dan Romascanu'
> Perhaps, but RFC 3580 followed many years of tradition in
> choosing the dashed-ASCII representation.

And 3580 also inherited the MAC tradition that even in 802-land the MAC address is not standerdized (As per another one of my emails -- I want to hear what Paul has to say)

>
> > So it is best to leave the presentation to a presentation layer and
> > not the RADIUS layer.
>
> Well, no.  The syntax and semantics of RADIUS attribute are a
> matter of the RADIUS protocol.  There is no presentation
> layer, and contrary to commonly held belief, RADIUS is not
> simply a transport protocol.  :-)

Exactly so why are we worried about how the attribute is formatted.  Specifically for humans.  The dash-notation or colon-notation is used by humans or text based protocols.  If RADIUS wanted to stay out of the presentation layer business it should have kept the MAC codification as it appears over the wire at the NAS. Conversion to other formats should be done as late as possible.

>
> > It isn't busted.
>
> Not within the "walled garden" of WiMAX.  On a global
> interoperability scale, I claim that it is broken.

By busted I mean that it isn't breaking even the holy grounds of the IETF.  No IETF AAA standard requires MAC address to be codified the way you state.  The standards says that

"The actual format of the information is site or application specific."

But I do agree that aligning with the RECOMMENDATION of 3580 would have been a good start.

> Yes.  The question is whether to "cowboy up" and fix it now.

Right.  And that is a political discussion that is best to have in WiMAX and NOT here.  I have no idea why it was brought to RADEXT since it hasn't even been discussed at WiMAX and there is no technical opposition to fixing the problem in WiMAX as far as I can tell.

---

From: Avi Lior <[email-masked]>
Date: Thu, 11 Sep 2008 13:39:01 -0400

Not as far as my understanding goes.  In 802.5 and 802.6 the MAC address is bit reversed over the wire.

> In my experience, application layer protocols such as RADIUS
> always deal with data in host order.
I think you maybe wrong about that.  It should be network order because host order is not deterministic.

> From: David B. Nelson [mailto:[email-masked]]
> Sent: September 11, 2008 1:23 PM
> To: Avi Lior; 'Alan DeKok'; 'Matt Holdrege'
> Cc: 'Mike Bean'; 'David B. Nelson'; 'Glen Zorn'; 'Ray Bell';
> 'Bernard Aboba'; 'Congdon, Paul T (ProCurve)';
> > 802.3 and 802.4 send the bits with the least siginificant
> bit first,
> > while 802.5 and 802.6 send the most significant bit first.
>
> Isn't this just the "host order" vs. "network order" issue?
>
>
>

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 11 Sep 2008 13:44:21 -0400

> Exactly so why are we worried about how the attribute is formatted.
> Specifically for humans.  The dash-notation or colon-notation is used by
> humans or text based protocols.  If RADIUS wanted to stay out of the
> presentation layer business it should have kept the MAC codification as it
> appears over the wire at the NAS. Conversion to other formats should be
> done as late as possible.

Uhhh...  I think you're missing a key point here.   There is no presentation
layer -- the "presentation" is hard-coded into the attribute definitions.
If the attribute content is intended only for human consumption, as are most
RADIUS Accounting attributes, then it truly doesn't matter.  OTOH, if the
RADIUS server is going to make some access control policy decision, or in
general customize the session to be delivered, based on the content of an
attribute, then that attribute had better have a standardized format, if we
are to have any expectation of multi-vendor, global interoperability.

---

From: Avi Lior <[email-masked]>
Date: Thu, 11 Sep 2008 13:53:19 -0400

See inline....

> Sent: September 11, 2008 10:55 AM
> To: David B. Nelson
> Cc: Avi Lior; 'Glen Zorn'; 'Ray Bell'; 'Matt Holdrege';
> I think backwards compatibility is poor excuse to preserve 6
> octet Calling-Station-Id given Alcatel-Lucent and, according
> to ASN-GW documentation, Cisco use RFC 3580
> Calling-Station-Id format with WiMAX.

I think the poor excuse here is that you want WiMAX folks to change because you didn't read and follow the specification.  For you its not a backwards compatibility issue because you didn't follow the specification and if you followed the specification you would have been screaming it's a backwards compatibility issue.  You could have changed it to the 3580 way for more then a year now.

> I have a trace that shows Huawei ASN-GW sends
> Calling-Station-Id as 12 hex characters lowercase, not
> binary.

3580 says upper-case. So they don't follow *ANY* recommodation or standard either. Why are we writing these standards or recommendation if people don't read and follow them.

> Not sure what other vendors send but at least there
> is some confusion among some vendors.

Vendors that don't read the or any specifications for that matter.

> I think a survey of
> additional WiMAX ASN-GW vendors would show whether there is
> an actual backwards compatibility issue.

But as you state here there is no standards way we can agree to follow. In your case you want 3580 with upper case, and Huawei wants 3580 with lower case; WiMAX tossed the case issue with the HEX encoding issue; not to mention the dash vs. colon issue and stuck with the lowest common denominator which is binary.

Avi.

> > Well, no.  The syntax and semantics of RADIUS attribute are
> a matter
> > of the RADIUS protocol.  There is no presentation layer,
> and contrary
> > to commonly held belief, RADIUS is not simply a transport
> protocol.
> > :-)
> >
> >
> >> It isn't busted.
> >>
> >

---

From: Avi Lior <[email-masked]>
Date: Thu, 11 Sep 2008 14:00:50 -0400

See inline....

> Sent: September 11, 2008 1:44 PM
> To: Avi Lior; 'David B. Nelson'; 'Glen Zorn'; 'Ray Bell';
> 'Matt Holdrege'; 'Bernard Aboba'; 'Congdon, Paul T
> (ProCurve)'; 'Mike Bean'; [email-masked]; 'Dan Romascanu'
> > Specifically for humans.  The dash-notation or
> colon-notation is used
> > by humans or text based protocols.  If RADIUS wanted to stay out of
> > the presentation layer business it should have kept the MAC
> > codification as it appears over the wire at the NAS. Conversion to
> > other formats should be done as late as possible.
>

Fine. Call it a hard-coded into the attribute.

> If the attribute content is intended only for human
> consumption, as are most RADIUS Accounting attributes, then
> it truly doesn't matter.

I don't know of any humans that consume accounting records. Do you? ;-)

> OTOH, if the RADIUS server is going
> to make some access control policy decision, or in general
> customize the session to be delivered, based on the content
> of an attribute, then that attribute had better have a
> standardized format, if we are to have any expectation of
> multi-vendor, global interoperability.

Right. Exactly. And since a MAC address can be presented in many different ways then it is best to convert the MAC address to the format as late as possible.  So if the MAC address is stored in a database using a colon notation - which is a common form.  Then we should convert it to that format as late as possible.

Today we have to format the value from a binary form at the NAS to some hex form and perhaps to some other form when it is used by the RADIUS server.

And there are issues all along with text forms.  Is the seperator a dash or a colon. Are the hex digits in upper or lower case.

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.

---

From: "Matt Holdrege" <[email-masked]>
Date: Thu, 11 Sep 2008 11:32:22 -0700

-----Original Message-----

> operators want a RADIUS server that serves both these NAS ports as
well
> as WiMax devices, you had better be thinking about backwards

|  In the interim, your AAA server could see the 6-octet format, and
|auto-convert it to the RFC 3580 format for standards compliance.

Hah! Never let engineering get in the way of standards development.

-Matt

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 11 Sep 2008 16:15:48 -0400

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

Well, "late binding" may be a good software design paradigm, but RADIUS only
specifies what goes into the PDUs on-the-wire.  Any other formats and
encodings used internally to the software and/or databases are a matter of
implementation, not a matter of standardization.

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.

All the rest is positioning in defense of one fielded implementation or the
other.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 12 Sep 2008 08:25:11 +0200

Hi,

> All the rest is positioning in defense of one fielded implementation or the

Being in the lucky position of not having to defend any particular 
implementation, my two currency-neutral cents.

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

 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?

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.

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.

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: "Matt Holdrege" <[email-masked]>
Date: Fri, 12 Sep 2008 01:43:53 -0700

Interesting timing that this RFC and BCP should just come out now...

http://www.rfc-editor.org/rfc/rfc5342.txt

---

From: Avi Lior <[email-masked]>
Date: Fri, 12 Sep 2008 12:00:17 -0400

Hi

> From: Stefan Winter [mailto:[email-masked]]
> Sent: September 12, 2008 2:25 AM
> To: David B. Nelson
> Cc: Avi Lior; 'David B. Nelson'; 'Glen Zorn'; 'Ray Bell';
> > 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.
>
> > 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
>

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)".
> 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
>
>