[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Modefg considered harmful
> -----Original Message-----
> From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca]
> Sent: maandag 3 februari 2003 21:42
> To: ipsec@lists.tislabs.com
> Subject: Re: Modefg considered harmful
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> >>>>> "Van" == Van Aken Dirk <VanAkenD@thmulti.com> writes:
> Van> Have you thought about following situation ?
>
> Van>
> RemoteOfficeLAN-----SmallIPSecGW-----LargeIPSecGW-----CentralOfficeLAN
>
> Van> Following parameters are configured on the SmallIPSecGW:
>
> This is out of scope.
Hi Michael,
The configuration I described above was created in our labs with two very
simple (and old) IPSec gateways not supporting any dynamic IP parameter
assignment method. So if I have to choose between configuring remote PC's
connected to these gateways manually or automatically, I sure know what to
choose.
Whether it is out of scope, I leave in the middle because I know too little
of the history of the IPSec working group. The point I wanted to make is
that in complex environments you will find a mix of IPSec GW's:
- old IPSec GW's with very little features;
- new ones with the latest feature set;
- IPSec GW's connecting VPN RAS users and VPN GW's connecting remote
offices.
If a system administrator can at least have a uniform IP parameter
distribution method over his whole network (including his central office LAN
;-) ), he would be very happy !
With IKEModeCfg this is clearly not the case but with DHCP based methods it
can be accomplished and that's my main motivation for the RFC3456 based
method.
The focal point of the IPSec working group is to create good standards for
IPSec but sometimes I have the impression that the fact that IPSec devices
must be integrated in a larger infrastructure is sometimes overlooked. I
hope that I do not offend anybody with this statement, I just express my
personal feeling on this point.
>
> SmallIPsecGW should run a DHCP relay, and tunnel the
> packets through the
> VPN to the CentralOfficeLAN's DHCP server.
>
> The only "difficulty" is that the IP addresses provided to the
> RemoteOfficeLAN will need to either fit into the existing tunnel that
> SmallIPsecGW has
This is only logical: the remote office network, the prefix pointing to this
network and the IPSec policy are identical.
, or that SmallIPsecGW should have a somewhat
> "wide" policy
> for all communication from RemoteOfficeLAN<->CentralOfficeLAN, and use
> per-host keying to create new LANs.
>
> ] ON HUMILITY: to err is human. To moo, bovine.
> | firewalls [
> ] Michael Richardson, Sandelman Software Works, Ottawa, ON
> |net architect[
> ] mcr@sandelman.ottawa.on.ca
> http://www.sandelman.ottawa.on.ca/ |device driver[
> ] panic("Just another Debian GNU/Linux using, kernel hacking,
> security guy"); [
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Finger me for keys
>
> iQCVAwUBPj7UAoqHRg3pndX9AQH8lgP/ReFXm9Www9hi+RJaB94lnecr+r+PIi68
> wvHHFepa2dpt/a8buGQelNV0+FDhr4D4+ogkpUwwpAmLFSByuvPe0CURp43p9zWP
> Vh7CqwZfGkzSp5Ab03hzFmG8UkC446Pg0FNx+qsxzqkt8TelM3tMSLG+iZMG5oza
> 2/FvdBI+tck=
> =TXIU
> -----END PGP SIGNATURE-----
>