[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question: when does a session change?
Paul --
Thanks very much for your detailed response. It seems like there is a
need for clarification on several points, including the generation
of Acct-Stop,/Start and whether the "Authenticate Only" service type
is appropriate for re-authentication.
In the original RADEXT charter we had a work item for "Implementation
Issues and Fixes". Perhaps such a document might be a vehicle for
clarifying some of these questions.
-------------------------------------------------------------------
Date: Mon, 26 Apr 2004 21:58:11 -0400
From: Paul Funk <paul@funk.com>
To: Bernard Aboba <aboba@internaut.com>, aaa-doctors@internaut.com
Subject: Re: [aaa-doctors] Question: When does a session change?
I think that making fuzzy decisions about the extent of a session
is dangerous. Comparing authorization attributes to determine whether
a session is considered ended or not will lead to implementation
mayhem.
For example, if the RADIUS server sets a Session-Timeout of an hour,
there had better be an Acct-Stop within that hour. Extending a session
by reauthenticating after 59 minutes and getting a new Session-Timeout
of an hour without stopping the first session and creating a new session
would be a violation of the expectations of the RADIUS server. In fact,
the RADIUS server may manufacture an Acct-Stop at the end of the
Session-Timeout period to send to proxy targets.
When a RADIUS server performs an authentication, it typically expects
an Acct-Start to confirm that the session indeed started. Without this
Acct-Start, it may deem the session a non-starter. In fact, if the RADIUS
server considers the reuse of NAS-Port/Port-Type to indicate that a
previous session has ended but its Acct-Stop packet was dropped, it will
make the following inference from the reauthentication request: the
original session has stopped due to reuse of NAS-Port, and the new session
did not start due to the absence of Acct-Start. Thus, for the AP to follow
3580 here would break existing RADIUS implementations.
RFC 3580's language is murky. I would suggest that the purpose of
reauthentication in order to acquire fresh keys can be served with a
Service-Type whose meaning is specifically that this is a reauthentication
within the same session, keys are to be generated, but no authorization
attributes are to be returned. This Service-Type is only valid during the
Session-Timeout period and does not extend that period. Since the user
has already been authorized for the Session-Timeout period, there should
rarely be a need to modify those authorizations; if there is, the RADIUS
server can either reject or send COA.
There is at least one AP that uses the "Authenticate Only" Service-Type
for just this purpose. So maybe it's not necessary to create a new
Service-Type but just define the use of "Authenticate Only" for 802.1X.
However, it is possible that there will be argument about this. Are
session-keys part of authentication or part of authorization? Different
people will have different answers.
In the meantime, I think that APs should ignore 3580's vague language and
just create a new session on reauthentication, with an Acct-Stop for the
old session and Acct-Start for the new. The two sessions can be associated
with each other for billing/tracking purposes using Acct-Multi-Session-Id.
Paul
-----------------------------------------------------------------------------
Date: Sun, 25 Apr 2004 00:12:59 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: aaa-doctors@internaut.com
Subject: Question: When does a session change?
Recently in AAA WG we've had a question come up: when does a new session
occur as the result of re-authentication or re-authorization? This
affects the generation of accounting STOP or interim records.
I found the following text in RFC 3580, Section 2.1:
" Within [IEEE80211], periodic re-authentication may be useful in
preventing reuse of an initialization vector with a given key. Since
successful re-authentication does not result in termination of the
session, accounting packets are not sent as a result of
re-authentication unless the status of the session changes. For
example:
a. The session is terminated due to re-authentication failure. In
this case the Reauthentication Failure (20) termination cause is
used.
b. The authorizations are changed as a result of a successful
re-authentication. In this case, the Service Unavailable (15)
termination cause is used. For accounting purposes, the portion
of the session after the authorization change is treated as a
separate session."
Note that this text is vague on several points:
1. What does "changed" mean in b)? Surely changing an attribute (such as
Session-Time or maybe Idle-Timeout) isn't sufficient to cause the session
to change. The nature of the session needs to change. What are the
guidelines for making this decision?
2. What does a separate session imply "for accounting purposes", other
than a new Acct-Session-Id? Is it necessary to send an Accounting START,
STOP, Interim record, or some other accounting packet indicating the
change?
-----------------------------------------------------------------------------
Date: Sun, 25 Apr 2004 11:19:13 -0400
From: Barney Wolff <barney@databus.com>
To: Bernard Aboba <aboba@internaut.com>
Cc: aaa-doctors@internaut.com
Subject: Re: [aaa-doctors] Question: When does a session change?
On Sun, Apr 25, 2004 at 12:12:59AM -0700, Bernard Aboba wrote:
>
> b. The authorizations are changed as a result of a successful
> re-authentication. In this case, the Service Unavailable (15)
> termination cause is used. For accounting purposes, the portion
> of the session after the authorization change is treated as a
> separate session."
>
> 1. What does "changed" mean in b)? Surely changing an attribute (such
as
> Session-Time or maybe Idle-Timeout) isn't sufficient to cause the
session
> to change. The nature of the session needs to change. What are the
> guidelines for making this decision?
I suppose that a changed filter (for framed) or target host would qualify.
But see <rant> below.
> 2. What does a separate session imply "for accounting purposes", other
> than a new Acct-Session-Id? Is it necessary to send an Accounting
START,
> STOP, Interim record, or some other accounting packet indicating the
> change?
Surely if Acct-Session-Id changes, a stop and start would be appropriate.
If the server can't match stops to starts with Acct-Session-Id, what is
the use of that attribute?
<rant>
When the code size of a NAS or AAA server passes that of the 5ESS,
we'll have lost something. We're not there yet, but the trend is clear.
</rant>
Barney
-----------------------------------------------------------------------------
Date: Sun, 25 Apr 2004 12:36:27 -0400
From: David Mitton <david@mitton.com>
To: aaa-doctors@internaut.com
Subject: Re: [aaa-doctors] Question: When does a session change?
On 4/25/2004 11:19 AM -0400, Barney Wolff wrote:
>On Sun, Apr 25, 2004 at 12:12:59AM -0700, Bernard Aboba wrote:
>...
> > 2. What does a separate session imply "for accounting purposes", other
> > than a new Acct-Session-Id? Is it necessary to send an Accounting
START,
> > STOP, Interim record, or some other accounting packet indicating the
> > change?
>
>Surely if Acct-Session-Id changes, a stop and start would be appropriate.
>If the server can't match stops to starts with Acct-Session-Id, what is
>the use of that attribute?
Agreed... for RADIUS. In Diameter we have a higher level Session-Id AVP.
sort of a 'Authorization-Session-Id' that we didn't have in RADIUS.
Unfortunately this introduces some interesting issues:
Can the Session-Id stay the same, and we Start/Stop multiple unique
Acct-Session-Ids for these billing segments?
Do we need to Start/Stop the overall session? If we do, is the backend
smart enought to just ignore them?
Is the use of the Interim-Status message for events (not interval
accounting)
fair?
In RADIUS some people never got comfortable with nested accounting
segments.
Everything is Start/Stop (or often just Stops) and the backend does the
agregation based on attributes (and time span?), not the type of events.
><rant>
>When the code size of a NAS or AAA server passes that of the 5ESS,
>we'll have lost something. We're not there yet, but the trend is clear.
></rant>
>
>Barney
Well some of us don't know the code on a #5ESS, but I do remember gen'ing
RSX-11M DECnet on a 64KW PDP-11 system, and being proud if I had two
partions for applications. Don't look back too often, it can get
depressing.
Dave.
-----------------------------------------------------------------------------
Date: Sun, 25 Apr 2004 13:28:08 -0400
From: Barney Wolff <barney@databus.com>
To: David Mitton <david@mitton.com>
Cc: aaa-doctors@internaut.com
Subject: Re: [aaa-doctors] Question: When does a session change?
On Sun, Apr 25, 2004 at 12:36:27PM -0400, David Mitton wrote:
> On 4/25/2004 11:19 AM -0400, Barney Wolff wrote:
> >Surely if Acct-Session-Id changes, a stop and start would be
> > appropriate.
> >If the server can't match stops to starts with Acct-Session-Id, what is
> >the use of that attribute?
>
> Agreed... for RADIUS. In Diameter we have a higher level Session-Id
> AVP. sort of a 'Authorization-Session-Id' that we didn't have in RADIUS.
> Unfortunately this introduces some interesting issues:
>
> Can the Session-Id stay the same, and we Start/Stop multiple unique
> Acct-Session-Ids for these billing segments?
Whether or not the overarching Session-Id exists, imho there is no sense
in having one Acct-Session-Id start and a different one stop. So there
must be something that marks the transition. If the only debate is
whether that should be separate stop+start or a new single request which
contains both the old and new Acct-Session-Id's, my vote would be to
avoid proliferating entities rather than worry about saving packets.
Consider that the new session might not be successful, so the stop
might be followed by something other than a start.
If Session-Id changes within a single real-world "connection" then I
don't understand the worth of Session-Id.
Barney
(I don't actually know the 5ESS code either, just used it as a metaphor
for semi-infinite and ultimately self-defeating complexity.)
-----------------------------------------------------------------------------
Date: Mon, 26 Apr 2004 10:08:25 -0400
From: "Nelson, David" <dnelson@enterasys.com>
To: aaa-doctors@internaut.com
Subject: RE: [aaa-doctors] Question: When does a session change?
> 1. What does "changed" mean in b)? Surely changing an attribute (such
> as Session-Time or maybe Idle-Timeout) isn't sufficient to cause the
> session to change. The nature of the session needs to change. What are
> the guidelines for making this decision?
There are at least three viewpoints to consider in answering this
question: (a) the nature of resources consumed at the NAS (e.g. the type
of service, protocol, etc.), (b) the quantity or quality of resources
consumed at the NAS (e.g. the level of service, bandwidth, Qos), etc.)
and (c) the nuances of billing at the RADIUS Server (e.g. tariffs,
differentiated rates, special offers, and other "business domain"
issues).
While accounting is used for various purposes, including auditing,
capacity tracking/planning and troubleshooting, the predominant use is
billing. So the trite answer to the question is "anything that will
affect the billing details and bottom line cost to the customer".
Leaving the distinction that open-ended is an invitation to trouble,
however, so some more concrete and concise basis is likely required. I
would need to give this some additional thought, before proposing one.
> 2. What does a separate session imply "for accounting purposes", other
> than a new Acct-Session-Id? Is it necessary to send an Accounting
> START, STOP, Interim record, or some other accounting packet indicating
> the change?
Based on the context of this portion of RFC 3580, I'd have to suggest
the answer is yes. I'm under the impression that RADIUS Accounting
servers would not expect to see a single accounting session (defined as
the duration between a related START and STOP) have more that a single
Acct-Session-ID. I'm not as familiar with Diameter Accounting
practices.
-- Dave
-----------------------------------------------------------------------------
Date: Mon, 26 Apr 2004 11:26:40 -0400
From: David Mitton <david@mitton.com>
To: aaa-doctors@internaut.com
Subject: RE: [aaa-doctors] Question: When does a session change?
On 4/26/2004 10:08 AM -0400, Nelson, David wrote:
...
>I'm under the impression that RADIUS Accounting
>servers would not expect to see a single accounting session (defined as
>the duration between a related START and STOP) have more that a single
>Acct-Session-ID.
That is correct. A general principal would be that once something is
STOP'ed it's no more. And cannot be reused.
But in RADIUS, the NAS can just increment the Acct-Session-Id and
carry-on, regardless if the port has been disconnected or not.
There's nothing stopping a Diameter accounting implementation from doing
that either.
But in RADIUS there is no overarching Session-Id and STR message to match
on. A RADIUS NAS Auth context is not visible after the start.
In Diameter we have an Auth context to end, at the end of session, to get
rid of the nasty RADIUS Acct msg tracking for stateful resource and
session
management.
> I'm not as familiar with Diameter Accounting
>practices.
I'm not sure their are any yet.
But I'm not sure I want them limited down to the simplest RADIUS
practices.
Dave.
hmm... now why was it we couldn't get a Base Accounting draft written?