Subject: RE: Issue: Attribute concatenation/splitting
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Date: Fri, 30 Jun 2006 11:46:38 -0700

>I guess this means that a single long rule can be split into multiple
>NAS-Filter-Rule attributes?

Yes.

>And a single NAS-Filter-Rule attribute could contain pieces of multiple 
>rules?

Yes.

BTW, do the same issues also apply to the NAS-Filter-Rule AVP defined in RFC 
4005?

>If so, I'd recommend separating the individual rules somehow.

Question:  Does introducing a separator into NAS-Filter-Rule attribute 
complicate the translation to and from NAS-Filter-Rule AVP?

For example, can we have multiple filter rules in a NAS-Filter-Rule AVP, and 
if so, how do we tell when one rule ends and another begins?

>In the current version of
>NAS-Traffic-Rule each individual rule ends with LF, making it easy to
>determine where one rule ends and another one begins. I'd suggest
>adopting this same convention for RADIUS NAS-Filter-Rule.

NAS-Traffic-Rule gets to define both the RADIUS attribute and Diameter AVP, 
so as to ensure easy translation between them.   Whereas NAS-Filter-Rule 
attribute definition has to deal with the definition of NAS-FilterRule AVP 
in 4005.   So the Diameter considerations for the two attributes may be 
different even though they are similar.

>
>This concatenation/splitting has also implications for Diameter
>translation (Section 4): AVPs coming from Diameter side may have to be
>split to several RADIUS attributes (and rule delimiters added), and
>attributes coming from RADIUS side have to be concatenated/split to
>Diameter AVPs (and rule delimiter removed).
>
>Best regards,
>Pasi
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

--
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, 30 Jun 2006 18:27:09 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: Genart review of RFC 3756 MIBs
Date: Fri, 30 Jun 2006 11:26:39 -0700

From: Brian E Carpenter <[email-masked]>
To: Ron Bonica <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [Gen-art] Re: Genart review of
draft-ietf-radext-dynauth-server-mib-05
/ draft-ietf-radext-dynauth-client-mib-05

Ron, it seems clear that the -06 versions are OK then, no need for
a real re-review.

    Brian

Ron Bonica wrote:
>Ok. In that case, you are fine. The MIB Rx is the MIB Doctor Review
>group. Your AD will introduce you to them somewhere in the process.
>
>                      Ron
>
>
>[email-masked] wrote:
>
>>Hi Ron,
>>
>>Thanks for the review, see below for some answers
>>
>>Ron Bonica wrote:
>>
>>
>>>I am the assigned Gen-ART reviewer for:
>>>draft-ietf-radext-dynauth-server-mib-05
>>>          -and-
>>>draft-ietf-radext-dynauth-client-mib-05
>>>
>>>
>>>For background on Gen-ART, please see the FAQ at
>>>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
>>>Please resolve these comments along with any other Last Call comments
>>>you may receive.
>>>
>>>This draft is ready for publication as a Standards Track document,
>>>except for the following nit:
>>>
>>
>>In fact, the 2 documents are informational.
>>
>>
>>>- The client MIB contains a note to the RFC editor about the reference
>>>[DYNSERV]. However, there is no such reference.
>>>
>>
>>I checked it and the client MIB is Ok, in the server MIB it seems that
>>the RFC ed note is incorrect and [DYNSERV] should be replaced by
>>[DYNCLNT]. The references in both of the drafts are correct, with the
>>exception of the RFC ed note in the server MIB.
>>
>>
>>
>>>And two substantial questions:
>>>
>>>- Can I assume that it has passed MIB Rx Review? (It compiles clean).
>>>
>>
>>Not sure what MIB Rx review is. I compliled the MIB with Smilent.
>>
>>
>>>- Should this MIB *ever* be used in conjuntion with SNMPv1? I know that
>>>you *recommend* against it. But it seems that divulging the information
>>>in this mib to a hostile party might be pretty bad.
>>>
>>
>>http://www.ops.ietf.org/mib-security.html contains preformatted text for
>>the security section and that text was put in the draft. See the text on
>>that webpage in the section "-- else if there are no read-write objects
>>in your MIB module". The text in the draft is more or less a copy/paste
>>from that webpage. Also the other Radius MIBs like
>>draft-ietf-radext-rfc2618bis-03.txt are also following the guidelines on
>>the mentioned webpage.
>>
>>regards,
>>Stefaan
>>
>>
>>
>>>                                      Ron
>>>
>>>
>>
>
>_______________________________________________
>Gen-art mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/gen-art
>

--
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, 30 Jun 2006 11:32:37 +0000
Content-class: urn:content-classes:message
Subject: Issue: Attribute concatenation/splitting
Date: Fri, 30 Jun 2006 14:32:05 +0300
From: <[email-masked]>
To: <[email-masked]>

Attribute concatenation/splitting
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: June 30, 2006
Reference:=20
Document: draft-ietf-radext-filter-00
Comment type: 'T'echnical=20
Priority: 'S' Must fix
Section: 2 and 4
Rationale/Explanation of issue:

Section 2 currently says that "Where more than one NAS-Filter-Rule
attribute is included in a RADIUS packet, the attributes MUST be
consecutive and it is assumed that the attributes are to be
concatenated to form a single filter list."

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

This concatenation/splitting has also implications for Diameter
translation (Section 4): AVPs coming from Diameter side may have to be
split to several RADIUS attributes (and rule delimiters added), and
attributes coming from RADIUS side have to be concatenated/split to
Diameter AVPs (and rule delimiter removed).

Best regards,
Pasi

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

Delivery-date: Thu, 29 Jun 2006 19:51:06 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc2621bis-04.txt 
Date: Thu, 29 Jun 2006 15:50:01 -0400

--NextPart

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

	Title		: RADIUS Accounting Server MIB for IPv6
	Author(s)	: D. Nelson
	Filename	: draft-ietf-radext-rfc2621bis-04.txt
	Pages		: 25
	Date		: 2006-6-29
	
This memo defines a set of extensions, which instrument RADIUS
accounting server functions.  These extensions represent a portion of
the Management Information Base (MIB) for use with network management
protocols in the Internet community.  Using these extensions IP-based
management stations can manage RADIUS accounting servers.

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

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc2621bis-04.txt

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Thu, 29 Jun 2006 19:50:41 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc2620bis-04.txt 
Date: Thu, 29 Jun 2006 15:50:01 -0400

--NextPart

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

	Title		: RADIUS Accounting Client MIB for IPv6
	Author(s)	: D. Nelson
	Filename	: draft-ietf-radext-rfc2620bis-04.txt
	Pages		: 23
	Date		: 2006-6-29
	
This memo defines a set of extensions, which instrument RADIUS
accounting client functions.  These extensions represent a portion of
the Management Information Base (MIB) for use with network management
protocols in the Internet community.  Using these extensions IP-based
management stations can manage RADIUS accounting clients.

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

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc2620bis-04.txt

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Thu, 29 Jun 2006 19:50:33 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc2619bis-04.txt 
Date: Thu, 29 Jun 2006 15:50:01 -0400

--NextPart

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

	Title		: RADIUS Authentication Server MIB for IPv6
	Author(s)	: D. Nelson
	Filename	: draft-ietf-radext-rfc2619bis-04.txt
	Pages		: 26
	Date		: 2006-6-29
	
This memo defines a set of extensions, which instrument RADIUS
authentication server functions.  These extensions represent a
portion of the Management Information Base (MIB) for use with network
management protocols in the Internet community.  Using these
extensions IP-based management stations can manage RADIUS
authentication servers.

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

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc2619bis-04.txt

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Thu, 29 Jun 2006 19:50:25 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc2618bis-04.txt 
Date: Thu, 29 Jun 2006 15:50:01 -0400

--NextPart

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

	Title		: RADIUS Authentication Client MIB for IPV6
	Author(s)	: D. Nelson
	Filename	: draft-ietf-radext-rfc2618bis-04.txt
	Pages		: 24
	Date		: 2006-6-29
	
This memo defines a set of extensions, which instrument RADIUS
authentication client functions.  These extensions represent a
portion of the Management Information Base (MIB) for use with network
management protocols in the Internet community.  Using these
extensions IP-based management stations can manage RADIUS
authentication clients.

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

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc2618bis-04.txt

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

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

--OtherAccess--

--NextPart--

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

Envelope-to: [email-masked]
Delivery-date: Thu, 29 Jun 2006 16:09:32 +0000
From: "Alan DeKok" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Subject: Re: The RADIUS attribute space: an assessment 
cc: [email-masked]
Date: Thu, 29 Jun 2006 12:00:00 -0400
Message-Id: <[email-masked]>

"Glen Zorn \(gwz\)" <[email-masked]> wrote:
> ???

  Making negative comments about someone's work isn't very nice.

> Actually, I thought that I had, by suggesting how to extend a RADIUS
> server w/one new feature (Diameter).  That way administrators don't
> _have_ to do anything new, but they _can_.  What's so alienating about
> that?

  I've looked under all the nooks and crannies I can find.  No such
Diameter server exists, and none is likely to exist in the near future.

> OK, so I'm wondering why I (or Cisco or anyone else) needs to 'fund a
> Diameter implementation with lots of features'...

  Is it really rocket science?  You said:

> ... if a vendor (commercial or otherwise) can't figure out how ...

  Figuring out how is the easy part.  Getting time/money to do the
work is the hard part.

  No one is funding an effort to replace FreeRADIUS with a compatible
Diameter server, which would seem to explain why one doesn't exist.
When this is pointed out, you scratch your head, and wonder why it
would need funding...

> Here's a thought: back up a bit & ask why equipment vendors aren't
> implementing it.  Is it just a bad idea?

  See my earlier comments about no customers asking for it.

> Hmm.  I could have sworn that (according to you) the main problem was
> that there are no open-source servers; isn't that your department?

  No, I explained that there were multiple factors, one of which was
the lack of an open source server.  If people *cooperated* to get the
peices done, it would be more likely to happen.

  But the NAS vendors aren't doing it, and the open source people
aren't doing it either, for all the previously mentioned reasons.

  So we're left with your complaints on the list that Diameter isn't
being deployed.  What, then, are your proposals to solve the problem?

  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, 29 Jun 2006 06:58:24 +0000
Date: Thu, 29 Jun 2006 08:58:10 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: The RADIUS attribute space:  an assessment
Reply-To: [email-masked]
Mail-Followup-To: "Glen Zorn (gwz)" <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]

On Wed, Jun 28, 2006 at 07:44:59PM -0700, Glen Zorn (gwz) wrote:
 
> A perfect example of this is the current nonsense going on in the
> isms WG, in which you are involved I believe.  Even w/i the "ivory
> tower", neither the IESG (nor you) are willing to give any guidance
> as to the appropriate use of AAA protocols _for new work_: nobody
> has deployed isms, it's not even close to being done, but they are
> using RADIUS (or trying to break it) & AFAIK no one but me has ever
> mentioned that Diameter fulfills their AAA needs perfectly.

ISMS is there with a simple goal - make SNMP security happen by
reusing and integrating with what is already out there.

I do not have a diameter server, I do not have diameter PAM libraries,
the switches and routers I have do not talk diameter. This is the
reality we are facing and trying to work with. And operators also seem
to rely much more on radius than anything else.

We have a secure version of SNMP which is full standard but not as
widely deployed as it should be. The SNMP community has gone through
all the discussions you are having here before and we learned in the
process that simply declaring something a standard does have close to
zero impact when it comes to deployment.

/js

PS: In the SNMPv3 case, we have several open implementations and
    newer devices also support it but still it is not being used - so
    an open implementation is in my view necessary but not a sufficient
    step for success.

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--
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, 29 Jun 2006 06:46:12 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space: an assessment 
Date: Wed, 28 Jun 2006 23:46:01 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

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

> "Glen Zorn \(gwz\)" <[email-masked]> wrote:
>> So you're saying that it is not possible to extend FreeRADIUS to
>> support Diameter in the way that I suggest?
>=20
>   Are you really that insistent on alienating everyone?

???

>=20
>   I note that you addressed none of my cost/benefit analysis for why
> administrators aren't deploying Diameter,=20

Actually, I thought that I had, by suggesting how to extend a RADIUS =
server w/one new feature (Diameter).  That way administrators don't =
_have_ to do anything new, but they _can_.  What's so alienating about =
that?

> and why NAS vendors aren't
> implementing it, either.  Instead, your main concern appears to be
> that the world doesn't meet your ideal of who "deserves" to be in
> business.   =20
>=20
>> Who funds FreeRADIUS?
>=20
>   No one.
>=20
>   Hard as that is to believe, coming from a "only commercial vendors
> deserve to exist" mindset,=20

You misinterpret my statement: what I meant is that Diameter doesn't =
need to show up on a user interface at all, except for an option to =
enable it, & further, if a vendor (commercial or otherwise) can't figure =
out how to make something like that basically transparent unless =
enabled, they shouldn't be in business (or in a different business - =
say, hospitality or food service).

> there has been *zero* funding of the
> project from day one.  Not a single cent.  Ever. =20

OK, so I'm wondering why I (or Cisco or anyone else) needs to 'fund a =
Diameter implementation with lots of features'...

>=20
>> For years now, the most common questions I've heard from SP customers
>> has been a variation on "What's happening with Diameter?  Is it the
>> wave of the future or a dead-end?  Is the IETF supporting it or
>> not?", all of which boil down to "Should we start thinking about
>> migrating from RADIUS?".  Of course, the only answer I can give is
>> "I don't know".  It appears that in your world the waffling of the
>> IESG has had no effect upon this market confusion.
>=20
>   It's strange.  I don't hear complaints from customers that the IESG
> is blocking Diameter.  Instead, I hear that Diameter doesn't add
> anything of value for them. =20

Why not?  Because they don't need the features or because this WG is =
busy hacking Diameter into RADIUS?

> Maybe that's why they're not deploying
> it?  =20
>=20
>   Or, I hear that the equipment vendors aren't implementing it.  Or,
> I hear that no adequate Diameter server exists.  Would that affect
> the customers decision to deploy it?=20

Here's a thought: back up a bit & ask why equipment vendors aren't =
implementing it.  Is it just a bad idea?  OK, I would accept that except =
for the fact that you seem to be hell-bent on reproducing a Frankenstein =
version of it by patching RADIUS.=20

>=20
>   Hey, don't *you* work for a large networking company?  Why don't
> you push them into implementing Diameter in their equipment, and
> implementing a replacement for ACS?  Wouldn't that be spectacular! =20

Hmm.  I could have sworn that (according to you) the main problem was =
that there are no open-source servers; isn't that your department?

>=20
>   Alan DeKok.

Hope this helps,

~gwz

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

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

Delivery-date: Thu, 29 Jun 2006 06:26:23 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space: an assessment
Date: Wed, 28 Jun 2006 23:25:56 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

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

>> Cosmetic surgery might be a better example: is it really necessary to
>> continue the facelifts & nips & >tucks & enhancements?  If so, then
>> let's just do it all at once; otherwise, let it age gracefully &
>> >move on to Diameter.
>=20
> OK, we'll go with the cosmetic surgery analogy.
>=20
> Is the issue that the facelifts, nips & tucks are not being done in a
> coordinated way, resulting in a potentially hideous outcome? =20

Pretty much, yeah.

> Several
> celebrities come to mind, but I won't mention them. =20

:-)

Hope this helps,

~gwz

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

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

Delivery-date: Thu, 29 Jun 2006 03:45:35 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: The RADIUS attribute space: an assessment
Date: Wed, 28 Jun 2006 20:44:56 -0700

>Cosmetic surgery might be a better example: is it really necessary to 
>continue the facelifts & nips & >tucks & enhancements?  If so, then let's 
>just do it all at once; otherwise, let it age gracefully & >move on to 
>Diameter.

OK, we'll go with the cosmetic surgery analogy.

Is the issue that the facelifts, nips & tucks are not being done in a 
coordinated way, resulting in a potentially hideous outcome?  Several 
celebrities come to mind, but I won't mention them.

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

Envelope-to: [email-masked]
Delivery-date: Thu, 29 Jun 2006 03:10:07 +0000
From: "Alan DeKok" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Subject: Re: The RADIUS attribute space: an assessment 
cc: [email-masked]
Date: Wed, 28 Jun 2006 23:00:46 -0400
Message-Id: <[email-masked]>

"Glen Zorn \(gwz\)" <[email-masked]> wrote:
> So you're saying that it is not possible to extend FreeRADIUS to support
> Diameter in the way that I suggest? 

  Are you really that insistent on alienating everyone?

  I note that you addressed none of my cost/benefit analysis for why
administrators aren't deploying Diameter, and why NAS vendors aren't
implementing it, either.  Instead, your main concern appears to be
that the world doesn't meet your ideal of who "deserves" to be in
business.

> Who funds FreeRADIUS?

  No one.

  Hard as that is to believe, coming from a "only commercial vendors
deserve to exist" mindset, there has been *zero* funding of the
project from day one.  Not a single cent.  Ever.

> For years now, the most common questions I've heard from SP customers
> has been a variation on "What's happening with Diameter?  Is it the wave
> of the future or a dead-end?  Is the IETF supporting it or not?", all of
> which boil down to "Should we start thinking about migrating from
> RADIUS?".  Of course, the only answer I can give is "I don't know".  It
> appears that in your world the waffling of the IESG has had no effect
> upon this market confusion.

  It's strange.  I don't hear complaints from customers that the IESG
is blocking Diameter.  Instead, I hear that Diameter doesn't add
anything of value for them.  Maybe that's why they're not deploying it?

  Or, I hear that the equipment vendors aren't implementing it.  Or, I
hear that no adequate Diameter server exists.  Would that affect the
customers decision to deploy it?

  Hey, don't *you* work for a large networking company?  Why don't you
push them into implementing Diameter in their equipment, and
implementing a replacement for ACS?  Wouldn't that be spectacular!

  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, 29 Jun 2006 03:02:43 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space: an assessment
Date: Wed, 28 Jun 2006 20:02:16 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

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

> Glen Zorn said:
>=20
> "It's not at all clear to me that Diameter (as specified) is actually
> a "better" protocol but at least it doesn't have the problem Bernard
> mentions; in any case, we're not talking about killing RADIUS, here,
> but whether to take heroic measures to keep it alive."  =20
>=20
> What would you characterize as a "heroic measure"?

I think that my analogy was inappropriate in that the question isn't =
really even keeping RADIUS alive (I really think it will likely out-live =
me easily, even with no more work).  Cosmetic surgery might be a better =
example: is it really necessary to continue the facelifts & nips & tucks =
& enhancements?  If so, then let's just do it all at once; otherwise, =
let it age gracefully & move on to Diameter.  There's pain involved =
either way, but at least we'll have a plan.

...

Hope this helps,

~gwz

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

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

Delivery-date: Thu, 29 Jun 2006 02:45:14 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space:  an assessment
Date: Wed, 28 Jun 2006 19:44:59 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>, "Glen Zorn \(gwz\)" <[email-masked]>

Glen Zorn (gwz) <> supposedly scribbled:

...

> I would note that none of those I-Ds have been accepted as WG items,
> nor does that appear to be likely.  My position remains the same as
> it was 10 years ago: I want the IETF to have a AAA protocol that
> actually works, & does what is necessary.  This seems at odds w/the
> aim of the IESG (& unsurprisingly, the WG chairs), however, which
> seems happy to continue the current situation.   =20

A perfect example of this is the current nonsense going on in the isms =
WG, in which you are involved I believe.  Even w/i the "ivory tower", =
neither the IESG (nor you) are willing to give any guidance as to the =
appropriate use of AAA protocols _for new work_: nobody has deployed =
isms, it's not even close to being done, but they are using RADIUS (or =
trying to break it) & AFAIK no one but me has ever mentioned that =
Diameter fulfills their AAA needs perfectly.  The same story is =
unfolding in ecrit, geopriv & probably others of which I'm unaware.  You =
are right to say that the IETF cannot force anyone to do anything, but =
the IESG is certainly capable of forcing WGs in a given direction, as =
they have demonstrated amply in the past.

...

~gwz

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

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

Delivery-date: Thu, 29 Jun 2006 02:33:53 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space: an assessment 
Date: Wed, 28 Jun 2006 19:33:10 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Greg Weber \(gdweber\)" <[email-masked]>
Cc: <[email-masked]>

Alan DeKok <> supposedly scribbled:

> "Greg Weber \(gdweber\)" <[email-masked]> wrote:
>> Do you have any more info about what makes Diameter difficult to
>> deploy?  Is it security setup? config changes?
>> Or just that any change at all is difficult?
>=20
>   A large part is that any change is difficult.
>=20
>   A similar part is the comment about Open Source servers.  Let's not
> underestimate the number of AAA server deployments that happen
> because someone had a spare whitebox, and a few hours to play around.
>=20
>   Also, capital costs show up in budgets, and incur pushback from
> accounting types.  Time spent on salaries is less problematic,
> because the perception is that those costs are already accounted for.
>=20
>> Is Diameter more difficult to deploy than IPsec protected RADIUS?
>=20
>   Absolutely.  Diameter involves an upgrade of your existing RADIUS
> server to, what exactly?  Something without LDAP/SQL/foo support,
> that include your custom batch files or Perl scripts? =20
>=20
>   That doesn't sell well.
>=20
>   In constrast, RADIUS + IPSec is an incremental approach over what
> people have now.  If people already have both systems separately
> deployed, it's simply integration, which is fairly simple. =20
>=20
>>  More difficult than RADIUS with CoA?
>=20
>   A lot of people don't use CoA, so that isn't a problem.  And for
> the people who do, most don't proxy CoA packets around the Internet.=20
> Instead, they run a script with a dumb RADIUS client that sends
> packets to the NAS, on the local network.=20
>=20
>   RADIUS server upgrade for CoA?  Who needs that?

You are making an excellent argument for _not_ extending RADIUS.

>=20
>   Oh... the large telecom providers, who *do* send CoA packets
> backwards across the net, through chains of proxies.  But there's a
> better way: Diameter. =20
>=20
>   So once again, they deploy Diameter, and no one else does.

