Ingress Filtering for Multihomed Networks
RFC 3704
| Document | Type |
RFC - Best Current Practice
(March 2004; No errata)
Updated by RFC 8704
Updates RFC 2827
Also known as BCP 84
Was draft-savola-bcp38-multihoming-update (individual in ops area)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 3704 (Best Current Practice) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Bert Wijnen | ||
| Send notices to | <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
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
Show full document text