[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPSec Complexity

Skip Booth wrote:
> 
> On Fri, 18 Feb 2000, Frederic Detienne wrote:
> 
> > >
> > > I agree.  One very nice thing about L2TP+IPSEC is that it looks like a network
> > > interface with security features versus a IPSEC in tunnel mode which is a layer
> > > 3 security transport. Since there is a PPP interface on top of L2TP, all the of
> > > the interface specific stuff runs transparent to IPSEC. There are no Routing
> > > protocol issues and standardized, well deployed MIBs are available for the
> > > interface.  PPP and L2TP also give you built-in keepalives for interface
> > > maintenance.
> >
> 
> > I think the presence of an IPSec tunnel interface is a matter of
> > implementation. Nothing prevents you a priori from having such an interface
> > and you could very well have the traffic run independent of the IPSec thing.
> 
> I agree to some degree.  You certainly can implement a IPSEC tunnel interface.
> Not sure how many SA's you have to set up though. Would you negotiate a new SA
> for every new route you learned?.  This would be very cumbersome for mesh
> connectivity as it would lead to a huge set of SA's. On the other hand I guess
> you could set your filters to encompass all traffic.

There is a potential catch 22 here: do you have routing protocols over IPSec or next to it ?

You can have both (in some cases, you _need_ both). The routing protocols out of IPSec helps establishing the tunnel, the routes you pass through the tunnel helps you not establishing new SA's. Especially in a dynamic environment like TED.

Even with IPSec and no interface, you have that problem. This is more a design issue.

> You also cannot assume at this point that your peer also implements a IPSEC
> Tunnel interface design.  There certainly is nothing in the current set of
> standards which addresses this issue.  With L2TP + IPSEC you know that both
> peers have a PPP interface which is standardized so there are no
> interoperability issues here.

It does not matter. The implementation and/or interface (the set of commands) you offer has little to see with the bits on the wire. The implemenation/interface can prevent users from exploiting the full power of a protocol or conversely allows incorrect things to be defined.

In no way can this affect interoperability (besides the expressivity power). There are examples of interface-enabled IPSec implementations working together with non intercace-enabled implementations.

Notice that you could also run routing protocols over an IPSec tunnel even without having a dedicated interface. This is, again, a matter of overall design and not a problem in IPSec itself.

> >
> > But I agree L2TP has some advantages; it would help in not re-inventing the
> > wheel with IPSec (thinking here of mode config). L2TP however does not have
> > an inherent "configuration" advantage over an IPSec tunnel.
> 
> Not sure what you mean here.  PPP supports a very robust negotiation protocol
> for it's link layer characteristics (LCP), and it's network protocols (NCPs).
> IPCP is the control protocol which PPP uses to set up IP.  IPCP already supports
> address, DNS, WINS, and Gateway assignment.

I was agreeing with you about the advantage of l2tp (parameter negociation). I just wanted to say that beyond the negociation, a tunnel is a tunnel and what you can transport with l2tp, you can do with IPSec.

	fred


-- 
------------------------- * oOo * -------------------------
                        CiscoSystems

                   Frederic Detienne, CDE
                 Security & Network Services

                     Tel 32 2 704 55 55
References: