Re: RE : RE : DHCP options drafts

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
>
>
> --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
>
>
>
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom
>