Subject: RE: MPLS vs IP encap in RFC2547

From: [email-masked]
Date: Tue, 10 Feb 2004 07:26:25 -0000

Hi Rajesh,

Agreed, however I do not believe I state anywhere in my original post anything contrary to your comment. 

In my original post I state "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." I use the term filtering loosely to refer to any mechanisms that checks MPLS labels for received packets and drops/forwards the packets accordingly. As you say, this may be a check to ensure that the received packet contains a label that has been announced to the CE.

Regards,

Richard

	-----Original Message----- 
	From: Rajesh Potti [mailto:[email-masked]] 
	Sent: Mon 09/02/2004 14:20 
	To: Jim Guichard 
	Cc: Spencer,R,Richard,XGH5 R; [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 

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

	-- 
	Rajesh Potti.

---

From: [email-masked]
Date: Tue, 10 Feb 2004 11:03:51 -0000

Having thought about it further, I have discovered a flaw in my argument. For an egress PE to correctly process a VPN packet received via IP or IP/GRE encapsulation across an IP/MPLS PSN, the encapsulation method must identify the payload as being an MPLS packet. In the IP encapsulation case this is done using a protocol number field (TBA). In the IP/GRE case, the IP protocol field is used to indicate that the IP packet contains a GRE packet, and the protocol type field in the GRE header is used to indicate that the packet is an MPLS packet. 

The above assumes that the spoofed VPN packet is sent via an interface directly connected to the PE. The reason being that if the PSN is running MPLS, then by default if a P router receives a packet with an IP destination address it has a FEC for then it will forward the packet using an MPLS label. To protect an IP/MPLS network from VPN spoofing using IP instead of MPLS, then the provider could simply filter out and drop any packets that contain MPLS-in-IP or GRE encapsulated packets based on the IP protocol number.

Using brute force an attacker could potentially inject spoofed VPN packets using IP encapsulation with the protocol number set to a number for a valid protocol type to be received over that interface (e.g. SNMP). In which case, the IP header would be replaced with a label and the packet would be switched across the LSP to the destination PE. However, when PHP pops the label from the stack, because the router that received the original IP encapsulated packet will have imposed a label with the bottom of the stack bit set, the remaining packet will be forwarded as an IP packet. When the egress PE receives the packet it will be expecting an IP packet (due to the L2 protocol ID), and will drop it because it will actually receive an MPLS packet, not an IP packet.

The option to filter out potential spoofed VPN packets using the IP protocol number field makes it easier to protect an IP/MPLS RFC2547 network against attack from spoofed VPN IP encapsulated packets. This is not an option in an IP only RFC2547 network as IP encapsulated packets must be forwarded.

Regards,

Richard

-----Original Message----- 
From: [email-masked] on behalf of [email-masked] 
Sent: Mon 09/02/2004 13:48 
To: [email-masked]; [email-masked] 
Cc: 
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.

	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:

	

	

	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: [email-masked]
Date: Wed, 11 Feb 2004 19:25:10 -0000

Hi Marc,

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

My argument was based on the fact that in an IP/MPLS network, VPN packets could potentially be forwarded using MPLS-in-IP/GRE or MPLS label stacking. Therefore at first pass I assumed the spoofing probability was P(MPLS-in-IP/GRE spoof attack) + P(MPLS label stacked spoof attack). However, having thought about it further, even if MPLS-in-IP/GRE was supported by default across an IP/MPLS network, it would be easy to stop MPLS-in-IP spoofing attacks by using IP protocol number filtering.

I now agree with existing IETF drafts that say VPN packet spoofing is easier to protect against in an MPLS PSN than it is in an IP PSN. However, this is based on the fact that 1) MPLS packets received at the edge can be dropped (or their labels checked against distributed labels if the interface supports MPLS), and 2) MPLS-in-IP/GRE packets (if supported) can be dropped by simply filtering on the IP protocol number. As far as I know, the current IETF drafts only mention 1, and not 2. I guess how important 2 is depends on whether router implementations support MPLS-in-IP/GRE by default and therefore IP protocol number filtering is required, or if MPLS-in-IP/GRE support is a feature that providers can simply turn on or off. 

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

Agreed, IP only needs routing protocols whereas MPLS requires routing and signalling protocols, which adds extra complexity. However, using protocols like L2TP in an IP network also increases complexity.  

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

Yes I agree that my original statement was incorrect, as I had not taken into account how easy it would be to block MPLS-in-IP packets in an IP/MPLS network. 

> To spoof into a MPLS VPN from the forwarding plane you need labelled traffic

… or support for MPLS-in-IP/GRE traffic.

Thanks for your comments,

Richard

---

From: [email-masked]
Date: Thu, 12 Feb 2004 05:11:00 -0000

Hi Jim,
 
> Hi Richard - my basic point is that labelled packets cannot be sent 
> into a PSN that is either IP or MPLS enabled. So, if an attacker knows 
> all the relevant label information then how can it get its packets from 
> an IP network onto an MPLS network ?
 
Regarding the sending of labelled packets into an MPLS PSN, I was thinking of the inter-provider case where a PSN may receive labelled packets from another provider. I agree that labelled packets cannot normally be sent into a PSN, i.e. by a CE.
 
> if the answer is that it can't then I would argue that the MPLS 
> infrastructure is more secure, not less. If you contrast that with an 
> IP network then if an attacker can obtain all the relevant IP 
> information then all they need to do is put the right encapsulation 
> onto the packet and they may attack the VPN - Jim
 
I now agree with you that the VPN data plane is more secure in a MPLS PSN than it is in an IP PSN. The reasons being that 1) any labelled packets received from a CE can simply be dropped, 2) any labelled packets received from another provider can have their labels checked against a list of valid labels distributed by the PE to that provider, and 3) MPLS-in-IP/GRE packets (if supported) can be dropped by turning the feature off or by filtering based on IP protocol numbers.

Richard