Subject: RE: [AAA-WG]: Issue: 8.1 Authorization Session State Machine

From: Thomas Panagiotis-PTHOMAS1 <[email-masked]>
Date: Wed, 29 Aug 2001 10:36:47 -0500

Most of my comments are in alignment with Fredrik's last
message.

> > Requested Change:
> > Add the following state:
> > Open		receive STR	 send STA	Closed
> Actually, it should be
> Open    STR Received    Send STA         Discon

How will the server ever get out of Discon? I think
that it should be
  Open    STR Received    Send STA,Cleanup  Closed

> Actually, the following
>   Open	ASA Received	Cleanup	Closed
> should have been
>   Discon	ASA Received	Cleanup	Idle

What difference does it make to go to Idle instead of Closed? 

Also, as part of this issue, I'd like to request for some
extra clarifications:

5. Client is in "Pending" and receives a failed Auth-Answer.
   ->goes to "Closed"?
6. Home Server is in "Idle", receives an Auth-Request and sends
   back a failed Auth-Answer.
   ->goes to "Closed"?
7. Home Server is in the "Open" and receives an Auth-Request
   ->sends an Auth-Answer and goes to "Open" if success, or
   "Closed" if failure?
8. Home Server wants to send an ASR
   -> goes to "Disconnect", right?

and a minor one...
"Pending  Successful Service-Specific      Grant    Active
          Authorization answer received    Access
          with Auth-Session-State set to
          NO_SESSION_MAINTAINED "

s/NO_SESSION_MAINTAINED/NO_STATE_MAINTAINED

-Panos

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Wednesday, August 29, 2001 8:57 AM
To: Fredrik Johansson
Cc: AAA Listan; Pat Calhoun
Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine

On Wed, Aug 29, 2001 at 11:06:08AM +0200, Fredrik Johansson wrote:
> Submitter name: Fredrik Johansson
> Submitter email address: [email-masked]
> Date first submitted: 2001-08-29
> Reference:
> Document: base
> Comment type: E
> Priority: 1
> Section:
> Rationale/Explanation of issue:
> 
> There are some missing states in the authorization session state machine.
> 
> 1. It is optional to send a ASR when cleaning up a session on a home
server,
> however there is no indication on what state to go to when doing so. My
> guess is that you should go to Disconnect and wait for a ASA. Since this
is
> an optional feature I'm not sure it should be in the state machine.
However,
> if you send an ASA there has to be a state indicating how to get from
> Disconnect to Closed.
> 
> Requested Change:
> 
> Add the following state
> 
> Discon	ASA Received	Cleanup	Closed
> BTW, it might just be a cut'n past error, the
> Open		ASA Received	Cleanup	Closed
> state should not exist, if you have sent an ASR you should not be in Open,
> so replace the latter with the first state above.

Actually, the following

Open	ASA Received	Cleanup	Closed

should have been

Discon	ASA Received	Cleanup	Idle

> 
> 2. There is no state where the home server can receive a service specific
> auth. request and extend access and stay in open.
> 
> Requested Change:
> Add a the following state:
> Open		Successful Service-Specific 		Extend	Open
> 		Authorization Request received	Access
> 

but -07 already has this exact state.

> 3. There is no state where the home server can receive a STR send a STA
and
> go to Closed
> 
> Requested Change:
> Add the following state:
> Open		receive STR					send STA
Closed

Actually, it should be

Open	STR Received	Send STA	Discon

> 
> 4. According to the following state:
> Open	Authorization-Lifetime 				Send		Open
> 	expires on access device			service
> 								specific
> 								auth req
> 
> It's not clear that an access device can not send a Service-Specific Auth.
> request on Authorization-Lifetime expiration unless it has received a MIP
> registration request or PPP request.
> 
> Requested Change:
> Can it be made clearer that if no such message has been received it should
> send a STR and go to Disconnect?

