Subject: Re: [Isms] extVacmRowLifetime

From: "David Harrington" <[email-masked]>
Date: Mon, 1 Feb 2010 09:19:18 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Randy Presuhn
> Sent: Saturday, January 30, 2010 11:05 AM
> To: [email-masked]
> Subject: Re: [Isms] extVacmRowLifetime
> 
> 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
> >
> > On Sat, Jan 30, 2010 at 04:51:26AM +0100, Randy Presuhn wrote:
> >  
> > > 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.
> > 
> > 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.
> > 
> > > 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.
> > 
> > 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.
> 
> 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.

I assume you refer to a security model in the SNMP engine. I do not
understand how you concluded that the security model knows anything
about the session lifetime; SNMP has no sessions. Transport models
might recognize transport sessions. So it would need to be a
RADIUS-enabled transport model that exposed the session lifetime, no?

> 
> Randy
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>