Ingress Filtering for Multihomed Networks
RFC 3704

Document Type RFC - Best Current Practice (March 2004; No errata)
Updates RFC 2827
Also known as BCP 84
Was draft-savola-bcp38-multihoming-update (individual in ops area)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 3704 (Best Current Practice)
Telechat date
Responsible AD Bert Wijnen
Send notices to <fred@cisco.com>, <pekkas@netcore.fi>
Network Working Group                                           F. Baker
Request for Comments: 3704                                 Cisco Systems
Updates: 2827                                                  P. Savola
BCP: 84                                                        CSC/FUNET
Category: Best Current Practice                               March 2004

               Ingress Filtering for Multihomed Networks

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   BCP 38, RFC 2827, 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.  This memo updates RFC 2827.

Baker & Savola           Best Current Practice                  [Page 1]
RFC 3704       Ingress Filtering for Multihomed Networks      March 2004

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Different Ways to Implement Ingress Filtering  . . . . . . . .  4
       2.1 Ingress Access Lists . . . . . . . . . . . . . . . . . . .  4
       2.2 Strict Reverse Path Forwarding . . . . . . . . . . . . . .  5
       2.3 Feasible Path Reverse Path Forwarding  . . . . . . . . . .  6
       2.4 Loose Reverse Path Forwarding  . . . . . . . . . . . . . .  6
       2.5 Loose Reverse Path Forwarding Ignoring Default Routes  . .  7
   3.  Clarifying the Applicability of Ingress Filtering  . . . . . .  8
       3.1 Ingress Filtering at Multiple Levels . . . . . . . . . . .  8
       3.2 Ingress Filtering to Protect Your Own Infrastructure . . .  8
       3.3 Ingress Filtering on Peering Links . . . . . . . . . . . .  9
   4.  Solutions to Ingress Filtering with Multihoming  . . . . . . .  9
       4.1 Use Loose RPF When Appropriate . . . . . . . . . . . . . . 10
       4.2 Ensure That Each ISP's Ingress Filter Is Complete  . . . . 11
       4.3 Send Traffic Using a Provider Prefix Only to That Provider 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  Conclusions and Future Work  . . . . . . . . . . . . . . . . . 13
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
       8.1.  Normative References . . . . . . . . . . . . . . . . . . 14
       8.2.  Informative References . . . . . . . . . . . . . . . . . 14
   9.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
   10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16

Baker & Savola           Best Current Practice                  [Page 2]
RFC 3704       Ingress Filtering for Multihomed Networks      March 2004

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
Show full document text