1. Introduction

   BCP 38, RFC 2827 [1], is designed to limit the impact of distributed
   denial of service attacks, by denying traffic with spoofed addresses
   access to the network, and to help ensure that traffic is traceable
   to its correct source network.  As a side effect of protecting the
   Internet against such attacks, the network implementing the solution
   also protects itself from this and other attacks, such as spoofed
   management access to networking equipment.  There are cases when this
   may create problems, e.g., with multihoming.  This document describes
   the current ingress filtering operational mechanisms, examines
   generic issues related to ingress filtering and delves into the
   effects on multihoming in particular.

   RFC 2827 recommends that ISPs police their customers' traffic by
   dropping traffic entering their networks that is coming from a source
   address not legitimately in use by the customer network.  The
   filtering includes but is in no way limited to the traffic whose
   source address is a so-called "Martian Address" - an address that is
   reserved [3], including any address within 0.0.0.0/8, 10.0.0.0/8,
   127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4, or
   240.0.0.0/4.

   The reasoning behind the ingress filtering procedure is that
   Distributed Denial of Service Attacks frequently spoof other systems'
   source addresses, placing a random number in the field.  In some
   attacks, this random number is deterministically within the target
   network, simultaneously attacking one or more machines and causing
   those machines to attack others with ICMP messages or other traffic;
   in this case, the attacked sites can protect themselves by proper
   filtering, by verifying that their prefixes are not used in the
   source addresses in packets received from the Internet.  In other
   attacks, the source address is literally a random 32 bit number,
   resulting in the source of the attack being difficult to trace.  If
   the traffic leaving an edge network and entering an ISP can be
   limited to traffic it is legitimately sending, attacks can be
   somewhat mitigated: traffic with random or improper source addresses
   can be suppressed before it does significant damage, and attacks can
   be readily traced back to at least their source networks.

   This document is aimed at ISP and edge network operators who 1) would
   like to learn more of ingress filtering methods in general, or 2) are
   already using ingress filtering to some degree but who would like to
   expand its use and want to avoid the pitfalls of ingress filtering in
   the multihomed/asymmetric scenarios.

   In section 2, several different ways to implement ingress filtering
   are described and examined in the generic context.  In section 3,
   some clarifications on the applicability of ingress filtering methods
   are made.  In section 4, ingress filtering is analyzed in detail from
   the multihoming perspective.  In section 5, conclusions and potential
   future work items are identified.