Subject: [AAA-WG]: [issue] Boot-Id

From: Paul Funk <[email-masked]>
Date: Sun, 27 May 2001 21:39:27 -0400

Submitter name: Paul Funk 
Submitter email address: [email-masked] 
Date first submitted: May, 20001 
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00135.html 
Document: Base 
Comment Type: Technical 
Priority: 1 or 2 (?) 
Section: Somewhere in section 6 
Rationale/Explanation of issue: 
Servers need to know if a NAS has rebooted, to be able to 
clean up state. A new connection is not necessarily and 
indication of reboot, since it could be a reconnect after a 
connection was broken.

Requested change:

The interim group felt that, of the three proposals in the foot-fetish 
thread, Paul's and Pat's should be adopted. Briefly, a Boot-Id is passed 
in DRI to allow a server to determine when a peer has rebooted, and 
Boot-Id is also passed in other messages, to allow downstream 
servers more than one hop away to glean this information.

Randy suggested that the name of the AVP be changed from Boot-Id to 
State-Id, since a server may retain state across reboots. Therefore, 
a new id is really indicative of fresh state. I suggest we in fact 
call it Origin-State-Id, to emphasize its relationship to Origin-FQDN.

Origin-State-Id will have to be added to the ABNF for DRI as well as all 
other messages, as an optional AVP.

Suggested language:

[add the following somewhere in the DRI section:]

Origin-State-Id AVP

The Origin-State-Id AVP (AVP Code ?), of type Unsigned32, is a 
monotonically increasing value that is advanced whenever a Diameter 
entity restarts with loss of previous state, for example upon reboot. 
Origin-State-Id MAY be included in any Diameter message, including 
DRI. 

A Diameter entity issuing this AVP MUST create a higher value for 
this AVP each time its state is reset. A Diameter entity MAY set 
Origin-State-Id to the time of startup, or it MAY use an incrementing 
counter retained in non-volatile memory across restarts.

The Origin-State-Id, if present, MUST reflect the state of the 
entity indicated by Origin-FQDN. If a proxy modifies Origin-FQDN, 
it MUST either remove Origin-State-Id or modify it appropriately as 
well.

Typically, Origin-State-Id is used by an access device that always 
starts up with no active sessions; that is, any session active prior 
to restart will have been been lost. By including Origin-State-Id in 
a message, it allows other Diameter entities to infer that sessions 
associated with a lower Origin-State-Id are no longer active. If an 
access device does not intend for such inferences to be made, it 
MUST either not include Origin-FQDN in any message, or set its value 
to 0.

[add the following to the Session Termination section:]

10.10 Inferring Session Termination from Origin-State-Id

Origin-State-Id is used to allow rapid detection of terminated 
sessions for which no STR would have been issued, due to unanticipated 
shutdown of an access device.

By including Origin-State-Id in DRI messages, an access device allows 
a next-hop server to determine immediately upon connection whether the 
device has lost its sessions since the last connection. 

By including Origin-State-Id in request messages, an access device
also allows a server with which it communicates via proxy to make 
such a determination. However, a server that is not directly connected 
with the access device will not discover that the access device has 
been restarted unless and until it receives a new request from the 
access device. Thus, use of this mechanism across proxies is 
opportunistic rather than reliable, but useful nonetheless.

When a Diameter server receives a Origin-State-Id that is greater 
than the Origin-State-Id previously received from the same issuer, 
it may assume that the issuer has lost state since the previous 
message and that all sessions that were active under the lower 
Origin-State-Id have been terminated. The Diameter server MAY clean 
up all session state associated with such lost sessions, and MAY also 
issues STRs for all such lost sessions that were authorized on 
downstream servers, to allow session state to be cleaned up globally.

Paul

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

---

From: Barney Wolff <[email-masked]>
Date: Mon, 28 May 2001 00:02:57 -0400

The idea of a state-id has some merit, but (as I always seem to)
I protest against over-determination.  There is no actual need for
a monotonic value.  All that's required is a value that does not
duplicate any value used within the "recent" past.  A 32-bit
pseudo-random number would do perfectly well.  My problem with
using the boot time as the state-id is that it is not well defined
until an interaction with some timeserver has completed.  A boot
counter kept in nvram is problematic when hardware is replaced.

The requirement that if Origin-FQDN is changed that state-id be
changed does not seem to make any sense:  state-id is not
required to be unique across different origin devices.

Barney Wolff

---

From: Paul Funk <[email-masked]>
Date: Mon, 28 May 2001 13:27:13 -0400

>counter kept in nvram is problematic when hardware is replaced.

If the only use of a state-id were between directly connecting peers, 
say in DRI, then yes, you would be correct, and only a different, rather 
than an increasing, state-id would be required.

However, once state-id passes across proxies, there would be a 
problem if a server were to receive messages out of order. Suppose 
an access device issues message A, reboots, then issues message 
B. If these messages take different proxy paths and a server receives 
message B first, upon subsequent receipt of message A it would 
incorrectly release authorization resources it created for message B. 

Hence the monotonically increasing value. A server is only supposed 
to release resources for sessions with lower state-id than the one it 
just received.

Use of boot time for state-id doesn't imply any synchronization with 
other devices. Whether the access device gets time from a time 
server or from its own clock, there's no requirement that the time be 
accurate, only that it never goes backwards. If the access device 
used a time server, it would have to complete the time determination 
prior to starting connections.

If you replace hardware and the nvram counter is reinitialized to 0, 
yes, sessions from the previous piece of hardware may persist until 
their authorization-lifetimes expire. But the error is on the conservative 
side -- no current users will lose resources.

>required to be unique across different origin devices.

That state-id is associated with Origin-FQDN is exactly the point. A 
server would be expected to associate state-id and Origin-FQDN with 
a session state. When a higher state-id arrived from a particular 
Origin-FQDN, it could release each session state entry with the same 
Origin-FQDN and lower state-id.

The purpose of the requirement is this: Suppose a broker "takes 
responsibility" for a request and modifies Origin-FQDN to its own. 
Well, it better modify state-id also, otherwise the home server will 
incorrectly assume the unmodified state-id from the access device 
is actually the state-id of the broker, and will clear sessions incorrectly.

Paul

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