Subject: AAA WG Last Call on draft-ietf-aaa-eap-08.txt
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Date: Mon, 28 Jun 2004 13:49:48 -0700 (PDT)

This is an announcement of a AAA WG Last Call on the Diameter EAP
document, prior to sending this document to the IESG for
consideration as a Proposed Standard.

The document is available for examination here:
http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-08.txt

The WG last call will last until midnite PDT on July 14, 2004. Please send
your comments to the AAA WG mailing list at [email-masked] in the format
specified on the AAA WG Issues list:

http://www.drizzle.com/~aboba/AAA/issues.html

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

Delivery-date: Wed, 23 Jun 2004 17:02:22 +0000
Date: Wed, 23 Jun 2004 10:01:54 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: IETF 60 RADEXT Agenda, Take Three

RADIUS EXTensions WG (RADEXT)

Dates and Times: TBD
=================================

CHAIRS:	Bernard Aboba <[email-masked]>
	David Nelson <[email-masked]>

AGENDA:

Preliminaries - 15 minutes

Bluesheets
Meeting Minutes
Agenda Bashing
Liaison Requests
   See: http://www.drizzle.com/~aboba/RADEXT/liaisons/
Document Status

Basic RADIUS work

IPv6 support in the RADIUS MIBs - Bert Wijnen & David Harrington, 5 min
http://www.ietf.org/rfc/rfc2618.txt
http://www.ietf.org/rfc/rfc2619.txt
http://www.ietf.org/rfc/rfc2620.txt
http://www.ietf.org/rfc/rfc2621.txt

RFC 3576 MIBs - M. Chiba, 10 minutes
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt

Using RADIUS backend for DHCP - T. Kivinen, 10 minutes
http://www.watersprings.org/pub/id/draft-ietf-ipsec-dhcp-over-ike-radius-00.txt

EAP lower layer attribues for AAA protocols - David Mariblanca, 5 minutes
http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt

(W)LAN applications

RFC 2486bis - Jari Arkko, 5 minutes
http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-01.txt

IEEE 802 attributes - Paul Congdon, 10 minutes
http://www.drizzle.com/~aboba/RADEXT/liaisons/RADIUS%20Extensions.xls

WFA Public WLAN attributes - TBD, 10 minutes
http://www.drizzle.com/~aboba/RADEXT/liaisons/wfa.zip

WLAN Attributes - Farid Adrangi, 10 minutes
http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capability-00.txt
http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-extension-00.txt

SIP-RADIUS

RADIUS Accounting for SIP - Henning Schulzrinne, 10 minutes
http://www.watersprings.org/pub/id/draft-schulzrinne-sipping-radius-accounting-00.txt

Digest Authentication in RADIUS - W, Beck, 10 minutes
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-02.txt

RADIUS Data Model Issues

IESG Policy on Protocol Extensibility - Thomas Narten, 10 minutes
http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-02.txt

RADIUS Data Model Review - Bernard Aboba, 10 minutes
Draft TBD

Diameter/RADIUS compatibility - Jari Arkko, 10 minutes
Draft TBD

RADIUS attribute extension format
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-00.txt

Pre-Paid

RADIUS Prepaid - Avi Lior, 15 minutes
http://www.ietf.org/internet-drafts/draft-lior-radius-extensions-for-prepaid-03.txt
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt

Wrapup - 20 minutes

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

Delivery-date: Tue, 22 Jun 2004 06:22:37 +0000
Date: Mon, 21 Jun 2004 23:22:29 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: [email-masked]
Subject: Re: your mail

> 4) There are a couple of other security key related attributes which are
> not covered by any drafts -- to best of my understanding.

Anyone planning to write these up?

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

Delivery-date: Tue, 22 Jun 2004 06:04:32 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Agenda, Take One
Date: Mon, 21 Jun 2004 23:04:15 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Sorry for duplicate mail!

Thanks Bernard.  As I recall the Liaison that we sent from WFA to IETF
contained the following:

1) Access network location information=20
      - covered by combined adrangi and jones draft soon to be submitted
to GeoPriv WG.  GeoPriv chairs are expecting this draft.

2) Access network Bandwidth parameters
      - covered by combined adrangi and black/congdon draft which is
currently being discussed on the mailing list.  Will submit a new
version by the end this month

3) billing class of Service
      - I believe "IP address type" attribute in the "lan attribute
extension" draft covers this.  At least, this was the case when we
discussed this in WFA sometime ago!

4) There are a couple of other security key related attributes which are
not covered by any drafts -- to best of my understanding.

BR,
Farid

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Monday, June 21, 2004 8:54 PM
> To: Adrangi, Farid
> Cc: [email-masked]
> Subject: RE: RADEXT Agenda, Take One
>=20
>=20
> > I think we should add
> >=20
> http://www.ietf.org/internet-drafts/draft-adrangi-radius-attri
> butes-exte
> > nsion-00.txt to the agenda as well.
>=20
> Done.
>=20
> > I believe WFA radius requirements
> > are captured in a different document (in Excel spreadsheet=20
> format) --
> > and that document does not propose any format/syntax for these
> > attributes.
>=20
> I wasn't sure whether the Excel spreadsheet was a public=20
> document or not.
> In any case, the reference was put in as a placeholder.  We=20
> have a liaison
> request from the WFA relating to those attributes, so I'm anticipating
> that a draft will be submitted defining them.
>=20
> Or am I missing something?
>=20

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

Delivery-date: Tue, 22 Jun 2004 05:55:18 +0000
Content-class: urn:content-classes:message
Subject: 
Date: Mon, 21 Jun 2004 22:54:35 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Thanks Bernrad.  As I recall the Liason that we sent from WFA to IETF
contained the following:

1) Access network location information=20
      - covered by combined adrangi and jones draft soon to be submitted
to GeoPriv WG.  GeoPriv chairs are expecting this draft.
2) Access network Bandwidth parameters
      - covered by combined adrangi and black/congdon draft which is
currently being discussed on the mailing list.  Will submit a new
version by the end this month
3) billing class of Service
      - I believe "IP address type" attribute in the "lan attribute
extension" draft covers this.  At least, this was the case when we
discussed this in WFA sometime ago!
4) There are a couple of other security key related attributes which are
not covered by any drafts -- to best of my understanding.

BR,
Farid

     =20

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Monday, June 21, 2004 8:54 PM
> To: Adrangi, Farid
> Cc: [email-masked]
> Subject: RE: RADEXT Agenda, Take One
>=20
>=20
> > I think we should add
> >=20
> http://www.ietf.org/internet-drafts/draft-adrangi-radius-attri
> butes-exte
> > nsion-00.txt to the agenda as well.
>=20
> Done.
>=20
> > I believe WFA radius requirements
> > are captured in a different document (in Excel spreadsheet=20
> format) --
> > and that document does not propose any format/syntax for these
> > attributes.
>=20
> I wasn't sure whether the Excel spreadsheet was a public=20
> document or not.
> In any case, the reference was put in as a placeholder.  We=20
> have a liaison
> request from the WFA relating to those attributes, so I'm anticipating
> that a draft will be submitted defining them.
>=20
> Or am I missing something?
>=20

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

Delivery-date: Tue, 22 Jun 2004 04:10:20 +0000
Date: Mon, 21 Jun 2004 21:10:15 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: IETF 60 RADEXT Agenda, Take Two

RADIUS EXTensions WG (RADEXT)

Dates and Times: TBD
=================================

CHAIRS:	Bernard Aboba <[email-masked]>
	David Nelson <[email-masked]>

AGENDA:

Preliminaries - 15 minutes

Bluesheets
Meeting Minutes
Agenda Bashing
Liaison Requests
   See: http://www.drizzle.com/~aboba/RADEXT/liaisons/
Document Status

Basic RADIUS work

IPv6 support in the RADIUS MIBs - Bert Wijnen & David Harrington, 5 min
http://www.ietf.org/rfc/rfc2618.txt
http://www.ietf.org/rfc/rfc2619.txt
http://www.ietf.org/rfc/rfc2620.txt
http://www.ietf.org/rfc/rfc2621.txt

RFC 3576 MIBs - M. Chiba, 10 minutes
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt

RADIUS attribute sub-option for DHCP - Ralph Droms, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-06.txt

(W)LAN applications

RFC 2486bis - Jari Arkko, 5 minutes
http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-01.txt

EAP lower layer attribues for AAA protocols - David Mariblanca, 5 minutes
http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt

IEEE 802 attributes - Paul Congdon, 10 minutes
http://www.drizzle.com/~aboba/RADEXT/liaisons/RADIUS%20Extensions.xls

WFA Public WLAN attributes - TBD, 10 minutes
http://www.drizzle.com/~aboba/RADEXT/liaisons/wfa.zip

WLAN Attributes - Farid Adrangi, 10 minutes
http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capability-00.txt
http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-extension-00.txt

SIP-RADIUS

RADIUS Accounting for SIP - Henning Schulzrinne, 10 minutes
http://www.watersprings.org/pub/id/draft-schulzrinne-sipping-radius-accounting-00.txt

Digest Authentication in RADIUS - W, Beck, 10 minutes
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-02.txt

RADIUS Data Model Issues

IESG Policy on Protocol Extensibility - Thomas Narten, 10 minutes
http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-02.txt

RADIUS Data Model Review - Bernard Aboba, 10 minutes
Draft TBD

Diameter/RADIUS compatibility - Jari Arkko, 10 minutes
Draft TBD

RADIUS attribute extension format
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-00.txt

Pre-Paid

RADIUS Prepaid - Avi Lior, 15 minutes
http://www.ietf.org/internet-drafts/draft-lior-radius-extensions-for-prepaid-03.txt
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt

Wrapup - 20 minutes

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

Delivery-date: Tue, 22 Jun 2004 03:55:16 +0000
Date: Mon, 21 Jun 2004 20:54:06 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: [email-masked]
Subject: RE: RADEXT Agenda, Take One

> I think we should add
> http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-exte
> nsion-00.txt to the agenda as well.

Done.

> I believe WFA radius requirements
> are captured in a different document (in Excel spreadsheet format) --
> and that document does not propose any format/syntax for these
> attributes.

I wasn't sure whether the Excel spreadsheet was a public document or not.
In any case, the reference was put in as a placeholder.  We have a liaison
request from the WFA relating to those attributes, so I'm anticipating
that a draft will be submitted defining them.

Or am I missing something?

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

Delivery-date: Mon, 21 Jun 2004 22:22:08 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Agenda, Take One
Date: Mon, 21 Jun 2004 15:21:40 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Hi Bernard,

I think we should add
http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-exte
nsion-00.txt to the agenda as well.  There has already been some
discussion on the mailing list on some of the attributes included in
this draft -- we are also going to update the draft mostly based on the
comments/feedback before the cut-off date.

Secondly, What is the purpose of discussing
http://www.weca.net/OpenSection/downloads/WISPr_V1.0.pdf ?  As far as I
know, this is an obsolete document.  I believe WFA radius requirements
are captured in a different document (in Excel spreadsheet format) --
and that document does not propose any format/syntax for these
attributes.

BR,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, June 18, 2004 2:49 PM
> To: [email-masked]
> Subject: RADEXT Agenda, Take One
>=20
>=20
> Here is a strawman agenda for RADEXT BOF at IETF 60.  No=20
> dates/times have been assigned yet.  If you'd like to present=20
> at the BOF and are not listed, or if you are listed, but=20
> can't present, let me know.
>=20
>=20
> --------------------------------------------------------------
> -------------------
> RADIUS EXTensions WG (RADEXT)
>=20
> Dates and Times: TBD
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> CHAIRS:	Bernard Aboba <[email-masked]>
> 	David Nelson <[email-masked]>
>=20
> AGENDA:
>=20
> Preliminaries - 15 minutes
>=20
> Bluesheets
> Meeting Minutes
> Agenda Bashing
> Liaison Requests
> Document Status
>=20
> Basic RADIUS work
>=20
> IPv6 support in the RADIUS MIBs - Bert Wijnen & David=20
> Harrington, 5 min http://www.ietf.org/rfc/rfc2618.txt
> http://www.ietf.org/rfc/rfc2619.txt
> http://www.ietf.org/rfc/rfc2620.txt
> http://www.ietf.org/rfc/rfc2621.txt
>=20
> RFC 3576 MIBs - M. Chiba, 10 minutes=20
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dyn
> auth-client-mib-01.txt
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dyn
> auth-server-mib-01.txt
>=20
> RADIUS attribute sub-option for DHCP - Ralph Droms, 10=20
> minutes=20
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-ra
> dius-06.txt
>=20
> (W)LAN applications
>=20
> RFC 2486bis - Jari Arkko, 5 minutes=20
> http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc248
> 6bis-01.txt
>=20
> EAP lower layer attribues for AAA protocols - David=20
> Mariblanca, 5 minutes=20
> http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-l
la-00.txt

IEEE 802 attributes - Paul Congdon, 10 minutes
Draft TBD

WFA attributes - TBD, 10 minutes
http://www.weca.net/OpenSection/downloads/WISPr_V1.0.pdf

WLAN Roaming - Farid Adrangi, 10 minutes
http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capab
ility-00.txt

SIP-RADIUS

RADIUS Accounting for SIP - Henning Schulzrinne, 10 minutes
http://www.watersprings.org/pub/id/draft-schulzrinne-sipping-radius-acco
unting-00.txt

Digest Authentication in RADIUS - W, Beck, 10 minutes
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-02.txt

RADIUS Data Model Issues

IESG Policy on Protocol Extensibility - Thomas Narten, 10 minutes
http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-02.txt

RADIUS Data Model Review - Bernard Aboba, 10 minutes
Draft TBD

Diameter/RADIUS compatibility - Jari Arkko, 10 minutes
Draft TBD

Pre-Paid

RADIUS Prepaid - Avi Lior, 15 minutes
http://www.ietf.org/internet-drafts/draft-lior-radius-extensions-for-pre
paid-03.txt
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext
ension-00.txt

Wrapup - 20 minutes

--
to unsubscribe send 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, 21 Jun 2004 21:40:34 +0000
Date: Mon, 21 Jun 2004 14:39:54 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: IETF document publication process tweaks. (fwd)

FYI

 > From: Bill Sommerfeld <[email-masked]>
 > To: [email-masked]
 > Subject: IETF document publication process tweaks.
 > Date: Tue, 08 Jun 2004 19:55:39 -0400
 >
 > For those of you who don't read IETF-announce, you should be
 > aware that the IESG has once again revised the procedures for
 > Internet-Draft submission.
 >
 >  - The old ID-Nits list is now the "ID Checklist",
 >             http://www.ietf.org/ID-Checklist.html
 >
 >  - There is also now a script available which provides an "internet
 > draft lint" tool, which checks for conformance with many of the
 > mechanical aspects of these new checklists.  See:
 > http://ietf.levkowetz.com/tools/idnits/
 >
 >  - In addition, with the publication of RFC 3667 and RFC 3668, which
 > supersede RFC2026, there now also newly rototilled draft template
 > boilerplate/copyright/IPR notice/etc.;
 >
 > A new version of the xml2rfc toolkit is available at
 > http://xml.resource.org/ which includes the new boilerplate.  While
 > use of xml2rfc is not required, it is strongly encouraged..
 >
 > As working group chair, I'm responsible for checking all drafts
 > against the checklist.  Help save you and me time by checking them
 > first before sending them in..
 >
 > 					- Bill

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

Delivery-date: Fri, 18 Jun 2004 21:48:53 +0000
Date: Fri, 18 Jun 2004 14:48:47 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT Agenda, Take One

Here is a strawman agenda for RADEXT BOF at IETF 60.  No dates/times have
been assigned yet.  If you'd like to present at the BOF and are not listed, or
if you are listed, but can't present, let me know.

---------------------------------------------------------------------------------
RADIUS EXTensions WG (RADEXT)

Dates and Times: TBD
=================================

CHAIRS:	Bernard Aboba <[email-masked]>
	David Nelson <[email-masked]>

AGENDA:

Preliminaries - 15 minutes

Bluesheets
Meeting Minutes
Agenda Bashing
Liaison Requests
Document Status

Basic RADIUS work

IPv6 support in the RADIUS MIBs - Bert Wijnen & David Harrington, 5 min
http://www.ietf.org/rfc/rfc2618.txt
http://www.ietf.org/rfc/rfc2619.txt
http://www.ietf.org/rfc/rfc2620.txt
http://www.ietf.org/rfc/rfc2621.txt

RFC 3576 MIBs - M. Chiba, 10 minutes
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt

RADIUS attribute sub-option for DHCP - Ralph Droms, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-06.txt

(W)LAN applications

RFC 2486bis - Jari Arkko, 5 minutes
http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-01.txt

EAP lower layer attribues for AAA protocols - David Mariblanca, 5 minutes
http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt

IEEE 802 attributes - Paul Congdon, 10 minutes
Draft TBD

WFA attributes - TBD, 10 minutes
http://www.weca.net/OpenSection/downloads/WISPr_V1.0.pdf

WLAN Roaming - Farid Adrangi, 10 minutes
http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capability-00.txt

SIP-RADIUS

RADIUS Accounting for SIP - Henning Schulzrinne, 10 minutes
http://www.watersprings.org/pub/id/draft-schulzrinne-sipping-radius-accounting-00.txt

Digest Authentication in RADIUS - W, Beck, 10 minutes
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-02.txt

RADIUS Data Model Issues

IESG Policy on Protocol Extensibility - Thomas Narten, 10 minutes
http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-02.txt

RADIUS Data Model Review - Bernard Aboba, 10 minutes
Draft TBD

Diameter/RADIUS compatibility - Jari Arkko, 10 minutes
Draft TBD

Pre-Paid

RADIUS Prepaid - Avi Lior, 15 minutes
http://www.ietf.org/internet-drafts/draft-lior-radius-extensions-for-prepaid-03.txt
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-00.txt

Wrapup - 20 minutes

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

Delivery-date: Fri, 18 Jun 2004 00:44:57 +0000
content-class: urn:content-classes:message
Subject: RE: User Identity issues
Date: Thu, 17 Jun 2004 17:42:01 -0700
From: "Blair T. Bullock" <[email-masked]>
To: [email-masked]

Sure I'm not telling y'all anything you don't already know, but just to
be clear...

As part of the roaming mediation and RADIUS clearinghouse process, once
the accounting is received by the mediated AAA exchange (routed by the
promiscuous decorations applied by the user or smart client), they are
forwarded/copied through the secure exchange to the Home Authentication
Server.  Part of the mediated roaming and clearing framework is not only
the Authentication events, but also the handling of the resulting
accounting packets for billing and secure forwarding to the Home
network.  Therefore, the AAA streams should take the same route based on
identical decoration as originally presented by the supplicant/peer.
Provisioning default routes, directed realm routes or other such
mechanisms to handle accounting separate from the
authentication/authorization events and NAI context causes event
correlation problems and potentially mis-routes accounting to other
clearinghouses.

If an enterprise uses multiple mediated roaming services, say GoRemote
and iPass, it is the NAI decoration which selects the desire exchange
for authentication and the accounting must follow suit without risk of
authenticating on one exchange and accounting on another.  We currently
rely on the NAI to correlate and handle those disparate events.  It is
not uncommon for one clearinghouse to get the accounting for another's
session due to timeout to one exchange and accounting following the
DEFAULT route to another.  Thankfully, with clear NAI construction
principles in place, we can easily determine whether or not this was
actually a request where we handled the authentication or is a misroute
from another's. =20

We enjoy a very high rate of AAA event correlation (around 98%+) due to
our managed NAI construction principles and low-latent local secure
proxies. These are founded on explicit NAI rules which can not change
over the course of the AAA sequence.

I'm not saying this is the only or even the best way.  In fact the
principles we operate on have their shortcomings too.  Only, it has up
to now been the most practical and expedient way to handle the
aggregated network access through mediated AAA to multi-homed RADIUS
clearinghouse model under practical real-world scenarios and legacy
RADIUS technology.  If there is a "better" way, we are all over it.
=3D^)   Only, it can't break our existing customer base in one fell
swoop....  It must be inclusive and any RADIUS methodology must provide
a migration path to allow everyone to get from here to there without
starting from scratch or knee-jerk fixes due to AP upgrades.

-Blair

-----Original Message-----
From: Nelson, David [mailto:[email-masked]]=20
Sent: Wednesday, June 16, 2004 7:57 AM
To: [email-masked]
Subject: RE: User Identity issues

Bernard Aboba writes...

> As Blair notes, there are cases where the Accounting data needs to=20
> follow the same path as Authorization, and User-Name rewriting can=20
> break that.

I generally understand that the issue is multi-party
brokering/mediation.  There are multiple entities that need to get their
"cut" of the revenue associated with the user's session.  Does that
imply that the accounting requests need to traverse the same path as the
authentication requests?  Does each entity need to maintain their own
accounting logs, or do the entities trust one central clearing house to
give then their fair share of revenue?  If the latter is true, then it
would seem that accounting requests could be sent directly to the
central clearing house, along with some indication of the list of
parties involved, so that the revenue allocation can be calculated and
distributed.

I guess what I'm asking is that the business-domain problem be clearly
defined before we attempt to create a protocol-domain solution that
meets the business requirements.

--  Dave

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

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

Delivery-date: Thu, 17 Jun 2004 19:13:53 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>, "Adrangi, Farid" <[email-masked]>
Subject: RE: comments on draft-lior-radius-redirection-00.txt
Date: Thu, 17 Jun 2004 15:13:30 -0400

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Thursday, June 03, 2004 5:59 AM
> To: [email-masked]'; Avi Lior; Adrangi, Farid
> Subject: comments on draft-lior-radius-redirection-00.txt
> 
> 
> 
> Hi Avi, Farid,
> 
> I have read your draft, and found it generally well
> written. The function it describes is useful. As usual, I do
> have some comments:
> 
> Management:
> ===========
> 
> I'm not sure which RADEXT proposed charter workitem
> this falls under. WLAN attributes? Prepaid? None?

Initially this was brought up for WLAN but it is also needed for Prepaid.

> Substantial:
> ============
> 
> > 6. Security Considerations
> > 
> >    TBD
> 
> This type of considerations may have to be revised
> before the IESG approves them ;-) You may want to
> mention at least the following:
> 
> - Basic attribute transport has the same security
>    issues as any attribute transport over RADIUS,
>    refer to the security considerations of the
>    base RFC.
> 
> - Limitations of filtering schemes. For instance, situations
>    where the client and some other node in the
>    internet conspire to hide some traffic under some protocol
>    where its in reality something else.

Understood.  There are probably others.  We are looking for help here.
 
> >    Redirection refers to an action taken by the NAS to redirect the
> >    user's traffic to an alternate location. Redirecting traffic in
> >    mid-session will most probably break some applications. However,
> >    Redirection at the start of a Service will most certainly work.
> 
> I may be missing something here. But I don't understand
> what you mean by "application" in this context. An IP
> application, or some specific AAA configuration? I'm pretty 
> sure some IP applications break even with redirection at the 
> start of the service...

An application could be HTTP HTML for example. SIP is another etc...

Your comment is correct some Applications do break.  The intent is to get a
signal that the user is doing something and react to it.  We are not trying
to maintain the application.

> 
> >    because their account has no more funds. The user's
> Service Provider
> >    instructs the NAS to block all traffic, and redirect any port 80
> >    traffic to the Service Provider's Prepaid Portal. Upon detecting
> > that
> 
> This is probably the only possible model we can have, but
> you should point out the limitations. It works only if this is person 
> and he or she uses the web application. Otherwise, your IP connection 
> mysteriously dies...

Well not necessarily.  It could be another flow other than HTML.  And we can
notify the user using other means.  For example, it we could notify a user
using SMS messaging when we detect that they are doing FTP.
 
> > 3.1.2 Mid-session Redirection
> > 
> >    Redirection of traffic using tunnel mid-session involves
> sending the
> >    tunnel attributes as per RFC2868 [5] to the NAS using
> >    Change-of-Authorization (COA) packet. The operation is
> described in
> >    RFC3576 [8]. Careful attention should be paid to the
> security issues
> >    in RFC3576.
> > 
> >    Note that if the session is already tunneled (eg.
> Mobile-IP) then the
> >    COA packet with a new tunnel specification can be sent
> to the NAS or
> >    alternatively the redirection can occur at the tunnel
> endpoint (the
> >    Home Agent) using any one of these methods.
> 
> It isn't clear to me that mid-session tunnel establisment is
> always possible. For instance, what if we are terminating PPP 
> at the NAS, and then suddenly the home network requests the 
> session to be moved on top of L2TP? I think that would have 
> to imply either (a) context transfer of PPP session to 
> another location (!) or (b) tearing down the PPP session and 
> renegging and authenticating everything.

In some cases that maybe true.  But the intent is not to solve all the
problems.  As a minimum, the user's will notice something has gone wrong and
will fire up their browser.

> >    There is one kind of packet that the access device MUST always
> >    discard, that is an IP fragment with a fragment offset
> of one. This
> >    is a valid packet, but it only has one use, to try to circumvent
> >    firewalls.
> 
> I'm pretty sure there are other attack-only packets. I
> suspect the definition of those packets belongs to another document.

Perhaps.  This is a cut and paste from Diameter.

>  > 4.1 NAS-Filter-Rule Attribute
> 
> Can it happen that the text is too long for a RADIUS attribute?

It could and we would just extend the value across to the next attribute.
This is common practice in RADIUS.

Because you can have more than one attribute, the only thing to watch out
for is that the extended attribute MUST not start with one of the "action"
keywords.
  
> Diameter Compatibility Issues:
> ==============================
> 
> - Section 1 could perhaps talk about what functions
>    exist in Diameter, how that compares to this specification,
>    and point to the section that talks about the translation.

Okay

> - Add a section on the translation. If you need help,
>    I can provide some text, but I think you know what
>    needs to be done.

Understood.

> >    As pointed out by NASREQ the use Filter-Id is not
> roaming friendly
> >    and it is recommended that instead one should use
> >    NAS-Filter-Rule(400) AVP. For this reason, this document
> introduces
> >    NAS-Filter-Rule(TBD) to RADIUS.
> 
> This seems to be a case where we add a new attribute to
> RADIUS where there already exists a Diameter AVP in Diameter 
> AVP code space. That is fine otherwise, but a system that 
> works according to the NASREQ translation rules would map the 
> new RADIUS attribute to the corresponding RADIUS code space 
> AVP in Diameter, rather than using the existing Diameter AVP, 
> making interoperability hard. This can be solved by having 
> the translation agent treat this attribute as a special case, 
> but it is not as nice is one could hope for. If anyone has 
> good suggestions how to solve this, let me know...

I predict that this will happen again and again.  Actually anytime that
someone developes a Diameter Application before the corresponding RADIUS one
we may run into this problem.
 
> Editorial:
> ==========
> 
> >    The text conforms to the following specification (taken
> from Diameter
> >    IPFilterRule Type):
> 
> Just as an editorial thing, I wonder if a reference to
> RFC 3588 would work better here. Then if there's a
> future extension of the filter rules some day, we could
> track those better.

Okay

> > 8. Open Issues
> 
> Delete.
> 
> >    An implementation is not compliant if it fails to
> satisfy one or more
> >    of the must or must not requirements for the protocols
> it implements.
> >    An implementation that satisfies all the must, must not,
> should and
> >    should not requirements for its protocols is said to be
> >    "unconditionally compliant"; one that satisfies all the
> must and must
> >    not requirements but not all the should or should not
> requirements
> >    for its protocols is said to be "conditionally compliant".
> 
> Capitalization of keywords?
> 
> >    Today this capability is supported in RADIUS
> >    and is configurable during service establishment and
> mid-service via
> >    the Filter-Id(11) attribute.
> 
> I would prefer seeing Filter-Id [Ref], ie. pointer to the spec rather 
> than the number. But maybe its just me...
> 
> >    As pointed out by NASREQ the use Filter-Id is not
> roaming friendly
> >    and it is recommended that instead one should use
> >    NAS-Filter-Rule(400) AVP. For this reason, this document
> introduces
> >    NAS-Filter-Rule(TBD) to RADIUS.
> 
> Maybe "As pointed out in [some reference] the use Filter-Id is not 
> roaming friendly due to the need to have a globally agreed filter 
> lists. Diameter NASREQ [Diameter NASREQ] defines the
> NAS-Filter-Rule(400) AVP for this reason. This document
> introduces the corresponding AVP to RADIUS.
> 
> > 4.3 Redirection-Rule
> 
> Is there some duplication with the filter format
> definion here vs. Section 4.1?

Redirection rule very much looks the same in many ways to Filter-Rule.

> --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: Thu, 17 Jun 2004 14:53:15 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: User Identity issues - Business Domain
Date: Thu, 17 Jun 2004 10:52:44 -0400

Hi

Originally when first being involved with this issue the need we saw was
that some intermediaries needed to know that a particular AAA transaction
was associated with a given user.  For example, the intermediary was
responsible for ensuring that the user only logged in once to the network.
Methods such as EAP that can hide the identity of the subscriber created
problems to these intermediaries.

As the I-D suggests adding a UserAlias which the home operator asserts that
it belongs to a given subscriber without revealing the subscribers identity
serves that purpose.

We did discuss putting this identity in the User-Name (User-name rewrite but
we felt that user-name re-writing was already overloaded and not well
specified)  Hence the we thought that a new attribute would be used.

Accounting or billing needs would also benefit but only when this is done
outside the context of the home network.  In the home network Class
attribute can be used.  Accounting Intermediaries could resolve the
User-Alias by interacting with the home network which would then provide the
billing entity for those records.
 
I think the routing of Access-Request messages and Accounting messages is
really a separate issue.  

User-Name re-writing could be the way to solve the routing problem or not --
Unfortunately the User-Name attribute is starting to to get somewhat
overloaded.  I guess in hindsight it would have been better to leave the
User-Name attribute to serve as strictly the User-Name attribute (and
perhaps an Alias) and have another attribute used for routing purposes.

Avi

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Wednesday, June 16, 2004 10:57 AM
> To: [email-masked]
> Subject: RE: User Identity issues
> 
> 
> Bernard Aboba writes...
> 
> > As Blair notes, there are cases where the Accounting data needs to 
> > follow the same path as Authorization, and User-Name rewriting can 
> > break that.
> 
> I generally understand that the issue is multi-party 
> brokering/mediation.  There are multiple entities that need 
> to get their "cut" of the revenue associated with the user's 
> session.  Does that imply that the accounting requests need 
> to traverse the same path as the authentication requests?  
> Does each entity need to maintain their own accounting logs, 
> or do the entities trust one central clearing house to give 
> then their fair share of revenue?  If the latter is true, 
> then it would seem that accounting requests could be sent 
> directly to the central clearing house, along with some 
> indication of the list of parties involved, so that the 
> revenue allocation can be calculated and distributed.
> 
> I guess what I'm asking is that the business-domain problem 
> be clearly defined before we attempt to create a 
> protocol-domain solution that meets the business requirements.
> 
> --  Dave
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Thu, 17 Jun 2004 08:16:22 +0000
Date: Thu, 17 Jun 2004 11:12:01 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: User Identity issues

Nelson, David wrote:

> I guess what I'm asking is that the business-domain problem be clearly
> defined before we attempt to create a protocol-domain solution that
> meets the business requirements.

Yes.

(I would also note that there are both business domain
and technical domain issues involved here. Some of
the latter include ability to provide a "handle" to
the user even when privacy is applied to the username
while authenticating e.g. via EAP, accommodating tunneled
authentication methods, ability to route accounting
packets using *some* route, and so on.)

--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: Thu, 17 Jun 2004 08:01:21 +0000
Date: Thu, 17 Jun 2004 10:56:39 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>
Subject: new version of the NAI draft

Hi,

I have posted a new version of the RFC 2486bis draft.
It does not yet appear in the I-D directories, but you
can access it here:

   http://www.arkko.com/publications/nai/naibis.txt
   http://www.arkko.com/publications/nai/naibis.html
   http://www.arkko.com/publications/nai/naibisdiff.html

I think we have addressed all comments that I have
gotten on the list or privately -- thanks for your
input, with two exceptions. First, I have not done
anything yet based on the yesterday's discussion we
are having around the username identity, accounting,
and its potential impacts on decorations. Secondly,
I believe someone wanted to have the bang syntax as
a formal part of the ABNF rather than an explanation
of how the username part may be used in some cases.
We decided against that, because the spirit of the
RFC 2486 was that the username field contents are
the business of the user & his home network, and because
formal syntax for the '!' might have made some existing
user names invalid.

Comments appreciated again. I can still do one more
version before the I-D deadline, so if you can review
this in the next two weeks, your comments will have
an impact to the -02 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: Wed, 16 Jun 2004 17:11:05 +0000
Content-class: urn:content-classes:message
Subject: RE: User Identity issues
Date: Wed, 16 Jun 2004 10:09:33 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Hi Bernard,
Please see my responses inline.
BR,
Farid

>=20
> As Blair notes, there are cases where the Accounting data needs
> to follow the same path as Authorization, and User-Name rewriting
> can break that.=20

It depends.  The routing is done based on the realm and/or prefix/suffix
used for NAI decoration.  In the context of conveying a billable
identity, the UserName(1) rewrite does not have to impact the realm or
prefix/suffix parts of the decorated NAI.  For example, if the AAA
server receives UserName value [email-masked] in the
Access-Request, the AAA server can convey the billable identity via
UserName (1) rewrite like [email-masked] , where 2345 is the billable
identity.  This should cause the accounting packets follow the same path
as the authorization.

When a decorated NAI is used, we have a problem even if the UserName(1)
rewrite is done by the AAA server.  Let's say the client uses a
decorated NAI as per syntax defined in 2486bis - for example
[email-masked].  Upon receipt of the
Access-Request, the intermediary strips off the decoration and forwards
the Access-Request.  Therefore, the UserName received by the AAA server
will be [email-masked].  In this case, even if the AAA server puts
the received UserName value as is (i.e., [email-masked]) in the
Access-Accept, this will appear to NAS like UserName rewrite. =20

However, please note that if prefix-based NAI decoration (e.g.,
intermediary.com/[email-masked]) is used on contrary to what is
specified in 2486bis, the intermediary can forward the AccessRequest
without striping off the decoration -- that is, the AAA server will see
intermediary.com/[email-masked].  The AAA server can return
intermediary.com/[email-masked] or preferably
intermediary.com/[email-masked] (where 2345 is the billable identity).
This should cause the accounting packets follow the same path as the
authorization.

> This argument against User-Name rewrite is more
> compelling than NAS compatibility or billing system compatibility
> since new attributes will also require changes to NASen and=20
> billing systems.
>=20
> I'd suggest that we need a discussion of the issues so that we can
> understand when it is safe to do User-Name rewriting, and=20
> when this can
> cause problems.

In my opinion, the cleanest approach is not to overload use of
UserName(1) with other things instead of doing analysis when it is safe
to do UserName (1) rewrite and hen it is not.  For example, if the
intent is to convey a billable identity to the NAS, use a separate
attribute. =20

>=20
> The major impetus for User-Name rewrite as I understand it is=20
> for use in
> privacy.  There are also the cosmetic cases that Dave Mitton=20
> has mentioned
> (e.g. changing case) but I think these are relatively benign.
>=20
> So how do we go forward?  There may need to be an errata submitted for
> RFC 3579.  As Barney Wolff pointed out, the text of RFC 3579=20
> is somewhat
> misleading; User-Name rewriting is not required for the
> routing of the Access-Accept back to the NAS;  Proxy State can handle
> this.
>=20

RFC 3579 also needs to make it clear which identity the NAS should use
in the accounting requests -- the original identity sent in the
Access-Request, or the identity received in the Access-Accept. =20

> I'd also like to understand if there are guidelines that a=20
> server can use
> to determine when User-Name rewrite is safe and when it isn't.  For
> example, what if a user attempts to protect Privacy in a=20
> network set up as
> Blair has suggested?  What breaks?  Is there a way for the server to
> detect the situation and not cause problems?
>=20
> I also think that we need to discuss this in the Network=20
> Discovery Problem
> Statement, since if a user desires to influence the mediating network,
> then accounting supporting that decision needs to be carried out.
>=20
>=20

Yes. And, I think use of prefix-based decorated NAI (as originally
specified in the mediating network discovery draft!) would solve this
problem - please see the argument above.

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

Envelope-to: [email-masked]
Delivery-date: Wed, 16 Jun 2004 15:00:08 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: User Identity issues 
Date: Wed, 16 Jun 2004 11:06:34 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> Anyone care to write up a discussion of the interoperability issues and an
> examination of the alternative approaches?

  I'd love to, but I'm not sure I have the time.

> Also, I'd like to collect a list of other similar topic areas, so that we
> can make an outline for the document.

e) requiring attributes to be in a certain order

  There's at least one RADIUS client which will bounce packets
verbatim back to the server if it sees attributes in a certain order.

  e.g. a packet containing Attribute-Foo = 1, Attribute-Bar = 2 in
that order is OK, but if the attribute ordering is swapped (even with
other intermediate attributes), the packet is not ignored... but is
"reflected" back to the server.

  The vendor has been notified, and (so far) has refused to correct
the behavior.

f) Mangling Proxy-State

  e.g. parsing the contents of Proxy-State into a local *typed*
variable, and then printing that variable back to a string, before
returning it in a reply packet.

  I believe the vendor has fixed their implementation, but there are
many older versions of the software still in use, which haven't been
upgraded.

  There may be more, but that's what I recall right now.

  Alan DeKok.

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

Delivery-date: Wed, 16 Jun 2004 14:58:34 +0000
Content-class: urn:content-classes:message
Subject: RE: User Identity issues
Date: Wed, 16 Jun 2004 10:57:12 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> As Blair notes, there are cases where the Accounting data needs
> to follow the same path as Authorization, and User-Name rewriting
> can break that.

I generally understand that the issue is multi-party
brokering/mediation.  There are multiple entities that need to get their
"cut" of the revenue associated with the user's session.  Does that
imply that the accounting requests need to traverse the same path as the
authentication requests?  Does each entity need to maintain their own
accounting logs, or do the entities trust one central clearing house to
give then their fair share of revenue?  If the latter is true, then it
would seem that accounting requests could be sent directly to the
central clearing house, along with some indication of the list of
parties involved, so that the revenue allocation can be calculated and
distributed.

I guess what I'm asking is that the business-domain problem be clearly
defined before we attempt to create a protocol-domain solution that
meets the business requirements.

--  Dave

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

Envelope-to: [email-masked]
Delivery-date: Wed, 16 Jun 2004 14:28:07 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: User Alias Identity (Was: Re: comments on draft-adrangi-radius-attributes-extension-00.tx) 
Date: Wed, 16 Jun 2004 10:33:13 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> The User-Name attribute is optional in an Access-Accept according to
> both RFC 2865 and 3579.  As has been noted by Barney Wolff, a
> proxy-state attribute can be used to enable proper routing of the
> Access-Accept, ...

  I understood the original comment to be discussing a problem with
accounting packets, as mentioned in RFC 3579, Section 3.

  e.g.

  Access-Request ("user@decorated", with inner tunnel of "user")
  Access-Accept  (returns "user")
  Accounting-Request (accounting for "user")

  Requests containing "user@decorated" can be routed, as a result of
the decorations.  The Accounting-Request, therefore, cannot.  It needs
additional information.  While the Class attribute could be used here,
but it may already be used for other purposes, and some
implementations may get confused with multiple Class attributes.

  The authentication server can't tell the NAS to send accounting
information with "user@decorated", because that may be
"anonymous@...", and used for many sessions.

  I'm not offering a solution, just an alternate presentation of the
original post.

  Alan DeKok.

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

Delivery-date: Wed, 16 Jun 2004 14:13:02 +0000
Date: Wed, 16 Jun 2004 07:11:58 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: [email-masked]
Subject: RE: User Identity issues

As Blair notes, there are cases where the Accounting data needs
to follow the same path as Authorization, and User-Name rewriting
can break that. This argument against User-Name rewrite is more
compelling than NAS compatibility or billing system compatibility
since new attributes will also require changes to NASen and billing systems.

I'd suggest that we need a discussion of the issues so that we can
understand when it is safe to do User-Name rewriting, and when this can
cause problems.

The major impetus for User-Name rewrite as I understand it is for use in
privacy.  There are also the cosmetic cases that Dave Mitton has mentioned
(e.g. changing case) but I think these are relatively benign.

So how do we go forward?  There may need to be an errata submitted for
RFC 3579.  As Barney Wolff pointed out, the text of RFC 3579 is somewhat
misleading; User-Name rewriting is not required for the
routing of the Access-Accept back to the NAS;  Proxy State can handle
this.

I'd also like to understand if there are guidelines that a server can use
to determine when User-Name rewrite is safe and when it isn't.  For
example, what if a user attempts to protect Privacy in a network set up as
Blair has suggested?  What breaks?  Is there a way for the server to
detect the situation and not cause problems?

I also think that we need to discuss this in the Network Discovery Problem
Statement, since if a user desires to influence the mediating network,
then accounting supporting that decision needs to be carried out.

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

Delivery-date: Wed, 16 Jun 2004 06:40:19 +0000
Date: Tue, 15 Jun 2004 23:40:50 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: User Identity issues

It occurs to me that this issue is an example of an area in which the
existing RADIUS RFCs are unclear, and therefore one where interoperability
problems may arise.

It therefore seems like an excellent topic for discussion in the "RADIUS
implementation errors and fixes" document.

Anyone care to write up a discussion of the interoperability issues and an
examination of the alternative approaches?

Also, I'd like to collect a list of other similar topic areas, so that we
can make an outline for the document.

Topics that have come up so far include:

a. User-Name usage in Access-Accept
b. Use of State attribute in EAP conversations (e.g. EAP restart)
c. Accounting for re-authentication (e.g. Service-Type=Authenticate-Only)
d. RADIUS retransmission behavior (e.g. backoff)

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

Delivery-date: Wed, 16 Jun 2004 06:08:10 +0000
Date: Tue, 15 Jun 2004 23:08:29 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Blair T. Bullock" <[email-masked]>
cc: [email-masked]
Subject: RE: User Alias Identity (Was: Re: comments on draft-adrangi-radius-attributes-extension-00.tx)

> We must not pass back
> the User-Name in the Access-Accept even though it is highly recommended.
>
> The question is, is this an acceptable control of this function

The User-Name attribute is optional in an Access-Accept according to both
RFC 2865 and 3579.  As has been noted by Barney Wolff, a proxy-state attribute
can be used to enable proper routing of the Access-Accept, even if the
User-Name attribute is omitted.  So it would seem like you can omit the
User-Name and include a Proxy-State attribute and the Access-Accept should
still be successfully routed back to the NAS.

> allowing the User-Name to return in the Access-Accept where we can be
> assured of proper accounting transmission, but then not include the
> User-Name when keeping the originally presented NAI

I'm finding this part hard to parse.  In the previous paragraph you
mention not including the User-Name attribute.  Given the issues you
raise, I'm not sure how "proper accounting transmission" can be
guaranteed, other than by having the proxy re-write the User-Name returned
in an Access-Accept, if it is different from the User-Name attribute in
the Access-Request.

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

Delivery-date: Tue, 15 Jun 2004 22:42:13 +0000
content-class: urn:content-classes:message
Subject: RE: User Alias Identity (Was: Re: comments on draft-adrangi-radius-attributes-extension-00.tx)
Date: Tue, 15 Jun 2004 15:39:28 -0700
From: "Blair T. Bullock" <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>, "Bernard Aboba" <[email-masked]>
cc: [email-masked], [email-masked]

iPass decorates the NAI via our Smart-Client/Supplicant to provide an
identity that navigates the local RADIUS infrastructure to select our
AAA exchange for purposes of mediated access.  This decoration is
independent from any customer-level decorations to navigate to the Home
AAA or via a reseller arrangement. =20

The Accounting User-Name attribute replacement, returning the inner
identity, completely breaks the ability for the accounting messages to
follow the same path that the authentication events took based on the
promiscuous decoration of the NAI to form supply arrangements, basically
dropping them on the floor. =20

Using the last revision of the AP firmware, all is well... but a simple
upgrade and all accounting stops unless a domain-specific or DEFAULT
route is used to capture them (which is worse than the cure).  Whoops!
Therefore, in order to maintain the initially provided NAI decorations
(which we can resolve since we put them there), we must not pass back
the User-Name in the Access-Accept even though it is highly recommended.

The question is, is this an acceptable control of this function, simply
allowing the User-Name to return in the Access-Accept where we can be
assured of proper accounting transmission, but then not include the
User-Name when keeping the originally presented NAI is required to
navigate mediated roaming exchanges by a decoration other than those
provisioned or controlled by the Home Authentication Server (who is
consuming the network, but not necessarily decorating an NAI for
purposes of footprint aggregation or mediated roaming services).=20

-Blair

-----Original Message-----
From: Adrangi, Farid [mailto:[email-masked]]=20
Sent: Tuesday, June 15, 2004 1:43 AM
To: Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: RE: User Alias Identity (Was: Re: comments on
draft-adrangi-radius-attributes-extension-00.tx)

Hi Bernard,
Thanks for your comments and questions. Please see my responses inline.
BR,
Farid

>=20
> > >    So, presumably the NASes were not prepared for the
> > >    possibility that the User-Name attribute might change.
> > >    Do they actually break, or is it just that they ignore
> > >    the User-Name attribute when it comes back?
> >
> > It will break the billing functionality according to the information

> > that we got from GSMA vendors.
>=20
> Can you explain what this means?  Does the NAS crash?  Send an=20
> accounting record with the User-Name sent in the Access-Request=20
> instead?  Do something else?  Perhaps we should hear directly from the

> vendors in question about how they handle this.
>=20

One type of failure is that the NAS discards the User-Name (rewritten)
in the Access-Accept.  I am not in a position to provide any vendor's
name here -- but all I can say GSMA has included this attribute in the
EAP-SIM roaming guidelines, and it was already implemented by all
vendors participated in the GSMA EAP-SIM trial.   Jouni Korhonen (the
editor of GSMA's EAP-SIM roaming guidelines) can provide more
information if needed.

> Remember that RFC 2865 enables inclusion of the User-Name attribute in

> an Access-Accept, so that compliant RADIUS client implementations need

> to be able to deal with this:
>=20
>    Request   Accept   Reject   Challenge   #    Attribute
>    0-1       0-1      0        0            1   User-Name
>=20

RFC 2865 does not say anything about the UserName(1) rewrite.  Please
see below for more ...

> > It applies to all scenarios where user's real or billable
> identity is
> > not revealed to the NAS by the user.
>=20
> RFC 3579 contains the same entry as RFC 2865 with respect to
> User-Name:
>=20
> Request  Accept  Reject  Challenge   #    Attribute
> 0-1      0-1     0       0            1   User-Name
>=20

Please see my response below to the specific text in RFC 3579.

> > RFC3579 does not mandate supporting user-name(1) rewrite so
> in my mind
> > it won't make it uncompliant. No?
>=20
> Here is what RFC 3579 says:
>=20
> "In order to permit forwarding of the Access-Reply by EAP-unaware=20
> proxies, if a User-Name attribute was included in an Access-Request,=20
> the RADIUS server MUST include the User-Name attribute in subsequent=20
> Access-Accept packets. Without the User-Name attribute, accounting and

> billing becomes difficult to manage.  The User-Name attribute within=20
> the Access-Accept packet need not be the same as the User-Name=20
> attribute in the Access-Request."
>=20

I think this is the source of the problem -- the RFC 3579 is not clear
about whether a NAS should include the UserName (1) value received in
the AccessAccept rather than the one was orginally sent in the
Access-Accept packet in the accounting request.=20

> So I'd say that a RADIUS client needs to support User-Name in an=20
> Access-Accept and also needs to be prepared for user-name rewrite.
>=20

Again the RFC is not clear which UserName value should be used by the
NAS.

> > The difference in the amount of code changes required by these two=20
> > methods is not the core issue.  The main goal is to provide
> a solution
> > that can be deployment without any changes to NAS, and without=20
> > disturbing the current use of User-Name(1) -- i.e., GSMA=20
> > vendors/operators don't want to overload the use of UserName(1) or=20
> > create conflicts/incompatibilities.
>=20
> This seems like one of several areas in which there are=20
> interoperability issues with current RADIUS implementations.  Where=20
> there are interoperability problems, it is typically required for=20
> *some* implementation to change.  The purpose of the "RADIUS=20
> Implementation Errors and Fixes" document is to document these=20
> problems and propose solutions.
>=20
> > >    ensure that the above NAS-need-not-be-changed properties can
> > >    be achieved if we move into this separation. That is, I'd like
> > >    to understand how this works in a backwards compatible manner
> > >    without requiring updates to the NASes.
>=20
> I don't see how this can possibly be implemented without changing=20
> NASes.
> Since this is an interoperability issue, the problem isn't "does=20
> someone have to change" -- but rather "what  should change" and "how".
>=20
>=20
This can be handled by the access network AAA proxy.

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

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

Delivery-date: Tue, 15 Jun 2004 18:11:48 +0000
From: "Ed Van Horne" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: accuracy of timestamps
Date: Tue, 15 Jun 2004 11:12:15 -0700

Jo,

We have firm customer requirements for billing accuracy with 1 second
resolution. This is a regulatory requirement in some countries (German, =
for
example). To comply with the tariffs for the service they wish to offer, =
the
billing system must meet this requirement.

Regards,
Ed

Ed Van Horne=20
NMTG - San Diego=20
Cisco Systems=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =
On
Behalf Of [email-masked]
Sent: Tuesday, June 15, 2004 8:03 AM
To: [email-masked]
Subject: accuracy of timestamps

Hello,

in my current work, I've recently seen some requirements about the=20
accuracy of timestamps to be used in RADIUS, especially in VoIP=20
environments. Some managers (and customers) started to demand that we=20
would store the start of stop of a session with 0.1 second precision=20
(+/- 0.5 seconds). They didn't want to use the EventTimestamp attribute=20
(in seconds) or the time-of-arrival with a correction of AcctDelayTime=20
(not accurate enough, because we don't know the RTT).

I remember that there has been a discussion when DIAMETER was designed,=20
whether NTP-style timestamps should use used, but SNTP was chosen (also=20
in seconds). I agree with this decision (statistics and all), but=20
there's no argueing with my boss or the customers :-) The customers even =

started to quote some legal requirements (for phone service), so maybe=20
some other implementors have seen the same problem. How did the 3GPP=20
people have solved this problem ? I'm currently using the original VSA=20
(they're not using EventTimestamp), specified in seconds, and I've added =

another VSA for the milliseconds part.

A related question :

EventTimestamp is defined as the number of seconds since 1/1/1970 00:00=20
UTC. This is recognized by every programmer as the UNIX-style time()=20
systemcall ofcourse, which returns the timestamp in UTC. You would use=20
localtime() to translate this into a readable string, which would also=20
add the correct timezone-offset. In this way, all reports will be in the =

timezone of the AAA-server, despite that the original RADIUS-packets=20
might be generated in several different timezones (think USA, Australia, =

Russia, China).

But some vendors seem to have taken a different route, and seem to add=20
the timezone-offset themselves, so you can't use localtime(). This might =

be because the NAS doesn't know it's own offset to UTC, and it running=20
his clock in localtime. A good NAS would ofcourse use NTP, and then it=20
would report everything in UTC. But we've seen networks that report=20
completly different timestamps for different NAS'es, which might be in=20
different timezones or plainly misconfigured. And nobody is using NTP=20
ofcourse (*).

Can we clarify that EventTimestamp should be in UTC, and should not=20
contain a timezone-offset ? Or if that's impossible to do, maybe we can=20
add another attribute that tells us wether EventTimestamp is in UTC or=20
in a local timezone.

(*) small anecdote : recently, an East-European customer was complaining =

that we generated incorrect timestamps, always 4 hours later. At first=20
we though that their NAS wasn't using UTC-timestamps (as mentioned=20
above), but that didn't turn out to be the case (it would have given a 2 =

hour difference). He had installed his AAA-server in GMT+2, instead of=20
in GMT-2 (there's a difference between Windows and UNIX here !). This=20
means that his server was located somewhere west of Ireland :-) When we
asked him if he didn't use NTP, he replied that NTP was always=20
reporting an incorrect timestamp (always 4 hours later !), so he decided =

to disable NTP-support on his server. The problem was ofcourse the=20
timezone-offset on the server, not the NTP-clock. The NAS was actually=20
correctly configured.
So we asked him to correct it, and to turn on NTP again. He refused,=20
because it would mean that he had to reconfigure several dozens of=20
servers. They're still running a large network with that error (I can't=20
name the customer, but it's a well-known name). In order to correct the=20
"error in our software", he has also now misconfigured the NAS. And did=20
the same on every server wherever there was some software (webserver,=20
database, billing software, ...) that had the same error. Sigh.

--=20
Jo Hermans

Change is inevitable, except from a vending machine.

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

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

Delivery-date: Tue, 15 Jun 2004 15:05:09 +0000
Date: Tue, 15 Jun 2004 11:04:49 -0400
To: <[email-masked]>
From: "Joel M. Halpern" <[email-masked]>
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 

I think that David is being quite reasonable in this case, and trying to do 
what a lot of people (and the IESG) have asked for.  While we are all free 
to have technical concerns about any proposal, that is no reason to pick 
nits about history when we are actually making progress.

Yours,
Joel

At 09:13 AM 6/15/2004 -0400, Nelson, David wrote:
>Avi Lior writes...
>
> > Previous claims that subtypes break radius - "break radius" was tied
>to
> > breaking dictionaries.  And I and others agreed that it is not a good
>idea
> > to break dictionaries.
> >
> > Note Sterman and prepaid drafts did not break dictionaries because
>they
> > used
> > fundemental RADIUS types.
> >
> > Now we are breaking radius for real (as you stated) but we don't want
>to
> > call it that anymore......hmmmmmmmmmmmm
>
>I did not state that.  Please be more accurate with your attributions.
>This whole thread is a "tempest in a teapot", IMHO.
>
>-- Dave
>
>
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Tue, 15 Jun 2004 15:03:47 +0000
Date: Tue, 15 Jun 2004 17:03:26 +0200
From: [email-masked]
Organization: Alcatel Belgium
To: [email-masked]
Subject: accuracy of timestamps

Hello,

in my current work, I've recently seen some requirements about the 
accuracy of timestamps to be used in RADIUS, especially in VoIP 
environments. Some managers (and customers) started to demand that we 
would store the start of stop of a session with 0.1 second precision 
(+/- 0.5 seconds). They didn't want to use the EventTimestamp attribute 
(in seconds) or the time-of-arrival with a correction of AcctDelayTime 
(not accurate enough, because we don't know the RTT).

I remember that there has been a discussion when DIAMETER was designed, 
whether NTP-style timestamps should use used, but SNTP was chosen (also 
in seconds). I agree with this decision (statistics and all), but 
there's no argueing with my boss or the customers :-) The customers even 
started to quote some legal requirements (for phone service), so maybe 
some other implementors have seen the same problem. How did the 3GPP 
people have solved this problem ? I'm currently using the original VSA 
(they're not using EventTimestamp), specified in seconds, and I've added 
another VSA for the milliseconds part.

A related question :

EventTimestamp is defined as the number of seconds since 1/1/1970 00:00 
UTC. This is recognized by every programmer as the UNIX-style time() 
systemcall ofcourse, which returns the timestamp in UTC. You would use 
localtime() to translate this into a readable string, which would also 
add the correct timezone-offset. In this way, all reports will be in the 
timezone of the AAA-server, despite that the original RADIUS-packets 
might be generated in several different timezones (think USA, Australia, 
Russia, China).

But some vendors seem to have taken a different route, and seem to add 
the timezone-offset themselves, so you can't use localtime(). This might 
be because the NAS doesn't know it's own offset to UTC, and it running 
his clock in localtime. A good NAS would ofcourse use NTP, and then it 
would report everything in UTC. But we've seen networks that report 
completly different timestamps for different NAS'es, which might be in 
different timezones or plainly misconfigured. And nobody is using NTP 
ofcourse (*).

Can we clarify that EventTimestamp should be in UTC, and should not 
contain a timezone-offset ? Or if that's impossible to do, maybe we can 
add another attribute that tells us wether EventTimestamp is in UTC or 
in a local timezone.

(*) small anecdote : recently, an East-European customer was complaining 
that we generated incorrect timestamps, always 4 hours later. At first 
we though that their NAS wasn't using UTC-timestamps (as mentioned 
above), but that didn't turn out to be the case (it would have given a 2 
hour difference). He had installed his AAA-server in GMT+2, instead of 
in GMT-2 (there's a difference between Windows and UNIX here !). This 
means that his server was located somewhere west of Ireland :-)
When we asked him if he didn't use NTP, he replied that NTP was always 
reporting an incorrect timestamp (always 4 hours later !), so he decided 
to disable NTP-support on his server. The problem was ofcourse the 
timezone-offset on the server, not the NTP-clock. The NAS was actually 
correctly configured.
So we asked him to correct it, and to turn on NTP again. He refused, 
because it would mean that he had to reconfigure several dozens of 
servers. They're still running a large network with that error (I can't 
name the customer, but it's a well-known name). In order to correct the 
"error in our software", he has also now misconfigured the NAS. And did 
the same on every server wherever there was some software (webserver, 
database, billing software, ...) that had the same error. Sigh.

-- 
Jo Hermans

Change is inevitable, except from a vending machine.

--
to unsubscribe send a message 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, 15 Jun 2004 14:38:21 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
Date: Tue, 15 Jun 2004 10:37:45 -0400

I am taking Bernards advice and further communication on this topic will be
taken to the IESG.

But I must respond to this email since you are accusing me of making things
up.

This is what David Nelson stated in an email that started this conversation:

Avi Lior wrote:
> In this case though "base RADIUS" does "break".  All end-points (final 
> RADIUS servers and clients) will have to parse this new attribute
type.
> No?

David Nelso wrote:
Yes.  The charter has evolved, and the original desire to not "break"
existing RADIUS implementations (in particular data dictionary driven
implementations) has yielded to the desire to obtain better interoperability
with Diameter, simplify RADIUS/Diameter translation requirements, and to
unify the IETF standard, SDO-Specific and Vendor-Specific attribute data
models.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Tuesday, June 15, 2004 9:14 AM
> To: Avi Lior; [email-masked]
> Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
> 
> 
> Avi Lior writes...
> 
> > Previous claims that subtypes break radius - "break radius" was tied
> to
> > breaking dictionaries.  And I and others agreed that it is 
> not a good
> idea
> > to break dictionaries.
> > 
> > Note Sterman and prepaid drafts did not break dictionaries because
> they
> > used
> > fundemental RADIUS types.
> > 
> > Now we are breaking radius for real (as you stated) but we 
> don't want
> to
> > call it that anymore......hmmmmmmmmmmmm
> 
> I did not state that.  Please be more accurate with your 
> attributions. This whole thread is a "tempest in a teapot", IMHO.
> 
> -- Dave
> 
> 

--
to unsubscribe send a message 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, 15 Jun 2004 13:14:41 +0000
Content-class: urn:content-classes:message
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
Date: Tue, 15 Jun 2004 09:13:42 -0400
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> Previous claims that subtypes break radius - "break radius" was tied
to
> breaking dictionaries.  And I and others agreed that it is not a good
idea
> to break dictionaries.
>=20
> Note Sterman and prepaid drafts did not break dictionaries because
they
> used
> fundemental RADIUS types.
>=20
> Now we are breaking radius for real (as you stated) but we don't want
to
> call it that anymore......hmmmmmmmmmmmm

I did not state that.  Please be more accurate with your attributions.
This whole thread is a "tempest in a teapot", IMHO.

-- Dave

--
to unsubscribe send a message 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, 15 Jun 2004 10:57:18 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments to "RADIUS Attributes Extension "
Date: Tue, 15 Jun 2004 03:57:02 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "David Mariblanca \(ML/EEM\)" <[email-masked]>, <[email-masked]>

Hi David,
Please see my responses inline.  Please let me know if you have any
questions.
BR,
Farid

>=20
> Thanks for the quick reply, Farid.
> I see the NAS may need to associate the user with some=20
> identity. But (using your example) how does a NAS know who is=20
> [email-masked] ?=20

It doesn't.  3456 is a unique identity known to the home operator (i.e.,
anyisp).  NAS associates the user's session with [email-masked]; the
NAS can refer to the user's session by this identity in future for
example to resolve charging disputes.  The NAS also reports this
identity in accounting request.

> [email-masked] means nothing.
> Or is it the case that the NAS will use [email-masked] for=20
> example to report accounting information to other network=20
> element, where the mapping [email-masked]<->"real identity" exists ?

The later one.
>=20
>

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

Delivery-date: Tue, 15 Jun 2004 09:40:54 +0000
From: "David Mariblanca (ML/EEM)" <[email-masked]>
To: "'Adrangi, Farid'" <[email-masked]>, [email-masked]
Subject: RE: Comments to "RADIUS Attributes Extension "
Date: Tue, 15 Jun 2004 11:40:40 +0200

Thanks for the quick reply, Farid.
I see the NAS may need to associate the user with some identity. But (using your example) how does a NAS know who is [email-masked] ? [email-masked] means nothing.
Or is it the case that the NAS will use [email-masked] for example to report accounting information to other network element, where the mapping [email-masked]<->"real identity" exists ?

David.

-----Original Message-----
From: Adrangi, Farid [mailto:[email-masked]]
Sent: lunes, 14 de junio de 2004 23:54
To: David Mariblanca (ML/EEM); [email-masked]
Subject: RE: Comments to "RADIUS Attributes Extension "

Hello David,
Thanks for your comments.  Please see my responses inline.
BR,
Farid

> -----Original Message-----
> From: David Mariblanca (ML/EEM) 
> [mailto:[email-masked]] 
> Sent: Monday, June 14, 2004 7:41 AM
> To: [email-masked]'; Adrangi, Farid
> Subject: Comments to "RADIUS Attributes Extension "
> 
> 
> 
> Hi Farid and all,
> small comments to this paper
> 
> - Diameter should be considered (comment already given as I can see).
> 
Yes.  We should.
> - In User Alias Identity attribute, I don't see why a home 
> network operator may wish to use this it, if it is hiding the 
> user identity in other payload of the message. I mean, it the 
> home network is hiding the user identity it's because it 
> wants some kind of privacy for the user identity. So if this 
> attribute is used, such privacy would be broken. Even more, 
> if the Alias used is some identity with an standardized 
> format like E.164 or the IMSI.
> 

That is not the problem.  The problem is that the NAS needs to associate
the user with some identity when the user authenticates to the access
network using an anonymous id.  So, the home network needs to convey
some form of identity to the NAS for that user's session -- it does not
have to be the user's real identity.  For example, it could be
[email-masked].  Please let me know if this did not answer questions.

> - Also, this attribute seems at the beginning to be for all 
> purposes but later on its description is very focused on 
> charging functions.

We chose a generic name that can used for other purposes.  We can use
specific name like billable identity or chargeable user identity.
> 
> Regards,
> David.
> 
> 
> 
> 
> 

--
to unsubscribe send a message 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, 15 Jun 2004 08:44:14 +0000
Content-class: urn:content-classes:message
Subject: RE: User Alias Identity (Was: Re: comments on draft-adrangi-radius-attributes-extension-00.tx)
Date: Tue, 15 Jun 2004 01:43:16 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Bernard,
Thanks for your comments and questions. Please see my responses inline.
BR,
Farid

>=20
> > >    So, presumably the NASes were not prepared for the
> > >    possibility that the User-Name attribute might change.
> > >    Do they actually break, or is it just that they ignore
> > >    the User-Name attribute when it comes back?
> >
> > It will break the billing functionality according to the information
> > that we got from GSMA vendors.
>=20
> Can you explain what this means?  Does the NAS crash?  Send=20
> an accounting
> record with the User-Name sent in the Access-Request instead?  Do
> something else?  Perhaps we should hear directly from the vendors in
> question about how they handle this.
>=20

