Subject: RE: RADIUS Design Guidelines [SEQUENCE]
From: "Murtaza S. Chiba" <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Date: Thu, 31 Aug 2006 07:48:48 -0700

One way to group attributes, instead of embedding them, is to use
explicit attributes that mark the beginning and end of the group.
Ofcourse, it requires that the intermediate servers dont modify the
sequence of attributes, but I have yet to come across a server that
actually does that apart from removing attributes.

On Tue, 2006-08-29 at 12:28 -0400, Avi Lior wrote:
> One more requirement:
> 
> SEQUENCE or (fixed encoding as I call it) does not support the notion
> where an element may repeat.
> 
>  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Nelson, David
> > Sent: Tuesday, August 29, 2006 11:51 AM
> > To: [email-masked]
> > Subject: RE: RADIUS Design Guidelines [SEQUENCE]
> > 
> > Avi Lior writes...
> > 
> > >Had to start a new thread.
> > 
> > Thanks for getting back to the subject that I'd originally 
> > wanted to discuss.
> > 
> > > Sequence as you propose does not work.
> > > 
> > > It only works when all members of a sequence are required 
> > except the 
> > > last one which can be optional --
> > 
> > Well, I think that packet formats that have [dynamically] 
> > optional data parts are more complicated, and definitely 
> > outside the RADIUS design paradigm of the TLV.  One type, one 
> > length, one value.
> > 
> > > .. or that if an element in the sequence is not required 
> > its value is 
> > > still sent (as a zero)
> > 
> > Assuming we were to accept that certain fields in a complex 
> > data type are optional, that would probably be the way to go.
> >  
> > > As well the sequence does not work for variable length fields.
> > 
> > I'd indicated the caveats around that in my initial post.
> > 
> > > A sequence of TLVs will work.  Since the Type field allows us to 
> > > identify the attribute resolving the first problem.
> > 
> > What comes around, goes around.  Three years later, it looks 
> > as if you are one again suggesting "sub-types", i.e. 
> > sequences of TLVs, potentially nested in other TLVs.
> > 
> > > If we are going to do this lets do it right!
> > 
> > Well, I'm sure that there are multiple definitions of "right".
> > 
> > The WG consensus on this issue, to date, is that we do not 
> > want to redefine the RADIUS data model, even though we 
> > acknowledge that it is very informal and rather limited.  
> > Rather than change the current practices in on-the-wire 
> > encodings in any substantial way, I was looking for a method 
> > of designing attributes and documenting current practices in 
> > a way that leads itself to a more formal and regular (read 
> > modular) construction.  I believe this will enhance the 
> > ability for data dictionary driven implementations to embrace 
> > the extended attributes.
> > 
> > The current RADIUS data model is TLV, for single-valued, 
> > atomic data elements.  We are currently discussing how to 
> > embrace structured forms of data elements (V). Over the 
> > years, the practice has developed of declaring the V as a 
> > String type (or worse yet, failing to declare its type at 
> > all), and defining the sub-elements of the string as "packed 
> > fields" using the textual descriptions.
> > 
> > This makes it hard(er) to implement using a data dictionary.  
> > I say this because there is no standard set of data types 
> > that can be referenced.
> > If the String data type is seen to be composed of a SEQUENCE OF other
> > (base) data types, it is much easier.
> > 
> > You make the point that string fields need a length.  
> > Absolutely.  I think it is not an unreasonable assumption to 
> > make that the RADIUS String and Text data types *do* include 
> > a length, the L in the TLV.
> > Sicne RADIUS only describes single-valued TLVs, there was no 
> > reason to associate the L with the string V.  One L was 
> > always sufficient.  It is logical, I think, to assume that if 
> > a TLV contains a SEQUENCE of string Vs, that the string Vs 
> > will each have associated Ls.
> > 
> > OTOH, as you suggest, it is not a large step to further 
> > extend this to allowing nested TLVs.  I don't think that 
> > nested TLVs are needed simply to express multi-part data 
> > values.  That would only be necessary for variable-content 
> > structures.  I think that it is only necessary for us to be 
> > able to work with fixed-content structures.  That will 
> > certainly solve the 85% problem.
> > 
> > 
> > --
> > 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/>
> > 
> 
> --
> 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/>

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

Delivery-date: Tue, 29 Aug 2006 16:28:09 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS Design Guidelines [SEQUENCE]
Date: Tue, 29 Aug 2006 12:28:15 -0400
From: "Avi Lior" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

One more requirement:

SEQUENCE or (fixed encoding as I call it) does not support the notion
where an element may repeat.

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Tuesday, August 29, 2006 11:51 AM
> To: [email-masked]
> Subject: RE: RADIUS Design Guidelines [SEQUENCE]
>=20
> Avi Lior writes...
>=20
> >Had to start a new thread.
>=20
> Thanks for getting back to the subject that I'd originally=20
> wanted to discuss.
>=20
> > Sequence as you propose does not work.
> >=20
> > It only works when all members of a sequence are required=20
> except the=20
> > last one which can be optional --
>=20
> Well, I think that packet formats that have [dynamically]=20
> optional data parts are more complicated, and definitely=20
> outside the RADIUS design paradigm of the TLV.  One type, one=20
> length, one value.
>=20
> > .. or that if an element in the sequence is not required=20
> its value is=20
> > still sent (as a zero)
>=20
> Assuming we were to accept that certain fields in a complex=20
> data type are optional, that would probably be the way to go.
> =20
> > As well the sequence does not work for variable length fields.
>=20
> I'd indicated the caveats around that in my initial post.
>=20
> > A sequence of TLVs will work.  Since the Type field allows us to=20
> > identify the attribute resolving the first problem.
>=20
> What comes around, goes around.  Three years later, it looks=20
> as if you are one again suggesting "sub-types", i.e.=20
> sequences of TLVs, potentially nested in other TLVs.
>=20
> > If we are going to do this lets do it right!
>=20
> Well, I'm sure that there are multiple definitions of "right".
>=20
> The WG consensus on this issue, to date, is that we do not=20
> want to redefine the RADIUS data model, even though we=20
> acknowledge that it is very informal and rather limited. =20
> Rather than change the current practices in on-the-wire=20
> encodings in any substantial way, I was looking for a method=20
> of designing attributes and documenting current practices in=20
> a way that leads itself to a more formal and regular (read=20
> modular) construction.  I believe this will enhance the=20
> ability for data dictionary driven implementations to embrace=20
> the extended attributes.
>=20
> The current RADIUS data model is TLV, for single-valued,=20
> atomic data elements.  We are currently discussing how to=20
> embrace structured forms of data elements (V). Over the=20
> years, the practice has developed of declaring the V as a=20
> String type (or worse yet, failing to declare its type at=20
> all), and defining the sub-elements of the string as "packed=20
> fields" using the textual descriptions.
>=20
> This makes it hard(er) to implement using a data dictionary. =20
> I say this because there is no standard set of data types=20
> that can be referenced.
> If the String data type is seen to be composed of a SEQUENCE OF other
> (base) data types, it is much easier.
>=20
> You make the point that string fields need a length. =20
> Absolutely.  I think it is not an unreasonable assumption to=20
> make that the RADIUS String and Text data types *do* include=20
> a length, the L in the TLV.
> Sicne RADIUS only describes single-valued TLVs, there was no=20
> reason to associate the L with the string V.  One L was=20
> always sufficient.  It is logical, I think, to assume that if=20
> a TLV contains a SEQUENCE of string Vs, that the string Vs=20
> will each have associated Ls.
>=20
> OTOH, as you suggest, it is not a large step to further=20
> extend this to allowing nested TLVs.  I don't think that=20
> nested TLVs are needed simply to express multi-part data=20
> values.  That would only be necessary for variable-content=20
> structures.  I think that it is only necessary for us to be=20
> able to work with fixed-content structures.  That will=20
> certainly solve the 85% problem.
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 29 Aug 2006 16:17:25 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS Design Guidelines [SEQUENCE]
Date: Tue, 29 Aug 2006 12:16:37 -0400
From: "Avi Lior" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Dave,

See inline....=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Tuesday, August 29, 2006 11:51 AM
> To: [email-masked]
> Subject: RE: RADIUS Design Guidelines [SEQUENCE]
>=20
> Avi Lior writes...
>=20
> >Had to start a new thread.
>=20
> Thanks for getting back to the subject that I'd originally=20
> wanted to discuss.
>=20
> > Sequence as you propose does not work.
> >=20
> > It only works when all members of a sequence are required=20
> except the=20
> > last one which can be optional --
>=20
> Well, I think that packet formats that have [dynamically]=20
> optional data parts are more complicated, and definitely=20
> outside the RADIUS design paradigm of the TLV.  One type, one=20
> length, one value.
>=20
> > .. or that if an element in the sequence is not required=20
> its value is=20
> > still sent (as a zero)
>=20
> Assuming we were to accept that certain fields in a complex=20
> data type are optional, that would probably be the way to go.
> =20
> > As well the sequence does not work for variable length fields.
>=20
> I'd indicated the caveats around that in my initial post.
>=20
> > A sequence of TLVs will work.  Since the Type field allows us to=20
> > identify the attribute resolving the first problem.
>=20
> What comes around, goes around.  Three years later, it looks=20
> as if you are one again suggesting "sub-types", i.e.=20
> sequences of TLVs, potentially nested in other TLVs.

At least I am consistant.  But I am not consitant for the sake of being
consistant.
As well I am not saying this because I am being argumentative or rigid
etc...
I keep asserting the same requirements because that is what is needed.

> > If we are going to do this lets do it right!
>=20
> Well, I'm sure that there are multiple definitions of "right".
>=20
> The WG consensus on this issue, to date, is that we do not=20
> want to redefine the RADIUS data model, even though we=20
> acknowledge that it is very informal and rather limited. =20
> Rather than change the current practices in on-the-wire=20
> encodings in any substantial way, I was looking for a method=20
> of designing attributes and documenting current practices in=20
> a way that leads itself to a more formal and regular (read=20
> modular) construction.  I believe this will enhance the=20
> ability for data dictionary driven implementations to embrace=20
> the extended attributes.
>=20
> The current RADIUS data model is TLV, for single-valued,=20
> atomic data elements.  We are currently discussing how to=20
> embrace structured forms of data elements (V). Over the=20
> years, the practice has developed of declaring the V as a=20
> String type (or worse yet, failing to declare its type at=20
> all), and defining the sub-elements of the string as "packed=20
> fields" using the textual descriptions.
>=20
> This makes it hard(er) to implement using a data dictionary. =20
> I say this because there is no standard set of data types=20
> that can be referenced.
> If the String data type is seen to be composed of a SEQUENCE OF other
> (base) data types, it is much easier.
>=20
> You make the point that string fields need a length. =20
> Absolutely.  I think it is not an unreasonable assumption to=20
> make that the RADIUS String and Text data types *do* include=20
> a length, the L in the TLV.
> Sicne RADIUS only describes single-valued TLVs, there was no=20
> reason to associate the L with the string V.  One L was=20
> always sufficient.  It is logical, I think, to assume that if=20
> a TLV contains a SEQUENCE of string Vs, that the string Vs=20
> will each have associated Ls.
>=20
> OTOH, as you suggest, it is not a large step to further=20
> extend this to allowing nested TLVs.  I don't think that=20
> nested TLVs are needed simply to express multi-part data=20
> values.  That would only be necessary for variable-content=20
> structures.  I think that it is only necessary for us to be=20
> able to work with fixed-content structures.  That will=20
> certainly solve the 85% problem.

So you are going to augment the parsing rules for dictionaries and you
don't want to solve the problem completely?

Anyway what you are promposed is what I called fixed field encoding in
the past.  It has its merits but that still does not solve my issues --
which are real issues.  I need the 'L' and I need the 'T' or something
equivalent to that.

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

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

Delivery-date: Tue, 29 Aug 2006 15:51:05 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS Design Guidelines [SEQUENCE] 
Date: Tue, 29 Aug 2006 11:50:52 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

>Had to start a new thread.

Thanks for getting back to the subject that I'd originally wanted to
discuss.

> Sequence as you propose does not work.
>=20
> It only works when all members of a sequence are required=20
> except the last one which can be optional --=20

Well, I think that packet formats that have [dynamically] optional data
parts are more complicated, and definitely outside the RADIUS design
paradigm of the TLV.  One type, one length, one value.

> .. or that if an element in the sequence is not required
> its value is still sent (as a zero)

Assuming we were to accept that certain fields in a complex data type
are optional, that would probably be the way to go.
=20
> As well the sequence does not work for variable length fields.

I'd indicated the caveats around that in my initial post.

> A sequence of TLVs will work.  Since the Type field allows us to
> identify the attribute resolving the first problem.

What comes around, goes around.  Three years later, it looks as if you
are one again suggesting "sub-types", i.e. sequences of TLVs,
potentially nested in other TLVs.

> If we are going to do this lets do it right!

Well, I'm sure that there are multiple definitions of "right".

The WG consensus on this issue, to date, is that we do not want to
redefine the RADIUS data model, even though we acknowledge that it is
very informal and rather limited.  Rather than change the current
practices in on-the-wire encodings in any substantial way, I was looking
for a method of designing attributes and documenting current practices
in a way that leads itself to a more formal and regular (read modular)
construction.  I believe this will enhance the ability for data
dictionary driven implementations to embrace the extended attributes.

The current RADIUS data model is TLV, for single-valued, atomic data
elements.  We are currently discussing how to embrace structured forms
of data elements (V). Over the years, the practice has developed of
declaring the V as a String type (or worse yet, failing to declare its
type at all), and defining the sub-elements of the string as "packed
fields" using the textual descriptions.

This makes it hard(er) to implement using a data dictionary.  I say this
because there is no standard set of data types that can be referenced.
If the String data type is seen to be composed of a SEQUENCE OF other
(base) data types, it is much easier.

You make the point that string fields need a length.  Absolutely.  I
think it is not an unreasonable assumption to make that the RADIUS
String and Text data types *do* include a length, the L in the TLV.
Sicne RADIUS only describes single-valued TLVs, there was no reason to
associate the L with the string V.  One L was always sufficient.  It is
logical, I think, to assume that if a TLV contains a SEQUENCE of string
Vs, that the string Vs will each have associated Ls.

OTOH, as you suggest, it is not a large step to further extend this to
allowing nested TLVs.  I don't think that nested TLVs are needed simply
to express multi-part data values.  That would only be necessary for
variable-content structures.  I think that it is only necessary for us
to be able to work with fixed-content structures.  That will certainly
solve the 85% problem.

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

Delivery-date: Tue, 29 Aug 2006 15:09:14 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS Design Guidelines [SEQUENCE] 
Date: Tue, 29 Aug 2006 11:09:02 -0400
From: "Avi Lior" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

 Had to start a new thread.

Sequence as you propose does not work.

It only works when all members of a sequence are required expcept the
last one which can be optional -- or
That if an element in the sequence is not required its value is still
sent (as a zero)

As well the sequence does not work for variable length fields.

A sequence of TLVs will work.  Since the Type field allows us to
identify the attribute resolving the first problem.

And Length allows us to handle variable length attributes.

If we are going to do this lets do it right!

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Monday, August 28, 2006 11:54 AM
> To: [email-masked]
> Subject: RADIUS Design Guidelines
>=20
> I've been giving some thought to the current RADIUS Design=20
> Guidelines draft, and the group consensus regarding that=20
> document and the Extended Attribute, coming out of IETF-66.
>=20
> The currently evolving proposals for Extended Attributes,=20
> solve some of the issues that have been identified in the=20
> Design Guidelines draft:
> shortage of attribute IDs, grouping of attributes, and an=20
> explicit method of fragmentation and reassembly.
>=20
> The one remaining issue raised in the RADIUS Design=20
> Guidelines draft not addressed is the issue of multi-part=20
> data values.  Most of the RADIUS work to date has simply=20
> addressed this by defining an attribute, of base-type String,=20
> and then defining sub-fields within the string.
>=20
> There is nothing inherently wrong with this approach, except=20
> perhaps that it makes it more difficult to maintain data=20
> dictionary driven implementations.
>=20
> I have a suggestion to float, in term of the BCP for attribute design.
> I'd like to suggest that any value portion of a RADIUS TLV=20
> that has multiple parts be formally defined in the document=20
> as a SEQUENCE of pre-defined RADIUS base-types.  I'm stealing=20
> the SMI syntax for SEQUENCE, as used in creating conceptual=20
> tables for MIB modules.  It would be relatively easy for data=20
> dictionary driven implementations to automatically understand=20
> a sequence of pre-defined base types.
>=20
> Let me provide a contrived example.  Suppose we want to=20
> define a new attribute whose value is a complex number.  For=20
> those who may have forgotten, a complex number consists of a=20
> real part and an imaginary part.  This is most often=20
> represented as: n + m*i, where n and m are real numbers and i=20
> is the square root of -1.  Such a hypothetical attribute=20
> light look like:
>=20
> <example>
>=20
> Complex-Number
>=20
>    Description
>=20
>    A complex number, consisting to two parts, a real part N and an=20
>    imaginary part M, such that the value is N + M*i, where i is the
>    square root of -1.
>=20
>    A summary of the Complex Number Attribute format is shown below.
>    The fields are transmitted from left to right.
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |    Length     |            Real-Part (N)
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>           Real-Part (cont)         |          Imaginary-Part (M)
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       Imaginary-Part (cont)
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>    Type
>=20
>       TBA for Complex-Number.
>=20
>    Length
>=20
>       10
>=20
>    Value
>=20
>       SEQUENCE OF Real-Part, Imaginary-Part
>=20
>    Real-Part
>=20
>       RADIUS base-type of Integer.  The real part of the=20
> complex number.
>=20
>    Imaginary-Part
>=20
>       RADIUS base-type of Integer.  The imaginary part of the complex
>       number.
>=20
> </example>
>=20
> I think there is some value here in the ability for data=20
> dictionary driven implementations to easily accommodate=20
> multi-part value fields that are simple concatenations, or=20
> sequences, of pre-defined base data types.
>=20
> A counter example would be an attribute with varying length=20
> fields, some maybe only one or two octets in length.  These=20
> types of constructs require custom parsing code.
>=20
> The one additional caveat, that comes to mind, is that=20
> variable length fields would need to (a) only occur at the=20
> end of all fixed length fields, (b) have an explicit length=20
> field, or (c) have an explicit delimiter field.
>=20
> Comments on this line of thought?
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 29 Aug 2006 01:29:46 +0000
Date: Mon, 28 Aug 2006 21:29:19 -0400
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked]
Subject: Re: RADIUS Design Guidelines

On Mon, Aug 28, 2006 at 02:07:59PM -0700, Glen Zorn (gwz) wrote:
> Barney Wolff <> scribbled on Monday, August 28, 2006 1:17 PM:
> 
> ...
> 
> > In order to avoid pathological cases, I would restrict EEA-type=0 to
> > the first instance of EEA-type in an EA-VSA, and only when the
> > previous EA-VSA had Length=253.  The meaning would be that the value
> > indicated by Length2 is to be concatenated with the last EEA in the
> > previous EA-VSA. It would be an error to have a Tag mismatch, an
> > EEA-type=0 not right after the Vendor-Id, or when the previous EA-VSA
> > was not of max length or there was no previous EA-VSA.   
> 
> All  a sudden, stealing a bit from the Tag sounds very simple ;-)

