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

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

Hi Joel,

Comments inline. 

> -----Original Message-----
> From: Joel Tran [mailto:[email-masked]] 
> Sent: Monday, April 05, 2004 3:19 PM
> To: Harrington, David; [email-masked]
> 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-masked]
co-chair, IETF SNMPv3 WG, concluded

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

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 06 Apr 2004 10:50:35 +0200

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-masked]> wrote:

| Hi Joel,
|
| Comments inline.
|
|> -----Original Message-----
|> From: Joel Tran [mailto:[email-masked]]
|> Sent: Monday, April 05, 2004 3:19 PM
|> To: Harrington, David; [email-masked]
|> 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-masked]
| co-chair, IETF SNMPv3 WG, concluded
|
|
|
|
| _______________________________________________
| midcom mailing list
| [email-masked]
| https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Cedric Aoun" <[email-masked]>
Date: Thu, 8 Apr 2004 09:24:32 +0200

We need to be careful with the DHCP option and have clear applicability 
statements about multihomed networks.
Not all networks allows a Midcom agent to deterministically know which 
Middlebox to signal for flows with a specific destination at a 
particular time, why?:
-Time of day routing
-Qos routing
-Load balancing (ECMP)
-Router failures and implied route changes

All of the above need to be documented in the applicability statement 
when a network has more than 1 Middlebox.
I'm sure that we'll hear some arguments that a Midcom agent could 
co-host a routing control engine and be aware of the routing :-); a 
reality check would show that this is definitely not the case in most 
(if not all) the implementations.
Cedric
On Apr 6, 2004, at 10:50, Martin Stiemerling wrote:

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