--- 1/draft-ietf-opsec-urpf-improvements-01.txt 2019-04-04 06:13:14.715633021 -0700 +++ 2/draft-ietf-opsec-urpf-improvements-02.txt 2019-04-04 06:13:14.751634051 -0700 @@ -1,20 +1,20 @@ OPSEC Working Group K. Sriram Internet-Draft D. Montgomery Intended status: Best Current Practice USA NIST -Expires: April 24, 2019 J. Haas +Expires: October 6, 2019 J. Haas Juniper Networks, Inc. - October 21, 2018 + April 4, 2019 Enhanced Feasible-Path Unicast Reverse Path Filtering - draft-ietf-opsec-urpf-improvements-01 + draft-ietf-opsec-urpf-improvements-02 Abstract This document identifies a need for improvement of the unicast Reverse Path Filtering techniques (uRPF) [BCP84] for source address validation (SAV) [BCP38]. The 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 [BCP84]. However, as shown in this draft, the existing feasible-path uRPF still has short comings. This document describes @@ -32,25 +32,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 24, 2019. + This Internet-Draft will expire on October 6, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + Copyright (c) 2019 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 @@ -101,27 +101,27 @@ directionality than the feasible-path uRPF. It is based on the principle that if BGP updates for multiple prefixes with the same origin AS were received on different interfaces (at border routers), then incoming data packets with source addresses in any of those prefixes should be accepted on any of those interfaces (presented in Section 3). For some challenging ISP-customer scenarios (see Section 3.3), this document also describes a more relaxed version of the enhanced feasible-path uRPF technique (presented in Section 3.4). Implementation considerations are discussed in Section 3.6. - Note: Definition of Reverse Path Filtering (RPF) list: The list of + Definition of Reverse Path Filtering (RPF) list: The list of permissible source address prefixes for incoming data packets on a given interface. - Note: Throughout this document, the routes in consideration are - assumed to have been vetted based on prefix filtering [RFC7454] and - possibly (in the future) origin validation [RFC6811]. + Throughout this document, the routes in consideration are assumed to + have been vetted based on prefix filtering [RFC7454] and possibly (in + the future) origin validation [RFC6811]. The enhanced feasible-path uRPF methods described here are expected to add greater operational robustness and efficacy to uRPF, while minimizing ISPs' concerns about accidental service disruption for their customers. It is expected that this will encourage more deployment of uRPF to help realize its DDoS prevention benefits network wide. 1.1. Requirements Language @@ -298,24 +298,24 @@ efficacy to existing uRPF methods discussed in Section 2. The technique is based on the principle that if BGP updates for multiple prefixes with the same origin AS were received on different interfaces (at border routers), then incoming data packets with source addresses in any of those prefixes should be accepted on any of those interfaces. It can be best explained with an example as follows: Let us say, a border router of ISP-A has in its Adj-RIB-Ins [RFC4271] the set of prefixes {Q1, Q2, Q3} each of which has AS-x as its origin - and AS-x is in ISP-A's customer cone. Further, the border router - received a route for prefix Q1 over a customer facing interface, - while it learned routes for prefixes Q2 and Q3 from a lateral peer - and an upstream transit provider, respectively. In this example + and AS-x is in ISP-A's customer cone. In this set, the border router + received the route for prefix Q1 over a customer facing interface, + while it learned the routes for prefixes Q2 and Q3 from a lateral + peer and an upstream transit provider, respectively. In this example scenario, the enhanced feasible-path uRPF method requires Q1, Q2, and Q3 be included in the RPF list for the customer interface in consideration. Loose uRPF (see Section 2.4) is recommended to be applied to the peer and provider interfaces in consideration. Thus, enhanced feasible-path uRPF defines feasible paths for customer interfaces in a more generalized but precise way (as compared to feasible-path uRPF). Looking back at Scenarios 1 and 2 (Figure 1 and Figure 2), the @@ -679,23 +679,23 @@ Redbarn blog , . [sriram-ripe63] Sriram, K. and R. Bush, "Estimating CPU Cost of BGPSEC on a Router", Presented at RIPE-63; also, at IETF-83 SIDR WG Meeting, March 2012, . [sriram-urpf] - Sriram, K., "Enhanced Feasible-Path Unicast Reverse Path - Filtering", Presented at the IETF-101 OPSEC WG Meeting , - March 2018, + Sriram et al., K., "Enhanced Feasible-Path Unicast Reverse + Path Filtering", Presented at the OPSEC WG Meeting, + IETF-101 London , March 2018, . [TA14-017A] "UDP-Based Amplification Attacks", US-CERT alert TA14-017A , January 2014, . Authors' Addresses