RE : RE : DHCP options drafts
"Joel Tran" <[email protected]>
| Newsgroups | gmane.ietf.midcom |
|---|---|
| Message-ID | <000a01c41b42$d5ea4c70$b248d284@kamel> |
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