Subject: RE: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0

From: "Martin Julien (ECE)" <[email-masked]>
Date: Tue, 23 Jan 2001 11:18:11 +0100

Barney,

I understand you point and I totally agree with you. However, could you please help me with the following scenario? I'd like to know if you would consider it a problem related to the configuration of the Home-AAA server (using policies) or the access device, if the Session-Timeout is reached and forces the servers to release the session? In the case that the timeout is reached in the access device, I could assume that a STR would be sent to the Home-AAA to stop accounting and release the resources in the proxies and the Home-AAA server. However, in the case where the timeout expires in the Home-AAA server, should it stop accounting and release the session immediately, even though you might not be sure that the service has really been terminated in the access device? Also, you might end-up receiving a STR in the Home-AAA with a no longer valid session-ID, right? IMHO, I think DIAMETER should give the tools for assuring user (service) session integrity for the whole network. I!
 hope it is clearer.

BR,
Martin

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Monday, January 22, 2001 7:30 PM
> To: Barney Wolff
> Cc: Pat Calhoun; Martin Julien (ECE); [email-masked]'
> Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments
> Section 3.0
> 
> 
> Ah, sorry for the misunderstanding. I do agree. Does anyone object?
> 
> PatC
> > I was commenting on language specifying when the server & proxy
> > must release resources (STR/STA).  I don't believe that has to
> > be specified.  All that needs to be said is that a server
> > must respond to STR with STA and a proxy must pass an STA back
> > to its client.  Specifying exactly when internal resources get
> > released is overkill, unless it has consequences on visible
> > behavior.  IMHO.
> > 
> > Barney
> > 
> > On Mon, Jan 22, 2001 at 08:15:26AM -0800, Pat Calhoun wrote:
> > > > Why does DIAMETER need to specify such within-node behavior?
> > > > Is any of it visible outside the node?
> > > 
> > > If state is released implicitly, then a sentence 
> explaining the purpose of the
> > > Session-Timeout AVP is sufficient. However, if explicit 
> signaling is used to
> > > release resources, then it is visible outside the node.
> > > 
> > > PatC
> > > 
> 
> 
>

---

From: Barney Wolff <[email-masked]>
Date: Tue, 23 Jan 2001 09:27:59 -0500

Ah, the famous "NAS caught fire" problem.  This is (part of) what
makes server-based resource management hard.  The only solution
that makes sense to me is periodic reassurance from the NAS that
the session is still in progress (aka Interim Accounting).  After
enough time without such assurance, the server has to consider
the resources held by the session to be free again.

You'll see in the Solutions draft discussion of soft state and
hard state - one can use different solutions for "loose"
resources such as IP addresses from a pool and "tight" resources
such as the number of concurrent logins allowed a single user.

I *hate* server-based resource management, but sometimes bosses
and marketeers insist.

Barney

On Tue, Jan 23, 2001 at 11:18:11AM +0100, Martin Julien (ECE) wrote:
> Barney,
> 
> I understand you point and I totally agree with you. However, could you please help me with the following scenario? I'd like to know if you would consider it a problem related to the configuration of the Home-AAA server (using policies) or the access device, if the Session-Timeout is reached and forces the servers to release the session? In the case that the timeout is reached in the access device, I could assume that a STR would be sent to the Home-AAA to stop accounting and release the resources in the proxies and the Home-AAA server. However, in the case where the timeout expires in the Home-AAA server, should it stop accounting and release the session immediately, even though you might not be sure that the service has really been terminated in the access device? Also, you might end-up receiving a STR in the Home-AAA with a no longer valid session-ID, right? IMHO, I think DIAMETER should give the tools for assuring user (service) session integrity for the whole network.!
  I!

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 23 Jan 2001 07:21:15 -0800 (PST)

Barney,

So do you agree then that it is possible for entities to simply free their
resources once the timeout has been reached, without the need for explicit
signaling? If the NAS decides to issue the STR, an error will be returned
stating that the session does not exist, at which point it will realize that
the timeout has occured, and free resources anyways.

So is this a problem?

PatC

---

From: Barney Wolff <[email-masked]>
Date: Tue, 23 Jan 2001 11:29:33 -0500

I think it's a little more complex.  A session-limiting timeout
from server to NAS should certainly provoke an STR from the server
when the time runs out.  The only time a node would silently drop
a session is when a server has sent a session-timeout at the start,
and fails to hear anything from the NAS after a well-chosen interval.
That could be some increment over the interim accounting interval,
if interim accounting is in use, or the session timeout, if that
was specified.  That silent drop assumes the server has no way to
signal or probe the NAS, as was true for RADIUS.

With DIAMETER, a server in that state should send an STR towards
the NAS rather than just silently drop its resources, as long as
such an STR is allowed.  That's a no-lose step - if the NAS has
silently restarted, the server will get some response indicating
that.  If the NAS is dead, the server will get a response from
a proxy, or at least time out after a relatively short wait.

I can imagine cases where it's more complex yet, when part of
the chain is DIAMETER and part is RADIUS.  There we need a
way for a proxy to say "cannot translate".

I'm sorry if I've been unclear in expression, or just muddled in
thinking.  Saying that we don't need to specify WHEN a node frees
resources was not intended to imply that a DIAMETER peer should
be silent when its partner fails to send an expected request or
response.

Barney

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 23 Jan 2001 08:39:50 -0800 (PST)

Cool, I think we are nearly there. One more question. Who initiates the STR?
Should it be the NAS, or the home server. We need to provide some guidelines
to reduce the changes of such messages crossing through the network.

PatC

---

From: David Spence <[email-masked]>
Date: Tue, 23 Jan 2001 12:44:31 -0500

> to reduce the changes of such messages crossing through the network.

I guess I'm confused as to where "there" is.  I hear Barney and Martin
aguing for explicit signalling and Pat arguing that timeouts themselves
should terminate sessions without the need for signalling.

Personally, I think that all terminations should be explicitly signalled. 
We need to carefully consider all of the possible collision scenarios.  Not
signalling doesn't really simplify things.  For example, the home server may
time out just as the NAS is simultaneously sending a re-auth.  (I realize
the NAS should have sent the re-auth earlier, but delays do happen.)  When
the home server receives the re-auth, it gets confused because it has
already released state.  If the home server had sent an STI and waited for
an STR, then things like the re-auth collision could be handled better.  To
get this right, we really need to specify a session state table.  That's
more work, but it's part of making a good standard.

I also have a comment on the idea of including an Extension-ID AVP in STRs
and STIs.  I can understand the desire to be able to terminate subsessions
of a complex session, but DIAMETER doesn't really support subsessions.  I
can also understand the need to free some resources within a session without
terminating the entire session.  But to do that, you need real resource
management, and DIAMETER doesn't do that either.  I don't think trying to do
pseudo-resouce management through the use of the Extension-ID AVP is a
particularly good idea.  The Extension-ID does not really indicate
resources, nor does it precisely indicate applications either.  Instead it
simply indicates which subsets of DIAMETER are being used in the protocol
exchange.  So what would it mean if a server receives an STR (or STI)
specifying some Session-ID and the NASREQ Extension-ID, but not the
Strong-Crypto Extension-ID which was also used in establishing the session? 
Or if a server receives an STR specifying the Accounting Extension-ID but
not the NASREQ Extension-ID (although maybe we've decided to include
accounting in the service extensions)?

Anyway, I think if we want to do resource management, then we should figure
out how to do resource management and not try to slap together a quick fix
that uses the wrong data element for the wrong purpose.  Personally, I would
be quite happy if we left the STRs and STIs the way they are and let them
terminate an entire session -- all resources and state associated with a
Session-ID.

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.

---

From: Barney Wolff <[email-masked]>
Date: Tue, 23 Jan 2001 13:29:18 -0500

I'd say the NAS does it, as it should have the primary timing
responsibility.  The server's timing is to avoid getting stuck in
a state, and can be quite coarse, or nonexistent if the server
does not track session state.

If the server had the primary
timing responsibility, we wouldn't need the session-timout avp at
all, as it could just decide to terminate the session when it wants
to.  But I think that's a poor use of server cycles.

Barney

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 23 Jan 2001 09:55:02 -0800 (PST)

> should terminate sessions without the need for signalling.

ok, perhaps I didn't make myself that clear. I am in agreement with Barney and
Martin, which led to my question.

> more work, but it's part of making a good standard.

So, if I understand correctly, a new state table needs to be provided to show
the state transitions of a session, correct?

Any comment on who should initiate the STR or STI? Could we say that if a
session is terminated due to a session timeout, the NAS does it. However, if
the home server does not receive the STR within session timeout + fudge
factor, then it should send the STI. Of course, either peer is entitled to
send the STR at any time prior to the session timeout.

does this work?

> accounting in the service extensions)?

Good argument against extension ID in STRs.

> terminate an entire session -- all resources and state associated with a

ok, that works for me as well, since it is the easiest (both in terms of
documentation as well as implementation).

PatC

---

From: David Spence <[email-masked]>
Date: Tue, 23 Jan 2001 13:48:43 -0500

Actually, both the NAS and the home server have to run a timer.  The home
server has to because he's the one who cares and he wants to enforce his
policy.  The NAS has to because it is possible that the home server will be
(temporarily) unreachable from the NAS at the time the timeout is to occur. 
The NAS has an interest in running the timer because if the home
organization will refuse to pay for a longer session than the timeout
specifies, then the NAS wants to make sure it doesn't provide a longer
session.

This means that both parties will timeout approximately simultaneously so a
termination collision is likely.  No problem.  The home server is expecting
an STR in response to its STI, so if it receives the STR generated by the
NAS' timeout, its happy.  The rule for the NAS is: ignore an STI received in
STR-sent state.  So the NAS avoids sending a second STR.  The home server
will send STA in response to STR and everyone is happy.

---

From: David Spence <[email-masked]>
Date: Tue, 23 Jan 2001 13:53:03 -0500

See comments interspersed below.

> Martin, which led to my question.

Good.  Now I understand.

> send the STR at any time prior to the session timeout.

See my reply of a few minutes ago to Barney Wolff for an informal
description of how I think it should work.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 23 Jan 2001 10:51:46 -0800 (PST)

Simple state machine. I like it.

PatC

---

From: Barney Wolff <[email-masked]>
Date: Tue, 23 Jan 2001 14:00:05 -0500

I do not think the home server has to run a fine-grained timer,
or any timer at all if it is not doing resource management.
It can do fine-grained timing, if it's anal, but we MUST NOT :)
make it a MUST.

Barney

---

From: David Spence <[email-masked]>
Date: Tue, 23 Jan 2001 14:04:35 -0500

I'm o.k. with making it a MUST for the NAS and a MAY for the home server. 
If the protocol is specified as I've proposed, it should work either way.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 23 Jan 2001 11:05:46 -0800 (PST)

Good, so NAS MUST sent STR, home server MAY sent STI. race conditions are
handled by the NAS.

I'll have text written up later today to represent the session state machine.

PatC