RE: RE : RE : DHCP options drafts

Hi David,

I agree with all your analysis. A point for configuring the IP addresses of 
middleboxes dynamically might be (as Juergen pointed out) multihoming. An 
MIDCOM agent that has preconfigured security associations with the 
middleboxes could learn which of the boxes is the right one for a 
particular destination. This could be conveyed via a MIDCOM option in  DHCP 
and some additional routing information options.


  Martin


--On Montag, 5. April 2004 16:10 Uhr -0400 "Harrington, David" 
<[email protected]> wrote:

| Hi Joel,
|
| Comments inline.
|
|> -----Original Message-----
|> From: Joel Tran [mailto:[email protected]]
|> Sent: Monday, April 05, 2004 3:19 PM
|> To: Harrington, David; [email protected]
|> Subject: RE : RE : [midcom] DHCP options drafts
|>
|> 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.
|
| Using SNMPv3's initial discovery mechanism, one engine can discover the
| other engine's engineID and time sync parameters. If the application
| (SNMP manager) knows the pre-shared keys of the SNMP agent on the
| middlebox, the application can look to see if the MIDCIM MIB module is
| supported by doing a GET of one or more of the OIDs used in the MIDCOM
| MIB module. That type of discovery is standard operating procedure for
| most SNMP applications.
|
| That type of discovery would be appropriate for discovering MIDCOM
| agents and middleboxes. If an application searching for middleboxes
| doesn't have the shared keys for the middlebox, then it probably
| shouldn't be given access to determine what specific types of
| functionality the other SNMP engine supports.
|
| This argues for having the application (MIDCOM agent) record the address
| of the middlebox whose SNMPv3 keys are being set into its database.
|
|>
|> > 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.
|
| I think there is a question of the order of events. If both sides need
| to know the shared keys, wouldn't an operator be likely to be able to
| tell the midcom agent what the address of the middlebox is at the same
| time?
|
| What is the usage scenario that requires DHCP to tell the midcom agent
| the address of the middlebox, if the shared keys have already been set
| into both devices?
|
| Understand that I am not objecting to the use of DHCP. I am trying to
| understand the scenario in which it is actually necessary, given that
| SNMPv3 currently requires key distribution for mutual authentication
| before secure communications can be established. SNMPv3 was explicitly
| designed to protect its information from disclosure to unauthenticated
| entities. During SNMpv3 design discussions, there was a significant
| segemnt of the market (part of the US govt) that argued an SNMPv3 engine
| shouldn't reply to an unauthenticed entity because that would reveal
| that an SNMP engine exists at a given address. On top of the strong
| authentication, seeing into the MIB to see what functionality is
| supported is tightly controlled by design, using the VACM access control
| model.
|
| Given that MIDCOM is designed to manipulate security-related features
| such as firewalls and NATs, it is fairly imperative that a strong SNMPv3
| security model is maintained. A hacker would need to work to get through
| the SNMPv3 authentication mechanisms to talk to the box, and then past
| the data access controls (authorizations) to determine that a box
| supports the MIDCOM MIB module. I am not convinced that using DHCP to
| advertise "the entity at this address is a middlebox, with SNMP support
| of the MIDCOM MIB module" is a very secure thing to do, and that it
| doesn't defeat some of the SNMPv3 security philosophy to a degree.
|
|
| It helps the hacker to discover which services are running on which
| boxes, which is why port scans are considered a general security threat.
| What mechanisms are in place to ensure that DHCP doesn't disclose
| information about entities that shouldn't be disclosed? What happens if
| the DHCP server is compromised?
|
| OTOH, SNMpv3 was also designed explicitly to not use obscurity as a
| security mechanism. Even if you tell a hacker that a device is a
| middlebox manageable using the MIDCOM MIB module, the SNMPv3 security
| should prevent them gaining unauthorized access.
|
|>
|> > 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?
|
| Multiple agents MAY work together, with one agent listening on a given
| port, and then the "dispatcher" of the SNMP listener can forward the
| requests directly to the appropriate registered engine, possibly (but
| not necessarily) through a different port. There are multiple SNMP-legal
| ways to support multiple engines at the same address, including the SNMP
| proxy mechanisms defined in RFC3413(?).
|
|>
|> > 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
|>
| David Harrington
| [email protected]
| co-chair, IETF SNMPv3 WG, concluded
|
|
|
|
| _______________________________________________
| midcom mailing list
| [email protected]
| https://www1.ietf.org/mailman/listinfo/midcom