[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSec Complexity
On Fri, 18 Feb 2000, Ricky Charlet wrote:
> 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. 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.
What would the phase 2 quick mode id's be? I assume you would have to negotiate
either 0.0.0.0 (Netmask 0.0.0.0), ALL Protocols, All Ports. If you don't do
this I am not sure how you put routing traffic such as RIP or IGRP which are
both broadcast routing protocols. How would you handle a multicast routing
protocol such as OSPF? If you don't negotiate an "ALL addresses" proxy, would
you set up a new SA for every route you learned on you private network. This
would seem to lead to SA explosion in a large mesh network. It has been
suggested that it is an implementation issue for how IPSEC tunnels should look
like an interface. IMO, it is an interoperability issue and needs the attention
of the IPSEC working group if this is to be the suggested way to create VPN's.
> It is suggested in this thread that authentication services and privacy
> services could be split apart from each other with authentication going
> to PPP or L2TP and privacy going to IPsec. I would like to pose an
> honest question to the proponents of that idea... since PPP and L2TP can
> provide privacy services, why not just stop using IPsec totally?
PPP can provide encryptions services, albiet weak one's compared to
IPSEC. There is no built in key management protocol and it does not
protect the L2TP header. Take a look at the L2TP security draft for more
information on why IPSEC/IKE is the security protocol for L2TP/PPP.
-Skip
>
>
>
> > Or was there another problem mentioned in another message?
> >
> > > Also, you will not be complaint with the IPsec Architecture as
> > > defined in RFC 2401.
> >
> > Depends on how it's read, perhaps. If you are referring to page 9/10:
> >
> > b) A security gateway is required to support only tunnel
> > mode. If it supports transport mode, that should be used
> > only when the security gateway is acting as a host, e.g.,
> > for network management.
> >
> > When it comes to overlays, a gateway acts as both host and cageway.
> > Host in how it terminates tunnels, and as far as the base network
> > is concerned. A gateway as far as the overlay is concerned.
> >
> > Since the IPSEC occurs visible to the base network, it is an IPSEC-style
> > host. The overlay network does not see the IPSEC at all.
> >
> > Is this the compliance issue?
> >
> > Joe
>
> --
> Ricky Charlet : Redcreek Communications : usa (510) 795-6903
>
>
Follow-Ups:
References: