[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 226: RFC 3576bis and Renumbering
David B. Nelson wrote:
> Glen Zorn reminds us that there are implementations in which the NAS
> responds to a user request for an additional service, based on the broad
> authorization contained in previous Access-Accept, creating a new service
> session and a new Acct-Session-Id, without ever sending a new
> Access-Request. Only the RADIUS Accounting server would have seen the new
> value of Acct-Session-Id.
I will re-phrase that as: The CoA client can send a CoA request for a
session when it has not seen any (or all) RADIUS traffic for that session.
Since the CoA client isn't party to the RADIUS traffic, it's likely
that the RPF checks described elsewhere in the document will fail.
Perhaps a better solution is to have what would otherwise be the CoA
client send the packet to a RADIUS server for forwarding, rather than
contacting the NAS itself.
i.e. if the CoA client is in the same administrative domain as the
RADIUS servers, then the RADIUS server MAY bypass its RPF checks.
> Avi Lior reminds us that implementers would like to use identifying
> attributes as a set of "match filters" to select a group of sessions (i.e. a
> group of Acct-Session-Id values) for action.
That is a very useful feature.
> Glen Zorn reminds us that the semantics of session attribute identification
> is likely to be extended and further defined in documents from non-IETF
> SDOs, covering particular application areas.
That would be a very useful feature. But it's not required if the
session identifiers are protocol-independent RADIUS attributes.
> While only the market can validate whether these extended notions of session
> identification are good ideas, it's probably not appropriate to prohibit
> them in RFC3576bis.
I agree. Prohibiting them is bad. Requiring ONLY them is just as bad.
> I recommend that we define some base session
> identification attributes for "generic", RFC2865-style RADIUS sessions, and
> make them SHOULDs or MAYs in RFC3576bis.
I prefer MUST over SHOULD, and SHOULD over MAY.
> I further recommend that we add
> some text indicating that other documents, covering specific areas of
> application, may in the future recommend or require different sets of
> session identifier attributes.
I'll see if I can come up with something acceptable.
> We should also acknowledge, for the benefit of the reader, that the nature
> of RADIUS "session" definition, i.e. concurrent, sequential and nested
> service provisioning, is not well standardized, and that the session ID
> attribute (whatever its name) included in the Access-Request messages may
> not describe all of the actual sessions that CoA-Request or
> Disconnect-Request messages may wish to address.
It's OK if that identifier doesn't describe all of the sessions. It's
only necessary that the identifer act as a key to limit the scope of the
per-session and protocol-specific identifiers.
> The only alternative to
> this, IMHO, is to restrict session creation in the NAS to a one-to-one
> relationship with Access-Request messages (i.e. vanilla RADIUS as it existed
> in the 1980's). I suspect that will meet with some resistance.
I like that idea, but recognize that it's unworkable.
>> If those two keys are NOT sufficient, then I again question how RADIUS
>> is being used to control sessions it knows nothing about.
>
> Secret sauce? That is a very valid question, to which I'm sure there is an
> answer. I'm equally sure that it hasn't been provided in this thread. :-)
Well, yes. I understand it's useful for an IDS box to send a
Disconnect-Request to a NAS. But the IDS has no inter-operable way of
knowing that it's idea of a session matches the NAS's idea of a session.
Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
--
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/>