[spoofing-tf] HOWTO draft
-
From: "Juan P. Cerezo" juampe@localhost
-
Date: Wed, 13 Sep 2006 17:21:48 +0200
Hi there.
This is the draft of the Anti-Spoofing Howto document, to be
discussed on the list.
There are some items to be filled yet, but people can start to
comment on what's been written up to now.
Saludos/regards
--
mailto: `echo NjuOampSe@localhost | sed 's/[NOSPAM]//g'`
--
-----------------------------------------------------------------
RIPE Anti-Spoofing Task Force.
HOW-TO and Experiences Document
Editors: Fernando García (Eurocomercial) and Juan P. Cerezo (BT GS)
0. INDEX
RIPE ANTI-SPOOFING TASK FORCE. 1
HOW-TO AND EXPERIENCES DOCUMENT 1
0. INDEX 1
1. INTRODUCTION 2
2. OVERVIEW 2
3. DEFINITIONS 2
4. COMMON ASPECTS RELATED TO IP NETWORKING 2
4.1. COMMON INTERNETWORKING HAZARDS 2
4.2. IP MECHANISMS INVOLVED 2
4.2.1. Filtering prefixes 2
4.2.2. Reverse Path Forwarding (RPF) mechanism(s) 2
4.2.3. Other filters. BOGON networks filtering 2
5. VENDOR SPECIFICS 3
5.1. CISCO FEATURES 3
5.1.1. Basic (independent of IOS version) features 3
5.1.2. IOS Dependent Features 3
5.1.3. Caveats and IOS related problems 3
5.2. JUNIPER FEATURES 3
5.2.1. Basic JUNOS features 3
5.2.2. Advanced (JunOS dependant) features 3
5.3. OTHER'S FEATURES (NORTEL, FORCE10, HUAWEI, ETC.) 3
5.3.1. NORTEL 3
5.3.2. FORCE10 3
5.3.3. HUAWEI 3
6. SCENARIOS 3
6.1. CUSTOMER/PROVIDER SCENARIOS 3
6.1.1. Single router, single provider 3
6.1.2. Multiple routers, single provider 4
6.1.3. Single Router, multiple providers 9
6.1.4. Multiple routers, multiple providers 10
6.1.5. Customers access networks 11
6.1.6. Other Special Cases 11
6.2. CARRIERS 11
6.2.1. DFZ routers 11
6.2.2. Customer aggregation routers 11
6.3. INTERACTION WITH SPECIAL MECHANISMS 11
6.4. MULTICAST ENABLED NETWORKS 11
6.5. NETWORKS WITH MPLS ENABLED 12
7. IPV6 APPLICABILITY 12
8. REFERENCES 12
1. Introduction
2. Overview
3. Definitions
CPE: Customer Premises Equipment. A router placed in a end user office
and that connect both the end user network and to the provider network
usually throuh a point-to-point link
PE: Provider Edge. A router located in the provider network that connect
directly with one or several CPEs..
4. Common aspects related to IP networking
4.1. Common Internetworking Hazards
- DDoS attacks
- Hijacking computers
- Hijacking services
4.2. IP mechanisms involved
4.2.1. Filtering prefixes
- Why to filter:
The increasing number and danger of security incidents that use spoofed
IP address suggests that performing some level of control over the
correctness of the source IP address of the packets that conform the
Internet traffic can mitigate the impact of the attacks on the
infrastructure.
- What to filter
Basically, IP traffic with a source address belonging to prefixes that
should not be on the routing table of routers connected to (or that
forward traffic from/to) the public Internet. The most common
characterization of these prefixes is the so-called Bogon Prefixes[1].
- Where to filter
On the IP hosts (if the TCP/IP stack implements this option), on the
customer (CPE) routers, on the ISP infrastructure equipment (access
routers and concentrators, DFZ routers). Applying filters the
nearest to
the origination of the spoofed traffic, the better the effects (on the
security and reliability of the hosts and the network) will be.
4.2.2. Reverse Path Forwarding (RPF) mechanism(s)
- Strict uRPF [2]: It's a mechanism by means of which the source addres
of the packet received on an interface is looked up in the forwarding
table of the router. If the source address is reachable through the same
interface on which the packet was received, the packet will be processed
by the router.
- Feasible Path uRPF [2]: A variant of the strict uRPF that works on
routing implementations on which not only the best route, but also
alternative paths (e.g., a router advertisements that are keep in the
BGP
FIB but are not the best route), are accepted as successful paths to the
source address of the packet. Feasible is a superset of active paths,
and
works also in asymmetric and multihomed scenarios.
- Loose uRPF [2]: In this mechanism only the existence of a route to the
source address in the forwarding table (even if it is a default
route) is
checked to forward or drop the packet.
(A variant of the last mechanism includes ignoring the existence of
default routes in the forwarding table).
The conditions on which these mechanisms are applicable is complex, but
at first approximation can be summarized by:
-
- Networks that apply Stric uRPF will keep directionality on
his network announcements, so asymmetric routing will not
work. The mechanism can be problematic in peering routers
that exchange routes with other ISPs ("hot potato" routing,
BGP filtering in both senses of the peering due to different
routing policies) or in Data Centers on which hosts are
connected to redundant router LANs.
-
- Loose uRPF applied to interfaces in border routers will
allow asymmetric routing but will limit the automatic
"pseudo-filtering" benefits of uRPF to private (RFC 1918)
and unroutable ("bogon") IP addresses [3].
4.2.3. Other filters. BOGON networks filtering
- What are BOGONs
A BOGON prefix as defined by Cymru [1] is "a route that should
never appear in the Internet routing table. A packet routed over
the public Internet (not including over VPN or other tunnels)
should never have a source address in a bogon range. These are
commonly found as the source addresses of DDoS attacks."
For the purpose of this HowTo a BOGON in an interface of a router
is any address that enters the router through that interface and
that legally shouldn't enter the router through that interface.
As the same documents indicates, this definition includes "martian"
addresses, as defined in RFC1918 and RFC3330 and netblocks of
public address that hasn't been allocated from the IANA to the
RIRs.
Also in this case are included the address that topologically ares
located always and in any situation in networks connected to other
ports of the router.
- Why to filter them
The document of the Cymru states that in some measurements up to
60% of the IP addresses used in attacks employ BOGONs addressing.
Filtering these addresses will reduce the impact of this attacks at
a great level.
- How to build the filters
There are two basic approaches:
In interfaces open to Internet, the simplest way is create a list
of denied networks and filter out that networks.
In interfaces open to internal networks –a reduced set of networks
with public and/or private addressing– usually is easier to create
a list of allowed networks and filter in that networks, rejecting
those that not match.
In the first case the netwoks list has a static part and a dynamic
part: the static part is the martians list defined previously and
the static networks inside the organisation. The dynamic part are,
at least, the list of valid addresses that are not allocated from
the IANA to the RIRs (but will be allocated in the future, so the
dynamic nature of this list).
5. Vendor specifics
5.1. CISCO features
5.1.1. Basic (independent of IOS version) features
5.1.2. IOS Dependent Features
5.1.3. Caveats and IOS related problems
5.2. Juniper Features
5.2.1. Basic JUNOS features
5.2.2. Advanced (JunOS dependant) features
5.3. Other's Features (NORTEL, FORCE10, HUAWEI, etc.)
5.3.1. NORTEL
5.3.2. FORCE10
5.3.3. HUAWEI
6. Scenarios
All the scenarios described focuses on the functionality of each router.
This determines what will be the generic filtering configuration to be
applied on each router.
6.1. Customer/provider scenarios
In these cases, there will be a clear separation between recommendations
for customer routers, and for the provider routers
6.1.1. Single router, single provider
There will be always a single link between customer and provider's
access
router, normally using /30 or /31 range from the provider PA range. In
many cases there will be a public addressing subnet assigned to the
client (From the PA range allocated to the provider), but some solutions
employ NAT with the CPE point to point address and an all private
addressing schema.
Routing between customer and provider in this scenario is static and
manually coded in the routers configuration.
In both cases you can filter manually with an access list and/or let the
router do it automatically using Unicast Reverse Path Forwarding. The
first method can be more precise but requires more time to maintain (a
big burden in the provider side) and is a significant load for the
router. It's not recommended if the link speed is over one
megabit/second. But if you implement this access list, the user of uRPF
is mostly redundant.
• Customer router (CPE)
ip cef
interface ATM0/1.1 point-to-point
description Interface to provider
ip address 89.107.53.1 255.255.255.254
¡ We filter packets based on a static list
ip access-group bogons in
¡ We also can use strict uRPF
¡ Thought it's redundant in this case
ip verify unicast reachable-via rx allow-default
[...]
¡ Route to Internet
ip route 0.0.0.0 0.0.0.0 ATM0/1.1
[...]
¡ Static networks to filter
¡ private and reserved networks are rejected
ip access-list extended bogons
deny ip 10.0.0.0 0.255.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 169.254.0.0 0.0.255.255 any
deny ip 192.0.2.0 0.0.0.255 any
deny ip 198.18.0.0 0.1.255.255 any
deny ip 224.0.0.0 15.255.255.255 any
deny ip 240.0.0.0 15.255.255.255 any
¡ If we have a public range assigned, we can't receive
¡ those address from the outside
deny ip 89.107.52.0 0.0.0.255 any
¡ our router external address
deny ip 89.107.53.1 0.0.0.0 any
permit ip any any
• Provider router (PE)
ip cef
interface ATM0/1.1 point-to-point
description Interface to customer
ip address 89.107.53.0 255.255.255.254
¡ static filter based on customer public addresing.
¡ This is a simple filter
ip access-group customer-routes in
¡ Here wa can also use strict uRPF.
¡ We don't use the allow-default option of uprf
¡ because customer link shouldn't be the default route
ip verify unicast reachable-via rx
[...]
! Static networks to filter
!
ip access-list extended customer-routes
¡ Here we do the opposite of the CPE
¡ we deny everything except customer public address
! Public address of the CPE router
permit ip 89.107.53.1 0.0.0.0 any
! If the customer has a public range assigned, allow it
permit ip 89.107.52.0 0.0.0.255 any
deny ip any any
6.1.2. Multiple routers, single provider
6.1.2.1 Redundant
- Scenario with 2+ routers connected to a single access router: each
route between customer and provider routers will be static and will have
different metrics in each path with one path being the default active in
both ways and the other the default passive in both ways. It's important
to use the same kind of metrics in both sides. If one side uses one path
as "best" and the other side use the other one, filters using uRPF won't
work and there will be no traffic routed between them.
Each router has a link between customer and provider's access router,
normally using /30 or /31 range from the provider PA range. The customer
will a have public range from the PA range allocated to the provider.
The CPEs usually have VRRP between them, with more weight in the CPE
with
the best link and linked to the physical interface to the provider. The
CPEs have two default routes, one through it's link to the customer and
another through the other router with a worse weight.
In the PE, there are routes to the customer network through both links,
with a better weight in the preferred link.
+----------+
| Provider |
| router |
++--------++
| |
+---------++ ++---------+
| Customer | | Customer |
| router A | | router B |
+--------+-+ +---+------+
| |
| |
| -------- |
|// \\|
/| \\
|| ||
| cutomer |
| network |
|| ||
\\ //
\\ //
--------
In each customer router we can implement the same filtering that was
described for single router, single provider scenario. We setup the
filter list only in the input from the other network, we don't filter in
the input from our network.
uRPF is also used in strict mode.
• Filters on customer router (CPE)
¡ ROUTER CUSTOMER A
¡ CEF is needed for uRPF
ip cef
interface ATM0/1.1 point-to-point
description Interface to provider
ip address 89.107.53.1 255.255.255.254
¡ static filtering
ip access-group bogons in
¡ estrict uRPF through this link
ip verify unicast reachable-via rx allow-default
[...]
ip route 0.0.0.0 0.0.0.0 ATM0/1.1 10
ip route 0.0.0.0 0.0.0.0 89.107.52.3 20
[...]
¡ Static networks to filter
ip access-list extended bogons
deny ip 10.0.0.0 0.255.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 169.254.0.0 0.0.255.255 any
deny ip 192.0.2.0 0.0.0.255 any
deny ip 198.18.0.0 0.1.255.255 any
deny ip 224.0.0.0 15.255.255.255 any
deny ip 240.0.0.0 15.255.255.255 any
¡ router external interface
deny ip 89.107.53.1 0.0.0.0 any
¡ Public addresing range of customer
deny ip 89.107.52.0 0.0.0.255 any
permit ip any any
…
interface FastEthernet0/0
ip address 89.107.52.2 255.255.255.0
standby 1 ip 89.107.52.1
standby 1 preempt
standby 1 priority 150
standby 1 track ATM0/1.1
¡ ROUTER CUSTOMER B
¡ CEF is needed for uRPF
ip cef
interface ATM0/1.1 point-to-point
description Interface to provider
ip address 89.107.53.3 255.255.255.254
¡ static filtering
ip access-group bogons in
¡ estrict uRPF through this link
ip verify unicast reachable-via rx allow-default
[...]
ip route 0.0.0.0 0.0.0.0 ATM0/1.1
[...]
¡ Static networks to filter
ip access-list extended bogons
deny ip 10.0.0.0 0.255.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 169.254.0.0 0.0.255.255 any
deny ip 192.0.2.0 0.0.0.255 any
deny ip 198.18.0.0 0.1.255.255 any
deny ip 224.0.0.0 15.255.255.255 any
deny ip 240.0.0.0 15.255.255.255 any
¡ router external interface
deny ip 89.107.53.3 0.0.0.0 any
¡ Public addresing range of customer
deny ip 89.107.52.0 0.0.0.255 any
permit ip any any
[…]
interface FastEthernet0/0
ip address 89.107.52.3 255.255.255.0
standby 1 ip 89.107.52.1
standby 1 preempt
standby 1 priority 75
standby 1 track ATM0/1.1
Filters on provider router (PE). We filter only in each
input from the customer
! cef is needed for uRPF
ip cef
interface ATM0/1.1 point-to-point
description Interface to customer
ip address 89.107.53.0 255.255.255.254
¡ static filtering
ip access-group customer-routes in
¡ uRPF filtering
ip verify unicast reachable-via rx
[...]
interface ATM0/2.1 point-to-point
description Interface to customer
ip address 89.107.53.2 255.255.255.254
¡ static filtering
ip access-group 102 in
¡ uRPF filtering
ip verify unicast reachable-via rx
[...]
ip route 89.107.52.0 255.255.255.0 ATM0/1.1 10
ip route 89.107.52.0 255.255.255.0 ATM0/2.1 20
¡ Static networks to filter
¡ Public address of the CPE router
ip access-list extended customer-routes
permit ip 89.107.53.1 0.0.0.0 any
¡ If the customer has a public range assigned, allow it
permit ip 89.107.52.0 0.0.0.255 any
deny ip any any
- Scenario with 2+ routers connected to different access routers of the
same provider:
---------
/// \\\
// \\
// \\
| |
| Provider |
| network |
| |
| |
\| //
|\ //
| \\\ ///|
| --------- |
| |
| |
+---------+-+ +-+---------+
|Provider | |Provider |
|router A | |router B |
| | | |
+-----+-----+ +----+------+
| |
| |
+-----+-----+ +----+------+
|Customer | |Customer |
|router A | |router B |
| | | |
+----------++ +--+--------+
| |
| |
| --------- |
|// \ |
/| \|
| Customer |
| network |
| |
\\ //
\\ //
---------
This scenario is similar to the previous one in the customer side and we
won't repeat it here.
In the provider side you can use some floating IP mechanism like the one
described for the customer in the previous scenario(HSRP, VRRP).
A more common scenario for the provider is the use of a dynamic routing
protocol inside its network and use it to announce the customer networks
internally. Two weights are used, one higher through the preferred link
and the second lower through the other link.
Though both scenarios are diferent at a routing level, are similar as
seen from the spoofing security level; similar static filters can be
used
and strict uRPF can be used.
But you must take one word of caution: for the uRPF configuration to
work, both sides (customer and provider) must select the same link as
"active". If each one use a different link as active, uRPF will block
all
traffic.
The configuration for the provider using a dynamic routing protocol is
the following.
Filters on provider routers (PE). We filter only in each input from the
customer
• Provider router A
¡ cef is needed for uRPF
ip cef
router ospf 10
network 89.107.52.0 0.0.0.255 area 1
redistribute static
interface ATM0/1.1 point-to-point
description Interface to customer
ip address 89.107.53.0 255.255.255.254
¡ static filtering
ip access-group customer-routes in
¡ strict uPRF filtering
ip verify unicast reachable-via rx
[...]
interface FastEthernet0/0
ip address 89.107.54.2 255.255.255.0
standby 1 ip 89.107.54.1
standby 1 preempt
standby 1 priority 150
standby 1 track ATM0/1.1
[...]
ip route 89.107.52.0 255.255.255.0 ATM0/1.1 10
ip route 89.107.52.0 255.255.255.0 89.107.54.3 20
¡ Static networks to filter
¡ Public address of the CPE router
ip access-list extended customer-routes
permit ip 89.107.53.1 0.0.0.0 any
¡ If the customer has a public range assigned, allow it
permit ip 89.107.52.0 0.0.0.255 any
deny ip any any
• Provider router B
¡ cef is needed for uRPF
ip cef
interface ATM0/1.1 point-to-point
description Interface to customer
ip address 89.107.53.0 255.255.255.254
¡ static filtering
ip access-group customer-routes in
¡ strict uRPF filtering
ip verify unicast reachable-via rx
[...]
interface FastEthernet0/0
ip address 89.107.54.3 255.255.255.0
standby 1 ip 89.107.54.1
standby 1 preempt
standby 1 priority 75
standby 1 track ATM0/1.1
[...]
ip route 89.107.52.0 255.255.255.0 ATM0/1.1 10
ip route 89.107.52.0 255.255.255.0 89.107.54.2 20
¡ Static networks to filter
¡ Public address of the CPE router
ip access-list extended customer-routes
permit ip 89.107.53.1 0.0.0.0 any
¡ If the customer has a public range assigned, allow
it
permit ip 89.107.52.0 0.0.0.255 any
deny ip any any
6.1.2.1. Load balancing
6.1.3. Single Router, multiple providers
The most usual multihoming scenario: a single router (CPE) that
can reach the Internet through separate links to other transit
providers, selecting the best route path through a variety of
mechanisms (static routing, BGP best path selection, etc.) The CPE
can run BGP against each ISP, announce his own PI addresses, or
PA addresses assigned by his own or another LIR, or combinations
of these.
Next diagram illustrates the setup:
+--------+
| | 1
| isp A +---------------------+
| | | |
| | | |
+--------+ | 3 |
+----+----+ |
| |5 |
| cust +-----+
| | |
| | |
+----+----+ |
| 4 |
+--------+ | |
| | |
| | 2 |
| isp B +---------------------+
| |
+--------+
Figure 6.1-1
6.1.3.1. Transit interfaces of the CPE router
The CPE will accept from their transit providers a set of routes
to be reached through them. In some cases, the default route could
be assigned to one or more of the ISP interfaces (resillient links
of the preferred one). In the other cases on which no default
route is configured, BGP process will select the best available
path and insert it in the FIB for each interface.
At these transit interfaces, antispoofing measures can include:
•
• - Anti-BOGON filtering via Access-Lists (see section 5.1.1)
•
• - Loose uRPF mechanism, or, if available, feasible-path uRPF
mechanism. It is activated at each interface that provides transit
to the Internet (interfaces 3 and 4 of the Figure 5.1-1), by using
the following commands.
For Cisco routers, first enable CEF or dCEF:
Router(config)# ip cef
or
Router(config)# ip cef distributed
and configure the interface with (IOS versions 12.2T+):
Router(config)# interface FastEthernet0/0
Router (config-if)# ip verify unicast source reachable-via
any
For Juniper routers:
[edit routing-options forwarding-table]
unicast-reverse-path feasible-paths;
and
[edit interfaces fe-0/0/0]
unit 0 {
family inet {
rpf-check; {
mode loose;
}
}
}
For Force10 routers, do:
[TBW]
6.1.3.2. CPE inner-networks interfaces
When the router (CPE) has interfaces that connect to customer's
domain networks with public addresses, anti-spoofing measures can
be:
- * If there's a single interface to the customer
networks, or multiple interface connecting different networks
(with separate prefixes), Strict uRPF applied at each customer
interface can help to drop illegal (spoofed) traffic generated by
compromised hosts inside these networks, e.g. running botnets or
other malware software during DdoS attacks. So, on interface 5 of
figure 5.1-1 one can apply:
-
- - Anti-BOGON filtering via Access-Lists (see section 5.1.1)
- - Loose uRPF mechanism, or, if available, feasible-path uRPF
mechanism. It is activated at each interface that provides
transit to the Internet (interfaces 3 and 4 of the Figure
5.1-1), by using the following commands.
-
For Cisco routers, first enable CEF or dCEF:
Router(config)# ip cef
or
Router(config)# ip cef distributed
and configure the interface with (IOS versions 12.2T+):
Router(config)# interface FastEthernet0/0
Router (config-if)# ip verify unicast source reachable-
via rx
For Juniper routers (feasible-path option):
[edit routing-options forwarding-table]
unicast-reverse-path feasible-paths;
and
[edit interfaces fe-0/0/0]
unit 0 {
family inet {
rpf-check;
}
}
For Force10 routers, do:
[TBW]
-
- * If there are multiple interfaces connecting to the
customer domain networks, and multiple paths are possible to reach
the customer addresses so asymmetric routing to the customer
networks is possible, then Strict uRPF would drop "good" traffic"
that arrives to the router via diverse interfaces, so feasible-
path uRPF has to be configured on the "inner" interfaces or, if
not available, Loose uRPF.
-
6.1.4. Multiple routers, multiple providers
As in the previous section, if asymmetric routing is possible (and
indispensable), and there is no default route present, the most
effective
configuration implies the configuration of feasible-path mode (or, if
not
available, loose mode) uRPF in the transit and inner interfaces of the
CPE routers, and bogon filtering in the transit interfaces.
In the figure 5.1-2, all the interfaces will operate in Loose or
feasible-path uRPF mode. In case "cust" routers have default route
configured , then only interfaces 9 and 10 will have Loose or feasible-
path uRPF configured, and just Bogon Filtering in the others (interfaces
5, 6, 7, 8)
+--------+
| |1 |
| isp A +-----------------------+ |
| | | |
| | | 5 |
+-----+--+ +----+---+ |
|2 | | |
| 6| cust +------+
+------------------------+ |9 |
| | +--------+ |
| | |
| | +--------+ |
| | 7| | |
| +---------------------+ cust +------+
| | |10 |
|3 +----+---+ |
+--+-----+ |8 |
| | | |
| |4 | |
| isp B +-----------------------+ |
| |
+--------+
Figure 5.1-2
6.1.5. Customers access networks
This kind of networks include the equipment deployed by ISPs and
carriers
to aggregate a large number of customers (e.g., broadband concentrators,
dial-up RAS, etc.)
The generic characterization of these equipments include multiple point-
to-point interfaces (to customers) with prefixes univocally (¿?)
assigned
to each customer interface, and a egress/transit interface to the
rest of
the Internet. There's no redundant/multiple paths to customer
destinations, although the transit interfaces can be multiple.
In this case, strict mode uRPF can be configured in the customer links.
This customer links are one of the best situations to use uRPF. IP
address for the customer is assigned usually in a dynamic way (with a
RADIUS server or similar), making the use of dynamic filters impossible.
6.1.5.1. Customer links
- For a Cisco AS5300 the configuration would be as
follows:
! for uRPF we need cef activated
ip cef
! Dial-in group
interface Group-Async1
ip unnumbered Loopback0
no ip directed-broadcast
¡ This is a dynamic assigned ip address
¡ so we can't use static filters, just strict uRPF
ip verify unicast source reachable-via rx
encapsulation ppp
async mode interactive
peer default ip address pool dialin_pool
no cdp enable
ppp authentication chap pap
group-range 1 96
6.1.6. Other Special Cases
6.2. Carriers
6.2.1. DFZ routers
6.2.2. Customer aggregation routers
6.3. Interaction with special mechanisms
All issues involved in Internetworking regarding HSRP, VRRP, etc.
6.4. Multicast enabled Networks
- RPF mechanisms related to Multicast forwarding and routing
- Coexistence with uRPF:
• As is basically the same mechanism, it just needs to be enabled
(explicitly) in the router interfaces.
6.5. Networks with MPLS enabled
This section will describe the anti-spoofing considerations for networks
that have enabled MPLS in some region or domain.
7. IPv6 applicability
8. References
[1] http://www.cymru.com/Bogons/
[2] Savola & Baker, RFC 3704
[3] Savola, draft-savola-bcp84-urpf-experiences-03.txt (updated version)