One type of failure is that the NAS discards the User-Name (rewritten)
in the Access-Accept.  I am not in a position to provide any vendor's
name here -- but all I can say GSMA has included this attribute in the
EAP-SIM roaming guidelines, and it was already implemented by all
vendors participated in the GSMA EAP-SIM trial.   Jouni Korhonen (the
editor of GSMA's EAP-SIM roaming guidelines) can provide more
information if needed.

> Remember that RFC 2865 enables inclusion of the User-Name=20
> attribute in an
> Access-Accept, so that compliant RADIUS client=20
> implementations need to be
> able to deal with this:
>=20
>    Request   Accept   Reject   Challenge   #    Attribute
>    0-1       0-1      0        0            1   User-Name
>=20

RFC 2865 does not say anything about the UserName(1) rewrite.  Please
see below for more ...

> > It applies to all scenarios where user's real or billable=20
> identity is
> > not revealed to the NAS by the user.
>=20
> RFC 3579 contains the same entry as RFC 2865 with respect to=20
> User-Name:
>=20
> Request  Accept  Reject  Challenge   #    Attribute
> 0-1      0-1     0       0            1   User-Name
>=20

Please see my response below to the specific text in RFC 3579.

> > RFC3579 does not mandate supporting user-name(1) rewrite so=20
> in my mind
> > it won't make it uncompliant. No?
>=20
> Here is what RFC 3579 says:
>=20
> "In order to permit forwarding of the Access-Reply by=20
> EAP-unaware proxies,
> if a User-Name attribute was included in an Access-Request, the RADIUS
> server MUST include the User-Name attribute in subsequent=20
> Access-Accept
> packets. Without the User-Name attribute, accounting and=20
> billing becomes
> difficult to manage.  The User-Name attribute within the=20
> Access-Accept packet
> need not be the same as the User-Name attribute in the=20
> Access-Request."
>=20

I think this is the source of the problem -- the RFC 3579 is not clear
about whether a NAS should include the UserName (1) value received in
the AccessAccept rather than the one was orginally sent in the
Access-Accept packet in the accounting request.=20

> So I'd say that a RADIUS client needs to support User-Name in an
> Access-Accept and also needs to be prepared for user-name rewrite.
>=20

Again the RFC is not clear which UserName value should be used by the
NAS.

> > The difference in the amount of code changes required by these two
> > methods is not the core issue.  The main goal is to provide=20
> a solution
> > that can be deployment without any changes to NAS, and without
> > disturbing the current use of User-Name(1) -- i.e., GSMA
> > vendors/operators don't want to overload the use of UserName(1) or
> > create conflicts/incompatibilities.
>=20
> This seems like one of several areas in which there are=20
> interoperability
> issues with current RADIUS implementations.  Where there are
> interoperability problems, it is typically required for *some*
> implementation to change.  The purpose of the "RADIUS Implementation
> Errors and Fixes" document is to document these problems and propose
> solutions.
>=20
> > >    ensure that the above NAS-need-not-be-changed properties can
> > >    be achieved if we move into this separation. That is, I'd like
> > >    to understand how this works in a backwards compatible manner
> > >    without requiring updates to the NASes.
>=20
> I don't see how this can possibly be implemented without=20
> changing NASes.
> Since this is an interoperability issue, the problem isn't=20
> "does someone
> have to change" -- but rather "what  should change" and "how".
>=20
>=20
This can be handled by the access network AAA proxy.

--
to unsubscribe send a message 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, 15 Jun 2004 04:45:01 +0000
Date: Tue, 15 Jun 2004 00:44:37 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: "Adrangi, Farid" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: User Alias Identity (Was: Re: comments on draft-adrangi-radius-attributes-extension-00.tx)

On Mon, Jun 14, 2004 at 06:20:22PM -0700, Bernard Aboba wrote:
> 
> Here is what RFC 3579 says:
> 
> "In order to permit forwarding of the Access-Reply by EAP-unaware proxies,
> if a User-Name attribute was included in an Access-Request, the RADIUS
> server MUST include the User-Name attribute in subsequent Access-Accept
> packets. Without the User-Name attribute, accounting and billing becomes
> difficult to manage.  The User-Name attribute within the Access-Accept packet
> need not be the same as the User-Name attribute in the Access-Request."
> 
> So in effect, handling of a User-Name attribute within an Access-Accept is
> mandatory.  RFC 3579 also warns RADIUS client implementations not to
> assume that the User-Name attribute will not necessarily be the same in a
> response as in a request.
> 
> So I'd say that a RADIUS client needs to support User-Name in an
> Access-Accept and also needs to be prepared for user-name rewrite.

RFC3579 is specifically for EAP support in RADIUS.  Are you saying that
you believe it mandates behavior for RADIUS implementations that do not
support EAP?

Also, I don't understand the paragraph as written.  How would a User-Name
in an access reply help a proxy to forward it towards the original sender
of the request?  I would have thought that a stateless proxy would use
the State attribute to remember from whence a request came.

I hold no strong opinion on User-Name rewriting, but simply want to
understand the logic of the debate.

Regards,
Barney

--
to unsubscribe send a message 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, 15 Jun 2004 03:42:09 +0000
Date: Mon, 14 Jun 2004 23:39:24 -0400
To: [email-masked]
From: David Mitton <[email-masked]>
Subject: RE: User Alias Identity (Was: Re: comments on draft-adrangi-radius-attributes-extension-00.txt)

On 6/14/2004 06:20 PM -0700, Bernard Aboba wrote:
...
>So I'd say that a RADIUS client needs to support User-Name in an
>Access-Accept and also needs to be prepared for user-name rewrite.
...

I've seen this behavior in action.  Someone's RADIUS server returns the 
username as written in the database, not a direct echo of the input value, 
and they do a case-insensitive match on the database.   So the name 
returned can have a different UPcase characteristic.   The NAS picked this 
up and used it in the Accounting messages.

Dave.  

--
to unsubscribe send a message 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, 15 Jun 2004 01:20:03 +0000
Date: Mon, 14 Jun 2004 18:20:22 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: User Alias Identity (Was: Re: comments on draft-adrangi-radius-attributes-extension-00.tx)

> >    So, presumably the NASes were not prepared for the
> >    possibility that the User-Name attribute might change.
> >    Do they actually break, or is it just that they ignore
> >    the User-Name attribute when it comes back?
>
> It will break the billing functionality according to the information
> that we got from GSMA vendors.

Can you explain what this means?  Does the NAS crash?  Send an accounting
record with the User-Name sent in the Access-Request instead?  Do
something else?  Perhaps we should hear directly from the vendors in
question about how they handle this.

Remember that RFC 2865 enables inclusion of the User-Name attribute in an
Access-Accept, so that compliant RADIUS client implementations need to be
able to deal with this:

   Request   Accept   Reject   Challenge   #    Attribute
   0-1       0-1      0        0            1   User-Name

> It applies to all scenarios where user's real or billable identity is
> not revealed to the NAS by the user.

RFC 3579 contains the same entry as RFC 2865 with respect to User-Name:

Request  Accept  Reject  Challenge   #    Attribute
0-1      0-1     0       0            1   User-Name

> RFC3579 does not mandate supporting user-name(1) rewrite so in my mind
> it won't make it uncompliant. No?

Here is what RFC 3579 says:

"In order to permit forwarding of the Access-Reply by EAP-unaware proxies,
if a User-Name attribute was included in an Access-Request, the RADIUS
server MUST include the User-Name attribute in subsequent Access-Accept
packets. Without the User-Name attribute, accounting and billing becomes
difficult to manage.  The User-Name attribute within the Access-Accept packet
need not be the same as the User-Name attribute in the Access-Request."

So in effect, handling of a User-Name attribute within an Access-Accept is
mandatory.  RFC 3579 also warns RADIUS client implementations not to
assume that the User-Name attribute will not necessarily be the same in a
response as in a request.

So I'd say that a RADIUS client needs to support User-Name in an
Access-Accept and also needs to be prepared for user-name rewrite.

> The difference in the amount of code changes required by these two
> methods is not the core issue.  The main goal is to provide a solution
> that can be deployment without any changes to NAS, and without
> disturbing the current use of User-Name(1) -- i.e., GSMA
> vendors/operators don't want to overload the use of UserName(1) or
> create conflicts/incompatibilities.

This seems like one of several areas in which there are interoperability
issues with current RADIUS implementations.  Where there are
interoperability problems, it is typically required for *some*
implementation to change.  The purpose of the "RADIUS Implementation
Errors and Fixes" document is to document these problems and propose
solutions.

> >    ensure that the above NAS-need-not-be-changed properties can
> >    be achieved if we move into this separation. That is, I'd like
> >    to understand how this works in a backwards compatible manner
> >    without requiring updates to the NASes.

I don't see how this can possibly be implemented without changing NASes.
Since this is an interoperability issue, the problem isn't "does someone
have to change" -- but rather "what  should change" and "how".

--
to unsubscribe send a message 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, 15 Jun 2004 00:41:15 +0000
Date: Mon, 14 Jun 2004 17:41:50 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Keeping on topic

Over the last few days, there have been a large number of off-topic
messages on this list, relating to changes in the RADEXT WG
charter.

At this point change control over the RADEXT WG charter lies with the
IESG.  As described in the WG Review message sent by the IESG on May 19,
2004, input on the RADEXT WG charter needs to be sent to [email-masked]:

http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg00139.html

So if you'd like to suggest a change in the RADEXT WG charter, please send
mail to [email-masked], *not* to the RADEXT WG mailing list
([email-masked]).

Thanks,

Bernard

--
to unsubscribe send a message 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, 14 Jun 2004 23:49:18 +0000
Date: Mon, 14 Jun 2004 16:49:18 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: [email-masked]
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 

> I don't think you have consensus on this issue David.

The current RADEXT charter is under consideration by the IESG.  If you
believe that the Charter is not appropriate, please send feeback to
[email-masked].

--
to unsubscribe send a message 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, 14 Jun 2004 22:39:44 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
Date: Mon, 14 Jun 2004 18:39:04 -0400

Well lets see:

Previous claims that subtypes break radius - "break radius" was tied to
breaking dictionaries.  And I and others agreed that it is not a good idea
to break dictionaries. 

Note Sterman and prepaid drafts did not break dictionaries because they used
fundemental RADIUS types.

Now we are breaking radius for real (as you stated) but we don't want to
call it that anymore......hmmmmmmmmmmmm

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Monday, June 14, 2004 6:17 PM
> To: Avi Lior; [email-masked]
> Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
> 
> 
> Avi Lior writes...
> 
> > Whether or not you are allowed to break RADIUS.
> 
> No one wants to "break" RADIUS.  Not the WG, not the IESG, 
> not the IETF. The requirement is still to avoid "breaking" 
> RADIUS.  However, the term "break" is inexact in the absence 
> of some technical definition.  The statements about 
> maintaining backwards compatibility with existing RADIUS RFCs 
> are the current technical definition of what it means to not 
> "break" RADIUS.
> 
> -- Dave
> 
> 

--
to unsubscribe send a message 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, 14 Jun 2004 22:17:35 +0000
Content-class: urn:content-classes:message
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
Date: Mon, 14 Jun 2004 18:17:20 -0400
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> Whether or not you are allowed to break RADIUS.

No one wants to "break" RADIUS.  Not the WG, not the IESG, not the IETF.
The requirement is still to avoid "breaking" RADIUS.  However, the term
"break" is inexact in the absence of some technical definition.  The
statements about maintaining backwards compatibility with existing
RADIUS RFCs are the current technical definition of what it means to not
"break" RADIUS.

-- Dave

--
to unsubscribe send a message 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, 14 Jun 2004 22:08:49 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
Date: Mon, 14 Jun 2004 18:08:29 -0400

Whether or not you are allowed to break RADIUS.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Monday, June 14, 2004 5:31 PM
> To: Avi Lior; [email-masked]
> Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
> 
> 
> 
> Avi Lior writes...
> 
> > I don't think you have consensus on this issue David.
> 
> OK. I've lost track of this thread.  What issue do you think 
> fails to achieve consensus?
> 
> -- The definition of "breaking RADIUS"? 
> 
> -- The current requirements of the charter?
> 
> Please elaborate.
> 
> -- Dave
> 
> 

--
to unsubscribe send a message 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, 14 Jun 2004 21:55:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments to "RADIUS Attributes Extension "
Date: Mon, 14 Jun 2004 14:54:23 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "David Mariblanca \(ML/EEM\)" <[email-masked]>, <[email-masked]>

Hello David,
Thanks for your comments.  Please see my responses inline.
BR,
Farid

> -----Original Message-----
> From: David Mariblanca (ML/EEM)=20
> [mailto:[email-masked]]=20
> Sent: Monday, June 14, 2004 7:41 AM
> To: [email-masked]'; Adrangi, Farid
> Subject: Comments to "RADIUS Attributes Extension "
>=20
>=20
>=20
> Hi Farid and all,
> small comments to this paper
>=20
> - Diameter should be considered (comment already given as I can see).
>=20
Yes.  We should.
> - In User Alias Identity attribute, I don't see why a home=20
> network operator may wish to use this it, if it is hiding the=20
> user identity in other payload of the message. I mean, it the=20
> home network is hiding the user identity it's because it=20
> wants some kind of privacy for the user identity. So if this=20
> attribute is used, such privacy would be broken. Even more,=20
> if the Alias used is some identity with an standardized=20
> format like E.164 or the IMSI.
>=20

That is not the problem.  The problem is that the NAS needs to associate
the user with some identity when the user authenticates to the access
network using an anonymous id.  So, the home network needs to convey
some form of identity to the NAS for that user's session -- it does not
have to be the user's real identity.  For example, it could be
[email-masked].  Please let me know if this did not answer questions.

> - Also, this attribute seems at the beginning to be for all=20
> purposes but later on its description is very focused on=20
> charging functions.

We chose a generic name that can used for other purposes.  We can use
specific name like billable identity or chargeable user identity.
>=20
> Regards,
> David.
>=20
>=20
>=20
>=20
>=20

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

Delivery-date: Mon, 14 Jun 2004 21:36:29 +0000
Content-class: urn:content-classes:message
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
Date: Mon, 14 Jun 2004 17:36:18 -0400
From: "Nelson, David" <[email-masked]>
To: "Kuntal Chowdhury" <[email-masked]>, <[email-masked]>

Kuntal Chowdhury writes...

> >I will also observe that the changes in the pending charter
> >that (a) emphasize RADIUS/Diameter interoperability and
> >migration, (b) encourage rationalization of attribute data
> >models and (c) require considerations for complex data types,
> >were introduced during the IESG review of the charter.  It is
> >my understanding that these changes are not subject to WG consensus.
>=20
> Sorry to hear that IETF/IESG may take the direction of NOT listing to
what
> the industry has to say. It is rather dangerous to let a few people to
> decide what the industry will do.

It is not my position to speak for the IESG.  However, the changes in
the proposed charter text that I have reported were made by members of
the IESG to resolve comments received from members of the IETF community
during the proposed charter comment period.  That's the way the process
works.

Backwards compatibility with existing RADIUS RFCs is still a strong
requirement for all RADEXT WG work.

-- Dave

--
to unsubscribe send a message 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, 14 Jun 2004 21:32:35 +0000
Content-class: urn:content-classes:message
Subject: RE: User Alias Identity (Was: Re: comments on draft-adrangi-radius-attributes-extension-00.tx)
Date: Mon, 14 Jun 2004 14:32:01 -0700
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Adrangi, Farid" <[email-masked]>

Hi Jari,
Sorry for a late reply -- catching up with my e-mails.  Thanks for your
good questions -- please see my responses inline.
BR,
Farid

>=20
> Ok. Let me go into a bit more depth here. Lets
> look at the issues one at a time:
>=20
> "Some NASes may not like user-name rewriting"
>=20
>    Fair enough. This may well be the case. Let me try to
>    understand why, and talk about the potential alternative
>    solutions and what makes them better in this respect.
>=20
>    So, presumably the NASes were not prepared for the
>    possibility that the User-Name attribute might change.
>    Do they actually break, or is it just that they ignore
>    the User-Name attribute when it comes back?
=20
It will break the billing functionality according to the information
that we got from GSMA vendors.

>=20
>    It seems like the functionality we are talking about
>    could be applied either in the context of EAP (RFC 3579)
>    or web-based logins (plain RADIUS). Are these problems
>    common in both cases or just in one?

It applies to all scenarios where user's real or billable identity is
not revealed to the NAS by the user.

>=20
>    Am I correct in assuming that if the context is EAP usage,
>    then a NAS which would be unable to support a rewritten
>    username would be uncompliant per requirements of RFC 3579?

RFC3579 does not mandate supporting user-name(1) rewrite so in my mind
it won't make it uncompliant. No?

>    It seems so, from Section 3. Now, I really don't want to
>    say that RFC 3579 is 100% right here -- it could well be that
>    this requirement should not have been there. However, I'd
>    like to ensure that the addition of the User Alias Identity
>    attributes helps solve the problem. I think the question
>    is "does the NAS vendor have to do something to get solution
>    X working in his product"?

Not really.  Because, this attribute can be handled by the access
network AAA proxy if the software update to NAS is not feasible.

> Presumably, the action to make
>    the User-Name approach work is to add code to read the
>    incoming User-Name from an Access-Accept and make it be
>    sent on accounting requests. Is there a similar code
>    change for User Alias Identity, or will all currently
>    unknown attributes be copied to the accounting requests?

The difference in the amount of code changes required by these two
methods is not the core issue.  The main goal is to provide a solution
that can be deployment without any changes to NAS, and without
disturbing the current use of User-Name(1) -- i.e., GSMA
vendors/operators don't want to overload the use of UserName(1) or
create conflicts/incompatibilities. =20

>    I tried to look at RFCs 2866 and 2869 but I did not find
>    a clear answer... but it would seem logical to copy all
>    attributes.
>=20
> "Need for a structured identity for indicating user's=20
> chargeable identity"
>=20
>    Right now, the chargeable identity has normally been the User-Name.
>    But I do agree that divorcing the identity used in the=20
> authentication
>    process -- which may be a specific temporary identity to=20
> begin with --
>    and the accounting identity would be useful. However, I'd like to
>    ensure that the above NAS-need-not-be-changed properties can
>    be achieved if we move into this separation. That is, I'd like
>    to understand how this works in a backwards compatible manner
>    without requiring updates to the NASes.

Please see my response above.

>=20
>    The second issue I'd like to have a better understanding and better
>    text on is the privacy issue. I think the privacy issues within the
>    authentication identity and the accounting identity are somewhat
>    separate; in the former we are most concerned about=20
> over-the-wireless
>    privacy. But I would also like to avoid telling the cleartext or
>    trackable user identity to a zillion access points attached to
>    coffee shop walls.=20

You are right.  But, operators have a choice to indicate an opaque
identity that makes the user untrackable. =20

>I think that boils down to suggesting in the
>    document that the accounting identity should be hidden somehow.
>    This is what you said in your response, but maybe we
>    could write it to the document as well.

I agree.  I Will make this clear in the next update.

>=20
>    Finally, I would note that since the routing of the=20
> Accounting-Request
>    packets is based on the User-Name domain part, it would appear that
>    the User-Name needs to be kept there as well.

Absolutely. We are not changing the behaviour or use the UserName(1)
attribute.
>=20
> --Jari
>=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: Mon, 14 Jun 2004 21:31:23 +0000
Content-class: urn:content-classes:message
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
Date: Mon, 14 Jun 2004 17:31:10 -0400
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> I don't think you have consensus on this issue David.

OK. I've lost track of this thread.  What issue do you think fails to
achieve consensus?

-- The definition of "breaking RADIUS"?=20

-- The current requirements of the charter?

Please elaborate.

-- Dave

--
to unsubscribe send a message 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, 14 Jun 2004 21:25:42 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
Date: Mon, 14 Jun 2004 17:25:18 -0400

I don't think you have consensus on this issue David.  

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Monday, June 14, 2004 4:39 PM
> To: Avi Lior; [email-masked]
> Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
> 
> 
> Avi Lior writes...
> 
> > Oh please!!!
> > 
> > After months of telling me and others that our "sub-types" 
> attributes
> were
> > breaking RADIUS - when they were clearly NOT.
> 
> Given the definition of "break" that we were using at that 
> time (maintaining compatibility with data dictionary driven 
> implementations) and given that there was no standard method 
> of encapsulating sub-types within IETF standard attributes, I 
> think my previous statements were accurate. 
> 
> > You of all people should not make statements such as this.
> 
> I fear you are starting to personalize the issues.  I am 
> relaying a statement of the current WG and charter direction 
> as driven by the IESG, in my capacity of Co-Chair.  This is 
> one of those "tell it like it is" statements.  I see no 
> reason why you should feel me disqualified to pass along this 
> information.
> 
> -- Dave
> 
> 
> 

--
to unsubscribe send a message 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, 14 Jun 2004 21:13:05 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: "Nelson, David" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
Date: Mon, 14 Jun 2004 17:12:33 -0400

[email-masked] wrote:

> We may have simply changed the threshold of what we mean by "break".
>

Could you please elaborate on this "changed threshold" for breaking RADIUS
comment? I heard from a big network operator that any modification to
existing RADIUS protocol use/ attribute formats is a BIG No No.

>I will also observe that the changes in the pending charter 
>that (a) emphasize RADIUS/Diameter interoperability and 
>migration, (b) encourage rationalization of attribute data 
>models and (c) require considerations for complex data types, 
>were introduced during the IESG review of the charter.  It is 
>my understanding that these changes are not subject to WG consensus.
>

Sorry to hear that IETF/IESG may take the direction of NOT listing to what
the industry has to say. It is rather dangerous to let a few people to
decide what the industry will do.

-Kuntal

--
to unsubscribe send a message 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, 14 Jun 2004 21:12:07 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: Who is the other Co-chair? - (was  Is it okay to break RADIUS? (w as RADIUS V2)) 
Date: Mon, 14 Jun 2004 17:11:49 -0400

BTW who is the other Co-chair(s)?

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Monday, June 14, 2004 4:39 PM
> To: Avi Lior; [email-masked]
> Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
> 
> 
> Avi Lior writes...
> 
> > Oh please!!!
> > 
> > After months of telling me and others that our "sub-types" 
> attributes
> were
> > breaking RADIUS - when they were clearly NOT.
> 
> Given the definition of "break" that we were using at that 
> time (maintaining compatibility with data dictionary driven 
> implementations) and given that there was no standard method 
> of encapsulating sub-types within IETF standard attributes, I 
> think my previous statements were accurate. 
> 
> > You of all people should not make statements such as this.
> 
> I fear you are starting to personalize the issues.  I am 
> relaying a statement of the current WG and charter direction 
> as driven by the IESG, in my capacity of Co-Chair.  This is 
> one of those "tell it like it is" statements.  I see no 
> reason why you should feel me disqualified to pass along this 
> information.
> 
> -- Dave
> 
> 
> 

--
to unsubscribe send a message 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, 14 Jun 2004 21:12:01 +0000
Content-class: urn:content-classes:message
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
Date: Mon, 14 Jun 2004 17:11:50 -0400
From: "Nelson, David" <[email-masked]>
To: "Parviz Yegani" <[email-masked]>, <[email-masked]>

Parviz Yegani writes...

> >I will also observe that the changes in the pending charter that (a)
> >emphasize RADIUS/Diameter interoperability and migration, (b)
encourage
> >rationalization of attribute data models and (c) require
considerations
> >for complex data types, were introduced during the IESG review of the
> >charter.  It is my understanding that these changes are not subject
to
> >WG consensus.
>=20
> So, are you saying that the IESG in its infinite wisdom is
recommending
> that we can break Radius to achieve (a)-(c) above?

Of course not.

The goal is to achieve (a) - (c) while maintaining backwards
compatibility with existing RADIUS RFCs and forward compatibility with
existing Diameter RFCs (and nearly-RFCs).  When we use the term "break"
RADIUS, it implies change it in a non-backwards compatible fashion.  At
one point in time our definition of "break" meant "requires core parser
code changes in data dictionary driven RADIUS implementations".  We have
backed off from that definition.  It is now allowable for some code
changes to be required to take advantage of the new features, but the
changes must be designed so that existing implementations SHOULD ignore
the new attributes.

-- Dave

--
to unsubscribe send a message 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, 14 Jun 2004 21:02:33 +0000
Date: Mon, 14 Jun 2004 14:02:09 -0700
To: "Nelson, David" <[email-masked]>, "Avi Lior" <[email-masked]>, <[email-masked]>
From: Parviz Yegani <[email-masked]>
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 

At 04:25 PM 6/14/2004 -0400, Nelson, David wrote:
>Avi Lior writes...
>
> > Right now I don't buy that its okay to break RADIUS.
>
>I don't think anyone is interested in breaking RADIUS.  We still have
>language in the charter requiring backwards compatibility with existing
>RADIUS RFCs.  We may have simply changed the threshold of what we mean
>by "break".

Interesting. It seems that the charter now allows us to break Radius as 
long as the
breakage point is below a certain threshold. How is this threshold defined 
and by whom?

>I will also observe that the changes in the pending charter that (a)
>emphasize RADIUS/Diameter interoperability and migration, (b) encourage
>rationalization of attribute data models and (c) require considerations
>for complex data types, were introduced during the IESG review of the
>charter.  It is my understanding that these changes are not subject to
>WG consensus.

So, are you saying that the IESG in its infinite wisdom is recommending that
we can break Radius to achieve (a)-(c) above?

-Parviz

>-- Dave
>
>
>
>--
>to unsubscribe send 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, 14 Jun 2004 20:39:35 +0000
Content-class: urn:content-classes:message
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
Date: Mon, 14 Jun 2004 16:39:25 -0400
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> Oh please!!!
>=20
> After months of telling me and others that our "sub-types" attributes
were
> breaking RADIUS - when they were clearly NOT.

Given the definition of "break" that we were using at that time
(maintaining compatibility with data dictionary driven implementations)
and given that there was no standard method of encapsulating sub-types
within IETF standard attributes, I think my previous statements were
accurate.=20

> You of all people should not make statements such as this.

I fear you are starting to personalize the issues.  I am relaying a
statement of the current WG and charter direction as driven by the IESG,
in my capacity of Co-Chair.  This is one of those "tell it like it is"
statements.  I see no reason why you should feel me disqualified to pass
along this information.

-- Dave

--
to unsubscribe send a message 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, 14 Jun 2004 20:28:21 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
Date: Mon, 14 Jun 2004 16:28:10 -0400

> 
> 
> Avi Lior writes...
> 
> > Right now I don't buy that its okay to break RADIUS.
> 
> I don't think anyone is interested in breaking RADIUS.  We 
> still have language in the charter requiring backwards 
> compatibility with existing RADIUS RFCs.  We may have simply 
> changed the threshold of what we mean by "break".

Oh please!!!

After months of telling me and others that our "sub-types" attributes were
breaking RADIUS - when they were clearly NOT.  You of all people should not
make statements such as this.

--
to unsubscribe send a message 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, 14 Jun 2004 20:25:23 +0000
Content-class: urn:content-classes:message
Subject: RE: Is it okay to break RADIUS? (was RADIUS V2) 
Date: Mon, 14 Jun 2004 16:25:11 -0400
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> Right now I don't buy that its okay to break RADIUS.

I don't think anyone is interested in breaking RADIUS.  We still have
language in the charter requiring backwards compatibility with existing
RADIUS RFCs.  We may have simply changed the threshold of what we mean
by "break".

I will also observe that the changes in the pending charter that (a)
emphasize RADIUS/Diameter interoperability and migration, (b) encourage
rationalization of attribute data models and (c) require considerations
for complex data types, were introduced during the IESG review of the
charter.  It is my understanding that these changes are not subject to
WG consensus.

-- Dave

--
to unsubscribe send a message 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, 14 Jun 2004 20:13:15 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, Alan DeKok <[email-masked]>,  [email-masked]
Subject: Is it okay to break RADIUS? (was RADIUS V2) 
Date: Mon, 14 Jun 2004 16:13:02 -0400

Right now I don't buy that its okay to break RADIUS.

Avi Lior wrote: 
> > In this case though "base RADIUS" does "break".  All 
> end-points (final 
> > RADIUS servers and clients) will have to parse this new attribute
> type.
> > No?

David Nelson repsonded:

> Yes.  The charter has evolved, and the original desire to not 
> "break" existing RADIUS implementations (in particular data 
> dictionary driven
> implementations) has yielded to the desire to obtain better 
> interoperability with Diameter, simplify RADIUS/Diameter 
> translation requirements, and to unify the IETF standard, 
> SDO-Specific and Vendor-Specific attribute data models.  The 
> charter includes finding ways to accommodate complex data 
> types, while maintaining backwards compatibility with RADIUS 
> RFCs and forward compatibility with Diameter RFCs, as part of 
> the Design Guidelines document.
> 
> It seems clear to me that finding an acceptable solution for 
> complex data types, given the constraints, will require 
> changes to any RADIUS implementation that wishes to use that 
> new attribute format.  The current goal is to find a 
> *single*, *standard* way to accomplish this, so that existing 
> implementations would only need to perform such an upgrade once.
> -- Dave
> 
>    
> 

--
to unsubscribe send a message 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, 14 Jun 2004 20:00:51 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, Alan DeKok <[email-masked]>,  [email-masked]
Subject: RE: RADIUS V2 
Date: Mon, 14 Jun 2004 16:00:28 -0400

Dave wrote:
> The charter does not embrace other "improvements" to RADIUS, 
> or any notion of creating a RADIUS V2 or RADIUS+ protocol.

I've seen a similar statement to this before with just different words ;-)

--
to unsubscribe send a message 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, 14 Jun 2004 18:36:48 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS V2 
Date: Mon, 14 Jun 2004 14:36:32 -0400
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Alan DeKok" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> > > What happened between Charter 3,4 etc. (no new attribute types)
and
> > > now? We should be asking these questions as well no?
> >
> >   This is a good point.  I can see a proposed
> > Diameter-Message attribute carrying diameter attributes, and
> > not much more.  It can then be an opaque type to everyone who
> > doesn't use it.
>=20
> As you would recall, I took a lot of heat for proposing an attribute
that
> was opaque to someone who doesn't use it.
>=20
> In this case though "base RADIUS" does "break".  All end-points (final
> RADIUS servers and clients) will have to parse this new attribute
type.
> No?

Yes.  The charter has evolved, and the original desire to not "break"
existing RADIUS implementations (in particular data dictionary driven
implementations) has yielded to the desire to obtain better
interoperability with Diameter, simplify RADIUS/Diameter translation
requirements, and to unify the IETF standard, SDO-Specific and
Vendor-Specific attribute data models.  The charter includes finding
ways to accommodate complex data types, while maintaining backwards
compatibility with RADIUS RFCs and forward compatibility with Diameter
RFCs, as part of the Design Guidelines document.

It seems clear to me that finding an acceptable solution for complex
data types, given the constraints, will require changes to any RADIUS
implementation that wishes to use that new attribute format.  The
current goal is to find a *single*, *standard* way to accomplish this,
so that existing implementations would only need to perform such an
upgrade once.

The charter does not embrace other "improvements" to RADIUS, or any
notion of creating a RADIUS V2 or RADIUS+ protocol.

-- 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: Mon, 14 Jun 2004 18:19:16 +0000
From: Avi Lior <[email-masked]>
To: 'Alan DeKok' <[email-masked]>, [email-masked]
Subject: RE: RADIUS V2 
Date: Mon, 14 Jun 2004 14:19:03 -0400

> > What happened between Charter 3,4 etc. (no new attribute types) and 
> > now? We should be asking these questions as well no?
> 
>   This is a good point.  I can see a proposed 
> Diameter-Message attribute carrying diameter attributes, and 
> not much more.  It can then be an opaque type to everyone who 
> doesn't use it.

As you would recall, I took a lot of heat for proposing an attribute that
was opaque to someone who doesn't use it.

In this case though "base RADIUS" does "break".  All end-points (final
RADIUS servers and clients) will have to parse this new attribute type. No?

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

Envelope-to: [email-masked]
Delivery-date: Mon, 14 Jun 2004 18:00:06 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: RADIUS V2 
Date: Mon, 14 Jun 2004 14:06:14 -0400
Message-Id: <[email-masked]>

Avi Lior <[email-masked]> wrote:
> I would have thought that we didn't want to go to RADIUSv2.  But reading the
> list you would get the impression that RADIUS has a long bright future.

  RADIUS (as RADIUS) *does* have a long and bright future.

  RADIUS++ or RADIUSv2 should be killed before they get too far.

> I do like Jari attribute but is it too little too late? 
> 
> Is someone really asking for it?  Are things really busted?

  I can see it as one path to moving to diameter.  There aren't
currently a lot of system using or demanding diameter.  Having
diameter attributes carried inside of RADIUS could help:

  a) avoid adding more features to RADIUS
  b) the migration to diameter.

  Of course, there are issues with this encapsulation, as has been
pointed out in earlier messages.

> What happened between Charter 3,4 etc. (no new attribute types) and now? We
> should be asking these questions as well no?

  This is a good point.  I can see a proposed Diameter-Message
attribute carrying diameter attributes, and not much more.  It can
then be an opaque type to everyone who doesn't use it.

  Alan DeKok.

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

Delivery-date: Mon, 14 Jun 2004 17:59:42 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: IETF Extended attribute and Vendor Id
Date: Mon, 14 Jun 2004 13:59:31 -0400

Assuming we have an issue with SDOs and Vendor Ids.

I don't see how this is actually addressing some of the concerns raised
before with SDOs and Vendors.

We are still using Vendor ID to support extension.  

