Re: [Isms] open issues

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

> From: "Randy Presuhn" <randy_presuhn at mindspring.com>
> To: <isms at ietf.org>
> Sent: Tuesday, April 22, 2008 6:54 PM
> Subject: Re: [Isms] open issues
...
> Think of a notification subscription as an information retrieval request,
> and the notification as the (potentially much-delayed) response.  How
> do we know the "response" (the notification) is going to the party that
> requested it and not someone else?  After all, *anything* could have
> been configured as the notification destination.  In the case of USM,
> it's the symmetric key used by the notification subscriber that implicitly
> makes this binding, and prevents anyone else from getting at the data first.
> (If the data isn't encrypted, the whole question is really moot.)
...

To be absolutely clear, this is *not* to say that the key used to configure
the destination is remembered.   The association happens through
snmpTargetParamsSecurityName in the snmpTargetParamsTable.
The value of snmpTargetParamsSecurityName isn't necessarily the
same as the securityName in use by the entity configuring the subscription.
(See section 5 of RFC 3413 for details.)

Randy

_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms