Subject: [AAA-WG]: draft-ietf-aaa-diameter-01 / Stateless server

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 28 Mar 2001 21:34:11 -0500

Hi Pat,

One section of the draft indicates that a server can be stateless
(i.e. maintaining neither session-state nor transaction-state),
while another suggests that servers must maintain at least
transaction-state:

Section 12.4 states that a server can be completely stateless:

>  12.4  Proxy Server
>
>  This section outlines the processing rules for Diameter proxy
>  servers.  A proxy server can either be stateful or stateless. A Proxy
>  server MAY act in a stateful manner for some requests, and be
>  stateless for others. There are two types of states that servers MAY
>  wish to maintain; transaction and session.
>
>  Maintaining transaction state implies that a server keeps a copy of a
>  request, which is then used when the corresponding response is
>  received.
>
>  [...]

But section 7.3 suggests that it is "necessary" for a [proxy]
server to maintain transaction state, for failover purposes.

>  7.3  Failover/Failback Procedures
>
>  In the event that a transport failure is detected with a peer, it is
>  necessary for all pending request, query and indication messages to
>  be forwarded to an alternate server, if possible. This is commonly
>  referred to as failover.
>
>  In order for a Diameter node to perform failover procedures, it is
>  necessary for the node to maintain a pending message queue for a
>  given peer. When a response is received, the message is removed from
>  the queue. 
>
>  [...]

Bob K.

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 29 Mar 2001 16:34:10 -0800 (PST)

Bob,

Great catch. In adding the failover text, I completely missed this one. I am
proposing the following text to replace the existing section 12.4:

12.4  Proxy Server

   Maintaining transaction state implies that a server keeps a copy of a
   request, which is then used when the corresponding response is
   received.  This could be done to apply local policies to the message,
   or simply for auditing purposes. Maintaining session state implies
   that a server keeps track of all "active" users. An active user is
   one that has been authorized for a particular service, and the server
   has not received any indication that the user has relinquished
   access.

   A stateless proxy is one that does not maintain session state, but
   MUST maintain transaction state. Transaction state SHOULD be released
   after a request's corresponding response has been forwarded towards
   the recipient, and has been acknowledged by the underlying transport.

   A stateful proxy is one that maintains session state, by observing
   request and responses. Session state SHOULD be released once it is
   informed that a user and/or device has relinquished access. A
   stateful server MAY provide the following features:
      - Protocol translation (e.g. RADIUS <-> Diameter)
      - Limiting resources authorized to a particular user
      - Per user or transaction auditing

   Home servers processing requests that include the Route-Record and/or
   the Proxy-State AVPs MUST return these AVPs in the same order in the
   corresponding response.

---

From: Barney Wolff <[email-masked]>
Date: Fri, 30 Mar 2001 01:26:36 -0500

Ok, now I'm really confused.  Back when we were debating stateful/
stateless, I could have sworn we were talking about transaction
state, not session state.  At least I was.

Be that as it may, this language is confusing, as it seems to (but
cannot really) say that only a (session-)stateless proxy MUST maintain
transaction state.

Also, what does the statefulness of a proxy or server have to do
with its ability to do protocol translation?  And the paragraph
starts out talking about a stateful proxy but shifts to a server.

<my standard diatribe on over-specifying internal behavior>
I have nothing against advice to implementors, but believe we go
too far when we use WORDS to express it.

Regards,
Barney

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 30 Mar 2001 06:55:33 -0800 (PST)

> state, not session state.  At least I was.

Right, but the new failover text *requires* that transaction state be
maintained. So I think the problem was that at the time we were discussing
state vs. stateless, we didn't have the whole picture.

> cannot really) say that only a (session-)stateless proxy MUST maintain

then I need to re-visit the text again.

> starts out talking about a stateful proxy but shifts to a server.

because the implementor's guidelines discusses some RADIUS attributes (e.g.
Class) which must be saved for future sessions. Of course, another alternative
is to allow these RADIUS attributes to be encoded in an AVP, and this AVP MUST
be present in future messages.

This, however, is new protocol work, and we have decided to cut new features.

> too far when we use WORDS to express it.

Again, read the failover text, and you will quickly see that mainaining
transaction state is no longer a MAY :(

PatC