To be clear I don't see SDOs going to the IETF to request codes. New codes
require some sort of IETF action.

 
> I have a concrete suggestion.
> 
> One of the problems in the current data model(s)
> is that we have technically and administratively
> different identifier spaces and data types for the
> various objects (attributes) in the AAA protocols and
> their extensions. While its desirable to provide
> a different set of administrative rules to allocate
> local and standard extensions, it is not desirable
> to fragment the spaces so that different specifications
> are needed to document the formats of these extensions.
> It is also not desirable to have more than one space
> for new standard attributes at the IETF, because
> this would create a need for translation.
> 
> With this in mind, the following proposal defines
> a new IETF extended RADIUS attribute that provides
> extended data types, supports vendor, SDO, and IETF
> attributes and avoids different spaces for RADIUS
> and Diameter. This has obvious advantages going forward,
> but it also eliminates the need for a few attributes
> from the currently proposed filter extensions, as
> existing specifications could be used as is.
> 
> The format supports a variety of data types, including
> IPv6 addresses, floating point numbers, and subattributes.
> 
> Here it is:
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Type      |  Length       |            Code
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>             Code (cont)             |V M r r r r r r| Vendor-ID (opt)
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>              Vendor-ID (opt, cont)                  | Data ...
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     Type
> 
>        <To Be Allocated By IANA> for IETF Extended
> 
>     Length
> 
>        >= 7
> 
>     Code
> 
>        This field identifies the attribute. Only values greater than
>        or equal to 256 are allowed. Current values are defined in
>        [RFC 3588], and if V = 0, new ones may be allocated following
>        Designated Expert with Specification Required [IANA].
>        Release of blocks of AVPs (more than 3 at a time
>        for a given purpose) should require IETF Consensus. If V != 0,
>        the indicated vendor is responsible for managing the 
> allocations.
> 
>     Vendor-ID
> 
>        The high-order octet is 0 and the low-order 3 octets 
> are the SMI
>        Network Management Private Enterprise Code of the Vendor in
>        network byte order.
> 
>     M
> 
>        The 'M' Bit, known as the Mandatory bit, indicates 
> whether support
>        of the attribute is required.  If an attribute with 
> the 'M' bit set is
>        received by a client, server, proxy, or translation agent
>        and either the attribute or its value is unrecognized, 
> the message MUST
>        be rejected.  Relay and redirect agents MUST NOT reject
>        messages with unrecognized attributes.
> 
>        The 'M' bit MUST be set according to the rules defined 
> for the attribute
>        containing it.  In order to preserve interoperability, an
>        implementation MUST be able to exclude from a message any
>        Mandatory attribute which is not defined for the specific
>        standard that this node claims conformance to.  It MAY 
> do this in one
>        of the following ways:
> 
>        1) If a message is rejected because it contains a Mandatory AVP
>           which is not defined in the relevant standard, the 
> implementation
>           may resend the message without the attribute, 
> possibly inserting
>           additional standard attributes instead.
> 
>        2) A configuration option may be provided on a system wide, per
>           peer, or per realm basis that would allow/prevent particular
>           Mandatory attributes to be sent.  Thus an 
> administrator could change
>           the configuration to avoid interoperability problems.
> 
>        Implementations are required to support all Mandatory
>        attributes which are defined in the relevant standard.
> 
>        Attributes with the 'M' bit cleared are informational 
> only and a
>        receiver that receives a message with such an 
> attribute that is not
>        supported, or whose value is not supported, MAY simply 
> ignore the
>        attribute.
> 
>     V
> 
>        The 'V' bit, known as the Vendor-Specific bit, 
> indicates whether
>        the optional Vendor-ID field is present in the header.  When
>        set the Code belongs to the specific vendor code address
>        space.
> 
>     r
> 
>        The 'r' (reserved) bits are unused and SHOULD be set
>        to 0.  Note that subsequent specifications MAY define
>        additional bits within the header, and an unrecognized bit
>        SHOULD be considered an error.
> 
>     Data
> 
>        The Data field is zero or more octets and contains
>        information specific to the atribute.  The format
>        and length of the Data field is determined by the
>        Code and Length fields.  The format of the Data field
>        MUST be one of the following base data types or a data
>        type derived from the base data types.  In the event
>        that a new base format is needed, a new version of
>        this RFC must be created.
> 
>        string
> 
>          The data contains arbitrary data of variable length.
>          See [RFC 2865].
> 
>        integer
> 
>          32 bit unsigned value, in network byte order. See [RFC 2865].
> 
>        integer64
> 
>          64 bit signed value, in network byte order.  See [RFC 3588].
> 
>        signed32
> 
>          32 bit signed value, in network byte order. See [RFC 3588].
> 
>        signed64
> 
>          64 bit signed value, in network byte order.  See [RFC 3588].
> 
>        float32
> 
>          This represents floating point values of single precision as
>          described by [FLOATPOINT].  The 32-bit value is 
> transmitted in
>          network byte order. See [RFC 3588].
> 
>        float64
> 
>          This represents floating point values of double precision as
>          described by [FLOATPOINT].  The 64-bit value is 
> transmitted in
>          network byte order. See [RFC 3588].
> 
>        grouped
> 
>          The Data field is specified as a sequence of attributes.
>          Each of these attributess follows - in the order in which
>          they are specified - including their headers.
> 
>        generic address
> 
>          This format is derived from the string base format. It
>          is a discriminated union, representing, for example a
>          32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most
>          significant octet first.  The first two octets of the Address
>          attribute represents the AddressType, which contains 
> an Address Family
>          defined in [IANAADFAM].  The AddressType is used to 
> discriminate
>          the content and format of the remaining octets. See 
> [RFC 3588].
> 
>        generic time
> 
>          This format is derived from the string base format.
>          The string MUST contain four octets, in the same 
> format as the
>          first four bytes are in the NTP timestamp format.  The NTP
>          Timestamp format is defined in chapter 3 of [SNTP].
> 
>          This represents the number of seconds since 0h on 1 
> January 1900
>          with respect to the Coordinated Universal Time (UTC).
> 
>          On 6h 28m 16s UTC, 7 February 2036 the time value 
> will overflow.
>          SNTP [SNTP] describes a procedure to extend the time to 2104.
>          This procedure MUST be supported by all nodes.
> 
>        text
> 
>          This format is derived from the string base format.
>          This is a human readable string represented using the
>          ISO/IEC IS 10646-1 character set, encoded as an 
> OctetString using
>          the UTF-8 [UFT8] transformation format described in RFC 2279.
>          See [RFC 2865] and [RFC 3588].
> 
>        enumerated
> 
>          Enumerated is derived from the integer base format. The
>          definition contains a list of valid values and their
>          interpretation and is described in the specification
>          introducing the attribute.
> 
>        ipfilterrule
> 
>          This format is derived from the string base
>          format.  It uses the ASCII charset.  See [RFC 3588].
> 
> (Open issues: inclusion of Diameter Identity data type, and
> the support for >255 long attributes. Either one is doable,
> though.)
> 
> --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/>
> 

--
to unsubscribe send a message 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, 14 Jun 2004 17:51:57 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: IETF Extended attribute and length
Date: Mon, 14 Jun 2004 13:51:30 -0400

Jari,

Here are my comments/suggestions....

Length:
We need to be able to extend longer than 255 octets.  Why?
-We are had discussion on having something longer in at least one particular
case.
-If we want to be compatible with Diameter then the length should be longer.
-We are suggesting to use this for grouped AVPs this needs longer attributes

The current overhead for this attribute is 11 bytes add 4 for payload. We
therefore can encode 17 integers attributes.  Some examples are starting to
come close to that.

To maintain maximal backwards compatibility I suggest we keep the attribute
to a max 255 and overflow to the next attribute - as would be the normal way
we do this in RADIUS.  However, we need an explicit indication that we are
overflowing. That is when we have two consecutive attributes in a packet we
need to differentiate between two different GROUPed AVPs an overflow.
Perhaps using one of the 'r' bits to indicate a continuation.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, June 09, 2004 5:14 AM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Object identifier and type spaces in a rationalized 
> RADIUS data model
> 
> 
> 
> I have a concrete suggestion.
> 
> One of the problems in the current data model(s)
> is that we have technically and administratively
> different identifier spaces and data types for the
> various objects (attributes) in the AAA protocols and
> their extensions. While its desirable to provide
> a different set of administrative rules to allocate
> local and standard extensions, it is not desirable
> to fragment the spaces so that different specifications
> are needed to document the formats of these extensions.
> It is also not desirable to have more than one space
> for new standard attributes at the IETF, because
> this would create a need for translation.
> 
> With this in mind, the following proposal defines
> a new IETF extended RADIUS attribute that provides
> extended data types, supports vendor, SDO, and IETF
> attributes and avoids different spaces for RADIUS
> and Diameter. This has obvious advantages going forward,
> but it also eliminates the need for a few attributes
> from the currently proposed filter extensions, as
> existing specifications could be used as is.
> 
> The format supports a variety of data types, including
> IPv6 addresses, floating point numbers, and subattributes.
> 
> Here it is:
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Type      |  Length       |            Code
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>             Code (cont)             |V M r r r r r r| Vendor-ID (opt)
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>              Vendor-ID (opt, cont)                  | Data ...
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     Type
> 
>        <To Be Allocated By IANA> for IETF Extended
> 
>     Length
> 
>        >= 7
> 
>     Code
> 
>        This field identifies the attribute. Only values greater than
>        or equal to 256 are allowed. Current values are defined in
>        [RFC 3588], and if V = 0, new ones may be allocated following
>        Designated Expert with Specification Required [IANA].
>        Release of blocks of AVPs (more than 3 at a time
>        for a given purpose) should require IETF Consensus. If V != 0,
>        the indicated vendor is responsible for managing the 
> allocations.
> 
>     Vendor-ID
> 
>        The high-order octet is 0 and the low-order 3 octets 
> are the SMI
>        Network Management Private Enterprise Code of the Vendor in
>        network byte order.
> 
>     M
> 
>        The 'M' Bit, known as the Mandatory bit, indicates 
> whether support
>        of the attribute is required.  If an attribute with 
> the 'M' bit set is
>        received by a client, server, proxy, or translation agent
>        and either the attribute or its value is unrecognized, 
> the message MUST
>        be rejected.  Relay and redirect agents MUST NOT reject
>        messages with unrecognized attributes.
> 
>        The 'M' bit MUST be set according to the rules defined 
> for the attribute
>        containing it.  In order to preserve interoperability, an
>        implementation MUST be able to exclude from a message any
>        Mandatory attribute which is not defined for the specific
>        standard that this node claims conformance to.  It MAY 
> do this in one
>        of the following ways:
> 
>        1) If a message is rejected because it contains a Mandatory AVP
>           which is not defined in the relevant standard, the 
> implementation
>           may resend the message without the attribute, 
> possibly inserting
>           additional standard attributes instead.
> 
>        2) A configuration option may be provided on a system wide, per
>           peer, or per realm basis that would allow/prevent particular
>           Mandatory attributes to be sent.  Thus an 
> administrator could change
>           the configuration to avoid interoperability problems.
> 
>        Implementations are required to support all Mandatory
>        attributes which are defined in the relevant standard.
> 
>        Attributes with the 'M' bit cleared are informational 
> only and a
>        receiver that receives a message with such an 
> attribute that is not
>        supported, or whose value is not supported, MAY simply 
> ignore the
>        attribute.
> 
>     V
> 
>        The 'V' bit, known as the Vendor-Specific bit, 
> indicates whether
>        the optional Vendor-ID field is present in the header.  When
>        set the Code belongs to the specific vendor code address
>        space.
> 
>     r
> 
>        The 'r' (reserved) bits are unused and SHOULD be set
>        to 0.  Note that subsequent specifications MAY define
>        additional bits within the header, and an unrecognized bit
>        SHOULD be considered an error.
> 
>     Data
> 
>        The Data field is zero or more octets and contains
>        information specific to the atribute.  The format
>        and length of the Data field is determined by the
>        Code and Length fields.  The format of the Data field
>        MUST be one of the following base data types or a data
>        type derived from the base data types.  In the event
>        that a new base format is needed, a new version of
>        this RFC must be created.
> 
>        string
> 
>          The data contains arbitrary data of variable length.
>          See [RFC 2865].
> 
>        integer
> 
>          32 bit unsigned value, in network byte order. See [RFC 2865].
> 
>        integer64
> 
>          64 bit signed value, in network byte order.  See [RFC 3588].
> 
>        signed32
> 
>          32 bit signed value, in network byte order. See [RFC 3588].
> 
>        signed64
> 
>          64 bit signed value, in network byte order.  See [RFC 3588].
> 
>        float32
> 
>          This represents floating point values of single precision as
>          described by [FLOATPOINT].  The 32-bit value is 
> transmitted in
>          network byte order. See [RFC 3588].
> 
>        float64
> 
>          This represents floating point values of double precision as
>          described by [FLOATPOINT].  The 64-bit value is 
> transmitted in
>          network byte order. See [RFC 3588].
> 
>        grouped
> 
>          The Data field is specified as a sequence of attributes.
>          Each of these attributess follows - in the order in which
>          they are specified - including their headers.
> 
>        generic address
> 
>          This format is derived from the string base format. It
>          is a discriminated union, representing, for example a
>          32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most
>          significant octet first.  The first two octets of the Address
>          attribute represents the AddressType, which contains 
> an Address Family
>          defined in [IANAADFAM].  The AddressType is used to 
> discriminate
>          the content and format of the remaining octets. See 
> [RFC 3588].
> 
>        generic time
> 
>          This format is derived from the string base format.
>          The string MUST contain four octets, in the same 
> format as the
>          first four bytes are in the NTP timestamp format.  The NTP
>          Timestamp format is defined in chapter 3 of [SNTP].
> 
>          This represents the number of seconds since 0h on 1 
> January 1900
>          with respect to the Coordinated Universal Time (UTC).
> 
>          On 6h 28m 16s UTC, 7 February 2036 the time value 
> will overflow.
>          SNTP [SNTP] describes a procedure to extend the time to 2104.
>          This procedure MUST be supported by all nodes.
> 
>        text
> 
>          This format is derived from the string base format.
>          This is a human readable string represented using the
>          ISO/IEC IS 10646-1 character set, encoded as an 
> OctetString using
>          the UTF-8 [UFT8] transformation format described in RFC 2279.
>          See [RFC 2865] and [RFC 3588].
> 
>        enumerated
> 
>          Enumerated is derived from the integer base format. The
>          definition contains a list of valid values and their
>          interpretation and is described in the specification
>          introducing the attribute.
> 
>        ipfilterrule
> 
>          This format is derived from the string base
>          format.  It uses the ASCII charset.  See [RFC 3588].
> 
> (Open issues: inclusion of Diameter Identity data type, and
> the support for >255 long attributes. Either one is doable,
> though.)
> 
> --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/>
> 

--
to unsubscribe send a message 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, 14 Jun 2004 16:29:03 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: RADIUS V2
Date: Mon, 14 Jun 2004 12:28:43 -0400

Bernard,

See comments below:

> As has been pointed out on this list, there are currently 
> quite a few "gotchas" in RADIUS/Diameter gateway operation.  
> For example, VSAs with "sub-attributes" are translated to 
> individual Diameter Vendor-Specific AVPs, rather than "Grouped" AVPs.

When you say "sub-attributes"  how are you defining sub-attributes?
As you know there was confusion surrounding this term.  I think it would be
helpful to use percise language here.
 
> It seems to me that Jari's proposal will improve the fidelity 
> of translation significantly, and make it quite a bit easier 
> to define attributes for both RADIUS and Diameter 
> simultaneously.  It also may allow for reuse of AVP 
> definitions in RFC 3588, NASREQ, Diameter EAP, etc., saving 
> considerable work (and text) in RADEXT WG documents.

I don't disagree with this.  But note that this is clearly a new RADIUS type
of attribute.  It will break existing code and specifically it will impact
what I call "base radius" that is, Policy Engines and Dictionary Parsers
etc. 

> Given the potential benefits, the proposal is definitely 
> worth serious examination.

I agree.  It would seem that one would consider this work if one had long
term prospects for RADIUS.  Since we are clearly "breaking RADIUS" what else
should we be looking at?

How about RADIUS reliability? Introduce a hearbeat mechanism and improve
accounting. Clearly a more pressing issue.

How about longer attribute lengths? -- as described before there is a need
for this and we see more evidence as we build more secure networks.

Avi

--
to unsubscribe send a message 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, 14 Jun 2004 15:48:29 +0000
Date: Mon, 14 Jun 2004 08:48:50 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: RADIUS V2

> Look at how long it took vendors to support Dynamic Authorization
> (RFC3576) - most still don't support it. Similar with the
> MessageAuthenticator attribute.

At this point many RADIUS implementations do support
Message-Authenticator, but it took several years for this to be
implemented.  RFC 3576 is going to be adopted more slowly because it
represents a change in the message flow -- and requires changes in RADIUS
proxies.

> I like Jari's extended attribute for 1 reason : forwards compatibility
> with Diameter. They could be used to build a good bidirectional
> RADIUS-DIAMETER gateway, which is difficult now, especially when
> translating a request from DIAMETER to RADIUS.

As has been pointed out on this list, there are currently quite a few
"gotchas" in RADIUS/Diameter gateway operation.  For example, VSAs with
"sub-attributes" are translated to individual Diameter Vendor-Specific
AVPs, rather than "Grouped" AVPs.

It seems to me that Jari's proposal will improve the fidelity of
translation significantly, and make it quite a bit easier to define
attributes for both RADIUS and Diameter simultaneously.  It also may allow
for reuse of AVP definitions in RFC 3588, NASREQ, Diameter EAP, etc.,
saving considerable work (and text) in RADEXT WG documents.

Given the potential benefits, the proposal is definitely worth serious
examination.

--
to unsubscribe send a message 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, 14 Jun 2004 15:07:37 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked]
Cc: Avi Lior <[email-masked]>
Subject: RE: RADIUS V2
Date: Mon, 14 Jun 2004 11:07:02 -0400

Hi Johan,

I would have thought that we didn't want to go to RADIUSv2.  But reading the
list you would get the impression that RADIUS has a long bright future.  If
that was true then we should be addressing other issues and these issues are
way more important then what was originally proposed by some.

I do like Jari attribute but is it too little too late? 

Is someone really asking for it?  Are things really busted?

What happened between Charter 3,4 etc. (no new attribute types) and now? We
should be asking these questions as well no?

What do you make of position that espouses the death of RADIUS then all of a
sudden start tauting  RADIUS Guidelines and Rationalization?  I for one
would like to understand the reason for that shift.

If this shift is justified then lets look at what we really have to do?

NASREQ btw is the forward compatibility for RADIUS and Diameter.  Do we
really need another one?

Avi.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Monday, June 14, 2004 5:03 AM
> To: [email-masked]
> Cc: Avi Lior
> Subject: Re: RADIUS V2
> 
> 
> Avi Lior wrote:
> 
> >  
> > Since it seems by the traffic on the list -- if we need a "fresh
> > start"  the lets do it right folks.
> >  
> > I propose that we create RADIUS V2 and that we include the new
> > attribute proposed by Jari and do some other good things as well.  
> > After all, reading the list one would get the impression 
> that RADIUS 
> > will live a long time. 
> >
> This sounds like a flashback to the year 1999. RADIUSv2, 
> Radius++, etc 
> ... were proposed a long time ago, but in the end Diameter 
> has won. Do 
> we need all that debate all over again ?
> 
> I know that Diameter has gotten a slow start, but it's 
> currently being 
> implemented (though mostly in the 3GPP world). Existing RADIUS 
> implementations will benefit from the work in this WG, but radical 
> changes might take a long time before they get implemented by 
> vendors.  
> Look at how long it took vendors to support Dynamic Authorization 
> (RFC3576) - most still don't support it. Similar with the 
> MessageAuthenticator attribute.
> 
> I like Jari's extended attribute for 1 reason : forwards 
> compatibility 
> with Diameter. They could be used to build a good bidirectional 
> RADIUS-DIAMETER gateway, which is difficult now, especially when 
> translating a request from DIAMETER to RADIUS.
> 
> > Like a Phoenix RADIUS seems to have risen from the ashes.  
> I therefore
> > propose that we call this version of RADIUS -- RADIUS Phoenix!!!
> >  
> >  
> 
> Heh ... I'm also a volunteer for Mozilla. Watch out with that 
> 'phoenix' 
> name, we got burned too :-)
> 
> -- 
> Jo Hermans
> 
> Change is inevitable, except from a vending machine.
> 

--
to unsubscribe send a message 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, 14 Jun 2004 14:41:41 +0000
From: "David Mariblanca (ML/EEM)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Adrangi, Farid" <[email-masked]>
Subject: Comments to "RADIUS Attributes Extension "
Date: Mon, 14 Jun 2004 16:41:17 +0200

Hi Farid and all,
small comments to this paper

- Diameter should be considered (comment already given as I can see).

- In User Alias Identity attribute, I don't see why a home network operator may wish to use this it, if it is hiding the user identity in other payload of the message. I mean, it the home network is hiding the user identity it's because it wants some kind of privacy for the user identity. So if this attribute is used, such privacy would be broken. Even more, if the Alias used is some identity with an standardized format like E.164 or the IMSI.

- Also, this attribute seems at the beginning to be for all purposes but later on its description is very focused on charging functions.

Regards,
David.

--
to unsubscribe send a message 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, 14 Jun 2004 11:56:48 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: new version of draft-sterman-aaa-sip
Date: Mon, 14 Jun 2004 13:52:02 +0200

Hello,

a new version of the HTTP Digest RADIUS draft is available:
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-02.txt

Changes from -01

   o  Replaced Sub-attributes with flat attributes [don't ask]
   o  aligned naming with draft-ietf-aaa-diameter-sip-app-02
   o  Added how a server must treat unknown attributes.
   o  Added a section 'Migration path to DIAMETER' [input/corrections from AAA WG welcome]
   o  Added an optional attribute for support of the digest scheme
      described in informational [RFC3310].
   o  Added a mode of operation where the RADIUS server chooses the
      nonce.  This was required for AKA [RFC3310], but can be useful for
      ordinary Digest authentication when the qop directive is not used.
      This required the addition of several attributes.

Wolfgang

--
Wolfgang Beck
T-Systems
Internet Netzplattformen
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt 

--
to unsubscribe send a message 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, 14 Jun 2004 09:03:43 +0000
Date: Mon, 14 Jun 2004 11:02:55 +0200
From: [email-masked]
Organization: Alcatel Belgium
To: [email-masked]
CC: Avi Lior <[email-masked]>
Subject: Re: RADIUS V2

Avi Lior wrote:

>  
> Since it seems by the traffic on the list -- if we need a "fresh 
> start"  the lets do it right folks.
>  
> I propose that we create RADIUS V2 and that we include the new 
> attribute proposed by Jari and do some other good things as well.  
> After all, reading the list one would get the impression that RADIUS 
> will live a long time. 
>
This sounds like a flashback to the year 1999. RADIUSv2, Radius++, etc 
... were proposed a long time ago, but in the end Diameter has won. Do 
we need all that debate all over again ?

I know that Diameter has gotten a slow start, but it's currently being 
implemented (though mostly in the 3GPP world). Existing RADIUS 
implementations will benefit from the work in this WG, but radical 
changes might take a long time before they get implemented by vendors.  
Look at how long it took vendors to support Dynamic Authorization 
(RFC3576) - most still don't support it. Similar with the 
MessageAuthenticator attribute.

I like Jari's extended attribute for 1 reason : forwards compatibility 
with Diameter. They could be used to build a good bidirectional 
RADIUS-DIAMETER gateway, which is difficult now, especially when 
translating a request from DIAMETER to RADIUS.

> Like a Phoenix RADIUS seems to have risen from the ashes.  I therefore 
> propose that we call this version of RADIUS -- RADIUS Phoenix!!!
>  
>  

Heh ... I'm also a volunteer for Mozilla. Watch out with that 'phoenix' 
name, we got burned too :-)

-- 
Jo Hermans

Change is inevitable, except from a vending machine.

--
to unsubscribe send a message 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, 13 Jun 2004 15:13:43 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: RADIUS V2
Date: Sun, 13 Jun 2004 11:13:35 -0400

Oh one more thing Bernard - I am not interested in RADIUS V2.

My point is that reading the list one would get the impression that others
are.

They are either using the Guidelines and associated threads as delaying
tactic or are truly beilvers that RADIUS needs to be fixed for its long life
going forward.

Which is it?

If we belive that RADIUS has a long life going forward.  Lets do the work
right.  That is my point.

Avi

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: June 12, 2004 10:27 AM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: RADIUS V2
> 
> 
> If you're interested in designing a new AAA protocol, I 
> suggest you request a BOF at IETF 60 for that purpose.
> 
> Designing RADIUSv2 is not within the scope of the RADEXT WG Charter.
> 
> On Sat, 12 Jun 2004, Avi Lior wrote:
> 
> >
> > Since it seems by the traffic on the list -- if we need a "fresh 
> > start"  the lets do it right folks.
> >
> > I propose that we create RADIUS V2 and that we include the new 
> > attribute proposed by Jari and do some other good things as well.  
> > After all, reading the list one would get the impression 
> that RADIUS 
> > will live a long time.
> >
> > Like a Phoenix RADIUS seems to have risen from the ashes.  
> I therefore 
> > propose that we call this version of RADIUS -- RADIUS Phoenix!!!
> >
> >
> >
> 

--
to unsubscribe send a message 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, 13 Jun 2004 15:10:45 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: RADIUS V2
Date: Sun, 13 Jun 2004 11:10:36 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C45158.94DEAE50
Content-Type: text/plain

If that is true John then why are we talking about some of these attributes?
 
I want to do the necessary work in RADIUS and not introduce new Attribute
Types and Spaces. 
 
Why are  talking about Guidelines etc at this stage of RADIUS?
 
Is this a delaying tactic? Or are people wanting to improve RADIUS?
 
If so then do it right, address other issues (which are more imporant).
That is my point.
 
And by the way RADIUS V2 is not Diameter.  Diameter is a totally new
protocol.  RADIUS V2 wouldn't be so radical a change.
 
Avi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: June 12, 2004 9:45 AM
To: [email-masked]; [email-masked]
Subject: RE: RADIUS V2

Avi,

Since it seems by the traffic on the list -- if we need a "fresh start"  the
lets do it right folks.
 
I propose that we create RADIUS V2 and that we include the new attribute
proposed by Jari and do some other good things as well.  After all, reading
the list one would get the impression that RADIUS will live a long time.  
 
Like a Phoenix RADIUS seems to have risen from the ashes.  I therefore
propose that we call this version of RADIUS -- RADIUS Phoenix!!! 
 
Didn't the IETF try this before?  I thought RADIUSv2 = Diameter ... 
 
John 

------_=_NextPart_001_01C45158.94DEAE50
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=328570415-13062004><FONT face=Arial color=#0000ff size=2><EM>If 
that is true John then why are we talking about some of these 
attributes?</EM></FONT></SPAN></DIV>
<DIV><SPAN class=328570415-13062004><EM><FONT face=Arial color=#0000ff 
size=2></FONT></EM></SPAN>&nbsp;</DIV>
<DIV><SPAN class=328570415-13062004><EM><FONT face=Arial color=#0000ff size=2>I 
want to do the necessary work in RADIUS and not introduce new Attribute Types 
and Spaces.&nbsp;</FONT></EM></SPAN></DIV>
<DIV><SPAN class=328570415-13062004><EM><FONT face=Arial color=#0000ff 
size=2></FONT></EM></SPAN>&nbsp;</DIV>
<DIV><SPAN class=328570415-13062004><EM><FONT face=Arial color=#0000ff 
size=2>Why are &nbsp;talking about Guidelines etc at this stage of 
RADIUS?</FONT></EM></SPAN></DIV>
<DIV><SPAN class=328570415-13062004><EM><FONT face=Arial color=#0000ff 
size=2></FONT></EM></SPAN>&nbsp;</DIV>
<DIV><SPAN class=328570415-13062004><EM><FONT face=Arial color=#0000ff size=2>Is 
this a delaying tactic? Or are people wanting to improve 
RADIUS?</FONT></EM></SPAN></DIV>
<DIV><SPAN class=328570415-13062004><EM><FONT face=Arial color=#0000ff 
size=2></FONT></EM></SPAN>&nbsp;</DIV>
<DIV><SPAN class=328570415-13062004><EM><FONT face=Arial color=#0000ff size=2>If 
so then do it right, a</FONT></EM></SPAN><SPAN 
class=328570415-13062004><EM><FONT face=Arial color=#0000ff size=2>ddress other 
issues (which are more imporant).&nbsp; That is my 
point.</FONT></EM></SPAN></DIV>
<DIV><SPAN class=328570415-13062004><EM><FONT face=Arial color=#0000ff 
size=2></FONT></EM></SPAN>&nbsp;</DIV>
<DIV><SPAN class=328570415-13062004><EM><FONT face=Arial color=#0000ff 
size=2>And by the way RADIUS V2 is not Diameter.&nbsp; Diameter is a totally new 
protocol.&nbsp; RADIUS V2 wouldn't be so radical a 
change.</FONT></EM></SPAN></DIV>
<DIV><SPAN class=328570415-13062004><EM><FONT face=Arial color=#0000ff 
size=2></FONT></EM></SPAN>&nbsp;</DIV>
<DIV><SPAN class=328570415-13062004><EM><FONT face=Arial color=#0000ff 
size=2>Avi</FONT></EM></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
  [email-masked] [mailto:[email-masked]] <BR><B>Sent:</B> June 
  12, 2004 9:45 AM<BR><B>To:</B> [email-masked]; 
  [email-masked]<BR><B>Subject:</B> RE: RADIUS V2<BR><BR></FONT></DIV>
  <DIV><SPAN class=368174413-12062004><FONT face=Arial color=#0000ff 
  size=2>Avi,</FONT></SPAN></DIV>
  <DIV><FONT face=Arial size=2><SPAN 
  class=296101213-12062004></SPAN></FONT><FONT face=Arial size=2><SPAN 
  class=296101213-12062004></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <DIV><FONT face=Arial size=2><SPAN class=296101213-12062004>Since it seems 
    by the traffic on the list -- if we need a "fresh start"&nbsp; the lets do 
    it right folks.</SPAN></FONT></DIV>
    <DIV><FONT face=Arial size=2><SPAN 
    class=296101213-12062004></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=Arial size=2><SPAN class=296101213-12062004>I propose that 
    we create RADIUS V2 and that we include the new attribute proposed by Jari 
    and do some other good things as well.&nbsp; After all, reading the list one 
    would get the impression that RADIUS will live a long time.&nbsp; 
    </SPAN></FONT></DIV>
    <DIV><FONT face=Arial size=2><SPAN 
    class=296101213-12062004></SPAN></FONT>&nbsp;</DIV>
    <DIV><SPAN class=296101213-12062004><FONT face=Arial><FONT 
    size=2>Like&nbsp;a Phoenix RADIUS seems to have risen from the 
    ashes.&nbsp;&nbsp;I therefore propose that we call this version of RADIUS -- 
    RADIUS Phoenix!!!<SPAN class=368174413-12062004><FONT 
    color=#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
    <DIV><SPAN class=296101213-12062004><FONT face=Arial><FONT size=2><SPAN 
    class=368174413-12062004></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=296101213-12062004><FONT face=Arial><FONT size=2><SPAN 
    class=368174413-12062004><FONT color=#0000ff>Didn't the IETF try this 
    before?&nbsp; I thought RADIUSv2 = Diameter 
    ...&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
    <DIV><SPAN class=296101213-12062004><FONT face=Arial><FONT size=2><SPAN 
    class=368174413-12062004></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=296101213-12062004><FONT face=Arial><FONT size=2><SPAN 
    class=368174413-12062004><FONT 
    color=#0000ff>John</FONT>&nbsp;</SPAN></FONT></FONT></SPAN></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C45158.94DEAE50--

--
to unsubscribe send a message 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, 13 Jun 2004 15:04:38 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: RADIUS V2
Date: Sun, 13 Jun 2004 11:03:58 -0400

I agree totally!!! Then why are we considering new spaces and new rules and
new coding.

I am not opening these flood gates others are.

What happened to no new Attribute Types?

Avi 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: June 12, 2004 10:27 AM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: RADIUS V2
> 
> 
> If you're interested in designing a new AAA protocol, I 
> suggest you request a BOF at IETF 60 for that purpose.
> 
> Designing RADIUSv2 is not within the scope of the RADEXT WG Charter.
> 
> On Sat, 12 Jun 2004, Avi Lior wrote:
> 
> >
> > Since it seems by the traffic on the list -- if we need a "fresh 
> > start"  the lets do it right folks.
> >
> > I propose that we create RADIUS V2 and that we include the new 
> > attribute proposed by Jari and do some other good things as well.  
> > After all, reading the list one would get the impression 
> that RADIUS 
> > will live a long time.
> >
> > Like a Phoenix RADIUS seems to have risen from the ashes.  
> I therefore 
> > propose that we call this version of RADIUS -- RADIUS Phoenix!!!
> >
> >
> >
> 

--
to unsubscribe send a message 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, 12 Jun 2004 14:26:38 +0000
Date: Sat, 12 Jun 2004 07:27:25 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: [email-masked]
Subject: Re: RADIUS V2

If you're interested in designing a new AAA protocol, I suggest you
request a BOF at IETF 60 for that purpose.

Designing RADIUSv2 is not within the scope of the RADEXT WG Charter.

On Sat, 12 Jun 2004, Avi Lior wrote:

>
> Since it seems by the traffic on the list -- if we need a "fresh start"  the
> lets do it right folks.
>
> I propose that we create RADIUS V2 and that we include the new attribute
> proposed by Jari and do some other good things as well.  After all, reading
> the list one would get the impression that RADIUS will live a long time.
>
> Like a Phoenix RADIUS seems to have risen from the ashes.  I therefore
> propose that we call this version of RADIUS -- RADIUS Phoenix!!!
>
>
>

--
to unsubscribe send a message 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, 12 Jun 2004 13:45:13 +0000
content-class: urn:content-classes:message
Subject: RE: RADIUS V2
Date: Sat, 12 Jun 2004 16:44:56 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C45083.724D5A61
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Avi,
=20

Since it seems by the traffic on the list -- if we need a "fresh start"  =
the lets do it right folks.
=20
I propose that we create RADIUS V2 and that we include the new attribute =
proposed by Jari and do some other good things as well.  After all, =
reading the list one would get the impression that RADIUS will live a =
long time. =20
=20
Like a Phoenix RADIUS seems to have risen from the ashes.  I therefore =
propose that we call this version of RADIUS -- RADIUS Phoenix!!!=20
=20
Didn't the IETF try this before?  I thought RADIUSv2 =3D Diameter ...=20
=20
John=20

------_=_NextPart_001_01C45083.724D5A61
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D368174413-12062004><FONT face=3DArial color=3D#0000ff =

size=3D2>Avi,</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D296101213-12062004></SPAN></FONT><FONT=20
face=3DArial size=3D2><SPAN =
class=3D296101213-12062004></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D296101213-12062004>Since it seems by=20
  the traffic on the list -- if we need a "fresh start"&nbsp; the lets =
do it=20
  right folks.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D296101213-12062004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D296101213-12062004>I =
propose that we=20
  create RADIUS V2 and that we include the new attribute proposed by =
Jari and do=20
  some other good things as well.&nbsp; After all, reading the list one =
would=20
  get the impression that RADIUS will live a long time.&nbsp;=20
  </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D296101213-12062004></SPAN></FONT>&nbsp;</DIV>
  <DIV><SPAN class=3D296101213-12062004><FONT face=3DArial><FONT =
size=3D2>Like&nbsp;a=20
  Phoenix RADIUS seems to have risen from the ashes.&nbsp;&nbsp;I =
therefore=20
  propose that we call this version of RADIUS -- RADIUS Phoenix!!!<SPAN=20
  class=3D368174413-12062004><FONT=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D296101213-12062004><FONT face=3DArial><FONT =
size=3D2><SPAN=20
  class=3D368174413-12062004></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D296101213-12062004><FONT face=3DArial><FONT =
size=3D2><SPAN=20
  class=3D368174413-12062004><FONT color=3D#0000ff>Didn't the IETF try =
