[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt
Hi,
SNMPv3 was designed to handle circumstances like devices behind a NAT.
The engineID concept separates the engine identity from its address.
Multiple engines can exist at the same address (the view from the public
side of a NAT) and each will have a different engineID.
(The engineID also helps in the router situation where multiple unique
interfaces share an SNMP agent; if the data sets originate from the same
engineID, they can be recognized as being the same SNMP engine, even
though their addresses are different).
An SNMPv3 message contains two engineIDs - one to identify the
"next-hop" snmp engine, and one to identify the originator of the data
contained in the PDU. The proxy capability allows a proxy-capable engine
to forward SNMP packets to different pre-configured contextEngineIDs and
their associated addresses.
The one place where SNMPv3 cannot easily solve the NAT problem is in the
traditional approach to engine discovery. A discovery performed from the
public side of a NAT won't work because the messages cannot be uniquely
addressed to the managed entities within the NAT without scoping it
through the public NAT address. A middlebox solution might be a viable
approach.
Recognize that configuring SNMPv3 proxies has a key distribution issue
to be aware of. The public-to-NAT messaging requires shared SNMPv3 keys,
and the NAT-to-private messaging will require SNMPv3 keys. A middlebox
solution probably should not try to distribute shared keys that don't
already exist in the NAT box, but should enable/disable SNMPv3 proxy
forwarding as needed, given pre-shared security principals (users) and
keys. The design of the SNMPv3 proxy application (RFC3417) supports this
separation of the security credentials (the TargetParams table) and the
addresses (TargetAddrTable), so a middlebox might be able to configure
where SNMP packets should be forwarded without being allowed to know the
security credentials necessary to do the forwarding.
David Harrington
dbh@enterasys.com
co-chair, IETF SNMPv3 WG, concluded
> -----Original Message-----
> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On
> Behalf Of Christopher A. Martin
> Sent: Wednesday, May 12, 2004 10:39 PM
> To: 'Melinda Shore'; midcom@ietf.org
> Subject: RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt
>
> Hi Melinda, everyone,
> Its been awhile. You know I notice that we now have the mib draft and
> was wondering, is it out of scope to look into a way to
> manage via SNMP
> via a middle-box using midcom to provide the mechanism for
> nat traversal
> for snmp?
>
> Just a thought...SNMP has always been the sore spot when it comes to
> managing devices behind a nat. Before snmp v3 I would never have asked
> rfor such functionality, but now...
>
> Any comments from anyone on this would be appreciated.
>
> _____
>
> Christopher A. Martin
> P.O. Box 1264
> Cedar Hill, Texas 75104
> _____
>
>
> DOMAINS.SIP1.COM
> Select your option below by clicking on the icon.
> RegisterForwardDomainAlert MonitoringWeb HostingSite
> BuilderEmailTraffic
> Blazer & Quick SizzleSSLInternet UtilitiesCopyright
>
>
>
> -----Original Message-----
> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On
> Behalf Of
> Melinda Shore
> Sent: Wednesday, May 12, 2004 1:21 PM
> To: midcom@ietf.org
> Subject: Fwd: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt
>
>
> This is our final deliverable - the end is in sight. Please give the
> draft a careful read and post comments to the mailing list.
> WG review
> is,
> perhaps, the most important stage in moving documents towards
> publication,
> and this is the time to catch and fix any problems that may
> lurk in the
> draft.
>
> Thanks,
>
> Melinda
>
>
> Begin forwarded message:
>
> > From: Internet-Drafts@ietf.org
> > Date: Wed May 12, 2004 9:41:12 AM US/Eastern
> > To: i-d-announce@ietf.org
> > Cc: midcom@ietf.org
> > Subject: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Middlebox Communication
> Working Group
>
> > of the IETF.
> >
> > Title : Definitions of Managed Objects for Middlebox
> > Communication
> > Author(s) : J. Quittek, et al.
> > Filename : draft-ietf-midcom-mib-01.txt
> > Pages : 82
> > Date : 2004-5-11
> >
> > This memo defines a portion of the Management Information Base (MIB)
> > for use with network management protocols in the Internet
> community.
> > In particular, it describes a set of managed objects that allow
> > configuring middleboxes, such as firewalls and network address
> > translators, in order to enable communication across
> these devices.
> > The definitions of managed objects in this documents
> follow closely
> > the MIDCOM semantics defined in RFC XXXX.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-01.txt
> >
> > To remove yourself from the I-D Announcement list, send a
> message to
> > i-d-announce-request@ietf.org with the word unsubscribe in
> the body of
>
> > the message. You can also visit
> > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> > username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-ietf-midcom-mib-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > mailserv@ietf.org.
> > In the body type:
> > "FILE /internet-drafts/draft-ietf-midcom-mib-01.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility. To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command. To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader. Different MIME-compliant mail
> readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > Content-Type: text/plain
> > Content-ID: <2004-5-12094156.I-D@ietf.org>
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>
>
_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom