Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs

From: Robert Raszuk <[email-masked]>
Date: Wed, 04 Feb 2004 23:40:37 -0800

Hi Richard,

 > in which case the same security
 > risks apply to MPLS 2547 networks and IP 2547 networks anyway.

It would be interesting to see how did you achieved the above conclusion.

If any PSN carries internet natively it seems much harder to inject MPLS 
labeled packets into them then IP packets. Of course one could protect 
such a network on all ingress points to accept any IP packet destined to 
a group of PE loopbacks used as next hops for IP 2547 and that is main 
protection scheme which should be applied in all IP 2547 networks.

It is my understanding that Mark's proposal just attempts to deliver an 
extra protection layer for operator's mistakes where such an ingress ACL 
could be by mistake omitted or for whatever reason disabled on any 
external interface.

Now signaling wise my personal opinion is that for operator's benefit 
both ways should be allowed. For those who use L2TPv3 for L2 transport 
and PE-PE L2TPv3 signaling is already in place it seems much more 
natural to extend it to carry extra information. For those who do not 
intend to use L2TP for L2 services using BGP which is already in place 
seems equally fine. The overhead incurred to distribute required 
information by BGP is pretty much negligible.

Also looking at the extra signaling need when L2TP encapsulation is used 
in Inter-AS cases for IP 2547 BGP seems a bit better suited as well. In 
a lot scenarios ingress ACL protection of such a remote islands may not 
be always at all possible :-).

Rgs,
R.

 > [email-masked] wrote:
> Mark,
> 
> The justification for using L2TP as opposed to IP or GRE
> encapsulation over an IP PSN seems to be that security is improved.
> However, from what I understand security in an IP/GRE encapsulated
> PSN using 2547 is exactly the same as a PSN using MPLS, i.e. security
> is not an issue and is comparable to FR/ATM. That is unless the same
> PSN is to be used for carrying Internet traffic (natively, not inside
> a VPN) and customer VPN traffic, in which case the same security
> risks apply to MPLS 2547 networks and IP 2547 networks anyway. The
> inherent problem being that IP the control traffic shares the same
> data plane as the public Internet traffic, unlike ATM which uses an
> out-of-band control plane (and is the only sensible solution to the
> problem, i.e. use reserved labels for control/management traffic in
> MPLS).
> 
>> From an L2 perspective I can see that L2TP could be useful as it is
>> well suited for encapsulating and signalling L2 tunnels. However, I
>> do not see why L2TP is useful for L3 VPNs, why not just use GRE or
>> IP encapsulations, which don't require any signalling? I could
>> maybe understand if a provider was using L2TP for L2 services and
>> wanted to reuse L2Tp for L3 services, but if so, why use BGP
>> signalling why not use L2TP signalling?
> 
> Also, I do not agree with the use of the phrase "RFC 2547 Style
> VPNs", which is used several times within this draft. I would not
> consider RFC2547 to be a 'style' of VPNs, I would consider RFC2547 to
> be a specific VPN implementation, just like FR or ATM are specific
> VPN implantations. Why is the word 'style' used? Why not just say RFC
> 2547 VPNs?
> 
> Richard
> 
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]]On Behalf Of Yakov Rekhter Sent: 04
>> February 2004 20:55 To: W. Mark Townsley Cc: [email-masked];
>> [email-masked] Subject: Re: MPLS over L2TPv3 encap for RFC 2547
>> VPNs
>> 
>> 
>> Mark,
>> 
>> 
>>> Yakov Rekhter wrote:
>>> 
>>> 
>>>> Please document in your draft what is exactly "prudent" about
>>>> BGP.
>>> 
>>> Using draft-ietf-l3vpn-ipsec-2547-01.txt as a guide:
>>> 
>>> "RFC2547 already provides an egress-to-ingress signaling
>> 
>> capability via BGP,
>> 
>>> and we specify below how to extend this to the signalling
>> 
>> of security policy."
>> 
>>> I will add this text to the l3vpn-l2tpv3 document:
>>> 
>>> "RFC2547 already provides an egress-to-ingress signaling
>> 
>> capability via BGP,
>> 
>>> [NALAWADE] or [RAGGARWA] specifies how to extend this to
>> 
>> the signaling of
>> 
>>> L2TPv3 reachability information for a PE."
>> 
>> Sorry, but the analogy with draft-ietf-l3vpn-ipsec-2547-01.txt does
>>  not work. This is because draft-ietf-l3vpn-ipsec-2547-01.txt does 
>> *not* replace IPSec signaling with BGP. All it does is specifying 
>> how to use BGP to indicate whether a particular VPN on a PE should 
>> use IPSec to get traffic to that PE.
>> 
>> In contrast your draft uses BGP not just to specify whether a 
>> particular VPN on a PE should use l2tp to get traffic to that PE, 
>> but also uses BGP to carry the l2tp session and cookie (l2tp
>> signaling information). That is, in contrast to 
>> draft-ietf-l3vpn-ipsec-2547-01.txt your draft does replace the l2tp
>> signaling protocol with BGP, thus eliminating the need for l2tp
>> signaling with the l2tp signaling protocol.
>> 
>> Just tell us why BGP signaling is any better than l2tp signaling.
>> 
>> 
>>>> That is, there is nothing in your draft that is specific to
>>>> just
>>> 
>>>> 2547. E.g., it is equally applicable to VR based L3VPNs.
>> 
>> Therefore,
>> 
>>>> the draft has to be generalized to cover any
>>>> multipoint-to-point application of MPLS over l2tp.
>>> 
>>> No, the l3vpn-l2tpv3 draft specifies carrying an MPLS label
>> 
>> for a VPN-IPv4
>> 
>>> address distributed via RFC2547 extensions to BGP between
>> 
>> PEs. I should not
>> 
>>> extend this draft to cover other L3VPN models any more than 
>>> draft-ietf-l3vpn-ipsec-2547-01.txt or
>> 
>> draft-ietf-l3vpn-gre-ip-2547-00.txt
>> 
>>> should. Shall I rename it to something with "2547" in the
>> 
>> title to be
>> 
>>> more clear?
>> 
>> First of all I'd like to thank you for pointing that both 
>> draft-ietf-l3vpn-ipsec-2547-01.txt or 
>> draft-ietf-l3vpn-gre-ip-2547-00.txt took a fairly narrow point of
>> view. This is a bug, not a feature, and therefore it should be
>> fixed.
>> 
>> Second, the restriction on the applicability of your draft to 2547
>> is quite arbitrary. That is, there are *no* technical
>> justifications for this restriction. And the fact that some other
>> drafts took a fairly narrow view of the problem is no justification
>> for continuing this.
>> 
>> 
>>>>>> 3. The security claims have to be reviewed by the Security
>>>>>> ADs.
>>> 
>>> I am more than happy to have discussions with Security ADs
>> 
>> on this topic.
>> 
>> Thanks. Please post the outcome of this discussion to the list.
>> 
>> Yakov.
>> 
> 
>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 05 Feb 2004 13:52:46 +0100

[email-masked] wrote:

> Mark,
> 
> The justification for using L2TP as opposed to IP or GRE encapsulation over
> an IP PSN seems to be that security is improved. However, from what I

Actually, the justification is 3-fold. As detailed in Section 5 "Applicability" 
of draft-townsley-l3vpn-l2tpv3-00.txt, the first two reasons have more to do 
with whether or not you are using L2TPv3 for other services on your network and 
wish to maintain a homogeneous type of tunneling encapsulation for MPLS as well 
as FR, ATM, etc. Incidentally, these two are precisely the same two reasons 
given for why one might choose a GRE encap vs. an IP encap. Security against 
blind spoofing attacks via the Cookie is identified as an additional reason for 
L2TPv3 over and above the other two reasons.

> understand security in an IP/GRE encapsulated PSN using 2547 is exactly the
> same as a PSN using MPLS, i.e. security is not an issue and is comparable to
> FR/ATM.   That is unless the same PSN is to be used for carrying Internet
> traffic (natively, not inside a VPN) and customer VPN traffic, in which case
> the same security risks apply to MPLS 2547 networks and IP 2547 networks
> anyway. 

There are a number of references to the security concerns with respect to packet 
spoofing when running MPLS over IP or GRE. These stem from the comparative 
ability between MPLS and IP to block exterior traffic from penetrating the core 
network where the VPN is operating, and thus disallowing spoofed packets into 
the customer VPN. As I understand the argument, it is purported to be far easier 
to isolate an MPLS core by dropping labeled traffic from any non-core-facing 
interface than it would be to configure and maintain similarly-purposed L3ACLs 
on all non-core-facing interfaces of an IP core. This argument is mentioned in 
more detail in a number of places, including:

draft-ietf-l3vpn-gre-ip-2547-00.txt, Section 7
draft-ietf-l3vpn-ipsec-2547-01.txt, Section 1.1, paragraph 3
"MPLS Technology and Applications," Davie, Rekhter, pg 217

 > The inherent problem being that IP the control traffic shares the
