Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications

["David Harrington" <ietfdbh at comcast.net>]

Hi,

It looks to me like we *would* be violating layers.

If (D)TLS gets an invalid certificate, will it still pass the payload
to SNMP?
If (D)TLS gets an invalid certificate during the "service
authorization" step, will it even start the SNMP service?

In SSHTM, we document what we know after asking for a session to be
opened or closed - i.e., it failed. We make the assumption we can tell
whether the failure was a user-authentication failure or a
server-authentication failure or a channel-open failure or a subsystem
failure. We do not assume we know what authentication method was used
when authentication failed; we have one error counter for userauth
failure and another for serverauth failure, whether SSH used passwords
or certificates or some other method to perform the authentication.

I think the InvalidClientCertificate and InvalidServercertificate
counters cross the line into (D)TLS specific processing.

If you want insight into what is happening at the (D)TLS "layer", then
you should write a (D)TLS MIB to capture that information. That does
not belong in the transport model though, just as the specific SSH
failures do not get documented in the SSHTM MIB. 

Think of it this way. If you write a generic (D)TLS MIB that recorded
InvalidClientCertificates and InvalidServercertificates, would these
only be incremented when SNMP was the protocol utilizing the (D)TLS
service, or might they also be incremented when using, say, IPFIX or
Netconf or HTTP? I think these are (D)TLS-specific errors, not
SNMP-TM-specific errors.

dbh

> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On 
> Behalf Of Jeffrey Hutzelman
> Sent: Monday, September 14, 2009 3:09 PM
> To: Wes Hardaker
> Cc: isms at ietf.org; jhutz at cmu.edu
> Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted 
> - tlstmNotifications
> 
> --On Monday, September 14, 2009 12:02:00 PM -0700 Wes Hardaker 
> <wjhns1 at hardakers.net> wrote:
> 
> >>>>>> On Mon, 14 Sep 2009 20:29:18 +0200, Juergen Schoenwaelder
> >>>>>> <j.schoenwaelder at jacobs-university.de> said:
> >
> > JS> The question is to what extend the SNMP agent is really 
> involved in
> > JS> all this or whether the DTLS transport takes care of 
> the processing
> > JS> itself. In the SNMP over SSH case, we did decide to 
> stay out of things
> > JS> that really concern the SSH layer. It seems with 
> TLS/DTLS, we seem to
> > JS> go into much more details - perhaps this is even 
> justified. I just
> > JS> notice that we seem to deal with these different secure 
> transports
> > JS> differently.
> >
> > I'd argue that if it helps the operator it doesn't matter 
> much.  We're
> > not violating layers because we want to help manage a 
> transport just as
> > we're not violating layers when we send a linkUp 
> notification (which if
> > you drew an architectural diagram, would be way outside the SNMPv3
> > blocks).
> >
> > In other words, do we want managers to be able to get
notifications
> > about failed (D)TLS connections?  If yes, then we need to define
the
> > notifications and it's implementation specific as to how to 
> detect the
> > need to send them.
> 
> Agree.  We're not talking here about the SNMP agent breaking 
> layers and 
> looking at things it has no business knowing about.  We're 
> talking about 
> the (D)TLS transport itself being manageable.
> 
> -- Jeff
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms
>