[j-nsp] Juniper and L2TPv3?

[Shane Amante]

Chris,
On Jan 13, 2005, at 7:44 PM, Christopher Morrow wrote:
> On Jan 14, 2005, at 2:08 AM, Christopher Morrow wrote:
>> On Jan 13, 2005, at 9:22 AM, Zvezdelin Vladov wrote:
>>
>>> Hi All,
>>>
>>> I have one quick question....
>>>
>>> Does anyone know if Juniper supports L2TPv3 in their M-Series or any
>>> other series?
>>>
>>> Can you please refer me to a document on their website stating the
>>> L2TPv3 support
>>> or exactly the opposite?
>>>
>>
>> Don't have a document reference, but I recall that their answer to 
>> 'we want you to do l2tpv3 because it's standards based' was: "uhm, 
>> use CCC" to which the reply
>
> I was reminded that the 'uhm, use ccc' was actually 'uhm, use GRE' ... 
> I'm forgetting right now the push for l2tpv3 instead of GRE, for that 
> I also apologize :(

One advantage of L2TPv3 over GRE is potentially stronger resilience 
against attacks on the data plane[1].  I say "potentially stronger", 
because the Cookie field is optional in L2TPv3.  (An L2TPv3 cookie is 
an [up to] 8-byte randomly generated nonce that verifies received 
packets are correlated with the Session ID in the packet, to prevent 
against blind, insertion attacks).  Cookies aren't a panacea, but IMO 
they significantly raise the bar in protecting routine, non-sensitive 
VPN data, without imposing the processing overhead required by IPsec.

Refer to Section 8.2 (and 8.1) of the L2TPv3 draft for more info on 
L2TPv3 security:
http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tp-base-15.txt

In the end, L2TPv3 is just another tool in the toolbox.  With respect 
to securing GRE, RFC2890 proposes a 4-Byte key & sequence numbers for 
GRE packets, which arguably provides equivalent security to L2TPv3 
Session ID's & Cookies -- however, I can't tell if Juniper implements 
RFC2890.

Finally, one could put MPLS [PWE3|2547] in GRE in IPsec (possibly back 
in MPLS, for fun :-).  This probably already works on Junipers -- I 
haven't played with it, but they've got all the protocols there :-).  
Although this will give you excellent security (assuming IPsec 
encryption/authentication of payloads) and may be useful is some 
limited situations, it is certainly a complex design with a lot of 
overhead and, IMO, it would be difficult to deploy, and maintain, on a 
medium- to large-scale.

[1] http://www.nanog.org/mtg-0402/pdf/townsley.pdf