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)
|
|
---|---|---|---|
Authors | Fred Baker , Pekka Savola | ||
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) | |
Action Holders |
(None)
|
||
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 someShow full document text