Opsec WG P. Savola
Internet-Draft CSC/FUNET
Intended status: Informational April 19, 2006
Expires: October 21, 2006
Experiences from Using Unicast RPF
draft-savola-bcp84-urpf-experiences-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
RFC 3704 (BCP 84) published in March 2004 provided an ingress
filtering technique update to RFC 2827 (BCP 38). This memo tries to
document operational experiences learned practising ingress filtering
techniques, in particular ingress filtering for multihomed networks.
Savola Expires October 21, 2006 [Page 1]
Internet-Draft Unicast RPF Experiences April 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Common uRPF Failures . . . . . . . . . . . . . . . . . . . . . 3
2.1. Unused Address Space Ping-Pong . . . . . . . . . . . . . . 3
2.2. Private Address Leak . . . . . . . . . . . . . . . . . . . 4
2.3. Wrong IP Address . . . . . . . . . . . . . . . . . . . . . 4
3. Multihoming uRPF Failures . . . . . . . . . . . . . . . . . . . 5
3.1. Incorrect Source Address Selection . . . . . . . . . . . . 5
3.2. Point-to-Point Interface Routes . . . . . . . . . . . . . . 5
3.3. Multiple Routers on a LAN use LAN for Transit . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Savola Expires October 21, 2006 [Page 2]
Internet-Draft Unicast RPF Experiences April 2006
1. Introduction
RFC 3704 [RFC3704] (BCP 84) published in March 2004 provided an
ingress filtering technique update to RFC 2827 [RFC2827] (BCP 38).
This memo tries to document operational experiences learned
practising ingress filtering techniques, in particular ingress
filtering for multihomed networks.
Specifically, the -00 version describes the lessons learned in
author's network where strict unicast RPF (uRPF) ingress filtering,
using "feasible paths" variant [RFC3704] has been used for all the
customer interfaces (whether single- or multihomed) for over two
years.
We use the typical "customer" and "ISP" terms to refer to the subject
of strict uRPF filtering and the party doing filtering. The same
considerations also apply for other business relationships (e.g.,
"internal customers" inside an ISP).
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
should be the next steps wrt. these experiences. Update to the
ingress filtering RFCs? Publish separately? Keep as a standing
document for now? Integrate with OPSEC document work? In any case,
feedback on other experiences is encouraged.
In the second section, we'll first look at the most common types of
uRPF failures and their mitigation techniques. In the third section,
we'll look at a few special cases observed on multihoming or multi-
connecting scenarios.
2. Common uRPF Failures
We'll describe the most common uRPF failures which apply to both
single- and multi-homed network, and respective fixes.
2.1. Unused Address Space Ping-Pong
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
route), but the customer doesn't use all of P, and an attacker A is
port-scanning the unused address space.
In that case, typically packets destined to the unused part of "P"
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
A (an IP address in the Internet), destined to the customer's prefix
Savola Expires October 21, 2006 [Page 3]
Internet-Draft Unicast RPF Experiences April 2006
P. This fails uRPF check and is dropped.
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
even 250 times the bandwidth and packet processing. This has been
briefly described in [I-D.ietf-ipngwg-p2p-pingpong].
The obvious fix is that the customer needs to install a static
discard routes (or equivalent) for all of its address space, 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
unless it wants to create customer-specific uRPF access-lists.
2.2. Private Address Leak
Very often, packes from all kinds of private addresses also leak to
the ISP, which are obviously dropped by uRPF. This is probably a
result of misconfigured NATs or inadequate firewall rules. Even
(constant) rates of hundreds of packets per second have been
observed, which makes one wonder which kinds of users' communications
must be failing or otherwise working in a non-optimal fashion due to
this kind of misconfiguration...
This is actually one of the most convincing reasons from the users'
perspective why (they or the ISP) using uRPF could give benefits: it
allows them to notice and fix network misconfiguration and
malfunction "at the source" and as a result, communication should
work more reliably and new issues would be easier to notice.
The obvious fix is to ensure that the customer is filtering out (and
logging) these packets, and based on that, figures out what is
causing such address leaks and fixes the misconfiguration or other
problem(s).
2.3. Wrong IP Address
It's also not atypical to see other kinds of wrong source addresses.
These can be classified in three main categories: a) nomadic laptops
trying their old IP from a previous network attachment point, b)
spoofed/misconfigured/typoed public, routable IP address, or c) an
unroutable ("bogon") IP address. (It should be noted that Loose uRPF
would only spot the last category.)
The same considerations as for leaking private addresses apply here,
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
should be applied recursively [RFC3704]).
Savola Expires October 21, 2006 [Page 4]
Internet-Draft Unicast RPF Experiences April 2006
3. Multihoming uRPF Failures
We'll describe a few uRPF failure modes which only occur in scenarios
with a multihomed/multi-connected network or host.
3.1. Incorrect Source Address Selection
Hosts attaching to multiple LANs with different IP address need to be
careful with their source address selection. The same applies to
networks with multiple prefixes as explored in
[I-D.huitema-shim6-ingress-filtering].
For example, assume the host has a default route through interface 1
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
P1 sends a packet to A2, the response may go out through interface 1;
similarly, when a host in P2 sends a packet to A1, the response may
go out through interface 2.
This problem can be fixed by the customers by setting up source-based
routing so packets go through the right route, or by making an
exclusion in the uRPF filter list to allow sourcing from the other
prefix. The latter is typically not a good solution, especially if
the ISP doesn't control both the prefixes, because an ISP originating
these excluded packets would be indistinguishable from IP address
spoofing.
3.2. Point-to-Point Interface Routes
Feasible path strict uRPF works well, but assumes that the routes in
all the directions are consistent (i.e., exist). This principle is
often violated with the interface routes between the ISP and the
customer (ie., point-to-point links).
In some cases, the point-to-point link may be unnumbered but this has
other issues (e.g., eBGP is more complicated). If the links have
addresses, the address blocks usually need to be separate. The
addresses might be more specifics of the customer's aggregate(s) or
from the ISP's address space. In either case, the similar source
address selection issue as described in the previous section applies
for communication (e.g., pinging the CPE's p2p address) to the
customer's point-to-point addresses.
The easiest fix is to add dummy static routes with a higher
preference/distance on all the border routers, so that every router
facing the customer knows all the point-to-point address blocks used
on other routers; using a higher preference implies that the route is
actually never used, but is still valid from uRPF perspective.
Savola Expires October 21, 2006 [Page 5]
Internet-Draft Unicast RPF Experiences April 2006
Another possibility, if the addresses come from the customer's
aggregate, is to not propagate the point-to-point addresses in iBGP
or IGP at all so that there are no more specifics to mess up the uRPF
feasible path consistency, but this may have manageability concerns
if the aggregate goes down (i.e., can't ping the point-to-point
address except on the router connecting the customer). As already
mentioned, using unnumbered interfaces is also possible in some cases
but may have manageability or configuration concerns.
3.3. Multiple Routers on a LAN use LAN for Transit
When multiple routers attach to the same network subnet (typically
when e.g., VRRP is used), packets destined to router 2 (R2)'s
interface addresses towards the LAN transiting router 1 use the LAN
interface to reach R2. (In most cases, the primary path between
routers should go via dedicated link(s), not via a LAN.) These
packets fail uRPF check at R2 (and vice versa at R1).
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
the LAN interface is not used, or make an exception to uRPF
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
interface address(es) (for example, circumventing remote login access
lists), which usually makes it a suboptimal solution.
4. IANA Considerations
This memo makes no request to IANA.
5. Acknowledgements
Maybe you in the next revision? :-)
6. Security Considerations
This document describes uRPF experiences. The most important
security impact comes from applying particular fixes to uRPF issues
noted, i.e., what kind of spoofing window or other unintended usage
that would allow.
As already stated, in invalid source address selection scenario,
making an exception to allow prefixes which you don't control is
typically a big mistake, as then you become indistinguishable from
someone spoofing that address. Also as already stated, in the case
Savola Expires October 21, 2006 [Page 6]
Internet-Draft Unicast RPF Experiences April 2006
of transit LAN, making an exception might allow one to spoof an
address destined to the LAN router's interface address(es) which
usually has a security impact.
7. References
7.1. Normative References
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
7.2. Informative References
[I-D.huitema-shim6-ingress-filtering]
Huitema, C., "Ingress filtering compatibility for IPv6
multihomed sites",
draft-huitema-shim6-ingress-filtering-00 (work in
progress), September 2005.
[I-D.ietf-ipngwg-p2p-pingpong]
Hagino, J., JINMEI, T., and B. Zill, "Avoiding ping-pong
packets on point-to-point links",
draft-ietf-ipngwg-p2p-pingpong-00 (work in progress),
July 2001.
Author's Address
Pekka Savola
CSC/FUNET
Espoo
Finland
Email: psavola@funet.fi
Savola Expires October 21, 2006 [Page 7]
Internet-Draft Unicast RPF Experiences April 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Savola Expires October 21, 2006 [Page 8]