RE: Modefg considered harmful

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

Hi Dereck ;-)

See my comments below.


----------------------------------------------------------- 
As of February 12, 2003 Thomson unifies its email addresses on a worldwide
basis.Please note my new email address: dirk.vanaken@thomson.net 

Thomson is the leader in solutions and technologies for the entertainment
and media industries and serves its customers under its four strategic
brands: Technicolor, Grass Valley, RCA and THOMSON. 
More about Thomson: http://www.thomson.net/videochain 

> -----Original Message-----
> From: Derek Atkins [mailto:derek@ihtfp.com]
> Sent: dinsdag 11 februari 2003 18:34
> To: Van Aken Dirk
> Cc: ipsec@lists.tislabs.com; Scott G. Kelly
> Subject: Re: Modefg considered harmful
> 
> 
> Van Aken Dirk <VanAkenD@thmulti.com> writes:
> 
> > If this can happen then I would say that the design of this 
> IPSec VPN node
> > is inherently insecure !
> 
> It's not the road-warrior node; it's the gateway. 

I was indeed referring to the gateway.

> If the GATEWAY is not involved in the address configuration of the
road-warrior, then it
> cannot protect the network.

RFC3456 is about assigning addresses via tunnels; its not about routing
(actually forwarding).

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

I would advise: post this paragraph to the PPVPN working group mailing list
!
 
<Trimmed>
> 
> 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.

Not correct: is this would be a RFC2547 requirement than it would result in
an architecture that cannot scale.
MPLS routers have typically a few 155 MBit/s Sonet/ATM links but with
literally thousands of virtual channels. Doing this with physical links
would result in large boxes don't you think ?

For your convenience I copied section 1.2 of RFC2547 and RFC2547bis below:

1.2. Edge Devices (RFC2547)

   We suppose that at each site, there are one or more Customer Edge
   (CE) devices, each of which is attached via some sort of data link
   (e.g., PPP, ATM, ethernet, Frame Relay, GRE tunnel, etc.)  to one or
   more Provider Edge (PE) routers.

Nothing in here about "physical" point-to-point links. Actually regarding
terminology, RFC2547bis is a little bit better on this point:

1.2. Customer Edge and Provider Edge (RFC2547 -
draft-ietf-ppvpn-rfc2547bis-03.txt)

   Routers can be attached to each other, or to end systems, in a
   variety of different ways: PPP connections, ATM VCs, Frame Relay
   DLCIs, ethernet interfaces, VLANs on ethernet interfaces, GRE
   tunnels, L2TP tunnels, IPsec tunnels, etc.  We will use the term
   "attachment circuit" to refer generally to some such means of
   attaching to a router.  An attachment circuit may be the sort of
   connection that is usually thought of as a "data link", or it may be
   a tunnel of some sort; what matters is that it be possible for two
   devices to be network layer peers over the attachment circuit.

   Each VPN site must contain one or more Customer Edge (CE) devices.
   Each CE device is attached, via some sort of attachment circuit, to
   one or more Provider Edge (PE) routers.

<Trimmed>

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

Well as said before, removing peer configuration from IKE and talking via an
API (which is an abstraction of the IKE functionality) yields:  1) I don't
need an IKE expert for this module and 2) each time a new attribute is
defined I don't have to go through an certification process (such as
ICSA's). Yet I can assure my customer that still my IPSec solution is not
compromised although I added/changed functionality.

BTW, after 20 years of BOOTP/DHCP new options are still being defined due to
the ever changing network environment. Why would this not be the case for
IKEModeCfg ?

<Trimmed>

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

Might be the case ...

  A working IPsec
> implementation is easily capable of protecting against these attacks.

I think everything is said on this subject and I guess it is up to the wise
men on the IPSec list to formulate recommendations for the IKEv2 draft.

Over & Out - Dirk