Well, no.  Every condition I listed would apply, just the same, however
one does fragmentation and concatenation.

-- 
Barney Wolff         I never met a computer I didn't like.

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

Delivery-date: Mon, 28 Aug 2006 21:08:13 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS Design Guidelines
Date: Mon, 28 Aug 2006 14:07:59 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Barney Wolff <> scribbled on Monday, August 28, 2006 1:17 PM:

...

> In order to avoid pathological cases, I would restrict EEA-type=3D0 to
> the first instance of EEA-type in an EA-VSA, and only when the
> previous EA-VSA had Length=3D253.  The meaning would be that the value
> indicated by Length2 is to be concatenated with the last EEA in the
> previous EA-VSA. It would be an error to have a Tag mismatch, an
> EEA-type=3D0 not right after the Vendor-Id, or when the previous =
EA-VSA
> was not of max length or there was no previous EA-VSA.  =20

All  a sudden, stealing a bit from the Tag sounds very simple ;-)
 =20
Hope this helps,

~gwz

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

Delivery-date: Mon, 28 Aug 2006 20:28:31 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS Design Guidelines
Date: Mon, 28 Aug 2006 16:28:21 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Barney Wolff writes...

> > I think that we have proposed that the Extended Attribute VSA
(EA-VSA),
> > i.e. the VSA with a Vendor-Id =3D IETF, may contain multiple =
instances
of
> > an Extended Attribute ...

This has been proposed on the list, but not accepted as consensus.

> btw, I thought the WG consensus was to solve only Type exhaustion, not
> all these other problems.

The consensus was to solve the attribute ID exhaustion, and not to solve
all the issues addressed by the "Diameter-flavor" extended attribute
proposal.

Adding tags has also been proposed on the list, and at IETF-66, but not
accepted as consensus.

I am operating under the assumption that this series of list discussions
will spawn a new Extended Attributes draft, and the WG will be asked,
after suitable review, whether it has consensus to accept that document.

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

Delivery-date: Mon, 28 Aug 2006 20:17:38 +0000
Date: Mon, 28 Aug 2006 16:17:16 -0400
From: Barney Wolff <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: RADIUS Design Guidelines

On Mon, Aug 28, 2006 at 03:35:26PM -0400, Nelson, David wrote:
> Barney Wolff writes...
> 
> > Let me try it again:  What's wrong with using the special value of 0
> for
> > extended-type to indicate that this extended attribute is a
> continuation
> > of the previous one?  That way, extra logic is only exercised when
> needed.
> 
> OK. Let's be a little more specific here.  I think what we are
> discussing is the following format:
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Type      |  Length       |            Vendor-Id
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          Vendor-Id (cont)            | Extended type |    Length2    |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |      Tag      |     Data (Value)...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
> I think that we have proposed that the Extended Attribute VSA (EA-VSA),
> i.e. the VSA with a Vendor-Id = IETF, may contain multiple instances of
> an Extended Attribute -- maybe we should call this an Encapsulated
> Extended Attribute (EEA) to distinguish it from the EA-VSA wrapper.  For
> example:
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Type      |  Length       |            Vendor-Id
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          Vendor-Id (cont)            | Extended type |    Length2    |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |      Tag      |     Data (Value)...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Extended type |    Length2    |      Tag      |  Data (Value)...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |      Data  (cont) ...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
> In this example, if *second* instance of "Extended type" were zero,
> would the value (data) portion of the second EEA be a continuation of
> the first EEA in this EA, or would it possibly be a continuation of as
> EEA in some other EA?
> 
> I think that this can get very complicated if we allow (a) tagging for
> data structuring, and (b) multiple extended attributes in a single VSA,
> and (c) a continuation "marker" of whatever sort.
> 
> Could you please restate you proposal for a "zero" EEA-type as
> continuation flag, given this discussion?  I'm trying to be sure that
> I'm not confused.

In order to avoid pathological cases, I would restrict EEA-type=0 to
the first instance of EEA-type in an EA-VSA, and only when the previous
EA-VSA had Length=253.  The meaning would be that the value indicated
by Length2 is to be concatenated with the last EEA in the previous EA-VSA.
It would be an error to have a Tag mismatch, an EEA-type=0 not right after
the Vendor-Id, or when the previous EA-VSA was not of max length or there
was no previous EA-VSA.

btw, I thought the WG consensus was to solve only Type exhaustion, not
all these other problems.  Since I think we should solve them, I don't
object, but I wonder if this is what people thought they were voting for.

-- 
Barney Wolff         I never met a computer I didn't like.

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

Delivery-date: Mon, 28 Aug 2006 19:35:42 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS Design Guidelines
Date: Mon, 28 Aug 2006 15:35:26 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Barney Wolff writes...

> Let me try it again:  What's wrong with using the special value of 0
for
> extended-type to indicate that this extended attribute is a
continuation
> of the previous one?  That way, extra logic is only exercised when
needed.

OK. Let's be a little more specific here.  I think what we are
discussing is the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |  Length       |            Vendor-Id
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Vendor-Id (cont)            | Extended type |    Length2    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Tag      |     Data (Value)...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

I think that we have proposed that the Extended Attribute VSA (EA-VSA),
i.e. the VSA with a Vendor-Id =3D IETF, may contain multiple instances =
of
an Extended Attribute -- maybe we should call this an Encapsulated
Extended Attribute (EEA) to distinguish it from the EA-VSA wrapper.  For
example:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |  Length       |            Vendor-Id
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Vendor-Id (cont)            | Extended type |    Length2    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Tag      |     Data (Value)...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Extended type |    Length2    |      Tag      |  Data (Value)...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Data  (cont) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

In this example, if *second* instance of "Extended type" were zero,
would the value (data) portion of the second EEA be a continuation of
the first EEA in this EA, or would it possibly be a continuation of as
EEA in some other EA?

I think that this can get very complicated if we allow (a) tagging for
data structuring, and (b) multiple extended attributes in a single VSA,
and (c) a continuation "marker" of whatever sort.

Could you please restate you proposal for a "zero" EEA-type as
continuation flag, given this discussion?  I'm trying to be sure that
I'm not confused.
=20
> Pardon me for grumbling, but it was specifically to avoid this sort of
> debate that some of us suggested we adopt the Diameter attribute
header.

Well, yeah, but that's not where the WG consensus came down.  Folks in
the WG wanted something much simpler.  We're just trying to nail down
all the corner conditions and figure out which ones we need to address,
and which we can simply declare off limits.

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

Delivery-date: Mon, 28 Aug 2006 19:14:49 +0000
Date: Mon, 28 Aug 2006 15:14:22 -0400
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: RADIUS Design Guidelines

On Mon, Aug 28, 2006 at 10:50:02AM -0700, Glen Zorn (gwz) wrote:
> Nelson, David <> scribbled on Monday, August 28, 2006 10:28 AM:
> > 
> > If this is a serious problem, could we simply use two tag fields, one
> > to mark grouping for "data structuring" and another to mark grouping
> > for "continuation"?  
> 
> That's certainly one way to do it, & simple.  Another (more compact but
> less simple) way would be to give away the high-order bit of the tag to
> an "Attribute start flag"; this only allows 128 frags/attr (around 32K
> max attribute length) however.

Let me try it again:  What's wrong with using the special value of 0 for
extended-type to indicate that this extended attribute is a continuation
of the previous one?  That way, extra logic is only exercised when needed.

Pardon me for grumbling, but it was specifically to avoid this sort of
debate that some of us suggested we adopt the Diameter attribute header.
Oh well, never mind.

-- 
Barney Wolff         I never met a computer I didn't like.

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

Delivery-date: Mon, 28 Aug 2006 18:33:04 +0000
Content-class: urn:content-classes:message
Subject: Publication of RFC4668, RFC4669, RFC4670, RFC4671
Date: Mon, 28 Aug 2006 21:32:54 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>

The announcements of the publication of the RADIUS Authentication Client
and Server and RADIUS Accounting Client and Server MIB documents just
went out. Congratulations to the WG and special thanks to David Nelson,
co-chair and editor of the documents for this achievements.=20

Dan

=20

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

Envelope-to: [email-masked]
Delivery-date: Mon, 28 Aug 2006 18:24:36 +0000
Date: Mon, 28 Aug 2006 11:24:30 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4671 on RADIUS Accounting Server MIB for IPv6
From: [email-masked]
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4671

        Title:      RADIUS Accounting Server MIB for 
                    IPv6 
        Author:     D. Nelson
        Status:     Informational
        Date:       August 2006
        Mailbox:    [email-masked]
        Pages:      24
        Characters: 47694
        Obsoletes:  RFC2621
        See-Also:   

        I-D Tag:    draft-ietf-radext-rfc2621bis-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4671.txt

This memo defines a set of extensions that instrument RADIUS
accounting server functions.  These extensions represent a portion of
the Management Information Base (MIB) for use with network management
protocols in the Internet community.  Using these extensions,
IP-based management stations can manage RADIUS accounting servers.

This memo obsoletes RFC 2621 by deprecating the MIB table containing
IPv4-only address formats and defining a new table to add support for
version-neutral IP address formats.  The remaining MIB objects from
RFC 2621 are carried forward into this document.  This memo also adds
UNITS and REFERENCE clauses to selected objects.  This memo provides information for the Internet community.

This document is a product of the RADIUS EXTensions
Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community. 
It does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

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

Envelope-to: [email-masked]
Delivery-date: Mon, 28 Aug 2006 18:24:29 +0000
Date: Mon, 28 Aug 2006 11:23:53 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4669 on RADIUS Authentication Server MIB for IPv6
From: [email-masked]
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4669

        Title:      RADIUS Authentication Server MIB for 
                    IPv6 
        Author:     D. Nelson
        Status:     Standards Track
        Date:       August 2006
        Mailbox:    [email-masked]
        Pages:      25
        Characters: 50525
        Obsoletes:  RFC2619
        See-Also:   

        I-D Tag:    draft-ietf-radext-rfc2619bis-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4669.txt

This memo defines a set of extensions that instrument RADIUS
authentication server functions.  These extensions represent a
portion of the Management Information Base (MIB) for use with network
management protocols in the Internet community.  Using these
extensions, IP-based management stations can manage RADIUS
authentication servers.

This memo obsoletes RFC 2619 by deprecating the MIB table containing
IPv4-only address formats and defining a new table to add support for
version-neutral IP address formats.  The remaining MIB objects from
RFC 2619 are carried forward into this document.  This memo also adds
UNITS and REFERENCE clauses to selected objects.  [STANDARDS TRACK]

This document is a product of the RADIUS EXTensions
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

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

Envelope-to: [email-masked]
Delivery-date: Mon, 28 Aug 2006 18:24:21 +0000
Date: Mon, 28 Aug 2006 11:23:38 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4668 on RADIUS Authentication Client MIB for IPv6
From: [email-masked]
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4668

        Title:      RADIUS Authentication Client MIB for 
                    IPv6 
        Author:     D. Nelson
        Status:     Standards Track
        Date:       August 2006
        Mailbox:    [email-masked]
        Pages:      24
        Characters: 48252
        Obsoletes:  RFC2618
        See-Also:   

        I-D Tag:    draft-ietf-radext-rfc2618bis-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4668.txt

This memo defines a set of extensions that instrument RADIUS
authentication client functions.  These extensions represent a
portion of the Management Information Base (MIB) for use with network
management protocols in the Internet community.  Using these
extensions, IP-based management stations can manage RADIUS
authentication clients.

This memo obsoletes RFC 2618 by deprecating the MIB table containing
IPv4-only address formats and defining a new table to add support for
version-neutral IP address formats.  The remaining MIB objects from
RFC 2618 are carried forward into this document.  The memo also adds
UNITS and REFERENCE clauses to selected objects.  [STANDARDS TRACK]

This document is a product of the RADIUS EXTensions
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

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

Envelope-to: [email-masked]
Delivery-date: Mon, 28 Aug 2006 18:24:13 +0000
Date: Mon, 28 Aug 2006 11:24:07 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4670 on RADIUS Accounting Client MIB for IPv6
From: [email-masked]
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4670

        Title:      RADIUS Accounting Client MIB for 
                    IPv6 
        Author:     D. Nelson
        Status:     Informational
        Date:       August 2006
        Mailbox:    [email-masked]
        Pages:      23
        Characters: 44667
        Obsoletes:  RFC2620
        See-Also:   

        I-D Tag:    draft-ietf-radext-rfc2620bis-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4670.txt

This memo defines a set of extensions that instrument RADIUS
accounting client functions.  These extensions represent a portion of
the Management Information Base (MIB) for use with network management
protocols in the Internet community.  Using these extensions, IP-based management stations can manage RADIUS accounting clients.

This memo obsoletes RFC 2620 by deprecating the MIB table containing
IPv4-only address formats and defining a new table to add support for
version-neutral IP address formats.  The remaining MIB objects from
RFC 2620 are carried forward into this document.  This memo also adds
UNITS and REFERENCE clauses to selected objects.  This memo provides information for the Internet community.

This document is a product of the RADIUS EXTensions
Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community. 
It does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

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

Delivery-date: Mon, 28 Aug 2006 17:50:47 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS Design Guidelines
Date: Mon, 28 Aug 2006 10:50:02 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Nelson, David <> scribbled on Monday, August 28, 2006 10:28 AM:

> Glen Zorn writes...
>=20
>> We already know how to send & receive XL attributes, via in-order
>> fragmentation, transmission & concatenation.  There is no need to use
>> tags for this.
>=20
> Yes, but doesn't this depend on the per-attribute textual definition?
> What I mean to say is that for some attributes there can be only one
> "logical" instance in a RADIUS message, and any additional instances
> MUST be continuations of the first.  For other attributes, having
> multiple instances in messages is acceptable, and there is no
> continuation ever required (or allowed).  What happens if there is an
> attribute that can have multiple instances *and* can have some of
> them continue over multiple attributes?   Don't we need the tag
> (grouping) to     =20
> indicate which are separate instances and which are continuations of
> an instance?=20

Yup, you're right.

...

>=20
> If this is a serious problem, could we simply use two tag fields, one
> to mark grouping for "data structuring" and another to mark grouping
> for "continuation"? =20

That's certainly one way to do it, & simple.  Another (more compact but
less simple) way would be to give away the high-order bit of the tag to
an "Attribute start flag"; this only allows 128 frags/attr (around 32K
max attribute length) however.

Hope this helps,

~gwz

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

Delivery-date: Mon, 28 Aug 2006 17:37:11 +0000
Date: Mon, 28 Aug 2006 13:36:58 -0400
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked]
Subject: Re: RADIUS Design Guidelines

On Mon, Aug 28, 2006 at 10:02:33AM -0700, Glen Zorn (gwz) wrote:
> Barney Wolff <> scribbled on Monday, August 28, 2006 9:30 AM:
> 
> > On Mon, Aug 28, 2006 at 11:54:21AM -0400, Nelson, David wrote:
> >> 
> >> The currently evolving proposals for Extended Attributes, solve some
> >> of the issues that have been identified in the Design Guidelines
> >> draft: shortage of attribute IDs, grouping of attributes, and an
> >> explicit method of fragmentation and reassembly.
> > 
> > I'm confused.  I thought the tag was being used for fragmentation and
> > reassembly, which would seem to preclude its use for grouping.  
> > Can somebody clarify?  
> > 
> 
> We already know how to send & receive XL attributes, via in-order
> fragmentation, transmission & concatenation.  There is no need to use
> tags for this.  The limitation of using tags to group attributes in
> conjunction w/this traditional method is that only one XL attribute of a
> given (extended) type can belong to a group.  If this is a serious
> problem, then some method of distinguishing the beginning of a new
> attribute from the middle of the previous one would be required.

We do?  I know that's been specified for EAP-Message, but if it's been
said anywhere as applying to attributes in general I must have missed it.

> > My own preference would be to use an extended-type of 0 to indicate
> > continuation, rather than the tag field.  
> 
> If we use anything like the customary method of dealing w/XL attributes,
> there doesn't seem to be any need for continuation indicator: an
> attribute starts & continues until a) another attribute starts or b) the
> end of the message is reached.

Again, I'm just confused.  I thought that multiple instances of a given
attribute were taken as multiple instances, not fragmented pieces of a
single longer attribute.  I'd appreciate a pointer to an RFC stating
otherwise in the general case.  Certainly there's been discussion of
how, if the instances are just glommed together, to parse that into
multiple filter rules, for example (and again, I'd really hate to see
such parsing have to be type-specific).  I apologize to all if I've
really missed a decision taken and documented.

-- 
Barney Wolff         I never met a computer I didn't like.

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

Delivery-date: Mon, 28 Aug 2006 17:28:32 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS Design Guidelines
Date: Mon, 28 Aug 2006 13:28:23 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Glen Zorn writes...

> We already know how to send & receive XL attributes, via=20
> in-order fragmentation, transmission & concatenation.  There
> is no need to use tags for this.

Yes, but doesn't this depend on the per-attribute textual definition?
What I mean to say is that for some attributes there can be only one
"logical" instance in a RADIUS message, and any additional instances
MUST be continuations of the first.  For other attributes, having
multiple instances in messages is acceptable, and there is no
continuation ever required (or allowed).  What happens if there is an
attribute that can have multiple instances *and* can have some of them
continue over multiple attributes?   Don't we need the tag (grouping) to
indicate which are separate instances and which are continuations of an
instance?

> The limitation of using tags to group attributes in
> conjunction w/this traditional method is that only one XL=20
> attribute of a given (extended) type can belong to a group.

Yes.

> If this is a serious problem, then some method of distinguishing
> the beginning of a new attribute from the middle of the previous
> one would be required.

If this is a serious problem, could we simply use two tag fields, one to
mark grouping for "data structuring" and another to mark grouping for
"continuation"?

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

Delivery-date: Mon, 28 Aug 2006 17:02:47 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS Design Guidelines
Date: Mon, 28 Aug 2006 10:02:33 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>, "Nelson, David" <[email-masked]>

Barney Wolff <> scribbled on Monday, August 28, 2006 9:30 AM:

> On Mon, Aug 28, 2006 at 11:54:21AM -0400, Nelson, David wrote:
>>=20
>> The currently evolving proposals for Extended Attributes, solve some
>> of the issues that have been identified in the Design Guidelines
>> draft: shortage of attribute IDs, grouping of attributes, and an
>> explicit method of fragmentation and reassembly.
>=20
> I'm confused.  I thought the tag was being used for fragmentation and
> reassembly, which would seem to preclude its use for grouping. =20
> Can somebody clarify? =20
>=20

We already know how to send & receive XL attributes, via in-order
fragmentation, transmission & concatenation.  There is no need to use
tags for this.  The limitation of using tags to group attributes in
conjunction w/this traditional method is that only one XL attribute of a
given (extended) type can belong to a group.  If this is a serious
problem, then some method of distinguishing the beginning of a new
attribute from the middle of the previous one would be required.

> My own preference would be to use an extended-type of 0 to indicate
> continuation, rather than the tag field. =20

If we use anything like the customary method of dealing w/XL attributes,
there doesn't seem to be any need for continuation indicator: an
attribute starts & continues until a) another attribute starts or b) the
end of the message is reached.

> But I'm just an anti-tag
> bigot. =20
>=20
> --
> Barney Wolff         I never met a computer I didn't like.