That's just fine: I happen to think that RADIUS is a great protocol =
within its limitations & I certainly wouldn't suggest that everyone on =
Earth rip out RADIUS & replace it w/Diameter.  However, saying that =
(which seems to be about what you are saying, too) hardly implies that =
we need to continue to patch, stretch & mutilate _standard_ RADIUS into =
some twisted simalcrum of Diameter.  There are doubtless many =
applications for which RADIUS _as it is_ is & always will be the best =
choice; all I'm saying is let's leave it at that & move on.  Maybe it's =
"self-congratulatory", maybe even self-aggrandizing, but I'd just like =
to note that the problem under discussion (the exhaustion of the RADIUS =
attribute space, if you'll recall) has already been solved.

>=20
>   Alan DeKok.

Hope this helps,

~gwz

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

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

Delivery-date: Thu, 29 Jun 2006 02:33:45 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space:  an assessment
Date: Wed, 28 Jun 2006 19:33:13 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Nelson, David <mailto:[email-masked]> supposedly scribbled:

> Glen Zorn writes...
>=20
>>> Why would that be a better idea?  Except, perhaps, on some
>>> self-congratulatory level?
>>=20
>> Thanks for the insult.
>=20
> No insult intended.  My point is that an attempt by the IESG to
> suppress RADIUS extensions work will ultimately fail, and serve only
> an ivory-tower "Diameter wins, RADIUS loses" sort of objective. =20

How is "not actively pursuing" equivalent to "suppressing"?

>=20
>> It's not at all clear to me that Diameter (as specified) is actually
>> a "better" protocol but at least it doesn't have the problem Bernard
>> mentions; in any case, we're not talking about killing RADIUS, here,
>> but whether to take heroic measures to keep it alive.
>=20
> Well, yes.  But you have authored several I-Ds that once could
> characterize as "heroic measures" to extend RADIUS and you told us
> during IETF-65 you were working on a method to extend the RADIUS PDU
> limit beyond 4095.  But perhaps you've changed your opinion, as all
> of us are wont to do from time to time. =20

I would note that none of those I-Ds have been accepted as WG items, nor =
does that appear to be likely.  My position remains the same as it was =
10 years ago: I want the IETF to have a AAA protocol that actually =
works, & does what is necessary.  This seems at odds w/the aim of the =
IESG (& unsurprisingly, the WG chairs), however, which seems happy to =
continue the current situation.
 =20
>=20
>> That would be near-suicidal for interoperability, of course.  Oh
>> wait, that might mean that RADIUS would go away...no wonder there is
>> no visible advantage.
>=20
> If the likely disastrous outcome of poor interoperability would
> actually prevent such further work, you might have a good point.  I
> suspect that it would not, and what we would end up with would be
> different, non-interoperable "dialects" of RADIUS promulgated by
> various SDOs, and possibly by vendors as well.  =20

Exactly.  The question is, why should we care?  If interoperability is =
not a goal of these unnamed SDOs & vendors, so be it.  If on the other =
hand, it is a goal, then they should follow the standard. =20

Hope this helps,

~gwz

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

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

Delivery-date: Thu, 29 Jun 2006 02:33:37 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space: an assessment 
Date: Wed, 28 Jun 2006 19:33:13 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

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

> "Glen Zorn \(gwz\)" <[email-masked]> wrote:
>> This is a red herring: any vendor that can't keep the same interfaces
>> for RADIUS while supporting Diameter doesn't deserve to be in
>> business.=20
>=20
>   You're joking, right?
>=20
>   As far as I can tell, counting by the number of deployments,
> FreeRADIUS is the #2 RADIUS server on the planet.  Maybe by your
> logic the project doesn't "deserve to be in business".  But sticking
> your head in the sand and pretending it doesn't exist won't change
> things. =20

So you're saying that it is not possible to extend FreeRADIUS to support =
Diameter in the way that I suggest?  I think that I would be a little =
put off by that, were I a FreeRADIUS developer. =20
 =20
>=20
>   The reality is that many people who've deployed RADIUS *don't* have
> an upgrade path to Diameter.  They don't have a free Diameter server
> they can use, and they don't have the budget to buy a commercial one.
> Even if they did have the budget to buy a commercial one, it would
> have significantly fewer features than the RADIUS server they're
> using right now. =20

Look at the list of new attributes in Bernard's original email.  Are you =
telling me that these poor, poverty-stricken folks actually are going to =
need to support GEOPRIV & MobileIP?

>=20
>   If you want to push Diameter, the best thing you could do is to
> fund the development of an Open Source Diameter server with a massive
> feature set,=20

Who funds FreeRADIUS?

> followed by ensuring that all NAS equipment supports
> Diameter.  =20
>=20
>   Until that happens, Diameter will continue to languish.

For years now, the most common questions I've heard from SP customers =
has been a variation on "What's happening with Diameter?  Is it the wave =
of the future or a dead-end?  Is the IETF supporting it or not?", all of =
which boil down to "Should we start thinking about migrating from =
RADIUS?".  Of course, the only answer I can give is "I don't know".  It =
appears that in your world the waffling of the IESG has had no effect =
upon this market confusion.
>=20
>   Alan DeKok.

Hope this helps,

~gwz

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

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

Delivery-date: Wed, 28 Jun 2006 19:50:24 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-filter-rules-01.txt 
Date: Wed, 28 Jun 2006 15:50:02 -0400

--NextPart

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

	Title		: RADIUS Attributes for Filtering and 
                          Redirection
	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-filter-rules-01.txt
	Pages		: 28
	Date		: 2006-6-28
	
In certain scenarios it is desirable to limit user access using      
      filters or redirection.  This document proposes additional 
      attributes for this purpose, for use with the Remote 
      Authentication Dial In User Server (RADIUS).  The attributes 
      described in this document are expected to be useful in a variety 
      of environments, including enterprise and service provider 
      scenarios.

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

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

Envelope-to: [email-masked]
Delivery-date: Wed, 28 Jun 2006 18:04:44 +0000
From: "Alan DeKok" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Subject: Re: The RADIUS attribute space: an assessment 
cc: [email-masked]
Date: Wed, 28 Jun 2006 13:55:22 -0400
Message-Id: <[email-masked]>

"Glen Zorn \(gwz\)" <[email-masked]> wrote:
> This is a red herring: any vendor that can't keep the same interfaces
> for RADIUS while supporting Diameter doesn't deserve to be in business.

  You're joking, right?

  As far as I can tell, counting by the number of deployments,
FreeRADIUS is the #2 RADIUS server on the planet.  Maybe by your logic
the project doesn't "deserve to be in business".  But sticking your
head in the sand and pretending it doesn't exist won't change things.

  The reality is that many people who've deployed RADIUS *don't* have
an upgrade path to Diameter.  They don't have a free Diameter server
they can use, and they don't have the budget to buy a commercial one.
Even if they did have the budget to buy a commercial one, it would
have significantly fewer features than the RADIUS server they're using
right now.

  If you want to push Diameter, the best thing you could do is to fund
the development of an Open Source Diameter server with a massive
feature set, followed by ensuring that all NAS equipment supports
Diameter.

  Until that happens, Diameter will continue to languish.

  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, 28 Jun 2006 17:11:58 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: The RADIUS attribute space: an assessment
Date: Wed, 28 Jun 2006 10:11:36 -0700

Glen Zorn said:

"It's not at all clear to me that Diameter (as specified) is actually a 
"better" protocol but at least it doesn't have the problem Bernard mentions; 
in any case, we're not talking about killing RADIUS, here, but whether to 
take heroic measures to keep it alive."

What would you characterize as a "heroic measure"?

Is extending the attribute space (if that is all that is done) "heroic"?

Or is the problem that proposals have also tended to add substantially new 
functionality in the process (e.g. support for Diameter AVPs)?

In other words, if RADIUS had a "living will", what "heroic measures" would 
be prohibited?

--
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, 28 Jun 2006 15:30:26 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space: an assessment 
Date: Wed, 28 Jun 2006 11:30:15 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Glen Zorn writes...
=20
> In fact, any reasonable Diameter "server" would look much=20
> more like b) than a) -- the "whiz-bang" new features being=20
> Diameter Base + NASREQ.

Where (b) refers to a self-consistent product upgrade, with a minimal
learning curve and (a) refers to a new product, with a steep learning
curve.

I would have thought the same thing, that rational product vendors would
create a Diameter server product, integrated with RADIUS capabilities,
that re-uses the human interface design of their RADIUS server product.

--
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, 28 Jun 2006 15:10:15 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space:  an assessment
Date: Wed, 28 Jun 2006 11:09:46 -0400
From: "Nelson, David" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>, <[email-masked]>

Glen Zorn writes...
=20
> > Why would that be a better idea?  Except, perhaps, on some
> > self-congratulatory level?
>=20
> Thanks for the insult.

No insult intended.  My point is that an attempt by the IESG to suppress
RADIUS extensions work will ultimately fail, and serve only an
ivory-tower "Diameter wins, RADIUS loses" sort of objective.=20

> It's not at all clear to me that Diameter (as specified) is actually a
> "better" protocol but at least it doesn't have the problem Bernard
> mentions; in any case, we're not talking about killing RADIUS, here,
but
> whether to take heroic measures to keep it alive.

Well, yes.  But you have authored several I-Ds that once could
characterize as "heroic measures" to extend RADIUS and you told us
during IETF-65 you were working on a method to extend the RADIUS PDU
limit beyond 4095.  But perhaps you've changed your opinion, as all of
us are wont to do from time to time.

> That would be near-suicidal for interoperability, of course.  Oh wait,
> that might mean that RADIUS would go away...no wonder there is no
visible
> advantage.

If the likely disastrous outcome of poor interoperability would actually
prevent such further work, you might have a good point.  I suspect that
it would not, and what we would end up with would be different,
non-interoperable "dialects" of RADIUS promulgated by various SDOs, and
possibly by vendors as well.

--
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, 28 Jun 2006 05:35:48 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space: an assessment 
Date: Tue, 27 Jun 2006 22:35:25 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>

Alan DeKok <> supposedly scribbled:

> "Nelson, David" <[email-masked]> wrote:
>> Let me ask if this is different for RADIUS?  I can't imagine all of
>> the enhancements to RADIUS you've mentioned -- those that mitigate
>> the need to migrate to Diameter -- are included in those 5-year old
>> versions of system FW?
>=20
>   Nope.  But that doesn't matter.  See below.
>=20
>> Why is it more attractive to add new features to, and ship new
>> versions of, RADIUS client and server software, than it is to ship a
>> Diameter implementation?
>=20
>   It's not.  The choice for a site admin is usually one of the
> following:=20
>=20
>   a) upgrade the AAA server to Diameter, and learn a whole new way to
>      configure & administer things (assuming that it includes a RADIUS
>      to Diameter gateway for legacy devices), and assuming it has the
>      feature set you've come to rely on.
>=20
>   b) upgrade the RADIUS AAA server to version X + 1, which just
>      happens to include whiz-bang new features.  He doesn't have to
>      learn any new configuration, unless he uses those new features,
>      in which case it's a simple delta over what he has today.
>=20
>   Not much of problem making that decision, is it? =20

This is a red herring: any vendor that can't keep the same interfaces =
for RADIUS while supporting Diameter doesn't deserve to be in business.  =
In fact, any reasonable Diameter "server" would look much more like b) =
than a) -- the "whiz-bang" new features being Diameter Base + NASREQ.

...

~gwz

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

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

Delivery-date: Wed, 28 Jun 2006 04:45:33 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space:  an assessment
Date: Tue, 27 Jun 2006 21:45:12 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Nelson, David <> supposedly scribbled:

> Glen Zorn writes...
>=20
>> A far better idea might be for the IESG to finally take some action,
>> deprecating RADIUS and actually supporting Diameter to solve one of
>> the problems for which it was designed.
>=20
> Why would that be a better idea?  Except, perhaps, on some
> self-congratulatory level? =20

Thanks for the insult.

> I've observed that the IESG doesn't have
> much influence over what the rest of the world chooses to implement.=20
> A recent, off list, discussion about some substantial enhancements to
> the RADIUS protocol as opposed to deployment of Diameter, has brought
> this home.  The impediment to Diameter deployment in this instance is
> that lack of complete, robust, open source implementations of
> Diameter, coupled with readily available open source RADIUS
> implementations and wide deployment of RADIUS.  The IETF can provide
> a standardized specification of a better protocol, but it can make
> vendors and operators deploy it.     =20

It's not at all clear to me that Diameter (as specified) is actually a =
"better" protocol but at least it doesn't have the problem Bernard =
mentions; in any case, we're not talking about killing RADIUS, here, but =
whether to take heroic measures to keep it alive.
   =20
>=20
> What would likely happen, if the IESG were to "deprecate" RADIUS, is
> that implementers will simply continue to extend RADIUS using the
> Vendor Specific Attribute.  I don't see any advantage in taking that
> route.  =20

That would be near-suicidal for interoperability, of course.  Oh wait, =
that might mean that RADIUS would go away...no wonder there is no =
visible advantage.

>=20
> The IESG could "support" Diameter by funding (or otherwise
> stimulating) the creation of complete, robust, well-documented open
> source implementations of Diameter.  However, I don't think the IESG
> is in that business.  =20

Hope this helps,

~gwz

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

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

Envelope-to: [email-masked]
Delivery-date: Tue, 27 Jun 2006 22:11:53 +0000
From: "Alan DeKok" <[email-masked]>
To: "Greg Weber \(gdweber\)" <[email-masked]>
Subject: Re: The RADIUS attribute space: an assessment 
cc: [email-masked]
Date: Tue, 27 Jun 2006 18:02:26 -0400
Message-Id: <[email-masked]>

"Greg Weber \(gdweber\)" <[email-masked]> wrote:
> Do you have any more info about what makes Diameter
> difficult to deploy?  Is it security setup? config changes?
> Or just that any change at all is difficult?

  A large part is that any change is difficult.

  A similar part is the comment about Open Source servers.  Let's not
underestimate the number of AAA server deployments that happen because
someone had a spare whitebox, and a few hours to play around.

  Also, capital costs show up in budgets, and incur pushback from
accounting types.  Time spent on salaries is less problematic, because
the perception is that those costs are already accounted for.

> Is Diameter more difficult to deploy than IPsec protected
> RADIUS?

  Absolutely.  Diameter involves an upgrade of your existing RADIUS
server to, what exactly?  Something without LDAP/SQL/foo support, that
include your custom batch files or Perl scripts?

  That doesn't sell well.

  In constrast, RADIUS + IPSec is an incremental approach over what
people have now.  If people already have both systems separately
deployed, it's simply integration, which is fairly simple.

>  More difficult than RADIUS with CoA?

  A lot of people don't use CoA, so that isn't a problem.  And for the
people who do, most don't proxy CoA packets around the Internet.
Instead, they run a script with a dumb RADIUS client that sends
packets to the NAS, on the local network.

  RADIUS server upgrade for CoA?  Who needs that?

  Oh... the large telecom providers, who *do* send CoA packets
backwards across the net, through chains of proxies.  But there's a
better way: Diameter.

  So once again, they deploy Diameter, and no one else does.

  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, 27 Jun 2006 21:50:44 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space: an assessment 
Date: Tue, 27 Jun 2006 17:50:35 -0400
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Tuesday, June 27, 2006 4:16 PM
> To: Nelson, David
> Cc: [email-masked]
> Subject: Re: The RADIUS attribute space: an assessment=20
>=20
<snip>
>   And for the vendors that do implement Diameter in a SW upgrade, ask
> them about their experience with customer uptake on *any* new version.
> Some people are happily running images 5 years out of date.  This
> minimizes the potential market for Diameter even more.
>=20
>   The main market I've seen is new deployments in telecom
> environments.  There's a lot of money, but few boxes, and zero impact
> on the rest of the world.  ISP's, enterprises, and the overwhelming
> majority of AAA deployments find it too hard to deploy Diameter.

Hi Alan,
Do you have any more info about what makes Diameter
difficult to deploy?  Is it security setup? config changes?
Or just that any change at all is difficult?

Is Diameter more difficult to deploy than IPsec protected
RADIUS?  More difficult than RADIUS with CoA?

Greg

>=20
>   Alan DeKok.
>=20

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

Envelope-to: [email-masked]
Delivery-date: Tue, 27 Jun 2006 21:28:24 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: The RADIUS attribute space: an assessment 
Date: Tue, 27 Jun 2006 17:18:51 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> Let me ask if this is different for RADIUS?  I can't imagine all of the
> enhancements to RADIUS you've mentioned -- those that mitigate the need
> to migrate to Diameter -- are included in those 5-year old versions of
> system FW?

  Nope.  But that doesn't matter.  See below.

> Why is it more attractive to add new features to, and ship new versions
> of, RADIUS client and server software, than it is to ship a Diameter
> implementation?

  It's not.  The choice for a site admin is usually one of the following:

  a) upgrade the AAA server to Diameter, and learn a whole new way to
     configure & administer things (assuming that it includes a RADIUS
     to Diameter gateway for legacy devices), and assuming it has the
     feature set you've come to rely on.

  b) upgrade the RADIUS AAA server to version X + 1, which just
     happens to include whiz-bang new features.  He doesn't have to
     learn any new configuration, unless he uses those new features,
     in which case it's a simple delta over what he has today.

  Not much of problem making that decision, is it?  And where is the
incentive for NAS vendors to implement Diameter clients when existing
customers won't use them?  And why do you need all of the extended
features (Diameter or not), in the NAS, when you've got a RADIUS
server whitebox sitting near it in the network?

  On the NAS manufacturer's side, where are the customers demanding
Diameter?  90% of the customers aren't asking for it, so engineering
resources aren't devoted to implementing Diameter clients.  The
customers who *are* asking for it have enough mony to buy whatever
feature they want, so they get it.

  After that, it might trickle down to everyone else.  Maybe.

  I see RADIUS becoming mostly a NAS to local server protocol.  If the
local network is down, reliable transport off the NAS doesn't matter.
And since there will be 1/20 as many local servers as NASes, upgrading
that box to RADIUS++ or Diameter is less of a cost problem than a
management one.  And the previously mentioned management
considerations mean that RADIUS will almost always win in existing
deployments.

  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, 27 Jun 2006 20:34:07 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space: an assessment 
Date: Tue, 27 Jun 2006 16:33:52 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> And for the vendors that do implement Diameter in a SW upgrade, ask
> them about their experience with customer uptake on *any* new version.
> Some people are happily running images 5 years out of date.  This
> minimizes the potential market for Diameter even more.

Let me ask if this is different for RADIUS?  I can't imagine all of the
enhancements to RADIUS you've mentioned -- those that mitigate the need
to migrate to Diameter -- are included in those 5-year old versions of
system FW?

Why is it more attractive to add new features to, and ship new versions
of, RADIUS client and server software, than it is to ship a Diameter
implementation?

I'm not attempting to argue any point of view here -- just trying to
understand the market dynamics.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 27 Jun 2006 20:26:17 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: The RADIUS attribute space: an assessment 
cc: [email-masked]
Date: Tue, 27 Jun 2006 16:16:22 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> This is the part that I've never really understood.  Is the issue that
> equipment vendors choose not to offer Diameter clients in version
> upgrades of the operating SW/FW for their equipment?  Is Diameter only
> available on new equipment (forklift upgrade)?

  Until fairly recently even large equipment vendors didn't appear to
offer Diameter support.  i.e. If you had $$, you could buy it.  The
average joe was out of luck.

  Even today, the low-end boxes tend not to support Diameter.  Given
Zipf's law, probsbly 90% of the deployments are low-end boxes, meaning
Diameter *starts* with 1/10 the possible market of RADIUS.

  And for the vendors that do implement Diameter in a SW upgrade, ask
them about their experience with customer uptake on *any* new version.
Some people are happily running images 5 years out of date.  This
minimizes the potential market for Diameter even more.

  The main market I've seen is new deployments in telecom
environments.  There's a lot of money, but few boxes, and zero impact
on the rest of the world.  ISP's, enterprises, and the overwhelming
majority of AAA deployments find it too hard to deploy Diameter.

  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, 27 Jun 2006 18:36:21 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space: an assessment 
Date: Tue, 27 Jun 2006 14:36:03 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> Many of the superior features of Diameter are already=20
> deployed in RADIUS.  Radsec, SRV record lookups, vendor
> attributes, etc. all mitigate the real-world need to move
> to Diameter.

That may well be so.

> To a large extent the operators don't have a choice.
> The people who *are* requiring Diameter in new deployments
> are the large telecom providers, who can afford big bucks=20
> for new equipment.  Everyone else in the world is stuck with
> whatever the vendors implement: RADIUS.

This is the part that I've never really understood.  Is the issue that
equipment vendors choose not to offer Diameter clients in version
upgrades of the operating SW/FW for their equipment?  Is Diameter only
available on new equipment (forklift upgrade)?

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

Envelope-to: [email-masked]
Delivery-date: Tue, 27 Jun 2006 18:23:19 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: The RADIUS attribute space: an assessment 
cc: [email-masked]
Date: Tue, 27 Jun 2006 14:13:45 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> A recent, off list, discussion about some substantial enhancements
> to the RADIUS protocol as opposed to deployment of Diameter, has
> brought this home.  The impediment to Diameter deployment in this
> instance is that lack of complete, robust, open source
> implementations of Diameter, coupled with readily available open
> source RADIUS implementations and wide deployment of RADIUS.

  Many of the superior features of Diameter are already deployed in
RADIUS.  Radsec, SRV record lookups, vendor attributes, etc. all
mitigate the real-world need to move to Diameter.

  But that's not all.

> The IETF can provide a standardized specification of a better
> protocol, but it can make vendors and operators deploy it.

  To a large extent the operators don't have a choice.  The people who
*are* requiring Diameter in new deployments are the large telecom
providers, who can afford big bucks for new equipment.  Everyone else
in the world is stuck with whatever the vendors implement: RADIUS.

  Since existing deployments can't upgrade to Diameter, they're forced
to extend the life of their current systems by adding new features to
RADIUS servers on whiteboxes.  It seems to work quite well in
practice, which further minimizes the demand on NAS vendors to
implement Diameter.

  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, 27 Jun 2006 17:25:40 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: The RADIUS attribute space: an assessment
Date: Tue, 27 Jun 2006 10:25:20 -0700

Mauricio said:

>Wasn't there a draft previously that talked to making the RADIUS message
>format a bit more Diameter-like?  What happened to that draft?  Maybe that
>could be used as a beginning for this problem?

There were two proposals that were discussed:
http://www.watersprings.org/pub/id/draft-wolff-radext-ext-attribute-00.txt
http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt

Here are pointers to other proposals that have been made over the years:
http://www.watersprings.org/pub/id/draft-lior-radius-attribute-type-extension-00.txt
http://www.watersprings.org/pub/id/draft-tjoens-aaa-radius-00.txt

>I assume you're about to propose that this general problem be a WG work 
>item?

It is already on the charter:

Oct 2006    RADIUS Extended Attributes submitted as a Proposed Standard RFC

--
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, 27 Jun 2006 15:29:08 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space:  an assessment
Date: Tue, 27 Jun 2006 11:28:56 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Mauricio Sanchez writes...

> Sounds like this topic would be good to add to the=20
> agenda of the upcoming meeting.

We'll add slots for the Design Guidelines and Extended Attributes
documents.  We'll find suitable presenters, either the authors or
someone else.

--
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, 27 Jun 2006 15:22:21 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space:  an assessment
Date: Tue, 27 Jun 2006 08:21:44 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0115_01C69A0B.4596B420
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dave points out....
> 
> Mauricio Sanchez writes...
> 
> > Wasn't there a draft previously that talked to making the RADIUS 
> > message format a bit more Diameter-like?
> 
> Yes.
> 
> > What happened to that draft?
> 
> It was discussed at IETF-65, and maybe a little on the list.  
> There was substantial push-back.  Some folks didn't like the 
> idea of extending RADIUS, some didn't like the Diameter 
> format, and others has their own favorite format for and 
> extended attribute.  In short, no consensus.
> 
> > Maybe that could be used as a beginning for this problem? 
> 
> Yes, I think so.  We first need to agree that there is a 
> problem.  Some think that the "problem" is simply failing to 
> migrate to Diameter.  We then need to renew the discussion, 
> with the idea of finding an acceptable solution.
> 
> > I assume you're about to propose that this general problem be a WG 
> > work item?
> 
> There is currently a milestone on our charter page for 
> Extended Attributes.  It is a normative dependency of the 
> Design Guidelines document.

Sounds like this topic would be good to add to the agenda of the upcoming
meeting.  Who's sheparding the design guidelines draft these days? Maybe
that person could MC the debate. Or perhaps the person that did the original
extended attributes draft.

MS

------=_NextPart_000_0115_01C69A0B.4596B420
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0115_01C69A0B.4596B420--

--
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, 27 Jun 2006 14:50:51 +0000
Content-class: urn:content-classes:message
Subject: Final IETF-66 Agenda
Date: Tue, 27 Jun 2006 10:50:20 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

The RADEXT session remains scheduled for Monday morning.

MONDAY, July 10, 2006
0800-1800 IETF Registration - Foyer 500D
0800-0900 Continental Breakfast - Foyer 500D
0900-1130 Morning Session I
Room 518AB        APP  apparea   Applications Area Open Meeting
Room 515          INT  ancp 	   Access Node Control Protocol
Room 513C-F       INT  netlmm    Network-based Localized Mobility =
Management WG
Room 519A         OPS  radext    RADIUS EXTensions WG
Room 520DEF       RAI  enum      Telephone Number Mapping WG
Room 520ABC       RTG  ccamp     Common Control and Measurement Plane WG
Room 513B         SEC  krb-wg    Kerberos WG WG
Room 519B         TSV  tsvwg     Transport Area Working Group WG
=A0

--
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, 27 Jun 2006 14:18:07 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space:  an assessment
Date: Tue, 27 Jun 2006 10:18:00 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Ooops.

> The IETF can provide a standardized specification of a=20
> better protocol, but it can make vendors and operators=20
> deploy it.

That's "...can't make vendors...".

--
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, 27 Jun 2006 14:14:28 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space:  an assessment
Date: Tue, 27 Jun 2006 10:14:23 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Mauricio Sanchez writes...

> Wasn't there a draft previously that talked to making=20
> the RADIUS message format a bit more Diameter-like?

Yes.

> What happened to that draft?

It was discussed at IETF-65, and maybe a little on the list.  There was
substantial push-back.  Some folks didn't like the idea of extending
RADIUS, some didn't like the Diameter format, and others has their own
favorite format for and extended attribute.  In short, no consensus.

> Maybe that could be used as a beginning for this problem?=20

Yes, I think so.  We first need to agree that there is a problem.  Some
think that the "problem" is simply failing to migrate to Diameter.  We
then need to renew the discussion, with the idea of finding an
acceptable solution.

> I assume you're about to propose that this general problem=20
> be a WG work item?

There is currently a milestone on our charter page for Extended
Attributes.  It is a normative dependency of the Design Guidelines
document.

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

Delivery-date: Tue, 27 Jun 2006 14:07:26 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space:  an assessment
Date: Tue, 27 Jun 2006 10:06:50 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Glen Zorn writes...
=20
> A far better idea might be for the IESG to finally take some action,
> deprecating RADIUS and actually supporting Diameter to solve one of
the
> problems for which it was designed.

Why would that be a better idea?  Except, perhaps, on some
self-congratulatory level?  I've observed that the IESG doesn't have
much influence over what the rest of the world chooses to implement.  A
recent, off list, discussion about some substantial enhancements to the
RADIUS protocol as opposed to deployment of Diameter, has brought this
home.  The impediment to Diameter deployment in this instance is that
lack of complete, robust, open source implementations of Diameter,
coupled with readily available open source RADIUS implementations and
wide deployment of RADIUS.  The IETF can provide a standardized
specification of a better protocol, but it can make vendors and
operators deploy it.

What would likely happen, if the IESG were to "deprecate" RADIUS, is
that implementers will simply continue to extend RADIUS using the Vendor
Specific Attribute.  I don't see any advantage in taking that route.

The IESG could "support" Diameter by funding (or otherwise stimulating)
the creation of complete, robust, well-documented open source
implementations of Diameter.  However, I don't think the IESG is in that
business.

--
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, 27 Jun 2006 09:57:10 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space:  an assessment
Date: Tue, 27 Jun 2006 02:56:56 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Sanchez, Mauricio \(ProCurve\)" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Sanchez, Mauricio (ProCurve) <> supposedly scribbled:

> Wasn't there a draft previously that talked to making the RADIUS
> message format a bit more Diameter-like?  What happened to that
> draft?  Maybe that could be used as a beginning for this problem?  I
> assume you're about to propose that this general problem be a WG work
> item?   =20

A far better idea might be for the IESG to finally take some action,
deprecating RADIUS and actually supporting Diameter to solve one of the
problems for which it was designed. =20

>=20
> MS
>=20
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Bernard Aboba
>> Sent: Tuesday, June 27, 2006 7:58 AM
>> To: [email-masked]
>> Subject: The RADIUS attribute space: an assessment
>>=20
>> At various points, authors of extended attribute space proposals have
>> pointed out the potential for exhaustion of the RADIUS attribute
>> space defined in RFC 2865.   Based on an examination of the
>> attribute needs of
>> current and projected IETF WG work items, I believe this concern is
>> quite real.=20
>>=20
>> Based on the IANA web page and RFC 3575, currently RADIUS attributes
>> 123-191 are eligible for assignment.  Of these, 5 attributes need to
>> be allocated for documents that have currently completed IETF last
>> call (Delegated-Prefix and VLAN/Priority attributes).  An additional
>> 5 attributes are required for documents that have undergone WG last
>> call (RADIUS GEOPRIV and filter attributes). This will leave a total
>> of 58 attributes unassigned (133-191).
>>=20
>> A look at the remaining RADEXT WG work items seems to indicate that
>> they could consume somewhere between 25 and 35 attributes.   This
>> would leave
>> between 23 and 33 attributes remaining.
>>=20
>> Recently, the MIPv4 WG submitted a request to charter work on
>> MIPv4 attributes for RADIUS.  The current draft requests the
>> allocation of 31 attributes.=20
>>=20
>> It would therefore appear that the need for additional attribute
>> space is quite real, and rather immediate (e.g.
>> next 12-18 months).
>>=20
>>=20
>>=20
>> --
>> to unsubscribe send a message to [email-masked] with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://psg.com/lists/radiusext/>

Hope this helps,

~gwz

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

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

Delivery-date: Tue, 27 Jun 2006 09:41:16 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space:  an assessment
Date: Tue, 27 Jun 2006 02:40:44 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_00BF_01C699DE.86A24A10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Wasn't there a draft previously that talked to making the RADIUS message
format a bit more Diameter-like?  What happened to that draft?  Maybe that
could be used as a beginning for this problem?  I assume you're about to
propose that this general problem be a WG work item?

MS

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Tuesday, June 27, 2006 7:58 AM
> To: [email-masked]
> Subject: The RADIUS attribute space: an assessment
> 
> At various points, authors of extended attribute space 
> proposals have pointed out the potential for exhaustion of 
> the RADIUS attribute space 
> defined in RFC 2865.   Based on an examination of the 
> attribute needs of 
> current and projected IETF WG work items, I believe this 
> concern is quite real.
> 
> Based on the IANA web page and RFC 3575, currently RADIUS 
> attributes 123-191 are eligible for assignment.  Of these, 5 
> attributes need to be allocated for documents that have 
> currently completed IETF last call (Delegated-Prefix and 
> VLAN/Priority attributes).  An additional 5 attributes are 
> required for documents that have undergone WG last call 
> (RADIUS GEOPRIV and filter attributes). This will leave a 
> total of 58 attributes unassigned (133-191).
> 
> A look at the remaining RADEXT WG work items seems to 
> indicate that they 
> could consume somewhere between 25 and 35 attributes.   This 
> would leave 
> between 23 and 33 attributes remaining.
> 
> Recently, the MIPv4 WG submitted a request to charter work on 
> MIPv4 attributes for RADIUS.  The current draft requests the 
> allocation of 31 attributes.
> 
> It would therefore appear that the need for additional 
> attribute space is quite real, and rather immediate (e.g. 
> next 12-18 months).
> 
> 
> 
> --
> 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/>
> 

------=_NextPart_000_00BF_01C699DE.86A24A10
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00BF_01C699DE.86A24A10--

--
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, 27 Jun 2006 08:13:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Request for Review:  NAS-Filter-Rule Specification
Date: Tue, 27 Jun 2006 01:11:24 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Bernard Aboba <> supposedly scribbled:

> As noted in the message below, it has been proposed that the RADEXT
> WG issue a document enabling use of the NAS-Filter-Rule defined in
> RFC 4005 within RADIUS, while at the same continuing work on the
> NAS-Traffic-Rule attribute:
> http://ops.ietf.org/lists/radiusext/2006/msg00560.html  =20
>=20
> A document specifying the NAS-Filter-Rule attribute is now available
> for=20
> inspection:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-00.txt
>=20
> Please review this document and post comments to the list.

Quick note: it appears that the minimum length of this attribute is =
actually 35 (Type+Length+"deny in 1 from 1.2.3.4 to 2.3.4.5"), rather =
than 3 as stated in section 2.

Hope this helps,

~gwz

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

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

Delivery-date: Tue, 27 Jun 2006 05:58:30 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: The RADIUS attribute space:  an assessment
Date: Mon, 26 Jun 2006 22:58:08 -0700

At various points, authors of extended attribute space proposals have 
pointed out the potential for exhaustion of the RADIUS attribute space 
defined in RFC 2865.   Based on an examination of the attribute needs of 
current and projected IETF WG work items, I believe this concern is quite 
real.

Based on the IANA web page and RFC 3575, currently RADIUS attributes 123-191 
are eligible for assignment.  Of these, 5 attributes need to be allocated 
for documents that have currently completed IETF last call (Delegated-Prefix 
and VLAN/Priority attributes).  An additional 5 attributes are required for 
documents that have undergone WG last call (RADIUS GEOPRIV and filter 
attributes). This will leave a total of 58 attributes unassigned (133-191).

A look at the remaining RADEXT WG work items seems to indicate that they 
could consume somewhere between 25 and 35 attributes.   This would leave 
between 23 and 33 attributes remaining.

Recently, the MIPv4 WG submitted a request to charter work on MIPv4 
attributes for RADIUS.  The current draft requests the allocation of 31 
attributes.

It would therefore appear that the need for additional attribute space is 
quite real, and rather immediate (e.g. next 12-18 months).

--
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, 27 Jun 2006 05:26:26 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Request for Review:  NAS-Filter-Rule Specification
Date: Mon, 26 Jun 2006 22:25:58 -0700

As noted in the message below, it has been proposed that the RADEXT WG issue 
a document enabling use of the NAS-Filter-Rule defined in RFC 4005 within 
RADIUS, while at the same continuing work on the NAS-Traffic-Rule attribute:
http://ops.ietf.org/lists/radiusext/2006/msg00560.html

A document specifying the NAS-Filter-Rule attribute is now available for 
inspection:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-00.txt

Please review this document and post comments to the list.

--
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, 26 Jun 2006 14:40:05 +0000
Content-class: urn:content-classes:message
Subject: Second call for RADEXT WG agenda items
Date: Mon, 26 Jun 2006 10:39:31 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, "Bernard Aboba" <[email-masked]>

WG agendas for IETF-66 are due no later than July 3, one week from
today.  The chairs have received a couple of agenda requests, so far.
Now is the time to submit your request if you have a document or other
item to discuss during the RADEXT session at IETF-66.

Please send your request, including the topic, document to be discussed,
and the desired presentation slot duration, to the chairs ASAP.  Thanks!

Bernard and Dave=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, 25 Jun 2006 08:19:04 +0000
Date: Sun, 25 Jun 2006 10:18:27 +0200
From: Hannes Tschofenig <[email-masked]>
To:  [email-masked],  [email-masked],  [email-masked]
Subject: [Fwd: [Dime] Diameter QoS Dinner]

Hi all,

NSIS, TSVWG, RADEXT WG members might also be interested in the Diameter 
Quality of Service dinner.

We plan to meet at the registration desk at 19:30 after the Welcome 
Reception on Sunday. See my previous mail:
http://www1.ietf.org/mail-archive/web/dime/current/msg00401.html

Please let me know if you plan to show up.

Ciao
Hannes

-------- Original Message --------
Subject: 	[Dime] Diameter QoS Dinner
Date: 	Mon, 19 Jun 2006 14:14:39 +0200
From: 	Tschofenig, Hannes <[email-masked]>
To: 	<[email-masked]>

Hi all,

it would be good to meet Diameter QoS interested folks at the next IETF
for a discussion about possible next steps before the DIME session.

The DIME WG session will be on***** MONDAY, July 10, 2006** *
*1740-1840 Afternoon Session III*
Room 519B       APP     _widex_
<http://www.ietf.org/html.charters/widex-charter.html>   Widget
Description Exchange Service WG
Room 520ABC     INT     _softwire_
<http://www.ietf.org/html.charters/softwire-charter.html>
Softwires WG
Room 519A       IRTF    NMRG    Network Management Research Group
Charter
*Room 513C-F     OPS     **_dime_*
<http://www.ietf.org/html.charters/dime-charter.html>*    Diameter
Maintenance and Extensions WG
*Room 520DEF     RAI     rtpsec  Securing the Real-time Transport
Protocol BOF
Room 513B       SEC     _sasl_
<http://www.ietf.org/html.charters/sasl-charter.html>    Simple
Authentication and Security Layer WG
Room 518AB      TSV     _tsvwg_
<http://www.ietf.org/html.charters/tsvwg-charter.html>   Transport Area
Working Group WG
_https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=66_ 

Hence, there is only time after the Welcome Reception on Sunday. My
proposal would be to meet  at the registration desk at 19:30.

Please send me a mail if you are interested.

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

Delivery-date: Sat, 24 Jun 2006 23:57:21 +0000
Content-class: urn:content-classes:message
Subject: Issue 192: Comments
Date: Sat, 24 Jun 2006 16:56:55 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0118_01C697AF.32DC09B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Jouni wrote.... 

> Issue 192: Comments
> Submitter name: Jouni Korhonen
> Submitter email address: [email-masked] Date 
> first submitted: April 26, 2006
> Reference: http://ops.ietf.org/lists/radiusext/2006/msg00480.html
> Document: Filter-00
> Comment type: Technical
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> I had a quick look at this draft. A few initial comments:
> 
>  o Introduction talks about 'home realm' and in the same
>    sentence also about 'local operator'. Maybe changing
>    home realm to home operator would be better?

I'm open to this suggestion.  It does seem more succinct when the home
operator term is used.

> 
>  o Introduction also discusses VLANs. I think that text
>    there does not really belong to this draft anymore.

Sounds appropriate.  We'll back off the usage of VLANs as a driving use case
and focus on what specifically drives the need for these attributes. 

> 
>  o terminology section lists Authenticator, Authentication
>    Server and Supplicant even if those are not used in the
>    text outside the terminology section. Imho a reference
>    to 802.1X should be enough
>

I remember adding this terms into the terminology section after group
discussion.  I remember people wanting additional detail around this and
having only a reference to 802.1X did not seem like enough.  I'll push back
and say that unless you really think having these terms are distraction,
then we should just leave them in. 

>  o hot-lining is also only mentioned in the terminology
>    section. Should there be some more text in the draft
>    itself about hot-lining e.g. in form of motivation for
>    this draft? Actually I would like to see a general
>    short motivation section somewhere under section 1

Hmmm, previous version talked about hotlining and people started to feel
that it was getting to be a distraction in the introduction. Elaboration on
hotlining was cut down to what it is now. Why do you feel we need to add
more motivation based on hot-lining?

>  o what is the purpose of the rule-delim in the
>    NAS-Traffic-Rule ABNF? As far as I interpreted the
>    ABNF there can be only one rule per attribute anyway?
>    I could be wrong ;)

The first version of the syntax had no rule delimiter and people commented
that having a delimiter would eliminate any possibility for ambiguity of
rule end. 

> 
>  o in the NAS-Traffic-Rule why there could not be
>     - ip-proto = ["!"] d8
>     - tcp-ports = ["!"] tcp-port *("," tcp-port)
> 
>    That would ease blocking of specific ports and 
>    protocols. E.g. in case of trying to block some
>    virus/worm generated traffic, while allowing 
>    everything else..

There no strong reason anymore why this couldn't be done.  It used to be an
argument of remaining true to the L3-L4 capabilities specified by Diameter's
IPFilterRule to facilitate translation.  However,  given that we're going
down the path of creating a Diameter AVP for NAS-Traffic-Rule, we probably
no longer need to constrain ourselves to the limitations of the IPFilterRule
syntax. 

>  
>  o tcp-port name might be a bit misleading as ports are
>    also used for other protocols. Maybe just using
>    ports or similar?

How about 'layer4-port' or 'l4-port'?

> 
>  o What's the intended use for the L2 filtering? I'd
>    like to see some real use case described here 

BPDU filtering is one real use case. 

> 
>  o section 3.1 Acct-NAS-Traffic-Rule attribute definition
>     - the length should probably be >= 11
>     - The 'String' should probably be 'Counter'
>     - the description for 'Text' is missing

Ok.

> 
>  o Security considerations mention VLAN-related attributes
>    several times although those are now in a separate
>    document.

Ok. Will update.

> 
> Some nits:
> 
>  o section 2
>    s/one new RADIUS authentication attributes/...attribute

Ok.

MS

------=_NextPart_000_0118_01C697AF.32DC09B0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0118_01C697AF.32DC09B0--

--
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, 24 Jun 2006 02:38:10 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Issue 111: Accounting
Date: Fri, 23 Jun 2006 19:37:36 -0700

>GDW> What happens if I have an HTTP redirect rule with
>redir-cnt set to 10, and I send this rule in an
>Access-Accept (i.e. no CoA in the picture).  Wouldn't it
>be useful to get an Accounting-Request when the redirection
>is removed (redir-cnt goes to zero)?  Assuming that situation
>is not described in 3576bis, where would it be described?

It seems to me that this scenario is quite independent of RFC 3576bis.

--
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, 23 Jun 2006 19:47:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 170: Precedence and Order for NAS-Filter-Rule
Date: Fri, 23 Jun 2006 15:47:43 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> The Filter-Id attribute refers to a particular set of=20
> filters provisioned on the NAS.   This document says that=20
> NAS-Traffic-Rule is not to be sent along with Filter-Id. =20
> Yet somehow a filter set described by Filter-Id can be
> activated without any explicitly indications from the=20
> RADIUS server?  This seems to be contradictory.

I think the notion that is being described is that the NAS may have a
set of rules that are statically configured (outside the scope or
influence of RADIUS).  These may or may not be the same set(s) of rules
that can be named by the Filter-ID.

--
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, 23 Jun 2006 19:41:58 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Issue 170: Precedence and Order for NAS-Filter-Rule
Date: Fri, 23 Jun 2006 12:41:38 -0700

>Wow.  In other words, the entity that creates a NAS-Traffic-Rule
>attribute really has no idea what the aggregate traffic filtering
>behavior of a given NAS will be.  So what makes this new attribute useful?

The Filter-Id attribute refers to a particular set of filters provisioned on 
the NAS.   This document says that NAS-Traffic-Rule is not to be sent along 
with Filter-Id.  Yet somehow a filter set described by Filter-Id can be 
activated without any explicitly indications from the RADIUS server?  This 
seems to be contradictory.

>I can see this mechanism working in a predictable fashion only in
>certain situations, based on assumptions of the locally configured NAS
>rules that take precedence.

As I understood it, the whole point of this attribute was to enable the 
RADIUS server to explicitly specify the filters that would be in operation, 
even in situations where the server had no knowledge of what filters are 
provisioned on the NAS.  So this new approach does not make sense to me.

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

Delivery-date: Fri, 23 Jun 2006 18:43:16 +0000
Date: Fri, 23 Jun 2006 14:42:54 -0400
From: Barney Wolff <[email-masked]>
To: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: Issue 170: Precedence and Order for NAS-Filter-Rule

On Fri, Jun 23, 2006 at 11:03:12AM -0700, Sanchez, Mauricio (ProCurve) wrote:
> 
> Maybe we're just going down a rat hole here.  By even mentioning that there
> may be other rules in effect on the NAS, it feels like an opportunity for
> creating greater confusion.  I'd rather just stick to detailing how a
> particular facet of the overall network service is provisioned, rather then
> define what the overall network service consists of. 
> 
> Would we better served by just yanking out the statement in question?
> Thoughts?

Reality is that a sane NAS-owner will have rules in place to protect
its infrastructure, and that these rules will be applied before any
rules from the RADIUS server.  It seems to me that ignoring the issue
relieves present pain at the cost of greater future pain.

