RE : RE : RE : DHCP options drafts

Hi David,

When I wrote the draft, my intention was how Midcom be used within
third-party end-user devices. Most NATs are residential and small corporate.
How can midcom be implemented in such situation and still be easy to use? In
such circumstances, I think that DHCP will provide an easy mean to configure
such device. Thus, the user don't need any network knowledge. A midcom third
party devices/middlebox will only need 3 infos (user/pwd/share key) in order
to work.

See comments inline.
...J


> -----Message d'origine-----
> De : Harrington, David [mailto:[email protected]]
> Envoyé : 5 avril, 2004 16:10
> À : Joel Tran; [email protected]
> Objet : RE: RE : RE : [midcom] DHCP options drafts
>
>
> 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.

Initial SNMP discovery mechanism, in my understanding, does not permit the
discovery of Midcom middlebox IP address. If we want to do such thing, we
will need to make SNMP midcom request to each and every IP on the network to
find a midcom device (I might be wrong since my understanding of SNMP is not
complete).

> 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.

I agree with you. In the case of DHCP, an administrator can configure the
DHCP server to send only the midcom address (and probably the engineID) to
specific user. These users MUST have there own shared key entered by the
administrator.

> 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?

In large corporate network, DNS SRV may be used in order to assign
dynamically the Midcom middlebox IP address to be used in each session. In
that case, I assume that authentication and share-key should be the same on
both middlebox.

>
> 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
>
>
>
>
>