Subject: [AAA-WG]: Re: Bug in Acct state machine

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Apr 2002 11:28:00 +0300

Pete, Bob,

Thanks for taking a look at the state tables, and Pete I think
you analysis was right on. I agree with the PendingI problem,
and you suggested solution. I also agree with the split.

Additionally, I think we should delete the accounting entries
from the auth tables, and simply deal with accounting under 8.2
regardless of whether it is a part of an auth application or separate
activity.

Also, if we split the server and client on the accounting side,
I think we can collapse all server side accounting states to
Idle.

And then to Bob's comments:

 > I think you might want to split the above "ASR Received" event
 > into three events, making the client's state machine more
 > consistent with the Server's state machine and with the base
 > protocol text; i.e.

Yes.

 >Shouldn't the above be:
 >        Discon    ASR Received                   Send STA.  Discon

Not quite. The STA is sent by the server, not the client.

There is an issue, however, on what to do if we have already sent an STR,
are waiting for the STA to arrive but then we get an ASR from the server
(STR and ASR meet on the wire). The -09 state machine simply ignored the
ASR in this case, and on the server side was able to terminate the session
if, while waiting for ASA would instead get STR. I think Pete's state
machine gets it right as well.

 > > Open      Authorization-Lifetime (and    Cleanup    Discon
 > > Auth-Grace-Period) expires
 > > on home server.
 >
 > I think going to Idle is more appropriate above, because the server
 > may not be receiving an STR from the client, i.e.
 >
 >        Open      Authorization-Lifetime (and    Cleanup    Idle
 >                  Auth-Grace-Period) expires
 >                  on home server.

Yes, if the server didn't get an STR by this time, something is wrong.
Idle is right I believe.

 > >  Open      Session-Timeout expires on     Cleanup    Discon
 > > home server
 >
 > I think going to Idle is more appropriate above, because the server
 > may not be receiving an STR from the client, i.e.
 >
 >         Open      Session-Timeout expires on     Cleanup    Idle
 >                   home server

Yes, same here.

 > > Open      STR Received                   Send STA   Idle
 >
 > I'd add a "cleanup" to the above, i.e.
 >
 >         Open      STR Received                   Send STA,  Idle
 >                                                  Cleanup

Agreed.

 > I'd replace the above by:
 >
 >        Not Open  STR Received                   Send STA,  Idle
 >                                                 Cleanup

Yes, in theory the only remaining state beyond Discon is Idle and
it can't have state, but it's good to make the state machine
recover from errors.

 > Since the server isn't maintaining session state, I'd
 > delete the above "SERVER, STATELESS" table altogether.

I think we should keep the table, but have it contain just
one entry and state.

 > 1. When in the PendingX states, do you want to add entries for
 > an "Unsuccessful accounting answer received" event?

I was trying to fight against this because of complexity it adds
to the state machine. But I now see that Realtime-Required AVP
has an effect to how these things should be treated, and hence
I have now included even the error cases in the table.

 > 2. Do you want to add entries to deal with having to send a Stop
 > when a Start or Interim is still pending, e.g. something like:

Yes. But given that a Start or Interim is already in progress, I don't
want to send another message along at the same time. Therefore, I
have put in 'Store Record' as an action. Ok?

Updated state table attached, please review again!

Jari

