The MPLS WG Archive

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

if the interface is an IP interface (e.g. MPLS forwarding is not enabled) then the router should drop ALL labelled packets - Jim

-----Original Message-----
From: rpotti@nortelnetworks.com [mailto:rpotti@nortelnetworks.com]
Sent: Monday, February 09, 2004 2:20 PM
To: Jim Guichard
Cc: richard.spencer@bt.com; 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.