Enhanced Feasible-Path Unicast Reverse Path Forwarding
RFC 8704
Document | Type |
RFC - Best Current Practice
(February 2020; No errata)
Updates RFC 3704
|
|
---|---|---|---|
Authors | Kotikalapudi Sriram , Doug Montgomery , Jeffrey Haas | ||
Last updated | 2020-03-09 | ||
Replaces | draft-sriram-opsec-urpf-improvements | ||
Stream | IETF | ||
Formats | plain text html xml pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Sandra Murphy | ||
Shepherd write-up | Show (last changed 2019-07-11) | ||
IESG | IESG state | RFC 8704 (Best Current Practice) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Warren Kumari | ||
Send notices to | Sandra Murphy <sandy@tislabs.com> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | No IANA Actions |
Internet Engineering Task Force (IETF) K. Sriram Request for Comments: 8704 D. Montgomery BCP: 84 USA NIST Updates: 3704 J. Haas Category: Best Current Practice Juniper Networks, Inc. ISSN: 2070-1721 February 2020 Enhanced Feasible-Path Unicast Reverse Path Forwarding Abstract This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible- path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8704. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 1.1. Terminology 1.2. Requirements Language 2. Review of Existing Source Address Validation Techniques 2.1. SAV Using Access Control List 2.2. SAV Using Strict Unicast Reverse Path Forwarding 2.3. SAV Using Feasible-Path Unicast Reverse Path Forwarding 2.4. SAV Using Loose Unicast Reverse Path Forwarding 2.5. SAV Using VRF Table 3. SAV Using Enhanced Feasible-Path uRPF 3.1. Description of the Method 3.1.1. Algorithm A: Enhanced Feasible-Path uRPF 3.2. Operational Recommendations 3.3. A Challenging Scenario 3.4. Algorithm B: Enhanced Feasible-Path uRPF with Additional Flexibility across Customer Cone 3.5. Augmenting RPF Lists with ROA and IRR Data 3.6. Implementation and Operations Considerations 3.6.1. Impact on FIB Memory Size Requirement 3.6.2. Coping with BGP's Transient Behavior 3.7. Summary of Recommendations 3.7.1. Applicability of the EFP-uRPF Method with Algorithm A 4. Security Considerations 5. IANA Considerations 6. References 6.1. Normative References 6.2. Informative References Acknowledgements Authors' Addresses 1. Introduction Source address validation (SAV) refers to the detection and mitigation of source address (SA) spoofing [RFC2827]. This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques [RFC3704] for SAV. Strict uRPF is inflexible about directionality (see [RFC3704] for definitions), the loose uRPF is oblivious to directionality, and the current feasible- path uRPF attempts to strike a balance between the two [RFC3704]. However, as shown in this document, the existing feasible-path uRPF still has shortcomings. Even with the feasible-path uRPF, ISPs are often apprehensive that they may be dropping customers' data packets with legitimate source addresses. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that aim to be more flexible (in a meaningful way) aboutShow full document text