Subject: [AAA-WG]: Re: Wrapping up NASREQ Re-auth

From: David Mitton <[email-masked]>
Date: Tue, 20 Apr 2004 17:38:13 -0400

On 4/20/2004 12:30 PM -0400, Avi Lior wrote:
>A couple of things:
>
>If the RAR properly identifies an active session, the NAS will
>    initiate a new local reauthentication or authorization sequence as
>    indicated by the Re-Auth-Request-Type value. This will cause the NAS
>    to send a new AAR message using the existing Session-Id. The server
>    will respond with an AAA message to specify the new service
>    parameters.
>
>Shouldn't we state that the AUTH-REQUEST-TYPE AVP of the AAR message be set
>to the same value Received in RAR Re-Auth-Request-Type AVP?  And what
>happens if its not?

I don't really have an opinion here.  Seems logical.  But either party 
could abort the Re-auth if it doesn't like the values in many AVPs.

This AVP is really described in the Base.
I find it interesting that we don't have a "Authenticate_Only" value for 
Re-Auth-Request.

>I am still having an issue with the following paragraph:
>
>  If accounting is active, every change of authentication or
>    authorization MUST generate an accounting message.  Either an
>    Accounting-Record-Type of INTERIM_RECORD indicating the new session
>    attributes and cumulative status (preferred) or two messages of the
>    types STOP_RECORD, and START_RECORD.  The later would be for service
>    specific compatibility with some RADIUS services.
>
>
>Why is the Interim preferred?

Because the session hasn't ended.  Stop means Stop, and we're not stopping 
we're continuing.  We've still got an authenticated context.

>Preferred seems to be an editorial comment.

Maybe.

>  Should we not specify when this
>is to be used? Also, would not Diameter suffer from the same issue that a
>RADIUS server would suffer?

It shouldn't, I was hoping to get rid of such problems.

>Would a backend process know why the Interim
>record is generated.  Would it always know what has changed?

Hopefully the service would generate sufficent information to discern that.

>  Would it be
>able to do the calculation to generate an appropriate bill?

A service information problem.  Most anything from the authorization 
message is fair game to include in the Accounting message.

Billing is not the only goal of Accounting, in fact one not normally 
addressed in the IETF.  Accounting is about about statistical and usage 
information.
The NAS doesn't know how I'm billing for my services and sessions.  I may 
be offering flat rate unlimited.  I many only care about total connect 
minutes, etc.

>Also, if new attributes are received, this is a new session right?

I think that's the crux of our disagreement.
I don't think that it is.  Maybe, but not a given.
I am aware of a number of services that offer differing sub-services over 
the lifetime of a session.  And for many providers that is not a problem, 
billing or management.

In my former line of work, a session didn't end until the port was 
disconnected.

I think the NAS is the primary party in position to make that decision.
But the server could just terminate the session and wait for the user to 
connect again.

>Don't we
>have to use something other then Interim records to deliniate a new session
>in diameter?

If this is important, sub-session Start/Stop messages are an option.
This is one reason that the Diameter Session-Id is separate from the RADIUS 
Acct-Session-Id.  We brought along RADIUS's Accounting-Multi-Session-Id and 
we added Accounting-Sub-Session-Id.

Our Nortel (former Bay Networks) VPN server would Start record for the 
construction of a new tunnel and do Starts & Stops (and hoards of VSA 
Interims) for each user session that used it, until the tunnel was torn down.

Also there is a precedent in the multi-link PPP space.  Each PPP "sub-" 
link would not know it was potentially part of a bundle until after it 
authenticated and the server could give it a token to associate with other 
links.  Each PPP link would become a separate RADIUS session, but part of a 
single overall user service session.  Links could come and go based on the 
how the system load or balancing.

The simplest system is one where a person connects an ASCII terminal to a 
NAS box, logs in (basic session) and then Telnets out (Terminal service 
either sub-session or additional session)  Until the port disconnects, the 
service is being provided. Our box (Xylogics) also supported LAT and FTP, 
etc. services too.

>Also, how would you (in a scalable way) specify which method is to be used:
>Interim or Stop/Start records?

In some ways it is a service specific accounting thing.  But we don't spec 
the services to that level of detail in the WG.  Heck RADIUS Accouting 
isn't even on the Standards track.  I would hope that in Diameter we 
provide the tools to do a straight forward and sensible implementation.

Also One (1) Interim record is less overhead than Two (2) Stop/Start records.

Dave.

> > -----Original Message-----
> > From: Bernard Aboba [mailto:[email-masked]]
> > Sent: Monday, April 19, 2004 3:34 PM
> > To: [email-masked]
> > Subject: [AAA-WG]: Wrapping up NASREQ...
> >
> >
> > David Mitton has put up a strawman version of the NASREQ-15 here for
> > examination:
> >
> > http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-15.txt
> >
> > This version is designed to close all open issues (see below).
> >
> > Since NASREQ has already gone through WG last call, IETF last
> > call, IESG review and approval for publication as a Proposed
> > Standard, this represents the very last opportunity to
> > comment on it before it is done.
> >
> > So... speak now or forever (until NASREQbis) hold your piece.
> >
> >
...

---

From: David Mitton <[email-masked]>
Date: Wed, 21 Apr 2004 11:19:48 -0400