this=20
  before?&nbsp; I thought RADIUSv2 =3D Diameter=20
  ...&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D296101213-12062004><FONT face=3DArial><FONT =
size=3D2><SPAN=20
  class=3D368174413-12062004></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D296101213-12062004><FONT face=3DArial><FONT =
size=3D2><SPAN=20
  class=3D368174413-12062004><FONT=20
  =
color=3D#0000ff>John</FONT>&nbsp;</SPAN></FONT></FONT></SPAN></DIV></BLOC=
KQUOTE></BODY></HTML>

------_=_NextPart_001_01C45083.724D5A61--

--
to unsubscribe send a message 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, 12 Jun 2004 13:29:02 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: RADIUS V2
Date: Sat, 12 Jun 2004 09:28:28 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C45081.25D0A310
Content-Type: text/plain

Since it seems by the traffic on the list -- if we need a "fresh start"  the
lets do it right folks.
 
I propose that we create RADIUS V2 and that we include the new attribute
proposed by Jari and do some other good things as well.  After all, reading
the list one would get the impression that RADIUS will live a long time.  
 
Like a Phoenix RADIUS seems to have risen from the ashes.  I therefore
propose that we call this version of RADIUS -- RADIUS Phoenix!!!

------_=_NextPart_001_01C45081.25D0A310
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=296101213-12062004></SPAN></FONT><FONT 
face=Arial size=2><SPAN class=296101213-12062004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=296101213-12062004>Since it seems by 
the traffic on the list -- if we need a "fresh start"&nbsp; the lets do it right 
folks.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=296101213-12062004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=296101213-12062004>I propose that we 
create RADIUS V2 and that we include the new attribute proposed by Jari and do 
some other good things as well.&nbsp; After all, reading the list one would get 
the impression that RADIUS will live a long time.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=296101213-12062004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=296101213-12062004>Like&nbsp;a Phoenix 
RADIUS seems to have risen from the ashes.&nbsp;&nbsp;I therefore propose that 
we call this version of RADIUS -- RADIUS Phoenix!!!</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=296101213-12062004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=296101213-12062004></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C45081.25D0A310--

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

Delivery-date: Fri, 11 Jun 2004 14:07:25 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Rationalizing the RADIUS data model
Date: Fri, 11 Jun 2004 10:07:09 -0400

Why John?

Because I don't want to do the work for academic reasons!!!!

And I certainly don't want to do the work in RADIUS.

Frankly I think its nuts!!! On one hand the same people that want to do this
are saying that RADIUS will soon die -- and they are turning around and
suggesting we need guideline documents.

And I want this work to be held to the same standards BTW.  Show me who
wants this done?

Finally, the Vendor issue is not a RADIUS problem its an IETF problem.

Like it or not, regardless of what we think the definition for Vendor is -
the IETF provides external entities a mechanism for extending IETF protocols
and that is and has been the Vendor Specific Attribute.  

This is the defacto standard.  Its not busted.  I havent seen any concrete
evidence that it is.

Avi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, June 10, 2004 11:43 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: Rationalizing the RADIUS data model
> 
> 
> Avi,
> 
> > > Knowing the enforcemant part of the IETF is rather weak, I
> > > don't think you need to worry about this.  If the IETF 
> > > defines a standard content, and insists upon its use for 
> > > standard / interoperable usage, would this be a problem?  
> > >
> > The answer is yes!!!!!
> 
> OK, what problem does this cause?
>  
> > Then what is the point of doing this?  This is going to 
> generate more 
> > heat then light.  It will be a pointless exercise.
> 
> Jari said this already:
> 
> 	.. obviously, the
> 	primary driver for something like this would come from
> 	a longer-term desire to improve and unify the data
> 	models in VSA, SDO, and IETF space. Current drafts on
> 	the IETF stds table do not cause us to run out of attribute
> 	or type space. So the first thing to decide is whether we
> 	want to do something about the "VSA problem", and if
> 	yes, then something like what I proposed would seem
> 	reasonable.
> 
> John
> 

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

Delivery-date: Fri, 11 Jun 2004 04:31:12 +0000
Date: Fri, 11 Jun 2004 07:26:56 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: Rationalizing the RADIUS data model

Hi Avi,

> I strongly agree with this statement.

Yes, so do I and probably most of the folks on
this list. However, if you read the subsequent
e-mails you'll see that we discussed this and
came up with an approach that would make your
and Barney's worry go away (see below). Sorry
for the confusion. Does alt 2 or 3 work for
you?

--Jari

> Finally, lets talk about what to do specification & status wise
> for the old VSA format, should we adopt something like what I
> proposed. I think the options are as follows:
> 
>    1. Make it illegal, i.e., MUST NOT use. Equipment that gets
>       updated would suddenly stop working when someone sends
>       it an old format VSA. We clearly don't want this.
> 
>    2. Keep it as it is, no change in behaviour or status.
> 
>    3. Make the use of the old format a SHOULD NOT for new attributes.
> 
>       Possibly combined with some status change of the old format,
>       maybe "historic".
> 
>    4. Make the use of the old format a MUST NOT for new attributes.
>       This may be too strong as well.
> 
> So, I think we want something along the lines of 2 or 3. Personally,
> I would go for a "SHOULD NOT". 

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

Delivery-date: Fri, 11 Jun 2004 03:44:41 +0000
content-class: urn:content-classes:message
Subject: RE: Rationalizing the RADIUS data model
Date: Fri, 11 Jun 2004 06:43:14 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Avi,

> > Knowing the enforcemant part of the IETF is rather weak, I=20
> > don't think you need to worry about this.  If the IETF=20
> > defines a standard content, and insists upon its use for=20
> > standard / interoperable usage, would this be a problem? =20
> >
> The answer is yes!!!!!

OK, what problem does this cause?
=20
> Then what is the point of doing this?  This is going to generate more =
heat
> then light.  It will be a pointless exercise.=20

Jari said this already:

	.. obviously, the
	primary driver for something like this would come from
	a longer-term desire to improve and unify the data
	models in VSA, SDO, and IETF space. Current drafts on
	the IETF stds table do not cause us to run out of attribute
	or type space. So the first thing to decide is whether we
	want to do something about the "VSA problem", and if
	yes, then something like what I proposed would seem
	reasonable.

John

--
to unsubscribe send a message 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, 10 Jun 2004 22:02:38 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked], [email-masked]
Subject: RE: Rationalizing the RADIUS data model
Date: Thu, 10 Jun 2004 18:02:29 -0400

John,

See inline.

> Barney,  write:
> 
> > I would strongly protest any move to make arbitrarily-formatted 
> > vendor- specific attributes retroactively prohibited.  There is 
> > absolutely no justification for any such move.  If you wish to 
> > contrain future vendor-specific attributes, you MUST define 
> a new Type 
> > code for that and confine the restriction to users of the new code.
> 
John responds:

> Knowing the enforcemant part of the IETF is rather weak, I 
> don't think you need to worry about this.  If the IETF 
> defines a standard content, and insists upon its use for 
> standard / interoperable usage, would this be a problem?  
>
The answer is yes!!!!!

Then what is the point of doing this?  This is going to generate more heat
then light.  It will be a pointless exercise. 

Surely we got better things to do then argue about something that wont  be
used or that is too little too late.

Avi

--
to unsubscribe send a message 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, 10 Jun 2004 21:58:45 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Barney Wolff <[email-masked]>, [email-masked]
Subject: RE: Rationalizing the RADIUS data model
Date: Thu, 10 Jun 2004 17:58:33 -0400

Barney,

See inline.

> Barney Wolff writes...
> 
> > I would strongly protest any move to make arbitrarily-formatted
> vendor-
> > specific attributes retroactively prohibited.  There is 
> absolutely no 
> > justification for any such move.  If you wish to contrain future 
> > vendor-specific attributes, you MUST define a new Type code 
> for that 
> > and confine the restriction to users of the new code.

I strongly agree with this statement.

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

Delivery-date: Thu, 10 Jun 2004 18:12:38 +0000
Date: Thu, 10 Jun 2004 21:08:19 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Object identifier and type spaces in a rationalized RADIUS data model

Jari Arkko wrote:
> Nelson, David wrote:
> 
>> Bernard Aboba writes...
>>
>>
>>> It *might* even obsolete the need for new RADIUS work in some areas --
>>> some existing Diameter applications might be reusable.  That
>>> is a huge win if it is possible.
>>
>>
>>
>> This *is* an attractive concept.  I'm vaguely concerned, however, that
>> we not take this to the next step and attempt to retrofit RADIUS with
>> some|many|all of the features of Diameter.  That used to be an explicit
>> prohibition in an earlier charter draft.  I think that we need to focus
>> on the unified data model issue and the Diameter compatibility issue,
>> without falling into the trap of creating a RADIUS-Plus protocol.
> 
> 
> Agreed. Yes, that danger has occurred to me as well.
> One way to proceed is to think very hard about the
> _scope_ of any extension we make but still ensure
> that whatever we do tries to unify rather than fragment
> the current data models. For instance, in a fear
> of retrofit and complexity, we might adopt the same identifier
> space and some new data types, but not take on all
> data types from Diameter and not extend the attribute
> length. We just need to be careful that while doing
> so, we don't turn "scoping" into "do things differently".

A follow up that I forgot to mention: obviously, the
primary driver for something like this would come from
a longer-term desire to improve and unify the data
models in VSA, SDO, and IETF space. Current drafts on
the IETF stds table do not cause us to run out of attribute
or type space. So the first thing to decide is whether we
want to do something about the "VSA problem", and if
yes, then something like what I proposed would seem
reasonable.

--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: Thu, 10 Jun 2004 16:13:01 +0000
Date: Thu, 10 Jun 2004 12:12:41 -0400
From: Barney Wolff <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Object identifier and type spaces in a rationalized RADIUS data model

On Thu, Jun 10, 2004 at 10:19:23AM -0400, Nelson, David wrote:
> Bernard Aboba writes...
> 
> > It *might* even obsolete the need for new RADIUS work in some areas --
> > some existing Diameter applications might be reusable.  That
> > is a huge win if it is possible.
> 
> This *is* an attractive concept.  I'm vaguely concerned, however, that
> we not take this to the next step and attempt to retrofit RADIUS with
> some|many|all of the features of Diameter.  That used to be an explicit
> prohibition in an earlier charter draft.  I think that we need to focus
> on the unified data model issue and the Diameter compatibility issue,
> without falling into the trap of creating a RADIUS-Plus protocol.

Agreed.  However I think it's useful to think separately about (to use
ASN.1 terms) abstract syntax and transfer syntax when thinking about the
data model.  That is, the same "thing" in client & server storage may look
different when transferred in the value field(s) of RADIUS & Diameter,
without introducing unendurable complexity on a protocol gateway between
them.  Obviously it would be easier, when possible, for the transfer
syntax to be the same, but (to me) it's not a showstopper if not.  One
could take the opposite view, that the protocol gateway MUST NOT need to
alter an attribute's value field in order to do its work.  That's a
decision that ought to be standardized.

Do we have any guidelines on what characteristics of an application would
make it ill-suited to RADIUS, restricting it to Diameter?

Conversely, would any Diameter application proposer ever be willing to limit
its functionality or data model in order to achieve RADIUS compatibility?
Can there be guidelines for this, or should it be separately decided for
each new application?

Barney

--
to unsubscribe send a message 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, 10 Jun 2004 14:31:34 +0000
Date: Thu, 10 Jun 2004 17:27:20 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Object identifier and type spaces in a rationalized RADIUS data model

Nelson, David wrote:
> Bernard Aboba writes...
> 
> 
>>It *might* even obsolete the need for new RADIUS work in some areas --
>>some existing Diameter applications might be reusable.  That
>>is a huge win if it is possible.
> 
> 
> This *is* an attractive concept.  I'm vaguely concerned, however, that
> we not take this to the next step and attempt to retrofit RADIUS with
> some|many|all of the features of Diameter.  That used to be an explicit
> prohibition in an earlier charter draft.  I think that we need to focus
> on the unified data model issue and the Diameter compatibility issue,
> without falling into the trap of creating a RADIUS-Plus protocol.

Agreed. Yes, that danger has occurred to me as well.
One way to proceed is to think very hard about the
_scope_ of any extension we make but still ensure
that whatever we do tries to unify rather than fragment
the current data models. For instance, in a fear
of retrofit and complexity, we might adopt the same identifier
space and some new data types, but not take on all
data types from Diameter and not extend the attribute
length. We just need to be careful that while doing
so, we don't turn "scoping" into "do things differently".

--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: Thu, 10 Jun 2004 14:19:30 +0000
Content-class: urn:content-classes:message
Subject: RE: Object identifier and type spaces in a rationalized RADIUS data model
Date: Thu, 10 Jun 2004 10:19:23 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> It *might* even obsolete the need for new RADIUS work in some areas --
> some existing Diameter applications might be reusable.  That
> is a huge win if it is possible.

This *is* an attractive concept.  I'm vaguely concerned, however, that
we not take this to the next step and attempt to retrofit RADIUS with
some|many|all of the features of Diameter.  That used to be an explicit
prohibition in an earlier charter draft.  I think that we need to focus
on the unified data model issue and the Diameter compatibility issue,
without falling into the trap of creating a RADIUS-Plus protocol.

-- Dave

--
to unsubscribe send a message 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, 10 Jun 2004 14:13:21 +0000
Content-class: urn:content-classes:message
Subject: RE: Object identifier and type spaces in a rationalized RADIUS data model
Date: Thu, 10 Jun 2004 10:11:48 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Jari Arkko writes...

> That was one of my open issues. I think the alternatives are:
>=20
>    1. Limit the attributes to 255 bytes in RADIUS. (Did the
>       charter say something about this limitation?) This
>       is the simplest approach and my current preference.

The charter used to explicitly prohibit extended-length attributes in an
earlier version.  Implementations might rely on the assumption that the
attribute length is no greater than 255 (e.g. copy buffer size) *before*
they get around to parsing the type code.  For that reason, I think it
would be difficult to extend the attribute length and ensure that we
don't break existing implementations.

> As we think about this issue, we should remember that
> RADIUS runs over UDP, and to avoid too many problems
> with fragmentation one shouldn't put too many >255
> byte attributes to the messages in the first place --
> so there are some underlying limitations and relaxing
> the attribute length limit may not help that much.

Right.

-- Dave

--
to unsubscribe send a message 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, 10 Jun 2004 07:03:33 +0000
content-class: urn:content-classes:message
Subject: RE: Object identifier and type spaces in a rationalized RADIUS data model
Date: Thu, 10 Jun 2004 10:03:01 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Jari,

> > I'm not sure that deprecation is possible, given the widespread =
deployment
> > of RADIUS.
>=20
> I probably should not have said "depracate", see the response
> to Barney on the options we have for recommending the new
> format and discouraging the old format for new work. A "SHOULD
> NOT use for new attributes" seems like a better way.

SHOULD NOT is OK with me.

John

--
to unsubscribe send a message 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, 10 Jun 2004 07:00:44 +0000
Date: Thu, 10 Jun 2004 09:55:40 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Object identifier and type spaces in a rationalized RADIUS data model

Bernard Aboba wrote:

> I'm not sure that deprecation is possible, given the widespread deployment
> of RADIUS.

I probably should not have said "depracate", see the response
to Barney on the options we have for recommending the new
format and discouraging the old format for new work. A "SHOULD
NOT use for new attributes" seems like a better way.

--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: Thu, 10 Jun 2004 06:36:03 +0000
Date: Wed, 9 Jun 2004 23:36:57 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked]
Subject: Re: Object identifier and type spaces in a rationalized RADIUS data model

> > defined in Diameter are automatically also defined in RADIUS? Some
> > of those attributes may rely on facilities that are not defined
> > in RADIUS.
>
> I can imagine that there are a few such attributes, as there
> are a few RADIUS attributes that don't get translated into
> Diameter.

One way to handle this is to have an explicit specification that describes
which Diameter AVPs are supported in RADIUS.  That way the behavior will
be well-defined.

> We could do this either way.

I'd suggest that the new attribute space is only usable if the NAS
indicates support for it, so as to address backwards compatibility issues.
So I think that to use the new Vendor-Specific space, you'd need the NAS
to be able to advertise support for vendor-extensions in the new space.
This wouldn't be that hard -- a specific Code could be used for that
purpose, and multiple attributes could be sent, listing the supported
VendorIDs.

> But my thinking was that we need a "fresh start" for both VSAs and
> standard attributes. Defining a new, somewhat more powerful format
> and deprecating the old space would achieve this pretty well. Of
> course, old VSAs would not stop working so no one's products would
> be in danger. But we would send a message to vendors and SDOs
> and ourselves that we have a new format that should be used for
> new work.

I'm not sure that deprecation is possible, given the widespread deployment
of RADIUS.

> > c. How do we deal with differences in attribute length between RADIUS and
> > Diameter?  My assumption is that we would concatenate attributes of the
> > same code and Vendor-ID.  But this might not work correctly for
> > all attributes - some can be present more than once.

I think you may need to handle this on an attribute-by-attribute basis.
Hence the need for a spec describing how each supported Diameter AVP is
handled in RADIUS.

While this is somewhat tedious that advantage of unifying the
AVP/attribute space is that we might save a lot of potential
Diameter/RADIUS compatibility headaches -- and also that we get to
leverage the work already done in RFC 3588.

It *might* even obsolete the need for new RADIUS work in some areas --
some existing Diameter applications might be reusable.  That
is a huge win if it is possible.

> As we think about this issue, we should remember that
> RADIUS runs over UDP, and to avoid too many problems
> with fragmentation one shouldn't put too many >255
> byte attributes to the messages in the first place --
> so there are some underlying limitations and relaxing
> the attribute length limit may not help that much.

I agree.  The next step is probably to think through the implications of
the proposal in more depth.  At this point I would say it appears quite
attractive.

--
to unsubscribe send a message 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, 10 Jun 2004 05:30:45 +0000
Date: Thu, 10 Jun 2004 08:26:34 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Rationalizing the RADIUS data model

Nelson, David wrote:

> I'm really opposed to "string" and "sub-string" based protocols.  RADIUS
> and Diameter are AVP based protocols, and I think it would be a major
> mistake to deviate from this design paradigm.  If sufficiently well
> described, string based protocols can be made interoperable, but it's
> generally much easier to achieve interoperability with AVP based
> protocols.

I think I generally agree that AVP is a better approach. At
the time that I wrote my e-mail that you responded to, I was
still thinking of how to make everything fit within the same
model. It now appears that choosing a new attribute number may
make this unnecessary.

> I would support adopting the "universal" data model for all attributes,
> including VSAs.  However, I suspect that the implementers who have
> enjoyed the vast freedom of "artistic expression" under the current VSA
> rules (basically none) would object.  It would likely make some existing
> VSAa non-compliant. 

I think we can avoid that, by picking a new attribute number.
But we already discussed that in other e-mails.

--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: Thu, 10 Jun 2004 05:27:50 +0000
Date: Thu, 10 Jun 2004 08:23:39 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Object identifier and type spaces in a rationalized RADIUS data model

Hi Bernard,

Your questions are valid. I'll try to answer, even if I'm
not sure I have all the answers. Some of these issues
are likely going to need more discussion.

> a. Since the number spaces are unified, is the IANA allocation
> process defined in RFC 3588 used?  Does this imply that *all* AVPs

I think having the same IANA rules makes sense. I can imagine
that there could be a discussion about what those rules are --
but if they need to be changed then I think the change should
apply to both.

> defined in Diameter are automatically also defined in RADIUS? Some
> of those attributes may rely on facilities that are not defined
> in RADIUS.

I can imagine that there are a few such attributes, as there
are a few RADIUS attributes that don't get translated into
Diameter.

> b. Since this format optionally supports a Vendor-Specific format, does
> this mean that we now have *two* Vendor-Specific Attribute (VSA) spaces
> going forward?  Or do we deprecate one of them (presumably the existing
> RADIUS attribute 26 space) for some uses (say SDO-specific attributes)?

We could do this either way.

But my thinking was that we need a "fresh start" for both VSAs and
standard attributes. Defining a new, somewhat more powerful format
and deprecating the old space would achieve this pretty well. Of
course, old VSAs would not stop working so no one's products would
be in danger. But we would send a message to vendors and SDOs
and ourselves that we have a new format that should be used for
new work.

> c. How do we deal with differences in attribute length between RADIUS and
> Diameter?  My assumption is that we would concatenate attributes of the
> same code and Vendor-ID.  But this might not work correctly for
> all attributes - some can be present more than once.

That was one of my open issues. I think the alternatives are:

   1. Limit the attributes to 255 bytes in RADIUS. (Did the
      charter say something about this limitation?) This
      is the simplest approach and my current preference.

   2. Come up with a concatenation scheme that works.
      As you point out, the simple Code-VID concatenation
      rule does not work. However, it would be possible
      to have a "Full Length" or "Offset" field or a
      "More to Follow" flag in the header. I had a "Full
      Length" field in an early design before I sent the
      proposal. However, I decided that it was too
      complicated.

As we think about this issue, we should remember that
RADIUS runs over UDP, and to avoid too many problems
with fragmentation one shouldn't put too many >255
byte attributes to the messages in the first place --
so there are some underlying limitations and relaxing
the attribute length limit may not help that much.

--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: Thu, 10 Jun 2004 05:24:55 +0000
Date: Thu, 10 Jun 2004 08:20:31 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Barney Wolff <[email-masked]>
Cc: [email-masked]
Subject: Re: Rationalizing the RADIUS data model

Hi Barney,

> I would strongly protest any move to make arbitrarily-formatted vendor-
> specific attributes retroactively prohibited.  There is absolutely no

I agree.

> justification for any such move.  If you wish to contrain future
> vendor-specific attributes, you MUST define a new Type code for that
> and confine the restriction to users of the new code.

Right. This was, more or less, what I proposed.

Let me first say a few words about why I think a new VSA/SDO/Std area
would make sense. Clearly, we have an attribute number and datatype
insufficiency problem, which could be solved this way.

You may then ask, why create yet another VSA space, isn't the current
one already enough? The answer to this is more complicated, but it
has to do with three things:

    o  A well-defined data model is beneficial for everyone.

    o  Making it possible to enforce the new data type & processing rules
       for the area, without making old VSAs illegal or cause
       protocol failures.

    o  Making it possible to easily move vendor- or SDO-originated
       enhancements into the standard space. This may not be obvious,
       people could argue that as a part of such move you can make
       modifications. But, as we have seen, such modifications are
       often painful, and this would continue to hurt standardization
       in the field.

Finally, lets talk about what to do specification & status wise
for the old VSA format, should we adopt something like what I
proposed. I think the options are as follows:

    1. Make it illegal, i.e., MUST NOT use. Equipment that gets
       updated would suddenly stop working when someone sends
       it an old format VSA. We clearly don't want this.

    2. Keep it as it is, no change in behaviour or status.

    3. Make the use of the old format a SHOULD NOT for new attributes.

       Possibly combined with some status change of the old format,
       maybe "historic".

    4. Make the use of the old format a MUST NOT for new attributes.
       This may be too strong as well.

So, I think we want something along the lines of 2 or 3. Personally,
I would go for a "SHOULD NOT".

--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: Thu, 10 Jun 2004 01:51:08 +0000
Date: Wed, 9 Jun 2004 16:22:01 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Barney Wolff <[email-masked]>
cc: [email-masked]
Subject: Re: Rationalizing the RADIUS data model

> I would strongly protest any move to make arbitrarily-formatted vendor-
> specific attributes retroactively prohibited.

I thought the problem was with *standardizing* arbitrarily formatted
vendor-specific attributes, not with allowing them to continue to exist.

> If you wish to constrain future
> vendor-specific attributes, you MUST define a new Type code for that
> and confine the restriction to users of the new code.

Personally, I'm not clear about the benefits of defining yet another
vendor-specific attribute space.  I do see the benefits of expanding the
capabilities of the standard space -- though I suppose that leaving the
vendor specific space alone might make it difficult to ensure that the
capabilities of the two spaces were identical.  But it might be a
situation in which we strive for "good enough" along that dimension, as
well as Diameter compatibility, and call it a day.

> The suggested VSA content format has never been more than a SHOULD.
> Are you really proposing to make it retroactively a MUST?

That seems unnecessary, to these eyes anyway.

--
to unsubscribe send 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, 09 Jun 2004 23:21:11 +0000
Date: Wed, 9 Jun 2004 16:22:01 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Barney Wolff <[email-masked]>
cc: [email-masked]
Subject: Re: Rationalizing the RADIUS data model

> I would strongly protest any move to make arbitrarily-formatted vendor-
> specific attributes retroactively prohibited.

I thought the problem was with *standardizing* arbitrarily formatted
vendor-specific attributes, not with allowing them to continue to exist.

> If you wish to constrain future
> vendor-specific attributes, you MUST define a new Type code for that
> and confine the restriction to users of the new code.

Personally, I'm not clear about the benefits of defining yet another
vendor-specific attribute space.  I do see the benefits of expanding the
capabilities of the standard space -- though I suppose that leaving the
vendor specific space alone might make it difficult to ensure that the
capabilities of the two spaces were identical.  But it might be a
situation in which we strive for "good enough" along that dimension, as
well as Diameter compatibility, and call it a day.

> The suggested VSA content format has never been more than a SHOULD.
> Are you really proposing to make it retroactively a MUST?

That seems unnecessary, to these eyes anyway.

--
to unsubscribe send a message 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, 09 Jun 2004 22:19:45 +0000
Date: Wed, 9 Jun 2004 18:19:29 -0400
From: Barney Wolff <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Rationalizing the RADIUS data model

On Wed, Jun 09, 2004 at 10:52:58PM +0300, [email-masked] wrote:
> 
> > I would strongly protest any move to make arbitrarily-formatted vendor-
> > specific attributes retroactively prohibited.  There is absolutely no
> > justification for any such move.  If you wish to contrain future
> > vendor-specific attributes, you MUST define a new Type code for that
> > and confine the restriction to users of the new code.
> 
> Knowing the enforcemant part of the IETF is rather weak, I don't
> think you need to worry about this.  If the IETF defines a standard
> content, and insists upon its use for standard / interoperable usage,
> would this be a problem?  

I have no problem with this if T!=26.

> > As for "extended RADIUS in 'non-interoperable' ways" the RFCs have
> > always said that a robust implementation SHOULD support the content
> > of a VSA as undistinguished octets.
> > 
> > The suggested VSA content format has never been more than a SHOULD.
> > Are you really proposing to make it retroactively a MUST?
> 
> I don't have a problem for making it a MUST for standard, interoperable
> usage.  For non-standard usage, arbatrary format could still be used, IMO.

The problem is exactly interoperability.  A RADIUS peer receiving a VSA
with unknown OID today has no choice but to ignore it or treat it as
undistinguished octets.  What it then decides to do is a matter of policy.
If we now decide that attributes with T=26 MUST be parsable as subattrs,
a new implementation talking to an old implementation may complain of
an invalidly formatted attribute and likely reject.  That's not good.

There's also the branding issue:  What does it mean to say on the outside
of the box "supports RADIUS"?  We don't have version numbers in
this protocol, do we?  I'm worried about finger-pointing, when one
vendor claims that another is sending invalid attribute formats.

One more issue:  What is a vendor to do who sends arbitrary VSA format
today but wants to be a good citizen and comply with the new standard?
How would the peer of such a vendor be able to tell a new-format VSA26
from an old one?  Would you make everybody go get new OIDs?

In hindsight, we should have bitten the bullet years ago and migrated to
ASN.1 - if not for RADIUS, at least for Diameter.  Yes, it is much too
late, but we're going to regret it for a long time.

Regards,
Barney

--
to unsubscribe send a message 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, 09 Jun 2004 21:25:46 +0000
Date: Wed, 9 Jun 2004 17:25:28 -0400
From: Barney Wolff <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Rationalizing the RADIUS data model

On Wed, Jun 09, 2004 at 03:39:26PM -0400, Nelson, David wrote:
> Barney Wolff writes...
>  <rant>
> 
> > The suggested VSA content format has never been more than a SHOULD.
> > Are you really proposing to make it retroactively a MUST?
> 
> I was observing that a single, rationalized, "universal" data model for
> all attributes, including VSAs, would have that effect (or some similar
> effect).  We could retain the traditional (free-format) VSAs and
> introduce a new type code for unified data model VSAs.  But that still
> begs the question of when to use the traditional VSA or the rationalized
> data model VSA?

I would have no problem with a statement discouraging the old free-form
attribute for new work, at the level of SHOULD NOT.  It was the concept
of retroactively invalidating existing implementations that combined
with a very hot day and broken AC to produce the rant.

Regards,
Barney

--
to unsubscribe send a message 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, 09 Jun 2004 19:54:33 +0000
content-class: urn:content-classes:message
Subject: RE: Rationalizing the RADIUS data model
Date: Wed, 9 Jun 2004 22:52:58 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Barney,

> I would strongly protest any move to make arbitrarily-formatted =
vendor-
> specific attributes retroactively prohibited.  There is absolutely no
> justification for any such move.  If you wish to contrain future
> vendor-specific attributes, you MUST define a new Type code for that
> and confine the restriction to users of the new code.

Knowing the enforcemant part of the IETF is rather weak, I don't
think you need to worry about this.  If the IETF defines a standard
content, and insists upon its use for standard / interoperable usage,
would this be a problem? =20
=20
> As for "extended RADIUS in 'non-interoperable' ways" the RFCs have
> always said that a robust implementation SHOULD support the content
> of a VSA as undistinguished octets.
>=20
> The suggested VSA content format has never been more than a SHOULD.
> Are you really proposing to make it retroactively a MUST?

I don't have a problem for making it a MUST for standard, interoperable
usage.  For non-standard usage, arbatrary format could still be used, =
IMO.

John

--
to unsubscribe send a message 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, 09 Jun 2004 19:39:56 +0000
Content-class: urn:content-classes:message
Subject: RE: Rationalizing the RADIUS data model
Date: Wed, 9 Jun 2004 15:39:26 -0400
From: "Nelson, David" <[email-masked]>
To: "Barney Wolff" <[email-masked]>, <[email-masked]>

Barney Wolff writes...

> I would strongly protest any move to make arbitrarily-formatted
vendor-
> specific attributes retroactively prohibited.  There is absolutely no
> justification for any such move.  If you wish to contrain future
> vendor-specific attributes, you MUST define a new Type code for that
> and confine the restriction to users of the new code.
>=20
> As for "extended RADIUS in 'non-interoperable' ways" the RFCs have
> always said that a robust implementation SHOULD support the content
> of a VSA as undistinguished octets.
>=20
> The suggested VSA content format has never been more than a SHOULD.
> Are you really proposing to make it retroactively a MUST?

I was observing that a single, rationalized, "universal" data model for
all attributes, including VSAs, would have that effect (or some similar
effect).  We could retain the traditional (free-format) VSAs and
introduce a new type code for unified data model VSAs.  But that still
begs the question of when to use the traditional VSA or the rationalized
data model VSA?

-- Dave

--
to unsubscribe send a message 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, 09 Jun 2004 18:37:19 +0000
Date: Wed, 9 Jun 2004 14:37:09 -0400
From: Barney Wolff <[email-masked]>
To: [email-masked]
Subject: Re: Rationalizing the RADIUS data model

On Wed, Jun 09, 2004 at 08:57:12PM +0300, [email-masked] wrote:
> 
> I also support having a universal, standard model for attributes.  If 
> folks have extended RADIUS in 'non-interoperable' ways, then it is their
> 'bad-luck' to have done so; I don't have a problem if these VSAs were
> made non-compliant, because they really are not complying to anything
> right now.

I would strongly protest any move to make arbitrarily-formatted vendor-
specific attributes retroactively prohibited.  There is absolutely no
justification for any such move.  If you wish to contrain future
vendor-specific attributes, you MUST define a new Type code for that
and confine the restriction to users of the new code.

As for "extended RADIUS in 'non-interoperable' ways" the RFCs have
always said that a robust implementation SHOULD support the content
of a VSA as undistinguished octets.

The suggested VSA content format has never been more than a SHOULD.
Are you really proposing to make it retroactively a MUST?

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

--
to unsubscribe send a message 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, 09 Jun 2004 17:57:54 +0000
content-class: urn:content-classes:message
Subject: RE: Rationalizing the RADIUS data model
Date: Wed, 9 Jun 2004 20:57:12 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

David,

> I would support adopting the "universal" data model for all =
attributes,
> including VSAs.  However, I suspect that the implementers who have
> enjoyed the vast freedom of "artistic expression" under the current =
VSA
> rules (basically none) would object.  It would likely make some =
existing
> VSAa non-compliant.=20

I also support having a universal, standard model for attributes.  If=20
folks have extended RADIUS in 'non-interoperable' ways, then it is their
'bad-luck' to have done so; I don't have a problem if these VSAs were
made non-compliant, because they really are not complying to anything
right now.

John

--
to unsubscribe send a message 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, 09 Jun 2004 15:17:41 +0000
Date: Wed, 9 Jun 2004 08:18:48 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Object identifier and type spaces in a rationalized RADIUS data model

> > Quick question - have you looked at the backwards compatibility-ness
> > of this proposal?  If new implementations support it its important
> > that they don't break older implementations.

One way to handle this is for a NAS supporting the new attributes to send
an attribute in the new format indicating support for the new format. The
RADIUS server would then be able to send those attributes -- but if it
didn't receive the "compatibility" attribute it would be advised not to
send 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: Wed, 09 Jun 2004 15:15:43 +0000
Date: Wed, 9 Jun 2004 08:16:39 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked]
Subject: Re: Object identifier and type spaces in a rationalized RADIUS data model

