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

Re: IPSec Complexity



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.

>
>  > 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.

>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. 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.

Steve



Follow-Ups: References: