Subject: MPLS vs IP encap in RFC2547

From: [email-masked]
Date: Mon, 9 Feb 2004 18:48:18 -0000

It has been asserted on this mailing list and in a couple of IETF drafts, that using IP encapsulation techniques across a PSN instead of MPLS for RFC2547 make it more difficult to protect VPNs against spoofed attacks.

I would like to challenge this assertion, as I believe that using IP encapsulation in the PSN instead of MPLS actually makes it easier to protect against spoofed VPN attacks. I am not a security expert so I welcome any comments that explain where my argument falls down. 

My argument is based on the fact that that MPLS networks can forward VPN packets based on IP or MPLS (PHP is a good example of this), and hence 'IP/MPLS' networks inherit the security risks associated with both IP and MPLS forwarding. 

Fundamentally, this argument comes back to the fact that IP/MPLS networks today use the same address space for control plane traffic that they use for forwarding VPN packets in the data plane, i.e. /32 loopback addresses that are used for LDP/BGP sessions are also used as PE next hops for VPN packets. As stated previously, one solution to the problem is to use filtering; another is to use an OOB control plane.

If an attacker is able to initiate an attack from within the service provider network then the security risks associated with IP/MPLS networks are comparable to other VPN technologies such as ATM/FR. If however an attacker attempts to initiate an attack from outside the provider network, then the security risks in an IP/MPLS network are dependant on which routing instance the interface connects to, i.e. a customer VRF or the global routing table.

To provide justification for this argument, I will examine 3 points of entry into the network where a spoofing attempt might take place.

1. Via a legitimate non-core facing managed interface at the edge of the provider network.

a) If the interface belongs to a VPN, then the VRF it belongs to will only contain routes belonging to that particular VPN. This would most likely be a customer-facing interface.

If a packet is received with an address/label that belongs to a different VPN or to the provider network, then the packet will be dropped because a route to the destination will not exist (i.e. route isolation is enforced). This is independent of whatever encapsulation method (IP/GRE, MPLS) is used within the PSN.

b) If the interface belongs to the service provider global routing table, then the routing table will contain IGP routes, and may contain Internet routes. This would most likely be an interface facing the Internet or another AS/provider to support inter-AS/provider VPNs.

In order to protect against IP packet spoofing, ingress filtering must be applied on the interface. This is independent of whatever encapsulation method is used within the PSN. This is a key point, a network running MPLS in the core can still forward packets based on IP addresses it receives at the edge (assuming IP is running on interfaces at the edge).

If MPLS labelled packets are received on an interface but MPLS is not enabled, then they should be dropped. This is independent of whatever encapsulation is used across the PSN.

If the PSN is using MPLS in the core, and MPLS is enabled on the interface then filtering needs be used to drop spoofed MPLS packets. This is in addition to the filtering required to protect against spoofed IP packets.

2. Via an illegal attack from a router interface within the provider network by an intruder

i) If an intruder has gained access to a router interface within the provider network (edge or core), the intruder may also be able to lookup routing/label information. If so, then the intruder can use this information to carry out a VPN packet spoofing attack. This is independent of whatever encapsulation is used across the PSN.

ii) If an intruder gains access to a router interface within the provider network but cannot acquire routing/label information, then brute force techniques must be used to spoof packets. In order to spoof a VPN packet, an attacker must determine the correct PSN label/IP destination addresses AND the correct VPN label. If the PSN label/address is not valid, the first PE/P router that receives the packet will drop it. If the PSN label/address is correct but the VPN label is incorrect, then the packet will be dropped by the egress PE.

If the PSN supports IP only, then the probability of spoofing success is based on:

P(PSN destination IP address) x P(VPN label)

If the PSN supports IP/MPLS forwarding then the probability is based on:

P(PSN destination IP address) x P(VPN label) OR

P(PSN label) x P(VPN label)

Regardless of what the actual probabilities are, the probability of a successful VPN packet spoof attack will always greater than an IP only network. This is because packets can be forwarded using IP destination addresses OR MPLS labels.

3. Via an illegal attack from an intruder that has tapped into a physical link within the provider network

i) If an intruder has tapped into a physical link then it is likely that they are able to snoop MPLS/IP packets to determine what labels or IP addresses are being used. If so, then the intruder can use this information to carry out a VPN packet spoofing attack. This is independent of whatever encapsulation is used across the PSN.

ii) If an intruder has gained access to a physical link and for whatever reason can only transmit packets, then brute force techniques must be applied as described in 2 ii).

In both 2 and 3, the only way to protect against this type of attack is to use ensure physical network protection and to use encryption/authentication. The point being that to protect against these types of attack, these security measures must be taken regardless of whether the PSN is IP or IP/MPLS.

As I say, admittedly I'm not a security expert so I welcome any comments that explain why my arguments are incorrect.

Richard

---

From: "Jim Guichard" <[email-masked]>
Date: Mon, 9 Feb 2004 14:01:40 -0500

Hi Richard,

if the intruder is sat on an IP network, even if they gain access to a provider router and assertain the relevant label information for a given destination, how can they get the labelled packet into the provider core, assuming that an interface that is NOT enabled for MPLS switching receives the incoming packets ? Jim

> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]On Behalf Of
> >[email-masked]
> >Sent: Monday, February 09, 2004 1:48 PM
> >To: [email-masked]; [email-masked]
> >Subject: MPLS vs IP encap in RFC2547
> >
> >
> >It has been asserted on this mailing list and in a couple of 
> >IETF drafts, that using IP encapsulation techniques across a PSN 
> >instead of MPLS for RFC2547 make it more difficult to protect 
> >VPNs against spoofed attacks.
> >
> > 
> >
> >I would like to challenge this assertion, as I believe that 
> >using IP encapsulation in the PSN instead of MPLS actually makes 
> >it easier to protect against spoofed VPN attacks. I am not a 
> >security expert so I welcome any comments that explain where my 
> >argument falls down. 
> >
> > 
> >
> >My argument is based on the fact that that MPLS networks can 
> >forward VPN packets based on IP or MPLS (PHP is a good example 
> >of this), and hence 'IP/MPLS' networks inherit the security 
> >risks associated with both IP and MPLS forwarding. 
> >
> > 
> >
> >Fundamentally, this argument comes back to the fact that IP/MPLS 
> >networks today use the same address space for control plane 
> >traffic that they use for forwarding VPN packets in the data 
> >plane, i.e. /32 loopback addresses that are used for LDP/BGP 
> >sessions are also used as PE next hops for VPN packets. As 
> >stated previously, one solution to the problem is to use 
> >filtering; another is to use an OOB control plane.
> >
> > 
> >
> >If an attacker is able to initiate an attack from within the 
> >service provider network then the security risks associated with 
> >IP/MPLS networks are comparable to other VPN technologies such 
> >as ATM/FR. If however an attacker attempts to initiate an attack 
> >from outside the provider network, then the security risks in an 
> >IP/MPLS network are dependant on which routing instance the 
> >interface connects to, i.e. a customer VRF or the global routing table.
> >
> > 
> >
> >To provide justification for this argument, I will examine 3 
> >points of entry into the network where a spoofing attempt might 
> >take place.
> >
> > 
> >
> >a) If the interface belongs to a VPN, then the VRF it belongs to 
> >will only contain routes belonging to that particular VPN. This 
> >would most likely be a customer-facing interface.
> >
> > 
> >
> >If a packet is received with an address/label that belongs to a 
> >different VPN or to the provider network, then the packet will 
> >be dropped because a route to the destination will not exist 
> >(i.e. route isolation is enforced). This is independent of 
> >whatever encapsulation method (IP/GRE, MPLS) is used within the PSN.
> >
> > 
> >
> >b) If the interface belongs to the service provider global 
> >routing table, then the routing table will contain IGP routes, 
> >and may contain Internet routes. This would most likely be an 
> >interface facing the Internet or another AS/provider to support 
> >inter-AS/provider VPNs.
> >
> > 
> >
> >In order to protect against IP packet spoofing, ingress 
> >filtering must be applied on the interface. This is independent 
> >of whatever encapsulation method is used within the PSN. This is 
> >a key point, a network running MPLS in the core can still 
> >forward packets based on IP addresses it receives at the edge 
> >(assuming IP is running on interfaces at the edge).
> >
> > 
> >
> >If MPLS labelled packets are received on an interface but MPLS 
> >is not enabled, then they should be dropped. This is independent 
> >of whatever encapsulation is used across the PSN.
> >
> > 
> >
> >If the PSN is using MPLS in the core, and MPLS is enabled on the 
> >interface then filtering needs be used to drop spoofed MPLS 
> >packets. This is in addition to the filtering required to 
> >protect against spoofed IP packets.
> >
> > 
> >
> >i) If an intruder has gained access to a router interface within 
> >the provider network (edge or core), the intruder may also be 
> >able to lookup routing/label information. If so, then the 
> >intruder can use this information to carry out a VPN packet 
> >spoofing attack. This is independent of whatever encapsulation 
> >is used across the PSN.
> >
> > 
> >
> >ii) If an intruder gains access to a router interface within the 
> >provider network but cannot acquire routing/label information, 
> >then brute force techniques must be used to spoof packets. In 
> >order to spoof a VPN packet, an attacker must determine the 
> >correct PSN label/IP destination addresses AND the correct VPN 
> >label. If the PSN label/address is not valid, the first PE/P 
> >router that receives the packet will drop it. If the PSN 
> >label/address is correct but the VPN label is incorrect, then 
> >the packet will be dropped by the egress PE.
> >
> > 
> >
> >Regardless of what the actual probabilities are, the probability 
> >of a successful VPN packet spoof attack will always greater than 
> >an IP only network. This is because packets can be forwarded 
> >using IP destination addresses OR MPLS labels.
> >
> > 
> >
> >3. Via an illegal attack from an intruder that has tapped into a 
> >physical link within the provider network
> >
> > 
> >
> >i) If an intruder has tapped into a physical link then it is 
> >likely that they are able to snoop MPLS/IP packets to determine 
> >what labels or IP addresses are being used. If so, then the 
> >intruder can use this information to carry out a VPN packet 
> >spoofing attack. This is independent of whatever encapsulation 
> >is used across the PSN.
> >
> > 
> >
> >ii) If an intruder has gained access to a physical link and for 
> >whatever reason can only transmit packets, then brute force 
> >techniques must be applied as described in 2 ii).
> >
> > 
> >
> >In both 2 and 3, the only way to protect against this type of 
> >attack is to use ensure physical network protection and to use 
> >encryption/authentication. The point being that to protect 
> >against these types of attack, these security measures must be 
> >taken regardless of whether the PSN is IP or IP/MPLS.
> >
> > 
> >
> >As I say, admittedly I'm not a security expert so I welcome any 
> >comments that explain why my arguments are incorrect.
> >
> > 
> >
> >Richard
> >

