RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt

["Harrington, David" <[e-mail]>]

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            
[e-mail]
co-chair, IETF SNMPv3 WG, concluded


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Christopher A. Martin
> Sent: Wednesday, May 12, 2004 10:39 PM
> To: 'Melinda Shore'; [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On 
> Behalf Of
> Melinda Shore
> Sent: Wednesday, May 12, 2004 1:21 PM
> To: [e-mail]
> 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: [e-mail]
> > Date: Wed May 12, 2004  9:41:12 AM US/Eastern
> > To: [e-mail]
> > Cc: [e-mail]
> > 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 
> > [e-mail] 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:
> > 	[e-mail].
> > 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:	<[e-mail]>
> 
> 
> _______________________________________________
> midcom mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/midcom
> 
> 
> _______________________________________________
> midcom mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/midcom
> 
> 

_______________________________________________
midcom mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/midcom