Hope this helps,

~gwz

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

Delivery-date: Mon, 28 Aug 2006 16:29:54 +0000
Date: Mon, 28 Aug 2006 12:29:33 -0400
From: Barney Wolff <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: RADIUS Design Guidelines

On Mon, Aug 28, 2006 at 11:54:21AM -0400, Nelson, David wrote:
> 
> The currently evolving proposals for Extended Attributes, solve some of
> the issues that have been identified in the Design Guidelines draft:
> shortage of attribute IDs, grouping of attributes, and an explicit
> method of fragmentation and reassembly.

I'm confused.  I thought the tag was being used for fragmentation and
reassembly, which would seem to preclude its use for grouping.  Can
somebody clarify?

My own preference would be to use an extended-type of 0 to indicate
continuation, rather than the tag field.  But I'm just an anti-tag bigot.

-- 
Barney Wolff         I never met a computer I didn't like.

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

Delivery-date: Mon, 28 Aug 2006 15:54:27 +0000
Content-class: urn:content-classes:message
Subject: RADIUS Design Guidelines
Date: Mon, 28 Aug 2006 11:54:21 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

I've been giving some thought to the current RADIUS Design Guidelines
draft, and the group consensus regarding that document and the Extended
Attribute, coming out of IETF-66.

The currently evolving proposals for Extended Attributes, solve some of
the issues that have been identified in the Design Guidelines draft:
shortage of attribute IDs, grouping of attributes, and an explicit
method of fragmentation and reassembly.

The one remaining issue raised in the RADIUS Design Guidelines draft not
addressed is the issue of multi-part data values.  Most of the RADIUS
work to date has simply addressed this by defining an attribute, of
base-type String, and then defining sub-fields within the string.

There is nothing inherently wrong with this approach, except perhaps
that it makes it more difficult to maintain data dictionary driven
implementations.

I have a suggestion to float, in term of the BCP for attribute design.
I'd like to suggest that any value portion of a RADIUS TLV that has
multiple parts be formally defined in the document as a SEQUENCE of
pre-defined RADIUS base-types.  I'm stealing the SMI syntax for
SEQUENCE, as used in creating conceptual tables for MIB modules.  It
would be relatively easy for data dictionary driven implementations to
automatically understand a sequence of pre-defined base types.

Let me provide a contrived example.  Suppose we want to define a new
attribute whose value is a complex number.  For those who may have
forgotten, a complex number consists of a real part and an imaginary
part.  This is most often represented as: n + m*i, where n and m are
real numbers and i is the square root of -1.  Such a hypothetical
attribute light look like:

<example>

Complex-Number

   Description

   A complex number, consisting to two parts, a real part N and an=20
   imaginary part M, such that the value is N + M*i, where i is the
   square root of -1.

   A summary of the Complex Number Attribute format is shown below.
   The fields are transmitted from left to right.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Real-Part (N)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Real-Part (cont)         |          Imaginary-Part (M)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Imaginary-Part (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      TBA for Complex-Number.

   Length

      10

   Value

      SEQUENCE OF Real-Part, Imaginary-Part

   Real-Part

      RADIUS base-type of Integer.  The real part of the complex number.

   Imaginary-Part

      RADIUS base-type of Integer.  The imaginary part of the complex
      number.

</example>

I think there is some value here in the ability for data dictionary
driven implementations to easily accommodate multi-part value fields
that are simple concatenations, or sequences, of pre-defined base data
types.

A counter example would be an attribute with varying length fields, some
maybe only one or two octets in length.  These types of constructs
require custom parsing code.

The one additional caveat, that comes to mind, is that variable length
fields would need to (a) only occur at the end of all fixed length
fields, (b) have an explicit length field, or (c) have an explicit
delimiter field.

Comments on this line of thought?

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

Delivery-date: Mon, 28 Aug 2006 15:45:16 +0000
Content-class: urn:content-classes:message
Subject: RE: Glen's proposal for Attribute Extension
Date: Mon, 28 Aug 2006 08:44:58 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Nelson, David <> scribbled on Monday, August 28, 2006 8:13 AM:

...

> Perhaps.  I'm likely reacting to the "naming thing".  Somehow, the
> notion of a Standard Extended Attribute format that is defined as a
> special case of a Vendor Specific Attribute seems wrong to me. =20

Not sure why: it seems to have worked pretty well for other SDOs, 3GPP2
being the one with which I'm most familiar.

>=20
> The value you see in using 26 as the "top-level" attribute ID is that
> it re-uses existing code for generating and parsing VSAs? =20

Actually, the whole proposal reuses well understood techniques & attempt
to isolate the changes to an area of the code  that is likely fluid in
any case.

> IMHO, once
> you need to make *any* code changes, you need to release new versions
> of the SW/FW.  I very much doubt there are many (if any)
> implementations that can accomplish this with only data dictionary
> changes.  Having said that, what is the practical cost of assigning a
> different "top-level" ID for the Extended Attribute?=20

Not sure; the rationale for making this a VSA is largely that VSA
formats are often non-standard (Cisco's, for example; I believe
Nortel's, as well, probably others) & therefore this (minor) change
would be localized in an area of code that changes fairly often anyway,
rather in the main line which I suspect changes much more rarely.   =20

Hope this helps,

~gwz

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

Delivery-date: Mon, 28 Aug 2006 15:13:23 +0000
Content-class: urn:content-classes:message
Subject: RE: Glen's proposal for Attribute Extension
Date: Mon, 28 Aug 2006 11:13:03 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Glen Zorn writes...

> OK. probably "minimal code changes" would be more accurate
> than "no code changes.

Yes.

> The formats of VSAs must be well defined, even if not standard.

Yes, each instance is well defined, but often highly varied.

> Well, I think that it would be as clear as we wanted to make it.
> If we publish an RFC that has "MUST" surrounding the formats,
> that seems pretty clear to me.

Perhaps.  I'm likely reacting to the "naming thing".  Somehow, the
notion of a Standard Extended Attribute format that is defined as a
special case of a Vendor Specific Attribute seems wrong to me.

The value you see in using 26 as the "top-level" attribute ID is that it
re-uses existing code for generating and parsing VSAs?  IMHO, once you
need to make *any* code changes, you need to release new versions of the
SW/FW.  I very much doubt there are many (if any) implementations that
can accomplish this with only data dictionary changes.  Having said
that, what is the practical cost of assigning a different "top-level" ID
for the Extended Attribute?

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

Delivery-date: Mon, 28 Aug 2006 14:33:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Zero Tag field in Filter-Rule attribute
Date: Mon, 28 Aug 2006 10:33:36 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...
> With the change, it might look like this:
>=20
> The Tag field is one octet, and MUST always be present. It is used to
> identify the filter rule that is represented. Where a single
> filter rule exceeds 253 octets in length, the rule MUST be encoded
> across multiple NAS-Filter-Rule attributes, each with the same
> non-zero Tag value; non-zero Tag values MUST be unique for each
> filter rule present in a RADIUS packet. The value of '0' (0x30) in
> the Tag field indicates that the attribute contains a filter rule
> that does not exceed 253 octets in length; as a result attributes
> with a Tag value of 0x30 MUST NOT be concatenated, and one or more
> Filter-Rule attributes with a tag value of 0x31 may be included
> in a single RADIUS packet, each describing a single filter rule.

Looks good to me, with the change to consistent use of 0x30, noted by
Jouni.

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

Delivery-date: Sun, 27 Aug 2006 21:37:36 +0000
Date: Sun, 27 Aug 2006 17:37:11 -0400
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue: Diameter-RADIUS gateway behavior not completely specified

On Sun, Aug 27, 2006 at 01:57:41PM -0700, Glen Zorn (gwz) wrote:
> 
> > Sigh.  It seems to me that 3588 4.1 at least in spirit says that a
> > gateway getting an attribute with an M-bit that it cannot for
> > whatever reason translate, MUST reject the message.  
> 
> In this case it would be handy if it did, but it doesn't & interpreting
> it that way would violate the M-bit semantics, IMHO.  

Violate in what way?

> > I would truly
> > hate to have to specify gateway behavior for each attribute type, and
> > hate even more having to implement type-specific behavior, just to
> > handle message overflow - or, for that matter, for any other reason. 
> 
> Unfortunately, this problem seems to be the "elephant in the corner" of
> RADIUS-Diameter interop: everybody knows about it (presupposing simple
> arithmetic ability) but nobody wants to talk about it...

Message overflow is a potential problem, sure.  But does dealing with it
actually require different logic depending on what attribute(s) don't fit?
Similarly, does dealing with a single attribute of length >253 actually
have to depend on the attribute type?  Pfui, if so.

-- 
Barney Wolff         I never met a computer I didn't like.

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

Delivery-date: Sun, 27 Aug 2006 20:57:52 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Diameter-RADIUS gateway behavior not completely specified
Date: Sun, 27 Aug 2006 13:57:41 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Barney Wolff <mailto:[email-masked]> scribbled on Saturday, August
26, 2006 6:16 PM:

...

> Sigh.  It seems to me that 3588 4.1 at least in spirit says that a
> gateway getting an attribute with an M-bit that it cannot for
> whatever reason translate, MUST reject the message. =20

In this case it would be handy if it did, but it doesn't & interpreting
it that way would violate the M-bit semantics, IMHO. =20

> I would truly
> hate to have to specify gateway behavior for each attribute type, and
> hate even more having to implement type-specific behavior, just to
> handle message overflow - or, for that matter, for any other reason.=20

Unfortunately, this problem seems to be the "elephant in the corner" of
RADIUS-Diameter interop: everybody knows about it (presupposing simple
arithmetic ability) but nobody wants to talk about it...

Hope this helps,

~gwz

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

Delivery-date: Sun, 27 Aug 2006 20:35:41 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Zero Tag field in Filter-Rule attribute
Date: Sun, 27 Aug 2006 13:35:22 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

[email-masked] <> scribbled on Sunday, August 27, 2006
11:36 AM:

> [snip]
>=20
>> The Tag field is one octet, and MUST always be present. It is used to
>> identify the filter rule that is represented. Where a single filter
>> rule exceeds 253 octets in length, the rule MUST be encoded across
>> multiple NAS-Filter-Rule attributes, each with the same non-zero Tag
>> value; non-zero Tag values MUST be unique for each filter rule
>> present in a RADIUS packet. The value of '0' (0x30) in the Tag field
>> indicates that the attribute contains a filter rule that does not
>> exceed 253 octets in length; as a result attributes with a Tag value
>> of 0x30 MUST NOT be concatenated, and one or more Filter-Rule
>> attributes with a tag value of 0x31 may be included
>=20
> Shouldn't 0x31 here be 0x30?

Yup, good catch!

>=20
>> in a single RADIUS packet, each describing a single filter rule.
>=20
>=20
> Cheers,
> 	Jouni

Hope this helps,

~gwz

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

Delivery-date: Sun, 27 Aug 2006 18:53:38 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue 204:  Review of draft-ietf-radext-delegated-prefix-02
Date: Sun, 27 Aug 2006 11:53:24 -0700

Issue 204: Review of draft-ietf-radext-delegated-prefix-02
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: August 27, 2006
Reference:
Document: draft-ietf-radext-delegated-prefix-02
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

Section 1

   The Delegated-IPv6-Prefix is a RADIUS attribute [1] that carries an
   IPv6 prefix to be delegated to the user, for use in the user's
   network.  For example, the prefix in a Delegated-IPv6-Prefix
   attribute can be delegated to another node through DHCP Prefix
   Delegation [2].

[BA] Is there another potential use of the Delegated-IPv6-Prefix attribute?
Suggest this be changed to:

   "The Delegated-IPv6-Prefix is a RADIUS attribute [1] that carries an
   IPv6 prefix to be delegated to the user, for use in the user's
   network, via DHCP Prefix Delegation [2]."

--------
   The Framed-IPv6-Prefix attribute [4] serves a similar purpose, but
   may also be used for other purposes other than delegating a prefix
   for use in a user's network.  Definition of the Delegated-IPv6-Prefix
   allows the simultaneous use of the Framed-IPv6-Prefix for other
   purposes and the Delegated-IPv6-Prefix for prefix delegation.

[BA] The Framed-IPv6-Prefix attribute is used to indicate a prefix
that is announced via RS/RA, which is not really a "similar" purpose.
Suggest this be changed to:

   "The Framed-IPv6-Prefix attribute defined in [4] as not designed
   for use in prefix delegation, and therefore Framed-IPv6-Prefix
   and Delegated-IPv6-Prefix attributes may be included in the same
   RADIUS packet."
--------

   The definition of the Delegated-IPv6-Prefix Attribute is based on the
   Framed-IPv6-Prefix attribute [4].

While the attributes are similar in format, they are used for different
purposes.  Suggest that this sentence be deleted.
--------

Section 3

The following table describes which messages the Delegated-IPv6-
   Prefix attribute can appear in and in what quantity.

   +------------------------------------------------------+
   | Request Accept Accounting  #   Attribute             |
   |                Request                               |
   | 0+      0+     0+          TBD Delegated-IPv6-Prefix |
   +------------------------------------------------------+

   In this table 0+ means that zero or more instances of this attribute
   MAY be present in packet.  This attribute MUST NOT appear in any
   packet not listed in the table.

Please use the standard table format from RFC 3162; Attribute Tables
are typically included in a separate section.  Suggest the following:

"4.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in which kinds of packets, and in what quantity.

   Request Accept Reject Challenge Accounting  #  Attribute
   0+      0+     0      0         0+         TBD  Delegated-IPv6-Prefix

   The meaning of the above table entries is as follows:

   0     This attribute MUST NOT be present.
   0+    Zero or more instances of this attribute MAY be present.
   0-1   Zero or one instance of this attribute MAY be present.
   1     Exactly one instance of this attribute MUST be present.
   1+    One or more of these attributes MUST be present."

Section 4

I think you need to include text on the AVP flag rules, along the lines of 
what is
in the Framed-IPv6-Prefix attribute:
                                    +---------------------+
                                    |    AVP Flag rules   |
                                    |----+-----+----+-----|----+
                  AVP               |    |     |SHLD| MUST|    |
  Attribute Name  Code   Value Type |MUST| MAY | NOT|  NOT|Encr|
  ----------------------------------|----+-----+----+-----|----|
  Delegated-IPv6-  97    OctetString| M  |  P  |    |  V  | Y  |
    Prefix                          |    |     |    |     |    |

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

Delivery-date: Sun, 27 Aug 2006 18:36:30 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Zero Tag field in Filter-Rule attribute
Date: Sun, 27 Aug 2006 20:36:05 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

[snip]

> The Tag field is one octet, and MUST always be present. It is used to
> identify the filter rule that is represented. Where a single
> filter rule exceeds 253 octets in length, the rule MUST be encoded
> across multiple NAS-Filter-Rule attributes, each with the same
> non-zero Tag value; non-zero Tag values MUST be unique for each
> filter rule present in a RADIUS packet. The value of '0' (0x30) in
> the Tag field indicates that the attribute contains a filter rule
> that does not exceed 253 octets in length; as a result attributes
> with a Tag value of 0x30 MUST NOT be concatenated, and one or more
> Filter-Rule attributes with a tag value of 0x31 may be included

Shouldn't 0x31 here be 0x30?

> in a single RADIUS packet, each describing a single filter rule.

Cheers,
	Jouni

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

Delivery-date: Sun, 27 Aug 2006 18:08:49 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: Issue: Zero Tag field in Filter-Rule attribute
Date: Sun, 27 Aug 2006 11:08:10 -0700

Question:  In the interest of making it easier to enter in Filter-Rules as 
ASCII strings, does it make sense to make the Tag value 0x30 (The '0' 
character) the way to indicate that a filter rule is untagged, rather than 
NULL (0x00)?  My understanding is that there may not be an easy way to enter 
in a NULL character in an ASCII string within some RADIUS server 
implementations, whereas entering a '0' character is easy.

Here is the current text:

Tag

The Tag field is one octet, and MUST always be present. It is used to
identify the filter rule that is represented. Where a single
filter rule exceeds 253 octets in length, the rule MUST be encoded
across multiple NAS-Filter-Rule attributes, each with the same
non-zero Tag value; non-zero Tag values MUST be unique for each
filter rule present in a RADIUS packet. The value of zero (0) in
the Tag field indicates that the attribute contains a filter rule
that does not exceed 253 octets in length; as a result attributes
with a Tag value of zero MUST NOT be concatenated, and one or more
Filter-Rule attributes with a tag value of zero may be included
in a single RADIUS packet, each describing a single filter rule.

With the change, it might look like this:

The Tag field is one octet, and MUST always be present. It is used to
identify the filter rule that is represented. Where a single
filter rule exceeds 253 octets in length, the rule MUST be encoded
across multiple NAS-Filter-Rule attributes, each with the same
non-zero Tag value; non-zero Tag values MUST be unique for each
filter rule present in a RADIUS packet. The value of '0' (0x30) in
the Tag field indicates that the attribute contains a filter rule
that does not exceed 253 octets in length; as a result attributes
with a Tag value of 0x30 MUST NOT be concatenated, and one or more
Filter-Rule attributes with a tag value of 0x31 may be included
in a single RADIUS packet, each describing a single filter rule.

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

Delivery-date: Sun, 27 Aug 2006 01:16:25 +0000
Date: Sat, 26 Aug 2006 21:15:53 -0400
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue: Diameter-RADIUS gateway behavior not completely specified

On Sat, Aug 26, 2006 at 04:25:21PM -0700, Glen Zorn (gwz) wrote:
> Barney Wolff <mailto:[email-masked]> scribbled on Saturday, August
> 26, 2006 4:00 PM:
> 
> > On Sat, Aug 26, 2006 at 01:45:00PM -0700, Glen Zorn (gwz) wrote:
> >> Barney Wolff <mailto:[email-masked]> scribbled on Saturday,
> >> August 26, 2006 12:34 PM: 
> >> 
> >>> I agree that the behavior should be specified.  It would seem that
> >>> this is an opportunity to take advantage of Diameter's M-bit in
> >>> governing the gateway's behavior.
> >> 
> >> Not sure how the M-bit helps.  Can you elaborate?
> > 
> > Sorry, I thought it was obvious:  An attribute lacking the M-bit may
> > legitimately be ignored, so may be eliminated in translation.  Not so
> > if the M-bit is set. 
> 
> Right, but RFC 4005 says that the M-bit MUST be set on the
> NAS-Filter-Rule AVP...

Sigh.  It seems to me that 3588 4.1 at least in spirit says that a gateway
getting an attribute with an M-bit that it cannot for whatever reason
translate, MUST reject the message.  I would truly hate to have to specify
gateway behavior for each attribute type, and hate even more having to
implement type-specific behavior, just to handle message overflow - or,
for that matter, for any other reason.

-- 
Barney Wolff         I never met a computer I didn't like.

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

Delivery-date: Sat, 26 Aug 2006 23:25:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Diameter-RADIUS gateway behavior not completely specified
Date: Sat, 26 Aug 2006 16:25:21 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Barney Wolff <mailto:[email-masked]> scribbled on Saturday, August
26, 2006 4:00 PM:

> On Sat, Aug 26, 2006 at 01:45:00PM -0700, Glen Zorn (gwz) wrote:
>> Barney Wolff <mailto:[email-masked]> scribbled on Saturday,
>> August 26, 2006 12:34 PM:=20
>>=20
>>> I agree that the behavior should be specified.  It would seem that
>>> this is an opportunity to take advantage of Diameter's M-bit in
>>> governing the gateway's behavior.
>>=20
>> Not sure how the M-bit helps.  Can you elaborate?
>=20
> Sorry, I thought it was obvious:  An attribute lacking the M-bit may
> legitimately be ignored, so may be eliminated in translation.  Not so
> if the M-bit is set.=20

Right, but RFC 4005 says that the M-bit MUST be set on the
NAS-Filter-Rule AVP...

Hope this helps,

~gwz

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

Delivery-date: Sat, 26 Aug 2006 23:01:00 +0000
Date: Sat, 26 Aug 2006 19:00:10 -0400
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue: Diameter-RADIUS gateway behavior not completely specified

On Sat, Aug 26, 2006 at 01:45:00PM -0700, Glen Zorn (gwz) wrote:
> Barney Wolff <mailto:[email-masked]> scribbled on Saturday, August
> 26, 2006 12:34 PM:
> 
> > I agree that the behavior should be specified.  It would seem that
> > this is an opportunity to take advantage of Diameter's M-bit in
> > governing the gateway's behavior.  
> 
> Not sure how the M-bit helps.  Can you elaborate?

Sorry, I thought it was obvious:  An attribute lacking the M-bit may
legitimately be ignored, so may be eliminated in translation.  Not so
if the M-bit is set.

-- 
Barney Wolff         I never met a computer I didn't like.

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

Delivery-date: Sat, 26 Aug 2006 20:45:07 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Diameter-RADIUS gateway behavior not completely specified
Date: Sat, 26 Aug 2006 13:45:00 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Barney Wolff <mailto:[email-masked]> scribbled on Saturday, August
26, 2006 12:34 PM:

> I agree that the behavior should be specified.  It would seem that
> this is an opportunity to take advantage of Diameter's M-bit in
> governing the gateway's behavior. =20

Not sure how the M-bit helps.  Can you elaborate?

...

Hope this helps,

~gwz

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

Delivery-date: Sat, 26 Aug 2006 20:39:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Diameter-RADIUS gateway behavior not completely specified
Date: Sat, 26 Aug 2006 13:38:32 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <mailto:[email-masked]> scribbled on Saturday,
August 26, 2006 12:48 PM:

>> I agree that the behavior should be specified.  It would seem that
>> this is an opportunity to take advantage of Diameter's M-bit in
>> governing the gateway's behavior.
>=20
> In theory the Diameter/RADIUS gateway could discard Diameter AVPs
> without the 'M' bit set in order to fit within the RADIUS packet size
> limit. =20
> However if there are multiple attributes of a given type, it might
> not be appropriate to discard some but not all of them.  So in
> practice, the rules might get quite complex.  If we believe that this
> is a problem which is only likely to occur due to mis-configuraiton,
> then it might be better for the gateway just to indicate that a
> problem has occurred to the source and destination and leave it at
> that.     =20

In this case, I think the problem would likely stem from
misconfiguration, but in general I don't believe that that is a good
assumption.  I'm seeing requests to send truly huge objects via Diameter
(& therefore, potentially through RADIUS)

Hope this helps,

~gwz

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

Delivery-date: Sat, 26 Aug 2006 19:48:26 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Issue: Diameter-RADIUS gateway behavior not completely specified
Date: Sat, 26 Aug 2006 12:48:12 -0700

>I agree that the behavior should be specified.  It would seem that this
>is an opportunity to take advantage of Diameter's M-bit in governing
>the gateway's behavior.

In theory the Diameter/RADIUS gateway could discard Diameter AVPs without 
the 'M' bit set in order to fit within the RADIUS packet size limit.  
However if there are multiple attributes of a given type, it might not be 
appropriate to discard some but not all of them.  So in practice, the rules 
might get quite complex.  If we believe that this is a problem which is only 
likely to occur due to mis-configuraiton, then it might be better for the 
gateway just to indicate that a problem has occurred to the source and 
destination and leave it at that.

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

Delivery-date: Sat, 26 Aug 2006 19:43:16 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Issue: Diameter-RADIUS gateway behavior not completely specified
Date: Sat, 26 Aug 2006 12:43:03 -0700

I think the major issue here is translation from Diameter to RADIUS in the 
case where the translated RADIUS packet does not fit within the maxium 
(4096) byte packet size.  Is that correct?

This problem is not unique to the NAS-Filter-Rule, so if possible I'd prefer 
a general solution, rather than one specific to NAS-Filter-Rule.

My take is that a solution:

a. Needs to notify the Diameter client or server of the problem so that it 
can be logged and hopefully fixed;

b. Needs to avoid sending an illegal RADIUS packet.

The way to think about this is that the Diameter/RADIUS proxy conceptually 
translates the Diameter message to a RADIUS packet and then checks whether 
it fits within the length constraints.  If not, then it needs to translate 
the oversize RADIUS packet to something else rather than sending it.   This 
problem can even occur in other scenarios, such as a RADIUS proxy which 
attempts to add a Proxy-State attribute but finds that the packet exceeds 
the 4096 octet size limit.

My suggestion is to translate an oversize RADIUS Access-Accept into a RADIUS 
Access-Reject with an Error-Cause attribute of value 505 "Other Proxy 
Processing Error ".   Not sure what Diameter error message would be 
appropriate.

In the case of server-initiated messages, I think the correct thing is to 
translate an oversize RADIUS CoA-Request to a Disconnect-Request, also with 
Error-Cause value 505.

==========================================================
>Description of issue: Diameter-RADIUS gateway behavior not completely 
>specified
>Submitter name: Glen Zorn
>Submitter email address: [email-masked]
>Date first submitted: 26 Aug 06
>Document: draft-ietf-radext-filter-01.txt
>Comment type: T
>Priority: 1
>Section: 4
>Rationale/Explanation of issue: The last sentence of section 4 says
>"Note that since a Diameter AVP can be larger than the maximum RADIUS
>packet size (4096), translation from Diameter to RADIUS may not be
>possible in all cases."  While this is true, the behavior of the
>Diameter-RADIUS gateway in this case is left unspecified.  Is the
>response forwarded back toward the requests' originator without the
>untranslatable AVPs?  In the case of an Access-Accept message, Section
>1.2 says "If a NAS conforming to this specification receives an
>Access-Accept packet containing a NAS-Filter-Rule attribute which it
>cannot apply, it MUST act as though it had received an Access-Reject.",
>it might be reasonable for the gateway to translate the Access-Accept
>into an Access-Reject, since an attribute that is missing because
>untranslatable can obviously not be applied.  In the case of a CoA
>message with an untranslatable attribute, should the message be
>translated into a Disconnect-Request or just discarded?  Or in both
>cases, should the gateway respond to the originating/responding Diameter
>peer with an appropriate error (e.g., DIAMETER_INVALID_AVP_LENGTH) and
>let it figure out the next step?  If so, it still seems that the peers
>behavior must be specified.
>
>--
>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/>

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

Delivery-date: Sat, 26 Aug 2006 19:36:22 +0000
Date: Sat, 26 Aug 2006 15:33:50 -0400
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue: Diameter-RADIUS gateway behavior not completely specified

I agree that the behavior should be specified.  It would seem that this
is an opportunity to take advantage of Diameter's M-bit in governing
the gateway's behavior.

On Sat, Aug 26, 2006 at 11:54:58AM -0700, Glen Zorn (gwz) wrote:
> Description of issue: Diameter-RADIUS gateway behavior not completely
> specified
> Submitter name: Glen Zorn
> Submitter email address: [email-masked]
> Date first submitted: 26 Aug 06
> Document: draft-ietf-radext-filter-01.txt
> Comment type: T
> Priority: 1
> Section: 4 
> Rationale/Explanation of issue: The last sentence of section 4 says
> "Note that since a Diameter AVP can be larger than the maximum RADIUS
> packet size (4096), translation from Diameter to RADIUS may not be
> possible in all cases."  While this is true, the behavior of the
> Diameter-RADIUS gateway in this case is left unspecified.  Is the
> response forwarded back toward the requests' originator without the
> untranslatable AVPs?  In the case of an Access-Accept message, Section
> 1.2 says "If a NAS conforming to this specification receives an
> Access-Accept packet containing a NAS-Filter-Rule attribute which it
> cannot apply, it MUST act as though it had received an Access-Reject.",
> it might be reasonable for the gateway to translate the Access-Accept
> into an Access-Reject, since an attribute that is missing because
> untranslatable can obviously not be applied.  In the case of a CoA
> message with an untranslatable attribute, should the message be
> translated into a Disconnect-Request or just discarded?  Or in both
> cases, should the gateway respond to the originating/responding Diameter
> peer with an appropriate error (e.g., DIAMETER_INVALID_AVP_LENGTH) and
> let it figure out the next step?  If so, it still seems that the peers
> behavior must be specified.

-- 
Barney Wolff         I never met a computer I didn't like.

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

Delivery-date: Sat, 26 Aug 2006 18:55:23 +0000
Content-class: urn:content-classes:message
Subject: Issue: Diameter-RADIUS gateway behavior not completely specified
Date: Sat, 26 Aug 2006 11:54:58 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Cc: "Glen Zorn \(gwz\)" <[email-masked]>

Description of issue: Diameter-RADIUS gateway behavior not completely
specified
Submitter name: Glen Zorn
Submitter email address: [email-masked]
Date first submitted: 26 Aug 06
Document: draft-ietf-radext-filter-01.txt
Comment type: T
Priority: 1
Section: 4=20
Rationale/Explanation of issue: The last sentence of section 4 says
"Note that since a Diameter AVP can be larger than the maximum RADIUS
packet size (4096), translation from Diameter to RADIUS may not be
possible in all cases."  While this is true, the behavior of the
Diameter-RADIUS gateway in this case is left unspecified.  Is the
response forwarded back toward the requests' originator without the
untranslatable AVPs?  In the case of an Access-Accept message, Section
1.2 says "If a NAS conforming to this specification receives an
Access-Accept packet containing a NAS-Filter-Rule attribute which it
cannot apply, it MUST act as though it had received an Access-Reject.",
it might be reasonable for the gateway to translate the Access-Accept
into an Access-Reject, since an attribute that is missing because
untranslatable can obviously not be applied.  In the case of a CoA
message with an untranslatable attribute, should the message be
translated into a Disconnect-Request or just discarded?  Or in both
cases, should the gateway respond to the originating/responding Diameter
peer with an appropriate error (e.g., DIAMETER_INVALID_AVP_LENGTH) and
let it figure out the next step?  If so, it still seems that the peers
behavior must be specified.

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

Delivery-date: Sat, 26 Aug 2006 17:43:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Zero Tag field in Filter-Rule attribute
Date: Sat, 26 Aug 2006 10:41:48 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Bernard Aboba <> scribbled on Saturday, August 26, 2006 7:52 AM:

,,,

>=20
> My suggestion is that a value of zero (0) be used to indicate a
> filter-rule that is less than 253 octets, so that concenation if not
> required, and multiple filter-rules can utilize the same zero (0)
> value.  Here is the proposed text:  =20
>=20
> Tag
>=20
>        The Tag field is one octet, and MUST always be present.  It is
>        used to identify the filter rule that is represented.  Where a
>        single filter rule exceeds 253 octets in length, the rule may
>        be encoded across multiple NAS-Filter-Rule attributes, each
>        with the same non-zero Tag value; non-zero Tag values MUST be
>        unique for each filter rule present in a RADIUS packet.  The
>        value of zero (0) in the Tag field indicates that the
>        attribute contains a filter rule that does not exceed 253
>        octets in length; as a result attributes with a Tag value of
>        zero MUST NOT be concatenated, and multiple Filter-Rule
>        attributes with a tag value of zero may be included in a
> single RADIUS packet.=20

Looks good to me.

Hope this helps,

~gwz=20

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

Delivery-date: Sat, 26 Aug 2006 14:52:53 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue: Zero Tag field in Filter-Rule attribute
Date: Sat, 26 Aug 2006 07:52:03 -0700

Issue: Zero Tag field in Filter-Rule attribute
Submitter name: David Nelson
Submitter email address: dnelson at enterasys.com
Date first submitted: August 26, 2006
Reference:
Document: Filter-Rule-02
Comment type: T
Priority: S
Section: 2
Rationale/Explanation of issue:

Currently the document does not describe how the Tag value of zero is 
handled.
I would suggest that the Tag value of 0 be reserved as an indicator of 
un-tagged attributes.
If it is not already clear from the diagram and text, we should clarify that 
this Tag is not
optional, as it is for strings in 2868.

[BA]

My suggestion is that a value of zero (0) be used to indicate a filter-rule 
that is less than 253 octets, so that concenation if not required, and 
multiple filter-rules can utilize the same zero (0) value.  Here is the 
proposed text:

Tag

       The Tag field is one octet, and MUST always be present.  It is used 
to
       identify the filter rule that is represented.  Where a single
       filter rule exceeds 253 octets in length, the rule may be encoded
       across multiple NAS-Filter-Rule attributes, each with the same
       non-zero Tag value; non-zero Tag values MUST be unique for each
       filter rule present in a RADIUS packet.  The value of zero (0) in
       the Tag field indicates that the attribute contains a filter rule
       that does not exceed 253 octets in length; as a result attributes
       with a Tag value of zero MUST NOT be concatenated, and multiple
       Filter-Rule attributes with a tag value of zero may be included
       in a single RADIUS packet.

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

Delivery-date: Fri, 25 Aug 2006 21:26:14 +0000
Content-class: urn:content-classes:message
Subject: RE: Glen's proposal for Attribute Extension
Date: Fri, 25 Aug 2006 14:25:54 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Nelson, David <> scribbled on Friday, August 25, 2006 7:44 AM:

> Bernard Aboba writes...
>=20
>> One of the motivations for this proposal was that it could be
>> implemented with no change to code on existing RADIUS servers,
>> because a single octet extended type was used, making it compatible
>> with the VSA format suggested in RFC 2865.
>=20
> I think we need to explore the "no code change" assertion.  If we are
> limiting the discussion of changes to the RADIUS attribute parser
> code that looks at command code and attribute ID, then it's true that
> no changes, are required.  However, once the parser determines that
> its type 26, a second level of parsing is required.  The vendor OUI
> needs to be recognized as well as any vendor types.  Assuming (and
> this may be a big assumption) that your data dictionary driven
> implementation allows you to enroll new vendor OUIs and associate
> them with a list of vendor types, it may be possible to implement
> this suggestion without any code changes.        =20
>=20
> I think that once you add the tag, some code changes likely to be
> required.  We are only discussing servers here.  I think we all agree
> that NASes and policy-enforcing proxies need to have code changes to
> encompass the semantics of the new attributes.=20

OK. probably "minimal code changes" would be more accurate than "no code
changes".  However, the strength of the proposal remains, I think, in
that the features already exist in both clients and servers, just in
different combinations.
  =20
>=20
>> Given that, why would the attribute type need to be changed?
>=20
> One additional reason that I would like to see the VSA ID not used is
> that RFC 2865 permits free-format VSAs, notwithstanding the
> recommendation to re-use the basic TLV format. =20

???  We are still talking about computers here, right?  If so, to the
best of my knowledge computers don't deal well with "free-form" ;-).
The formats of VSAs must be well defined, even if not standard.

> We need to retain
> that freedom for VSAs.  I would like to curtail that freedom for the
> Extended RADIUS Attributes, and mandate use of the basic TLV format,
> along with use of basic RADIUS data types. =20

OK.
  =20
>=20
> I think it's clear from the analysis in the Design Guidelines draft
> that the data models for VSA and standard attribute spaces have
> diverged.  I thought it was a goal of the WG to bring them back
> together for the extended attributes.  I don't think it would be very
> clear that the format restrictions apply only to VSAs with a
> particular OUI value. =20

Well, I think that it would be as clear as we wanted to make it.  If we
publish an RFC that has "MUST" surrounding the formats, that seems
pretty clear to me.

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

Delivery-date: Fri, 25 Aug 2006 21:08:18 +0000
Content-class: urn:content-classes:message
Subject: RE: Glen's proposal for Attribute Extension
Date: Fri, 25 Aug 2006 14:07:55 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Nelson, David <> scribbled on Friday, August 25, 2006 7:09 AM:

> Uggh!  Let me try again, to get the ASCII art aligned.  I really
> dislike the line-wrap behavior of my current e-mail client, when it
> comes to plain text messages, with ">" quoting characters inserted. =20
>=20
> Glen has also suggested, as have others, that a fixed tag field
> could/should be used to address issues of attribute grouping.  The
> tag does not show up in this layout. =20
>=20
>>     0                   1                   2                   3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |     Type      |  Length       |            Vendor-Id
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>         Vendor-Id (cont)           | Extended type |    Length2    |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |    Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>=20
> If we were to add it, would the format look like this?

Yes, sorry for the confusion.

>=20
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Type      |  Length       |            Vendor-Id
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          Vendor-Id (cont)           | Extended type |    Length2    |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |      Tag      |     Data...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>=20
> An additional question -- are we suggesting that this format is a
> MUST for the Extended RADIUS Attributes, as opposed to the merely
> suggested format for VSAs?  I think we should do so. =20

Me, too.

>=20
> I also think that maybe we want to not use the VSA attribute type
> (26) for this purpose.=20

Not sure why...

>=20
>>=20
>>    Type
>>=20
>>       26 for Vendor-Specific.
>>=20
>>    Length
>>=20
>>       >=3D 7
>>=20
>>    Vendor-Id
>>=20
>>       0 (for Extended Attributes)
>>=20
>>    Extended Type
>>=20
>>       0:       Reserved
>>       1-250:   Allocated by IANA
>>       250-255: Reserved
>>=20
>>    Length2
>>=20
>>       >=3D0
>>=20
>>       Multiple subattributes MAY be encoded within a single Extended
>>       Attribute, although they do not have to be.
>=20
>      Tag
>=20
>         0:        Not Used (i.e. attribute is untagged)
>         1-255:    Tag value used to aggregate attributes into groups
>=20
> The value of the Tag field MAY be limited to printable ASCII values,
> for ease of human entry and interpretation.=20
>=20
>> For Diameter compatibility, the RADIUS Extended Type attributes
>> would need to be allocated within the Diameter AVP space.

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

Delivery-date: Fri, 25 Aug 2006 14:44:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Glen's proposal for Attribute Extension
Date: Fri, 25 Aug 2006 10:44:27 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> One of the motivations for this proposal was that it could be
implemented
> with no change to code on existing RADIUS servers, because a single
octet
> extended type was used, making it compatible with the VSA format
suggested
> in RFC 2865.

I think we need to explore the "no code change" assertion.  If we are
limiting the discussion of changes to the RADIUS attribute parser code
that looks at command code and attribute ID, then it's true that no
changes, are required.  However, once the parser determines that its
type 26, a second level of parsing is required.  The vendor OUI needs to
be recognized as well as any vendor types.  Assuming (and this may be a
big assumption) that your data dictionary driven implementation allows
you to enroll new vendor OUIs and associate them with a list of vendor
types, it may be possible to implement this suggestion without any code
changes.

I think that once you add the tag, some code changes likely to be
required.  We are only discussing servers here.  I think we all agree
that NASes and policy-enforcing proxies need to have code changes to
encompass the semantics of the new attributes.

> Given that, why would the attribute type need to be changed?

One additional reason that I would like to see the VSA ID not used is
that RFC 2865 permits free-format VSAs, notwithstanding the
recommendation to re-use the basic TLV format.  We need to retain that
freedom for VSAs.  I would like to curtail that freedom for the Extended
RADIUS Attributes, and mandate use of the basic TLV format, along with
use of basic RADIUS data types.

I think it's clear from the analysis in the Design Guidelines draft that
the data models for VSA and standard attribute spaces have diverged.  I
thought it was a goal of the WG to bring them back together for the
extended attributes.  I don't think it would be very clear that the
format restrictions apply only to VSAs with a particular OUI value.=20

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

Delivery-date: Fri, 25 Aug 2006 14:26:19 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Glen's proposal for Attribute Extension
Date: Fri, 25 Aug 2006 07:26:09 -0700

>I also think that maybe we want to not use the VSA attribute type (26)
>for this purpose.

One of the motivations for this proposal was that it could be implemented 
with no change to code on existing RADIUS servers, because a single octet 
extended type was used, making it compatible with the VSA format suggested 
in RFC 2865.  Given that, why would the attribute type need to be changed?

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

Delivery-date: Fri, 25 Aug 2006 14:09:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Glen's proposal for Attribute Extension
Date: Fri, 25 Aug 2006 10:09:25 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Uggh!  Let me try again, to get the ASCII art aligned.  I really dislike
the line-wrap behavior of my current e-mail client, when it comes to
plain text messages, with ">" quoting characters inserted.

Glen has also suggested, as have others, that a fixed tag field
could/should be used to address issues of attribute grouping.  The tag
does not show up in this layout.

>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |  Length       |            Vendor-Id
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         Vendor-Id (cont)           | Extended type |    Length2    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    Data...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

If we were to add it, would the format look like this?

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |  Length       |            Vendor-Id
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Vendor-Id (cont)           | Extended type |    Length2    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Tag      |     Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

An additional question -- are we suggesting that this format is a MUST
for the Extended RADIUS Attributes, as opposed to the merely suggested
format for VSAs?  I think we should do so.

I also think that maybe we want to not use the VSA attribute type (26)
for this purpose. =20

>=20
>    Type
>=20
>       26 for Vendor-Specific.
>=20
>    Length
>=20
>       >=3D 7
>=20
>    Vendor-Id
>=20
>       0 (for Extended Attributes)
>=20
>    Extended Type
>=20
>       0:       Reserved
>       1-250:   Allocated by IANA
>       250-255: Reserved
>=20
>    Length2
>=20
>       >=3D0
>=20
>       Multiple subattributes MAY be encoded within a single Extended
>       Attribute, although they do not have to be.

     Tag

        0:        Not Used (i.e. attribute is untagged)
        1-255:    Tag value used to aggregate attributes into groups

The value of the Tag field MAY be limited to printable ASCII values, for
ease of human entry and interpretation.
=20
> For Diameter compatibility, the RADIUS Extended Type attributes would
need
> to be allocated within the Diameter AVP space.

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

Delivery-date: Fri, 25 Aug 2006 13:59:37 +0000
Content-class: urn:content-classes:message
Subject: RE: Glen's proposal for Attribute Extension
Date: Fri, 25 Aug 2006 09:59:13 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Glen has also suggested, as have others, that a fixed tag field
could/should be used to address issues of attribute grouping.  The tag
does not show up in this layout.

>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |  Length       |            Vendor-Id
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            Vendor-Id (cont)           | Extended type |    Length2
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Data...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

If we were to add it, would the format look like this?

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |  Length       |            Vendor-Id
=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Vendor-Id (cont)           | Extended type |    Length2
|
=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      Tag      |     Data...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

An additional question -- are we suggesting that this format is a MUST
for the Extended RADIUS Attributes, as opposed to the merely suggested
format for VSAs?  I think we should do so.

I also think that maybe we want to not use the VSA attribute type (26)
for this purpose. =20

>=20
>    Type
>=20
>       26 for Vendor-Specific.
>=20
>    Length
>=20
>       >=3D 7
>=20
>    Vendor-Id
>=20
>       0 (for Extended Attributes)
>=20
>    Extended Type
>=20
>       0:       Reserved
>       1-250:   Allocated by IANA
>       250-255: Reserved
>=20
>    Length2
>=20
>       >=3D0
>=20
>       Multiple subattributes MAY be encoded within a single Extended
>       Attribute, although they do not have to be.

     Tag

        0:        Not Used (i.e. attribute is untagged)
        1-255:    Tag value used to aggregate attributes into groups

The value of the Tag field MAY be limited to printable ASCII values, for
ease of human entry and interpretation.
=20
> For Diameter compatibility, the RADIUS Extended Type attributes would
need
> to be allocated within the Diameter AVP space.

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

Delivery-date: Thu, 24 Aug 2006 19:27:44 +0000
Content-class: urn:content-classes:message
Subject: RE: Glen's proposal for Attribute Extension
Date: Thu, 24 Aug 2006 12:27:13 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <mailto:[email-masked]> scribbled on Tuesday,
August 22, 2006 1:15 PM:

Sorry for the tardy response: my laptop's been in the shop getting
upgraded to WinXP.  Anyway, yes, I think that pretty much covers it.
Thanks for drawing it!

> Is the below a reasonable description of your proposal?
>=20
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     =20
>     =20
>     =20
>          =20
>     =20
>     =20
>     =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =20
> Type      |  Length       |            Vendor-Id
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Vendor-Id (cont)           | Extended type |    Length2    |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =20
> Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-     =20
>=20
>    Type
>=20
>       26 for Vendor-Specific.
>=20
>    Length
>=20
>       >=3D 7
>=20
>    Vendor-Id
>=20
>       0 (for Extended Attributes)
>=20
>    Extended Type
>=20
>       0:       Reserved
>       1-250:   Allocated by IANA
>       250-255: Reserved
>=20
>    Length2
>=20
>       >=3D0
>=20
>       Multiple subattributes MAY be encoded within a single Extended
>       Attribute, although they do not have to be.
>=20
>=20
> For Diameter compatibility, the RADIUS Extended Type attributes would
> need to be allocated within the Diameter AVP space.=20

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

Delivery-date: Wed, 23 Aug 2006 13:39:33 +0000
Content-class: urn:content-classes:message
Subject: Issue: Review of draft-chowdhury-mip6-radius-02
Date: Wed, 23 Aug 2006 16:38:07 +0300
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Review of draft-chowdhury-mip6-radius-02
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: August 23, 2006
Reference:=20
Document: draft-chowdhury-mip6-radius-02
Comment type: T/E
Priority: 1
Section: various
Rationale/Explanation of issue:

1) The document should give all new attributes short names that=20
don't contain spaces (e.g. "MIP6-Home-Link-Prefix" or just
"Home-Link-Prefix").