---

From: Rajesh Potti <[email-masked]>
Date: Mon, 09 Feb 2004 14:20:12 -0500

Hi Richard,

 When a PE receives a packet from the CE, PEalso checks to make sure, it comes with a label, that it has announced to the CE.
 If PE did not announce that label to the CE, the packet is dropped.

Rajesh

--
Rajesh Potti.

---

From: "Jim Guichard" <[email-masked]>
Date: Mon, 9 Feb 2004 14:15:33 -0500

if the interface is an IP interface (e.g. MPLS forwarding is not enabled)
then the router should drop ALL labelled packets - Jim
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]
  Sent: Monday, February 09, 2004 2:20 PM
  To: Jim Guichard
  Cc: [email-masked]; [email-masked]; [email-masked]
  Subject: Re: MPLS vs IP encap in RFC2547

  Hi Richard,
   When a PE receives a packet from the CE, PEalso checks to make sure, it
comes with a label, that it has announced to the CE.
   If PE did not announce that label to the CE, the packet is dropped.

  Rajesh

  Jim Guichard wrote:

    Hi Richard,
    if the intruder is sat on an IP network, even if they gain access to a
provider router and assertain the relevant label information for a given
destination, how can they get the labelled packet into the provider core,
assuming that an interface that is NOT enabled for MPLS switching receives
the incoming packets ? Jim

--
Rajesh Potti.

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 10 Feb 2004 11:35:41 +0100

Hello Richard,

maybe I'm missing something but from what you say I can't see the 
"spoof probability is higher for MPLS than for IP encapsulation". Looks 
more like a "not much difference" for me.

The overall complexity of the MPLS control plane is larger than for 
native IP due to additional protocols like LDP and RSVP. The challenge 
to protect these protocols is similar to a native IP network and the 
protection mechanism are identical, e.g. MD5 hashing, infrastructure 
ACL  and so on. With more protocols in place it is probably easier to 
disturb the MPLS service.

On the forwarding plane I would rate MPLS as safer than IP 
encapsulation. In an ideal world it should be the same but the 
situation is more complex for IP-encapsulation. VPN ports (unless for 
CsC) and "Internet" ports are native IP ports and a router can simply 
drop labeled packets. And for CsC customers only advertised labels (in 
the particular VRF context) are accepted. One may compare this to uRPF 
for IP - but this feature is not always available or the performance 
makes it impractical to use. As a result address spoofing is likely to 
be possible - and any scheme like GRE is at risk.

Stated less technically: for VPNs based on IP encapsulation the 
customer is closer to the VPN implementation as s/he talks IP too. It's 
mainly the global Internet ports causing the problem.

There is one scenario in the MPLS world which is similar: InterAS "type 
b" and "type c" interconnects where a port in global routing accepts 
labeled traffic.

I disagree with your statement that in an IP/MPLS network both option 
are available, forwarding based on IP and on MPLS and thus the overall 
risk is the sum of both. To spoof into a MPLS VPN from the forwarding 
plane you need labeled traffic - try to send some data to 10.1.2.3 
while on a core router ;-)

Regards, Marc

