Subject: FW: [IANA #46166] Request for allocation of NAS-Port-Type values
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Date: Tue, 12 Dec 2006 13:14:11 -0800

>From: "Amanda Baber via RT" <[email-masked]>
>Reply-To: [email-masked]
>To: [email-masked]
>Subject: [IANA #46166] Request for allocation of NAS-Port-Type values Date: 
>Tue, 12 Dec 2006 11:38:31 -0800
>
>Dear Bernard,
>
>The following values for RADIUS Attribute 61, NAS-Port-Type,
>have been added to the registry:
>
>27  Wireless - IEEE 802.16
>28  Wireless - IEEE 802.20
>29  Wireless - IEEE 802.22
>
>Please see the following:
>
>http://www.iana.org/assignments/radius-types
>
>Best regards,
>
>Amanda Baber
>IANA

--
to unsubscribe send a message 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, 10 Dec 2006 21:01:10 +0000
Content-class: urn:content-classes:message
Subject: RE: [IANA #46166] Request for allocation of NAS-Port-Type values
Date: Sun, 10 Dec 2006 16:03:01 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Sunday, December 10, 2006 3:49 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [IANA #46166] Request for allocation of=20
> NAS-Port-Type values
>=20
> RFC 4603 explicitly requested an allocation of values 30-34,=20

We started at 30 just to leave some open space in case
anything was allocated between when we implemented &
when we standardized, not because 27-29 were used.

Greg

> which makes me=20
> wonder whether a vendor isn't already using 27-29.
>=20
>=20
> >From: "Alan DeKok" <[email-masked]>
> >To: "Bernard Aboba" <[email-masked]>
> >CC: [email-masked]
> >Subject: Re: [IANA #46166] Request for allocation of=20
> NAS-Port-Type values=20
> >Date: Sun, 10 Dec 2006 14:28:39 -0500
> >
> >"Bernard Aboba" <[email-masked]> wrote:
> > > Is there any existing usage of values 27-29?
> >
> >   Not that I can see.
> >
> >   Alan DeKok.
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Sun, 10 Dec 2006 20:50:01 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: [IANA #46166] Request for allocation of NAS-Port-Type values
Date: Sun, 10 Dec 2006 12:49:17 -0800

RFC 4603 explicitly requested an allocation of values 30-34, which makes me 
wonder whether a vendor isn't already using 27-29.

>From: "Alan DeKok" <[email-masked]>
>To: "Bernard Aboba" <[email-masked]>
>CC: [email-masked]
>Subject: Re: [IANA #46166] Request for allocation of NAS-Port-Type values 
>Date: Sun, 10 Dec 2006 14:28:39 -0500
>
>"Bernard Aboba" <[email-masked]> wrote:
> > Is there any existing usage of values 27-29?
>
>   Not that I can see.
>
>   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/>

Envelope-to: [email-masked]
Delivery-date: Sun, 10 Dec 2006 19:40:52 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: [IANA #46166] Request for allocation of NAS-Port-Type values 
cc: [email-masked]
Date: Sun, 10 Dec 2006 14:28:39 -0500
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> Is there any existing usage of values 27-29?

  Not that I can see.

  Alan DeKok.

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

Delivery-date: Sat, 09 Dec 2006 00:30:43 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: [IANA #46166] Request for allocation of NAS-Port-Type values
Date: Fri, 08 Dec 2006 16:29:47 -0800

Is there any existing usage of values 27-29?

>From: "Amanda Baber via RT" <[email-masked]>
>Reply-To: [email-masked]
>To: [email-masked]
>Subject: [IANA #46166] Request for allocation of NAS-Port-Type values Date: 
>Fri, 08 Dec 2006 14:32:40 -0800
>
>Dear Bernard,
>
>It appears that you're requesting three assignments:
>
>Value Description
>-------------------------------------------------
>TBD Wireless - IEEE 802.16 [802.16]
>TBD Wireless - IEEE 802.20 [802.20]
>TBD Wireless - IEEE 802.22 [802.22]
>
>In the registry, values 27-29 are listed as "unassigned."
>Do you know of any reason why these values shouldn't be
>used for these assignments?
>
>Thanks,
>
>Amanda Baber
>IANA

--
to unsubscribe send a message 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, 08 Dec 2006 18:25:47 +0000
Content-class: urn:content-classes:message
Subject: Minutes of the RADEXT WG session at IETF-67
Date: Fri, 8 Dec 2006 13:24:36 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Here are the RADEXT minutes, as posted to the meeting material web site.
Please review for any errors or omissions and comment back to the list.
Thanks!

------------------------------------------------------------------------
IETF 67 RADEXT WG Minutes
Harbor Island I
9:00 - 11:30 AM
Tuesday, November 7, 2006

Note takers: Mauricio Sanchez, Madjid Nakhjiri
Jabber scribe:  Sharon Chisholm
Minutes editor: Dave Nelson

* Meeting started at 9:05am

* Agenda bashing. No changes.

Look for info in http://www.drizzle.com/~aboba/RADEXT/
Look for presentations at IETF meeting material page:
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6=
7

* Bernard went through WG document status.
------------------------------------------
- 7 docs published as RFCs, 4 RADIUS IPv6  MIBs and 2 Dynamic RADIUS
MIBs=20

- some comments on the MIBs came after RFC publications, but mostly
editorial

- Dave described comments made on the RADIUS MIB RFCs relating to
structure and format; No substantive comments, just editorial.

* Wolfgang Beck went through RFC 4590 errata issues.
----------------------------------------------------
- A week after the RFC publication, an implementer sent email about an
error about an IANA type.

- It seems to be easier to change the IANA website than to change the
RFC.

- Bernard asks whether WG feels that errata are severe enough to cause
confusion

- Alan DeKok (Infoblox) feels strongly that there are issues at hand and
should be addressed; He ran into questions.

- Bernard recommends that minor clarifications be made; IANA table
updates.  Feels that a quick spin of document is possible

- Bernard moreover recommends that issues not be treated as errata;
Indicates that a quick "bis" draft and WGLC would be advisable.

* Mauricio Sanchez presented NAS-Filter-Rule and NAS-Traffic-Rule draft
-----------------------------------------------------------------------
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-04.txt=20
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-

- A draft comparison slide was shown between the radext-filter-rules and
radext-filter-05

- the filter-rule draft is simpler since it is based on Diameter,=20

- there are two attributes in the first draft and one attribute in the
second draft.

- NAS-filter-rule status

- 5 new draft versions since IETF66

- resolved issues: attribute length and Diameter-READIUS GW behavior

- open issues: concatenation/splitting

- Base questions: how to split a long rule across multiple rules?

- 6 proposals since IETF 65

- usage of tag field was favorite out of IETF 66.

- It seems that a consensus is being reached quickly on this issue.

- Plan to go to WG last call with 05 draft.

- Bernard: Can we deal with the issue right now? What if Diameter sends
both kinds of attribute?=20

- Implementers of Diameter come and say what use does it have in RADIUS
and why?

- Comment: <silence>

- Bernard: Anybody has an objection to have a MUST not use both here?

- Comment: <silence>

- Bernard: OK, done.=20

- NAS-traffic-rule status

- no new drafts since IETF 65

- Editor to go talk to individuals to get opinions

- big variety of open issues existed:
   -- accounting issue mostly closed waiting for 3GPP insights
   -- NAS filter rule accounting

- Diameter compatibility=20

- Bernard: There is a VLAN attribute draft that is not just for RADIUS
but also for Diameter.

- AD: Pointed the charter to Dave: All RADIUS functions must be
compatible with=20

- Diameter and attributes must be reused as much as possible.

- Next step: To close the issues to talk to issue owners in the next
couple of weeks

- new version 02 within a month

* Alan DeKok presented RADIUS issues & fixes draft
--------------------------------------------------
- A list of clarification (e.g. on EAP), a list of correction, question
relatively little discussion or disagreement on list about the issues
and fixes draft.

- Alan asks the group how many have people have read the draft; Few
people have

- Dave suggests we take it to last call to force everyone to read it

- Someone pointed out that this draft is not a WG item, yet is already
being considered for last call. Bernard contends that this has been done
in the past to take an individual submission and turn it into a WG item
at the same time it went to last call.

-  Dave asks group whether anyone objects to taking document to working
group last call.  No one does.  Dave and Bernard to confirm consensus on
email list.=20

* Dave presented NAS-Port-Type attribute draft
----------------------------------------------
- Dave asks group whether to take document to WG last call

- Pasi Eronen says that draft has five lines of technical content, just
ship it.

- Bernard points out that the RADIUS IANA Considerations in RRC 3575
says additional values for attributes can be approved by designated
experts do not require a published specification.=20

- Bernard suggests that it not be published as an RFC to reduce IASA /
RFC Editor publishing costs.=20

- Simply request the values from IANA.

- WG chairs will provide IANA with an expert review contact.

- AD: As long as we have regular get-togethers where people oversee
these=20
assignments.

* Bernard presented WLAN attributes draft
-----------------------------------------
- Some attributes already assigned in RFC 4072

- Pre-auth support
  -- It was discussed in HOKEY BOF
  -- There is a use case in 802.11 and there are some tricky issues

- SSID attribute

- Pre-auth key lifetime attribute
  -- A STA pre-auths with an AP, but it does not know what the AP SSID
is, and the AAA server does not know the diff between pre-auth and full
auth.
  -- Situation, when the admin want to cache the keys just for a short
time when it is pre-auth compared to longer time for regular auth.

- Bernard asked group whether to make draft an official WG item

- Dave questions whether to split document into attributes that are
necessary now and those that need further definition.  Draft is already
behind from a milestone perspective. Bernard points out that IEEE
802.11r group may have requirements, but is busy with other issues at
this point.

- Dave asks group whether group has preference on what to do with
document

- Majid points out that HOKEY does have dependency on AAA pre-auth
requirements that from a timeline perspective are further out.  =20

- Majid asks about the process of getting comments from .11r group;
Bernard explains the formal liaison process to request comments

- Bernard suggests that we submit a liaison request to IEEE 802.11r to
get them to review document.

* Glen Zorn presented Extended RADIUS attributes draft
------------------------------------------------------
- Glen asks how many people have read it; Only a couple have

- Alan DeKok points out that he has comments, but has separate
presentation for his points.=20

- Dave asks Glen how extended attributes should be treated by servers
not supporting extended attributes; Glen replies that servers that don't
understand the attribute will ignore it, whether that's a problem is a
different question. Glen expects all contemporary servers to support
extended attributes.  If ancient servers can't, then so be it.=20

- Dave asks whether having just an 8-bit type value for extended
attributes is too small.  An 8-bit value would only allow for 256
additional extended attributes.  Glen believes this is good because it
would force conservation and have a built-in penalty for creating new
attributes willy-nilly.  If the type space were once again exhausted, a
new vendor-id would have to be allocated.  =20

* Alan DeKok goes through his commentary of extended RADIUS
-----------------------------------------------------------
- Glen agrees with the argument that a non-zero vendor-ID should be
allocated;  He went on to say that GEOPRIV should be given their own
vendor-id;  He argues that the value of 0 traditionally means IETF.

- Dave points out that it's unclear of whether multiple vendor-id values
can be registered to a singe entity; Someone in group says that it is
possible.

- Dave made comment on tag and feels that it is of value; It's not a
con. Alan agrees that it's the most practical option available; Points
out that EAP clients and servers are currently forced to mangle
attributes.  It would be useful just to do it once.=20

- Glen points out that Alan's presentation isn't as much a criticism as
an exposition of issues;  Questions whether there will be any short-term
decision to make progress;  Dave responds that a large block of time was
allocated up front but asks opinion of group.  Alan says he's fine with
the state of the document other than vendor-id.  Suggests that group
pick a vendor-id value and have some preliminary interoperability
testing.  Bernard says that the extended attribute draft is necessary to
be able to complete ongoing attribute work;  Code space will run out
based on proposed work and something must be done.=20

- Someone points out that granting control code space control to other
groups=20
(other than RADEXT) needs to be considered.   Bernard points out that
there are already something like 12 different dialects of RADIUS.  IESG
needs to answer whether this is acceptable or not.

- Glen suggests that allocation of vendor-id/type values be separated
out from format issues.  Bernard nodded in agreement.

- Dave opens floor to ask group what should be done with document

* Majid points out that other groups do need attributes, groups can't
wait.  Sees value in allowing groups control their own destiny and
manage their own attribute space.

* Glen recommends cutting to the chase and making document a WG item.=20

* Bernard recommends that a new version with local RADEXT issues be
addressed, thereafter document should be open to other groups for
review.

* Glen points out that making document a WG item would force control of
document by greater group than where it is as an individual submission.
Glenn wants to be under the control of the chairs.

* Group agrees to make a new version and distribute to greater
community.

* Dave presents RADIUS guidelines draft
---------------------------------------
- Bernard comments that the objectionable part of the draft is to try to
deprecate old RFC and say that current way RADIUS works/designed is bad.
Objective of document should be limited to things that prevent
deployment, such as those things that force server code change issues.
Document should strive for architectural purity, since most don't force
server code changes.

- Bernard wishes that document be basis for other groups to define their
own attributes that adhere to guidelines and not force groups to pass
their attributes through RADEXT.   Dave counters that MIB example is not
a valid example.

- Bernard suggests that document remove extended attribute discussion
and other things people find objectionable.  Take a look at the core and
see whether enough remains to take on as official WG item.

- Glen Z. and Hannes T. step forward to volunteer as co-editors of
document

* Dave presents crypto-agility work item
----------------------------------------
- Glen questions where security requirements are documented.  Dave
responds that Russ said to write security requirements as stated to
point to SAAG=20

- Hannes T. asks whether this work item would provide end-to-end
security between client and server.  Dave and Bernard say no.  This
document only describes how new crypto algorithms can be used in the
current protocol framework. Dave states that genesis is document is to
address the security issues arising from the recent identified
weaknesses in MD5. =20

- Someone comments that if addressing MD5 issues is really the problem
at hand, then the document should state that as the scope.  Feels
current document has many general requirements. Bernard points out that
there are probably two paragraphs that actually address the MD5 issue.
Feels that document needs to be explicit in what it intends to fix.
Bernard recommends title 'Crypto-Agility Goals in RADIUS'

- Someone wanted confirmation that this work item was not undertaking a
huge gap analysis.  Bernard says emphatically no.=20

- Joe S. is concerned by 'negotiation'.  Dave contends that there is
already a very simple 'negotiation' present in RADIUS.   The client
proposes via hint attributes in the Access-Request. The server disposes
via provisioning attributes in the Access-Accept.  This work item would
not upset the balance in RADIUS.

- Glen concerned about the recommending MD5 as lowest common denominator
when no other crypto supported.  Feels like a security issue to him.

* Hannes presented GEOPRIV cross-WG review item
-----------------------------------------------
- Bernard asked about document status.

- Hannes unsure and would need to look at the issue tracker.

* Hannes presented RADIUS MIPv6 draft
-------------------------------------
- Glen asks whether acceptance of extended radius attribute draft will
have impact. Hannes says it depends.  Glen feels that remaining radius
standard code-space should be set aside for future use, a conservation
measure

- Dave says that RFC 3575 would need to be updated to ensure reservation
of remaining code space.

* Vidya presented handover key draft
------------------------------------
- Group discussed what to do with draft; Bernard and Jari agree that
this draft conceivably create a new authentication method for RADIUS,
just like digest authentication.=20

- Glen points out that an existing individual submission, key request,
that presumably does some of the same things Vidya's draft provides.
Questions arises on whether mechanics used by Glen's draft are similar
to handover draft.  Glen suggests that key request draft be reviewed for
changes that would address handover draft.=20

- Bernard comments he doesn't understand how this draft has anything to
do with keying. Vidya explains how key material is transferred as part
of handover exchange. =20

- Bernard asks whether handshake is stateful or stateless.  Vidya says
it's stateless.  Bernard now sees parallels to other authentication
transactions, like http digest authentication.=20

- Bernard asks what is the question MIPSHOP desires RADEXT to answer.
Is it the case that all options needs to be reviewed, just one? Jari
says that there may be some of both.

- Someone expresses concern of using RADIUS as a key server.  Vidya
points out that key material is not tied to the RADIUS server and can be
logically separated from server.

- Glen points out that this draft is shoehorning a function not serviced
well by RADIUS; It's key exchange protocol that happens to use RADIUS.
Glen doesn't feel this is the way to go.

* Dave notes that we are over our allotted time, so remaining
discussion, as well as the remaining agenda item will need to be
discussed on the WG mailing list.

Regards,
=20
Dave
=20
David B. Nelson
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
Phone: (978) 684-1330 =20
E-mail: [email-masked]
=20

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

Delivery-date: Fri, 08 Dec 2006 15:06:10 +0000
Content-class: urn:content-classes:message
Subject: Upcoming Diameter Interop
Date: Fri, 8 Dec 2006 16:05:06 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi all,=20

our interop event planning is finished.
=20
WHAT? Diameter Interoperability Event

Further information regarding agenda, test framework, venue and travel
information as well as on-line registration are available at:
http://www.diameterinterop.com
 =20
WHEN? January 29 - February 2, 2007=20
=20
WHERE? Orlando, Florida (hosted by IntelliNet Technologies)
=20
WHO? Companies implementing Diameter, Diameter extensions and Diameter
applications

A copy-and-paste from the press announcement:=20
"=20
The Diameter Interoperability Event provides an excellent opportunity
for vendors of the Diameter protocol and applications to test their
implementations in a friendly setting and get a better understanding of
the protocol behavior. Discussions with peers and the experts from DiME
provide a forum to realize an industry leading implementation. We are
expecting a substantial number of participating companies and products,
including the base protocol from several vendors as well as a broad
range of applications using the protocol. This offers you the
opportunity to further refine your own products and assure their
interoperability.
"

IMPORTANT: Please register at http://www.diameterinterop.com=20
(deadline: January 15, 2007)=20

Ciao
Hannes & 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/>

Envelope-to: [email-masked]
Delivery-date: Thu, 07 Dec 2006 23:48:20 +0000
To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'RADIUS Filter Rule Attribute' to Proposed Standard  (draft-ietf-radext-filter) 
Reply-To: [email-masked]
Cc: <[email-masked]>
Message-Id: <[email-masked]>
Date: Thu, 07 Dec 2006 18:47:36 -0500

The IESG has received a request from the RADIUS EXTensions WG to 
consider the following document:

- 'RADIUS Filter Rule Attribute '
   <draft-ietf-radext-filter-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-12-21.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-06.txt

--
to unsubscribe send a message 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, 05 Dec 2006 21:19:13 +0000
Content-class: urn:content-classes:message
Subject: Document review request
Date: Tue, 5 Dec 2006 16:18:22 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

At the risk of a duplicate posting, I'm forwarding this message again,
as it seems to be "stuck" somewhere....

-----Original Message-----
From: Nelson, David=20
Sent: Tuesday, December 05, 2006 4:03 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Consideration of draft-lior-radius-attribute-type-extension-01
in RADEXT WG

The RADEXT WG has a charter deliverable for an extended form of RADIUS
attribute.  The apparent consensus in the WG is to solve a very simple
set of problems in this space, including the pending exhaustion of the
standard RADIUS attribute IDs, a consistent mechanism for application
layer fragmentation and reassembly for Diameter interoperability, and a
consistent mechanism for grouping of attributes for data structuring,
also for Diameter interoperability.

Given the list of proposed work in RADEXT and other IETF WGs with RADIUS
extensions work on their charters, it is conceivable that we might
exhaust the existing IANA RADIUS registry for Attribute Types fairly
soon.  Therefore, this work is considered to be of some urgency.

The structure of the extended attribute format currently under
consideration may require changes in various RADIUS extensions drafts in
RADEXT and other working groups.   This assumes that at least some of
these documents will ultimately use the RADIUS extended attribute
allocations.

The RADEXT WG Chairs are requesting that the RADEXT WG and all other
affected WGs please review the following document:

http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext
ension-01.txt

Please comment as to whether this document is ready for adoption as a
RADEXT WG work item, and provide comments as to suggested changes or
improvements.  Please use the RADEXT Issue Tracker format template,
found at

http://www.drizzle.com/~aboba/RADEXT/

and submit your comments to the RADEXT WG mailing list with the keyword
"New Issue" in the subject header.

[email-masked]

Please respond by December 22, 2006.  Once all the resultant open issues
have been resolved, the RADEXT WG Chairs expect that a WGLC will be
issued on the revised draft soon thereafter, early in 2007.

Thank you, in advance, for your timely review, especially during this
busy holiday season.

Regards,
=20
Dave Nelson
Bernard Aboba

Co-Chairs, RADEXT WG

--
to unsubscribe send a message 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, 05 Dec 2006 21:03:52 +0000
Content-class: urn:content-classes:message
Subject: Consideration of draft-lior-radius-attribute-type-extension-01 in  RADEXT WG
Date: Tue, 5 Dec 2006 16:02:41 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

The RADEXT WG has a charter deliverable for an extended form of RADIUS
attribute.  The apparent consensus in the WG is to solve a very simple
set of problems in this space, including the pending exhaustion of the
standard RADIUS attribute IDs, a consistent mechanism for application
layer fragmentation and reassembly for Diameter interoperability, and a
consistent mechanism for grouping of attributes for data structuring,
also for Diameter interoperability.

Given the list of proposed work in RADEXT and other IETF WGs with RADIUS
extensions work on their charters, it is conceivable that we might
exhaust the existing IANA RADIUS registry for Attribute Types fairly
soon.  Therefore, this work is considered to be of some urgency.

The structure of the extended attribute format currently under
consideration may require changes in various RADIUS extensions drafts in
RADEXT and other working groups.   This assumes that at least some of
these documents will ultimately use the RADIUS extended attribute
allocations.

The RADEXT WG Chairs are requesting that the RADEXT WG and all other
affected WGs please review the following document:

http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext
ension-01.txt

Please comment as to whether this document is ready for adoption as a
RADEXT WG work item, and provide comments as to suggested changes or
improvements.  Please use the RADEXT Issue Tracker format template,
found at

http://www.drizzle.com/~aboba/RADEXT/

and submit your comments to the RADEXT WG mailing list with the keyword
"New Issue" in the subject header.

[email-masked]

Please respond by December 22, 2006.  Once all the resultant open issues
have been resolved, the RADEXT WG Chairs expect that a WGLC will be
issued on the revised draft soon thereafter, early in 2007.

Thank you, in advance, for your timely review, especially during this
busy holiday season.

Regards,
=20
Dave Nelson
Bernard Aboba

Co-Chairs, RADEXT WG

--
to unsubscribe send a message 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, 05 Dec 2006 20:51:41 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Status of draft-yan-radext-port-type-01.txt
Date: Tue, 05 Dec 2006 12:50:59 -0800

I sent email to IANA, cc:'ing the document author, asking for the allocation 
to be approved.

--
to unsubscribe send a message 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, 05 Dec 2006 20:36:51 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Status of draft-yan-radext-port-type-01.txt
Date: Tue, 05 Dec 2006 12:35:50 -0800

>WiMAX Forum needs IEEE 802.16 NAS port type assignment for Release 1 (which
>is planned to be finalized within a month). It'd be appreciated if the IANA
>assignment process can be expedited.

As Dave noted, there is no problem with this request, which was discussed on 
the RADEXT WG list quite a while ago, as well as at IETF 67.

Has a request been sent to IANA?

--
to unsubscribe send a message 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, 05 Dec 2006 16:18:39 +0000
Content-class: urn:content-classes:message
Subject: RE: Status of draft-yan-radext-port-type-01.txt
Date: Tue, 5 Dec 2006 11:17:45 -0500
From: "Nelson, David" <[email-masked]>
To: "CTO YAN Renxiang" <[email-masked]>
Cc: <[email-masked]>

I think the specific action item should be for the author of this I-D
(copied on this e-mail) to extract the salient information from the I-D,
and submit a written request to IANA for allocation within the RADIUS
registry, as per the provisions of RFC 3575.  The salient information
would be a precise and concise description of the port types being
requested, such that it will be self-documenting in the RADIUS IANA
registry.

For example:

   NAS-Port-Type Value

   This request is for new values for the RADIUS NAS-Port-Type=20
   attribute from the RADIUS Types registry
   [<http://www.iana.org/assignments/radius-types>], according to
   the allocation policy given in [RFC3575].

   This request is for the following values:

     Value     Description
   -------------------------------------------------
     TBD     Wireless - IEEE 802.16 [802.16]
     TBD     Wireless - IEEE 802.20 [802.20]
     TBD     Wireless - IEEE 802.22 [802.22]

> It would be very much appreciated if NAS-Port-Type for 802.16 is
> quickly assigned in the RADEXT chairs' recommended way, because IEEE
> 802.21 specification has some dependency on NAS-Port-Type values.
>
> > > What is the status of this I-D?
> > >
> > > I think I-D is important because it defines NAS-Port-Type
> > > for several new wireless technologies including 802.16.
> >
> > I'm still working on the minutes of the RADEXT WG session at
IETF-67,
> > however, the discussion of this document in the meeting can be
> > summarized as follows:
> >
> > -- The proposal to register new code points for the NAS-Port-Type
> > attribute in the RADIUS IANA registry is fine.
> >
> > -- This attribute does not require a published specification.  We
can
> > save the cost of publishing an RFC.
> >
> > -- The recommendation of the WG Chairs was to submit a request to
IANA
> > for the assignment, and the RADEXT Chairs will work with IANA to see
> > that any necessary expert review is provided.

--
to unsubscribe send a message 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, 05 Dec 2006 16:13:06 +0000
From: "Alper Yegin" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, "'Yoshihiro Ohba'" <[email-masked]>, <[email-masked]>
Subject: RE: Status of draft-yan-radext-port-type-01.txt
Date: Tue, 5 Dec 2006 17:59:41 +0200

WiMAX Forum needs IEEE 802.16 NAS port type assignment for Release 1 (which
is planned to be finalized within a month). It'd be appreciated if the IANA
assignment process can be expedited.

Regards,

Alper, on behalf of WiMAX Forum NWG Security team

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Nelson, David
> Sent: Tuesday, December 05, 2006 5:36 PM
> To: Yoshihiro Ohba; [email-masked]
> Subject: RE: Status of draft-yan-radext-port-type-01.txt
> 
> Yoshihiro Ohba writes...
> 
> > What is the status of this I-D?
> >
> > I think I-D is important because it defines NAS-Port-Type
> > for several new wireless technologies including 802.16.
> 
> I'm still working on the minutes of the RADEXT WG session at IETF-67,
> however, the discussion of this document in the meeting can be
> summarized as follows:
> 
> -- The proposal to register new code points for the NAS-Port-Type
> attribute in the RADIUS IANA registry is fine.
> 
> -- This attribute does not require a published specification.  We can
> save the cost of publishing an RFC.
> 
> -- The recommendation of the WG Chairs was to submit a request to IANA
> for the assignment, and the RADEXT Chairs will work with IANA to see
> that any necessary expert review is provided.
> 
> 
> --
> to unsubscribe send 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, 05 Dec 2006 16:02:25 +0000
Date: Tue, 05 Dec 2006 11:01:13 -0500
From: Yoshihiro Ohba <[email-masked]>
Subject: Re: Status of draft-yan-radext-port-type-01.txt
To: "Nelson, David" <[email-masked]>
Cc: Yoshihiro Ohba <[email-masked]>, [email-masked]

Thank you for the information.  

It would be very much appreciated if NAS-Port-Type for 802.16 is
quickly assigned in the RADEXT chairs' recommended way, because IEEE
802.21 specification has some dependency on NAS-Port-Type values.

Best Regards,
Yoshihiro Ohba

On Tue, Dec 05, 2006 at 10:36:21AM -0500, Nelson, David wrote:
> Yoshihiro Ohba writes...
> 
> > What is the status of this I-D?
> > 
> > I think I-D is important because it defines NAS-Port-Type
> > for several new wireless technologies including 802.16.
> 
> I'm still working on the minutes of the RADEXT WG session at IETF-67,
> however, the discussion of this document in the meeting can be
> summarized as follows:
> 
> -- The proposal to register new code points for the NAS-Port-Type
> attribute in the RADIUS IANA registry is fine.
> 
> -- This attribute does not require a published specification.  We can
> save the cost of publishing an RFC.
> 
> -- The recommendation of the WG Chairs was to submit a request to IANA
> for the assignment, and the RADEXT Chairs will work with IANA to see
> that any necessary expert review is provided.
> 
> 
> 

--
to unsubscribe send a message 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, 05 Dec 2006 15:38:30 +0000
Content-class: urn:content-classes:message
Subject: RE: Status of draft-yan-radext-port-type-01.txt
Date: Tue, 5 Dec 2006 10:36:21 -0500
From: "Nelson, David" <[email-masked]>
To: "Yoshihiro Ohba" <[email-masked]>, <[email-masked]>

Yoshihiro Ohba writes...

> What is the status of this I-D?
>=20
> I think I-D is important because it defines NAS-Port-Type
> for several new wireless technologies including 802.16.

I'm still working on the minutes of the RADEXT WG session at IETF-67,
however, the discussion of this document in the meeting can be
summarized as follows:

-- The proposal to register new code points for the NAS-Port-Type
attribute in the RADIUS IANA registry is fine.

-- This attribute does not require a published specification.  We can
save the cost of publishing an RFC.

-- The recommendation of the WG Chairs was to submit a request to IANA
for the assignment, and the RADEXT Chairs will work with IANA to see
that any necessary expert review is provided.

--
to unsubscribe send a message 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, 05 Dec 2006 15:17:05 +0000
Date: Tue, 05 Dec 2006 10:15:49 -0500
From: Yoshihiro Ohba <[email-masked]>
Subject: Status of draft-yan-radext-port-type-01.txt
To: [email-masked]

What is the status of this I-D?  

I think I-D is important because it defines NAS-Port-Type 
for several new wireless technologies including 802.16.

Regards,
Yoshihiro Ohba

--
to unsubscribe send a message 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, 04 Dec 2006 23:36:37 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Inclusion of Filter-Id and NAS-Filter-Rule AVPs
Date: Mon, 04 Dec 2006 15:35:13 -0800

>What happens in the instance that a diameter->radius gateway can't 
>translate a packet?

RFC 4005 Section 9 describes two situations in which translation may not be 
possible:

"  Although the Diameter protocol is in many ways a superset of RADIUS
   functions, a number of RADIUS representations are not allowed, so
   that new capabilities can be used without the old problems.

   There are primarily two different situations that must be handled:
   one in which a RADIUS request is received that must be forwarded as a
   Diameter request, and another in which the inverse is true.  RADIUS
   does not support a peer-to-peer architecture, and server-initiated
   operations are generally not supported.  See [RADDynAuth] for an
   alternative.

   Some RADIUS attributes are encrypted.  RADIUS security and encryption
   techniques are applied on a hop-per-hop basis.  A Diameter agent will
   have to decrypt RADIUS attribute data entering the Diameter system,
   and if that information is forwarded, the agent MUST secure it by
   using Diameter specific techniques."

>There must be some exception path, right?

My reading of RFC 4005 is that other than these situations, that RADIUS 
packets are expected to be translatable to Diameter.  RADIUS does not have a 
mechanism to enable a NAS to indicate an error in response to an 
Access-Accept, so that if RADIUS packets are not translatable it would 
difficult to communicate this to a RADIUS server.  If the NAS does a silent 
discard, then no Accounting-Request is generated.  That's the only 
indication that a RADIUS server will have that the attributes sent were 
unacceptable.

>If so, why couldn't we leave in the MUST NOT for mixture of filter-id and 
>nas-filter-rule
>attributes and have the gateway generate an error to avoid wedging both 
>attributes into a radius >packet?

On the Diameter side, behavior will depend on whether the gateway silently 
discards the RADIUS packet (in which case no error would be sent to the 
Diameter NAS) or whether it acts as though an Access-Reject were received 
(in which case the Diameter equivalent of the Reject would be sent to the 
NAS).

BTW, here is what RFC 2119, Section 6 says about MUST and MUST NOT:

"   Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability."

In this particular case, there does not appear to be an interoperability 
issue (in fact, the MUST NOT might create an issue), so we are left with 
assessing the potential for causing harm.

--
to unsubscribe send a message 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, 04 Dec 2006 20:51:19 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-filter-06.txt 
Date: Mon, 04 Dec 2006 15:50:01 -0500

--NextPart

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

	Title		: RADIUS Filter Rule Attribute
	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-filter-06.txt
	Pages		: 10
	Date		: 2006-12-4
	
While RFC 2865 defines the Filter-Id attribute, this requires that
   the Network Access Server (NAS) be pre-populated with the desired
   filters.  However, in situations where the server operator does not
   know which filters have been pre-populated, it useful to specify
   filter rules explicitly.  This document defines the NAS-Filter-Rule
   attribute within the Remote Authentication Dial In User Service
   (RADIUS).  This attribute is based on the Diameter NAS-Filter-Rule
   Attribute Value Pair (AVP) described in RFC 4005, and the
   IPFilterRule syntax defined in RFC 3588.

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Sat, 02 Dec 2006 01:26:20 +0000
Content-class: urn:content-classes:message
Subject: RE: Inclusion of Filter-Id and NAS-Filter-Rule AVPs
Date: Fri, 1 Dec 2006 19:24:45 -0600
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0226_01C7156D.984C8A40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

What happens in the instance that a diameter->radius gateway can't translate
a packet?  There must be some exception path, right?  If so, why couldn't we
leave in the MUST NOT for mixture of filter-id and nas-filter-rule
attributes and have the gateway generate an error to avoid wedging both
attributes into a radius packet?

It just feels wrong to have to carry forward diameter sloppiness.  

MS

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Monday, November 27, 2006 11:59 AM
> To: [email-masked]
> Subject: RE: Inclusion of Filter-Id and NAS-Filter-Rule AVPs
> 
> Bernard Aboba writes...
>  
> > Perhaps the best solution is simply to say this in the document.
> 
> That may, in fact, be the best we can do.
> 
> >  For example:
> > 
> > "The NAS-Filter-Rule attribute is not intended to be used 
> concurrently 
> > with any other filter rule attribute, including Filter-Id (11) and 
> > NAS-Traffic-Rule [Traffic] attributes.
> > NAS-Filter-Rule and NAS-Traffic-Rule attributes MUST NOT 
> appear in the 
> > same RADIUS packet.  If a NAS-Traffic-Rule attribute is 
> present, a NAS 
> > implementing this specification MUST silently discard 
> NAS-Filter-Rule 
> > attributes, if present.  Filter-Id and NAS-Filter-Rule attributes 
> > SHOULD NOT appear in the same RADIUS packet.
> >
> > Given the absence in [RFC4005] of well-defined precedence rules for 
> > combining Filter-Id and NAS-Filter-Rule attributes into a 
> single rule 
> > set, the behavior of NASes receiving both attributes is 
> undefined, and 
> > therefore a RADIUS server implementation cannot assume a consistent 
> > behavior."
> 
> This seems OK to me.
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

------=_NextPart_000_0226_01C7156D.984C8A40--

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