8.1  Authorization Session State Machine

   This section contains a set of finite state machines, representing the life
   cycle of Diameter sessions, and which MUST be observed by all Diameter
   implementations that make use of the authentication and/or
   authorization portion of a Diameter application. The term Service-
   Specific below refers to a message defined in a Diameter application
   (e.g. Mobile IP, NASREQ).

   There are four different authorization session state machines
   supported in the Diameter base protocol. The first two describe a
   session in which the server is maintaining session state, indicated
   by the value of the Auth-Session-State AVP (or its absence).  One
   describes the session from a client perspective, the other from a
   server perspective. The second two state machines are used when
   the server does not maintain session state. Here again, one
   describes the session from a client perspective, the other from a
   server perspective.

   When a session is moved to the Idle state, any resources that were
   allocated for the particular session must be released.  Any event not
   listed in the state machines MUST be considered as an error
   condition, and an answer, if applicable, MUST be returned to the
   originator of the message.

   The following state machine is observed by a client when state is
   maintained on the server:

                              CLIENT, STATEFUL
      State     Event                          Action     New State
      -------------------------------------------------------------
      Idle      Client or Device Requests      Send       Pending
                access                         service
                                               specific
                                               auth req

      Idle      ASR Received                   Send ASA   Idle
                for unknown session            with
                                               Result-Code
                                               = UNKNOWN-
                                               SESSION-ID

      Pending   Successful Service-specific    Grant      Open
                authorization answer           Access
                received with default
                Auth-Session-State value

      Pending   Successful Service-specific    Sent STR   Discon
                authorization answer received
                but service not provided

      Pending   Error processing successful    Sent STR   Discon
                Service-specific authorization
                answer

      Pending   Failed Service-specific        Cleanup    Idle
                authorization answer received

      Open      user or client device          Send       Open
                requests access to service     service
                                               specific
                                               auth req

      Open      Successful Service-specific    Extend     Open
                authorization answer received  Answer

      Open      Failed Service-specific        Discon.    Idle
                authorization answer           user/device
                received.

      Open      Session-Timeout Expires on     Send STR   Discon
                Access Device

      Open      ASR Received,                  Send ASA   Discon
                client will comply with        with
                request to end the session     Result-Code
                                               = SUCCESS,
                                               Send STR.

      Open      ASR Received,                  Send ASA   Open
                client will not comply with    with
                request to end the session     Result-Code
                                               != SUCCESS

      Open      Authorization-Lifetime +       Send STR   Discon
                Auth-Grace-Period expires on
                access device

      Discon    ASR Received                   None       Discon

      Discon    STA Received                   Discon.    Idle
                                               user/device

   The following state machine is observed by a server when it is
   maintaining state for the session:

                             SERVER, STATEFUL
      State     Event                          Action     New State
      -------------------------------------------------------------
      Idle      Service-specific authorization Send       Open
                request received, and          successful
                user is authorized             serv.
                                               specific answer

      Idle      Service-specific authorization Send       Idle
                request received, and          failed serv.
                user is not authorized         specific answer

      Open      Service-specific authorization Send       Open
                request received, and user     successful
                is authorized                  serv. specific
                                               answer

      Open      Service-specific authorization Send       Idle
                request received, and user     failed serv.
                is not authorized              specific
                                               answer,
                                               Cleanup

      Open      Home server wants to           Send ASR   Open
                terminate the service

      Open      ASA Received                   Cleanup    Idle
                with Result-Code
                = UNKNOWN-SESSION-ID

      Open      ASA Received                   None       Open
                with Result-Code               
                not = UNKNOWN-SESSION-ID

      Open      Authorization-Lifetime (and    Cleanup    Idle
                Auth-Grace-Period) expires
                on home server.

      Open      Session-Timeout expires on     Cleanup    Idle
                home server

      Open      STR Received                   Send STA,  Idle
                                               Cleanup

      Not       ASA Received                   None       No Change.
      Open

      Not       STR Received                   Send STA,  Idle
      Open                                     Cleanup

   The following state machine is observed by a client when state is
   not maintained on the server:

                              CLIENT, STATELESS
      State     Event                          Action     New State
      -------------------------------------------------------------
      Idle      Client or Device Requests      Send       Pending
                access                         service
                                               specific
                                               auth req

      Pending   Successful Service-specific    Grant      Open
                authorization answer           Access
                received with Auth-Session-
                State set to
                NO_STATE_MAINTAINED

      Pending   Failed Service-specific        Cleanup    Idle
                authorization answer
                received

      Open      Session-Timeout Expires on     Discon.    Idle
                Access Device                  user/device

      Open      Service to user is terminated  Discon.    Idle
                                               user/device

   The following state machine is observed by a server when it is not
   maintaining state for the session:

                              SERVER, STATELESS
      State     Event                          Action     New State
      -------------------------------------------------------------
      Idle      Service-specific authorization Send serv. Idle
                request received, and          specific
                successfully processed         answer

