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

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

Hi,

Following up on Juergen's and Jeff's comments, I think the document
should explain why this TM does pay attention to
authentication-mechanism-specific errors, as compared to, say, SSH -
IIUC, because TLS does not multiplex services while SSH does.

For interoperability purposes, it is important to know that some
agents might send a notification and count these particular errors,
while others do not, even though both would apparently be considered
compliant. A separate compliance clause might be the right approach
for this. A knob that indicates whether this support is available or
not might be helpful to NMSes.

dbh 

> -----Original Message-----
> From: Wes Hardaker [mailto:wjhns1 at hardakers.net] 
> Sent: Monday, September 14, 2009 5:08 PM
> To: David Harrington
> Cc: 'Jeffrey Hutzelman'; 'Wes Hardaker'; isms at ietf.org
> Subject: Re: draft-hardaker-isms-dtls-tm-05 submitted - 
> tlstmNotifications
> 
> >>>>> On Mon, 14 Sep 2009 16:56:16 -0400, "David Harrington" 
> <ietfdbh at comcast.net> said:
> 
> DH> If one were to implement the DTLS-TM using a DTLS 
> toolkit, would the
> DH> SNMP side of the API likely know why that the client 
> certificate was
> DH> invalid, or would that likely be internal to the toolkit?
> 
> 1) Yes.  I've seen the openssl code and know that you can 
> determine this
>    exact situation.
> 
> 2) IMHO, it doesn't matter.  It's not up to us to specify how 
> a service
>    gets managed.  As an example, many of the interface counters, for
>    example, were put into "exporting data" code in the linux kernel
>    because SNMP needed access to them.
> 
>    There are only two cases:
> 
>    A) A (D)TLS implementation can export the situation already today
>       within the existing APIs (such as the case for OpenSSL, as
>       mentioned above).
> 
>    B) A (D)TLS implementation can not export the data and as 
> far as the
>       client goes, it's a silent fail with a generic error.  
> If this is
>       the case, then one of three things must happen:
> 
>       i) the SSL implementation implements a mechanism through "some
>          manner" so that the invalid-certificate notification can be
>          sent by the application using the SSL API.  Maybe 
> through a new
>          error code, or whatever.
> 
>      ii) the SSL implementation implements an internal "I got 
> a problem"
>          event and sends through some aspect to anyone listening.  A
>          listener (possibly the SNMP agent application) would 
> listen for
>          a problem and send a notification when it received that
>          internal software event.
> 
>     iii) the SSL implementation won't export the details that 
> a problem
>          has occurred problem through any method.  This 
> leaves the SNMP
>          agent implementation out of luck as it simply can't send
the
>          notification at all.  If we think this is possible, 
> wouldn't it
>          make more sense to put the notification into an optional
>          conformance group than to not put it in at all?
> 
>          And eventually, hopefully, all iii)s would eventually
>          transition to either i) or ii).
> 
> -- 
> Wes Hardaker
> Cobham Analytic Solutions
>