We all, I hope, would agree that the consequence of applying such
implicit (from the server's point of view) rules must be tighter
restriction, not looser.

Regards,
Barney Wolff

--
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, 23 Jun 2006 18:04:24 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 170: Precedence and Order for NAS-Filter-Rule 
Date: Fri, 23 Jun 2006 11:03:12 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0098_01C696B4.9E60EDF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dave responds...

> > "A NAS MAY apply additional rules (deny, redirect, etc.) of its own 
> > before, in between, or after rules specified with 
> NAS-Traffic-Rule.  
> > For example, these additional rules may protect the access device 
> > owner's infrastructure.
> > Management of these additional rules is out of scope and are not 
> > subject to the semantics or behaviors described for 
> NAS-Traffic-Rule."
> 
> Wow.  In other words, the entity that creates a 
> NAS-Traffic-Rule attribute really has no idea what the 
> aggregate traffic filtering behavior of a given NAS will be.  
> So what makes this new attribute useful?
>  
> > The guidelines for rule ordering are only relevant for those 
> > controlled via this RADIUS specification.  I see it as out 
> of scope on 
> > mandating how non-RADIUS rules should behave.
> 
> Fair enough.  I still wonder how useful this attribute will 
> be if the administrator that sets it up has no idea which (if 
> any) of the elements he has specified will be enforced by the 
> NAS, and which (potentially
> all) of the elements are superseded by a local NAS filtering rule.
> 
> I can see this mechanism working in a predictable fashion 
> only in certain situations, based on assumptions of the 
> locally configured NAS rules that take precedence.

Yes, I agree.  What is assumed is vital to the overall predictibility of a
solution.  Fortuntately, I think in most instances it's safe to assume that
the NAS doesn't have any locally configured NAS rules that will adversely
interfere with those being provisioned by RADIUS.

Maybe we're just going down a rat hole here.  By even mentioning that there
may be other rules in effect on the NAS, it feels like an opportunity for
creating greater confusion.  I'd rather just stick to detailing how a
particular facet of the overall network service is provisioned, rather then
define what the overall network service consists of. 

Would we better served by just yanking out the statement in question?
Thoughts?

MS

------=_NextPart_000_0098_01C696B4.9E60EDF0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0098_01C696B4.9E60EDF0--

--
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, 23 Jun 2006 17:37:32 +0000
Content-class: urn:content-classes:message
Subject: Proposed comment resolution for 2618bis-2621bis drafts
Date: Fri, 23 Jun 2006 13:37:22 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

The following Gen-ART review was received on the subject I-D, which as
completed IETF Last Call.

I propose to accept the comments from this review and apply them to all
four documents (2618bis-2621bis) as applicable, as well as the IETF LC
comment on the typos in 2620bis and 2621bis (see
https://ops.ietf.org/lists/radiusext/2006/msg00510.html).  I will
prepare revised I-Ds on all four RADIUS IPv6 MIBs, and submit them prior
to the deadline on Monday, June 26 (probably by this afternoon, in
fact).

If anyone in WG objects to resolving the IETF LC and Gen-ART review
comments as proposed, please reply to this message.

----------------  Begin review  ----------------

Summary: This draft is on the right track but has an open issue,
	described in the review.

I really only have one major concern that I think NEEDS to be
addressed and that is that the security concerns are not complete.
The two minor comments are to improve the clarity and need not delay
things, but since an update may well be needed they may as well be
addressed at the same time.  The typo, of course, can be fixed any
time up to and including AUTH48 with the RFC editor.

I'll also note that except for the Security Considerations comment
these also apply to the rfc2619bis draft as well, however I didn't
review it, just looked at these points (but I did notice a typo ["cab"
instead of "can" in paragraph 2 of Security Considerations in
rfc2619bis] that you could fix).  I figured I'd just mention that
since the two drafts have the same author

Major concerns
--------------

In the list of sensitive objects in the security section, you list
both the address and the port objects in the new table, but only the
address and not the port in the deprecated table.  I'd expect the port
number there to be as sensitive.  Also, while nowhere near as
sensitive as the address and port, the address type also potentially
leaks useful info.

Minor comments
--------------

Is RFC4001 Normative?  The Textual conventions defined there are used
here.  I would think that would make it normative to the definitions
in this document.  This MIB imports from INET-ADDRESS-MIB which is
defined in RFC4001, so I think it must be normative.  But, I am not a
MIB expert, so I could be mistaken, of course.

Is the server MIB also being updated?  I see there's a draft for
that.  I suggest that it should be referenced at least in Section 5
second paragraph.  Perhaps more than just citing it include a sentence
about "client in this doc and server in [RFCtbd]".  Of course, this
should be symmetrical, that doc should ref this one.

----------------------------------------------------------------
   The following typo is noted for the convenience of possible copy
   editors but is not part of the technical review.

Typos
-----

In the abstract, the third sentence needs a comma after "extensions".

--
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, 23 Jun 2006 17:15:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 170: Precedence and Order for NAS-Filter-Rule 
Date: Fri, 23 Jun 2006 13:15:28 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Mauricio Sanchez writes...

> "A NAS MAY apply additional rules (deny, redirect, etc.)=20
> of its own before, in between, or after rules specified=20
> with NAS-Traffic-Rule.  For example, these additional rules
> may protect the access device owner's infrastructure.
> Management of these additional rules is out of scope and are=20
> not subject to the semantics or behaviors described for=20
> NAS-Traffic-Rule."

Wow.  In other words, the entity that creates a NAS-Traffic-Rule
attribute really has no idea what the aggregate traffic filtering
behavior of a given NAS will be.  So what makes this new attribute
useful?
=20
> The guidelines for rule ordering are only relevant for those
> controlled via this RADIUS specification.  I see it as out of
> scope on mandating how non-RADIUS rules should behave.

Fair enough.  I still wonder how useful this attribute will be if the
administrator that sets it up has no idea which (if any) of the elements
he has specified will be enforced by the NAS, and which (potentially
all) of the elements are superseded by a local NAS filtering rule.

I can see this mechanism working in a predictable fashion only in
certain situations, based on assumptions of the locally configured NAS
rules that take precedence.

--
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, 23 Jun 2006 16:44:47 +0000
Content-class: urn:content-classes:message
Subject: Issue 170: Precedence and Order for NAS-Filter-Rule 
Date: Fri, 23 Jun 2006 09:44:30 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Greg Weber (gdweber)" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0093_01C696A9.A00D3F60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Greg stated...

>At the very end of Section 2.5 on NAS-Filter-Rule,
>it says that the NAS can apply rules of its own before
>rules supplied via the interface in this document.
>I didn't understand the ordering and precedence 
>between filters originated from the different sources.

I see your point.  The thought was not to give complete treatment to all
possible active rules sets (i.e. those specified by RADIUS, those configured
locally, those rule the PEP enforces because of security considerations),
but at least acknowledge that other active rules do exist and that they may
influence the ultimate forwarding decision.  What if the statement in
question were changed as follows?

"A NAS MAY apply deny rules of its own before the supplied rules, for
example to protect the access device owner's infrastructure."

To 

"A NAS MAY apply additional rules (deny, redirect, etc.) of its own before,
in between, or after rules specified with NAS-Traffic-Rule.  For example,
these additional rules may protect the access device owner's infrastructure.
Management of these additional rules is out of scope and are not subject to
the semantics or behaviors described for NAS-Traffic-Rule."

>Is that covered somewhere?  If the server sends a 
>flush-rule via CoA-Request, does that remove the 
>NAS originated (configured) rules?  The text is implying

By NAS originated do you mean those rule sets not assigned via the RADIUS
interface?  If so, then the answer is no.  The process of assignment,
updates, and flushing only affect those rules controlled by RADIUS.  

>that the rules are applied in specific order based on 
>type, e.g. HTTP filter rules are last.  What if the NAS
>defines the HTTP filter rule, and other types come via 
>CoA?  What's the order then?  This seems like an area
>of likely implementation confusion.

If that HTTP filter was not assigned through the RADIUS interface, then
flushes and CoA messages have no effect on it. 

The guidelines for rule ordering are only relevant for those controlled via
this RADIUS specification.  I see it as out of scope on mandating how
non-RADIUS rules should behave. 

>
>Requested change:
>I think the precedence of locally configured rules
>relative to dynamic updates needs to be clarified.  
>It might also be useful to treat this in the examples
>of Appendix B.  This seems similar to Issue 107
>related to Acct-Interim-Interval.  The NAS owner needs
>to be able to protect his resources, and the server
>owner needs predictable results for dynamic updates.

MS

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
ProCurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5557
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------   

------=_NextPart_000_0093_01C696A9.A00D3F60
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0093_01C696A9.A00D3F60--

--
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, 23 Jun 2006 15:00:37 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG at IETF-66
Date: Fri, 23 Jun 2006 11:00:01 -0400
From: "Nelson, David" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Cc: <[email-masked]>

Glen Zorn  writes...
=20
> Sure: the milestone I had missed says "RADIUS Crypto-agility draft
(e.g.
> FIPS 140-2 compliance for RADIUS) submitted as a Proposed Standard RFC
> (split out from WLAN attributes draft)"; that says to me that a) there
is
> a goal & b) how that goal will be accomplished (in some detail: "split
out
> from WLAN attributes draft").

Ah.  I see how the milestone might be read that way.  The intent was to
track the transfer of milestone deliverables as they were split.  I
don't think the intent was ever to foreclose discussion of which
specific draft and exactly which text would eventually meet the goal.

We have, in fact, discussed your draft on this subject on the list.  I
may be mistaken, but as I recall there were questions raised on the list
and at one or more IETF meetings that were never fully answered.

Discussion of solution approaches on this deliverable is open, as long
as it results in open discussion.  Any draft author seeking to submit a
WG work items need to be prepared to answer questions, accept and
incorporate comments and cede change control of their draft to the WG.

I know you were somewhat annoyed that Bernard would offer a competing
solution to your key-wrap draft, but that's the IETF process.  I
encourage you to rejoin in active discussion, as we get closer to
addressing this particular milestone.

--
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, 23 Jun 2006 01:28:08 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG at IETF-66
Date: Thu, 22 Jun 2006 18:27:41 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Nelson, David <> supposedly scribbled:

...

>> Apparently there's no need, since the method by which
>> "crypto-agility" will be attained has already been decided.
>=20
> You've lost me here.  The work item is to address the "crypto-agility"
> requirements coming out of SAAG.  Could you please elaborate?=20

Sure: the milestone I had missed says "RADIUS Crypto-agility draft (e.g. =
FIPS 140-2 compliance for RADIUS) submitted as a Proposed Standard RFC =
(split out from WLAN attributes draft)"; that says to me that a) there =
is a goal & b) how that goal will be accomplished (in some detail: =
"split out from WLAN attributes draft").  What was in the WLAN =
attributes draft (and presumably will soon be in a new crypto-agility =
draft) reflected a particular approach & viewpoint; from the wording of =
the milestone, I can only assume that that is the approach to be taken.  =

> Decided when?  By whom?=20

I've no idea, but I would think that you would.

Hope this helps,

~gwz

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

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

Delivery-date: Thu, 22 Jun 2006 22:51:07 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-dynauth-server-mib-06.txt 
Date: Thu, 22 Jun 2006 18:50:02 -0400

--NextPart

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

	Title		: Dynamic Authorization Server MIB
	Author(s)	: S. De Cnodder, et al.
	Filename	: draft-ietf-radext-dynauth-server-mib-06.txt
	Pages		: 28
	Date		: 2006-6-22
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes the Remote Authentication Dial In User
   Service (RADIUS) [RFC2865] Dynamic Authorization Server (DAS)
   functions that support the dynamic authorization extensions as
   defined in RFC 3576.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-06.txt

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-dynauth-server-mib-06.txt

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Thu, 22 Jun 2006 22:50:51 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-dynauth-client-mib-06.txt 
Date: Thu, 22 Jun 2006 18:50:02 -0400

--NextPart

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

	Title		: Dynamic Authorization Client MIB
	Author(s)	: S. De Cnodder, et al.
	Filename	: draft-ietf-radext-dynauth-client-mib-06.txt
	Pages		: 30
	Date		: 2006-6-22
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes the Remote Authentication Dial In User
   Service (RADIUS) [RFC2865] Dynamic Authorization Client (DAC)
   functions that support the dynamic authorization extensions as
   defined in RFC 3576.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-06.txt

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-dynauth-client-mib-06.txt

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Thu, 22 Jun 2006 21:58:46 +0000
Content-class: urn:content-classes:message
Subject: Issue 169: Handling Unparsable NAS-Filter-Rule  
Date: Thu, 22 Jun 2006 14:58:32 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: <[email-masked]>
Cc: "Greg Weber (gdweber)" <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_005C_01C6960C.5403B1A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Greg pointed out...

>Issue 169: Handling Unparsable NAS-Filter-Rule 
>Submitter names: Greg Weber
>Submitter email address: [email-masked]
>Date first submitted: February 2, 2006
>Reference: http://ops.ietf.org/lists/radiusext/2006/msg00104.html
>Document: IEEE 802-01
>Comment type: Technical
>Priority: S
>Section: 1.4, 6
>Rationale/Explanation of issue:
>The NAS-Filter-Rule represents a *lot* of functionality.
>I think we can expect lots of variability in NASes which
>support various parts, e.g. maybe all the filtering, but
>not HTTP redirection, etc.  I think we maybe need to be
>clearer on what is supposed to happen when the NAS gets
>a CoA-Request or Access-Request containing directives
>that it cannot parse or apply.  In particular, in Section
>1.4 "Attribute Interpretation", I see text indicating that
>non-understood attributes result in Access-Rejects.  But,
>in Section 6 "Security Considerations", I see text like:
>"...a NAS could be configured to ... not accept any
>redirection rules if it is known they are not used in
>this environment."   These would seem to be contradictory.
>
>Requested change:
>Need clarification on the intent.

I hear you on this issue.  How about the change of section 1.4 to read from:

"If a NAS conforming to this specification receives an Access-Accept packet
containing an attribute defined in this document which it cannot apply, it
MUST act as though it had received an Access-Reject."

To 

"If a NAS conforming to this specification receives an Access-Accept packet
containing an attribute defined in this document which it cannot apply, it
MUST act as though it had received an Access-Reject.  A NAS may be incapable
of applying an attribute due to functional limitations of the NAS or
security reasons (as described in section 7 - Security Considerations)."

Does this help?

MS

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
ProCurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5557
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------   

------=_NextPart_000_005C_01C6960C.5403B1A0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_005C_01C6960C.5403B1A0--

--
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, 22 Jun 2006 21:20:59 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 111: Accounting
Date: Thu, 22 Jun 2006 14:20:41 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Greg Weber (gdweber)" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_004E_01C69607.0A6E0E00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Greg wrote... 

> -----Original Message-----
> From: Greg Weber (gdweber) [mailto:[email-masked]] 
> Sent: Thursday, June 22, 2006 1:59 PM
> To: Sanchez, Mauricio (ProCurve)
> Cc: Bernard Aboba; [email-masked]
> Subject: RE: Issue 111: Accounting

<...unnecessary part of message trimmed...>

> > 
> > In light that the treatment of accounting behavior would be best 
> > treated elsewhere, such as in 3576bis, I would suggest
> 
> GDW> What happens if I have an HTTP redirect rule with
> redir-cnt set to 10, and I send this rule in an Access-Accept 
> (i.e. no CoA in the picture).  Wouldn't it be useful to get 
> an Accounting-Request when the redirection is removed 
> (redir-cnt goes to zero)?  Assuming that situation is not 
> described in 3576bis, where would it be described?

It's an interesting question best answered by those folks that wanted http
redirection countdown in the first place (i.e. 3GPP2).  I, for one, could go
either way on this one.  I can see how one could argue to add it in as a
matter of completeness.  However, if no one comes up with a meaningful use
case, it does seem like a distraction. 

What would the accounting-request message contain?

> 
> > that we omit any discussion of accounting behavior in this draft.  
> > This means that sections 1.4 would be modified and section 
> A.3 would 
> > be eliminated to remove accounting references.
> 
> GDW> Would section 3, including the Acct-NAS-Traffic-Rule
> attribute, also be removed?

No, just the mention of accounting behavior in 1.4 and A.3.  The accounting
attribute would remain.  I will note that Bernard raised issue 167 with
similar concerns of accounting behavior and being compatible with RFC 2866
and RFC3576.  In that discussion thread, it appears we are reaching
consensus on leaving just a bit of description of accounting behavior in
section 1.4. 

I suggest you review Bernard's proposed text for issue 167 and let us know
whether you in agreement with the changes to section 1.4.  I'm still open to
removing section A.3. altogether (which issue 167 doesn't address at all).

I still feel that something like 3576bis or the like is the best place to
address questions about when to and when to generate accounting messages. 

MS

------=_NextPart_000_004E_01C69607.0A6E0E00
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_004E_01C69607.0A6E0E00--

--
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, 22 Jun 2006 20:59:25 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 111: Accounting
Date: Thu, 22 Jun 2006 16:59:12 -0400
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: "Sanchez, Mauricio \(PNB Roseville\)" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

=20
Mauricio,
A couple questions inline at GDW>=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Sanchez,=20
> Mauricio (PNB Roseville)
> Sent: Wednesday, February 01, 2006 7:50 PM
> To: Bernard Aboba; [email-masked]
> Subject: RE: Issue 111: Accounting
>=20
>=20
> Bernard noted a while back...=20
>=20
> > -----Original Message-----
> > From: [email-masked]=20
> > [mailto:[email-masked]] On Behalf Of Bernard Aboba
> > Sent: Sunday, November 13, 2005 10:17 PM
> > To: [email-masked]
> > Subject: Re: Issue 111: Accounting
> >=20
> > Here is what RFC 2866 says about the notion of an=20
> Accounting Session:
> >=20
> <...removed what RFC2866 says about accounting...>
> >=20
> > As Greg noted, the Service-Type is not being changed here, so=20
> > that the Service is continuing, and sending of additional=20
> > Start/Stop messages is somewhat odd.  Also, do we really want=20
> > individual RADIUS attributes to provide their own definitions=20
> > of when a new session is started and stopped? =20
> > RADIUS accounting is a separate protocol from RADIUS=20
> > authentication, and runs on a separate port.  Authentication=20
> > attributes that affect accounting (Class,=20
> > Acct-Interim-Interval) have to date been general ones. =20
> > Terminating the Accounting Session in mid-stream could cause=20
> > issues with RADIUS implementations that use the Accounting=20
> > Records for things like simultaneous usage control.
> >=20
> > Paul Congdon said:
> >=20
> > At IETF-64 we reviewed this issue.  There did not seem to be=20
> > any objection to having compliance statements in the Annex=20
> > given that this Annex is where the context for the statements=20
> > is developed.  Also, since a new session is created, as=20
> > stated in the draft, there is no need to use INTERM messages.
> >=20
> > --------------------------------------------------------------
> > -------------------
> > Issue 111: Accounting
> > Submitter name: Greg Weber
> > Submitter email address: [email-masked] Date first=20
> > submitted: August 10, 2005
> > Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html
> > Document: IEEE802-00
> > Comment type: T
> > Priority: S
> > Section: A.3
> > Rationale/Explanation of issue:
> >=20
> > The accounting requirements do not seem to be fully treated=20
> > by the draft.  Section A.3 has a MUST requirement related to=20
> > accounting.  I would think that MUST requirements should be=20
> > treated by the text, not in an appendix.  Why does=20
> > redirection require a STOP/START pair?  Can't this=20
> > information be conveyed via an INTERIM record for the same=20
> > session?  If the Service- Type is not changing, I'd think=20
> > that an INTERIM would suffice.
>=20
> In light that the treatment of accounting behavior would be=20
> best treated elsewhere, such as in 3576bis, I would suggest=20

GDW> What happens if I have an HTTP redirect rule with=20
redir-cnt set to 10, and I send this rule in an
Access-Accept (i.e. no CoA in the picture).  Wouldn't it
be useful to get an Accounting-Request when the redirection
is removed (redir-cnt goes to zero)?  Assuming that situation
is not described in 3576bis, where would it be described?

> that we omit any discussion of accounting behavior in this=20
> draft.  This means that sections 1.4 would be modified and=20
> section A.3 would be eliminated to remove accounting
> references.=20

GDW> Would section 3, including the Acct-NAS-Traffic-Rule=20
attribute, also be removed?

Greg
>=20
> Does this seem like a reasonable path?
>=20
> Cheers,
> MS
> =20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Thu, 22 Jun 2006 20:50:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 167: Compatibility with RFC 2866 and RFC 3576
Date: Thu, 22 Jun 2006 13:50:21 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0044_01C69602.CD786BC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I'm fine with leveraging the wording you note below for section 1.4 of the
filter draft.

MS 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, March 16, 2006 2:28 PM
> To: [email-masked]
> Subject: RE: Proposed Resolution to Issue 167: Compatibility 
> with RFC 2866 and RFC 3576
> 
> Note the text from the VLAN/Priority document on a similar subject:
> 
> 1.3.  Attribute Interpretation
> 
>    If a NAS conforming to this specification receives an Access-Accept
>    packet containing an attribute defined in this document which it
>    cannot apply, it MUST act as though it had received an 
> Access-Reject.
> 
>    Similarly, [RFC3576] requires that a NAS receiving a  CoA-Request
>    containing an unsupported attribute reply with a CoA-NAK.  It is
>    recommended that an Error-Cause attribute with value set to
>    "Unsupported Attribute" (401) be included in the packet.  
> As noted in
>    [RFC3576], authorization changes are atomic so that this situation
>    does not result in session termination and the pre-existing
>    configuration remains unchanged.  As a result, no 
> accounting packets
>    should be generated.
> 
> 
> >From: "Bernard Aboba" <[email-masked]>
> >To: [email-masked]
> >Subject: Proposed Resolution to Issue 167: Compatibility 
> with RFC 2866 
> >and RFC 3576
> >Date: Thu, 16 Mar 2006 14:12:04 -0800
> >
> >The text of Issue 167 is enclosed below.   The proposed 
> resolution is as 
> >follows:
> >
> >In Section 1.4, change:
> >
> >  1.4 Attribute Interpretation
> >
> >     Unless otherwise noted in the individual description of an
> >     attribute contained herein, a NAS that conforms to this
> >     specification and receives an Access-Accept message 
> that contains
> >     an attribute from this document that it cannot apply MUST
> >     interpret this though an Access-Reject had been sent and MUST
> >     terminate the session.  If accounting is enabled on the NAS, it
> >     MUST generate an Accounting-Request(Stop) message upon session
> >     termination.
> >
> >     Similarly, if a NAS conforming to this specification and also
> >     conforming to RFC 3576 [RFC3576] receives a CoA message that
> >     contains an attribute from this document that it cannot 
> apply, it
> >     MUST NOT terminate the session and MUST generate a 
> CoA-NAK packet
> >     with ERROR-CAUSE(101) set to "Unsupported Attribute"(401).  If
> >     accounting is enabled on the NAS, it MUST NOT generate an
> >     Accounting-Request(Stop) message in such instances.
> >
> >To:
> >
> >  1.4 Attribute Interpretation
> >
> >     Unless otherwise noted in the individual description of an
> >     attribute contained herein, a NAS that conforms to this
> >     specification and receives an Access-Accept message 
> that contains
> >     an attribute from this document that it cannot apply MUST
> >     interpret this though an Access-Reject had been sent and MUST
> >     terminate the session.
> >
> >     Similarly, if a NAS conforming to this specification and also
> >     conforming to RFC 3576 [RFC3576] receives a CoA message that
> >     contains an attribute from this document that it cannot 
> apply, it
> >     MUST NOT terminate the session and MUST generate a 
> CoA-NAK packet.
> >
> >-------------------------------------------------------------
> ----------
> >------------------------------ Issue 167: Compatibility with 
> RFC 2866 
> >and RFC 3576 Submitter names: Bernard Aboba Submitter email address: 
> >[email-masked] Date first submitted: January 30, 2006
> >Reference:
> >Document: IEEE 802-01
> >Comment type: Technical
> >Priority: S
> >Section: 1.4
> >Rationale/Explanation of issue:
> >
> >Section 1.4 states:
> >
> >  1.4 Attribute Interpretation
> >
> >     Unless otherwise noted in the individual description of an
> >     attribute contained herein, a NAS that conforms to this
> >     specification and receives an Access-Accept message 
> that contains
> >     an attribute from this document that it cannot apply MUST
> >     interpret this though an Access-Reject had been sent and MUST
> >     terminate the session.  If accounting is enabled on the NAS, it
> >     MUST generate an Accounting-Request(Stop) message upon session
> >     termination.
> >
> >     Similarly, if a NAS conforming to this specification and also
> >     conforming to RFC 3576 [RFC3576] receives a CoA message that
> >     contains an attribute from this document that it cannot 
> apply, it
> >     MUST NOT terminate the session and MUST generate a 
> CoA-NAK packet
> >     with ERROR-CAUSE(101) set to "Unsupported Attribute"(401).  If
> >     accounting is enabled on the NAS, it MUST NOT generate an
> >     Accounting-Request(Stop) message in such instances.
> >RFC 2866 does not specify the generation of Accounting Stop messages 
> >resulting from Access-Reject packets.  This document is therefore 
> >requiring RADIUS accounting clients to generate accounting 
> records in 
> >circumstances where they would not otherwise do so.  This raises the 
> >question of why this particular set of attributes would 
> cause a special 
> >case modification to RFC 2866.  Here is what RFC 3576 has to 
> say about 
> >receipt of attributes in a CoA-Request:
> >
> >  If one or more authorization changes specified in a CoA-Request  
> > cannot be carried out, or if one or more attributes or attribute-  
> > values is unsupported, a CoA-NAK MUST be sent.
> >
> >On inclusion of Error-Cause attributes:
> >
> >     It is possible that the NAS cannot honor Disconnect-Request or
> >     CoA-Request messages for some reason.  The Error-Cause Attribute
> >     provides more detail on the cause of the problem.  It MAY be
> >     included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
> >     messages.
> >
> >Since inclusion of an Error-Cause attribute is generally 
> optional, the 
> >second paragraph mandates behavior not required by RFC 3576.
> >
> >
> >
> >--
> >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/>
> 

------=_NextPart_000_0044_01C69602.CD786BC0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0044_01C69602.CD786BC0--

--
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, 22 Jun 2006 14:41:14 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG at IETF-66
Date: Thu, 22 Jun 2006 10:40:41 -0400
From: "Nelson, David" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Cc: <[email-masked]>

> Sorry, I was looking for something in the "Description
> of Working Group" section, maybe under "Work Items".

That might have been a good place to add a description, but we chose to
deal with this simply as a milestone update, after deciding that the
work was already in scope.

> >> ... are we going to discuss this?
> >
> > We can.
>=20
> Apparently there's no need, since the method by which "crypto-agility"
> will be attained has already been decided.

You've lost me here.  The work item is to address the "crypto-agility"
requirements coming out of SAAG.  Could you please elaborate?  Decided
when?  By whom?

--
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, 22 Jun 2006 00:50:32 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG at IETF-66
Date: Wed, 21 Jun 2006 17:50:05 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Nelson, David <mailto:[email-masked]> supposedly scribbled:

> Glen Zorn writes...
>=20
>> Looking at the WG charter, I notice that so-called "crypto agility"
>> has not yet been added; ...
>=20
> From the RADEXT WG charter page:
>=20
> <quote>
>=20
> Goals and Milestones:
>=20
> <snip>
>=20
> Dec 2006    RADIUS Crypto-agility draft (e.g. FIPS 140-2 compliance
> for=20
> RADIUS) submitted as a Proposed Standard RFC (split out from WLAN
> attributes draft)=20
>=20
> </quote>
>=20
> So it appears to me that it *has* been added to the WG charter.

Sorry, I was looking for something in the "Description of Working Group" =
section, maybe under "Work Items".
 =20
>=20
>> ... are we going to discuss this?
>=20
> We can.

Apparently there's no need, since the method by which "crypto-agility" =
will be attained has already been decided.

>=20
>> How about other new work items?
>=20
> We will prioritize the session time so as to facilitate meeting
> short-term WG milestones. If there is time available, we can discuss
> new work items.  We do need to maintain our focus on meeting all our
> milestones, however.  =20

Hope this helps,

~gwz

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

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

Delivery-date: Wed, 21 Jun 2006 14:02:31 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG at IETF-66
Date: Wed, 21 Jun 2006 10:01:58 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Glen Zorn \(gwz\)" <[email-masked]>

Glen Zorn writes...

> Looking at the WG charter, I notice that so-called "crypto agility"
has
> not yet been added; ...

>From the RADEXT WG charter page:

<quote>

Goals and Milestones:

<snip>
 =20
Dec 2006    RADIUS Crypto-agility draft (e.g. FIPS 140-2 compliance for
RADIUS) submitted as a Proposed Standard RFC (split out from WLAN
attributes draft) =20

</quote>

So it appears to me that it *has* been added to the WG charter.

> ... are we going to discuss this?

We can.

> How about other new work items?

We will prioritize the session time so as to facilitate meeting
short-term WG milestones. If there is time available, we can discuss new
work items.  We do need to maintain our focus on meeting all our
milestones, however.

--
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, 21 Jun 2006 09:25:26 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG at IETF-66
Date: Wed, 21 Jun 2006 02:24:37 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>, "Glen Zorn \(gwz\)" <[email-masked]>

Nelson, David <> supposedly scribbled:

> From the tentative agenda for IETF-66:
>=20
> MONDAY, July 10, 2006
> 0900-1130 Morning Session I
>=20
> Room 519B         OPS  radext 	RADIUS EXTensions WG
>=20
> Please remember that the final agenda is subject to change.
>=20
> Anyone wishing a presentation slot during the RADEXT session please
> send a message to the chairs indicating the subject, the related
> Internet-Draft, and the desired time.  Priority will be given to WG
> milestones in the immediate to near future.=20

Looking at the WG charter, I notice that so-called "crypto agility" has =
not yet been added; are we going to discuss this?  How about other new =
work items? =20

~gwz

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

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

Delivery-date: Tue, 20 Jun 2006 18:43:18 +0000
Content-class: urn:content-classes:message
Subject: RADEXT WG at IETF-66
Date: Tue, 20 Jun 2006 14:42:51 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>

>From the tentative agenda for IETF-66:

MONDAY, July 10, 2006
0900-1130 Morning Session I

Room 519B         OPS  radext 	RADIUS EXTensions WG

Please remember that the final agenda is subject to change.

Anyone wishing a presentation slot during the RADEXT session please send
a message to the chairs indicating the subject, the related
Internet-Draft, and the desired time.  Priority will be given to WG
milestones in the immediate to near future.

--
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, 19 Jun 2006 19:50:29 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-filter-00.txt 
Date: Mon, 19 Jun 2006 15:50:02 -0400

--NextPart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

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

Envelope-to: [email-masked]
Delivery-date: Sun, 18 Jun 2006 15:26:19 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Issue: RADIUS Response and Retransmissions 
cc: [email-masked]
Date: Sun, 18 Jun 2006 11:17:38 -0400
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> Right.  It is probably worth adding a caveat about the effects of changing 
> the Request ID.

  I'll try to write up some text for inclusion in the issues & fixes
document.

> RFC 2865 doesn't give an indication that change of ID relates to aborting 
> the session.  For example, we could be talking about re-authentication or a 
> situation where an Event-Timestamp attribute is being included (such as is 
> recommended in RFC 3576).  That would lead to a change on ID with each 
> retransmission.  Yet the session is still in progress.

  I quite agree.  But how does the NAS know that the server will agree
it's the same session?  It can guess, but...

> What we are seeing is that the RADIUS client RTO is less than the time it 
> takes for the RADIUS server to respond.  The ID isn't necessarily changing, 
> but the RADIUS client is dropping the Response.  If the RTO is not backed 
> off, this can continue for quite a while without success, even though an 
> Access-Accept is being continually returned.

  That's an independent problem, I think, caused by two issues:

  1) RTO is fixed and unchanging (and probably much less than 30s)
  2) old request packets are discarded

  The side-effect of (1) means that the NAS isn't doing exponential
