Enhanced Feasible-Path Unicast Reverse Path Forwarding
RFC 8704

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04



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) about