RE: RE : DHCP options drafts

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:

> 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 protected] [mailto:[email protected]] On
>> Behalf Of Joel Tran
>> Sent: Wednesday, March 31, 2004 10:01 AM
>> To: 'Melinda Shore'; [email protected]
>> 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 protected] [mailto:[email protected]] De
>> la part de
>> Melinda Shore
>> Envoyé : 31 mars, 2004 07:22
>> À : [email protected]
>> 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 protected]
>> https://www1.ietf.org/mailman/listinfo/midcom
>>
>>
>>
>> _______________________________________________
>> midcom mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/midcom
>>
>>
>
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom