Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt

From: "Dave Nelson" <[email-masked]>
Date: Wed, 31 Dec 2008 18:25:01 -0500

Alfred Hoenes writes...

> RADIUS was not designed for that kind and degree of extensibility:
>  o  very limited message size, which was ...
>  o  adjusted for, and coupled with, unreliable UDP transport;
>  o  hence a very limited namespace for attributes was good enough;
>  o  poor security.

I think that accurately summarizes the challenges of "classic" RADIUS.

> I already have been beaten in the past for asking questions like:
>  -  do we really need RADIUS Extended Attributes ?

Well, in order to support the use of RADIUS in certain application areas
that developers want to pursue, the answer is apparently yes.  Additionally,
this mechanism addresses the potential exhaustion of the standard RADIUS
attribute ID number-space, which only includes values 1 - 192.

> -  do we really need new transports for RADIUS, RADSEC, etc. ?

Need?  Well, I think that for specialized uses, i.e. large aggregation-proxy
deployments, there is a case to be made.

> -  do we really need to maintain in the IETF
>    a legacy AAA protocol side by side with its successor ?

We used to not think so.  Time has somewhat changed that perception.  RADIUS
continues to be a popular vehicle for implementing AAA solutions.  I have
heard various reasons for this -- none of which are verified, simply
reported as "heard on the street":

-- RADIUS is simple; Diameter is complicated.

-- RADIUS is easy to extend (since there are very few formal extension
rules, almost anything is considered fair game).

-- High-quality open source implementations of RADIUS are freely available.

-- Diameter lacks similar open source support.

-- Diameter has some IPR statements filed against its RFCs.

-- RADIUS is preferred by enterprise and academic market segments.

-- Diameter is preferred by carrier market segments.

--
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, 31 Dec 2008 23:25:23 +0000
From: "Dave Nelson" <[email-masked]>
To: =?iso-8859-1?Q?'Alfred_H=CEnes'?= <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Wed, 31 Dec 2008 18:25:01 -0500

Alfred Hoenes writes...

> RADIUS was not designed for that kind and degree of extensibility:
>  o  very limited message size, which was ...
>  o  adjusted for, and coupled with, unreliable UDP transport;
>  o  hence a very limited namespace for attributes was good enough;
>  o  poor security.

I think that accurately summarizes the challenges of "classic" RADIUS.

> I already have been beaten in the past for asking questions like:
>  -  do we really need RADIUS Extended Attributes ?

Well, in order to support the use of RADIUS in certain application areas
that developers want to pursue, the answer is apparently yes.  Additionally,
this mechanism addresses the potential exhaustion of the standard RADIUS
attribute ID number-space, which only includes values 1 - 192.

> -  do we really need new transports for RADIUS, RADSEC, etc. ?

Need?  Well, I think that for specialized uses, i.e. large aggregation-proxy
deployments, there is a case to be made.

> -  do we really need to maintain in the IETF
>    a legacy AAA protocol side by side with its successor ?

We used to not think so.  Time has somewhat changed that perception.  RADIUS
continues to be a popular vehicle for implementing AAA solutions.  I have
heard various reasons for this -- none of which are verified, simply
reported as "heard on the street":

-- RADIUS is simple; Diameter is complicated.

-- RADIUS is easy to extend (since there are very few formal extension
rules, almost anything is considered fair game).

-- High-quality open source implementations of RADIUS are freely available.

-- Diameter lacks similar open source support.

-- Diameter has some IPR statements filed against its RFCs.

-- RADIUS is preferred by enterprise and academic market segments.

-- Diameter is preferred by carrier market segments.

--
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, 31 Dec 2008 22:51:05 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Wed, 31 Dec 2008 17:50:01 -0500

Hannes Tschofenig writes...

> To give you an example: Some time back when RFC 4675 was written it was
> state-of-the-art to define an attribute as:
>
> User-Priority-Table
>
>       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       |          String
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                    String
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                    String            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+>
>
> Where 'String' represented a customing encoding.

OK, let's examine this case a bit further.  The string value is composed as
follows:

      The String field is 8 octets in length and includes a table that
      maps the incoming priority (if it is set -- the default is 0) into
      one of eight regenerated priorities.  The first octet maps to
      incoming priority 0, the second octet to incoming priority 1, etc.

That is to say, it is an octet array -- a singly dimensioned array of
one-octet values.  That seems to me to be the very definition of the base
RADIUS data type "String".  I see no issue here.

> Today, the encoding of RFC 4675 might quite likely be different and 
> there is still a lot of possibility to argue around why this is still
> a good encoding.

I think you need to use a more complex example to illustrate your point.  An
octet array is a base data type.  To stretch the capabilities of "classic"
RADIUS, you need to attempt to encode the equivalent of C-language
structures, arrays of structures, structures of arrays, or structures of
structures.

> Whether the AAA server had to be updated in order to provide additional
> parsing capability depends a lot on the procedure how some of these
> attributes (and the values in them) get introduced into the system in
> the first place.

Well, that sounds like a user interface discussion, and thus out of scope
for RADIUS attribute design.  In the example you have given, the
User-Priority-Table can be treated by the AAA server as a fixed length
string of 8 octets.  Parsing may be required to enter the values into the
local database, but it's not required during authentication request
processing.

> In some systems they might be statically provisioned into a
> database and just retrieved without any additional logic...

Right.

>... and in other systems they would be dynamically generated and there
> might be some logic behind all this stuff. 

Perhaps.  What you are suggesting is that the user interface (UI) of the AAA
server might be replaced or supplemented by an application programming
interface (API).  Sure.  But that doesn't make the needs of the API a matter
of concern for the RADIUS on-the-wire message format.  That's all we
typically standardize, right?  The on-the-wire message format.

I think we need to apply a little judicious software architecture here.
While all sorts of auxiliary policy engines, data base interfaces, proxy
mechanisms, and other added value applications might be utilized by an AAA
server in "fetching" the values to populate attributes (AVPs), that doesn't
mean that those elements are part of the AAA server.  They may be packaged
as one deliverable for engineering or marketing reasons, but architecturally
they are logically separate entities.  If we always attempted to accommodate
complex systems, composed of multiple cooperating components, every time we
designed any component-level on-the-wire protocol in the IETF, we'd never
get anything accomplished.  I think it's a mistake to attempt to do that
here.

Now, there are other reasons that developers want to use complex attributes,
which don't hinge on system integration issues.  There are data objects that
a server may want to provision in a NAS that are inherently multi-part.  One
classic example is cryptographic keys, which often have a cipher-suite name,
a key name, a lifetime, and a scope that need to be attached to each key.
In that example there is no way to get around the need for structured data.
The question is how to achieve the structuring.

Is the existing tagging mechanism of the Extend Attribute draft sufficient?
I think the answer is yes, unless you want to have multiple keys that are
somehow associated with other attributes in the message (which would require
two distinct tag fields).  The question the RADEXT WG has tried to grapple
with is how complicated do we need to get?  What's the simplest attribute
encoding design that covers 80% of the likely use cases?  I, for one, am
willing to relegate the remaining 20% of use cases to Diameter-only
solutions. :-)  YMMV.

> Still, there is this tendency to label custom encoding (like the one
> from above) as really bad (by calling it "interoperability and deployment
> issues" or see the discussion in Section 2.1.4 of draft-ietf-radext-
> design-05.txt regarding "Complex Attributes and Security").

IMHO, the reason that these encodings are "bad" is two fold: (1) they do not
support the needs of data dictionary driven server implementations, and (2)
the technique for encoding them is ad-hoc (based on the personal design
choices of developers), which precludes any single set enhancements to data
dictionary driven server implementations which might allow them to deal with
a broad class of such 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, 31 Dec 2008 00:16:15 +0000
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Issue:  Data Type Advice
Date: Tue, 30 Dec 2008 16:15:41 -0800

--_f3d02cac-9e47-451c-b6af-146e5a7e9f24_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Yes=2C but what does that mean?  Designated Expert?  AAA Doctors?  Certai=
nly
> not IETF Last Call.

Why not?  RFC 3580 went through IETF last call=2C when it was included as
an Appendix in IEEE 802.1X-2004.=20

> > Also=2C as David notes=2C the document can be read as suggesting IETF r=
eview
> > of all SDO RADIUS attribute documents.
>=20
> What is the current practice with MIB Modules?  Are MIB Doctors assigned =
to
> assist non-IETF SDOs with authoring/reviewing their MIB Modules?  I bet D=
an
> Romascanu can enlighten us here.

RFC 4663 discusses this.  The short answer I believe is "yes".=20

--_f3d02cac-9e47-451c-b6af-146e5a7e9f24_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B Yes=2C but what does that mean?  Designated Expert?  AAA Doctors?  C=
ertainly<br>&gt=3B not IETF Last Call.<br><br>Why not?&nbsp=3B RFC 3580 wen=
t through IETF last call=2C when it was included as<br>an Appendix in IEEE =
802.1X-2004. <br><br>&gt=3B &gt=3B Also=2C as David notes=2C the document c=
an be read as suggesting IETF review<br>&gt=3B &gt=3B of all SDO RADIUS att=
ribute documents.<br>&gt=3B <br>&gt=3B What is the current practice with MI=
B Modules?  Are MIB Doctors assigned to<br>&gt=3B assist non-IETF SDOs with=
 authoring/reviewing their MIB Modules?  I bet Dan<br>&gt=3B Romascanu can =
enlighten us here.<br><br>RFC 4663 discusses this.&nbsp=3B The short answer=
 I believe is "yes". <br></body>
</html>=

--_f3d02cac-9e47-451c-b6af-146e5a7e9f24_--

--
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, 30 Dec 2008 23:40:30 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue:  Data Type Advice
Date: Tue, 30 Dec 2008 18:39:44 -0500

Bernard Aboba writes...

>=A0Right now, this section seems to suggest that SDO specifications =
utilizing
> existing RADIUS standard data types can avail themselves of IETF =
review.

Yes, but what does that mean?  Designated Expert?  AAA Doctors?  =
Certainly
not IETF Last Call.

> Also, as David notes, the document can be read as suggesting IETF =
review
> of all SDO RADIUS attribute documents.

What is the current practice with MIB Modules?  Are MIB Doctors assigned =
to
assist non-IETF SDOs with authoring/reviewing their MIB Modules?  I bet =
Dan
Romascanu can enlighten us here.

--
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, 30 Dec 2008 22:06:42 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>, "David B. Nelson" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: Issue:  Data Type Advice
Date: Tue, 30 Dec 2008 14:06:21 -0800

--_05b410fd-c509-4915-a81a-03f65da12539_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>   It is intended to encourage SDO specifications that re-use existing
> data types.  These specifications should *not* need IETF review.
>=20
>   Specifications that are SDO specific=2C and do *not* re-use existing
> types are SDO specific=2C and do not need IETF review.
>=20
>   Much of this is already in the document.  What can we do to clarify
> the text to avoid repeated questions?

I'd suggest that a revision of Section 1.1 is needed to clarify this.  Righ=
t now=2C
this section seems to suggest that SDO specifications utilizing existing
RADIUS standard data types can avail themselves of IETF review.  Also=2C
as David notes=2C the document can be read as suggesting IETF review
of all SDO RADIUS attribute documents. =20
=20
>   The most I would do is to provide horrific examples of what *not* to
> do.  i.e. putting arbitrary text strings into the "data" portion of a
> VSA (no... no VSA-type/VSA-length/VSA-data... just Vendor-Id/text..)

Describing why this is a bad idea would probably be useful.=20

--_05b410fd-c509-4915-a81a-03f65da12539_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B   It is intended to encourage SDO specifications that re-use existin=
g<br>&gt=3B data types.  These specifications should *not* need IETF review=
.<br>&gt=3B <br>&gt=3B   Specifications that are SDO specific=2C and do *no=
t* re-use existing<br>&gt=3B types are SDO specific=2C and do not need IETF=
 review.<br>&gt=3B <br>&gt=3B   Much of this is already in the document.  W=
hat can we do to clarify<br>&gt=3B the text to avoid repeated questions?<br=
><br>I'd suggest that a revision of Section 1.1 is needed to clarify this.&=
nbsp=3B Right now=2C<br>this section seems to suggest that SDO specificatio=
ns utilizing existing<br>RADIUS standard data types can avail themselves of=
 IETF review.&nbsp=3B Also=2C<br>as David notes=2C the document can be read=
 as suggesting IETF review<br>of all SDO RADIUS attribute documents.&nbsp=
=3B <br>&nbsp=3B<br>&gt=3B   The most I would do is to provide horrific exa=
mples of what *not* to<br>&gt=3B do.  i.e. putting arbitrary text strings i=
nto the "data" portion of a<br>&gt=3B VSA (no... no VSA-type/VSA-length/VSA=
-data... just Vendor-Id/text..)<br><br>Describing why this is a bad idea wo=
uld probably be useful. <br></body>
</html>=

--_05b410fd-c509-4915-a81a-03f65da12539_--

--
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, 30 Dec 2008 22:03:16 +0000
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Issue:  Data Type Advice
Date: Tue, 30 Dec 2008 14:02:51 -0800

--_9bc80fbb-1f0e-44b1-8b64-72acd47ac735_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> >   Does the data fit utilize ad-hoc extensions to the RADIUS data model=
=2C
> >   as outlined in below?  If so=2C it SHOULD be encapsulated in a RADIUS=
 VSA=20
> >   or an Extended Attribute [EXTENDED].
>=20
> While it may be feasible to group the ad-hoc extensions into a handful of
> categories=2C I'm not sure what benefit this provides.  Anything *other* =
than
> the (limited) standard data model is automatically an ad-hoc extension=2C
> right?  Do we need to provide examples?

Once the ad-hoc extensions are included in Appendix B=2C as is claimed in
Section 1=2C then several questions arise:

* Which=2C if any=2C of these additional data types are suitable for use in=
 Extended
Attributes?

* Which=2C if any=2C of these additional data types are appropriate for use=
 in=20
SDO-specific attributes?

* Which=2C if any=2C of these additional data types are appropriate for use=
 in VSAs?=20

Presumably=2C the answer to these questions might be different. =20

It is possible that some of these questions may be left to other documents=
=3B
for example=2C the Extended Attributes document could deal with the data
model appropriate to those attributes (incorporating Section A.1.2 from
Design Guidelines=2C for example). =20

It is also possible that some of these questions may be explicitly ruled ou=
t
of scope.  But if so=2C that needs to be made clear within Section 1.1=2C w=
hich
deals with Applicability.=20

--_9bc80fbb-1f0e-44b1-8b64-72acd47ac735_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B &gt=3B   Does the data fit utilize ad-hoc extensions to the RADIUS d=
ata model=2C<br>&gt=3B &gt=3B   as outlined in below?  If so=2C it SHOULD b=
e encapsulated in a RADIUS VSA <br>&gt=3B &gt=3B   or an Extended Attribute=
 [EXTENDED].<br>&gt=3B <br>&gt=3B While it may be feasible to group the ad-=
hoc extensions into a handful of<br>&gt=3B categories=2C I'm not sure what =
benefit this provides.  Anything *other* than<br>&gt=3B the (limited) stand=
ard data model is automatically an ad-hoc extension=2C<br>&gt=3B right?  Do=
 we need to provide examples?<br><br>Once the ad-hoc extensions are include=
d in Appendix B=2C as is claimed in<br>Section 1=2C then several questions =
arise:<br><br>* Which=2C if any=2C of these additional data types are suita=
ble for use in Extended<br>Attributes?<br><br>* Which=2C if any=2C of these=
 additional data types are appropriate for use in <br>SDO-specific attribut=
es?<br><br>* Which=2C if any=2C of these additional data types are appropri=
ate for use in VSAs? <br><br>Presumably=2C the answer to these questions mi=
ght be different.&nbsp=3B <br><br>It is possible that some of these questio=
ns may be left to other documents=3B<br>for example=2C the Extended Attribu=
tes document could deal with the data<br>model appropriate to those attribu=
tes (incorporating Section A.1.2 from<br>Design Guidelines=2C for example).=
&nbsp=3B <br><br>It is also possible that some of these questions may be ex=
plicitly ruled out<br>of scope.&nbsp=3B But if so=2C that needs to be made =
clear within Section 1.1=2C which<br>deals with Applicability. <br></body>
</html>=

--_9bc80fbb-1f0e-44b1-8b64-72acd47ac735_--

--
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, 30 Dec 2008 21:58:51 +0000
Date: Tue, 30 Dec 2008 22:58:19 +0100
From: Alan DeKok <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: [email-masked]
Subject: Re: Issue:  Data Type Advice

Dave Nelson wrote:
> Bernard Aboba writes...
> 
>> Therefore the "existing RADIUS data model as outlined below" is really
>> just the data model for standard RADIUS attributes. 
> 
> Well, characterizing various ad-hoc extensions as part of a data model seems
> to me to de-value the term "data model".  :-)

  Most vendors are smart/lazy enough to re-use the existing data types.
 The guidelines draft is intended to encourage this behavior, and to
discourage "complex" types that are little more than simple collation of
existing data types.

  It is intended to encourage SDO specifications that re-use existing
data types.  These specifications should *not* need IETF review.

  Specifications that are SDO specific, and do *not* re-use existing
types are SDO specific, and do not need IETF review.

  Much of this is already in the document.  What can we do to clarify
the text to avoid repeated questions?

>>   Does the data fit utilize ad-hoc extensions to the RADIUS data model,
>>   as outlined in below?  If so, it SHOULD be encapsulated in a RADIUS VSA 
>>   or an Extended Attribute [EXTENDED].
> 
> While it may be feasible to group the ad-hoc extensions into a handful of
> categories, I'm not sure what benefit this provides.  Anything *other* than
> the (limited) standard data model is automatically an ad-hoc extension,
> right?  Do we need to provide examples?

  I would say no.

  The most I would do is to provide horrific examples of what *not* to
do.  i.e. putting arbitrary text strings into the "data" portion of a
VSA (no... no VSA-type/VSA-length/VSA-data... just Vendor-Id/text..)

  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, 30 Dec 2008 21:33:19 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue:  Data Type Advice
Date: Tue, 30 Dec 2008 16:33:04 -0500

Bernard Aboba writes...

> Therefore the "existing RADIUS data model as outlined below" is really
> just the data model for standard RADIUS attributes.=A0

Well, characterizing various ad-hoc extensions as part of a data model =
seems
to me to de-value the term "data model".  :-)

>   Does the data fit within the RADIUS standard attribute data model,
>   as outlined below?  If so, it MAY be encapsulated either in a =
[RFC2865]
>   format RADIUS attribute, or in a [RFC2865] format RADIUS VSA.

OK.

>   Does the data fit utilize ad-hoc extensions to the RADIUS data =
model,
>   as outlined in below?  If so, it SHOULD be encapsulated in a RADIUS =
VSA=20
>   or an Extended Attribute [EXTENDED].

While it may be feasible to group the ad-hoc extensions into a handful =
of
categories, I'm not sure what benefit this provides.  Anything *other* =
than
the (limited) standard data model is automatically an ad-hoc extension,
right?  Do we need to provide examples?
=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, 30 Dec 2008 21:23:42 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Tue, 30 Dec 2008 16:23:03 -0500

Bernard Aboba writes...

> Given the widely divergent interpretations of the document applicability,
> it would seem that we will need to develop an applicability statement 
> section so that the scope (and intent) of the document is clear. 

Uh...  There *is* an applicability statement, Section 1.1 Applicability.
:-)

I previously quoted part of it.  Here's the complete section:

1.1.  Applicability

   As RADIUS has become more widely accepted as a management protocol,
   its usage has become more prevalent, both within the IETF as well as
   within other SDOs.  Given the expanded utilization of RADIUS, it has
   become apparent that requiring SDOs to accomplish all their RADIUS
   work within the IETF is inherently inefficient and unscalable.  By
   articulating guidelines for RADIUS attribute design, this document
   enables SDOs to design their own RADIUS attributes within the Vendor-
   Specific Attribute (VSA) space, seeking review from the IETF.  In
   order to enable IETF review of SDO RADIUS attribute specifications,
   the authors recommend that:

      * SDOs make their RADIUS attribute specifications publicly
      available;

      * SDOs request review of RADIUS attribute specifications by
      sending email to the AAA Doctors [DOCTORS] or equivalent mailing
      list;

      * IETF and SDO RADIUS attribute specifications are reviewed
      according to the guidelines proposed in this document;

      * Reviews of specifications are posted to the RADEXT WG mailing
      list, the AAA Doctors mailing list [DOCTORS] or another IETF
      mailing list suggested by the Operations & Management Area
      Directors of the IETF.

   The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.  RADIUS protocol
   changes, or specification of attributes (such as Service-Type) that
   can be used to, in effect, provide new RADIUS commands require
   greater expertise and deeper review, as do changes to the RADIUS
   operational model, as described in Section 3.3 .  Such changes should
   not be undertaken outside the IETF and when handled within the IETF
   require "IETF Consensus" for adoption, as noted in [RFC3575] Section
   2.1.

--
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, 30 Dec 2008 20:44:28 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Issue:  Extended Attributes Dependency
Date: Tue, 30 Dec 2008 12:44:05 -0800

--_21f4c260-8619-4075-8db7-416223bc7260_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Issue: Extended Attributes Dependency

Submitter name:  Bernard Aboba

Submitter email address: [email-masked]

Date first submitted: December 30=2C 2008 =20

Reference:=20

Document:  GUIDELINES

Comment type: Technical

Priority:  S

Section:  Appendix A.1.2

Rationale/Explanation of issue:

Section A.1.2 reads:
   Where possible=2C the data types defined above in Section A.1.1 SHOULD
   be used.  The extended data types defined in [EXTEN] SHOULD be used
   only where there is no clear method of expressing the data using
   existing types.

   Does the data fit within the extended RADIUS data model=2C as outlined
   below?  If so=2C it SHOULD be encapsulated in a [EXTEN] format RADIUS
   VSA.

      * Attributes grouped into a logical container.
        This does not include nested groups.
      * Attributes requiring the transport of more than 247 octets of
        Text or String data.  This includes the opaque encapsulation
        of data structures defined outside of RADIUS.  See also Section
        A.1.3=2C below.

This text includes normative statements relating to the Extended
Attributes document=2C and yet [EXTEN] is only listed as an
Informative reference.  Either a normative reference needs to be
added=2C or this section needs to be removed.=20

--_21f4c260-8619-4075-8db7-416223bc7260_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<br><strong>Issue: Extended Attributes Dependency</strong><br>

Submitter name:&nbsp=3B Bernard Aboba<br>

Submitter email address: [email-masked]<br>

Date first submitted: December 30=2C 2008&nbsp=3B <br>

Reference:&nbsp=3B
<br>

Document:&nbsp=3B GUIDELINES<br>

Comment type: Technical<br>

Priority:&nbsp=3B S<br>

Section:&nbsp=3B Appendix A.1.2<br>

Rationale/Explanation of issue:<br><br>Section A.1.2 reads:<pre class=3D"ne=
wpage"><br>   Where possible=2C the data types defined above in Section A.1=
.1 SHOULD<br>   be used.  The extended data types defined in [<a href=3D"ht=
tp://tools.ietf.org/html/draft-ietf-radext-design-05#ref-EXTEN">EXTEN</a>] =
SHOULD be used<br>   only where there is no clear method of expressing the =
data using<br>   existing types.<br><br>   Does the data fit within the ext=
ended RADIUS data model=2C as outlined<br>   below?  If so=2C it SHOULD be =
encapsulated in a [<a href=3D"http://tools.ietf.org/html/draft-ietf-radext-=
design-05#ref-EXTEN">EXTEN</a>] format RADIUS<br>   VSA.<br><br>      * Att=
ributes grouped into a logical container.<br>        This does not include =
nested groups.<br>      * Attributes requiring the transport of more than 2=
47 octets of<br>        Text or String data.  This includes the opaque enca=
psulation<br>        of data structures defined outside of RADIUS.  See als=
o Section<br>        A.1.3=2C below.<br><br>This text includes normative st=
atements relating to the Extended<br>Attributes document=2C and yet [EXTEN]=
 is only listed as an<br>Informative reference.  Either a normative referen=
ce needs to be<br>added=2C or this section needs to be removed. <br></pre><=
table style=3D"border-top: 1px solid black=3B font-weight: bold=3B font-fam=
ily: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><br></td></tr></tbo=
dy></table></body>
</html>=

--_21f4c260-8619-4075-8db7-416223bc7260_--

--
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, 30 Dec 2008 20:33:02 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Issue:  Data Type Advice
Date: Tue, 30 Dec 2008 12:32:30 -0800

--_23f84cdf-de7a-43ea-9a45-e1ccb9d34263_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Issue: Data Type Advice

Submitter name:  Bernard Aboba

Submitter email address: [email-masked]

Date first submitted: December 30=2C 2008 =20

Reference:=20

Document:  GUIDELINES

Comment type: Technical

Priority:  S

Section:  Appendix A.1.1

Rationale/Explanation of issue:

Section A.1.1 reads:=20
   Does the data fit within the existing RADIUS data model=2C as outlined
   below?  If so=2C it SHOULD be encapsulated in a [RFC2865] format RADIUS
   attribute=2C or in a [RFC2865] format RADIUS VSA.

As noted in an earlier issue=2C Appendix B does not cover data types utiliz=
ed within RADIUS VSAs=2C=20
only the data types in standard RADIUS attributes.   Therefore the "existin=
g RADIUS data model
as outlined below" is really just the data model for standard RADIUS attrib=
utes.   On that basis
the sentence might better read:

   Does the data fit within the RADIUS standard attribute data model=2C as =
outlined
   below?  If so=2C it MAY be encapsulated either in a [RFC2865] format RAD=
IUS
   attribute=2C or in a [RFC2865] format RADIUS VSA.

Assuming that the promised survey of ad-hoc data model extensions is actual=
ly included in the
document=2C then this could be referenced to in a subsequent sentence:

   Does the data fit utilize ad-hoc extensions to the RADIUS data model=2C =
as outlined
   in below?  If so=2C it SHOULD be encapsulated in a RADIUS VSA or an Exte=
nded
   Attribute [EXTENDED]. =20

Given this=2C it would appear that Section A.1.1 is recommending that RADIU=
S VSAs only

--_23f84cdf-de7a-43ea-9a45-e1ccb9d34263_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<strong>Issue: Data Type Advice</strong><br>

Submitter name:&nbsp=3B Bernard Aboba<br>

Submitter email address: [email-masked]<br>

Date first submitted: December 30=2C 2008&nbsp=3B <br>

Reference:&nbsp=3B
<br>

Document:&nbsp=3B GUIDELINES<br>

Comment type: Technical<br>

Priority:&nbsp=3B S<br>

Section:&nbsp=3B Appendix A.1.1<br>

Rationale/Explanation of issue:<br><br>Section A.1.1 reads: <br><pre class=
=3D"newpage">   Does the data fit within the existing RADIUS data model=2C =
as outlined<br>   below?  If so=2C it SHOULD be encapsulated in a [<a href=
=3D"http://tools.ietf.org/html/rfc2865" title=3D"&quot=3B28800 V42BIS/LAPM&=
quot=3B">RFC2865</a>] format RADIUS<br>   attribute=2C or in a [<a href=3D"=
http://tools.ietf.org/html/rfc2865" title=3D"&quot=3B28800 V42BIS/LAPM&quot=
=3B">RFC2865</a>] format RADIUS VSA.<br><br></pre>As noted in an earlier is=
sue=2C Appendix B does not cover data types utilized within RADIUS VSAs=2C =
<br>only the data types in standard RADIUS attributes.&nbsp=3B&nbsp=3B Ther=
efore the "existing RADIUS data model<br>as outlined below" is really just =
the data model for standard RADIUS attributes.&nbsp=3B&nbsp=3B On that basi=
s<br>the sentence might better read:<br><br><pre class=3D"newpage">   Does =
the data fit within the RADIUS standard attribute data model=2C as outlined=
<br>   below?  If so=2C it MAY be encapsulated either in a [<a href=3D"http=
://tools.ietf.org/html/rfc2865" title=3D"&quot=3B28800 V42BIS/LAPM&quot=3B"=
>RFC2865</a>] format RADIUS<br>   attribute=2C or in a [<a href=3D"http://t=
ools.ietf.org/html/rfc2865" title=3D"&quot=3B28800 V42BIS/LAPM&quot=3B">RFC=
2865</a>] format RADIUS VSA.</pre>
<br>Assuming that the promised survey of ad-hoc data model extensions is ac=
tually included in the<br>document=2C then this could be referenced to in a=
 subsequent sentence:<br><br><pre class=3D"newpage">   Does the data fit ut=
ilize ad-hoc extensions to the RADIUS data model=2C as outlined<br>   in be=
low?  If so=2C it SHOULD be encapsulated in a RADIUS VSA or an Extended<br>=
   Attribute [EXTENDED].  <br></pre>
<br><br><br><br><br><br><br>Given this=2C it would appear that Section A.1.=
1 is recommending that RADIUS VSAs only<br><table style=3D"border-top: 1px =
solid black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-=
serif=3B"><tbody><tr><td><br></td></tr></tbody></table></body>
</html>=

--_23f84cdf-de7a-43ea-9a45-e1ccb9d34263_--

--
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, 30 Dec 2008 20:16:45 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Issue:  Attribute Usage
Date: Tue, 30 Dec 2008 12:16:15 -0800

--_f4a2acc9-39be-4a4f-9e82-b56f052c495a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Issue: Attribute Usage

Submitter name:  Bernard Aboba

Submitter email address: [email-masked]

Date first submitted: December 30=2C 2008 =20

Reference:=20

Document:  GUIDELINES

Comment type: Technical

Priority:  S

Section:  1=2C Appendix B

Rationale/Explanation of issue:

Section 1 of the document reads:

   In order to characterize current attribute usage=2C both the basic and
   complex data types defined in the existing RADIUS RFCs are reviewed=2C
   together with the ad-hoc extensions to that data model that have been
   used in Vendor-Specific Attributes.

Appendix B covers only data types used in existing RADIUS RFCs.   As far as=
 I can tell=2C
the document does not catalog the ad-hoc extensions that have been used in
Vendor-Specific Attributes.=20

Either the document needs to add material relating to ad-hoc extensions=2C =
or this
portion of the sentence needs to be removed.

--_f4a2acc9-39be-4a4f-9e82-b56f052c495a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<strong>Issue: Attribute Usage</strong><br>
Submitter name:&nbsp=3B Bernard Aboba<br>
Submitter email address: [email-masked]<br>
Date first submitted: December 30=2C 2008&nbsp=3B <br>
Reference:&nbsp=3B
<br>
Document:&nbsp=3B GUIDELINES<br>
Comment type: Technical<br>
Priority:&nbsp=3B S<br>
Section:&nbsp=3B 1=2C Appendix B<br>
Rationale/Explanation of issue:<br><br>Section 1 of the document reads:<br>=
<pre class=3D"newpage"><br>   In order to characterize current attribute us=
age=2C both the basic and<br>   complex data types defined in the existing =
RADIUS RFCs are reviewed=2C<br>   together with the ad-hoc extensions to th=
at data model that have been<br>   used in Vendor-Specific Attributes.<br><=
/pre><br>Appendix B covers only data types used in existing RADIUS RFCs.&nb=
sp=3B&nbsp=3B As far as I can tell=2C<br>the document does not catalog the =
ad-hoc extensions that have been used in<br>Vendor-Specific Attributes. <br=
><br>Either the document needs to add material relating to ad-hoc extension=
s=2C or this<br>portion of the sentence needs to be removed.<br><br><br><br=
><br><br><br><br><br><br><br><table style=3D"border-top: 1px solid black=3B=
 font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbo=
dy><tr><td><br></td></tr></tbody></table></body>
</html>=

--_f4a2acc9-39be-4a4f-9e82-b56f052c495a_--

--
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, 30 Dec 2008 20:00:41 +0000
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Tue, 30 Dec 2008 11:59:55 -0800

--_31276e7e-ad26-4f35-8370-6ef8fa8729e4_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> That's not what it says.  What it actually says is:
>=20
>    Given the expanded utilization of RADIUS=2C it has
>    become apparent that requiring SDOs to accomplish all their
>    RADIUS work within the IETF is inherently inefficient and=20
>    unscalable.  By articulating guidelines for RADIUS attribute=20
>    design=2C this document enables SDOs to design their own RADIUS=20
>    attributes within the Vendor-Specific Attribute (VSA) space=2C
>    seeking review from the IETF.
>=20
> It specifically indicates that the guidelines apply to SDO-defined
> attributes=2C and I think this was the general intent all along -- to pro=
vide
> design guidance so that high-quality RADUS work could occur both within t=
he
> IETF and within other SDOs.

I think that this may in part explain some of Hannes' (and others) objectio=
ns to the document.=20

Given the widely divergent interpretations of the document applicability=2C=
 it would seem that we
will need to develop an applicability statement section so that the scope (=
and intent) of the
document is clear.=20

--_31276e7e-ad26-4f35-8370-6ef8fa8729e4_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B That's not what it says.  What it actually says is:<br>&gt=3B <br>&g=
t=3B    Given the expanded utilization of RADIUS=2C it has<br>&gt=3B    bec=
ome apparent that requiring SDOs to accomplish all their<br>&gt=3B    RADIU=
S work within the IETF is inherently inefficient and <br>&gt=3B    unscalab=
le.  By articulating guidelines for RADIUS attribute <br>&gt=3B    design=
=2C this document enables SDOs to design their own RADIUS <br>&gt=3B    att=
ributes within the Vendor-Specific Attribute (VSA) space=2C<br>&gt=3B    se=
eking review from the IETF.<br>&gt=3B <br>&gt=3B It specifically indicates =
that the guidelines apply to SDO-defined<br>&gt=3B attributes=2C and I thin=
k this was the general intent all along -- to provide<br>&gt=3B design guid=
ance so that high-quality RADUS work could occur both within the<br>&gt=3B =
IETF and within other SDOs.<br><br>I think that this may in part explain so=
me of Hannes' (and others) objections to the document. <br><br>Given the wi=
dely divergent interpretations of the document applicability=2C it would se=
em that we<br>will need to develop an applicability statement section so th=
at the scope (and intent) of the<br>document is clear. <br><br></body>
</html>=

--_31276e7e-ad26-4f35-8370-6ef8fa8729e4_--

--
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, 30 Dec 2008 19:11:33 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Tue, 30 Dec 2008 14:11:11 -0500

Bernard Aboba writes...

> The RADIUS design guidelines only apply to documents that are 
> requesting allocation of RADIUS standard attributes.

That's not what it says.  What it actually says is:

   Given the expanded utilization of RADIUS, it has
   become apparent that requiring SDOs to accomplish all their
   RADIUS work within the IETF is inherently inefficient and 
   unscalable.  By articulating guidelines for RADIUS attribute 
   design, this document enables SDOs to design their own RADIUS 
   attributes within the Vendor-Specific Attribute (VSA) space,
   seeking review from the IETF.

It specifically indicates that the guidelines apply to SDO-defined
attributes, and I think this was the general intent all along -- to provide
design guidance so that high-quality RADUS work could occur both within the
IETF and within other SDOs.

--
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, 30 Dec 2008 18:38:37 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Dave Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Tue, 30 Dec 2008 10:38:21 -0800

David Nelson said:

"Should such a review include analysis of compliance with the RADIUS Design
Guidelines?  Are you assuming that the guidelines apply only after they are
finally published as a BCP?"

The RADIUS design guidelines only apply to documents that are requesting
allocation of RADIUS standard attributes.  If this document were to 
allocate its attributes from the IEEE 802 attribute space, then I don't
believe that conformance to Design Guidelines would be required.  

--
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, 30 Dec 2008 18:33:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Dave Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Tue, 30 Dec 2008 10:33:07 -0800

> I haven't seen the code so I don't know for sure, but my guess
> is that your presumption would be incorrect.  Since multiple 
> vendors are involved, this is not a technically appropriate 
> use of VSAs.

No. The Design Guidelines document was written in part to dispel
this misconception.  VSAs (specifically those allocated to
SDOs such as IEEE 802) are not only technically appropriate 
for this use, they are the recommended approach for use
in documents (such as this one) which describe SDO-specific
uses of RADIUS.  

If this point is not being made crystal clear in the Design
Guidelines document, then we need to change the text until
it is. 

Forcing SDOs to put documents on the IETF standards track
merely so that they can obtain request allocation of standard RADIUS
attributes for SDO-specific uses of RADIUS makes no sense. 

--
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, 30 Dec 2008 16:27:12 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Tue, 30 Dec 2008 11:26:52 -0500

Bernard Aboba writes...

> If the goal here is to publish documentation of an existing 
> implementation of RADIUS attributes for IEEE 802.16a, then a request
> should be sent to the AAA-Doctors list for a review.

Should such a review include analysis of compliance with the RADIUS Design
Guidelines?  Are you assuming that the guidelines apply only after they are
finally published as a BCP?

--
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, 30 Dec 2008 15:58:38 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Tue, 30 Dec 2008 10:57:43 -0500

Dan Romascanu writes...

>> And that preference would be that the draft simply be 
>> published as an Informational RFC, via the AD Sponsorship route.
> 
> I will accept taking this path if the WG is OK with it, but I would
> note that I will ask anyway the WG to designate an expert reviewer
> for this document and would expect people to comment at last call
> (or before).

There are two issues which would slow the progress this draft as a RADEXT WG
work item: (1) if the WG members were not sufficiently interested in 802.16
key management to engage in active review and commentary and (2) if the
draft were to be entangled in the debate over whether or not to support
complex, structured attributes.

I can't predict (1) but I can predict (2).  One snippet from the draft
reads:

      The PKM-Config-Settings Attribute is 30 octets in length and
      consists of seven independent fields, each of type integer
      [RFC2865].
 
This tell us right up front that the draft is using complex / structured
attributes, in this case a fixed length array of integer values.  As
currently constituted, the RADIUS Design Guidelines draft discourages such
attribute design for attributes in the "classic" RADIUS attribute ID space.
This draft is requesting allocation from that space.

We had a similar problem with the GEOPRIV Location Attributes draft.  That
document has moved on, but the basic tension between its attribute design
and the recommendations of the Design Guidelines was never fully resolved.

While the Design Guidelines draft is up for IESG approval, and represents
the consensus opinion of the RADEXT WG in the matter of attribute design,
there is still some disquiet.  Most recently, Hannes Tschofenig posted some
commentary regarding the issue of Diameter AVP compatibility that directly
hinges on this thorny issue of complex / structured attributes.

My observation is that there are still drafts being written that do not
follow the RADIUS Design Guidelines, even though that document is basically
a "done deal".  I assume that means that developers find the guidelines too
restrictive for their particular applications or their particular design
preferences.   I can only assume that this will continue, even after the
RADIUS Design Guidelines draft is published as a BCP.  Sigh.

With regard to the example quoted above, the recommended design would be
seven separate attributes of type Integer.  If we take the scarcity issue
off the table for a moment, the only downside would be encoding
inefficiency, i.e. the seven integer values would take up more space in the
RADIUS PDU.  Glen Zorn, in particular, has continually suggested to the WG
that applications are bumping up against the limitation of RADIUS PDU
length.  I suppose an application that is including multiple X.509
certificates in a RADIUS packet may indeed have this problem.

I will take some time to read the current draft and offer some comments.
What am I to do about attributes that don't follow the RADIUS Design
Guidelines?  This promises to be the GEOPRIV debate all over again.  We can
simply turn a blind eye, and let the draft go via the individual submission
route, but what kind of precedent are we setting if we start bypassing
RADIUS Design Guidelines right out of the gate?

If we have design rules or guidelines, they ought to mean something.  That
requires we either reject drafts that don't comply or we enhance the
guidelines so that all reasonable-minded developers can live within their
restrictions.  Anything else is pretty silly, IMHO.

We thought that the RADIUS Extended Attribute format would be a way out of
this mess, i.e. that it would support a sufficient (albeit limited) way to
encode complex / structured attributes.  The Design Guidelines draft is
largely silent on how to design Extended Attributes; that guidance is to be
included in the Extended Attributes draft.

The RADEXT WG consensus of Extended Attributes is that the current tagging
mechanism is sufficient to permit the representation of structured
attributes.  Glen has told us in various postings that that format is not
sufficient (acceptable) to accommodate the need of the PKMV1 draft we are
discussing.  So, we see the draft using "classic" attributes in a way not
supported by the RADIUS Design Guidelines draft.

I think something has to change, or we're in for a lot of future silliness.
I personally have supported a more robust format for Extended Attributes
that would better accommodate the [perceived] need for structured and
complex attribute design.  However, that's not where the WG consensus lies.
That's fine.  But what are we to do with draft submissions that find neither
the Extended Attribute format nor the guidance of the RADIUS Design
Guidelines for "classic" attributes acceptable to their purpose?  Should we
(or some appointed Expert Reviewer) reject those drafts and attempt to block
their publication?

If the motivation in the developer community to design, publish and deploy
complex, structured attributes is sufficiently strong, and the IETF does not
provide a reasonable format or alternative, we're in for a lot more heated
debates.

Let me put it this way: What would MIB Module designers do if there were no
tables available in SMI and there was no SEQUENCE OF syntax?  :-)

I'm seeking suggestions for a way forward, not only for this draft, but for
other similar ones to come.

--
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, 30 Dec 2008 14:50:20 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Tue, 30 Dec 2008 09:49:34 -0500

Glen Zorn writes...

>> I presume the attributes have been deployed as VSAs.  
>
> I haven't seen the code so I don't know for sure, but my guess
> is that your presumption would be incorrect.  Since multiple 
> vendors are involved, this is not a technically appropriate 
> use of VSAs.

So perhaps the implementers used code points in the "Private Use" range (192
- 240)?  Please don't tell me that they poached code points under IANA
control.  :-(  That would be pretty egregious. 

In any event, changes to the code would need to be made, no?

--
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, 30 Dec 2008 10:11:57 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Tue, 30 Dec 2008 11:10:51 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "D. B. Nelson" <[email-masked]>, <[email-masked]>, "Glen Zorn" <[email-masked]>

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of D. B. Nelson
> Sent: Monday, December 29, 2008 4:13 PM
> To: [email-masked]
> Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt=20
>=20
> Glen Zorn writes...
>=20
> > Anyway, my preference hasn't changed since I sent my=20
> original request=20
> > (attached) to Dan over 2 months ago.
>=20
> And that preference would be that the draft simply be=20
> published as an Informational RFC, via the AD Sponsorship route.
>=20

I will accept taking this path if the WG is OK with it, but I would note
that I will ask anyway the WG to designate an expert reviewer for this
document and would expect people to comment at last call (or before).=20

Glen, in order to start the AD-sponsoring process you need to find a
shepherd for this document, and he or she will need to submit a PROTO
write-up as per http://www.ietf.org/IESG/content/Indiv-Doc-Writeup.html

Thanks and Regards,

Dan

--
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, 30 Dec 2008 07:12:22 +0000
Date: Tue, 30 Dec 2008 08:12:02 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: Glen Zorn <[email-masked]>,  Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Issue:  Use of the term "extended" within the Design Guidelines Document

Bernard Aboba wrote:
> Looking at the Design Guidelines document, the term "extended"
> is used in a number of contexts.  This may explain some of the
> questions that Hannes raised. 

  I will update the document to ensure that the "extended" term is used
only in reference to the extended attributes document.

  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, 30 Dec 2008 07:00:39 +0000
From: "Glen Zorn" <[email-masked]>
To: "'D. B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Tue, 30 Dec 2008 13:59:06 +0700

> Glen Zorn writes...
> 
> > Anyway, my preference hasn't changed since I sent my original
> > request (attached) to Dan over 2 months ago.
> 
> And that preference would be that the draft simply be published as an
> Informational RFC, via the AD Sponsorship route.
> 
> > Furthermore (& I _really_ hate to say this) the attributes as
> > they are have already been implemented by at least 2 vendors
> > and deployed.
> 
> I presume the attributes have been deployed as VSAs.  

I haven't seen the code so I don't know for sure, but my guess is that your
presumption would be incorrect.  Since multiple vendors are involved, this
is not a technically appropriate use of VSAs.

...

--
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, 30 Dec 2008 05:38:48 +0000
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Mon, 29 Dec 2008 21:37:28 -0800

--_715eaaa2-bd87-4d94-abea-af6997f280c8_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> I suppose this draft could be published as documentation of existing
> practice / fielded deployment=2C as an Informational RFC using the fielde=
d VSA
> assignments.

Indeed=2C according to the Design Guidelines document=2C that is the *prefe=
rred*
approach=2C since it maximizes interoperability with existing implementatio=
ns.=20

Of course=2C this raises the question whether the existing attributes are a=
llocated
in the IEEE 802 space (e.g. SDO-specific attributes)=2C or in the Vendor-Sp=
ace.=20

However=2C in terms of the review process described in the Design Guideline=
s
document=2C it does not matter.=20

> Using Extended Attributes was my first choice but it is unfortunately
> impossible to do this in any reasonable fashion using them=3B this was
> established as unchangeable WG Consensus some time ago=2C as announced by=
 Alan
> Dekok=20
Given that this protocol has supposedly already been implemented by 2 vendo=
rs=2C=20
why is the presence or absence of any feature within the Extended Attribute=
s
document relevant?  Presumably a description of an existing implementation =
would
be self-contained=2C not requiring a normative reference to any work-in-pro=
gress=2C
assuming that the protocol is already implemented.=20

> (it _is_ interesting that RFCs can be updated & made obsolete &
> decisions of even the highest courts may be overturned=2C all based on ne=
w
> data=2C but WG Consensus cannot change -- who knew?).

What I don't understand is what "working group consensus" has to do with
publishing documentation of an existing implementation.   Presumably the on=
ly
criteria governing would be whether the document actually describes
what has been implemented.=20

> These spurious claims can't avoid the fact that you haven't succeeded
> in changing the WG consensus to support your position.  Don't blame me.
The "claims" in question here seem to have nothing whatever to do with the =
document
under discussion in this thread:  draft-zorn-radius-pkm1.   So before we ge=
t drawn
into a discussion of the validity of them=2C I'd first like to understand w=
hy they are even=20
relevant.

If the goal here is to publish documentation of an existing implementation =
of RADIUS
attributes for IEEE 802.16a=2C then a request should be sent to the AAA-Doc=
tors list
for a review.  Such a document need not become a RADEXT WG work item to be
eligible for publication.  Certainly that has not been the case for other s=
uch
documents=2C most recently RFC 4679. =20

=20
 =20

--_715eaaa2-bd87-4d94-abea-af6997f280c8_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B I suppose this draft could be published as documentation of existing=
<br>&gt=3B practice / fielded deployment=2C as an Informational RFC using t=
he fielded VSA<br>&gt=3B assignments.<br><br>Indeed=2C according to the Des=
ign Guidelines document=2C that is the *preferred*<br>approach=2C since it =
maximizes interoperability with existing implementations. <br><br>Of course=
=2C this raises the question whether the existing attributes are allocated<=
br>in the IEEE 802 space (e.g. SDO-specific attributes)=2C or in the Vendor=
-Space. <br><br>However=2C in terms of the review process described in the =
Design Guidelines<br>document=2C it does not matter. <br><br><pre>&gt=3B Us=
ing Extended Attributes was my first choice but it is unfortunately<br>&gt=
=3B impossible to do this in any reasonable fashion using them=3B this was<=
br>&gt=3B established as unchangeable WG Consensus some time ago=2C as anno=
unced by Alan<br>&gt=3B Dekok <br></pre>Given that this protocol has suppos=
edly already been implemented by 2 vendors=2C <br>why is the presence or ab=
sence of any feature within the Extended Attributes<br>document relevant?&n=
bsp=3B Presumably a description of an existing implementation would<br>be s=
elf-contained=2C not requiring a normative reference to any work-in-progres=
s=2C<br>assuming that the protocol is already implemented. <br><br><pre>&gt=
=3B (it _is_ interesting that RFCs can be updated &amp=3B made obsolete &am=
p=3B<br>&gt=3B decisions of even the highest courts may be overturned=2C al=
l based on new<br>&gt=3B data=2C but WG Consensus cannot change -- who knew=
?).<br></pre><br>What I don't understand is what "working group consensus" =
has to do with<br>publishing documentation of an existing implementation.&n=
bsp=3B&nbsp=3B Presumably the only<br>criteria governing would be whether t=
he document actually describes<br>what has been implemented. <br><br><pre>&=
gt=3B These spurious claims can't avoid the fact that you haven't succeeded=
<br>&gt=3B in changing the WG consensus to support your position.  Don't bl=
ame me.<br></pre>The "claims" in question here seem to have nothing whateve=
r to do with the document<br>under discussion in this thread:&nbsp=3B draft=
-zorn-radius-pkm1. &nbsp=3B So before we get drawn<br>into a discussion of =
the validity of them=2C I'd first like to understand why they are even <br>=
relevant.<br><br>If the goal here is to publish documentation of an existin=
g implementation of RADIUS<br>attributes for IEEE 802.16a=2C then a request=
 should be sent to the AAA-Doctors list<br>for a review.&nbsp=3B Such a doc=
ument need not become a RADEXT WG work item to be<br>eligible for publicati=
on.&nbsp=3B Certainly that has not been the case for other such<br>document=
s=2C most recently RFC 4679.&nbsp=3B <br><br>&nbsp=3B<br>&nbsp=3B <br><br><=
br><br></body>
</html>=

--_715eaaa2-bd87-4d94-abea-af6997f280c8_--

--
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, 29 Dec 2008 14:14:15 +0000
From: "D. B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Mon, 29 Dec 2008 09:13:15 -0500

Glen Zorn writes...

> Anyway, my preference hasn't changed since I sent my original
> request (attached) to Dan over 2 months ago.

And that preference would be that the draft simply be published as an
Informational RFC, via the AD Sponsorship route.

> Furthermore (& I _really_ hate to say this) the attributes as
> they are have already been implemented by at least 2 vendors
> and deployed.

I presume the attributes have been deployed as VSAs.  This draft requests
that IANA assign standard code space IDs to the attributes. I understand
that changing the deployed code to remove VSA headers and substitute
standard headers is not a lot of work, but it _is_ a code change.  Once you
open up the code for change...  well, change is change.

I suppose this draft could be published as documentation of existing
practice / fielded deployment, as an Informational RFC using the fielded VSA
assignments.

--
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, 29 Dec 2008 09:17:38 +0000
From: Bernard Aboba <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Issue:  Use of the term "extended" within the Design Guidelines Document
Date: Mon, 29 Dec 2008 01:16:52 -0800

> At the risk of putting words in Hannes' mouth=2C I'm pretty sure that the
> draft he believes gives the impression that Extended Attributes can easil=
y
> support the Diameter AVP structure _is_ the Design Guidelines draft=3B as=
 he
> points out=2C it would be impossible for a reasonable person to get that =
idea
> from the Extended Attributes draft.

Looking at the Design Guidelines document=2C the term "extended"
is used in a number of contexts.  This may explain some of the
questions that Hannes raised.=20

For example=2C in Section 2.2=2C the term is used to refer to the Extended =
Attributes document:=20
2.2.  Extended RADIUS Attributes

   The extended RADIUS attribute document [EXTEN] defines a number of
   extensions to RADIUS.  The standard attribute space is extended by
   permitting standard allocations from within a specific subset of the
   VSA space=3B the format of extended attributes is defined=3B and extende=
d
   data types are defined within that format.

   New specifications seeking to extend the standard RADIUS data model
   SHOULD examine [EXTEN] to see if their needs fit within the extended
   RADIUS data model.

In Section 3.1.2=2C the term is used to refer to RADIUS VSAs in general:

   As discussed in [RFC2865] Section 5.26=2C the vendor space is intended
   for vendors to support their own extended attributes not suitable for
   general use.=20

In Section A.1.2=2C the term "Extended" is used to refer to data types.=20
However=2C it is not clear whether this advice is only applicable to
RADIUS standard attributes (which I believe is the case)=2C or whether
it applies to VSAs or SDO-specific attributes.=20

A.1.2. Extended data types

   Where possible=2C the data types defined above in Section A.1.1 SHOULD
   be used.  The extended data types defined in [EXTEN] SHOULD be used
   only where there is no clear method of expressing the data using
   existing types.

   Does the data fit within the extended RADIUS data model=2C as outlined
   below?  If so=2C it SHOULD be encapsulated in a [EXTEN] format RADIUS
   VSA.

      * Attributes grouped into a logical container.
        This does not include nested groups.
      * Attributes requiring the transport of more than 247 octets of
        Text or String data.  This includes the opaque encapsulation
        of data structures defined outside of RADIUS.  See also Section
        A.1.3=2C below.

In Section A.5=2C the term "extended" is used to refer to SDO-specific
data types:

   Note that the points listed above do not relax the recommendations
   discussed in this document.  Instead=2C they recognize that the RADIUS
   data model has limitations.  In certain situations where
   interoperability can be strongly constrained=2C a data model extended
   by the SDO or vendor MAY be used. =20

The term is also used in Section B.8=2C this time in reference to the
Extended Attributes document:

   Future specifications that attempt to obtain similar
   functionality SHOULD use the extended types from [EXTEN].

Overall=2C in looking over this text=2C there does seem to be some possibil=
ity
of confusion relating to the applicability of the document (which I believe
only applies to attributes within the RADIUS standard attribute space).=20

However=2C none of the above text would seem capable of leading a reader
to believe that the Diameter AVP format was supported.  Or am I missing
something?=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: Mon, 29 Dec 2008 07:53:48 +0000
Date: Mon, 29 Dec 2008 08:53:21 +0100
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: "'D. B. Nelson'" <[email-masked]>,  'Bernard Aboba' <[email-masked]>, [email-masked], "'Romascanu, Dan \(Dan\)'" <[email-masked]>
Subject: Re: I-D Action:draft-zorn-radius-pkmv1-03.txt

Glen Zorn wrote:
> Using Extended Attributes was my first choice but it is unfortunately
> impossible to do this in any reasonable fashion using them; this was
> established as unchangeable WG Consensus some time ago, as announced by Alan
> Dekok 

  I never said any such thing.

  In the past, people rejected the modifications you proposed.  This
forms the "WG consensus" that I have referred to.

  In the present, no one has agreed to make those modifications.

  In the future, if people *do* agree to make those modifications, that
would form "WG consensus", and I would be in no position to oppose it.

> (it _is_ interesting that RFCs can be updated & made obsolete &
> decisions of even the highest courts may be overturned, all based on new
> data, but WG Consensus cannot change -- who knew?).

  These spurious claims can't avoid the fact that you haven't succeeded
in changing the WG consensus to support your position.  Don't blame me.

  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: Mon, 29 Dec 2008 07:40:22 +0000
Date: Mon, 29 Dec 2008 08:39:46 +0100
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Bernard Aboba' <[email-masked]>,  'Hannes Tschofenig' <[email-masked]>, [email-masked]
Subject: Re: philosophy of the Design Guidelines document

Glen Zorn wrote:
> At the risk of putting words in Hannes' mouth, I'm pretty sure that the
> draft he believes gives the impression that Extended Attributes can easily
> support the Diameter AVP structure _is_ the Design Guidelines draft; as he
> points out, it would be impossible for a reasonable person to get that idea
> from the Extended Attributes draft.

  You must be reading a different version of the Design Guidelines
document than the one I'm editing.

  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: Mon, 29 Dec 2008 07:18:01 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: "'Hannes Tschofenig'" <[email-masked]>, <[email-masked]>
Subject: RE: philosophy of the Design Guidelines document
Date: Mon, 29 Dec 2008 14:17:10 +0700

Bernard Aboba [mailto:[email-masked]] writes:

...

> > At least I am asking to capture these aspects in the draft as there
> are
> > really two types of complex attributes, namely those captured with
> the
> > RADIUS extended attributes draft and then more complex onces that can
> be
> > found also in the Diameter space. Reading through the draft one could
> easily
> > get the impression that that document now allows the Diameter AVP
> structure
> > to be easily supported, which is not true.
> 
> Discussion of Extended Attribute design is out of scope of the Design
> Guidelines
> document.  However, it *is* in scope for the Extended Attributes
> document.  So
> I think you are pointing out an issue with the Extended Attributes
> document here.

At the risk of putting words in Hannes' mouth, I'm pretty sure that the
draft he believes gives the impression that Extended Attributes can easily
support the Diameter AVP structure _is_ the Design Guidelines draft; as he
points out, it would be impossible for a reasonable person to get that idea
from the Extended Attributes 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/>

Delivery-date: Mon, 29 Dec 2008 06:29:06 +0000
From: "Glen Zorn" <[email-masked]>
To: "'D. B. Nelson'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>, "'Romascanu, Dan \(Dan\)'" <[email-masked]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Mon, 29 Dec 2008 13:27:42 +0700

This is a multipart message in MIME format.

------=_NextPart_000_0015_01C969B9.45EF0B90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

David Nelson [mailto:[email-masked]] writes:

> Dan Romascanu writes...
> 
> > I would like to ask the WG chairs and the WG at large what are
> > the plans with this document following the response received from
> > IEEE 802.16.
> 
> We should first ask Glen his intent / preferences.  Glen, what is your
> preferred path to publish this draft?

Sorry for the slow response, I've been occupied with administrivia ;-).
Anyway, my preference hasn't changed since I sent my original request
(attached) to Dan over 2 months ago.

> 
> As this draft has been deemed useful to IEEE 802.16 (at least to
> address
> fielded deployments), the first question to ask is whether this work
> should
> be taken on in the IETF, or whether it should be taken on in the IEEE
> (or as
> a individual submission).  We have created a framework in which RADIUS
> attributes that are of interest to particular SDOs, but not of general
> interest to the Internet community, could be documented as SDO Specific
> Attributes, using the RADIUS Extended Attribute format and the RADIUS
> Design
> Guidelines.  

Using Extended Attributes was my first choice but it is unfortunately
impossible to do this in any reasonable fashion using them; this was
established as unchangeable WG Consensus some time ago, as announced by Alan
Dekok (it _is_ interesting that RFCs can be updated & made obsolete &
decisions of even the highest courts may be overturned, all based on new
data, but WG Consensus cannot change -- who knew?).  Furthermore (& I
_really_ hate to say this) the attributes as they are have already been
implemented by at least 2 vendors and deployed.  

...

------=_NextPart_000_0015_01C969B9.45EF0B90
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment

From: "Glen Zorn" <[email-masked]>
To: "'Dan Romascanu'" <[email-masked]>
Cc: "'Glen Zorn'" <[email-masked]>,
	"'Bernard Aboba'" <[email-masked]>,
	"'David B. Nelson'" <[email-masked]>
Subject: FW: I-D Action:draft-zorn-radius-pkmv1-01.txt 
Date: Sat, 18 Oct 2008 14:31:45 +0700

This is a multipart message in MIME format.

------=_NextPart_000_000F_01C969B9.45EBFE50
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0010_01C969B9.45EBFE50"

------=_NextPart_001_0010_01C969B9.45EBFE50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi, Dan.  In the interest of timeliness, I'm wondering if I can interest you
in sponsoring this draft for publication.  I'm not at all averse to radext
WG review of the document but publishing it as a WG document would, in all
probability, take years; in fact, it might take years to get it in the
charter.  Thanks for your consideration.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Saturday, October 18, 2008 2:00 PM
To: [email-masked]
Subject: I-D Action:draft-zorn-radius-pkmv1-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : RADIUS Attributes for IEEE 802.16 Privacy Key
Management Version 1 (PKMv1) Protocol Support
	Author(s)       : G. Zorn
	Filename        : draft-zorn-radius-pkmv1-01.txt
	Pages           : 14
	Date            : 2008-10-17

This document defines a set of RADIUS Attributes which are designed to
provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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_0010_01C969B9.45EBFE50
Content-Type: text/html;
	boundary="----=_NextPart_000_0021_01C9312E.546372B0";
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
08.00.0681.000">
<TITLE>FW: I-D Action:draft-zorn-radius-pkmv1-01.txt </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi, Dan.&nbsp; In the interest of timeliness, I'm =
wondering if I can interest you</FONT>

<BR><FONT SIZE=3D2>in sponsoring this draft for publication.&nbsp; I'm =
not at all averse to radext</FONT>

<BR><FONT SIZE=3D2>WG review of the document but publishing it as a WG =
document would, in all</FONT>

<BR><FONT SIZE=3D2>probability, take years; in fact, it might take years =
to get it in the</FONT>

<BR><FONT SIZE=3D2>charter.&nbsp; Thanks for your consideration.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:i-d-announce-bounces=
@ietf.org</A>]</FONT>

<BR><FONT SIZE=3D2>On Behalf Of [email-masked]</FONT>

<BR><FONT SIZE=3D2>Sent: Saturday, October 18, 2008 2:00 PM</FONT>

<BR><FONT SIZE=3D2>To: [email-masked]</FONT>

<BR><FONT SIZE=3D2>Subject: I-D Action:draft-zorn-radius-pkmv1-01.txt =
</FONT>
</P>

<P><FONT SIZE=3D2>A New Internet-Draft is available from the on-line =
Internet-Drafts</FONT>

<BR><FONT SIZE=3D2>directories.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; : RADIUS Attributes for IEEE 802.16 Privacy Key</FONT>

<BR><FONT SIZE=3D2>Management Version 1 (PKMv1) Protocol Support</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : G. Zorn</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-zorn-radius-pkmv1-01.txt</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; : 14</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; : 2008-10-17</FONT>
</P>

<P><FONT SIZE=3D2>This document defines a set of RADIUS Attributes which =
are designed to</FONT>

<BR><FONT SIZE=3D2>provide RADIUS support for IEEE 802.16 Privacy Key =
Management Version 1.</FONT>
</P>

<P><FONT SIZE=3D2>A URL for this Internet-Draft is:</FONT>

<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-01.tx=
t">http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-01.txt</A>=
</FONT>
</P>

<P><FONT SIZE=3D2>Internet-Drafts are also available by anonymous FTP =
at:</FONT>

<BR><FONT SIZE=3D2><A =
HREF=3D"ftp://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/internet-=
drafts/</A></FONT>
</P>

<P><FONT SIZE=3D2>Below is the data which will enable a MIME compliant =
mail reader</FONT>

<BR><FONT SIZE=3D2>implementation to automatically retrieve the ASCII =
version of the</FONT>

<BR><FONT SIZE=3D2>Internet-Draft.</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_001_0010_01C969B9.45EBFE50--

------=_NextPart_000_000F_01C969B9.45EBFE50
Content-Type: Message/External-body;
	name="draft-zorn-radius-pkmv1-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-zorn-radius-pkmv1-01.txt"

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

------=_NextPart_000_000F_01C969B9.45EBFE50
Content-Type: text/plain;
	name="ATT00016.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00016.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------=_NextPart_000_000F_01C969B9.45EBFE50--

------=_NextPart_000_0015_01C969B9.45EF0B90--

--
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, 29 Dec 2008 03:11:03 +0000
From: Bernard Aboba <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: philosophy of the Design Guidelines document
Date: Sun, 28 Dec 2008 19:09:47 -0800

"There are more things in
heaven and earth=2C Horatio=2C

Than are dreamt of in your philosophy."=20
WILLIAM SHAKESPEARE / Hamlet Act 1.
Scene V abt. 1601
> No. I am asking for considering the needs of some of the other usage envi=
ronments as well.

At the risk of offending Shakespeare=2C perhaps its time to talk about the =
philosophy of the Design
Guidelines document.=20

The Design Guidelines document has two major aspects to it:

  1. Articulating Design Guidelines for RADIUS standard attributes (e.g. no=
t Extended Attributes).=20
  2. Improving the efficiency and scalability of the standardization proces=
s for RADIUS attributes=2C
    both within the IETF as well as in other SDOs.=20

Through aspects #1 and 2=2C the goal is to be able to address a wide range =
of needs in an
efficient way. =20

> If you believe that different requirements may lead to different results =
then you are essentially with me.

By recognizing the unique needs of SDOs=2C and by establishing a new proces=
s for the creation and
review of RADIUS attribute document=2C the Design Guidelines document would=
 seem
to be in agreement with this philosophy.=20

For example=2C the Design Guidelines document=2C by articulating the RADIUS=
 Design Guidelines=2C
allows=2C and even *encourages* SDOs to create their own RADIUS attribute s=
pecifications. =20
As we learned in the process of developing RFC 4663 (and also to some exten=
t after long=20
experience with RFC 3427)=2C it is becoming increasingly difficult for SDO =
participants to attend=20
both SDO and IETF meetings in order to complete management (MIB or AAA) doc=
ument. =20
These documents are more efficiently done in only one SDO=2C and if the doc=
ument doesn't=20
involve protocol changes=2C  then the work can most efficiently be done out=
side the IETF.=20

So=2C as I read it=2C the goal of the Design Guidelines document isn't to l=
ead to further ossification
of the IETF process  -- but rather to a more productive and cooperative rel=
ationship
between the IETF and SDOs.   For example. the guidelines on complex attribu=
tes only=20
apply to the RADIUS standard attribute space=2C not to the Extended Attribu=
te space=2C or=20
to SDO-Specific attributes.   So as I read it=2C the document isn't saying =
"you can't do=20
this for an SDO-specific purpose"=2C but rather=2C "if you wish to create a=
ttributes that are=20
unlikely to be widely deployed outside your SDO=2C do so using SDO-specific=
 attributes=20
so as to to minimize impact on existing implementations".=20

The overall philosophy that the IETF needs to focus its energy on the
*intersection* of requirements (including those from SDOs)=2C not on the *u=
nion*
of requirements.  At the same time=2C the IETF needs to provide the mechani=
sms
by which SDOs that need work done can do that work themselves.  In principl=
e
this approach enables design coherence to be maintained while at the same t=
ime
getting the IETF out of the critical path for much of the work that the SDO=
s need
to get done.=20

> At least I am asking to capture these aspects in the draft as there are
> really two types of complex attributes=2C namely those captured with the
> RADIUS extended attributes draft and then more complex onces that can be
> found also in the Diameter space. Reading through the draft one could eas=
ily
> get the impression that that document now allows the Diameter AVP structu=
re
> to be easily supported=2C which is not true.

Discussion of Extended Attribute design is out of scope of the Design Guide=
lines
document.  However=2C it *is* in scope for the Extended Attributes document=
.  So
I think you are pointing out an issue with the Extended Attributes document=
 here.=20

> It is fine not to align it 100% with Diameter. I just want the difference=
s
> to be documented in the document.

This is indeed a valid concern -- with respect to the Extended Attributes d=
ocument.=20

> Using a dictionary based approach is not a bad thing and will work for ma=
ny
> cases. The question is only how powerful the language for the dictionary =
has to be.
> It could be just a "attribute name"=2C "attribute code" and "data type".
>
> Regarding the "data type: Looking at the dictionary provided with FreeRAD=
IUS
> I noticed that there are datatypes support that are not listed in the RAD=
IUS
> Design Guidelines document.

By looking at all existing RADIUS implementations=2C I am sure we could fin=
d=20
support for a considerable number of additional data types.  However=2C the
question being considered by this document is not "what is the union of
all implemented RADIUS datatypes"=2C but rather "what is the likely=20
intersection of data types used in RADIUS standard attributes". =20
That question has been answered by examining existing RADIUS RFCs.=20

However=2C the question of addition of data types *would* be relevant
to the Extended Attributes document=2C where presumably we are not
as concerned with backward compatibility.=20

> BUT:
>
> * If I take certain Diameter documents and I want to provide the
> same/similar functionality in RADIUS then I cannot use the "simple"
> attribute encoding. Example: Diameter QoS attribute. In that case I have =
to
> come up with my own RADIUS attribute encoding for this purpose.

I do think this is a useful question to consider -- but I think that questi=
on
should be considered in the context of the Extended Attributes document=2C
not the Design Guidelines document.=20

> Even though these cases seem to be implicitly covered by the RADIUS desig=
n
> guidelines document I still got beaten up with the RADIUS GEOPRIV documen=
t.

If you have suggestions for clarifying the language=2C feel free to submit =
an issue.=20
However=2C in general=2C IETF beatings do not have to be linked to an offen=
se=2C real
or imagined.  Rather the general philosophy seems to be "beatings will cont=
inue
until morale improves". :)

> I believe there is value in documenting what the perceived mode of operat=
or
> for a protocol is.

Sure.  The WMF has produced hundreds=2C even thousands of pages of
documentation=2C most of which is publicly available.  That they have
been able to utilize RADIUS for this purpose without changing the
protocol seems like a good example of the approach advocated by
the Design Guidelines document.=20

> I think that's a Very Bad Idea (tm) and falls under the recommendation ag=
ainst
> polymorphic attribute design.

It should be noted that the Design Guidelines document is a BCP=2C and the
IETF is not the protocol police.  As a result=2C  SDOs are free to create
polymorphic attributes within their SDO-specific attribute spaces.  =20

>I believe that the argument that complex
>attributes lead to interoperability=2C deployment and security
>issues as stated in the draft is incorrect and can of course happen
>from certain implementation choices.

I would agree that a greenfield implementation could indeed support
a wider range of attribute complexity with little ill effects.  For example=
=2C
most Diameter implementations support a considerably wider range
of data types=2C grouping formats=2C etc. than most RADIUS implementations
do=2C because they were designed from the start to do this.

Where greenfield capabilities are being created (such as in the Extended
Attributes work)=2C these arguments can and should be entertained.  However=
=2C
where we are talking about a protocol with dozens of legacy implementations=
=2C
the bar is set much higher=2C because the WG not only has to take into=20
account the interests of those who want to do new things=2C but also the
impact on existing deployments.  Manding a forklist upgrade for existing
RADIUS servers which may be long off maintenance in order to add modest
new capabilities is not something that network administrators will apprecia=
te.=20

> As an example: Consider the work in the NEA working group that has an imp=
act
> to the AAA server. Simple? Not really. Will people use and deploy it? Who=
 knows.

As far as I can tell=2C the "statements of health"/"posture attributes"
that are being designed in NEA WG fit within the "opaque blob" concept
articulated in the Design Guidelines document.  That is=2C there is no requ=
irement
that a AAA server not implementing NEA change a single line of code. =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: Sun, 28 Dec 2008 04:20:14 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Hannes Tschofenig'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>, "'D. B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Sun, 28 Dec 2008 11:17:52 +0700

Hannes Tschofenig [mailto:[email-masked]] writes:

...

> Instead, I am asking for something different. I would like to have a
> bit more reality touch 

I wish you luck, but I'm afraid you're in the wrong WG for 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, 27 Dec 2008 22:59:12 +0000
Date: Sat, 27 Dec 2008 17:58:36 -0500
From: "Greg Weber" <[email-masked]>
To: "D. B. Nelson" <[email-masked]>
Subject: Re: Question regarding draft-ietf-radext-design-05.txt
Cc: [email-masked]

On Sat, Dec 27, 2008 at 5:02 PM, D. B. Nelson <[email-masked]> wrote:
> Greg Weber writes...
>
>> ...I'd like to remind that the original submission of the
>> Design Guidelines was back in July '05...
>
> True enough.  As I've said very recently, the debate over complex attributes
> dates all the way back to the chartering of RADEXT.

I've read all the recent list traffic, but I'm not sure it's fair to
characterize this as an SDO run-around as opposed to a
failure of IETF process.  So, I'd be a bit careful about 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, 27 Dec 2008 22:32:15 +0000
From: "D. B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Sat, 27 Dec 2008 17:32:17 -0500

Hannes Tschofenig writes...

> Given the available data types this was essentially the only 
> choice to comply with the idea of the data dictionary and the
> desire to have everything be covered under the available data
> types.

Yes.  The current RADIUS data types are very limiting, in that they
represent only scalars and octet arrays (strings).  I once suggested that we
try to address this in a fashion similar to the way SMI (SNMP) handles this
issue, i.e. to allow sequences of basic types to be encoded in an attribute
to form a complex type.  That went over like a lead balloon. :-(

> Whether the AAA server had to be updated in order to provide
> additional parsing capability depends a lot on the procedure how
> some of these attributes (and the values in them) get introduced
> into the system in the first place.

Sure.  The problem is, I suspect, that if one developer gets to standardize
attributes that were designed based on _his_ server implementation, that may
have impact on everyone else whose server is implemented differently.  What
turns out to be a natural encoding representation for a given implementation
/ system design may be cumbersome for another design, even though both are
fully "compliant" with the feature requirements.  Standards have to serve
the least (reasonable) common denominator.

--
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, 27 Dec 2008 22:02:37 +0000
From: "D. B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Sat, 27 Dec 2008 17:02:20 -0500

Greg Weber writes...

> ...I'd like to remind that the original submission of the 
> Design Guidelines was back in July '05...

True enough.  As I've said very recently, the debate over complex attributes
dates all the way back to the chartering of RADEXT.

> And the SDOs have business issues that must be addressed in
> a more timely fashion.

This is more an issue of style that substance.  The work could easily have
been done in "classic" RADIUS attributes, albeit less elegantly.  There's a
school of AAA design style that wants to encapsulate the complex C-language
(or similar) "structs" that are used in the client and server code into
RADIUS attributes, as if RADIUS were some form of RPC mechanism.  :-)  The
debate is about whether or not that's a good idea.  It's certainly a valid
design approach -- the question is whether or not it fits well within
RADIUS.  If you view RADIUS as little more that a convenient transport for
application data, maybe it does.

--
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, 27 Dec 2008 21:33:22 +0000
Date: Sat, 27 Dec 2008 16:32:56 -0500
From: "Greg Weber" <[email-masked]>
To: "D. B. Nelson" <[email-masked]>
Subject: Re: Question regarding draft-ietf-radext-design-05.txt
Cc: [email-masked]

On Sat, Dec 27, 2008 at 4:09 PM, D. B. Nelson <[email-masked]> wrote:
> Yeah.  Some of the folks in WiMAX were among those who were early advocates
> of deeply complex attribute encodings in RADIUS.  When the RADEXT WG didn't
> embrace that design philosophy, the work got done outside the IETF.  If you
> don't like the consensus you find here, you take the work elsewhere.  :-)

I'm not sure if that accurately captures the chronological sequence of events,
but I'd like to remind that the original submission of the Design Guidelines
was back in July '05;  three & a half years back.
The WG has had trouble embracing _any_ design philosophy.
And the SDOs have business issues that must be addressed in a more
timely fashion.

--
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, 27 Dec 2008 21:21:31 +0000
From: "D. B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: FW: [Fwd: Question regarding draft-ietf-radext-design-05.txt.]
Date: Sat, 27 Dec 2008 16:21:29 -0500

Alan DeKok writes...

>> My immediate suggestion: Don't put a RADIUS / Diameter compatibility
>> considerations section into the document as it is almost always wrong. 
>
>  I'll have to ask the chairs about this...

<Chair Hat = on>

I don't think it's OK to simply "punt" on Diameter interoperability
considerations in RADIUS extensions work.  It's in the RADEXT charter, for
good reason.

I agree that the boilerplate text we've been using recently is flawed.  It's
not enough to effectively say "just follow NASreq".  There are a number of
issues to address, with complex AVP encoding and Application IDs being top
of mind.  It seems to me that the authors so RFC 4005 thought about
importing all of the RADIUS attributes that existed at the time that
document was published under the NASreq Application ID, but not about future
RADIUS extensions.  The whole mandatory attributes vs. new application IDs
thing is a major headache that, IMHO, DIME needs to solve.

We need tome assistance from folks in DIME, and we may need them to create
an RFC 4005bis, or some such.

I don't think we can simply omit discussing Diameter compatibly and
interoperability.

If there is a good reason why Diameter interoperability (ease of gateway) is
not required for a given application area, then we can simply say that in
the document -- don't bother trying to import these attributes into
Diameter.

<Chair Hat = off>

--
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, 27 Dec 2008 21:09:59 +0000
From: "D. B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Sat, 27 Dec 2008 16:09:59 -0500

Alan DeKok writes...

>> Regarding the "data type: Looking at the dictionary provided
>> with FreeRADIUS I noticed that there are datatypes support that
>> are not listed in the RADIUS Design Guidelines document.
>
>  Yes.  One word: WiMAX.

Yeah.  Some of the folks in WiMAX were among those who were early advocates
of deeply complex attribute encodings in RADIUS.  When the RADEXT WG didn't
embrace that design philosophy, the work got done outside the IETF.  If you
don't like the consensus you find here, you take the work elsewhere.  :-)

--
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, 27 Dec 2008 20:44:31 +0000
From: "D. B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: FW: [Fwd: Question regarding draft-ietf-radext-design-05.txt.]
Date: Sat, 27 Dec 2008 15:44:13 -0500

Alan DeKok writes...

>>> "Can lead ...".  The text is describing common practices and 
>>> deployments.  The only reason to change the text is if those 
>>> practices are not, in fact, in common use.
>> 
>> But these type of statements are used against draft authors who
>> decided to pick a different format and then we have all these
>> discussions. 
>> 
>> I think it would be useful to provide a bit more context, as 
>> argued a few paragraphs above. 
>
>  Ok.  We should be able to make it clearer that the opinions
> against complex attributes are SHOULD NOT.

Hmmm...  Two thoughts on this:

(1) Since the Design Guidelines are to be a BCP, guidance about design
choices, short of a major security flaw or a redesign of the RADIUS base
protocol, will end up being a SHOULD or SHOULD NOT.  MUST and MUST NOT will
be rare.

(2) At some level, RADIUS Design Guidelines will likely be as popular with
certain developers as corporate coding style guidelines.  :-)  That's the
nature of the beast.  Having said that, if the guidelines value everyone's
individual design styles equally, then the guidelines serve no purpose.  The
value in creating a RECOMMENED design style is in achieving a certain level
of uniformity.  There is a fine balance to be struck between standardization
and creative expression.

--
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, 27 Dec 2008 19:33:25 +0000
From: "Hannes Tschofenig" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, "'D. B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Sat, 27 Dec 2008 21:32:45 +0200

Hi Bernard, 

Maybe I was misunderstood. 

I am not asking for RADIUS to become Diameter (even though the group is
heading into that direction in a step-by-step fashion already). 

Instead, I am asking for something different. I would like to have a bit
more reality touch regarding what can be done with the encoding in RADIUS
today and where custom encoding is necessary. 

To give you an example: Some time back when RFC 4675 was written it was
state-of-the-art to define an attribute as:

User-Priority-Table

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

Where 'String' represented a customing encoding. Other attributes in the
same document followed the same format. 

Given the available data types this was essentially the only choice to
comply with the idea of the data dictionary and the desire to have
everything be covered under the available data types. 

The dictionary might look like: 

ATTRIBUTE      User-Priority-Table     59         String 

Today, the encoding of RFC 4675 might quite likely be different and there is
still a lot of possibility to argue around why this is still a good
encoding. 

Whether the AAA server had to be updated in order to provide additional
parsing capability depends a lot on the procedure how some of these
attributes (and the values in them) get introduced into the system in the
first place. In some systems they might be statically provisioned into a
database and just retrieved without any additional logic and in other
systems they would be dynamically generated and there might be some logic
behind all this stuff. 

Now, the extended attributes draft extends the limits a bit. 

Still, there is this tendency to label custom encoding (like the one from
above) as really bad (by calling it "interoperability and deployment issues"
or see the discussion in Section 2.1.4 of draft-ietf-radext-design-05.txt
regarding "Complex Attributes and Security"). 

I guess nobody would argue that attributes that can have a simple encoding
are supposed to get unnecessarily complex. 

However, I would like to present the story in a way that custom encoding is
a side-effect of the design constraints that are introduced by the work the
group did. If you want something that does not fall into the "simple scheme"
(which btw happens quite often these days) then a custom encoding is more
difficult to avoid. 

There is nothing bad about this. The reason for this is largely based on the
fact that implementers have seen custom encoding already for a while and
hence they have found ways to deal with it.

Maybe what I should be doing is to go through the RADIUS Design Guidelines
draft and to make detailed text proposals to make it clearer what I actually
mean. 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Bernard Aboba
>Sent: 27 December, 2008 00:18
>To: 'D. B. Nelson'; [email-masked]
>Subject: RE: Question regarding draft-ietf-radext-design-05.txt
>
>"I think that the basic issues here is that there is a 
>disconnect between the consensus position of the RADEXT WG (to 
>keep things pretty simple) and need you are describing to 
>provide [near] capability parity with Diameter."
>
>To quote the conclusions of the AAA protocol Evaluation team 
>(RFC 3127) with
>
>respect to the prospects for enhancing RADIUS so as to meet the AAA
>requirements:
>
>"  Radius++ is not considered acceptable as an AAA protocol.  
>There is a
>   fairly substantial amount of engineering required to make 
>it meet all
>   requirements, and that engineering would most likely result in
>   something close to the functionality of Diameter." 
>
>Indeed, at various points with the RADEXT WG, questions have 
>come up relating to adoption of one or more features of 
>Diameter, and WG consensus has lined up with the RFC 3127 assessment:
>
>1) during the discussion on Extended Attributes, the question 
>arose as to whether RADIUS should adopt the Diameter AVP 
>format.  The WG consensus was against this, and as a result 
>only modest extensions (for tagging and additional attribute 
>space) were adopted. 
>
>2) during the transport work, questions have arisen about the 
>suitability of the RFC 3539 watchdog timer and failover logic. 
> Again, WG sentiment does not appear to support a strict port 
>of the Diameter functionality to RADIUS.  
>
>So while it is possible (and potentially desirable) for RADEXT 
>to develop enhancements (such as Extended Attributes and 
>RADSEC), this falls considerably short of providing the full 
>functionality of Diameter. 
>
>
>
>
>
>
>--
>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, 27 Dec 2008 16:07:24 +0000
Date: Sat, 27 Dec 2008 17:07:12 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: 'Glen Zorn' <[email-masked]>,  "'David B. Nelson'" <[email-masked]>, [email-masked]
Subject: Re: Issues with draft-ietf-radext-extended-attributes-05.txt

Bernard Aboba wrote:
> There are multiple issues here, I think:
> 
> a. Whether existing implementations will have a problem with a vendor-id
> of zero, regardless of the size of the type code space, and the attribute
> numbering;  

  I can think of at least one that does.  I'm not sure anyone else is
going to admit that their implementation is less than perfect. :)

> b. Whether the *combination* of a vendor-id of zero along with attribute
> usage 1-255 can cause problems; 
>
> If we have problem a, then the fix would be to assign the IETF a non-zero
> Vendor-Id; merely prohibiting attributes 1-255 would not do the trick. 
> 
> If we only have problem b, then we could prohibit attributes 1-255 from
> being assigned. 

  That would be the solution with the minimum changes.

  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: Sat, 27 Dec 2008 16:06:10 +0000
Date: Sat, 27 Dec 2008 17:05:19 +0100
From: Alan DeKok <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
CC: [email-masked]
Subject: Re: FW: [Fwd: Question regarding draft-ietf-radext-design-05.txt.]

Hannes Tschofenig wrote:
>>  Yes.  Some RADIUS servers also support complex attribute 
>> decoding through simple scripting languages.  But this has not 
>> been historically wide-spread.
> 
> These assumptions have been built-into the draft and it would be good to be
> explicit what type of RADIUS server you are talking about when you argue
> that complex attributes lead to implementation, deployment and security
> problems. This may very well be true be true for some of these servers but
> certainly not true for many others. Maybe these older servers don't even
> care about the functionality we are specifying today. 

  That's a good point.

  Can you suggest updated text for the draft?

> My immediate suggestion: Don't put a RADIUS / Diameter compatibility
> considerations section into the document as it is almost always wrong. 

  I'll have to ask the chairs about this...

>> "Can lead ...".  The text is describing common practices and 
>> deployments.  The only reason to change the text is if those 
>> practices are not, in fact, in common use.
> 
> But these type of statements are used against draft authors who decided to
> pick a different format and then we have all these discussions. 
> 
> I think it would be useful to provide a bit more context, as argued a few
> paragraphs above. 

  Ok.  We should be able to make it clearer that the opinions against
complex attributes are SHOULD NOT.

>>>> Btw, has the draft been sent to other SDOs for review?
>>  Suggestions?
> Almost all the major SDOs have to deal with RADIUS in some form:
> Wimax Forum, Broadband Forum, 3GPP, 3GPP2, CableLabs

  I think the chairs should ask for official statements from the other SDOs.

  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: Sat, 27 Dec 2008 14:15:43 +0000
Date: Sat, 27 Dec 2008 15:14:52 +0100
From: Alan DeKok <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
CC: "'D. B. Nelson'" <[email-masked]>, [email-masked]
Subject: Re: Question regarding draft-ietf-radext-design-05.txt

Hannes Tschofenig wrote:
> Two examples: 
> 
> * EAP Channel Bindings: I mentioned that I was not able to find anyone in
> the cellular industry that was interested in this. 
> Does it mean that the work will not be done? No, because folks argue that in
> the university space and enterprise environment it could be useful. 

  The WiFi roaming people are interested in this.  It permits them to
extend the enterprise environment across global roaming consortia.

> * TLS and TCP for RADIUS: Most folks in the cellular space don't care about
> this because they are specifying Diameter all over the place. 
> As we have learned, folks working at the universities have different
> constraints and needs (e.g., using software that is downloadable for free
> from the Internet as a basis for their AAA deployment). As such, they like
> this new work as it will solve their problem without switching to commercial
> solutions or to switch to OpenDiameter etc. 

  The WiFi roaming people are also interested in this, especially to
simplify connections (avoiding IPSec), and to minimize lost packets in
EAP sessions.

>> Otherwise, why maintain both AAA protocols going forward.  :-)
> 
> There are many reasons -- none of them have anything todo with technical
> arguments. 

  "Install base". :)

> Using a dictionary based approach is not a bad thing and will work for many
> cases. 
> The question is only how powerful the language for the dictionary has to be.
> It could be just a "attribute name", "attribute code" and "data type".  
> 
> Regarding the "data type: Looking at the dictionary provided with FreeRADIUS
> I noticed that there are datatypes support that are not listed in the RADIUS
> Design Guidelines document.

  Yes.  One word: WiMAX.

> Additionally, FreeRADIUS support some form of scripting also in addition the
> to the dictionary, see http://wiki.freeradius.org/Configuration. 

  It has a simple policy language that is not Turing complete.  The
policy language also cannot (currently) decode attributes of complex
format.  The data types are still dictionary driven.

> I believe there is value in documenting what the perceived mode of operator
> for a protocol is. 

  I agree.

> Folks use the protocol they are familiar with for their favorite purpose
> (even if it has nothing todo with AAA anymore). There are certain groups
> that are more familiar with RADIUS and other's that bought into Diameter. It
> is just a protocol and both of them are not difficult to implement. 

  Hmm.... I would beg to differ. But that's not part of this discussion.

> Well. I would like to hear from other folks in the group whether they think
> RADIUS server implements deployed in larger networks are so simple.

  Yes.

> A
> Diameter implementation can also be pretty simple if you don't make use of
> certain features and extensions. 

  No opinion... I lack sufficient experience.

> As such, this is very little todo with the protocol itself rather with the
> features that folks want to accomplish. 
> 
> As an example: Consider the work in the NEA working group that has an impact
> to the AAA server. Simple? Not really. Will people use and deploy it? Who
> knows. 

  NEA is complicated.  See the NEA list archives for my opinions.

  That being said, it will likely get implemented... like WiMAX.

  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: Sat, 27 Dec 2008 11:25:07 +0000
From: "Hannes Tschofenig" <[email-masked]>
To: "'D. B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Sat, 27 Dec 2008 13:24:23 +0200

Hi David, 

>Hannes Tschofenig writes...
>
>>> The issue is whether extensions to the RADIUS on-the-wire protocol 
>>> should be designed to accommodate the traditional, 
>>> data-dictionary-driven RADIUS server, or not.  I think what we are 
>>> saying is that, while complex RADIUS server implementations exist, 
>>> RADIUS protocol enhancements should not be at the expense of the 
>>> simple implementations.
>> 
>> I think it is not a question of simple or complex implementation.
>> The main issue is what the specific customers want. AAA servers are 
>> used by different clusters of customers (different types of 
>> enterprises, WLAN hotspots, universities, ISPs, cellular operators, 
>> etc). These customers have different needs but the guidelines do not 
>> acknowledge that there are different classes of customers and hence 
>> the design guidelines are often applied without considering 
>these aspects.
>
>Certainly there are different classes of customers, different 
>market segments, different use cases, etc.  Does that mean 
>that the protocol has to differ to address each?

No. I am asking for considering the needs of some of the other usage
environments as well. 

>IMHO, that's 
>not a formal "protocol" if it differs depending on who's using 
>it.  The syntax, i.e. message format, of a protocol needs to 
>be invariant; only the content of the messages should be variable.

I am not sure I fully understand what you are saying. 

If you believe that different requirements may lead to different results
then you are essentially with me. 

Two examples: 

* EAP Channel Bindings: I mentioned that I was not able to find anyone in
the cellular industry that was interested in this. 
Does it mean that the work will not be done? No, because folks argue that in
the university space and enterprise environment it could be useful. 

* TLS and TCP for RADIUS: Most folks in the cellular space don't care about
this because they are specifying Diameter all over the place. 
As we have learned, folks working at the universities have different
constraints and needs (e.g., using software that is downloadable for free
from the Internet as a basis for their AAA deployment). As such, they like
this new work as it will solve their problem without switching to commercial
solutions or to switch to OpenDiameter etc. 

>
>> I believe I can say that because I was a victim of "strictly 
>applying"
>> the guidelines as they are, despite the examples provided in the 
>> document on EAP etc.
>
>This harkens back to the age old debate on whether RADIUS 
>should provide facilities to encode complex / structured data. 
> This debate is as old as
>the RADEXT WG itself.   The current RADEXT WG consensus is that RADIUS
>doesn't need extensive "structuring" facilities, and that the 
>simple "grouping" facilities, e.g. of the Extended Attributed 
>draft, is sufficient.

At least I am asking to capture these aspects in the draft as there are
really two types of complex attributes, namely those captured with the
RADIUS extended attributes draft and then more complex onces that can be
found also in the Diameter space. Reading through the draft one could easily
get the impression that that document now allows the Diameter AVP structure
to be easily supported, which is not true. 

>Yes, this is far short of Diameter's capabilities, but we 
>decided that RADIUS should not be extended to maintain feature 
>parity with Diameter.

It is fine not to align it 100% with Diameter. I just want the differences
to be documented in the document. 

>Otherwise, why maintain both AAA protocols going forward.  :-)

There are many reasons -- none of them have anything todo with technical
arguments. 

>
>>>> I am not even sure that it is always the right way to put such a 
>>>> section in a RADIUS document when they authors do not envision 
>>>> Diameter to be used in their specific environment.
>>>
>>>What do you suggest?
>>
>> Based on the discussion we had at the AAA doctors meeting I 
>will think 
>> about some way forward.
>
>Thanks!
>
>>> Please elaborate...
>>
>> The above statement makes the assumption that the parsing happens in 
>> some C-alike language that was used to implement the entire RADIUS 
>> server. There are indeed issues when you touch this code.
>>
>> However, most AAA servers have an abstract language they use for 
>> handling of msg processing. This language is typically not C and 
>> written in a way that it does not lead to security issues. As such, 
>> even additional parsing that has to be implemented it does 
>not lead to 
>> any interoperability or security problems.
>
>Hmmm...  "Most"?  The metric we have been using is the "data 
>dictionary driven" server, which is admittedly a fairly old 
>implementation technique.

Using a dictionary based approach is not a bad thing and will work for many
cases. 
The question is only how powerful the language for the dictionary has to be.
It could be just a "attribute name", "attribute code" and "data type".  

Regarding the "data type: Looking at the dictionary provided with FreeRADIUS
I noticed that there are datatypes support that are not listed in the RADIUS
Design Guidelines document.

Additionally, FreeRADIUS support some form of scripting also in addition the
to the dictionary, see http://wiki.freeradius.org/Configuration. 

>Such servers may have auxiliary "policy servers" that make 
>more complex decisions about authorization data than is 
>possible with simple attribute matching schemes or user group 
>membership schemes.  The relevant point of discussion, 
>however, is the on-the-wire RADIUS message format.

I am not saying that everyone should come up with the most complex attribute
formats. 
If one can avoid a custom attribute format then this is certainly
appreciated as it will lower the time it takes to implement a specific
functionality.

BUT: 

* If I take certain Diameter documents and I want to provide the
same/similar functionality in RADIUS then I cannot use the "simple"
attribute encoding. Example: Diameter QoS attribute. In that case I have to
come up with my own RADIUS attribute encoding for this purpose. 

* If I have features that already require additional code at the AAA server
(like the location stuff) then it does not make a big difference whether I
have to write a few lines more or less -- I have to touch the code base
already anyway. 

Even though these cases seem to be implicitly covered by the RADIUS design
guidelines document I still got beaten up with the RADIUS GEOPRIV document. 

>
>RADIUS was designed to provision pretty simple things.  It 
>originally envisioned each attribute as having an "atomic" 
>value, not some complex, structured message.  I understand 
>that AAA servers today attempt to provision more complex 
>things, and this is wherein the friction results.
>Should RADIUS be extended, much as Diameter has, to support a 
>more complex and nuanced set of provisioning capabilities? 

RADIUS has already been extended to provide more than "simple things". 
Example: Key distribution in Wimax. 

I believe there is value in documenting what the perceived mode of operator
for a protocol is. 

> If 
> so, then why do we need Diameter? :-)

Folks use the protocol they are familiar with for their favorite purpose
(even if it has nothing todo with AAA anymore). There are certain groups
that are more familiar with RADIUS and other's that bought into Diameter. It
is just a protocol and both of them are not difficult to implement. 

So, I don't see a problem with regard to this aspect. 

>
>>> So, what you are suggesting is that the syntax and semantics of 
>>> RADIUS attributes are contextually dependent on some policy 
>decision 
>>> that is opaque to the RADIUS client, proxies, etc?  I think 
>that's a 
>>> Very Bad Idea (tm) and falls under the recommendation against 
>>> polymorphic attribute design.
>>
>> No, my argument is different. I believe that the argument 
>that complex 
>> attributes lead to interoperability, deployment and security 
>issues as 
>> stated in the draft is incorrect and can of course happen 
>from certain 
>> implementation choices.
>
>I see.  I guess I still disagree.  Yes, anything, no matter 
>how complex, convoluted and baroque can be made to 
>interoperate with sufficient attention to detail.  A pig, 
>given sufficient thrust, can be made to fly.  :-)
>
>> Most AAA server do not have these issues as they are providing an 
>> abstract language for the developer for business logic, parsing, msg 
>> handling, etc.
>
>So, you're saying that today's AAA Servers are really Policy Servers?

Yes. 

>
>I think that the basic issues here is that there is a 
>disconnect between the consensus position of the RADEXT WG (to 
>keep things pretty simple) and need you are describing to 
>provide [near] capability parity with Diameter.  
Well. I would like to hear from other folks in the group whether they think
RADIUS server implements deployed in larger networks are so simple. A
Diameter implementation can also be pretty simple if you don't make use of
certain features and extensions. 
As such, this is very little todo with the protocol itself rather with the
features that folks want to accomplish. 

As an example: Consider the work in the NEA working group that has an impact
to the AAA server. Simple? Not really. Will people use and deploy it? Who
knows. 

Ciao
Hannes

>
>
>
>--
>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, 26 Dec 2008 23:26:11 +0000
From: "D. B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 290
Date: Fri, 26 Dec 2008 18:25:44 -0500

Bernard Aboba writes...

> Is there an IETF last call comment on the Guidelines document relating
> to this?

Yes.  I believe Hannes raised the issue.  Maybe others.

> Since Extended Attributes uses Attribute 26, I had assumed that it
> inherits all the capabilities of that attribute.

Yes and no.  Basically, RFC 2865 allows VSAs to contain _anything_ in the
"value" portion of the attribute that will fit into 253 (more or less)
octets.  There is a recommended format, and multiple instances in the
recommended format may be included, but so may anything else.

For the purpose of the Extended Attribute, I think we absolutely must
retract the "but so may anything else" portion, and stick to the format as
defined in the Extended Attributes draft.

Of course, I suppose that one could have a Vendor Specific 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: Fri, 26 Dec 2008 22:18:23 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'D. B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Fri, 26 Dec 2008 14:17:51 -0800

"I think that the basic issues here is that there is a disconnect between
the
consensus position of the RADEXT WG (to keep things pretty simple) and need
you are describing to provide [near] capability parity with Diameter."

To quote the conclusions of the AAA protocol Evaluation team (RFC 3127) with

respect to the prospects for enhancing RADIUS so as to meet the AAA
requirements:

"  Radius++ is not considered acceptable as an AAA protocol.  There is a
   fairly substantial amount of engineering required to make it meet all
   requirements, and that engineering would most likely result in
   something close to the functionality of Diameter." 

Indeed, at various points with the RADEXT WG, questions have come up
relating
to adoption of one or more features of Diameter, and WG consensus has lined
up
with the RFC 3127 assessment:

1) during the discussion on Extended Attributes, the question arose
as to whether RADIUS should adopt the Diameter AVP format.  The WG
consensus was against this, and as a result only modest extensions
(for tagging and additional attribute space) were adopted. 

2) during the transport work, questions have arisen about the
suitability of the RFC 3539 watchdog timer and failover logic.  Again,
WG sentiment does not appear to support a strict port of the
Diameter functionality to RADIUS.  

So while it is possible (and potentially desirable) for RADEXT to
develop enhancements (such as Extended Attributes and RADSEC), this 
falls considerably short of providing the full functionality of 
Diameter. 

--
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, 26 Dec 2008 21:53:52 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'D. B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Issue 298
Date: Fri, 26 Dec 2008 13:53:31 -0800

David Nelson said:

"I think we want to be very careful here.  The correct behavior for
implementations that have not included the Extended Attribute =
functionality
is to treat them as unrecognized / unknown VSAs, and to ignore them.  =
They
may be logged in some fashion, of course.  Whether they should be =
included
in RADIUS Accounting or Dynamic RADIUS packets as "unknown attributes" =
is
open to debate.

What I think should not happen is for Extended Attributes to be
"selectively" understood.  The implementation either "groks" the =
Extended
Attribute format, in which case the rules for standard attributes (or =
SDO
Specific Attributes) apply, or it simply sees them as unrecognized / =
unknown
VSAs, in which case the rules for unknown attributes apply.  We should =
not
encourage implementations to treat them as unknown for one purpose but =
known
for another."

[BA] Very well put.  Care to take a shot at providing text to resolve =
the
issue?

> So one question is whether this implies that a NAS should signal its
> support for Extended Attributes in the Access-Request in some way --=20
> so as to make it clear to the RADIUS server how those attributes would
> be interpreted.=A0=A0

I think we should make that feature a MUST.

[BA] That seems sensible to me.  The question is how to do it.  Maybe
include
an Extended Attribute of Type 1 with a NUL in it within an =
Access-Request?

--
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, 26 Dec 2008 21:51:38 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'D. B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Issue 290
Date: Fri, 26 Dec 2008 13:51:14 -0800

David Nelson said:

"Would that be a RADEXT or DIME work item?"

It would probably be a DIME WG work item, assuming that they are willing to
take it.
However, before making progress on that we would need a viable proposal (and
a document 
that references it). 

David Nelson also said:

"There is a larger issue here, currently being discussed as part of the
RADIUS Design Guidelines commentary."

Is there an IETF last call comment on the Guidelines document relating to
this? 
I've been trying to keep the tracker up to date on the last call issues, but
I suspect I may be missing some. 

"I think we need to nail down that issue before we can effectively
close on the Design Guidelines and Extended Attributes drafts"

Since Extended Attributes uses Attribute 26, I had assumed that it
inherits all the capabilities of that attribute.  RFC 2865, Section
5.26 says:

      Multiple subattributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be.

--
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, 26 Dec 2008 21:42:55 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'Glen Zorn'" <[email-masked]>, "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Issues with draft-ietf-radext-extended-attributes-05.txt
Date: Fri, 26 Dec 2008 13:42:02 -0800

Alan DeKok said:

"I was thinking also API's.  Some systems have internal API's that
add/delete/lookup attributes based on a key.  The key is (vendor-id,
attribute).  The problem is that looking up traditional RFC attributes
is often done by setting vendor-id=0.

  If we allow vendor-id to be zero, AND allow attributes 1..255 to mean
something new, this will cause problems for many implementations.

  Using 1..255 also prevents the grouping of standard RFC attributes
into the extended-attribute format, which was one of Glens goals."

There are multiple issues here, I think:

a. Whether existing implementations will have a problem with a vendor-id
of zero, regardless of the size of the type code space, and the attribute
numbering;  

b. Whether the *combination* of a vendor-id of zero along with attribute
usage 1-255 can cause problems; 

If we have problem a, then the fix would be to assign the IETF a non-zero
Vendor-Id; merely prohibiting attributes 1-255 would not do the trick. 

If we only have problem b, then we could prohibit attributes 1-255 from
being assigned. 

--
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, 26 Dec 2008 20:34:43 +0000
From: "D. B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 278
Date: Fri, 26 Dec 2008 15:34:41 -0500

Alan DeKok writes...
 
>  I was thinking also API's.  Some systems have internal API's that
> add/delete/lookup attributes based on a key.  The key is (vendor-id,
> attribute).  The problem is that looking up traditional RFC attributes
> is often done by setting vendor-id=0.

In hind sight, that was a very inconvenient thing for implements to have
done, although I can see its attraction in terms of abstracting properties
of various classes of attributes.

>  If we allow vendor-id to be zero, AND allow attributes 1..255 to mean
> something new, this will cause problems for many implementations.

I suggested at two different IETF meetings that using a Vendor ID of 0 might
be problematic.  I envisioned just this sort of scenario.  No one seemed to
see the same issues, since my suggestion gathered no support.  :-)  We could
revisit the use of 0 and assign some other, non-zero, PEN.

>  Using 1..255 also prevents the grouping of standard RFC attributes
> into the extended-attribute format, which was one of Glens goals.

Or we could reserve the legacy values 0..255.

--
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, 26 Dec 2008 20:17:13 +0000
From: "D. B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Fri, 26 Dec 2008 15:16:51 -0500

Hannes Tschofenig writes...

>> The issue is whether extensions to the RADIUS on-the-wire
>> protocol should be designed to accommodate the traditional,
>> data-dictionary-driven RADIUS server, or not.  I think what we 
>> are saying is that, while complex RADIUS server 
>> implementations exist, RADIUS protocol enhancements should not 
>> be at the expense of the simple implementations.
> 
> I think it is not a question of simple or complex implementation.
> The main issue is what the specific customers want. AAA servers are
> used by different clusters of customers (different types of enterprises,
> WLAN hotspots, universities, ISPs, cellular operators, etc). These
> customers have different needs but the guidelines do not acknowledge
> that there are different classes of customers and hence the design
> guidelines are often applied without considering these aspects.

Certainly there are different classes of customers, different market
segments, different use cases, etc.  Does that mean that the protocol has to
differ to address each?  IMHO, that's not a formal "protocol" if it differs
depending on who's using it.  The syntax, i.e. message format, of a protocol
needs to be invariant; only the content of the messages should be variable.

> I believe I can say that because I was a victim of "strictly applying"
> the guidelines as they are, despite the examples provided in the document
> on EAP etc. 

This harkens back to the age old debate on whether RADIUS should provide
facilities to encode complex / structured data.  This debate is as old as
the RADEXT WG itself.   The current RADEXT WG consensus is that RADIUS
doesn't need extensive "structuring" facilities, and that the simple
"grouping" facilities, e.g. of the Extended Attributed draft, is sufficient.
Yes, this is far short of Diameter's capabilities, but we decided that
RADIUS should not be extended to maintain feature parity with Diameter.
Otherwise, why maintain both AAA protocols going forward.  :-)

>>> I am not even sure that it is always the right way to put such a 
>>> section in a RADIUS document when they authors do not envision 
>>> Diameter to be used in their specific environment.
>>
>>What do you suggest?
>
> Based on the discussion we had at the AAA doctors meeting I will
> think about some way forward.

Thanks!

>> Please elaborate...
>
> The above statement makes the assumption that the parsing happens
> in some C-alike language that was used to implement the entire RADIUS 
> server. There are indeed issues when you touch this code.
>
> However, most AAA servers have an abstract language they use for
> handling of msg processing. This language is typically not C and 
> written in a way that it does not lead to security issues. As such,
> even additional parsing that has to be implemented it does not lead
> to any interoperability or security problems.

Hmmm...  "Most"?  The metric we have been using is the "data dictionary
driven" server, which is admittedly a fairly old implementation technique.
Such servers may have auxiliary "policy servers" that make more complex
decisions about authorization data than is possible with simple attribute
matching schemes or user group membership schemes.  The relevant point of
discussion, however, is the on-the-wire RADIUS message format.

RADIUS was designed to provision pretty simple things.  It originally
envisioned each attribute as having an "atomic" value, not some complex,
structured message.  I understand that AAA servers today attempt to
provision more complex things, and this is wherein the friction results.
Should RADIUS be extended, much as Diameter has, to support a more complex
and nuanced set of provisioning capabilities?  If so, then why do we need
Diameter? :-)

>> So, what you are suggesting is that the syntax and semantics 
>> of RADIUS attributes are contextually dependent on some policy 
>> decision that is opaque to the RADIUS client, proxies, etc?  I 
>> think that's a Very Bad Idea (tm) and falls under the 
>> recommendation against polymorphic attribute design. 
>
> No, my argument is different. I believe that the argument that
> complex attributes lead to interoperability, deployment and 
> security issues as stated in the draft is incorrect and can of
> course happen from certain implementation choices.

I see.  I guess I still disagree.  Yes, anything, no matter how complex,
convoluted and baroque can be made to interoperate with sufficient attention
to detail.  A pig, given sufficient thrust, can be made to fly.  :-)

> Most AAA server do not have these issues as they are providing an
> abstract language for the developer for business logic, parsing,
> msg handling, etc.

So, you're saying that today's AAA Servers are really Policy Servers?

I think that the basic issues here is that there is a disconnect between the
consensus position of the RADEXT WG (to keep things pretty simple) and need
you are describing to provide [near] capability parity with Diameter.  

--
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, 26 Dec 2008 19:36:30 +0000
From: "D. B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 298
Date: Fri, 26 Dec 2008 14:36:18 -0500

> Issue 298 -- This issue relates to whether Extended Attributes are
> treated like VSAs or not.=A0 For implementations of this document, the
answer
> is probably "no" -- they are treated like any other standard =
attribute.

I heartily agree!

> However, for implementations that don't support Extended Attributes,
> the answer is probably "yes" -- which has implications for=20
> Accounting-Responses (where VSAs are permitted, but few standard
attributes)
> and=A0Disconnect-Responses (where VSAs may only be used for session
identification).

I think we want to be very careful here.  The correct behavior for
implementations that have not included the Extended Attribute =
functionality
is to treat them as unrecognized / unknown VSAs, and to ignore them.  =
They
may be logged in some fashion, of course.  Whether they should be =
included
in RADIUS Accounting or Dynamic RADIUS packets as "unknown attributes" =
is
open to debate.

What I think should not happen is for Extended Attributes to be
"selectively" understood.  The implementation either "groks" the =
Extended
Attribute format, in which case the rules for standard attributes (or =
SDO
Specific Attributes) apply, or it simply sees them as unrecognized / =
unknown
VSAs, in which case the rules for unknown attributes apply.  We should =
not
encourage implementations to treat them as unknown for one purpose but =
known
for another.

> So one question is whether this implies that a NAS should signal its
> support for Extended Attributes in the Access-Request in some way --=20
> so as to make it clear to the RADIUS server how those attributes would
> be interpreted.=A0=A0

I think we should make that feature a MUST.

--
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, 26 Dec 2008 19:24:33 +0000
From: "D. B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 290
Date: Fri, 26 Dec 2008 14:24:32 -0500

> Issue 290 -- This relates to the issue of Diameter support for=20
> non-standard VSA formats (which this document now uses).=A0=A0 During =
IETF 73,
> we discussed one potential avenue for addressing this, which would be
> to update RFC 4005 to enable use of Diameter AVP 26 for translation of
> RADIUS VSAs of non-standard type.

Would that be a RADEXT or DIME work item?

There is a larger issue here, currently being discussed as part of the
RADIUS Design Guidelines commentary.  That issue revolves around the use =
of
complex / structured data in the value field of attributes, i.e. the V =
of
the TLV.  I think we need to nail down that issue before we can =
effectively
close on the Design Guidelines and Extended Attributes drafts, as well =
as
recommended practice for Diameter Compatibility and the related text =
that
should accompany the definition of new RADIUS [Extended] Attributes.  =
There
was discussion of this issue in the RADEXT and DIME WG meetings at =
IETF-73
and in the AAA Doctors lunch meeting.  Amazingly, this "larger issue" =
topic
has been hotly debated, on and off, as far back as the original =
discussion
on chartering RADEXT, back around time of IETF-56 (or so)!

I'll pick that discussion up in another thread.

Suffice it to say that the "consensus of record" of the RADEXT WG on =
this
issue does not address the interests and concerns of a handful of
individuals, who continue to make a case for more robust and rich
functionality regarding complex / structured 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: Fri, 26 Dec 2008 19:10:52 +0000
From: "D. B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 278
Date: Fri, 26 Dec 2008 14:10:38 -0500

> Issue 278 -- The remaining portion of this issue relates to whether
> IANA can allocate Extended Attributes 0-255, and if by doing so, 
> confusion would be created with respect to existing RADIUS attributes.

> In general, we have not seen confusion relating to use of VSAs with
> Type Code values which overlap the standards range (which most do).

I think that Extended Attributes (for implementations which _know_ that they
_are_ Extended Attributes) are clearly not the same thing as Vendor Specific
Attributes.  Assuming that VSA rules and practices apply to Extended
Attributes is probably not the best way to go.   Carving out a reservation
for the legacy codes of 0-255 seems reasonable, especially in light of the
extended type code field.

--
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, 26 Dec 2008 19:02:10 +0000
From: "D. B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issues with draft-ietf-radext-extended-attributes-05.txt
Date: Fri, 26 Dec 2008 14:02:04 -0500

Bernard Aboba writes...

> Here is my take on where each of the current open issues stands
> and what could be done to move things along.=A0

I'm going to break my comments into separate replies for each issue, and
revise the subject headers accordingly.  These will follow in subsequent
messages.

--
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, 26 Dec 2008 18:07:38 +0000
From: "D. B. Nelson" <[email-masked]>
To: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, "'Glen Zorn'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Fri, 26 Dec 2008 13:06:49 -0500

Dan Romascanu writes...

> I would like to ask the WG chairs and the WG at large what are
> the plans with this document following the response received from
> IEEE 802.16.

We should first ask Glen his intent / preferences.  Glen, what is your
preferred path to publish this draft?

As this draft has been deemed useful to IEEE 802.16 (at least to address
fielded deployments), the first question to ask is whether this work should
be taken on in the IETF, or whether it should be taken on in the IEEE (or as
a individual submission).  We have created a framework in which RADIUS
attributes that are of interest to particular SDOs, but not of general
interest to the Internet community, could be documented as SDO Specific
Attributes, using the RADIUS Extended Attribute format and the RADIUS Design
Guidelines.  This process may still require / desire expert review by the
RADEXT WG and/or the AAA Doctors.

OTOH, if the RADEXT WG is requested to invest substantial time in reviewing
this draft, it may make sense to publish this draft via the IETF process,
and thus as a RADEXT WG work item.  I don't have a strong opinion either
way.  If the WG chooses to take on this work, then it would need to be
appropriately prioritized w.r.t. the current deliverables, some of which
would be a prerequisite for either path (e.g. Design Guidelines and Extended
Attributes).

Regards,

Dave Nelson

--
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, 26 Dec 2008 09:38:57 +0000
Date: Fri, 26 Dec 2008 10:37:35 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: Glen Zorn <[email-masked]>,  "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Issues with draft-ietf-radext-extended-attributes-05.txt

Bernard Aboba wrote:
> Issue 225 -- It would appear that the major point of contention here
> relates to the length field and
> fragmentation.  I believe that  this comment could be resolved by
> addition of some advice (a SHOULD
> might suffice) on fragmentation usage for senders and support on
> receivers.   The ability to include
> multiple attributes inside a VSA was allowed in RFC 2865, and so should
> not be a subject of dispute
> for this document.  Given that this issue is nearly resolved, I would
> suggest that you and Alan
> work out appropriate text.

  I'll see if I can suggest something.

> Issue 278 -- The remaining portion of this issue relates to whether IANA
> can allocate Extended
> Attributes 0-255, and if by doing so, confusion would be created with
> respect to existing
> RADIUS attributes.  What is interesting about this discussion is that it
> only arose once the
> size of the type field was expanded to 16 bits.  In general, we have not
> seen confusion
> relating to use of VSAs with Type Code values which overlap the
> standards range (which
> most do).  For example, do people confuse Example.com VSA #32 with the
> RADIUS
> NAS-Identifier attribute (32)?   Maybe this issue could be resolved by
> suggestion of appropriate
> nomenclature.  For example, the term "<Attribute name> Extended
> Attribute (#)"
> instead of today's usage "NAS-Identifier Attribute (32)". 

  I was thinking also API's.  Some systems have internal API's that
add/delete/lookup attributes based on a key.  The key is (vendor-id,
attribute).  The problem is that looking up traditional RFC attributes
is often done by setting vendor-id=0.

  If we allow vendor-id to be zero, AND allow attributes 1..255 to mean
something new, this will cause problems for many implementations.

  Using 1..255 also prevents the grouping of standard RFC attributes
into the extended-attribute format, which was one of Glens goals.

  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, 25 Dec 2008 13:24:29 +0000
From: "Hannes Tschofenig" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, <[email-masked]>
Subject: RE: FW: [Fwd: Question regarding draft-ietf-radext-design-05.txt.]
Date: Thu, 25 Dec 2008 15:24:22 +0200

Hi Alan, 

also sorry that I did not reply to this mail earlier.  

>>>      * it is easier for the user to enter the data as well-known
>>>        types, rather than complex structures;
>>>
>>> I believe this text shouldn't really say "user". Even on the AAA 
>>> server (to which this text is most likely pointing to) I 
>think it is 
>>> worth pointing out that this depends a lot on where the data comes 
>>> from; often it does not come from a human.
>
>  Sure.  That could say:
>
>  * it is easier for the data to be managed as well-known types...

I guess we all agree that it would be nice to have only well-known data
types. 
The problem unfortunately is that the extended attributes draft does not
allow this to happen because of it's restricted treatement of complex
attributes. Even we some of the DIME documents we have today we run into a
lot of problems. 

>
>>>      * it enables additional error checking by leveraging the
>>>        parsing and validation routines for well-known types;
>>>
>>> If you are truely serious about this issue then one should 
>replicate 
>>> the Diameter mechanisms where you can group AVPs arbitrarily and 
>>> where you have far more data types available.
>
>  Nice idea, but this is RADIUS.  We can't change it at this point.

Well. RADIUS is a protocol and protocols seem to change over time. We see
this also with RADIUS. 
Recent example: TCP and TLS extensions for RADIUS

>
>>> I would like to discuss this statement a bit. It makes an 
>assumption 
>>> about the way how a RADIUS server works that might not be how it is 
>>> always being used today. It indicates that a RADIUS server works 
>>> roughly in the following way:
>>>
>>> a) Receive attributes (e.g., attribute foobar)
>>> b) Formulate a query based on the received attributes (e.g., select 
>>> foobar from tables where user-id=X)
>>> c) Return result from previous query
>
>  No.  It assumes that policies inside of the RADIUS server 
>are managed by attribute *name*, rather than on-the-wire number.

I am not sure how this relates to my statement. 

>
>>> This ignores that there might be more complex processing 
>going on in 
>>> the RADIUS server, for example that other protocols need to get 
>>> invoked to get the result (e.g., attributes Y require LDAP to fetch 
>>> results from server X while other mechanisms may be consulted to 
>>> obtain the necessary information related to attributes Z), 
>that there 
>>> is some business logic that needs to be executed).
>
>  That happens, but it's independent of RADIUS dictionaries.
>
>>> I would at least like to relax this statement a bit and acknowledge 
>>> the fact that RADIUS servers are a bit more complex today than just 
>>> boxes where one could have used SQL instead of the RADIUS protocol 
>>> right away.
>
>  The original servers didn't even use SQL...
>
>>> I think that policy languages in AAA servers are getting 
>more common 
>>> today.
>>> During the Diameter interop I have seen a lot of vendors 
>using quite 
>>> sophisticated policy languages and their boxes supported (in almost 
>>> all
>>> cases) not only Diameter but also RADIUS (and other protocols).
>
>  Yes.  Some RADIUS servers also support complex attribute 
>decoding through simple scripting languages.  But this has not 
>been historically wide-spread.

These assumptions have been built-into the draft and it would be good to be
explicit what type of RADIUS server you are talking about when you argue
that complex attributes lead to implementation, deployment and security
problems. This may very well be true be true for some of these servers but
certainly not true for many others. Maybe these older servers don't even
care about the functionality we are specifying today. 

>
>>> Finally, I would like to mention that RADIUS documents sometimes 
>>> specify RADIUS/Diameter compatibility in a wrong fashion.
>
>  Are there any changes required to the design guidelines 
>document?  Can you offer suggested text?

My immediate suggestion: Don't put a RADIUS / Diameter compatibility
considerations section into the document as it is almost always wrong. 

>
>>> The following paragraph (and a lot of related text) is 
>related to the 
>>> aspect of policy languages:
>>>
>>>   However, some standard attributes do not follow this format.
>>>   Attributes that use sub-fields instead of using a basic 
>data type are
>>>   known as "complex attributes".  As described below, the 
>definition of
>>>   complex attributes can lead to interoperability and deployment
>>>   issues, so they need to be introduced with care.
>>>
>>> It somewhat depends on how the policy language works and what you 
>>> expect the policy language todo.
>
> "Can lead ...".  The text is describing common practices and 
>deployments.  The only reason to change the text is if those 
>practices are not, in fact, in common use.

But these type of statements are used against draft authors who decided to
pick a different format and then we have all these discussions. 

I think it would be useful to provide a bit more context, as argued a few
paragraphs above. 

>
>>> If you also assume that the policy language is not only 
>used to deal 
>>> with the business logic but also with decoding and encoding of 
>>> attribute content then one could deal with a number of 
>>> interoperability and security issues with the choice of language.
>
>  This is really splitting hairs over what "code" is.  
>Assembler is code.  Policy languages are (not?) code.  Java is 
>intermediate...

The type of language really matters a lot when it comes to security issues.
There are certainly languages where buffer overflows and other issues are
more common than in other languages. It is also a difference whether a
developer has to write code in the scripting language of the AAA server or
whether the core part of the server has to be changed. 

>
>  In any case, *some* logic has to be updated for complex attributes.

As I mentioned in the mail to David I argue that for some of the "customer
groups" there is code at the level of the scripting language necessary
anyway (for almost all of the documents that get produced). Hence, I
provided the comparison to SQL in my previous mail by saying that RADIUS is
different to the initial versions of SQL databases in the sense that new
functionality requires often a bit of new code at the AAA server. Even SQL
has evolved over time and some of these database systems also allow some
form of scripting (e.g., via PL/SQL) 

>
>>> Btw, has the draft been sent to other SDOs for review?
>
>  Suggestions?
Almost all the major SDOs have to deal with RADIUS in some form:
Wimax Forum, Broadband Forum, 3GPP, 3GPP2, CableLabs

Ciao
Hannes

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

--
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, 25 Dec 2008 12:51:51 +0000
From: "Hannes Tschofenig" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Thu, 25 Dec 2008 14:51:10 +0200

Hi David, 

I noticed that I did not reply to these messages. 

>> If you are truely serious about this issue then one should replicate 
>> the Diameter mechanisms where you can group AVPs arbitrarily 
>and where 
>> you have far more data types available.
>
>That proposal was made in one of the early extended attributes 
>drafts, and was rejected by the RADEXT WG.  WG consensus says 
>that approach is not acceptable or interesting to the WG.  So, 
>while technically you have a very valid suggestion, it does 
>not seem to gain traction in the RADEXT WG.
> 
>> I would like to discuss this statement a bit. It makes an assumption 
>> about the way how a RADIUS server works that might not be how it is 
>> always being used today. It indicates that a RADIUS server works 
>> roughly in the following way:
>> 
>> a) Receive attributes (e.g., attribute foobar)
>> b) Formulate a query based on the received attributes (e.g., select 
>> foobar from tables where user-id=X)
>> c) Return result from previous query
>> 
>> This ignores that there might be more complex processing going on in 
>> the RADIUS server, for example that other protocols need to get 
>> invoked to get the result (e.g., attributes Y require LDAP to fetch 
>> results from server X while other mechanisms may be consulted to 
>> obtain the necessary information related to attributes Z), 
>that there 
>> is some business logic that needs to be executed).
>
>The policy determination / enforcement mechanism of RADIUS 
>servers is solely a matter of implementation.  It might be 
>implemented by means of delegation / consultation with some 
>other service, via some other protocol.  Or it might not.

While this is indeed an aspect of implementation there seem to be aspects
that impact the larger topic of how extensibility is perceived to work. 

>
>> I would at least like to relax this statement a bit and acknowledge 
>> the fact that RADIUS servers are a bit more complex today than just 
>> boxes where one could have used SQL instead of the RADIUS protocol 
>> right away.
>
>I think readers likely know that.  The issue is whether 
>extensions to the RADIUS on-the-wire protocol should be 
>designed to accommodate the traditional, 
>data-dictionary-driven RADIUS server, or not.  I think what we 
>are saying is that, while complex RADIUS server 
>implementations exist, RADIUS protocol enhancements should not 
>be at the expense of the simple implementations.

I think it is not a question of simple or complex implementation. 
The main issue is what the specific customers want. AAA servers are used by
different clusters of customers (different types of enterprises, WLAN
hotspots, universities, ISPs, cellular operators, etc). These customers have
different needs but the guidelines do not acknowledge that there are
different classes of customers and hence the design guidelines are often
applied without considering these aspects. I believe I can say that because
I was a victim of "strictly applying" the guidelines as they are, despite
the examples provided in the document on EAP etc. 

> 
>> I think that policy languages in AAA servers are getting more common 
>> today.
>
>Perhaps.

Would be worth investigating what folks develop today. 

> 
>> Finally, I would like to mention that RADIUS documents sometimes 
>> specify RADIUS/Diameter compatibility in a wrong fashion.
>
>That's an issue we need to address, and get right.
>
>> For example, there are a number of RADIUS documents that 
>indicate that 
>> the corresponding Diameter AVPs have the M-bit set.
>> This cannot be possible since this would require a new Diameter 
>> application to be specified.
>
>Ah, the long-standing Diameter Application quagmire.  :-(
>
>> I am not even sure that it is always the right way to put such a 
>> section in a RADIUS document when they authors do not envision 
>> Diameter to be used in their specific environment.
>
>What do you suggest?

Based on the discussion we had at the AAA doctors meeting I will think about
some way forward. 

>
>> The following paragraph (and a lot of related text) is 
>related to the 
>> aspect of policy languages:
>> 
>>   However, some standard attributes do not follow this format.
>>   Attributes that use sub-fields instead of using a basic data 
>>   type are known as "complex attributes".  As described below, 
>>   the definition of complex attributes can lead to interoperability
>>   and deployment issues, so they need to be introduced with care.
>> 
>> It somewhat depends on how the policy language works and what you 
>> expect the policy language todo.
>
>Please elaborate...

The above statement makes the assumption that the parsing happens in some
C-alike language that was used to implement the entire RADIUS server. 
There are indeed issues when you touch this code. 

However, most AAA servers have an abstract language they use for handling of
msg processing. This language is typically not C and written in a way that
it does not lead to security issues. As such, even additional parsing that
has to be implemented it does not lead to any interoperability or security
problems. Furthermore, as I argued above, since RADIUS usage today requires
more interaction the same language is used for the other processing and when
new functionality is added new code is being added. 

>
>> If you also assume that the policy language is not only used to deal 
>> with the business logic but also with decoding and encoding of 
>> attribute content then one could deal with a number of 
>> interoperability and security issues with the choice of language.
>
>So, what you are suggesting is that the syntax and semantics 
>of RADIUS attributes are contextually dependent on some policy 
>decision that is opaque to the RADIUS client, proxies, etc?  I 
>think that's a Very Bad Idea (tm) and falls under the 
>recommendation against polymorphic attribute design. 

No, my argument is different. I believe that the argument that complex
attributes lead to interoperability, deployment and security issues as
stated in the draft is incorrect and can of course happen from certain
implementation choices. Most AAA server do not have these issues as they are
providing an abstract language for the developer for business logic,
parsing, msg handling, etc. 

>
>> Btw, has the draft been sent to other SDOs for review?
>
>No.  I don't think that individual drafts are noticed the IETF 
>New Work list (maybe I'm wrong) so it would only come to the 
>attention of other SDOs via the efforts of overlapping participants.

Maybe it would have been good to get some feedback from organizations that
typically mess around with RADIUS protocols. 

Ciao
Hannes

>
>
>--
>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: Thu, 25 Dec 2008 07:03:40 +0000
From: Bernard Aboba <[email-masked]>
To: Glen Zorn <[email-masked]>, "David B. Nelson" <[email-masked]>, Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: Issues with draft-ietf-radext-extended-attributes-05.txt
Date: Wed, 24 Dec 2008 23:02:57 -0800

--_38be55ae-d34f-4a23-bacd-d9459b16d1c1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In general=2C it is the job of the editor to work with the Issue filters to
resolve review comments. =20

While it is possible to issue a formal WG consensus call to resolve=20
contentious issues=2C it is neither practical or necessary to go through=20
this process for each of the open issues.  We have already had to=20
engage that formal consensus process twice -- and that proved=20
to be  extremely time consuming.=20

In looking at the open issues=2C in most cases the remaining
areas of dispute are relatively minor=2C so that they are readily
resolvable between the editor and the Issue proposers.  =20

In one or two cases the issues are more substantial=2C but=20
discussion has not yet clarified the problem.  In these=20
situations more discussion is probably required.=20

Here is my take on where each of the current open issues stands
and what could be done to move things along.   Given the current
status=2C it is hard to see why the majority of these issues could
not be closed by the IETF 74 submission deadline.=20

Extended=20
      Attributes=20
      Issue Number
    Status
    Type
    Description
    Owner
 =20
    Issue 225
    Pending
    Technical
   =20
	Review
    Alan=20
    DeKok
 =20
    Issue 251
    Pending
    Technical
   =20
	Review
    Bernard=20
      Aboba
 =20
    Issue 278
    Pending
    Technical
   =20
=09
	Comments
    Alan=20
    DeKok
=09
=09
    Issue 279
    Pending
    Technical
   =20
=09
	Comments
    Stefan=20
	Winter
=09
 =20
    Issue 287
    No Discussion
    Technical
   =20
=09
	Comments
    Greg=20
    Weber
=09
=09
    Issue 290
    No Discussion
    Technical
   =20
	RFC=20
	4005bis Dependency
    Bernard=20
	Aboba
=09
 =20
    Issue 298
    No Discussion
    Technical
   =20
=09
	Extended Attributes Restriction
    Bernard=20
	Aboba

Issue 225 -- It would appear that the major point of contention here relate=
s to the length field and=20
fragmentation.  I believe that  this comment could be resolved by addition =
of some advice (a SHOULD
might suffice) on fragmentation usage for senders and support on receivers.=
   The ability to include
multiple attributes inside a VSA was allowed in RFC 2865=2C and so should n=
ot be a subject of dispute
for this document.  Given that this issue is nearly resolved=2C I would sug=
gest that you and Alan
work out appropriate text.=20

Issue 251 -- This relates to the need for IANA considerations text.  I can =
post a suggestion.=20

Issue 278 -- The remaining portion of this issue relates to whether IANA ca=
n allocate Extended
Attributes 0-255=2C and if by doing so=2C confusion would be created with r=
espect to existing
RADIUS attributes.  What is interesting about this discussion is that it on=
ly arose once the
size of the type field was expanded to 16 bits.  In general=2C we have not =
seen confusion
relating to use of VSAs with Type Code values which overlap the standards r=
ange (which
most do).  For example=2C do people confuse Example.com VSA #32 with the RA=
DIUS=20
NAS-Identifier attribute (32)?   Maybe this issue could be resolved by sugg=
estion of appropriate
nomenclature.  For example=2C the term "<Attribute name> Extended Attribute=
 (#)"
instead of today's usage "NAS-Identifier Attribute (32)". =20

Issue 279 -- Stefan has made concrete suggestions for resolving the remaini=
ng aspects of this
issue.  My suggestion would be to either incorporate them or make a counter=
-proposal.=20

Issue 290 -- This relates to the issue of Diameter support for non-standard=
 VSA formats (which this
document now uses).   During IETF 73=2C we discussed one potential avenue f=
or addressing this=2C which
would be to update RFC 4005 to enable use of Diameter AVP 26 for translatio=
n of RADIUS VSAs of
non-standard type.   This document would then normatively reference RFC 400=
5bis for a discussion
on translation of Extended Attributes.   Dave Mitton has expressed interest=
 in working on the
RFC 4005 revision=2C so my suggestion would be to work with him on that.=20

Issue 298 -- This issue relates to whether Extended Attributes are treated =
like VSAs or not.  For
implementations of this document=2C the answer is probably "no" -- they are=
 treated like any other standard
attribute.  However=2C for implementations that don't support Extended Attr=
ibutes=2C the answer is=20
probably "yes" -- which has implications for Accounting-Responses (where VS=
As are permitted=2C=20
but few standard attributes) and  Disconnect-Responses (where VSAs may only=
 be used for=20
session identification).   So one question is whether this implies that a N=
AS should signal its
support for Extended Attributes in the Access-Request in some way -- so as =
to make it clear
to the RADIUS server how those attributes would be interpretted.   Given th=
at the implications
of this issue (and therefore consensus) are still somewhat unclear=2C my re=
commendation would to=20
continue discussion in hope of achieving clarity.=20

Glen Zorn said:

> Hi=2C guys.  I would _really_ like to get this draft done=2C but none of =
the
> outstanding issues are owned by myself & the issue owners haven't been ve=
ry
> forthcoming w/text.  So=2C in the interest alacrity=2C could I talk you i=
nto
> doing a little more Chair-stuff?  Specifically=2C if you have comprehende=
d WG
> consensus on any/all of the issues=2C can you provide editing instruction=
s to
> me so that the issues may be closed & the document progressed?  TIA!

--_38be55ae-d34f-4a23-bacd-d9459b16d1c1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
In general=2C it is the job of the editor to work with the Issue filters to=
<br>resolve review comments.&nbsp=3B <br><br>While it is possible to issue =
a formal WG consensus call to resolve <br>contentious issues=2C it is neith=
er practical or necessary to go through <br>this process for each of the op=
en issues.&nbsp=3B We have already had to <br>engage that formal consensus =
process twice -- and that proved <br>to be&nbsp=3B extremely time consuming=
. <br><br>In looking at the open issues=2C in most cases the remaining<br>a=
reas of dispute are relatively minor=2C so that they are readily<br>resolva=
ble between the editor and the Issue proposers.&nbsp=3B&nbsp=3B <br><br>In =
one or two cases the issues are more substantial=2C but <br>discussion has =
not yet clarified the problem.&nbsp=3B In these <br>situations more discuss=
ion is probably required. <br><br>Here is my take on where each of the curr=
ent open issues stands<br>and what could be done to move things along.&nbsp=
=3B&nbsp=3B Given the current<br>status=2C it is hard to see why the majori=
ty of these issues could<br>not be closed by the IETF 74 submission deadlin=
e. <br><br><table id=3D"table62" width=3D"761" border=3D"1" height=3D"1"><t=
body><tr><td width=3D"117" height=3D"34"><font size=3D"4"><strong>Extended=
=20
      Attributes</strong></font>=20
      <b><font size=3D"4">Issue Number</font></b><BR></td>
    <td width=3D"146" height=3D"34"><b><font size=3D"4">Status</font></b></=
td>
    <td width=3D"84" height=3D"34"><font size=3D"4"><b>Type</b></font></td>
    <td width=3D"272" height=3D"34"><b><font size=3D"4">Description</font><=
/b></td>
    <td width=3D"112" height=3D"34"><b><font size=3D"4">Owner</font></b></t=
d></tr>
  <tr>
    <td width=3D"117" height=3D"62">Issue 225</td>
    <td width=3D"146" height=3D"34">Pending</td>
    <td width=3D"73" height=3D"62">Technical</td>
    <td width=3D"277" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
225">Review</a></td>
    <td width=3D"117" height=3D"51"><a href=3D"mailto:aland@deployingradius=
.com">Alan=20
    DeKok</a></td></tr>
  <tr>
    <td style=3D"height: 62px=3B" width=3D"117">Issue 251</td>
    <td style=3D"height: 62px=3B" width=3D"146">Pending</td>
    <td style=3D"height: 62px=3B" width=3D"84">Technical</td>
    <td style=3D"height: 62px=3B" width=3D"272">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
251">Review</a></td>
    <td style=3D"height: 62px=3B" width=3D"112"><a href=3D"mailto:Bernard_A=
[email-masked]">Bernard=20
      Aboba</a></td></tr>
  <tr>
    <td width=3D"117" height=3D"62">Issue 278</td>
    <td width=3D"146" height=3D"34">Pending</td>
    <td width=3D"73" height=3D"62">Technical</td>
    <td width=3D"277" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
278">
	Comments</a></td>
    <td width=3D"117" height=3D"51"><a href=3D"mailto:aland@deployingradius=
.com">Alan=20
    DeKok</a></td>
	</tr>
	<tr>
    <td width=3D"117" height=3D"62">Issue 279</td>
    <td width=3D"146" height=3D"34">Pending</td>
    <td width=3D"73" height=3D"62">Technical</td>
    <td width=3D"277" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
279">
	Comments</a></td>
    <td width=3D"117" height=3D"51"><a href=3D"mailto:stefan.winter@restena=
.lu">Stefan=20
	Winter</a></td>
	</tr>
  <tr>
    <td width=3D"116" height=3D"62">Issue 287</td>
    <td width=3D"143" height=3D"34">No Discussion</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
287">
	Comments</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:[email-masked]">Gr=
eg=20
    Weber</a></td>
	</tr>
	<tr>
    <td width=3D"116" height=3D"62">Issue 290</td>
    <td width=3D"143" height=3D"34">No Discussion</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
290">RFC=20
	4005bis Dependency</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:bernard_aboba@hotmail=
.com">Bernard=20
	Aboba</a></td>
	</tr>
  <tr>
    <td width=3D"116" height=3D"62">Issue 298</td>
    <td width=3D"143" height=3D"34">No Discussion</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
298">
	Extended Attributes Restriction</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:bernard_aboba@hotmail=
.com">Bernard=20
	Aboba</a></td></tr></tbody></table><br><br>Issue 225 -- It would appear th=
at the major point of contention here relates to the length field and <br>f=
ragmentation.&nbsp=3B I believe that&nbsp=3B this comment could be resolved=
 by addition of some advice (a SHOULD<br>might suffice) on fragmentation us=
age for senders and support on receivers.&nbsp=3B&nbsp=3B The ability to in=
clude<br>multiple attributes inside a VSA was allowed in RFC 2865=2C and so=
 should not be a subject of dispute<br>for this document.&nbsp=3B Given tha=
t this issue is nearly resolved=2C I would suggest that you and Alan<br>wor=
k out appropriate text. <br><br>Issue 251 -- This relates to the need for I=
ANA considerations text.&nbsp=3B I can post a suggestion. <br><br>Issue 278=
 -- The remaining portion of this issue relates to whether IANA can allocat=
e Extended<br>Attributes 0-255=2C and if by doing so=2C confusion would be =
created with respect to existing<br>RADIUS attributes.&nbsp=3B What is inte=
resting about this discussion is that it only arose once the<br>size of the=
 type field was expanded to 16 bits.&nbsp=3B In general=2C we have not seen=
 confusion<br>relating to use of VSAs with Type Code values which overlap t=
he standards range (which<br>most do).&nbsp=3B For example=2C do people con=
fuse Example.com VSA #32 with the RADIUS <br>NAS-Identifier attribute (32)?=
&nbsp=3B&nbsp=3B Maybe this issue could be resolved by suggestion of approp=
riate<br>nomenclature.&nbsp=3B For example=2C the term "&lt=3BAttribute nam=
e&gt=3B Extended Attribute (#)"<br>instead of today's usage "NAS-Identifier=
 Attribute (32)".&nbsp=3B <br><br>Issue 279 -- Stefan has made concrete sug=
gestions for resolving the remaining aspects of this<br>issue.&nbsp=3B My s=
uggestion would be to either incorporate them or make a counter-proposal. <=
br><br>Issue 290 -- This relates to the issue of Diameter support for non-s=
tandard VSA formats (which this<br>document now uses).&nbsp=3B&nbsp=3B Duri=
ng IETF 73=2C we discussed one potential avenue for addressing this=2C whic=
h<br>would be to update RFC 4005 to enable use of Diameter AVP 26 for trans=
lation of RADIUS VSAs of<br>non-standard type.&nbsp=3B&nbsp=3B This documen=
t would then normatively reference RFC 4005bis for a discussion<br>on trans=
lation of Extended Attributes.&nbsp=3B&nbsp=3B Dave Mitton has expressed in=
terest in working on the<br>RFC 4005 revision=2C so my suggestion would be =
to work with him on that. <br><br>Issue 298 -- This issue relates to whethe=
r Extended Attributes are treated like VSAs or not.&nbsp=3B For<br>implemen=
tations of this document=2C the answer is probably "no" -- they are treated=
 like any other standard<br>attribute.&nbsp=3B However=2C for implementatio=
ns that don't support Extended Attributes=2C the answer is <br>probably "ye=
s" -- which has implications for Accounting-Responses (where VSAs are permi=
tted=2C <br>but few standard attributes) and&nbsp=3B Disconnect-Responses (=
where VSAs may only be used for <br>session identification).&nbsp=3B&nbsp=
=3B So one question is whether this implies that a NAS should signal its<br=
>support for Extended Attributes in the Access-Request in some way -- so as=
 to make it clear<br>to the RADIUS server how those attributes would be int=
erpretted.&nbsp=3B&nbsp=3B Given that the implications<br>of this issue (an=
d therefore consensus) are still somewhat unclear=2C my recommendation woul=
d to <br>continue discussion in hope of achieving clarity. <br><br><br>Glen=
 Zorn said:<br><br>&gt=3B Hi=2C guys.  I would _really_ like to get this dr=
aft done=2C but none of the<br>&gt=3B outstanding issues are owned by mysel=
f &amp=3B the issue owners haven't been very<br>&gt=3B forthcoming w/text. =
 So=2C in the interest alacrity=2C could I talk you into<br>&gt=3B doing a =
little more Chair-stuff?  Specifically=2C if you have comprehended WG<br>&g=
t=3B consensus on any/all of the issues=2C can you provide editing instruct=
ions to<br>&gt=3B me so that the issues may be closed &amp=3B the document =
progressed?  TIA!<br><br><br><br></body>
</html>=

--_38be55ae-d34f-4a23-bacd-d9459b16d1c1_--

--
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, 25 Dec 2008 05:16:59 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, "'David B. Nelson'" <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: Issues with draft-ietf-radext-extended-attributes-05.txt
Date: Thu, 25 Dec 2008 12:15:21 +0700

Hi, guys.  I would _really_ like to get this draft done, but none of the
outstanding issues are owned by myself & the issue owners haven't been very
forthcoming w/text.  So, in the interest alacrity, could I talk you into
doing a little more Chair-stuff?  Specifically, if you have comprehended WG
consensus on any/all of the issues, can you provide editing instructions to
me so that the issues may be closed & the document progressed?  TIA!

--
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, 22 Dec 2008 10:24:37 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Mon, 22 Dec 2008 11:22:48 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Glen Zorn" <[email-masked]>, <[email-masked]>

I would like to ask the WG chairs and the WG at large what are the plans
with this document following the response received from IEEE 802.16.=20

Thanks and Regards,

Dan
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Glen Zorn
> Sent: Sunday, December 21, 2008 3:12 PM
> To: [email-masked]
> Subject: FW: I-D Action:draft-zorn-radius-pkmv1-03.txt=20
>=20
> FYI, in case you didn't see it.
>=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Wednesday, December 17, 2008 5:30 PM
> To: [email-masked]
> Subject: I-D Action:draft-zorn-radius-pkmv1-03.txt=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
>=20
> 	Title           : RADIUS Attributes for IEEE 802.16 Privacy Key
> Management Version 1 (PKMv1) Protocol Support
> 	Author(s)       : G. Zorn
> 	Filename        : draft-zorn-radius-pkmv1-03.txt
> 	Pages           : 15
> 	Date            : 2008-12-17
>=20
> This document defines a set of RADIUS Attributes which are=20
> designed to provide RADIUS support for IEEE 802.16 Privacy=20
> Key Management Version 1.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-03.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> Below is the data which will enable a MIME compliant mail=20
> reader implementation to automatically retrieve the ASCII=20
> version of the Internet-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: Sun, 21 Dec 2008 13:13:18 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Subject: FW: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Sun, 21 Dec 2008 20:11:31 +0700

This is a multipart message in MIME format.

------=_NextPart_000_0008_01C963A8.588B4EB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

FYI, in case you didn't see it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Wednesday, December 17, 2008 5:30 PM
To: [email-masked]
Subject: I-D Action:draft-zorn-radius-pkmv1-03.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : RADIUS Attributes for IEEE 802.16 Privacy Key
Management Version 1 (PKMv1) Protocol Support
	Author(s)       : G. Zorn
	Filename        : draft-zorn-radius-pkmv1-03.txt
	Pages           : 15
	Date            : 2008-12-17

This document defines a set of RADIUS Attributes which are designed to
provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

------=_NextPart_000_0008_01C963A8.588B4EB0
Content-Type: Message/External-body;
	name="draft-zorn-radius-pkmv1-03.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-zorn-radius-pkmv1-03.txt"

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

------=_NextPart_000_0008_01C963A8.588B4EB0
Content-Type: text/plain;
	name="ATT00065.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00065.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------=_NextPart_000_0008_01C963A8.588B4EB0--

--
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, 19 Dec 2008 10:51:12 +0000
Date: Fri, 19 Dec 2008 11:50:39 +0100
From: Klaas Wierenga <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: Inner identities, privacy, and roaming termination

Alan DeKok wrote:
> Bernard Aboba wrote:
>> In EDUROAM, an attack has been identified that involves use of two
>> distinct realms within an EAP method
>> supporting privacy (such as EAP-TTLSv0):
>> http://www.cesnet.cz/doc/techzpravy/2008/incorrect-eap-termination-in-eduroam/
> 
>   I will note that version 2.0 of FreeRADIUS doesn't have this issue.
> The functionality was originally added to support separation of the TLS
> side of EAP from traditional RADIUS.  i.e. Placing a modern server
> upstream from a legacy server, to enable support for EAP, when the
> legacy server doesn't support EAP.

also, it is in general not a good idea to use the same credentials both 
inside and outside tunnels anyway (compound authentication binding 
problem), so the end IdP should refuse credentials that arrive 'in the 
clear'.

What remains is that this is an end IdP problem. The IdP of the user can 
after terminating the EAP tunnel do whatever it pleases with the 
credentials, but that is not a protocol problem as Stefan mentioned.

Klaas

> 
>> It would appear that this attack can be addressed by adding a check on
>> the part of a home
>> RADIUS server in order to require that the inner and outer identities
>> share a realm.   If the
>> realms are allowed to differ, then it would appear to be necessary for
>> at least the inner realm
>> to be provided to the NAS somehow.  This could be within a CUI attribute
>> or a User-Name
>> attribute.  The question is whether an EAP-Peer-Id attribute might also
>> be useful. 
> 
>   Some deployments *require* that the realms differ, IIRC.  e.g. outer
> "anonymous" and inner "[email-masked]".
> 
>   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/>

--
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, 19 Dec 2008 10:08:33 +0000
Date: Fri, 19 Dec 2008 11:08:03 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Inner identities, privacy, and roaming termination

Bernard Aboba wrote:
> In EDUROAM, an attack has been identified that involves use of two
> distinct realms within an EAP method
> supporting privacy (such as EAP-TTLSv0):
> http://www.cesnet.cz/doc/techzpravy/2008/incorrect-eap-termination-in-eduroam/

  I will note that version 2.0 of FreeRADIUS doesn't have this issue.
The functionality was originally added to support separation of the TLS
side of EAP from traditional RADIUS.  i.e. Placing a modern server
upstream from a legacy server, to enable support for EAP, when the
legacy server doesn't support EAP.

> It would appear that this attack can be addressed by adding a check on
> the part of a home
> RADIUS server in order to require that the inner and outer identities
> share a realm.   If the
> realms are allowed to differ, then it would appear to be necessary for
> at least the inner realm
> to be provided to the NAS somehow.  This could be within a CUI attribute
> or a User-Name
> attribute.  The question is whether an EAP-Peer-Id attribute might also
> be useful. 

  Some deployments *require* that the realms differ, IIRC.  e.g. outer
"anonymous" and inner "[email-masked]".

  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: Fri, 19 Dec 2008 09:46:32 +0000
Date: Fri, 19 Dec 2008 10:46:05 +0100
From: Stig Venaas <[email-masked]>
To: Stefan Winter <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Watchdog logic

Stefan Winter wrote:
[...]
> I am not in favour of splitting the two connections. Fate-sharing is a
> desirable property, IMHO.

+1. I think fate sharing is essential here. A separate TCP connection
also adds overhead and complexity.

> Greetings,
> Stefan Winter

--
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, 19 Dec 2008 09:09:44 +0000
Date: Fri, 19 Dec 2008 10:09:15 +0100
From: Stefan Winter <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Watchdog logic

Hello,

> I'm wondering what the implications would be of using two separate connections, 
> one for Status-Server/Access-Accept and the other 
> one for Access-Request/Access-Accept transactions. 
>
> The failover logic would change, to be sure.  For example, 
> a connection failure on the Request/Accept connection would probably trigger
> failover, regardless of the state of the Status-Server/Accept connection. 
>   

Separating into two connections is a very dangerous path, IMHO. The
scenario you depicted above may *wrongly* trigger failover in a roaming
scenario. The Request/Accept connection could be unresponsive due to the
server having proxied all its requests to a downstram server. I.e. it
could be up and running, waiting itself for answers. If that connection
is closed and fail-overed, actual traffic will be discarded without
reason. If, OTOH, Status-Server is sent within this connection, a
Status-Server/Accept pair can immediately enlighten the requesting
server that the other peer is indeed running.

> Also, the state of the two connections could get out of 
> sync; for example, if the Request/Accept connection was quite busy,
> then the Status/Accept connection might send little or no traffic,
> which might cause middleboxes (e.g. a NAT) to lose connection state
> on the Status/Accept connection.  In such a situation, you might just
> be able to bring up another Status/Accept connection rather than 
> triggering failover. 

I am not in favour of splitting the two connections. Fate-sharing is a
desirable property, IMHO.

Greetings,

Stefan Winter

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

Tel: +352 424409 1
Fax: +352 422473

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

Delivery-date: Fri, 19 Dec 2008 08:59:27 +0000
Date: Fri, 19 Dec 2008 09:58:37 +0100
From: Stefan Winter <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Inner identities, privacy, and roaming termination

Hello,

> Today, a mechanism for providing the user identity to the NAS is to
> send the EAP Peer-Id
> within a User-Name attribute in an Access-Accept.  This will provide
> the NAS with the inner identity,
> and will also cause Accounting-Requests to include the inner-identity
> within the User-Name attribute.

Some eduroam participants do this. NAS behaviour in Accounting-Requests
is apparently not homogenous. Some apparently continue to use the
User-Name from the authentication phase. In a roaming context, where the
home AAA server has no information on the NAS equipment being used, this
indeterminism makes the "feature" of using User-Name for EAP Peer-Id
mostly useless.
>    However,
> this does have the side effect of potentially causing authentication
> and accounting messages to take different paths
> in the situation where NAI re-writing occurs within proxies.   For
> example, if the NAI 
> [email-masked] were used in the
> Access-Request, and the NAI [email-masked]
> were sent back in the Access-Accept, this would result in
> Accounting-Requests that were sent with a User-Name
> attribute of [email-masked], bypassing roamingpartner.com.  This
> concern was articulated in RFC 4372 as well.
> Providing an EAP-Peer-Id attribute would address concerns about
> overloading of the User-Name attribute.

That's true. Getting rid of this overloading would in itself be a
justification for keeping EAP-Peer-Id in the 80211 attributes draft.

> One concern that has been raised about the EAP-Peer-Id attribute is
> privacy. 
> As noted in the CUI RFC (RFC 4372), there are situations where it is
> undesirable for the NAS to obtain
> knowledge of the user identity.  Where a CUI attribute containing a
> NUL is sent in an Access-Request,
> the home server should assume that privacy is desired, and neither a
> User-Name nor an EAP-Peer-Id
> attribute should be sent in an Access-Accept, only a CUI attribute. 

IMHO, there is little a NAS can do if a home AAA wants to send this
information. The home AAA could also send it in an arbitrary VSA. So,
while it may be undesirable, it is also not deterministically possible
for the NAS to disable getting this information. Providing or not
providing a defined semantics/attribute for the piece of information
doesn't magically make the possibility for transmission go away. So, I
wouldn't use this argument against the definition of an EAP-Peer-Id.

> However, there are situations in which privacy might be desired, but
> the NAS does not support the
> CUI attribute.  Therefore the document currently states that the
> EAP-Peer-Id is only sent in an
> Access-Accept if the EAP-Peer-Id attribute is included in an
> Access-Request.   To address the concerns
> expressed by Alfred Hoenes (see
> http://ops.ietf.org/lists/radiusext/2008/msg00822.html),
> it would be possible to include a single NUL character in EAP-Peer-Id
> and EAP-Server-Id attributes sent within
> an Access-Request, rather than sending empty attributes. 

Since empty attributes are forbidden, a 0x00 seems like a good workaround.

> In EDUROAM, an attack has been identified that involves use of two
> distinct realms within an EAP method
> supporting privacy (such as EAP-TTLSv0):
> http://www.cesnet.cz/doc/techzpravy/2008/incorrect-eap-termination-in-eduroam/
>
> It would appear that this attack can be addressed by adding a check on
> the part of a home
> RADIUS server in order to require that the inner and outer identities
> share a realm.   If the
> realms are allowed to differ, then it would appear to be necessary for
> at least the inner realm
> to be provided to the NAS somehow.  This could be within a CUI
> attribute or a User-Name
> attribute.  The question is whether an EAP-Peer-Id attribute might
> also be useful.

While we were concerned over this redirection possibility, I wouldn't
call it an "attack", but much rather an "unexpected feature". It can be
mitigated by the AAA server which terminates the EAP session. It is in
possession of both the outer identity and the EAP Peer-Id, and can do
the sanity checks. This reduces the problem to one of a correct local
configuration at the side of the EAP peer. I wonder if it really makes
sense to do additional checks on the visited AAA or NAS side. If so, an
EAP-Peer-Id attribute might make sense here.
Also, I could imagine some configurations where a home AAA server serves
multiple realms, a user uses a combination with differing realms but
which are both handled by the same AAA server, in which case it might be
unexpected that a NAS somewhere decides that this is an unjust action.

Greetings,

Stefan Winter

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

Tel: +352 424409 1
Fax: +352 422473

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

Delivery-date: Thu, 18 Dec 2008 18:04:50 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Inner identities, privacy, and roaming termination
Date: Thu, 18 Dec 2008 10:03:55 -0800

--_121e0a5e-1e16-4a63-96b5-ffd54f78387a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The current version of the IEEE 802 attributes draft includes support for E=
AP-Server-Id and EAP-Peer-Id attributes:
http://tools.ietf.org/html/draft-aboba-radext-wlan

I am considering removing these attributes in the next revision of the docu=
ment=2C and would like to get the WG's
opinion on this.  The question is whether these attributes are needed=2C an=
d whether they would be used if provided.=20

The primary use of the EAP-Peer-Id attribute would be to enable a NAS to de=
termine the identity of the user where
the EAP method-specific identity differed from the identity provided in the=
 EAP-Response/Identity.   For example=2C
in EAP-TTLSv0=2C the outer identity could be anonymous=2C while the inner i=
dentity could provide the authenticated
identity of the user.=20

Today=2C a mechanism for providing the user identity to the NAS is to send =
the EAP Peer-Id
within a User-Name attribute in an Access-Accept.  This will provide the NA=
S with the inner identity=2C=20
and will also cause Accounting-Requests to include the inner-identity withi=
n the User-Name attribute.   However=2C=20
this does have the side effect of potentially causing authentication and ac=
counting messages to take different paths=20
in the situation where NAI re-writing occurs within proxies.   For example=
=2C if the NAI =20
[email-masked] were used in the Access-Request=2C=
 and the NAI [email-masked]=20
were sent back in the Access-Accept=2C this would result in Accounting-Requ=
ests that were sent with a User-Name
attribute of [email-masked]=2C bypassing roamingpartner.com.  This concer=
n was articulated in RFC 4372 as well.=20
Providing an EAP-Peer-Id attribute would address concerns about overloading=
 of the User-Name attribute.=20

One concern that has been raised about the EAP-Peer-Id attribute is privacy=
. =20
As noted in the CUI RFC (RFC 4372)=2C there are situations where it is unde=
sirable for the NAS to obtain
knowledge of the user identity.  Where a CUI attribute containing a NUL is =
sent in an Access-Request=2C
the home server should assume that privacy is desired=2C and neither a User=
-Name nor an EAP-Peer-Id
attribute should be sent in an Access-Accept=2C only a CUI attribute. =20

However=2C there are situations in which privacy might be desired=2C but th=
e NAS does not support the
CUI attribute.  Therefore the document currently states that the EAP-Peer-I=
d is only sent in an
Access-Accept if the EAP-Peer-Id attribute is included in an Access-Request=
.   To address the concerns=20
expressed by Alfred Hoenes (see http://ops.ietf.org/lists/radiusext/2008/ms=
g00822.html)=2C

it would be possible to include a single NUL character in EAP-Peer-Id and E=
AP-Server-Id attributes sent within

an Access-Request=2C rather than sending empty attributes. =20

In EDUROAM=2C an attack has been identified that involves use of two distin=
ct realms within an EAP method=20
supporting privacy (such as EAP-TTLSv0):
http://www.cesnet.cz/doc/techzpravy/2008/incorrect-eap-termination-in-eduro=
am/

It would appear that this attack can be addressed by adding a check on the =
part of a home
RADIUS server in order to require that the inner and outer identities share=
 a realm.   If the
realms are allowed to differ=2C then it would appear to be necessary for at=
 least the inner realm
to be provided to the NAS somehow.  This could be within a CUI attribute or=
 a User-Name
attribute.  The question is whether an EAP-Peer-Id attribute might also be =
useful. =20

 EMAILING FOR THE GREATER GOOD
Join me=

--_121e0a5e-1e16-4a63-96b5-ffd54f78387a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
The current version of the IEEE 802 attributes draft includes support for E=
AP-Server-Id and EAP-Peer-Id attributes:<br>http://tools.ietf.org/html/draf=
t-aboba-radext-wlan<br><br>I am considering removing these attributes in th=
e next revision of the document=2C and would like to get the WG's<br>opinio=
n on this.&nbsp=3B The question is whether these attributes are needed=2C a=
nd whether they would be used if provided. <br><br>The primary use of the E=
AP-Peer-Id attribute would be to enable a NAS to determine the identity of =
the user where<br>the EAP method-specific identity differed from the identi=
ty provided in the EAP-Response/Identity.&nbsp=3B&nbsp=3B For example=2C<br=
>in EAP-TTLSv0=2C the outer identity could be anonymous=2C while the inner =
identity could provide the authenticated<br>identity of the user. <br><br>T=
oday=2C a mechanism for providing the user identity to the NAS is to send t=
he EAP Peer-Id<br>within a User-Name attribute in an Access-Accept.&nbsp=3B=
 This will provide the NAS with the inner identity=2C <br>and will also cau=
se Accounting-Requests to include the inner-identity within the User-Name a=
ttribute.&nbsp=3B&nbsp=3B However=2C <br>this does have the side effect of =
potentially causing authentication and accounting messages to take differen=
t paths <br>in the situation where NAI re-writing occurs within proxies.&nb=
sp=3B&nbsp=3B For example=2C if the NAI&nbsp=3B <br>example.com!anonymous@r=
oamingpartner.com were used in the Access-Request=2C and the NAI fred@examp=
le.com <br>were sent back in the Access-Accept=2C this would result in Acco=
unting-Requests that were sent with a User-Name<br>attribute of fred@exampl=
e.com=2C bypassing roamingpartner.com.&nbsp=3B This concern was articulated=
 in RFC 4372 as well. <br>Providing an EAP-Peer-Id attribute would address =
concerns about overloading of the User-Name attribute. <br><br>One concern =
that has been raised about the EAP-Peer-Id attribute is privacy.&nbsp=3B <b=
r>As noted in the CUI RFC (RFC 4372)=2C there are situations where it is un=
desirable for the NAS to obtain<br>knowledge of the user identity.&nbsp=3B =
Where a CUI attribute containing a NUL is sent in an Access-Request=2C<br>t=
he home server should assume that privacy is desired=2C and neither a User-=
Name nor an EAP-Peer-Id<br>attribute should be sent in an Access-Accept=2C =
only a CUI attribute.&nbsp=3B <br><br>However=2C there are situations in wh=
ich privacy might be desired=2C but the NAS does not support the<br>CUI att=
ribute.&nbsp=3B Therefore the document currently states that the EAP-Peer-I=
d is only sent in an<br>Access-Accept if the EAP-Peer-Id attribute is inclu=
ded in an Access-Request.&nbsp=3B&nbsp=3B To address the concerns <br>expre=
ssed by Alfred Hoenes (see http://ops.ietf.org/lists/radiusext/2008/msg0082=
2.html)=2C<br>

it would be possible to include a single NUL character in EAP-Peer-Id and E=
AP-Server-Id attributes sent within<br>

an Access-Request=2C rather than sending empty attributes.&nbsp=3B <br><br>=
In EDUROAM=2C an attack has been identified that involves use of two distin=
ct realms within an EAP method <br>supporting privacy (such as EAP-TTLSv0):=
<br>http://www.cesnet.cz/doc/techzpravy/2008/incorrect-eap-termination-in-e=
duroam/<br><br>It would appear that this attack can be addressed by adding =
a check on the part of a home<br>RADIUS server in order to require that the=
 inner and outer identities share a realm.&nbsp=3B&nbsp=3B If the<br>realms=
 are allowed to differ=2C then it would appear to be necessary for at least=
 the inner realm<br>to be provided to the NAS somehow.&nbsp=3B This could b=
e within a CUI attribute or a User-Name<br>attribute.&nbsp=3B The question =
is whether an EAP-Peer-Id attribute might also be useful.&nbsp=3B <br><br><=
br><br><br><br><br><br><br><br><table style=3D"border-top: 1px solid black=
=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><=
tbody><tr><td><a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML=
_WLHM_GreaterGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=
=3B text-decoration: none=3B"><img style=3D"border-style: none=3B" src=3D"h=
ttp://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" alt=3D"i'm"> EMAILING FOR=
 THE GREATER GOOD<br><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B =
color: rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B">Join me</span=
></a></td></tr></tbody></table></body>
</html>=

--_121e0a5e-1e16-4a63-96b5-ffd54f78387a_--

--
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, 18 Dec 2008 15:34:22 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: Watchdog logic
Date: Thu, 18 Dec 2008 07:33:25 -0800

--_8c203aac-c42b-44e1-bbc4-9605944bd286_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>   Ok.  There are situations where a connection may be up=2C but the
> application is unresponsive.  It would be good to use the RFC 3539
> method to validate the connection.

The watchdog is based on application-layer timescales (e.g. 6 seconds)=2C r=
ather than connection timescales.  So it's possible for the watchdog to cau=
se application layer failover prior to connection failure/reset.=20

>   I'm not sure having a separate connection for Status-Server is a good
> idea.

I'm not sure either.   Separating the Status-Server traffic from the RADSEC
traffic breaks "fate sharing" which could introduce a number of bugs.

>   In addition=2C the algorithm in 3539 appears to be focussed on keeping
> the connections up... even if that means re-opening them.  I'm not sure
> this is a good idea.  It means that spikes in traffic cause a large
> number of connections to be opened... which then never close=2C or are
> continuously re-opened.  Even if there's no traffic on them.

The idea is to always have a connection "ready" for traffic=2C so yes=2C th=
e
algorithm does keep connections up even if there is no regular traffic
(e.g. the algorithm generates watchdog traffic). =20

>   It may be worth adding suggestions:
>=20
> - TCP connections SHOULD be kept "full".  i.e. used in a "most recently
> used" fashion for normal RADIUS traffic.
>=20
> - The RFC 3539 watchdog algorithm should be used to determine the status =
of a *connection*.

Not sure that the watchdog really determines connection status so much as s=
tatus at the application layer. =20

> - so long as one connection is alive=2C the server should be marked "aliv=
e".

Agreed.  But doesn't this somewhat conflict with the previous goal?

> - connections that haven't been used for T seconds (4 * RTT?) may be
> pro-actively closed.

How do you know what RTT is?  Or do you assume RTTMAX?  Since routing trans=
ients can take as long as 30 seconds to resolve=2C T probably would need to=
 be significant (e.g. minutes).=20

> - at least one connection should remain open to determine application
> responsiveness.

Sure.=20

--_8c203aac-c42b-44e1-bbc4-9605944bd286_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B   Ok.  There are situations where a connection may be up=2C but the<=
br>&gt=3B application is unresponsive.  It would be good to use the RFC 353=
9<br>&gt=3B method to validate the connection.<br><br>The watchdog is based=
 on application-layer timescales (e.g. 6 seconds)=2C rather than connection=
 timescales.&nbsp=3B So it's possible for the watchdog to cause application=
 layer failover prior to connection failure/reset. <br><br>&gt=3B   I'm not=
 sure having a separate connection for Status-Server is a good<br>&gt=3B id=
ea.<br><br>I'm not sure either.&nbsp=3B&nbsp=3B Separating the Status-Serve=
r traffic from the RADSEC<br>traffic breaks "fate sharing" which could intr=
oduce a number of bugs.<br><br>&gt=3B   In addition=2C the algorithm in 353=
9 appears to be focussed on keeping<br>&gt=3B the connections up... even if=
 that means re-opening them.  I'm not sure<br>&gt=3B this is a good idea.  =
It means that spikes in traffic cause a large<br>&gt=3B number of connectio=
ns to be opened... which then never close=2C or are<br>&gt=3B continuously =
re-opened.  Even if there's no traffic on them.<br><br>The idea is to alway=
s have a connection "ready" for traffic=2C so yes=2C the<br>algorithm does =
keep connections up even if there is no regular traffic<br>(e.g. the algori=
thm generates watchdog traffic).&nbsp=3B <br><br>&gt=3B   It may be worth a=
dding suggestions:<br>&gt=3B <br>&gt=3B - TCP connections SHOULD be kept "f=
ull".  i.e. used in a "most recently<br>&gt=3B used" fashion for normal RAD=
IUS traffic.<br>&gt=3B <br>&gt=3B - The RFC 3539 watchdog algorithm should =
be used to determine the status of a *connection*.<br><br>Not sure that the=
 watchdog really determines connection status so much as status at the appl=
ication layer.&nbsp=3B <br><br>&gt=3B - so long as one connection is alive=
=2C the server should be marked "alive".<br><br>Agreed.&nbsp=3B But doesn't=
 this somewhat conflict with the previous goal?<br><br>&gt=3B - connections=
 that haven't been used for T seconds (4 * RTT?) may be<br>&gt=3B pro-activ=
ely closed.<br><br>How do you know what RTT is?&nbsp=3B Or do you assume RT=
TMAX?&nbsp=3B Since routing transients can take as long as 30 seconds to re=
solve=2C T probably would need to be significant (e.g. minutes). <br><br>&g=
t=3B - at least one connection should remain open to determine application<=
br>&gt=3B responsiveness.<br><br>Sure. <br></body>
</html>=

--_8c203aac-c42b-44e1-bbc4-9605944bd286_--

--
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, 18 Dec 2008 10:39:09 +0000
Date: Thu, 18 Dec 2008 11:38:21 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Watchdog logic

Bernard Aboba wrote:
> "With TCP, there is a connection between client and server.  The
> watchdog timer algorithm in RFC 3539 is defined per *connection*.  So an
> ID has to be reserved, because the client can't open a new connection to
> test if an existing connection is still alive."
> 
> While it's true that the watchdog timer algorithm is defined per connection,
> it seems like Status-Server is about determining whether a server is up
> or not.  The only way to determine whether a connection is down
> is to wait for it to close (either via a RESET or timeout).  RFC 3539
> attempts to detect a failure at the application layer prior to connection failure. 

  Ok.  There are situations where a connection may be up, but the
application is unresponsive.  It would be good to use the RFC 3539
method to validate the connection.

> I'm wondering what the implications would be of using two separate connections, 
> one for Status-Server/Access-Accept and the other 
> one for Access-Request/Access-Accept transactions. 
> 
> The failover logic would change, to be sure.  For example, 
> a connection failure on the Request/Accept connection would probably trigger
> failover, regardless of the state of the Status-Server/Accept connection. 
> Also, the state of the two connections could get out of 
> sync; for example, if the Request/Accept connection was quite busy,
> then the Status/Accept connection might send little or no traffic,
> which might cause middleboxes (e.g. a NAT) to lose connection state
> on the Status/Accept connection.  In such a situation, you might just
> be able to bring up another Status/Accept connection rather than 
> triggering failover. 

  I'm not sure having a separate connection for Status-Server is a good
idea.

  In addition, the algorithm in 3539 appears to be focussed on keeping
the connections up... even if that means re-opening them.  I'm not sure
this is a good idea.  It means that spikes in traffic cause a large
number of connections to be opened... which then never close, or are
continuously re-opened.  Even if there's no traffic on them.

  It may be worth adding suggestions:

- TCP connections SHOULD be kept "full".  i.e. used in a "most recently
used" fashion for normal RADIUS traffic.

- The RFC 3539 watchdog algorithm should be used to determine the status
of a *connection*.

- so long as one connection is alive, the server should be marked "alive".

- connections that haven't been used for T seconds (4 * RTT?) may be
pro-actively closed.

- at least one connection should remain open to determine application
responsiveness.

  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, 17 Dec 2008 17:40:09 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Watchdog logic
Date: Wed, 17 Dec 2008 09:39:38 -0800

--_26d31129-88e8-46c5-9100-33d20413d498_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In a previous message (http://ops.ietf.org/lists/radiusext/2008/msg00857.ht=
ml) Alan DeKok
pointed out:

"With TCP=2C there is a connection between client and server.  The
watchdog timer algorithm in RFC 3539 is defined per *connection*.  So an
ID has to be reserved=2C because the client can't open a new connection to
test if an existing connection is still alive."

While it's true that the watchdog timer algorithm is defined per connection=
=2C
it seems like Status-Server is about determining whether a server is up
or not.  The only way to determine whether a connection is down
is to wait for it to close (either via a RESET or timeout).  RFC 3539
attempts to detect a failure at the application layer prior to connection f=
ailure.=20

I'm wondering what the implications would be of using two separate connecti=
ons=2C=20
one for Status-Server/Access-Accept and the other=20
one for Access-Request/Access-Accept transactions.=20

The failover logic would change=2C to be sure.  For example=2C=20
a connection failure on the Request/Accept connection would probably trigge=
r
failover=2C regardless of the state of the Status-Server/Accept connection.=
=20
Also=2C the state of the two connections could get out of=20
sync=3B for example=2C if the Request/Accept connection was quite busy=2C
then the Status/Accept connection might send little or no traffic=2C
which might cause middleboxes (e.g. a NAT) to lose connection state
on the Status/Accept connection.  In such a situation=2C you might just
be able to bring up another Status/Accept connection rather than=20
triggering failover.=20

=20

--_26d31129-88e8-46c5-9100-33d20413d498_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
In a previous message (http://ops.ietf.org/lists/radiusext/2008/msg00857.ht=
ml) Alan DeKok<br>pointed out:<br><br><pre>"With TCP=2C there is a connecti=
on between client and server.  The<br>watchdog timer algorithm in RFC 3539 =
is defined per *connection*.  So an<br>ID has to be reserved=2C because the=
 client can't open a new connection to<br>test if an existing connection is=
 still alive."<br><br>While it's true that the watchdog timer algorithm is =
defined per connection=2C<br>it seems like Status-Server is about determini=
ng whether a server is up<br>or not.  The only way to determine whether a c=
onnection is down<br>is to wait for it to close (either via a RESET or time=
out).  RFC 3539<br>attempts to detect a failure at the application layer pr=
ior to connection failure. <br><br>I'm wondering what the implications woul=
d be of using two separate connections=2C <br>one for Status-Server/Access-=
Accept and the other <br>one for Access-Request/Access-Accept transactions.=
 <br><br>The failover logic would change=2C to be sure.  For example=2C <br=
>a connection failure on the Request/Accept connection would probably trigg=
er<br>failover=2C regardless of the state of the Status-Server/Accept conne=
ction. <br>Also=2C the state of the two connections could get out of <br>sy=
nc=3B for example=2C if the Request/Accept connection was quite busy=2C<br>=
then the Status/Accept connection might send little or no traffic=2C<br>whi=
ch might cause middleboxes (e.g. a NAT) to lose connection state<br>on the =
Status/Accept connection.  In such a situation=2C you might just<br>be able=
 to bring up another Status/Accept connection rather than <br>triggering fa=
ilover. <br><br><br><br></pre>&nbsp=3B<table style=3D"border-top: 1px solid=
 black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=
=3B"><tbody><tr><td><a href=3D"http://im.live.com/Messenger/IM/Home/?source=
=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C =
203)=3B text-decoration: none=3B"><span style=3D"padding: 0px 24px=3B font-=
size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B">=
</span></a><br></td></tr></tbody></table></body>
</html>=

--_26d31129-88e8-46c5-9100-33d20413d498_--

--
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, 17 Dec 2008 17:23:39 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Summary of WG review of "RADIUS over TCP" document
Date: Wed, 17 Dec 2008 09:22:31 -0800

--_42a820e1-386f-45cd-a21f-926389685def_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> > Why should the ID be unique regardless of packet code when run
> > over reliable transport=2C but not UDP?  This suggests that the ID is
> > being processed differently for unreliable vs. reliable transport=2C wh=
ich
> > seems odd.
>=20
>   With UDP=2C there is no "connection" from client to server.  So any
> Status-Server checks are sent from any client port.  This removes much
> of the problem of reserving one ID: the client just opens another source
> port.
>=20
>   If it uses the same source port for Status-Server as for
> Access-Request=2C then it would need to ensure that the ID allocated to
> Status-Server is unused by any Access-Request.

The problem is not so much with the Status-Server/Access-Request ID
conflict=2C as with the potential conflict of Access-Accept IDs=2C correct?=
=20

>   With TCP=2C there is a connection between client and server.  The
> watchdog timer algorithm in RFC 3539 is defined per *connection*.  So an
> ID has to be reserved=2C because the client can't open a new connection t=
o
> test if an existing connection is still alive.

Ah.  I understand now.  Let's talk about the implications of this on a sepa=
rate
thread.  Some of the above logic might be worth putting into the document.=
=20

--_42a820e1-386f-45cd-a21f-926389685def_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B &gt=3B Why should the ID be unique regardless of packet code when ru=
n<br>&gt=3B &gt=3B over reliable transport=2C but not UDP?  This suggests t=
hat the ID is<br>&gt=3B &gt=3B being processed differently for unreliable v=
s. reliable transport=2C which<br>&gt=3B &gt=3B seems odd.<br>&gt=3B <br>&g=
t=3B   With UDP=2C there is no "connection" from client to server.  So any<=
br>&gt=3B Status-Server checks are sent from any client port.  This removes=
 much<br>&gt=3B of the problem of reserving one ID: the client just opens a=
nother source<br>&gt=3B port.<br>&gt=3B <br>&gt=3B   If it uses the same so=
urce port for Status-Server as for<br>&gt=3B Access-Request=2C then it woul=
d need to ensure that the ID allocated to<br>&gt=3B Status-Server is unused=
 by any Access-Request.<br><br>The problem is not so much with the Status-S=
erver/Access-Request ID<br>conflict=2C as with the potential conflict of Ac=
cess-Accept IDs=2C correct? <br><br>&gt=3B   With TCP=2C there is a connect=
ion between client and server.  The<br>&gt=3B watchdog timer algorithm in R=
FC 3539 is defined per *connection*.  So an<br>&gt=3B ID has to be reserved=
=2C because the client can't open a new connection to<br>&gt=3B test if an =
existing connection is still alive.<br><br>Ah.&nbsp=3B I understand now.&nb=
sp=3B Let's talk about the implications of this on a separate<br>thread.&nb=
sp=3B Some of the above logic might be worth putting into the document. <br=
><br><br></body>
</html>=

--_42a820e1-386f-45cd-a21f-926389685def_--

--
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, 17 Dec 2008 14:26:27 +0000
Date: Wed, 17 Dec 2008 15:26:09 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: Issue with Guidelines document

Bernard Aboba wrote:
>> Yes. I suggest that the Extended attributes draft (and maybe even the
>> guidelines document) contain text that says "Extended attributes with
>> Vendor-Id of zero (0) are not to be interpreted as VSA's within the
>> meaning of the other drafts".
> 
> You might be able to make that recommendation with respect to
> implementations
> that understand Extended Attributes (e.g. implementations of the Extended
> Attribute specification). But how can we say that with respect to existing
> implementations?  This implies that legacy implementations will treat
> Extended Attributes like VSAs (e.g. ignore them if they don't understand
> them).  

  I think that's what will happen.

  We can't change the behavior of legacy implementations.  We just have
to be careful about how we use the extended attributes.

  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, 17 Dec 2008 14:25:14 +0000
Date: Wed, 17 Dec 2008 15:25:00 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: draft-ietf-radext-status-server-02 editorials (fwd)

Bernard Aboba wrote:
>> Ok... so should it be Experimental, or Informational?
> 
> FWIW, I'd say Informational.  That is what we did for RFC 5176, since
> its original implementation had so many warts.  Where there were
> potential fixes, we pointed them out, but since the goal was to
> describe what was implemented, we could not break backward
> compatibility by inserting MUST/MUST NOT language to outlaw
> poor practices (e.g. the original specification enabled replay
> attacks). 

  OK.  The next version will be marked "Informational".

  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, 17 Dec 2008 14:23:41 +0000
Date: Wed, 17 Dec 2008 15:23:14 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: Summary of WG review of "RADIUS over TCP" document

Bernard Aboba wrote:
>> I would prefer to leave the discussion of Status-Server && RADIUS ID
>> use in this document. The traditional use of Status-Server is over UDP,
>> and therefore does not have the issues presented here. (i.e. suggestion
>> to reserve one RADIUS ID per TCP connection for Status-Server.)
> 
> Why should the ID be unique regardless of packet code when run
> over reliable transport, but not UDP?  This suggests that the ID is
> being processed differently for unreliable vs. reliable transport, which
> seems odd.

  With UDP, there is no "connection" from client to server.  So any
Status-Server checks are sent from any client port.  This removes much
of the problem of reserving one ID: the client just opens another source
port.

  If it uses the same source port for Status-Server as for
Access-Request, then it would need to ensure that the ID allocated to
Status-Server is unused by any Access-Request.

  With TCP, there is a connection between client and server.  The
watchdog timer algorithm in RFC 3539 is defined per *connection*.  So an
ID has to be reserved, because the client can't open a new connection to
test if an existing connection is still alive.

  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, 17 Dec 2008 13:55:50 +0000
Date: Wed, 17 Dec 2008 14:54:53 +0100
From: Stefan Winter <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-ietf-radext-radsec-02 for WGLC

Hi, Joe,

thanks for the review!
> Here are some working group last call comments on RADSEC:
>
> 1.  How is backward compatibility/forward migration of RADSEC handled?
> Operational recommendations in this area should be discussed.   The
> potential for rollback attacks should also be covered in the security
> considerations section.
>   

True. I had hoped to offload backward compatibility to the TCP transport
document, since this is the one with the new transport. But since TCP
w/o TLS and TCP with TLS have different port numbers, a distinct issue
is raised between the two. Effectively, both tcp-transport and radsec
need to have their own backwards compatibility section. I will add text
to the next revision, also for the security considerations.

> 2.  I think the certificate handling and authorization section needs to
> be more specific for supporting mandatory to implement options.
> Currently, the document implicitly requires trust root based
> authorization where all certs issued by a given trust root are
> authorized.  Some more specific rules are discussed in an informative
> section.  I believe some of this needs to be normative and more specific
> in order to have interoperable implementations.  This should also be
> discussed in the security considerations.
>   

The hesitance against mandating specific options is historic from when I
thought this would only become an informational description. I'll
merrily promote the check options mentioned in the document to
mandatory-to-implement. A revised draft will follow.

> 3.  I'm not sure I understand the choice of ciphersuites.
>
> Why is TLS_RSA_WITH_RC4_128_SHA recommended?  It seems that it would be
> much preferable to use AES or 3DES? 
>   

Hm... This was a first shot :-) I can't brag about being a cipher suite
expert. Can you create a list of suggested cipher suites?

> 4.  The document should state that the fixed string "radsec" shared
> secret MUST NOT be used when TLS is not available.  
>   

I fully agree that using a fixed, well-known shared secret is suicidal
when not using TLS. I'm not sure though if it needs to be in this
document though... the document specifies how to behave when *doing*
TLS. People who implement TCP only (without RadSec) wouldn't necessarily
read the RadSec document anyway. So I'm not sure if it makes sense to
write it down here. It makes much sense though to add this word of
warning to tcp-transport though. So... any particular opinion in the
group about adding this or not?

> 5. The terms "dynamic peer resolution" and "dynamic peer discovery" are
> used in the document and not clearly defined.  
>   

The whole dynamic discovery will be moved to a separate document, as
discussed in MSP. That other document should clearly define this though,
agreed.

> 6. Would RADSEC benefit from a mechanism that did not require a PKI?
> This could be achieved by specifying a certificate fingerprint or PSK
> mode of operation.  
>   

I'm almost certain it would! There are certainly deployment scenarios
where a PKI rollout could be seen as "overkill". I tried to formulate
the draft PKI-agnostic, saying "*When using X.509 certificates* in the
"Connection Setup" section, hoping to imply that any other way of
establishing a TLS connection, like with a PSK, is not excluded. I can
make this more explicit though.

Greetings,

Stefan Winter

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

Tel: +352 424409 1
Fax: +352 422473

--
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, 16 Dec 2008 17:11:53 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>, "David B. Nelson" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: Issue with Guidelines document
Date: Tue, 16 Dec 2008 09:11:30 -0800

--_380781a3-26dd-4d14-a4b9-4124844d8442_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>   Yes.  I suggest that the Extended attributes draft (and maybe even the
> guidelines document) contain text that says "Extended attributes with
> Vendor-Id of zero (0) are not to be interpreted as VSA's within the
> meaning of the other drafts".

You might be able to make that recommendation with respect to implementatio=
ns
that understand Extended Attributes (e.g. implementations of the Extended
Attribute specification). But how can we say that with respect to existing=
=20
implementations?  This implies that legacy implementations will treat
Extended Attributes like VSAs (e.g. ignore them if they don't understand
them).  =20

--_380781a3-26dd-4d14-a4b9-4124844d8442_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B   Yes.  I suggest that the Extended attributes draft (and maybe even=
 the<br>&gt=3B guidelines document) contain text that says "Extended attrib=
utes with<br>&gt=3B Vendor-Id of zero (0) are not to be interpreted as VSA'=
s within the<br>&gt=3B meaning of the other drafts".<br><br>You might be ab=
le to make that recommendation with respect to implementations<br>that unde=
rstand Extended Attributes (e.g. implementations of the Extended<br>Attribu=
te specification). But how can we say that with respect to existing <br>imp=
lementations?&nbsp=3B This implies that legacy implementations will treat<b=
r>Extended Attributes like VSAs (e.g. ignore them if they don't understand<=
br>them).&nbsp=3B&nbsp=3B <br></body>
</html>=

--_380781a3-26dd-4d14-a4b9-4124844d8442_--

--
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, 16 Dec 2008 17:07:05 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>, "David B. Nelson" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: draft-ietf-radext-status-server-02 editorials (fwd)
Date: Tue, 16 Dec 2008 09:06:48 -0800

--_2653eca6-4b77-430c-8f36-e519a7087396_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>   Ok... so should it be Experimental=2C or Informational?

FWIW=2C I'd say Informational.  That is what we did for RFC 5176=2C since
its original implementation had so many warts.  Where there were
potential fixes=2C we pointed them out=2C but since the goal was to
describe what was implemented=2C we could not break backward
compatibility by inserting MUST/MUST NOT language to outlaw
poor practices (e.g. the original specification enabled replay
attacks). =20

--_2653eca6-4b77-430c-8f36-e519a7087396_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B   Ok... so should it be Experimental=2C or Informational?<br><br>FWI=
W=2C I'd say Informational.&nbsp=3B That is what we did for RFC 5176=2C sin=
ce<br>its original implementation had so many warts.&nbsp=3B Where there we=
re<br>potential fixes=2C we pointed them out=2C but since the goal was to<b=
r>describe what was implemented=2C we could not break backward<br>compatibi=
lity by inserting MUST/MUST NOT language to outlaw<br>poor practices (e.g. =
the original specification enabled replay<br>attacks).&nbsp=3B <br></body>
</html>=

--_2653eca6-4b77-430c-8f36-e519a7087396_--

--
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, 16 Dec 2008 17:02:31 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>, <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: [ISSUE] Status-Server
Date: Tue, 16 Dec 2008 09:02:08 -0800

--_7b9c7ebd-af26-4d21-ba64-6269f183df06_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> > * I would suggest removing all of section 5.  These topics seem related=
=2C
> > but not germane to the purpose and scope of this doc.

I can see removing all of Section 5=2C though I would want the material in
Section 5.2 to end up somewhere (maybe the RADIUS over TCP doc).=20

Section 5.1 does seem tangential to the goal of describing how Status-Serve=
r
is used. =20

Section 5.2 does seem relevant=2C since it clarifies the use/limitations of
Status-Server over reliable transport.  This section could just as easily
go in the RADIUS over TCP document=2C though.=20

At IETF 73=2C we talked about removing references to CoA (Section 5.3).=20

--_7b9c7ebd-af26-4d21-ba64-6269f183df06_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B &gt=3B * I would suggest removing all of section 5.  These topics se=
em related=2C<br>&gt=3B &gt=3B but not germane to the purpose and scope of =
this doc.<br><br>I can see removing all of Section 5=2C though I would want=
 the material in<br>Section 5.2 to end up somewhere (maybe the RADIUS over =
TCP doc). <br><br>Section 5.1 does seem tangential to the goal of describin=
g how Status-Server<br>is used.&nbsp=3B <br><br>Section 5.2 does seem relev=
ant=2C since it clarifies the use/limitations of<br>Status-Server over reli=
able transport.&nbsp=3B This section could just as easily<br>go in the RADI=
US over TCP document=2C though. <br><br>At IETF 73=2C we talked about remov=
ing references to CoA (Section 5.3). <br><br></body>
</html>=

--_7b9c7ebd-af26-4d21-ba64-6269f183df06_--

--
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, 16 Dec 2008 16:56:35 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Summary of WG review of "RADIUS over TCP" document
Date: Tue, 16 Dec 2008 08:55:32 -0800

--_c82e55c1-bc1b-492e-ad36-0403f6224cf4_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>   I would prefer to leave the discussion of Status-Server && RADIUS ID
> use in this document.  The traditional use of Status-Server is over UDP=
=2C
> and therefore does not have the issues presented here.  (i.e. suggestion
> to reserve one RADIUS ID per TCP connection for Status-Server.)

Why should the ID be unique regardless of packet code when run
over reliable transport=2C but not UDP?  This suggests that the ID is
being processed differently for unreliable vs. reliable transport=2C which
seems odd.=20

--_c82e55c1-bc1b-492e-ad36-0403f6224cf4_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B   I would prefer to leave the discussion of Status-Server &amp=3B&am=
p=3B RADIUS ID<br>&gt=3B use in this document.  The traditional use of Stat=
us-Server is over UDP=2C<br>&gt=3B and therefore does not have the issues p=
resented here.  (i.e. suggestion<br>&gt=3B to reserve one RADIUS ID per TCP=
 connection for Status-Server.)<br><br>Why should the ID be unique regardle=
ss of packet code when run<br>over reliable transport=2C but not UDP?&nbsp=
=3B This suggests that the ID is<br>being processed differently for unrelia=
ble vs. reliable transport=2C which<br>seems odd. <br><br></body>
</html>=

--_c82e55c1-bc1b-492e-ad36-0403f6224cf4_--

--
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, 16 Dec 2008 14:45:16 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-tcp-transport-02.txt 
Date: Tue, 16 Dec 2008 06:45:02 -0800 (PST)

--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 Over TCP
	Author(s)       : A. DeKok
	Filename        : draft-ietf-radext-tcp-transport-02.txt
	Pages           : 16
	Date            : 2008-12-16

The Remote Authentication Dial In User Server (RADIUS) Protocol has
traditionally used the User Datagram Protocol (UDP) as it's
underlying transport layer.  This document defines RADIUS over the
Transmission Control Protocol (TCP).

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-radext-tcp-transport-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--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: Tue, 16 Dec 2008 14:35:13 +0000
Date: Tue, 16 Dec 2008 15:34:30 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: Summary of WG review of "RADIUS over TCP" document

Bernard Aboba wrote:
> Based on the discussion at IETF 73, the following issues have been filed
> against the document:
> 
> Issue 291 	Pending 	Technical 	UDP/TCP Translation
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20291>
> Alan DeKok

  I've updated the document with text as suggested by Bernard.

> Issue 292 	Pending 	Technical 	Applicability
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20292>
> Alan DeKok 

  I have updated the document as per review, and consolidated the
multiple applicability sections into one.  The document now also says
that using bare TCP is NOT RECOMMENDED.

> Issue 293 	Pending 	Technical 	Watchdog Timer
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20293>
> Alan DeKok

  I would prefer to leave the discussion of Status-Server && RADIUS ID
use in this document.  The traditional use of Status-Server is over UDP,
and therefore does not have the issues presented here.  (i.e. suggestion
to reserve one RADIUS ID per TCP connection for Status-Server.)

  Since this document is discussing non-traditional TCP transport issues
related to Status-Server, this document appears to be the best place for
this discussion.

> Issue 294 	No Discussion 	Technical 	Document Status
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20294>
> Bernard Aboba

  I have updated the document status to be "Experimental", to be in line
with the RadSec document, which is also experimental.

> Issue 295 	Pending 	Technical 	Head of Line Blocking
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20295>
> Alan DeKok <mailto:[email-masked]>

  This issue appears to be substantially similar, if not ientical, to
Issue 291.

  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, 16 Dec 2008 10:41:45 +0000
Date: Tue, 16 Dec 2008 11:41:04 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Summary of RADEXT WG Last Call on Status-Server Document

Bernard Aboba wrote:
> Issue 283 	No Discussion 	Technical 	Status-Server Comments
> <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 283> 	Greg
> Weber

  I have responded to that issue.  The only remaining question for the
WG is whether or not Section 5 is appropriate for the document.  If not,
it can be deleted in its entirety.

> Issue 285 	Pending 	Technical 	Question
> <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 285> 	Alan
> DeKok <mailto:[email-masked]>

  The text on CoA has been removed as per WG consensus.  This issue
should be now closed.

> Issue 288 	Pending 	Technical 	Review
> <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 288> 	Stig
> Venaas <mailto:[email-masked]>

  I have updated the document as per comments form the review, with
additional text as per David Nelson.

> Issue 289 	No Discussion 	Editorial 	Editorial Comments
> <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 289> 	Stig
> Venaas <mailto:[email-masked]>

  I responded in a message on December 8.  The comments are mostly
editorial, and the document has been updated as per the review.  The one
change suggested that was not made was changing "packet" to "message".
RFC 2865, etc. use "packet", so that term is used here for consistency.

> Overall, as was discussed during IETF 73, it should be understood that
> the goal of this document is to document the
> existing Status-Server protocol (which was first developed by Ascend
> Communications in the mid-1990s).  Therefore
> inclusion of non-implemented functionality in this document is out of
> scope.

  The CoA text has been deleted.

  I've also updated the document as per editorial reviews from Alfred.

  I will submit an updated document shortly.

  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, 16 Dec 2008 10:04:17 +0000
Date: Tue, 16 Dec 2008 11:03:48 +0100
From: Alan DeKok <[email-masked]>
To: Greg Weber <[email-masked]>
CC: radext mailing list <[email-masked]>
Subject: Re: [ISSUE] Status-Server

Greg Weber wrote:
> * idnits says the boilerplate needs to be updated.

  Done.

> *  In section 3, I see: "Status-Server packets MAY include NAS-Identifier,
> one of NAS-IP-Address or NAS-IPv6-Address, and Reply-Message."
> This conflicts with the Table of Attributes in section 6 which indicates
> that Reply-Message cannot be included in Status-Server packets.

  The Status-Server packet shouldn't include a Reply-Message.  I've
updated the document.

> * Reply-Message can be included in Access-Accept, but not Acct-Response?
> That means the Verbose Query and Response example in section 7.3 works
> only for authentication servers and not accounting servers.  That seems like
> a discontinuity.

  Yes.  It's in line with existing implementations, and with practices
for Accounting-Response.  I wouldn't want this document to make it look
like Accounting-Response can now contain standard RADIUS attributes.

> * The Table of Attributes in section 6 indicates that Calling-Station-Id
> may be included Status-Server and Access-Accept packets.  This
> conflicts with RFC 2865 which disallows that attribute in Access-Accept.
> And, how would this attribute be populated in Status-Server packets
> where there is no associated calling station?

  The reference to Calling-Station-Id has been removed from the Table of
Attributes.

> * I would suggest removing all of section 5.  These topics seem related,
> but not germane to the purpose and scope of this doc.

  Possibly.  Are there other people who agree?

> * In section 4.1, I see "Robust implementations SHOULD accept any Response
> packet as a valid response to a Status-Server packet..."  That seems to be a
> pretty fundamental change to the RADIUS request/response model.  I would
> suggest removing that paragraph or changing it to a MAY.

  As per other reviews, I've updated that to say SHOULD accept
Access-Accept/Accounting-Response.  Other response types are NOT
RECOMMENDED.

> Small changes by section:
> ToC: Fix indent & missing title on 2.3.2
> Section 3: "MUST NOTE" -> "MUST NOT"
> Section 3.1: "is an CoA-ACK packet" -> "is a CoA-ACK packet."

  I've deleted that text.

> Section 4.3: "to start packets to start" -> "to start"
> Section 4.4: "may sent" -> "may be sent"
> Section 4.6: "along along" -> "along"

  Fixed.

> Section 4.6: "impement" -> "implement"
> Section 5.1: "has internal RADIUS server that proxy" ->
>   "has an internal RADIUS server that proxies"

  Fixed as per Alfred's review.

> Section 6: "table provide a guide" -> "table provides a guide"
> 
> Small global changes:
> "it's" -> "its" (6 times)
> "wide-spread" -> "widespread" (2 times)

  Fixed.

> "inter-operable" -> "interoperable" (1 time)

  Fixed.

> "use-case" -> "use case" (3 times)

  Fixed.

> "pro-actively" -> "proactively" (1 time)

  Deleted.

> "re-use" -> "reuse" (3 times)

  Fixed.

> "coa" -> "CoA" (2 times)

  Deleted.

> "16-octet" -> "16 octet" (3 times)

  Fixed.

  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, 16 Dec 2008 09:35:38 +0000
Date: Tue, 16 Dec 2008 10:35:18 +0100
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: [email-masked]
Subject: Re: Issue with Guidelines document

David B. Nelson wrote:
> Is it possible to make a meaningful and logical distinction between Extended
> Attribute and Vendor Specific Attribute? 

  Yes.  I suggest that the Extended attributes draft (and maybe even the
guidelines document) contain text that says "Extended attributes with
Vendor-Id of zero (0) are not to be interpreted as VSA's within the
meaning of the other drafts".

  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, 16 Dec 2008 09:23:27 +0000
Date: Tue, 16 Dec 2008 10:22:44 +0100
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: [email-masked]
Subject: Re: Fwd: draft-ietf-radext-status-server-02 editorials (fwd)

David B. Nelson wrote:
> Given that the intended scope of this draft is to document an implemented
> but heretofore undocumented practice, it seems inappropriate that this draft
> would Update any other RFCs, be they Standards Track or Informational.
> 
> In publishing this draft, the WG does not intend revise any aspects of the
> RADIUS operational model.  We wish acknowledge what's been deployed, without
> raising the status of that deployment so as to create defacto changes to the
> de jure RADIUS protocol.  Perhaps it's a fine line to tread...

  Ok... so should it be Experimental, or Informational?

  There was also some discussion at one point of making it Proposed
Standard, but I don't think the consensus is going that way.

  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, 16 Dec 2008 07:46:53 +0000
Date: Tue, 16 Dec 2008 02:46:04 -0500
From: "Greg Weber" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Subject: Re: Issue with Guidelines document
Cc: "Bernard Aboba" <[email-masked]>,  "[email-masked]" <[email-masked]>

On Mon, Dec 15, 2008 at 2:39 AM, Alan DeKok <[email-masked]> wrote:
> Greg Weber wrote:
>>>  I would like to know what it *means* to have VSA's in an
>>> Accounting-Response.  What does the NAS do with them?  Log them?  Ignore
>>> them?  Change it's behavior?
>>
>> This can be used to communicate server load or pending planned downtime
>> information back to the NAS which then can be used in server selection
>> algorithms.
>
>  That sounds like a bit of a hack to me.  "Yes I've stored the
> accounting data for bob, and by the way, I'm rebooting in 5 minutes".

I think this was used with the client's own accounting session id,
not a user's (bob's) session id.  In other words, when the client booted
or was configured for accounting, it sent an Accounting-Request with
Acct-Status-Type = Accounting-On and Acct-Session-Id = "I am foo client".
Then it sent periodic Accounting-Requests (Acct-Status-Type=Interim-Update)
using the same Acct-Session-Id.  The server could send responses to
these interims with the load or potentially planned downtime schedule info.

--
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, 15 Dec 2008 22:47:45 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue with Guidelines document
Date: Mon, 15 Dec 2008 17:47:19 -0500
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

> It would be good for the Extended Attributes draft to clear this up
> (I've filed on issue on this).  However, a number of existing
> Documents (including RFC 2866 and RFC 5176) make statements about
> the allowable uses of Attribute 26.  Since Extended Attribute
> use Attribute 26, those statements will by default apply.

Well... yes.  That's a logical inference.  I wonder, however, if it's the
inference that we desire.  I think if we fail to separate the restrictions
of the "classic" VSA from the intended use model of the Extended Attributes,
we will have failed in some significant way.  Yes, the Extended Attributes
"overload" the use of the VSA type code, but IMHO they are not VSAs, as we
know them.  Another way of saying this is that all the current references to
type code 26 and/or VSA in the RFCs are in the context of "classic" VSAs,
i.e. "proprietary secret sauce" attributes.

Is it possible to make a meaningful and logical distinction between Extended
Attribute and Vendor Specific Attribute?  If not, I think that the utility
of Extended Attributes will be substantially lessened.

--
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, 15 Dec 2008 22:34:13 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Issue with Guidelines document
Date: Mon, 15 Dec 2008 14:33:26 -0800

David Nelson said:

"If this is a common misunderstanding -- i.e. the traditional usage rules
for
VSAs apply to Extended Attributes -- we should indeed clear up that
confusion immediately.  Perhaps in the Extended Attributes draft itself."

It would be good for the Extended Attributes draft to clear this up
(I've filed on issue on this).  However, a number of existing
Documents (including RFC 2866 and RFC 5176) make statements about
the allowable uses of Attribute 26.  Since Extended Attribute
use Attribute 26, those statements will by default apply.    

--
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, 15 Dec 2008 21:07:08 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'Alfred ?'" <[email-masked]>, <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Subject: RE: Fwd: draft-ietf-radext-status-server-02 editorials (fwd)
Date: Mon, 15 Dec 2008 16:06:42 -0500
Organization: Elbrys Networks, Inc.

Given that the intended scope of this draft is to document an implemented
but heretofore undocumented practice, it seems inappropriate that this draft
would Update any other RFCs, be they Standards Track or Informational.

In publishing this draft, the WG does not intend revise any aspects of the
RADIUS operational model.  We wish acknowledge what's been deployed, without
raising the status of that deployment so as to create defacto changes to the
de jure RADIUS protocol.  Perhaps it's a fine line to tread...

--
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, 15 Dec 2008 20:29:04 +0000
Date: Mon, 15 Dec 2008 21:28:13 +0100
From: Alan DeKok <[email-masked]>
To: [email-masked]
CC: [email-masked], =?UTF-8?B?QWxmcmVkIO+/vQ==?= <[email-masked]>
Subject: Re: Fwd: draft-ietf-radext-status-server-02 editorials (fwd)

> From [email-masked] Thu Dec 11 16:15:59 MEZ 2008
...
> (1)  Section 1, last para -- typo/grammar
> 
>       The remaining text contains ...  and discussed security ...
> ---                                                ^
>       The remaining text contains ...  and discusses security ...

  Fixed.
                                                    ^
> 
> (2)  Section 2.1, last para -- typo
> 
> s/qeuries/queries/
>    ^^      ^^

  Fixed.

> (3)  Section 2.3.2
> 
> (3a)  headline missing  (already noted)
> 
> (3b)  requirements language
> 
> Section 2.3.1 starts:
> 
>    Status-Server SHOULD be used instead ...
>                  !!!!!!
> 
> But 2.3.2, which apparently is intended to catch the alternative
> case left open by that 'SHOULD', starts with:
> 
> |  Status-Server may be used instead of ...
>                  ^^^
> For logical consistency, this counterpoint also should use uppercase:
> 
> |  Status-Server MAY be used instead of ...

  OK, thanks.

                 ^^^
> 
> (4)  Section 2.3.3
> 
> Following up from above, 2.3.3 should also be changed:
> 
>    Status-Server may be pro-actively sent ...
> ---
>    Status-Server MAY be pro-actively sent ...
>                  ^^^

  That section has been deleted, at the suggestion of the RADEXT chairs
&& Area Director.

> (5)  Section 3 -- clarifications
> 
> (5a)  1st para below indented part 'Request Authenticator'
> 
> The draft says:
> 
>    Similarly, the Response Authenticator field of an Access-Accept
>    packet sent in response to Status-Server queries MUST be generated
>    using the same method as used for for calculating the Response
> |  Authenticator of the Access-Accept, with the Status-Server Request
>    Authenticator taking the place of the Access-Request Request
>    Authenticator.
> 
> For clarity, I suggest to insert a phrase better qualifying the
> Access-Accept taken as a reference:
> 
>    Similarly, the Response Authenticator field of an Access-Accept
>    packet sent in response to Status-Server queries MUST be generated
>    using the same method as used for for calculating the Response
> |  Authenticator of the Access-Accept sent in response to an Access-
>    vvvvvvvv                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |  Request, with the Status-Server Request Authenticator taking the
>    place of the Access-Request Request Authenticator.

  Good suggestion, thanks.

> (5b)  2nd para below indented part 'Request Authenticator'
> 
> Similarly, I suggest to improve the wording in the next paragraph:
> 
>    The Response Authenticator field of an Accounting-Response packet
>    sent in response to Status-Server queries MUST be generated using the
>    same method as used for for calculating the Response Authenticator of
> |  the Accounting-Response, with the Status-Server Request Authenticator
>    taking the place of the Accounting-Request Request Authenticator.
> ---
>    The Response Authenticator field of an Accounting-Response packet
>    sent in response to Status-Server queries MUST be generated using the
>    same method as used for for calculating the Response Authenticator of
> |  the Accounting-Response sent in response to and Accounting-Request,
>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    with the Status-Server Request Authenticator taking the place of the
>    Accounting-Request Request Authenticator.

  Agreed.

> 
> (6)  Section 3.1
> 
> (6a)  headline
> 
> To better indicate the simplification for implementations, which seems
> to be the spirit of this detail, I suggest to change the headline
> (this will be even more become clear by the subsequent modification
> I'll propose below):
> 
> |3.1.  Consistent definition for Status-Server
> ---
> |3.1.  Single Definition for Status-Server
>        ^^^^^^^^
> 
> (6b)  2nd paragraph -- clarification / textual improvement
> 
> I suggest to replace "one" by "a single":
> 
>           vvv
> |  Having one definition for Status-Server packets is simpler than
>    having different definitions for different destination ports.  [...]
> ---       vvvvvvvvv
> |  Having a single definition for Status-Server packets is simpler than
>    having different definitions for different destination ports.  [...]

  That is reasonable.

> 
> (7)  Section 4 -- consistent spelling of abbreviation
> 
> For uniformity and consistency, I suggest to    s/coa/CoA/
> (2 instances in Section 4).

  That text has been deleted at the suggestion of the RADEXT chairs &&
the Area Director.

> 
> (8)  Section 4.2
> 
> (8a)  need to update the metadata (front matter)
> 
> The third para says:
> 
>    We note that [RFC2865] Section 3 defines a number of RADIUS Codes,
>    but does not make statements about which Codes are valid for port
> |  1812.  In contrast, [RFC2866] Section 3 specifies that only RADIUS
> |  Accounting packets are to be sent to port 1813.  This specification
>    is compatible with [RFC2865], as it uses a known Code for packets to
>    port 1812.  This specification is not compatible with [RFC2866], as
>    it adds a new code (Status-Server) that is valid for port 1812.
> |  However, as the category of [RFC2866] is Informational, this conflict
> |  is acceptable.
> 
> This statement clearly indicates that this specification
> *** Updates RFC 2866 ***.

  I'll have to ask the RADEXT chairs for help on this one.  Can we do this?

> This relationship really should be noted in the front matter of the
> draft.
> 
> (8b)  7th para -- word omission
> 
> Please correct:
>                                          v
> |  The server MAY prioritize the handling Status-Server queries over the
>    handling of other requests, subject to the rate limiting described
>    above.
> ---                                      vvvv
> |  The server MAY prioritize the handling of Status-Server queries over
>    the handling of other requests, subject to the rate limiting
>    described above.

  Fixed as per earlier comments.

> 
> (9)  Section 4.3
> 
> (9a)  1st para -- improvement #1
...
> (9b)  1st para -- improvement #2 (missing word)
...
> (9c)  4th para -- inconsistency with 1st para
...
> (9d)  last para -- punctuation

  All of this text has been deleted as per comments from the chairs &&
the AD.

> (10)  Section 4.4, 2nd para -- improvement
> 
> I suggest to slightly change the wording:
> 
>         [...].  If the server is still unresponsive, however, the result
>    may be user login failures.  The Status-Server solution is an ideal
> |  one to solve this problem.
> ---^^^
>         [...].  If the server is still unresponsive, however, the result
>    may be user login failures.  The Status-Server solution is an ideal
> |  way to solve this problem.
>    ^^^

  Fixed, thanks.

> 
> (11)  Section 4.6
> 
> (11a)  4th para below first figure -- improvement/grammar
> 
> I suggest to change:
> 
>            [...].  If the implementation fails to respond, then the NAS
>    cannot distinguish between the Proxy Server being down, or the next
> |  server along along the proxy chain is unreachable.
> --                                    ^^
>            [...].  If the implementation fails to respond, then the NAS
>    cannot distinguish between the Proxy Server being down, or the next
> |  server along along the proxy chain being unreachable.
>                                       ^^^^^

  Agreed.

> (11b)  5th para below first figure -- missing word
> 
> I suggest to insert "in" as follows:
> 
>    In the worst case, failures in routing for Realm A may affect users
> |  Realm B.  [...]
> ---^
>    In the worst case, failures in routing for Realm A may affect users
> |  in Realm B.  [...]
>    ^^^^

  Changed to "of" Realm B, as per earlier comments.

> (11c)  denomination of entities
> 
>>From the second figure ...
> 
>                 /-> Proxy Server P -----> Home Server P
>                /                    \ /
>             NAS                      X
>                \                    / \
>                 \-> Proxy Server S -----> Home Server S
> 
> ... it becomes apparent that the denominations of the entities are
> not chosen carefully; in this case, 'P' and 'S' are both overloaded.
> 
> To disambiguate the whole stuff, here's my proposal:
> 
> Use 'P1' and 'P2' (in place of 'P' and 'S') for the two Proxy Servers
> in both scenarios (figures and text); use 'H1' and 'H2'  for the Home
> Servers in the second scenario.

  The terms "Primary" and "Secondary" are commonly used in RADIUS.  I'll
see if there's some compromise that uses historical terminology, but
also clarifies the diagram.

> (12)  Section 4.7 -- terminology
> 
> The draft uses the colloquial, but incorrect short term "MIB" whenever
> in wants to indicate a "MIB Module".  Please see the BCP 111, RFC 4181
> for the detailed rationale of the precise terminology.
> 
> Therefore,  please change     MIB[s]   -->   MIB module[s]
> throughout the text.

  Fixed.

> (13)  Section 4.7.1
> 
> (13a)  need to update the metadata (front matter)
> 
> The 1st para clearly indicates that this draft
> ***  Updates RFC 4669 and RFC 4671  ***
> 
> To make it easier for developers and users to find this update,
> please amend the draft front matter accordingly.

  I'm not sure it *updates* those documents.  Comments from the Area
Director would help here.

> (13b)  last para
> 
> The draft text is confusingly complicated, yet inprecise.
> The draft text could be misunderstood as recommending to
> define alternate MIB modules where it better should recommend
>  using extensions for standard MIB tables.
> 
> I suggest to modify this paragraph as follows:
> 
>    If a server supports Status-Server and the [RFC4669] or [RFC4671]
> |  MIBs, then it SHOULD also support vendor-specific MIBs containing
> |  similar information as the standard MIBs, but which are instead
>    dedicated solely to tracking Status-Server requests and responses.
> |  Any definition of the server MIBs for Status-Server is outside of the
>    scope of this document.
> ---
> |  If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB
> |  modules, then it SHOULD also support vendor-specific MIB extensions
>    ^^^^^^^                                              ^^^^^^^^^^^^^^^^
>    dedicated solely to tracking Status-Server requests and responses.
> |  Any definition of the server MIB module extensions for Status-Server
>                                 ^^^^^^^^^^^^^^^^^^^^^
>    is outside of the scope of this document.

  OK.

> (Please note the deletion of the full 3rd line!)

  Noted.

> (14)   Section 4.7.2
> 
> (14a)
> Similar as noted in (13a) above, the first para of 4.7.2 clearly
> indicates that this specification  *** updates RFCs 4668 and 4670 ***.

  Maybe clarifies?  I'm unsure here.

> (14b)
> Similarly as in (13b) above, the last para of 4.7.2 should be modified
> as follows:
> 
>    If an implementation supports Status-Server and the [RFC4668] or
> |  [RFC4670] MIBs, then it SHOULD also support vendor-specific MIBs
> |  containing similar information as those MIBs, but which are instead
>    dedicated solely to tracking Status-Server requests and responses.
> |  Any definition of the client MIBs for Status-Server is outside of the
>    scope of this document.
> ---
>    If an implementation supports Status-Server and the [RFC4668] or
> |  [RFC4670] MIB modules, then it SHOULD also support vendor-specific
>              ^^^^^^^^^^^
> |  MIB extensions dedicated solely to tracking Status-Server requests
>    ^^^^^^^^^^^^^^^
> |  and responses.  Any definition of the client MIB module extensions
>                                                 ^^^^^^^^^^^^^^^^^^^^^
>    for Status-Server is outside of the scope of this document.

  OK.

> (15)  Section 5.1
> 
> (15a)  2nd para, last sentence -- typo/grammar
> 
> Please   s/server/servers/  in ...
> 
>                      [...].  These queries are most useful in
> |  deployments where an administrator has internal RADIUS servers that

  Fixed, thanks.

> (15b)  3rd para -- improvement
> 
> To improve the readability, I suggest varying the multiple uses of
> "use", e.g.:
>       vvvv            vvvv                vvvvv
>    If used, the names used for these test users SHOULD be difficult to
>    guess by an attacker.  [...]
> ---                   vvvvvvvv
>    If used, the names utilized for these test users SHOULD be difficult
>    to guess by an attacker.  [...]

  Ok.

> (16)  Section 5.2  -- outdated text
> 
> The first paragraph seems to be outdated now by the RADIUS-over-TCP
> draft!

  Yes.  I'll see if I can coordinate the text.  The "RADIUS over TCP"
will be published after this one.  I don't know that we want to have the
two drafts depend on each other...

> (17)  Section 5.3, 1st para
> 
> The draft says:
>                                                   [...].  It may be
>    tempting to increase the utility of Status-Server by having the
> |  responses carry additional information, implementors are warned that
>    such uses have not been analyzed for potential security issues or
>    network problems.
> 
> To better reflect the relationship between the two (half-)sentences
> connected with a comma, I propose to either use a semicolon instead
> of the comma, or insert  " but" after the comma:
> 
>                                                   [...].  It may be
>    tempting to increase the utility of Status-Server by having the
> |  responses carry additional information, but implementors are warned
>    that such uses have not been analyzed for potential security issues
>    or network problems.

  I would suggest using "but".

  Thanks for the feedback.

  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: Mon, 15 Dec 2008 18:49:14 +0000
Date: Mon, 15 Dec 2008 18:48:52 +0000 (UTC)
From: [email-masked]
To: [email-masked]
Subject: Fwd: draft-ietf-radext-status-server-02 editorials (fwd)

------=_Part_166748_896156211.1229366932742
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Forwarding for a non-list member:=20

>From [email-masked] Thu Dec 11 16:15:59 MEZ 2008=20
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16=
.3)=20
=C2=A0=C2=A0 =C2=A0 =C2=A0id AA022718557; Thu, 11 Dec 2008 16:15:57 +0100=
=20
Return-Path: <[email-masked]>=20
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)=20
=C2=A0=C2=A0 =C2=A0 =C2=A0id QAA22212; Thu, 11 Dec 2008 16:15:57 +0100 (MEZ=
)=20
From: Alfred H=EF=BF=BDnes <[email-masked]>=20
To: [email-masked]=20
Cc: [email-masked]=20
Message-Id: <[email-masked]>=20
Date: Thu, 11 Dec 2008 16:15:56 +0100 (MEZ)=20
Subject: draft-ietf-radext-status-server-02 editorials=20

Hello,=20
after studying the Internet-Draft authored/edited by you,=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-radext-status-server-02,=
=20
I'd like to submit a few comments, mostly addressing textual=20
flaws I found in that memo.=20

Note on proofreading:=20
=C2=A0=C2=A0Quickly browsing the radext list, I saw that there's some overl=
ap=20
=C2=A0=C2=A0of another review with the items below. =C2=A0My apologies -- I=
 didn't=20
=C2=A0=C2=A0clean up that all now to avoid having to renumber the items.=20

The items below are presented in textual order.=20
To give more context, sometimes I quote larger blocks of text=20
literally and show the replacement proposed using the shorthand=20
notation:=20

=C2=A0=C2=A0 <original draft text>=20
---=20
=C2=A0=C2=A0 <modified text>=20

I use change bars ('|' in column 1) and up/down pointing marker=20
lines ('^^^'/'vvv') to emphasize the location of textual issues=20
and/or proposed corrections. =C2=A0Modified text has been re-adjusted=20
to match RFC formatting rules, where appropriate.=20

(1) =C2=A0Section 1, last para -- typo/grammar=20

=C2=A0=C2=A0 =C2=A0 =C2=A0The remaining text contains ... =C2=A0and discuss=
ed security ...=20
--- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0^=20
=C2=A0=C2=A0 =C2=A0 =C2=A0The remaining text contains ... =C2=A0and discuss=
es security ...=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^=20

(2) =C2=A0Section 2.1, last para -- typo=20

s/qeuries/queries/=20
=C2=A0=C2=A0 ^^ =C2=A0 =C2=A0 =C2=A0^^=20

(3) =C2=A0Section 2.3.2=20

(3a) =C2=A0headline missing =C2=A0(already noted)=20

(3b) =C2=A0requirements language=20

Section 2.3.1 starts:=20

=C2=A0=C2=A0 Status-Server SHOULD be used instead ...=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 !!!!!!=20

But 2.3.2, which apparently is intended to catch the alternative=20
case left open by that 'SHOULD', starts with:=20

| =C2=A0Status-Server may be used instead of ...=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^=20
For logical consistency, this counterpoint also should use uppercase:=20

| =C2=A0Status-Server MAY be used instead of ...=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^=20

(4) =C2=A0Section 2.3.3=20

Following up from above, 2.3.3 should also be changed:=20

=C2=A0=C2=A0 Status-Server may be pro-actively sent ...=20
---=20
=C2=A0=C2=A0 Status-Server MAY be pro-actively sent ...=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^=20

(5) =C2=A0Section 3 -- clarifications=20

(5a) =C2=A01st para below indented part 'Request Authenticator'=20

The draft says:=20

=C2=A0=C2=A0 Similarly, the Response Authenticator field of an Access-Accep=
t=20
=C2=A0=C2=A0 packet sent in response to Status-Server queries MUST be gener=
ated=20
=C2=A0=C2=A0 using the same method as used for for calculating the Response=
=20
| =C2=A0Authenticator of the Access-Accept, with the Status-Server Request=
=20
=C2=A0=C2=A0 Authenticator taking the place of the Access-Request Request=
=20
=C2=A0=C2=A0 Authenticator.=20

For clarity, I suggest to insert a phrase better qualifying the=20
Access-Accept taken as a reference:=20

=C2=A0=C2=A0 Similarly, the Response Authenticator field of an Access-Accep=
t=20
=C2=A0=C2=A0 packet sent in response to Status-Server queries MUST be gener=
ated=20
=C2=A0=C2=A0 using the same method as used for for calculating the Response=
=20
| =C2=A0Authenticator of the Access-Accept sent in response to an Access-=
=20
=C2=A0=C2=A0 vvvvvvvv =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=20
| =C2=A0Request, with the Status-Server Request Authenticator taking the=20
=C2=A0=C2=A0 place of the Access-Request Request Authenticator.=20

(5b) =C2=A02nd para below indented part 'Request Authenticator'=20

Similarly, I suggest to improve the wording in the next paragraph:=20

=C2=A0=C2=A0 The Response Authenticator field of an Accounting-Response pac=
ket=20
=C2=A0=C2=A0 sent in response to Status-Server queries MUST be generated us=
ing the=20
=C2=A0=C2=A0 same method as used for for calculating the Response Authentic=
ator of=20
| =C2=A0the Accounting-Response, with the Status-Server Request Authenticat=
or=20
=C2=A0=C2=A0 taking the place of the Accounting-Request Request Authenticat=
or.=20
---=20
=C2=A0=C2=A0 The Response Authenticator field of an Accounting-Response pac=
ket=20
=C2=A0=C2=A0 sent in response to Status-Server queries MUST be generated us=
ing the=20
=C2=A0=C2=A0 same method as used for for calculating the Response Authentic=
ator of=20
| =C2=A0the Accounting-Response sent in response to and Accounting-Request,=
=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=20
=C2=A0=C2=A0 with the Status-Server Request Authenticator taking the place =
of the=20
=C2=A0=C2=A0 Accounting-Request Request Authenticator.=20

(6) =C2=A0Section 3.1=20

(6a) =C2=A0headline=20

To better indicate the simplification for implementations, which seems=20
to be the spirit of this detail, I suggest to change the headline=20
(this will be even more become clear by the subsequent modification=20
I'll propose below):=20

|3.1. =C2=A0Consistent definition for Status-Server=20
---=20
|3.1. =C2=A0Single Definition for Status-Server=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 ^^^^^^^^=20

(6b) =C2=A02nd paragraph -- clarification / textual improvement=20

I suggest to replace "one" by "a single":=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vvv=20
| =C2=A0Having one definition for Status-Server packets is simpler than=20
=C2=A0=C2=A0 having different definitions for different destination ports. =
=C2=A0[...]=20
--- =C2=A0 =C2=A0 =C2=A0 vvvvvvvvv=20
| =C2=A0Having a single definition for Status-Server packets is simpler tha=
n=20
=C2=A0=C2=A0 having different definitions for different destination ports. =
=C2=A0[...]=20

(7) =C2=A0Section 4 -- consistent spelling of abbreviation=20

For uniformity and consistency, I suggest to =C2=A0 =C2=A0s/coa/CoA/=20
(2 instances in Section 4).=20

(8) =C2=A0Section 4.2=20

(8a) =C2=A0need to update the metadata (front matter)=20

The third para says:=20

=C2=A0=C2=A0 We note that [RFC2865] Section 3 defines a number of RADIUS Co=
des,=20
=C2=A0=C2=A0 but does not make statements about which Codes are valid for p=
ort=20
| =C2=A01812. =C2=A0In contrast, [RFC2866] Section 3 specifies that only RA=
DIUS=20
| =C2=A0Accounting packets are to be sent to port 1813. =C2=A0This specific=
ation=20
=C2=A0=C2=A0 is compatible with [RFC2865], as it uses a known Code for pack=
ets to=20
=C2=A0=C2=A0 port 1812. =C2=A0This specification is not compatible with [RF=
C2866], as=20
=C2=A0=C2=A0 it adds a new code (Status-Server) that is valid for port 1812=
.=20
| =C2=A0However, as the category of [RFC2866] is Informational, this confli=
ct=20
| =C2=A0is acceptable.=20

This statement clearly indicates that this specification=20
*** Updates RFC 2866 ***.=20

This relationship really should be noted in the front matter of the=20
draft.=20

(8b) =C2=A07th para -- word omission=20

Please correct:=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v=20
| =C2=A0The server MAY prioritize the handling Status-Server queries over t=
he=20
=C2=A0=C2=A0 handling of other requests, subject to the rate limiting descr=
ibed=20
=C2=A0=C2=A0 above.=20
--- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vvvv=20
| =C2=A0The server MAY prioritize the handling of Status-Server queries ove=
r=20
=C2=A0=C2=A0 the handling of other requests, subject to the rate limiting=
=20
=C2=A0=C2=A0 described above.=20

(9) =C2=A0Section 4.3=20

(9a) =C2=A01st para -- improvement #1=20

I suggest to improver the wording:=20

=C2=A0=C2=A0 When a Dynamic Authorization Client ([RFC5176] Section 1.3) re=
boots,=20
| =C2=A0it SHOULD send a Status-Server packet to a CoA port to IP addresses=
=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 !! =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0!!=20
=C2=A0=C2=A0 that are configured as both Dynamic Authorization Servers and =
RADIUS=20
=C2=A0=C2=A0 clients. =C2=A0[...]=20
---=20
=C2=A0=C2=A0 When a Dynamic Authorization Client ([RFC5176] Section 1.3) re=
boots,=20
| =C2=A0it SHOULD send a Status-Server packet to a CoA port at IP addresses=
=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^=20
=C2=A0=C2=A0 that are configured as both Dynamic Authorization Servers and =
RADIUS=20
=C2=A0=C2=A0 clients. =C2=A0[...]=20

(9b) =C2=A01st para -- improvement #2 (missing word)=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...] =C2=A0Wh=
en a response is received, the Dynamic=20
=C2=A0=C2=A0 Authorization Client MUST NOT send further Status-Server packe=
ts to=20
| =C2=A0the CoA port of any Dynamic Authorization until it next reboots.=20
--- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...] =C2=A0Wh=
en a response is received, the Dynamic=20
=C2=A0=C2=A0 Authorization Client MUST NOT send further Status-Server packe=
ts to=20
| =C2=A0the CoA port of any Dynamic Authorization Server until it next=20
=C2=A0=C2=A0 reboots.=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0^^^^^^^^=20
(9c) =C2=A04th para -- inconsistency with 1st para=20

The final part of the 4th para apparently contradicts the last=20
sentence of the first para (quoted in (9b) above):=20

| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0[...]. =C2=A0The NAS MAY=20
| =C2=A0otherwise decide to receive multiple packets to it's CoA port befor=
e=20
| =C2=A0marking the RADIUS server as responsive. =C2=A0This behavior is=20
| =C2=A0implementation-defined, and SHOULD be configurable.=20

(9d) =C2=A0last para -- punctuation=20

The last comma (after "port 3799") IMO distorts the sentence=20
and should better be deleted.=20

(10) =C2=A0Section 4.4, 2nd para -- improvement=20

I suggest to slightly change the wording:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]. =C2=A0If the server is still unresp=
onsive, however, the result=20
=C2=A0=C2=A0 may be user login failures. =C2=A0The Status-Server solution i=
s an ideal=20
| =C2=A0one to solve this problem.=20
---^^^=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]. =C2=A0If the server is still unresp=
onsive, however, the result=20
=C2=A0=C2=A0 may be user login failures. =C2=A0The Status-Server solution i=
s an ideal=20
| =C2=A0way to solve this problem.=20
=C2=A0=C2=A0 ^^^=20

(11) =C2=A0Section 4.6=20

(11a) =C2=A04th para below first figure -- improvement/grammar=20

I suggest to change:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [...]. =C2=A0If the implementation=
 fails to respond, then the NAS=20
=C2=A0=C2=A0 cannot distinguish between the Proxy Server being down, or the=
 next=20
| =C2=A0server along along the proxy chain is unreachable.=20
-- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [...]. =C2=A0If the implementation=
 fails to respond, then the NAS=20
=C2=A0=C2=A0 cannot distinguish between the Proxy Server being down, or the=
 next=20
| =C2=A0server along along the proxy chain being unreachable.=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^=20

(11b) =C2=A05th para below first figure -- missing word=20

I suggest to insert "in" as follows:=20

=C2=A0=C2=A0 In the worst case, failures in routing for Realm A may affect =
users=20
| =C2=A0Realm B. =C2=A0[...]=20
---^=20
=C2=A0=C2=A0 In the worst case, failures in routing for Realm A may affect =
users=20
| =C2=A0in Realm B. =C2=A0[...]=20
=C2=A0=C2=A0 ^^^^=20

(11c) =C2=A0denomination of entities=20

>From the second figure ...=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/-> Proxy Serv=
er P -----> Home Server P=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 / =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\ /=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NAS =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0X=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \ =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\-> Proxy Serv=
er S -----> Home Server S=20

... it becomes apparent that the denominations of the entities are=20
not chosen carefully; in this case, 'P' and 'S' are both overloaded.=20

To disambiguate the whole stuff, here's my proposal:=20

Use 'P1' and 'P2' (in place of 'P' and 'S') for the two Proxy Servers=20
in both scenarios (figures and text); use 'H1' and 'H2' =C2=A0for the Home=
=20
Servers in the second scenario.=20

(12) =C2=A0Section 4.7 -- terminology=20

The draft uses the colloquial, but incorrect short term "MIB" whenever=20
in wants to indicate a "MIB Module". =C2=A0Please see the BCP 111, RFC 4181=
=20
for the detailed rationale of the precise terminology.=20

Therefore, =C2=A0please change =C2=A0 =C2=A0 MIB[s] =C2=A0 --> =C2=A0 MIB m=
odule[s]=20
throughout the text.=20

(13) =C2=A0Section 4.7.1=20

(13a) =C2=A0need to update the metadata (front matter)=20

The 1st para clearly indicates that this draft=20
*** =C2=A0Updates RFC 4669 and RFC 4671 =C2=A0***=20

To make it easier for developers and users to find this update,=20
please amend the draft front matter accordingly.=20

(13b) =C2=A0last para=20

The draft text is confusingly complicated, yet inprecise.=20
The draft text could be misunderstood as recommending to=20
define alternate MIB modules where it better should recommend=20
=C2=A0using extensions for standard MIB tables.=20

I suggest to modify this paragraph as follows:=20

=C2=A0=C2=A0 If a server supports Status-Server and the [RFC4669] or [RFC46=
71]=20
| =C2=A0MIBs, then it SHOULD also support vendor-specific MIBs containing=
=20
| =C2=A0similar information as the standard MIBs, but which are instead=20
=C2=A0=C2=A0 dedicated solely to tracking Status-Server requests and respon=
ses.=20
| =C2=A0Any definition of the server MIBs for Status-Server is outside of t=
he=20
=C2=A0=C2=A0 scope of this document.=20
---=20
| =C2=A0If a server supports Status-Server and the [RFC4669] or [RFC4671] M=
IB=20
| =C2=A0modules, then it SHOULD also support vendor-specific MIB extensions=
=20
=C2=A0=C2=A0 ^^^^^^^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^=20
=C2=A0=C2=A0 dedicated solely to tracking Status-Server requests and respon=
ses.=20
| =C2=A0Any definition of the server MIB module extensions for Status-Serve=
r=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^=20
=C2=A0=C2=A0 is outside of the scope of this document.=20

(Please note the deletion of the full 3rd line!)=20

(14) =C2=A0 Section 4.7.2=20

(14a)=20
Similar as noted in (13a) above, the first para of 4.7.2 clearly=20
indicates that this specification =C2=A0*** updates RFCs 4668 and 4670 ***.=
=20

(14b)=20
Similarly as in (13b) above, the last para of 4.7.2 should be modified=20
as follows:=20

=C2=A0=C2=A0 If an implementation supports Status-Server and the [RFC4668] =
or=20
| =C2=A0[RFC4670] MIBs, then it SHOULD also support vendor-specific MIBs=20
| =C2=A0containing similar information as those MIBs, but which are instead=
=20
=C2=A0=C2=A0 dedicated solely to tracking Status-Server requests and respon=
ses.=20
| =C2=A0Any definition of the client MIBs for Status-Server is outside of t=
he=20
=C2=A0=C2=A0 scope of this document.=20
---=20
=C2=A0=C2=A0 If an implementation supports Status-Server and the [RFC4668] =
or=20
| =C2=A0[RFC4670] MIB modules, then it SHOULD also support vendor-specific=
=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^=20
| =C2=A0MIB extensions dedicated solely to tracking Status-Server requests=
=20
=C2=A0=C2=A0 ^^^^^^^^^^^^^^^=20
| =C2=A0and responses. =C2=A0Any definition of the client MIB module extens=
ions=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^=20
=C2=A0=C2=A0 for Status-Server is outside of the scope of this document.=20

(15) =C2=A0Section 5.1=20

(15a) =C2=A02nd para, last sentence -- typo/grammar=20

Please =C2=A0 s/server/servers/ =C2=A0in ...=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 [...]. =C2=A0These queries are most useful in=20
| =C2=A0deployments where an administrator has internal RADIUS servers that=
=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0^=20
=C2=A0=C2=A0 proxy to other internal RADIUS servers, such as for load balan=
cing or=20
=C2=A0=C2=A0 fail over.=20

(15b) =C2=A03rd para -- improvement=20

To improve the readability, I suggest varying the multiple uses of=20
"use", e.g.:=20
=C2=A0=C2=A0 =C2=A0 =C2=A0vvvv =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vvv=
v =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vvvvv=20
=C2=A0=C2=A0 If used, the names used for these test users SHOULD be difficu=
lt to=20
=C2=A0=C2=A0 guess by an attacker. =C2=A0[...]=20
--- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vvvvvvvv=
=20
=C2=A0=C2=A0 If used, the names utilized for these test users SHOULD be dif=
ficult=20
=C2=A0=C2=A0 to guess by an attacker. =C2=A0[...]=20

(16) =C2=A0Section 5.2 =C2=A0-- outdated text=20

The first paragraph seems to be outdated now by the RADIUS-over-TCP=20
draft!=20

(17) =C2=A0Section 5.3, 1st para=20

The draft says:=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]. =C2=A0It may be=20
=C2=A0=C2=A0 tempting to increase the utility of Status-Server by having th=
e=20
| =C2=A0responses carry additional information, implementors are warned tha=
t=20
=C2=A0=C2=A0 such uses have not been analyzed for potential security issues=
 or=20
=C2=A0=C2=A0 network problems.=20

To better reflect the relationship between the two (half-)sentences=20
connected with a comma, I propose to either use a semicolon instead=20
of the comma, or insert =C2=A0" but" after the comma:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]. =C2=A0It may be=20
=C2=A0=C2=A0 tempting to increase the utility of Status-Server by having th=
e=20
| =C2=A0responses carry additional information, but implementors are warned=
=20
=C2=A0=C2=A0 that such uses have not been analyzed for potential security i=
ssues=20
=C2=A0=C2=A0 or network problems.=20

Best regards,=20
=C2=A0=C2=A0Alfred H=EF=BF=BDnes.=20

--=20

+------------------------+--------------------------------------------+=20
| TR-Sys Alfred Hoenes =C2=A0 | =C2=A0Alfred Hoenes =C2=A0 Dipl.-Math., Dip=
l.-Phys. =C2=A0|=20
| Gerlinger Strasse 12 =C2=A0 | =C2=A0Phone: (+49)7156/9635-0, Fax: -18 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |=20
| D-71254 =C2=A0Ditzingen =C2=A0 =C2=A0 | =C2=A0E-Mail: =C2=[email-masked] =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=20
+------------------------+--------------------------------------------+=20

------=_Part_166748_896156211.1229366932742
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Arial; font-size: 12pt; color: #000000'><P>Forwar=
ding for a non-list member:</P>
<P><BR>From [email-masked] Thu Dec 11 16:15:59 MEZ 2008<BR>Received: fr=
om ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3)<BR>&nbsp=
;&nbsp; &nbsp; &nbsp;id AA022718557; Thu, 11 Dec 2008 16:15:57 +0100<BR>Ret=
urn-Path: &lt;[email-masked]&gt;<BR>Received: (from ah@localhost) by z.=
TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)<BR>&nbsp;&nbsp; &nbsp; &nbsp;id QAA222=
12; Thu, 11 Dec 2008 16:15:57 +0100 (MEZ)<BR>From: Alfred H=EF=BF=BDnes &lt=
;[email-masked]&gt;<BR>To: [email-masked]<BR>Cc: [email-masked]=
<BR>Message-Id: &lt;[email-masked]&gt;<BR>Date: Thu, 11 De=
c 2008 16:15:56 +0100 (MEZ)<BR>Subject: draft-ietf-radext-status-server-02 =
editorials<BR><BR>Hello,<BR>after studying the Internet-Draft authored/edit=
ed by you,<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;draft-ietf-radext-sta=
tus-server-02,<BR>I'd like to submit a few comments, mostly addressing text=
ual<BR>flaws I found in that memo.<BR><BR>Note on proofreading:<BR>&nbsp;&n=
bsp;Quickly browsing the radext list, I saw that there's some overlap<BR>&n=
bsp;&nbsp;of another review with the items below. &nbsp;My apologies -- I d=
idn't<BR>&nbsp;&nbsp;clean up that all now to avoid having to renumber the =
items.<BR><BR><BR>The items below are presented in textual order.<BR>To giv=
e more context, sometimes I quote larger blocks of text<BR>literally and sh=
ow the replacement proposed using the shorthand<BR>notation:<BR><BR>&nbsp;&=
nbsp; &lt;original draft text&gt;<BR>---<BR>&nbsp;&nbsp; &lt;modified text&=
gt;<BR><BR>I use change bars ('|' in column 1) and up/down pointing marker<=
BR>lines ('^^^'/'vvv') to emphasize the location of textual issues<BR>and/o=
r proposed corrections. &nbsp;Modified text has been re-adjusted<BR>to matc=
h RFC formatting rules, where appropriate.<BR><BR><BR>(1) &nbsp;Section 1, =
last para -- typo/grammar<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp;The remaining te=
xt contains ... &nbsp;and discussed security ...<BR>--- &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^<=
BR>&nbsp;&nbsp; &nbsp; &nbsp;The remaining text contains ... &nbsp;and disc=
usses security ...<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^<BR><BR>(2) &nbsp;Sec=
tion 2.1, last para -- typo<BR><BR>s/qeuries/queries/<BR>&nbsp;&nbsp; ^^ &n=
bsp; &nbsp; &nbsp;^^<BR><BR>(3) &nbsp;Section 2.3.2<BR><BR>(3a) &nbsp;headl=
ine missing &nbsp;(already noted)<BR><BR>(3b) &nbsp;requirements language<B=
R><BR>Section 2.3.1 starts:<BR><BR>&nbsp;&nbsp; Status-Server SHOULD be use=
d instead ...<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; !!!!!!<BR><BR>But 2.3.2, which apparently is intended to catch the alte=
rnative<BR>case left open by that 'SHOULD', starts with:<BR><BR>| &nbsp;Sta=
tus-Server may be used instead of ...<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; ^^^<BR>For logical consistency, this counterpoi=
nt also should use uppercase:<BR><BR>| &nbsp;Status-Server MAY be used inst=
ead of ...<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 ^^^<BR><BR>(4) &nbsp;Section 2.3.3<BR><BR>Following up from above, 2.3.3 s=
hould also be changed:<BR><BR>&nbsp;&nbsp; Status-Server may be pro-activel=
y sent ...<BR>---<BR>&nbsp;&nbsp; Status-Server MAY be pro-actively sent ..=
.<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^^^<BR><=
BR>(5) &nbsp;Section 3 -- clarifications<BR><BR>(5a) &nbsp;1st para below i=
ndented part 'Request Authenticator'<BR><BR>The draft says:<BR><BR>&nbsp;&n=
bsp; Similarly, the Response Authenticator field of an Access-Accept<BR>&nb=
sp;&nbsp; packet sent in response to Status-Server queries MUST be generate=
d<BR>&nbsp;&nbsp; using the same method as used for for calculating the Res=
ponse<BR>| &nbsp;Authenticator of the Access-Accept, with the Status-Server=
 Request<BR>&nbsp;&nbsp; Authenticator taking the place of the Access-Reque=
st Request<BR>&nbsp;&nbsp; Authenticator.<BR><BR>For clarity, I suggest to =
insert a phrase better qualifying the<BR>Access-Accept taken as a reference=
:<BR><BR>&nbsp;&nbsp; Similarly, the Response Authenticator field of an Acc=
ess-Accept<BR>&nbsp;&nbsp; packet sent in response to Status-Server queries=
 MUST be generated<BR>&nbsp;&nbsp; using the same method as used for for ca=
lculating the Response<BR>| &nbsp;Authenticator of the Access-Accept sent i=
n response to an Access-<BR>&nbsp;&nbsp; vvvvvvvv &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^^^^^^^^^^=
^^^^^^^^^^^^^^^^^^^^^<BR>| &nbsp;Request, with the Status-Server Request Au=
thenticator taking the<BR>&nbsp;&nbsp; place of the Access-Request Request =
Authenticator.<BR><BR>(5b) &nbsp;2nd para below indented part 'Request Auth=
enticator'<BR><BR>Similarly, I suggest to improve the wording in the next p=
aragraph:<BR><BR>&nbsp;&nbsp; The Response Authenticator field of an Accoun=
ting-Response packet<BR>&nbsp;&nbsp; sent in response to Status-Server quer=
ies MUST be generated using the<BR>&nbsp;&nbsp; same method as used for for=
 calculating the Response Authenticator of<BR>| &nbsp;the Accounting-Respon=
se, with the Status-Server Request Authenticator<BR>&nbsp;&nbsp; taking the=
 place of the Accounting-Request Request Authenticator.<BR>---<BR>&nbsp;&nb=
sp; The Response Authenticator field of an Accounting-Response packet<BR>&n=
bsp;&nbsp; sent in response to Status-Server queries MUST be generated usin=
g the<BR>&nbsp;&nbsp; same method as used for for calculating the Response =
Authenticator of<BR>| &nbsp;the Accounting-Response sent in response to and=
 Accounting-Request,<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^<BR>&nbsp;&nbsp; with the Status-Server Request Authenticator =
taking the place of the<BR>&nbsp;&nbsp; Accounting-Request Request Authenti=
cator.<BR><BR><BR>(6) &nbsp;Section 3.1<BR><BR>(6a) &nbsp;headline<BR><BR>T=
o better indicate the simplification for implementations, which seems<BR>to=
 be the spirit of this detail, I suggest to change the headline<BR>(this wi=
ll be even more become clear by the subsequent modification<BR>I'll propose=
 below):<BR><BR>|3.1. &nbsp;Consistent definition for Status-Server<BR>---<=
BR>|3.1. &nbsp;Single Definition for Status-Server<BR>&nbsp;&nbsp; &nbsp; &=
nbsp; ^^^^^^^^<BR><BR>(6b) &nbsp;2nd paragraph -- clarification / textual i=
mprovement<BR><BR>I suggest to replace "one" by "a single":<BR><BR>&nbsp;&n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp;vvv<BR>| &nbsp;Having one definition for St=
atus-Server packets is simpler than<BR>&nbsp;&nbsp; having different defini=
tions for different destination ports. &nbsp;[...]<BR>--- &nbsp; &nbsp; &nb=
sp; vvvvvvvvv<BR>| &nbsp;Having a single definition for Status-Server packe=
ts is simpler than<BR>&nbsp;&nbsp; having different definitions for differe=
nt destination ports. &nbsp;[...]<BR><BR><BR>(7) &nbsp;Section 4 -- consist=
ent spelling of abbreviation<BR><BR>For uniformity and consistency, I sugge=
st to &nbsp; &nbsp;s/coa/CoA/<BR>(2 instances in Section 4).<BR><BR><BR>(8)=
 &nbsp;Section 4.2<BR><BR>(8a) &nbsp;need to update the metadata (front mat=
ter)<BR><BR>The third para says:<BR><BR>&nbsp;&nbsp; We note that [RFC2865]=
 Section 3 defines a number of RADIUS Codes,<BR>&nbsp;&nbsp; but does not m=
ake statements about which Codes are valid for port<BR>| &nbsp;1812. &nbsp;=
In contrast, [RFC2866] Section 3 specifies that only RADIUS<BR>| &nbsp;Acco=
unting packets are to be sent to port 1813. &nbsp;This specification<BR>&nb=
sp;&nbsp; is compatible with [RFC2865], as it uses a known Code for packets=
 to<BR>&nbsp;&nbsp; port 1812. &nbsp;This specification is not compatible w=
ith [RFC2866], as<BR>&nbsp;&nbsp; it adds a new code (Status-Server) that i=
s valid for port 1812.<BR>| &nbsp;However, as the category of [RFC2866] is =
Informational, this conflict<BR>| &nbsp;is acceptable.<BR><BR>This statemen=
t clearly indicates that this specification<BR>*** Updates RFC 2866 ***.<BR=
><BR>This relationship really should be noted in the front matter of the<BR=
>draft.<BR><BR>(8b) &nbsp;7th para -- word omission<BR><BR>Please correct:<=
BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v=
<BR>| &nbsp;The server MAY prioritize the handling Status-Server queries ov=
er the<BR>&nbsp;&nbsp; handling of other requests, subject to the rate limi=
ting described<BR>&nbsp;&nbsp; above.<BR>--- &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp;vvvv<BR>| &nbsp;The server MAY prioritize the ha=
ndling of Status-Server queries over<BR>&nbsp;&nbsp; the handling of other =
requests, subject to the rate limiting<BR>&nbsp;&nbsp; described above.<BR>=
<BR><BR>(9) &nbsp;Section 4.3<BR><BR>(9a) &nbsp;1st para -- improvement #1<=
BR><BR>I suggest to improver the wording:<BR><BR>&nbsp;&nbsp; When a Dynami=
c Authorization Client ([RFC5176] Section 1.3) reboots,<BR>| &nbsp;it SHOUL=
D send a Status-Server packet to a CoA port to IP addresses<BR>&nbsp;&nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; !! &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp;!!<BR>&nbsp;&nbsp; that are configured as both =
Dynamic Authorization Servers and RADIUS<BR>&nbsp;&nbsp; clients. &nbsp;[..=
.]<BR>---<BR>&nbsp;&nbsp; When a Dynamic Authorization Client ([RFC5176] Se=
ction 1.3) reboots,<BR>| &nbsp;it SHOULD send a Status-Server packet to a C=
oA port at IP addresses<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^^<=
BR>&nbsp;&nbsp; that are configured as both Dynamic Authorization Servers a=
nd RADIUS<BR>&nbsp;&nbsp; clients. &nbsp;[...]<BR><BR>(9b) &nbsp;1st para -=
- improvement #2 (missing word)<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp;[...] &nbsp;When a response is received, the Dynam=
ic<BR>&nbsp;&nbsp; Authorization Client MUST NOT send further Status-Server=
 packets to<BR>| &nbsp;the CoA port of any Dynamic Authorization until it n=
ext reboots.<BR>--- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; ^<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;[...] &nbsp;When a response is received, the Dynamic<BR>&nbsp;&nbsp; Autho=
rization Client MUST NOT send further Status-Server packets to<BR>| &nbsp;t=
he CoA port of any Dynamic Authorization Server until it next<BR>&nbsp;&nbs=
p; reboots.<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp;^^^^^^^^<BR>(9c) &nbsp;4th para -- inconsistency wi=
th 1st para<BR><BR>The final part of the 4th para apparently contradicts th=
e last<BR>sentence of the first para (quoted in (9b) above):<BR><BR>| &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp;[...]. &nbsp;The NAS MAY<BR>| &nbsp;otherwise decide to receive multip=
le packets to it's CoA port before<BR>| &nbsp;marking the RADIUS server as =
responsive. &nbsp;This behavior is<BR>| &nbsp;implementation-defined, and S=
HOULD be configurable.<BR><BR>(9d) &nbsp;last para -- punctuation<BR><BR>Th=
e last comma (after "port 3799") IMO distorts the sentence<BR>and should be=
tter be deleted.<BR><BR><BR>(10) &nbsp;Section 4.4, 2nd para -- improvement=
<BR><BR>I suggest to slightly change the wording:<BR><BR>&nbsp;&nbsp; &nbsp=
; &nbsp; &nbsp;[...]. &nbsp;If the server is still unresponsive, however, t=
he result<BR>&nbsp;&nbsp; may be user login failures. &nbsp;The Status-Serv=
er solution is an ideal<BR>| &nbsp;one to solve this problem.<BR>---^^^<BR>=
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;[...]. &nbsp;If the server is still unresp=
onsive, however, the result<BR>&nbsp;&nbsp; may be user login failures. &nb=
sp;The Status-Server solution is an ideal<BR>| &nbsp;way to solve this prob=
lem.<BR>&nbsp;&nbsp; ^^^<BR><BR><BR>(11) &nbsp;Section 4.6<BR><BR>(11a) &nb=
sp;4th para below first figure -- improvement/grammar<BR><BR>I suggest to c=
hange:<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [...]. &nbsp;If the =
implementation fails to respond, then the NAS<BR>&nbsp;&nbsp; cannot distin=
guish between the Proxy Server being down, or the next<BR>| &nbsp;server al=
ong along the proxy chain is unreachable.<BR>-- &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp;^^<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [...]=
. &nbsp;If the implementation fails to respond, then the NAS<BR>&nbsp;&nbsp=
; cannot distinguish between the Proxy Server being down, or the next<BR>| =
&nbsp;server along along the proxy chain being unreachable.<BR>&nbsp;&nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^^^^^<BR><BR>(11b) &nbsp=
;5th para below first figure -- missing word<BR><BR>I suggest to insert "in=
" as follows:<BR><BR>&nbsp;&nbsp; In the worst case, failures in routing fo=
r Realm A may affect users<BR>| &nbsp;Realm B. &nbsp;[...]<BR>---^<BR>&nbsp=
;&nbsp; In the worst case, failures in routing for Realm A may affect users=
<BR>| &nbsp;in Realm B. &nbsp;[...]<BR>&nbsp;&nbsp; ^^^^<BR><BR>(11c) &nbsp=
;denomination of entities<BR><BR>&gt;From the second figure ...<BR><BR>&nbs=
p;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/-&gt; Proxy Serve=
r P -----&gt; Home Server P<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; / &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp;\ /<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;NAS &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;X<BR>&nbs=
p;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; \ &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/ \<BR>&nbsp;&nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;\-&gt; Proxy Server S -----&gt; Hom=
e Server S<BR><BR>... it becomes apparent that the denominations of the ent=
ities are<BR>not chosen carefully; in this case, 'P' and 'S' are both overl=
oaded.<BR><BR>To disambiguate the whole stuff, here's my proposal:<BR><BR>U=
se 'P1' and 'P2' (in place of 'P' and 'S') for the two Proxy Servers<BR>in =
both scenarios (figures and text); use 'H1' and 'H2' &nbsp;for the Home<BR>=
Servers in the second scenario.<BR><BR><BR>(12) &nbsp;Section 4.7 -- termin=
ology<BR><BR>The draft uses the colloquial, but incorrect short term "MIB" =
whenever<BR>in wants to indicate a "MIB Module". &nbsp;Please see the BCP 1=
11, RFC 4181<BR>for the detailed rationale of the precise terminology.<BR><=
BR>Therefore, &nbsp;please change &nbsp; &nbsp; MIB[s] &nbsp; --&gt; &nbsp;=
 MIB module[s]<BR>throughout the text.<BR><BR>(13) &nbsp;Section 4.7.1<BR><=
BR>(13a) &nbsp;need to update the metadata (front matter)<BR><BR>The 1st pa=
ra clearly indicates that this draft<BR>*** &nbsp;Updates RFC 4669 and RFC =
4671 &nbsp;***<BR><BR>To make it easier for developers and users to find th=
is update,<BR>please amend the draft front matter accordingly.<BR><BR>(13b)=
 &nbsp;last para<BR><BR>The draft text is confusingly complicated, yet inpr=
ecise.<BR>The draft text could be misunderstood as recommending to<BR>defin=
e alternate MIB modules where it better should recommend<BR>&nbsp;using ext=
ensions for standard MIB tables.<BR><BR>I suggest to modify this paragraph =
as follows:<BR><BR>&nbsp;&nbsp; If a server supports Status-Server and the =
[RFC4669] or [RFC4671]<BR>| &nbsp;MIBs, then it SHOULD also support vendor-=
specific MIBs containing<BR>| &nbsp;similar information as the standard MIB=
s, but which are instead<BR>&nbsp;&nbsp; dedicated solely to tracking Statu=
s-Server requests and responses.<BR>| &nbsp;Any definition of the server MI=
Bs for Status-Server is outside of the<BR>&nbsp;&nbsp; scope of this docume=
nt.<BR>---<BR>| &nbsp;If a server supports Status-Server and the [RFC4669] =
or [RFC4671] MIB<BR>| &nbsp;modules, then it SHOULD also support vendor-spe=
cific MIB extensions<BR>&nbsp;&nbsp; ^^^^^^^ &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^^^^^^^^^^^^^^^^<BR>=
&nbsp;&nbsp; dedicated solely to tracking Status-Server requests and respon=
ses.<BR>| &nbsp;Any definition of the server MIB module extensions for Stat=
us-Server<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^^^^^^^^^^^^^^^^^^^^=
^<BR>&nbsp;&nbsp; is outside of the scope of this document.<BR><BR>(Please =
note the deletion of the full 3rd line!)<BR><BR><BR>(14) &nbsp; Section 4.7=
.2<BR><BR>(14a)<BR>Similar as noted in (13a) above, the first para of 4.7.2=
 clearly<BR>indicates that this specification &nbsp;*** updates RFCs 4668 a=
nd 4670 ***.<BR><BR>(14b)<BR>Similarly as in (13b) above, the last para of =
4.7.2 should be modified<BR>as follows:<BR><BR>&nbsp;&nbsp; If an implement=
ation supports Status-Server and the [RFC4668] or<BR>| &nbsp;[RFC4670] MIBs=
, then it SHOULD also support vendor-specific MIBs<BR>| &nbsp;containing si=
milar information as those MIBs, but which are instead<BR>&nbsp;&nbsp; dedi=
cated solely to tracking Status-Server requests and responses.<BR>| &nbsp;A=
ny definition of the client MIBs for Status-Server is outside of the<BR>&nb=
sp;&nbsp; scope of this document.<BR>---<BR>&nbsp;&nbsp; If an implementati=
on supports Status-Server and the [RFC4668] or<BR>| &nbsp;[RFC4670] MIB mod=
ules, then it SHOULD also support vendor-specific<BR>&nbsp;&nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; ^^^^^^^^^^^<BR>| &nbsp;MIB extensions dedicated s=
olely to tracking Status-Server requests<BR>&nbsp;&nbsp; ^^^^^^^^^^^^^^^<BR=
>| &nbsp;and responses. &nbsp;Any definition of the client MIB module exten=
sions<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp;^^^^^^^^^^^^^^^^^^^^^<BR>&nbsp;&nbsp; for S=
tatus-Server is outside of the scope of this document.<BR><BR><BR>(15) &nbs=
p;Section 5.1<BR><BR>(15a) &nbsp;2nd para, last sentence -- typo/grammar<BR=
><BR>Please &nbsp; s/server/servers/ &nbsp;in ...<BR><BR>&nbsp;&nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [...]. &nbsp;Thes=
e queries are most useful in<BR>| &nbsp;deployments where an administrator =
has internal RADIUS servers that<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^<BR>&nbsp;&nbsp; proxy to other in=
ternal RADIUS servers, such as for load balancing or<BR>&nbsp;&nbsp; fail o=
ver.<BR><BR>(15b) &nbsp;3rd para -- improvement<BR><BR>To improve the reada=
bility, I suggest varying the multiple uses of<BR>"use", e.g.:<BR>&nbsp;&nb=
sp; &nbsp; &nbsp;vvvv &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;vvvv &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;vvvvv<BR>&nbsp;&nbsp; If us=
ed, the names used for these test users SHOULD be difficult to<BR>&nbsp;&nb=
sp; guess by an attacker. &nbsp;[...]<BR>--- &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; vvvvvvvv<BR>&nbsp;&nbsp; If used, the name=
s utilized for these test users SHOULD be difficult<BR>&nbsp;&nbsp; to gues=
s by an attacker. &nbsp;[...]<BR><BR><BR>(16) &nbsp;Section 5.2 &nbsp;-- ou=
tdated text<BR><BR>The first paragraph seems to be outdated now by the RADI=
US-over-TCP<BR>draft!<BR><BR><BR>(17) &nbsp;Section 5.3, 1st para<BR><BR>Th=
e draft says:<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;[...]. &nbsp;It may be<BR>&n=
bsp;&nbsp; tempting to increase the utility of Status-Server by having the<=
BR>| &nbsp;responses carry additional information, implementors are warned =
that<BR>&nbsp;&nbsp; such uses have not been analyzed for potential securit=
y issues or<BR>&nbsp;&nbsp; network problems.<BR><BR>To better reflect the =
relationship between the two (half-)sentences<BR>connected with a comma, I =
propose to either use a semicolon instead<BR>of the comma, or insert &nbsp;=
" but" after the comma:<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;[...]. &nbsp;I=
t may be<BR>&nbsp;&nbsp; tempting to increase the utility of Status-Server =
by having the<BR>| &nbsp;responses carry additional information, but implem=
entors are warned<BR>&nbsp;&nbsp; that such uses have not been analyzed for=
 potential security issues<BR>&nbsp;&nbsp; or network problems.<BR><BR><BR>=
Best regards,<BR>&nbsp;&nbsp;Alfred H=EF=BF=BDnes.<BR><BR>--<BR><BR>+------=
------------------+--------------------------------------------+<BR>| TR-Sy=
s Alfred Hoenes &nbsp; | &nbsp;Alfred Hoenes &nbsp; Dipl.-Math., Dipl.-Phys=
. &nbsp;|<BR>| Gerlinger Strasse 12 &nbsp; | &nbsp;Phone: (+49)7156/9635-0,=
 Fax: -18 &nbsp; &nbsp; &nbsp; &nbsp; |<BR>| D-71254 &nbsp;Ditzingen &nbsp;=
 &nbsp; | &nbsp;E-Mail: &nbsp;[email-masked] &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<BR>+------------------------+------=
--------------------------------------+<BR></P></div></body></html>
------=_Part_166748_896156211.1229366932742--

--
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, 15 Dec 2008 18:47:37 +0000
Date: Mon, 15 Dec 2008 18:47:19 +0000 (UTC)
From: [email-masked]
To: [email-masked]
Subject: Fwd: draft-zorn-radius-err-msg-10 (fwd)

------=_Part_166733_366877312.1229366839550
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Forwarding for a non-list member:=20

>From [email-masked] Thu Dec 11 19:01:22 MEZ 2008=20
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16=
.3)=20
=C2=A0=C2=A0 =C2=A0 =C2=A0id AA023378481; Thu, 11 Dec 2008 19:01:21 +0100=
=20
Return-Path: <[email-masked]>=20
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)=20
=C2=A0=C2=A0 =C2=A0 =C2=A0id TAA22555; Thu, 11 Dec 2008 19:01:20 +0100 (MEZ=
)=20
From: Alfred H=EF=BF=BDnes <[email-masked]>=20
To: [email-masked]=20
Message-Id: <[email-masked]>=20
Date: Thu, 11 Dec 2008 19:01:20 +0100 (MEZ)=20
Subject: draft-zorn-radius-err-msg-10=20

Hello again,=20
I also have reviewed your Internet-Draft draft-zorn-radius-err-msg-10=20
and would like to submit a few comments.=20

I have a couple of concerns regarding the structure of the document.=20

First of all, it looks like Section 3 was intended as a summary=20
of related pre-existing specifications for RADIUS.=20
Thus, it comes to surprise that this section contains two inserts=20
giving details for the new protocol elements that will be introduced=20
later in the memo, in Sections 4 ff.=20
To avoid confusion, I suggest to move these parts to the proper=20
places later in the document; this will save text and improve=20
the clarity of the document.=20
Very few generally applicable text should be moved in the opposite=20
direction, as well.=20
I'll give the details in the document walk-through below.=20

Subsequently, Sections 4..6 are structured for extensibility,=20
which obviously is not needed in this document.=20
The headlines always let the reader expect to come more, where=20
there's always only a single new protocol object ro define.=20
I strongly suggest to update the headlines and amalgamate these=20
sections with their single subsection each.=20

(1) =C2=A0Section 3=20

The draft text starts with:=20

=C2=A03. =C2=A0RADIUS Packet Format=20

=C2=A0=C2=A0 Exactly one RADIUS packet is encapsulated in the UDP Data fiel=
d=20
=C2=A0=C2=A0 [RFC0768] where the UDP Destination Port field indicates 1812=
=20
=C2=A0=C2=A0 (decimal).=20

=C2=A0=C2=A0 When a reply is generated, the source and destination ports ar=
e=20
=C2=A0=C2=A0 reversed.=20

The topic of these two paragraphs, transport of radius messages,=20
is not directly related to the "Packet Format" announced by the=20
section headline.=20
I suggest to move these two paragraphs to the end of the section,=20
at best in a new subsection,=20

=C2=A03.1. =C2=A0RADIUS Transport=20

There, it should at least be mentioned that TCP (and TLS-secured)=20
transport of RADIUS packets is currently pursued in the RADEXT WG=20
as well (for instance, see draft-ietf-radext-tcp-transport).=20

I propose to move the short text currently in Section 4 next here=20
in Section 3, in front of the diagram, and add a more fundamental=20
explanation. In the 'Administrative Note' at the end of the section,=20
the term "RADIUS proxy" is used as well, without priop explanation.=20
Therefore, I recommend to also introduce this concept here.=20

For instance:=20

| =C2=A0RADIUS is a request-reply protocol, where each request packet sent=
=20
| =C2=A0from a "RADIUS Client" to a "RADIUS Server" is responded to with a=
=20
| =C2=A0reply packet. =C2=A0A "RADIUS proxy" relays, as an intermediate age=
nt,=20
| =C2=A0requests and reponses between an original RADIUS client and the fin=
al=20
| =C2=A0RADIUS server, behaving as a server for the forme and as a client f=
or=20
| =C2=A0the latter. =C2=A0The RADIUS Packet type is determined by the Code =
field=20
| =C2=A0in the first octet of the Packet.=20
|=20
| =C2=A0A summary of the RADIUS packet format is shown below. =C2=A0The fie=
lds are=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 ^^^^^^=20
=C2=A0=C2=A0 transmitted from left to right.=20

Having that statement in front of the diagram, the sentence immediately=20
below the diagram,=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 The Code field is one octet, and identifi=
es the type of RADIUS=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 packet.=20

... could be simplified to only say:=20

| =C2=A0 =C2=A0 =C2=A0 =C2=A0The Code field is one octet, and identifies th=
e packet type.=20

... or even:=20

| =C2=A0 =C2=A0 =C2=A0 =C2=A0The Code field is one octet.=20

The second part of the explanation for 'Code' is not of general nature.=20
IMHO, it should be removed from this section, and elaborated upon in=20
Section 4:=20

DELETE:=20

| =C2=A0 =C2=A0 =C2=A0 =C2=A0The RADIUS Codes (decimal) defined in this doc=
ument are as=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0follows:=20
|=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <MSG1> Error-Notification=20

Again, in the explanation of 'Authenticator', the second part with=20
the headline 'Notification Authenticator' comes to surprise here.=20
I suggest to move it entirely into Section 4:=20

DELETE:=20

| =C2=A0 =C2=A0 =C2=A0 =C2=A0Notification Authenticator=20
|=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The value of the Authenticator field i=
n the Error-=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Notification packet is called the Noti=
fication=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authenticator, and contains a one-way =
MD5 hash calculated=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 over a stream of octets consisting of:=
 the RADIUS packet,=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 beginning with the Code field, includi=
ng the Identifier, the=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Length, the Authenticator field from t=
he packet to which=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this packet is a response, and the res=
ponse Attributes,=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 followed by the shared secret. =C2=A0T=
hat is,=20
|=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Notification Auth =3D=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MD5=
(Code+ID+Length+RequestAuth+Attributes+Secret)=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 where '+' denotes concatenation.=20

In the 3rd paragraph of the 'Administrative Note', I suggest to add a=20
few clarifying words in order to disambiguate the scenario described:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 When using a forwarding proxy, the proxy =
must be able to alter=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 the packet as it passes through in each d=
irection - when the=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 proxy forwards the request, the proxy MAY=
 add a Proxy-State=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 Attribute, and when the proxy forwards a =
response, it MUST=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0remove its Proxy-State Attribute if it added o=
ne. =C2=A0[...]=20
---=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 When using a forwarding proxy, the proxy =
must be able to alter=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 the packet as it passes through in each d=
irection - when the=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 proxy forwards the request, the proxy MAY=
 add a Proxy-State=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 Attribute, and when the proxy forwards a =
response, it MUST=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0remove its Proxy-State Attribute if it added o=
ne to the=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 vvvvvvv =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0request. =C2=A0[...]=20

(2) =C2=A0Section 4=20

As noted above, I propose to simplify and clarify the structure=20
of this section:=20

|4. =C2=A0Packet Types=20
|=20
| =C2=A0The RADIUS Packet type is determined by the Code field in the first=
=20
| =C2=A0octet of the Packet.=20
|=20
|4.1. =C2=A0Error-Notification=20

The prose already has been moved inTo section 3, so the replacement=20
is simply:=20

|4. =C2=A0New Packet Type: Error-Notification=20

The explanation for 'Notification Authenticator' currently says:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0Notification Authenticator=20

| =C2=A0 =C2=A0 =C2=A0 =C2=A0The Notification Authenticator value is calcul=
ated from the=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0Error-Notification packet, as described above.=
=20

This sentence IMO does not match reasonably what was currently=20
described in Section 3.=20
As mentioned above, I strongly recommend to move that text (DELETED=20
above) to this location; doing so allows to drop the above two-liner=20
entirely:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0Notification Authenticator=20

| =C2=A0 =C2=A0 =C2=A0 =C2=A0The value of the Authenticator field in the Er=
ror-Notification=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0packet is called the Notification Authenticato=
r, and contains a=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0one-way MD5 hash calculated over a stream of o=
ctets consisting=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0of: the RADIUS packet, beginning with the Code=
 field, including=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0the Identifier, the Length, the Authenticator =
field from the=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0packet to which this packet is a response, and=
 the response=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0Attributes, followed by the shared secret. =C2=
=A0That is,=20
|=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Notification Auth =3D=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MD5(Code+I=
D+Length+RequestAuth+Attributes+Secret)=20
|=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0where '+' denotes concatenation.=20

As I understand that (unchanged) text, with the single exception of the=20
original Authenticator field from the errored packet, all these fields=20
are the fields of the Error-Notification packet; that was not clear=20
from the two-liner above!=20

Another concern: =C2=A0This new 'signature' again is stuck with the old-=20
fashioned Keyed-MD5 construction; obviously, doing so violates the=20
directive from the IESG and the IAB to equip all IETF protocols with=20
capabilities for crypto-algorithm agility.=20

(3) =C2=A0Section 5=20

Again, as indicated above, I strongly recommend to simplify the=20
section structure:=20

|5. =C2=A0Attributes=20
|=20
|5.1. =C2=A0Error-Code=20
---=20
|5. =C2=A0New Attribute: Error-Code=20

(4) =C2=A0Section 6=20

Currently the text in Section 4 says:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 vv =C2=A0 =C2=A0 =C2=A0vv=20
| =C2=A0The following sub-sections defines a new value for the Acct-Status-=
=20
=C2=A0=C2=A0 Type Attribute [RFC2866].=20

That's bogus grammar anyway. =C2=A0However, following the spirit of the=20
above proposals for simplification, I suggest to change that entirely:=20

|6. =C2=A0Attribute Values=20
|=20
| =C2=A0The following sub-sections defines a new value for the Acct-Status-=
=20
| =C2=A0Type Attribute [RFC2866].=20
|=20
|6.1. =C2=A0Acct-Error-Notification=20
---=20
|6. =C2=A0New Attribute Value: Acct-Error-Notification=20

=C2=A0=C2=A0 This section defines a new value for the Acct-Status-Type Attr=
ibute=20
=C2=A0=C2=A0 [RFC2866], 'Acct-Error-Notification' (<VAL>).=20

(5) =C2=A0Section 7=20

Since this document does not define any new (sub-)namespaces to be=20
managed by IANA, the present text seems to be misleading.=20
Instead, the three specific assignments should be detailed there;=20
for instance, following this pattern (cf BCP 26, RFC 5226):=20

| =C2=A0The criteria to be used by the Internet Assigned Numbers Authority=
=20
| =C2=A0(IANA) for assignment of numbers within namespaces defined within=
=20
| =C2=A0this document are identical to those given in [RFC3575].=20
---=20
| =C2=A0IANA is requested to assign three code points within the RADIUS=20
| =C2=A0Parameters registry defined in [RFC3575], currently located at=20
| =C2=A0<http://www.iana.org/assignments/...> :=20
|=20
| =C2=A0o =C2=A0One RADIUS Packet Type=20
|=20
| =C2=A0 =C2=A0 Type =C2=A0 =C2=A0 Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reference=20
| =C2=A0 =C2=A0 ------------------------------------------=20
| =C2=A0 =C2=A0 <MSG1> =C2=A0 Error-Notification =C2=A0 =C2=A0 =C2=A0[RFCth=
is]=20
|=20
| =C2=A0o =C2=A0...=20
|=20
|=20
| =C2=A0o =C2=A0...=20

(6) =C2=A0Section 8=20

|8. =C2=A0Security Considerations=20
|=20
| =C2=A0None.=20

I bet the IESG will not be a friend of such brevity ...=20

Kind regards,=20
=C2=A0=C2=A0Alfred H=EF=BF=BDnes.=20

--=20

+------------------------+--------------------------------------------+=20
| TR-Sys Alfred Hoenes =C2=A0 | =C2=A0Alfred Hoenes =C2=A0 Dipl.-Math., Dip=
l.-Phys. =C2=A0|=20
| Gerlinger Strasse 12 =C2=A0 | =C2=A0Phone: (+49)7156/9635-0, Fax: -18 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |=20
| D-71254 =C2=A0Ditzingen =C2=A0 =C2=A0 | =C2=A0E-Mail: =C2=[email-masked] =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=20
+------------------------+--------------------------------------------+=20

------=_Part_166733_366877312.1229366839550
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Arial; font-size: 12pt; color: #000000'><P>Forwar=
ding for a non-list member:</P>
<P><BR>From [email-masked] Thu Dec 11 19:01:22 MEZ 2008<BR>Received: fr=
om ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3)<BR>&nbsp=
;&nbsp; &nbsp; &nbsp;id AA023378481; Thu, 11 Dec 2008 19:01:21 +0100<BR>Ret=
urn-Path: &lt;[email-masked]&gt;<BR>Received: (from ah@localhost) by z.=
TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)<BR>&nbsp;&nbsp; &nbsp; &nbsp;id TAA225=
55; Thu, 11 Dec 2008 19:01:20 +0100 (MEZ)<BR>From: Alfred H=EF=BF=BDnes &lt=
;[email-masked]&gt;<BR>To: [email-masked]<BR>Message-Id: &lt;200812111801.TA=
[email-masked]&gt;<BR>Date: Thu, 11 Dec 2008 19:01:20 +0100 (MEZ)<BR>Subj=
ect: draft-zorn-radius-err-msg-10<BR><BR>Hello again,<BR>I also have review=
ed your Internet-Draft draft-zorn-radius-err-msg-10<BR>and would like to su=
bmit a few comments.<BR><BR>I have a couple of concerns regarding the struc=
ture of the document.<BR><BR>First of all, it looks like Section 3 was inte=
nded as a summary<BR>of related pre-existing specifications for RADIUS.<BR>=
Thus, it comes to surprise that this section contains two inserts<BR>giving=
 details for the new protocol elements that will be introduced<BR>later in =
the memo, in Sections 4 ff.<BR>To avoid confusion, I suggest to move these =
parts to the proper<BR>places later in the document; this will save text an=
d improve<BR>the clarity of the document.<BR>Very few generally applicable =
text should be moved in the opposite<BR>direction, as well.<BR>I'll give th=
e details in the document walk-through below.<BR><BR>Subsequently, Sections=
 4..6 are structured for extensibility,<BR>which obviously is not needed in=
 this document.<BR>The headlines always let the reader expect to come more,=
 where<BR>there's always only a single new protocol object ro define.<BR>I =
strongly suggest to update the headlines and amalgamate these<BR>sections w=
ith their single subsection each.<BR><BR><BR>(1) &nbsp;Section 3<BR><BR>The=
 draft text starts with:<BR><BR>&nbsp;3. &nbsp;RADIUS Packet Format<BR><BR>=
&nbsp;&nbsp; Exactly one RADIUS packet is encapsulated in the UDP Data fiel=
d<BR>&nbsp;&nbsp; [RFC0768] where the UDP Destination Port field indicates =
1812<BR>&nbsp;&nbsp; (decimal).<BR><BR>&nbsp;&nbsp; When a reply is generat=
ed, the source and destination ports are<BR>&nbsp;&nbsp; reversed.<BR><BR>T=
he topic of these two paragraphs, transport of radius messages,<BR>is not d=
irectly related to the "Packet Format" announced by the<BR>section headline=
.<BR>I suggest to move these two paragraphs to the end of the section,<BR>a=
t best in a new subsection,<BR><BR>&nbsp;3.1. &nbsp;RADIUS Transport<BR><BR=
>There, it should at least be mentioned that TCP (and TLS-secured)<BR>trans=
port of RADIUS packets is currently pursued in the RADEXT WG<BR>as well (fo=
r instance, see draft-ietf-radext-tcp-transport).<BR><BR>I propose to move =
the short text currently in Section 4 next here<BR>in Section 3, in front o=
f the diagram, and add a more fundamental<BR>explanation. In the 'Administr=
ative Note' at the end of the section,<BR>the term "RADIUS proxy" is used a=
s well, without priop explanation.<BR>Therefore, I recommend to also introd=
uce this concept here.<BR><BR>For instance:<BR><BR>| &nbsp;RADIUS is a requ=
est-reply protocol, where each request packet sent<BR>| &nbsp;from a "RADIU=
S Client" to a "RADIUS Server" is responded to with a<BR>| &nbsp;reply pack=
et. &nbsp;A "RADIUS proxy" relays, as an intermediate agent,<BR>| &nbsp;req=
uests and reponses between an original RADIUS client and the final<BR>| &nb=
sp;RADIUS server, behaving as a server for the forme and as a client for<BR=
>| &nbsp;the latter. &nbsp;The RADIUS Packet type is determined by the Code=
 field<BR>| &nbsp;in the first octet of the Packet.<BR>|<BR>| &nbsp;A summa=
ry of the RADIUS packet format is shown below. &nbsp;The fields are<BR>&nbs=
p;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; ^^^^^^<BR>&nbsp;&nbsp; transmitted from left to right.<BR=
><BR>Having that statement in front of the diagram, the sentence immediatel=
y<BR>below the diagram,<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; The Code f=
ield is one octet, and identifies the type of RADIUS<BR>&nbsp;&nbsp; &nbsp;=
 &nbsp; &nbsp; packet.<BR><BR>... could be simplified to only say:<BR><BR>|=
 &nbsp; &nbsp; &nbsp; &nbsp;The Code field is one octet, and identifies the=
 packet type.<BR><BR>... or even:<BR><BR>| &nbsp; &nbsp; &nbsp; &nbsp;The C=
ode field is one octet.<BR><BR><BR>The second part of the explanation for '=
Code' is not of general nature.<BR>IMHO, it should be removed from this sec=
tion, and elaborated upon in<BR>Section 4:<BR><BR>DELETE:<BR><BR>| &nbsp; &=
nbsp; &nbsp; &nbsp;The RADIUS Codes (decimal) defined in this document are =
as<BR>| &nbsp; &nbsp; &nbsp; &nbsp;follows:<BR>|<BR>| &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &lt;MSG1&gt; Error-Notification<BR><BR>Again, in the explanat=
ion of 'Authenticator', the second part with<BR>the headline 'Notification =
Authenticator' comes to surprise here.<BR>I suggest to move it entirely int=
o Section 4:<BR><BR>DELETE:<BR><BR>| &nbsp; &nbsp; &nbsp; &nbsp;Notificatio=
n Authenticator<BR>|<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; The value of t=
he Authenticator field in the Error-<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; Notification packet is called the Notification<BR>| &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; Authenticator, and contains a one-way MD5 hash calculated<BR>=
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; over a stream of octets consisting of:=
 the RADIUS packet,<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; beginning with =
the Code field, including the Identifier, the<BR>| &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; Length, the Authenticator field from the packet to which<BR>| &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; this packet is a response, and the respons=
e Attributes,<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; followed by the share=
d secret. &nbsp;That is,<BR>|<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Notif=
ication Auth =3D<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; MD5(Code+ID+Length+RequestAuth+Attributes+Secret)<BR>| &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; where '+' denotes concatenation.<BR><BR>In =
the 3rd paragraph of the 'Administrative Note', I suggest to add a<BR>few c=
larifying words in order to disambiguate the scenario described:<BR><BR>&nb=
sp;&nbsp; &nbsp; &nbsp; &nbsp; When using a forwarding proxy, the proxy mus=
t be able to alter<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; the packet as it pa=
sses through in each direction - when the<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nb=
sp; proxy forwards the request, the proxy MAY add a Proxy-State<BR>&nbsp;&n=
bsp; &nbsp; &nbsp; &nbsp; Attribute, and when the proxy forwards a response=
, it MUST<BR>| &nbsp; &nbsp; &nbsp; &nbsp;remove its Proxy-State Attribute =
if it added one. &nbsp;[...]<BR>---<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; Wh=
en using a forwarding proxy, the proxy must be able to alter<BR>&nbsp;&nbsp=
; &nbsp; &nbsp; &nbsp; the packet as it passes through in each direction - =
when the<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; proxy forwards the request, t=
he proxy MAY add a Proxy-State<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; Attribu=
te, and when the proxy forwards a response, it MUST<BR>| &nbsp; &nbsp; &nbs=
p; &nbsp;remove its Proxy-State Attribute if it added one to the<BR>&nbsp;&=
nbsp; &nbsp; &nbsp; &nbsp; vvvvvvv &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; ^^^^^^^<BR>| &nbsp; &nbsp; &nbsp; &nbsp;request. &=
nbsp;[...]<BR><BR><BR>(2) &nbsp;Section 4<BR><BR>As noted above, I propose =
to simplify and clarify the structure<BR>of this section:<BR><BR>|4. &nbsp;=
Packet Types<BR>|<BR>| &nbsp;The RADIUS Packet type is determined by the Co=
de field in the first<BR>| &nbsp;octet of the Packet.<BR>|<BR>|4.1. &nbsp;E=
rror-Notification<BR><BR>The prose already has been moved inTo section 3, s=
o the replacement<BR>is simply:<BR><BR>|4. &nbsp;New Packet Type: Error-Not=
ification<BR><BR>The explanation for 'Notification Authenticator' currently=
 says:<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp;Notification Authenticator<BR><BR>|=
 &nbsp; &nbsp; &nbsp; &nbsp;The Notification Authenticator value is calcula=
ted from the<BR>| &nbsp; &nbsp; &nbsp; &nbsp;Error-Notification packet, as =
described above.<BR><BR>This sentence IMO does not match reasonably what wa=
s currently<BR>described in Section 3.<BR>As mentioned above, I strongly re=
commend to move that text (DELETED<BR>above) to this location; doing so all=
ows to drop the above two-liner<BR>entirely:<BR><BR>&nbsp;&nbsp; &nbsp; &nb=
sp;Notification Authenticator<BR><BR>| &nbsp; &nbsp; &nbsp; &nbsp;The value=
 of the Authenticator field in the Error-Notification<BR>| &nbsp; &nbsp; &n=
bsp; &nbsp;packet is called the Notification Authenticator, and contains a<=
BR>| &nbsp; &nbsp; &nbsp; &nbsp;one-way MD5 hash calculated over a stream o=
f octets consisting<BR>| &nbsp; &nbsp; &nbsp; &nbsp;of: the RADIUS packet, =
beginning with the Code field, including<BR>| &nbsp; &nbsp; &nbsp; &nbsp;th=
e Identifier, the Length, the Authenticator field from the<BR>| &nbsp; &nbs=
p; &nbsp; &nbsp;packet to which this packet is a response, and the response=
<BR>| &nbsp; &nbsp; &nbsp; &nbsp;Attributes, followed by the shared secret.=
 &nbsp;That is,<BR>|<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Notification A=
uth =3D<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 MD5(Code+ID+Length+RequestAuth+Attributes+Secret)<BR>|<BR>| &nbsp; &nbsp; =
&nbsp; &nbsp;where '+' denotes concatenation.<BR><BR>As I understand that (=
unchanged) text, with the single exception of the<BR>original Authenticator=
 field from the errored packet, all these fields<BR>are the fields of the E=
rror-Notification packet; that was not clear<BR>from the two-liner above!<B=
R><BR>Another concern: &nbsp;This new 'signature' again is stuck with the o=
ld-<BR>fashioned Keyed-MD5 construction; obviously, doing so violates the<B=
R>directive from the IESG and the IAB to equip all IETF protocols with<BR>c=
apabilities for crypto-algorithm agility.<BR><BR><BR>(3) &nbsp;Section 5<BR=
><BR>Again, as indicated above, I strongly recommend to simplify the<BR>sec=
tion structure:<BR><BR>|5. &nbsp;Attributes<BR>|<BR>|5.1. &nbsp;Error-Code<=
BR>---<BR>|5. &nbsp;New Attribute: Error-Code<BR><BR><BR>(4) &nbsp;Section =
6<BR><BR>Currently the text in Section 4 says:<BR><BR>&nbsp;&nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 vv &nbsp; &nbsp; &nbsp;vv<BR>| &nbsp;The following sub-sections defines a =
new value for the Acct-Status-<BR>&nbsp;&nbsp; Type Attribute [RFC2866].<BR=
><BR>That's bogus grammar anyway. &nbsp;However, following the spirit of th=
e<BR>above proposals for simplification, I suggest to change that entirely:=
<BR><BR>|6. &nbsp;Attribute Values<BR>|<BR>| &nbsp;The following sub-sectio=
ns defines a new value for the Acct-Status-<BR>| &nbsp;Type Attribute [RFC2=
866].<BR>|<BR>|6.1. &nbsp;Acct-Error-Notification<BR>---<BR>|6. &nbsp;New A=
ttribute Value: Acct-Error-Notification<BR><BR>&nbsp;&nbsp; This section de=
fines a new value for the Acct-Status-Type Attribute<BR>&nbsp;&nbsp; [RFC28=
66], 'Acct-Error-Notification' (&lt;VAL&gt;).<BR><BR><BR>(5) &nbsp;Section =
7<BR><BR>Since this document does not define any new (sub-)namespaces to be=
<BR>managed by IANA, the present text seems to be misleading.<BR>Instead, t=
he three specific assignments should be detailed there;<BR>for instance, fo=
llowing this pattern (cf BCP 26, RFC 5226):<BR><BR>| &nbsp;The criteria to =
be used by the Internet Assigned Numbers Authority<BR>| &nbsp;(IANA) for as=
signment of numbers within namespaces defined within<BR>| &nbsp;this docume=
nt are identical to those given in [RFC3575].<BR>---<BR>| &nbsp;IANA is req=
uested to assign three code points within the RADIUS<BR>| &nbsp;Parameters =
registry defined in [RFC3575], currently located at<BR>| &nbsp;&lt;http://w=
ww.iana.org/assignments/...&gt; :<BR>|<BR>| &nbsp;o &nbsp;One RADIUS Packet=
 Type<BR>|<BR>| &nbsp; &nbsp; Type &nbsp; &nbsp; Name &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Reference<BR>| &nbsp; &nbsp=
; ------------------------------------------<BR>| &nbsp; &nbsp; &lt;MSG1&gt=
; &nbsp; Error-Notification &nbsp; &nbsp; &nbsp;[RFCthis]<BR>|<BR>| &nbsp;o=
 &nbsp;...<BR>|<BR>|<BR>| &nbsp;o &nbsp;...<BR><BR><BR>(6) &nbsp;Section 8<=
BR><BR>|8. &nbsp;Security Considerations<BR>|<BR>| &nbsp;None.<BR><BR>I bet=
 the IESG will not be a friend of such brevity ...<BR><BR><BR>Kind regards,=
<BR>&nbsp;&nbsp;Alfred H=EF=BF=BDnes.<BR><BR>--<BR><BR>+-------------------=
-----+--------------------------------------------+<BR>| TR-Sys Alfred Hoen=
es &nbsp; | &nbsp;Alfred Hoenes &nbsp; Dipl.-Math., Dipl.-Phys. &nbsp;|<BR>=
| Gerlinger Strasse 12 &nbsp; | &nbsp;Phone: (+49)7156/9635-0, Fax: -18 &nb=
sp; &nbsp; &nbsp; &nbsp; |<BR>| D-71254 &nbsp;Ditzingen &nbsp; &nbsp; | &nb=
sp;E-Mail: &nbsp;[email-masked] &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; |<BR>+------------------------+-------------------=
-------------------------+<BR></P></div></body></html>
------=_Part_166733_366877312.1229366839550--

--
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, 15 Dec 2008 18:46:36 +0000
Date: Mon, 15 Dec 2008 18:46:03 +0000 (UTC)
From: [email-masked]
To: [email-masked]
Subject: Fwd: review of draft-zorn-radius-pkmv1-02 (fwd)

------=_Part_166722_200715823.1229366763285
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Forwarding for a non-list memeber:=20

>From [email-masked] Thu Dec 11 19:56:57 MEZ 2008=20
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16=
.3)=20
=C2=A0=C2=A0 =C2=A0 =C2=A0id AA023651816; Thu, 11 Dec 2008 19:56:56 +0100=
=20
Return-Path: <[email-masked]>=20
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)=20
=C2=A0=C2=A0 =C2=A0 =C2=A0id TAA22615; Thu, 11 Dec 2008 19:56:55 +0100 (MEZ=
)=20
From: Alfred H=EF=BF=BDnes <[email-masked]>=20
To: [email-masked]=20
Cc: [email-masked]=20
Message-Id: <[email-masked]>=20
Date: Thu, 11 Dec 2008 19:56:55 +0100 (MEZ)=20
Subject: review of draft-zorn-radius-pkmv1-02=20

Hello,=20
on my cycle over RADIUS-related Internet-Drafts, I also have=20
followed up to your I-D, draft-zorn-radius-pkmv1-02,=20
and would like to submit a few comments.=20

First of all, I fear that this draft violates the emerging=20
guidelines for RADIUS extensions (draft-ietf-radext-design-05,=20
IETF LC passed) in so many details that it will most probably=20
not be socially acceptable.=20
Perhaps it would be prudent to redesign the intended attributes=20
as "Extended RADIUS Attributes", following the principles laid=20
down in draft-ietf-radext-extended-attributes-05 (you should be=20
aware of, as a co-author :-) )=20

Furthermore, I am astonished by seeing the draft making use of=20
very outdated references (which perhaps should be Normative!):=20

o =C2=A0 [PKCS.1.1998] =C2=A0had been documented for the IETF in RFC 2437,=
=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which =
has been obsoleted by RFC 3447 long ago;=20

o =C2=A0 [RFC2459] =C2=A0 =C2=A0 =C2=A0had first been obsoleted by RFC 3280=
,=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which =
now has been obsoleted by RFC 5280.=20

More details:=20

(1) =C2=A0Section 2.2=20

The draft uses, but does not introduce, more Acronyms than presently=20
listed there, e.g.,=20

=C2=A0=C2=A0 SS=20
=C2=A0=C2=A0 =C2=A0 =C2=A0Subscriber Station.=20

=C2=A0=C2=A0 BS=20
=C2=A0=C2=A0 =C2=A0 =C2=A0Base Station.=20

=C2=A0=C2=A0 CA=20
=C2=A0=C2=A0 =C2=A0 =C2=A0Certificate Authority; trusted party issuing and =
signing X.509=20
=C2=A0=C2=A0 =C2=A0 =C2=A0certificates.=20

(2) =C2=A0Section 3.1=20

The draft says:=20

=C2=A0=C2=A0 Description=20

=C2=A0=C2=A0 =C2=A0 =C2=A0The PKM-SS-Cert Attribute is variable length and =
contains the=20
| =C2=A0 =C2=A0 X.509 certificate [RFC2459] identifying the Subscriber Stat=
ion; it=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^=20
=C2=A0=C2=A0 =C2=A0 =C2=A0MAY be transmitted in the Access-Request message.=
=20

That's misleading.=20
How about saying more precisely:=20

=C2=A0=C2=A0 Description=20

=C2=A0=C2=A0 =C2=A0 =C2=A0The PKM-SS-Cert Attribute is variable length and =
contains the=20
| =C2=A0 =C2=A0 X.509 certificate [RFC2459] binding a public key to the ide=
ntifier=20
=C2=A0=C2=A0 =C2=A0 =C2=A0vvv =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^=20
| =C2=A0 =C2=A0 of the Subscriber Station; it MAY be transmitted in the Acc=
ess-=20
=C2=A0=C2=A0 =C2=A0 =C2=A0Request message.=20

'Value' :=20

Since you explicitely refer to RSA, how do you imagine to squeeze=20
an RSA public key certificate into the Value field (I guess you mean,=20
in RADIUS String format, do you?), which is limited to 253 octets ???=20

Did you mean -- contrary to the explanation quoted above -- a plain=20
certificate hash?=20

(3) =C2=A0Section 3.2=20

The draft says:=20

=C2=A0=C2=A0 Description=20

=C2=A0=C2=A0 =C2=A0 =C2=A0The PKM-CA-Cert Attribute is variable length and =
contains the=20
| =C2=A0 =C2=A0 X.509 certificate [RFC2459] identifying the CA certificate =
for the=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^=20
=C2=A0=C2=A0 =C2=A0 =C2=A0SS; it MAY be transmitted in the Access-Request m=
essage.=20

I'm getting confused even more. =C2=A0Did you mean:=20

=C2=A0=C2=A0 Description=20

=C2=A0=C2=A0 =C2=A0 =C2=A0The PKM-CA-Cert Attribute is variable length and =
contains the=20
| =C2=A0 =C2=A0 X.509 certificate [RFC2459] used by the CA to sign the SS=
=20
| =C2=A0 =C2=A0 certificate carried in the PKM-SS-Cert attribute of the sam=
e=20
| =C2=A0 =C2=A0 message; it MAY be transmitted in the Access-Request messag=
e.=20

'Value' :=20

Same issue as in (2) above!=20

(4) =C2=A0Section 3.3=20

'Description' :=20

I fear the text confuses the terms "timer" and "timeout".=20
A 'timer' is a running counter; it only makes sense to transport=20
its limit/starting value, a 'timeout value' in a packet over the=20
network.=20

The intended restriction,=20

=C2=A0=C2=A0 =C2=A0 An instance ... MAY be included ...=20

should perhaps better, and more precisely say,=20

=C2=A0=C2=A0 =C2=A0 One instance ... MAY be included ...=20
=C2=A0=C2=A0 =C2=A0 ^^^=20

'Value' :=20

The definition given is in direct violation of the principles laid down=20
in the RADIUS Extension Guidelines. =C2=A0Following the spirit of that memo=
,=20
doing so requires much more detailed, and much more convincing=20
rationale!=20

(5) =C2=A0Sections 3.4 and 3.5=20

Using 24- or 16-bit integers seems to be inacceptable, according to=20
the Guidelines. =C2=A0Putting multiple such values into one option also is=
=20
not conformant; the Guidelines recommend using multiple instances=20
of an elementary option instead.=20

(6) =C2=A0Section 3.6=20

The draft says:=20

=C2=A0=C2=A0 Description=20

| =C2=A0 =C2=A0 The PKM-SA-Descriptor Attribute is 8 octets in length. =C2=
=A0It=20
=C2=A0=C2=A0 =C2=A0 =C2=A0vvvvvvvvv =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^=20
| =C2=A0 =C2=A0 consists of 3 fields, described below, which together speci=
fy the=20
| =C2=A0 =C2=A0 characteristics of a PKM security association. =C2=A0One or=
 more=20
=C2=A0=C2=A0 =C2=A0 =C2=A0vvvvvvvvv =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^=20
| =C2=A0 =C2=A0 instances of the PKM-SA-Descriptor Attribute MAY occur in a=
n=20
=C2=A0=C2=A0 =C2=A0 =C2=A0Access-Accept message.=20

Semantically, the "It consists" is ambiguous and misleading;=20
obviously the text only talks about the sub-fields of the value=20
field; thus, it should be explicit about that and say:=20

=C2=A0=C2=A0"Its value consists ..." =C2=A0 =C2=A0or =C2=A0 =C2=A0"It conta=
ins ..." =C2=A0.=20
=C2=A0=C2=A0 ^^^^^^^^^^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^=20

I do not understand the semantics of "One or more instances".=20
Other parts of the text indicate that this attributes carries=20
the selection from the choice of cryptosuite identifiers offered=20
in the PKM-Cryptosuite-List attribute, plus more SA data.=20
Also, the table in Section 4 contains '0-1' in the 'Accept' column=20
and '0' in all other columns for this attribute.=20
Hence, the expected multiplicity needs to be clarified.=20

Subsequently, the draft says:=20

=C2=A0=C2=A0 SAID=20

=C2=A0=C2=A0 =C2=A0 =C2=A0The SAID field is two octets in length and contai=
ns a PKM SAID=20
| =C2=A0 =C2=A0 Section 3.5.=20

Apparently something is missing here. =C2=A0I guess:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0The SAID field is two octets in length and contai=
ns a PKM SAID=20
| =C2=A0 =C2=A0 (see Section 3.5).=20

The structured 'Value' field again violated the Guidelines.=20
It needs explicit, convincing justification.=20

(7) =C2=A0Section 3.7=20

Similar issues as in (6) apply here.=20
For brevity, I omit the details.=20

Kind regards,=20
=C2=A0=C2=A0Alfred H=EF=BF=BDnes.=20

--=20

+------------------------+--------------------------------------------+=20
| TR-Sys Alfred Hoenes =C2=A0 | =C2=A0Alfred Hoenes =C2=A0 Dipl.-Math., Dip=
l.-Phys. =C2=A0|=20
| Gerlinger Strasse 12 =C2=A0 | =C2=A0Phone: (+49)7156/9635-0, Fax: -18 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |=20
| D-71254 =C2=A0Ditzingen =C2=A0 =C2=A0 | =C2=A0E-Mail: =C2=[email-masked] =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=20
+------------------------+--------------------------------------------+=20

------=_Part_166722_200715823.1229366763285
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Arial; font-size: 12pt; color: #000000'><P>Forwar=
ding for a non-list memeber:</P>
<P><BR>From [email-masked] Thu Dec 11 19:56:57 MEZ 2008<BR>Received: fr=
om ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3)<BR>&nbsp=
;&nbsp; &nbsp; &nbsp;id AA023651816; Thu, 11 Dec 2008 19:56:56 +0100<BR>Ret=
urn-Path: &lt;[email-masked]&gt;<BR>Received: (from ah@localhost) by z.=
TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)<BR>&nbsp;&nbsp; &nbsp; &nbsp;id TAA226=
15; Thu, 11 Dec 2008 19:56:55 +0100 (MEZ)<BR>From: Alfred H=EF=BF=BDnes &lt=
;[email-masked]&gt;<BR>To: [email-masked]<BR>Cc: [email-masked]<BR>M=
essage-Id: &lt;[email-masked]&gt;<BR>Date: Thu, 11 Dec 200=
8 19:56:55 +0100 (MEZ)<BR>Subject: review of draft-zorn-radius-pkmv1-02<BR>=
<BR>Hello,<BR>on my cycle over RADIUS-related Internet-Drafts, I also have<=
BR>followed up to your I-D, draft-zorn-radius-pkmv1-02,<BR>and would like t=
o submit a few comments.<BR><BR>First of all, I fear that this draft violat=
es the emerging<BR>guidelines for RADIUS extensions (draft-ietf-radext-desi=
gn-05,<BR>IETF LC passed) in so many details that it will most probably<BR>=
not be socially acceptable.<BR>Perhaps it would be prudent to redesign the =
intended attributes<BR>as "Extended RADIUS Attributes", following the princ=
iples laid<BR>down in draft-ietf-radext-extended-attributes-05 (you should =
be<BR>aware of, as a co-author :-) )<BR><BR>Furthermore, I am astonished by=
 seeing the draft making use of<BR>very outdated references (which perhaps =
should be Normative!):<BR><BR>o &nbsp; [PKCS.1.1998] &nbsp;had been documen=
ted for the IETF in RFC 2437,<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; which has been obsoleted by RFC 3447 long ago;<B=
R><BR>o &nbsp; [RFC2459] &nbsp; &nbsp; &nbsp;had first been obsoleted by RF=
C 3280,<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; which now has been obsoleted by RFC 5280.<BR><BR>More details:<BR><BR>=
<BR>(1) &nbsp;Section 2.2<BR><BR>The draft uses, but does not introduce, mo=
re Acronyms than presently<BR>listed there, e.g.,<BR><BR>&nbsp;&nbsp; SS<BR=
>&nbsp;&nbsp; &nbsp; &nbsp;Subscriber Station.<BR><BR>&nbsp;&nbsp; BS<BR>&n=
bsp;&nbsp; &nbsp; &nbsp;Base Station.<BR><BR>&nbsp;&nbsp; CA<BR>&nbsp;&nbsp=
; &nbsp; &nbsp;Certificate Authority; trusted party issuing and signing X.5=
09<BR>&nbsp;&nbsp; &nbsp; &nbsp;certificates.<BR><BR><BR>(2) &nbsp;Section =
3.1<BR><BR>The draft says:<BR><BR>&nbsp;&nbsp; Description<BR><BR>&nbsp;&nb=
sp; &nbsp; &nbsp;The PKM-SS-Cert Attribute is variable length and contains =
the<BR>| &nbsp; &nbsp; X.509 certificate [RFC2459] identifying the Subscrib=
er Station; it<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^^^^^^^^=
^^^<BR>&nbsp;&nbsp; &nbsp; &nbsp;MAY be transmitted in the Access-Request m=
essage.<BR><BR>That's misleading.<BR>How about saying more precisely:<BR><B=
R>&nbsp;&nbsp; Description<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp;The PKM-SS-Cert=
 Attribute is variable length and contains the<BR>| &nbsp; &nbsp; X.509 cer=
tificate [RFC2459] binding a public key to the identifier<BR>&nbsp;&nbsp; &=
nbsp; &nbsp;vvv &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<BR>| &nbsp;=
 &nbsp; of the Subscriber Station; it MAY be transmitted in the Access-<BR>=
&nbsp;&nbsp; &nbsp; &nbsp;Request message.<BR><BR>'Value' :<BR><BR>Since yo=
u explicitely refer to RSA, how do you imagine to squeeze<BR>an RSA public =
key certificate into the Value field (I guess you mean,<BR>in RADIUS String=
 format, do you?), which is limited to 253 octets ???<BR><BR>Did you mean -=
- contrary to the explanation quoted above -- a plain<BR>certificate hash?<=
BR><BR><BR>(3) &nbsp;Section 3.2<BR><BR>The draft says:<BR><BR>&nbsp;&nbsp;=
 Description<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp;The PKM-CA-Cert Attribute is =
variable length and contains the<BR>| &nbsp; &nbsp; X.509 certificate [RFC2=
459] identifying the CA certificate for the<BR>&nbsp;&nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp;^^^^^^^^^^^<BR>&nbsp;&nbsp; &nbsp; &nbsp;SS; it MAY be=
 transmitted in the Access-Request message.<BR><BR>I'm getting confused eve=
n more. &nbsp;Did you mean:<BR><BR>&nbsp;&nbsp; Description<BR><BR>&nbsp;&n=
bsp; &nbsp; &nbsp;The PKM-CA-Cert Attribute is variable length and contains=
 the<BR>| &nbsp; &nbsp; X.509 certificate [RFC2459] used by the CA to sign =
the SS<BR>| &nbsp; &nbsp; certificate carried in the PKM-SS-Cert attribute =
of the same<BR>| &nbsp; &nbsp; message; it MAY be transmitted in the Access=
-Request message.<BR><BR>'Value' :<BR><BR>Same issue as in (2) above!<BR><B=
R><BR>(4) &nbsp;Section 3.3<BR><BR>'Description' :<BR><BR>I fear the text c=
onfuses the terms "timer" and "timeout".<BR>A 'timer' is a running counter;=
 it only makes sense to transport<BR>its limit/starting value, a 'timeout v=
alue' in a packet over the<BR>network.<BR><BR>The intended restriction,<BR>=
<BR>&nbsp;&nbsp; &nbsp; An instance ... MAY be included ...<BR><BR>should p=
erhaps better, and more precisely say,<BR><BR>&nbsp;&nbsp; &nbsp; One insta=
nce ... MAY be included ...<BR>&nbsp;&nbsp; &nbsp; ^^^<BR><BR>'Value' :<BR>=
<BR>The definition given is in direct violation of the principles laid down=
<BR>in the RADIUS Extension Guidelines. &nbsp;Following the spirit of that =
memo,<BR>doing so requires much more detailed, and much more convincing<BR>=
rationale!<BR><BR><BR>(5) &nbsp;Sections 3.4 and 3.5<BR><BR>Using 24- or 16=
-bit integers seems to be inacceptable, according to<BR>the Guidelines. &nb=
sp;Putting multiple such values into one option also is<BR>not conformant; =
the Guidelines recommend using multiple instances<BR>of an elementary optio=
n instead.<BR><BR><BR>(6) &nbsp;Section 3.6<BR><BR>The draft says:<BR><BR>&=
nbsp;&nbsp; Description<BR><BR>| &nbsp; &nbsp; The PKM-SA-Descriptor Attrib=
ute is 8 octets in length. &nbsp;It<BR>&nbsp;&nbsp; &nbsp; &nbsp;vvvvvvvvv =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; ^^^<BR>| &nbsp; &nbsp; consists of 3 fields, described below, wh=
ich together specify the<BR>| &nbsp; &nbsp; characteristics of a PKM securi=
ty association. &nbsp;One or more<BR>&nbsp;&nbsp; &nbsp; &nbsp;vvvvvvvvv &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^^^^^^^^^^^^<BR>| &=
nbsp; &nbsp; instances of the PKM-SA-Descriptor Attribute MAY occur in an<B=
R>&nbsp;&nbsp; &nbsp; &nbsp;Access-Accept message.<BR><BR>Semantically, the=
 "It consists" is ambiguous and misleading;<BR>obviously the text only talk=
s about the sub-fields of the value<BR>field; thus, it should be explicit a=
bout that and say:<BR><BR>&nbsp;&nbsp;"Its value consists ..." &nbsp; &nbsp=
;or &nbsp; &nbsp;"It contains ..." &nbsp;.<BR>&nbsp;&nbsp; ^^^^^^^^^^ &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; ^^^^^^^^<BR><BR>I do not understand the semantics of "One or mor=
e instances".<BR>Other parts of the text indicate that this attributes carr=
ies<BR>the selection from the choice of cryptosuite identifiers offered<BR>=
in the PKM-Cryptosuite-List attribute, plus more SA data.<BR>Also, the tabl=
e in Section 4 contains '0-1' in the 'Accept' column<BR>and '0' in all othe=
r columns for this attribute.<BR>Hence, the expected multiplicity needs to =
be clarified.<BR><BR>Subsequently, the draft says:<BR><BR>&nbsp;&nbsp; SAID=
<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp;The SAID field is two octets in length an=
d contains a PKM SAID<BR>| &nbsp; &nbsp; Section 3.5.<BR><BR>Apparently som=
ething is missing here. &nbsp;I guess:<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp;The=
 SAID field is two octets in length and contains a PKM SAID<BR>| &nbsp; &nb=
sp; (see Section 3.5).<BR><BR>The structured 'Value' field again violated t=
he Guidelines.<BR>It needs explicit, convincing justification.<BR><BR><BR>(=
7) &nbsp;Section 3.7<BR><BR>Similar issues as in (6) apply here.<BR>For bre=
vity, I omit the details.<BR><BR><BR>Kind regards,<BR>&nbsp;&nbsp;Alfred H=
=EF=BF=BDnes.<BR><BR>--<BR><BR>+------------------------+------------------=
--------------------------+<BR>| TR-Sys Alfred Hoenes &nbsp; | &nbsp;Alfred=
 Hoenes &nbsp; Dipl.-Math., Dipl.-Phys. &nbsp;|<BR>| Gerlinger Strasse 12 &=
nbsp; | &nbsp;Phone: (+49)7156/9635-0, Fax: -18 &nbsp; &nbsp; &nbsp; &nbsp;=
 |<BR>| D-71254 &nbsp;Ditzingen &nbsp; &nbsp; | &nbsp;E-Mail: &nbsp;ah@TR-S=
ys.de &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 |<BR>+------------------------+-------------------------------------------=
-+<BR></P></div></body></html>
------=_Part_166722_200715823.1229366763285--

--
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, 15 Dec 2008 18:34:20 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue with Guidelines document
Date: Mon, 15 Dec 2008 13:33:18 -0500
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

> > 5.13. Table of Attributes
> >=20
> > The following table provides a guide to which attributes may be=20
> > found in Accounting-Request packets. No attributes should be found
> > in Accounting-Response packets except Proxy-State and possibly
> > Vendor-Specific.
> >
> > That seems pretty clear. Nothing but Proxy-State && VSA's.
>
> Yes.=A0=A0 VSAs are allowed.=A0 Presumably this would also include
> Extended Attributes?=20

Uh...  No.  Extended Attributes leverage the VSA _format_ for =
extensibility
reasons but they are not [inherently] vendor specific.  VSA =
traditionally
implied "proprietary secret sauce" that other vendors could safely =
ignore.
That is certainly not the case with Extended Attributes, which could be
Standards Track.

If this is a common misunderstanding -- i.e. the traditional usage rules =
for
VSAs apply to Extended Attributes -- we should indeed clear up that
confusion immediately.  Perhaps in the Extended Attributes draft itself. =

--
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, 15 Dec 2008 16:01:30 +0000
From: Bernard Aboba <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: Issue with Guidelines document
Date: Mon, 15 Dec 2008 08:00:27 -0800

--_b5ca6ad8-e603-4619-81af-a72db548d792_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Perhaps you could suggest a better way to accomplish this?  Maybe it's
> really not needed: much more efficient to just wait till the server goes
> away then retry a few times.

I don't think there is a better way to accomplish this in RADIUS at this po=
int.=20

SIP=2C Diameter and HTTP all have a "redirect" error message.  RADIUS does
not.  This means that the RADIUS accounting server either stores the=20
accounting packet and returns an Accounting-Response=2C or it drops the=20
packet=2C and then has to deal with a retry.=20

Given this=2C about the best that can be done is for the server to process =
the
Accounting-Request and then send whatever load shedding info it has in
a VSA. =20

If the NAS doesn't understand the VSA=2C then it will ignore it=2C and
things will be no worse off than had the server not sent the VSA at all.=20

> Excellent suggestion: it's not like the semantics of the CoA exchange bin=
d
> it to a specific session=2C while the Accounting-Response is a generic
> accounting-related ACK. =20

TheCoA-Request also requires the NAS (and Dynamic Authorization Client)
to implement RFC 5176.=20

--_b5ca6ad8-e603-4619-81af-a72db548d792_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B Perhaps you could suggest a better way to accomplish this?  Maybe it=
's<br>&gt=3B really not needed: much more efficient to just wait till the s=
erver goes<br>&gt=3B away then retry a few times.<br><br>I don't think ther=
e is a better way to accomplish this in RADIUS at this point. <br><br>SIP=
=2C Diameter and HTTP all have a "redirect" error message.&nbsp=3B RADIUS d=
oes<br>not.&nbsp=3B This means that the RADIUS accounting server either sto=
res the <br>accounting packet and returns an Accounting-Response=2C or it d=
rops the <br>packet=2C and then has to deal with a retry. <br><br>Given thi=
s=2C about the best that can be done is for the server to process the<br>Ac=
counting-Request and then send whatever load shedding info it has in<br>a V=
SA.&nbsp=3B <br><br>If the NAS doesn't understand the VSA=2C then it will i=
gnore it=2C and<br>things will be no worse off than had the server not sent=
 the VSA at all. <br><br>&gt=3B Excellent suggestion: it's not like the sem=
antics of the CoA exchange bind<br>&gt=3B it to a specific session=2C while=
 the Accounting-Response is a generic<br>&gt=3B accounting-related ACK.  <b=
r><br>TheCoA-Request also requires the NAS (and Dynamic Authorization Clien=
t)<br>to implement RFC 5176. <br></body>
</html>=

--_b5ca6ad8-e603-4619-81af-a72db548d792_--

--
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, 15 Dec 2008 13:20:57 +0000
Date: Mon, 15 Dec 2008 14:20:24 +0100
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Greg Weber' <[email-masked]>,  'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: Re: Issue with Guidelines document

Glen Zorn wrote:
>>   That sounds like a bit of a hack to me.  "Yes I've stored the
>> accounting data for bob, and by the way, I'm rebooting in 5 minutes".
> 
> Perhaps you could suggest a better way to accomplish this?  Maybe it's
> really not needed: much more efficient to just wait till the server goes
> away then retry a few times.

  I have no good suggestions here.  Traditionally, yes, the server just
"goes away".

  I'm not even aware of *which* NASes support this behavior.  This
behavior is new to me, and I've been doing this for well over a decade.

>>   I would suggest that CoA might be a better choice for that.
> 
> Excellent suggestion: it's not like the semantics of the CoA exchange bind
> it to a specific session, while the Accounting-Response is a generic
> accounting-related ACK.  

 ... which is sent in response to an Accounting-Request for a particular
user session.

  Just like CoA.

  If the NAS vendors need this functionality, CoA seems to be a better
fit than Accounting-Response.  Few RADIUS servers have traditionally
implemented CoA, so I understand why using Accounting-Response is tempting.

  Now that we have the potential for Status-Server, it is much safer for
the RADIUS server to just "go away".

  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: Mon, 15 Dec 2008 11:41:47 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'Greg Weber'" <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: Issue with Guidelines document
Date: Mon, 15 Dec 2008 18:40:12 +0700

> Greg Weber wrote:
> >>  I would like to know what it *means* to have VSA's in an
> >> Accounting-Response.  What does the NAS do with them?  Log them?
> Ignore
> >> them?  Change it's behavior?
> >
> > This can be used to communicate server load or pending planned
> downtime
> > information back to the NAS which then can be used in server
> selection
> > algorithms.
> 
>   That sounds like a bit of a hack to me.  "Yes I've stored the
> accounting data for bob, and by the way, I'm rebooting in 5 minutes".

Perhaps you could suggest a better way to accomplish this?  Maybe it's
really not needed: much more efficient to just wait till the server goes
away then retry a few times.

> 
> >  I believe there's a commercial server in the PacketCable space
> > doing this (for voice gateway RADIUS clients).  Also have heard some
> > discussion about a server being able to dynamically adjust the
> interim
> > accounting
> > record interval by setting a VSA in the accounting response
> (mimicking a
> > Diameter feature), but I'm not sure if that's implemented by any
> servers.
> 
>   I would suggest that CoA might be a better choice for that.

Excellent suggestion: it's not like the semantics of the CoA exchange bind
it to a specific session, while the Accounting-Response is a generic
accounting-related ACK.  

...

--
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, 15 Dec 2008 10:22:41 +0000
Date: Mon, 15 Dec 2008 11:21:59 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: Issue with Guidelines document

Bernard Aboba wrote:
> Yes.   VSAs are allowed  Presumably this would also include 
> Extended Attributes?

  Likely, yes.

> Since this document is a BCP, not an update to RFC 2866, it can quote from
> existing RFCs, but shouldn't modify them.
> 
> So it's ok to add an item to Section 3.3 about not including standard RADIUS
> attributes beyond Proxy-State in Accounting-Responses, using a quote
> from RFC 2866 Section 5.13 for justification.  Since RFC 2866 allows VSAs,
> I don't think they can or should be prohibited in this document.

  Maybe make them NOT RECOMMENDED?

  Ongoing discussion indicates that people are using them to implement
CoA behavior.  i.e. changes to billing, bandwidth, etc.  Because "doing
CoA is too hard".

  Also, making changes to user sessions as a result of VSA's in an
Accounting-Response should be NOT RECOMMENDED.  Implementors SHOULD use
CoA instead.

  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: Mon, 15 Dec 2008 07:40:35 +0000
Date: Mon, 15 Dec 2008 08:39:45 +0100
From: Alan DeKok <[email-masked]>
To: Greg Weber <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: Issue with Guidelines document

Greg Weber wrote:
>>  I would like to know what it *means* to have VSA's in an
>> Accounting-Response.  What does the NAS do with them?  Log them?  Ignore
>> them?  Change it's behavior?
> 
> This can be used to communicate server load or pending planned downtime
> information back to the NAS which then can be used in server selection
> algorithms.

  That sounds like a bit of a hack to me.  "Yes I've stored the
accounting data for bob, and by the way, I'm rebooting in 5 minutes".

>  I believe there's a commercial server in the PacketCable space
> doing this (for voice gateway RADIUS clients).  Also have heard some
> discussion about a server being able to dynamically adjust the interim
> accounting
> record interval by setting a VSA in the accounting response (mimicking a
> Diameter feature), but I'm not sure if that's implemented by any servers.

  I would suggest that CoA might be a better choice for that.

  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: Sun, 14 Dec 2008 22:04:32 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Issue 298:  Extended Attribute Usage Restrictions
Date: Sun, 14 Dec 2008 14:04:09 -0800

--_d8ae8bd6-d3d6-4ab0-bb26-8a646e4cb5c5_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Issue 298:  Extended Attributes Restrictions

Submitter name: Bernard Aboba

Submitter email address: [email-masked]=20

Date first submitted:  December 14=2C 2008

Reference:  =20

Document: EXTENDED

Comment type:  Technical

Priority: S=20

Section: Various =20

Rationale/Explanation of issue:

RFC 2866 Section 5.13 states:
   The following table provides a guide to which attributes may be found
   in Accounting-Request packets.  No attributes should be found in
   Accounting-Response packets except Proxy-State and possibly Vendor-
   Specific.

Given that RADIUS Extended Attributes are VSAs=2C the question arises as to=
 whether
they are allowed in Accounting-Responses or not.  My take would be "no" -- =
they
should be treated like RADIUS standard attributes.=20

In RFC 5176=2C VSAs are listed as not permitted within CoA-ACK=2C CoA-NAK=
=2C Disconnect-ACK
or Disconnect-NAK packets.  They are listed as "0+" within CoA-Request and=
=20
Disconnect-Request packets=2C however:

   (Note 7) Within Disconnect-Request packets=2C Vendor-Specific
   Attributes (VSAs) MAY be used for session identification.  Within
   CoA-Request packets=2C VSAs MAY be used for either session
   identification or authorization change.  However=2C the same Attribute
   MUST NOT be used for both purposes simultaneously.

So=2C do the restrictions on VSA usage apply to Extended Attributes as well=
?=20

--_d8ae8bd6-d3d6-4ab0-bb26-8a646e4cb5c5_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<b>Issue 298:&nbsp=3B Extended Attributes Restrictions</b><br>
Submitter name: Bernard Aboba<br>
Submitter email address: [email-masked] <br>
Date first submitted:&nbsp=3B December 14=2C 2008<br>
Reference:&nbsp=3B&nbsp=3B <br>
Document: EXTENDED<br>
Comment type:&nbsp=3B Technical<br>
Priority: S <br>
Section: Various&nbsp=3B <br>
Rationale/Explanation of issue:<br><br>RFC 2866 Section 5.13 states:<br><pr=
e>   The following table provides a guide to which attributes may be found<=
br>   in Accounting-Request packets.  No attributes should be found in<br> =
  Accounting-Response packets except Proxy-State and possibly Vendor-<br>  =
 Specific.<br><br>Given that RADIUS Extended Attributes are VSAs=2C the que=
stion arises as to whether<br>they are allowed in Accounting-Responses or n=
ot.  My take would be "no" -- they<br>should be treated like RADIUS standar=
d attributes. <br><br>In RFC 5176=2C VSAs are listed as not permitted withi=
n CoA-ACK=2C CoA-NAK=2C Disconnect-ACK<br>or Disconnect-NAK packets.  They =
are listed as "0+" within CoA-Request and <br>Disconnect-Request packets=2C=
 however:<br><br>   (Note 7) Within Disconnect-Request packets=2C Vendor-Sp=
ecific<br>   Attributes (VSAs) MAY be used for session identification.  Wit=
hin<br>   CoA-Request packets=2C VSAs MAY be used for either session<br>   =
identification or authorization change.  However=2C the same Attribute<br> =
  MUST NOT be used for both purposes simultaneously.<br><br>So=2C do the re=
strictions on VSA usage apply to Extended Attributes as well? <br></pre><br=
><br><table style=3D"border-top: 1px solid black=3B font-weight: bold=3B fo=
nt-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"ht=
tp://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D=
"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"=
><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=
=2C 85)=3B text-decoration: underline=3B"></span></a><br></td></tr></tbody>=
</table></body>
</html>=

--_d8ae8bd6-d3d6-4ab0-bb26-8a646e4cb5c5_--

--
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, 14 Dec 2008 21:56:29 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>, Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: Issue with Guidelines document
Date: Sun, 14 Dec 2008 13:55:42 -0800

--_e467b4d2-4cab-41cb-bcc5-0096977c6733_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>In this particular case=2C while RFC 2866 indicates that there are no
>required attributes in an Accounting-Response=2C it doesn't prohibit
>them.
>
> 5.13.  Table of Attributes
>
> The following table provides a guide to which attributes may be found
> in Accounting-Request packets.  No attributes should be found in
> Accounting-Response packets except Proxy-State and possibly Vendor-
> Specific.
>
> That seems pretty clear.  Nothing but Proxy-State && VSA's.

Yes.   VSAs are allowed  Presumably this would also include

Extended Attributes?=20

> >  I would like to know what it *means* to have VSA's in an
> > Accounting-Response.  What does the NAS do with them?  Log them?  Ignor=
e
> > them?  Change it's behavior?
>=20
> This can be used to communicate server load or pending planned downtime
> information back to the NAS which then can be used in server selection
> algorithms.  I believe there's a commercial server in the PacketCable spa=
ce
> doing this (for voice gateway RADIUS clients).  Also have heard some
> discussion about a server being able to dynamically adjust the interim
> accounting record interval by setting a VSA in the accounting response (m=
imicking a
> Diameter feature)=2C but I'm not sure if that's implemented by any server=
s.
>=20
> But it sounds like you're talking about static attribute values below.
> Anyway=2C I don't think we should try to prohibit VSAs in accounting resp=
onses.

Since this document is a BCP=2C not an update to RFC 2866=2C it can quote f=
rom
existing RFCs=2C but shouldn't modify them.=20

So it's ok to add an item to Section 3.3 about not including standard RADIU=
S
attributes beyond Proxy-State in Accounting-Responses=2C using a quote
from RFC 2866 Section 5.13 for justification.  Since RFC 2866 allows VSAs=
=2C
I don't think they can or should be prohibited in this document.=20

It also probably makes sense to log an issue against the Extended Attribute=
s
document for clarification on whether they can be included in Accounting-Re=
sponses.=20

--_e467b4d2-4cab-41cb-bcc5-0096977c6733_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3BIn this particular case=2C while RFC 2866 indicates that there are no=
<br>&gt=3Brequired attributes in an Accounting-Response=2C it doesn't prohi=
bit<br>&gt=3Bthem.<br>&gt=3B<br>&gt=3B 5.13.  Table of Attributes<br>&gt=3B=
<br>&gt=3B The following table provides a guide to which attributes may be =
found<br>&gt=3B in Accounting-Request packets.  No attributes should be fou=
nd in<br>&gt=3B Accounting-Response packets except Proxy-State and possibly=
 Vendor-<br>&gt=3B Specific.<br>&gt=3B<br>&gt=3B That seems pretty clear.  =
Nothing but Proxy-State &amp=3B&amp=3B VSA's.<br><br>Yes.&nbsp=3B&nbsp=3B V=
SAs are allowed&nbsp=3B Presumably this would also include<br><br>Extended =
Attributes? <br><br>&gt=3B &gt=3B  I would like to know what it *means* to =
have VSA's in an<br>&gt=3B &gt=3B Accounting-Response.  What does the NAS d=
o with them?  Log them?  Ignore<br>&gt=3B &gt=3B them?  Change it's behavio=
r?<br>&gt=3B <br>&gt=3B This can be used to communicate server load or pend=
ing planned downtime<br>&gt=3B information back to the NAS which then can b=
e used in server selection<br>&gt=3B algorithms.  I believe there's a comme=
rcial server in the PacketCable space<br>&gt=3B doing this (for voice gatew=
ay RADIUS clients).  Also have heard some<br>&gt=3B discussion about a serv=
er being able to dynamically adjust the interim<br>&gt=3B accounting record=
 interval by setting a VSA in the accounting response (mimicking a<br>&gt=
=3B Diameter feature)=2C but I'm not sure if that's implemented by any serv=
ers.<br>&gt=3B <br>&gt=3B But it sounds like you're talking about static at=
tribute values below.<br>&gt=3B Anyway=2C I don't think we should try to pr=
ohibit VSAs in accounting responses.<br><br>Since this document is a BCP=2C=
 not an update to RFC 2866=2C it can quote from<br>existing RFCs=2C but sho=
uldn't modify them. <br><br>So it's ok to add an item to Section 3.3 about =
not including standard RADIUS<br>attributes beyond Proxy-State in Accountin=
g-Responses=2C using a quote<br>from RFC 2866 Section 5.13 for justificatio=
n.&nbsp=3B Since RFC 2866 allows VSAs=2C<br>I don't think they can or shoul=
d be prohibited in this document. <br><br>It also probably makes sense to l=
og an issue against the Extended Attributes<br>document for clarification o=
n whether they can be included in Accounting-Responses. <br></body>
</html>=

--_e467b4d2-4cab-41cb-bcc5-0096977c6733_--

--
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, 14 Dec 2008 19:09:52 +0000
Date: Sun, 14 Dec 2008 14:09:03 -0500
From: "Greg Weber" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Subject: Re: Issue with Guidelines document
Cc: "Bernard Aboba" <[email-masked]>,  "[email-masked]" <[email-masked]>

On Sun, Dec 14, 2008 at 12:53 PM, Alan DeKok <[email-masked]> wrote:
> Bernard Aboba wrote:
>> In this particular case, while RFC 2866 indicates that there are no
>> required attributes in an Accounting-Response, it doesn't prohibit
>> them.
>
>  Hmm...
>
> 5.13.  Table of Attributes
>
>   The following table provides a guide to which attributes may be found
>   in Accounting-Request packets.  No attributes should be found in
>   Accounting-Response packets except Proxy-State and possibly Vendor-
>   Specific.
>
>  That seems pretty clear.  Nothing but Proxy-State && VSA's.
>
>>  So is the issue the inclusion of attributes, or is it the use
>> of those attributes?
>
>  I would like to know what it *means* to have VSA's in an
> Accounting-Response.  What does the NAS do with them?  Log them?  Ignore
> them?  Change it's behavior?

This can be used to communicate server load or pending planned downtime
information back to the NAS which then can be used in server selection
algorithms.  I believe there's a commercial server in the PacketCable space
doing this (for voice gateway RADIUS clients).  Also have heard some
discussion about a server being able to dynamically adjust the interim
accounting
record interval by setting a VSA in the accounting response (mimicking a
Diameter feature), but I'm not sure if that's implemented by any servers.

But it sounds like you're talking about static attribute values below.
Anyway, I don't think we should try to prohibit VSAs in accounting responses.

Greg

>
>  I'm seeing people who insist that they have to put attributes in an
> Accounting-Response.  Sometimes they claim their NAS requires it.  But I
> can't get an explanation as to *why*.
>
>  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/>
>

--
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, 14 Dec 2008 17:54:12 +0000
Date: Sun, 14 Dec 2008 18:53:30 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Issue with Guidelines document

Bernard Aboba wrote:
> In this particular case, while RFC 2866 indicates that there are no
> required attributes in an Accounting-Response, it doesn't prohibit
> them.

  Hmm...

5.13.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in Accounting-Request packets.  No attributes should be found in
   Accounting-Response packets except Proxy-State and possibly Vendor-
   Specific.

  That seems pretty clear.  Nothing but Proxy-State && VSA's.

>  So is the issue the inclusion of attributes, or is it the use
> of those attributes?

  I would like to know what it *means* to have VSA's in an
Accounting-Response.  What does the NAS do with them?  Log them?  Ignore
them?  Change it's behavior?

  I'm seeing people who insist that they have to put attributes in an
Accounting-Response.  Sometimes they claim their NAS requires it.  But I
can't get an explanation as to *why*.

  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: Sun, 14 Dec 2008 16:20:11 +0000
Date: Sun, 14 Dec 2008 11:19:47 -0500
From: "Greg Weber" <[email-masked]>
To: [email-masked]
Subject: Re: WGLC comments on draft-ietf-radext-tunnel-type-00.txt

I liked the proposed title change too (below).

Also, the current text has one error and one warning in idnits.

On Tue, Nov 25, 2008 at 4:54 PM, David B. Nelson
<[email-masked]> wrote:
> Glen Zorn writes...
>
>> The title is so vague as to be meaningless: suggest changing to the
>> extremely unwieldy "A RADIUS Tunnel Type for IP Encapsulating Security
>> Payload (ESP) in the Tunnel-mode with IKEv2" or some such thing (see
>> below), w/an appropriate abbreviation for the second & following pages.
>
> Agreed.
>
<snip>

--
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, 14 Dec 2008 15:34:01 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Issue with Guidelines document
Date: Sun, 14 Dec 2008 07:32:45 -0800

--_c84f5585-0f36-4c90-94e3-39e0d1535ddc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In gerneral=2C the purpose of the Design Guidelines document is to provide
guidelines compatible with existing RADIUS RFCs.  As a result=2C RADIUS
operational model issues discussed in Section 3.3 contain citations
to existing RFCs.=20
=20
In this particular case=2C while RFC 2866 indicates that there are no
required attributes in an Accounting-Response=2C it doesn't prohibit
them.  So is the issue the inclusion of attributes=2C or is it the use
of those attributes?
=20
>From Section 4.2:
=20
4.2.  Accounting-Response   Description      Accounting-Response packets ar=
e sent by the RADIUS accounting      server to the client to acknowledge th=
at the Accounting-Request      has been received and recorded successfully.=
  If the Accounting-      Request was recorded successfully then the RADIUS=
 accounting      server MUST transmit a packet with the Code field set to 5=
      (Accounting-Response).  On reception of an Accounting-Response by    =
  the client=2C the Identifier field is matched with a pending      Account=
ing-Request.  The Response Authenticator field MUST contain      the correc=
t response for the pending Accounting-Request.  Invalid      packets are si=
lently discarded.      A RADIUS Accounting-Response is not required to have=
 any      attributes in it.   A summary of the Accounting-Response packet f=
ormat 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   +-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Code      |  Identifi=
er   |            Length             |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                                        =
                       |   |                     Response Authenticator    =
                |   |                                                      =
         |   |                                                             =
  |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |=
  Attributes ...   +-+-+-+-+-+-+-+-+-+-+-+-+-   Code      5 for Accounting-=
Response.   Identifier      The Identifier field is a copy of the Identifie=
r field of the      Accounting-Request which caused this Accounting-Respons=
e.   Response Authenticator      The Response Authenticator of an Accountin=
g-Response contains a      16-octet MD5 hash value calculated according to =
the method      described in "Response Authenticator" above.   Attributes  =
    The Attributes field is variable in length=2C and contains a list of   =
   zero or more Attributes.
=20

 EMAILING FOR THE GREATER GOODJoin me> Date: Sat=2C 13 Dec 2008 10:16:53 +0=
100> From: [email-masked]> To: [email-masked]> Subject: =
Issue with Guidelines document> > This might be a little late=2C but it may=
 be worth adding one more note:> > ---> Accounting-Response packets SHOULD =
contain only Proxy-State.> > State changes in the RADIUS client based on Ac=
counting-Response> packets are NOT RECOMMENDED. They do not fit within the =
traditional> RADIUS operational model. Despite the text in [RFC2866] Sectio=
n 5.13> saying that "possibly" Vendor-Specific is permitted=2C such use is =
NOT> RECOMMENDED.> ---> > > Is it too late for this? Do we have Area Direct=
or agreement that this> is a good idea?> > The background is a growing numb=
er of NAS equipment that I'm seeing> which *does* look for attributes in an=
 Accounting-Response. It's not> clear what the NAS does with those attribut=
es=2C but internal state> changes are a logical conclusion.> > Alan DeKok.>=
 > --> to unsubscribe send a message to [email-masked] with=
> the word 'unsubscribe' in a single line as the message text body.> archiv=
e: <http://psg.com/lists/radiusext/>=

--_c84f5585-0f36-4c90-94e3-39e0d1535ddc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
In gerneral=2C the purpose of the Design Guidelines document is to provide<=
BR>
guidelines compatible with existing RADIUS RFCs.&nbsp=3B As a result=2C RAD=
IUS<BR>
operational model issues discussed in Section 3.3 contain citations<BR>
to existing RFCs. <BR>
&nbsp=3B<BR>
In this particular case=2C while RFC 2866 indicates that there are no<BR>
required attributes in an Accounting-Response=2C&nbsp=3Bit doesn't prohibit=
<BR>
them. &nbsp=3BSo is the issue the inclusion of attributes=2C or is it the u=
se<BR>
of those attributes?<BR>
&nbsp=3B<BR>
>From Section 4.2:<BR>
&nbsp=3B<BR>
4.2.&nbsp=3B Accounting-Response<BR><BR>&nbsp=3B&nbsp=3B Description<BR><BR=
>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Accounting-Response packets are s=
ent by the RADIUS accounting<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B se=
rver to the client to acknowledge that the Accounting-Request<BR>&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B has been received and recorded successfully.=
&nbsp=3B If the Accounting-<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Req=
uest was recorded successfully then the RADIUS accounting<BR>&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B server MUST transmit a packet with the Code fie=
ld set to 5<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B (Accounting-Respons=
e).&nbsp=3B On reception of an Accounting-Response by<BR>&nbsp=3B&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B the client=2C the Identifier field is matched with a=
 pending<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Accounting-Request.&nb=
sp=3B The Response Authenticator field MUST contain<BR>&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B the correct response for the pending Accounting-Reques=
t.&nbsp=3B Invalid<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B packets are =
silently discarded.<BR><BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B A RADIU=
S Accounting-Response is not required to have any<BR>&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B attributes in it.<BR><BR>&nbsp=3B&nbsp=3B A summary of =
the Accounting-Response packet format is shown below.<BR>&nbsp=3B&nbsp=3B T=
he fields are transmitted from left to right.<BR><BR>&nbsp=3B&nbsp=3B&nbsp=
=3B 0&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
 1&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B 2&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B 3<BR>&n=
bsp=3B&nbsp=3B&nbsp=3B 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<BR>&nbsp=3B&nbsp=3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp=3B&nbsp=3B |&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B Code&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |&nbsp=3B Identifier&nbsp=
=3B&nbsp=3B |&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B Length&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |<BR>&nbsp=3B&nbsp=
=3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&n=
bsp=3B&nbsp=3B |&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |<BR>&nbsp=
=3B&nbsp=3B |&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B Response Authenticator&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |<BR>&nbsp=3B&nbsp=3B |=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |<BR>&nbsp=3B&nbsp=3B |&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |<BR>&nbsp=3B&nbsp=3B +-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp=3B&nbsp=
=3B |&nbsp=3B Attributes ...<BR>&nbsp=3B&nbsp=3B +-+-+-+-+-+-+-+-+-+-+-+-+-=
<BR><BR>&nbsp=3B&nbsp=3B Code<BR><BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B 5 for Accounting-Response.<BR><BR>&nbsp=3B&nbsp=3B Identifier<BR><BR>&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B The Identifier field is a copy of th=
e Identifier field of the<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Accou=
nting-Request which caused this Accounting-Response.<BR><BR>&nbsp=3B&nbsp=
=3B Response Authenticator<BR><BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B =
The Response Authenticator of an Accounting-Response contains a<BR>&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B 16-octet MD5 hash value calculated accordi=
ng to the method<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B described in "=
Response Authenticator" above.<BR><BR>&nbsp=3B&nbsp=3B Attributes<BR><BR>&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B The Attributes field is variable in =
length=2C and contains a list of<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B zero or more Attributes.<BR><BR><BR>
<BR>&nbsp=3B<BR>
<TABLE style=3D"BORDER-TOP: black 1px solid=3B FONT-WEIGHT: bold=3B FONT-FA=
MILY: 'Segoe UI'=2CTahoma=2Csan-serif">
<TBODY>
<TR>
<TD><A style=3D"FONT-SIZE: 9pt=3B COLOR: #0184cb=3B TEXT-DECORATION: none" =
href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood=
"><IMG style=3D"BORDER-TOP-STYLE: none=3B BORDER-RIGHT-STYLE: none=3B BORDE=
R-LEFT-STYLE: none=3B BORDER-BOTTOM-STYLE: none" alt=3D"i'm" src=3D"http://=
gfx1.hotmail.com/mail/w3/ltr/i_charity.gif"> EMAILING FOR THE GREATER GOOD<=
BR><SPAN style=3D"PADDING-RIGHT: 24px=3B PADDING-LEFT: 24px=3B FONT-SIZE: 8=
pt=3B PADDING-BOTTOM: 0px=3B COLOR: #3fb555=3B PADDING-TOP: 0px=3B TEXT-DEC=
ORATION: underline">Join me</SPAN></A></TD></TR></TBODY></TABLE><BR><BR>&gt=
=3B Date: Sat=2C 13 Dec 2008 10:16:53 +0100<BR>&gt=3B From: aland@deploying=
radius.com<BR>&gt=3B To: [email-masked]<BR>&gt=3B Subject: Issue wi=
th Guidelines document<BR>&gt=3B <BR>&gt=3B This might be a little late=2C =
but it may be worth adding one more note:<BR>&gt=3B <BR>&gt=3B ---<BR>&gt=
=3B Accounting-Response packets SHOULD contain only Proxy-State.<BR>&gt=3B =
<BR>&gt=3B State changes in the RADIUS client based on Accounting-Response<=
BR>&gt=3B packets are NOT RECOMMENDED. They do not fit within the tradition=
al<BR>&gt=3B RADIUS operational model. Despite the text in [RFC2866] Sectio=
n 5.13<BR>&gt=3B saying that "possibly" Vendor-Specific is permitted=2C suc=
h use is NOT<BR>&gt=3B RECOMMENDED.<BR>&gt=3B ---<BR>&gt=3B <BR>&gt=3B <BR>=
&gt=3B Is it too late for this? Do we have Area Director agreement that thi=
s<BR>&gt=3B is a good idea?<BR>&gt=3B <BR>&gt=3B The background is a growin=
g number of NAS equipment that I'm seeing<BR>&gt=3B which *does* look for a=
ttributes in an Accounting-Response. It's not<BR>&gt=3B clear what the NAS =
does with those attributes=2C but internal state<BR>&gt=3B changes are a lo=
gical conclusion.<BR>&gt=3B <BR>&gt=3B Alan DeKok.<BR>&gt=3B <BR>&gt=3B --<=
BR>&gt=3B to unsubscribe send a message to [email-masked] w=
ith<BR>&gt=3B the word 'unsubscribe' in a single line as the message text b=
ody.<BR>&gt=3B archive: &lt=3Bhttp://psg.com/lists/radiusext/&gt=3B<BR></bo=
dy>
</html>=

--_c84f5585-0f36-4c90-94e3-39e0d1535ddc_--

--
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, 13 Dec 2008 09:17:51 +0000
Date: Sat, 13 Dec 2008 10:16:53 +0100
From: Alan DeKok <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: Issue with Guidelines document

  This might be a little late, but it may be worth adding one more note:

---
    Accounting-Response packets SHOULD contain only Proxy-State.

  State changes in the RADIUS client based on Accounting-Response
packets are NOT RECOMMENDED.  They do not fit within the traditional
RADIUS operational model.  Despite the text in [RFC2866] Section 5.13
saying that "possibly" Vendor-Specific is permitted, such use is NOT
RECOMMENDED.
---

  Is it too late for this?  Do we have Area Director agreement that this
is a good idea?

  The background is a growing number of NAS equipment that I'm seeing
which *does* look for attributes in an Accounting-Response.  It's not
clear what the NAS does with those attributes, but internal state
changes are a logical conclusion.

  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: Fri, 12 Dec 2008 20:34:44 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Preliminary Meeting Minutes from IETF 73
Date: Fri, 12 Dec 2008 12:33:35 -0800

--_d70a75a7-397d-4744-bff9-a64b9a19ac7c_
Content-Type: multipart/alternative;
	boundary="_833c9354-ddfe-4bff-827b-8c55e5288d63_"

--_833c9354-ddfe-4bff-827b-8c55e5288d63_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Are enclosed.=20

 EMAILING FOR THE GREATER GOODJoin me=

--_833c9354-ddfe-4bff-827b-8c55e5288d63_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
Are enclosed. <BR><BR><BR><BR><BR>
<TABLE style=3D"BORDER-TOP: black 1px solid=3B FONT-WEIGHT: bold=3B FONT-FA=
MILY: 'Segoe UI'=2CTahoma=2Csan-serif">
<TBODY>
<TR>
<TD><A style=3D"FONT-SIZE: 9pt=3B COLOR: #0184cb=3B TEXT-DECORATION: none" =
href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood=
"><IMG style=3D"BORDER-TOP-STYLE: none=3B BORDER-RIGHT-STYLE: none=3B BORDE=
R-LEFT-STYLE: none=3B BORDER-BOTTOM-STYLE: none" alt=3D"i'm" src=3D"http://=
gfx1.hotmail.com/mail/w3/ltr/i_charity.gif"> EMAILING FOR THE GREATER GOOD<=
BR><SPAN style=3D"PADDING-RIGHT: 24px=3B PADDING-LEFT: 24px=3B FONT-SIZE: 8=
pt=3B PADDING-BOTTOM: 0px=3B COLOR: #3fb555=3B PADDING-TOP: 0px=3B TEXT-DEC=
ORATION: underline">Join me</SPAN></A></TD></TR></TBODY></TABLE></body>
</html>=

--_833c9354-ddfe-4bff-827b-8c55e5288d63_--

--_d70a75a7-397d-4744-bff9-a64b9a19ac7c_
Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ietf73-minutes.txt"

--_d70a75a7-397d-4744-bff9-a64b9a19ac7c_--

--
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, 11 Dec 2008 23:54:29 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: Summary of Review of draft-ietf-radext-extended-attributes-05.txt
Date: Thu, 11 Dec 2008 17:53:55 -0600

This is a multipart message in MIME format.

------=_NextPart_000_0023_01C95BB9.6F6B9A50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

On November 3, 2008, a call was issues for the review the status of open
issues on draft-ietf-radext-extended-attributes-05.txt:

http://ops.ietf.org/lists/radiusext/2008/msg00720.html

This generated the following responses:

http://ops.ietf.org/lists/radiusext/2008/msg00727.html

http://ops.ietf.org/lists/radiusext/2008/msg00737.html

http://ops.ietf.org/lists/radiusext/2008/msg00757.html

http://ops.ietf.org/lists/radiusext/2008/msg00755.html

Looking over these responses and subsequent postings, it would appear that
the following issues remain open:

Extended Attributes 

Issue Number

Status

Type

Description

Owner

Issue 225

Pending

Technical

Review <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20225> 

Alan DeKok <mailto:[email-masked]> 

Issue 251

Pending

Technical

Review <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20251> 

Bernard Aboba <mailto:[email-masked]> 

Issue 278

Pending

Technical

Comments
<http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20278> 

Alan DeKok <mailto:[email-masked]> 

Issue 279

Pending

Technical

Comments
<http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20279> 

Stefan Winter <mailto:[email-masked]> 

Issue 287

No Discussion

Technical

Comments
<http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20287> 

Greg Weber <mailto:[email-masked]> 

Issue 290

No Discussion

Technical

RFC <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20290>
4005bis Dependency

Bernard Aboba <mailto:[email-masked]> 

I have updated the Issues list to take into account the current status, as
well as to reflect

the mailing list discussion of these issues.  If any of the above issues are
now closed, or

if there is are any additional comments that the original posters wish to
make relating to

current status, please reply to this message. 

------=_NextPart_000_0023_01C95BB9.6F6B9A50
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:PMingLiU;
	panose-1:2 2 5 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"\@PMingLiU";
	panose-1:2 2 5 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText>On November 3, 2008, a call was issues for the =
review the
status of open issues on =
draft-ietf-radext-extended-attributes-05.txt:<o:p></o:p></p>

<p class=3DMsoPlainText><a
href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00720.html">http://op=
s.ietf.org/lists/radiusext/2008/msg00720.html</a><o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>This generated the following =
responses:<o:p></o:p></p>

<p class=3DMsoPlainText><a
href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00727.html">http://op=
s.ietf.org/lists/radiusext/2008/msg00727.html</a><o:p></o:p></p>

<p class=3DMsoPlainText><a
href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00737.html">http://op=
s.ietf.org/lists/radiusext/2008/msg00737.html</a><o:p></o:p></p>

<p class=3DMsoPlainText><a
href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00757.html">http://op=
s.ietf.org/lists/radiusext/2008/msg00757.html</a><o:p></o:p></p>

<p class=3DMsoPlainText><a
href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00755.html">http://op=
s.ietf.org/lists/radiusext/2008/msg00755.html</a><o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>Looking over these responses and subsequent =
postings, it
would appear that the following issues remain open:<o:p></o:p></p>

<p class=3DMsoPlainText><span =
style=3D'color:black'><o:p>&nbsp;</o:p></span></p>

<table class=3DMsoNormalTable border=3D1 cellpadding=3D0 width=3D761 =
style=3D'width:570.75pt'>
 <tr style=3D'height:25.5pt'>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:25.5pt'>
  <p class=3DMsoNormal><strong><span =
style=3D'font-size:13.5pt;font-family:"Calibri","sans-serif"'>Extended
  Attributes</span></strong> <o:p></o:p></p>
  <p><b><span style=3D'font-size:13.5pt'>Issue =
Number</span></b><o:p></o:p></p>
  </td>
  <td width=3D146 style=3D'width:109.5pt;padding:.75pt .75pt .75pt =
75pt;
  height:25.5pt'>
  <p class=3DMsoNormal><b><span =
style=3D'font-size:13.5pt'>Status</span></b><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D84 style=3D'width:63.0pt;padding:.75pt .75pt .75pt =
75pt;height:25.5pt'>
  <p class=3DMsoNormal><b><span =
style=3D'font-size:13.5pt'>Type</span></b><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D272 style=3D'width:204.0pt;padding:.75pt .75pt .75pt =
75pt;
  height:25.5pt'>
  <p class=3DMsoNormal><b><span =
style=3D'font-size:13.5pt'>Description</span></b><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D112 style=3D'width:84.0pt;padding:.75pt .75pt .75pt =
75pt;height:
  25.5pt'>
  <p class=3DMsoNormal><b><span =
style=3D'font-size:13.5pt'>Owner</span></b><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr style=3D'height:38.25pt'>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>Issue 225<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D146 style=3D'width:109.5pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>Pending<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D73 style=3D'width:54.75pt;padding:.75pt .75pt .75pt =
75pt;height:
  38.25pt'>
  <p class=3DMsoNormal>Technical<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D277 style=3D'width:207.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a
  =
href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%2022=
5">Review</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a href=3D"mailto:[email-masked]">Alan =
DeKok</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr style=3D'height:46.5pt'>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:46.5pt'>
  <p class=3DMsoNormal>Issue 251<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D146 style=3D'width:109.5pt;padding:.75pt .75pt .75pt =
75pt;
  height:46.5pt'>
  <p class=3DMsoNormal>Pending<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D84 style=3D'width:63.0pt;padding:.75pt .75pt .75pt =
75pt;height:46.5pt'>
  <p class=3DMsoNormal>Technical<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D272 style=3D'width:204.0pt;padding:.75pt .75pt .75pt =
75pt;
  height:46.5pt'>
  <p class=3DMsoNormal><a
  =
href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%2025=
1">Review</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D112 style=3D'width:84.0pt;padding:.75pt .75pt .75pt =
75pt;height:
  46.5pt'>
  <p class=3DMsoNormal><a =
href=3D"mailto:[email-masked]">Bernard Aboba</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr style=3D'height:38.25pt'>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>Issue 278<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D146 style=3D'width:109.5pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>Pending<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D73 style=3D'width:54.75pt;padding:.75pt .75pt .75pt =
75pt;height:
  38.25pt'>
  <p class=3DMsoNormal>Technical<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D277 style=3D'width:207.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a
  =
href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%2027=
8">Comments</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a href=3D"mailto:[email-masked]">Alan =
DeKok</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr style=3D'height:38.25pt'>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>Issue 279<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D146 style=3D'width:109.5pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>Pending<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D73 style=3D'width:54.75pt;padding:.75pt .75pt .75pt =
75pt;height:
  38.25pt'>
  <p class=3DMsoNormal>Technical<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D277 style=3D'width:207.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a
  =
href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%2027=
9">Comments</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a =
href=3D"mailto:[email-masked]">Stefan Winter</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr style=3D'height:38.25pt'>
  <td width=3D116 style=3D'width:87.0pt;padding:.75pt .75pt .75pt =
75pt;height:
  38.25pt'>
  <p class=3DMsoNormal>Issue 287<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D143 style=3D'width:107.25pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>No Discussion<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D80 style=3D'width:60.0pt;padding:.75pt .75pt .75pt =
75pt;height:38.25pt'>
  <p class=3DMsoNormal>Technical<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D276 style=3D'width:207.0pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a
  =
href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%2028=
7">Comments</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D111 style=3D'width:83.25pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a href=3D"mailto:[email-masked]">Greg =
Weber</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr style=3D'height:38.25pt'>
  <td width=3D116 style=3D'width:87.0pt;padding:.75pt .75pt .75pt =
75pt;height:
  38.25pt'>
  <p class=3DMsoNormal>Issue 290<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D143 style=3D'width:107.25pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>No Discussion<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D80 style=3D'width:60.0pt;padding:.75pt .75pt .75pt =
75pt;height:38.25pt'>
  <p class=3DMsoNormal>Technical<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D276 style=3D'width:207.0pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a
  =
href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%2029=
0">RFC
  4005bis Dependency</a><span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D111 style=3D'width:83.25pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a =
href=3D"mailto:[email-masked]">Bernard Aboba</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
 </tr>
</table>

<p class=3DMsoPlainText><span =
style=3D'color:black'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'>I have updated the =
Issues list
to take into account the current status, as well as to =
reflect<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'>the mailing list =
discussion of
these issues.&nbsp; If any of the above issues are now closed, =
or<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'>if there is are any =
additional
comments that the original posters wish to make relating =
to<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'>current status, =
please reply to
this message. <o:p></o:p></span></p>

</div>

</body>

</html>

------=_NextPart_000_0023_01C95BB9.6F6B9A50--

--
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, 11 Dec 2008 23:11:00 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: draft-aboba-radext-wlan-09 (fwd)
Date: Thu, 11 Dec 2008 15:10:04 -0800

--_cc2446ef-abde-4a07-a551-165783cd9a81_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Date: Wed=2C 10 Dec 2008 19:46:02 +0100 (MEZ)
From: Alfred H=C3=B6nes <[email-masked]>
To:  <[email-masked]>=2C  <[email-masked]>=2C  <paul_congdon@hp.=
com>=2C  <[email-masked]>
Cc:  <[email-masked]>
Subject: draft-aboba-radext-wlan-09

Hello=2C
I started to review the I-D authored by you=2C
        draft-aboba-radext-wlan-09=2C
but after stumbling over a rather general issue=2C
I stopped delving into other details.

This issue is a systematical violation of the RADIUS spec
and draft-ietf-radext-option-design-05:

As pointed out in Section 2.1.1 (et al.) of the latter=2C

   [RFC2865] defines the following data types:

|  text           1-253 octets containing UTF-8 encoded 10646 [RFC3629]
|                 characters.  Text of length zero (0) MUST NOT be sent=3B
|                 omit the entire attribute instead.
|  string         1-253 octets containing binary data (values 0 through
|                 255 decimal=2C inclusive).  Strings of length zero (0)
|                 MUST NOT be sent=3B omit the entire attribute instead.
   [...]

In persistent violation of these principles=2C
draft-aboba-radext-wlan-09 calls for zero-length String values
in many attributes=2C starting with Section 2.2:

   Length

|     >=3D2

   String

      [...]                                           As a result=2C an
|     EAP-Key-Name Attribute sent in an Access-Request MUST NOT contain
|     any data.  [...]

There's many more similar and closely related text in the draft
for other attributes.

IMO=2C this draft should be reworked to follow the existing specs and
the guidelines=2C and not request sending Null-String values attributes.

Another general recommendation:

In order to reduce the probability for clerical errors to happen
during the final processing after IANA assignments=2C I strongly
recommend using distinguished placeholders for the code points to
be assigned by IANA=2C e.g.=2C  "TBA1"=2C "TBA2"=2C ... or  "TBD1"=2C ...
(This is aligned with recommendations in BCP 26=2C RFC 5226.)

Kind regards=2C
  Alfred H=C3=B6nes.

--=20

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math.=2C Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0=2C Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

 EMAILING FOR THE GREATER GOOD
Join me=

--_cc2446ef-abde-4a07-a551-165783cd9a81_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<font style=3D"" face=3D"Courier New">Date: Wed=2C 10 Dec 2008 19:46:02 +01=
00 (MEZ)</font><font style=3D"" face=3D"Courier New"><br></font><font style=
=3D"" face=3D"Courier New">From: Alfred H=C3=B6nes &lt=[email-masked]&gt=3B=
</font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" fa=
ce=3D"Courier New">To:&nbsp=3B &lt=[email-masked]&gt=3B=2C&nbsp=3B =
&lt=[email-masked]&gt=3B=2C&nbsp=3B &lt=[email-masked]&gt=3B=
=2C&nbsp=3B &lt=[email-masked]&gt=3B</font><font style=3D"" face=3D"C=
ourier New"><br></font><font style=3D"" face=3D"Courier New">Cc:&nbsp=3B &l=
t=[email-masked]&gt=3B</font><font style=3D"" face=3D"Courier New"><br></=
font><font style=3D"" face=3D"Courier New">Subject: draft-aboba-radext-wlan=
-09</font><font style=3D"" face=3D"Courier New"><br></font><font style=3D""=
 face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New">Hell=
o=2C</font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"=
" face=3D"Courier New">I started to review the I-D authored by you=2C</font=
><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"=
Courier New">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B draft=
-aboba-radext-wlan-09=2C</font><font style=3D"" face=3D"Courier New"><br></=
font><font style=3D"" face=3D"Courier New">but after stumbling over a rathe=
r general issue=2C</font><font style=3D"" face=3D"Courier New"><br></font><=
font style=3D"" face=3D"Courier New">I stopped delving into other details.<=
/font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" fac=
e=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New">This iss=
ue is a systematical violation of the RADIUS spec</font><font style=3D"" fa=
ce=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New">and dra=
ft-ietf-radext-option-design-05:</font><font style=3D"" face=3D"Courier New=
"><br></font><font style=3D"" face=3D"Courier New"><br></font><font style=
=3D"" face=3D"Courier New">As pointed out in Section 2.1.1 (et al.) of the =
latter=2C</font><font style=3D"" face=3D"Courier New"><br></font><font styl=
e=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New=
">&nbsp=3B&nbsp=3B [RFC2865] defines the following data types:</font><font =
style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier=
 New"><br></font><font style=3D"" face=3D"Courier New">|&nbsp=3B text&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
 1-253 octets containing UTF-8 encoded 10646 [RFC3629]</font><font style=3D=
"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New">|&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B characters.&nbsp=3B Te=
xt of length zero (0) MUST NOT be sent=3B</font><font style=3D"" face=3D"Co=
urier New"><br></font><font style=3D"" face=3D"Courier New">|&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B omit the entire attribute instead.=
</font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" fa=
ce=3D"Courier New">|&nbsp=3B string&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B 1-253 octets containing binary data (values 0 thro=
ugh</font><font style=3D"" face=3D"Courier New"><br></font><font style=3D""=
 face=3D"Courier New">|&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B 255 decimal=2C inclusive).&nbsp=3B Strings of length zero (0)</font><fo=
nt style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Cour=
ier New">|&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B MUST NOT be=
 sent=3B omit the entire attribute instead.</font><font style=3D"" face=3D"=
Courier New"><br></font><font style=3D"" face=3D"Courier New">&nbsp=3B&nbsp=
=3B [...]</font><font style=3D"" face=3D"Courier New"><br></font><font styl=
e=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New=
"><br></font><font style=3D"" face=3D"Courier New">In persistent violation =
of these principles=2C</font><font style=3D"" face=3D"Courier New"><br></fo=
nt><font style=3D"" face=3D"Courier New">draft-aboba-radext-wlan-09 calls f=
or zero-length String values</font><font style=3D"" face=3D"Courier New"><b=
r></font><font style=3D"" face=3D"Courier New">in many attributes=2C starti=
ng with Section 2.2:</font><font style=3D"" face=3D"Courier New"><br></font=
><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"=
Courier New"><br></font><font style=3D"" face=3D"Courier New">&nbsp=3B&nbsp=
=3B Length</font><font style=3D"" face=3D"Courier New"><br></font><font sty=
le=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier Ne=
w">|&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B &gt=3B=3D2</font><font style=3D"" face=
=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New"><br></fon=
t><font style=3D"" face=3D"Courier New">&nbsp=3B&nbsp=3B String</font><font=
 style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courie=
r New"><br></font><font style=3D"" face=3D"Courier New"><br></font><font st=
yle=3D"" face=3D"Courier New">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B [...=
]&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B As a result=2C an</font><font style=
=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New"=
>|&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B EAP-Key-Name Attribute sent in an Access=
-Request MUST NOT contain</font><font style=3D"" face=3D"Courier New"><br><=
/font><font style=3D"" face=3D"Courier New">|&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B any data.&nbsp=3B [...]</font><font style=3D"" face=3D"Courier New"><br=
></font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" f=
ace=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New">There'=
s many more similar and closely related text in the draft</font><font style=
=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New"=
>for other attributes.</font><font style=3D"" face=3D"Courier New"><br></fo=
nt><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=
=3D"Courier New">IMO=2C this draft should be reworked to follow the existin=
g specs and</font><font style=3D"" face=3D"Courier New"><br></font><font st=
yle=3D"" face=3D"Courier New">the guidelines=2C and not request sending Nul=
l-String values attributes.</font><font style=3D"" face=3D"Courier New"><br=
></font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" f=
ace=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New">Anothe=
r general recommendation:</font><font style=3D"" face=3D"Courier New"><br><=
/font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" fac=
e=3D"Courier New">In order to reduce the probability for clerical errors to=
 happen</font><font style=3D"" face=3D"Courier New"><br></font><font style=
=3D"" face=3D"Courier New">during the final processing after IANA assignmen=
ts=2C I strongly</font><font style=3D"" face=3D"Courier New"><br></font><fo=
nt style=3D"" face=3D"Courier New">recommend using distinguished placeholde=
rs for the code points to</font><font style=3D"" face=3D"Courier New"><br><=
/font><font style=3D"" face=3D"Courier New">be assigned by IANA=2C e.g.=2C&=
nbsp=3B "TBA1"=2C "TBA2"=2C ... or&nbsp=3B "TBD1"=2C ...</font><font style=
=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New"=
>(This is aligned with recommendations in BCP 26=2C RFC 5226.)</font><font =
style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier=
 New"><br></font><font style=3D"" face=3D"Courier New"><br></font><font sty=
le=3D"" face=3D"Courier New">Kind regards=2C</font><font style=3D"" face=3D=
"Courier New"><br></font><font style=3D"" face=3D"Courier New">&nbsp=3B Alf=
red H=C3=B6nes.</font><font style=3D"" face=3D"Courier New"><br></font><fon=
t style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Couri=
er New">-- </font><font style=3D"" face=3D"Courier New"><br></font><font st=
yle=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier N=
ew">+------------------------+--------------------------------------------+=
</font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" fa=
ce=3D"Courier New">| TR-Sys Alfred Hoenes&nbsp=3B&nbsp=3B |&nbsp=3B Alfred =
Hoenes&nbsp=3B&nbsp=3B Dipl.-Math.=2C Dipl.-Phys.&nbsp=3B |</font><font sty=
le=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier Ne=
w">| Gerlinger Strasse 12&nbsp=3B&nbsp=3B |&nbsp=3B Phone: (+49)7156/9635-0=
=2C Fax: -18&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B |</font><font style=3D"" face=3D"Courier New"><br></font><font style=3D=
"" face=3D"Courier New">| D-71254&nbsp=3B Ditzingen&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B |&nbsp=3B E-Mail:&nbsp=3B [email-masked]&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |</font><font s=
tyle=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier =
New">+------------------------+--------------------------------------------=
+</font><br><br><br><br><br><table style=3D"border-top: 1px solid black=3B =
font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbod=
y><tr><td><a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLH=
M_GreaterGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B te=
xt-decoration: none=3B"><img style=3D"border-style: none=3B" src=3D"http://=
gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" alt=3D"i'm"> EMAILING FOR THE G=
REATER GOOD<br><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color:=
 rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B">Join me</span></a><=
/td></tr></tbody></table></body>
</html>=

--_cc2446ef-abde-4a07-a551-165783cd9a81_--

--
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, 11 Dec 2008 18:45:20 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-tcp-transport-01.txt 
Date: Thu, 11 Dec 2008 10:45:02 -0800 (PST)

--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 Over TCP
	Author(s)       : A. DeKok
	Filename        : draft-ietf-radext-tcp-transport-01.txt
	Pages           : 15
	Date            : 2008-12-11

The Remote Authentication Dial In User Server (RADIUS) Protocol has
traditionally used the User Datagram Protocol (UDP) as it's
underlying transport layer.  This document defines RADIUS over the
Transmission Control Protocol (TCP).

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-radext-tcp-transport-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--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: Thu, 11 Dec 2008 18:40:13 +0000
Date: Thu, 11 Dec 2008 19:39:17 +0100
From: Alan DeKok <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: draft-ietf-radext-tcp-transport-01.txt

  It has been brought to my attention that the the -00 version of the
IETF draft was taken from -00 of the individual draft.  However,
draft-dekok-radext-tcp-transport-01.txt was the last one published.

  To fix that, I have submitted draft-ietf-radext-tcp-transport-01.txt,
with contents taken verbatim from -01 of the individual draft.

  It's been a long day.  Sorry for the confusion.

  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, 11 Dec 2008 16:17:52 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Summary of WG review of "RADIUS over TCP" document
Date: Thu, 11 Dec 2008 08:16:42 -0800

--_cb9b69a7-dd5f-4897-b70c-3ca33b8058a6_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Based on the discussion at IETF 73=2C the following issues have been filed =
against the document:

Issue 291
    Pending
    Technical
   =20
=09
	UDP/TCP Translation
    Alan=20
	DeKok
=09
=09
    Issue 292
    Pending
    Technical
   =20
=09
	Applicability
    Alan=20
	DeKok
=09
=09
    Issue 293
    Pending
    Technical
   =20
=09
	Watchdog Timer
    Alan=20
	DeKok
=09
=09
    Issue 294
    No Discussion
    Technical
   =20
=09
	Document Status
    Bernard=20
	Aboba
=09
=09
    Issue 295
    Pending
    Technical
   =20
=09
	Head of Line Blocking
    Alan=20
	DeKok
Rather than waiting until WG last call=2C my suggestion would be to engage =
a Transport Directorate adviser to
assist with resolution of these issues.  I have sent an email to the tsv-di=
r mailing list to solicit a volunteer.=20

Subject: RE: Summary of WG review of "RADIUS over TCP" document
Date: Thu=2C 11 Dec 2008 10:54:18 +0100
From: [email-masked]
To: [email-masked]=3B [email-masked]

I=20
suggest that by the time the document reaches WGLC a specific request be se=
nt by=20
the chairs to the Transport Directorate for an early review.=20

=20
Dan
=20

 =20
 =20
  From: [email-masked]=20
  [mailto:[email-masked]] On Behalf Of Bernard=20
  Aboba
Sent: Thursday=2C December 11=2C 2008 8:03 AM
To:=20
  [email-masked]
Subject: Summary of WG review of "RADIUS over=20
  TCP" document

  A call for review of the "RADIUS over TCP" document was issued on=20
  November 4=2C 2008
(see http://ops.ietf.org/lists/radiusext/2008/msg00731.html)=20
  and concluded on=20
November 19=2C 2008.=20
=20
Based on the response to=20
  the call for review=2C the document is accepted as a=20
RADEXT WG work item=2C=20
  and should be resubmitted as=20
  draft-ietf-radext-tcp-transport-00.txt.
=20
Note that a number of=20
  transport issues were raised during the IETF 73 discussion
of this=20
  document=2C by Magnus Westerlund (Transport AD) and others.   It=20
  is
therefore recommended that this document receive an=20
  early review by the
Transport=20
Directorate. =20

--_cb9b69a7-dd5f-4897-b70c-3ca33b8058a6_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
Based on the discussion at IETF 73=2C the following issues have been filed =
against the document:<br><br><table id=3D"table66" width=3D"762" border=3D"=
1" height=3D"1"><tbody><tr><td width=3D"116" height=3D"62">Issue 291</td>
    <td width=3D"143" height=3D"34">Pending</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
291">
	UDP/TCP Translation</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:aland@deployingradius=
.com">Alan=20
	DeKok</a></td>
	</tr>
	<tr>
    <td width=3D"116" height=3D"62">Issue 292</td>
    <td width=3D"143" height=3D"34">Pending</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
292">
	Applicability</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:aland@deployingradius=
.com">Alan=20
	DeKok</a></td>
	</tr>
	<tr>
    <td width=3D"116" height=3D"62">Issue 293</td>
    <td width=3D"143" height=3D"34">Pending</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
293">
	Watchdog Timer</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:aland@deployingradius=
.com">Alan=20
	DeKok</a></td>
	</tr>
	<tr>
    <td width=3D"116" height=3D"62">Issue 294</td>
    <td width=3D"143" height=3D"34">No Discussion</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
294">
	Document Status</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:bernard_aboba@hotmail=
.com">Bernard=20
	Aboba</a></td>
	</tr>
	<tr>
    <td width=3D"116" height=3D"62">Issue 295</td>
    <td width=3D"143" height=3D"34">Pending</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
295">
	Head of Line Blocking</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:aland@deployingradius=
.com">Alan=20
	DeKok</a></td></tr></tbody></table><br>Rather than waiting until WG last c=
all=2C my suggestion would be to engage a Transport Directorate adviser to<=
br>assist with resolution of these issues.&nbsp=3B I have sent an email to =
the tsv-dir mailing list to solicit a volunteer. <br><br><hr id=3D"stopSpel=
ling">Subject: RE: Summary of WG review of "RADIUS over TCP" document<br>Da=
te: Thu=2C 11 Dec 2008 10:54:18 +0100<br>From: [email-masked]<br>To: be=
[email-masked]=3B [email-masked]<br><br>

<style>
.ExternalClass .EC_hmmessage P
{padding-right:0px=3Bpadding-left:0px=3Bpadding-bottom:0px=3Bpadding-top:0p=
x=3B}
.ExternalClass BODY.EC_hmmessage
{font-size:10pt=3Bfont-family:Verdana=3B}
</style>

<div><span class=3D"EC_356165309-11122008"><font color=3D"#0000ff" face=3D"=
Arial"><strong><em>I=20
suggest that by the time the document reaches WGLC a specific request be se=
nt by=20
the chairs to the Transport Directorate for an early review.=20
</em></strong></font></span></div>
<div><span class=3D"EC_356165309-11122008"><strong><em><font color=3D"#0000=
ff" face=3D"Arial"></font></em></strong></span>&nbsp=3B</div>
<div><span class=3D"EC_356165309-11122008"><strong><em><font color=3D"#0000=
ff" face=3D"Arial">Dan</font></em></strong></span></div>
<div><span class=3D"EC_356165309-11122008"><strong><em><font color=3D"#0000=
ff" face=3D"Arial"></font></em></strong></span>&nbsp=3B</div><br>
<blockquote style=3D"border-left: 2px solid rgb(0=2C 0=2C 255)=3B padding-l=
eft: 5px=3B margin-left: 5px=3B margin-right: 0px=3B">
  <div class=3D"EC_OutlookMessageHeader" dir=3D"ltr" align=3D"left" lang=3D=
"en-us">
  <hr>
  <font face=3D"Tahoma"><b>From:</b> [email-masked]=20
  [mailto:[email-masked]] <b>On Behalf Of </b>Bernard=20
  Aboba<br><b>Sent:</b> Thursday=2C December 11=2C 2008 8:03 AM<br><b>To:</=
b>=20
  [email-masked]<br><b>Subject:</b> Summary of WG review of "RADIUS=
 over=20
  TCP" document<br></font><br></div>
  <div></div>A call for review of the "RADIUS over TCP" document was issued=
 on=20
  November 4=2C 2008<br>(see <a href=3D"http://ops.ietf.org/lists/radiusext=
/2008/msg00731.html">http://ops.ietf.org/lists/radiusext/2008/msg00731.html=
</a>)=20
  and concluded on <br>November 19=2C 2008. <br>&nbsp=3B<br>Based on the re=
sponse to=20
  the call for review=2C the document is accepted as a <br>RADEXT WG work i=
tem=2C=20
  and should be resubmitted as=20
  draft-ietf-radext-tcp-transport-00.txt.<br>&nbsp=3B<br>Note that a number=
 of=20
  transport issues were raised during the IETF 73 discussion<br>of this=20
  document=2C by Magnus Westerlund (Transport AD) and others.&nbsp=3B&nbsp=
=3B It=20
  is<br>therefore recommended that&nbsp=3Bthis document receive an=20
  early&nbsp=3Breview by the<br>Transport=20
Directorate.&nbsp=3B&nbsp=3B<br></blockquote></body>
</html>=

--_cb9b69a7-dd5f-4897-b70c-3ca33b8058a6_--

--
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, 11 Dec 2008 13:15:49 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-tcp-transport-00.txt 
Date: Thu, 11 Dec 2008 05:15:02 -0800 (PST)

--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 Over TCP
	Author(s)       : A. DeKok
	Filename        : draft-ietf-radext-tcp-transport-00.txt
	Pages           : 14
	Date            : 2008-12-11

The Remote Authentication Dial In User Server (RADIUS) Protocol has
traditionally used the User Datagram Protocol (UDP) as it's
underlying transport layer.  This document defines RADIUS over the
Transport Control Protocol (TCP).

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-radext-tcp-transport-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--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: Thu, 11 Dec 2008 10:47:10 +0000
Date: Thu, 11 Dec 2008 11:46:38 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Summary of WG review of "RADIUS over TCP" document

Bernard Aboba wrote:
> A call for review of the "RADIUS over TCP" document was issued on
> November 4, 2008
> (see http://ops.ietf.org/lists/radiusext/2008/msg00731.html) and
> concluded on
> November 19, 2008.
>  
> Based on the response to the call for review, the document is accepted as a
> RADEXT WG work item, and should be resubmitted as
> draft-ietf-radext-tcp-transport-00.txt.

  I have submitted the document with the following changes from
draft-dekok-tcp-transport-00.txt:

 - IPR statements updated
 - name in page footers corrected
 - updated reference from status-server-00 to status-server-02
 - Submission && expiry dates changed

  No changes have been made to the body of the text.  WG reviews will be
integrated into a -01 version of the document.

  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, 11 Dec 2008 09:55:18 +0000
Content-class: urn:content-classes:message
Subject: RE: Summary of WG review of "RADIUS over TCP" document
Date: Thu, 11 Dec 2008 10:54:18 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C95B76.6F5306F3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I suggest that by the time the document reaches WGLC a specific request
be sent by the chairs to the Transport Directorate for an early review.=20
=20
Dan
=20

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard Aboba
	Sent: Thursday, December 11, 2008 8:03 AM
	To: [email-masked]
	Subject: Summary of WG review of "RADIUS over TCP" document
=09
=09
	A call for review of the "RADIUS over TCP" document was issued
on November 4, 2008
	(see http://ops.ietf.org/lists/radiusext/2008/msg00731.html) and
concluded on=20
	November 19, 2008.=20
	=20
	Based on the response to the call for review, the document is
accepted as a=20
	RADEXT WG work item, and should be resubmitted as
draft-ietf-radext-tcp-transport-00.txt.
	=20
	Note that a number of transport issues were raised during the
IETF 73 discussion
	of this document, by Magnus Westerlund (Transport AD) and
others.   It is
	therefore recommended that this document receive an early review
by the
	Transport Directorate. =20
=09

------_=_NextPart_001_01C95B76.6F5306F3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>.hmmessage P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY.hmmessage {
	FONT-SIZE: 10pt; FONT-FAMILY: Verdana
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.3429" name=3DGENERATOR></HEAD>
<BODY class=3Dhmmessage>
<DIV><SPAN class=3D356165309-11122008><FONT face=3DArial =
color=3D#0000ff><STRONG><EM>I=20
suggest that by the time the document reaches WGLC a specific request be =
sent by=20
the chairs to the Transport Directorate for an early review.=20
</EM></STRONG></FONT></SPAN></DIV>
<DIV><SPAN class=3D356165309-11122008><STRONG><EM><FONT face=3DArial=20
color=3D#0000ff></FONT></EM></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D356165309-11122008><STRONG><EM><FONT face=3DArial=20
color=3D#0000ff>Dan</FONT></EM></STRONG></SPAN></DIV>
<DIV><SPAN class=3D356165309-11122008><STRONG><EM><FONT face=3DArial=20
color=3D#0000ff></FONT></EM></STRONG></SPAN>&nbsp;</DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Bernard=20
  Aboba<BR><B>Sent:</B> Thursday, December 11, 2008 8:03 =
AM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Summary of WG review of =
"RADIUS over=20
  TCP" document<BR></FONT><BR></DIV>
  <DIV></DIV>A call for review of the "RADIUS over TCP" document was =
issued on=20
  November 4, 2008<BR>(see <A=20
  =
href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00731.html">http://op=
s.ietf.org/lists/radiusext/2008/msg00731.html</A>)=20
  and concluded on <BR>November 19, 2008. <BR>&nbsp;<BR>Based on the =
response to=20
  the call for review, the document is accepted as a <BR>RADEXT WG work =
item,=20
  and should be resubmitted as=20
  draft-ietf-radext-tcp-transport-00.txt.<BR>&nbsp;<BR>Note that a =
number of=20
  transport issues were raised during the IETF 73 discussion<BR>of this=20
  document, by Magnus Westerlund (Transport AD) and others.&nbsp;&nbsp; =
It=20
  is<BR>therefore recommended that&nbsp;this document receive an=20
  early&nbsp;review by the<BR>Transport=20
Directorate.&nbsp;&nbsp;<BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C95B76.6F5306F3--

--
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, 11 Dec 2008 07:09:09 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'radext mailing list'" <[email-masked]>
Subject: RE: TCP transport draft
Date: Wed, 10 Dec 2008 23:08:20 -0800

Comments below. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alan DeKok
Sent: Wednesday, November 19, 2008 10:33 AM
To: 'radext mailing list'
Subject: TCP transport draft

  The WG meeting yesterday raised a number of potential issues with the
draft.

  1) The document doesn't discuss UDP -> TCP and TCP -> UDP issues when
proxying packets.  This needs to be updated.  

[BA] There are several situations in which the law of "conservation of
packets"
could be violated on an end-to-end basis (e.g. where more packets could
enter
the system than could leave it on a short-term basis): 

a. Where TCP is used between proxies, it is possible that the bandwidth
consumed by incoming UDP packets destined to a given realm could exceed the
sending 
rate of a single TCP connection to that realm, based on the window size/RTT
estimate. 

b.  It is possible for the incoming rate of TCP packets destined to a given
realm to exceed the UDP throughput achievable using the transport guidelines
established
in RFC 5080.  This could happen, for example, where the TCP window between
proxies
has opened, but packet loss is being experienced on the UDP leg, so that the
effective congestion window on the UDP side is 1. 

Intrinsically, proxy systems operate with multiple control loops instead of
one end-to-end
loop, and so are less stable.  This is true even for TCP-TCP proxies.  As
discussed in 
RFC 3539, the only way to achieve stability equivalent to a single TCP
connection is to 
mimic the end-to-end behavior of a single TCP connection.  This typically 
is not achievable with an application-layer RADIUS implementation regardless
of transport. 

There are also head-of-line blocking issues when there are sudden spikes of
traffic.

[BA] HoL blocking can occur whenever there is packet loss on a TCP
connection.
This need not necessarily correspond to sudden RADSEC traffic spikes, but
could
be due to background traffic. 

  2) The document needs more review from the transport area for TCP issues.

[BA] I will send a message to the tsv-dir requesting assignment of a
Transport
Advisor. 

  3) TCP && RadSec.

	Q: Does the WG want to *forbid* "raw" TCP transport?

  i.e. TCP MUST be used with RadSec.  TCP MUST NOT be used to transport
bare RADIUS.

[BA] My suggestion would be to coalesce sections 1.1 and 1.2 into
an Applicability section in which the intent of the document
(to address transport relating to RADSEC) could be described, along with the
RECOMMENDED and NOT RECOMMENDED uses. I'm not sure that a MUST NOT is
necessarily
required; perhaps a NOT RECOMMENDED might be sufficient, along with a
reference
to the caveats described in Section 2.4 of RFC 2865. 

Another way to make it clear that "raw TCP" is not recommended for prime
time
would be to classify the document as Experimental.  If the document is
largely 
focused on use with RADSEC, this would be consistent with RADSEC's
Experimental
status.

  4) Use of Status-Server as the RFC3539 watchdog timer packet.  The
issues surrounding Status-Server means that 1 RADIUS ID will have to be
dedicated to Status-Server.  This means that there can only be 255
packets "in flight" on one TCP connection.

	Q: Does the WG want to stay with Status-Server, or define a new
	   packet code?

[BA] My advice would be to describe the Status-Server ID issues in
that document, and talk about some of the Transport implications in
this one.  Once we've understood the implications and alternatives,
we can explore whether a new packet code is warranted.  However, the
current charter of the Status-Server document is to describe the
existing protocol rather than attempting to fix/radically improve it. 

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

--
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, 11 Dec 2008 06:20:05 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Meeting minutes?
Date: Wed, 10 Dec 2008 22:19:40 -0800

--_bd1ca3bd-a40e-4006-ab40-dcc054b40bc1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If you took minutes of the IETF 73 RADEXT WG meeting=2C please send them to=
 me and David ASAP. =

--_bd1ca3bd-a40e-4006-ab40-dcc054b40bc1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
If you took minutes of the IETF 73 RADEXT WG meeting=2C please send them to=
 me and David ASAP. </body>
</html>=

--_bd1ca3bd-a40e-4006-ab40-dcc054b40bc1_--

--
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, 11 Dec 2008 06:02:59 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Summary of WG review of "RADIUS over TCP" document
Date: Wed, 10 Dec 2008 22:02:34 -0800

--_0b3d4815-f3cd-4be3-afde-50906852ae16_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A call for review of the "RADIUS over TCP" document was issued on November =
4=2C 2008
(see http://ops.ietf.org/lists/radiusext/2008/msg00731.html) and concluded =
on=20
November 19=2C 2008.=20
=20
Based on the response to the call for review=2C the document is accepted as=
 a=20
RADEXT WG work item=2C and should be resubmitted as draft-ietf-radext-tcp-t=
ransport-00.txt.
=20
Note that a number of transport issues were raised during the IETF 73 discu=
ssion
of this document=2C by Magnus Westerlund (Transport AD) and others.   It is
therefore recommended that this document receive an early review by the
Transport Directorate.  =

--_0b3d4815-f3cd-4be3-afde-50906852ae16_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
A call for review of the "RADIUS over TCP" document was issued on November =
4=2C 2008<BR>
(see <A href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00731.html">htt=
p://ops.ietf.org/lists/radiusext/2008/msg00731.html</A>) and concluded on <=
BR>
November 19=2C 2008. <BR>
&nbsp=3B<BR>
Based on the response to the call for review=2C the document is accepted as=
 a <BR>
RADEXT WG work item=2C and should be resubmitted as draft-ietf-radext-tcp-t=
ransport-00.txt.<BR>
&nbsp=3B<BR>
Note that a number of transport issues were raised during the IETF 73 discu=
ssion<BR>
of this document=2C by Magnus Westerlund (Transport AD) and others.&nbsp=3B=
&nbsp=3B It is<BR>
therefore recommended that&nbsp=3Bthis document receive an early&nbsp=3Brev=
iew by the<BR>
Transport Directorate.&nbsp=3B&nbsp=3B<BR></body>
</html>=

--_0b3d4815-f3cd-4be3-afde-50906852ae16_--

--
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, 11 Dec 2008 05:58:40 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Summary of RADEXT WG last call on the RADSEC document
Date: Wed, 10 Dec 2008 21:58:23 -0800

--_a7f0b0a4-86bf-432f-bdf7-5e84317c8e84_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RADEXT WG last call on the RADSEC document was announced on October 27=2C 2=
008
(see http://ops.ietf.org/lists/radiusext/2008/msg00691.html)=2C and conclud=
ed on November 25=2C 2008.=20
=20
The following issues were raised during WG last call:
=20

Issue 281
Pending
Technical
SRV vs. A/AAAA RRs
Stefan Winter

Issue 282
No Discussion
Technical
Comments
Joe Salowey
=20
As noted by Dan Romascanu in his posting to the list (see http://ops.ietf.o=
rg/lists/radiusext/2008/msg00793.html)=2C
the document needs to address issues of backward compatibility and rollback=
 attacks. =

--_a7f0b0a4-86bf-432f-bdf7-5e84317c8e84_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
RADEXT WG last call on the RADSEC document was announced on October 27=2C 2=
008<BR>
(see <A href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00691.html">htt=
p://ops.ietf.org/lists/radiusext/2008/msg00691.html</A>)=2C and concluded o=
n November 25=2C 2008. <BR>
&nbsp=3B<BR>
The following issues were raised during WG last call:<BR>
&nbsp=3B<BR>

<TABLE id=3Dtable57 height=3D1 width=3D762 border=3D1>
<TBODY>
<TR>
<TD width=3D116 height=3D62>Issue 281</TD>
<TD width=3D143 height=3D34>Pending</TD>
<TD width=3D80 height=3D62>Technical</TD>
<TD width=3D276 height=3D62><A href=3D"http://www.drizzle.com/~aboba/RADEXT=
/radissues2.html#Issue 281"><FONT color=3D#0066cc>SRV vs. A/AAAA RRs</FONT>=
</A></TD>
<TD width=3D111 height=3D51><A href=3D"mailto:[email-masked]"><FO=
NT color=3D#0066cc>Stefan Winter</FONT></A></TD></TR>
<TR>
<TD width=3D116 height=3D62>Issue 282</TD>
<TD width=3D143 height=3D34>No Discussion</TD>
<TD width=3D80 height=3D62>Technical</TD>
<TD width=3D276 height=3D62><A href=3D"http://www.drizzle.com/~aboba/RADEXT=
/radissues2.html#Issue 282"><FONT color=3D#0066cc>Comments</FONT></A></TD>
<TD width=3D111 height=3D51><A href=3D"mailto:[email-masked]"><FONT col=
or=3D#0066cc>Joe Salowey</FONT></A></TD></TR></TBODY></TABLE><BR>
&nbsp=3B<BR>
As&nbsp=3Bnoted by Dan Romascanu in his posting to the list (see <A href=3D=
"http://ops.ietf.org/lists/radiusext/2008/msg00793.html">http://ops.ietf.or=
g/lists/radiusext/2008/msg00793.html</A>)=2C<BR>
the document needs to address issues of backward compatibility and rollback=
 attacks. <BR></body>
</html>=

--_a7f0b0a4-86bf-432f-bdf7-5e84317c8e84_--

--
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, 11 Dec 2008 05:53:31 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Summary of RADEXT WG Last Call on Status-Server Document
Date: Wed, 10 Dec 2008 21:53:11 -0800

--_41427d71-001a-4415-99e7-eb1eaf320830_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RADEXT WG last call on the Status-Server document was announced on November=
 3=2C 2008
(see http://ops.ietf.org/lists/radiusext/2008/msg00721.html) and concluded =
on November 25=2C 2008.=20
=20
The following issues were raised during WG last call:
=20

Issue 283
No Discussion
Technical
Status-Server Comments
Greg Weber

Issue 285
Pending
Technical
Question
Alan DeKok

Issue 288
Pending
Technical
Review
Stig Venaas

Issue 289
No Discussion
Editorial
Editorial Comments
Stig Venaas
Overall=2C as was discussed during IETF 73=2C it should be understood that =
the goal of this document is to document the
existing Status-Server protocol (which was first developed by Ascend Commun=
ications in the mid-1990s).  Therefore
inclusion of non-implemented functionality in this document is out of scope=
.=20

 EMAILING FOR THE GREATER GOODJoin me=

--_41427d71-001a-4415-99e7-eb1eaf320830_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
RADEXT WG last call on the Status-Server document was announced on November=
 3=2C 2008<BR>
(see <A href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00721.html">htt=
p://ops.ietf.org/lists/radiusext/2008/msg00721.html</A>) and concluded on N=
ovember 25=2C 2008. <BR>
&nbsp=3B<BR>
The following issues were raised during WG last call:<BR>
&nbsp=3B<BR>

<TABLE id=3Dtable58 height=3D1 width=3D762 border=3D1>
<TBODY>
<TR>
<TD width=3D116 height=3D62>Issue 283</TD>
<TD width=3D143 height=3D34>No Discussion</TD>
<TD width=3D80 height=3D62>Technical</TD>
<TD width=3D276 height=3D62><A href=3D"http://www.drizzle.com/~aboba/RADEXT=
/radissues2.html#Issue 283"><FONT color=3D#0066cc>Status-Server Comments</F=
ONT></A></TD>
<TD width=3D111 height=3D51><A href=3D"mailto:[email-masked]"><FONT colo=
r=3D#0066cc>Greg Weber</FONT></A></TD></TR>
<TR>
<TD width=3D116 height=3D62>Issue 285</TD>
<TD width=3D143 height=3D34>Pending</TD>
<TD width=3D80 height=3D62>Technical</TD>
<TD width=3D276 height=3D62><A href=3D"http://www.drizzle.com/~aboba/RADEXT=
/radissues2.html#Issue 285"><FONT color=3D#0066cc>Question</FONT></A></TD>
<TD width=3D111 height=3D51><A href=3D"mailto:[email-masked]"><F=
ONT color=3D#0066cc>Alan DeKok</FONT></A></TD></TR>
<TR>
<TD width=3D116 height=3D62>Issue 288</TD>
<TD width=3D143 height=3D34>Pending</TD>
<TD width=3D80 height=3D62>Technical</TD>
<TD width=3D276 height=3D62><A href=3D"http://www.drizzle.com/~aboba/RADEXT=
/radissues2.html#Issue 288"><FONT color=3D#0066cc>Review</FONT></A></TD>
<TD width=3D111 height=3D51><A href=3D"mailto:[email-masked]"><FONT=
 color=3D#0066cc>Stig Venaas</FONT></A></TD></TR>
<TR>
<TD width=3D116 height=3D62>Issue 289</TD>
<TD width=3D143 height=3D34>No Discussion</TD>
<TD width=3D80 height=3D62>Editorial</TD>
<TD width=3D276 height=3D62><A href=3D"http://www.drizzle.com/~aboba/RADEXT=
/radissues2.html#Issue 289"><FONT color=3D#0066cc>Editorial Comments</FONT>=
</A></TD>
<TD width=3D111 height=3D51><A href=3D"mailto:[email-masked]"><FONT=
 color=3D#0066cc>Stig Venaas</FONT></A></TD></TR></TBODY></TABLE><BR>
<BR>Overall=2C as&nbsp=3Bwas discussed during IETF 73=2C it should be under=
stood that the goal of this document is to document the<BR>
existing Status-Server protocol (which was first developed by Ascend Commun=
ications in the mid-1990s).&nbsp=3B Therefore<BR>
inclusion of non-implemented functionality in this document is out of scope=
. <BR><BR><BR><BR><BR>
<TABLE style=3D"BORDER-TOP: black 1px solid=3B FONT-WEIGHT: bold=3B FONT-FA=
MILY: 'Segoe UI'=2CTahoma=2Csan-serif">
<TBODY>
<TR>
<TD><A style=3D"FONT-SIZE: 9pt=3B COLOR: #0184cb=3B TEXT-DECORATION: none" =
href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood=
"><IMG style=3D"BORDER-TOP-STYLE: none=3B BORDER-RIGHT-STYLE: none=3B BORDE=
R-LEFT-STYLE: none=3B BORDER-BOTTOM-STYLE: none" alt=3D"i'm" src=3D"http://=
gfx1.hotmail.com/mail/w3/ltr/i_charity.gif"> EMAILING FOR THE GREATER GOOD<=
BR><SPAN style=3D"PADDING-RIGHT: 24px=3B PADDING-LEFT: 24px=3B FONT-SIZE: 8=
pt=3B PADDING-BOTTOM: 0px=3B COLOR: #3fb555=3B PADDING-TOP: 0px=3B TEXT-DEC=
ORATION: underline">Join me</SPAN></A></TD></TR></TBODY></TABLE></body>
</html>=

--_41427d71-001a-4415-99e7-eb1eaf320830_--

--
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, 11 Dec 2008 05:49:39 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Issue 290: RFC 4005bis Dependency
Date: Wed, 10 Dec 2008 21:48:35 -0800

--_01e7b896-ca72-4c09-84e8-be8fd481b1ae_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Issue 290: 4005bis DependencySubmitter name: Bernard Aboba Submitter email =
address: [email-masked] Date first submitted:  December 10=2C 20=
08Reference:   http://www.watersprings.org/pub/id/draft-mitton-diameter-rad=
ius-vsas-01.txtDocument: EXTATTR Comment type: T Priority: S  Section:  7Ra=
tionale/Explanation of issue:
=20
Section 7 of this document contains the following text on Diameter Consider=
ations:   Since the Extended Attributes are encoded as Vendor-Specific RADI=
US
   Attributes (see [IANA])=2C no special handling is required by Diameter
   [RFC3588] entities=3B see [RFC4005] for details on the Diameter
   treatment of RADIUS VSAs.
Unfortunately=2C this text is wrong.  RFC 4005 does not in fact describe ho=
w to translate RADIUS Extended Attributes to Diameter.=20
RFC 4005 Section 9 defines the RADIUS/Diameter gateway.   Unfortunately=2C =
Section 9.6 assumes that RADIUS VSAs follow the format recommended in RFC 2=
865=2C Section 5.26.  As noted in Section 9.6.2:   The Diameter AVP will co=
nsist of the following fields:

      Diameter Flags: V=3D1=2C M=3D0=2C P=3D0
      Diameter Vendor code =3D RADIUS VSA Vendor code
      Diameter AVP code =3D RADIUS VSA Vendor type code
      Diameter AVP length =3D length of AVP (header + data)
      Diameter Data =3D RADIUS VSA vendor data

   Note that the VSAs are considered optional by RADIUS rules=2C and this
   specification does not set the Mandatory flag.  If an implementor
   desires a VSA be made mandatory because it represents a required
   service policy=2C the RADIUS gateway should have a process to set the
   bit on the Diameter side.

   If the RADIUS receiving code knows of vendor specific field
   interpretations for the specific vendor=2C it may employ them to parse
   an extended AVP code or data length.  Otherwise the recommended
   standard fields will be used.

   Nested Multiple vendor data fields MUST be expanded into multiple
   Diameter AVPs.
Since the RADIUS Extended Attribute format does not conform to the recommen=
ded RADIUS VSA format in RFC 2865=2C RFC 4005 Section 9.6.2 does not apply.=
  As a result=2C an alternative mechanism for translating RADIUS Extended A=
ttributes to Diameter needs to be defined (RFC 4005bis).  The RADIUS Extend=
ed Attributes document has a normative dependency on this document (which p=
robably should be handled in the DIME WG). =

--_01e7b896-ca72-4c09-84e8-be8fd481b1ae_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<STRONG><A name=3D"Issue 290"></A>Issue 290: 4005bis Dependency</STRONG><BR=
>Submitter name: Bernard Aboba <BR>Submitter email address: bernard_aboba@h=
otmail.com <BR>Date first submitted:&nbsp=3B December 10=2C 2008<BR>Referen=
ce: &nbsp=3B http://www.watersprings.org/pub/id/draft-mitton-diameter-radiu=
s-vsas-01.txt<BR>Document: EXTATTR <BR>Comment type: T <BR>Priority: S&nbsp=
=3B <BR>Section:&nbsp=3B&nbsp=3B7<BR>Rationale/Explanation of issue:<BR>
&nbsp=3B<BR>
Section 7 of this document contains the following text on Diameter Consider=
ations:<BR><PRE class=3Dnewpage>   Since the Extended Attributes are encode=
d as Vendor-Specific RADIUS
   Attributes (see [<A title=3D'"RADIUS TYPES"' href=3D"http://tools.ietf.o=
rg/html/draft-ietf-radext-extended-attributes-05#ref-IANA"><FONT color=3D#0=
066cc>IANA</FONT></A>])=2C no special handling is required by Diameter
   [<A title=3D'"Diameter Base Protocol"' href=3D"http://tools.ietf.org/htm=
l/rfc3588"><FONT color=3D#0066cc>RFC3588</FONT></A>] entities=3B see [<A ti=
tle=3D'"Diameter Network Access Server Application"' href=3D"http://tools.i=
etf.org/html/rfc4005"><FONT color=3D#0066cc>RFC4005</FONT></A>] for details=
 on the Diameter
   treatment of RADIUS VSAs.</PRE>
Unfortunately=2C this text is wrong.&nbsp=3B RFC 4005 does not in fact desc=
ribe how to translate RADIUS Extended Attributes to Diameter. <BR>
<A href=3D"http://tools.ietf.org/html/rfc4005"><FONT color=3D#0066cc>RFC 40=
05</FONT></A> Section 9 defines the RADIUS/Diameter gateway.&nbsp=3B&nbsp=
=3B Unfortunately=2C Section 9.6 assumes that RADIUS VSAs follow the format=
 recommended in RFC 2865=2C Section 5.26.&nbsp=3B As noted in Section 9.6.2=
:<BR><PRE class=3Dnewpage>   The Diameter AVP will consist of the following=
 fields:

      Diameter Flags: V=3D1=2C M=3D0=2C P=3D0
      Diameter Vendor code =3D RADIUS VSA Vendor code
      Diameter AVP code =3D RADIUS VSA Vendor type code
      Diameter AVP length =3D length of AVP (header + data)
      Diameter Data =3D RADIUS VSA vendor data

   Note that the VSAs are considered optional by RADIUS rules=2C and this
   specification does not set the Mandatory flag.  If an implementor
   desires a VSA be made mandatory because it represents a required
   service policy=2C the RADIUS gateway should have a process to set the
   bit on the Diameter side.

   If the RADIUS receiving code knows of vendor specific field
   interpretations for the specific vendor=2C it may employ them to parse
   an extended AVP code or data length.  Otherwise the recommended
   standard fields will be used.

   Nested Multiple vendor data fields MUST be expanded into multiple
   Diameter AVPs.</PRE>
<P class=3Dstyle7>Since the RADIUS Extended Attribute format does not confo=
rm to the recommended RADIUS VSA format in RFC 2865=2C RFC 4005 Section 9.6=
.2 does not apply.&nbsp=3B As a result=2C an alternative mechanism for tran=
slating RADIUS Extended Attributes to Diameter needs to be defined (RFC 400=
5bis).&nbsp=3B The RADIUS Extended Attributes document has a normative depe=
ndency on this document (which probably should be handled in the DIME WG). =
</P></body>
</html>=

--_01e7b896-ca72-4c09-84e8-be8fd481b1ae_--

--
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, 08 Dec 2008 16:01:45 +0000
Date: Mon, 08 Dec 2008 17:01:02 +0100
From: Stig Venaas <[email-masked]>
To: Stefan Winter <[email-masked]>
Cc: "David B. Nelson" <[email-masked]>, [email-masked]
Subject: Re: RADEXT WG Last Call on Status-Server Document

Stefan Winter wrote:
> Hi,
> 
>>>   Maybe it's best to say that authentication ports respond with
>>> Access-Accept, and accounting ports respond with Accounting-Response.
>>> Anything else is NOT RECOMMENDED.
>>>     
>> That would certainly cover all bases.
>>   
> 
> That text sounds good to me.

I am also OK with that.

It would have been easier to implement this correctly if there were
something distinguishing the requests (other than they being received
at auth or acc ports).

Stig

> Stefan

--
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, 08 Dec 2008 15:14:22 +0000
Date: Mon, 08 Dec 2008 16:14:02 +0100
From: Stefan Winter <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: [email-masked]
Subject: Re: RADEXT WG Last Call on Status-Server Document

Hi,

>>   Maybe it's best to say that authentication ports respond with
>> Access-Accept, and accounting ports respond with Accounting-Response.
>> Anything else is NOT RECOMMENDED.
>>     
>
> That would certainly cover all bases.
>   

That text sounds good to me.

Stefan

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

Tel: +352 424409 1
Fax: +352 422473

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

Delivery-date: Mon, 08 Dec 2008 15:02:06 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: RADEXT WG Last Call on Status-Server Document
Date: Mon, 8 Dec 2008 10:01:17 -0500
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

> > IIRC, the consensus of the room at the RADEXT WG meeting at
> > IETF-73 was that this was a bad idea.
 
> OK, if the consensus is that it's a bad idea, that can be
> removed from the draft.

As usual, tentative consensus from an IETF meeting needs to be confirmed on
the list.  This would seem to be a good opportunity to do so.

Consensus Call:  Should we document the following as "recognized" RADIUS
behavior?

   Some server implementations accept both Access-Request and
   Accounting-Request packets on the same port, and do not distinguish
   between "authentication only" ports, and "accounting only" ports.
   Those implementations SHOULD reply to Status-Server packets with an
   Access-Accept packet.

> > Where do we draw the line?
> 
>   We'd like to draw it at things that are crazy.  But we're
> too late for that.

Too late in terms of what folks have implemented, yes.  Not too late in
terms of what we publish in an RFC and recognize as "recommended" behavior.
Not all bugs need to be promoted to feature status.
 
>   Maybe it's best to say that authentication ports respond with
> Access-Accept, and accounting ports respond with Accounting-Response.
> Anything else is NOT RECOMMENDED.

That would certainly cover all bases.
 
>   Comments?

Yes, comments from others, please.

--
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, 08 Dec 2008 14:50:35 +0000
Date: Mon, 08 Dec 2008 15:49:57 +0100
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: [email-masked]
Subject: Re: RADEXT WG Last Call on Status-Server Document

David B. Nelson wrote:
> Hmm.  IIRC, the consensus of the room at the RADEXT WG meeting at IETF-73
> was that this was a bad idea.  I realize this was probably the only
> substantive comment received during WGLC on this draft.  However, it's only
> one opinion.

  OK, if the consensus is that it's a bad idea, that can be removed from
the draft.

>>>    Some server implementations accept both Access-Request and
>>>    Accounting-Request packets on the same port, and do not
>>>    distinguish between "authentication only" ports, and "accounting 
>>>    only" ports.  Those implementations SHOULD reply to Status-Server 
>>>    packets with an Access-Accept packet.
> 
> Yeah, but isn't that extremely broken behavior?

  Umm... if you say so.  I won't comment.

>  I know we're documenting
> existing behavior, but do we have to document the most broken parts?  I
> thought the idea was to support the needs of RADSEC with respect to server
> "liveness", and in doing so, re-use an existing mechanism.  Otherwise, there
> are probably lots of other broken behaviors in RADIUS implementations that
> could be documented.  You know... "A bug, once documented, becomes a
> feature".  :-(  Where do we draw the line?

  We'd like to draw it at things that are crazy.  But we're too late for
that.

  Maybe it's best to say that authentication ports respond with
Access-Accept, and accounting ports respond with Accounting-Response.
Anything else is NOT RECOMMENDED.

  Comments?

  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: Mon, 08 Dec 2008 14:43:29 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: RADEXT WG Last Call on Status-Server Document
Date: Mon, 8 Dec 2008 09:42:16 -0500
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

> > I think clients should allow Access-Accept responses to 
> > status-server messages sent to the accounting port. Even
> > if it's not the expected message, it shows that the server
> > is alive.
> 
>   Ok.  I've updated the draft, and will issue a new version
> shortly.

Hmm.  IIRC, the consensus of the room at the RADEXT WG meeting at IETF-73
was that this was a bad idea.  I realize this was probably the only
substantive comment received during WGLC on this draft.  However, it's only
one opinion.

<WG Chair hat on>

I think document editors need to be careful to avoid adding technical
changes to WG drafts at the request of just one commenter.  If that one
comment happens to represent WG consensus, then fine.  If the one comment is
simply one individual's opinion, then maybe not so fine.  I also realize
that in RADEXT, these days, it's sometimes hard to distinguish.  :-(

<WG Chair hat off>

> > Also, towards the end of section 4.2 the draft says:
> >
> >    Some server implementations accept both Access-Request and
> >    Accounting-Request packets on the same port, and do not
> >    distinguish between "authentication only" ports, and "accounting 
> >    only" ports.  Those implementations SHOULD reply to Status-Server 
> >    packets with an Access-Accept packet.

Yeah, but isn't that extremely broken behavior?  I know we're documenting
existing behavior, but do we have to document the most broken parts?  I
thought the idea was to support the needs of RADSEC with respect to server
"liveness", and in doing so, re-use an existing mechanism.  Otherwise, there
are probably lots of other broken behaviors in RADIUS implementations that
could be documented.  You know... "A bug, once documented, becomes a
feature".  :-(  Where do we draw the line?

--
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, 08 Dec 2008 12:41:31 +0000
Date: Mon, 08 Dec 2008 13:41:16 +0100
From: Alan DeKok <[email-masked]>
To: Stig Venaas <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: RADEXT WG Last Call on Status-Server Document

Stig Venaas wrote:
> In most places (but not all) the draft uses the term "Status-Server
> packet" or just "packet". Wouldn't it be better to replace "packet"
> with "message"? Especially since it's not limited to UDP transport.

  Maybe.  It's still a RADIUS packet, and the term "packet" is
consistent with RFC 2865.

> "it's" should be replaced with "its" throughout (genitive).

  Fixed, thanks.

> TOC formatting is slightly broken (2.3.1/2.3.2).

  I'll fix that in the next rev.

> Section 2.3.2 has no title (missing both in TOC and body).
> 
> In 2.2:
> 
>    A similar solution for the problem of querying server status may be
>    for a NAS to send specially formed Accounting-Request packets to a
>    RADIUS servers authentication port.  The NAS can then look for a
>           ^^^^^^^^^^^^^^^^^^^^^^
>  server's accounting

  Fixed, thanks.

> In 3:
> 
>    Note that when a server responds to a Status-Server request, it MUST
>    NOTE send more than one response packet.
> s/NOTE/NOT/

  Fixed, thanks.

> In 4.2:
> 
>    The server MAY prioritize the handling Status-Server queries over the
> 
> Insert "of"                            ^^^^^
> 
>    The server MAY decide to not respond to a Status-Server, depending on
> Insert "packet" or "message"                        ^^^^^^^

  Fixed, thanks.

> In 4.3:
>    unresponsive, this change would enable the NAS to start packets to
>                                                     ^^^^^^^^^^^^^^^^^^
>    start sending packets to that RADIUS server again.  The NAS MAY
> Remove " start packets to".

  Fixed, thanks.

> In 4.6:
>    In the worst case, failures in routing for Realm A may affect users
>    Realm B.  For example, if Proxy Server P can reach Realm B but not
>  ^^^^^
> Insert "of"

  Fixed, thanks.

>    In this situation, if all participants impement Status-Server as
> s/impement/implement/                    ^^^^^^^^^^

  Fixed, thanks.

> In 6:
>    The following table provide a guide to which attributes may be found
> s/provide/provides/   ^^^^^^^^^

  Fixed, thanks.

  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: Mon, 08 Dec 2008 12:38:02 +0000
Date: Mon, 08 Dec 2008 13:37:00 +0100
From: Alan DeKok <[email-masked]>
To: Stig Venaas <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: RADEXT WG Last Call on Status-Server Document

Stig Venaas wrote:
> I think clients should allow Access-Accept responses to status-server
> messages sent to the accounting port. Even if it's not the expected
> message, it shows that the server is alive.

  Ok.  I've updated the draft, and will issue a new version shortly.

> Also, towards the end of section 4.2 the draft says:
> 
>    Some server implementations accept both Access-Request and
>    Accounting-Request packets on the same port, and do not distinguish
>    between "authentication only" ports, and "accounting only" ports.
>    Those implementations SHOULD reply to Status-Server packets with an
>    Access-Accept packet.
> 
> Due to this, I think the text in 2.3.2 is too strict:
> 
>    The Status-Server packet MUST contain a Message-Authenticator
>    attribute for security.  The response (if any) to a Status-Server
>    packet sent to an accounting port MUST be an Accounting-Response
>    packet.  The list of attributes that are permitted in the Accounting-
>    Response packet is given in the Table of Attributes in Section 6,
>    below.
> 
> I think the second MUST should be a SHOULD. Or at the very least, in
> section 4.1 where it talks about clients being liberal at what they
> accept. Add a note that they SHOULD accept this.

  OK.  I've done that:

      The response (if any) to a Status-Server
      packet sent to an accounting port SHOULD be an Accounting-Response
      packet, and MAY be an Access-Accept packet.  Other response packet
      codes MUST NOT be used.

  With similar text for authentication packets.

  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, 04 Dec 2008 16:30:35 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: draft-ietf-radext-crypto-agility-requirements-01
Date: Thu, 4 Dec 2008 11:29:25 -0500
Organization: Elbrys Networks, Inc.

Here are some editorial nits that I received in a private e-mail message:

> (1)  Section 3
> 
> In the first line of the first paragraph, please correct the
> typo:     s/MD5-baed/MD5-based/  .
>                            ^
> 
> (2)  Section 4.6
> 
> The bullets from a grammar point of view are made up of a complete
> sentence each, and start with a capital letter.
> Consequently, a trailing period should be added to all (4) bullets.

--
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, 02 Dec 2008 01:51:07 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: FW: [Technical Errata Reported] RFC4282 (1623)
Date: Mon, 1 Dec 2008 17:50:00 -0800

FYI. 

-----Original Message-----
From: RFC Errata System [mailto:[email-masked]] 
Sent: Monday, December 01, 2008 4:45 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Technical Errata Reported] RFC4282 (1623)

The following errata report has been submitted for RFC4282,
"The Network Access Identifier".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4282&eid=1623

--------------------------------------
Type: Technical
Reported by: Martin Thomson <[email-masked]>

Section: 2.1

Original Text
-------------
   realm       =  1*( label "." ) label

Corrected Text
--------------
   realm       =  *( label "." ) label

Notes
-----
The ABNF for realm forces the inclusion of two labels, which is not
consistent with RFC 1034, which allows just one:
  <subdomain> ::= <label> | <subdomain> "." <label>

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4282 (draft-ietf-radext-rfc2486bis-06)
--------------------------------------
Title               : The Network Access Identifier
Publication Date    : December 2005
Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

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