Issue 114: WGLC Review

[Bernard Aboba <aboba@internaut.com>]

Issue 114: WGLC Review
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: August 10, 2005
Reference:
Document: IEEE802-00
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Accounting

I do not understand the purpose of the accounting functionality in the
draft.

The focus of this document is VLAN attribute, priority and filtering. How
does Acct-EAP-Auth-Method fit into that? I think this is a leftover WLAN
attribute which should be removed.

Acct-NAS-Filter-Rule attribute. The purpose of this attribute is to keep
count
of hits on filter rules. This duplicates functionality under development
in
other WGs such as IPFIX, and so I'd question whether this is appropriate
functionality for RADIUS accounting.

Overview

I do not understand the purpose of Section 2, Overview. Most of it seems
like it could be deleted without losing anything.

" As described in the Introduction section, it may be desirable to a
control user's access to network resources (e.g. the Internet)
with greater standardized explicitness than what current RADIUS
attributes provide. In this section we will examine these
requirements in more detail. "

What is "standardized explicitness?" The filtering functionality defined
in this document is no more granular than what is already supported in the
Filter-ID attribute. So this sentence seems inaccurate.

" Besides IEEE 802.1X networks, there is a corollary need within
Internet Service Provider (ISP) environments for standardized
authorization attributes."

What is an IEEE 802.1X network? Do you mean an IEEE 802 network?
RADIUS has supported authorization attributes for a long time, this
sentence makes it seem like this is the first time that authorization
attributes have been defined in RADIUS. Also, mixing ISPs and IEEE 802
functionality in the same document is a symptom of a deeper problem which
Greg Weber has brought up -- it is not clear what devices need to do in
order to comply with the document, if compliance is even possible.

" From time to time, an ISP requires to
restrict a user's access to the Internet and redirect their
traffic to an alternate location. For example, the user maybe on
a prepaid plan and all the resources have been used up."

Since this implies that the document is actually aimed at prepaid,
I think you need a reference here.

The ability to block user's traffic is required at service
initiation and once service has been established. These
capabilities must also be available across access technologies and
various business scenarios. For example, the ability to block and
redirect traffic is required for TCP users, cell phone users, WiFi
users. As well, this capability must work whether the user is in
their home network or roaming in a visited network which may or
may not have a direct roaming relationship with the user's home
network.

This seems like a list of requirements that this document was supposed to
satisfy. However, I would question whether in fact these requirements
are legitimate. This documented started out focussed on IEEE 802
functionality -- how did it somehow morph into a document relating to
prepaid, portals, etc.?

" Blocking access refers to setting up access control rules at the
NAS such that when the user initiates IP traffic, the NAS examines
the set of rules associated with the service granted to the user.
These rules determine what traffic is allowed to proceed through
the NAS and what traffic will be blocked. Today this capability
is supported in RADIUS and is configurable during service
establishment and mid-service via the Filter-Id(11) attribute. To
use Filter-Id to control access to network resources the rules
need to be configured apriori at each NAS. Filter-Id(11) is used
in an Access-Accept to specify the name of the filter rule(s) to
apply to this session. To effect a change mid-service
(dynamically), the Filter-Id(11) is included in a Change-of-
Authorization (COA) packet as described in [RFC3676]. Upon
receiving the Filter-Id(11) the NAS starts to apply the rules
specified by the Filter-Id(11)."

I'm not sure why this document needs to discuss Filter-ID, which is not
defined here.

" 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."

What does "roaming friendly" mean? Filter-ID has been used in roaming
for many years by cooperating parties. Perhaps the issue is requiring
pre-established filters to be set on the NAS? This paragraph appears
to be deprecating an existing RADIUS attribute without a clear
justification.


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