8.2  Accounting Session State Machine

   For applications that only require accounting services or
   applications that have an accounting portion, the following state
   machines MUST be supported. The first is to be observed by clients,
   the second by servers.

   When a session is moved to the Idle state, any resources that were
   allocated for the particular session must be released.  Any event not
   listed in the state machines MUST be considered as an error
   condition, and an answer, if applicable, MUST be returned to the
   originator of the message.

   In the state table, the event 'Failure to send' means that the
   Diameter client is unable to communicate with the desired
   destination. This could be due to the peer being down, or due to
   the peer sending back a transient failure or temporary protocol
   error notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or
   DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting
   Answer command.

   The event 'Failed answer' means that the Diameter client received a
   non-transient failure notification in the Accounting Answer
   command.

   Note that the action 'Disconnect user/dev' MUST have an effect also
   to the authorization session state table, e.g. cause the STR
   message to be sent, if the given application has both
   authentication/authorization and accounting portions.

                            CLIENT, ACCOUNTING
      State     Event                          Action     New State
      -------------------------------------------------------------
      Idle      Client or device requests      Send       PendingS
                access                         accounting
                                               start req.

      Idle      Client or device requests      Send       PendingE
                a one-time service             accounting
                                               event req

      Idle      Records in storage             Send       PendingB
                                               record

      PendingS  Successful accounting                     Open
                start answer received

      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

      PendingS  Failed accounting start answer            Open
                received and realtime equal
                to GRANT_AND_LOSE

      PendingS  Failed accounting start answer Disconnect Idle
                received and realtime not      user/dev
                equal to GRANT_AND_LOSE

      PendingS  User service terminated        Store      PendingS
                                               stop
                                               record

      Open      Interim interval elapses       Send       PendingI
                                               accounting
                                               interim
                                               record

      Open      User service terminated        Send       PendingL
                                               accounting
                                               stop req.

      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

      PendingI  Failed accounting interim                 Open
                answer received and realtime
                equal to GRANT_AND_LOSE

      PendingI  Failed accounting interim      Disconnect Idle
                answer received and realtime   user/dev
                not equal to GRANT_AND_LOSE

      PendingI  User service terminated        Store      PendingI
                                               stop
                                               record

      PendingE  Successful accounting                     Idle
                event answer received

      PendingE  Failure to send and buffer     Store      Idle
                space available                event
                                               record

      PendingE  Failure to send and no buffer             Idle
                space available

      PendingE  Failed accounting event answer            Idle
                received

      PendingB  Successful accounting answer   Delete     Idle
                received                       record

      PendingB  Failure to send                           Idle

      PendingB  Failed accounting answer       Delete     Idle
                received                       record

      PendingL  Successful accounting                     Idle
                stop answer received

      PendingL  Failure to send and buffer     Store      Idle
                space available                stop
                                               record

      PendingL  Failure to send and no buffer             Idle
                space available

      PendingL  Failed accounting stop answer             Idle
                received

                            SERVER, ACCOUNTING
      State     Event                          Action     New State
      -------------------------------------------------------------

      Idle      Accounting start request       Send       Idle
                received, and successfully     accounting
                processed.                     start
                                               answer

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

      Idle      Interim record received,       Send       Idle
                and successfully processed.    accounting
                                               answer

      Idle      Accounting stop request        Send       Idle
                received, and successfully     accounting
                processed                      stop answer

      Idle      Accounting request received,   Send       Idle
                no space left to store         accounting
                records                        answer,
                                               Result-Code
                                               = OUT_OF_
                                               SPACE

---

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Apr 2002 15:33:57 +0300

