[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Modefg considered harmful



I've been following this discussion for a bit now, but must admit that I'm
still coming up to speed on how rfc.3456 is intended to work, so please
bear with me.  For background, I have implemented Mode-Config, but not
rfc.3456.

On Wed, 5 Feb 2003, Van Aken Dirk wrote:

> Hi Darren,
>
> See my comments below.
>
> > Regarding your comments about modecfg, there is no need for
> > an address pool
> > on the LargeIPsecGW since it could act as a DHCP-client when
> > it receives
> > modecfg requests from an IRAC instead of having its ipsec
> > engine sniffing
> > for inbound DHCP packets and forwarding them to the internal
> > DHCP relay.
> >
> > Darren.
>
> The IPSec engine must not sniff on DHCP packets. As said before,
> implementing RFC3456 can IMHO happen almost completely outside the IKE and
> IPSec code! More specific, a DHCP discover arriving via an IPSec tunnel has
> a source address (0,0) and destination address (-1,-1). After passing
> through the SPD, this packet must be delivered locally, that is, to the
> internal IP host of the IPSec GW (see RFC1812-section 5.2.3). The local host
> is configured with a DHCP relay that is listening on UDP port 67 (DHCP
> server port). This DHCP relay can either forward the request to an internal
> DHCP server or relay it to an external DHCP server. The only IPSec specific
> item that the relay must take care of is that replies from the server must
> end-up in the correct "DHCP-tunnel". This can be accomplished via the DHCP
> Relay Information Option/sub-options. i.e. The DHCP relay must "tag" the
> DHCP requests (e.g. with the Tunnel IP address, Tunnel port number) in the
> direction towards the DHCP server and must "untag" the DHCP replies and use
> this tag to look-up the correct tunnel in the direction towards the DHCP
> client (see section 4.2 of RFC3456).

Regarding the DHCP relay to IPSEC tunnel selection, rfc.3456 gives several
options on how this may be done... one of which is the Relay Info Option.
The question I have is whether or not you can count on DHCP servers
supporting this option (can you count on all servers supporting this)?
If this option is not supported, this means another method for determining
the tunnel selection must be used, and the only viable option that I can
think of is for the SGW to keep the state table mentioned which tracks the
DHCP transaction to the IPSEC tunnel.

You state that the IKE/IPSEC engine must not sniff the DHCP packets... but
that's in opposition to what's suggested in rfc.3456...

    "To learn the internal IP address of the client in order to route
    packets to it, the security gateway will typically snoop the yiaddr
    field within the DHCPACK and plumb a corresponding route as part of
    the DHCP Relay processing."

My biggest concern here is where the enforcement of client to virtual IP
mapping happening?  Or is this not a desired goal/capability for remote
access?  For example, if I have Joe User who should always receive IP
10.1.1.111, and I setup a security policy which allows the 10.1.1.111 to
have special access privileges, how can I guarantee that someone besides
Joe can't obtain the 10.1.1.111 address?  The security concerns section for
rfc.3456 states that the assigned address MUST NOT be depended upon for
security.

This sort of access control can be done easily w/ Mode-Config, as IKE knows
the address which should be assigned to the client and can setup the
allowed Quick Mode selectors appropriately.

> So to conclude:
> - I don't have to touch the IKE code

While this may be true, I don't believe it carries the same weight as it
used to, since we're working on defining what the IKEv2 code should
actually be.

> - I don't have to touch IPSec code

This isn't totally true, is it?  You have to add the glue which
inserts/extracts the DHCP traffic into the IPSEC tunnel.  You also have to
deal with the management of the DHCP-specific IPSEC SA and setting up of
the dynamic SPD entries associated with the assigned address.

> - I might have to change DHCP relay code but this technology is well
> understood
> - my IP parameter distribution method is in-line with the rest of the
> network infrastucture and inherits an existing and rich feature set.
>
> Best regards - Dirk

I'm struggling here because I'm not sure I totally like either solution
that's being offered.  My biggest complaints with RFC.3456 are the
specialized IPSEC SA required for DHCP traffic and the lack of control on
address assignment.

Mode-Config for IKEv1 had a similar problem to rfc.3456 for SA management,
as MC was a "phase 1.5" exchange, causing headaches in the IKE state
tables.  This seems to be solved in IKEv2 by the fact that the MC payloads
are now inline in the base phase 1 exchange.  I would agree, however that
MC does duplicate the purpose of DHCP.

The solution?  The ideal solution in my mind would be to still use DHCP,
but have the initial DHCP traffic pass through IKE instead of IPSEC.
Either attempt to introduce the DHCP payloads directly into the phase 1
exchange (similar to what's proposed for MC), or to instantiate a new
exchange for the DHCP traffic.  IKE would be required to parse a minimum
number of DHCP attributes in order to determine some base info, like the
assigned IP address.

If such a solution is not possible, then I'd prefer to keep the current
Mode-Config proposal as described in the IKEv2 draft.  We can keep the
scope of MC to be very simple... address assignment for the remote peer.
Once a VPN is established, any other network configuration parameters can
be determined via the DHCPINFORM method.

My $.02 worth.

=====================================================================
= Tylor Allison         Secure Computing Corporation        =========
=====================================================================