> I have a concrete suggestion.

This proposal would appear to guarantee compatibility with Diameter, by
unifying the attribute number space as well as data types and to some
extent, attribute format.

Some questions:

a. Since the number spaces are unified, is the IANA allocation
process defined in RFC 3588 used?  Does this imply that *all* AVPs
defined in Diameter are automatically also defined in RADIUS? Some
of those attributes may rely on facilities that are not defined
in RADIUS.

b. Since this format optionally supports a Vendor-Specific format, does
this mean that we now have *two* Vendor-Specific Attribute (VSA) spaces
going forward?  Or do we deprecate one of them (presumably the existing
RADIUS attribute 26 space) for some uses (say SDO-specific attributes)?

c. How do we deal with differences in attribute length between RADIUS and
Diameter?  My assumption is that we would concatenate attributes of the
same code and Vendor-ID.  But this might not work correctly for
all attributes - some can be present more than once.

--
to unsubscribe send a message 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, 09 Jun 2004 13:49:09 +0000
Content-class: urn:content-classes:message
Subject: RE: Rationalizing the RADIUS data model
Date: Wed, 9 Jun 2004 09:47:57 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Jari Arkko writes...

> But let's talk about the specifics. What, exactly, is the
> current problem?

The current problem is that the RFC 2865 "SHOULD" rules for VSA format
are not universally followed, and even when they are followed, they
don't match the rules for standard attributes.  There is currently
nothing prohibiting a VSA from containing *anything* that will fit
within the approximately 250 available data payload octets of a VSA.
This has been repeatedly pointed out by various implementers who have
taken advantage of this "artistic license".

> Clearly, we have been impacted by the
> small attribute space. This can be solved.

Assuming that RADIUS has a sufficient useful lifetime remaining that the
current standard attribute space is consumed, then, yes, this can be
relatively easily solved.

> Structured data within an octet string, subfields in text
> strings, subattributes? There's probably more to discuss
> there.

Yes, indeed.

> I would rather not have structured
> data as "records", but subattributes might be doable,
> particularly if they could be mapped to grouped AVPs
> in Diameter.=20

That sounds like a potential avenue to explore.

> The rest could then be labeled as an
> octet string; is there a reason why this type of a
> model could not be adopted as _the_ model, for all
> attributes?

I'm really opposed to "string" and "sub-string" based protocols.  RADIUS
and Diameter are AVP based protocols, and I think it would be a major
mistake to deviate from this design paradigm.  If sufficiently well
described, string based protocols can be made interoperable, but it's
generally much easier to achieve interoperability with AVP based
protocols.

I would support adopting the "universal" data model for all attributes,
including VSAs.  However, I suspect that the implementers who have
enjoyed the vast freedom of "artistic expression" under the current VSA
rules (basically none) would object.  It would likely make some existing
VSAa non-compliant.=20

-- Dave

--
to unsubscribe send a message 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, 09 Jun 2004 10:26:54 +0000
Date: Wed, 09 Jun 2004 13:22:39 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: [email-masked]
Subject: Re: Object identifier and type spaces in a rationalized RADIUS data model

[email-masked] wrote:
> Jari,
> 
> Quick question - have you looked at the backwards compatibility-ness
> of this proposal?  If new implementations support it its important
> that they don't break older implementations.

Good question. Lets see: from the point of view of
nodes that do not support this proposed new attribute,
this looks like yet another unknown attribute. It
would be passed on by proxies, ignored by receivers.
I think it would be echoed back from Access-Accept
to Accounting-Requests, and dumped as hex in accounting
records. Nodes that want to send an attribute in
this new format should be able to do that, assuming
they can be configured with a new dictionary entry
and allow a binary string as a configured value for
the attribute.

Nodes that actually want *do* something with this
new attribute would need new code. Say, if a new
attribute were defined on top of this and it would
control IP address assignment, a NAS would need
new code but probably the home AAA server could
generate this based on a dictionary and a fixed
value given to it in a configuration file.

--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, 09 Jun 2004 10:14:32 +0000
content-class: urn:content-classes:message
Subject: RE: Object identifier and type spaces in a rationalized RADIUS data model
Date: Wed, 9 Jun 2004 13:13:44 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Jari,

Quick question - have you looked at the backwards compatibility-ness
of this proposal?  If new implementations support it its important
that they don't break older implementations.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Jari Arkko
> Sent: 09 June, 2004 12:14
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Object identifier and type spaces in a rationalized=20
> RADIUS data
> model
>=20
>=20
>=20
> I have a concrete suggestion.
>=20
> One of the problems in the current data model(s)
> is that we have technically and administratively
> different identifier spaces and data types for the
> various objects (attributes) in the AAA protocols and
> their extensions. While its desirable to provide
> a different set of administrative rules to allocate
> local and standard extensions, it is not desirable
> to fragment the spaces so that different specifications
> are needed to document the formats of these extensions.
> It is also not desirable to have more than one space
> for new standard attributes at the IETF, because
> this would create a need for translation.
>=20
> With this in mind, the following proposal defines
> a new IETF extended RADIUS attribute that provides
> extended data types, supports vendor, SDO, and IETF
> attributes and avoids different spaces for RADIUS
> and Diameter. This has obvious advantages going forward,
> but it also eliminates the need for a few attributes
> from the currently proposed filter extensions, as
> existing specifications could be used as is.
>=20
> The format supports a variety of data types, including
> IPv6 addresses, floating point numbers, and subattributes.
>=20
> Here it is:
>=20
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Type      |  Length       |            Code
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>             Code (cont)             |V M r r r r r r| Vendor-ID (opt)
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>              Vendor-ID (opt, cont)                  | Data ...
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>     Type
>=20
>        <To Be Allocated By IANA> for IETF Extended
>=20
>     Length
>=20
>        >=3D 7
>=20
>     Code
>=20
>        This field identifies the attribute. Only values greater than
>        or equal to 256 are allowed. Current values are defined in
>        [RFC 3588], and if V =3D 0, new ones may be allocated following
>        Designated Expert with Specification Required [IANA].
>        Release of blocks of AVPs (more than 3 at a time
>        for a given purpose) should require IETF Consensus. If V !=3D =
0,
>        the indicated vendor is responsible for managing the=20
> allocations.
>=20
>     Vendor-ID
>=20
>        The high-order octet is 0 and the low-order 3 octets=20
> are the SMI
>        Network Management Private Enterprise Code of the Vendor in
>        network byte order.
>=20
>     M
>=20
>        The 'M' Bit, known as the Mandatory bit, indicates=20
> whether support
>        of the attribute is required.  If an attribute with=20
> the 'M' bit set is
>        received by a client, server, proxy, or translation agent
>        and either the attribute or its value is unrecognized,=20
> the message MUST
>        be rejected.  Relay and redirect agents MUST NOT reject
>        messages with unrecognized attributes.
>=20
>        The 'M' bit MUST be set according to the rules defined=20
> for the attribute
>        containing it.  In order to preserve interoperability, an
>        implementation MUST be able to exclude from a message any
>        Mandatory attribute which is not defined for the specific
>        standard that this node claims conformance to.  It MAY=20
> do this in one
>        of the following ways:
>=20
>        1) If a message is rejected because it contains a Mandatory AVP
>           which is not defined in the relevant standard, the=20
> implementation
>           may resend the message without the attribute,=20
> possibly inserting
>           additional standard attributes instead.
>=20
>        2) A configuration option may be provided on a system wide, per
>           peer, or per realm basis that would allow/prevent particular
>           Mandatory attributes to be sent.  Thus an=20
> administrator could change
>           the configuration to avoid interoperability problems.
>=20
>        Implementations are required to support all Mandatory
>        attributes which are defined in the relevant standard.
>=20
>        Attributes with the 'M' bit cleared are informational=20
> only and a
>        receiver that receives a message with such an=20
> attribute that is not
>        supported, or whose value is not supported, MAY simply=20
> ignore the
>        attribute.
>=20
>     V
>=20
>        The 'V' bit, known as the Vendor-Specific bit,=20
> indicates whether
>        the optional Vendor-ID field is present in the header.  When
>        set the Code belongs to the specific vendor code address
>        space.
>=20
>     r
>=20
>        The 'r' (reserved) bits are unused and SHOULD be set
>        to 0.  Note that subsequent specifications MAY define
>        additional bits within the header, and an unrecognized bit
>        SHOULD be considered an error.
>=20
>     Data
>=20
>        The Data field is zero or more octets and contains
>        information specific to the atribute.  The format
>        and length of the Data field is determined by the
>        Code and Length fields.  The format of the Data field
>        MUST be one of the following base data types or a data
>        type derived from the base data types.  In the event
>        that a new base format is needed, a new version of
>        this RFC must be created.
>=20
>        string
>=20
>          The data contains arbitrary data of variable length.
>          See [RFC 2865].
>=20
>        integer
>=20
>          32 bit unsigned value, in network byte order. See [RFC 2865].
>=20
>        integer64
>=20
>          64 bit signed value, in network byte order.  See [RFC 3588].
>=20
>        signed32
>=20
>          32 bit signed value, in network byte order. See [RFC 3588].
>=20
>        signed64
>=20
>          64 bit signed value, in network byte order.  See [RFC 3588].
>=20
>        float32
>=20
>          This represents floating point values of single precision as
>          described by [FLOATPOINT].  The 32-bit value is=20
> transmitted in
>          network byte order. See [RFC 3588].
>=20
>        float64
>=20
>          This represents floating point values of double precision as
>          described by [FLOATPOINT].  The 64-bit value is=20
> transmitted in
>          network byte order. See [RFC 3588].
>=20
>        grouped
>=20
>          The Data field is specified as a sequence of attributes.
>          Each of these attributess follows - in the order in which
>          they are specified - including their headers.
>=20
>        generic address
>=20
>          This format is derived from the string base format. It
>          is a discriminated union, representing, for example a
>          32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most
>          significant octet first.  The first two octets of the Address
>          attribute represents the AddressType, which contains=20
> an Address Family
>          defined in [IANAADFAM].  The AddressType is used to=20
> discriminate
>          the content and format of the remaining octets. See=20
> [RFC 3588].
>=20
>        generic time
>=20
>          This format is derived from the string base format.
>          The string MUST contain four octets, in the same=20
> format as the
>          first four bytes are in the NTP timestamp format.  The NTP
>          Timestamp format is defined in chapter 3 of [SNTP].
>=20
>          This represents the number of seconds since 0h on 1=20
> January 1900
>          with respect to the Coordinated Universal Time (UTC).
>=20
>          On 6h 28m 16s UTC, 7 February 2036 the time value=20
> will overflow.
>          SNTP [SNTP] describes a procedure to extend the time to 2104.
>          This procedure MUST be supported by all nodes.
>=20
>        text
>=20
>          This format is derived from the string base format.
>          This is a human readable string represented using the
>          ISO/IEC IS 10646-1 character set, encoded as an=20
> OctetString using
>          the UTF-8 [UFT8] transformation format described in RFC 2279.
>          See [RFC 2865] and [RFC 3588].
>=20
>        enumerated
>=20
>          Enumerated is derived from the integer base format. The
>          definition contains a list of valid values and their
>          interpretation and is described in the specification
>          introducing the attribute.
>=20
>        ipfilterrule
>=20
>          This format is derived from the string base
>          format.  It uses the ASCII charset.  See [RFC 3588].
>=20
> (Open issues: inclusion of Diameter Identity data type, and
> the support for >255 long attributes. Either one is doable,
> though.)
>=20
> --Jari
>=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, 09 Jun 2004 09:18:21 +0000
Date: Wed, 09 Jun 2004 12:14:03 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Object identifier and type spaces in a rationalized RADIUS data model

I have a concrete suggestion.

One of the problems in the current data model(s)
is that we have technically and administratively
different identifier spaces and data types for the
various objects (attributes) in the AAA protocols and
their extensions. While its desirable to provide
a different set of administrative rules to allocate
local and standard extensions, it is not desirable
to fragment the spaces so that different specifications
are needed to document the formats of these extensions.
It is also not desirable to have more than one space
for new standard attributes at the IETF, because
this would create a need for translation.

With this in mind, the following proposal defines
a new IETF extended RADIUS attribute that provides
extended data types, supports vendor, SDO, and IETF
attributes and avoids different spaces for RADIUS
and Diameter. This has obvious advantages going forward,
but it also eliminates the need for a few attributes
from the currently proposed filter extensions, as
existing specifications could be used as is.

The format supports a variety of data types, including
IPv6 addresses, floating point numbers, and subattributes.

Here it is:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |  Length       |            Code
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Code (cont)             |V M r r r r r r| Vendor-ID (opt)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Vendor-ID (opt, cont)                  | Data ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

       <To Be Allocated By IANA> for IETF Extended

    Length

       >= 7

    Code

       This field identifies the attribute. Only values greater than
       or equal to 256 are allowed. Current values are defined in
       [RFC 3588], and if V = 0, new ones may be allocated following
       Designated Expert with Specification Required [IANA].
       Release of blocks of AVPs (more than 3 at a time
       for a given purpose) should require IETF Consensus. If V != 0,
       the indicated vendor is responsible for managing the allocations.

    Vendor-ID

       The high-order octet is 0 and the low-order 3 octets are the SMI
       Network Management Private Enterprise Code of the Vendor in
       network byte order.

    M

       The 'M' Bit, known as the Mandatory bit, indicates whether support
       of the attribute is required.  If an attribute with the 'M' bit set is
       received by a client, server, proxy, or translation agent
       and either the attribute or its value is unrecognized, the message MUST
       be rejected.  Relay and redirect agents MUST NOT reject
       messages with unrecognized attributes.

       The 'M' bit MUST be set according to the rules defined for the attribute
       containing it.  In order to preserve interoperability, an
       implementation MUST be able to exclude from a message any
       Mandatory attribute which is not defined for the specific
       standard that this node claims conformance to.  It MAY do this in one
       of the following ways:

       1) If a message is rejected because it contains a Mandatory AVP
          which is not defined in the relevant standard, the implementation
          may resend the message without the attribute, possibly inserting
          additional standard attributes instead.

       2) A configuration option may be provided on a system wide, per
          peer, or per realm basis that would allow/prevent particular
          Mandatory attributes to be sent.  Thus an administrator could change
          the configuration to avoid interoperability problems.

       Implementations are required to support all Mandatory
       attributes which are defined in the relevant standard.

       Attributes with the 'M' bit cleared are informational only and a
       receiver that receives a message with such an attribute that is not
       supported, or whose value is not supported, MAY simply ignore the
       attribute.

    V

       The 'V' bit, known as the Vendor-Specific bit, indicates whether
       the optional Vendor-ID field is present in the header.  When
       set the Code belongs to the specific vendor code address
       space.

    r

       The 'r' (reserved) bits are unused and SHOULD be set
       to 0.  Note that subsequent specifications MAY define
       additional bits within the header, and an unrecognized bit
       SHOULD be considered an error.

    Data

       The Data field is zero or more octets and contains
       information specific to the atribute.  The format
       and length of the Data field is determined by the
       Code and Length fields.  The format of the Data field
       MUST be one of the following base data types or a data
       type derived from the base data types.  In the event
       that a new base format is needed, a new version of
       this RFC must be created.

       string

         The data contains arbitrary data of variable length.
         See [RFC 2865].

       integer

         32 bit unsigned value, in network byte order. See [RFC 2865].

       integer64

         64 bit signed value, in network byte order.  See [RFC 3588].

       signed32

         32 bit signed value, in network byte order. See [RFC 3588].

       signed64

         64 bit signed value, in network byte order.  See [RFC 3588].

       float32

         This represents floating point values of single precision as
         described by [FLOATPOINT].  The 32-bit value is transmitted in
         network byte order. See [RFC 3588].

       float64

         This represents floating point values of double precision as
         described by [FLOATPOINT].  The 64-bit value is transmitted in
         network byte order. See [RFC 3588].

       grouped

         The Data field is specified as a sequence of attributes.
         Each of these attributess follows - in the order in which
         they are specified - including their headers.

       generic address

         This format is derived from the string base format. It
         is a discriminated union, representing, for example a
         32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most
         significant octet first.  The first two octets of the Address
         attribute represents the AddressType, which contains an Address Family
         defined in [IANAADFAM].  The AddressType is used to discriminate
         the content and format of the remaining octets. See [RFC 3588].

       generic time

         This format is derived from the string base format.
         The string MUST contain four octets, in the same format as the
         first four bytes are in the NTP timestamp format.  The NTP
         Timestamp format is defined in chapter 3 of [SNTP].

         This represents the number of seconds since 0h on 1 January 1900
         with respect to the Coordinated Universal Time (UTC).

         On 6h 28m 16s UTC, 7 February 2036 the time value will overflow.
         SNTP [SNTP] describes a procedure to extend the time to 2104.
         This procedure MUST be supported by all nodes.

       text

         This format is derived from the string base format.
         This is a human readable string represented using the
         ISO/IEC IS 10646-1 character set, encoded as an OctetString using
         the UTF-8 [UFT8] transformation format described in RFC 2279.
         See [RFC 2865] and [RFC 3588].

       enumerated

         Enumerated is derived from the integer base format. The
         definition contains a list of valid values and their
         interpretation and is described in the specification
         introducing the attribute.

       ipfilterrule

         This format is derived from the string base
         format.  It uses the ASCII charset.  See [RFC 3588].

(Open issues: inclusion of Diameter Identity data type, and
the support for >255 long attributes. Either one is doable,
though.)

--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, 09 Jun 2004 07:48:38 +0000
Date: Wed, 09 Jun 2004 10:44:09 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Rationalizing the RADIUS data model

Nelson, David wrote:

> That is the $64,000 question.  In rationalizing the data models, one
> assumes we mean that the same data models will be usable for VSA, SSA,
> and potentially IETF-Extended-Attributes (IEA??).  Whether the set of
> "universal" data format rules (the rationalized data model) is as
> loosely defined, and as subject to liberal interpretation by
> implementers, as the current rules for VSAs will be the crux of the
> discussion on this subject, I rather suspect.

Yes.

> One possible approach is the definition of a unified data model that is
> more flexible than the current standard data types defined in RFC 2865,
> but less flexible than the current VSA rules.  VSAs could still use the
> original, loose VSA data model, but if there is an expectation that a
> VSA might be promoted to an SSA or standard attribute, the developer
> would be constrained to use the new universal data model.

I may not have anything better to suggest, but I would
note that there are still two problems with the above:

o  People's predictions of the fate of their small
    extensions are often bad; a lot of stuff that got
    developed as a private extension is still with us
    today.

o  Long-term, a model where the vendor-specific mechanisms
    are "better" (at least in perception or ease) than
    standard mechanisms does not encourage standardization.
    This could lead to important extensions defined by
    dominant vendors and industry consortiums.

But lets talk about the specifics. What, exactly, is the
current problem? Clearly, we have been impacted by the
small attribute space. This can be solved. What else?
Limited set of basic data types, lack of IPv6 address
for instance. This can be solved too, and I think we
can find consensus on these issues.

Structured data within an octet string, subfields in text
strings, subattributes? There's probably more to discuss
there. Personally, I think text strings will always have
some form of subfields. I would rather not have structured
data as "records", but subattributes might be doable,
particularly if they could be mapped to grouped AVPs
in Diameter. The rest could then be labeled as an
octet string; is there a reason why this type of a
model could not be adopted as _the_ model, for all
attributes?

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

Envelope-to: [email-masked]
Delivery-date: Tue, 08 Jun 2004 15:03:34 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Rationalizing the RADIUS data model 
Date: Tue, 08 Jun 2004 11:09:34 -0400
Message-Id: <[email-masked]>

[email-masked] wrote:
> But is that all, or should we also be worried about
> code changes (not just attribute number changes in
> a dictionary) when moving between the vendor, SDO,
> and extended IETF attribute space.

  Code changes aren't the problem.  The software which knows about new
features can be updated to handle "vendor-id == 0".

  I'm more concerned about legacy software.  Some people have old
servers which proxy requests to new servers.  With a vendor-id of
zero, the old servers may not be able to proxy the requests.  With a
non-zero vendor id, the older servers will be able to proxy the
requests.

  This is a daily concern for some people I work with.  Deployment of
*any* new feature has to be done in a way which doesn't break old
systems, which they can't/won't upgrade.

  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, 08 Jun 2004 15:01:11 +0000
Content-class: urn:content-classes:message
Subject: RE: Rationalizing the RADIUS data model
Date: Tue, 8 Jun 2004 11:00:29 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Jari Arkko writes...

> But is that all, or should we also be worried about
> code changes (not just attribute number changes in
> a dictionary) when moving between the vendor, SDO,
> and extended IETF attribute space. Seems like it would
> be good that a transition from one space to other
> does not mean a radical change in the kind of data
> types one can use, for instance.

That is the $64,000 question.  In rationalizing the data models, one
assumes we mean that the same data models will be usable for VSA, SSA,
and potentially IETF-Extended-Attributes (IEA??).  Whether the set of
"universal" data format rules (the rationalized data model) is as
loosely defined, and as subject to liberal interpretation by
implementers, as the current rules for VSAs will be the crux of the
discussion on this subject, I rather suspect.

One possible approach is the definition of a unified data model that is
more flexible than the current standard data types defined in RFC 2865,
but less flexible than the current VSA rules.  VSAs could still use the
original, loose VSA data model, but if there is an expectation that a
VSA might be promoted to an SSA or standard attribute, the developer
would be constrained to use the new universal data model.

-- Dave

--
to unsubscribe send a message 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, 08 Jun 2004 14:47:16 +0000
Date: Tue, 08 Jun 2004 17:42:50 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Alan DeKok <[email-masked]>
Cc: [email-masked]
Subject: Re: Rationalizing the RADIUS data model

Alan DeKok wrote:

>   My concern is not that, but implementations which assume that
> "vendor-id == 0", means an invalid packet.  There's a reason that the
> attribute Id of "0" wasn't assigned.  We probably shouldn't assign a
> vendor Id of zero, either.

Yes, I see that this could happen. I agree
that a non-zero IETF vendor ID could solve this
problem.

But is that all, or should we also be worried about
code changes (not just attribute number changes in
a dictionary) when moving between the vendor, SDO,
and extended IETF attribute space. Seems like it would
be good that a transition from one space to other
does not mean a radical change in the kind of data
types one can use, for instance.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 08 Jun 2004 14:18:25 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Rationalizing the RADIUS data model 
Date: Tue, 08 Jun 2004 10:24:26 -0400
Message-Id: <[email-masked]>

Barney Wolff <[email-masked]> wrote:
> > I think that was the question.  Are vendors using vendorID=0 already for
> > some purpose?
> 
> Perhaps not, but I wonder if there are examples of tests for nonzero
> indicating the existence of a vendor-id.

  My concern is not that, but implementations which assume that
"vendor-id == 0", means an invalid packet.  There's a reason that the
attribute Id of "0" wasn't assigned.  We probably shouldn't assign a
vendor Id of zero, either.

>  In that sense, id==0 is special, and perhaps the solution would be
> cleaner if an id were allocated to the IETF.  What could it hurt?

  It wouldn't hurt.  I know in implementations I've worked with,
checks which assume "0 == invalid" have caught programming errors.

  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, 08 Jun 2004 14:08:14 +0000
Date: Tue, 8 Jun 2004 10:07:52 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: Jari Arkko <[email-masked]>, [email-masked]
Subject: Re: Rationalizing the RADIUS data model

On Tue, Jun 08, 2004 at 06:49:20AM -0700, Bernard Aboba wrote:
> > So, just for my clarification: what are the "potential
> > backward compatibility issues" with a)? I think we don't
> > have vendor=0 attributes yet, or do we? If we don't have
> > them, it appears that the IETF can define the contents
> > of the extended attribute as we please, no?
> 
> I think that was the question.  Are vendors using vendorID=0 already for
> some purpose?

Perhaps not, but I wonder if there are examples of tests for nonzero
indicating the existence of a vendor-id.  In that sense, id==0 is
special, and perhaps the solution would be cleaner if an id were
allocated to the IETF.  What could it hurt?
Barney

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

--
to unsubscribe send a message 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, 08 Jun 2004 13:48:16 +0000
Date: Tue, 8 Jun 2004 06:49:20 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked]
Subject: Re: Rationalizing the RADIUS data model

> So, just for my clarification: what are the "potential
> backward compatibility issues" with a)? I think we don't
> have vendor=0 attributes yet, or do we? If we don't have
> them, it appears that the IETF can define the contents
> of the extended attribute as we please, no?

I think that was the question.  Are vendors using vendorID=0 already for
some purpose?

--
to unsubscribe send a message 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, 08 Jun 2004 13:09:42 +0000
Date: Tue, 08 Jun 2004 16:05:30 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Rationalizing the RADIUS data model

Hi Bernard,

I have a question about your old-mail... I'm not
sure if this was already discussed.

> a.  Using a Vendor-Id of zero (0) within the existing VSA attribute 26,
>     in order to define an extended IETF standard attribute space that
>     would mirror the VSA data model, including support for sub-attributes.
> 
> b.  Creating a new attribute that would mirror the VSA data model,
>     including support for subattributes.
> 
> As I understand it, the primary argument for b) over a) relates to
> potential backward compatibility issues with a).  To determine whether
> this is an issue or not we will need to survey existing implementations.

So, just for my clarification: what are the "potential
backward compatibility issues" with a)? I think we don't
have vendor=0 attributes yet, or do we? If we don't have
them, it appears that the IETF can define the contents
of the extended attribute as we please, no?

Or is the issue that when migrating, say, an SDO-defined VSA
into the IETF space we have to change not just the attribute
number, but also the format due to the M and R fields (and
maybe data type)?

--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: Tue, 08 Jun 2004 12:37:12 +0000
Date: Tue, 08 Jun 2004 14:36:41 +0200
From: [email-masked]
To: [email-masked], "Adrangi, Farid" <[email-masked]>
CC: [email-masked]
Subject: Re: more on bandwidth

Jari, Farid,

My preference would be option 1 (single bandwidth and single burst
size). The NAS tries to provide this bandwidth to the user, but no
more (hence it is min and max at the same time). Later, if there is
a real need for more, an extra bandwidth attribute could be defined
containing the max. However, going for option 3 below immediately
would also be fine for me.

Another concern was that all the attributes *must* be there.
Currently all 4, but I believe that if we would like to have a
solution that can be extended in the future (i.e. adding more
attributes later when there is a real need for it), all attributes
should be optional and only make the presence of attributes a must
when really needed. For instance, it makes no sense to specify a
burst size without bandwidth so if burst size is present also the
bandwidth must be present. This does not apply for 2 bandwidth
parameters: the presence of a min bw does not need a max bw.
Therefore, I also see the encoding of a "dont care" as the attribute
not being present in message.

regards,

Stefaan

Jari Arkko wrote:
> 
> Hi Farid and Stefaan,
> 
> >>1) two bandwidth parameters are defined: min and max. However, when
> >>I look to RFC2697, a traffic conditioner with parameters 2 bandwidth
> >>values and burst size. RFC2698 describes an mechanism with 2
> >>bandwidth parameters and two burst sizes. The MEF (metro ethernet
> >>forum) has further extended these mechanisms. Most NAS
> >>implementations, as far as I know, use a more simpler mechanism: a
> >>single bandwidth with a burst size. So my question: why are there no
> >>burst sizes included in the document? Maybe a burst size does not
> >>mean a lot for the end user but the algorithms used in some NASes do
> >>have to know the burst size.
> >>
> >
> > No specific reasons.  Our initial goal was to support WFA bandwidth
> > profile requirements.  I think burst size would be a useful parameter to
> > add, as the access network needs to support both bursty TCP-based data
> > application as well as constant rate UDP-based applications like VoIP.
> 
> I guess the alternatives are 1) bandwidth + burst, 2) two bandwidths,
> and 3) two bandwidths + burst. Based on earlier discussion on this
> list, I think we want to avoid making the AAA become a fully fledged
> qos mechanism, so I think that implies as simple set of attributes
> as possible. Based on Stefaans comments above I am convinced that
> burst needs to be there. But is the chosen alternative 1 or 3?
> 
> >>2) Similar as Jari's comment: 12 attributes looks too much. Why is
> >>just Kbps not enough? With a 32 bit value field, very high
> >>bandwidths are possible with a fine granularity.
> >>
> >
> >
> > Agreed with Jari's comment.  Will fix it.
> 
> Here we have an alternative also. I was thinking of having
> an octets/s and megawords/s attributes, to match with the
> corresponding accounting attributes. However, perhaps Stefaan
> has pointed to an even simpler approach above. In accounting,
> the sums are cumulative over a longer period, so we need a lot
> of bits. On a bandwidth indicator, maybe just one AVP is
> enough. If its octets/s and 32 bits, that would give you a
> maximum of 32 gigabits/second.
> 
> --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/>

--
to unsubscribe send a message 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, 08 Jun 2004 10:57:26 +0000
Date: Tue, 08 Jun 2004 13:53:10 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Adrangi, Farid" <[email-masked]>
Cc: [email-masked]
Subject: User Alias Identity (Was: Re: comments on draft-adrangi-radius-attributes-extension-00.tx)

Hi Farid,

>>Here's what RFC 3579 says: "The User-Name attribute within the Access-
>>Accept packet need not be the same as the User-Name attribute in the
>>Access-Request."
>>
>>I wonder if this could be used to implement the functionality that
>>you want, without adding a new attribute. But you could still
>>include the explanation of the problem and guidelines for the
>>servers.
>>
> 
> Good question.  We had a long discussion on this subject amongst GSMA
> delegates.  In summary, the decision was made not to use UserName(1)
> rewrite because:
> 
> 1) Some NASes may not like user-name rewriting
> 2) Need for a structured identity for indicating user's chargeable
> identity
> 3) Avoid overloading the UserName(1) attribute for this purpose

Ok. Let me go into a bit more depth here. Lets
look at the issues one at a time:

"Some NASes may not like user-name rewriting"

   Fair enough. This may well be the case. Let me try to
   understand why, and talk about the potential alternative
   solutions and what makes them better in this respect.

   So, presumably the NASes were not prepared for the
   possibility that the User-Name attribute might change.
   Do they actually break, or is it just that they ignore
   the User-Name attribute when it comes back?

   It seems like the functionality we are talking about
   could be applied either in the context of EAP (RFC 3579)
   or web-based logins (plain RADIUS). Are these problems
   common in both cases or just in one?

   Am I correct in assuming that if the context is EAP usage,
   then a NAS which would be unable to support a rewritten
   username would be uncompliant per requirements of RFC 3579?
   It seems so, from Section 3. Now, I really don't want to
   say that RFC 3579 is 100% right here -- it could well be that
   this requirement should not have been there. However, I'd
   like to ensure that the addition of the User Alias Identity
   attributes helps solve the problem. I think the question
   is "does the NAS vendor have to do something to get solution
   X working in his product"? Presumably, the action to make
   the User-Name approach work is to add code to read the
   incoming User-Name from an Access-Accept and make it be
   sent on accounting requests. Is there a similar code
   change for User Alias Identity, or will all currently
   unknown attributes be copied to the accounting requests?
   I tried to look at RFCs 2866 and 2869 but I did not find
   a clear answer... but it would seem logical to copy all
   attributes.

"Need for a structured identity for indicating user's chargeable identity"

   Right now, the chargeable identity has normally been the User-Name.
   But I do agree that divorcing the identity used in the authentication
   process -- which may be a specific temporary identity to begin with --
   and the accounting identity would be useful. However, I'd like to
   ensure that the above NAS-need-not-be-changed properties can
   be achieved if we move into this separation. That is, I'd like
   to understand how this works in a backwards compatible manner
   without requiring updates to the NASes.

   The second issue I'd like to have a better understanding and better
   text on is the privacy issue. I think the privacy issues within the
   authentication identity and the accounting identity are somewhat
   separate; in the former we are most concerned about over-the-wireless
   privacy. But I would also like to avoid telling the cleartext or
   trackable user identity to a zillion access points attached to
   coffee shop walls. I think that boils down to suggesting in the
   document that the accounting identity should be hidden somehow.
   This is what you said in your response, but maybe we
   could write it to the document as well.

   Finally, I would note that since the routing of the Accounting-Request
   packets is based on the User-Name domain part, it would appear that
   the User-Name needs to be kept there as well.

--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: Tue, 08 Jun 2004 09:31:23 +0000
Date: Tue, 08 Jun 2004 12:26:56 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Adrangi, Farid" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: more on bandwidth

Hi Farid and Stefaan,

>>1) two bandwidth parameters are defined: min and max. However, when
>>I look to RFC2697, a traffic conditioner with parameters 2 bandwidth
>>values and burst size. RFC2698 describes an mechanism with 2
>>bandwidth parameters and two burst sizes. The MEF (metro ethernet
>>forum) has further extended these mechanisms. Most NAS
>>implementations, as far as I know, use a more simpler mechanism: a
>>single bandwidth with a burst size. So my question: why are there no
>>burst sizes included in the document? Maybe a burst size does not
>>mean a lot for the end user but the algorithms used in some NASes do
>>have to know the burst size.
>>
> 
> No specific reasons.  Our initial goal was to support WFA bandwidth
> profile requirements.  I think burst size would be a useful parameter to
> add, as the access network needs to support both bursty TCP-based data
> application as well as constant rate UDP-based applications like VoIP.