Submitter name: Jari Arkko
Submitter email address: [email-masked]
Date first submitted: April 1, 2002
Reference:
Document: Base
Comment type: T
Priority: S
Section: 8.18
Rationale/Explanation of issue:

The ALLOW_SERVICE and TRY_AGAIN_ALLOW_SERVICE cases talk
about what to do after STR fails, and indicate that, if
the delivery of the STR fails, the session should be
terminated.

Duh! Isn't the session terminated _anyway_ if we are
in the progress of sending STRs?

But perhaps I'm missing something.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Apr 2002 14:51:41 +0300

> machine gets it right as well.

On second thought, and on reading section 8.5, it seems that the more
appropriate action is really answering the ASR also. The ASR could
come from some other server than the one we sent the STR to. So,
if we are in the progress of releasing the session already and we
get ASR, we should respond with ASA Result-Code = Success.

Modified state machine attached.

Jari

                              CLIENT, STATEFUL

      Discon    ASR Received                   Send ASA   Discon

                             SERVER, STATEFUL

                              CLIENT, STATELESS

                              SERVER, STATELESS

                            CLIENT, ACCOUNTING

                            SERVER, ACCOUNTING

---

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Apr 2002 16:44:56 +0300

Hi,

Over the weekend I went through the base-09 to try and catch both
editorial and other possibly remaining problems. The results have
been documented in the link

   http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20#320

