Re: RFC3576bis and Session State

[Alan DeKok <aland@nitros9.org>]

David B. Nelson wrote:
> Glen Zorn writes...
> 
>> Not necessarily.  For example, I can imagine that an SDO other than the
>> IETF might decide what constitutes a "session" for their system.  I
>> think that that qualifies as "deployment-specific", with a market
>> possibly significant enough to warrant manufacturing customization.
> 
> Ah, I see.

  If RADIUS does AAA for a session, it has access to a session key such
as Acct-Session-Id.  If RADIUS does not do AAA for a session, I'm
unclear as to why RADIUS should be used for CoA of that session.

  I think the difficulty is one of terminology, rather than anything
else.  When I say I want to use a session ID as a key, I do NOT mean I
want to forbid using any other attributes to narrowly define a portion
of the session to change.  What I mean is that using ONLY those other
attributes is completely wrong.

  Here's a nice test case:  A switch has multiple ports, all
authenticated, etc. through RADIUS.  The authentication and accounting
servers are co-resident, and co-resident with the CoA client.  The
policy of the RADIUS server puts users into multiple VLANs, each with a
private network space, as follows:

    user A, port 1, VLAN 10, IP 192.168.1.2, Acct-Session-Id YYZ
    user B, port 2, VLAN 20, IP 192.168.1.2, Acct-Session-Id AAB

  The CoA client now wants to change a parameter associated with one of
the users.

  Is the problem obvious yet?

  How does the RADIUS server know what key to use in the CoA request?
Following Avi's rules, the RADIUS server has a hard time figuring out
what it's supposed to do.

  If we ONLY use the Framed-IP-Address as a key in CoA requests, then
the NAS has no idea which login session it applies to.  We could use
NAI, but maybe the user has logged in via two ports, and is trying to
span the interfaces.

  In short, the ONLY choice to uniquely identify a session is a unique
session identifier that is independent of protocol, port, username, etc.

  That being said, we MUST also permit additional attributes in the CoA
request, which add fine-grained control over portions of the session.

> This still seems problematic for RFC 3576bis, however.  If we leave the
> selection of session "marker" attributes that need to appear in
> Access-Request and CoA-Request messages to support a particular application
> open ended, then we can't easily task someone to write a test plan to verify
> multi-vendor interoperability of RFC 3567bis, because the attribute
> selection is not deterministic, or at least not determined within the scope
> of the document.

  Exactly.  And as I pointed out above, those markers are ambiguous, and
unworkable in the absence of a session identification key.

> If we are looking at RFC 3576bis as simply a base document that is used by
> other SDO documents to form a complete solution, but that is not a complete,
> interoperable protocol unto itself, then let's at least say so.  I think it
> may be best to specify a minimum set of session "marker" attributes for
> generic RADIUS applications as SHOULDs in RFC 3567bis and indicate that
> there are an unlimited number of other session "marker" attributes that MAY
> appear, based on the requirements of other documents, e.g. from non-IETF
> SDOs.

  Given the confusion on this list, I would now say that using
Acct-Session-Id is a MUST.  The NAS MUST send it in Access-Request.  The
CoA client MUST send it in a CoA request.  Additional attributes MAY be
present, and are used to control sub-portions of a session.

  Alan DeKok.


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