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

From: Bernard Aboba <[email-masked]>
Date: Fri, 30 Apr 2004 23:32:59 -0700 (PDT)

David Mitton has updated the NASREQ draft for perhaps the last time.
This version is available at:
http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-15.txt

Further changes have been made to the section on re-auth.

If there are no objections, the draft will be submitted for publication by
the RFC editor by May 6, 2004.

---

From: <[email-masked]>
Date: Sat, 1 May 2004 09:39:30 +0300

Bernard,

> the RFC editor by May 6, 2004.

I had a quick look at the changes & I say ship it.

John

---

From: Mark Jones <[email-masked]>
Date: Tue, 4 May 2004 15:35:48 -0400

> Then what do we do with current BRAS'es (Redback SMC and 
> Redback SE800 
> for example) that already send an Accounting-Update packet when an 
> reauthorization happens ? I know that's in RADIUS, but 
> DIAMETER should 
> still be backwards compatible. 

So because this behavior is vendor-specific in RADIUS, we must leave it as
vendor-specific going forward?

> Your MUST NOT will prevent us from proxying those events.

Given the backwards compatibility issue, I concede that the MUST NOT is too
strict here. However, as nasreq-15 is currently worded, your proxy target
would have to deal with those events expressed as Interims or Stop/Start
depending on each NAS implementors interpretation of 'significant change'.

Mark

---

From: Mark Jones <[email-masked]>
Date: Tue, 4 May 2004 16:55:42 -0400

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

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

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

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?

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

Mark

---

From: David Mitton <[email-masked]>
Date: Wed, 05 May 2004 00:56:05 -0400

>Would a SHOULD be acceptable here instead?

Perhaps, but there does seem to be some abiguity as to what constitutes a 
new session.

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

>messages were sent on re-authorization. Correct?

that's certainly in the realm of possible.

>this in the draft break any existing implementations?

I doubt it, but the question is worth asking.

>suggesting text. I have no idea what you could have inferred as being _my_

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: Avi Lior <[email-masked]>
Date: Wed, 12 May 2004 16:30:17 -0400

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 

> > > 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.
> >
> > Yes.
> >
> > Okay so what happens if its "Authenticate only" and 
> > non-authentication-related attributes are received?  Is the 
> > specfication clear about this (a point I brought up before)
> 
> RFC 3580 is not clear about this, certainly.  I'm not sure 
> that RFC 2865 is either.  Do you have a proposal?

Well, as I see it there are three options:

A) Leave it unspecified.  That is if there are service effecting attributes
then
So be it.

B) Ignore any service effecting attributes.  But this is bad since the home
network will think the new attributes have been accepted.

C) Make the specification tight.  NAS must reject any messages that are not
authentication related.

C) Is what we probably should have done. But probably people would complain.
In hide sight it may have been better to have two new commands: one for
re-authenticate and one for re-authorize.

Also related to this.  Not sure what is being done.  When we reauthenticate
what happens when the identity does not match the original identity?  Not
sure this was addressed.

> > > 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.
> >
> > So the call flow is:
> >
> > Acct Start  Acct-Session Id = X
> > Interim
> > Interim
> > <REAUTHENTICATION>
> > Acct Start Acct-Session Id = X
> 
> Yes, I think this makes sense.
> 
> > > 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?
> >
> > Do you mean Accounting Session-Id or Session-Id?
> > If you meant Acct-Session Id then it should not change. Because the 
> > second Accounting Start will be detected as a duplicate 
> start record 
> > in the accounting stream. Providing the accounting session 
> id is not 
> > modified and same NAI etc.... Not sure if that is universal but I 
> > checked with our folks and that's what we do.
> 
> This makes sense, I think.
> 
> > If you change the Session Id I think you would have to generate an 
> > Accounting Stop to close the old session id.
> 
> Yes.
> 
> > > b. Is it useful to make a distinction between Service-Type= 
> > > "Authenticate Only" and other Service-Types?
> >
> > From a purists point of view Authentication Only should 
> only be about 
> > authentication and not anything do to about authorization.  
> So I would 
> > like to see that.  But obviously we should not break things.
> 
> I believe that current usage of "Authenticate Only" is 
> consistent with that, although usage is not  universal.
>