[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADEXT WG last call on draft-ietf-radext-ieee802-00.txt
My WGLC comments on the subject draft are included herein.
--------------
1. Introduction
Within the confines of RADIUS authentication, authorization, and
accounting (AAA) environments, there is a general dearth of
standardized RADIUS attributes to limit user access using dynamic
VLANs, filters or redirection.
Could we change "a general dearth of" to "a requirement for"? It sounds
more positive.
-------------
User traffic redirection is supported with or without tunneling.
Tunneling support is provided using the tunnel attributes defined
in [RFC2868]. Redirection of traffic in mid-session may break
applications.
Remove "or without". I thought we had agreed to remove support for
non-tunneled IP redirection.
---------------
IEEE 802.1X-2004 [IEEE8021X] provides "network port
authentication" for IEEE 802 [IEEE802] media, including Ethernet
[IEEE8023], Token Ring and 802.11 wireless LANs [IEEE80211i].
Remove this sentence as it appears in the second paragraph as well.
---------------
1.1 Terminology
The following definitions are not used in the draft:
Access Point
Association
Station
--------------
2. Overview
The first paragraph is awkwardly worded. Perhaps the following would be
an improvement.
In this section we provide an elaboration of the requirements
briefly described in the Introduction.
------------
For example, the user maybe on
a prepaid plan and all the resources have been used up.
Change "maybe" to "may be" and "resources have" to "credit balance has".
--------------
For example, the ability to block and
redirect traffic is required for TCP users, cell phone users,
WiFi users.
Change "TCP users" to "IP users".
-------------
Change:
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(TBD) AVP. For this reason, this document introduces
NAS-Filter-Rule(TBD) to RADIUS.
To:
As pointed out by [NASREQ] the use Filter-Id is not roaming
friendly and it is recommended that instead one should adapt
the Diameter NAS-Filter-Rule AVP as a RADIUS NAS-Filter-Rule(TBD)
attribute.
-----------
2.1. Capability Advertisement
RADIUS does not currently define a method by which a NAS can
advertise its capabilities and in many instances, it would be
desirable for the home network to know what capabilities are
supported by the NAS to ensure proper operational behavior. The
attributes defined in this document are intended to be used to
enforce policy by the NAS. If a NAS does not recognize these
attributes it will most likely ignore them and the desired policy
will not be enforced. A method for the NAS advertising the
capability to support these attributes would help the RADIUS
server understand if the intended policies can be enforced. As a
result, the attributes in this document, in particular NAS-Filter-
Rule(TBD), can benefit from capability advertisement, if
available.
Should this entire section perhaps be part of the Security
Considerations?
-----------
Change:
Similarly, if a NAS conforming to this specification receives a
CoA message that contains an attribute from this document that it
does not recognize or cannot apply, it MUST NOT terminate the
session and MUST generate a CoA-NAK packet with ERROR-CAUSE(101)
set to "Unsupported Attribute"(401).
To:
Similarly, if a NAS conforming to this specification and also
conforming to RFC 3576 [RFC3576] receives a CoA message that
contains an attribute from this document that it does not
recognize or cannot apply, it MUST NOT terminate the session and
MUST generate a CoA-NAK packet with Error-Cause (101) set to
"Unsupported Attribute"(401).
------------
3.1. Egress-VLANID
Integer
The Integer field is four octets in length. The format of the
Integer field consists of two parts, the first consuming high-
order octet and the second consuming the remaining three lower-
order octets. The high-order octet field indicates if the
VLANID is allowed for tagged or untagged packets. The second
part is the 12-bit 802.1Q VLAN VID value that has been padded
out to consume the remaining three lower-order octets. A
sample encoding follows:
This is not an Integer data type. It is a multi-field Octet String
(complex data type).
-----------
3.4. User-Priority-Table
Description
IEEE 802.1D clause 7.5.1 discusses how to regenerate (or re-
map) user priority on frames received at a port.
Change "IEEE 802.1D" to "IEEE 802.1D [IEEE8021D]".
-----------
3.5. NAS-Filter-Rule
Furthermore, the concatenated filter list
must abide to the following rules of precedence and ordering:
1) A flush rule MUST appear before all other rule types.
Change "A flush rule" to "A flush rule, when present,".
2) Base encapsulation filter rules MUST appear after a
flush rule and before IP tunnel, HTTP redirect, IP
filter, and/or HTTP filter rules.
Change "a flush rule" to "any flush rule".
dir "in" is from the terminal, "out" is to the
terminal, "inout" is from and to the terminal.
The term "terminal" is not defined in the draft. I suspect it
identifies the network entity which contains the IEEE 802.1X Supplicant
function, but this should perhaps be clarified.
General comment: I'd much rather that we use ABNF to define the
NAS-Filter-Rule formal syntax, however I'm not prepared to submit that
text just now. :-)
------------
4.1. Acct-NAS-Filter-Rule
The first eight octets of this string are used for a 64-bit
value of the rule counter. The remaining octets are used to
specify which filter rule the counter value is for. The rule
specification MUST conform to the syntax rules specified for
NAS-Filter-Rule[TODO].
Provide the [TODO].
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>