Skip to main content

Enhanced Feasible-Path Unicast Reverse Path Forwarding
RFC 8704 part of BCP 84

Revision differences

Document history

Date By Action
2023-12-12
(System) Imported membership of rfc8704 in bcp84 via sync to the rfc-index
2023-12-12
(System) No history of BCP84 is currently available in the datatracker before this point
2020-03-09
(System)
Received changes through RFC Editor sync (changed abstract to 'This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) …
Received changes through RFC Editor sync (changed abstract to '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.', changed pages to 17, changed standardization level to Best Current Practice, changed state to RFC, changed IESG state to RFC Published)
2020-02-07
(System)
Received changes through RFC Editor sync (created alias RFC 8704, changed abstract to 'This document identifies a need for and proposes improvement of the …
Received changes through RFC Editor sync (created alias RFC 8704, changed abstract to '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.', changed pages to 17, changed standardization level to Best Current Practice, changed state to RFC, added RFC published event at 2020-02-07, changed IESG state to RFC Published, created updates relation between draft-ietf-opsec-urpf-improvements and RFC 3704)
2020-02-07
(System) RFC published