< draft-savola-bcp84-urpf-experiences-00.txt   draft-savola-bcp84-urpf-experiences-01.txt >
Opsec WG P. Savola Opsec WG P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Intended status: Informational April 19, 2006 Intended status: Informational June 12, 2006
Expires: October 21, 2006 Expires: December 14, 2006
Experiences from Using Unicast RPF Experiences from Using Unicast RPF
draft-savola-bcp84-urpf-experiences-00.txt draft-savola-bcp84-urpf-experiences-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 21, 2006. This Internet-Draft will expire on December 14, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
RFC 3704 (BCP 84) published in March 2004 provided an ingress RFC 3704 (BCP 84) published in March 2004 provided an ingress
filtering technique update to RFC 2827 (BCP 38). This memo tries to filtering technique update to RFC 2827 (BCP 38). This memo tries to
document operational experiences learned practising ingress filtering document operational experiences learned practising ingress filtering
techniques, in particular ingress filtering for multihomed networks. techniques, in particular ingress filtering for multihomed networks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Common uRPF Failures . . . . . . . . . . . . . . . . . . . . . 3 2. Common uRPF Failures . . . . . . . . . . . . . . . . . . . . . 3
2.1. Unused Address Space Ping-Pong . . . . . . . . . . . . . . 3 2.1. Unused Address Space Ping-Pong . . . . . . . . . . . . . . 4
2.2. Private Address Leak . . . . . . . . . . . . . . . . . . . 4 2.2. Private Address Leak . . . . . . . . . . . . . . . . . . . 4
2.3. Wrong IP Address . . . . . . . . . . . . . . . . . . . . . 4 2.3. Wrong IP Address . . . . . . . . . . . . . . . . . . . . . 5
3. Multihoming uRPF Failures . . . . . . . . . . . . . . . . . . . 5 3. Multihoming uRPF Failures . . . . . . . . . . . . . . . . . . 5
3.1. Incorrect Source Address Selection . . . . . . . . . . . . 5 3.1. Incorrect Source Address Selection . . . . . . . . . . . . 5
3.2. Point-to-Point Interface Routes . . . . . . . . . . . . . . 5 3.2. Point-to-Point Interface Routes . . . . . . . . . . . . . 6
3.3. Multiple Routers on a LAN use LAN for Transit . . . . . . . 6 3.3. Multiple Routers on a LAN use LAN for Transit . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4. Special uRPF Failures Cases . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. PMTUD and Private/Non-routed Addresses . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Introduction
RFC 3704 [RFC3704] (BCP 84) published in March 2004 provided an RFC 3704 [RFC3704] (BCP 84) published in March 2004 provided an
ingress filtering technique update to RFC 2827 [RFC2827] (BCP 38). ingress filtering technique update to RFC 2827 [RFC2827] (BCP 38).
This memo tries to document operational experiences learned This memo tries to document operational experiences learned
practising ingress filtering techniques, in particular ingress practising ingress filtering techniques, in particular ingress
filtering for multihomed networks. filtering for multihomed networks.
Specifically, the -00 version describes the lessons learned in Specifically, this version describes the lessons learned in author's
author's network where strict unicast RPF (uRPF) ingress filtering, network where strict unicast RPF (uRPF) ingress filtering, using
using "feasible paths" variant [RFC3704] has been used for all the "feasible paths" variant [RFC3704] has been used for all the customer
customer interfaces (whether single- or multihomed) for over two interfaces (whether single- or multihomed) for over two years. In
years. feasible paths strict uRPF, only an accepted equal length prefix
(even if not preferred) is considered feasible. While in some cases,
a more specific or even a less specific might be acceptable, such
condition would not necessarily be correct in general.
We use the typical "customer" and "ISP" terms to refer to the subject We use the typical "customer" and "ISP" terms to refer to the subject
of strict uRPF filtering and the party doing filtering. The same of strict uRPF filtering and the party doing filtering. The same
considerations also apply for other business relationships (e.g., considerations also apply for other business relationships (e.g.,
"internal customers" inside an ISP). "internal customers" inside an ISP).
According to a study, there is substantial ingress filtering
deployment, even 75% of addresses were not spoofable [SPOOFER].
We note explicitly that Loose mode RPF is NOT a sufficient solution
in any way to ingress filtering as it creates a false sense of
protection. Even its use as a "contract validation" [RFC3704] is
tenuous at best.
NOTE IN DRAFT: comments should be directed to the author or the OPSEC NOTE IN DRAFT: comments should be directed to the author or the OPSEC
mailing list (opsec@ops.ietf.org). However, it is not clear what mailing list (opsec@ops.ietf.org). However, it is not clear what
should be the next steps wrt. these experiences. Update to the should be the next steps wrt. these experiences. Update to the
ingress filtering RFCs? Publish separately? Keep as a standing ingress filtering RFCs? Publish separately? Keep as a standing
document for now? Integrate with OPSEC document work? In any case, document for now? Integrate with OPSEC document work? In any case,
feedback on other experiences is encouraged. feedback on other experiences is encouraged.
In the second section, we'll first look at the most common types of In the second section, we'll first look at the most common types of
uRPF failures and their mitigation techniques. In the third section, uRPF failures and their mitigation techniques. In the third section,
we'll look at a few special cases observed on multihoming or multi- we'll look at a few special cases observed on multihoming or multi-
connecting scenarios. connecting scenarios. More special filtering failures are discussed
in the fourth section.
2. Common uRPF Failures 2. Common uRPF Failures
We'll describe the most common uRPF failures which apply to both We'll describe the most common uRPF failures which apply to both
single- and multi-homed network, and respective fixes. single- and multi-homed network, and respective fixes.
2.1. Unused Address Space Ping-Pong 2.1. Unused Address Space Ping-Pong
By far, the most common cause for uRPF failures seems to be the case By far, the most common cause for uRPF failures seems to be the case
where a prefix P is routed to the customer (e.g., using a static where a prefix P is routed to the customer (e.g., using a static
skipping to change at page 4, line 11 skipping to change at page 4, line 23
lack a more specific route, and are routed back to the ISP through a lack a more specific route, and are routed back to the ISP through a
default route. The ISP's router sees these as sourced from attacker default route. The ISP's router sees these as sourced from attacker
A (an IP address in the Internet), destined to the customer's prefix A (an IP address in the Internet), destined to the customer's prefix
P. This fails uRPF check and is dropped. P. This fails uRPF check and is dropped.
Note: if uRPF is not employed, the scan may may cause ping-pong Note: if uRPF is not employed, the scan may may cause ping-pong
effect up to the remaining hop count/TTL of the packet, consuming effect up to the remaining hop count/TTL of the packet, consuming
even 250 times the bandwidth and packet processing. This has been even 250 times the bandwidth and packet processing. This has been
briefly described in [I-D.ietf-ipngwg-p2p-pingpong]. briefly described in [I-D.ietf-ipngwg-p2p-pingpong].
The obvious fix is that the customer needs to install a static The ping-pong effect has also been used in Internet Exchanges to game
discard routes (or equivalent) for all of its address space, so that peer selection or traffic balance data.
if no better route exists, such probe packets are discarded. An
alternative is applying a similar filtering in egress interface Therefore, the customer should install static discard aggregate
routes (or equivalent) for all of its address space upon assignment,
so that if no better route exists, such probe packets are discarded.
An alternative is applying a similar filtering in egress interface
towards the ISP. There isn't much an ISP can do to prevent this towards the ISP. There isn't much an ISP can do to prevent this
unless it wants to create customer-specific uRPF access-lists. unless it wants to create customer-specific uRPF access-lists.
2.2. Private Address Leak 2.2. Private Address Leak
Very often, packes from all kinds of private addresses also leak to Very often, packes from all kinds of private addresses also leak to
the ISP, which are obviously dropped by uRPF. This is probably a the ISP, which are obviously dropped by uRPF. This is probably a
result of misconfigured NATs or inadequate firewall rules. Even result of misconfigured NATs or inadequate firewall rules. Even
(constant) rates of hundreds of packets per second have been (constant) rates of hundreds of packets per second have been
observed, which makes one wonder which kinds of users' communications observed, which makes one wonder which kinds of users' communications
skipping to change at page 4, line 48 skipping to change at page 5, line 14
2.3. Wrong IP Address 2.3. Wrong IP Address
It's also not atypical to see other kinds of wrong source addresses. It's also not atypical to see other kinds of wrong source addresses.
These can be classified in three main categories: a) nomadic laptops These can be classified in three main categories: a) nomadic laptops
trying their old IP from a previous network attachment point, b) trying their old IP from a previous network attachment point, b)
spoofed/misconfigured/typoed public, routable IP address, or c) an spoofed/misconfigured/typoed public, routable IP address, or c) an
unroutable ("bogon") IP address. (It should be noted that Loose uRPF unroutable ("bogon") IP address. (It should be noted that Loose uRPF
would only spot the last category.) would only spot the last category.)
Many spoofed attacks are usually a result of a worm or a botnet (DoS)
attack. A recent case was using recursive DNS servers for reflection
[I-D.ietf-dnsop-reflectors-are-evil], but a lot of different usages
have been observed.
The same considerations as for leaking private addresses apply here, The same considerations as for leaking private addresses apply here,
except that these wouldn't typically get this far if the customer had except that these wouldn't typically get this far if the customer had
been using unicast RPF at its LAN interfaces (i.e., uRPF can and been using unicast RPF at its LAN interfaces (i.e., uRPF can and
should be applied recursively [RFC3704]). should be applied recursively [RFC3704]).
3. Multihoming uRPF Failures 3. Multihoming uRPF Failures
We'll describe a few uRPF failure modes which only occur in scenarios We'll describe a few uRPF failure modes which only occur in scenarios
with a multihomed/multi-connected network or host. with a multihomed/multi-connected network or host.
We note that a customer can multihome and even perform traffic
engineering with feasible paths uRPF provided that the consistency
requirement is fulfilled. In other words, AS-path prepending,
setting communities to lower local-preference, etc. are all valid
mechanisms to ensure the prefix is advertised to every provider, but
actually may not ever end up being used.
3.1. Incorrect Source Address Selection 3.1. Incorrect Source Address Selection
Hosts attaching to multiple LANs with different IP address need to be Hosts attaching to multiple LANs with different IP address need to be
careful with their source address selection. The same applies to careful with their source address selection. The same applies to
networks with multiple prefixes as explored in networks with multiple prefixes as explored in
[I-D.huitema-shim6-ingress-filtering]. [I-D.huitema-shim6-ingress-filtering].
For example, assume the host has a default route through interface 1 For example, assume the host has a default route through interface 1
with address A1 from prefix P1, and only a more specific route with address A1 from prefix P1, and only a more specific route
through interface 2 with address A2 from prefix P2. When a host in through interface 2 with address A2 from prefix P2. When a host in
skipping to change at page 6, line 31 skipping to change at page 7, line 9
packets fail uRPF check at R2 (and vice versa at R1). packets fail uRPF check at R2 (and vice versa at R1).
There are two obvious fixes: have R2 advertise such LAN addresses in There are two obvious fixes: have R2 advertise such LAN addresses in
iBGP or IGP (or set up static routes), resulting a more specific so iBGP or IGP (or set up static routes), resulting a more specific so
the LAN interface is not used, or make an exception to uRPF the LAN interface is not used, or make an exception to uRPF
configuration to allow such "transit LAN" usage. However, the latter configuration to allow such "transit LAN" usage. However, the latter
allows an attacker in the LAN to spoof an address to the LAN router's allows an attacker in the LAN to spoof an address to the LAN router's
interface address(es) (for example, circumventing remote login access interface address(es) (for example, circumventing remote login access
lists), which usually makes it a suboptimal solution. lists), which usually makes it a suboptimal solution.
4. IANA Considerations 4. Special uRPF Failures Cases
4.1. PMTUD and Private/Non-routed Addresses
A disturbing issue is that some large operators seem to think it's
perfectly legitimate to send private-source addressed packets ICMP
messages (e.g., from PMTUD) across AS boundaries [PRIVIP]. While the
reasoning is different, the result is similar for non-routed, but
uniquely assigned address space.
Private IP addresses for infrastructure are a bad idea. But even
worse than that is deploying links in such infrastructure which have
lower MTU than the egress link, i.e., are guaranteed to send ICMP
fragmentation needed messages under certain circumstances. Deploying
such networks that require PMTUD to work while happily originating
RFC1918 traffic (and translating it at the edge) seems like very bad
design from network hygiene perspective.
5. IANA Considerations
This memo makes no request to IANA. This memo makes no request to IANA.
5. Acknowledgements 6. Acknowledgements
Maybe you in the next revision? :-) Danny McPherson and Matsuzaki Yoshinobu provided comments on the
first revision of this document.
6. Security Considerations 7. Security Considerations
This document describes uRPF experiences. The most important This document describes uRPF experiences. The most important
security impact comes from applying particular fixes to uRPF issues security impact comes from applying particular fixes to uRPF issues
noted, i.e., what kind of spoofing window or other unintended usage noted, i.e., what kind of spoofing window or other unintended usage
that would allow. that would allow.
As already stated, in invalid source address selection scenario, As already stated, in invalid source address selection scenario,
making an exception to allow prefixes which you don't control is making an exception to allow prefixes which you don't control is
typically a big mistake, as then you become indistinguishable from typically a big mistake, as then you become indistinguishable from
someone spoofing that address. Also as already stated, in the case someone spoofing that address. Also as already stated, in the case
of transit LAN, making an exception might allow one to spoof an of transit LAN, making an exception might allow one to spoof an
address destined to the LAN router's interface address(es) which address destined to the LAN router's interface address(es) which
usually has a security impact. usually has a security impact.
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
7.2. Informative References 8.2. Informative References
[I-D.huitema-shim6-ingress-filtering] [I-D.huitema-shim6-ingress-filtering]
Huitema, C., "Ingress filtering compatibility for IPv6 Huitema, C., "Ingress filtering compatibility for IPv6
multihomed sites", multihomed sites",
draft-huitema-shim6-ingress-filtering-00 (work in draft-huitema-shim6-ingress-filtering-00 (work in
progress), September 2005. progress), September 2005.
[I-D.ietf-dnsop-reflectors-are-evil]
Damas, J. and F. Neves, "Preventing Use of Nameservers in
Reflector Attacks",
draft-ietf-dnsop-reflectors-are-evil-00 (work in
progress), May 2006.
[I-D.ietf-ipngwg-p2p-pingpong] [I-D.ietf-ipngwg-p2p-pingpong]
Hagino, J., JINMEI, T., and B. Zill, "Avoiding ping-pong Hagino, J., JINMEI, T., and B. Zill, "Avoiding ping-pong
packets on point-to-point links", packets on point-to-point links",
draft-ietf-ipngwg-p2p-pingpong-00 (work in progress), draft-ietf-ipngwg-p2p-pingpong-00 (work in progress),
July 2001. July 2001.
[PRIVIP] NANOG mailing-list thread, "private IP addresses from
ISP", May 2006,
<http://www.merit.edu/mail.archives/nanog/msg00279.html>.
[SPOOFER] MIT ANA, "Spoofer Project",
<http://spoofer.csail.mit.edu>.
Author's Address Author's Address
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo Espoo
Finland Finland
Email: psavola@funet.fi Email: psavola@funet.fi
Full Copyright Statement Full Copyright Statement
 End of changes. 19 change blocks. 
38 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/