backoff, which is a well-known solution to delay/congestion in networks.

  The side effect of (2) means that the NAS has no idea of knowing
what the RTO *should* be.

  RADIUS clients typically use fixed time intervals for RTO & total
packet time.  The "Issues & Fixes" document already talks about
congestive back-off.  Maybe it's worth adding a section about RTO's in
general.  If poor retransmission methods cause problems in
non-congested situations, that's reason to have a separate section.

  I'll see if I can write up some text this week.

  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, 17 Jun 2006 00:41:26 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Issue: RADIUS Response and Retransmissions
Date: Fri, 16 Jun 2006 17:41:06 -0700

>I'm not sure what is meant by a "retransmission" if the
>Access-Request packet contents change.  Which attributes determine a
>"session"?

I'm not sure, either, but RFC 2865 section 2.5 mentions "retransmitting" and 
changing the ID in the same paragraph:

  If the NAS is retransmitting a RADIUS request to the same server as
  before, and the attributes haven't changed, you MUST use the same
  Request Authenticator, ID, and source port.  If any attributes have
  changed, you MUST use a new Request Authenticator and ID.

>In the absence of a clear and consistent definition for "session",
>the RADIUS server MAY treat a "retransmit with new ID" as a different
>session.  It MAY return Access-Accept for one request, and
>Access-Reject for another.  This can happen when multiple simultaneous
>login restrictions are enforced, among other scenarios.
>
>   So the problem appears to be larger than just the NAS behavior.

Right.  It is probably worth adding a caveat about the effects of changing 
the Request ID.

>Again, in the absence of a clear and consistent definition for
>"session", the presumed behavior of a NAS when it "retransmits with a
>new ID" is that the old session is being discarded, and a new session
>is being initiated.  In that case, the response of the server (if any)
>is irrelevant, as the NAS has decided to stop supporting that session.

RFC 2865 doesn't give an indication that change of ID relates to aborting 
the session.  For example, we could be talking about re-authentication or a 
situation where an Event-Timestamp attribute is being included (such as is 
recommended in RFC 3576).  That would lead to a change on ID with each 
retransmission.  Yet the session is still in progress.

>My question is that if the NAS is supposed to validate the
>response... what does it do then with that response?  How does it's
>behavior cange over silently dropping the response?  How does it
>handle the case where one "session" returns Access-Accept, and the
>other Access-Reject?  Which session wins, and why?

What we are seeing is that the RADIUS client RTO is less than the time it 
takes for the RADIUS server to respond.  The ID isn't necessarily changing, 
but the RADIUS client is dropping the Response.  If the RTO is not backed 
off, this can continue for quite a while without success, even though an 
Access-Accept is being continually returned.

If we are talking about retransmission as discussed in Section 2.5, I don't 
think RFC 2865 defines what happens when the Response to one transmission 
has a different result than the Response to a retransmission.

>Silently discarding the old session would seem to me to be the
>safest thing to do.

If the ID has changed, that might be reasonable, but if it hasn't, then I 
don't see why it shouldn't be processed.

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

Envelope-to: [email-masked]
Delivery-date: Fri, 16 Jun 2006 23:34:56 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Issue: RADIUS Response and Retransmissions 
cc: [email-masked]
Date: Fri, 16 Jun 2006 19:26:29 -0400
Message-Id: <[email-masked]>

> Therefore for a RADIUS retransmission it is possible that the ID and Request 
> Authenticator will remain the same or that they will change.

  I'm not sure what is meant by a "retransmission" if the
Access-Request packet contents change.  Which attributes determine a
"session"?

  Section 1.2 of RFC 2865 says:

   session   Each service provided by the NAS to a dial-in user
             constitutes a session, with the beginning of the session
             defined as the point where service is first provided and
             the end of the session defined as the point where service
             is ended.  A user may have multiple sessions in parallel or
             series if the NAS supports that.

  But it doesn't describe how to distinguish multiple parallel
sessions on the same NAS.  Many implementations assume a unique
session is at least (NAS-IP-Address, NAS-Port), but there may be other
viable approaches.

  In the absence of a clear and consistent definition for "session",
the RADIUS server MAY treat a "retransmit with new ID" as a different
session.  It MAY return Access-Accept for one request, and
Access-Reject for another.  This can happen when multiple simultaneous
login restrictions are enforced, among other scenarios.

  So the problem appears to be larger than just the NAS behavior.

  Again, in the absence of a clear and consistent definition for
"session", the presumed behavior of a NAS when it "retransmits with a
new ID" is that the old session is being discarded, and a new session
is being initiated.  In that case, the response of the server (if any)
is irrelevant, as the NAS has decided to stop supporting that session.

  So silently discarding the response associated with the "old"
session would appear to be the correct thing to do.  The NAS *could*
validate the response, but that would serve as a check that it was a
valid response, and an indication that the RADIUS server is still
alive.  That response would make no difference in subsequent NAS
behavior, as it already had decided to drop that session.

  My question is that if the NAS is supposed to validate the
response... what does it do then with that response?  How does it's
behavior cange over silently dropping the response?  How does it
handle the case where one "session" returns Access-Accept, and the
other Access-Reject?  Which session wins, and why?

  Silently discarding the old session would seem to me to be the
safest thing to do.

  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, 16 Jun 2006 21:44:53 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue:  RADIUS Response and Retransmissions
Date: Fri, 16 Jun 2006 14:44:30 -0700

Issue: RADIUS Response and Retransmissions
Submitter names: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: June 16, 2006
Reference:
Document: Issues and Fixes
Comment type: 'T'echnical |
Priority: '1' Should fix
Section: New
Rationale/Explanation of issue:

We are seeing RADIUS client implementations in the field that do not 
correctly handle receipt of RADIUS responses after retransmissions.   The 
recommended text is as follows:

"X.X  Responses Received After Retransmissions

RFC 2865 Section 2.5 states:

   If the NAS is retransmitting a RADIUS request to the same server as
   before, and the attributes haven't changed, you MUST use the same
   Request Authenticator, ID, and source port.  If any attributes have
   changed, you MUST use a new Request Authenticator and ID.

Therefore for a RADIUS retransmission it is possible that the ID and Request 
Authenticator will remain the same or that they will change.

Regardless of whether a retransmission utilizes the same ID and Request 
Authenticator or changes them, it is possible to receive a RADIUS response 
to a previous transmission after a retransmission has been sent.

RADIUS client implementations SHOULD validate those responses, rather than 
silently discarding them. "

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

Delivery-date: Fri, 16 Jun 2006 15:40:03 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Conclusion of IETF Last call on RFC 3576 MIBs, RFC 2618bis-2621bis
Date: Fri, 16 Jun 2006 08:39:36 -0700

>Is it Ok to resubmit the new versions now?

Yes.

--
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, 15 Jun 2006 23:13:51 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: IESG DISCUSS comments on draft-ietf-radext-delegated-prefix
Date: Thu, 15 Jun 2006 16:13:28 -0700

As described in RFC 4005, the Framed-IPv6-Prefix attribute in Diameter is of 
type OctetString, so I think that it's ok for the Delegated Prefix attribute 
to be of the same type.

I also think you need to include text on the AVP flag rules, along the lines 
of what is in the Framed-IPv6-Prefix attribute:

                                            +---------------------+
                                            |    AVP Flag rules   |
                                            |----+-----+----+-----|----+
                   AVP  Section             |    |     |SHLD| MUST|    |
   Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----|
   Framed-IPv6-      97  6.11.6  OctetString| M  |  P  |    |  V  | Y  |
     Prefix                                 |    |     |    |     |    |

--------------------------------------------------------------------------------
From: Ralph Droms [mailto:[email-masked]]
Sent: Thu 6/15/2006 8:50 AM
To: Nelson, David; Romascanu, Dan (Dan); Joseph Salowey (jsalowey); 
[email-masked]
Cc: [email-masked]
Subject: Re: COMMENT: draft-ietf-radext-delegated-prefix

(Second try)

Here is a draft of new replacement text for section 4 in
draft-ietf-radext-delegated-prefix, based on Jari's template.  If the
substance of the text is acceptable, I will clean up the various citations
and references.

Not knowing any better, I used OctetString as the datatype for the
Delegated-IPv6-Prefix.  Also, not being intimately familiar with Diameter,
the last three paragraphs may need some editing or correction.

Note that I modified the text from Jari's template, and suggest those
editorial changes be considered for the template in the future.

- Ralph

OLD:

4.  Diameter Considerations

   A definition is needed for an identical attribute with the same Type
   value for Diameter [4].  The attribute should be available as part of
   the NASREQ application [5], as well as the Diameter EAP application
   [6].

NEW:

   When used in Diameter, the attribute defined in this specification
   can be used as a Diameter AVP from the Code space 1-255, i.e.,
   RADIUS attribute compatibility space. No additional Diameter Code
   values are therefore allocated. The data types of the attributes
   are as follows:

     Delegated-IPv6-Prefix             OctetString

   The attribute in this specification has no special translation
   requirements for Diameter to RADIUS or RADIUS to Diameter gateways,
   i.e., the attribute is copied as is, except for changes relating to
   headers, alignment, and padding. See also [RFC 3588] Section 4.1
   and [RFC 4005] Section 9.

   The text in this specification describing the applicability of the
   Delegated-IPv6-Prefix attribute for RADIUS Access-Request applies
   in Diameter to AA-Request [RFC 4005] or Diameter-EAP-Request [RFC
   4072].

   The text in this specification describing the applicability of the
   Delegated-IPv6-Prefix attribute for RADIUS Access-Accept applies in
   Diameter to AA-Answer or Diameter-EAP-Answer that indicates
   success.

   The text in this specification describing the applicability of the
   Delegated-IPv6-Prefix attribute for RADIUS Accounting-Request
   applies to Diameter Accounting-Request [RFC 4005] as well.

--
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, 15 Jun 2006 08:25:23 +0000
Date: Thu, 15 Jun 2006 10:24:30 +0200
From: [email-masked]
To: "David Nelson (E-mail)" <[email-masked]>
CC: [email-masked]
Subject: Re: Conclusion of IETF Last call on RFC 3576 MIBs, RFC 	2618bis-2621bis

> 
> With respect to the Dynamic RADIUS MIBs, it may in fact be preferable to
> issue a new draft version, and first run the revisions through an SMIv2
> syntax checker.  I'll defer to the preference of the authors in this
> regard, but it seemed that's what they had suggested.
> 

Indeed, 2 changes in the MIB have to be done and (moving discontinuity 
counter from scalar inside the table and a small SYNTAX update), so it 
looks to me best to update the draft. (see 
https://ops.ietf.org/lists/radiusext/2006/msg00534.html) for the 
details. Also a very small change in an RFC ed note has to be done.

Is it Ok to resubmit the new versions now?

regards,
Stefaan

--
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, 15 Jun 2006 00:49:08 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Question about NAI Realm based routing of RADIUS
Date: Wed, 14 Jun 2006 17:48:39 -0700

Dhaval said:

"Hi
     Thanks for the detailed response. Much appreciated.

A few more questions:

- how does this realm routing table get populated?
- what are the contents of such a realm routing table, i.e. what do the 
entries look like?
- what document describes this realm routing table?

- I understand RADIUS by itself does not support DNS based server discovery, 
but can it simply use hostname lookup for the FQDN of the realm and use that 
IP address?

- And if I understood your email correctly, even if there is a routing 
entry, the RADIUS proxy will only forward the packet if it has a shared 
secret with the server just found in the realm routing
table, correct?

Thanks again
Dhaval."

The realm routing table is typically  populated by manual configuration of 
the RADIUS proxy.  The realm routing table typically includes a realm and 
the IP addresses of one or more RADIUS servers within that realm.  The realm 
routing table is often configured at the same time that the proxy itself is 
configured, so as to ensure that each entry in the realm routing table has a 
corresponding RADIUS shared secret associated with it.  That way, every 
destination in the realm routing table will be properly configured so that 
the proxy can forward RADIUS packets to it.

Using DNS to determine the RADIUS server address from the realm name is not 
advisable because there is no guarantee that the RADIUS server will have the 
same name as the realm.  For example, the RADIUS for "example.com" need not 
reside on the machine "example.com";  it could reside at "foo.example.com" 
or "balloon.example.com".   That is the reason why Diameter adopted a more 
sophisticated service discovery model described in RFC 3588.

Material relating to RADIUS proxy forwarding is available in the following 
documents:

RFC 2477
RFC 2607
RFC 2865
RFC 4284

Material specific to Diameter forwarding and discovery is provided in RFC 
3588.

===================================================
>From: "Bernard Aboba" <[email-masked]>
>To: [email-masked]
>CC: [email-masked]
>Subject: Re: Question about NAI Realm based routing of RADIUS
>Date: Wed, 14 Jun 2006 13:53:50 -0700
>
>Daval --
>
>RADIUS clients do not modify the EAP-Response/Identity, but rather they 
>just insert it as is into the User-Name attribute.  RADIUS clients 
>typically are only configured with primary/secondary RADIUS servers and so 
>they do not handle routing; this is the responsibility of RADIUS proxies.  
>The situation is akin to hosts which only point to default gatways;  it is 
>the gateways that typically run routing protocols, rather than hosts.
>
>So in your example, the RADIUS client would send the Access-Request to the 
>local RADIUS proxy. if a RADIUS proxy received an Access-Request containing 
>a User-Name of [email-masked] 
>then it would look in its routing table for the RADIUS server handling the 
>other1.example.net realm, and route the Access-Request to that server.  
>RADIUS servers can only be included in the realm routing table if there is 
>a shared secret configured for communication with that server.
>
>Since RADIUS does not support DNS-based server discovery (this is a 
>Diameter feature), there is no notion of "resolving" a realm name to an IP 
>address other than via the realm routing table.  If the RADIUS proxy did 
>not have a realm routing table entry for "other1.example.net" then it would 
>either drop the packet or perhaps send back an Access-Challenge containing 
>an EAP-Message/EAP-Request/Identity message containing realm hints as 
>specified in RFC 4284.
>
>In Diameter, DNS-based discovery is possible.  This could allow a Diameter 
>proxy to discover the IP address of a server within a destination realm, 
>without that address being configured in the realm routing table.  However, 
>a successful Diameter session would only be set up if appropriate 
>credentials were available to enable authentication.  For example, if 
>Diameter over TLS were used, then the Diameter proxy would need to be able 
>to verify the Diameter Server certificate based on its configured trust 
>anchors.
>
>--------------------------------------------------------------------------------------------------------------------------
>Date: Wed, 14 Jun 2006 12:29:13 -0700
>From: Dhaval Shah <[email-masked]>
>To: [email-masked]
>Subject: [AAA-WG]: Question about NAI Realm based routing of RADIUS
>Parts/Attachments:
>
>Hi
>     I have a question about NAI Realm based routing of AAA RADIUS messages 
>from say a 802.1x
>authenticator to the Home AAA server.
>
>Consider the following example: (I am using the notations from RFC 4282 
>(Network Access Identifier), section 2.7)
>
>Lets say autheticator received user identity in EAP-Response packet as NAI 
>formed like
>
>[email-masked]
>
>This NAI will be converted by the RADIUS client of the 802.1x authenticator 
>as
>
>[email-masked]
>
>and forwarded to the IP address of other2.example.net as a RADIUS 
>Access-Request.
>
>My question is, RADIUS client usually needs to share a "secret" with AAA 
>server, in the above
>case where the client needs to send the message through multiple routing 
>realms as coded
>in the NAI, is it required that the client MUST have a shared "secret" with 
>the first hop AAA
>server/proxy towards the Home AAA server? In the above case, does 802.1x 
>authenticator
>of other1.example.net needs to share a "secret" with AAA server of 
>other2.example.net and
>it MUST use that to prepare the Message Authenticator? And similarly, AAA 
>server of
>other2.example.net MUST share a "secret" with home.example.net's AAA 
>server?
>
>Also, what (if any) extensions must be added to the RADIUS message 
>originating at the authenticator to allow such realm based forwarding of 
>the packet to the Home AAA server?
>
>thanks
>Dhaval
>
>
>
>--
>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: Wed, 14 Jun 2006 20:54:18 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Question about NAI Realm based routing of RADIUS
Date: Wed, 14 Jun 2006 13:53:50 -0700

Daval --

RADIUS clients do not modify the EAP-Response/Identity, but rather they just 
insert it as is into the User-Name attribute.  RADIUS clients typically are 
only configured with primary/secondary RADIUS servers and so they do not 
handle routing; this is the responsibility of RADIUS proxies.  The situation 
is akin to hosts which only point to default gatways;  it is the gateways 
that typically run routing protocols, rather than hosts.

So in your example, the RADIUS client would send the Access-Request to the 
local RADIUS proxy. if a RADIUS proxy received an Access-Request containing 
a User-Name of [email-masked] 
then it would look in its routing table for the RADIUS server handling the 
other1.example.net realm, and route the Access-Request to that server.  
RADIUS servers can only be included in the realm routing table if there is a 
shared secret configured for communication with that server.

Since RADIUS does not support DNS-based server discovery (this is a Diameter 
feature), there is no notion of "resolving" a realm name to an IP address 
other than via the realm routing table.  If the RADIUS proxy did not have a 
realm routing table entry for "other1.example.net" then it would either drop 
the packet or perhaps send back an Access-Challenge containing an 
EAP-Message/EAP-Request/Identity message containing realm hints as specified 
in RFC 4284.

In Diameter, DNS-based discovery is possible.  This could allow a Diameter 
proxy to discover the IP address of a server within a destination realm, 
without that address being configured in the realm routing table.  However, 
a successful Diameter session would only be set up if appropriate 
credentials were available to enable authentication.  For example, if 
Diameter over TLS were used, then the Diameter proxy would need to be able 
to verify the Diameter Server certificate based on its configured trust 
anchors.

--------------------------------------------------------------------------------------------------------------------------
Date: Wed, 14 Jun 2006 12:29:13 -0700
From: Dhaval Shah <[email-masked]>
To: [email-masked]
Subject: [AAA-WG]: Question about NAI Realm based routing of RADIUS
Parts/Attachments:

Hi
     I have a question about NAI Realm based routing of AAA RADIUS messages 
from say a 802.1x
authenticator to the Home AAA server.

Consider the following example: (I am using the notations from RFC 4282 
(Network Access Identifier), section 2.7)

Lets say autheticator received user identity in EAP-Response packet as NAI 
formed like

[email-masked]

This NAI will be converted by the RADIUS client of the 802.1x authenticator 
as

[email-masked]

and forwarded to the IP address of other2.example.net as a RADIUS 
Access-Request.

My question is, RADIUS client usually needs to share a "secret" with AAA 
server, in the above
case where the client needs to send the message through multiple routing 
realms as coded
in the NAI, is it required that the client MUST have a shared "secret" with 
the first hop AAA
server/proxy towards the Home AAA server? In the above case, does 802.1x 
authenticator
of other1.example.net needs to share a "secret" with AAA server of 
other2.example.net and
it MUST use that to prepare the Message Authenticator? And similarly, AAA 
server of
other2.example.net MUST share a "secret" with home.example.net's AAA server?

Also, what (if any) extensions must be added to the RADIUS message 
originating at the authenticator to allow such realm based forwarding of the 
packet to the Home AAA server?

thanks
Dhaval

--
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, 14 Jun 2006 18:21:56 +0000
Content-class: urn:content-classes:message
Subject: RE: Conclusion of IETF Last call on RFC 3576 MIBs, RFC  2618bis-2621bis
Date: Wed, 14 Jun 2006 14:21:49 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba writes...

> Can we go ahead and issue new documents with these=20
> issues fixed?

In the case of the RADIUS Accounting MIBs, the change is trivial enough
that I would recommend that the IESG address it with an RFC Editor Note.

s/ACCT/ACC/ one place in each of two documents.

With respect to the Dynamic RADIUS MIBs, it may in fact be preferable to
issue a new draft version, and first run the revisions through an SMIv2
syntax checker.  I'll defer to the preference of the authors in this
regard, but it seemed that's what they had suggested.

--
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, 14 Jun 2006 18:15:27 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Conclusion of IETF Last call on RFC 3576 MIBs, RFC 2618bis-2621bis
Date: Wed, 14 Jun 2006 11:15:13 -0700

Can we go ahead and issue  new documents with these issues fixed?  We could 
then ask the IESG to approve the documents.

>From: "Nelson, David" <[email-masked]>
>To: <[email-masked]>
>Subject: RE: Conclusion of IETF Last call on RFC 3576 MIBs, RFC 
>2618bis-2621bis
>Date: Wed, 14 Jun 2006 13:47:53 -0400
>
>Bernard Aboba writes...
>
> > In order to enable IESG evaluation, we are requesting that
> > the authors summarize the IETF last call comments and their
> > responses to them on the RADEXT WG list.
>
>With regard to RFC 2618bis - 2621bis, there is one outstanding comment
>from IETF Last Call, on RFC 2620bis and RFC 2621bis.
>
> >> 3) the accounting client MIB the first line of the MIB changed from
> >>
> >>    RADIUS-ACC-CLIENT-MIB DEFINITIONS ::= BEGIN
> >>
> >> to
> >>
> >>    RADIUS-ACCT-CLIENT-MIB DEFINITIONS ::= BEGIN
> >>
> >> (the T was added). Is this ok?
>
> > Ooops.  No, it is not OK.  This is a typo that will need to be
> > corrected before the document is published as an RFC.  Good catch.
> > Everyone else, including me, has missed this so far.  :-)
>
>Note that this change applies to both the RADIUS Accounting Client and
>Server MIBs.
>
>
>With regard to the RFC 3676 (Dynamic RADIUS) MIBs, Stefaan DeCnodder has
>recently written, in response to a GetArt Review comment...
>
> >> - The client MIB contains a note to the RFC editor about the
> >> reference [DYNSERV]. However, there is no such reference.
>
> > I checked it and the client MIB is OK, in the server MIB it seems
> > that the RFC ed note is incorrect and [DYNSERV] should be replaced
> > by [DYNCLNT]. The references in both of the drafts are correct,
> > with the exception of the RFC ed note in the server MIB.
>
>With regard to the RFC 3676 (Dynamic RADIUS) MIBs, Stefaan DeCnodder has
>recently written, in response to RADEXT Issue No. 193...
>
><quote>
>
>* draft-ietf-dynauth-client-mib-06.txt
>
>1) issue 193: change SYNTAX of radiusDynAuthServerClientPortNumber from
>"InetPortNumber" to "InetPortNumber (1..65535)"
>
>     radiusDynAuthServerClientPortNumber OBJECT-TYPE
>            SYNTAX     InetPortNumber (1..65535)
>            MAX-ACCESS read-only
>            STATUS     current
>            DESCRIPTION
>                  "The UDP destination port that the RADIUS Dynamic
>                   Authorization Client is using to send requests to this
>                   server. The value zero is invalid."
>            ::= { radiusDynAuthServerEntry 4 }
>
>2) remove radiusDynAuthClientCounterDiscontinuity as a scaler and put it
>as last attribute in the table. Description has been updated slightly as
>well as a small update in the conformance statement to reflect the move
>of this attribute into the table. Also a small update of the overview
>section that describes high level the scalars and table.
>
>     radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE
>            SYNTAX TimeTicks
>            UNITS  "hundredths of a second"
>            MAX-ACCESS read-only
>            STATUS current
>            DESCRIPTION
>                  "The time (in hundredths of a second) since the
>                   last counter discontinuity. A discontinuity may
>                   be the result of a reinitialization of the DAC
>                   module within the managed entity."
>            ::= { radiusDynAuthServerEntry 32 }
>
>3) update date of draft and also inside the MIB
>
>* draft-ietf-dynauth-server-mib-06.txt
>
>1) remove radiusDynAuthServerCounterDiscontinuity as a scaler and put it
>as last attribute in the table. Description has been updated slightly as
>well as a small update in the conformance statement to reflect the move
>of this attribute into the table. Also a small update of the overview
>section that describes high level the scalars and table.
>
>     radiusDynAuthServerCounterDiscontinuity OBJECT-TYPE
>            SYNTAX TimeTicks
>            UNITS  "hundredths of a second"
>            MAX-ACCESS read-only
>            STATUS current
>            DESCRIPTION
>                  "The time (in hundredths of a second) since the
>                   last counter discontinuity. A discontinuity may
>                   be the result of a reinitialization of the DAS
>                   module within the managed entity."
>            ::= { radiusDynAuthClientEntry 27 }
>
>2) update date of draft and also inside the MIB
>
></quote>
>
>
>--
>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: Wed, 14 Jun 2006 17:48:25 +0000
Content-class: urn:content-classes:message
Subject: RE: Conclusion of IETF Last call on RFC 3576 MIBs, RFC  2618bis-2621bis
Date: Wed, 14 Jun 2006 13:47:53 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> In order to enable IESG evaluation, we are requesting that=20
> the authors summarize the IETF last call comments and their=20
> responses to them on the RADEXT WG list.

With regard to RFC 2618bis - 2621bis, there is one outstanding comment
from IETF Last Call, on RFC 2620bis and RFC 2621bis.

>> 3) the accounting client MIB the first line of the MIB changed from
>>=20
>>    RADIUS-ACC-CLIENT-MIB DEFINITIONS ::=3D BEGIN
>>=20
>> to
>>=20
>>    RADIUS-ACCT-CLIENT-MIB DEFINITIONS ::=3D BEGIN
>>=20
>> (the T was added). Is this ok?

> Ooops.  No, it is not OK.  This is a typo that will need to be=20
> corrected before the document is published as an RFC.  Good catch.
> Everyone else, including me, has missed this so far.  :-)

Note that this change applies to both the RADIUS Accounting Client and
Server MIBs.

With regard to the RFC 3676 (Dynamic RADIUS) MIBs, Stefaan DeCnodder has
recently written, in response to a GetArt Review comment...

>> - The client MIB contains a note to the RFC editor about the
>> reference [DYNSERV]. However, there is no such reference.

> I checked it and the client MIB is OK, in the server MIB it seems
> that the RFC ed note is incorrect and [DYNSERV] should be replaced
> by [DYNCLNT]. The references in both of the drafts are correct,=20
> with the exception of the RFC ed note in the server MIB.

With regard to the RFC 3676 (Dynamic RADIUS) MIBs, Stefaan DeCnodder has
recently written, in response to RADEXT Issue No. 193...

<quote>

* draft-ietf-dynauth-client-mib-06.txt

1) issue 193: change SYNTAX of radiusDynAuthServerClientPortNumber from
"InetPortNumber" to "InetPortNumber (1..65535)"

    radiusDynAuthServerClientPortNumber OBJECT-TYPE
           SYNTAX     InetPortNumber (1..65535)
           MAX-ACCESS read-only
           STATUS     current
           DESCRIPTION
                 "The UDP destination port that the RADIUS Dynamic
                  Authorization Client is using to send requests to this
                  server. The value zero is invalid."
           ::=3D { radiusDynAuthServerEntry 4 }

2) remove radiusDynAuthClientCounterDiscontinuity as a scaler and put it
as last attribute in the table. Description has been updated slightly as
well as a small update in the conformance statement to reflect the move
of this attribute into the table. Also a small update of the overview
section that describes high level the scalars and table.

    radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE
           SYNTAX TimeTicks
           UNITS  "hundredths of a second"
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
                 "The time (in hundredths of a second) since the
                  last counter discontinuity. A discontinuity may
                  be the result of a reinitialization of the DAC
                  module within the managed entity."
           ::=3D { radiusDynAuthServerEntry 32 }

3) update date of draft and also inside the MIB

* draft-ietf-dynauth-server-mib-06.txt

1) remove radiusDynAuthServerCounterDiscontinuity as a scaler and put it
as last attribute in the table. Description has been updated slightly as
well as a small update in the conformance statement to reflect the move
of this attribute into the table. Also a small update of the overview
section that describes high level the scalars and table.

    radiusDynAuthServerCounterDiscontinuity OBJECT-TYPE
           SYNTAX TimeTicks
           UNITS  "hundredths of a second"
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
                 "The time (in hundredths of a second) since the
                  last counter discontinuity. A discontinuity may
                  be the result of a reinitialization of the DAS
                  module within the managed entity."
           ::=3D { radiusDynAuthClientEntry 27 }

2) update date of draft and also inside the MIB

</quote>

--
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, 13 Jun 2006 21:39:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: NAS-Filter-Rule document
Date: Tue, 13 Jun 2006 14:39:54 -0700

As part of the proposal for moving forward on the NAS-Traffic-Rule document, 
it has been proposed that a RADIUS NAS-Filter-Rule attribute be defined with 
the same functionality as the NAS-Filter-Rule AVP defined in Diameter 
NASREQ, RFC 4005.

A strawman version of a NAS-Filter-Rule attribute document is enclosed 
below:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-filter-00.txt

Comments welcome.

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

Delivery-date: Tue, 13 Jun 2006 21:38:31 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Moving forward on the NAS-Filter-Rule document
Date: Tue, 13 Jun 2006 14:38:10 -0700

Recently a conference call took place relating to the next steps for the 
NAS-Filter-Rule document.  The new proposal for moving forward is as 
follows:

1. Have DIME WG commit to defining a new diameter AVP that replicates the 
nas-traffic-rule attribute.  The filter syntax would be exactly the same, 
thereby allowing the draft-ietf-radext-filter-rule to claim interoperability 
in terms of direct translation.  Diameter's IPFilterRule is not altered.

2. Have RADEXT WG commit to define a new RADIUS attribute that replicates 
IPFilterRule.  The ongoing work with nas-traffic-rule continues.

Discussion/feedback is solicited on this new proposal.

--
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, 13 Jun 2006 19:29:19 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Conclusion of IETF Last call on RFC 3576 MIBs, RFC 2618bis-2621bis
Date: Tue, 13 Jun 2006 12:28:59 -0700

IETF Last Call has concluded on these documents.

In order to enable IESG evaluation, we are requesting that the authors 
summarize the IETF last call comments and their responses to them on the 
RADEXT WG list.  This will help us quickly get out updated documents, so 
that we can get these documents on the IESG Agenda ASAP.

Let's get these 6 documents (as well as the Prefix Delegation document) into 
the RFC Editor Queue so we can focus on moving forward with other work 
items!

--------------------------------------------------------------------------------------------------------------------------
Date: Tue, 13 Jun 2006 12:18:04 +0300
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: [email-masked], Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Six radext MIB Documents completed IETF LC

Radext chairs,

Six MIB documents completed IETF LC. Please let me know if you believe
that there are any comments of substance that would require new
versions, or editorial comments that could be the objects of requests
for the RFC Editor. Also, make sure that the proto write-up information
is updated and available for the IESG evaluation.

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, 13 Jun 2006 08:05:05 +0000
Date: Tue, 13 Jun 2006 11:04:33 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Changes to draft-ietf-radext-vlan to address IESG DISCUSS Comments

Bernard Aboba wrote:

>> Works for me. But didn't you have a discussion earlier that
>> user-priority-table would not be mandatory?
>
>
> There may be situations in which it could be mandatory.  For example,
> for DoS prevention, it might be required to remark frames at an
> exchange point that are transmitted by an ISP that doesn't do ingress
> filtering.

OK

> The problem is that a RADIUS/Diameter gateway may not necessarily know
> what the intent of the attribute is, so that it seems safest if the
> 'M' bit is always set.  That's why I moved it from the 'MAY' column to
> the MUST column.

It is indeed important that the gateways do not have to start making
policy decisions of what a value means. All translation should be
as mechanical as possible.

(I cleared my DISCUSS based on the new version.)

--Jari

--
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, 12 Jun 2006 19:50:31 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-vlan-06.txt 
Date: Mon, 12 Jun 2006 15:50:02 -0400

--NextPart

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

	Title		: RADIUS Attributes for Virtual LAN and Priority Support
	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-vlan-06.txt
	Pages		: 15
	Date		: 2006-6-12
	
This document proposes additional RADIUS (Remote Authentication Dial
   In User Service) attributes for dynamic Virtual LAN assignment and
   prioritization, for use in provisioning of access to IEEE 802 local
   area networks.  These attributes are usable within either RADIUS or
   Diameter.

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-vlan-06.txt

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Mon, 12 Jun 2006 16:59:04 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Changes to draft-ietf-radext-vlan to address IESG DISCUSS Comments
Date: Mon, 12 Jun 2006 09:58:18 -0700

>Works for me. But didn't you have a discussion earlier that
>user-priority-table would not be mandatory?

There may be situations in which it could be mandatory.  For example, for 
DoS prevention, it might be required to remark frames at an exchange point 
that are transmitted by an ISP that doesn't do ingress filtering.

The problem is that a RADIUS/Diameter gateway may not necessarily know what 
the intent of the attribute is, so that it seems safest if the 'M' bit is 
always set.  That's why I moved it from the 'MAY' column to the MUST column.

--
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, 12 Jun 2006 15:22:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Changes to draft-ietf-radext-vlan to address IESG DISCUSS Comments
Date: Mon, 12 Jun 2006 08:22:08 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Looks good.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Sunday, June 11, 2006 6:48 PM
> To: [email-masked]
> Subject: Changes to draft-ietf-radext-vlan to address IESG=20
> DISCUSS Comments
>=20
> Jari Arkko and Russ Housley have reviewed the VLAN/Priority=20
> document.  In order to address their comments, the following=20
> changes are proposed:
>=20
> Change Section 1 to the following:
>=20
> "1.  Introduction
>=20
>    This document describes Virtual LAN (VLAN) and re-prioritization
>    attributes that may prove useful for provisioning of access to IEEE
>    802 local area networks [IEEE-802] with the Remote Authentication
>    Dialin User Service (RADIUS) or Diameter.
>=20
>    While [RFC3580] enables support for VLAN assignment based on the
>    tunnel attributes defined in [RFC2868], it does not provide support
>    for a more complete set of VLAN functionality as defined by
>    [IEEE-802.1Q].  The attributes defined in this document provide
>    support within RADIUS and Diameter analogous to the management
>    variables supported in [IEEE-802.1Q] and MIB objects defined in
>    [RFC4363].  In addition, this document enables support for a wider
>    range of [IEEE-802.1X] configurations."
>=20
> In Section 1.1, add the following definitions:
>=20
> "RADIUS server
>      A RADIUS authentication server is an entity that provides an
>      authentication service to a NAS.
>=20
> RADIUS proxy
>      A RADIUS proxy acts as an authentication server to the NAS, and a
>      RADIUS client to the RADIUS server."
>=20
> Change Section 4 to the following:
>=20
> "4.  Diameter Considerations
>=20
>    When used in Diameter, the attributes defined in this specification
>    can be used as Diameter AVPs from the Code space 1-255 (RADIUS
>    attribute compatibility space). No additional Diameter Code values
>    are therefore allocated.  The data types and flag rules for the
>    attributes are as follows:
>=20
>                                   +---------------------+
>                                   |    AVP Flag rules   |
>                                   |----+-----+----+-----|----+
>                                   |    |     |SHLD| MUST|    |
>    Attribute Name      Value Type |MUST| MAY | NOT|  NOT|Encr|
>    -------------------------------|----+-----+----+-----|----|
>    Egress-VLANID       OctetString| M  |  P  |    |  V  | Y  |
>    Ingress-Filters     Enumerated | M  |  P  |    |  V  | Y  |
>    Egress-VLAN-Name    UTF8String | M  |  P  |    |  V  | Y  |
>    User-Priority-Table OctetString| M  |  P  |    |  V  | Y  |
>    -------------------------------|----+-----+----+-----|----|
>=20
>    The attributes in this specification have no special translation
>    requirements for Diameter to RADIUS or RADIUS to Diameter gateways;
>    they are copied as is, except for changes relating to headers,
>    alignment, and padding. See also [RFC 3588] Section 4.1 and [RFC
>    4005] Section 9.
>=20
>    What this specification says about the applicability of the
>    attributes for RADIUS Access-Request packets applies in Diameter to
>    AA-Request [RFC 4005] or Diameter-EAP-Request [RFC 4072].  What is
>    said about Access-Challenge applies in Diameter to AA-Answer [RFC
>    4005] or Diameter-EAP-Answer [RFC 4072] with Result-Code AVP set to
>    DIAMETER_MULTI_ROUND_AUTH.
>=20
>    What is said about Access-Accept applies in Diameter to=20
> AA-Answer or
>    Diameter-EAP-Answer messages that indicate success. =20
> Similarly, what
>    is said about RADIUS Access-Reject packets applies in=20
> Diameter to AA-
>    Answer or Diameter-EAP-Answer messages that indicate failure.
>=20
>    What is said about COA-Request applies in Diameter to=20
> Re-Auth-Request
>    [RFC 4005].
>=20
>    What is said about Accounting-Request applies to Diameter=20
> Accounting-
>    Request [RFC 4005] as well."
>=20
> Change Section 6 to the following:
>=20
> "6.  Security Considerations
>=20
>    This specification describes the use of RADIUS and Diameter for
>    purposes of authentication, authorization and accounting=20
> in IEEE 802
>    local area networks.  RADIUS threats and security issues for this
>    application are described in [RFC3579] and [RFC3580];=20
> security issues
>    encountered in roaming are described in [RFC2607].  For=20
> Diameter, the
>    security issues relating to this application are described in
>    [RFC4005] and [RFC4072].
>=20
>    This document specifies new attributes that can be included in
>    existing RADIUS packets, which are protected as described in
>    [RFC3579] and [RFC3576].  In Diameter, the attributes are protected
>    as specified in [RFC3588]. See those documents for a more detailed
>    description.
>=20
>    The security mechanisms supported in RADIUS and Diameter=20
> are focused
>    on preventing an attacker from spoofing packets or=20
> modifying packets
>    in transit.  They do not prevent an authorized=20
> RADIUS/Diameter server
>    or proxy from inserting attributes with malicious intent.
>=20
>    VLAN attributes sent by a RADIUS/Diameter server or proxy=20
> may enable
>    access to unauthorized VLANs.  These vulnerabilities can be limited
>    by performing authorization checks at the NAS.  For example, a NAS
>    can be configured to accept only certain VLANIDs from a given
>    RADIUS/Diameter server/proxy.
>=20
>    Similarly, an attacker gaining control of a=20
> RADIUS/Diameter server or
>    proxy can modify the user priority table, causing either=20
> degradation
>    of quality of service (by downgrading user priority of frames
>    arriving at a port), or denial of service (by raising the level of
>    priority of traffic at multiple ports of a device, oversubscribing
>    the switch or link capabilities)."
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Mon, 12 Jun 2006 06:22:33 +0000
Date: Mon, 12 Jun 2006 09:21:52 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Changes to draft-ietf-radext-vlan to address IESG DISCUSS Comments

Works for me. But didn't you have a discussion earlier that
user-priority-table would not be mandatory?

--Jari

Bernard Aboba wrote:

> Jari Arkko and Russ Housley have reviewed the VLAN/Priority document. 
> In order to address their comments, the following changes are proposed:
>
> Change Section 1 to the following:
>
> "1.  Introduction
>
>   This document describes Virtual LAN (VLAN) and re-prioritization
>   attributes that may prove useful for provisioning of access to IEEE
>   802 local area networks [IEEE-802] with the Remote Authentication
>   Dialin User Service (RADIUS) or Diameter.
>
>   While [RFC3580] enables support for VLAN assignment based on the
>   tunnel attributes defined in [RFC2868], it does not provide support
>   for a more complete set of VLAN functionality as defined by
>   [IEEE-802.1Q].  The attributes defined in this document provide
>   support within RADIUS and Diameter analogous to the management
>   variables supported in [IEEE-802.1Q] and MIB objects defined in
>   [RFC4363].  In addition, this document enables support for a wider
>   range of [IEEE-802.1X] configurations."
>
> In Section 1.1, add the following definitions:
>
> "RADIUS server
>     A RADIUS authentication server is an entity that provides an
>     authentication service to a NAS.
>
> RADIUS proxy
>     A RADIUS proxy acts as an authentication server to the NAS, and a
>     RADIUS client to the RADIUS server."
>
> Change Section 4 to the following:
>
> "4.  Diameter Considerations
>
>   When used in Diameter, the attributes defined in this specification
>   can be used as Diameter AVPs from the Code space 1-255 (RADIUS
>   attribute compatibility space). No additional Diameter Code values
>   are therefore allocated.  The data types and flag rules for the
>   attributes are as follows:
>
>                                  +---------------------+
>                                  |    AVP Flag rules   |
>                                  |----+-----+----+-----|----+
>                                  |    |     |SHLD| MUST|    |
>   Attribute Name      Value Type |MUST| MAY | NOT|  NOT|Encr|
>   -------------------------------|----+-----+----+-----|----|
>   Egress-VLANID       OctetString| M  |  P  |    |  V  | Y  |
>   Ingress-Filters     Enumerated | M  |  P  |    |  V  | Y  |
>   Egress-VLAN-Name    UTF8String | M  |  P  |    |  V  | Y  |
>   User-Priority-Table OctetString| M  |  P  |    |  V  | Y  |
>   -------------------------------|----+-----+----+-----|----|
>
>   The attributes in this specification have no special translation
>   requirements for Diameter to RADIUS or RADIUS to Diameter gateways;
>   they are copied as is, except for changes relating to headers,
>   alignment, and padding. See also [RFC 3588] Section 4.1 and [RFC
>   4005] Section 9.
>
>   What this specification says about the applicability of the
>   attributes for RADIUS Access-Request packets applies in Diameter to
>   AA-Request [RFC 4005] or Diameter-EAP-Request [RFC 4072].  What is
>   said about Access-Challenge applies in Diameter to AA-Answer [RFC
>   4005] or Diameter-EAP-Answer [RFC 4072] with Result-Code AVP set to
>   DIAMETER_MULTI_ROUND_AUTH.
>
>   What is said about Access-Accept applies in Diameter to AA-Answer or
>   Diameter-EAP-Answer messages that indicate success.  Similarly, what
>   is said about RADIUS Access-Reject packets applies in Diameter to AA-
>   Answer or Diameter-EAP-Answer messages that indicate failure.
>
>   What is said about COA-Request applies in Diameter to Re-Auth-Request
>   [RFC 4005].
>
>   What is said about Accounting-Request applies to Diameter Accounting-
>   Request [RFC 4005] as well."
>
> Change Section 6 to the following:
>
> "6.  Security Considerations
>
>   This specification describes the use of RADIUS and Diameter for
>   purposes of authentication, authorization and accounting in IEEE 802
>   local area networks.  RADIUS threats and security issues for this
>   application are described in [RFC3579] and [RFC3580]; security issues
>   encountered in roaming are described in [RFC2607].  For Diameter, the
>   security issues relating to this application are described in
>   [RFC4005] and [RFC4072].
>
>   This document specifies new attributes that can be included in
>   existing RADIUS packets, which are protected as described in
>   [RFC3579] and [RFC3576].  In Diameter, the attributes are protected
>   as specified in [RFC3588]. See those documents for a more detailed
>   description.
>
>   The security mechanisms supported in RADIUS and Diameter are focused
>   on preventing an attacker from spoofing packets or modifying packets
>   in transit.  They do not prevent an authorized RADIUS/Diameter server
>   or proxy from inserting attributes with malicious intent.
>
>   VLAN attributes sent by a RADIUS/Diameter server or proxy may enable
>   access to unauthorized VLANs.  These vulnerabilities can be limited
>   by performing authorization checks at the NAS.  For example, a NAS
>   can be configured to accept only certain VLANIDs from a given
>   RADIUS/Diameter server/proxy.
>
>   Similarly, an attacker gaining control of a RADIUS/Diameter server or
>   proxy can modify the user priority table, causing either degradation
>   of quality of service (by downgrading user priority of frames
>   arriving at a port), or denial of service (by raising the level of
>   priority of traffic at multiple ports of a device, oversubscribing
>   the switch or link capabilities)."
>
>
>
> -- 
> 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: Mon, 12 Jun 2006 01:48:06 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Changes to draft-ietf-radext-vlan to address IESG DISCUSS Comments
Date: Sun, 11 Jun 2006 18:47:51 -0700

Jari Arkko and Russ Housley have reviewed the VLAN/Priority document.  In 
order to address their comments, the following changes are proposed:

Change Section 1 to the following:

