RE: Sensationalism? [was Re: FW: Man in the middle attack against RFC3456.]

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

Hi Darren,

See my comments below.

> -----Original Message-----
> From: Darren Dukes [mailto:ddukes@cisco.com]
> Sent: donderdag 6 februari 2003 17:20
> To: Van Aken Dirk; 'Scott G. Kelly'
> Cc: ipsec@lists.tislabs.com
> Subject: RE: Sensationalism? [was Re: FW: Man in the middle attack
> against RFC3456.]
> 
> 
> Dirk, the main point you can take from my posting this problem is that
> RFC3456 has had relatively little mileage and implementation 
> experience
> compared to modecfg.  People have had years to discover the inherent
> problems with modecfg and understand them, they've also had years to
> understand how useful it can be.  RFC3456 is relatively young and not
> entirely understood by this working group so there are likely 
> many scenarios
> where it will have problems that have not been discovered.

Do not agree with the term "many" because RFC3456 is almost transparent to
IKE.

Setting up a tunnel for DHCP is not different from setting up a tunnel for
any other protocol.
The only difference is that the SPD/SAD selectors must contain the limited
broadcast address (255.255.255.255) and the default address 0.0.0.0. and of
course transport protocol UDP, destination ports/source port 67/68.

As said before, as soon as DHCP packets pass through the SPD, it is standard
IP/DHCP relay processing. If there would be a problem we would have heard it
by now because this technology has been proven over the years.
And that's the beauty of RFC3456, there is almost no interaction with IPSec
and the interaction can be done via standardized API/interfaces.

Of course on the point where there is interaction between DHCP/IKE/IPSec I
agree with you that one must be careful to not introduce side effects.

<trimmed ..>
> The one I pointed out is just one of those, will there be 
> others?

See my answer on your so called attack below.

What you doing here is trying to put RFC3456 in a negative daylight. i.e.
Using words such as "many", "one of those" and razing questions such as
"will there be others ?" you just try to scare/confuse the audience. Why
don't we look at the method in a positive way: the protocol is good until it
is has been proven otherwise ?

> Most likely.  Should they be posted and discussed? Absolutely.

Yes of course but in a positive way. Because up till now I heard all kind of
arguments against the solution, some of these being in a different protocol
layer.

> Will they have
> solutions that could change our understanding or 
> implementation of RFC3456 ?
> Who knows.
 
> Dirk, you wrote.
> > I would agree with you Darren, if this same scenario would work
> > form the VPN
> > client side because there is far less control on who is 
> sitting behind the
> > VPN client.
> 
> Why would it not work from a client?  If the selectors are 
> such that all
> traffic is tunnelled then a client could send DHCPACKs to the 
> DHCP-relay on
> the SGW, correct?

Yes, but then again have look at RFC3056 and how it can be applied.

FYI, 
- we use the Agent Circuit ID Sub-option to reference the tunnel via which
DHCP requests arrived into the system
- we put information into the Agent Remote ID Sub-option that is specific to
the relaying system and protected via cryptographic techniques.

As you will read in the RFC, the server must loop the complete contents of
the DHCP relay information option. Hence if we receive DHCP acks we can
easily check whether these are replies to original (relayed) requests or
not.

Over & out - Dirk