RE: RFC3576bis and Session State

["Avi Lior" <avi@bridgewatersystems.com>]

See inline.... 

-----Original Message-----
From: Alan DeKok [mailto:aland@nitros9.org] 
Sent: Tuesday, May 29, 2007 4:10 AM
To: Avi Lior
Cc: Bernard Aboba; radiusext@ops.ietf.org
Subject: Re: RFC3576bis and Session State

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.

[Avi] Session is overloaded.  I tried to define what the different
possible sessions are.  To me Acct-Session-Id represents a segement of a
session -- or an Accounting Segment of a session. If that is the case,
killing an accounting-segment is not very useful unless you were sure
that killing that segment would kill that session.  And you cant always
be sure of that.


  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.

[Avi] Yes.  See above. And let me give you an example.

NAS
 |
 |<--IP-Session starts
 |
 |-------------------Acct Start (Acct-Session-Id 1)--->
 |
 |<-QoS Change
 |
 |-------------------Acct Stop (Acct-Session-ID 1) --->
 |                   Reporting usage on original QoS
 |-------------------Acct Start (Acct-Session-ID 2) --->
 |                   Starting to record usage on  new QoS
 |
 
[Avi] Also I don't want to dig through accounting message to find the
current Acct-Session Id

[Avi] And accounting may not be used.

[Avi] And accounting may be delayed.  Accounting is not realtime. And
using information from the accounting stream is  not a good idea.  Hence
I like the logoff draft.

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

[Avi] That is just a bad handle.  It can only have one Acct-Session-ID
that may only be valid for a short time.  Acct-Session-Id is used for
correlating a Start and a Stop.

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

[Avi] No. It can include the CUI, NAI and the IP-Session.  And do you
think that an attacker that can inject a COA with an IP-address cant
find the CUI and NAI to include in the message as well?  Be real, this
only works in the security model of AAA.


  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.

[Avi] I have never run across a case where I need to update the IP
address. If I were to run into such a case I would create another
attribute called newIPAddress. But I have run into many situartion where
I a given User session has multiple IP sessions, and I need to modify a
specific IP session.


  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.

[Avi] Not true. The COA will have all the information it needs to modify
the a specific session or subsession.  You use the attributes like a
path to drill down to a specific session: Here is an example:
/username or Acct-Multi-Session-id or CUI/framedIp : to effect an IP
session of a given user.


  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.

[avi] In the general case yes.  But an SDO may want to do just that. We
always need to allow folks to extend the protocol.

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

[Avi] That is not acceptable to me at all.  Its okay perhaps in an
simple enterprise model. But does not work in my world at all.

  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.

[Avi] I disagree.  An access request can download policy or
authorization to create session at the NAS. Each one of these session
will have its own Accounting Stream ie its own Start/Stop with its own
Acctounting Session ID.

[Avi]Also Alan, you can have Accounting without
Authentication/Authorization.  There are many deployements that use
RADIUS Accounting without RADIUS Authentication/Authorization. And
perhaps -- and I know you wont like this at all, COA/DM without RADIUS
Authetnication/Authorization.  But I am not asking the IETF to
standerdize that. Just don't prohibit it.

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

[Avi] No. Because in the case of flow based accounting, the
Acct-Session-ID identifies a flow and not necessarily the IP session.
So if you want to kill the IP session you could only do that by killing
all the flows.  Not a good idea since you would have to search through
rims of accounting messages, and these may arrive a day later at the AAA
server, or not at all if the no accounting is used.


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