Subject: L2TP and IPSec

From: "Cheng-Yin Lee" <[email-masked]>
Date: 25 Nov 2002 18:55:19 -0500

Eric,
During the discussion on CE-based VPL, I understood your question to be
: "Why use L2TP+IPSec and not just IPSec?", perhaps people in L2TPEXT WG
has some comments on that.
But someone pointed out perhaps that is not what you meant, could you
kindly clarify this pls?

thanks,
cheng-yin

---

From: Eric Rosen <[email-masked]>
Date: Tue, 26 Nov 2002 10:54:16 -0500

The intent of CE-based VPN work is  usually to allow the CEs to be connected
over the public Internet.  So it  seems that IPsec is needed.  For VPLS, you
may also  want to  use IP-encapsulated ethernet  pseudowires from  PWE3.  So
the path of least resistance  leads to IPsec+L2TP, perhaps L2TP within IPsec
transport mode.  

I was thinking that once you have  IPsec between the two CEs, it is overkill
to also have L2TP, but maybe there's no real problem with that.

---

From: Mark Duffy <[email-masked]>
Date: Tue, 26 Nov 2002 17:39:21 -0500

I'm not familiar enough with the VPL work to be sure whether this is
relevant or not, but one possible reason to use L2TP+IPsec would be to get
the capability (based on L2TP sessions) to multiplex many separate VPN
contexts within one IPsec SA.  Thus saving on number of SAs to create.
Also, L2TP is readily extensible to allow binding each L2TP session to a
given VPN context.  IPsec is not readily extensible to allow binding each
SA to a given VPN context.  

--Mark

---

From: "alok" <[email-masked]>
Date: Wed, 27 Nov 2002 12:27:57 +0530

> contexts within one IPsec SA.

are u planning to use tunnel multiple customers in 1 IPSEC tunnel?

and using L2TP to distinguish them?

and are you saying the IPSEC tunnels are PE to PE, not CE to CE?

---

From: Mudhafar Hassan-Ali <[email-masked]>
Date: Tue, 26 Nov 2002 16:09:39 -0800

Mark,

I concur with you. Additionally L2TP allows for multiplexing multiple PPP
sessions, which leads to the use of AAA functions etc.

Mudhafar

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Nov 2002 09:42:58 -0800

> contexts within one IPsec SA.  Thus saving on number of SAs to create.

Muxing several VPNs over a single IPsec is contradictory:

	- if the VPNs have sufficient security, they don't need IPsec
	underneath

	- if the VPNs lack security, they're not P anymore.

> SA to a given VPN context.  

"extensible?" - this group isn't chartered to form new protocols to 
solve problems.

Having a separate VPN ID space doesn't magically solve anything. VPN IDs 
must be unique, at least where multiple VPNs 'touchdown' (share routers 
or so-called 'edge' devices).

I.e., there are two solutions:
	a- IPsec with nonoverlapping (where touchdown occurs) addresses
	b- L2TP et al extended with nonoverlapping VPN IDs

(a) exists; (b) provides a larger IP address space, at the cost of 
requiring extension and deployment of a new protocol

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Nov 2002 13:13:09 -0800

Cheng-Yin Lee wrote:
> Joe, Mark, Alok,
> Some quick comments.
> 
> For  CE-based Virtual Private LAN (VPL):
> - there is  no multiplexing of different customers VPL over a single IPSec
> - VPL ID is not used regardless of whether IPsec or L2TP is the tunneling
> protocol
> - As Eric Rosen pointed out, "the path of least resistance  leads to
> IPsec+L2TP", and I agree with him on this respect.
> I am open to using IPSec (in fact, personally, I do like something like EtherIP,
> but would IANA assign a new/recycled protocol ID for CE-based VPL?), but as I
> understand from discussions, L2TP options signaling and keepalives are nice for
> VPL applications, and L2TP+IPSec overhead is not significant compared to IPSec
> only. Perhaps the L2TPEXT WG has some comments.

IMO, these VPNs should be largely independent of tunnel used. There is 
no need for signalling or keep-alives per se in a tunnel - that is the 
task of a routing protocol within the VPN.

The path of least resistance involves not creating new protocols.

Joe

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 27 Nov 2002 18:07:57 -0500

Joe,

> task of a routing protocol within the VPN.
Perhaps I misunderstood your point, but I was commenting on Virtual
Private LAN above.

> The path of least resistance involves not creating new protocols.
May I know which new protocols are you referring to?

thanks
cheng-yin

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 27 Nov 2002 14:49:16 -0500

Joe, Mark, Alok,
Some quick comments.

thanks
cheng-yin

---

From: Mark Duffy <[email-masked]>
Date: Thu, 28 Nov 2002 11:51:51 -0500

>and are you saying the IPSEC tunnels are PE to PE, not CE to CE?

What I plan to do is not for this forum :-)   But what I was talking about
was using an l2tp session per vpn context.  And an ipsec sa per l2tp
tunnel.  PE-PE.

---

From: Mark Duffy <[email-masked]>
Date: Thu, 28 Nov 2002 12:02:50 -0500

>	- if the VPNs lack security, they're not P anymore.

I disagree.  The multiple VPNs share an SA only from PE to PE.  The
"customers" (whose data is in the VPNs) do not have the keys.  It's a
little like a bank where they lock your money and mine in the same vault.
But that doesn't mean I can withdraw your money nor you mine.

>"extensible?" - this group isn't chartered to form new protocols to 

The extension I had in mind was merely allocating an AVP to convey a VPN
Identifier to bind to an l2tp session.  L2tpv3 already has such an AVP, but
I don't  think l2tpv2 does.  I, personally, am operating on the assumption
that allocating a new l2tp AVP is not outside the charter of this wg.

I believe allocating such an AVP for l2tp is *much* more feasible than
allocating a corresponding IKE payload to do such a thing for IPsec.

--Mark