"1.  Introduction

   This document describes Virtual LAN (VLAN) and re-prioritization
   attributes that may prove useful for provisioning of access to IEEE
   802 local area networks [IEEE-802] with the Remote Authentication
   Dialin User Service (RADIUS) or Diameter.

   While [RFC3580] enables support for VLAN assignment based on the
   tunnel attributes defined in [RFC2868], it does not provide support
   for a more complete set of VLAN functionality as defined by
   [IEEE-802.1Q].  The attributes defined in this document provide
   support within RADIUS and Diameter analogous to the management
   variables supported in [IEEE-802.1Q] and MIB objects defined in
   [RFC4363].  In addition, this document enables support for a wider
   range of [IEEE-802.1X] configurations."

In Section 1.1, add the following definitions:

"RADIUS server
     A RADIUS authentication server is an entity that provides an
     authentication service to a NAS.

RADIUS proxy
     A RADIUS proxy acts as an authentication server to the NAS, and a
     RADIUS client to the RADIUS server."

Change Section 4 to the following:

"4.  Diameter Considerations

   When used in Diameter, the attributes defined in this specification
   can be used as Diameter AVPs from the Code space 1-255 (RADIUS
   attribute compatibility space). No additional Diameter Code values
   are therefore allocated.  The data types and flag rules for the
   attributes are as follows:

                                  +---------------------+
                                  |    AVP Flag rules   |
                                  |----+-----+----+-----|----+
                                  |    |     |SHLD| MUST|    |
   Attribute Name      Value Type |MUST| MAY | NOT|  NOT|Encr|
   -------------------------------|----+-----+----+-----|----|
   Egress-VLANID       OctetString| M  |  P  |    |  V  | Y  |
   Ingress-Filters     Enumerated | M  |  P  |    |  V  | Y  |
   Egress-VLAN-Name    UTF8String | M  |  P  |    |  V  | Y  |
   User-Priority-Table OctetString| M  |  P  |    |  V  | Y  |
   -------------------------------|----+-----+----+-----|----|

   The attributes in this specification have no special translation
   requirements for Diameter to RADIUS or RADIUS to Diameter gateways;
   they are copied as is, except for changes relating to headers,
   alignment, and padding. See also [RFC 3588] Section 4.1 and [RFC
   4005] Section 9.

   What this specification says about the applicability of the
   attributes for RADIUS Access-Request packets applies in Diameter to
   AA-Request [RFC 4005] or Diameter-EAP-Request [RFC 4072].  What is
   said about Access-Challenge applies in Diameter to AA-Answer [RFC
   4005] or Diameter-EAP-Answer [RFC 4072] with Result-Code AVP set to
   DIAMETER_MULTI_ROUND_AUTH.

   What is said about Access-Accept applies in Diameter to AA-Answer or
   Diameter-EAP-Answer messages that indicate success.  Similarly, what
   is said about RADIUS Access-Reject packets applies in Diameter to AA-
   Answer or Diameter-EAP-Answer messages that indicate failure.

   What is said about COA-Request applies in Diameter to Re-Auth-Request
   [RFC 4005].

   What is said about Accounting-Request applies to Diameter Accounting-
   Request [RFC 4005] as well."

Change Section 6 to the following:

"6.  Security Considerations

   This specification describes the use of RADIUS and Diameter for
   purposes of authentication, authorization and accounting in IEEE 802
   local area networks.  RADIUS threats and security issues for this
   application are described in [RFC3579] and [RFC3580]; security issues
   encountered in roaming are described in [RFC2607].  For Diameter, the
   security issues relating to this application are described in
   [RFC4005] and [RFC4072].

   This document specifies new attributes that can be included in
   existing RADIUS packets, which are protected as described in
   [RFC3579] and [RFC3576].  In Diameter, the attributes are protected
   as specified in [RFC3588]. See those documents for a more detailed
   description.

   The security mechanisms supported in RADIUS and Diameter are focused
   on preventing an attacker from spoofing packets or modifying packets
   in transit.  They do not prevent an authorized RADIUS/Diameter server
   or proxy from inserting attributes with malicious intent.

   VLAN attributes sent by a RADIUS/Diameter server or proxy may enable
   access to unauthorized VLANs.  These vulnerabilities can be limited
   by performing authorization checks at the NAS.  For example, a NAS
   can be configured to accept only certain VLANIDs from a given
   RADIUS/Diameter server/proxy.

   Similarly, an attacker gaining control of a RADIUS/Diameter server or
   proxy can modify the user priority table, causing either degradation
   of quality of service (by downgrading user priority of frames
   arriving at a port), or denial of service (by raising the level of
   priority of traffic at multiple ports of a device, oversubscribing
   the switch or link capabilities)."

--
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, 12 Jun 2006 01:31:37 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: DISCUSS: draft-ietf-radext-vlan
Date: Sun, 11 Jun 2006 18:31:13 -0700

> > I don't believe there are any substantial differences in the security
> > implications of these attributes in RADIUS vs. Diameter, and I'd
> > suggest that the document say this and leave it at that.
>
>I agree.

Here is a rewrite of the Security Considerations of the VLAN document to 
address Russ's DISCUSS comment:

6.  Security Considerations

   This specification describes the use of RADIUS and Diameter for
   purposes of authentication, authorization and accounting in IEEE 802
   local area networks.  RADIUS threats and security issues for this
   application are described in [RFC3579] and [RFC3580]; security issues
   encountered in roaming are described in [RFC2607].  For Diameter, the
   security issues relating to this application are described in
   [RFC4005] and [RFC4072].

   This document specifies new attributes that can be included in
   existing RADIUS packets, which are protected as described in
   [RFC3579] and [RFC3576].  In Diameter, the attributes are protected
   as specified in [RFC3588]. See those documents for a more detailed
   description.

   The security mechanisms supported in RADIUS and Diameter are focused
   on preventing an attacker from spoofing packets or modifying packets
   in transit.  They do not prevent an authorized AAA server or proxy
   from inserting attributes with malicious intent.

   VLAN attributes sent by a server or proxy may enable access to
   unauthorized VLANs.  These vulnerabilities can be limited by
   performing authorization checks at the NAS.  For example, a NAS can
   be configured to accept only certain VLANIDs from a given AAA
   server/proxy.

   Similarly, an attacker gaining control of a AAA server or proxy can
   modify the user priority table, causing either degradation of quality
   of service (by downgrading user priority of frames arriving at a
   port), or denial of service (by raising the level of priority of
   traffic at multiple ports of a device, oversubscribing the switch or
   link capabilities).

--
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, 12 Jun 2006 00:11:22 +0000
Date: Sun, 11 Jun 2006 22:10:52 +0200
From: Hannes Tschofenig <[email-masked]>
To: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
CC:  [email-masked]
Subject: Re: Questions about draft-ietf-radext-filter-rules-00.txt

Hi Mauricio,

thanks for your response. Please find my comments inline:

Sanchez, Mauricio (ProCurve) wrote:

>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Hannes Tschofenig
>>Sent: Monday, June 05, 2006 3:02 AM
>>To: [email-masked]
>>Subject: Questions about draft-ietf-radext-filter-rules-00.txt
>>
>>Hi all,
>>
>>I have two questions regarding the filter rules draft:
>>
>>1) Is is possible to define the draft in such a way that the 
>>actions can be extended? I would like to use the filter rule 
>>format for QoS. For example, I would like to express 
>>something like the following:
>>
>>          qos qparam1 in from 192.0.2.168 1234 to 2345
>>          qparam1=some qos parameters
> 
> 
> I'd be leery to go down this pass given that some already argue that the
> syntax is already complex.

That's a standard argument.

The encoding is obviously not compact. There is plenty of room for 
improvement...

   Moreover, IMHO allowing proprietary
> extensions somewhat dilutes the customer value of having a standardized
> attribute.  Why not just define a VSA at this point?

You mix two functions into the filter language:

* Description of the data traffic (often referred as flow identifier)

* Action that is applied to the data traffic

Since you mesh the two aspects together you prevent it from being used 
in a generic way.

There is also the desire to align this with Diameter, as you know. I 
wonder how this would work.

> 
> Rather, I'd rather talk about what you need.  It sounds like you want to
> perform some sort of QoS reclassification based on L3-L4 information.
Layer 2, 3 and 4.

> Can you describe more in depth what your requirements are and what you'd
> like to accomplish?  Given the syntax is not closed at this point, it's
> still open to new extensions and modifications.  

We might be aware of the QoS work in DIME. We need a description of the 
data traffic and the respective QoS treatment. Alignment with the RADIUS 
QoS work would be important.

We wrote a strawman proposal some time back, with 
http://www.tschofenig.com/drafts/draft-tschofenig-radext-qos-02.txt
If possible, we should align it with the rest of the DIME QoS work and 
potentially with the filter-rule work.

> 
> 
> 
>>2) What happens if the IP address of the end host is not 
>>known when the NAS-Traffic-Rule attribute is sent from the 
>>RADIUS server to the RADIUS client in the Access-Accept? Is 
>>there a field to indicate that the RADIUS client should 
>>instantiate the rule when the end host gets the IP address assigned?
> 
> 
> There already exists a technique to address this use case. The keyword
> 'assigned' can be assigned in the place of the source IP field.
> 'assigned' is defined as the IP associated with the terminal.  What is
> not described is the method by which the NAS determines the IP of a
> terminal.

I missed this aspect. Thanks for point me to it.

Ciao
Hannes

> 
> MS
> 
> 

--
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, 11 Jun 2006 02:46:50 +0000
Content-class: urn:content-classes:message
Subject: RE: FW: DISCUSS: draft-ietf-radext-delegated-prefix
Date: Sat, 10 Jun 2006 19:46:05 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

Bernard Aboba <> supposedly scribbled:

>> This IESG DISCUSS comment from Russ applies equally to all RADEXT WG
>> documents that provide for Diameter AVPs, whether by the RFC 4005
>> Diameter NAS Application method, or by some other explicit means.  We
>> need to develop a suitable chunk of template text for the Security
>> Considerations section of RADEXT WG documents to address Diameter
>> security considerations, as well as RADIUS security considerations.
>=20
> I don't believe there are any substantial differences in the security
> implications of these attributes in RADIUS vs. Diameter, and I'd
> suggest that the document say this and leave it at that.=20

I agree.=20

Hope this helps,

~gwz

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

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

Delivery-date: Sat, 10 Jun 2006 05:00:32 +0000
Content-class: urn:content-classes:message
Subject: RE: Diameter Considerations Section
Date: Sat, 10 Jun 2006 07:59:56 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

That's my reading as well.

John=20

>-----Original Message-----
>From: [email-masked]=20
>[mailto:[email-masked]] On Behalf Of ext Nelson, David
>Sent: 09 June, 2006 23:28
>To: [email-masked]
>Subject: RE: Diameter Considerations Section
>
>Glen Zorn writes...
>
>> IIRC, the intent was that Diameter would (MUST) support all standard=20
>> RADIUS attributes.  Of course, at the time it was (rather naively)=20
>> supposed that no more standard RADIUS attributes would be defined.
>Given
>> this, I don't really think that new App-Ids need to be assigned; in
>fact,
>> if such an assignment took place, I would argue that the=20
>attributes in=20
>> question should be mapped to new Diameter AVPs, rather than=20
>handled in
>the
>> same way as legacy standard RADIUS attributes.
>
>I think this is correct.  Since RADIUS does not have the=20
>notion of Application IDs, then all RADIUS attributes that are=20
>"imported" to Diameter via the RFC 4005 mechanism ought to=20
>have the same Diameter Application ID.
>
>
>--
>to unsubscribe send a message to=20
>[email-masked] with the word 'unsubscribe' in=20
>a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>
>

--
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, 09 Jun 2006 22:30:58 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: FW: DISCUSS: draft-ietf-radext-delegated-prefix
Date: Fri, 09 Jun 2006 15:30:29 -0700

>This IESG DISCUSS comment from Russ applies equally to all RADEXT WG
>documents that provide for Diameter AVPs, whether by the RFC 4005
>Diameter NAS Application method, or by some other explicit means.  We
>need to develop a suitable chunk of template text for the Security
>Considerations section of RADEXT WG documents to address Diameter
>security considerations, as well as RADIUS security considerations.

I don't believe there are any substantial differences in the security 
implications of these attributes in RADIUS vs. Diameter, and I'd suggest 
that the document say this and leave it at that.

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

Delivery-date: Fri, 09 Jun 2006 21:02:54 +0000
Content-class: urn:content-classes:message
Subject: FW: DISCUSS: draft-ietf-radext-delegated-prefix 
Date: Fri, 9 Jun 2006 17:02:32 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Russ Housley writes...

Discuss:

  The Abstract says: "This attribute is usable within either RADIUS
  or Diameter."  However, the Security Considerations only deal with
  RADIUS.  Please expand the Security Considerations to address both
  protocol environments.

This IESG DISCUSS comment from Russ applies equally to all RADEXT WG
documents that provide for Diameter AVPs, whether by the RFC 4005
Diameter NAS Application method, or by some other explicit means.  We
need to develop a suitable chunk of template text for the Security
Considerations section of RADEXT WG documents to address Diameter
security considerations, as well as RADIUS security considerations.=20

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

Delivery-date: Fri, 09 Jun 2006 20:28:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Diameter Considerations Section
Date: Fri, 9 Jun 2006 16:27:33 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Glen Zorn writes...

> IIRC, the intent was that Diameter would (MUST) support all standard
> RADIUS attributes.  Of course, at the time it was (rather naively)
> supposed that no more standard RADIUS attributes would be defined.
Given
> this, I don't really think that new App-Ids need to be assigned; in
fact,
> if such an assignment took place, I would argue that the attributes in
> question should be mapped to new Diameter AVPs, rather than handled in
the
> same way as legacy standard RADIUS attributes.

I think this is correct.  Since RADIUS does not have the notion of
Application IDs, then all RADIUS attributes that are "imported" to
Diameter via the RFC 4005 mechanism ought to have the same Diameter
Application ID.

--
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, 09 Jun 2006 15:50:16 +0000
Content-class: urn:content-classes:message
Subject: RE: Genart review of draft-ietf-radext-dynauth-server-mib-05 /  draft-ietf-radext-dynauth-client-mib-05
Date: Fri, 9 Jun 2006 11:49:56 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, "Ron Bonica" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

> > - Can I assume that it has passed MIB Rx Review? (It compiles
clean).

It has.

> > - Should this MIB *ever* be used in conjuntion with SNMPv1? I know
that
> > you *recommend* against it. But it seems that divulging the
information
> > in this mib to a hostile party might be pretty bad.

I think the standard warning is appropriate.  It SHOULD NOT be used in
conjunction with SNMPv1 in the general case.  There might be some
particular environments, e.g. enterprise LANs with protected management
VLANs, in which the operator is convinced that the use of SNMPv1 does
not give rise to any meaningful security risks.  I think that the
recommendation is appropriate, and one couldn't really mandate what
operators will do, in any event.

--
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, 09 Jun 2006 15:42:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Diameter Considerations  Section (VLAN/Priority, Delegated  Prefix,etc.)
Date: Fri, 9 Jun 2006 11:42:22 -0400
From: "Nelson, David" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, "Greg Weber \(gdweber\)" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "Ralph Droms \(rdroms\)" <[email-masked]>, <[email-masked]>

Jari Arkko writes...

> >Is the M-bit supposed to be set for these RADIUS attrs?
> >
> Good question. Based on Section 1.3 of the vlan document,
> I believe the M bit may have to be set in AA-Answer message.

I think that was the intent of the text in Section 1.3, to make the
attributes in this document "implicitly mandatory" in the RADIUS
tradition, such as is the case with the Service-Type 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, 09 Jun 2006 15:15:08 +0000
Content-class: urn:content-classes:message
Subject: RE: Diameter Considerations Section
Date: Fri, 9 Jun 2006 08:14:46 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Bernard Aboba <> supposedly scribbled:

> Greg Weber said:
> "     In section 4.1 of RFC 3588, I see:
>       Unless otherwise noted, AVPs will have the following default AVP
>       Flags field settings:
>          The 'M' bit MUST be set.  The 'V' bit MUST NOT be set.
>=20
> Is the M-bit supposed to be set for these RADIUS attrs?"

I think so.

>=20
> Jari Arkko said:
>=20
> "Good question. Based on Section 1.3 of the vlan document, I believe
> the M bit may have to be set in AA-Answer message.=20
> There may be other issues like that -- please review the text
> carefully."=20
>=20
> Given the security implications I think that the 'M' bit must be set
> for the Egress-VLANID, Ingress-Fitlers, and Egress-VLAN-Name
> attributes and may or may not be set for the User-Priority-Table
> attribute.  Here is the modified text: =20
>=20
>    When used in Diameter, the attributes defined in this specification
>    can be used as Diameter AVPs from the Code space 1-255 (RADIUS
>    attribute compatibility space). No additional Diameter Code values
>    are therefore allocated. The data types and flag rules for the
>    attributes are as follows:
>=20
>                                   +---------------------+
>                                   |    AVP Flag rules   |
>                                   |----+-----+----+-----|----+
>                                   |    |     |SHLD| MUST|    |
>    Attribute Name      Value Type |MUST| MAY | NOT|  NOT|Encr|
>    -------------------------------|----+-----+----+-----|----|
>    Egress-VLANID       OctetString| M  |  P  |    |  V  | Y  |
>    Ingress-Filters     Enumerated | M  |  P  |    |  V  | Y  |
>    Egress-VLAN-Name    UTF8String | M  |  P  |    |  V  | Y  |
>    User-Priority-Table OctetString|    | M,P |    |  V  | Y  |
>    -------------------------------|----+-----+----+-----|----|
>=20
> This brings up another issue.  I believe that the addition of
> Mandatory attributes to RFC 4005 and 4072 requires assignment of new
> Application-Ids, correct? =20

IIRC, the intent was that Diameter would (MUST) support all standard =
RADIUS attributes.  Of course, at the time it was (rather naively) =
supposed that no more standard RADIUS attributes would be defined.  =
Given this, I don't really think that new App-Ids need to be assigned; =
in fact, if such an assignment took place, I would argue that the =
attributes in question should be mapped to new Diameter AVPs, rather =
than handled in the same way as legacy standard RADIUS attributes.

Hope this helps,

~gwz

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

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

Delivery-date: Fri, 09 Jun 2006 14:31:52 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Diameter Considerations Section
Date: Fri, 09 Jun 2006 07:31:18 -0700

Greg Weber said:
"     In section 4.1 of RFC 3588, I see:
      Unless otherwise noted, AVPs will have the following default AVP
      Flags field settings:
         The 'M' bit MUST be set.  The 'V' bit MUST NOT be set.

Is the M-bit supposed to be set for these RADIUS attrs?"

Jari Arkko said:

"Good question. Based on Section 1.3 of the vlan document,
I believe the M bit may have to be set in AA-Answer message.
There may be other issues like that -- please review the text
carefully."

Given the security implications I think that the 'M' bit must be set for the 
Egress-VLANID, Ingress-Fitlers, and Egress-VLAN-Name attributes and may or 
may not be set for the User-Priority-Table attribute.  Here is the modified 
text:

   When used in Diameter, the attributes defined in this specification
   can be used as Diameter AVPs from the Code space 1-255 (RADIUS
   attribute compatibility space). No additional Diameter Code values
   are therefore allocated. The data types and flag rules for the
   attributes are as follows:

                                  +---------------------+
                                  |    AVP Flag rules   |
                                  |----+-----+----+-----|----+
                                  |    |     |SHLD| MUST|    |
   Attribute Name      Value Type |MUST| MAY | NOT|  NOT|Encr|
   -------------------------------|----+-----+----+-----|----|
   Egress-VLANID       OctetString| M  |  P  |    |  V  | Y  |
   Ingress-Filters     Enumerated | M  |  P  |    |  V  | Y  |
   Egress-VLAN-Name    UTF8String | M  |  P  |    |  V  | Y  |
   User-Priority-Table OctetString|    | M,P |    |  V  | Y  |
   -------------------------------|----+-----+----+-----|----|

This brings up another issue.  I believe that the addition of Mandatory 
attributes to RFC 4005 and 4072 requires assignment of new Application-Ids, 
correct?

--
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, 08 Jun 2006 10:18:10 +0000
Date: Thu, 08 Jun 2006 12:17:08 +0200
From: [email-masked]
To: Ron Bonica <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Genart review of draft-ietf-radext-dynauth-server-mib-05 / draft-ietf-radext-dynauth-client-mib-05

Hi Ron,

Thanks for the review, see below for some answers

Ron Bonica wrote:

> I am the assigned Gen-ART reviewer for:
> draft-ietf-radext-dynauth-server-mib-05
>           -and-
> draft-ietf-radext-dynauth-client-mib-05
> 
> 
> For background on Gen-ART, please see the FAQ at
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> This draft is ready for publication as a Standards Track document,
> except for the following nit:
> 

In fact, the 2 documents are informational.

> - The client MIB contains a note to the RFC editor about the reference
> [DYNSERV]. However, there is no such reference.
> 

I checked it and the client MIB is Ok, in the server MIB it seems that 
the RFC ed note is incorrect and [DYNSERV] should be replaced by 
[DYNCLNT]. The references in both of the drafts are correct, with the 
exception of the RFC ed note in the server MIB.

> And two substantial questions:
> 
> - Can I assume that it has passed MIB Rx Review? (It compiles clean).
> 

Not sure what MIB Rx review is. I compliled the MIB with Smilent.

> - Should this MIB *ever* be used in conjuntion with SNMPv1? I know that
> you *recommend* against it. But it seems that divulging the information
> in this mib to a hostile party might be pretty bad.
> 

http://www.ops.ietf.org/mib-security.html contains preformatted text for 
the security section and that text was put in the draft. See the text on 
that webpage in the section "-- else if there are no read-write objects 
in your MIB module". The text in the draft is more or less a copy/paste 
from that webpage. Also the other Radius MIBs like 
draft-ietf-radext-rfc2618bis-03.txt are also following the guidelines on 
the mentioned webpage.

regards,
Stefaan

>                                       Ron
> 
> 

--
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, 07 Jun 2006 18:50:46 +0000
Date: Wed, 07 Jun 2006 21:50:05 +0300
From: Jari Arkko <[email-masked]>
To: "Greg Weber (gdweber)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  "Ralph Droms (rdroms)" <[email-masked]>, [email-masked]
Subject: Re: Diameter Considerations  Section (VLAN/Priority, Delegated Prefix, etc.)

Greg Weber (gdweber) wrote:

>>
>>   When used in Diameter, the attributes defined in this
>>   specification can be used as Diameter AVPs from the
>>   Code space 1-255, i.e., RADIUS attribute compatibility
>>   space. No additional Diameter Code values are therefore
>>   allocated. The data types of the attributes are as
>>   follows:
>>
>>     Egress-VLANID                     OctetString
>>     Ingress-Filters                   Enumerated
>>     Egress-VLAN-Name                  UTF8String
>>     User-Priority-Table               OctetString
>>
>>   The attributes in this specification have no special
>>   translation requirements for Diameter to RADIUS or
>>   RADIUS to Diameter gateways, i.e., the attributes
>>   are copied as is, except for changes relating to
>>   headers, alignment, and padding. See also
>>   [RFC 3588] Section 4.1 and [RFC 4005] Section 9.
>>    
>>
>
>GDW> In section 4.1 of RFC 3588, I see:
>      Unless otherwise noted, AVPs will have the following default AVP
>      Flags field settings:
>
>         The 'M' bit MUST be set.  The 'V' bit MUST NOT be set.
>
>Is the M-bit supposed to be set for these RADIUS attrs?
>  
>
Good question. Based on Section 1.3 of the vlan document,
I believe the M bit may have to be set in AA-Answer message.

There may be other issues like that -- please review the text
carefully.

--Jari

--
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, 07 Jun 2006 16:44:47 +0000
Content-class: urn:content-classes:message
Subject: RE: Diameter Considerations  Section (VLAN/Priority, Delegated Prefix, etc.)
Date: Wed, 7 Jun 2006 12:44:23 -0400
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: "Ralph Droms \(rdroms\)" <[email-masked]>, <[email-masked]>

