The MPLS WG Archive

["Jim Guichard" <jguichar@cisco.com>]

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