Subject: [Isms] extVacmRowLifetime

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 29 Jan 2010 19:51:26 -0800

Hi -

Working through the elements of procedure and the MIB, I've come
to the conclusion that we don't need extVacmRowLifetime.  Here's
my reasoning:

The value is simply whatever came over as the RADIUS Session-Timeout
attribute.

The secure transport model is already required to enfore the RADIUS
Session-Timeout attribute.

Consequently, while a session may be terminated before the expiration
of Session-Timeout, it cannot outlast it.

The secure transport model is also already required to tell us both
when sessions are created and terminated.

Thus we can conclude that relying on session termination indications
alone would cause us to take no more time than using both.

Consequently, knowledge of the termination all sessions using a particular
(security model, security name) pair is sufficient for the decision
to remove the corresponding extVacmSecurityToGroupEntry.

Consequently, extVacmSecurityToGroup doesn't need to know about it,
and we can get rid of extVacmRowLifetime from the MIB, and the EOP.
Also, we don't need to talk about Session-Timeout.

As I see it, the counter-argument to all this is to say that we
might want to support other security models that don't have these
properties with respect to session timeouts.

Opinions?

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 30 Jan 2010 16:14:53 +0100

> Also, we don't need to talk about Session-Timeout.

I think it needs to be clear how rows get deleted from the table(s).
So I think it is essential to keep this sentence:

   When the secure transport session is torn down, disconnected or times
   out, the corresponding extVacmSecurityToGroupEntry is deleted.

While we likely can avoid talking about the RADIUS Session-Timeout
Attribute, it might still be useful to have explicit text somewhere to
help implementors to do the right thing, e.g.

   When the secure transport session is torn down, disconnected or
   times out (e.g. following the RADIUS Session-Timeout Attribute),
   the corresponding extVacmSecurityToGroupEntry is deleted.

> properties with respect to session timeouts.

If there is a security model without a session timeout, then having a
MIB object for a timeout that is not known would not help. It seems
having the MIB object is more a way of exposing the lifetime.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 30 Jan 2010 08:04:30 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, January 30, 2010 7:14 AM
> Subject: Re: [Isms] extVacmRowLifetime
>

Agreed on all points.

The conclusion that leads me to is that if anything exposes
the session lifetime data, it should be the security model, since that
lifetime (and whether it exists at all) is a property of the security model.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 30 Jan 2010 17:13:34 +0100

On Sat, Jan 30, 2010 at 05:04:30PM +0100, Randy Presuhn wrote:
 
> The conclusion that leads me to is that if anything exposes the
> session lifetime data, it should be the security model, since that

I agree. However, the dynamic vacm entry inherits the lifetime from
the security model and this is the only thing we can deal with here.
But (speaking as technical contributor), I am fine with not exposing
this lifetime.

/js