A question inline at GDW>=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, June 07, 2006 12:19 PM
> To: [email-masked]
> Cc: Ralph Droms (rdroms)
> Subject: Diameter Considerations Section (VLAN/Priority,=20
> Delegated Prefix, etc.)
>=20
> Jari Arkko has suggested a new template for Diameter=20
> Considerations sections=20
> in RADEXT WG documents.  I believe this suggestion applies to=20
> both the=20
> VLAN/Priority and Delegated Prefix attributes.
>=20
> --------------------------------------------------------------
> ------------------
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Wed 6/7/2006 3:29 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: DISCUSS: draft-ietf-radext-vlan
>=20
>=20
> Discuss:
> I am raising an issue that is largely about the same text as=20
> Dan already
> commented on. But the main issue is not inconsistency in this=20
> specification
> but rather the need to fulfill requirements from the WG's charter and
> the desire to keep the RADIUS and Diameter protocols=20
> interoperable through
> gateways.
>=20
> Fortunately, I think we can correct this issue relatively easily.
>=20
> The document said this:
>=20
> >4.  Diameter Considerations
> >
> >   Diameter needs to define identical attributes with the same Type
> >   values.  The attributes should be available as part of the NASREQ
> >   application [RFC4005], as well as the Diameter EAP application
> >   [RFC4072].
>=20
> But RADEXT charter says:
>=20
> >All RADIUS work MUST be compatible with equivalent facilities in
> >Diameter. Where possible, new attributes should be defined so that
> >the same attribute can be used in both RADIUS and Diameter without
> >translation.
>=20
> In this case I believe there is no technical reason to require
> different attributes. I would suggest the following contents
> for Section 4:
>=20
>    When used in Diameter, the attributes defined in this
>    specification can be used as Diameter AVPs from the
>    Code space 1-255, i.e., RADIUS attribute compatibility
>    space. No additional Diameter Code values are therefore
>    allocated. The data types of the attributes are as
>    follows:
>=20
>      Egress-VLANID                     OctetString
>      Ingress-Filters                   Enumerated
>      Egress-VLAN-Name                  UTF8String
>      User-Priority-Table               OctetString
>=20
>    The attributes in this specification have no special
>    translation requirements for Diameter to RADIUS or
>    RADIUS to Diameter gateways, i.e., the attributes
>    are copied as is, except for changes relating to
>    headers, alignment, and padding. See also
>    [RFC 3588] Section 4.1 and [RFC 4005] Section 9.

GDW> In section 4.1 of RFC 3588, I see:
      Unless otherwise noted, AVPs will have the following default AVP
      Flags field settings:

         The 'M' bit MUST be set.  The 'V' bit MUST NOT be set.

Is the M-bit supposed to be set for these RADIUS attrs?

Greg

>=20
>    What this specification says about the applicability
>    of the attributes for RADIUS Access-Request applies
>    in Diameter to AA-Request [RFC 4005] or Diameter-EAP-Request
>    [RFC 4072]. What is said about Access-Challenge applies
>    in Diameter to AA-Answer [RFC 4005] or Diameter-EAP-Answer
>    [RFC 4072] with Result-Code AVP set to
>    DIAMETER_MULTI_ROUND_AUTH.
>=20
>    What is said about Access-Accept applies in Diameter
>    to AA-Answer or Diameter-EAP-Answer that indicates
>    success. Similarly, what is said about Access-Reject
>    applies in Diameter to AA-Answer or Diameter-EAP-Answer
>    that indicates failure.
>=20
>    What is said about COA-Request applies in Diameter
>    to Re-Auth-Request [RFC 4005].
>=20
>    What is said about Accounting-Request applies to
>    Diameter Accounting-Request [RFC 4005] as well.
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
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, 07 Jun 2006 16:22:19 +0000
content-class: urn:content-classes:message
Subject: RE: Diameter Considerations  Section (VLAN/Priority, Delegated Prefix, etc.)
Date: Wed, 7 Jun 2006 19:22:10 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

FWIW - This proposal would answer my concerns expressed in the COMMENTs
made vs. the two documents on the IESG agenda this week.=20

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, June 07, 2006 7:19 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Diameter Considerations Section (VLAN/Priority,=20
> Delegated Prefix, etc.)
>=20
> Jari Arkko has suggested a new template for Diameter=20
> Considerations sections in RADEXT WG documents.  I believe=20
> this suggestion applies to both the VLAN/Priority and=20
> Delegated Prefix attributes.
>=20
> --------------------------------------------------------------
> ------------------
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Wed 6/7/2006 3:29 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: DISCUSS: draft-ietf-radext-vlan
>=20
>=20
> Discuss:
> I am raising an issue that is largely about the same text as=20
> Dan already commented on. But the main issue is not=20
> inconsistency in this specification but rather the need to=20
> fulfill requirements from the WG's charter and the desire to=20
> keep the RADIUS and Diameter protocols interoperable through gateways.
>=20
> Fortunately, I think we can correct this issue relatively easily.
>=20
> The document said this:
>=20
> >4.  Diameter Considerations
> >
> >   Diameter needs to define identical attributes with the same Type
> >   values.  The attributes should be available as part of the NASREQ
> >   application [RFC4005], as well as the Diameter EAP application
> >   [RFC4072].
>=20
> But RADEXT charter says:
>=20
> >All RADIUS work MUST be compatible with equivalent facilities in=20
> >Diameter. Where possible, new attributes should be defined=20
> so that the=20
> >same attribute can be used in both RADIUS and Diameter without=20
> >translation.
>=20
> In this case I believe there is no technical reason to=20
> require different attributes. I would suggest the following=20
> contents for Section 4:
>=20
>    When used in Diameter, the attributes defined in this
>    specification can be used as Diameter AVPs from the
>    Code space 1-255, i.e., RADIUS attribute compatibility
>    space. No additional Diameter Code values are therefore
>    allocated. The data types of the attributes are as
>    follows:
>=20
>      Egress-VLANID                     OctetString
>      Ingress-Filters                   Enumerated
>      Egress-VLAN-Name                  UTF8String
>      User-Priority-Table               OctetString
>=20
>    The attributes in this specification have no special
>    translation requirements for Diameter to RADIUS or
>    RADIUS to Diameter gateways, i.e., the attributes
>    are copied as is, except for changes relating to
>    headers, alignment, and padding. See also
>    [RFC 3588] Section 4.1 and [RFC 4005] Section 9.
>=20
>    What this specification says about the applicability
>    of the attributes for RADIUS Access-Request applies
>    in Diameter to AA-Request [RFC 4005] or Diameter-EAP-Request
>    [RFC 4072]. What is said about Access-Challenge applies
>    in Diameter to AA-Answer [RFC 4005] or Diameter-EAP-Answer
>    [RFC 4072] with Result-Code AVP set to
>    DIAMETER_MULTI_ROUND_AUTH.
>=20
>    What is said about Access-Accept applies in Diameter
>    to AA-Answer or Diameter-EAP-Answer that indicates
>    success. Similarly, what is said about Access-Reject
>    applies in Diameter to AA-Answer or Diameter-EAP-Answer
>    that indicates failure.
>=20
>    What is said about COA-Request applies in Diameter
>    to Re-Auth-Request [RFC 4005].
>=20
>    What is said about Accounting-Request applies to
>    Diameter Accounting-Request [RFC 4005] as well.
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Wed, 07 Jun 2006 16:19:22 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Diameter Considerations  Section (VLAN/Priority, Delegated Prefix, etc.)
Date: Wed, 07 Jun 2006 09:19:13 -0700

Jari Arkko has suggested a new template for Diameter Considerations sections 
in RADEXT WG documents.  I believe this suggestion applies to both the 
VLAN/Priority and Delegated Prefix attributes.

--------------------------------------------------------------------------------
From: Jari Arkko [mailto:[email-masked]]
Sent: Wed 6/7/2006 3:29 AM
To: [email-masked]
Cc: [email-masked]
Subject: DISCUSS: draft-ietf-radext-vlan

Discuss:
I am raising an issue that is largely about the same text as Dan already
commented on. But the main issue is not inconsistency in this specification
but rather the need to fulfill requirements from the WG's charter and
the desire to keep the RADIUS and Diameter protocols interoperable through
gateways.

Fortunately, I think we can correct this issue relatively easily.

The document said this:

>4.  Diameter Considerations
>
>   Diameter needs to define identical attributes with the same Type
>   values.  The attributes should be available as part of the NASREQ
>   application [RFC4005], as well as the Diameter EAP application
>   [RFC4072].

But RADEXT charter says:

>All RADIUS work MUST be compatible with equivalent facilities in
>Diameter. Where possible, new attributes should be defined so that
>the same attribute can be used in both RADIUS and Diameter without
>translation.

In this case I believe there is no technical reason to require
different attributes. I would suggest the following contents
for Section 4:

   When used in Diameter, the attributes defined in this
   specification can be used as Diameter AVPs from the
   Code space 1-255, i.e., RADIUS attribute compatibility
   space. No additional Diameter Code values are therefore
   allocated. The data types of the attributes are as
   follows:

     Egress-VLANID                     OctetString
     Ingress-Filters                   Enumerated
     Egress-VLAN-Name                  UTF8String
     User-Priority-Table               OctetString

   The attributes in this specification have no special
   translation requirements for Diameter to RADIUS or
   RADIUS to Diameter gateways, i.e., the attributes
   are copied as is, except for changes relating to
   headers, alignment, and padding. See also
   [RFC 3588] Section 4.1 and [RFC 4005] Section 9.

   What this specification says about the applicability
   of the attributes for RADIUS Access-Request applies
   in Diameter to AA-Request [RFC 4005] or Diameter-EAP-Request
   [RFC 4072]. What is said about Access-Challenge applies
   in Diameter to AA-Answer [RFC 4005] or Diameter-EAP-Answer
   [RFC 4072] with Result-Code AVP set to
   DIAMETER_MULTI_ROUND_AUTH.

   What is said about Access-Accept applies in Diameter
   to AA-Answer or Diameter-EAP-Answer that indicates
   success. Similarly, what is said about Access-Reject
   applies in Diameter to AA-Answer or Diameter-EAP-Answer
   that indicates failure.

   What is said about COA-Request applies in Diameter
   to Re-Auth-Request [RFC 4005].

   What is said about Accounting-Request applies to
   Diameter Accounting-Request [RFC 4005] as well.

--
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, 07 Jun 2006 16:16:17 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions about draft-ietf-radext-filter-rules-00.txt
Date: Wed, 7 Jun 2006 09:15:07 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>, <[email-masked]>

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Monday, June 05, 2006 3:02 AM
> To: [email-masked]
> Subject: Questions about draft-ietf-radext-filter-rules-00.txt
>=20
> Hi all,
>=20
> I have two questions regarding the filter rules draft:
>=20
> 1) Is is possible to define the draft in such a way that the=20
> actions can be extended? I would like to use the filter rule=20
> format for QoS. For example, I would like to express=20
> something like the following:
>=20
>           qos qparam1 in from 192.0.2.168 1234 to 2345
>           qparam1=3Dsome qos parameters

I'd be leery to go down this pass given that some already argue that the
syntax is already complex.  Moreover, IMHO allowing proprietary
extensions somewhat dilutes the customer value of having a standardized
attribute.  Why not just define a VSA at this point?

Rather, I'd rather talk about what you need.  It sounds like you want to
perform some sort of QoS reclassification based on L3-L4 information.
Can you describe more in depth what your requirements are and what you'd
like to accomplish?  Given the syntax is not closed at this point, it's
still open to new extensions and modifications. =20

> 2) What happens if the IP address of the end host is not=20
> known when the NAS-Traffic-Rule attribute is sent from the=20
> RADIUS server to the RADIUS client in the Access-Accept? Is=20
> there a field to indicate that the RADIUS client should=20
> instantiate the rule when the end host gets the IP address assigned?

There already exists a technique to address this use case. The keyword
'assigned' can be assigned in the place of the source IP field.
'assigned' is defined as the IP associated with the terminal.  What is
not described is the method by which the NAS determines the IP of a
terminal.=20

MS

--
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, 07 Jun 2006 11:02:10 +0000
Date: Mon, 05 Jun 2006 12:01:32 +0200
From: Hannes Tschofenig <[email-masked]>
To:  [email-masked]
Subject: Questions about draft-ietf-radext-filter-rules-00.txt

Hi all,

I have two questions regarding the filter rules draft:

1) Is is possible to define the draft in such a way that the actions can 
be extended? I would like to use the filter rule format for QoS. For 
example, I would like to express something like the following:

          qos qparam1 in from 192.0.2.168 1234 to 2345
          qparam1=some qos parameters

2) What happens if the IP address of the end host is not known when the 
NAS-Traffic-Rule attribute is sent from the RADIUS server to the RADIUS 
client in the Access-Accept? Is there a field to indicate that the 
RADIUS client should instantiate the rule when the end host gets the IP 
address assigned?

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

Delivery-date: Wed, 07 Jun 2006 08:38:31 +0000
Date: Wed, 07 Jun 2006 10:37:53 +0200
From: [email-masked]
To: [email-masked]
Subject: overview comments RFC3576 MIBs received until now

Hi,

The RFC3576 MIBs are currently in IETF last call, so far there are 2 
comments that will be included in the next version of the draft when the 
last call is finished. An overview:

* draft-ietf-dynauth-client-mib-06.txt

1) issue 193: change SYNTAX of radiusDynAuthServerClientPortNumber from 
"InetPortNumber" to "InetPortNumber (1..65535)"

    radiusDynAuthServerClientPortNumber OBJECT-TYPE
           SYNTAX     InetPortNumber (1..65535)
           MAX-ACCESS read-only
           STATUS     current
           DESCRIPTION
                 "The UDP destination port that the RADIUS Dynamic
                  Authorization Client is using to send requests to this
                  server. The value zero is invalid."
           ::= { radiusDynAuthServerEntry 4 }

2) remove radiusDynAuthClientCounterDiscontinuity as a scaler and put it 
as last attribute in the table. Description has been updated slightly as 
well as a small update in the conformance statement to reflect the move 
of this attribute into the table. Also a small update of the overview 
section that describes high level the scalars and table.

    radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE
           SYNTAX TimeTicks
           UNITS  "hundredths of a second"
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
                 "The time (in hundredths of a second) since the
                  last counter discontinuity. A discontinuity may
                  be the result of a reinitialization of the DAC
                  module within the managed entity."
           ::= { radiusDynAuthServerEntry 32 }

3) update date of draft and also inside the MIB

* draft-ietf-dynauth-server-mib-06.txt

1) remove radiusDynAuthServerCounterDiscontinuity as a scaler and put it 
as last attribute in the table. Description has been updated slightly as 
well as a small update in the conformance statement to reflect the move 
of this attribute into the table. Also a small update of the overview 
section that describes high level the scalars and table.

    radiusDynAuthServerCounterDiscontinuity OBJECT-TYPE
           SYNTAX TimeTicks
           UNITS  "hundredths of a second"
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
                 "The time (in hundredths of a second) since the
                  last counter discontinuity. A discontinuity may
                  be the result of a reinitialization of the DAS
                  module within the managed entity."
           ::= { radiusDynAuthClientEntry 27 }

2) update date of draft and also inside the MIB

regards,

Stefaan

--
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, 04 Jun 2006 19:34:40 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 196: User-Name Attribute
Date: Sun, 4 Jun 2006 12:34:26 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <> supposedly scribbled:

>> Right, but it's my understanding (laboriously gained, yet perhaps
>> still flawed) that the SIP proxy >functionality was expected to
>> deliver the SIP request to the destination realm; if the user has no
>> >account in that realm, they are simply out of luck.  This would
>> seem to imply that RADIUS proxies >are unnecessary, at least insofar
>> as inter-realm routing is concerned.
>=20
> That might be correct, but it is still possible for proxies to be
> deployed within the destination realm, no?=20
>=20

I suppose so, but it seems like their purpose would be other than =
routing (except in a non-NAI-specific fashion like load-balancing).

...

Hope this helps,

~gwz

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

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

Delivery-date: Sun, 04 Jun 2006 18:48:58 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: Issue 196: User-Name Attribute
Date: Sun, 04 Jun 2006 11:48:09 -0700

>Right, but it's my understanding (laboriously gained, yet perhaps still 
>flawed) that the SIP proxy >functionality was expected to deliver the SIP 
>request to the destination realm; if the user has no >account in that 
>realm, they are simply out of luck.  This would seem to imply that RADIUS 
>proxies >are unnecessary, at least insofar as inter-realm routing is 
>concerned.

That might be correct, but it is still possible for proxies to be deployed 
within the destination realm, no?

>OK, I give up: how does the Calling-Station-Id help to route RADIUS 
>packets?

Presumably a RADIUS proxy determines that the Calling-Station-Id has been 
placed in the User-Name attribute by comparing it to the Calling-Station-Id, 
and then routes the request to the RADIUS server in the local realm.

Of course, I'm not clear that RFC 3579 implementations actually do this; 
most RADIUS clients always send an EAP-Request/Identity and so they always 
have something to put in the User-Name attribute (except if the client 
responds with a null EAP-Response/Identity).

This specification seems unique in that the RADIUS client will *never* have 
something to put in the User-Name attribute, so this is no longer a corner 
condition.

--
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, 04 Jun 2006 14:50:59 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 196: User-Name Attribute
Date: Sun, 4 Jun 2006 07:50:46 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, "Glen Zorn \(gwz\)" <[email-masked]>

Bernard Aboba <> supposedly scribbled:

>> Who cares?  I'm not being facetious: if the value is unknown by the
>> client & unused by the >server, why does it matter what the value is?
>=20
> The lack of a User-Name attribute may prevent proxies from forwarding
> the Access-Request.  Also, some RADIUS servers will not be able to
> handle an Access-Request without a User-Name attribute.=20

Right, but it's my understanding (laboriously gained, yet perhaps still =
flawed) that the SIP proxy functionality was expected to deliver the SIP =
request to the destination realm; if the user has no account in that =
realm, they are simply out of luck.  This would seem to imply that =
RADIUS proxies are unnecessary, at least insofar as inter-realm routing =
is concerned. =20

>=20
> Note that this problem has been encountered before.  For example, in
> RFC 3579 there are situations in which the User-Name is not known,
> such as when the NAS does not send an EAP-Reuqest/Identity to
> initiate the EAP exchange (e.g. NAS could start off with an
> EAP-Request for a method, or could send an EAP-Start to the RADIUS
> server).  Despite this, RFC 3579 always fills in the User-Name
> attribute.    =20
>=20
> RFC 3579 Section 2.1 recommends:
>=20
> "  If the NAS initially sends an EAP-Request for an
>    authentication method, and the peer identity cannot be determined
>    from the EAP-Response, then the User-Name attribute SHOULD be
>    determined by another means.  As noted in [RFC2865] Section 5.6, it
>    is recommended that Access-Requests use the value of the
>    Calling-Station-Id as the value of the User-Name attribute."

OK, I give up: how does the Calling-Station-Id help to route RADIUS =
packets?

Hope this helps,

~gwz

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

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

Delivery-date: Sun, 04 Jun 2006 14:28:26 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: Issue 196: User-Name Attribute
Date: Sun, 04 Jun 2006 07:27:55 -0700

>Who cares?  I'm not being facetious: if the value is unknown by the client 
>& unused by the >server, why does it matter what the value is?

The lack of a User-Name attribute may prevent proxies from forwarding the 
Access-Request.  Also, some RADIUS servers will not be able to handle an 
Access-Request without a User-Name attribute.

Note that this problem has been encountered before.  For example, in RFC 
3579 there are situations in which the User-Name is not known, such as when 
the NAS does not send an EAP-Reuqest/Identity to initiate the EAP exchange 
(e.g. NAS could start off with an EAP-Request for a method, or could send an 
EAP-Start to the RADIUS server).  Despite this, RFC 3579 always fills in the 
User-Name attribute.

RFC 3579 Section 2.1 recommends:

"  If the NAS initially sends an EAP-Request for an
   authentication method, and the peer identity cannot be determined
   from the EAP-Response, then the User-Name attribute SHOULD be
   determined by another means.  As noted in [RFC2865] Section 5.6, it
   is recommended that Access-Requests use the value of the
   Calling-Station-Id as the value of the User-Name 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: Sun, 04 Jun 2006 04:36:49 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 196:  User-Name Attribute
Date: Sat, 3 Jun 2006 21:36:00 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Bernard Aboba <> supposedly scribbled:

> Issue 196: User-Name Attribute
> Submitter names: Cristina Ruiz
> Submitter email address: [email-masked] Date first
> submitted: June 2, 2006=20
> Reference: http://ops.ietf.org/lists/radiusext/2006/msg00527.html
> Document: DIGEST-09
> Comment type: 'T'echnical
> Priority: S
> Section: 5, 6
> Rationale/Explanation of issue:
>=20
> The User-Name attribute is mandatory in the RADIUS Access Request as
> indicated in the table of attributes (Section 5). But in the initial
> HTTP GET method, the user-name is not received, and in the example
> (Section 6) nothing is sent in the User-name attribute in the B->C
> comunication. What does the RADIUS client include in the User-Name
> attribute in this case? And what shall the RADIUS Server do when this
> dummy user-name is received?  =20

Who cares?  I'm not being facetious: if the value is unknown by the =
client & unused by the server, why does it matter what the value is?
  =20
>=20
> I think the "client nonce generation mode" removed from draft 07 was
> usefull to avoid inventing a user name in  this HTTP case (where the
> nonce generation does not depend on the user and this is not received
> in the initial  request).  Why was it removed?  =20

The answer would be known if the questioner had been paying attention =
during the lengthy discussion of this issue; otherwise, it could be =
found in the archives.  I'm not sure why this qualifies as an "issue".

~gwz

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

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

Delivery-date: Sat, 03 Jun 2006 23:29:17 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue 196:  User-Name Attribute
Date: Sat, 03 Jun 2006 16:28:39 -0700

Issue 196: User-Name Attribute
Submitter names: Cristina Ruiz
Submitter email address: [email-masked]
Date first submitted: June 2, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00527.html
Document: DIGEST-09
Comment type: 'T'echnical
Priority: S
Section: 5, 6
Rationale/Explanation of issue:

The User-Name attribute is mandatory in the RADIUS Access Request as 
indicated in the table of attributes (Section 5). But in the initial HTTP 
GET method, the user-name is not received, and in the example (Section 6) 
nothing is sent in the User-name attribute in the B->C comunication. What 
does the RADIUS client include in the User-Name attribute in this case? And 
what shall the RADIUS Server do when this dummy user-name is received?

I think the "client nonce generation mode" removed from draft 07 was usefull 
to avoid inventing a user name in  this HTTP case (where the nonce 
generation does not depend on the user and this is not received in the 
initial  request).  Why was it removed?

--
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, 02 Jun 2006 06:20:39 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS Digest Authentication document approved for publication
Date: Fri, 2 Jun 2006 08:19:55 +0200
From: "Cristina Ruiz \(E2/EEM\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: "Cristina Ruiz \(E2/EEM\)" <[email-masked]>

Hello,

I've just read the final document (I have been following the evolution =
of this draft a bit), and although I know it is already approved (too =
late for comments), I have a question that I think is not fully =
clarified in the document and could create problems in real =
implementation.

The user-name AVP is mandatory in the RADIUS Access Request as indicated =
in the table of attributes (chapter 5).
But in the initial HTTP GET method, the user-name is not received, and =
in the example (chapter 6) nothing is sent as user-name AVP in the B->C =
comunication.
Which value is supposed to add the RADIUS client as User-name in this =
case? And what shall the RADIUS Server do when this dummy user-name is =
received?

I think the "client nonce generation mode" removed from draft 07 was =
usefull to avoid inventing a user name in this HTTP case (where the =
nonce generation does not depend on the user and this is not received in =
the initial request). Do you know why it was removed?

Best regards,
    Cristina.=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Bernard Aboba
Sent: mi=E9rcoles, 31 de mayo de 2006 18:28
To: [email-masked]
Subject: RADIUS Digest Authentication document approved for publication

Today, the IESG approved the RADIUS Digest Authentication document for =
publication.  Congratulations to the authors!

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