[ The file is still missing all comments beyond section 8.3 but
I'm sure that it will be updated as soon as Bernard wakes up ;-) ]

My comments are mostly editorial and/or improvements to explanations,
but there are also a number of technical observations. For your convenience,
I'll list the most interesting observations below.

I didn't find anything horrible, the document seems to be in reasonable
state even if there were a lot of smaller inconsistencies. We do need to
have several people agree that the new state machines are OK, however.

Jari
----
1.2.1:

- "If the new AVP value changes an existing command code's ABNF, the
IANA AVP value request MUST include the new ABNF itself.": I'm not
sure how a new AVP value for enumerated could ever change the ABNF.
Propose to remove this sentence.

2.1:

- "Diameter implementations SHOULD be able to interpret ICMP protocol
port unreachable messages as explicit indications that the server is
not reachable, in addition to interpreting ECONNREFUSED (a reset from
the transport) and timed-out connection attempts."
=>
"Diameter implementations SHOULD be able to interpret ICMP protocol
port unreachable messages as explicit indications that the server is
not reachable, subject to security policy on trusting such messages.
Diameter implementations SHOULD also be able to interpret ECONNREFUSED
(a reset from the transport) and timed-out connection attempts."

3.0:

- Under Vendor-ID: "All vendor-specific Diameter commands require
Information RFCs documenting the command.". First of all, it's
Informational, not Information. Secondly, I really wonder about
the usefulness of such a strong requirement. Section 11.2 talks
about 'private use'. I would say "It is recommended that vendor-specific
Diameter commands are documented in Informational RFCs."

- The rules on DiameterIdentity contents are really
unclear. I don't understand what the DI = fqdn
statement intends to say, nor does it say anywhere
how the multiple DIs on multi-server nodes are
supposed to be created. I suggest the following text
to replace this entry:

"DiameterIdentity value is used to uniquely identify a Diameter
node for purposes of duplicate connection and routing loop
detection.

The DiameterIdentity format is derived from the OctetString Base AVP
Format. It uses the UTF-8 encoding and has the same requirements as
UTF8String.

The contents of the string MUST be the fqdn of the Diameter node.
If multiple Diameter nodes run on the same host, each Diameter
node MUST be assigned a unique DiameterIdentity. If a Diameter
node can be identified by several FQDNs, a single FQDN should
be picked at startup, and used as the only DiameterIdentity for
that node, whatever the connection it is sent on."

4.4:

- Under filterrule and the "assigned" explanation, the SHOULD
remark about the first rule is confusing and incorrect for
IPv6. Replace with the following text: "For IPv4, a typical
first rule is often "deny in ip !assigned""

- Add after the "ipno/bits" text: "For a match to occur, the
same IP version must be present in the packet that was used
in describing the IP address. To test for a particular IP version,
the bits part can be set to zero."

- Icmptypes, add text "Both the numeric values and the symbolic
values listed below can be used."

- Under QoSFilterRule, the dir, proto, and src/dst explanations
are copy-pasted from the IPFilterrule, and somewhat incorrect
(e.g. about the advice for the first rule). My suggestion is
to include the following text *only*:

dir The format is as described under IPFilterRule.

proto The format is as described under IPFilterRule.

src and dst The format is as described under IPFilterRule.

- In QoSFilterRule, there's no similar statement as we had for
IPFilterRule about what to do if the NAS doesn't support this
filter. I propose the following:

An access device that is unable to interpret or apply a QoS
rule SHOULD NOT terminate the session.

4.5:

- Remove all bnf starting from the "Fixed" since that
has already been described earlier in the same way
under the command abnf section.

5.1:

- How come are the failover procedures *not* implemented if the
primary goes to suspect list? This seems to be an error,
given that the transport draft says FailOver is called from
the OKAY state if timer fires.

5.6.4:

- "Hanging octets are assumed to have value 0x80, but
dimpled octets are ignored." What is this??!?!?

6.1.7:

- The language is somewhat clear as to whether a single or
multiple Redirect-Host AVPs are allowed. My suggestion is
to allow multiple. Add the following text to the end of the
section: "Multiple Redirect-Host AVPs are allowed. The receiver
of the answer message with the 'E' bit set selects exactly one
of these hosts as the destination of the redirected message."

6.10:

- "Either the Auth-Application-Id or the Acct-
Application-Id AVP MAY be present. Both AVPs MAY be present if they
both contain the same value." This is somewhat problematic. Useful
in CER, but not absolutely necessary. And would present problems in
accounting or auth commands. My suggestion is to have CER include
multiple copies if necessary. Therefore, propose the following text:
"Exactly one of the Auth-Application-Id and Acct-Application-Id AVPs
MAY be present."

8.1:

- You've seen the state machine discussion on the list. This appears
   to be the only serious issue, and I hope everyone contributes in
   verifying that the latest version is really ok.

- The auth state machines (both versions) have an action
to send or receive an accounting message. This seems inadequate,
and is perhaps a remnant of the old state machine which didn't
do a good job in accounting. I propose that the two entries
in the state machine are removed

9.1:

- Add at the end of the second paragraph: "Note, however,
   that even if at the Diameter layer accounting requests
   are processed one by one, transport protocols used under
   Diameter typically batch several requests in the same packet
   under heavy traffic conditions. This may be sufficient for many
   applications."

- "The server (or agents) uses
    the Accounting-Interim-Interval AVP to control the operation of the
    Diameter peer operating as a client."
   =>
   "The server (or agents) uses
    the Accounting-Interim-Interval and Accounting-Realtime-Required AVPs to control
    the operation of the Diameter peer operating as a client."

9.2:

- "A rejected Accounting-Request message SHOULD
    cause the user's session to be terminated."
   =>
   "A rejected Accounting-Request message MAY
    cause the user's session to be terminated,
    depending on the value of the Accounting-Realtime-Required AVP received
    earlier for the session in question."

11:

- Add a new section 11.16:
   11.16  Accounting-Realtime-Required AVP Values

    As defined in Section 9.8.7, the Accounting-Realtime-Required AVP (AVP Code
    483) defines the values 1-3. All remaining values are available for
    assignment via IETF Consensus [IANA].

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 1 Apr 2002 07:09:13 -0800 (PST)

Assigned issue #323.

---

From: Pete McCann <[email-masked]>
Date: Mon, 1 Apr 2002 11:04:44 -0600 (CST)

Ok, it looks like there were some unresolved issues left in the state
machine table.  I'm glad I posted; it seems like separating client
from server states made the issues stand out a little better.  I think
I agree with Jari's changes, but I have a question on something that I
don't quite understand:

 >       Open      ASA Received                   Cleanup    Idle

I think I agree that if an ASA is received in response to an ASR, and
the code is DIAMETER_UNKNOWN_SESSION_ID, then we should clean up the
session and go to idle.  For instance, the access device may have
forgotten about the session.  Do we need something explicit to state
that the ASA is in response to an ASR (i.e., the Identifiers match)?
Note that the state on the left is just "Open", there is nothing to
indicate we have sent an ASR.

 >       Open      ASA Received                   None       Open

So the other two response codes are DIAMETER_SUCCESS and
DIAMETER_UNABLE_TO_COMPLY.  Should these both result in ignoring the
response?  I might agree with the latter, but certainly not the
former!

I suggest that DIAMETER_UNKNOWN_SESSION_ID and DIAMETER_SUCCESS be
used for the first event, and that the second simply use
DIAMETER_UNABLE_TO_COMPLY.

-Pete

---

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Apr 2002 20:07:37 +0300

Pete McCann wrote:

> I'm glad I posted; it seems like separating client
> from server states made the issues stand out a little better.

Indeed.

> indicate we have sent an ASR.

I'm not sure we do. The session-id match seems to be an implicit assumption
on almost all events, just to get to the right session and its state we
need session-id.

> DIAMETER_UNABLE_TO_COMPLY.

The whole ASA handling seems a bit weird, now that I look at it.
If we need to abort, we need to abort and clean up the state regardless
of whether there was some problem somewhere which prevented us
from doing so. The question is, is the error something that is temporary
such as network partitioning, or something which is caused by a software
problem at either end? If former, it makes sense to wait and retry. If
latter, we really don't want to get into a loop here.

There's two possible approaches to this. One approach is that we ignore
the problem, and allow temporary problems to prevent abortions. Another
approach is to make the state machine more complex and in a manner similar
to the accounting state machine keep on trying if the problem is temporary.

Perhaps the latter approach is more appropriate. I've added a new state
for the server side, and dealt with different error codes in different
manner. Please comment. Voice your opinion also if you wanted
alternative #1.

Jari

                              CLIENT, STATEFUL

                             SERVER, STATEFUL

      Open      Home server wants to           Send ASR   Discon
                terminate the service

      Discon    ASA Received                   Cleanup    Idle
                with Result-Code
                = SUCCESS

      Discon    Unable to send ASR or          Wait,      Discon
                ASA Received                   Send ASR
                with Result-Code     
                = TOO_BUSY or
                LOOP_DETECTED

      Discon    ASA Received                   Cleanup    Idle
                with Result-Code               
                not = SUCCESS and
                not = TOO_BUSY and
                not = LOOP_DETECTED

      Discon

                              CLIENT, STATELESS

                              SERVER, STATELESS

                            CLIENT, ACCOUNTING

                            SERVER, ACCOUNTING

---

From: Pete McCann <[email-masked]>
Date: Mon, 1 Apr 2002 13:39:52 -0600 (CST)

Hi, Jari,

I agree with what you wrote, but perhaps a bit of clean-up can be
done; the Accounting state machine defines the condition "Failure to
Send" as including unable to reach peer, OUT_OF_SPACE, LOOP_DETECTED,
or TOO_BUSY.  Perhaps you can define a similar condition for the
authorization session state, maybe without the OUT_OF_SPACE.

Also, can't the following two actions be combined?

 >       Discon    ASA Received                   Cleanup    Idle

Here you could use the complement of "Failure to Send" as the triggering
event, and just cleanup and go to Idle no matter what is received.

Also,

 >                 authorization answer received    ^^^^ "Send"
 >                 but service not provided
 > 
 >                 Service-specific authorization   ^^^^ "Send"
 >                 answer

Also,

  s/UNKNOWN-SESSION-ID/UNKNOWN_SESSION_ID

-Pete