Re: Modefg considered harmful

[Derek Atkins <derek@ihtfp.com>]

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

Van Aken Dirk <VanAkenD@thmulti.com> writes:

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

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek@ihtfp.com             www.ihtfp.com