Subject: Re: PPP encryption documents

From: Vernon Schryver <[email-masked]>
Date: Thu, 25 Jun 1998 08:36:07 -0600 (MDT)

> From: Thomas Narten <[email-masked]>
>
> > Given the problems the L2TP people have had with security, that sounds a
> > little messy.  At the very least, such considerations should not be allowed
> > to derail or delay L2TP.
>
> I mentioned L2TP only in the sense that a stronger PPP authentication
> mechanism might be useful to L2TP. Actually, to a client running PPP
> that suspects that L2TP is being used. Specifically, if you are a
> client, and you don't know anything about how L2TP is being used by
> your ISP, the standard thing to do is assume the worst and do you own
> end-to-end encryption/authentication. Right now, that does not include
> strong authentication at the PPP level.

I strongly disagree with that as stated.  If you have 0.1% of a clue, and
you care about the security (either integrity or confidentiality) of your
data, you do run an end-to-end encryption (which includes replay attack
defenses), and so do not give a fig what happens at or below any link
layer in the path, including links those using PPP.  None of PPP in almost
any real situation, whether L2TP is involved or not, is remotely
end-to-end.  Better PPP/L2TP encryuption might protect your data between
the first and last boxes at your ISP, but what about sniffers on the
Ethernet connecting the last box to the next hop?

It is inevitiable that essentially all uses of PPP are <<NEVER>> even
remotely end-to-end.  The best thing that can be done for security is to
accept that fact and not obscure it by talking about security within,
below, or beside PPP.  The current as well as literally all conceivable
kinds of PPP security harm real security by allowing people to fool
themselves, or be fooled by salescritters.

> I would agree that using IPSec as part of the L2TP infrastructure
> makes sense, but that is not something the end user has control
> over.

If user cannot trust their ISP's to use L2TP with IPSec or take equivalent
precautions (e.g. keeping the link between PPP/ISDN boxes in a secure
space), then users cannot trust ISP's to do anything with L2TP security.
Simply adding protocol mechanisms won't cause ISP's to pick good passwords
for whatever mechanism you like, or keep them secret.  And again, in most
cases, the wires on which L2TP is run are as secure as the boxes L2TP
connects.  It would be silly to run serious security on the short wires
on which L2TP runs, because the bad guy would be using the trace facilities
in the terminal boxes because it's easier than using a sniffer.  Or at
least sniffing on the output of the last box, after MP has re-ordered
the fragments and made the target's traffic readable.

>       (The end user could also of course run IPSec end-to-end across
> PPP, but that would only help IP traffic.)

If you really care about security, you run IPsec above PPP.  If you don't,
you're just talking about security or selling snake oil.

As for not helping non-IP traffic, what non-IP traffic invovles ISPs who
might sneak in an L2TP tunnel?  Unless you are talking about traffic that
never leaves the terminal PPP peers, PPP is still not end-to-end, and so
any security involving PPP and/or L2TP is eyewash that that is a danger
to the naive or unwary.  Your Appletalk or Netware packets are far more
likely to be sniffed on the Ethernet beyond the terminal PPP/L2TP box than
in the L2TP link just before the terminal box.

I've heard that some people think that L2TP will be used heavily for
virtual private nets.  I think that's unlikely, but if it does happen,
they'll be using IPSec below L2TP.

You cannot do real security without involving the ends.  The end user
always has all control necessary for security.  Making L2TP more or less
secure would have absolutely no effect on any real security, because
end-to-end security involves the ends (including the user) and ignores
the middle.  If this hypothetical non-IP traffic does not have sufficient
security of its own (e.g. application layer), then nothing you can do
for, to, with, or by L2TP and/or PPP will help.

> Also, to clarify, although L2TP is being considered by the IESG at
> present, it's outcome is not tied to this discussion.

good.

> > Besides, isn't the L2TP position that anyone who really cares about
> > security below the application layer will be using IPSEC below the L2TP-PPP
> > tunnel?
>
> The end user doesn't have control over this. Isn't one of the goals of
> L2TP that it is completely transparent to the client? I.e., the client
> doesn't even know it's being used.

Yes.  So what?  Regardless of whether L2TP is involved, your PPP link is
equally and inevitably insecure.  So what if your ISP exposes half of the
MP fragments of your packets to a private, very secure 10-foot Ethernet
connecting two hubs before assemblying them into complete IP packets and
putting on much larger Ethernets, FDDI rings, and serial links, in the
clear and very more available to bad guys with sniffers and taps?  In real
life, L2TP does and cannot affect the security of PPP for good or ill.

Security requires honest and rational assessements of risks.  Making L2TP
secure would be about as smart as using multiport bridges (a.k.a.
"switches") to Ethernets secure.  That zillions of switch salescritters
and their marks don't know about routing, ARP, and other hacks to look
through that gauze curtain does not justify making PPP have similar snake
oil security.

Vernon Schryver    [email-masked]

---

From: [email-masked] (Patrice Calhoun)
Date: Thu, 25 Jun 1998 10:10:56 -0700

This really comes down to packet effeciency more than anything else.

If IPSEC is applied to the outer IP header, then you guarantee that both the
L2TP protocol as well as the payload is protected. What we are really talking
about here, in case I missed the original e-mail is protecting L2TP. 

Given that end-to-end encryption is far from ubiquitous, I believe this to
be more than sufficient. In a scenario where end-to-end is required, then
possibly all that really needed is AH on the outer IP header, and ESP (with
possibly AH) on the inner IP header.

PPP encryption simply does not work very well. I have had discussions with
some people that used CCP, and with the current best effort state of the 
internet, it causes so much re-syncing on both ends that the effective
throughput is not tolerable.

So, although I have NO idea what originated this thread, nor what the initial
question really was (since I think that it started on the PPP mailing list), I
would state that IPSEC on the outer IP header only.

Now, in the case of compulsory tunneling its a different beast altogether and
it is clear that IPSEC on the inner IP header is necessary, however since 
end-to-end encryption is not available in most cases, I believe that the LNS
will have to act as a "Security Gateway" that requires a security association
between the PPP CLient and the LNS (see the IPSEC Architecture document for more
info).

Hope this helps,

PatC
>Some additional comments:
>At 10:45 AM 6/25/98 -0400, W. Mark Townsley wrote:
>>
>>There are two issues here. Protecting L2TP, and protecting PPP that is
>>being tunneled by L2TP. There are also two deployment models. 
>>
>>Thomas is referring to the model where L2TP is transparent to the PPP
>>user. Assuming the peer dialing into the ISP even knows that L2TP is
>being
>>used to create his/her VPN, it is not up to the PPP peer (from the
>>protocol's perspective) to dictate whether or not IPSec or any other type
>>of protection over the L2TP tunnel is used. In this case, the ISP is
>>initiatiating the tunnel, thus it is the ISP's responsibility to provide
>>whatever level of protection that the client is paying for and that the
>>ISP is willing to live with. If the client is truly concerned about the
>>*privacy* of his or her data, then a form of end to end encryption should
>>always be used (PPP, IP, Application level or otherwise). 
>
>The client can run IPSEC end to end (assuming the client's IP stack
>supports it of course).  PPP encryption only runs from the client to the
>LNS.  Of course, this could/would end up with the ISP protecting the
>tunnel with IPSEC and the client protecting their transmission with IPSEC.
>>
>>If the end user is not only running PPP, but initiating L2TP as well
>>(sometimes referred to a PPP/LAC client), then it is up to the client
>>provide whatever L2TP protection is desired. In this case, IPSec can and
>>should be used by the client. PPP encryption alone would of course only
>>serve to protect the PPP data, not the L2TP control messages and
>>encapsulation (not to mention UDP/IP running under L2TP). The bonus here
>>is that since L2TP and PPP are intiated and controlled by the same
>source,
>>if L2TP is protected, PPP is protected as well, so PPP encryption is not
>>necessary.
>
>There is an interesting component to client tunneling.  Running IPSEC on
>the transport IP stack would protect the L2TP info, but only runs from the
>client to the LNS.  True "end-to-end" encryption would use IPSEC on the
>upper IP stack.  This would protect the data from the client to the
>destination application, but would not protect the L2TP control messages.
>Of course, you could run IPSEC on the upper IP layer to protect the
>end-to-end data and (a different instance) on the transport IP stack to
>protect the L2TP control messages. aaack!
>
>M.C. Escher could probably draw a good diagram of this. ;-\
>Chip 
>
>>On Thu, 25 Jun 1998, Thomas Narten wrote:
>>
>>> over. (The end user could also of course run IPSec end-to-end across
>>> Thomas
>--------------------------------------------------
>Chip Sharp			voice: +1 (919) 851-2085 
>Cisco Systems		Mgr - Telco Consulting  			
>--------------------------------------------------

---

From: [email-masked] (Rich Shea)
Date: Thu, 25 Jun 1998 17:10:56 -0400

At 01:02 PM 6/25/98 -0700, Philip Rakity wrote:
>
>Bill,
>
>You are correct.  If one argues that a packet can be injected (correct
>sequence number, etc) then a denial of service attack is possible.  One
>can also do the samething against IPSec by flooding IP packets.
>

Not as effectively, since with IPSEC you authenticate the packets first
which is less intensive than decryption so the denial of service attack is
not as effective.  Also there is no chaining between IPSEC packets so there
is no concept of having to drop a packet because the one before it was lost
(or invalid).

>Philip
>
>
>On Thu, 25 Jun 1998 [email-masked] wrote:
>
>> 
>>      Philip,
>>      
>>      Even if they don't crack your DES key, can't they inject packets in a 
>>      denial of service attack?  If you fail to decrypt the injected
packet, 
>>      you discard that one as well as the next good one.  Meanwhile, you're 
>>      expending MIPs decrypting.  If memory serves me (always
questionable), 
>>      one of the reasons for adding authentication to ESP was for such 
>>      attacks.  ESP Authentication is much faster than decryption.
>>      
>>      Bill
>> 
>> 
>> ______________________________ Reply Separator
_________________________________
>> Subject: Re: PPP encryption documents
>> Author:  Karl Fox <[email-masked]> at internet-mail
>> Date:    6/25/98 3:11 PM
>> 
>> 
>> Philip Rakity <[email-masked]> writes:
>> > We run RFC1669 PPP DES Encryption over a L2TP link to provide security
>>             ^^^^1969
>> > between the LAC (eg our L2TP Client) and the LNS.  The encrypted
tunnel is 
>> > created between us and the LNS and is not visible to the ISP, and the
>> > link is secured between the LAC and the ISP since it is encrypted. 
>> > 
>> > The security of the encrypted link depends upon the ablility to break
DES 
>> > and the ability to break the MD5 hash for CHAP
>>      
>> Are you sure about this?  If someone cracks your DES key but not the 
>> CHAP MD5 key, can't they inject encrypted packets into your L2TP 
>> stream?
>> -- 
>> Karl Fox, servant of God, employee of Ascend Communications
>> 655 Metro Place South, Suite 370, Dublin, Ohio  43017   +1 614 760 4041
>>      
>> 
>> 
>
>
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Richard Shea, Principal Engineer               [email-masked]
Bay Networks / Extranet Access                          978-635-2019