Subject: Questions on modified Extended Attribute format?

From: "Glen Zorn" <[email-masked]>
Date: Sun, 9 Dec 2007 10:39:33 -0800

During the meeting last week, I thought that there were a couple of
questions/comments on Jabber regarding the changes that I proposed to the
extended attribute format (adding a bit to distinguish between new TLVs and
legacy RADIUS attributes in extended attributes) but I didn't quite catch
them.  Would those who presented those remarks mind repeating them in email?
TIA.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 26 Dec 2007 18:33:56 +0100

Glen Zorn wrote:
> questions/comments on Jabber regarding the changes that I proposed to
> the extended attribute format (adding a bit to distinguish between new
> TLVs and legacy RADIUS attributes in extended attributes) but I didn't
> quite catch them.  Would those who presented those remarks mind
> repeating them in email?  TIA.

  WiMAX uses the same attribute format as proposed here.  Changes that
are incompatible with WiMAX should be discouraged.

  If it's just stealing a bit (which WiMAX doesn't use), that sounds
fine.  The ability to group legacy RADIUS attributes via a method other
than tags would be good.

  One question: If we DO permit this for legacy RADIUS attributes, what
does the "C" bit mean?  Do we use the WiMAX method for splitting
attributes encrypted with the "Tunnel-Password" method?

  Alan DeKok.

--
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: "Glen Zorn" <[email-masked]>
Date: Wed, 26 Dec 2007 09:52:47 -0800

WiMAX uses the same attribute format as proposed here.  Changes that
are incompatible with WiMAX should be discouraged.
[gwz] 
I'm not at all sure why that would be the case; I don't recall the IETF
bending over backwards to be compatible w/anyone else's VSAs...
[/gwz]

  If it's just stealing a bit (which WiMAX doesn't use), that sounds
fine.  The ability to group legacy RADIUS attributes via a method other
than tags would be good.
[gwz] 
Actually, I've convinced myself that a) this idea was not quite baked & b) I
was wrong about making the Ext-Type field just one octet.  If we make the
Ext-Type field 16 bits in length _and_ start numbering the new attributes at
0x100, that would seem to solve a couple of problems nicely.
[/gwz]

  One question: If we DO permit this for legacy RADIUS attributes, what
does the "C" bit mean?  Do we use the WiMAX method for splitting
attributes encrypted with the "Tunnel-Password" method?
[gwz] 
I don't know what method that is, but I'm not sure why those attributes
would be treated differently than others. 
[/gwz]

  Alan DeKok.

---

From: <[email-masked]>
Date: Wed, 26 Dec 2007 10:01:26 -0800

> are incompatible with WiMAX should be discouraged.

I would agree.   If the extensions remain compatible with WiMAX then
the amount of code duplication will be minimized.

> attributes encrypted with the "Tunnel-Password" method?

We need to be careful about feature creep here.  The original purpose of
the Extended Attributes document was to extend the RADIUS attribute space.

If the document is now taking on new problems (extending capabilities of the
RADIUS protocol or changing the semantics of existing attributes) then that
problem needs to be clearly stated, and justification needs to be provided.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 26 Dec 2007 10:16:28 -0800

[gwz] 
If we're suddenly worried about the size of code for processing VSAs, it
would seem to make much more sense to be compatible with cisco's VSAs since
they are far more widely deployed than WiMax's (and probably always will
be).
[/gwz]

[gwz] 
I'm not suggesting anything of the sort: the capabilities for sending large
attributes & grouping them already exist (although in limited ways); I'm
talking about standardizing these existing capabilies, not adding new ones.
[/gwz]

---

From: Alan DeKok <[email-masked]>
Date: Wed, 26 Dec 2007 20:10:57 +0100

> bending over backwards to be compatible w/anyone else's VSAs...

  The last thing I need right now is yet another incompatible VSA format.

> 0x100, that would seem to solve a couple of problems nicely.

  I understand... I'm not sure I completely agree.

> would be treated differently than others. 

  Neither am I.  But they are.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 26 Dec 2007 20:15:14 +0100

> they are far more widely deployed than WiMax's (and probably always will

  Yes... but strings?  Really?

> talking about standardizing these existing capabilies, not adding new ones.

  If we can get the functionality of the new extended attributes applied
to legacy RADIUS, I'm all for it.  But I don't want it to be a lot of
work... that causes bugs and interoperability issues.

  My preferences are to leave the extended attributes defined the way
they are right now.  Anything else starts to cause issues.

  e.g. legacy attributes encapsulated in a VSA.... what happens with
legacy implementations?  The only image that comes to mind is a cloud
going *boom*.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 26 Dec 2007 12:06:25 -0800

The last thing I need right now is yet another incompatible VSA format.
[gwz] 
I understand, & sympathize; I think that it's important to remember that a
major reason that we ended up in the position of having multiple external
SDOs defining their own mutually incompatible VSAs is that we (the IETF)
refused to address RADIUS' problems in a useful and meaningful way.  We have
an opportunity now to ameliorate if not solve that problem; I don't think
that we should pass it up.
[/gwz]

...

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 26 Dec 2007 12:10:32 -0800

[gwz] 
I know, but the point stands, no?
[/gwz]

[gwz] 
;-)  Not sure why, though -- they would be easily identified & it seems like
the code we're talking about should already exist (that's why we chose these
rather modest techniques in the first place, right?).
[/gwz]

  Alan DeKok.

---

From: "Matt Holdrege" <[email-masked]>
Date: Wed, 26 Dec 2007 12:51:25 -0800

Glen,

Didn't you say this same exact thing here a year or two ago? Or am I
stuck in a time warp? Or is this group stuck in a time warp?

-Matt (I'll go back into my hole now)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Glen Zorn
Sent: Wednesday, December 26, 2007 9:06 PM
To: 'Alan DeKok'
Cc: [email-masked]
Subject: RE: Questions on modified Extended Attribute format?

[gwz] 
I understand, & sympathize; I think that it's important to remember that
a
major reason that we ended up in the position of having multiple
external
SDOs defining their own mutually incompatible VSAs is that we (the IETF)
refused to address RADIUS' problems in a useful and meaningful way.  We
have
an opportunity now to ameliorate if not solve that problem; I don't
think
that we should pass it up.
[/gwz]

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 26 Dec 2007 14:12:11 -0800

Glen,

[gwz] Plus ça change, plus c'est la même chose... [/gwz]

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

[gwz]

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 26 Dec 2007 21:58:54 -0500

Bernard Aboba writes...
 
> the amount of code duplication will be minimized.

I'm not so sure that I agree.  We should do what's right for the RADIUS
community.  If that happens to be compatible with WiMAX, then great.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 27 Dec 2007 05:48:29 +0100

> that we should pass it up.

  If we're going to re-design the attribute format from scratch again,
I'd like to know what we've accomplished in the past year.  There were
proposals that were ugly, but solved almost all of the concerns that
were raised.  This includes the ability to group legacy RADIUS
attributes in a "new" format.

  The one show-stopper I see is putting standard RADIUS attributes into
a VSA.  If this has *zero* impact on implementations that don't
understand the new format, then it would be acceptable.  Otherwise, it's
an incompatible change to RADIUS.

  If we can't put standard attributes into the new format, then we
should just pick a better format, and ideally one that's been deployed.
 The WiMAX format (plus grouping) seems to fit that definition fairly well.

  Alan DeKok.

---

From: "Matt Holdrege" <[email-masked]>
Date: Wed, 26 Dec 2007 21:47:35 -0800

No kidding. I think my first RADIUS WG meeting was almost 12 years ago at IETF 35. Take a look at http://www3.ietf.org/proceedings/96mar/area.and.wg.reports/ops/radius/radius.html and read the minutes.

You might laugh at the irony, or more likely cry. Are the current AD's aware of the history here?

-Matt

-----Original Message-----
From: Glen Zorn [mailto:[email-masked]] 
Sent: Wednesday, December 26, 2007 11:12 PM
To: Matt Holdrege
Cc: [email-masked]; 'Alan DeKok'
Subject: RE: Questions on modified Extended Attribute format?

Glen,

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

[gwz]

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 27 Dec 2007 15:28:26 -0800

have

  If we're going to re-design the attribute format from scratch again,
I'd like to know what we've accomplished in the past year.  

[gwz] I don't know where the "from scratch" comes from; there is a format
defined in
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00
.txt.  I am suggesting adding a single octet to the format which A) would
considerably enlarge the new type space and B) _could_ be used to
standardize functionality that has been added to RADIUS over the years in an
ad hoc fashion.
[/gwz]

There were

[gwz]
Interesting definition of "incompatible".  If that is in fact the standard
to be met we may as well just fold up our tents and go home since there is
_no_ change that could be made which would have "*zero* impact on
implementations that don't understand".
[/gwz]

[gwz]
Can you tell us what it looks like?
[/gwz]

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 28 Dec 2007 09:40:29 +0100

Glen Zorn wrote:
> .txt.  I am suggesting adding a single octet to the format which

  Opens it up for change again, after a long discussion, where everyone
had agreed that the format in -00 was acceptable.

> implementations that don't understand".

  It's not about changes, it's about *compatible* changes to the
*standard* attributes.  Let me re-phrase:

  - standard RADIUS attributes in a VSA MUST be compatible with existing
implementations that only understand standard RADIUS attributes

  Put that way, it's obviously impossible.  Since RADIUS has no
capability negotiation, there's no way for the NAS to tell the server it
is capable of that new functionality.

  Therefore, the proposed change is incompatible with existing deployments.

> Can you tell us what it looks like?

  The format in -00, which achieved WG consensus after long and
protracted discussion.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 28 Dec 2007 08:35:11 -0800

...

[gwz] 
As I said, put that way or any other way you like, ANY change is
incompatible with existing deployments.  If one were to add a new "standard"
attribute (in the old format or the proposed VSA-like format or any other)
it would be incompatible with existing deployments.  The whole idea of
extended attributes REQUIRES that existing deployment be updated, no matter
how they are formatted.
[/gwz]

  The format in -00, which achieved WG consensus after long and
protracted discussion.
[gwz] 
Actually, while the timeframe was long, the discussion wasn't: I've only
received a couple of comments on it in the last months.  It _did_ take an
inordinate amount of time to reject the 'Diameterization' of RADIUS,
though...
[/gwz]

  Alan DeKok.