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

From: Avi Lior <[email-masked]>
Date: Tue, 20 Apr 2004 20:05:58 -0400

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

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.

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.

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.  

> -----Original Message-----
> 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
> 
> 
> 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.tx
> > > t
> > >
> > > 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: Bernard Aboba <[email-masked]>
Date: Tue, 20 Apr 2004 19:06:28 -0700 (PDT)

> that. This perhaps would require more support then just recording the event

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?

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)?