RE: Modefg considered harmful

[Van Aken Dirk <VanAkenD@thmulti.com>]

Hi Derek,

See my comments below,

> -----Original Message-----
> From: Derek Atkins [mailto:derek@ihtfp.com]
> Sent: dinsdag 11 februari 2003 0:23
> To: Van Aken Dirk
> Cc: 'ddukes@cisco.com'; Michael Richardson; ipsec@lists.tislabs.com;
> Scott G. Kelly
> Subject: Re: Modefg considered harmful
> 
> 
> 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

I agree on this; these kind of attacks must be countered !

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

If this can happen then I would say that the design of this IPSec VPN node
is inherently insecure !
In this context, you might have a look at RFC2547 (BGP/MPLS VPNs):
- this kind of VPN uses the concept of virtual routers such that traffic
from one VPN cannot leak into another VPN
- it defines the VPN-IPv4 address family such that identical address pools
can be used per VPN.
Consequently a VPN client can execute the aforementioned attacks but within
its own VPN; not in a "neighbor" VPN.

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

I assume there is a misunderstanding here: I agree that the IPSec gateway
MUST be involved but it must not necessarily be done directly by the IKE
module and it does not necessarily impacts existing IPSec code.

My reasoning is the following:
1) IKE takes care of the identification/authentication of the client and
allows it to set-up an RFC3456 phase2
2) the client issues DHCP requests in the RFC3456 tunnel
3) a DHCP server responds as it can assume that the client went through the
IKE identification/authentication procedure
4) a module (such as a DHCP relay that is outside the IPSec code) analyses
these DHCP responses and via an API such as PF_Key or PF_Policy it injects
the necessary entries into the SPD
5) in addition, depending on the IPSec implementation, the DHCP relay uses
the PF_Route API to add the necessary routes into the forwarding information
base
6) finally the client establishes a second SA and announces its IP address
via IDci
7) IDci must match the entries added to the SPD and/or FIB in the previous
step

If the client uses another address, its IDci attribute does not match the
SPD rule hence the SA does not get established.

Of course depending on the paranoia level, the communication between the
client and the DHCP server over the DHCP relay can be further secured;
plenty of solutions there.

> 
> IPsec cannot be used in a vacuum.

I totally agree with this statement! However in the RFC3456 solution IKE is
used for the identification/authentication part but autherization is
performed by other modules in coorperation with IKE/IPSec of course. In this
way I have a clean separation of different functions and still I don't
compromize my security solution.

BTW Derec, the attacks you mentioned can be launched successfully against
most existing IKEModeCfg solutions for two reasons:
- IPSec clients must be able to operate behind NAT/NAPT routers hence a VPN
gateway must tolerate multiple modecfg requests from the same peer address
which makes attack a) quite easy
- most IPSec clients are able to operate with a static IP address which
opens possibilities for attack b)

You might do a few experiments on this it will confirm my findings ...

Cheers - Dirk

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