Subject: [AAA-WG]: Boot-ID in DRI

From: Paul Funk <[email-masked]>
Date: Mon, 07 May 2001 00:40:36 -0400

RADIUS servers generally use accounting as a means of 
tracking user sessions. In addition to Start and Stop 
accounting requests, a NAS can use On and Off requests 
to indicate it has just come up or is about to go down. 
A RADIUS server receiving an On or Off may then infer 
that resources for all user sessions controlled by that 
NAS can be released.

In Diameter, when a connection starts up and DRIs are 
exchanged, there is no way for the server to know 
whether this represents a restart of the client or 
resumption of a broken connection. If it guesses wrong, 
it will either retain resources incorrectly, causing, 
for example, IP address leakage, or it will release 
them incorrectly, causing, for example, assignment of 
the same address to multiple users.

The only means for the Diameter server to determine 
the true state of affairs would be to query the client 
for all current sessions. Such a mechanism, if I 
remember correctly, was defined as a "session 
management" extension once, but is not currently a 
AAA draft.

But that is a heavyweight mechanism that may not be 
practical to employ, if it even gets implemented.

Admittedly, the problem is less severe under Diameter 
than under RADIUS, since sessions have lifetimes and 
they eventually expire anyway. But it would still be 
a great improvement to be able to release resources 
quickly. If a client maintains thousands of sessions, 
a reboot of that client could put a significant dent 
in a Diameter server's resource pool, particularly as 
the affected users start to log in again.

I would suggest that we define a Boot-ID AVP for use 
in DRI. Each Diameter peer would determine a new 
Boot-ID at startup. When a DRI is received with a new 
Boot-ID value, this means the peer has restarted since 
the last connection. If the Boot-ID is the same, this 
means that this just a resumed connection. Upon 
connecting with a client, a server could release all 
sessions created under a different Boot-ID, if the 
server knows that the client does not retain user 
sessions across reboot.

I suggest we make use of Boot-ID a MAY for Diameter 
peers in general and a SHOULD for clients that provide 
session service. I suggest the following AVP definition:

Boot-ID AVP

The Boot-ID AVP (AVP Code ?) is of type Unsigned32 and is 
used to allow a Diameter peer to determine whether the 
issuing device has restarted since the last connection.

A Diameter entity issuing this AVP must create a new 
value for this AVP each time it restarts. This value MUST, 
at least to a high degree of probability, be different from 
values it has used after previous restarts. This may be 
accomplished by using the restart time, by generating a 
random value at each restart, or by using an incrementing 
counter retained in non-volatile memory across restarts.

A Diameter entity issuing this AVP MUST use a single 
Boot-ID value in all DRI messages between restarts with 
all peers it connects with.

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 7 May 2001 07:08:35 -0700

> the same address to multiple users.

correct.

> management" extension once, but is not currently a 

This is currently a personal draft, and I am not convinced that
it really scales all that well. However, it is out there because
people have asked for it.

> the affected users start to log in again.

ok.

> server knows that the client does not retain user 

I am not sure that this actually solves the problem. In a
real scenario, the NAS will communicate directly with a
proxy server, which in turn will communicate with another server.
For the purposes of this discussion, let's assume that the
proxy communicates with a home server that is maintaining 
session state.

If the NAS was to reboot, it would send the Boot-Id to its
proxy server, but this information would never make it down
to the server in the home network, right? This is really
where the problem is. The home server would never know
that the NAS has rebooted, *unless* a new Shoe-Id would
cause the proxy to send some message to the home server informing
it that the NAS had rebooted.

A rather ugly scenario :(

However, I believe that there is a different way around this,
and we can make use of most of your proposal. If the NAS
was to include the Shoe-Id in most of the authentication
messages, the home server could evaluate its value with
previous ones, and determine whether the NAS had rebooted
or not.

Of course, the home server would only be informed the next time
the same NAS issues a message to that home server, so this
isn't really timely. Unless, of course, the NAS supports the
E2E security extension, and attempts to establish security
associations with known home servers upon bootup (but I don't
think this is a very likely scenario).

A truly redundant NAS, which could retain all sessions
across reboots, wouldn't include a new value in this
AVP.

> session service. I suggest the following AVP definition:

Heck, I'd prefer to make it a MUST. It is fairly trivial
to implement, and does provide significant assistance to the
home servers that maintain state.

Comments?

PatC

---

From: "Mark Jones" <[email-masked]>
Date: Mon, 7 May 2001 17:37:33 -0400

Pat,

> home servers that maintain state.

I assume this MUST only applies to clients that provide session service.
Some access wholesalers are contractually bound to send the RADIUS
Acct-On/Acct-Off messages onto some of their proxy partners. Others may
prefer to hide their network (and its potential flakiness) from their
proxy partners. If the Boot-Id AVP was a MUST for Diameter peers in
general then this would no longer be possible. It also seems a little
extreme to include the Boot-Id AVP in most(?) messages given the low
frequency of device reboot events.

How about a new command that really is just a Device Reboot Indication and
MAY be proxied depending on the proxy server policy? Following a
successful capabilities exchange with the rebooted device, the proxy
server MAY send this device reboot indication command to the home servers.
As with other proxied commands. the Route-Record AVP would be required in
the device reboot indication to prevent forwarding loops. A new AVP would
also be required in the capabilities exchange command to indicate that the
capabilities exchange was initiated due to a device reboot.

Regards,
       Mark

---

From: "Ammo Goettsch" <[email-masked]>
Date: Mon, 7 May 2001 18:39:52 -0400

> -----Original Message-----
> From: Mark Jones [mailto:[email-masked]]
> Sent: Monday, May 07, 2001 5:38 PM
> To: Pat Calhoun; Paul Funk
> Cc: [email-masked]
> Subject: RE: [AAA-WG]: Boot-ID in DRI
> 
> 
> Pat,
> 

1) How would a proxy know where to proxy this reboot indication to?
- home servers may have been found via brokers
- home servers may have been reached via redirect
- home servers may have been reached due to fail over conditions

2) How would the home server interpret this Proxied-DRI?
- If the Proxied-DRI takes particularly slow proxy route to
  the final home server, it may arrive AFTER new sessions that were
  created AFTER the reboot become known to the home server.  
  Therefore, the home server could not clear out ALL sessions 
  from the rebooted device, because only certain ones are actually
  invalid.

3) Because of problems in 2), it appears that some sort of "tag"
or "shoe id" is needed to identify which sessions are to be cleared
out.  In a scenario where different proxy routing causes re-ordering
of requests, it cannot be assured that a proxied DRI is received 
in any timely manner. In fact, multiple reboots could occur 
before any new shoe id reaches the home server.  For this 
reason, I have only been able to come up with using
a NAS-local clock time as the shoe id.  That is, some sort of request
(an ueber-STR) would be sent from the proxy to each home server
previously used for the rebooted NAS.  The ueber-STR would cause
"all sessions started before NAS time xx:yy" to be cleared out because
there was a reboot/administrative-down at xx:yy.  This would still
require each proxy to track the host names of all responses sent to
a NAS to build a list of all "home servers the NAS has talked to
since the last reboot."

Sorry for providing more problems than solutions.
Ammo

>        Mark

Ammo Goettsch             
Unprincipled Architect, ISP Products 
Funk Software              http://www.funk.com
Cambridge, MA             mailto:[email-masked]
PGP:  8708A9E464A376A6DB6672314487C3FD9A085B03

---

From: Paul Funk <[email-masked]>
Date: Mon, 07 May 2001 20:03:44 -0400

>A rather ugly scenario :(

Actually, it does solve the problem (as I define the problem, anyway).

The problem is that without Boot-ID in DRI, nobody knows whether the 
NAS has rebooted, and nobody knows whether its sessions are still 
valid.

With a Boot-ID, the local Diameter server knows when the NAS has 
rebooted and when to invalidate sessions. It may then use STR to 
inform home servers that the session is over.

Come to think of it, it might be a good idea for the draft to warn that 
an STR need not come from the original NAS; it could be issued 
by a server on behalf of the NAS. Therefore, the home server 
receiving an STR should disregard Origin-FQDN and use only 
Session-ID (which is globally unique) to identify a session.

>think this is a very likely scenario).

Your proposal is addressed to an additional problem, namely: 
Given that the first-hop proxy knows that a NAS has rebooted, 
how does it efficiently inform home servers? 

Your proposal minimizes (actually, eliminates) the traffic necessary 
to inform home servers. In my proposal, the first-hop server would 
have to issue an STR for each roaming session.

But in general, roaming sessions can be expected to be fewer than 
local ones. So if a 1000 user NAS goes down, the 900 sessions 
handled locally could be automatically released by the first-hop 
server, but it would have to issue 100 STRs to other servers for 
the 100 roaming users.

I'm not advocating one proposal over another, just drawing 
distinctions.

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Barney Wolff <[email-masked]>
Date: Mon, 7 May 2001 21:54:42 -0400

Just to add more complexity, let's remember that all these baroque
solutions don't do a thing for the NAS-caught-fire scenario, where
the NAS takes an extended unplanned outage.

Given the impossibility of perfection, it's comforting to realize
that a perfect model of the network state is seldom necessary.
To start with, the server doing the modeling only has to be
close to accurate when it has to make a decision, not in between.
As an example, if the server wants to prevent a user from parallel
sessions, it's only when the request for an apparent second session
arrives that it's important to validate the continued existence of
the first session.

A state-keeping server needs to see interim accounting, and have a
query mechansim back to the NAS to validate session survival.  Any
solution that imposes much more complexity than that is a loser,
in my long-considered opinion.

Barney Wolff

---

From: Paul Funk <[email-masked]>
Date: Mon, 07 May 2001 21:12:33 -0400

At 05:24 PM 5/7/01 -0700, Pat Calhoun wrote:
>On Mon, May 07, 2001 at 08:03:44PM -0400, Paul Funk wrote:
>ok, but now we *require* that proxies maintain state, and MUST inform
>home servers when a reboot has occured. What would happen if the
>state was on the wrong proxy? The home server would only get half (or
>worse) of the picture.
>
>I am assuming here a hierarchy level of three, where the proxies in the
>middle (not next to the NAS) maintain state. So, I guess that if all
>Diameter proxies maintain state, then this would work.
>
>And this is now mandatory, otherwise home servers wouldn't be able to 
>accurately maintain state, and could be fooled by thiking that the proxies
>are in fact providing this service.
>
>Of course, maintaining state in ALL Diameter entities in one hell of a MUST
>to introduce at this point :(

I don't think it's that complicated, and I don't think it introduces any 
additional state requirements on intermediate proxies.

The only Diameter server that would need to keep state is the one 
next to the NAS (not the one in the middle). This is the server that 
aggregates all the local NASes and either provides AAA service 
directly or proxies to other servers.

This aggregating server would keep the state of all sessions for the 
NASes it serves. Part of the session state is Destination-Realm and 
Destination-FQDN to which an STR would have to be sent. If the 
NAS goes down, the aggregating server would issue an STR for 
each of the NAS's sessions to the appropriate Destination-Realm 
and Destination-FQDN. 

Proxies between the aggregating server and the home server need 
not keep session state at all; they just need to forward the STR.

I wouldn't recommend that issuing STRs on behalf of a NAS be a 
MUST. If the aggregating server doesn't do this, home servers 
will leak resources, okay. Perhaps that's best left as a business 
issue for roaming agreements rather than a protocol issue. 

But yes, I agree that your proposal of having a footwear-ID in 
each request allows home servers to often, though not always, 
release stale sessions of a rebooted NAS, regardless of what the 
aggregating server is capable of. Its unreliability is mitigated by the 
fact that if the NAS is not sending any new requests to a 
particular home server, it probably doesn't have many leaked 
sessions on it anyway.

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 7 May 2001 17:24:30 -0700

> I'm not advocating one proposal over another, just drawing 

Right, none of them are perfect, and my proposal is so unreliable that
I wonder whether it is even useful. However, it does eliminate the need
for state in all servers.

PatC

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 8 May 2001 11:03:26 -0400

> - home servers may have been reached due to fail over conditions

Apart from the redirect, these issues exist with RADIUS Acct-On/Off today
and the fowarding policy is typically derived from the contractual
agreement between access provider and service provider. This forwarding
policy defines whether the Acct-On/Off gets sent to the service provider's
server. If the service provider has multiple servers, the fowarding policy
may also define whether the reboot notification must be sent to one or
all. In a proxy chain, a different forwarding policy may exist at each
hop.

>   from the rebooted device, because only certain ones are actually

I was assuming that Paul's Sandal-Id is present in the DRI and
Proxied-DRI. Hence, sessions would only be cleared out which had a
different (lower?) Sandal-Id. However, I do see the problem if new
sessions are setup before the DRI arrives. Doesn't the same problem exist
if the Sandal-Id is sent in every request and the requests arrive at the
home server in a different order?

> a NAS-local clock time as the shoe id.

Without those pesky DST changes, right? Wouldn't the home server still be
testing for stale sessions with (newSandalId > sessionSandalId)? So a
monotonically increasing value retained in non-volatile memory across
reboots would fulfill the same function.

Regards,
       Mark