Subject: RE: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG

From: Avi Lior <[email-masked]>
Date: Wed, 5 May 2004 12:13:44 -0400

David, Mark,

I understand that we want to make progress here.  Perhaps some of this
issues would be best dealt with in 3576 bis -- if we have one.

My view and 3588's view of interim records are that they are  "typically
implemented in order to provide for partial accounting of a user's session
in the case of a device reboot or other network problems". That is the rule
and not the exception.

The problem with the text in NASREQ and it's use of interims is that we are
making the exception the rule.  IMO it aught to be the other way round.  We
should be generating Stops - Starts  and in certain cases use Interim
records. The may in that par should be changed to a SHOULD.

With respect to letting the NAS decide (Which I understood was Mark's
principal objection).  While this has worked in the past it is a huge
concern.  Especially when we are faced with roaming situations where we
don't have direct relationships with the NASes.  The home network's
responsibility is to generate the Bill and we really can't have some NAS at
the Roach Hotel dictate to us.  The tail should not wag that dog.  While I
don't know how to solve this I do know that the existing text is not going
to help.

With respect to when a new session starts.  If we need a guideline (and it
would certainly help) then perhaps we can suggest that any change is session
attribute should be considered a change in session.  Application writers
could refine this definition.

With respect to getting a different user authenticatign during a re-auth.
IMO the only thing you do there is turf the session.  You should provide a
guideline in the document and perhaps couch it in a SHOULD (although I think
it should be a MUST).

I know you want to get this thing off you back.

Avi

> -----Original Message-----
> From: David Mitton [mailto:[email-masked]] 
> Sent: Wednesday, May 05, 2004 12:56 AM
> To: Mark Jones
> Cc: [email-masked]'
> Subject: RE: [AAA-WG]: Diameter Nasreq Draft 15 ready to go 
> to the IESG
> 
> 
> On 5/4/2004 04:55 PM -0400, Mark Jones wrote:
> > > >>(1) If the re-authorization results in a change to any of
> > > the service
> > > >>parameters, the NAS MUST treat this as a new session 
> and send two 
> > > >>messages (Stop/Start).
> > >
> > > "any" is too broad a term to leverage a MUST here.
> >
> >Would a SHOULD be acceptable here instead?
> 
> Perhaps, but there does seem to be some abiguity as to what 
> constitutes a 
> new session.
> 
> 
> > > A typical auth upgrade
> > > scenario is the addition of more parameters.
> > >
> >
> >Replace is the most common scenario I've encountered in RADIUS up to 
> >now but I agree the text should also cover addition and deletion.
> >
> > > Billing models are provider dependent.   If I have a
> > > different policy, I
> > > may NEED those messages.  So why are you trying to dictate your 
> > > policies to my NAS implementation code?
> > >
> >
> >If a provider NEEDS stop/start messages, it should not be 
> left to the 
> >NAS implementor to decide whether the re-authorization change is 
> >significant enough to warrant the sending of those messages.
> 
> Well, these things actually tend to go hand-in-hand.  ISPs 
> know how their 
> NAS's work and either code around them or get them changed to 
> suit.  The 
> whole situation should be predictable.  The provider knows 
> what they're 
> changing, why,  and how the NAS implmentation would respond to that.
> 
> It might be interesting to try to figure out what we're 
> talking about by 
> creating some reasonable specific scenarios.
> 
> 
> > >
> > > It also possible to provide managed NAS behavior.  The messages 
> > > could be optioned off by NAS management, if not needed in a given
> > > configuration.
> >
> >And this configuration option would control whether Interim or 
> >Stop/Start messages were sent on re-authorization. Correct?
> 
> that's certainly in the realm of possible.
> 
> 
> >On a related note, I assume the sending of an Interim for a 
> >re-authorization event causes the Acct-Interim-Interval timer to be 
> >reset.  Would stating this in the draft break any existing 
> >implementations?
> 
> I doubt it, but the question is worth asking.
> 
> 
> > > This protocol covers a host of services, not just yours.
> >
> >That is a strange rebuke for pointing out an ambiguity in a 
> draft and 
> >suggesting text. I have no idea what you could have inferred 
> as being 
> >_my_ service.
> 
> I'm sorry, but I personalized the discussion a little, by I'm 
> responding to 
> an abstracted a service with requirements that come from your 
> suggested 
> behaviors.  It seems you (and your colleague) may have a 
> specific service 
> in mind.  And your collective commentary keeps poking at this 
> text in a 
> consistent direction.
> 
> Likewise, I don't really have a specific service I provide this 
> minute.  But I have done ones in the past that work in a 
> manner consistent 
> with my discussion.
> That is, are long lasting, with changes in service and  emit 
> lots of Vendor 
> specific accounting event messages under optional control, 
> among other things. Probably not the most popular RADIUS 
> service in the world, but I don't 
> think it's model should be outlawed.
> 
> Dave. 
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 5 May 2004 09:43:43 -0700 (PDT)

> issues would be best dealt with in 3576 bis -- if we have one.

I don't think this is just a 3576bis issue, unfortunately.  There is some
somewhat vague text in RFC 3580 that appears to require the NAS to make a
judgement on whether authorizations have changed sufficiently to justify
sending an accounting STOP/Start, but doesn't provide guidance on the
Service-Type, whether is is "Authenticate Only" or not.  And then we have
the NASREQ document.

So I think this is a somewhat bigger discussion.

> in the case of a device reboot or other network problems". That is the rule

OK.

> don't know how to solve this I do know that the existing text is not going

I agree in principle.  However, I'm not sure at this point what range of
practices are implemented -- and therefore what the "state of the art" is.
As David mentioned, we need to be careful about outlawing common
practice.

> could refine this definition.

The usage of Service-Type="Authenticate Only" seems to indicate that
changes in authentication-related attributes (such as keys or EAP Types)
do not constitute a change in authorization.

However, Paul Funk has made an argument that some implementations
may use an Accounting START to confirm that the session in fact started
-- and may assume that it did not start if they don't receive it.

Some questions:

a. Is it possible to send another Accounting START with the same
Session-Id?  Or must the Session-Id always change for each START?

b. Is it useful to make a distinction between Service-Type= "Authenticate
Only" and other Service-Types?

> I know you want to get this thing off you back.

We all do.  But at the same time, I don't want to make a mess we'll have
to clean up later.  It seems like we already have a problem on our hands
that may be difficult to address (since we have lots of implementations in
the field).