On Feb 9, 2004, at 7:48 PM, [email-masked] wrote:

> It has been asserted on this mailing list and in a couple of IETF 
> drafts, that using IP encapsulation techniques across a PSN instead of 
> MPLS for RFC2547 make it more difficult to protect VPNs against 
> spoofed attacks.
>
>
>
> I would like to challenge this assertion, as I believe that using IP 
> encapsulation in the PSN instead of MPLS actually makes it easier to 
> protect against spoofed VPN attacks. I am not a security expert so I 
> welcome any comments that explain where my argument falls down.
>
>
>
> My argument is based on the fact that that MPLS networks can forward 
> VPN packets based on IP or MPLS (PHP is a good example of this), and 
> hence 'IP/MPLS' networks inherit the security risks associated with 
> both IP and MPLS forwarding.
>
>
>
> networks today use the same address space for control plane traffic 
> that they use for forwarding VPN packets in the data plane, i.e. /32 
> loopback addresses that are used for LDP/BGP sessions are also used as 
> PE next hops for VPN packets. As stated previously, one solution to 
> the problem is to use filtering; another is to use an OOB control 
> plane.
>
>
>
> If an attacker is able to initiate an attack from within the service 
> provider network then the security risks associated with IP/MPLS 
> networks are comparable to other VPN technologies such as ATM/FR. If 
> however an attacker attempts to initiate an attack from outside the 
> provider network, then the security risks in an IP/MPLS network are 
> dependant on which routing instance the interface connects to, i.e. a 
> customer VRF or the global routing table.
>
>
>
> To provide justification for this argument, I will examine 3 points of 
> entry into the network where a spoofing attempt might take place.
>
>
>
> a) If the interface belongs to a VPN, then the VRF it belongs to will 
> only contain routes belonging to that particular VPN. This would most 
> likely be a customer-facing interface.
>
>
>
> different VPN or to the provider network, then the packet will be 
> dropped because a route to the destination will not exist (i.e. route 
> isolation is enforced). This is independent of whatever encapsulation 
> method (IP/GRE, MPLS) is used within the PSN.
>
>
>
> b) If the interface belongs to the service provider global routing 
> table, then the routing table will contain IGP routes, and may contain 
> Internet routes. This would most likely be an interface facing the 
> Internet or another AS/provider to support inter-AS/provider VPNs.
>
>
>
> In order to protect against IP packet spoofing, ingress filtering must 
> be applied on the interface. This is independent of whatever 
> encapsulation method is used within the PSN. This is a key point, a 
> network running MPLS in the core can still forward packets based on IP 
> addresses it receives at the edge (assuming IP is running on 
> interfaces at the edge).
>
>
>
> If MPLS labelled packets are received on an interface but MPLS is not 
> enabled, then they should be dropped. This is independent of whatever 
> encapsulation is used across the PSN.
>
>
>
> interface then filtering needs be used to drop spoofed MPLS packets. 
> This is in addition to the filtering required to protect against 
> spoofed IP packets.
>
>
>
> i) If an intruder has gained access to a router interface within the 
> provider network (edge or core), the intruder may also be able to 
> lookup routing/label information. If so, then the intruder can use 
> this information to carry out a VPN packet spoofing attack. This is 
> independent of whatever encapsulation is used across the PSN.
>
>
>
> provider network but cannot acquire routing/label information, then 
> brute force techniques must be used to spoof packets. In order to 
> spoof a VPN packet, an attacker must determine the correct PSN 
> label/IP destination addresses AND the correct VPN label. If the PSN 
> label/address is not valid, the first PE/P router that receives the 
> packet will drop it. If the PSN label/address is correct but the VPN 
> label is incorrect, then the packet will be dropped by the egress PE.
>
>
>
> Regardless of what the actual probabilities are, the probability of a 
> successful VPN packet spoof attack will always greater than an IP only 
> network. This is because packets can be forwarded using IP destination 
> addresses OR MPLS labels.
>
>
>
> i) If an intruder has tapped into a physical link then it is likely 
> that they are able to snoop MPLS/IP packets to determine what labels 
> or IP addresses are being used. If so, then the intruder can use this 
> information to carry out a VPN packet spoofing attack. This is 
> independent of whatever encapsulation is used across the PSN.
>
>
>
> whatever reason can only transmit packets, then brute force techniques 
> must be applied as described in 2 ii).
>
>
>
> In both 2 and 3, the only way to protect against this type of attack 
> is to use ensure physical network protection and to use 
> encryption/authentication. The point being that to protect against 
> these types of attack, these security measures must be taken 
> regardless of whether the PSN is IP or IP/MPLS.
>
>
>
--
Marc Binderberger    <[email-masked]>    Powered by *BSD ;-)