Subject: Re: [AAA-WG]: [Issue] Granting Access via Accounting

From: Jari Arkko <[email-masked]>
Date: Thu, 03 Jan 2002 16:03:16 +0200

Hi.

I have now merged some requested modifications to
the accounting state table [1, 2, 3]. These requests
included

  - Adding one-time service accounting entries.

  - Removing dependency on waiting for the ack
    from the server before granting service. I
    also did the same modification for the session
    disconnection.

I also modified in addition the following:

   - An entry to deal with sending an
     interim record.

   - Renamed states in a more consistent manner.

I have NOT dealt with the following [2] yet since
I think more discussion is needed:

  - Sections 9.4 and 8.2 are in conflict.
    The former requires clients to store acct
    records during network outage, and the 
    latter requires immediate sending. I'll
    file a separate issue on this.

  - Adding the capability for an accounting server
    to send an ASR to the Diameter client.

[1] http://www.merit.edu/mail.archives/aaa-wg/msg02788.html
[2] http://www.merit.edu/mail.archives/aaa-wg/msg02791.html
[3] http://www.merit.edu/mail.archives/aaa-wg/msg02807.html

State     Event                          Action     New State
-------------------------------------------------------------
Idle      Client or device requests      send       PendingE
          a one-time service             accounting
                                         event req.
                                         and grant
                                         service

Idle      Client or device requests      send       PendingS
          a measurable length service    accounting
                                         start req.
                                         and grant
                                         service

Idle      Accounting event request       send       Idle
          received, and successfully     accounting
          processed.                     event
                                         answer

Open      Time to send an interim        send       PendingI
          record                         accounting
                                         interim
                                         req.

Open      Receive Interim Record         send       Open
                                         accounting
                                         answer

Open      The measurable length user     send       PendingD
          service terminated             accounting
                                         stop req.
                                         and discon.
                                         user/device

Open      Accounting stop request        send       Idle
          received, and successfully     accounting
          processed                      stop answer

PendingE  Successful accounting                     Idle
          event answer received          

PendingS  Successful accounting                     Open
          start answer received          

PendingI  Successful accounting                     Open
          interim answer received

PendingD  Successful accounting                     Idle
          stop answer received           

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 03 Jan 2002 17:13:17 +0200

Submitter: Jari Arkko <[email-masked]>
Date: January 3, 2002
Reference: 
Document: BASE-08
Comment type: T
Priority: S 
Section: 8.2
Rationale/Explanation of issue:

Sections 9.4 and 8.2 are in conflict.
The former requires clients to store acct
records during network outage, and the 
latter requires immediate sending.

The specification is also silent on
how the client devices know whether
it should grant access during times
of network outages towards the accounting
server. I can imagine that in some
cases we would like to stop services if
we can't provide real-time accounting,
while in some other cases we would like
to continue.

Furthermore, the state machine in 8.2
(as well as the one that I just posted)
does not specify what to do when things
happen to the session faster than what it
takes for an ack to come back from the server.
For instance, what should we do if the session
is terminated while we are still waiting for
the start ack?

Proposed change:

An AVP similar to the Accounting-Interim-Interval
could be used to control whether access should be
granted or discontinued upon problems in sending
the accounting records.

The state machine must be modified to consider what
to do with session termination and interim record
generation while we are still waiting to send previous
data.

9.8.x. Accounting-Realtime-Required AVP

   The Accounting-Realtime-Required AVP (AVP Code TBD) is of type
   Enumerated and is sent from the Diameter home authorization server to
   the Diameter client. The client uses information in this AVP to
   decide what to do if the sending of accounting records to the
   accounting server has been temporarily prevented due to,
   for instance, a network problem.

      DELIVER_AND_GRANT			1

         The AVP with Value field set to DELIVER_AND_GRANT means
         that the service MUST only be granted as long as there is
         a connection to an accounting server. Note that the set
         of alternative accounting servers are treated as one server
         in this sense. Having to move the accounting record stream to a
         backup server is not a reason to discontinue the service
         to the user.

      GRANT_AND_STORE			2

         The AVP with Value field set to GRANT_AND_STORE means that
         service SHOULD be granted if there is a connection, or as
         long as records can still be stored as described in section
         9.4.

         This is the default behaviour if the AVP isn't included
         in the reply from the authorization server.

      GRANT_AND_LOSE			3

         The AVP with Value field set to GRANT_AND_LOSE means
         that service SHOULD be granted even if the records can
         not be delivered or stored.

8.2. Accounting State Machine

Add the following new entries:

PendingE  Failure to send and buffer     Store      Idle
          space available                Event
                                         Record
                        
PendingE  Failure to send and no buffer             Idle
          space available    
                          
PendingS  Failure to send and buffer     Store      Open
          space available and realtime   Start
          not equal to DELIVER_AND_GRANT Record

PendingS  Failure to send and no buffer             Open
          space available and realtime   
          equal to GRANT_AND_LOSE       
                       
PendingS  Failure to send and no buffer  Disconnect Idle
          space available and realtime   user/dev
          not equal to GRANT_AND_LOSE                                             
                            
PendingI  Failure to send and (buffer     Store     Open
          space available or old record   Interim
          can be overwritten) and         Record
          realtime not equal to
          DELIVER_AND_GRANT  

PendingI  Failure to send and no buffer             Open
          space available and realtime   
          equal to GRANT_AND_LOSE       
                       
PendingI  Failure to send and no buffer  Disconnect Idle
          space available and realtime   user/dev
          not equal to GRANT_AND_LOSE  

PendingD  Failure to send and buffer     Store      Idle
          space available                Stop
                                         Record

PendingD  Failure to send and no buffer             Idle
          space available       

Idle      Records in storage             Send       PendingB
                                         record

PendingB  Successful accounting answer   Delete     Idle
          received                       record

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 3 Jan 2002 09:35:24 -0800 (PST)

> latter requires immediate sending.

Here "network outage" means that absence of any connection in a usable
state, correct? Since the transport spec prohibits sending on closed or
suspect connections, if there is no connection that
can be used, then "immediate sending" is not an option. 

> server. 

There's an even bigger issue. The spec doesn't do a good job of 
differentating between "accounting servers" and servers that support
Diameter base (which now includes accounting). Accounting and
authentication now operate on the same port, and if I read the spec
correctly on page 17, it states that Accounting does not have
an Application Identifier because it is part of Base and therefore support
is mandatory. I think this may confuse "mandatory to implement" with
"mandatory to use". This means there is no way for a Diameter Server *not*
to advertise accounting capabilities! This appears to be contradicted by
section 5.3.1 on page 51, where the CER can include Acct-Application-Id. 

On page 19, it does indicate that a route entry can have a different
destination based on the Acct-Application-Id or Auth-Application-Id. 
So presumably if this can be exchanged in the CER, then it can be used in
routing. 

Since I envisage that the NAS will in most cases be dealing with a relay
which advertises *, in practice it seems like both accounting and auth
will flow over the same connection from NAS to relay, and then will be
separately routed by the relay. Thus, there will typically be "fate
sharing" between the two services on the first hop. 

Thus the notion of "primary" in the transport spec really means "primary
for a given Acct-Application-Id or Auth-Application-Id." This isn't
spelled out very well. 

> I can imagine that in some

I think we need to be careful about the definition of "can't provide
real-time accounting". Does this mean that the session will go down
whenever a transport failover occurs in any hop between the NAS and the
Accounting Server? How will the NAS even know if this occurs if the
failure is not on the first hop? Remember, the Watchdog isn't end to
end. It only tells the NAS that its first hop (often a relay) is alive. If
a connection goes down between the relay and a server, this doesn't affect
the NAS-Relay connection, which is still live. The Relay initiates
transport failover, and only after it runs out of options will it send a
DIAMETER_UNABLE_TO_DELIVER message back to the NAS. Should such a message
(or other error messages, too)sent in response to an Accounting Request
result in a stoppage of services? 

> is terminated while we are still waiting for

The state table should probably include more events. 

> granted or discontinued upon problems in sending

Specifically, I think you want to define "problems" as receipt of
any of a set of error messages or lack of *any*
accounting-capable connection on the NAS. 

In terms of error messages on pages 76-77 of the spec, it
occurs to me that for these purposes they would some protocol errors
(3xxx), some Transient Failures (4xxx) and some Permanent Failures (5xxx). 
For example:

3001 DIAMETER_COMMAND_UNSUPPORTED
3002 DIAMETER_UNABLE_TO_DELIVER (accounting server(s) unavailable)
3003 DIAMETER_REALM_NOT_SERVED (Can't find an accounting server)
3004 DIAMETER_TOO_BUSY (Accounting server overwhelmed)
3005 DIAMETER_LOOP_DETECTED 
3007 DIAMETER_APPLICATION_UNSUPPORTED
3008 DIAMETER_INVALID_HDR_BITS
4002 DIAMETER_OUT_OF_SPACE (No room on accounting server)

> generation while we are still waiting to send previous

Remember, that the failure can occur between Relay and Server too. 

>          a connection to an accounting server. 

Not sure this is an adequate definition, since the NAS can have a
connection to a relay that advertises *, but the accounting server can be
down, causing the relay to send DIAMETER_UNABLE_TO_DELIVER messages. 

>          Having to move the accounting record stream to a

Good. Let's avoid interaction with transport failover if we can.

---

From: "Yacine El Mghazli" <[email-masked]>
Date: Fri, 4 Jan 2002 12:14:08 +0100

thanks in advance.

-- Yacine El Mghazli
----------------------------------------------------------------------
  Alcatel R&I
  Marcoussis, France
  Tel  +33 1 6963 4187
  Fax  +33 1 6963 1169
  [email-masked]
----------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Fri, 04 Jan 2002 14:50:30 +0200

Somehow, in the middle of a Friday afternoon,
I have managed to forget how the following
works. Perhaps you can help.

PPP authentication can be run in two directions.
Normally we authenticate the user by the
server. But we could also run e.g. CHAP to
authenticate the server to the user.

AAA basically allows a remote node, the AAA
server, to perform the user authentication
instead of the NAS. But can AAA handle the
server authentication in a remote manner?
It can do this using mutually authenticating
EAP methods. But can it do it using other
authentication types such as CHAP? That is,
does our NASREQ extension allow for us to
send the server authentication CHAP challenge
to the server, and have it return the correct
answer?

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 Jan 2002 13:45:41 -0800 (PST)

I'm working on it. Current deadline for submission to the IETF archives is
1/14/01. It's the first thing on my list as soon as I get back from
vacation ;)