[rfc-dist] BCP 84, RFC 8704 on Enhanced Feasible-Path Unicast Reverse Path Forwarding

rfc-editor@rfc-editor.org Fri, 07 February 2020 18:02 UTC

Return-Path: <rfc-dist-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-dist-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-dist-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97264120947 for <ietfarch-rfc-dist-archive@ietfa.amsl.com>; Fri, 7 Feb 2020 10:02:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.201
X-Spam-Level:
X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hsxnf9Se8GnE for <ietfarch-rfc-dist-archive@ietfa.amsl.com>; Fri, 7 Feb 2020 10:02:21 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7060B12093C for <rfc-dist-archive-yuw6Xa6hiena@ietf.org>; Fri, 7 Feb 2020 10:02:21 -0800 (PST)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 77714F406F0; Fri, 7 Feb 2020 10:02:03 -0800 (PST)
X-Original-To: rfc-dist@rfc-editor.org
Delivered-To: rfc-dist@rfc-editor.org
Received: by rfc-editor.org (Postfix, from userid 30) id 779AFF406DA; Fri, 7 Feb 2020 10:02:02 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20200207180202.779AFF406DA@rfc-editor.org>
Date: Fri, 7 Feb 2020 10:02:02 -0800 (PST)
Subject: [rfc-dist] =?utf-8?q?BCP_84=2C_RFC_8704_on_Enhanced_Feasible-Pat?= =?utf-8?q?h_Unicast_Reverse_Path_Forwarding?=
X-BeenThere: rfc-dist@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Announcements <rfc-dist.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-dist>, <mailto:rfc-dist-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-dist/>
List-Post: <mailto:rfc-dist@rfc-editor.org>
List-Help: <mailto:rfc-dist-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-dist>, <mailto:rfc-dist-request@rfc-editor.org?subject=subscribe>
Cc: drafts-update-ref@iana.org, opsec@ietf.org, rfc-editor@rfc-editor.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: rfc-dist-bounces@rfc-editor.org
Sender: "rfc-dist" <rfc-dist-bounces@rfc-editor.org>

A new Request for Comments is now available in online RFC libraries.

        BCP 84        
        RFC 8704

        Title:      Enhanced Feasible-Path Unicast Reverse Path 
                    Forwarding 
        Author:     K. Sriram,
                    D. Montgomery,
                    J. Haas
        Status:     Best Current Practice
        Stream:     IETF
        Date:       February 2020
        Mailbox:    ksriram@nist.gov, 
                    dougm@nist.gov, 
                    jhaas@juniper.net
        Pages:      17
        Updates:    RFC 3704
        See Also:   BCP 84

        I-D Tag:    draft-ietf-opsec-urpf-improvements-04.txt

        URL:        https://www.rfc-editor.org/info/rfc8704

        DOI:        10.17487/RFC8704

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.

This document is a product of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF.


BCP: 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.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
rfc-dist mailing list
rfc-dist@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-dist
http://www.rfc-editor.org