[j-nsp] Juniper and L2TPv3?

[Zvezdelin Vladov]

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?

Thank you very much!

Zvezdelin Vladov

[Christopher Morrow]

Post by Zvezdelin Vladov
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 was: "Thats not standards based" and they replied:
"yea, but it works the same"... it was a circular arguement with no
real answer arrived at :(

If you paid them enough for the devel work and to move it up the
feature tree I'd bet they'd introduce it for you/us/everyone.

[Christopher Morrow]

Post by Christopher Morrow

Post by Zvezdelin Vladov
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 :(

[Shane Amante]

Chris,

Post by Christopher Morrow

Post by Christopher Morrow

Post by Zvezdelin Vladov
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

[Zvezdelin Vladov]

Dear All,

Thank you for all of your replies,
but what about this?

Searching L2TPv3 at:
http://www.rfc-editor.org/cgi-bin/idsearch.pl

gives this:

draft-ietf-l2tpext-pwe3-ethernet-02 Transport of Ethernet Frames over
L2TPv3 Rahul Aggarwal l2tpext 7-Dec-04

And within the draft:

Rahul Aggarwal
Juniper Networks

Any suggestion?

Zvezdelin Vladov

On Fri, 14 Jan 2005 02:45:08 +0000, Christopher Morrow

Post by Christopher Morrow
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"

I would expect the answer to be "GRE".

Ah-ha, I have forgotten my tunnelings. I do believe you are correct.

Post by Christopher Morrow
to which the reply was: "Thats not standards based" and
they replied: "yea, but it works the same"... it was a circular
arguement with no real answer arrived at :(

a) it must not fit M-series max encaps string size.
b) it is convinient to vendor X to create a new copy of GRE since a
given set of semantics are desirable for an IP tunneling encaps and
the existing implementation of GRE on platform Y doesn't have those
semantics (desirable: "precomputed encaps" vs undesirable: "double
route lookup" on output).

I believe the reason to want l2tpv3 was related to some state on the
tunnels, it's been a while, hence my switching gre and CCC :(

That is my recollection of the time i was working for vendor X.
It is a solution which serves the interests of one particular vendor
ramed through the a standards body, by choosing a WG noboby is paying
much attention to... after all L2TP is this dial thing.
My personal view, only.

Post by Christopher Morrow
If you paid them enough for the devel work and to move it up the
feature tree I'd bet they'd introduce it for you/us/everyone.

That is always true... it can be done on the AS PIC (and probably
t-series). But not using m-series normal forwarding path (i.e. tunnel
Pic).
cheers,
Pedro.

[Danny McPherson]

Post by Zvezdelin Vladov
Rahul Aggarwal
Juniper Networks
Any suggestion?

Heh.. How about "Rahul hasn't been at Juniper that long
and worked on this at his previous employer"? :-)

-danny

[David Gethings]

Post by Zvezdelin Vladov
Does anyone know if Juniper supports L2TPv3 in their M-Series or any
other series?

Not sure that the M series does but I am sure the E series does.

[David Gethings]

Post by David Gethings
Not sure that the M series does but I am sure the E series does.

Forget that. I'm totally wrong. I believe it's not supported.

But don't quote me on that. ;)

[Fouant, Stefan A]

-----Original Message-----

Post by David Gethings
Not sure that the M series does but I am sure the E series does.

Forget that. I'm totally wrong. I believe it's not supported.

Juniper M Series does not support L2TPv3 at this time, and there is no
roadmap for it anytime in the near future. Believe me, we've been
bugging them to support this for quite some time.

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.

RFC 2890 is still only 32 bits when compared to L2TPv3's 32 bit sequence
and 32 bit key for a total of 64 bits, definitely more secure than GRE
w/ 2890. As for support, I recently beta tested RFC 2890 support for
Juniper and it should be introduced in JUNOS 7.1.

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.

I've done this and it works... (2547 in GRE in IPSec, back into MPLS for
TE) and it is fun ;)

Stefan Fouant
Senior Network Engineer
UUNET / MCU