Subject: [AAA-WG]: Error in base-08 state machine ?

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 30 Jan 2002 08:43:04 -0500

Hi Mark,

This is just a preview of what might become an issue.  I want to bring
this up, but haven't clarified my thoughts enough to propose a
solution.

There might be a bug in the "Authorization Session State Machine", in
section 8.1 of the base draft, in the 1st state machine which
represents the case where the server maintains session-state.

If in OPEN state, the server wants the session to be be terminated, it
sends an ASR and goes into DISCON state.  When the ASA is received,
the server goes into IDLE state.  This seems not quite right for a few
reasons.

(1) When the server subsequently receives the follow-up STR from the
access device, the session will be either non-existent or in IDLE
state.

(2) The draft indicates that an access device is not required to honor
an ASR, i.e. the access device can just reply with "unable to comply"
and not terminate the session.  In this case the server would have
incorrectly terminated the session when receiving the negative ASA.

The state machine might look the way it does because it is trying to
accommodate the picture where some server other than the AAAH sends
the ASR.  Some sort of central session manager server.  In this case
the state machine works ok.  What I see as an error is in the case
where the AAAH sends his own ASR.

Here's a few more partly-baked thoughts:

(1) The protocol is asymmetrical; the server sends ASRs, receives auth
requrests, receives STRs, sends STAs, etc; while the access device
does the opposite.  It might be clearer to have two state tables, one
for the server and one for the access device.

(2) Is the access device allowed to ignore an ASR from the AAAH?  It
might be that the text indicating that the access device is not
required to honor an ASR is so that any old schmuck cannot just
terminate a session. But should the access device be REQUIRED to honor
the ASR if it comes from the AAAH?

(3) This is a very-slightly baked thought: the state machine might
want an entry or two about re-auths.  Maybe the client's state table
needs to differentiate between a "pending" re-auth versus a "pending"
initial auth, and to reflect when a re-auth is pending versus
hasn't-been-sent-yet.  While the re-auth is pending, the service is
effectively Opened for continued business, but not so when the initial
auth is pending.  Also, the client can receive an ASR while a re-auth
is pending, but not so when the inital auth is pending.

Bob K.

---

From: Johan Johansson <[email-masked]>
Date: Wed, 30 Jan 2002 16:12:15 +0100

>access device, the session will be either non-existent or in IDLE
It gets better. There is no specified order between the STR and the ASA, 
and since they may very well travel different routes specifying and 
order in the sending of them from the client wouldn't rectify this. If 
you really want your messages to add up you will need to add an 
intermediate state and transitions both on received STR and STA from 
both (well ok there are other possible statemachines but this seems like 
the smallest). The solution we have adopted for our mobile ip sessions 
is to simply ignore whichever arrives last.

>incorrectly terminated the session when receiving the negative ASA.
So on a negative ASA you would go back to open and stay there 
indefinately? Would you do the same thing if the ASR was undeliverable? 
It could be stated for good reasons that every service you receive after 
attempting to tear down the session is free.

>for the server and one for the access device.
It certainly would. I think any reasonable implementation would separate 
them anyway.

>the ASR if it comes from the AAAH?
This brings me back to the question of why ASRs don't have termination 
causes while STRs do?

j