Subject: RADEXT WG last call on RADIUS Attributes for Filtering and Redirection

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Dec 2007 11:53:16 -0800

On July 5, 2007 the RADEXT WG first began WG last call on "RADIUS Attributes for 
Filtering and Redirection":
http://ops.ietf.org/lists/radiusext/2007/msg00494.html
http://ops.ietf.org/lists/radiusext/2007/msg00541.html

This WG last call was to last until Monday, July 23, 2007.
During the WG last call, only a single comment was received, from Hannes 
Tschofenig:
http://ops.ietf.org/lists/radiusext/2007/msg00496.html

No other messages were posted to the RADEXT WG mailing list indicating that 
WG participants had read the document.

Given the light level of participation, the WG last 
call was extended for 10 more days (until August 28, 2007):
http://ops.ietf.org/lists/radiusext/2007/msg00633.html

No comments were received during that WG last call either.

Given that no comments have been received during the last two RADEXT WG last calls, we are going to bring the document to RADEXT WG call again.  This RADEXT WG last call will last until January 15, 2008. 

If you have read the 
document and approve of its publication as a Proposed Standard, please post 
your approval to the list, even if you have no comments to provide.
If you have comments, please provide them in the format described on the 
RADEXT WG Issues page:
http://www.drizzle.com/~aboba/RADEXT/

---

From: Alan DeKok <[email-masked]>
Date: Fri, 28 Dec 2007 12:13:09 +0100

Bernard Aboba wrote:
> Given that no comments have been received during the last two RADEXT WG
> last calls, we are going to bring the document to RADEXT WG call again. 
> This RADEXT WG last call will last until January 15, 2008.

  Some comments:

1.4:

  It may be useful to note that an Accounting-Request packet MAY be
generated when the NAS cannot apply an attribute in the Access-Accept.
The Accounting Request MAY contain Error-Cause, with value "Unsupported
Attribute" (401), and Acct-Status-Type = Stop, Acct-Terminate-Cause =
NAS-Error.  This serves as limited capability feedback.

Page 12:

        "any"       Keyword for 0.0.0.0/0 or the IPv6 equivalent.

  The IPv6 equivalent is...?  It could be specified here.

        "ipoptions" Match if the IP header contains the comma separated
                     list of options specified in spec.  The supported

  Can we allow hexadecimal specifications of options, too?  This would
be useful, and would match the rest of the document (e.g. IP proto as a
number, icmptypes, ...)

  A similar comment applies for tcpoptions.

3.1:

  Acct-NAS-Traffic-Rule is a complex attribute not meeting the
suggestions in the guidelines document.  Is there another way to achieve
the same end?  Since the extended attributes draft is still pending, I
think the answer is "no".

1.3:

  Capability advertisement could be done in a limited way by permitting
NAS-Traffic-Rule in an Access-Request.  Allowing this has practical
uses, too.  e.g. a WiFi hotspot (walled garden) could advertise upstream
 that it is *currently* blocking traffic, by sending it's filter rule:

    NAS-Traffic-Rule = "v1 redirect http://....local-login/"

  Similarly, a NAS requiring 802.1x could send:

   NAS-Traffic-Rule = "v1 permit inout l2:ether2:0x888e from any to
NAS-MAC-address"

  i.e. EAPoL is permitted, everything else is discarded.

  This information is useful for upstream servers, and can help them
make better policy decisions.  It solves a serious problem in many
current deployments, where you have no idea what the NAS is currently
doing...

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