Subject: RE: Modefg considered harmful

From: Van Aken Dirk <[email-masked]>
Date: Tue, 11 Feb 2003 09:29:10 +0100

Hi Derek,

See my comments below,

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]]
> Sent: dinsdag 11 februari 2003 0:23
> To: Van Aken Dirk
> Cc: [email-masked]'; Michael Richardson; [email-masked];
> 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 <[email-masked]> 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
>        [email-masked]             www.ihtfp.com
>

---

From: "Derek Atkins" <[email-masked]>
Date: 11 Feb 2003 12:34:16 -0500

> If this can happen then I would say that the design of this IPSec VPN node

It's not the road-warrior node; it's the gateway.  If the GATEWAY is
not involved in the address configuration of the road-warrior, then it
cannot protect the network.  By routing around IPsec (which is exactly
what you are proposing by selecting DHCP outside IKE), you are in
effect REMOVING the ip address protections from the tunnel.

> from one VPN cannot leak into another VPN

I've looked at this.  Unfortunately your analysis is incorrect -- it
is possible to leak information from one vpn to another in a BGP/MPLS
VPN if you share an entry point to the MPLS network, which maps quite
nicely into the attack I'm worried about.

> its own VPN; not in a "neighbor" VPN.

It depends completely on the implementation.  If there is a shared
wire between my network edge, your network edge, and the MPLS fabric,
then packets can bleed across.  MPLS "fixes" this problem by requiring
physical point-to-point links between the edge node and the MPLS
gateway.  That way it can differentiate the traffic based on which
physical interface it arrived on.

The EXACT SAME THING is true for IPsec -- if IPsec knew the allocated
address then it can act in the same way.  If the IPsec gateway knows
that you are only allowed 1.2.3.4, then if it sees a packet claiming
to be from 1.2.3.5 it can drop it.  

However, if the gateway is not involved in the road-warrior
configuration, if it does NOT know what addresses are configured, the
is has NO CLUE what addresses are allowed to traverse the tunnel.  In
effect, it's the same as if you used an ethernet rather than
point-to-point links between the edge gateways and MPLS.  Sure, the
traffic is encrypted, but there is no guarantee it is correct.

This is why you MUST include the IPsec gateway in your address
configuration.

> 7) IDci must match the entries added to the SPD and/or FIB in the previous

UMM, your steps 4 and 5 here have just proven my point.  If you are
going to require a "special" DHCP relay that knows about IPsec, why
not just make that IKE?

> most existing IKEModeCfg solutions for two reasons:

My name is "Derek", thank you...

> which makes attack a) quite easy

Operating from behind a NAT has nothing to do with this.  We're
talking about tunnel-mode address configuration.  The fact that the
outer address is natted has nothing to do with it.  Indeed, this just
proves my argument.  You necessarily WANT to tie the phase-1 IKE
identity to the phase-2 tunnel addresses (i.e. the INSIDE address).

Even through a NAT you can still differentiate flows.  A gateway ties
Flow A to IKE-ID A and ties Flow B to IKE-ID B.  When a packet arrives
at the gateway on Flow A, the gateway needs to know which address(es)
were configured to client-A to make policy acceptance decisions.  But
you necessarily want to make those policy decisions with full
knowledge of the ike id.

This is exactly the same problem that MGCP has using IPsec for
security.  MGCP has in-band endpoint identifiers that name the end
points.  The problem is that this identifier is NOT tied to the IPsec
security, so just because a flow is protected by IPsec does NOT imply
that you can believe the MGCP identifier.  As a real-world example,
your neighbor could connect to your neighborhood MGCP gateway but
claim to be you within MGCP.  Sure, IPsec would know its your
neighbor, but MGCP would not.

This is why you need to tie the identifiers together.  In MGCP you
need to tie the MGCP identifier into IKE/IPsec.  In the IPsec VPN you
need to tie the Tunneled IP Addresses to the IKE ID.  This means that
the IKE policy (on the gateway) needs to know what address(es) are
assigned to the road-warrior client.

> opens possibilities for attack b)

In which case the IPsec Gateway should know which address the client
is connecting from, and that becomes part of the policy.

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

I have performed these experiments, and they don't confirm your
findings.  Perhaps there are some (broken) implementation of IPsec
that have these failings, but this is a bug.  A working IPsec
implementation is easily capable of protecting against these attacks.

-derek