On 4/20/2004 08:05 PM -0400, Avi Lior wrote:
>One problem I have is the use of Interim Records goes against the purpose of
>what Interim Accounting is about:
>
>Interim accounting
>       An interim accounting message provides a snapshot of usage during
>       a user's session.  It is typically implemented in order to provide
>       for partial accounting of a user's session in the case of a device
>       reboot or other network problem prevents the reception of a
>       session summary message or session record.
>
>What you propose goes against the above "grain".

Well that's one and maybe the most popular use of that Acct-Status-Type.
There is nothing saying it's the only or restrictive one.

The Acct-Status-Type of "Interim-Status" appears in RFC 2866 without any of 
the above information.
The Acct-Interim-Interval attribute first appears in RFC 2869 as an Extention.

The Interim accounting process and the Interim-Status record are two 
separate things.

I think we could use an INTERIM-EVENT record type here.
But that suggestion was not well received a little while back, and creating 
one adds a backwards compatibility problem.

>I think you are using Interim in this case to save a message.  But this
>maybe opening other cans of worms.
>
>Also, are we going to increment the various accounting/session ids?  Its not
>clear.

Diameter only asks that the Session-Id remain constant for the session.
All the other sub-ids can change as needed for the service.

>You say the session is not ending.  But as stated in that section, the
>session may be getting new session attributs.  It is therefore a new
>Session.

No.  It's not.  If same user, same port,
Until the port is disconnected my service thinks it's one session.

The user may reauthenticate and reauthorize until the cows come home.
In fact it may be done automatically for him by a lower layer.
Certainly possible with 802.11 roaming.

If the process discerns a different user (whatever that means in the 
service context), then by all means, indicate a new context and Stop the 
old session.

>I think two things are happening here: one is we have re-authentication the
>other is re-authorization.  I think that these need to be treated
>differently.  I may or may not want to record the fact that
>re-authentication happened.  I probably don't care much about billing for
>that event.

but we're still talking about "re-" something.  Not bare, new, Auth

>But for re-authorization, we want to record and we want to probably bill for
>that. This perhaps would require more support then just recording the event
>in an interim record.

Go for it.   The requirements are minimums.

Given that we've been through multiple last calls on this document.
I'm not going to change anything that is not broken without WG concensus.

Dave.

> > From: David Mitton [mailto:[email-masked]]
> > Sent: Tuesday, April 20, 2004 5:38 PM
> > To: Avi Lior; 'Bernard Aboba'; [email-masked]
> > Subject: Re: Wrapping up NASREQ Re-auth
> >
> >
> > >Shouldn't we state that the AUTH-REQUEST-TYPE AVP of the AAR
> > message be
> > >set to the same value Received in RAR Re-Auth-Request-Type AVP?  And
> > >what happens if its not?
> >
> > >is to be used? Also, would not Diameter suffer from the same
> > issue that
> > >a RADIUS server would suffer?
> >
> > I think the NAS is the primary party in position to make that
> > decision. But the server could just terminate the session and
> > wait for the user to
> > connect again.
> >
> > >Don't we
> > >have to use something other then Interim records to deliniate a new
> > >session in diameter?
> >
> > If this is important, sub-session Start/Stop messages are an
> > option. This is one reason that the Diameter Session-Id is
> > separate from the RADIUS
> > >Also, how would you (in a scalable way) specify which method
> > is to be
> > >used: Interim or Stop/Start records?
> >
> > > > Since NASREQ has already gone through WG last call, IETF
> > last call,
> > > > IESG review and approval for publication as a Proposed Standard,
> > > > this represents the very last opportunity to comment on
> > it before it
> > > > is done.
> > > >

---

From: Avi Lior <[email-masked]>
Date: Wed, 21 Apr 2004 18:48:11 -0400

Bernard and all:

> > I think two things are happening here: one is we have 
> > re-authentication the other is re-authorization.  I think 
> that these 
> > need to be treated differently.  I may or may not want to 
> record the 
> > fact that re-authentication happened.  I probably don't care much 
> > about billing for that event.
> >
> > But for re-authorization, we want to record and we want to probably 
> > bill for that. This perhaps would require more support then just 
> > recording the event in an interim record.
> 
> There is some logic to this.  However, in practice the 
> distinctions may not be so clean:
> 
> a. Reauthentication: If you do reauthentication and get a new 
> set of attributes (this can happen in either Diameter or 
> RADIUS) do you have to check to see if the attributes change 
> to decide whether to send an Interim accounting update?

If we restricted Reauthentication to just be reauthentication and don't
allow the AAA to respond with attributes then the ambiquity (whether or not
this is a re-authentication vs re-authenticaiton with potentially
re-authorization) goes away.

> 
> b. Re-authorization: When doing Diameter re-authorization or 
> RFC 3576 CoA, do we start a new session in all cases? Does it 
> matter who initiated the re-authorization (NAS or AAA server)?
>

I think in general the answer must be yes.  However, since this could
generate lots of unnecessary traffic perhaps we leave it up to the protocol
designer to specify what happens when a COA message is sent or when an
Access Request with Authorize Only message is sent.

For example in prepaid we use Access Request with Authorize Only and the
Access Accept with Authorize Only to tranpsort prepaid quota.  This
mechanism is used to refresh prepaid and really doesn't need change the
service.  It probably doesn't need to be recorded either. So there is no
need to generate an Accounting message for this.

If you look at the  bandwidth draft. When we dynamically change the
bandwidth we want to generate an accounting stop for the old session and
accounting start for the new session.  This is because we are probably going
to bill differently for the bytes sent at different bandwidth.