I guess the alternatives are 1) bandwidth + burst, 2) two bandwidths,
and 3) two bandwidths + burst. Based on earlier discussion on this
list, I think we want to avoid making the AAA become a fully fledged
qos mechanism, so I think that implies as simple set of attributes
as possible. Based on Stefaans comments above I am convinced that
burst needs to be there. But is the chosen alternative 1 or 3?

>>2) Similar as Jari's comment: 12 attributes looks too much. Why is
>>just Kbps not enough? With a 32 bit value field, very high
>>bandwidths are possible with a fine granularity.
>>
> 
> 
> Agreed with Jari's comment.  Will fix it.

Here we have an alternative also. I was thinking of having
an octets/s and megawords/s attributes, to match with the
corresponding accounting attributes. However, perhaps Stefaan
has pointed to an even simpler approach above. In accounting,
the sums are cumulative over a longer period, so we need a lot
of bits. On a bandwidth indicator, maybe just one AVP is
enough. If its octets/s and 32 bits, that would give you a
maximum of 32 gigabits/second.

--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: Tue, 08 Jun 2004 07:17:30 +0000
Content-class: urn:content-classes:message
Subject: RE: more on bandwidth
Date: Tue, 8 Jun 2004 00:16:52 -0700
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Adrangi, Farid" <[email-masked]>

Hello Stefaan,
Thanks so much for reviewing the draft and providing comments.  Please
see my responses inline.
BR,
Farid

>=20
> Hi,
>=20
> I have some questions/comments on
> draft-adrangi-radius-bandwidth-capability:
>=20
> 1) two bandwidth parameters are defined: min and max. However, when
> I look to RFC2697, a traffic conditioner with parameters 2 bandwidth
> values and burst size. RFC2698 describes an mechanism with 2
> bandwidth parameters and two burst sizes. The MEF (metro ethernet
> forum) has further extended these mechanisms. Most NAS
> implementations, as far as I know, use a more simpler mechanism: a
> single bandwidth with a burst size. So my question: why are there no
> burst sizes included in the document? Maybe a burst size does not
> mean a lot for the end user but the algorithms used in some NASes do
> have to know the burst size.
>=20
No specific reasons.  Our initial goal was to support WFA bandwidth
profile requirements.  I think burst size would be a useful parameter to
add, as the access network needs to support both bursty TCP-based data
application as well as constant rate UDP-based applications like VoIP.

> 2) Similar as Jari's comment: 12 attributes looks too much. Why is
> just Kbps not enough? With a 32 bit value field, very high
> bandwidths are possible with a fine granularity.
>=20

Agreed with Jari's comment.  Will fix it.

> 3) Is an access-accept with for instance an ingress bandwidth in
> bits per second and an ingress bandwidth in kilo bits per second
> also valid? I guess only 1 of them may occur or should the values be
> added to have the final bandwidth?

One instance of each bandwidth parameter may occur.  Unless you think it
is useful to have two instances of a bandwidth parameter within
access-accept?

>=20
> 4) Since for some NASes, only 1 bandwidth parameter can be
> specified, would it also be useful to specify "don't care" for the
> second bandwidth? In the draft, the 4 bandwidth values must be
> specified to be valid (section 2.2). Should this not be more
> relaxed?=20

That's a good point.  We can use a value of zero to indicate "don't
care".  What do you think?

> By the way, I am a little bit confused by the notation
> "0-4" in section 5: does it mean: 0 or 4, or does it mean: 0, 1, 2,
> 3, or 4? section 2.2 seems to imply 0 or 4?
>=20

It means 0 or 4.  Good point - will make it clear in section 5.

> 5) typo third line section 2.2.2.1: the HSN (instead of the AN) MAY
> also include other attributes in the COA message.
>=20

Yes, good catch!

--
to unsubscribe send a message 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, 07 Jun 2004 21:38:18 +0000
Date: Mon, 07 Jun 2004 23:37:52 +0200
From: [email-masked]
To: [email-masked]
Subject: more on bandwidth

Hi,

I have some questions/comments on
draft-adrangi-radius-bandwidth-capability:

1) two bandwidth parameters are defined: min and max. However, when
I look to RFC2697, a traffic conditioner with parameters 2 bandwidth
values and burst size. RFC2698 describes an mechanism with 2
bandwidth parameters and two burst sizes. The MEF (metro ethernet
forum) has further extended these mechanisms. Most NAS
implementations, as far as I know, use a more simpler mechanism: a
single bandwidth with a burst size. So my question: why are there no
burst sizes included in the document? Maybe a burst size does not
mean a lot for the end user but the algorithms used in some NASes do
have to know the burst size.

2) Similar as Jari's comment: 12 attributes looks too much. Why is
just Kbps not enough? With a 32 bit value field, very high
bandwidths are possible with a fine granularity.

3) Is an access-accept with for instance an ingress bandwidth in
bits per second and an ingress bandwidth in kilo bits per second
also valid? I guess only 1 of them may occur or should the values be
added to have the final bandwidth?

4) Since for some NASes, only 1 bandwidth parameter can be
specified, would it also be useful to specify "don't care" for the
second bandwidth? In the draft, the 4 bandwidth values must be
specified to be valid (section 2.2). Should this not be more
relaxed? By the way, I am a little bit confused by the notation
"0-4" in section 5: does it mean: 0 or 4, or does it mean: 0, 1, 2,
3, or 4? section 2.2 seems to imply 0 or 4?

5) typo third line section 2.2.2.1: the HSN (instead of the AN) MAY
also include other attributes in the COA message.

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: Mon, 07 Jun 2004 14:30:09 +0000
Content-class: urn:content-classes:message
Subject: RE: Rationalizing the RADIUS data model
Date: Mon, 7 Jun 2004 10:28:15 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> Yes, it could be a separate work item or part of the Guidelines item.
> Separate might be better, particularly since this seems fairly urgent.

There is currently some text to include this work in the Design
Guidelines document, proposed as part of the IESG review of the charter.
I tend to think that the data model rationalization and design
guidelines are interdependent.  If there is urgency, then maybe we
should accelerate the design guidelines.  Presumptively changing the
data model(s) prior to completing the design guidelines might lead to
yet another round of the sort of "liberal interpretation" that has
caused so much debate on the list.

-- Dave

--
to unsubscribe send a message 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, 07 Jun 2004 14:12:47 +0000
Date: Mon, 7 Jun 2004 07:13:57 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: RE: Rationalizing the RADIUS data model

Yes, it could be a separate work item or part of the Guidelines item.
Separate might be better, particularly since this seems fairly urgent. If
you have thoughts on that you might send them to [email-masked] as a
charter comment.

On Mon, 7 Jun 2004 [email-masked] wrote:

> Bernard,
>
> This very much seems like a proposal for a charter item.  Assuming that
> there is consensus on this, should we propose to take this work on?
>
> John

--
to unsubscribe send a message 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, 07 Jun 2004 08:32:39 +0000
content-class: urn:content-classes:message
Subject: RE: Rationalizing the RADIUS data model
Date: Mon, 7 Jun 2004 11:31:22 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Bernard,

This very much seems like a proposal for a charter item.  Assuming that
there is consensus on this, should we propose to take this work on?

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Bernard Aboba
> Sent: 28 May, 2004 19:03
> To: Avi Lior
> Cc: [email-masked]
> Subject: Rationalizing the RADIUS data model
>=20
>=20
> > So I don't know what the benefit of having a new class of=20
> attribute.  What
> > are we really fixing here?
>=20
> Presumably what we would be fixing is:
>=20
> a. Providing a migration path from current SDO VSAs to the=20
> IETF standards
>    space.
>=20
> b. Rationalizing the RADIUS VSA data model with the IETF standard
>    attribute data model.
>=20
> Today because the data models are different and the IETF=20
> standards space
> is only 8 bits, we have difficulties in migrating arbitrary=20
> SDO VSAs to
> the IETF standards space.
>=20
> To get there, I'd suggest we need to do the following:
>=20
> 1.  Take inventory of the data types used in current RADIUS=20
> RFCs.  We've
>     discussed this on previous emails, but we still need to=20
> summarize this
>     and draw conclusions from it so we can understand what the current
>     RADIUS data model is.
>=20
> 2.  Take inventory of the data types that folks feel they=20
> need/want going
>     forward.  Certainly sub-attributes are one element of=20
> this, but there
>     is probably more as well (such as an IPv6 address type).
>=20
> 3.  Put together a draft summarizing what we have now, and analyzing
>     where we need to go, including the Diameter/RADIUS translation
>     issues.
>=20
> In terms of attribute definition, we have two proposals on the table:
>=20
> a.  Using a Vendor-Id of zero (0) within the existing VSA=20
> attribute 26,
>     in order to define an extended IETF standard attribute space that
>     would mirror the VSA data model, including support for=20
> sub-attributes.
>=20
> b.  Creating a new attribute that would mirror the VSA data model,
>     including support for subattributes.
>=20
> As I understand it, the primary argument for b) over a) relates to
> potential backward compatibility issues with a).  To determine whether
> this is an issue or not we will need to survey existing=20
> implementations.
>=20
> Proposal for an IETF extended attribute space:
>=20
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |  Length       |            Vendor-Id
>      =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            Vendor-Id (cont)           |M|R|      Vendor type =20
>         |
>      =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | Vendor length |  Attribute-Specific...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>=20
>    Type
>=20
>       26 for Vendor-Specific
>=20
>    Length
>=20
>       >=3D 7
>=20
>    Vendor-Id
>=20
>       The high-order octet is 0 and the low-order 3 octets are the SMI
>       Network Management Private Enterprise Code of the Vendor in
>       network byte order.  A value of zero (0) denotes the IETF
>       extended attribute space.
>=20
>    M
>       1 =3D Mandatory
>       0 =3D Non-mandatory
>=20
>    R
>       Reserved for future use, and set to zero (0).
>=20
>    Vendor type
>=20
>       The vendor type field is 14 bits.
>=20
>    Vendor length
>=20
>       The Vendor Length field is one octet, and indicates the=20
> length of
>       this Attribute in octets, including the M, R, Vendor=20
> type, Vendor
>       length and Attribute-Specific fields.
>=20
>    Attribute-specific
>=20
>       The Attribute-Specific field is dependent on the definition of
>       the Attribute.
>=20
>    Multiple subattributes MAY be encoded within a
>    single IETF extended attribute, although they do not have to be.
>=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, 03 Jun 2004 21:07:49 +0000
From: Avi Lior <[email-masked]>
To: Avi Lior <[email-masked]>, 'Tschofenig Hannes' <[email-masked]>, 'John Schnizlein' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: draft-jones-radius-geopriv
Date: Thu, 3 Jun 2004 17:07:46 -0400 

Oopps old message.

> -----Original Message-----
> From: Avi Lior 
> Sent: Thursday, June 03, 2004 5:04 PM
> To: 'Tschofenig Hannes'; 'John Schnizlein'
> Cc: [email-masked]; [email-masked]
> Subject: RE: draft-jones-radius-geopriv
> 
> 
> Hi there,
> 
> Keep in mind that any attribute that is required to be 
> processed by RADIUS should be easily parsable.  That is, an 
> attribute that is used in authentication or authorization 
> would need to be  easily parsable so that we don't take a 
> processing hit.
> 
> Remember we are talking about 1000s authentication per second.
> 
> 
> > -----Original Message-----
> > From: Tschofenig Hannes [mailto:[email-masked]]
> > Sent: Tuesday, February 17, 2004 4:38 AM
> > To: 'John Schnizlein'
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: draft-jones-radius-geopriv
> > 
> > 
> > hi john,
> > 
> > thanks for your observation.
> > 
> > i see the following ways to tackle this problem:
> > - forget xml and use a different encoding which is more "lighweight"
> > - switch to diameter 
> > - compress xml objects
> > 
> > i personally think that the privacy issues are worth thinking
> > about these options. 
> > 
> > ciao
> > hannes
> > 
> > > -----Original Message-----
> > > From: John Schnizlein [mailto:[email-masked]]
> > > Sent: Monday, February 16, 2004 1:53 AM
> > > To: Tschofenig Hannes
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: draft-jones-radius-geopriv
> > > 
> > > 
> > > I am sorry I quoted the wrong part of RFC 2865.
> > > The length of an attribute is at most 255, one octet [page 25]. It
> > > seems unlikely that GML, or any XML, would be efficient 
> > enough to be
> > > carried in a RADIUS attribute.
> > > 
> > > At 01:12 PM 2/10/2004, John Schnizlein wrote:
> > > >> One concern, if this location configuration information
> > (LCI) is to
> > > >> be carried over RADIUS, is that the example in section 6
> > seems to
> > > >> be 993 characters long. This one attribute seems to be taking a
> > > >> large share of the maximum RADIUS packet size of 4096. 
> > [RFC 2865, p
> > > >> 15] Is there enough room for everything else that would
> > be expected
> > > >> with this 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/>
> > 
> 

--
to unsubscribe send a message 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, 03 Jun 2004 21:04:48 +0000
From: Avi Lior <[email-masked]>
To: 'Tschofenig Hannes' <[email-masked]>, 'John Schnizlein' <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: draft-jones-radius-geopriv
Date: Thu, 3 Jun 2004 17:04:24 -0400 

Hi there,

Keep in mind that any attribute that is required to be processed by RADIUS
should be easily parsable.  That is, an attribute that is used in
authentication or authorization would need to be  easily parsable so that we
don't take a processing hit.

Remember we are talking about 1000s authentication per second.

> -----Original Message-----
> From: Tschofenig Hannes [mailto:[email-masked]] 
> Sent: Tuesday, February 17, 2004 4:38 AM
> To: 'John Schnizlein'
> Cc: [email-masked]; [email-masked]
> Subject: RE: draft-jones-radius-geopriv
> 
> 
> hi john, 
> 
> thanks for your observation. 
> 
> i see the following ways to tackle this problem: 
> - forget xml and use a different encoding which is more "lighweight"
> - switch to diameter 
> - compress xml objects
> 
> i personally think that the privacy issues are worth thinking 
> about these options. 
> 
> ciao
> hannes
> 
> > -----Original Message-----
> > From: John Schnizlein [mailto:[email-masked]]
> > Sent: Monday, February 16, 2004 1:53 AM
> > To: Tschofenig Hannes
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: draft-jones-radius-geopriv
> > 
> > 
> > I am sorry I quoted the wrong part of RFC 2865.
> > The length of an attribute is at most 255, one octet [page 25]. It 
> > seems unlikely that GML, or any XML, would be efficient 
> enough to be 
> > carried in a RADIUS attribute.
> > 
> > At 01:12 PM 2/10/2004, John Schnizlein wrote:
> > >> One concern, if this location configuration information 
> (LCI) is to 
> > >> be carried over RADIUS, is that the example in section 6 
> seems to 
> > >> be 993 characters long. This one attribute seems to be taking a 
> > >> large share of the maximum RADIUS packet size of 4096. 
> [RFC 2865, p 
> > >> 15] Is there enough room for everything else that would 
> be expected 
> > >> with this 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/>
> 

--
to unsubscribe send a message 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, 03 Jun 2004 10:03:35 +0000
Date: Thu, 03 Jun 2004 12:59:19 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>, "Adrangi, Farid" <[email-masked]>
Subject: comments on draft-lior-radius-redirection-00.txt

Hi Avi, Farid,

I have read your draft, and found it generally well
written. The function it describes is useful. As usual, I do
have some comments:

Management:
===========

I'm not sure which RADEXT proposed charter workitem
this falls under. WLAN attributes? Prepaid? None?

Substantial:
============

> 6. Security Considerations
> 
>    TBD

This type of considerations may have to be revised
before the IESG approves them ;-) You may want to
mention at least the following:

- Basic attribute transport has the same security
   issues as any attribute transport over RADIUS,
   refer to the security considerations of the
   base RFC.

- Limitations of filtering schemes. For instance, situations
   where the client and some other node in the
   internet conspire to hide some traffic under some protocol
   where its in reality something else.

>    Redirection refers to an action taken by the NAS to redirect the
>    user's traffic to an alternate location. Redirecting traffic in
>    mid-session will most probably break some applications. However,
>    Redirection at the start of a Service will most certainly work.

I may be missing something here. But I don't understand
what you mean by "application" in this context. An IP
application, or some specific AAA configuration? I'm pretty
sure some IP applications break even with redirection at
the start of the service...

>    because their account has no more funds. The user's Service Provider
>    instructs the NAS to block all traffic, and redirect any port 80
>    traffic to the Service Provider's Prepaid Portal. Upon detecting that

This is probably the only possible model we can have, but
you should point out the limitations. It works only if this
is person and he or she uses the web application. Otherwise,
your IP connection mysteriously dies...

> 3.1.2 Mid-session Redirection
> 
>    Redirection of traffic using tunnel mid-session involves sending the
>    tunnel attributes as per RFC2868 [5] to the NAS using
>    Change-of-Authorization (COA) packet. The operation is described in
>    RFC3576 [8]. Careful attention should be paid to the security issues
>    in RFC3576.
> 
>    Note that if the session is already tunneled (eg. Mobile-IP) then the
>    COA packet with a new tunnel specification can be sent to the NAS or
>    alternatively the redirection can occur at the tunnel endpoint (the
>    Home Agent) using any one of these methods.

It isn't clear to me that mid-session tunnel establisment is always
possible. For instance, what if we are terminating PPP at the NAS,
and then suddenly the home network requests the session to be moved
on top of L2TP? I think that would have to imply either (a) context
transfer of PPP session to another location (!) or (b) tearing down
the PPP session and renegging and authenticating everything.

>    There is one kind of packet that the access device MUST always
>    discard, that is an IP fragment with a fragment offset of one. This
>    is a valid packet, but it only has one use, to try to circumvent
>    firewalls.

I'm pretty sure there are other attack-only packets. I suspect
the definition of those packets belongs to another document.

 > 4.1 NAS-Filter-Rule Attribute

Can it happen that the text is too long for a RADIUS
attribute?

Diameter Compatibility Issues:
==============================

- Section 1 could perhaps talk about what functions
   exist in Diameter, how that compares to this specification,
   and point to the section that talks about the translation.

- Add a section on the translation. If you need help,
   I can provide some text, but I think you know what
   needs to be done.

>    As pointed out by NASREQ the use Filter-Id is not roaming friendly
>    and it is recommended that instead one should use
>    NAS-Filter-Rule(400) AVP. For this reason, this document introduces
>    NAS-Filter-Rule(TBD) to RADIUS.

This seems to be a case where we add a new attribute to RADIUS where
there already exists a Diameter AVP in Diameter AVP code space.
That is fine otherwise, but a system that works according to the
NASREQ translation rules would map the new RADIUS attribute to
the corresponding RADIUS code space AVP in Diameter, rather than
using the existing Diameter AVP, making interoperability hard.
This can be solved by having the translation agent treat this
attribute as a special case, but it is not as nice is one could
hope for. If anyone has good suggestions how to solve this, let
me know...

Editorial:
==========

>    The text conforms to the following specification (taken from Diameter
>    IPFilterRule Type):

Just as an editorial thing, I wonder if a reference to
RFC 3588 would work better here. Then if there's a
future extension of the filter rules some day, we could
track those better.

> 8. Open Issues

Delete.

>    An implementation is not compliant if it fails to satisfy one or more
>    of the must or must not requirements for the protocols it implements.
>    An implementation that satisfies all the must, must not, should and
>    should not requirements for its protocols is said to be
>    "unconditionally compliant"; one that satisfies all the must and must
>    not requirements but not all the should or should not requirements
>    for its protocols is said to be "conditionally compliant".

Capitalization of keywords?

>    Today this capability is supported in RADIUS
>    and is configurable during service establishment and mid-service via
>    the Filter-Id(11) attribute.

I would prefer seeing Filter-Id [Ref], ie. pointer to the
spec rather than the number. But maybe its just me...

>    As pointed out by NASREQ the use Filter-Id is not roaming friendly
>    and it is recommended that instead one should use
>    NAS-Filter-Rule(400) AVP. For this reason, this document introduces
>    NAS-Filter-Rule(TBD) to RADIUS.

Maybe "As pointed out in [some reference] the use Filter-Id
is not roaming friendly due to the need to have a globally agreed
filter lists. Diameter NASREQ [Diameter NASREQ] defines the
NAS-Filter-Rule(400) AVP for this reason. This document introduces
the corresponding AVP to RADIUS.

> 4.3 Redirection-Rule

Is there some duplication with the filter format
definion here vs. Section 4.1?

--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: Thu, 03 Jun 2004 06:44:54 +0000
Content-class: urn:content-classes:message
Subject: RE: comments on draft-adrangi-radius-attributes-extension-00.tx
Date: Wed, 2 Jun 2004 23:44:42 -0700
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Jari,
Thanks again for your thorough review and detailed comments.   I will
update the document according to your comments/proposed text.
CapExchange is currently discussed on a different thread - please see my
response for the remaining inline. =20
BR,
Farid

> >    2.1 RADIUS Support for Specifying User Alias Identity=20
> >    =20
> >       Rationale=20
> >         In certain authentication methods such as, EAP-PEAP or EAP-
> >         TTLS, the true identity of the subscriber is hidden=20
> from the=20
> >         RADIUS AAA infrastructure.  In these methods the=20
> User-name(1)=20
> >         attribute contains an anonymous identity sufficient=20
> to route=20
> >         the RADIUS packets to the home network but otherwise=20
> >         insufficient to identify the subscriber.  While=20
> this mechanism=20
> >         is good practice there are situations where this creates=20
> >         problems.  For example, in certain roaming situations=20
> >         intermediaries and visited network require to be able to=20
> >         correlate an authentication session with a user=20
> identity;  A=20
> >         broker may require to implement a policy where by=20
> only session=20
> >         is allowed per user entity.  Third party billing=20
> brokers may=20
> >         require to match accounting records to a user identity.=20
> >         =20
> >         The User Identity Alias provides a solution to the above=20
> >         problem.  When the home network assigns a value to the User=20
> >         Identity Alias it asserts that this value=20
> represents a user in=20
> >         the home network.  The assertion should be temporary.  Long=20
> >         enough to be useful for the external applications=20
> and not too=20
> >         long to such that it can be used to identify the user.=20
>=20
> Here's what RFC 3579 says: "The User-Name attribute within the Access-
> Accept packet need not be the same as the User-Name attribute in the
> Access-Request."
>=20
> I wonder if this could be used to implement the functionality that
> you want, without adding a new attribute. But you could still
> include the explanation of the problem and guidelines for the
> servers.
>=20
Good question.  We had a long discussion on this subject amongst GSMA
delegates.  In summary, the decision was made not to use UserName(1)
rewrite because:

1) Some NASes may not like user-name rewriting
2) Need for a structured identity for indicating user's chargeable
identity
3) Avoid overloading the UserName(1) attribute for this purpose

> >      When the home network assigns a value to the User=20
> >      Identity Alias it asserts that this value represents a user in=20
> >      the home network.  The assertion should be temporary.  Long=20
> >      enough to be useful for the external applications and not too=20
> >      long to such that it can be used to identify the user.=20
>=20
> (snip)
>=20
> >         00   reserved=20
> >         01   IMSI=20
> >         02   NAI=20
> >         03   E.164 number=20
> >         04   SIP URL (as defined in [13])=20
> >         05   Opaque string=20
>=20
> I find the first statement and types 1, 3, and 4
> contradictory. This appears to be another reason why
> the RFC 3579 approach might be better. Alternatively,
> define the opaque string case only.
>=20

The options here do not have to reveal the actual identity of the user
-- for example, for IMSI, pseudonym IMSI can be used.=20
=20

> (Type 2 is problematic too if not constructed the right way.)
>=20

> >         A RADIUS server MUST NOT include this attribute in=20
> the Access-
> >         Accept if the IP Address Type options were not=20
> advertised in=20
>=20
> Why? Seems like this adds a rule to the server side, but
> sending an attribute which the NAS will ignore does not
> seem to harm anyone. Or am I missing something?

I see your point.  Would that be okay if I change "MUST NOT" to "SHOULD
NOT"?
>=20
> >         the Access-Request.  If an invalid IP Address Type=20
> option is=20
> >         received in the Access-Accept, then the AN MUST use=20
> its default=20
> >         IP Address Type option for the client.  Otherwise,=20
>=20
> In the other document an invalid attribute resulted in an
> Access-Reject. Why is this different?

Good point!  In the other draft, if an invalid attribute is received,
the NAS rejects/discards the packet.  It makes sense to do the same
thing here.

>=20
> >         assign an IP address according to the specified=20
> type option. =20
> >         In either case it MUST include this attribute in Accounting-
> >         Request packets to indicate the used IP address=20
> type option. =20
>=20
> Which one? The one that the server sent, or the one that the NAS
> chose?

The one that server sent.  You are right - I should be more specific
about it.

>=20
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5=20
> 6 7 8 9 0 1=20
> >      =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
> >       |     Type      |    Length     |IP Address Type|=20
> >      =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
> >  =20
> (snip)
> >         Length=20
> >         =20
> >           1=20
>=20
> This does not seem to match the usual (?) RADIUS style
> where integer/enumerated attributes have a 32-bit
> integer.

Will fix it.

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

Delivery-date: Wed, 02 Jun 2004 21:07:53 +0000
Content-class: urn:content-classes:message
Subject: RE: push & pull (Was: Re: comments on draft-adrangi-radius-bandwidth-capability-00.txt)
Date: Wed, 2 Jun 2004 14:07:31 -0700
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hi Jari,
Thanks for the discussion. Please see my response below.
BR,
Farid

> I have not formed my opinion yet. Let me explore this a little
> further: if we assume that due to other traffic load in the
> access point, the advertisements vary. For instance, an initial
> advertisement may have said that 50 Mbit/s is available, but
> after getting some other sessions, the access point can now
> offer just 5 Mbit/s for this session. This brings up two
> interesting questions:
>=20
>    1. Is the home network's bandwidth decision based
>       on the advertisements?

Yes.

> This seems natural, but
>       are you sure its not a "provide this if you can"
>       scenario?

It could be.  "provide this if you can" is basically the push model.
But, it seems that we still need the pull model if want to interoperate
with Diameter - no?  =20

> The only case where I'd see the advertisement
>       affecting a real decision would be if the user's
>       decision to buy some additional bandwidth would be
>       affected as well. For instance, the web page where
>       he can buy more bandwidth shows the available
>       bandwidth based on the advertisement. Is this what
>       we want?
>=20

No, that wasn't the intent.  I am not sure if this would be doable, from
the current protocol perspective.  That is, an access-accept should
follow the access-request (containing the advertisement) --  in this
case, it seems that you want to send access-request only to indicate the
current bandwidth capability status.

>       (Otherwise accounting will take care of the actually
>       provided service and its cost.)
>=20
>    2. Are the Confirmed bandwidths binding? If they
>       are not, the available bandwidth may change
>       5 seconds after the reception of the COA, which
>       appears to make the advertisement pointless.
>=20

They are.=20

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

Delivery-date: Wed, 02 Jun 2004 19:22:15 +0000
Date: Wed, 02 Jun 2004 22:18:05 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Adrangi, Farid" <[email-masked]>
Cc: [email-masked]
Subject: push & pull (Was: Re: comments on draft-adrangi-radius-bandwidth-capability-00.txt)

Hi Farid,

>>Ok. After a second read of the relevant parts in the document
>>I think I understand this. But it still seems that in order
>>for this functionality to be useful, the contents of the 
>>advertisement must vary during the session, e.g., due to 
>>other traffic through the AN. Otherwise it would be 
>>sufficient for the HSN to rely on the initial advertisement, no?
>>
> 
> Yes.  However, There is no guarantee that the content of the
> advertisement will be different from the initial one.  This provides an
> option for an HSN to receive a fresh advertisement (same as or different
> from the initial one) before doing the Selection.  So, are we in
> agreement on this one?

I have not formed my opinion yet. Let me explore this a little
further: if we assume that due to other traffic load in the
access point, the advertisements vary. For instance, an initial
advertisement may have said that 50 Mbit/s is available, but
after getting some other sessions, the access point can now
offer just 5 Mbit/s for this session. This brings up two
interesting questions:

   1. Is the home network's bandwidth decision based
      on the advertisements? This seems natural, but
      are you sure its not a "provide this if you can"
      scenario? The only case where I'd see the advertisement
      affecting a real decision would be if the user's
      decision to buy some additional bandwidth would be
      affected as well. For instance, the web page where
      he can buy more bandwidth shows the available
      bandwidth based on the advertisement. Is this what
      we want?

      (Otherwise accounting will take care of the actually
      provided service and its cost.)

   2. Are the Confirmed bandwidths binding? If they
      are not, the available bandwidth may change
      5 seconds after the reception of the COA, which
      appears to make the advertisement pointless.

--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, 02 Jun 2004 18:58:45 +0000
Content-class: urn:content-classes:message
Subject: RE: comments on draft-adrangi-radius-bandwidth-capability-00.txt
Date: Wed, 2 Jun 2004 11:58:34 -0700
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hi Jari,

>=20
> > - The key difference between pull and push models is in the=20
> > advertisement.  In the pull model, the HSN receives the current=20
> > bandwidth capabilities (in the Advertisement) before doing the=20
> > Selection.
>=20
> Ok. After a second read of the relevant parts in the document
> I think I understand this. But it still seems that in order
> for this functionality to be useful, the contents of the=20
> advertisement must vary during the session, e.g., due to=20
> other traffic through the AN. Otherwise it would be=20
> sufficient for the HSN to rely on the initial advertisement, no?
>=20
Yes.  However, There is no guarantee that the content of the
advertisement will be different from the initial one.  This provides an
option for an HSN to receive a fresh advertisement (same as or different
from the initial one) before doing the Selection.  So, are we in
agreement on this one?

> Also a nit on the push/pull section:
>=20
> >         In either push or pull method, upon successful=20
> acceptance of=20
> >         the new bandwidth parameters for the session.  The AN MUST=20
> >         generate an Accouting-Stop record that contains the old
>=20
> s/Accouting/Accounting/
>=20
Got it - thanks.

BR,
Farid

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

Delivery-date: Wed, 02 Jun 2004 18:50:14 +0000
Content-class: urn:content-classes:message
Subject: RE: Comment on Capabilities Exchange
Date: Wed, 2 Jun 2004 14:49:23 -0400
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> > Could you perhaps elaborate on the pending "explosion"?
>=20
> I will Dave.  When I respond to Jari's email on the same subject.

Thanks!  That will be helpful.

-- Dave

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

Delivery-date: Wed, 02 Jun 2004 18:47:01 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Comment on Capabilities Exchange
Date: Wed, 2 Jun 2004 14:46:44 -0400 

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Wednesday, June 02, 2004 2:16 PM
> To: [email-masked]
> Subject: RE: Comment on Capabilities Exchange
> 
> 
> Avi Lior writes...
> 
> > If we loose sub-capabilities then we may have an explosion of 
> > capabilities.
> 
> Could you perhaps elaborate on the pending "explosion"? 

I will Dave.  When I respond to Jari's email on the same subject.

> I'm 
> looking at the work currently chartered, and don't quite see 
> it.  Are you referring
> to future extensions not yet on the radar scope?  

I will do a survey of the current 3GPP2 stuff for example to show you what
is going on.
Prepaid for one needs to indicate prepaid capability in general and
subcapabilities for specific flavours of prepaid that are supported by the
NAS.
 
> We are 
> talking about
> RADIUS protocol capabilities, right, and not general 

> NAS firmware capabilities?

No not NAS firmware capabilities.

> 
> -- Dave
> 
> 
> 
> --
> to unsubscribe send 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, 02 Jun 2004 18:42:36 +0000
Date: Wed, 02 Jun 2004 21:38:37 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Adrangi, Farid" <[email-masked]>
Cc: [email-masked]
Subject: Re: comments on draft-adrangi-radius-bandwidth-capability-00.txt

Hi Farid and thanks for your response. It seems that
we agree. I just wanted to dig a bit deeper into the
pull vs. push models:

> - The key difference between pull and push models is in the
> advertisement.  In the pull model, the HSN receives the current
> bandwidth capabilities (in the Advertisement) before doing the
> Selection.  

Ok. After a second read of the relevant parts in the document
I think I understand this. But it still seems that in order
for this functionality to be useful, the contents of the
advertisement must vary during the session, e.g., due to
other traffic through the AN. Otherwise it would be sufficient
for the HSN to rely on the initial advertisement, no?

Also a nit on the push/pull section:

>         In either push or pull method, upon successful acceptance of 
>         the new bandwidth parameters for the session.  The AN MUST 
>         generate an Accouting-Stop record that contains the old 

s/Accouting/Accounting/

--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, 02 Jun 2004 18:40:36 +0000
Date: Wed, 02 Jun 2004 21:36:31 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
Cc: [email-masked], "[email-masked]'" <[email-masked]>
Subject: Re: Comment on Capabilities Exchange

Hi Avi,

> Sub-capabilities are important. These are used in 3GPP2 for instance.

Ok, this looks like an important requirement. Can you
send the list of capabilities and sub-capabilities
in 3GPP2?

> So the intention was to allow the base RADIUS -- which is driven by
> Dictionaries and policy files to treat this as an integer and only check the
> 12-it indicator. The sub-capability would be used by the actual
> applications.

So, the dictionaries and policy files will look at the
highest 12 bits? Will they generally be able to do this?
Hmm... I guess so if they have gt/lt operators, since these
are the highest bits.

> If we loose sub-capabilities then we may have an explosion of capabilities.
> I think this is a reasonable tradeoff.

