The MPLS WG Archive

[richard.spencer@bt.com]

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: l3vpn-admin@ietf.org on behalf of richard.spencer@bt.com 
Sent: Mon 09/02/2004 13:48 
To: l3vpn@ietf.org; mpls@UU.NET 
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:
	
	
	
	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