SSMSM establishes one or more SSH sessions between an SNMP manager and
agent. Each session is based on transportType, transportAddress,
securityName (the principal or user), the securityModel (in this case
the SSH security model), and a securityLevel.
While SNMPv3 supports noAuthNoPriv, authPriv, and authNoPriv, SSHSM
uses only authPriv. If an application asks for a different
securitylevel, the message will still be sent over an SSH transport
connection with authentication and encryption. I expect further debate
over this approach. We decided that the details of the security
mechanisms (the authentication protocol used, the SSH protocol options
selected, etc.) should be opaque to SSHSM. Unless the SNMP engine has
more insight into and control over the SSH transport connection
parameters, and the security model violates the data hiding rules of
the RFC3411 architecture, we don't have a way to deal with multiple
securitylevels easily. Of course, an operator may choose to deploy
their SSH transport connections differently, but SSHSM will not know,
just as netconf won't know if a BEEP or SSH session is not deployed as
called for.
Sessions are reusable. It does not matter whether the session was
initially created by a manager as a request/response channel, or
created by an agent as a notifications channel. What matters is that
the transport and securityName/Model/Level match.
SSHSM sessions may be closed by either side at any time for resource
management (or other reasons). When a message is sent, the security
model in the sender checks to see if a suitable session exists. If
not, it creates an appropriate session (if it cannot, it discards the
message and sends back an error to the other parts of the engine).
Multiple SNMP messages, of the request/response variety or
notifications, may be sent over an existing session. SNMP messages are
BER encoded, with length tags, etc., and do not have the same issues
of document validation that a XML-based document has, and that
multiple XML messages in a stream has. So the never-ending RPC is not
an issue that has arisen in ISMS.
Just like in netconf, any callback mechanism has been underspecified.
In ISMS, Balsz's discussion of the loop for notifications is slightly
different because we use a modular approach:
For each event {
determine the targets,
apply filters,
send message request to message processing
}
For each message request {
build each notification,
send message to transport mapping
}
For each message {
Check whether suitable session exists
If not, create session
send message
}
Hope this helps,
David Harrington
dharrington@huawei.com
dbharrington@comcast.net
ietfdbh@comcast.net
-----Original Message-----
From: owner-netconf@ops.ietf.org
[mailto:owner-netconf@ops.ietf.org] On Behalf Of Juergen
Schoenwaelder
Sent: Thursday, May 18, 2006 8:35 AM
To: Balazs Lengyel
Cc: Andy Bierman; Netconf (E-mail)
Subject: Re: The datamodel in Notification Draft
On Thu, May 18, 2006 at 01:59:58PM +0200, Balazs Lengyel wrote:
JURGEN! Could you tell us how ISMS is solving the session
based security?
As I understand they also decided to have proper security
you need to
maintain sessions.
ISMS is all about using existing security solutions for SNMP. It
turns
out that the most widely deployed security solutions are somehow
session based and the most widely deployed onces are running over
TCP. Note that session based security is not the same as running
over
TCP.
The statement "to have proper security you need to maintain
sessions"
per se might not be correct. But to have security, you need to
maintain some state between the communicating endpoints and setting
this up involves some work, even in the case of SNMPv3/USM.
We will soon post some measurement data to the ISMS list which shows
the cost of the various transport and security options for SNMP. We
did the measurements on a perfect network but also under conditions
of
packet loss. All I can say is that those who use a stock net-snmp
implementation really should not worry about a TCP transport in case
the network is in trouble. With other SNMP stacks you might be
better
off - we did not measure them.
/js
PS: Also SNMPv3/USM has some overhead when you send the first
notification and you have to synchronize clocks. You do
not establish
a session key which saves on round trip times, but also reduces
the level of security you get if you are paranoid (or you have
to
do more frequent key changes). The point is that you have to
look
at the whole system and that it is misleading to separate out
pieces of the picture and to look at it in isolation.
PPS: Even if you consider signed syslog messages over plain
UDP, it might
be instructive to figure out what the overall performance will
be
end-to-end including generation and verification of the
signatures.
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561,
28725 Bremen, Germany
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>