but this is service specific. If I was to add such language, it could break
the state machine for future apps that don't operate this way. I will assume
that the implementor knows that some access protocol interactions are
necessary
with the user, and leave it undefined.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 29 Aug 2001 15:47:09 -0700

> Most of my comments are in alignment with Fredrik's last

Please take a look at the complete state table below (I just realized that
I only sent a portion of it in my response to Fredrik). These changes were
the result of issues that have since been closed. Any comments on this
state table would be most appreciated:

State     Event                          Action     New State
-------------------------------------------------------------
Idle      Client or Device Requests      send       Pending
          access                         service
                                         specific
                                         auth req

Idle      Service-Specific authorization send serv. Open
          request received, and          specific
          successfully processed         answer

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

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

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

Open      Successful Service-Specific    Extend     Open
          Authorization request or       Access
          answer received

Open      Accounting message sent or     process    Open
          received

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
                                         STR

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

Open      Session-Timeout expires on     Cleanup    Discon
          home server

Discon    ASR Received                   None       Discon

Discon    STR Received                   Send STA   Idle

Discon    STA Received                   Discon.    Idle
                                         user/device

The following state machine is used when state is not maintained
on the server:

State     Event                          Action     New State
-------------------------------------------------------------
Idle      Client or Device Requests      send       Pending
          access                         service
                                         specific
                                         auth req

Idle      Service-Specific authorization send serv. Open
          request received, and          specific
          successfully processed         answer

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

Open      Accounting message sent or     process    Open
          received

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

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

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 30 Aug 2001 11:52:05 +0200

Pat,

I've a comment (apart from the one I just send about the send STR go to
Open).

from section 8.0
"An access device that does not expect to send a re-authorization or a
   session termination request to the server MAY include the Auth-
   Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint
   to the server.  If the server accepts the hint, it agrees that since
   no session termination message will be received once service to the
   user is terminated, it cannot maintain state for the session. "

according to the above paragraph there should be no state maintained. So why
move to Open on the server if no state should be maintained? I believe that
when receiving a Service Specific Auth Req/Ans with NO_STATE_MAINTAINED (and
the server accepts this) it would be better to go to Idle? If it is because
the server should be able to receive accounting messages for the session,
then I don't see the meaning of NO_STATE_MAINTAINED.

When is the NO_STATE_MAINTAINED used anyway?

/Fredrik

>Sent: den 30 augusti 2001 00:47
>To: Thomas Panagiotis-PTHOMAS1
>Cc: 'Pat Calhoun'; Fredrik Johansson; [email-masked]'

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 30 Aug 2001 06:22:54 -0700

> When is the NO_STATE_MAINTAINED used anyway?

So, if I was to modify the server side state to:

Idle      Service-Specific authorization send serv. Idle
          request received, and          specific
          successfully processed         answer

that would satisfy your issue? The client side still remains in the open
state since it has an active "connection" to the user. When the user goes
away the state control block is moved to Idle.

Is that ok?

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 30 Aug 2001 16:15:42 +0200

sounds good to me, might want to add that no state is maintained.

Idle      Service-Specific authorization send serv. Idle
          request received, and          specific
          successfully processed, and    answer
          NO_STATE_MAINTAINED

Just out of curiosity, do you have an example on when one might use the
NO_STATE_MAINTAINED?

thanks

/Fredrik

>Sent: den 30 augusti 2001 15:23
>To: Fredrik Johansson
>Cc: Pat Calhoun; Thomas Panagiotis-PTHOMAS1; [email-masked]

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 30 Aug 2001 07:08:07 -0700

> Just out of curiosity, do you have an example on when one might use the

you mean an app? No, but 3GPP is getting one ready.

So I can close the issue, then?

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 30 Aug 2001 16:27:27 +0200

Thanks,

yepp, please close this issue. One down not so many more to go (I hope),
although it seems like there is an endless stream of issues.

/Fredrik

>Sent: den 30 augusti 2001 16:08
>To: Fredrik Johansson