The MPLS WG Archive

[richard.spencer@bt.com]

Hi Jim,

 

Thanks for you comment, I am not sure which specific scenario you are referring to, can you elaborate as to which point(s) of entry you are referring to, what the PSN type is and what type of packets (IP or MPLS) are being received by the interface?

 

Are you asking even if an intruder learns label information for a given destination, how can packets be sent to an interface that does not have MPLS enabled? If this is what you are asking then I agree that they can't. As I stated in my original message "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."

 

However, I may be misinterpreting what you are saying.

 

Richard 

	-----Original Message----- 
	From: Jim Guichard [mailto:jguichar@cisco.com] 
	Sent: Mon 09/02/2004 14:01 
	To: Spencer,R,Richard,XGH5 R; l3vpn@ietf.org; mpls@UU.NET 
	Cc: 
	Subject: RE: MPLS vs IP encap in RFC2547
	
	

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