I see that Dave asked about the explosion. Perhaps we could
come up with the expected table of capabilities and
sub-capabilities, so we could see what the actual situation
will be.

So, in the IETF space we would have at least the following
optional capabilities:

- RFC 2866 (accounting)
- RFC 2548 (ms vsas)
- RFC 2867 (tunnel acct)
- RFC 2868 (tunnel attrs)
- RFC 2869 (radius extensions except for EAP)
- RFC 2869 (eap, version 1)
- RFC 3579 (eap, version 2)
- RFC 3162 (ipv6)
- RFC 3576 (dyn)
- RFC 3580 (1x)
- NASREQ translation

Presumably some of these, such as RFC 2869 extensions
might break down to smaller parts, like ARAP &
accounting extensions. Then add 5-10 pieces from
the results of the RADEXT WG. This comes down to 20-30
capabilities.

It isn't clear to me if all of the capabilities will
be useful. Signaling support for some of them might
not be necessary. I can't think of a specific example
right now, however.

What about capabilities outside the IETF?

Can you say something about the subcapabilities?
Example of use etc?

--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, 02 Jun 2004 18:16:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Comment on Capabilities Exchange
Date: Wed, 2 Jun 2004 14:16:25 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> If we loose sub-capabilities then we may have an explosion of
> capabilities.

Could you perhaps elaborate on the pending "explosion"?  I'm looking at
the work currently chartered, and don't quite see it.  Are you referring
to future extensions not yet on the radar scope?   We are talking about
RADIUS protocol capabilities, right, and not general NAS firmware
capabilities?

-- Dave

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

Delivery-date: Wed, 02 Jun 2004 16:41:13 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Adrangi, Farid" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Comment on Capabilities Exchange
Date: Wed, 2 Jun 2004 12:40:52 -0400 

Jari,

Thanx for the review.  I have an immediate comment on the following:

Jari wrote:

Snip-------
This does not seem to match the usual (?) RADIUS style
where integer/enumerated attributes have a 32-bit
integer.

>    The format of this Integer is as follows:
>     
>    0xCCCTSSSS
>     
>    Where: 
>      CCC is a 12-bit indicator that identifies the capability ID.
(snip)
>      SSSS is 16-bit indicator that identifies the sub-capabilities ID.

Uh oh. This is getting pretty complicated, and requires server side code
(not just regexp) to handle. Are we really, really sure that we couldn't
survive without the sub-capability IDs?
-------

The attribute is a 32 bit integer. It' not intended to be an enumeration.

Sub-capabilities are important. These are used in 3GPP2 for instance.

So the intention was to allow the base RADIUS -- which is driven by
Dictionaries and policy files to treat this as an integer and only check the
12-it indicator. The sub-capability would be used by the actual
applications.

If we loose sub-capabilities then we may have an explosion of capabilities.
I think this is a reasonable tradeoff.

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

Delivery-date: Wed, 02 Jun 2004 14:03:29 +0000
Content-class: urn:content-classes:message
Subject: RE: comments on draft-adrangi-radius-bandwidth-capability-00.txt
Date: Wed, 2 Jun 2004 07:03:10 -0700
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hello Jari,
Thanks so much for your thorough review and detailed/excellent comments
- as always.  I will update the draft accordingly.

- Yes, the attributes need to work with Diameter. The draft was
submitted before our diameter discussion in the last IETF!!=20

- The key difference between pull and push models is in the
advertisement.  In the pull model, the HSN receives the current
bandwidth capabilities (in the Advertisement) before doing the
Selection. =20

- On attributes format/syntax, we have the flexibility to do the right
thing -- WFA is looking for IETF for the most appropriate syntax.  I
don't want to open subtype can-of-worms here either!  I am okay with
your proposal.

BR,
Farid

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]=20
> Sent: Wednesday, June 02, 2004 4:30 AM
> To: [email-masked]'; Adrangi, Farid
> Subject: comments on draft-adrangi-radius-bandwidth-capability-00.txt
>=20
>=20
>=20
> Hi Farid,
>=20
> Overall, I think the basic functionality suggested
> in this draft is valid and useful. Some work remains,
> however. The attributes need to work with Diameter,
> too, so when you mention a Radius message you should
> also list the equivalent Diameter message. There's
> a bunch of editorial issues and some suggested
> simplifications below too. I'm not sure if the
> pull model is useful, and the 12 attributes defined
> should be compressed to 8. Finally, I would use
> a different format in the attribute.
>=20
> In more detail:
>=20
> Substantial:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> >      The attribute is described for RADIUS [1].
>=20
> As I have stated before, I'd like attributes to be
> defined generally. Suggested rewrite: The attribute
> is described for RADIUS, but works as is also in
> Diameter [RFC 3588], and through the translation
> rules defined in [Diameter NASREQ]."
>=20
> However, this probably means that the attribute format=20
> corresponds to some known Diameter type. More on this later.
>=20
> >         The ingress minimum bandwidth parameter indicates=20
> the average=20
> >         minimum ingress data rate that an AN will try to=20
> provide to an=20
> >         authorized user.  This value is a target, rather than a=20
> >         guarantee.
>=20
> I have a feeling that "average minimum" is not well defined.=20
> What does that mean? I guess it does not mean guaranteed=20
> minimum peak rate. If not, what does it mean?
>=20
> How about "... indicates the minimum peak rate that the=20
> authorized user should get. However, this value is a target=20
> and not a guarantee."
>=20
> >       Both protocols exchange bandwidth parameters using=20
> the various=20
> >       RADIUS messages, and they are comprised of three phases: =20
> >       bandwidth Advertisement, Selection, and Confirmation.
> >       =20
> >       Bandwidth Advertisement:
> >       =20
> >          MAY be sent in Access-Request packet from the AN=20
> to the HSN=20
> >          and conveys possible/available bandwidth=20
> parameters that can=20
> >          be allocated for an the AN client connection to=20
> the HSN by the=20
> >          AN.  Advertisements are optional.
> >       =20
> >       Bandwidth Selection:
> >       =20
> >          MAY be sent in Access-Accept packet and Change of=20
> >          Authorization (COA) messages.  Selection conveys=20
> the desired=20
> >          bandwidth for the AN Client connection to the AN=20
> by the HSN.  =20
> >       =20
> >       Bandwidth Confirmation:
> >       =20
> >          If Bandwidth Selection is received and enforced,=20
> It MUST be=20
> >          sent in Accounting-Request packets.  Confirmation=20
> indicates=20
> >          that the desired bandwidth parameters specified by=20
> a HSN are=20
> >          being enforced by the AN.  =20
> >       =20
> >       =20
> >       Bandwidth Attribute (BA), defined in section 3, is=20
> used to carry=20
> >       the Bandwidth Advertisement, Selection, Confirmation=20
> in various=20
> >       RADIUS packets.
>=20
> RADIUS specific. Suggested rewrite:
>=20
>        Both protocols exchange bandwidth parameters using the various
>        AAA messages, and they are comprised of three phases:
>        bandwidth Advertisement, Selection, and Confirmation.
>=20
>        Bandwidth Advertisement:
>=20
>           MAY be sent in Access-Request packet in RADIUS, and  the AAR
>           and DER commands in Diameter [Diameter NASREQ,=20
> Diameter EAP],
>           from the AN to the HSN. The attributes convey=20
> possible/available
>           bandwidth parameters that can be allocated for an=20
> the AN client
>           connection to the HSN by the AN.  Advertisements=20
> are optional.
>=20
>        Bandwidth Selection:
>=20
>           MAY be sent in Access-Accept packet and Change of
>           Authorization (COA) messages in RADIUS. MAY be sent in RAR
>           command in Diameter [RFC 3588]. Selection conveys=20
> the desired
>           bandwidth for the AN Client connection to the AN by the HSN.
>=20
>        Bandwidth Confirmation:
>=20
>           If Bandwidth Selection is received and enforced, It MUST be
>           sent in Accounting-Request packets in RADIUS and in=20
> ACR command
>           in Diameter. Confirmation indicates that the desired
>           bandwidth parameters specified by a HSN are being enforced
>           by the AN.
>=20
>        Bandwidth Attribute (BA), defined in section 3, is=20
> used to carry
>        the Bandwidth Advertisement, Selection, Confirmation in various
>        RADIUS packets and Diameter commands.
>=20
> >         The AN MAY send an Advertisement in an=20
> Access-Request message. =20
> >         If the HSN receives an invalid Advertisement, then=20
> the HSN MUST=20
> >         silently discard the Access-Request.
>=20
> I believe this text from 2.2.1 is unnecessary, as the MAY=20
> already appeared in 2.2. The MUST part might be useful,=20
> except that it would perhaps be better to move it too to 2.2.
>=20
> > A HSN MAY send the Selection after receiving a valid=20
> >         Advertisement.  It MAY also send the Selection in=20
> the absence=20
> >         of an Advertisement, based on local policies such as the AN=20
> >         client s subscription profile.
>=20
> So the bottom line is that the HSN MAY send the=20
> advertisement, which was already stated in 2.2... suggested rewrite:
>=20
>     A selection is sent after receiving a valid Advertisement,
>     or based on a local policy such the user's subscription
>     parameters.
>=20
> (The style is explanation rather than normative language, I=20
> think 2.2 already covered this pretty well.)
>=20
> Similar comments apply to the rest of 2.2.1-2
>=20
> >  Dynamic bandwidth allocation uses the Change of Authorization=20
> >         (COA) message as defined in [3].
>=20
> Suggested rewrite: "Dynamic bandwidth allocation uses the=20
> Change of Authorization (COA) RADIUS message as defined in=20
> [3], and the Diameter RAR message as defined in [RFC 3588].=20
> These messages are referred to as the re-authorization=20
> messages in this specification."
>=20
> In the rest of the section, change "COA message" to=20
> "re-authorization message".
>=20
> > or it may instruct the AN to generate an Authorize-Only=20
> >         Access-Request (Access-Request with Service-Type set to=20
> >          Authorize-Only ) in which case it is instructing the AN to=20
> >         pull the BAs.
>=20
> How about "or it may instruct the AN to generate an=20
> authorize-only AAA exchange. In RADIUS this exchange is an=20
> Access-Request with Service-Type set to "Authorize-Only". In=20
> Diameter it is the AAR command with the Auth-Request-Type AVP=20
> set to AUTHORIZE_ONLY. In either case, the HSN instructs the=20
> AN to  pull the bandwidth attributes."
>=20
> >    2.2.2.2 Pull Method
>=20
> I'm not sure why the pull method is needed. Seems like in
> both pull and push the HSN needs to take the initiative.=20
> Simplify by removing the pull method from the spec?
>=20
> >    In the former case, the AN must generate an Accounting Stop=20
> >    message containing the old bandwidth attributes followed by=20
> >    an Accounting-Start message containing the current bandwidth=20
> >    attributes.
>=20
> Does this cause the real session to appear as a set of
> sessions in the accounting records?
>=20
> >      The attribute MAY be present in Access-Request, Access-Accept,=20
> >      Accounting-Request.
>=20
> Duplicate text, but if you want to say something about the=20
> attributes here, then an occurrence table per message would=20
> be appropriate here. Alternatively, delete the text.
>=20
> >            =20
> >            1   Average Minimum Bandwidth Rate for Ingress=20
> Traffic in=20
> >            bits per second=20
> >            2   Average Minimum Bandwidth Rate for Ingress=20
> Traffic in=20
> >            Kilo bits per second=20
> >            3   Average Minimum Bandwidth Rate for Ingress=20
> Traffic in=20
> >            Giga bits per second
>=20
> Three attributes for the same thing appear a bit unnecessary,=20
> imho. Also, it is not in line with the byte - gigaword=20
> approach defined in RFC 2869. My suggestion is to provide the=20
> rates as bytes/s and gigawords/s. This will compress your set=20
> of attributes down to 8 instead of 12.
>=20
> >   =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
> >    |     Type      |    Length     |     Params            =20
>        |=20
> >   =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
> >    |                               Value                   =20
>        |=20
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> I'm not sure I want to open the subtype can-of-worms here.
> Are these attributes deployed somewhere by some SDO and=20
> vendor, and we can't change the format? If yes, we can think=20
> about it, but then there may be issues for Diameter=20
> translation. If not, my preference would be to use plain old=20
> standards space RADIUS attributes. We don't need that many.=20
> See also above. If that fails, VSA with vendor=3DIETF would=20
> also work better for me.
>=20
> Editorial:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> >  Authorize-Only )
>=20
> Non-ASCII char.
>=20
> > preformed
>=20
> performed
>=20
> > 1   Average
>=20
> Non-ASCII char.
>=20
> >       This  document  describes  network  bandwidth =20
> parameters  and =20
> > a
>=20
> Additional spacing between words. I think the I-D guidelines=20
> say that left justification is preferred.
>=20
> >   protocol framework within which the parameters can be exchanged=20
> >   between an Access Network (AN) and a Home Service Network (HSN)=20
> >   in order to determine the average minimum and maximum bandwidth=20
> >   for both ingress and egress traffic that should be allocated by=20
> >   the AN for the duration of an authorized client session.
>=20
> This is a pretty long sentence. Suggested rewrite:
>=20
>      This document describes network bandwidth parameters and a
>      protocol mechanism within which the parameters can be exchanged
>      between an access network and a home network. The parameters
>      can be used to allocate and police the minimum and maximum
>      bandwidth for the user's session, for both ingress and egress
>      traffic.
>=20
> >           This is a server which provides for
>=20
> Non-ASCII char.
>=20
> >           Dynamic Authorization Extensions to Remote Authentication
>=20
> Non-ASCII char.
>=20
> > pushing the BAs
>=20
> pushing the bandwidth attributes?
>=20
> >    3. Operations
> >    =20
> >      Operation  is  identical  to  that  defined  in  RADIUS  AAA=20
> >      specifications  [1][2]  and  Dynamic  Authorization =20
> Extensions  to=20
> >      Remote Authentication Dial In User Service (RADIUS)[3].
>=20
> This seems like an unnecessary section, imho. Refer to the=20
> specs the first time you mention RADIUS, that should do it.
>=20
> >    Authors  Addresses
>=20
> Non-ASCII char.
>=20
> >    Farid Adrangi, Intel Corporatation       =20
> [email-masked]=20
> >    Chuck Black, Hewlett Packard Company      [email-masked]=20
> >    Paul Congdon, Hewlett Packard Company     [email-masked]=20
> >    Farooq Bari, AT&T Wireless               =20
> [email-masked]            =20
> >    Avi Lior, Bridgwater Systems Corporation =20
> > [email-masked]
>=20
> This is not the usual style of author address lists.
> Here's an example format from RFC 2865:
>=20
>     William Allen Simpson
>     Daydreamer
>     Computer Systems Consulting Services
>     1384 Fontaine
>     Madison Heights, Michigan  48071
>=20
>     EMail: [email-masked]
>=20
> --Jari
>=20
>=20

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

Delivery-date: Wed, 02 Jun 2004 13:32:12 +0000
Date: Wed, 02 Jun 2004 16:27:19 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Adrangi, Farid" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: comments on draft-adrangi-radius-attributes-extension-00.txt

Hi Farid et al,

Most of the functions in this draft appear valid
and useful. I do have a number of comments again,
however ;-) Some of these comments have to do with
the User Alias Identity. I'm uncertain whether
it should be done like this, or if the existing User-Name
AVP is sufficient. Certainly the way that its now specified
in the draft appears to have some privacy issues. Other set
of comments involves making these attributes work with
Diameter too (surprisingly, even the RADIUS capabilities
discovery may be useful for Diameter). I also have
some issues with the 1-byte long enumerated fields.

In more detail:

Substantial:

>   This document describes additional Remote Authentication Dial In 
>   User Service (RADIUS) [1] attributes for use of RADIUS AAA 
>   (Authentication, Authorization, Accounting) in both Wireless and 
>   wired networks.

This is otherwise OK abstract, but I would like to have
it say something more about what the attributes do. Also
make it less-RADIUS specific. How about this:

   This document describes additional Authentication, Authorization,
   Accounting (AAA) attributes for network access. It provides
   an IPv4 address type control mechanism, mobile IPv4 home
   agent discovery mechanism, and a RADIUS capabilities discovery
   mechanism.

>    2. Operation 
>  
>      Operation is identical to that defined in [1] and [2]. 

Like in the other draft, this seems to say very little.
How about deleting this and adding the following text
to the end of the Introduction: "This document assumes
that the RADIUS protocol operates as specified in [1, 2]
and that the Diameter protocol operates as specified in
[RFC 3588, NASREQ, EAP].

>     This document describes a number of additional attributes that are 
>     needed to enable use of RADIUS AAA in various types of access 
>     network in an interoperable manner.   

First some editorials: s/access network/access networks/
and s/RADIUS AAA/the RADIUS and Diameter AAA protocols/.
Then to the substantive comment: I'm not sure I understand
what is claimed here. Is this the draft that makes RADIUS
interoperable? I'm pretty sure it adds new features.
It certainly is likely that this specification is more
interoperable than the existing VSAs, but lets state that
then:

     This document describes a number of additional attributes
     for the RADIUS and Diameter AAA protocols. These attributes
     are needed to provide <a set of functions> for wired and
     wireless access networks. Some of these functions already
     exist as vendor-specific solutions, but it is expected that
     this draft makes these functions interoperable among different
     vendors.

>    2.1 RADIUS Support for Specifying User Alias Identity 
>     
>       Rationale 
>         In certain authentication methods such as, EAP-PEAP or EAP-
>         TTLS, the true identity of the subscriber is hidden from the 
>         RADIUS AAA infrastructure.  In these methods the User-name(1) 
>         attribute contains an anonymous identity sufficient to route 
>         the RADIUS packets to the home network but otherwise 
>         insufficient to identify the subscriber.  While this mechanism 
>         is good practice there are situations where this creates 
>         problems.  For example, in certain roaming situations 
>         intermediaries and visited network require to be able to 
>         correlate an authentication session with a user identity;  A 
>         broker may require to implement a policy where by only session 
>         is allowed per user entity.  Third party billing brokers may 
>         require to match accounting records to a user identity. 
>          
>         The User Identity Alias provides a solution to the above 
>         problem.  When the home network assigns a value to the User 
>         Identity Alias it asserts that this value represents a user in 
>         the home network.  The assertion should be temporary.  Long 
>         enough to be useful for the external applications and not too 
>         long to such that it can be used to identify the user. 

Here's what RFC 3579 says: "The User-Name attribute within the Access-
Accept packet need not be the same as the User-Name attribute in the
Access-Request."

I wonder if this could be used to implement the functionality that
you want, without adding a new attribute. But you could still
include the explanation of the problem and guidelines for the
servers.

>      When the home network assigns a value to the User 
>      Identity Alias it asserts that this value represents a user in 
>      the home network.  The assertion should be temporary.  Long 
>      enough to be useful for the external applications and not too 
>      long to such that it can be used to identify the user. 

(snip)

>         00 � reserved 
>         01 � IMSI 
>         02 � NAI 
>         03 � E.164 number 
>         04 � SIP URL (as defined in [13]) 
>         05 � Opaque string 

I find the first statement and types 1, 3, and 4
contradictory. This appears to be another reason why
the RFC 3579 approach might be better. Alternatively,
define the opaque string case only.

(Type 2 is problematic too if not constructed the right way.)

>    2.2 RADIUS Support for Advertising Application-based capabilities  

I would add the following text somewhere: This discovery also
enables a Diameter translation agent to discover
whether it can initiate these functions and expect them to
succeed when translated to RADIUS. This attribute SHOULD
be translated as is to Diameter, to enable the server
make these decisions as well. A translation agent
converting a Diameter AAR command to a RADIUS Access-Request
packet SHOULD include this attribute iwith the
value <TBD> to indicate that Diameter can support, for instance,
dynamic authorization.

>         This attribute indicates IPv4 address type options. It can be 
>         present  in  Access-Request,  Access-Accept,  and  Accounting-
>         Request records where the Acc-Status-Type is set to Start or 
>         Stop.  When it is used in an Access-Accept and Accounting-
>         Request packets, the Address Type value MUST be 1 or 2.   

RADIUS-specific. Suggested rewrite:

      This attribute indicates IPv4 address type options. In RADIUS,
      it can be present  in  Access-Request,  and Access-Accept messages.
      In Diameter, it can be present in AAR, AAA, and RAR commands. In
      both protocols, it can be present in
      Accounting-Request messages where the Acc-Status-Type is set to Start or
      Stop.  When it is used in an Access-Accept and Accounting-
      Request packets, the Address Type value MUST be 1 or 2.

> A RADIUS server includes 
>         this attribute in the Access-Accept to specify an IP address 
>         type option for the PWLAN client.  

Rewrite:

         A server includes this attribute in the RADIUS Access-Accept
         packet or Diameter AAA and RAR commands to specify an IP address
         type option for the PWLAN client.

>         A RADIUS server MUST NOT include this attribute in the Access-
>         Accept if the IP Address Type options were not advertised in 

Why? Seems like this adds a rule to the server side, but
sending an attribute which the NAS will ignore does not
seem to harm anyone. Or am I missing something?

>         the Access-Request.  If an invalid IP Address Type option is 
>         received in the Access-Accept, then the AN MUST use its default 
>         IP Address Type option for the client.  Otherwise, the AN MUST 

In the other document an invalid attribute resulted in an
Access-Reject. Why is this different?

>         assign an IP address according to the specified type option.  
>         In either case it MUST include this attribute in Accounting-
>         Request packets to indicate the used IP address type option.  

Which one? The one that the server sent, or the one that the NAS
chose?

>         If an IP address type option is not specified in the Access-
>         Accept, the NAS MUST NOT include this attribute in Accounting-
>         Request packets. 

s/Access-Accept/RADIUS Access-Accept or Diameter RAR and
AAA commands/

>      This draft introduces new RADIUS Attributes.  Therefore, there is 
>      a need for obtaining new attribute TYPE numbers from IANA.  

I think the document should also say something about the
future allocations in the defined enumerated spaces.
How about this additional text:

    New enumerated values within the attributes defined here
    can be allocated using the policies defined in RFC 3575,
    i.e., Designated Expert.

>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |     Type      |    Length     |IP Address Type| 
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>   
(snip)
>         Length 
>          
>           1 

This does not seem to match the usual (?) RADIUS style
where integer/enumerated attributes have a 32-bit
integer.

>    The format of this Integer is as follows: 
>     
>    0xCCCTSSSS 
>     
>    Where: 
>      CCC is a 12-bit indicator that identifies the capability ID.  
(snip)
>      SSSS is 16-bit indicator that identifies the sub-capabilities ID.  

Uh oh. This is getting pretty complicated, and requires server
side code (not just regexp) to handle. Are we really, really
sure that we couldn't survive without the sub-capability IDs?

Editorial:

>    4. Security Considerations 
>     
>      The attributes in this document have no additional security 
>      considerations beyond those already identified in [?]. 

Missing reference.

> PWLAN client

This seems a bit too WLAN specific. Just say network access
client.

(Multiple places.)

> RADIUS Attributes Extension

A bit generic name for the system.

> and sever are

s/sever/server/

>    2.1 RADIUS Support for Specifying User Alias Identity..............2 
>    2.2 RADIUS Support for Advertising Application-based capabilities..4 
>    2.3 RADIUS Support for Specifying a Mobile IP Home Agent...........6 
>    2.4 RADIUS Support for Specifying IP Address Type Options..........7 

Suggest s/RADIUS Support for Specifying// and
s/RADIUS Support for Advertising/ in order to make
the titles short.

>     Remote Access Dial In User Service (RADIUS) [1],[2],[3] is the 
>     dominant Authentication, Authorization, and Accounting (AAA) 
>     protocol in use across broadband wireless and wired networks 
>     globally.  

True, but not really relevant to the specification task at hand.
Suggestion: delete paragraph. Move references to the next paragraph.

> user�s

Non-ASCII char.

>            00 � reserved 
>            01 � IMSI 
>            02 � NAI 
>            03 � E.164 number 
>            04 � SIP URL (as defined in [13]) 
>            05 � Opaque string 
>  

Non-ASCII char.

>         later be indicated to the client through several means � for 
>         example, it can be relayed in the �home agent address� field of 

Non-ASCII chars.

>    Authors� Addresses 

Non-ASCII char.

--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, 02 Jun 2004 11:34:38 +0000
Date: Wed, 02 Jun 2004 14:30:22 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>, "Adrangi, Farid" <[email-masked]>
Subject: comments on draft-adrangi-radius-bandwidth-capability-00.txt

Hi Farid,

Overall, I think the basic functionality suggested
in this draft is valid and useful. Some work remains,
however. The attributes need to work with Diameter,
too, so when you mention a Radius message you should
also list the equivalent Diameter message. There's
a bunch of editorial issues and some suggested
simplifications below too. I'm not sure if the
pull model is useful, and the 12 attributes defined
should be compressed to 8. Finally, I would use
a different format in the attribute.

In more detail:

Substantial:
============

>      The attribute is described for RADIUS [1]. 

As I have stated before, I'd like attributes to be
defined generally. Suggested rewrite: The attribute
is described for RADIUS, but works as is also in
Diameter [RFC 3588], and through the translation
rules defined in [Diameter NASREQ]."

However, this probably means that the attribute format
corresponds to some known Diameter type. More on this
later.

>         The ingress minimum bandwidth parameter indicates the average 
>         minimum ingress data rate that an AN will try to provide to an 
>         authorized user.  This value is a target, rather than a 
>         guarantee.

I have a feeling that "average minimum" is not well defined. What
does that mean? I guess it does not mean guaranteed minimum peak
rate. If not, what does it mean?

How about "... indicates the minimum peak rate that the
authorized user should get. However, this value is a target
and not a guarantee."

>       Both protocols exchange bandwidth parameters using the various 
>       RADIUS messages, and they are comprised of three phases:  
>       bandwidth Advertisement, Selection, and Confirmation. 
>        
>       Bandwidth Advertisement: 
>        
>          MAY be sent in Access-Request packet from the AN to the HSN 
>          and conveys possible/available bandwidth parameters that can 
>          be allocated for an the AN client connection to the HSN by the 
>          AN.  Advertisements are optional. 
>        
>       Bandwidth Selection:  
>        
>          MAY be sent in Access-Accept packet and Change of 
>          Authorization (COA) messages.  Selection conveys the desired 
>          bandwidth for the AN Client connection to the AN by the HSN.   
>        
>       Bandwidth Confirmation: 
>        
>          If Bandwidth Selection is received and enforced, It MUST be 
>          sent in Accounting-Request packets.  Confirmation indicates 
>          that the desired bandwidth parameters specified by a HSN are 
>          being enforced by the AN.   
>        
>        
>       Bandwidth Attribute (BA), defined in section 3, is used to carry 
>       the Bandwidth Advertisement, Selection, Confirmation in various 
>       RADIUS packets. 

RADIUS specific. Suggested rewrite:

       Both protocols exchange bandwidth parameters using the various
       AAA messages, and they are comprised of three phases:
       bandwidth Advertisement, Selection, and Confirmation.

       Bandwidth Advertisement:

          MAY be sent in Access-Request packet in RADIUS, and  the AAR
          and DER commands in Diameter [Diameter NASREQ, Diameter EAP],
          from the AN to the HSN. The attributes convey possible/available
          bandwidth parameters that can be allocated for an the AN client
          connection to the HSN by the AN.  Advertisements are optional.

       Bandwidth Selection:

          MAY be sent in Access-Accept packet and Change of
          Authorization (COA) messages in RADIUS. MAY be sent in RAR
          command in Diameter [RFC 3588]. Selection conveys the desired
          bandwidth for the AN Client connection to the AN by the HSN.

       Bandwidth Confirmation:

          If Bandwidth Selection is received and enforced, It MUST be
          sent in Accounting-Request packets in RADIUS and in ACR command
          in Diameter. Confirmation indicates that the desired
          bandwidth parameters specified by a HSN are being enforced
          by the AN.

       Bandwidth Attribute (BA), defined in section 3, is used to carry
       the Bandwidth Advertisement, Selection, Confirmation in various
       RADIUS packets and Diameter commands.

>         The AN MAY send an Advertisement in an Access-Request message.  
>         If the HSN receives an invalid Advertisement, then the HSN MUST 
>         silently discard the Access-Request. 

I believe this text from 2.2.1 is unnecessary, as the MAY already
appeared in 2.2. The MUST part might be useful, except that it
would perhaps be better to move it too to 2.2.

> A HSN MAY send the Selection after receiving a valid 
>         Advertisement.  It MAY also send the Selection in the absence 
>         of an Advertisement, based on local policies such as the AN 
>         client�s subscription profile.

So the bottom line is that the HSN MAY send the advertisement,
which was already stated in 2.2... suggested rewrite:

    A selection is sent after receiving a valid Advertisement,
    or based on a local policy such the user's subscription
    parameters.

(The style is explanation rather than normative language, I
think 2.2 already covered this pretty well.)

Similar comments apply to the rest of 2.2.1-2

>  Dynamic bandwidth allocation uses the Change of Authorization 
>         (COA) message as defined in [3].

Suggested rewrite: "Dynamic bandwidth allocation uses the
Change of Authorization (COA) RADIUS message as defined in [3],
and the Diameter RAR message as defined in [RFC 3588]. These
messages are referred to as the re-authorization messages in
this specification."

In the rest of the section, change "COA message" to "re-authorization
message".

> or it may instruct the AN to generate an Authorize-Only 
>         Access-Request (Access-Request with Service-Type set to 
>         �Authorize-Only�) in which case it is instructing the AN to 
>         pull the BAs. 

How about "or it may instruct the AN to generate an authorize-only
AAA exchange. In RADIUS this exchange is an Access-Request with
Service-Type set to "Authorize-Only". In Diameter it is the AAR
command with the Auth-Request-Type AVP set to AUTHORIZE_ONLY.
In either case, the HSN instructs the AN to  pull the bandwidth
attributes."

>    2.2.2.2 Pull Method 

I'm not sure why the pull method is needed. Seems like in
both pull and push the HSN needs to take the initiative.
Simplify by removing the pull method from the spec?

>    In the former case, the AN must generate an Accounting Stop 
>    message containing the old bandwidth attributes followed by 
>    an Accounting-Start message containing the current bandwidth 
>    attributes.

Does this cause the real session to appear as a set of
sessions in the accounting records?

>      The attribute MAY be present in Access-Request, Access-Accept, 
>      Accounting-Request. 

Duplicate text, but if you want to say something about the
attributes here, then an occurrence table per message would
be appropriate here. Alternatively, delete the text.

>             
>            1 � Average Minimum Bandwidth Rate for Ingress Traffic in 
>            bits per second 
>            2 � Average Minimum Bandwidth Rate for Ingress Traffic in 
>            Kilo bits per second 
>            3 � Average Minimum Bandwidth Rate for Ingress Traffic in 
>            Giga bits per second 

Three attributes for the same thing appear a bit unnecessary,
imho. Also, it is not in line with the byte - gigaword approach
defined in RFC 2869. My suggestion is to provide the rates as
bytes/s and gigawords/s. This will compress your set of attributes
down to 8 instead of 12.

>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |     Type      |    Length     |     Params                    | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                               Value                           | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

I'm not sure I want to open the subtype can-of-worms here.
Are these attributes deployed somewhere by some SDO and vendor,
and we can't change the format? If yes, we can think about it,
but then there may be issues for Diameter translation. If not,
my preference would be to use plain old standards space RADIUS
attributes. We don't need that many. See also above. If that
fails, VSA with vendor=IETF would also work better for me.

Editorial:
==========

> �Authorize-Only�)

Non-ASCII char.

> preformed

performed

> 1 � Average

Non-ASCII char.

>       This  document  describes  network  bandwidth  parameters  and  a 

Additional spacing between words. I think the I-D guidelines
say that left justification is preferred.

>   protocol framework within which the parameters can be exchanged 
>   between an Access Network (AN) and a Home Service Network (HSN) 
>   in order to determine the average minimum and maximum bandwidth 
>   for both ingress and egress traffic that should be allocated by 
>   the AN for the duration of an authorized client session.  

This is a pretty long sentence. Suggested rewrite:

     This document describes network bandwidth parameters and a
     protocol mechanism within which the parameters can be exchanged
     between an access network and a home network. The parameters
     can be used to allocate and police the minimum and maximum
     bandwidth for the user's session, for both ingress and egress
     traffic.

>          �This is a server which provides for 

Non-ASCII char.

>          �Dynamic Authorization Extensions to Remote Authentication 

Non-ASCII char.

> pushing the BAs

pushing the bandwidth attributes?

>    3. Operations  
>     
>      Operation  is  identical  to  that  defined  in  RADIUS  AAA 
>      specifications  [1][2]  and  Dynamic  Authorization  Extensions  to 
>      Remote Authentication Dial In User Service (RADIUS)[3]. 

This seems like an unnecessary section, imho. Refer to the specs
the first time you mention RADIUS, that should do it.

>    Authors� Addresses 

Non-ASCII char.

>    Farid Adrangi, Intel Corporatation        [email-masked] 
>    Chuck Black, Hewlett Packard Company      [email-masked] 
>    Paul Congdon, Hewlett Packard Company     [email-masked] 
>    Farooq Bari, AT&T Wireless                [email-masked]             
>    Avi Lior, Bridgwater Systems Corporation  [email-masked] 

This is not the usual style of author address lists.
Here's an example format from RFC 2865:

    William Allen Simpson
    Daydreamer
    Computer Systems Consulting Services
    1384 Fontaine
    Madison Heights, Michigan  48071

    EMail: [email-masked]

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