Re: [Isms] Session timeouts?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Isms] Session timeouts?



> Since we don't know which implementation of SSH or which
> implementation of RADIUS will be used, would it make sense to simply
> add an implementer note that they might want to configure their
> implementation to utilize such parameters?

That presumes that it's a configuration option, i.e. that the feature has
been coded into the implementation and simply needs to be enabled at run
time.  That may not always be the case.
 
> Are there some values we should recommend as being appropriate to
> enhance interoperability? Or would this even affect interoperability?

I think all we need to specify is that an SNMP session is closed by the SSH
server after Session-Timeout seconds, or after Idle-Timeout seconds elapse
between SNMP messages.  That is to say, that the SSH server takes notice of
the session limiting authorization information.

> Our SSH transport model is designed to handle finding that no session
> is currently open (so it opens one), or that a session might have
> terminated between the time of receiving a request and sending the
> response (so it discards the response).

Right.

> Is this actually germane to the SNMP mapping? Would this be better
> discussed in the radext draft for mgmt attributes?

Well, the RADEXT draft defines _new_ RADIUS attributes for management
authorization.  It does not indicate how those attributes are used in a
specific application (e.g. SNMP, NETCONF, et. al.), although it does
describe how they are generally used in an application agnostic fashion.  It
does not layer additional usage guidelines _existing_ attributes, for
specific applications.  I think it is preferable to define attributes in one
place (e.g. the base document RFC 2865 or the Management Authorization
draft) and explain how they are applied in a particular application in a
separate draft (like RFC 3580 does for 802.1X).


_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.