draft-ietf-idr-flowspec-interfaceset-03.txt		draft-ietf-idr-flowspec-interfaceset-04.txt
	Routing Area Working Group S. Litkowski		Inter-Domain Routing S. Litkowski
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track A. Simpson		Intended status: Standards Track A. Simpson
	Expires: September 12, 2017 Nokia		Expires: December 30, 2018 Nokia
	K. Patel		K. Patel
	Arrcus, Inc		Arrcus, Inc
	J. Haas		J. Haas
	Juniper Networks		Juniper Networks
	L. Yong		L. Yong
	Huawei		Huawei
	March 11, 2017		June 28, 2018
	Applying BGP flowspec rules on a specific interface set		Applying BGP flowspec rules on a specific interface set
	draft-ietf-idr-flowspec-interfaceset-03		draft-ietf-idr-flowspec-interfaceset-04
	Abstract		Abstract
	BGP flowspec is an extension to BGP that allows for the dissemination		The BGP Flow Specification (flowspec) Network Layer Reachability
	of traffic flow specification rules. The primary application of this		Information (BGP NLRI) extension ([RFC5575]) is used to distribute
	extension is DDoS mitigation where the flowspec rules are applied in		traffic flow specifications into BGP. The primary application of
	most cases to all peering routers of the network.		this extension is the distribution of traffic filtering policies for
			the mitigation of distributed denial of service (DDoS) attacks.
	This document will present another use case of BGP flowspec where
	flow specifications are used to maintain some access control lists at
	network boundary. BGP flowspec is a very efficient distributing
	machinery that can help in saving OPEX while deploying/updating ACLs.
	This new application requires flow specification rules to be applied
	only on a specific subset of interfaces and in a specific direction.
	The current specification of BGP flowspec ([RFC5575]) introduces the
	notion of flow specification (which describes the matching criterion)
	and traffic filtering actions. The flow specification is encoded as
	part of the NLRI while the traffic filtering actions are encoded as
	extended communities. The combination of a flow specification and
	one or more actions is known as a flow specification rule. [RFC5575]
	does not detail where the flow specification rules need to be
	applied.
	Besides the flow specification and traffic filtering actions, this		By default, flow specification filters are applied on all forwarding
	document introduces the notion of traffic filtering scope in order to		interfaces that are enabled for use by the BGP flowspec extension. A
	drive where a particular rule must be applied. In particular, this		network operator may wish to apply a given filter selectively to a
	document introduces the "interface-set" traffic filtering scope that		subset of interfaces based on an internal classification scheme.
	could be used in parallel of traffic filtering actions (marking,		Examples of this include "all customer interfaces", "all peer
	rate-limiting ...). The purpose of this extension is to inform		interfaces", "all transit interfaces", etc.
	remote routers about groups of interfaces where the rule must be
	applied.
	This extension can also be used in a DDoS mitigation context where a		This document defines BGP Extended Communities ([RFC4360]) that
	provider wants to apply the filtering only on specific peers.		permit such filters to be selectively applied to sets of forwarding
			interfaces sharing a common group identifier. The BGP Extended
			Communities carrying this group identifier are referred to as the BGP
			Flowspec "interface-set" Extended Communities.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	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
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 15 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 September 12, 2017.		This Internet-Draft will expire on December 30, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Specific filtering for DDoS . . . . . . . . . . . . . . . 3		2. Interface specific filtering using BGP flowspec . . . . . . . 3
	1.2. ACL maintenance . . . . . . . . . . . . . . . . . . . . . 4		3. Interface-set extended community . . . . . . . . . . . . . . 4
	2. Collaborative filtering and managing filter direction . . . . 5		4. Scaling of per-interface rules . . . . . . . . . . . . . . . 6
	3. Traffic filtering scope . . . . . . . . . . . . . . . . . . . 6		5. Deployment Considerations . . . . . . . . . . . . . . . . . . 6
	4. Interface specific filtering using BGP flowspec . . . . . . . 7		5.1. Add-Paths . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Interface-set extended community . . . . . . . . . . . . . . 8		5.2. Inter-domain Considerations . . . . . . . . . . . . . . . 6
	6. Handling rules from different sources in the processing pipe 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6.1. Combining Policy Based Routing with BGP flowspec and		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	interface-set . . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6.2. Combining flow collection with BGP flowspec and		8.1. FlowSpec Transitive Extended Communities . . . . . . . . 7
	interface-set . . . . . . . . . . . . . . . . . . . . . . 11		8.2. FlowSpec Non-Transitive Extended Communities . . . . . . 7
	7. Scaling of per interface rules . . . . . . . . . . . . . . . 11		8.3. FlowSpec interface-set Extended Community . . . . . . . . 8
	8. Deployment considerations . . . . . . . . . . . . . . . . . . 12		8.4. Allocation Advice to IANA . . . . . . . . . . . . . . . . 8
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		9. Normative References . . . . . . . . . . . . . . . . . . . . 8
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	11.1. FlowSpec Transitive Extended Communities . . . . . . . . 13
	11.2. FlowSpec Non-Transitive Extended Communities . . . . . . 13
	11.3. FlowSpec interface-set Extended Community . . . . . . . 13
	11.4. Allocation Advice to IANA . . . . . . . . . . . . . . . 13
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	12.1. Normative References . . . . . . . . . . . . . . . . . . 14
	12.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Use case		1. Use case
	1.1. Specific filtering for DDoS		While a network may provide connectivity to a homogenous class of
			users, it often provides connectivity to different groups of users.
	----------------- --- (ebgp) - Peer3 (BW 10G)		The nature of these different groups, and how they're classified,
	/ \/		varies based on the purpose of the network. In an enterprise
	| /|		network, connectivity may exist between data centers, offices, and
	| PE --- (ebgp) - Transit1(BW 4x10G)		external connectivity. In a virtual private networking (VPN)
	Cust1 --- (ebgp) --- PE |		network, it may consist of customers in different sites connected
	| PE ---- (ebgp) - Peer2 (BW 4*10G)		through a VPN, the provider core network, and external networks such
	| \|		as the Internet. In a traditional Internet service provider (ISP)
	Cust2 --- (ebgp) --- PE |----- (ebgp) - Customer3		network, the network may consist of points of presence (POPs),
	/| |		internal infrastructure networks, customer networks, peer networks,
	Peer1(BW10G)-(ebgp) | PE --- (ebgp) - Transit2(BW 4x10G)		and transit networks.
	| |
	\ /
	------------------
	Figure 1
	The figure 1 above displays a typical service provider Internet
	network owing Customers, Peers and Transit. To protect pro actively
	against some attacks (e.g. DNS, NTP ...), the service provider may
	want to deploy some rate-limiting of some flows on peers and transit
	links. But depending on link bandwidth, the provider may want to
	apply different rate-limiting values.
	For 4*10G links peer/transit, it may want to apply a rate-limiting of
	DNS flows of 1G, while on 10G links, the rate-limiting would be set
	to 250Mbps. Customer interfaces must not be rate-limited.
	BGP flowspec infrastructure may already be present on the network,
	and all PEs may have a BGP session running flowspec address family.
	The flowspec infrastructure may be reused by the service provider to
	implement such rate-limiting in a very quick manner and being able to
	adjust values in future quickly without having to configure each node
	one by one. Using the current BGP flowspec specification, it would
	not be possible to implement different rate limiter on different
	interfaces of a same router. The flowspec rule is applied to all
	interfaces in all directions or on some interfaces where flowspec is
	activated but flowspec rule set would be the same among all
	interfaces.
	Section Section 4 will detail a solution to address this use case
	using BGP flowspec.
	1.2. ACL maintenance
	--------------- --- (ebgp) - Cust4_VPN
	/ \/
	Cust1_INT -- (ebgp) --- PE /|
	| PE ------ (ebgp) - Transit1
	Cust3_VPN -- (ebgp) --- PE |
	| PE ------ (ebgp) - Peer2
	| \|
	Cust2_INT -- (ebgp) --- PE |----- (ebgp) - Cust4_INT
	/| |
	Peer1 ------ (ebgp) -- | PE ------ (ebgp) - Transit2
	| |
	\ /
	----------------
	Figure 2
	The figure 1 above displays a typical service provider multiservice
	network owing Customers, Peers and Transit for Internet, as well as
	VPN services. The service provider requires to ensure security of
	its infrastructure by applying ACLs at network boundary. Maintaining
	and deploying ACLs on hundreds/thousands of routers is really painful
	and time consuming and a service provider would be interested to
	deploy/updates ACLs using BGP flowspec. In this scenario, depending
	on the interface type (Internet customer, VPN customer, Peer, Transit
	...) the content of the ACL may be different.
	We foresee two main cases :
	o Maintaining complete ACLs using flowspec : in this case all the
	ingress ACL are maintained and deployed using BGPflowspec. See
	section Section 9 for more details on security aspects.
	o Requirement of a quick deployment of a new filtering term due to a
	security alert : new security alerts often requires a fast
	deployment of new ACL terms. Using traditional CLI and hop by hop
	provisioning, such deployment takes time and network is
	unprotected during this time window. Using BGP flowspec to deploy
	such rule, a service provider can protect its network in few
	seconds. Then the SP can decide to keep the rule permanently in
	BGP flowspec or update its ACL or remove the entry (in case
	equipments are not vulnerable anymore).
	Section Section 4 will detail a solution to address this use case
	using BGP flowspec.
	2. Collaborative filtering and managing filter direction
	[RFC5575] states in Section 5. : "This mechanism is primarily
	designed to allow an upstream autonomous system to perform inbound
	filtering in their ingress routers of traffic that a given downstream
	AS wishes to drop.".
	In case of networks collaborating in filtering, there is a use case
	for performing outbound filtering. Outbound filtering allows to
	apply traffic action one step before and so may allow to prevent
	impact like congestions.
	----------------------
	/ \
	| Upstream provider |
	\ /
	-----------------------
	| |
	|P2 |P1
	----------------------
	/ \
	| MyAS |
	\ /
	-----------------------
	Figure 3
	In the figure above, MyAS is connected to an upstream provider. If a
	malicious traffic comes in from the upstream provider, it may
	congestion P1 or P2 links. If MyAS apply inbound filtering on P1/P2
	using BGP flowspec, the congestion issue will not be solved.
	Using collaborative filtering, the upstream provider may propose to
	MyAS to filter malicious traffic sent to it. We propose to enhance
	[RFC5575] to make myAS able to send BGP flowspec updates (on eBGP
	sessions) to the upstream provider to request outbound filtering on
	peering interfaces towards MyAS. When the upstream provider will
	receive the BGP flowspec update from MyAS, the BGP flowspec update
	will contain request for outbound filtering on a specific set of
	interfaces. The upstream provider will apply automatically the
	requested filter and congestion will be prevented.
	3. Traffic filtering scope
	We see with the use case described above that some BGP flowspec rules
	may need to be applied only on specific elements of the network
	(interfaces, nodes ...). The basic specification detailed in
	[RFC5575] does not address this and does not give any detail on where
	the traffic filtering rule need to be applied.
	In addition to the flow specification (flow matching criterion) and		The BGP flowspec extension permits traffic filters to be distributed
	traffic filtering actions described in [RFC5575], this document		to routers throughout a network. However, these filters often should
	introduces the notion of traffic filtering scope. The traffic		not be uniformly applied to all network interfaces. As an example, a
	filtering scope will describe where a particular flow specification		rate-limiting filter applied to the SMTP protocol may be applied to
	rule must be applied.		customer networks, but not other networks. Similarly, a DDoS attack
			on the SSH protocol may be deemed appropriate to drop at upstream
			peering routers but not customer routers.
	Using a traffic filtering scope in a BGP flowspec rule is optional.		By default, BGP flowspec filters are applied at all interfaces that
	When a rule does not contain any traffic filtering scope parameter,		permit flowspec filters to be installed. What is needed is a way to
	[RFC5575] applies.		selectively apply those filters to subsets of interfaces in a
			network.
	4. Interface specific filtering using BGP flowspec		2. Interface specific filtering using BGP flowspec
	The use case detailed above requires application of different BGP		The uses case detailed above require application of different BGP
	flowspec rules on different set of interfaces.		flowspec rules on different sets of interfaces.
	We propose to introduce, within BGP flowspec, a traffic filtering		We propose to introduce, within BGP flowspec, a traffic filtering
	scope that identifies a group of interfaces where a particular filter		scope that identifies a group of interfaces where a particular filter
	should apply on. Identification of interfaces within BGP flowspec		should be applied. Identification of interfaces within BGP flowspec
	will be done through group identifiers. A group identifier marks a		will be done through group identifiers. A group identifier marks a
	set of interfaces sharing a common administrative property. Like a		set of interfaces sharing a common administrative property. Like a
	BGP community, the group identifier itself does not have any		BGP community, the group identifier itself does not have any
	significance. It is up to the network administrator to associate a		significance. It is up to the network administrator to associate a
	particular meaning to a group identifier value (e.g. group ID#1		particular meaning to a group identifier value (e.g. group ID#1
	associated to Internet customer interfaces). The group identifier is		associated to Internet customer interfaces). The group identifier is
	a local interface property. Any interface may be associated with one		a local interface property. Any interface may be associated with one
	or more group identifiers using manual configuration.		or more group identifiers using manual configuration.
	When a filtering rule advertised through BGP flowspec must be applied		When a filtering rule advertised through BGP flowspec must be applied
	only to particular sets of interfaces, the BGP flowspec BGP update		only to particular sets of interfaces, the BGP flowspec BGP UPDATE
	will contain the identifiers associated with the relevant sets of		will contain the identifiers associated with the relevant sets of
	interfaces. In addition to the group identifiers, it will also		interfaces. In addition to the group identifiers, it will also
	contain the direction the filtering rule must be applied in (see		contain the direction the filtering rule must be applied in (see
	Section 5).		Section 3).
	Configuration of group identifiers associated to interfaces may		Configuration of group identifiers associated to interfaces may
	change over time. An implementation MUST ensure that the filtering		change over time. An implementation MUST ensure that the filtering
	rules (learned from BGP flowspec) applied to a particular interface		rules (learned from BGP flowspec) applied to a particular interface
	are always updated when the group identifier mapping is changing.		are always updated when the group identifier mapping is changing.
	Considering figure 2, we can imagine the following design :		As an example, we can imagine the following design :
	o Internet customer interfaces are associated with group-identifier		o Internet customer interfaces are associated with group-identifier
	1.		1.
	o VPN customer interfaces are associated with group-identifier 2.		o VPN customer interfaces are associated with group-identifier 2.
	o All customer interfaces are associated with group-identifier 3.		o All customer interfaces are associated with group-identifier 3.
	o Peer interfaces are associated with group-identifier 4.		o Peer interfaces are associated with group-identifier 4.
	o Transit interfaces are associated with group-identifier 5.		o Transit interfaces are associated with group-identifier 5.
	o All external provider interfaces are associated with group-		o All external provider interfaces are associated with group-
	identifier 6.		identifier 6.
	o All interfaces are associated with group-identifier 7.		o All interfaces are associated with group-identifier 7.
	If the service provider wants to deploy a specific inbound filtering		If the service provider wants to deploy a specific inbound filtering
	on external provider interfaces only, the provider can send the BGP		on external provider interfaces only, the provider can send the BGP
	flow specification using group-identifier 6 and including inbound		flow specification using group-identifier 6 for the inbound
	direction.		direction.
	There are some cases where nodes are dedicated to specific functions		There are some cases where nodes are dedicated to specific functions
	(Internet peering, Internet Edge, VPN Edge, Service Edge ...), in		(Internet peering, Internet Edge, VPN Edge, Service Edge ...), in
	this kind of scenario, there is an interest for a constrained		this kind of scenario, there is an interest for a constrained
	distribution of filtering rules that are using the interface specific		distribution of filtering rules that are using the interface specific
	filtering. Without the constrained route distribution, all nodes		filtering. Without the constrained route distribution, all nodes
	will received all the filters even if they are not interested in		will received all the filters even if they are not interested in
	those filters. Constrained route distribution of flowspec filters		those filters. Constrained route distribution of flowspec filters
	would allow for a more optimized distribution.		would allow for a more optimized distribution.
	5. Interface-set extended community		3. Interface-set extended community
	This document proposes a new BGP Route Target extended community		This document proposes a new BGP Route Target extended community
	called "flowspec interface-set". This document so expands the		called the "flowspec interface-set". This document expands the
	definition of the Route Target extended community to allow a new		definition of the Route Target extended community to allow a new
	value of high order octet (Type field) to be TBD (in addition to the		value of high order octet (Type field) to be 0x07 for the transitive
	values specified in [RFC4360]).		flowspec interface-set extended community, or 0x47 for the non-
			transitive flowspec interface-set extended community. These are in
	In order to ease intra-AS and inter-AS use cases, this document		addition to the values specified in [RFC4360].
	proposes to have a transitive as well as a non transitive version of
	this extended community.
	This new BGP Route Target extended community is encoded as follows :		This new BGP Route Target extended community is encoded as follows :
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type (TBD) | 0x02 | Autonomous System Number :		| 0x07 or 0x47 | 0x02 | Autonomous System Number :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	: AS Number (cont.) |O|I| Group Identifier |		: AS Number (cont.) |O|I| Group Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The flags are :		The flags are :
	o O : if set, the flow specification rule MUST be applied in		o O : if set, the flow specification rule MUST be applied in
	outbound direction to the interface set referenced by the		outbound direction to the interface set referenced by the
	following group-identifier.		following group-identifier.
	o I : if set, the flow specification rule MUST be applied in input		o I : if set, the flow specification rule MUST be applied in inbound
	direction to the interface set referenced by the following group-		direction to the interface set referenced by the following group-
	identifier.		identifier.
	Both flags can be set at the same time in the interface-set extended		Both flags can be set at the same time in the interface-set extended
	community leading to flow rule to be applied in both directions. An		community leading to flow rule to be applied in both directions. An
	interface-set extended community with both flags set to zero MUST be		interface-set extended community with both flags set to zero MUST be
	treated as an error and as consequence, the flowspec update MUST be		treated as an error and as consequence, the flowspec update MUST be
	discarded. As having no direction indicated as no sense, there is no		discarded. As having no direction indicated as no sense, there is no
	need to propagate the filter informations in the network.		need to propagate the filter informations in the network.
	The Group Identifier is coded as a 14-bit number (values goes from 0		The Group Identifier is encoded as a 14-bit number, values 0..16383.
	to 16383).
	Multiple instances of the interface-set community may be present in a
	BGP update. This may appear if the flow rule need to be applied to
	multiple set of interfaces.
	Multiple instances of the community in a BGP update MUST be
	interpreted as a "OR" operation : if a BGP update contains two
	interface-set communities with group ID 1 and group ID 2, the filter
	would need to be installed on interfaces belonging to Group ID 1 or
	Group ID 2.
	As using a Route Target, route distribution of flowspec NLRI with
	interface-set may be subject to constrained distribution as defined
	in [RFC4684]. Constrained route distribution for flowspec routes
	using interface-set requires discussion and will be addressed in a
	future revision of the document.
	6. Handling rules from different sources in the processing pipe
	A packet on a router may be processed by multiple rules that are
	originated by different sources (e.g. statically configured, I2RS
	ephemeral, BGP ephemeral ...). [RFC5575] does not provide any
	guidance regarding the precedence of BGP flowspec rules compared to
	other sources. A new version of BGP flowspec
	[I-D.hares-idr-flowspec-v2] should address these precedence rules
	definition in future.
	This document only addresses the usage of "interface-set" in the
	framework of [RFC5575] and the following generic rules SHOULD be used
	by an implementation:
	o An inbound flowspec rule using interface-set SHOULD be processed
	after all existing inbound traffic processing rules (ACL, PBR,
	QoS, flow collection ...) and SHOULD be applied before forwarding
	decision is made.
	o An outbound flowspec rule using interface-set SHOULD be processed
	after all existing outbound traffic processing rules (ACL, PBR,
	QoS, flow collection ...) and SHOULD be applied after forwarding
	decision has been made.
	Inbound processing Forwarding Outbound processing
	ACL->PBR->BGP_FS in -> Lookup -> PBR->QoS->I2RS->BGP_FS out
	Example of packet processing pipe
	In the example above, any BGP flowspec rule ([RFC5575]) with an
	inbound interface-set is processed after all existing features (ACL,
	PBR and QoS) but before the lookup is done. The outbound BGP
	flowspec rules with interface-set are applied after the lookup and
	after all any existing feature.
	This section gives two examples of combining existing features with
	BGP flowspec+interface-set attribute on an interface.
	6.1. Combining Policy Based Routing with BGP flowspec and interface-set
	In this example, a router has an already configured inbound policy on
	an interface IF1 with the following rules:
	o Static policy IN:
	* Entry 1: from udp 10/8 to 11/8 port 53 then set dscp af11 and
	accept
	* Entry 2: from tcp 10/8 to 11/8 port 22 then set dscp af22 and
	accept
	* Entry 3: from tcp 10/8 to 11/8 port 80 then set dscp af11 and
	accept
	* Entry 4: from ip 10/8 to 11/8 then drop
	In addition to this static inbound ACL, the router receives the
	following unordered BGP flowspec version 1 rules with an interface-
	set matching IF1.
	o flowspec rules IN :
	* from udp 10.0.0.1/32 to 11/8 port 53 then drop
	* from tcp 10/8 to 11/8 port 80 then set dscp af32 and accept
	* from udp 10/8 to 11/8 then accept
	The combination of the static inbound ACL and the inbound "interface-
	set" flowspec rules should result in the following packet processing:
	o a UDP flow from 10.0.0.1 to 11.0.0.2 on port 53 will be rejected:
	firstly, it is allowed by the static ACL and DSCP is set to af11
	but then it is dropped by the flowspec filter.
	o a UDP flow from 10.0.0.2 to 11.0.0.2 on port 53 will be accepted
	and DSCP will be set to af11.
	o a TCP flow from 10.0.0.2 to 11.0.0.2 on port 80 will be accepted		Multiple instances of the interface-set extended community may be
	and DSCP will be set to af32: firstly, the static PBR rule set the		present in a BGP update. This may occur if the flowspec rule needs
	DSCP to af11 and accepts the packet, then the flowspec filter		to be applied to multiple sets of interfaces.
	rewrites the DSCP to af32 and accepts it also.
	6.2. Combining flow collection with BGP flowspec and interface-set		Multiple instances of the extended community in a BGP update MUST be
			interpreted as a "OR" operation. For example, if a BGP UPDATE
			contains two interface-set extended communities with group ID 1 and
			group ID 2, the filter would need to be installed on interfaces
			belonging to Group ID 1 or Group ID 2.
	A router may activate flow collection features (used in collaboration		Similar to using a Route Target extended community, route
	with Netflow export). Flow collection can be done at input side or		distribution of flowspec NLRI with interface-set extended communities
	output side. When a router is configured to collect flow		may be subject to constrained distribution as defined in [RFC4684].
	informations on an inbound interface, the flow collection happens
	before any BGP flowspec rule with interface-set: if a particular
	packet flow is denied by a BGP flowspec rule, it will still be
	collected.
	The same happens if a router is configured to collect flow		4. Scaling of per-interface rules
	informations on an outbound interface, the flow collection happens,
	and then the BGP flowspec rule is applied: the flow is collected
	whatever the result of the BGP flowspec rule.
	7. Scaling of per interface rules		In the absence of an interface-set extended community, a flowspec
			filter is applied to all flowspec enabled interfaces. When
			interface-set extended communities are present, different interfaces
			may have different filtering rules, with different terms and actions.
			These differing rules may make it harder to share forwarding
			instructions within the forwarding plane.
	Without "interface-set", all the interfaces are using the same		Flowspec implementations supporting the interface-set extended
	flowspec filter, while with "interface-set" different interfaces may		community SHOULD take care to minimize the scaling impact in such
	have different flowspec filters (with different terms and actions).		circumstances. How this is accomplished is out of the scope of this
	Having such flowspec rules that are applied on specific interfaces		document.
	may create forwarding instructions that may be harder to share within
	the forwarding plane: a particular term may be present or not in the
	filter of a particular interface.
	An implementation SHOULD take care about trying to keep sharing		5. Deployment Considerations
	forwarding structures as much as possible in order to limit the
	scaling impact. How the implementation would do so is out of scope
	of the document.
	8. Deployment considerations		5.1. Add-Paths
	There are some cases where a particular BGP flowspec NLRI may be		There are some cases where a particular BGP flowspec NLRI may be
	advertised to different interface groups with a different action.		advertised to different interface groups with a different action.
	For example, a service provider may want to discard all ICMP traffic		For example, a service provider may want to discard all ICMP traffic
	from customer interfaces to infrastructure addresses and want to		from customer interfaces to infrastructure addresses and want to
	rate-limit the same traffic when it comes from some internal		rate-limit the same traffic when it comes from some internal
	platforms. These particular cases require ADD-PATH to be deployed in		platforms. These particular cases require ADD-PATH ([RFC7911]) to be
	order to ensure that all paths (NLRI+interface-set group-id+actions)		deployed in order to ensure that all paths (NLRI+interface-set group-
	are propagated within the BGP control plane. Without ADD-PATH, only		id+actions) are propagated within the BGP control plane. Without
	a single "NLRI+interface-set group-id+actions" will be propagated, so		ADD-PATH, only a single "NLRI+interface-set group-id+actions" will be
	some filtering rules will never be applied.		propagated, so some filtering rules will never be applied.
	9. Security Considerations		5.2. Inter-domain Considerations
	Managing permanent Access Control List by using BGP flowspec as		The Group Identifier used by the interface-set extended community has
	described in Section 1.2 helps in saving roll out time of such ACL.		local significance to its provisioning Autonomous System. While
	However some ACL especially at network boundary are critical for the		[RFC5575] permits inter-as advertisement of flowspec NLRI, care must
	network security and loosing the ACL configuration may lead to		be taken to not accept these communities when they would result in
	network open for attackers.		unacceptable filtering policies.
	By design, BGP flowspec rules are ephemeral : the flow rule exists in		Filtering of interface-set extended communities at Autonomous System
	the router while the BGP session is UP and the BGP path for the rule		border routers (ASBRs) may thus be desirable.
	is valid. We can imagine a scenario where a Service Provider is
	managing the network boundary ACLs by using only flowspec. In this
	scenario, if , for example, an attacker succeed to make the internal
	BGP session of a router to be down , it can open all boundary ACLs on
	the node, as flowspec rules will disappear due to the BGP session
	down.
	In reality, the chance for such attack to occur is low, as boundary		Note that the default behavior without the interface-set feature
	ACLs should protect the BGP session from being attacked.		would to have been to install the flowspec filter on all flowspec
			enabled interfaces.
	In order to complement the BGP flowspec solution is such deployment		6. Security Considerations
	scenario and provides security against such attack, a service
	provider may activate Long lived Graceful Restart
	[I-D.uttaro-idr-bgp-persistence] on the BGP session owning flowspec
	address family. So in case of BGP session to be down, the BGP paths
	of flowspec rules would be retained and the flowspec action will be
	retained.
	10. Acknowledgements		This document extends the Security Considerations of [RFC5575] by
			permitting flowspec filters to be selectively applied to subsets of
			network interfaces in a particular direction. Care must be taken to
			not permit the inadvertant manipulation of the interface-set extended
			community to bypass expected traffic manipulation.
			7. Acknowledgements
	Authors would like to thanks Wim Hendrickx and Robert Raszuk for		Authors would like to thanks Wim Hendrickx and Robert Raszuk for
	their valuable comments.		their valuable comments.
	11. IANA Considerations		8. IANA Considerations
	11.1. FlowSpec Transitive Extended Communities		8.1. FlowSpec Transitive Extended Communities
	This document requests a new type from the "BGP Transitive Extended		This document requests a new type from the "BGP Transitive Extended
	Community Types" extended community registry from the First Come		Community Types" extended community registry from the First Come
	First Served range. This type name shall be 'FlowSpec Transitive		First Served range. This type name shall be 'FlowSpec Transitive
	Extended Communities'.		Extended Communities'. IANA has assigned the value 0x07 to this
			type.
	This document requests creation of a new registry called "FlowSpec		This document requests creation of a new registry called "FlowSpec
	Transitive Extended Community Sub-Types". This registry contains		Transitive Extended Community Sub-Types". This registry contains
	values of the second octet (the "Sub-Type" field) of an extended		values of the second octet (the "Sub-Type" field) of an extended
	community when the value of the first octet (the "Type" field) is the		community when the value of the first octet (the "Type" field) is the
	value allocated in this document. The registration procedure for		value allocated in this document. The registration procedure for
	values in this registry shall be First Come First Served.		values in this registry shall be First Come First Served.
	11.2. FlowSpec Non-Transitive Extended Communities		8.2. FlowSpec Non-Transitive Extended Communities
	This document requests a new type from the "BGP Non-Transitive		This document requests a new type from the "BGP Non-Transitive
	Extended Community Types" extended community registry from the First		Extended Community Types" extended community registry from the First
	Come First Served range. This type name shall be 'FlowSpec Non-		Come First Served range. This type name shall be 'FlowSpec Non-
	Transitive Extended Communities'.		Transitive Extended Communities'. IANA has assigned the value 0x47
			to this type.
	This document requests creation of a new registry called "FlowSpec		This document requests creation of a new registry called "FlowSpec
	Non-Transitive Extended Community Sub-Types". This registry contains		Non-Transitive Extended Community Sub-Types". This registry contains
	values of the second octet (the "Sub-Type" field) of an extended		values of the second octet (the "Sub-Type" field) of an extended
	community when the value of the first octet (the "Type" field) is the		community when the value of the first octet (the "Type" field) is the
	value allocated in this document. The registration procedure for		value allocated in this document. The registration procedure for
	values in this registry shall be First Come First Served.		values in this registry shall be First Come First Served.
	11.3. FlowSpec interface-set Extended Community		8.3. FlowSpec interface-set Extended Community
	Within the two new registries above, this document requests a new		Within the two new registries above, this document requests a new
	subtype (suggested value 0x02). This sub-type shall be named		subtype (suggested value 0x02). This sub-type shall be named
	"interface-set", with a reference to this document.		"interface-set", with a reference to this document.
	11.4. Allocation Advice to IANA		8.4. Allocation Advice to IANA
	IANA is requested to allocate the values of the FlowSpec Transitive		IANA is requested to allocate the values of the FlowSpec Transitive
	and Non-Transitive Extended Communities such that their values are		and Non-Transitive Extended Communities such that their values are
	identical when ignoring the second high-order bit (Transitive). See		identical when ignoring the second high-order bit (Transitive). See
	section 2, [RFC4360]. An example allocation would be 0x09/0x49.		section 2, [RFC4360].
	It is suggested to IANA that, when possible, allocations from the		It is suggested to IANA that, when possible, allocations from the
	FlowSpec Transitive/Non-Transitive Extended Community Sub-Types		FlowSpec Transitive/Non-Transitive Extended Community Sub-Types
	registries are made for transitive or non-transitive versions of		registries are made for transitive or non-transitive versions of
	features (section 2, [RFC4360]) that their code point in both		features (section 2, [RFC4360]) that their code point in both
	registries is identical.		registries is identical.
	12. References		9. Normative References
	12.1. Normative References
	[I-D.ietf-idr-rtc-no-rt]
	Rosen, E., Patel, K., Haas, J., and R. Raszuk, "Route
	Target Constrained Distribution of Routes with no Route
	Targets", draft-ietf-idr-rtc-no-rt-06 (work in progress),
	November 2016.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended		[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
	Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,		Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
	February 2006, <http://www.rfc-editor.org/info/rfc4360>.		February 2006, <https://www.rfc-editor.org/info/rfc4360>.
	[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,		[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
	R., Patel, K., and J. Guichard, "Constrained Route		R., Patel, K., and J. Guichard, "Constrained Route
	Distribution for Border Gateway Protocol/MultiProtocol		Distribution for Border Gateway Protocol/MultiProtocol
	Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual		Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
	Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,		Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
	November 2006, <http://www.rfc-editor.org/info/rfc4684>.		November 2006, <https://www.rfc-editor.org/info/rfc4684>.
	[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,		[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
	and D. McPherson, "Dissemination of Flow Specification		and D. McPherson, "Dissemination of Flow Specification
	Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,		Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
	<http://www.rfc-editor.org/info/rfc5575>.		<https://www.rfc-editor.org/info/rfc5575>.
	12.2. Informative References
	[I-D.hares-idr-flowspec-v2]
	Hares, S., "BGP Flow Specification Version 2", draft-
	hares-idr-flowspec-v2-00 (work in progress), June 2016.
	[I-D.uttaro-idr-bgp-persistence]		[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
	Uttaro, J., Chen, E., Decraene, B., and J. Scudder,		"Advertisement of Multiple Paths in BGP", RFC 7911,
	"Support for Long-lived BGP Graceful Restart", draft-		DOI 10.17487/RFC7911, July 2016, <https://www.rfc-
	uttaro-idr-bgp-persistence-03 (work in progress), November		editor.org/info/rfc7911>.
	2013.
	Authors' Addresses		Authors' Addresses
	Stephane Litkowski		Stephane Litkowski
	Orange		Orange
	Email: stephane.litkowski@orange.com		Email: stephane.litkowski@orange.com
	Adam Simpson		Adam Simpson
	Nokia		Nokia
	Email: adam.1.simpson@nokia.com		Email: adam.1.simpson@nokia.com
	skipping to change at page 15, line 19 ¶		skipping to change at page 9, line 22 ¶
	Adam Simpson		Adam Simpson
	Nokia		Nokia
	Email: adam.1.simpson@nokia.com		Email: adam.1.simpson@nokia.com
	Keyur Patel		Keyur Patel
	Arrcus, Inc		Arrcus, Inc
	Email: keyur@arrcus.com		Email: keyur@arrcus.com
	Jeff Haas		Jeffrey Haas
	Juniper Networks		Juniper Networks
	Email: jhaas@juniper.net		Email: jhaas@juniper.net
	Lucy Yong		Lucy Yong
	Huawei		Huawei
	Email: lucy.yong@huawei.com		Email: lucy.yong@huawei.com
End of changes. 57 change blocks.
	414 lines changed or deleted		147 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/