The MPLS WG Archive

[richard.spencer@bt.com]

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:rpotti@nortelnetworks.com] 
	Sent: Mon 09/02/2004 14:20 
	To: Jim Guichard 
	Cc: Spencer,R,Richard,XGH5 R; l3vpn@ietf.org; mpls@UU.NET 
	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: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of 
		> >richard.spencer@bt.com 
		> >Sent: Monday, February 09, 2004 1:48 PM 
		> >To: l3vpn@ietf.org; mpls@UU.NET 
		> >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.