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/