[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RFC3576bis and Session State
I have an issue with some
of the statement being made below:
What session identifiers
I include in the COA or DM message should indicate what I want to
effect.
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...
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.
If I include the
Acct-Session-Id attribute then I want only to effect the session that is being
identified by that handle.
If I inlcude the
Framed-IP-Address, then I want to effect the sessions that are identified by the
IP address (IPv4 or IPv6)
There may even be some
VSA that can be used as well....
I dont think therefore
that 3576 should prohibit any of the above. It really is up to
deployements to determine how these are used.
3576 should simply state
that the COA and DM should identify the session to be effected using any of the
session attributes available (including VSAs). Some examples may be
appropriate.
Statements
like:
Alan worte: "I can
add a sentence to Section saying "A NAS implementing this specification SHOULD
send
an Acct-Session-Id or Acct-Multi-Session-Id Attribute within an
Access-Request." "
Which as i pointed out
only works in very simple cases. And in some cases Acct-Session-Id is totally
useless.
Or
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.
> Date: Sat, 26 May 2007 16:16:31 +0100
> From:
aland@nitros9.org
> To: bernard_aboba@hotmail.com
> Subject: Re:
RFC3576bis and Session State
>
> Bernard Aboba wrote:
> >
> I suggest we can request that they implement it now, *if* they also
>
> > support CoA or Disconnect request.
> >
> > [BA] Are
you suggesting that NASes implementing RFC 3576bis SHOULD send
> > the
Acct-Session-Id within an Access-Request?
>
> Yes. Or,
Acct-Multi-Session-Id, which may address Avi's concerns
> over multiple
Acct-Session-Id's for one "session".\
[BA] Hmm... Perhaps we
need a change in Section 3 from:
"As noted in [RFC2866] Section
5.5:
An Accounting-Request packet MUST have an Acct-Session-Id.
An
Access-Request packet MAY have an Acct-Session-Id; if it does,
then the
NAS MUST use the same Acct-Session-Id in the Accounting-Request
packets for
that session.
Since the Acct-Session-Id is optional in
Access-Requests,
if the Dynamic Authorization Client only has access
to
attributes sent to or by the RADIUS authentication server, then it
will
not necessarily know the Acct-Session-Id of the session it is attempting
to
target.
Where the Acct-Session-Id Attribute is not present in
a
CoA-Request or Disconnect-Request,
it is possible that the User-Name or
Chargeable-User-Identity
attributes will not be sufficient to uniquely
identify the session (e.g. if the same
user has multiple sessions on the NAS,
or the privacy NAI is used).
As a result, one or more of the
Acct-Multi-Session-Id,
Called-Station-Id, Calling-Station-Id, NAS-Port and
NAS-Port-Id attributes
MAY be used as additional session
identification."
To something like this:
"A NAS implementing this
specification SHOULD send an Acct-Session-Id or Acct-Multi-Session-Id Attribute
within an Access-Request. However, where the Acct-Session-Id or
Acct-Multi-Session-Id is not included within an Access-Request, unless the
Dynamic Authorization Client has access to accounting data, it is possible that
the Dynamic Authorization Client will not know the Acct-Session-Id or
Acct-Multi-Session-Id of the session it is attempting to target.
Where an
Acct-Session-Id or Acct-Multi-Session-Id Attribute is not present in a
CoA-Request or Disconnect-Request, it is possible that the User-Name or
Chargeable-User-Identity attributes will not be sufficient to uniquely identify
the session (e.g. if the same user has multiple sessions on the NAS or the
privacy NAI is used). As a result, one or more of the Called-Station-Id,
Calling-Station-Id, NAS-Port and NAS-Port-Id attributes MAY be used as
additional session identification."
I can add a sentence to Section
saying "A NAS implementing this specification SHOULD send
an Acct-Session-Id
or Acct-Multi-Session-Id Attribute within an Access-Request."
>
> Requiring this would avoid the issue of Framed-IP-Address being used
> as both a key for the session, and the target of the change request,
> which was the start of this thread.
[BA] Actually, it seems like
it might make it unnecessary to use an IP address as a session identification
attribute.
> Requiring a session identification attribute would
avoid the ad-hoc
> session identification. i.e. IPv4, IPv6, and fields
from other
> protocols used to identify sessions? Are we going to update
the RFC's
> every time someone uses RADIUS to authorize a new
protocol?
>
> Or, we can define a protocol-independent key, and use
that for all
> protocols, old and new.
[BA] That seems like a
better idea.
>
> Alan DeKok.