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

Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability)



On Wed, 17 May 2000, Scott G. Kelly wrote:

> I've been asking this question elsewhere, but all the action seems to be
> here. That being the case, I'll jump threads. I'm trying to objectively
> determine the benefits (and drawbacks) of accepting l2tp/ipsec as a
> remote access solution. I'm also interested in whether there are any
> other non-rmt-access benefits.

Scott, thank you for trying to add some process/sanity to this discussion. Sorry
for the long response.  BTW, I thought there was an effort by a few people to
try and capture the pros/cons of each proposal in terms of meeting the stated
requirements of IPSRA charter and put this information into the form of a draft.
Is this happening?

> 
> Clearly, folks who have been working on l2tp (and ppp) for years feel
> quite strongly about this, but strongly-held views are only helpful here
> when backed up with objective reasoning. That's what I'm after.
> 
> The point has been made that some sort of aaa infrastructure has been
> deployed for dial-up users, and that customers should not be asked to
> discard this. Please clarify what components would be discarded if we do
> not use l2tp. For example, I know of several ipsec vendors who implement
> some sort of radius interaction without using either ppp or l2tp, so it
> seems that radius investments are not necessarily in jeopardy here.
> Please address this.

Certainly you don't need PPP or L2TP to interact with a AAA server.  However PPP
and it's interaction with AAA has been deployed for a long time and is very
mature.  Over time customers have asked for fairly nifty features relating to
their PPP and AAA deployment, some of which have become standardized and some of
which are vendor specific.  PPP does have well defined mechanisms for when to
start authentication, how to apply authorization, and when to start and stop
accounting.  Accounting in particular is of some concern to me when dealing with
IPsec by itself, since there is no well defined, robust mechanism to determine
when the user logs off and thus stop accounting.  Both PPP and L2TP have well
defined mechanisms for both controlled teardowns (ie, LCP TermReq/TermAck and
StopCCN) and keepalives for detecting a non-graceful teardown.  Additionally,
applying authorization information such as filters, allowed connection time,
idle timeouts, login banners, etc to IPsec seems to require more invention than
just reusing a protocol which already knows how to do this.  Maybe there are
some vendors which don't have all this PPP and L2TP code and it's easier for
them to just design this into IPsec and IKE.  I for one don't like this approach
since I don't think its good design practice to try and make one protocol satify
all requirements for different spaces since it will inevitably fail to do any
one well. I also don't like the fact that our customers will have to go through
all the trials and tribulations over again as we rewrite this code just to give
them what they already have with traditional dial-up PPP connections.

> 
> Secondly, in response to overhead concerns, the point has been made that
> there are various header compression schemes available in ppp/l2tp which
> mitigate this. While this response addresses the on-the-wire overhead to
> some extent, it ignores the additional packet processing overhead and
> complexity that wrapping the packets in 2 more protocols (all the while
> doing header compression) entails. Please address this.

For PPP, the header compression details are a no-op, at least for our
implementation.  PPP is really just a few extra lines of code in our switching
path, regardless of whether it is doing AFC and/or PFC.  L2TP certainly adds
some additionally switching overhead since there are tunnel/session lookups on a
per packet basis, similar to what IPsec must perform on inbound and outbound SA
lookups, except obviously less expensive since no filtering is involved.
Although we have not implemented the L2TP Header compression draft yet, in
looking at it, it should be a no-op in terms of per-packet overhead.  If you
employ L2TP HC and PPP AFC/PFC, then the overhead for running PPP over IPsec is
only 2 bytes.  If you run IPsec in transport mode, then I believe this actually
is less header overhead than running IPsec in tunnel mode.  You also get the
benefit of multi-protocol support through PPP.

> 
> Finally, in response to the security issues raised by obscuring the
> transit selectors from the ipsec machinery, the argument has been made
> that ppp provides all the necessary protections. However, this is not
> all that reassuring, and conjures up images of the left hand not knowing
> what the right hand is doing. Please elaborate a bit on how this
> mechanism provides comparable assurance to one where ipsec is employed
> alone.

There are certainly two camps here and it almost becomes a religous discussion.
My argument has always been that protecting L2TP with IPsec provides the same
level of security which our customers have today with their traditional
networks. If I have an IPsec SA set up between two peers (A and B), and the
traffic which is protected between us is A <-> B, UDP, port 1701, 1701 than the
only traffic which L2TP should *ever* see is traffic which arrived from that SA.  
Otherwise it should have been dropped when performing the inbound filtering
checks by IPsec.  This statement requires no binding between L2TP and IPsec!  
Now if I want to limit the type of traffic I allow my peer to send into my
network, I can apply filters to the PPP interface as has been traditionally done
by our customers.  They understand how this should be done and how to audit this
as well.  Additionally, at least for Cisco, they can get this filters on a per
user basis as part of their authorization information obtained from the AAA
server.  The additional point which can be made is that the traditional firewall
filters which can be applied to a PPP interface are much more robust than what
typically can be applied to IPsec packet filter statements.

In addition to the points which you brought up above, running PPP/L2TP over
IPsec by definition makes this a routeable interface with all the
characteristics of an interface.  We have discussed this before on this list and
again there are several camps which say this is just an implementation issue for
IPsec.  I maintain that implementation issues lead to interoperability issues
and ultimately customer dissatisfaction.

I think in a previous email you asked for a laundry list of what PPP/L2TP
provides in this space.  Well here's my list:

1) IP/DNS/WINs assignment through IPCP
2) User authentication
3) AAA integration
4) multi-protocol support
5) Link layer negotiation for MRU (this may help in the fragmentation arena)
6) Keepalives for both PPP and L2TP
7) Multilink PPP for bundling bandwidth
8) Routeable interface

Note that most of these are really PPP centric.  I would argue that the main
reason you need L2TP in this space is that it provides a well defined, well
deployed mechanism to transport PPP over IP which allows it to be protected by
IPsec.  If most people agree that PPP is an adequate solution to this problem
but L2TP is the problem, then I am certainly open for the discussion of a better
mechanism to tunnel PPP.  Although I think will we be hard pressed to do so
without reinventing L2TP.

My biggest point about this whole discussion is that I think it would be a real
shame to reinvent protocols defined by the IETF and features requested by our
customers within the IPsec working group unless there is a very compelling
reason why those protocols fall short of the requirements needed by the IPsec
and IPSRA working groups.

-Skip

> 
> Scott
> 
>
Follow-Ups: References: