Subject: RE: RE : [midcom] DHCP options drafts

From: "Harrington, David" <[email-masked]>
Date: Mon, 5 Apr 2004 10:56:34 -0400

Hi,

Since the communications between a midcom agent and the middlebox is done via SNMPv3, to provide mutual authentication, the discovery needs to be done using SNMPv3.

DHCP is good for dynamically assigning addresses, but SNMPv3 has specific requirements about the identification of managed nodes, and addresses have proven inadequate for identification purposes, largely as the result of technologies such as DHCP and NAT. It is also possible to have multiple SNMPv3 agents at the same address (e.g. to manage different types of functionality present on the same box), and to have one SNMP agent respond at multiple addresses (e.g. in a router or in a multi-blade chassis). 

That's why SNMPv3 uses engineIDs for identification. SNMPv3 discovery entails a type of mutual discovery, during which the SNMP engines share their SNMPv3 engineIDs, and clock sync information. This permits SNMPv3 to communicate with different engines at a given address, or to recognize when one engine has multiple addresses. This discovered information cannot be provided via DHCP.

There is also the issue of key distribution. The initial distribution of keys must be done outside SNMPv3, using a secure protocol. This may accomplished using a key distribution protocol, such as kerberos, or by kickstarting a "root" or "admin" type of security relationship, and then distributing additional keys using SNMPv3. DHCP is inappropriate for key distribution.

DHCP might be useful for saying "there is an SNMP engine (which may be a midcom agent or a middlebox or some other type of SNMP engine) at address a.b.c.d, but the information DHCP provides alone will be inadequate for establishing secure SNMPv3 communications or for establishing non-secure SNMPv3 communications. It might be adequate for identifying where there is an SNMP engine that could then be "discovered" using SNMPv3 discovery. If DHCP provided the engineIDs for the SNMP engines, as well as the addresses to use to reach each SNMP engine, that could be a good thing.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joel Tran
> Sent: Wednesday, March 31, 2004 10:01 AM
> To: 'Melinda Shore'; [email-masked]
> Subject: RE : [midcom] DHCP options drafts
> 
> There has been an error during the submission of the two 
> drafts. While this
> get fix, the documents will be available at: 
> 
> http://www-edu.gel.usherb.ca/traj1901/draft-tran-midcom-dhcp-o
> ption-00.txt
> http://www-edu.gel.usherb.ca/traj1901/draft-tran-midcom-dhcpv6
> -option-00.txt
> 
> These documents present a technique for discovering the 
> midcom agent in an
> IPv4 and IPv6 network using DHCP. This technique will be 
> useful for end-user
> device which will implement midcom.
> 
> Any comments are appreciated.
> Thanks,
> ...J 
> 
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de
> Melinda Shore
> Envoyé : 31 mars, 2004 07:22
> À : [email-masked]
> Objet : [midcom] DHCP options drafts
> 
> By now you may have seen the announcements for two
> new drafts on using DHCP to configure middlebox addresses
> into clients.  This work would probably most appropriately be
> done in the dhc working group, but first we need to make sure
> that midcom participants think that the idea is sound and
> second we'd need to review the document and make sure that
> the options, etc. are correct.  So, first question first:
> is this worth doing?
> 
> Thanks,
> 
> Melinda
> 
> http://www.ietf.org/internet-drafts/draft-tran-midcom-dhcp-opt
> ion-00.txt
> http://www.ietf.org/internet-drafts/draft-tran-midcom-dhcpv6-option- 
> 00.txt
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
> 
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
> 
> 

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

---

From: "Joel Tran" <[email-masked]>
Date: Mon, 5 Apr 2004 15:18:54 -0400

Comments inline.

> Since the communications between a midcom agent and the
> middlebox is done via SNMPv3, to provide mutual
> authentication, the discovery needs to be done using SNMPv3.

True, preferably, the discovery should by done using SNMPv3. However, I
can't figure out one thing: How we can ONLY identify SNMPv3 agent performing
Midcom services in an effective way? With the use of DHCP, we can pin-point
directly the Midcom device in a network.

> DHCP is good for dynamically assigning addresses, but SNMPv3
> has specific requirements about the identification of managed
> nodes, and addresses have proven inadequate for
> identification purposes, largely as the result of
> technologies such as DHCP and NAT.

DHCP serves as assigning dynamically addresses and configuration parameter.
In our case, Midcom agent needs to know the addresses of Midcom middlebox.
DHCP provides this means. For identification/authentication is out of scope
of DHCP. The Midcom agent will thus have to provide authentication to the
Midcom middlebox.

> It is also possible to
> have multiple SNMPv3 agents at the same address (e.g. to
> manage different types of functionality present on the same
> box),

Quick question, in this case, are all the SNMP agents listening to the port
or they have individual port?

> That's why SNMPv3 uses engineIDs for identification. SNMPv3
> discovery entails a type of mutual discovery, during which
> the SNMP engines share their SNMPv3 engineIDs, and clock sync
> information. This permits SNMPv3 to communicate with
> different engines at a given address, or to recognize when
> one engine has multiple addresses. This discovered
> information cannot be provided via DHCP.

> There is also the issue of key distribution. The initial
> distribution of keys must be done outside SNMPv3, using a
> secure protocol. This may accomplished using a key
> distribution protocol, such as kerberos, or by kickstarting a
> "root" or "admin" type of security relationship, and then
> distributing additional keys using SNMPv3. DHCP is
> inappropriate for key distribution.

> DHCP might be useful for saying "there is an SNMP engine
> (which may be a midcom agent or a middlebox or some other
> type of SNMP engine) at address a.b.c.d, but the information
> DHCP provides alone will be inadequate for establishing
> secure SNMPv3 communications or for establishing non-secure
> SNMPv3 communications. It might be adequate for identifying
> where there is an SNMP engine that could then be "discovered"
> using SNMPv3 discovery. If DHCP provided the engineIDs for
> the SNMP engines, as well as the addresses to use to reach
> each SNMP engine, that could be a good thing.

As you mentioned, it will probably be interesting to provide engineIDs to
identify the good SNMPv3 agent in the document. Anybody have some other
comments on this?

...J

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 06 Apr 2004 08:37:16 +0200

David,

I completely agree with your analysis. The missing integration with the
MIDCOM MIB is one of the shortcomings of the current drafts.  Another one
is lacking support for multihoming.

Still I think that the general idea of supporting MIDCOM by DHCP options
is useful. Both shortcomings can be fixed.

Thanks,

    Juergen

--On 05.04.2004 10:56 Uhr -0400 Harrington, David wrote:

> DHCP is good for dynamically assigning addresses, but SNMPv3 has specific requirements about the identification of managed nodes, and addresses have proven inadequate for identification purposes, largely as the result of technologies such as DHCP and
> NAT. It is also possible to have multiple SNMPv3 agents at the same address (e.g. to manage different types of functionality present on the same box), and to have one SNMP agent respond at multiple addresses (e.g. in a router or in a multi-blade
> chassis).
>
> That's why SNMPv3 uses engineIDs for identification. SNMPv3 discovery entails a type of mutual discovery, during which the SNMP engines share their SNMPv3 engineIDs, and clock sync information. This permits SNMPv3 to communicate with different engines
> at a given address, or to recognize when one engine has multiple addresses. This discovered information cannot be provided via DHCP.
>
> There is also the issue of key distribution. The initial distribution of keys must be done outside SNMPv3, using a secure protocol. This may accomplished using a key distribution protocol, such as kerberos, or by kickstarting a "root" or "admin" type
> of security relationship, and then distributing additional keys using SNMPv3. DHCP is inappropriate for key distribution.
>
> DHCP might be useful for saying "there is an SNMP engine (which may be a midcom agent or a middlebox or some other type of SNMP engine) at address a.b.c.d, but the information DHCP provides alone will be inadequate for establishing secure SNMPv3
> communications or for establishing non-secure SNMPv3 communications. It might be adequate for identifying where there is an SNMP engine that could then be "discovered" using SNMPv3 discovery. If DHCP provided the engineIDs for the SNMP engines, as well
> as the addresses to use to reach each SNMP engine, that could be a good thing.
>
> dbh
>