RE: The datamodel in Notification Draft

["David B Harrington" <dbharrington@comcast.net>]

Hi,

Juergen answered this question somewhat. I agree with all his
comments. Sessions are not required for security (as USM
demonstrates), but the use of sessions can help to amortize the
overhead of transport connection and security costs over multiple
messages.

Let me discuss the ISMS solution that is in the ***current*** SSHSM
document in more detail. This is a work in progress, so things may
change. SSHSM is the SSH Security Model for SNMP.

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/>