draft-ietf-idr-flowspec-interfaceset-01.txt   draft-ietf-idr-flowspec-interfaceset-02.txt 
Routing Area Working Group S. Litkowski Routing Area Working Group S. Litkowski
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track A. Simpson Intended status: Standards Track A. Simpson
Expires: December 10, 2016 Alcatel Lucent Expires: April 28, 2017 Nokia
K. Patel K. Patel
Cisco Arrcus, Inc
J. Haas J. Haas
Juniper Networks Juniper Networks
June 8, 2016 L. Yong
Huawei
October 25, 2016
Applying BGP flowspec rules on a specific interface set Applying BGP flowspec rules on a specific interface set
draft-ietf-idr-flowspec-interfaceset-01 draft-ietf-idr-flowspec-interfaceset-02
Abstract Abstract
BGP Flow-spec is an extension to BGP that allows for the BGP flowspec is an extension to BGP that allows for the dissemination
dissemination of traffic flow specification rules. The primary of traffic flow specification rules. The primary application of this
application of this extension is DDoS mitigation where the flowspec extension is DDoS mitigation where the flowspec rules are applied in
rules are applied in most cases to all peering routers of the most cases to all peering routers of the network.
network.
This document will present another use case of BGP Flow-spec where This document will present another use case of BGP flowspec where
flow specifications are used to maintain some access control lists at flow specifications are used to maintain some access control lists at
network boundary. BGP Flowspec is a very efficient distributing network boundary. BGP flowspec is a very efficient distributing
machinery that can help in saving OPEX while deploying/updating ACLs. machinery that can help in saving OPEX while deploying/updating ACLs.
This new application requires flow specification rules to be applied This new application requires flow specification rules to be applied
only on a specific subset of interfaces and in a specific direction. only on a specific subset of interfaces and in a specific direction.
The current specification of BGP Flow-spec ([RFC5575]) introduces the The current specification of BGP flowspec ([RFC5575]) introduces the
notion of flow specification (which describes the matching criterion) notion of flow specification (which describes the matching criterion)
and traffic filtering actions. The flow specification is encoded as and traffic filtering actions. The flow specification is encoded as
part of the NLRI while the traffic filtering actions are encoded as part of the NLRI while the traffic filtering actions are encoded as
extended communities. The combination of a flow specification and extended communities. The combination of a flow specification and
one or more actions is known as a flow specification rule. [RFC5575] one or more actions is known as a flow specification rule. [RFC5575]
does not detail where the flow specification rules need to be does not detail where the flow specification rules need to be
applied. applied.
Besides the flow specification and traffic filtering actions, this Besides the flow specification and traffic filtering actions, this
document introduces the notion of traffic filtering scope in order to document introduces the notion of traffic filtering scope in order to
skipping to change at page 2, line 29 skipping to change at page 2, line 29
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 December 10, 2016. This Internet-Draft will expire on April 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 3, line 12 skipping to change at page 3, line 12
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 1.1. Specific filtering for DDoS . . . . . . . . . . . . . . . 3
1.2. ACL maintenance . . . . . . . . . . . . . . . . . . . . . 4 1.2. ACL maintenance . . . . . . . . . . . . . . . . . . . . . 4
2. Collaborative filtering and managing filter direction . . . . 5 2. Collaborative filtering and managing filter direction . . . . 5
3. Traffic filtering scope . . . . . . . . . . . . . . . . . . . 6 3. Traffic filtering scope . . . . . . . . . . . . . . . . . . . 6
4. Interface specific filtering using BGP flowspec . . . . . . . 6 4. Interface specific filtering using BGP flowspec . . . . . . . 7
5. Interface-set extended community . . . . . . . . . . . . . . 8 5. Interface-set extended community . . . . . . . . . . . . . . 8
6. Interaction with permanent traffic filtering rules . . . . . 9 6. Handling rules from different sources in the processing pipe 9
6.1. Interaction with interface ACLs . . . . . . . . . . . . . 9 6.1. Combining Policy Based Routing with BGP flowspec and
6.2. Interaction with flow collection . . . . . . . . . . . . 11 interface-set . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Combining flow collection with BGP flowspec and
interface-set . . . . . . . . . . . . . . . . . . . . . . 11
7. Scaling of per interface rules . . . . . . . . . . . . . . . 11 7. Scaling of per interface rules . . . . . . . . . . . . . . . 11
8. Deployment considerations . . . . . . . . . . . . . . . . . . 11 8. Deployment considerations . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Use case 1. Use case
1.1. Specific filtering for DDoS 1.1. Specific filtering for DDoS
----------------- --- (ebgp) - Peer3 (BW 10G) ----------------- --- (ebgp) - Peer3 (BW 10G)
/ \/ / \/
| /| | /|
| PE --- (ebgp) - Transit1(BW 4x10G) | PE --- (ebgp) - Transit1(BW 4x10G)
Cust1 --- (ebgp) --- PE | Cust1 --- (ebgp) --- PE |
skipping to change at page 4, line 9 skipping to change at page 4, line 11
network owing Customers, Peers and Transit. To protect pro actively network owing Customers, Peers and Transit. To protect pro actively
against some attacks (e.g. DNS, NTP ...), the service provider may against some attacks (e.g. DNS, NTP ...), the service provider may
want to deploy some rate-limiting of some flows on peers and transit want to deploy some rate-limiting of some flows on peers and transit
links. But depending on link bandwidth, the provider may want to links. But depending on link bandwidth, the provider may want to
apply different rate-limiting values. apply different rate-limiting values.
For 4*10G links peer/transit, it may want to apply a rate-limiting of 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 DNS flows of 1G, while on 10G links, the rate-limiting would be set
to 250Mbps. Customer interfaces must not be rate-limited. to 250Mbps. Customer interfaces must not be rate-limited.
BGP Flow-spec infrastructure may already be present on the network, BGP flowspec infrastructure may already be present on the network,
and all PEs may have a BGP session running flowspec address family. and all PEs may have a BGP session running flowspec address family.
The Flowspec infrastructure may be reused by the service provider to The flowspec infrastructure may be reused by the service provider to
implement such rate-limiting in a very quick manner and being able 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 adjust values in future quickly without having to configure each node
one by one. Using the current BGP flowspec specification, it would one by one. Using the current BGP flowspec specification, it would
not be possible to implement different rate limiter on different not be possible to implement different rate limiter on different
interfaces of a same router. The flowspec rule is applied to all interfaces of a same router. The flowspec rule is applied to all
interfaces in all directions or on some interfaces where flowspec is interfaces in all directions or on some interfaces where flowspec is
activated but flowspec rule set would be the same among all activated but flowspec rule set would be the same among all
interfaces. interfaces.
Section Section 4 will detail a solution to address this use case Section Section 4 will detail a solution to address this use case
using BGP Flowspec. using BGP flowspec.
1.2. ACL maintenance 1.2. ACL maintenance
--------------- --- (ebgp) - Cust4_VPN --------------- --- (ebgp) - Cust4_VPN
/ \/ / \/
Cust1_INT -- (ebgp) --- PE /| Cust1_INT -- (ebgp) --- PE /|
| PE ------ (ebgp) - Transit1 | PE ------ (ebgp) - Transit1
Cust3_VPN -- (ebgp) --- PE | Cust3_VPN -- (ebgp) --- PE |
| PE ------ (ebgp) - Peer2 | PE ------ (ebgp) - Peer2
| \| | \|
skipping to change at page 4, line 48 skipping to change at page 4, line 50
---------------- ----------------
Figure 2 Figure 2
The figure 1 above displays a typical service provider multiservice The figure 1 above displays a typical service provider multiservice
network owing Customers, Peers and Transit for Internet, as well as network owing Customers, Peers and Transit for Internet, as well as
VPN services. The service provider requires to ensure security of VPN services. The service provider requires to ensure security of
its infrastructure by applying ACLs at network boundary. Maintaining its infrastructure by applying ACLs at network boundary. Maintaining
and deploying ACLs on hundreds/thousands of routers is really painful and deploying ACLs on hundreds/thousands of routers is really painful
and time consuming and a service provider would be interested to and time consuming and a service provider would be interested to
deploy/updates ACLs using BGP Flowspec. In this scenario, depending deploy/updates ACLs using BGP flowspec. In this scenario, depending
on the interface type (Internet customer, VPN customer, Peer, Transit on the interface type (Internet customer, VPN customer, Peer, Transit
...) the content of the ACL may be different. ...) the content of the ACL may be different.
We foresee two main cases : We foresee two main cases :
o Maintaining complete ACLs using flowspec : in this case all the o Maintaining complete ACLs using flowspec : in this case all the
ingress ACL are maintained and deployed using BGPFlowspec. See ingress ACL are maintained and deployed using BGPflowspec. See
section Section 9 for more details on security aspects. section Section 9 for more details on security aspects.
o Requirement of a quick deployment of a new filtering term due to a o Requirement of a quick deployment of a new filtering term due to a
security alert : new security alerts often requires a fast security alert : new security alerts often requires a fast
deployment of new ACL terms. Using traditional CLI and hop by hop deployment of new ACL terms. Using traditional CLI and hop by hop
provisioning, such deployment takes time and network is provisioning, such deployment takes time and network is
unprotected during this time window. Using BGP flowspec to deploy unprotected during this time window. Using BGP flowspec to deploy
such rule, a service provider can protect its network in few such rule, a service provider can protect its network in few
seconds. Then the SP can decide to keep the rule permanently in seconds. Then the SP can decide to keep the rule permanently in
BGP Flowspec or update its ACL or remove the entry (in case BGP flowspec or update its ACL or remove the entry (in case
equipments are not vulnerable anymore). equipments are not vulnerable anymore).
Section Section 4 will detail a solution to address this use case Section Section 4 will detail a solution to address this use case
using BGP Flowspec. using BGP flowspec.
2. Collaborative filtering and managing filter direction 2. Collaborative filtering and managing filter direction
[RFC5575] states in Section 5. : "This mechanism is primarily [RFC5575] states in Section 5. : "This mechanism is primarily
designed to allow an upstream autonomous system to perform inbound designed to allow an upstream autonomous system to perform inbound
filtering in their ingress routers of traffic that a given downstream filtering in their ingress routers of traffic that a given downstream
AS wishes to drop.". AS wishes to drop.".
In case of networks collaborating in filtering, there is a use case In case of networks collaborating in filtering, there is a use case
for performing outbound filtering. Outbound filtering allows to for performing outbound filtering. Outbound filtering allows to
skipping to change at page 6, line 5 skipping to change at page 6, line 23
/ \ / \
| MyAS | | MyAS |
\ / \ /
----------------------- -----------------------
Figure 3 Figure 3
In the figure above, MyAS is connected to an upstream provider. If a In the figure above, MyAS is connected to an upstream provider. If a
malicious traffic comes in from the upstream provider, it may malicious traffic comes in from the upstream provider, it may
congestion P1 or P2 links. If MyAS apply inbound filtering on P1/P2 congestion P1 or P2 links. If MyAS apply inbound filtering on P1/P2
using BGP Flowspec, the congestion issue will not be solved. using BGP flowspec, the congestion issue will not be solved.
Using collaborative filtering, the upstream provider may propose to Using collaborative filtering, the upstream provider may propose to
MyAS to filter malicious traffic sent to it. We propose to enhance MyAS to filter malicious traffic sent to it. We propose to enhance
[RFC5575] to make myAS able to send BGP FlowSpec updates (on eBGP [RFC5575] to make myAS able to send BGP flowspec updates (on eBGP
sessions) to the upstream provider to request outbound filtering on sessions) to the upstream provider to request outbound filtering on
peering interfaces towards MyAS. When the upstream provider will peering interfaces towards MyAS. When the upstream provider will
receive the BGP Flowspec update from MyAS, the BGP flowspec update receive the BGP flowspec update from MyAS, the BGP flowspec update
will contain request for outbound filtering on a specific set of will contain request for outbound filtering on a specific set of
interfaces. The upstream provider will apply automatically the interfaces. The upstream provider will apply automatically the
requested filter and congestion will be prevented. requested filter and congestion will be prevented.
3. Traffic filtering scope 3. Traffic filtering scope
We see with the use case described above that some BGP flowspec rules 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 may need to be applied only on specific elements of the network
(interfaces, nodes ...). The basic specification detailed in (interfaces, nodes ...). The basic specification detailed in
[RFC5575] does not address this and does not give any detail on where [RFC5575] does not address this and does not give any detail on where
the traffic filtering rule need to be applied. the traffic filtering rule need to be applied.
In addition to the flow specification (flow matching criterion) and In addition to the flow specification (flow matching criterion) and
traffic filtering actions described in [RFC5575], this document traffic filtering actions described in [RFC5575], this document
introduces the notion of traffic filtering scope. The traffic introduces the notion of traffic filtering scope. The traffic
filtering scope will describe where a particular flow specification filtering scope will describe where a particular flow specification
rule must be applied. rule must be applied.
Using a traffic filtering scope in a BGP Flow spec rule is optional. Using a traffic filtering scope in a BGP flowspec rule is optional.
When a rule does not contain any traffic filtering scope parameter, When a rule does not contain any traffic filtering scope parameter,
[RFC5575] applies. [RFC5575] applies.
4. Interface specific filtering using BGP flowspec 4. Interface specific filtering using BGP flowspec
The use case detailed above requires application of different BGP The use case detailed above requires application of different BGP
Flowspec rules on different set of interfaces. flowspec rules on different set 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 apply on. 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 5).
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 : Considering figure 2, 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.
skipping to change at page 8, line 40 skipping to change at page 9, line 8
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 input
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 coded as a 14-bit number (values goes from 0
to 16383). to 16383).
Multiple instances of the interface-set community may be present in a 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 BGP update. This may appear if the flow rule need to be applied to
multiple set of interfaces. multiple set of interfaces.
skipping to change at page 9, line 17 skipping to change at page 9, line 31
interface-set communities with group ID 1 and group ID 2, the filter 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 would need to be installed on interfaces belonging to Group ID 1 or
Group ID 2. Group ID 2.
As using a Route Target, route distribution of flowspec NLRI with As using a Route Target, route distribution of flowspec NLRI with
interface-set may be subject to constrained distribution as defined interface-set may be subject to constrained distribution as defined
in [RFC4684]. Constrained route distribution for flowspec routes in [RFC4684]. Constrained route distribution for flowspec routes
using interface-set requires discussion and will be addressed in a using interface-set requires discussion and will be addressed in a
future revision of the document. future revision of the document.
6. Interaction with permanent traffic filtering rules 6. Handling rules from different sources in the processing pipe
[RFC5575] states that BGP Flowspec is primarily designed to allow A packet on a router may be processed by multiple rules that are
upstream AS to perform inbound filtering in their ingress routers. originated by different sources (e.g. statically configured, I2RS
This specification does not precise where this ingress filtering ephemeral, BGP ephemeral ...). [RFC5575] does not provide any
should happen in the packet processing pipe. 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 proposal enhances [RFC5575] in order to add rules for traffic This document only addresses the usage of "interface-set" in the
coming from or going to specific interfaces. Based on this framework of [RFC5575] and the following generic rules SHOULD be used
enhancement, some new requirements come to implementations. by an implementation:
An implementation SHOULD apply input actions (I bit set) within the o An inbound flowspec rule using interface-set SHOULD be processed
input packet processing pipe. An implementation SHOULD apply output after all existing inbound traffic processing rules (ACL, PBR,
actions (O bit set) within the output packet processing pipe. QoS, flow collection ...) and SHOULD be applied before forwarding
decision is made.
As input and output processing pipes may also involve already present o An outbound flowspec rule using interface-set SHOULD be processed
static/permanent features that will manipulate the packet, the next after all existing outbound traffic processing rules (ACL, PBR,
sections will try to clarify how the static behaviors should interact QoS, flow collection ...) and SHOULD be applied after forwarding
will BGP flowspec actions. decision has been made.
6.1. Interaction with interface ACLs Inbound processing Forwarding Outbound processing
ACL->PBR->BGP_FS in -> Lookup -> PBR->QoS->I2RS->BGP_FS out
Deploying interface specific filters using BGP FlowSpec (dynamic Example of packet processing pipe
entries) may interfere with existing permanent interface ACL (static
entries). The content of the existing permanent ACL MUST NOT be
altered by dynamic entries coming from BGP FlowSpec. Permanent ACLs
are using a specific ordering which is not compatible with the
ordering of FS rules and misordering of ACL may lead to undesirable
behaviour. In order, to keep a deterministic and well known
behaviour, an implementation SHOULD process the BGP FlowSpec ACL as
follows :
o In inbound direction, the permanent ACL action is applied first In the example above, any BGP flowspec rule ([RFC5575]) with an
followed by FlowSpec action. This gives the primary action to the inbound interface-set is processed after all existing features (ACL,
permanent ACL as it is done today. 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.
o In outbound direction, FlowSpec action is applied first followed This section gives two examples of combining existing features with
by permanent ACL. This gives the final action to the permanent BGP flowspec+interface-set attribute on an interface.
ACL as it is done today.
Inbound filters Outbound filters 6.1. Combining Policy Based Routing with BGP flowspec and interface-set
--------- ------- ---------- ------- ---------
|Permanent| -> |Dynamic| -> |Forwarding| -> |Dynamic| -> |Permanent|
In order for a flow to be accepted, the flow must be accepted by the In this example, a router has an already configured inbound policy on
two ACLs and a flow is rejected when one of the ACL rejects it as an interface IF1 with the following rules:
described in the table below :
+-------------------------+--------------------------+--------------+ o Static policy IN:
| Permanent ACL entry | FlowSpec ACL entry | Result |
| action | action | action |
+-------------------------+--------------------------+--------------+
| Drop | Drop | Drop |
| Drop | Accept | Drop |
| Accept | Drop | Drop |
| Accept | Accept | Accept |
+-------------------------+--------------------------+--------------+
Example : * Entry 1: from udp 10/8 to 11/8 port 53 then set dscp af11 and
accept
o ACL permanent IN : * Entry 2: from tcp 10/8 to 11/8 port 22 then set dscp af22 and
accept
* Entry 1 : permit udp from 10/8 to 11/8 port 53 * Entry 3: from tcp 10/8 to 11/8 port 80 then set dscp af11 and
accept
* Entry 2 : permit tcp from 10/8 to 11/8 port 22 * Entry 4: from ip 10/8 to 11/8 then drop
* Entry 3 : deny ip from 10/8 to 11/8 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 ACL dynamic FlowSpec IN : o flowspec rules IN :
* Entry 1 : deny udp from 10.0.0.1/32 to 11/8 port 53 * from udp 10.0.0.1/32 to 11/8 port 53 then drop
* Entry 2 : permit tcp from 10/8 to 11/8 port 80 * from tcp 10/8 to 11/8 port 80 then set dscp af32 and accept
In the example above : * from udp 10/8 to 11/8 then accept
o a UDP flow from 10.0.0.1 to 11.0.0.2 on port 53 will be rejected The combination of the static inbound ACL and the inbound "interface-
because the dynamic ACL rejects it. 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 o a UDP flow from 10.0.0.2 to 11.0.0.2 on port 53 will be accepted
because both ACLs accept it. 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 rejected o a TCP flow from 10.0.0.2 to 11.0.0.2 on port 80 will be accepted
because permanent ACL rejects it. and DSCP will be set to af32: firstly, the static PBR rule set the
DSCP to af11 and accepts the packet, then the flowspec filter
rewrites the DSCP to af32 and accepts it also.
6.2. Interaction with flow collection 6.2. Combining flow collection with BGP flowspec and interface-set
A router may activate flow collection features (used in collaboration A router may activate flow collection features (used in collaboration
with Netflow export). Flow collection can be done at input side or with Netflow export). Flow collection can be done at input side or
output side. As for ACL, an implementation SHOULD process : output side. When a router is configured to collect flow
informations on an inbound interface, the flow collection happens
o BGP FS rules after the inbound flow collection : in case of DDoS before any BGP flowspec rule with interface-set: if a particular
protection, it is important to keep monitoring of attack flows and packet flow is denied by a BGP flowspec rule, it will still be
so performing action, after collection. collected.
o BGP FS rules before the outbound flow collection : purpose of
outbound flow collection is really to track flows that are exiting
the interface. BGP FS rules should not interfere in this.
Inbound Outbound The same happens if a router is configured to collect flow
Flow BGP BGP Flow informations on an outbound interface, the flow collection happens,
collection FS FS collection and then the BGP flowspec rule is applied: the flow is collected
--------- ------- ---------- ------- --------- whatever the result of the BGP flowspec rule.
|Permanent| -> |Dynamic| -> |Forwarding| -> |Dynamic| -> |Permanent|
7. Scaling of per interface rules 7. Scaling of per interface rules
Creating rules that are applied on specific interfaces may create Without "interface-set", all the interfaces are using the same
forwarding rules that may be harder to share. flowspec filter, while with "interface-set" different interfaces may
have different flowspec filters (with different terms and actions).
Having such flowspec rules that are applied on specific interfaces
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 An implementation SHOULD take care about trying to keep sharing
forwarding structures as much as possible in order to limit the forwarding structures as much as possible in order to limit the
scaling impact. How the implementation would do so is out of scope scaling impact. How the implementation would do so is out of scope
of the document. of the document.
8. Deployment considerations 8. Deployment considerations
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 to be deployed in
order to ensure that all paths (NLRI+interface-set group-id+actions) order to ensure that all paths (NLRI+interface-set group-id+actions)
are propagated within the BGP control plane. Without ADD-PATH, only are propagated within the BGP control plane. Without ADD-PATH, only
a single "NLRI+interface-set group-id+actions" will be propagated, so a single "NLRI+interface-set group-id+actions" will be propagated, so
some filtering rules will never be applied. some filtering rules will never be applied.
9. Security Considerations 9. Security Considerations
Managing permanent Access Control List by using BGP Flowspec as Managing permanent Access Control List by using BGP flowspec as
described in Section 1.2 helps in saving roll out time of such ACL. described in Section 1.2 helps in saving roll out time of such ACL.
However some ACL especially at network boundary are critical for the However some ACL especially at network boundary are critical for the
network security and loosing the ACL configuration may lead to network security and loosing the ACL configuration may lead to
network open for attackers. network open for attackers.
By design, BGP flowspec rules are ephemeral : the flow rule exists in By design, BGP flowspec rules are ephemeral : the flow rule exists in
the router while the BGP session is UP and the BGP path for the rule the router while the BGP session is UP and the BGP path for the rule
is valid. We can imagine a scenario where a Service Provider is is valid. We can imagine a scenario where a Service Provider is
managing the network boundary ACLs by using only FlowSpec. In this managing the network boundary ACLs by using only flowspec. In this
scenario, if , for example, an attacker succeed to make the internal 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 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 the node, as flowspec rules will disappear due to the BGP session
down. down.
In reality, the chance for such attack to occur is low, as boundary In reality, the chance for such attack to occur is low, as boundary
ACLs should protect the BGP session from being attacked. ACLs should protect the BGP session from being attacked.
In order to complement the BGP flowspec solution is such deployment In order to complement the BGP flowspec solution is such deployment
scenario and provides security against such attack, a service scenario and provides security against such attack, a service
provider may activate Long lived Graceful Restart provider may activate Long lived Graceful Restart
[I-D.uttaro-idr-bgp-persistence] on the BGP session owning Flowspec [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 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 of flowspec rules would be retained and the flowspec action will be
retained. retained.
10. Acknowledgements 10. 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 11. IANA Considerations
This document requests a new type from the "BGP Transitive Extended This document requests a new type from the "BGP Transitive Extended
skipping to change at page 13, line 41 skipping to change at page 14, line 12
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, <http://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>. <http://www.rfc-editor.org/info/rfc5575>.
12.2. Informative References 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] [I-D.uttaro-idr-bgp-persistence]
Uttaro, J., Chen, E., Decraene, B., and J. Scudder, Uttaro, J., Chen, E., Decraene, B., and J. Scudder,
"Support for Long-lived BGP Graceful Restart", draft- "Support for Long-lived BGP Graceful Restart", draft-
uttaro-idr-bgp-persistence-03 (work in progress), November uttaro-idr-bgp-persistence-03 (work in progress), November
2013. 2013.
Authors' Addresses Authors' Addresses
Stephane Litkowski Stephane Litkowski
Orange Orange
skipping to change at page 14, line 4 skipping to change at page 14, line 28
"Support for Long-lived BGP Graceful Restart", draft- "Support for Long-lived BGP Graceful Restart", draft-
uttaro-idr-bgp-persistence-03 (work in progress), November uttaro-idr-bgp-persistence-03 (work in progress), November
2013. 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
Alcatel Lucent Nokia
Email: adam.simpson@alcatel-lucent.com Email: adam.simpson@nokia.com
Keyur Patel Keyur Patel
Cisco Arrcus, Inc
Email: keyupate@cisco.com Email: keyur@arrcus.com
Jeff Haas Jeff Haas
Juniper Networks Juniper Networks
Email: jhaas@juniper.net Email: jhaas@juniper.net
Lucy Yong
Huawei
Email: lucy.yong@huawei.com
 End of changes. 71 change blocks. 
125 lines changed or deleted 131 lines changed or added

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