Subject: Re: L2TP and IPSec

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 03 Dec 2002 02:56:51 +0100

Mark Duffy wrote:
> At 09:42 AM 11/27/02 -0800, Joe Touch wrote:
> 
>>
>>Mark Duffy wrote:
>>
>>>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, keeping the tunnneling mechanism above IP separate from the security 
mechanism of IP allows IPsec to focus on securing IP traffic between two points, 
and L2TP to focus on tunneling Layer 2. From a security perspective, I would be 
uncomfortable mucking around with IKE unnecessarily, or managing more SAs than 
necessary.

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

Note that you can always have multiple SAs (one per VPN and PE pair) if you 
want, but you are not forced to.

> 
> 
>>>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.  
>>
>>"extensible?" - this group isn't chartered to form new protocols to 
>>solve problems.
> 
> 
> 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.  

The exact application was left somewhat out of scope in L2TPv2 as defined in 
RFC2661, but a number of AVPs are sometimes used for this today (i.e. the 
Calling Number AVP, or ATM VPI/VCI AVP). More often, session binding is 
performed via PPP-level authentication on top of the L2TP session (which, in 
turn, may also be carried in an L2TP AVP).

The AVP format in L2TPv3 and L2TPv2 is identical, so you could quite easily use 
one AVP for the other. That said, if at all possible I would personally prefer 
to see folks move to L2TPv3 in full, rather than picking and choosing pieces 
into L2TPv2.

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

You may only have to go so far as to reference existing mechanisms of L2TPv3. I 
don't see this as protocol definition at all, merely application definition, 
which I believe is within the charter of this group.

> --Mark

---

From: Eric Rosen <[email-masked]>
Date: Tue, 03 Dec 2002 10:20:45 -0500

Mark> Also,  keeping the  tunnneling mechanism  above IP  separate  from the
Mark> security mechanism of IP allows  IPsec to focus on securing IP traffic
Mark> between two points, and L2TP to focus on tunneling Layer 2. 

Well, you  should have made that argument  some years ago when  the IPsec WG
was inventing  their own tunneling protocol  ;-) The problem now  is that if
one proposes to  use L2TP-in-IPsec, someone will point out  that this is one
tunneling  protocol inside  another,  and that  it  therefore violates  some
principle  or other of  network metaphysics.   (Of course,  if we  use IPsec
transport mode  we can  claim that  we have not  violated this  principle of
metaphysics, but  of course there's always another  principle of metaphysics
that can be trottted out ...)

I see  two arguments  in favor of  passing PWE3 stuff  transparently through
IPsec: 

1. This allows PWE3 signaling to pass through, and there is no temptation to
   try to add PWE3 stuff to IPsec signaling. 

2. This allows a single SA  to carry multiple ethernet links.  (I think this
   is really  what Mark  Duffy was getting  at.  Whether the  multiple links
   belong to different VPNs or not is an issue for a higher layer.) 

I think these are  good arguments, but iff one gave no  weight to them, then
ethernet-in-IP-in-IPsec is what would make the most sense.

---

From: Eric Vyncke <[email-masked]>
Date: Tue, 03 Dec 2002 17:36:23 +0100

>was inventing  their own tunneling protocol  ;-) The problem now  is that if

While I agree, please note that IPSec tunnel mode is identical to IPinIP protected by IPSec transport mode. So, the real question is rather: why IPSec WG complicated everything ;-)

-eric

---

From: "alok" <[email-masked]>
Date: Tue, 3 Dec 2002 22:21:11 +0530

say that to GRE too?

----- Original Message -----
From: Eric Vyncke <[email-masked]>
To: <[email-masked]>
Cc: W. Mark Townsley <[email-masked]>; Mark Duffy
<[email-masked]>; Joe Touch <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, December 03, 2002 10:06 PM
Subject: Re: L2TP and IPSec

> While I agree, please note that IPSec tunnel mode is identical to IPinIP
protected by IPSec transport mode. So, the real question is rather: why
IPSec WG complicated everything ;-)

---

From: Joe Touch <[email-masked]>
Date: Tue, 03 Dec 2002 08:44:32 -0800

Eric Vyncke wrote:
> While I agree, please note that IPSec tunnel mode is identical to
> IPinIP protected by IPSec transport mode. So, the real question
 > is rather: why IPSec WG complicated everything ;-)

See draft-touch-ipsec-vpn

Although the two generate the same packet on the wire, they differ 
dramatically in the order of processing of certain steps, and thus 
capabilities.

Joe

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 03 Dec 2002 17:58:42 +0100

Eric Rosen wrote:
> was inventing  their own tunneling protocol  ;-) 

I did, at the very least for the ipsra space.

> ethernet-in-IP-in-IPsec is what would make the most sense.

I consider both #1 and #2 significant.

I would also consider the functional decomposition of the PWE3 service on top of 
IP from the securing of the IP connectivity itself as advantageous from a 
troubleshooting perspective, as well as from a service offering perspective in 
the case where no, or perhaps a selection of, tunnels need packet-level 
authentication, encryption, non-repudiation, etc. provided by IPsec.

- Mark