Subject: RE: Modefg considered harmful

From: Van Aken Dirk <[email-masked]>
Date: Wed, 5 Feb 2003 10:11:40 +0100

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

So to conclude:
- I don't have to touch the IKE code
- I don't have to touch IPSec code
- 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

For your convenience excerpted the relevant section on local delivery of
RFC1812 - Requirements for IP Version 4 Routers.

5.2.3 Local Delivery Decision

   When a router receives an IP packet, it must decide whether the
   packet is addressed to the router (and should be delivered locally)
   or the packet is addressed to another system (and should be handled
   by the forwarder).  There is also a hybrid case, where certain IP
   broadcasts and IP multicasts are both delivered locally and
   forwarded.  A router MUST determine which of the these three cases
   applies using the following rules.

   o An unexpired source route option is one whose pointer value does
      not point past the last entry in the source route.  If the packet
      contains an unexpired source route option, the pointer in the
      option is advanced until either the pointer does point past the
      last address in the option or else the next address is not one of
      the router's own addresses.  In the latter (normal) case, the
      packet is forwarded (and not delivered locally) regardless of the
      rules below.

   o The packet is delivered locally and not considered for forwarding
      in the following cases:

      - The packet's destination address exactly matches one of the
         router's IP addresses,

      - The packet's destination address is a limited broadcast address
         ({-1, -1}), or

---

From: Tylor Allison <[email-masked]>
Date: Wed, 5 Feb 2003 13:55:56 -0600 (CST)

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.

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

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

> network infrastucture and inherits an existing and rich feature set.

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

---

From: Derek Atkins <[email-masked]>
Date: 10 Feb 2003 18:23:11 -0500

Dirk,

Unfortunately IPsec MUST know the IP Address that is assigned to
the client.  In particular, the IPsec GATEWAY must know what
selectors to apply when creating the tunnel, and must know
the address in an authenticated manner.  

If the gateway is not involved in the IP Address configuration,
then it has to trust the client to act responsible.  This may not
be a reasonable choice:

   a) it opens you up to address-stealing attacks
   b) it opens you up to address-spoofing attacks

Here's why.

A client connects to a gateway but doesn't agree on an IP Address.
The client then says "ok, I'm 1.2.3.4".  The IPsec gateway has no way
to know that this client is authorized to use 1.2.3.4 -- it's just
trusting the client, which is bad.  Think PPVPN!  If my company and
your company share a VPN node, I could gain access to your vpn this
way.

Address spoofing is much the same way -- if you leave the selectors
open then even though I've got address 1.2.3.4, I could send a packet
claiming to be from 1.2.3.5 into the network.

The only way to fix this is for the IPsec gateway to be involved in
the address assignment (even if it's just reading the DHCP responses).

IPsec cannot be used in a vacuum.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com