2) Section 5: "The attributes MAY be present in the Access-Accept and
the Accounting-Request." The accounting part is too ambiguous; does
e.g. requesting DNS update really make sense for accounting messages?
At the very least, the document should explicitly say what is=20
included in accounting messages and what it means.

3) Section 5.2: This attribute should use the same data type as other
attributes containing FQDNs (i.e., just the FQDN, without the zeroes
in the beginning).

4) Section 5.3: This attribute should use the same data type as
other attributes containing IPv6 prefixes (e.g. Framed-IPv6-Prefix=20
in RFC 3162).

5) Section 5.5: This section should describe that the status code
field uses values defined in "draft-ietf-mip6-bootstrapping-split-02";
now it gives the impression that totally number space is created
(but doesn't give any IANA considerations on how to manage it).

6) Section 5.5 first says "response to the request MAY not carry a
FQDN value" but then changes its mind "The data field MUST contain a
FQDN".

7) Section 5.5: This attribute should probably be split to 2..3
separate attributes (e.g. DNS-Update-FQDN and DNS-Update-Result);
this would be better in line with other recent RADIUS documents.

8) Section 5: Suggest rephrasing "All bits set to 0" to "The bits=20
MUST be initialized to zero by the sender, and MUST be ignored by=20
the receiver."

9) Section 8: According to Section 5, the first four attributes are
sent by the RADIUS server to the NAS, so the first column should be=20
"0" instead of "0-1" (alternatively, Section 5 needs to specify what=20
these attributes mean in Access-Requests).=20

10) Section 8: The table should probably include accounting messages
and CoA-Request as well.

11) For the split scenario, the document should define what to=20
put in Service-Type and NAS-Port-Type attributes (and maybe also
Calling-Station-Id and Called-Station-Id).

12) The document talks about doing EAP authentication over RADIUS,
but never mentions RFC 3579?=20

13) The document should either point to RFC 2548, or explicitly say
that this document does not contain an interoperable solution for the
split scenario, since it does not specify (either here or by
referencing some other document) how to send the MSK from the RADIUS
server to the HA.

14) The document should probably have at least informative=20
reference to RFC 4306.

15) And last (but not least, as everyone who has followed=20
RADEXT knows :-): the document does not have a Diameter
considerations section.

Best regards,
Pasi

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

Delivery-date: Wed, 23 Aug 2006 07:41:38 +0000
Date: Wed, 23 Aug 2006 09:40:27 +0200
From: Hannes Tschofenig <[email-masked]>
To: "Nelson, David" <[email-masked]>
CC:  [email-masked]
Subject: Re: FW: [Geopriv] I-D ACTION:draft-ietf-geopriv-radius-lo-08.txt

Hi David,

after submitting the -08 version Pasi sent me some more comments. I have 
incorporated them as well and I am about to submit -09.

Ciao
Hannes

Nelson, David schrieb:
> WGLC on this draft in GEOPRIV and RADEXT has completed.  The revised I-D
> purports to addresses all comments received during WGLC.
> 
> (Forwarded Message)
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Geographic Location/Privacy Working
> Group of the IETF.
> 
> 	Title		: Carrying Location Objects in RADIUS
> 	Author(s)	: H. Tschofenig, et al.
> 	Filename	: draft-ietf-geopriv-radius-lo-08.txt
> 	Pages		: 57
> 	Date		: 2006-8-14
> 	
> This document describes RADIUS attributes for conveying access
> network ownership and location information based on a civic and
> geospatial location format.
> 
> The distribution of location information is a privacy sensitive task.
> Dealing with mechanisms to preserve the user's privacy is important
> and addressed in this document.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-08.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of
> the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-geopriv-radius-lo-08.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-geopriv-radius-lo-08.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 22 Aug 2006 22:24:44 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Glen's proposal for Attribute Extension 
cc: [email-masked]
Date: Tue, 22 Aug 2006 18:16:05 -0400
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:

>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            Vendor-Id (cont)           | Extended type |    Length2    |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Data...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

  This doesn't solve the length problem, even if the extended types
are allowed to span multiple VSA's.  The attribute lengths are still
limited to 253 bytes of data.

  And I'm a little leery of yet another 8-bit type field.  I know the
8 bits in the current space aren't exhausted, and they've been
sufficient for a decade.  A 16-bit type would have little additional
impact on the packet length, but would make attribute allocation much
more open.

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

Delivery-date: Tue, 22 Aug 2006 21:14:45 +0000
Content-class: urn:content-classes:message
Subject: FW: [Geopriv] I-D ACTION:draft-ietf-geopriv-radius-lo-08.txt 
Date: Tue, 22 Aug 2006 17:14:36 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C62F.F8E23E59
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

WGLC on this draft in GEOPRIV and RADEXT has completed.  The revised I-D
purports to addresses all comments received during WGLC.

(Forwarded Message)

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Geographic Location/Privacy Working
Group of the IETF.

	Title		: Carrying Location Objects in RADIUS
	Author(s)	: H. Tschofenig, et al.
	Filename	: draft-ietf-geopriv-radius-lo-08.txt
	Pages		: 57
	Date		: 2006-8-14
=09
This document describes RADIUS attributes for conveying access
network ownership and location information based on a civic and
geospatial location format.

The distribution of location information is a privacy sensitive task.
Dealing with mechanisms to preserve the user's privacy is important
and addressed in this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-08.txt

To remove yourself from the I-D Announcement list, send a message to=20
[email-masked] with the word unsubscribe in the body of
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-geopriv-radius-lo-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-geopriv-radius-lo-08.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_001_01C6C62F.F8E23E59
Content-Type: application/octet-stream;
	name="draft-ietf-geopriv-radius-lo-08.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-ietf-geopriv-radius-lo-08.URL
Content-Disposition: attachment;
	filename="draft-ietf-geopriv-radius-lo-08.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1pZXRmLWdlb3ByaXYtcmFkaXVzLWxvLTA4LnR4dA0K

------_=_NextPart_001_01C6C62F.F8E23E59--

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

Delivery-date: Tue, 22 Aug 2006 21:14:26 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to Issue 199: Attribute Length
Date: Tue, 22 Aug 2006 14:13:59 -0700

This issue pointed out that a single rule cannot be less than 32 octets in 
length.   However, with the proposed Tag format, it is possible for a rule 
fragment to be included in the value field of a NAS-Filter-Rule attribute.  
Such a fragment could be as small as 1 octet.  Therefore the minimum length 
of the modified NAS-Filter-Rule attribute appears to be 4 octets.

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

Delivery-date: Tue, 22 Aug 2006 21:06:32 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Request for Review:  draft-ietf-radext-filter-01.txt
Date: Tue, 22 Aug 2006 14:06:23 -0700

The Filter document has been updated to address Issues 198 and 199.   The 
latest version is available here:

http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-01.txt

Comments welcome.

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

Delivery-date: Tue, 22 Aug 2006 21:02:23 +0000
Content-class: urn:content-classes:message
Subject: RE: Request from MIP6 WG on a Radius I-D
Date: Tue, 22 Aug 2006 17:01:04 -0400
From: "Nelson, David" <[email-masked]>
To: "Basavaraj Patil" <[email-masked]>, <[email-masked]>

Basavaraj Patil writes...

> Just for my own clarification here, are you recommending that the
> I-D be considered as a MIP6 WG document but go through a cross-WG
> review?

Yes.  We've done this with a RADIUS document in the GEOPRIV WG.
Cross-WG review is requested, and simultaneous WGLC on the draft is held
in each WG.

> In which case the MIP6 WG would be responsbile for the process of
> advancing the I-D.

Yes, once WGLC comments from both MIP6 and RADEXT have been
satisfactorily resolved.

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

Delivery-date: Tue, 22 Aug 2006 20:30:35 +0000
Content-class: urn:content-classes:message
Subject: RE: Request from MIP6 WG on a Radius I-D
Date: Tue, 22 Aug 2006 16:30:07 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Basavaraj Patil" <[email-masked]>

A point of clarification.

> We (MIP6 WG chairs) would like to request that this I-D=20
> be reviewed and advanced in the RADEXT WG.

The RADEXT WG chairs are interpreting this as a request for Cross-WG
review.

The subject draft is not on the charter for the RADEXT WG, but I believe
it is on the charter of the MIP6 WG.  Therefore, document is not
eligible for advancement in the RADEXT WG.  However, the RADEXT WG
members are requested to review and comment upon the MIP6 RADIUS draft,
much as we have done previously for the GEOPRIV RADIUS draft. =20

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

Delivery-date: Tue, 22 Aug 2006 20:15:46 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: Glen's proposal for Attribute Extension
Date: Tue, 22 Aug 2006 13:15:20 -0700

Is the below a reasonable description of your proposal?

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)           | Extended type |    Length2    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      26 for Vendor-Specific.

   Length

      >= 7

   Vendor-Id

      0 (for Extended Attributes)

   Extended Type

      0:       Reserved
      1-250:   Allocated by IANA
      250-255: Reserved

   Length2

      >=0

      Multiple subattributes MAY be encoded within a single Extended
      Attribute, although they do not have to be.

For Diameter compatibility, the RADIUS Extended Type attributes would need
to be allocated within the Diameter AVP space.

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

Delivery-date: Tue, 22 Aug 2006 19:40:42 +0000
Content-class: urn:content-classes:message
Subject: FW: Request from MIP6 WG on a Radius I-D
Date: Tue, 22 Aug 2006 15:39:59 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Forwarded Message From: Basavaraj Patil

The MIP6 WG has been working on developing bootstrapping solutions over
the
last 18+ months. The Bootstrapping solution specified in the MIP6 WG is
a
framework that includes building blocks using various protocols. One of
the
building blocks therein is Radius (interaction between the HA and the
AAA
server). The MIP6 WG bootstrapping I-Ds are:

1. Problem Statement for bootstrapping Mobile IPv6 (In the RFC Editor
Queue)
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-05.txt

2. Mobile IPv6 bootstrapping in split scenario (I-D Exists)
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-
02.txt

3. MIP6-bootstrapping via DHCPv6 for the Integrated Scenario (I-D
Exists)
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integr
ated-dhc-01.txt

The Radius specific I-D is draft-chowdhury-mip6-radius-02.txt, and this
is
required for the overall bootstrapping solution. (I-D Exists)
http://www.ietf.org/internet-drafts/draft-chowdhury-mip6-radius-02.txt

We (MIP6 WG chairs) would like to request that this I-D be reviewed and
advanced in the RADEXT WG. The MIP6 WG itself has been asked to review
and
comment on it and no issues have been identified.

If you need any MIP6 specific help in reviewing this I-D, please let us
know.=20

Please direct comments to the RADEXT WG list, and use the Issue Tracker
template found at: http://www.drizzle.com/~aboba/RADEXT/

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

Delivery-date: Mon, 21 Aug 2006 23:20:58 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-filter-01.txt 
Date: Mon, 21 Aug 2006 18:50:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: RADIUS Filter Rule Attribute
	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-filter-01.txt
	Pages		: 9
	Date		: 2006-8-21
	
This document defines the NAS-Filter-Rule attribute within the Remote
Authentication Dial In User Service (RADIUS), equivalent to the
Diameter NAS-Filter-Rule AVP described in RFC 4005.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-filter-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-filter-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-filter-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-filter-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

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

Delivery-date: Fri, 18 Aug 2006 21:25:18 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on RADIUS Extended attributes
Date: Fri, 18 Aug 2006 14:24:56 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Nelson, David <> supposedly scribbled:

> Glen Zorn writes...
>=20
>>> (2) A standard method of encoding "over-size" attributes (those
>>> greater than 253 but less than the RADIUS PDU size).
>>=20
>> Didn't we already have that?
>=20
> Not in a formally specified, generic way.  As a common practice, and
> for specific attributes, sure.=20

IIRC, it was one of the major reasons for specifying that attributes may =
not be re-ordered by proxies.  How formal and generic do you want it to =
be?

>=20
>> One problem it doesn't solve, though, is that of requiring code
>> changes in servers & clients.  I'm still wondering why we think that
>> 2 bytes are really needed for "Extended Type".
>=20
> One reason is to be very sure that we solve the shortage of standard
> attribute IDs for all time.  Let's do this once, and be done with it.
> The proposal to define an Extended Type ID of zero as the
> "continuation" =20
> flag would probably create the need for revised code, even if the
> Extended Length field were limited to one octet.=20

Just one more reason that it's not that good of an idea.

>=20
>> Also (just to note), the lack of a second Length field means that
>> extended attributes can't be packed, unlike VSAs.
>=20
> Is that a bad thing?  An unreasonable restriction?

It's a useful feature that is not lost w/my proposal.

>=20
>> Grouping could be handled w/tags, a la RFC 2868.
>=20
> Yes, I agree, with the caveat that the tag fields are fixed, and not
> optional.  I think you expressed a similar sentiment.=20

Yup.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Fri, 18 Aug 2006 18:53:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on RADIUS Extended attributes
Date: Fri, 18 Aug 2006 14:52:09 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Glen Zorn writes...

> > (2) A standard method of encoding "over-size" attributes (those
> > greater than 253 but less than the RADIUS PDU size).
>=20
> Didn't we already have that?

Not in a formally specified, generic way.  As a common practice, and for
specific attributes, sure.

> One problem it doesn't solve, though, is that of requiring code
changes in
> servers & clients.  I'm still wondering why we think that 2 bytes are
> really needed for "Extended Type".

One reason is to be very sure that we solve the shortage of standard
attribute IDs for all time.  Let's do this once, and be done with it.
The proposal to define an Extended Type ID of zero as the "continuation"
flag would probably create the need for revised code, even if the
Extended Length field were limited to one octet.

> Also (just to note), the lack of a second Length field means that
> extended attributes can't be packed, unlike VSAs.

Is that a bad thing?  An unreasonable restriction?

> Grouping could be handled w/tags, a la RFC 2868.

Yes, I agree, with the caveat that the tag fields are fixed, and not
optional.  I think you expressed a similar sentiment.

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

Delivery-date: Fri, 18 Aug 2006 01:36:40 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on RADIUS Extended attributes
Date: Thu, 17 Aug 2006 18:36:26 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <mailto:[email-masked]> supposedly scribbled:

...

> RFC 2865 states that more than one vendor-specific attribute can be
> included within a RADIUS attribute of Type 26.  However, I don't
> think it describes how vendor-specific attributes can be split across
> RADIUS attributes of Type 26. =20

I don't think it does, but I don't know why it would be any different =
than the way normal attributes work.

> One way to address this is via a tagging scheme. =20

Not sure why this would be necessary.  If you think of the Vendor-Type =
field as just an extension :-) of the standard Type field, then on =
reception just cat all attributes w/the same "type" (in this case 26 + =
Vendor-Type) together in order, creating one massive attribute.  Where =
this scheme falls apart is if there are more than one XXL attribute of =
the same type in a message.  I think that tags can fix this, though, as =
well as providing a rudimentary attribute grouping capability.  With =
tags, the algorithm becomes "cat all the attributes w/the same =
(Type+ExtType) and Tag together in order"; again, this only allows one =
XXL attribute of a given (Type+ExtType) per attribute group, but I =
suspect that that is probably adequate.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Fri, 18 Aug 2006 01:21:32 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on RADIUS Extended attributes
Date: Thu, 17 Aug 2006 18:20:56 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Nelson, David <> supposedly scribbled:

...

>=20
> This solves two problems:
>=20
> (1) Exhaustion of ID space.
>=20
> (2) A standard method of encoding "over-size" attributes (those
> greater than 253 but less than the RADIUS PDU size).=20

Didn't we already have that?

>=20
> I think this meets the requirements we've agreed to for Extended
> Attributes.=20

One problem it doesn't solve, though, is that of requiring code changes =
in servers & clients.  I'm still wondering why we think that 2 bytes are =
really needed for "Extended Type".  Also (just to note), the lack of a =
second Length field means that extended attributes can't be packed, =
unlike VSAs.

>=20
> There are other issues that we have *not* yet agreed to, such as how
> to standardize structured data (grouping, sub-types, etc.).=20

Grouping could be handled w/tags, a la RFC 2868.

>=20
> While we agreed to solve one problem at a time, I note there are
> drafts waiting in the wings that need to take advantage of grouping
> features, or at least are currently designed to use them. =20

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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

Envelope-to: [email-masked]
Delivery-date: Thu, 17 Aug 2006 21:25:27 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Questions on RADIUS Extended attributes 
cc: [email-masked]
Date: Thu, 17 Aug 2006 17:17:03 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> By "list of such attributes", do you mean a sequence comprising an
> initial attribute and continuation (concatenation) attributes?  I was
> thinking that removing one or more continuation attributes from the
> middle of a sequence would be very bad.

  Yes, and yes.

  But most proxies either (1) forward everything unchanged, or (b)
implement local policy.

> Mangling by whom?  Noticed by whom?  It would certainly seem to me that
> the NAS or the Server would notice!

  A proxying server that implements local policy enforcement has no
business forwarding attributes it doesn't understand.

  A proxying server that does nothing more than routing or aggregation
has no business changing the policies it's transporting.

  A NAS that expects Extended-Type has a trust relationship with a
local RADIUS server.  If that server doesn't understand Extended-Type,
it (a) won't send Extended-Type to the NAS, or (b) has no business
forwarding Extended-Type from a home server to the NAS.

> Tagging would support grouping, but not nested grouping.  Do we think
> that single-level grouping is sufficient to solve the "80% problem"?

  I believe so.

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

Delivery-date: Thu, 17 Aug 2006 19:36:10 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on RADIUS Extended attributes 
Date: Thu, 17 Aug 2006 15:35:48 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Alan DeKok writes...

> The requirement to not add or delete the attributes is limited
> to only those proxies that are unaware of the new attribute=20
> format.  Those proxies might remove an Extended-Type attribute=20
> from the *middle* of a list of such attributes, which would be=20
> bad.

By "list of such attributes", do you mean a sequence comprising an
initial attribute and continuation (concatenation) attributes?  I was
thinking that removing one or more continuation attributes from the
middle of a sequence would be very bad.

>   2) policy-limiting forwarders.  These servers act as forwarders
> that authenticate remotely, but enforce local policy.  In that case,
> the Extended-Type attributes will either be understood locally (and
> thus not mangled), or not understood (in which case mangling won't=20
> be noticed).

Mangling by whom?  Noticed by whom?  It would certainly seem to me that
the NAS or the Server would notice!

> The main problem with this proposal is that it doesn't easily
> support nested grouping.  For that to work would require defining=20
> yet another attribute packing format.  Or, Emile's tag suggestion=20
> would seem to work.

Tagging would support grouping, but not nested grouping.  Do we think
that single-level grouping is sufficient to solve the "80% problem"?

> My only requirement for a tagged format is that as Glen pointed=20
> out, the tags MUST ALWAYS exist.  Optional tags are a nightmare.

I absolutely agree.

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

Envelope-to: [email-masked]
Delivery-date: Thu, 17 Aug 2006 19:07:58 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Questions on RADIUS Extended attributes 
cc: [email-masked]
Date: Thu, 17 Aug 2006 14:59:34 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> And we clearly require that attributes of type TBD never be re-ordered,
> added or deleted by proxies.

  The re-ordering requirement is already in RADIUS, of course.  The
requirement to not add or delete the attributes is limited to only
those proxies that are unaware of the new attribute format.  Those
proxies might remove an Extended-Type attribute from the *middle* of a
list of such attributes, which would be bad.

  We can try to work around that problem by increasing the complexity
of the solution, or we can see if that problem exists today.

  Personally, I don't see it as much of a problem.  Proxies generally
fall into one of two categories:

  1) blind forwarders who serve as aggregation points and/or
application-layer routers.  These forwarders don't modify the packet
contents.  The Extended-Type proposal doesn't affect these.

  2) policy-limiting forwarders.  These servers act as forwarders that
authenticate remotely, but enforce local policy.  In that case, the
Extended-Type attributes will either be understood locally (and thus
not mangled), or not understood (in which case mangling won't be
noticed)

> There are other issues that we have *not* yet agreed to, such as how to
> standardize structured data (grouping, sub-types, etc.).

  The main problem with this proposal is that it doesn't easily
support nested grouping.  For that to work would require defining yet
another attribute packing format.  Or, Emile's tag suggestion would
seem to work.

  My only requirement for a tagged format is that as Glen pointed out,
the tags MUST ALWAYS exist.  Optional tags are a nightmare.

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

Delivery-date: Thu, 17 Aug 2006 18:15:28 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on RADIUS Extended attributes
Date: Thu, 17 Aug 2006 14:15:10 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> Yes. So your proposal looks like this, no?
>=20
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Type      |    Length     |            Extended-Type      |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Value...
>      +-+-+-+-+-+-+-+-+
>=20
>      Type
>=20
>         TBD  (not 26)
>=20
>      Length
>=20
>         >=3D 4
>=20
>      Extended-Type
>=20
>         Two octets.
>=20
>         0:  Concatenation
>        1-255:  Reserved
>        255-65530: Allocated by IANA
>        65531-65535:  Reserved
>=20
>      Value
>=20
>         0-251 octets (Length - 4).
>=20
>      Only a single RADIUS Extended-Type attribute may be included
within
>      a RADIUS attribute of Type TBD.   Where the value of the
Extended-
>      Type field is zero (0), this indicates that the content of the
value
>      field is to be concatenated with the contents of the value field
in
>      the previous attribute of Type TBD.

And we clearly require that attributes of type TBD never be re-ordered,
added or deleted by proxies.

This solves two problems:

(1) Exhaustion of ID space.

(2) A standard method of encoding "over-size" attributes (those greater
than 253 but less than the RADIUS PDU size).

I think this meets the requirements we've agreed to for Extended
Attributes.

There are other issues that we have *not* yet agreed to, such as how to
standardize structured data (grouping, sub-types, etc.).

While we agreed to solve one problem at a time, I note there are drafts
waiting in the wings that need to take advantage of grouping features,
or at least are currently designed to use them.

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

Delivery-date: Thu, 17 Aug 2006 17:57:12 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on RADIUS Extended attributes
Date: Thu, 17 Aug 2006 13:56:44 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> One way to address this is via a tagging scheme.  I think=20
> the question is whether we'd want to *require* tags in each=20
> Extended attribute, or not.

I'd say yes.  I think the simplicity of a fixed field trades off well
against one extra octet on the wire.

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

Delivery-date: Wed, 16 Aug 2006 22:26:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Define some new NAS-Port-Type
Date: Wed, 16 Aug 2006 17:26:37 -0500
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "CTO YAN Renxiang" <[email-masked]>, <[email-masked]>, <[email-masked]>

I was out in the weeds in my comment.  I was thinking about something =
else and Bernard's comment about access networks threw me.  Not sure why =
a PAN isn't considered an access network, if a PAN access controller is =
connected to something larger.  Just ignore the comment...=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Glen Zorn (gwz)
> Sent: Wednesday, August 16, 2006 11:33 AM
> To: Congdon, Paul T (ProCurve)
> Cc: Bernard Aboba; CTO YAN Renxiang; [email-masked];=20
> [email-masked]
> Subject: RE: Define some new NAS-Port-Type
>=20
> Congdon, Paul T (ProCurve) <> supposedly scribbled:
>=20
> > People do use RADIUS to authenticate infrastructure devices as well
>=20
> True, but the conjunction of the terms "infrastructure" &=20
> "Personal Area Network" has me confused.  Would you mind elaborating?
>=20
> >=20
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> >> Sent: Tuesday, August 15, 2006 7:30 PM
> >> To: 'CTO YAN Renxiang'; [email-masked];=20
> [email-masked]
> >> Subject: RE: Define some new NAS-Port-Type
> >>=20
> >> Typically a NAS-Port-Type value is only needed for access=20
> >> technologies that may need to use RADIUS.  I don't think that
> >> 802.15 fits into that category (though lots of other wireless=20
> >> technologies do).
> >>=20
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of CTO YAN Renxiang
> >> Sent: Tuesday, August 01, 2006 10:13 PM
> >> To: Bernard Aboba; [email-masked]; [email-masked]
> >> Subject: re: Define some new NAS-Port-Type
> >>=20
> >> Hi, David and Bernard,
> >>=20
> >> Thanks for your comments.
> >>=20
> >> I think stating as work in progress in Informative Reference is ok.
> >> Many RFC documents are also written in this way, as follows,
> >>=20
> >> 5.2 Informative References
> >>=20
> >> [802.20]	Mobile Broadband Wireless Access (MBWA), IEEE
> >> Standard, Work
> >> in Progress.
> >>=20
> >> [802.22]	Wireless Regional Area Networks (WRAN), IEEE
> >> Standard, Work
> >> in Progress.
> >>=20
> >> How do you think about that?
> >>=20
> >> BTW, do you think we need to define a NAS-Port-Type for 802.15
> >> (WPAN) also?=20
> >>=20
> >> Renxiang
> >>=20
> >>=20
> >>> -----=D4=AD=CA=BC=D3=CA=BC=FE-----
> >>> =B7=A2=BC=FE=C8=CB: Bernard Aboba =
[mailto:[email-masked]]
> >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA8=D4=C22=C8=D5 9:04
> >>> =CA=D5=BC=FE=C8=CB: [email-masked]; CTO YAN Renxiang;=20
> [email-masked]
> >>> =D6=F7=CC=E2: RE: Define some new NAS-Port-Type
> >>>=20
> >>>=20
> >>>> I understand the
> >>>> difficulty of referencing draft IEEE standards, so I'm not sure=20
> >>>> exactly what to suggest as an alternative.
> >>>=20
> >>> I think they can reference IEEE 802 work-in-progress as an=20
> >>> Informative Reference.
> >>>=20
> >>>=20
> >>>=20
> >>=20
> >> --
> >> to unsubscribe send a message to=20
> [email-masked] with=20
> >> the word 'unsubscribe' in a single line as the message text body.
> >> archive: <http://psg.com/lists/radiusext/>
> >>=20
> >>=20
> >> --
> >> to unsubscribe send a message to=20
> [email-masked] with=20
> >> the word 'unsubscribe' in a single line as the message text body.
> >> archive: <http://psg.com/lists/radiusext/>
>=20
> Hope this helps,
>=20
> ~gwz
>=20
> Why is it that most of the world's problems can't be solved by simply
>   listening to John Coltrane? -- Henry Gabriel
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Envelope-to: [email-masked]
Delivery-date: Wed, 16 Aug 2006 22:25:40 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Questions on RADIUS Extended attributes 
Date: Wed, 16 Aug 2006 18:17:27 -0400
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> Yes. So your proposal looks like this, no?

  Yes.  I just don't do ASCII art well. :)

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

Delivery-date: Wed, 16 Aug 2006 22:10:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on RADIUS Extended attributes
Date: Wed, 16 Aug 2006 15:10:44 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <mailto:[email-masked]> supposedly scribbled:

>> I know that a couple of people stated that preference on the list
>> recently, but without any technical justification.
>=20
> I think there may have been some concern about compatibility with
> existing RADIUS servers, since the format proposed in the Lior & Li
> draft utilized a larger Extended-Type field (32 bits) than was
> suggested for the VSA format in RFC 2865.

Yes, that's actually what I'm questioning the need for...
  =20
>=20
>> Is it really necessary to do more than double the number of standard
>> attributes?  That is what the >VSA approach would do, without
>> requiring code changes...
>=20
> I think the implicit assumption here is that the VSA approach
> (Vendor-Id of 0) would utilize the VSA format described in RFC 2865
> (single octet Type=20
> field).  =20

Yes, sorry, I should have been more explicit.

> However, the Lior & Li proposal was for a larger
> Extended-Type=20
> space, and I presume that this would require code changes.
>=20
>> In combination with the tagging scheme (or something very similar)
>> you mentioned in a recent >message, the "VSA Zero" approach solves
>> this problem, as well.
>=20
> RFC 2865 states that more than one vendor-specific attribute can be
> included within a RADIUS attribute of Type 26.  However, I don't
> think it describes how vendor-specific attributes can be split across
> RADIUS attributes of Type 26.  One way to address this is via a
> tagging scheme.  I think the question is whether we'd want to
> *require* tags in each Extended attribute, or not.=20

I'd say yes -- the semantic difficulties w/the tagging scheme in RFC =
2868 are I think in some part due to the false economy of trying to make =
the Tag field "disappear" if unused.  Things would have been much had =
the Tag field been a real field in the attributes.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Wed, 16 Aug 2006 21:48:20 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Questions on RADIUS Extended attributes
Date: Wed, 16 Aug 2006 14:48:08 -0700

>Therefore, my proposal is the following.  L2 is unnecessary, so we
>drop it.  The format is now:
>
>   T L T2 data...
>
>   We still have the problem of data length, though.  We can solve this
>by saying "if T2 is zero, then the data for this extended type is
>concatenated to the data for the previous one".  e.g.
>
>   T L T2 data1... T L 0000 data2...
>
>   The format of Extended-Type is now always 'T2 data...', which seems
>good to me.  The length of T2 is derived from from the lengths of the
>encapsulating Extended-Type attribute.  And the concatatenation can
>only occur if the first Extended-Type attribute has L=255, and even
>then, only if the next Extended-Type attribute exists, AND has T2 != 0000.
>
>   I hope that's a little clearer.

Yes. So your proposal looks like this, no?

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |            Extended-Type      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Value...
     +-+-+-+-+-+-+-+-+

     Type

        TBD  (not 26)

     Length

        >= 4

     Extended-Type

        Two octets.

        0:  Concatenation
       1-255:  Reserved
       255-65530: Allocated by IANA
       65531-65535:  Reserved

     Value

        0-251 octets (Length - 4).

     Only a single RADIUS Extended-Type attribute may be included within
     a RADIUS attribute of Type TBD.   Where the value of the Extended-Type
     field is zero (0), this indicates that the content of the value field 
is to
     be concatenated with the contents of the value field in the previous
     attribute of Type TBD.

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

Delivery-date: Wed, 16 Aug 2006 21:38:27 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Questions on RADIUS Extended attributes
Date: Wed, 16 Aug 2006 14:37:53 -0700

>I know that a couple of people stated that preference on the list recently, 
>but without any technical justification.

I think there may have been some concern about compatibility with existing 
RADIUS servers, since the format proposed in the Lior & Li draft utilized a 
larger Extended-Type field (32 bits) than was suggested for the VSA format 
in RFC 2865.

>Is it really necessary to do more than double the number of standard 
>attributes?  That is what the >VSA approach would do, without requiring 
>code changes...

I think the implicit assumption here is that the VSA approach (Vendor-Id of 
0) would utilize the VSA format described in RFC 2865 (single octet Type 
field).   However, the Lior & Li proposal was for a larger Extended-Type 
space, and I presume that this would require code changes.

>In combination with the tagging scheme (or something very similar) you 
>mentioned in a recent >message, the "VSA Zero" approach solves this 
>problem, as well.

RFC 2865 states that more than one vendor-specific attribute can be included 
within a RADIUS attribute of Type 26.  However, I don't think it describes 
how vendor-specific attributes can be split across RADIUS attributes of Type 
26.  One way to address this is via a tagging scheme.  I think the question 
is whether we'd want to *require* tags in each Extended attribute, or not.

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

Delivery-date: Wed, 16 Aug 2006 18:33:33 +0000
Content-class: urn:content-classes:message
Subject: RE: Define some new NAS-Port-Type
Date: Wed, 16 Aug 2006 11:33:10 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Congdon, Paul T \(ProCurve\)" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "CTO YAN Renxiang" <[email-masked]>, <[email-masked]>, <[email-masked]>

Congdon, Paul T (ProCurve) <> supposedly scribbled:

> People do use RADIUS to authenticate infrastructure devices as well

True, but the conjunction of the terms "infrastructure" & "Personal Area =
Network" has me confused.  Would you mind elaborating?

>=20
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Bernard Aboba
>> Sent: Tuesday, August 15, 2006 7:30 PM
>> To: 'CTO YAN Renxiang'; [email-masked]; [email-masked]
>> Subject: RE: Define some new NAS-Port-Type
>>=20
>> Typically a NAS-Port-Type value is only needed for access
>> technologies that may need to use RADIUS.  I don't think that
>> 802.15 fits into that category (though lots of other wireless
>> technologies do).=20
>>=20
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of CTO YAN Renxiang
>> Sent: Tuesday, August 01, 2006 10:13 PM
>> To: Bernard Aboba; [email-masked]; [email-masked]
>> Subject: re: Define some new NAS-Port-Type
>>=20
>> Hi, David and Bernard,
>>=20
>> Thanks for your comments.
>>=20
>> I think stating as work in progress in Informative Reference is ok.
>> Many RFC documents are also written in this way, as follows,
>>=20
>> 5.2 Informative References
>>=20
>> [802.20]	Mobile Broadband Wireless Access (MBWA), IEEE
>> Standard, Work
>> in Progress.
>>=20
>> [802.22]	Wireless Regional Area Networks (WRAN), IEEE
>> Standard, Work
>> in Progress.
>>=20
>> How do you think about that?
>>=20
>> BTW, do you think we need to define a NAS-Port-Type for 802.15
>> (WPAN) also?=20
>>=20
>> Renxiang
>>=20
>>=20
>>> -----=D4=AD=CA=BC=D3=CA=BC=FE-----
>>> =B7=A2=BC=FE=C8=CB: Bernard Aboba [mailto:[email-masked]]
>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA8=D4=C22=C8=D5 9:04
>>> =CA=D5=BC=FE=C8=CB: [email-masked]; CTO YAN Renxiang; =
[email-masked]
>>> =D6=F7=CC=E2: RE: Define some new NAS-Port-Type
>>>=20
>>>=20
>>>> I understand the
>>>> difficulty of referencing draft IEEE standards, so I'm not sure
>>>> exactly what to suggest as an alternative.
>>>=20
>>> I think they can reference IEEE 802 work-in-progress as an
>>> Informative Reference.=20
>>>=20
>>>=20
>>>=20
>>=20
>> --
>> 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/>
>>=20
>>=20
>> --
>> 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/>

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Wed, 16 Aug 2006 17:27:33 +0000
Content-class: urn:content-classes:message
Subject: RE: Define some new NAS-Port-Type
Date: Wed, 16 Aug 2006 12:26:54 -0500
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "CTO YAN Renxiang" <[email-masked]>, <[email-masked]>, <[email-masked]>

People do use RADIUS to authenticate infrastructure devices as well

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Tuesday, August 15, 2006 7:30 PM
> To: 'CTO YAN Renxiang'; [email-masked]; [email-masked]
> Subject: RE: Define some new NAS-Port-Type
>=20
> Typically a NAS-Port-Type value is only needed for access=20
> technologies that may need to use RADIUS.  I don't think that=20
> 802.15 fits into that category (though lots of other wireless=20
> technologies do).=20
>=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of CTO YAN Renxiang
> Sent: Tuesday, August 01, 2006 10:13 PM
> To: Bernard Aboba; [email-masked]; [email-masked]
> Subject: re: Define some new NAS-Port-Type
>=20
> Hi, David and Bernard,
>=20
> Thanks for your comments.
>=20
> I think stating as work in progress in Informative Reference=20
> is ok. Many RFC documents are also written in this way, as follows,
>=20
> 5.2 Informative References
>=20
> [802.20]	Mobile Broadband Wireless Access (MBWA), IEEE=20
> Standard, Work
> in Progress.
>=20
> [802.22]	Wireless Regional Area Networks (WRAN), IEEE=20
> Standard, Work
> in Progress.
>=20
> How do you think about that?
>=20
> BTW, do you think we need to define a NAS-Port-Type for=20
> 802.15 (WPAN) also?=20
>=20
> Renxiang
>=20
>=20
> > -----=D4=AD=CA=BC=D3=CA=BC=FE-----
> > =B7=A2=BC=FE=C8=CB: Bernard Aboba [mailto:[email-masked]]
> > =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA8=D4=C22=C8=D5 9:04
> > =CA=D5=BC=FE=C8=CB: [email-masked]; CTO YAN Renxiang; =
[email-masked]
> > =D6=F7=CC=E2: RE: Define some new NAS-Port-Type
> >=20
> >=20
> > >I understand the
> > >difficulty of referencing draft IEEE standards, so I'm not
> > sure exactly
> > >what to suggest as an alternative.
> >=20
> > I think they can reference IEEE 802 work-in-progress as an=20
> Informative=20
> > Reference.
> >=20
> >=20
> >=20
>=20
> --
> 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/>
>=20
>=20
> --
> 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/>
>=20

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

Delivery-date: Wed, 16 Aug 2006 16:34:30 +0000
Content-class: urn:content-classes:message
Subject: RE: Possible Resolution to Issue 198:  Attribute Concatenation/Splitting
Date: Wed, 16 Aug 2006 09:34:18 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <> supposedly scribbled:

> I am wondering if the following approach to the
> concatenation/splitting problem with NAS-Filter-Rule might work:=20
>=20
> a.  Add a single octet Tag field:
>=20
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     =20
>     =20
>     =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =20
> Type      |    Length     |      Tag      |      String...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =20
>=20
> b.  Specify that a multiple NAS-Filter-Rule attributes with the same
> value of the Tag field represent a single rule and are to be
> concatenated when translating to Diameter NAS-Filter-Rule. =20
>=20
> c.  Prohibit reordering of NAS-Filter-Rule attributes.
>=20
> d. Suggest that ASCII values (e.g. '1'=3D0x31, etc.) be used in the =
tag
> field so they can be entered easily.=20

This sounds very similar to what was discussed in Montreal.  I think =
that this would work fine, and particularly well with the VSA method of =
extending the attribute space.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Wed, 16 Aug 2006 16:29:29 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on RADIUS Extended attributes 
Date: Wed, 16 Aug 2006 09:29:20 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Alan DeKok <> supposedly scribbled:

> "Bernard Aboba" <[email-masked]> wrote:
>> a. Do we want an Extended-Type field of two or four octets?  If it is
>> four octets, this would seem to imply that RADIUS attributes and
>> Diameter AVPs share the same type space.  Will this work?  If it is
>> two octets, we could reserve 65535 values within the existing
>> Diameter attribute space for RADIUS Extended-Type attributes. =20
>> Opinions solicited.=20
>=20
>   I think 2 octets is OK.  There are nowhere near 64k RADIUS
> attributes in existence today, even including VSA's.  So 64k would
> seem to be sufficient for a while. =20

A master of understatement ;-).  Actually, I suspect that another 256 =
would be more than enough, if there was a rational (or any) AAA =
development strategy in the IETF; probably even without one.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Wed, 16 Aug 2006 16:21:33 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on RADIUS Extended attributes
Date: Wed, 16 Aug 2006 09:21:17 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <> supposedly scribbled:

> At IETF 66, we discussed how to extend the RADIUS attribute space.=20
> The consensus in the room as well as on the WG mailing list seems to
> be to focus on extending the space only, not adding functionality,
> along the lines that Avi had proposed:  =20
>=20
> =
http://www.watersprings.org/pub/id/draft-lior-radius-attribute-type-exten=
sion-00.txt
>=20
> During IETF 66, there was some sentiment that the RADIUS Extended
> attribute should utilize a new RADIUS attribute value, rather than
> using a Vendor-Id value of zero (0) with the existing RADIUS VSA
> attribute (Type 26).=20

Hmm.  I don't remember any discussion like that at during the meeting, =
and searched in vain for mention of it in the draft minutes; I know that =
a couple of people stated that preference on the list recently, but =
without any technical justification.
 =20
>=20
> Taking that into account, find below a strawman proposal for what the
> Extended-Type attribute would look like.=20
>=20
> Some questions:
>=20
> a. Do we want an Extended-Type field of two or four octets?  If it is
> four octets, this would seem to imply that RADIUS attributes and
> Diameter AVPs share the same type space.  Will this work?  If it is
> two octets, we could reserve 65535 values within the existing
> Diameter attribute space for RADIUS Extended-Type attributes. =20
> Opinions solicited.=20

Is it really necessary to do more than double the number of standard =
attributes?  That is what the VSA approach would do, without requiring =
code changes...
  =20
>=20
> b.  Should the second length field include the Extended-Type field or
> not?=20
> If it is included and Extended-Type is 4 octets, then this implies
> that the Value field could only be 251 octets.  If the second length
> field doesn't include Extended-Type, it could be as long as 255
> octets, but then we'd need to allow Extended-Type attributes to be
> split among multiple RADIUS attributes. =20

In combination with the tagging scheme (or something very similar) you =
mentioned in a recent message, the "VSA Zero" approach solves this =
problem, as well.
 =20
>=20
> c. Should we allow multiple Extended-Type attributes to be placed
> inside a single RADIUS attribute? This is OK for RADIUS VSAs, is
> there an issue here?=20

Ditto.
=20
...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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

Envelope-to: [email-masked]
Delivery-date: Wed, 16 Aug 2006 15:35:00 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Questions on RADIUS Extended attributes 
cc: [email-masked]
Date: Wed, 16 Aug 2006 11:26:25 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> > The issue of data length can be addressed, for example, by reserving
> > 0 for "concatenate values to the end of the previous Extended-Type".
> > This allows the values to extend past 251 octets, and makes the format
> > of the attribute constant.
> 
> Please elaborate.  What field contains the "zero" that indicates
> concatenation?  Do I understand correctly that this is a mechanism for
> fragmentation and reassembly?  Some additional detail would be helpful.

  The proposed format for the Extended-Type is (in short)

  T L T2 L2 data...

  Where T and L are the RADIUS type and length.  T2 is the proposed 2
or 4 octet extended type, and L2 is the length of the encapsulated data.

  Since we have L, L2 isn't strictly necessary.  But even with L2, the
length of the data is limited to less than 253 bytes, which is a
problem for long data strings.  We could fix the data length problem
by allow L2 to be larger than 253, and relying on that to indicate
concatenation.

  e.g.

  T L T2 L2 data1... T L data2...

  Where L2 is the length of data1 + data2.  However, this makes
parsing the Extended-Type problematic, as the data in Extended-Type is
sometimes 'T2 L2 data', and sometimes just 'data..'  I've run into
these issues in the past, and they're awkward and problematic to deal
with.

  Therefore, my proposal is the following.  L2 is unnecessary, so we
drop it.  The format is now:

  T L T2 data...

  We still have the problem of data length, though.  We can solve this
by saying "if T2 is zero, then the data for this extended type is
concatenated to the data for the previous one".  e.g.

  T L T2 data1... T L 0000 data2...

  The format of Extended-Type is now always 'T2 data...', which seems
good to me.  The length of T2 is derived from from the lengths of the
encapsulating Extended-Type attribute.  And the concatatenation can
only occur if the first Extended-Type attribute has L=255, and even
then, only if the next Extended-Type attribute exists, AND has T2 != 0000.

  I hope that's a little clearer.

  My main reason for getting rid of L2 is that allowing it to be
larger than L is a nightmare.  i.e. the encapsulated structure
indicates it's larger than the structure that is performing the
encapsulation.  That's a recipe for buffer overflows, bugs,
incompatibilities, etc.  I'm rating developer efficiency as a higher
priority than network efficiency.  I have *rarely* seen packet size be
a problem in RADIUS, and I've seen many bugs and incompatibilities in
implementations.

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

Delivery-date: Wed, 16 Aug 2006 15:01:21 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on RADIUS Extended attributes 
Date: Wed, 16 Aug 2006 11:01:05 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Alan DeKok writes...

> The issue of data length can be addressed, for example, by reserving
> 0 for "concatenate values to the end of the previous Extended-Type".
> This allows the values to extend past 251 octets, and makes the format
> of the attribute constant.

Please elaborate.  What field contains the "zero" that indicates
concatenation?  Do I understand correctly that this is a mechanism for
fragmentation and reassembly?  Some additional detail would be helpful.

>   If we don't include a length, no.

I think if you explain the suggestion above, it will also answer my
questions on this statement.

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

Envelope-to: [email-masked]
Delivery-date: Wed, 16 Aug 2006 14:29:01 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Questions on RADIUS Extended attributes 
cc: [email-masked]
Date: Wed, 16 Aug 2006 10:20:21 -0400
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> a. Do we want an Extended-Type field of two or four octets?  If it is four 
> octets, this would seem to imply that RADIUS attributes and Diameter AVPs 
> share the same type space.  Will this work?  If it is two octets, we could 
> reserve 65535 values within the existing Diameter attribute space for RADIUS 
> Extended-Type attributes.   Opinions solicited.

  I think 2 octets is OK.  There are nowhere near 64k RADIUS
attributes in existence today, even including VSA's.  So 64k would
seem to be sufficient for a while.

> b.  Should the second length field include the Extended-Type field or not?  
> If it is included and Extended-Type is 4 octets, then this implies that the 
> Value field could only be 251 octets.  If the second length field doesn't 
> include Extended-Type, it could be as long as 255 octets, but then we'd need 
> to allow Extended-Type attributes to be split among multiple RADIUS 
> attributes.

  I would say the length field does not need to be included.

  The issue of data length can be addressed, for example, by reserving
0 for "concatenate values to the end of the previous Extended-Type".
This allows the values to extend past 251 octets, and makes the format
of the attribute constant.

> c. Should we allow multiple Extended-Type attributes to be placed inside a 
> single RADIUS attribute? This is OK for RADIUS VSAs, is there an issue here?

  If we include a length, yes.  We should then say that all
implementations MUST support it.

  If we don't include a length, no.

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

Delivery-date: Wed, 16 Aug 2006 03:20:50 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Questions on RADIUS Extended attributes
Date: Tue, 15 Aug 2006 20:20:36 -0700

At IETF 66, we discussed how to extend the RADIUS attribute space.  The 
consensus in the room as well as on the WG mailing list seems to be to focus 
on extending the space only, not adding functionality, along the lines that 
Avi had proposed:

http://www.watersprings.org/pub/id/draft-lior-radius-attribute-type-extension-00.txt

During IETF 66, there was some sentiment that the RADIUS Extended attribute 
should utilize a new RADIUS attribute value, rather than using a Vendor-Id 
value of zero (0) with the existing RADIUS VSA attribute (Type 26).

Taking that into account, find below a strawman proposal for what the 
Extended-Type attribute would look like.

Some questions:

a. Do we want an Extended-Type field of two or four octets?  If it is four 
octets, this would seem to imply that RADIUS attributes and Diameter AVPs 
share the same type space.  Will this work?  If it is two octets, we could 
reserve 65535 values within the existing Diameter attribute space for RADIUS 
Extended-Type attributes.   Opinions solicited.

b.  Should the second length field include the Extended-Type field or not?  
If it is included and Extended-Type is 4 octets, then this implies that the 
Value field could only be 251 octets.  If the second length field doesn't 
include Extended-Type, it could be as long as 255 octets, but then we'd need 
to allow Extended-Type attributes to be split among multiple RADIUS 
attributes.

c. Should we allow multiple Extended-Type attributes to be placed inside a 
single RADIUS attribute? This is OK for RADIUS VSAs, is there an issue here?

==================================================
Proposed Extended-Type Attribute Format

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |            Extended-Type
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Extended-Type           |    Length2    |    Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         TBD  (not 26)

      Length

         >= 7

      Extended-Type

         Four octets.

         Values <= 255: Reserved
         Values > 255:  To be allocated by IANA

      Length2

         0-255 (doesn't include the Extended-Type field)

      Value

         0 or more octets as defined by the Length2 field.

      More than one RADIUS Extended-Type attribute may be included within
      a RADIUS attribute of Type TBD.  If more than one RADIUS attribute
      of Type TBD is included, then they are to be concatenated (allowing
      an Extended-Type attribute to be split between two RADIUS attributes).

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

Delivery-date: Wed, 16 Aug 2006 02:59:30 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Possible Resolution to Issue 198:  Attribute Concatenation/Splitting
Date: Tue, 15 Aug 2006 19:59:16 -0700

I am wondering if the following approach to the concatenation/splitting 
problem with NAS-Filter-Rule might work:

a.  Add a single octet Tag field:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |      Tag      |      String...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

b.  Specify that a multiple NAS-Filter-Rule attributes with the same value 
of the Tag field represent a single rule and are to be concatenated when 
translating to Diameter NAS-Filter-Rule.

c.  Prohibit reordering of NAS-Filter-Rule attributes.

d. Suggest that ASCII values (e.g. '1'=0x31, etc.) be used in the tag field 
so they can be entered easily.

---------------------------------------------------------------------
Issue 198: Attribute Concatenation/Splitting
Submitter names: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: June 30, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00640.html
Document: Filter-00
Comment type: 'T'echnical
Priority: S
Section: 2 and 4
Rationale/Explanation of issue:
Section 2 currently says that "Where more than one NAS-Filter-Rule
attribute is included in a RADIUS packet, the attributes MUST be
consecutive and it is assumed that the attributes are to be
concatenated to form a single filter list."

I guess this means that a single long rule can be split into multiple
NAS-Filter-Rule attributes? And a single NAS-Filter-Rule attribute
could contain pieces of multiple rules? If so, I'd recommend
separating the individual rules somehow. In the current version of
NAS-Traffic-Rule each individual rule ends with LF, making it easy to
determine where one rule ends and another one begins. I'd suggest
adopting this same convention for RADIUS NAS-Filter-Rule.

This concatenation/splitting has also implications for Diameter
translation (Section 4): AVPs coming from Diameter side may have to be
split to several RADIUS attributes (and rule delimiters added), and
attributes coming from RADIUS side have to be concatenated/split to
Diameter AVPs (and rule delimiter removed).
[Pasi Eronen]
>BTW, do the same issues also apply to the NAS-Filter-Rule AVP defined in 
>RFC 4005?

As far as I can tell, no: in RFC 4005, a single AVP always contains
one complete rule (long rules are not split into multiple AVPs, and
one AVP never contains multiple rules).
[Rajith R]
AFAIK, splitting & concatenation are necessitated by the 255 byte limit
for RADIUS attributes. So it would be better to split at 253 byte (for
the attribute payload) boundary rather than LF or some other attribute
specific delimiter,
I think this would have the advantage of
* same & simple logic for concatenation/splitting of any suitable RADIUS
attribute of length > 255
* packing efficiency in the message, though not a principal concern
[Pasi Eronen] This simple concatenation/splitting works when you need to 
include a
single, potentially long data item (e.g. EAP-Message) in a RADIUS
message. But it gets complex if you need to include multiple,
potentially long data items of the same type (in this case, individual
filter rules) and you need to maintain the boundaries between the
individual data items somehow.

In particular, if we decide to support individual filter rules longer
than 253 characters, it looks like a RADIUS-to-Diameter translation
agent will need code specific to NAS-Filter-Rule no matter how we
choose to do the concatenation/splitting on the RADIUS side. The
difference is just how complex that code needs to be (e.g., is it
sufficient just to recognize "LF", or understand the full filter
rule syntax).

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

Delivery-date: Wed, 16 Aug 2006 02:30:01 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'CTO YAN Renxiang'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Define some new NAS-Port-Type
Date: Tue, 15 Aug 2006 19:29:48 -0700

Typically a NAS-Port-Type value is only needed for access technologies =
that
may need to use RADIUS.  I don't think that 802.15 fits into that =
category
(though lots of other wireless technologies do).=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =
On
Behalf Of CTO YAN Renxiang
Sent: Tuesday, August 01, 2006 10:13 PM
To: Bernard Aboba; [email-masked]; [email-masked]
Subject: re: Define some new NAS-Port-Type

Hi, David and Bernard,

Thanks for your comments.

I think stating as work in progress in Informative Reference is ok. Many =
RFC
documents are also written in this way, as follows,

5.2 Informative References

[802.20]	Mobile Broadband Wireless Access (MBWA), IEEE Standard, Work
in Progress.

[802.22]	Wireless Regional Area Networks (WRAN), IEEE Standard, Work
in Progress.

How do you think about that?

BTW, do you think we need to define a NAS-Port-Type for 802.15 (WPAN) =
also?=20

Renxiang

> -----=D4=AD=CA=BC=D3=CA=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Bernard Aboba [mailto:[email-masked]]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA8=D4=C22=C8=D5 9:04
> =CA=D5=BC=FE=C8=CB: [email-masked]; CTO YAN Renxiang; =
[email-masked]
> =D6=F7=CC=E2: RE: Define some new NAS-Port-Type
>=20
>=20
> >I understand the
> >difficulty of referencing draft IEEE standards, so I'm not=20
> sure exactly
> >what to suggest as an alternative.
>=20
> I think they can reference IEEE 802 work-in-progress as an=20
> Informative=20
> Reference.
>=20
>=20
>=20

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

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

Delivery-date: Fri, 11 Aug 2006 20:00:47 +0000
Content-class: urn:content-classes:message
Subject: Draft of RADEXT WG Minutes for IETF-66
Date: Fri, 11 Aug 2006 15:59:55 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

This is the draft RADEXT WG session minutes, as submitted for the
IETF-66 Proceedings.

Please review these minutes and reply to the list with any error or
omissions.  Thanks!

IETF-66 RADEXT WG Meeting Minutes
9:00 AM - 11:30 AM
Monday, July 10, 2006
Montreal, Quebec, Canada

Note takers: Mauricio Sanchez, David Mitton.  Edited by: David Nelson.

1. Agenda bashing: no changes proposed

2. Document status (Bernard)

Since last IETF eight (almost nine) documents are completed

3. NAS-Traffic-Rules, NAS-Filter-Rule (Mauricio)

Comment (Glen Z): You can always parse the beginning of a rule.  The end
is harder to recognize. Suggest that you enhance the Diameter filter
rules, as it's not that good.

Comment (Dave N): Suggest that we don't pack multiple rules into one
attribute.

Comment (Bernard A): We need to clarify the issues.

Comment (Glen Z): With NAS-Traffic-Rule you will have to translate
strings.

Answer: We'll we have a proposal coming.

Comment (Dave N): 3GPP has already deployed Diameter, and requested the
NAS-Filter-Rule capability in RADIUS.  We need to meet that requirement.

Issue:  RADEXT Issue 170 --  Precedence and order of server-provided
rules to local NAS-provide rules.

Comment (Bernard A): This is an issue if NASes have local rules and
policies.

This has been around forever.

Comment (Dave N): We are about policy provisioning, not policy
definition.

Comment: The principle should be interoperability of features.

Poll (Bernard A): Who thinks the NAS-Filter-Rules draft is ready last
call?=20

    Response: 1

Poll (Bernard A) Who thinks the NAS-Traffic-Rules draft is ready for
last call?

    Response: 0

Comment (Bernard A): We all need to read and submit comments so we can
move forward.

4. Pre-Authentication AAA Requirements (Yoshiro Ohba)

Yoshiro presented two basic requirements identified in the IETF-65 BoF.

Yoshiro presented technical issues related to pre-authentication.

There is a dependency between moving between pre-auth and auth states
and key caching.

Comment (Bernard A.): Key caching was addressed 802.11i and it was
decided that key caching was not going to be managed individually by
user, it is a global parameter.  Given it's a global parameter its
there's no need to control via RADIUS.  Each system is configured with
key cache timeout.

Comment (Nancy C-W): Says that 802.11 revisiting topic and considering
to use something else other than Session-Timeout as a means to signal
when to expire keys.  In 802.11i, there is no notion of session
lifetime, just a key lifetime.

Comment (Bernard A): Asserts that the meaning of the Session-Timeout
attribute is too overloaded.=20

Comment (Nancy C-W): Yes this is an issue.  Says that 802.11r has no
notion of pre-authentication.  We are looking at making this more
explicit but it's not done.

Comment (Pat C): Points out that there is no signaling between
authenticator and server about the pre-auth state.  You are trying to do
some sort of signaling on the transition from Pre-Auth to active?  It's
not clear that these events exist, and they are not RADIUS issues.

Comment (Bernard A): Points out that no accounting is generated prior to
session setup.  Accounting is used to know when session starts and ends.
We need to ask implementers what they do.  This is discussed in RFC
3780.

Comment (Pat C): Not sure this is practical for wireless roaming.
Concerned that a client may pre-auth with many APs and if it moves just
a bit...

Comment: Calling-Station-ID - What value shall it take on with
pre-authentication?

Yoshiro presents a summary:

Drives home message that pre-auth requires a lot of work in EAP and AAA
layers.  Most work to be done in HOAKEY.

Comment: Someone asks scope of HOAKEY.

Answer: HOAKEY will define requirements that will need work in
respective working groups.

5. WLAN Attributes (Bernard)

Bernard presented the notion of a pre-auth specific timeout attribute.

Comment (Yoshiro O): Asks whether the absence of pre-auth attribute
should be considered always as a normal session?

Answer (Bernard A):  It depends.  The presence of the attribute in an
Access-Request means it is a pre-auth session.  However, when absent,
it's not always pre-auth.  Need to use RFC3580 behavior.

Comment: Asks about key cache lifetime?

Answer (Bernard A): Thinks that 802.11i drives the lifetime based on the
session-timeout value.

Comment (Dorothy S): Validates Bernard's assertion; states that work on
wireless attributes is good to clear up gaps of understanding.

Bernard asks how to work with other standards groups on open
questions/issues. =20

Comment (Dorothy S): Responds that groups should work with liaison
representatives by generating lists of questions/issues.

Comment (Dan R): Points out that the discussion a number of times this
morning has been topics out of scope of RADEXT, e.g. data format for
Diameter's filter rule, 802.11i discussion.  Dan feels we need figure
out how not to talk about issues that other groups need to resolve.

Comment (Pat C): Looked at RFC 3780. Accounting is not required to go to
same server as Authentication.

Comment (Bernard A): If you want state, you setup a server that keeps
state that both Authentication and Accounting talk to.

Comment (Pat C): Does this presume a common backend?

Answer (Bernard A): Yes.

Bernard presented the SSID attribute.

6. RADIUS Attribute Design Guidelines (Dave N. for Greg W.)

Dave presented an overview of document.

Dave presented the open issues.

Comment (Glen Z): Wondering why use by an independent SDO is an issue.
Glen asserts that most SDOs are just looking for IANA code-point
numbers.  This could be solved by giving blanket permission.  Neither
Dave nor Glen believe this is good practice.

Dave presented RADIUS attribute guidelines (section 7 of the draft).

Comment (Glen Z):  Believes all problems have been solved over the
years.  Dave asks in which documents problems have been solved. Glenn
feels that problems should be solved just once, if there are existing
solutions elsewhere, they should be deprecated.  There should be only
one solution.

Comment (Dan R):  Questions whether this document is to be a BCP.  Dave
says yes, that is the plan.

Comment (Dan R):  Says same problem happened with MIBs.  The felling
there was that a guidelines document would make it easier for new people
to ramp up on standards development.

Comment (Glen Z):  Asserts that solutions exist in a protocol called
Diameter.  He points out that most of the problems in design guidelines
were fundamental problems addressed in Diameter.  Sees no need to
re-solve problems that have already been solved once.

Comment (Bernard A):  Points out that the guidelines document should
strictly be about BCP, not defining new extensions to RADIUS. =20

Dave describes examples of where several new document rely on complex
data structures, such as GEOPRIV, where having design guideline document
would be (have been) beneficial.=20

Dave opens up discussion to group on how to move forward.

Comment (Bernard A):  Points out that design guidelines document has
taken on two hard problems, BCP and designing new RADIUS protocol
extensions (i.e. extended attributes), that will make it difficult to
make progress.  He suggests that problems be split up into two
individual documents. =20

Comment (Glen Z):  Agrees with Bernard's suggestion to split up
document.  Having a BCP would be beneficial.

Comment (Hannes T):  Says that time is of essence for this document as
SDOs continue to make progress and they may use non-optimal designs.=20

Dave asks group to consider the suggestion to remove any references to
extended attributes. Extended attributes would be treated in separate
effort.

There seems to be rough consensus in the room. We will confirm this
direction on the WG mailing list.=20

7. RADIUS Attribute Space Exhaustion (Bernard)

Bernard presented summary of RADIUS attribute exhaustion issues.

Bernard presented possible outcomes of the discussion.

Bernard opened up the discussion to floor to discuss whether solution is
desired, where work should be performed, and whether there any other
problems to solve.

Comment (Pat C):  Believes that RADIUS should not be used for new
applications, but extensions should be allowed for existing
applications.  Doesn't care whether RADEXT tackles problem.

Comment (Dave N):  Believes the problem should be solved.  Believes that
SDOs and implementers will continue to use RADIUS even if IETF stops
work on it.  Believes that the attribute exhaustion solution work should
be done in RADEXT.  Unsure whether there are any additional problems
that need work. =20

Comment (Dave N):  Puts out radical suggestion of reclaiming blocks of
reserved but ill-defined attribute code-points, such as the experimental
or implementation-specific blocks.  Bernard says it needs to be
investigated.

Comment (Glen Z): Says that problems have already been solved (i.e.
Diameter).  He's OK with solving problem, again.  However, does not feel
RADIUS attribute space should be extended.  Feels RADEXT is the right
place to do the work, if other solutions are thrown out.=20

Comment: Believes that attribute space should be extended, RADEXT is the
right place, and does believe extended attributes is the only problem.

Comment (Glen Z): Disagrees with Dave N. The IETF has more power to stop
people from doing work than we think we do.  The SDOs use the IETF to
talk to each other and standardize interoperation. If there is no RFC,
this will challenge them.

Comment: (Pasi E): Repeats Glen's claim that problem has already been
solved. However, feels usage of vendor-specific attributes offers an
infinite space.

Comment: Points out that allowing on certain applications to use RADIUS
and not

Bernard does straw poll of group on three questions:

Is the problem worth solving?

    13 in favor, 6 against

Is RADEXT the right place to do the work?

    18 in favor, 0 against

Should the extended attribute ID space be the only problem to be solved?

    6 in favor, 3 against

We will confirm this rough consensus on the WG mailing list.

Bernard recaps existing proposals.

8. Extended RADIUS Attributes (Bernard A. for Barney W.)

Bernard presented the motivation for this work.=20

Bernard presented usage of Diameter AVP format as the extended RADIUS
Attribute format.

Bernard opens up to the floor for comments.

Comment (Glen Z): Mapping Diameter AVP formats in RADIUS brings up the
RADIUS PDU length problems.

Comment (Dave M): Yes, maybe it is a bad idea in general.  But it may
work for some things.  I think we should start saying things like "This
feature is limited, and if that's a problem, use something else, i.e.
Diameter".

Comment (Dave M): I like the characterization of the issues.  This
provides a good basis for tradeoffs.  We need to make decisions and
perhaps say we don't do some of it.

Comment (Dave N): This draft is proposing solutions rather than just
hand-waving.  Asserts that the backbone of RADEXT will be tested on
whether to address these problems.

Comment (Glen Z): Points out that entire network will have to be
upgraded to support Barney's draft.  Questions why it would be easier to
force a RADIUS forklift upgrade than going to Diameter.

Comment (Dave N): Asks for opinions from RADIUS server vendors.
Questions what server vendor will support all functionality.

Comment (Bernard A): Points out the fundamental change this draft would
have to the RADIUS data-dictionary.  We'd be nearly 75% of the way to
Diameter if this draft is approved.

Comment (Yoshiro O):  Believes RADIUS should remain simple and not take
on Diameter like parsing.

Comment (Joe S): Re-iterates that this draft takes RADIUS nearly all the
way to Diameter.  Agrees with Glen that this is not good. =20

Comment (Glen Z): It's still possible to do some grouping using tags.

Comment (Dave N): Asks the group whether group feels that the RADIUS
tagging mechanism is sufficient for all attribute grouping?

Bernard does straw poll:

How many people favor addressing extended attributes using limited
solution proposed by Lior?

    8 in favor, 1 against

This seems to be a solid consensus of the room.  We'll verify this on
the WG mailing list.

9. Issues & Fixes (Bernard for Alan DeKok)

Bernard presented a summary.

Not much discussion.  We need to get more people to read the draft and
comment on the list.

10. RADIUS Attribute for Management Authorization (Dave N.)

Dave presented the background and motivation.

Dave presented current attribute proposals.

Dave asks group whether document is ready for adoption as a WG work
item?

Bernard asks how many people have read document?

  One person in the room has.

The obvious outcome is that additional people need to read document and
comment on the list.

11. GEOPRIV (Hannes T.)

Hannes described the status of GEOPRIV work.

Many changes between the current and previous version.  Open issue on
encoding of location attributes, split complex attributes into two,
wrong references corrected and lot of cleanup work.

Bernard asks how work should progress towards completion, given it's
been around so long.  Decided that next step is that when document goes
last call in GEOPRIV that RADEXT should also review document from a last
call perspective.  Bernard suggests that RADEXT group submit issues
prior to GEOPRIV last call.

12. ISMS WG requirements for RADIUS (Dave N.)

Dave described motivation for Authorize Only operations.

Dave described motivation for an Asserted Identity.

Comment (Hannes T): ISMS requirements seem similar to requirements he's
hearing in other groups. Seems similar to the SIP problem.  Should look
at that.

Comment (Dave N): ISMS is interested in RADIUS because it integrates
something people already have.

Comment (Bernard A):  Points out that the document is making a leap by
integrating technologies like Kerberos and RADIUS.  Questions how these
technologies will be re-conciliated. =20

Answer (Dave N):  Responds that Jeff H. (Kerberos WG Chair) believes
that authentication and authorization services should be split.  In his
mind, the authentication and authorization services are/should be
decoupled and independent. =20

Comment (Bernard A): Curious to hear whether the security considerations
hve been investigated thoroughly.

Comment (Bernard A):  Points out that ISMS requirements seem to violate
basic key distribution principles, feels it's very ad-hoc, and changes
Kerberos in a fundamental way. Kerberos tickets are bound to
capabilities. Bernard would like agreement from the Kerberos WG before
ratifying such a fundamental change.

Comment (Dave N): This comes from specific deployment requirements in
ISMS, and this situation is not an integration of Kerberos and RADIUS.

Comment: Kerberos does have optional authorization fields, some may be
used or not.  This should be looked at carefully.  Don't know if anyone
does that....

Comment (Joe S): Agrees that additional thought is necessary.

Comment (Hannes T): Questions the viability of splitting authentication
and authorization services, given that most technologies bind
authentication and authorization together.  SAML has similar mechanisms.

Comment (Dave N): Will take this feedback to ISMS WG and see how they
wish to proceed.

13. Wrap-up/final comments

Comment (Glen Z): Would like the crypto-agility work item to be
clarified. What is the problem, the issues, etc.?   The WG should decide
to make this into a formal work item, if that is deemed necessary.

Answer (Dave N): It is already a WG milestone, but we should look at
whether charter language, scope, etc. also needs revision.

End of the meeting.

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

Delivery-date: Wed, 02 Aug 2006 05:13:24 +0000
content-class: urn:content-classes:message
Subject: re: Define some new NAS-Port-Type
Date: Wed, 2 Aug 2006 13:12:40 +0800
From: "CTO YAN Renxiang" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi, David and Bernard,

Thanks for your comments.

I think stating as work in progress in Informative Reference is ok. Many =
RFC documents=20
are also written in this way, as follows,

5.2 Informative References

[802.20]	Mobile Broadband Wireless Access (MBWA), IEEE Standard, Work in =
Progress.

[802.22]	Wireless Regional Area Networks (WRAN), IEEE Standard, Work in =
Progress.

How do you think about that?

BTW, do you think we need to define a NAS-Port-Type for 802.15 (WPAN) =
also?=20

Renxiang

> -----=D4=AD=CA=BC=D3=CA=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Bernard Aboba [mailto:[email-masked]]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA8=D4=C22=C8=D5 9:04
> =CA=D5=BC=FE=C8=CB: [email-masked]; CTO YAN Renxiang;=20
> [email-masked]
> =D6=F7=CC=E2: RE: Define some new NAS-Port-Type
>=20
>=20
> >I understand the
> >difficulty of referencing draft IEEE standards, so I'm not=20
> sure exactly
> >what to suggest as an alternative.
>=20
> I think they can reference IEEE 802 work-in-progress as an=20
> Informative=20
> Reference.
>=20
>=20
>=20

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

Delivery-date: Wed, 02 Aug 2006 01:04:54 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Define some new NAS-Port-Type
Date: Tue, 01 Aug 2006 18:04:13 -0700

>I understand the
>difficulty of referencing draft IEEE standards, so I'm not sure exactly
>what to suggest as an alternative.

I think they can reference IEEE 802 work-in-progress as an Informative 
Reference.

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

Delivery-date: Tue, 01 Aug 2006 15:22:47 +0000
Content-class: urn:content-classes:message
Subject: RE: Define some new NAS-Port-Type
Date: Tue, 1 Aug 2006 11:22:31 -0400
From: "Nelson, David" <[email-masked]>
To: "CTO YAN Renxiang" <[email-masked]>, <[email-masked]>

> A draft to define some new NAS-Port-Type for wireless
> http://www.ietf.org/internet-drafts/draft-yan-radext-port-type-00.txt
>=20
> Could you please comment on it?

The NAS-Port-Type assignments look OK.  I note, however, that the
informative references for 802.20 and 802.22 are to the WG web sites,
which don't seem to be an appropriate, stable reference.  For example,
will the site exist after the WG has closed?  I understand the
difficulty of referencing draft IEEE standards, so I'm not sure exactly
what to suggest as an alternative.

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

Delivery-date: Tue, 01 Aug 2006 15:03:24 +0000
content-class: urn:content-classes:message
Subject: Define some new NAS-Port-Type
Date: Tue, 1 Aug 2006 14:20:29 +0800
From: "CTO YAN Renxiang" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Bernard Aboba" <[email-masked]>

Hi,

A draft to define some new NAS-Port-Type for wireless=20
http://www.ietf.org/internet-drafts/draft-yan-radext-port-type-00.txt

Could you please comment on it?

Thanks and regards,

Renxiang

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