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.