[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSec Complexity
> From owner-ipsec@lists.tislabs.com Fri Feb 18 18:52:05 2000
> Date: Fri, 18 Feb 2000 18:44:05 -0800
> From: Ricky Charlet <rcharlet@redcreek.com>
> To: Joe Touch <touch@ISI.EDU>
> CC: CTrobridge@baltimore.com, kent@bbn.com, ipsec@lists.tislabs.com
> Subject: Re: IPSec Complexity
>
> Joe Touch wrote:
> >
> > > From owner-ipsec@lists.tislabs.com Fri Feb 18 09:36:47 2000
> > > Date: Fri, 18 Feb 2000 12:29:16 -0500
> > > To: Chris Trobridge <CTrobridge@baltimore.com>
> > > From: Stephen Kent <kent@bbn.com>
> > > Subject: RE: IPSec Complexity
> > > Cc: ipsec@lists.tislabs.com
> > >
> > > Chris,
> > >
> > > If you do IP in IP tunneling, and then apply transport mode, you
> > > will suffer the access control problems I described earlier, because
> > > transport mode IPsec looks only at the outer IP header, not the inner
> > > one.
> >
> > The only one I noticed your mentioning had to do with
> > the difficulty, after popping out of the IP in IP tunnel,
> > of determining which traffic came from where.
> >
> > This is exactly what enables routing over IPSEC. The assumption
> > is that the IPSEC is securing the links in this mode, not the entire
> > system.
> >
> Your statement is only true if you presuppose that routing protocols
> must flow on a GRE or L2TP tunnel.
How so? I run routing protocols - including RIPv2, using multicast,
over the IPSEC tunnels I have. I don't do (or want to do) anything
over any protocol other than IP (that way I can do overlays
on overlays, ad infinitum, modulo packet MTU consumption by
headers).
> Alternativly, you could make IPsec
> tunnels behave as if they had virtual interfaces and then Routing
> protocols run nativly over IPsec tunnels and you get to retain all of
> IPsec's rich authentication services.
That's what I do. Though they're not really virtual interfaces
in the sense I'm familiar - they are aliases to real interfaces,
though.
Joe