Re: Proxy Forwarder apps RFC ?



HI,

Juergen is generous in responding. I've have to say the
same answer for all of your questions.

By the way, there is a new security model being developed
in the ISMS WG. I've been trying to help someone that
should know what SNMP engineIDs are all about to understand
them and how they are used for proxy. Discovery is over rated
and it's need is, I believe, widely misunderstood.
I believe it's not needed and exists because of really
poor design decisions in SNMPv3. Juergen and I fought back
in the late 90's to resolve some of the issues with the
SNMPv3 specifications.

So how would you make SNMP proxy better, and what would
you use SNMP for?

On Sat, 10 Sep 2005, Juergen Schoenwaelder wrote:
> jbertron <jd@xxxxxxxxxx> wrote:
>
> > I think the community needs someone in the standard track to comment on
> > the design of the Proxy Forwarder applications. The documentation is
> > sparse and the design leaves many holes that will ultimately result in
> > several incompatible approaches.
>
> I never liked proxies in the SNMPv3 RFCs so I do not consider myself a
> proxy expert. So my attempt to respond below might just document my
> poor understanding of SNMP proxies.
>
> > 1- Implications on engine discovery. Intermediate or pass-through ?
>
> The engineID used in the security header is hop-by-hop. The engineID
> in the scoped PDU is end-to-end (unless you have a real ugly proxy
> which smells like a NAT).
>
> > 2- KeyChange.
>
> Security is hop-by-hop since proxies may proxy between different SNMP
> versions (or different security models in the future).
>
> > 3- USM and VACM implications.
>
> VACM is called by the command responder / notification originator and
> hence proxies should have no impact on VACM. USM is also not affected
> since USM is hop-by-hop rather end-to-end.
>
> > 4- Context rewriting.
>
> As I said above, this really smells like NAT stuff and will cause lots
> of confusion if a proxy does this. So I would say "don't do it since
> it will hurt".
>
> > I don't think we're all on the same page on these issues. I certainly
> > see multiple approaches are possible and I don't see anywhere in the
> > RFCs where these are addressed.
>
> Hm. Things might not be spelled out. But they may be implicit if you
> read the text carefully. But my knowledge of the details is becoming
> rusty and re-reading the specs takes too much energy...
>
> /js

Regards,
/david t. perkins
.