[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Some questions about IEEE802-01

Thanks for your comments, Greg. It looks to me like each of the points you raise is a real issue, so please go ahead and file them. 


*) In A.2.2, regarding mid-session HTTP redirection,
the text in the 2nd paragraph is talking about the
RADIUS server sending an Access-Accept with Service-Type
set to "Authorize Only".  I didn't understand what that
was all about.  I thought "Authorize Only" could only
be used in CoA-Request & Access-Request messages.
Did I miss something there?
You didn't miss anything. I don't understand this usage of the "Authorize Only" Service-Type. 


*) At the very end of Section 2.5 on NAS-Filter-Rule,
it says that the NAS can apply rules of its own before
rules supplied via the interface in this document.
I didn't understand the ordering and precendence
between filters originated from the different sources.
Is that covered somewhere?  If the server sends a
flush-rule via CoA-Request, does that remove the
NAS originated (configured) rules?  The text is implying
that the rules are applied in specific order based on
type, e.g. HTTP filter rules are last.  What if the NAS
defines the HTTP filter rule, and other types come via
CoA?  What's the order then?  This seems like an area
of likely implementation confusion.


Yes, I think this is an issue.


*) For Egress-VLANID & Egress-VLAN-Name, is there any
particular reason to overload the "Tag Option" into
the same attribute as the remainder values - instead
of making the "Tag Option" portion a separate attribute?
Wouldn't it be easier to configure on the server if
these were separated out?  Also, if not separated,
isn't calling the first octet a 'tag' confusing with
the RADIUS tagged tunnel attributes?
My impression was that the usage was similar to the 'Tag' in the tunnel attributes, but perhaps I'm misreading the document. 


*) The NAS-Filter-Rule represents a *lot* of functionality.
I think we can expect lots of variability in NASes to
support various parts, e.g. maybe all the filtering, but
not HTTP redirection, etc.  I think we maybe need to be
clearer on what is supposed to happen when the NAS gets
a CoA-Request or Access-Request containing directives
that it cannot parse or apply.  In particular, in Section
1.4 "Attribute Interpretation", I text indicating that
non-understood attribute result in Access-Rejects.  But,
in Section 6 "Security Considerations", I see text like:
"...a NAS could be configured to ... not accept any
redirection rules if it is known they are not used in
this environment."   There seems to be some confusion
about whether the NAS or server is authoritative.


Yes, I think there is a contradiction there.



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