The MPLS WG Archive

[Marc Binderberger <marc@sniff.de>]

Hello Richard,

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.


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.

On the forwarding plane I would rate MPLS as safer than IP 
encapsulation. In an ideal world it should be the same but the 
situation is more complex for IP-encapsulation. VPN ports (unless for 
CsC) and "Internet" ports are native IP ports and a router can simply 
drop labeled packets. And for CsC customers only advertised labels (in 
the particular VRF context) are accepted. One may compare this to uRPF 
for IP - but this feature is not always available or the performance 
makes it impractical to use. As a result address spoofing is likely to 
be possible - and any scheme like GRE is at risk.

Stated less technically: for VPNs based on IP encapsulation the 
customer is closer to the VPN implementation as s/he talks IP too. It's 
mainly the global Internet ports causing the problem.

There is one scenario in the MPLS world which is similar: InterAS "type 
b" and "type c" interconnects where a port in global routing accepts 
labeled traffic.


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. To spoof into a MPLS VPN from the forwarding 
plane you need labeled traffic - try to send some data to 10.1.2.3 
while on a core router ;-)


Regards, Marc





On Feb 9, 2004, at 7:48 PM, richard.spencer@bt.com wrote:

> 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
>
>
--
Marc Binderberger    <marc@sniff.de>    Powered by *BSD ;-)