Re: RFC3576bis and Session State

[Alan DeKok <aland@nitros9.org>]

Avi Lior wrote:
> What session identifiers I include in the COA or DM message should
> indicate what I want to effect.

  The word "session" is being used in multiple contradictory ways.  Your
previous message indicated that one login "session" may result in
multiple Acct-Session-Id's.  In that case, keying off of Acct-Session-Id
to change a session would make sense.

  You now seem to be saying that sessions are *independent* of
Acct-Session-Id's, and that you do *not* want to use Acct-Session-Id as
a key for a session, but rather something else.

> If I only inlcude the User Identity (NAI, CUI, or some other identity)
> then I want to effect the user session being identified which may
> inlcude all of the users IP sessions and all the flows etc...

  Yes.  That's a wonderful idea.  So... why can't the NAS include an
Acct-Session-Id in the Access-Request, in conjunction with the NAI?  Any
request to affect the "user session" would then just use that
Acct-Session-Id.

> If I inlcude the Acct-Mutli-Session-Id attribute, then I want to effect
> all the sessions that are being identitified by the
> Acct-Multi-Session-Id.

  Yes.  That's a wonderful idea.

> If I include the Acct-Session-Id attribute then I want only to effect
> the session that is being identified by that handle.

  Yes, that's a wonderful idea.

> If I inlcude the Framed-IP-Address, then I want to effect the sessions
> that are identified by the IP address (IPv4 or IPv6)

  And there's the problem.  Those IPv4 sessions don't exist in a vacuum.
 Are you really saying that the CoA client will try to change a session
where it *only* knows the IP address?  That looks to me like an open
invitation to a security attack.

  Also, you still haven't addressed the point where you can't use the IP
address as both a key, and an update attribute.  If the IP "session" has
an Acct-Session-Id associated with it, they key is Acct-Session-Id, and
the updated information is the Framed-IP-Address.

  On top of that, your rules above for using "CUI, or NAI, or
Acct-Multi-Session-Id, or Acct-Session-Id, or Framed-IP-Address" are
guaranteed to prevent interoperability.  The CoA client will have NO
IDEA what it's supposed to send to affect a session.

  That's what keys are for: they act as unique identifiers, independent
of the data being updated.

> There may even be some VSA that can be used as well....

  If we allow that, we've given up on interoperability.

> Which as i pointed out only works in very simple cases. And in some
> cases Acct-Session-Id is totally useless.

  Then the NAS needs to be fixed to generate a useful Acct-Session-Id.

  If there are "sessions" you need to refer to that are not authorized
or authenticated via RADIUS, then my suggestion would be that using
RADIUS to change those "sessions" is flat-out wrong.  You're trying to
get RADIUS to control pieces of the network that it doesn't even know
exists, which is always difficult.

> Bernard wrote:  "Actually, it seems like it might make it unnecessary to
> use an IP address as a session identification attribute."
> 
> IMO are not appropriate because they are useful in only some
> deployements.

  If the session involves RADIUS knowing about a Framed-IP-Address, then
the Acct-Session-Id can be included in the protocol flow, and it can be
used as a key instead.  If the session does not involve RADIUS knowing
about a Framed-IP-Address, then RADIUS should not be used for session
change control.

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