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

From: Mark Jones <[email-masked]>
Date: Mon, 3 May 2004 16:24:04 -0400

I have a comment on the following section (2.2) in nasreq-15:

   If accounting is active, every change of authentication or
   authorization SHOULD generate an accounting message.  If the NAS
   service is a continuation of the prior user context, then an
   Accounting-Record-Type of INTERIM_RECORD indicating the new session
   attributes and cumulative status would be appropriate. If a new user
   or a significant change in authorization is detected by the NAS, then
   the service may consider it appropriate to send two messages of  the
   types STOP_RECORD, and START_RECORD.

In the re-authorization case, I am not comfortable with letting the NAS
implementor deciding what constitutes a "significant change". The
re-authorization request is used to trigger events of significant billing
interest so predictable behavior across vendors is critical. I think
interoperability would be better served by a more explicit requirement on
the NAS. Two possible solutions come to mind:

EITHER

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

OR

(2) The AAA server MUST specify whether the Stop/Start is required at the
time it requests the re-authorization. If the AAA server does not request a
Stop/Start at re-authorization, the NAS MUST NOT send any accounting
messages for this event.

I have a preference for (2) since it eliminates redundant accounting
messages in those cases where the service provider is not dependent on the
Stop/Start messages to bill for the service change triggered by
re-authorization.

Regards
Mark

---

From: [email-masked]
Date: Tue, 04 May 2004 12:48:04 +0200

>Stop/Start messages to bill for the service change triggered by
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. Your MUST NOT will prevent us from 
proxying those events.

-- 
Jo Hermans

---

From: David Mitton <[email-masked]>
Date: Tue, 04 May 2004 12:16:17 -0400

>>the NAS. Two possible solutions come to mind:

Well, in the old stateless days of RADIUS, the server may know almost nothing.
In many cases the server doesn't really authenticate or authorize, it 
delegates   that problem by checking a static database.

Still, in Diameter, the NAS really is the only one that is required to 
operationally have the current context of the session, as servers may fail 
and transition.

But this raises some points worth discussing:

- Why does a session do re-authentication/re-authorization?

a) to reaffirm that the same user is still on the line
b) to re-spin the user's keys for better security
c) to re-authorize the user's continued service
         (policy only allows x sized chunks)
d) to authorize more service for the user
         (secondary authorization has been approved)
d) to authorize a different service for the same user
         (service provides multiple types of service)

- When does re-authentication/re-authorization happen?

a) by Authorization-Lifetime timeout
b) by spontaneous Server request (RAR message)
c) by spontaneous NAS request
         (underlying auth mechanism like CHAP or 802.1x)

What's the difference between a Re-Auth and a new call?
- there's an open connection context on the NAS
         port resources with state and prior
         user information and possible encryption keys

- there's an open resource context in the Server
         (and potential stateful proxy servers)
These resources have to re-allocated (sessions closed with STR)
- We used the same Session-ID in the Re-Auth AAR message.

How can we tell that it's not the same call?
- different user identification?  Is there a requirement for this? maybe

- different user credentials?
         (straw man - these may not be visible at the NAS, and may be 
purposely  different to prevent replay and MtM attacks)

- auth fails! - end of story or do we allow retries? ;^)

- Server says so!?
         The only technical addition I think we may need here.

         Perhaps we need an AVP for the server to say, START_OVER.
         Note that the Session-Id got re-used in the AAR.

It's possible to make a case that if the user presents a different user 
identity to the NAS, that we should NOT treat this as a re-auth, but a new 
session call.
This would catch the issues of services that cannot detect port cycling.

>>parameters, the NAS MUST treat this as a new session and send two messages

"any" is too broad a term to leverage a MUST here.  A typical auth upgrade 
scenario is the addition of more parameters.

>>Stop/Start at re-authorization, the NAS MUST NOT send any accounting

Like the other correspondent notes (below), and I have noted previously...
Why are you trying to stop my application from sending Accounting messages?
Perhaps _I_ need those messages.

>>Stop/Start messages to bill for the service change triggered by

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 given back-end billing model believes that certain NAS Accounting 
messages are irrelevant, it can discard them at some stage of the 
collection and collation processing.

It also possible to provide managed NAS behavior.  The messages could be 
optioned off by NAS management, if not needed in a given configuration.
This protocol covers a host of services, not just yours.

>>Regards
>>Mark
>>
>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 
>still be backwards compatible. Your MUST NOT will prevent us from proxying 
>those events.
>
>--
>Jo Hermans

The only way we are going to achieve consensus on this specification is to 
stop trying to disallow practices already out there.

The protocol should provide a framework that reports changes and events in 
service.  How those services are billed is configuration dependent.  How 
these services MAY be billed is more relevant.   The protocol should be 
flexible enough to ALLOW for predicable and common practice.  It should be 
specific enough that NAS and Server vendors can build interoperable products.

Now, for the fans of micro-sub-sessions that STOP/START all the time, the 
current text allows for that.  It seems that Section 9.6 of RFC 3588 even 
allows that the Session-Id of Accounting messages doesn't have to be the 
same as the Auth messages. (kind of bizarre, but there it is)

So I think the only issue to address is a bit of confusion over how we 
detect  changes in user context (at both the NAS and Server) with respect 
to an established session (Note that a session is defined around 
authenticated user call context) as to prevent any injection attacks.

Dave.