[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSec Complexity
On Fri, 18 Feb 2000, Stephen Kent wrote:
> Mark,
>
>
> >The linkage between IPsec and L2TP is a standards track document
> >(draft-ietf-pppext-l2tp-security-05.txt).
>
> I'll be sure to review it when it comes up for last call.
>
> >
> >The linkage between L2TP and PPP is a standards track RFC (RFC 2661).
> >
> >The only missing element is the requirement of filters at the virtual
> >PPP interface actually defined in an RFC. Filtering traffic on an
> >interface or based on a PPP user is something that PPP Remote Access
> >vendors have done for years. Since there are no bits on the wire
> >required of these features, I suspect that the WG did not see fit to
> >write up an RFC. However, if we really, really, really, need an RFC for
> >it to be real, that could certainly be accomplished if we found the
> >people with the time to write it up and charter under which to publish
> >it. However, the more important thing to me and my customers is that the
> >given functionality exists and is available from multiple vendors. That
> >is certainly the case throughout the industry now. The fact that it is
> >not in an RFC is purely academic (again, which is not to say that it is
> >not worthwhile to document).
>
> I don't doubt that the clients of any single vendor are more focused
> on the vendor's product doing what the clients want, vs. having a
> standard that defines what the products should do. That's especially
> true when a single vendor has a very strong market presence and can
> establish de facto standards through the introduction of features in
> products. However, the IETF is a standards forum and only when we
> produce documents, and get approval for them as standards, are we
> doing our job as IETF members. So, I stand by my point.
But we can't do everything. Perhaps it is just me, but I believe that it
is most important to standardize that which is required to interoperate.
Then, to give localized implementation recommendations or requirements.
Both are important, but there is a priority here. If we had all the
resources in the world, then we could write documents for how to implement
every feature in every piece of networking gear. This would leave us at a
loss for anyone to actually sit down and write the code to make it all
work. The line has to be drawn somewhere.
At any rate, my point is that the PPP filters used in the manner described
earlier perform the same function as IPsec filters matched to a specific
SA (aside of varying transforms per traffic type for a specific user). The
advantage to this is that it offloads some of the requirements for IPsec
(this thread started as a thread about IPsec complexity) while allowing
the user to capilatize on something that they are already familiar with.
It also utilizes code that has been field tested on private networks for
years. An incremental transition is less complex to define, and typically
easier on the customer when completed.
>
> >
> > > that is not defined in any of those standards. Also, in other than
> > > the dialup user case, e.g., in extranets and intranets based on
> > > IPsec, it is not clear that the same linkages will occur.
> > >
> > > So, I guess I'm willing to believe that a vendor could create an
> > > implementation that maintained the SA linkages you describe, but it
> >
> >In fact, by linking L2TP and IPsec, you get the filter linkages
> >described for free.
>
> Free, at the cost of an extra layer of protocol, i.e., L2TP.
L2TP allows you to capitalize on PPP. The overall cost is less than
reinventing everything in IPsec. Tunnel mode vs. L2TP -- either way you
have an extra header. With L2TP you preserve PPP and all of the remote
access benefits that come with it (user auth, accounting, keepalives, an
interface to bind routing protocols to, filtering, etc...).
But I digress...
>
> >We have been doing remote access for years via leased lines and dialup
> >connections. We have filtering techniques galore for these at either end
> >of the connection. When you add IPsec for a VPN, in a sense you are
> >simply replacing the leased line with a tunneled connection over the
> >Internet. Securing that connection is necessary given that the internet
> >is a shared public medium, but I do not see why the filter techniques
> >defined in an IPsec RFC are any more real than those we have already
> >been using for years. In fact, I think it makes the transistion much
> >easier for customers to NOT define a whole new protocol, but rather to
> >use what they are already familiar with.
>
> Yes, we have had filters in place for these links for a while,
> although most of them, to the best of my knowledge, do not have IETF
> standards defining the access control filtering. IPsec establishes
> such standards, and accommodates filtering that can transition from a
> name space to an address space, as is necessary for dynamically
> assigned addresses.
A noble cause to define filtering, but this could be applied equally as
well at a different layer, under a different venue.
> It defines name forms coupled to the underlying
> authentication mechanisms, to avoid the need for tables to map
> between the two, a good place to introduce errors into access control
> systems. By providing some rigor in the definitions for this access
> control method, it establishes a basis for more sophisticated
> inter-organization access control negotiations, of the sort that the
> IPSEC Policy WG is about to address.
Again, I don't have a problem having filters defined for IPsec. But,
saying they are somehow more secure or better applied than the same types
of filters at a different layer is nonsense. Even if it is defined in an
RFC.
>
> Steve
>
>
>
References: