< draft-ietf-opsec-urpf-improvements-01.txt   draft-ietf-opsec-urpf-improvements-02.txt >
OPSEC Working Group K. Sriram OPSEC Working Group K. Sriram
Internet-Draft D. Montgomery Internet-Draft D. Montgomery
Intended status: Best Current Practice USA NIST Intended status: Best Current Practice USA NIST
Expires: April 24, 2019 J. Haas Expires: October 6, 2019 J. Haas
Juniper Networks, Inc. Juniper Networks, Inc.
October 21, 2018 April 4, 2019
Enhanced Feasible-Path Unicast Reverse Path Filtering Enhanced Feasible-Path Unicast Reverse Path Filtering
draft-ietf-opsec-urpf-improvements-01 draft-ietf-opsec-urpf-improvements-02
Abstract Abstract
This document identifies a need for improvement of the unicast This document identifies a need for improvement of the unicast
Reverse Path Filtering techniques (uRPF) [BCP84] for source address Reverse Path Filtering techniques (uRPF) [BCP84] for source address
validation (SAV) [BCP38]. The strict uRPF is inflexible about validation (SAV) [BCP38]. The strict uRPF is inflexible about
directionality, the loose uRPF is oblivious to directionality, and directionality, the loose uRPF is oblivious to directionality, and
the current feasible-path uRPF attempts to strike a balance between the current feasible-path uRPF attempts to strike a balance between
the two [BCP84]. However, as shown in this draft, the existing the two [BCP84]. However, as shown in this draft, the existing
feasible-path uRPF still has short comings. This document describes feasible-path uRPF still has shortcomings. This document describes
an enhanced feasible-path uRPF technique, which aims to be more an enhanced feasible-path uRPF technique, which aims to be more
flexible (in a meaningful way) about directionality than the flexible (in a meaningful way) about directionality than the
feasible-path uRPF. It can potentially alleviate ISPs' concerns feasible-path uRPF. It can potentially alleviate ISPs' concerns
about the possibility of disrupting service for their customers, and about the possibility of disrupting service for their customers, and
encourage greater deployment of uRPF techniques. encourage greater deployment of uRPF techniques.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 51 skipping to change at page 2, line 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This internet draft identifies a need for improvement of the unicast This internet draft identifies a need for improvement of the unicast
Reverse Path Filtering (uRPF) techniques [RFC2827] for source address Reverse Path Filtering (uRPF) techniques [RFC2827] for source address
validation (SAV) [RFC3704]. The strict uRPF is inflexible about validation (SAV) [RFC3704]. The strict uRPF is inflexible about
directionality, the loose uRPF is oblivious to directionality, and directionality, the loose uRPF is oblivious to directionality, and
the current feasible-path uRPF attempts to strike a balance between the current feasible-path uRPF attempts to strike a balance between
the two [RFC3704]. However, as shown in this draft, the existing the two [RFC3704]. However, as shown in this draft, the existing
feasible-path uRPF still has short comings. Even with the feasible- feasible-path uRPF still has shortcomings. Even with the feasible-
path uRPF, ISPs are often apprehensive that they may be dropping path uRPF, ISPs are often apprehensive that they may be dropping
customers' data packets with legitimate source addresses. customers' data packets with legitimate source addresses.
This document describes an enhanced feasible-path uRPF technique, This document describes an enhanced feasible-path uRPF technique,
which aims to be more flexible (in a meaningful way) about which aims to be more flexible (in a meaningful way) about
directionality than the feasible-path uRPF. It is based on the directionality than the feasible-path uRPF. It is based on the
principle that if BGP updates for multiple prefixes with the same principle that if BGP updates for multiple prefixes with the same
origin AS were received on different interfaces (at border routers), origin AS were received on different interfaces (at border routers),
then incoming data packets with source addresses in any of those then incoming data packets with source addresses in any of those
prefixes should be accepted on any of those interfaces (presented in prefixes should be accepted on any of those interfaces (presented in
Section 3). For some challenging ISP-customer scenarios (see Section 3). For some challenging ISP-customer scenarios (see
Section 3.3), this document also describes a more relaxed version of Section 3.3), this document also describes a more relaxed version of
the enhanced feasible-path uRPF technique (presented in Section 3.4). the enhanced feasible-path uRPF technique (presented in Section 3.4).
Implementation considerations are discussed in Section 3.6. 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 permissible source address prefixes for incoming data packets on a
given interface. given interface.
Note: Throughout this document, the routes in consideration are Throughout this document, the routes in consideration are assumed to
assumed to have been vetted based on prefix filtering [RFC7454] and have been vetted based on prefix filtering [RFC7454] and possibly (in
possibly (in the future) origin validation [RFC6811]. the future) origin validation [RFC6811].
The enhanced feasible-path uRPF methods described here are expected The enhanced feasible-path uRPF methods described here are expected
to add greater operational robustness and efficacy to uRPF, while to add greater operational robustness and efficacy to uRPF, while
minimizing ISPs' concerns about accidental service disruption for minimizing ISPs' concerns about accidental service disruption for
their customers. It is expected that this will encourage more their customers. It is expected that this will encourage more
deployment of uRPF to help realize its DDoS prevention benefits deployment of uRPF to help realize its DDoS prevention benefits
network wide. network wide.
1.1. Requirements Language 1.1. Requirements Language
skipping to change at page 7, line 35 skipping to change at page 7, line 35
efficacy to existing uRPF methods discussed in Section 2. The efficacy to existing uRPF methods discussed in Section 2. The
technique is based on the principle that if BGP updates for multiple technique is based on the principle that if BGP updates for multiple
prefixes with the same origin AS were received on different prefixes with the same origin AS were received on different
interfaces (at border routers), then incoming data packets with interfaces (at border routers), then incoming data packets with
source addresses in any of those prefixes should be accepted on any source addresses in any of those prefixes should be accepted on any
of those interfaces. It can be best explained with an example as of those interfaces. It can be best explained with an example as
follows: follows:
Let us say, a border router of ISP-A has in its Adj-RIB-Ins [RFC4271] 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 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 and AS-x is in ISP-A's customer cone. In this set, the border router
received a route for prefix Q1 over a customer facing interface, received the route for prefix Q1 over a customer facing interface,
while it learned routes for prefixes Q2 and Q3 from a lateral peer while it learned the routes for prefixes Q2 and Q3 from a lateral
and an upstream transit provider, respectively. In this example peer and an upstream transit provider, respectively. In this example
scenario, the enhanced feasible-path uRPF method requires Q1, Q2, and scenario, the enhanced feasible-path uRPF method requires Q1, Q2, and
Q3 be included in the RPF list for the customer interface in Q3 be included in the RPF list for the customer interface in
consideration. Loose uRPF (see Section 2.4) is recommended to be consideration. Loose uRPF (see Section 2.4) is recommended to be
applied to the peer and provider interfaces in consideration. applied to the peer and provider interfaces in consideration.
Thus, enhanced feasible-path uRPF defines feasible paths for customer Thus, enhanced feasible-path uRPF defines feasible paths for customer
interfaces in a more generalized but precise way (as compared to interfaces in a more generalized but precise way (as compared to
feasible-path uRPF). feasible-path uRPF).
Looking back at Scenarios 1 and 2 (Figure 1 and Figure 2), the Looking back at Scenarios 1 and 2 (Figure 1 and Figure 2), the
skipping to change at page 15, line 39 skipping to change at page 15, line 39
Redbarn blog , <http://www.redbarn.org/dns/ratelimits>. Redbarn blog , <http://www.redbarn.org/dns/ratelimits>.
[sriram-ripe63] [sriram-ripe63]
Sriram, K. and R. Bush, "Estimating CPU Cost of BGPSEC on Sriram, K. and R. Bush, "Estimating CPU Cost of BGPSEC on
a Router", Presented at RIPE-63; also, at IETF-83 SIDR WG a Router", Presented at RIPE-63; also, at IETF-83 SIDR WG
Meeting, March 2012, Meeting, March 2012,
<http://www.ietf.org/proceedings/83/slides/ <http://www.ietf.org/proceedings/83/slides/
slides-83-sidr-7.pdf>. slides-83-sidr-7.pdf>.
[sriram-urpf] [sriram-urpf]
Sriram, K., "Enhanced Feasible-Path Unicast Reverse Path Sriram et al., K., "Enhanced Feasible-Path Unicast Reverse
Filtering", Presented at the IETF-101 OPSEC WG Meeting , Path Filtering", Presented at the OPSEC WG Meeting,
March 2018, IETF-101 London , March 2018,
<https://datatracker.ietf.org/meeting/101/materials/ <https://datatracker.ietf.org/meeting/101/materials/
slides-101-opsec-draft-sriram-opsec-urpf-improvements-00>. slides-101-opsec-draft-sriram-opsec-urpf-improvements-00>.
[TA14-017A] [TA14-017A]
"UDP-Based Amplification Attacks", US-CERT alert "UDP-Based Amplification Attacks", US-CERT alert
TA14-017A , January 2014, TA14-017A , January 2014,
<https://www.us-cert.gov/ncas/alerts/TA14-017A>. <https://www.us-cert.gov/ncas/alerts/TA14-017A>.
Authors' Addresses Authors' Addresses
 End of changes. 11 change blocks. 
18 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/