> same data plane as the public Internet traffic, unlike ATM which uses an
> out-of-band control plane (and is the only sensible solution to the problem,
> i.e. use reserved labels for control/management traffic in MPLS).

Interesting, but how does carrying the control channel out of band help in a 
blind spoofing attack on the data plane (where one is merely guessing labels in 
attempt to break into a VPN)?

> 
>> From an L2 perspective I can see that L2TP could be useful as it is well
>> suited for encapsulating and signalling L2 tunnels. However, I do not see
>> why L2TP is useful for L3 VPNs, why not just use GRE or IP encapsulations,
>> which don't require any signalling? I could maybe understand if a provider
>> was using L2TP for L2 services and wanted to reuse L2Tp for L3 services,
>> but if so, why use BGP signalling why not use L2TP signalling?

We are only advertising a single Session/Cookie per PE (not per PE pair, per 
VPN, etc). So, for the 2547 L3VPN case, we can include this Session/Cookie in 
the BGP Next Hop Update allowing it to become part of the single adjacency that 
gets built for sending all 2547 traffic over L2TPv3/IP to that PE. If we were 
performing any sort of p2p signaling, advertising any customer-facing interface 
parameters or IDs, signaling interface status, utilizing keepalives, etc. I 
would be more inclined to use the L2TP signaling, establishing individual 
sessions between PEs.

> 
> Also, I do not agree with the use of the phrase "RFC 2547 Style VPNs", which
> is used several times within this draft. I would not consider RFC2547 to be a
> 'style' of VPNs, I would consider RFC2547 to be a specific VPN
> implementation, just like FR or ATM are specific VPN implantations. Why is
> the word 'style' used? Why not just say RFC 2547 VPNs?

"RFC 2547 Style" - it's not my word. In fact, I was stumped as to what term to 
use myself, so I referred to draft-andersson-ppvpn-terminology-04.txt which uses 
"RFC 2547 Style" and "Virtual Router (VR) style" (Page 8-9 and in some figures) 
to differentiate between the two VPN methods. I'm happy to use any other 
accepted term.

Hope this clarifies things, and thanks for the feedback,

- Mark

>> [mailto:[email-masked]]On Behalf Of Yakov Rekhter Sent: 04 February 2004
>> 20:55 To: W. Mark Townsley Cc: [email-masked]; [email-masked] Subject: Re:
>> MPLS over L2TPv3 encap for RFC 2547 VPNs
>> 
>> 
>> Mark,
>> 
>> 
>>> Yakov Rekhter wrote:
>>> 
>>> 
>>>> Please document in your draft what is exactly "prudent" about BGP.
>>> 
>> Sorry, but the analogy with draft-ietf-l3vpn-ipsec-2547-01.txt does not
>> work. This is because draft-ietf-l3vpn-ipsec-2547-01.txt does *not* replace
>> IPSec signaling with BGP. All it does is specifying how to use BGP to
>> indicate whether a particular VPN on a PE should use IPSec to get traffic
>> to that PE.
>> 
>> In contrast your draft uses BGP not just to specify whether a particular
>> VPN on a PE should use l2tp to get traffic to that PE, but also uses BGP to
>> carry the l2tp session and cookie (l2tp signaling information). That is, in
>> contrast to draft-ietf-l3vpn-ipsec-2547-01.txt your draft does replace the
>> l2tp signaling protocol with BGP, thus eliminating the need for l2tp
>>>> That is, there is nothing in your draft that is specific to just
>>> 
>>>> the draft has to be generalized to cover any multipoint-to-point 
>>>> application of MPLS over l2tp.
>>> 
>> draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt 
>> took a fairly narrow point of view. This is a bug, not a feature, and
>> therefore it should be fixed.
>> 
>> Second, the restriction on the applicability of your draft to 2547 is quite
>> arbitrary. That is, there are *no* technical justifications for this
>> restriction. And the fact that some other drafts took a fairly narrow view
>> of the problem is no justification for continuing this.
>> 
>> 
>>>>>> 3. The security claims have to be reviewed by the Security ADs.
>>>

---

From: David Meyer <[email-masked]>
Date: Thu, 5 Feb 2004 08:11:33 -0800

Richard,

>> VPNs", which is used several times within this draft. I would
>> not consider RFC2547 to be a 'style' of VPNs, I would consider
>> RFC2547 to be a specific VPN implementation, just like FR or ATM
>> are specific VPN implantations. Why is the word 'style' used?
>> Why not just say RFC 2547 VPNs? 

	Well taken. FWIW, my recollection is that the term
	"style" crept in when we were thinking that there might
	be multiple kinds of L3 VPNs (the two notable
	instantiations were 2547 and VR). So we talked about 2547
	style v. VR style L3VPNs. In any event, as you suggest,
	maybe its time to update our terminology.  

	Dave

	[I must also admit that I use "2547 Style VPN" in the
	RIFT document, but will change that -- dmm]

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 06 Feb 2004 11:34:05 -0800

Mark,

[email-masked] wrote:
> Actually, the justification is 3-fold. As detailed in Section 5
> "Applicability" of draft-townsley-l3vpn-l2tpv3-00.txt, the first
> two reasons have more to do with whether or not you are using L2TPv3
> for other services on your network a nd wish to maintain a homogeneous
> type of tunneling encapsulation for MPLS as we ll as FR, ATM, etc.

If you already using l2tpv3 for other services, that means that you
already using l2tpv3 signaling as well. So, why for 2547 you
would use BGP as a signaling protocol ? 

> Incidentally, these two are precisely the same two reasons given
> for why one might choose a GRE encap vs. an IP encap. 

The analogy does not work, as there is one significant difference
between GRE and l2tpv3 - GRE encaps does not require any signaling,
l2tpv3 does.

[clipped...[

> the BGP Next Hop Update allowing it to become part of the single adjacency 
> that gets built for sending all 2547 traffic over L2TPv3/IP to that PE. 

Two points:

1. Could you please elaborate on the benefits of doing this relative to
the use of l2tpv3 signaling.

2. In the VR case, we would only advertise a single Session/Cookie per PE 
(not per PE pair, per VPN, etc). So, for the VR L3VPN case, we can include 
this Session/Cookie in the BGP Next Hop Update allowing it to become part 
of the single adjacency   that gets built for sending all VR VPN traffic over 
L2TPv3/IP to that PE. 

Which is exactly my point - from the BGP-based l2tp signaling
exactly the same procedures are used for both VR and 2547.

Yakov.

---

From: [email-masked]
Date: Thu, 5 Feb 2004 02:13:18 -0000

Mark,

The justification for using L2TP as opposed to IP or GRE encapsulation over an IP PSN seems to be that security is improved. However, from what I understand security in an IP/GRE encapsulated PSN using 2547 is exactly the same as a PSN using MPLS, i.e. security is not an issue and is comparable to FR/ATM. That is unless the same PSN is to be used for carrying Internet traffic (natively, not inside a VPN) and customer VPN traffic, in which case the same security risks apply to MPLS 2547 networks and IP 2547 networks anyway. The inherent problem being that IP the control traffic shares the same data plane as the public Internet traffic, unlike ATM which uses an out-of-band control plane (and is the only sensible solution to the problem, i.e. use reserved labels for control/management traffic in MPLS).

>From an L2 perspective I can see that L2TP could be useful as it is well suited for encapsulating and signalling L2 tunnels. However, I do not see why L2TP is useful for L3 VPNs, why not just use GRE or IP encapsulations, which don't require any signalling? I could maybe understand if a provider was using L2TP for L2 services and wanted to reuse L2Tp for L3 services, but if so, why use BGP signalling why not use L2TP signalling?

Also, I do not agree with the use of the phrase "RFC 2547 Style VPNs", which is used several times within this draft. I would not consider RFC2547 to be a 'style' of VPNs, I would consider RFC2547 to be a specific VPN implementation, just like FR or ATM are specific VPN implantations. Why is the word 'style' used? Why not just say RFC 2547 VPNs?

Richard 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Yakov
> Rekhter
> Sent: 04 February 2004 20:55
> To: W. Mark Townsley
> Cc: [email-masked]; [email-masked]
> Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs 
> 
> 
> Mark,
> 
> > Yakov Rekhter wrote:
> > 
> but also uses BGP to carry the l2tp session and cookie (l2tp signaling
> information). That is, in contrast to 
> draft-ietf-l3vpn-ipsec-2547-01.txt
> your draft does replace the l2tp signaling protocol with BGP, thus
> eliminating the need for l2tp signaling with the l2tp signaling
> protocol.
> 
> took a fairly narrow point of view. This is a bug, not a feature,
> and therefore it should be fixed.
> 
> Second, the restriction on the applicability of your draft to 2547 is
> quite arbitrary. That is, there are *no* technical justifications
> for this restriction. And the fact that some other drafts 
> took a fairly 
> narrow view of the problem is no justification for continuing this.
>