[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSec Complexity
My reply at bottom:
Skip Booth wrote:
>
> 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
> >
> >
Howdy Skip,
I think you've merged two different questions together a little too
quickly. "What would the phase 2 Quick mode IDs be to make routing
protocols run (or what would the selectors look like)?" and "If you do
get routing protocols running over an IPsec tunnel, what good is it if
your policy does not track dynamic route changes?"
First off, it is possible to define selectors which match very tightly
to particular routing protocols from particular gateways, even when you
want to allow the broadcasts and multicasts (which you should). It is
also possible to define selectors which match very broadly (multiple
endpoints, multiple or routing, or all protocols...). And again, one
could even establish a routing PKI and make the endpoints be name type
selectors where the names match subject names in certificates. This is
an adminstrators choice. The point is that routing protocols can be
allowed to flow through SAs in several ways in todays standards.
I think the more interesting question (and the one I think you are
really building up to) is "So what if we do learn all these new routes,
how will policy be made to track with routing changes?" And you
retorically suggest that policy would look like and either or choice
between 1) allow anything to anything in order for traffic following new
routes to be allowed to pass,; or 2) keep hand configuring new selectors
which align to the routes in your routing environment of the day. Well
either of those may be ligitamate in some circumstances. That 'allow any
thing to anything' idea is also what you inherit from using IPsec to add
privacy to L2TP/PPP encapsulated tunnels. IPsec, however can do more.
Network administrators can define that certian IP ranges belong to
certian satalite entities and create secruity policyes to enfores these
expectations so that newly discovered routes must conform to the
expected IP ranges or the traffic will infact be denied. Again, another
possibility is that a large enduser PKI exists within the AS and this
may be utilized to name endpoints and govern their access to
resources... then the selectors are not IP or route sensitive at all.
All of these are possible in today's standards. One further possiblity
(and I am only mentioning this, not advicating it) is that some places
may put enough trust in their routing protocol that they would accept a
situation where (possibliy authenticated) routing updates internally
cause selector updates in their SPDs. This idea will not work with
todays standards and, if advanced, would probably invoke a huge debate
about should we allow unsuspcecting customers to even trust their
routing protocols.
Your final point about these 'IPsec interfaces' needing the attention
of the WG for standardizaion if they go forward, I wholeheartedly agree
with.
I view this thread as a debate about which mechanism should we carry
routing protocol through. The choices are an L2TP/PPP/IPsec combo with
authentication and filtering going to L2TP/PPP because routing protocols
already flow over them, or making a new routing protocol friendly IPsec
interface. I am switching my position from nuteral to advocate for doing
the IPsec interface thing (if and only if this WG wants to tackle making
routing protocols run through VPNs). I think that simple packet
filtering is too week an authenticaion mechanism for all situations,
non-ip protocols are sacrificeable with in the IPsec world, and
authenticaion and privice services being spit apart from each other is a
bad thing. I doubt I will get swayed back to L2TP/PPP/IPsec but I might
get swayed to a "change a routing protocol to make it IPsec friendly"
position if someone begins advocating there.
--
Ricky Charlet : Redcreek Communications : usa (510) 795-6903
References: