Inter-Domain Routing Area Working Group                                        S. Litkowski
Internet-Draft                                                    Orange
Intended status: Standards Track                              A. Simpson
Expires: September 12, 2017 December 30, 2018                                         Nokia
                                                                K. Patel
                                                             Arrcus, Inc
                                                                 J. Haas
                                                        Juniper Networks
                                                                 L. Yong
                                                                  Huawei
                                                          March 11, 2017
                                                           June 28, 2018

        Applying BGP flowspec rules on a specific interface set
                draft-ietf-idr-flowspec-interfaceset-03
                draft-ietf-idr-flowspec-interfaceset-04

Abstract

   The BGP flowspec is an Flow Specification (flowspec) Network Layer Reachability
   Information (BGP NLRI) extension ([RFC5575]) is used to BGP that allows for the dissemination
   of distribute
   traffic flow specification rules. specifications into BGP.  The primary application of
   this extension is DDoS mitigation where the flowspec rules are applied in
   most cases to all peering routers distribution of traffic filtering policies for
   the network.

   This document will present another use case mitigation of BGP flowspec where distributed denial of service (DDoS) attacks.

   By default, flow specifications specification filters are used to maintain some access control lists at
   network boundary. applied on all forwarding
   interfaces that are enabled for use by the BGP flowspec is extension.  A
   network operator may wish to apply a very efficient distributing
   machinery that can help in saving OPEX while deploying/updating ACLs.
   This new application requires flow specification rules given filter selectively 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
   document introduces the notion based on an internal classification scheme.
   Examples of traffic filtering scope in order to
   drive where a particular rule must be applied.  In particular, this include "all customer interfaces", "all peer
   interfaces", "all transit interfaces", etc.

   This document introduces the "interface-set" traffic filtering scope defines BGP Extended Communities ([RFC4360]) that
   could
   permit such filters to be used in parallel of traffic filtering actions (marking,
   rate-limiting ...).  The purpose of this extension is selectively applied to inform
   remote routers about groups sets of forwarding
   interfaces where the rule must be
   applied.

   This extension can also be used in a DDoS mitigation context where sharing a
   provider wants common group identifier.  The BGP Extended
   Communities carrying this group identifier are referred to apply as the filtering only on specific peers. BGP
   Flowspec "interface-set" Extended Communities.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 12, 2017. December 30, 2018.

Copyright Notice

   Copyright (c) 2017 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Use case  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Specific filtering for DDoS . . . . . . . . . . . . . . .   3
     1.2.  ACL maintenance . . . . . . . . . . . . . . . . . . . . .   4
   2.  Collaborative filtering and managing filter direction . . . .   5
   3.  Traffic filtering scope . . . . . . . . . . . . . . . . . . .   6
   4.  Interface specific filtering using BGP flowspec . . . . . . .   7
   5.   3
   3.  Interface-set extended community  . . . . . . . . . . . . . .   8
   6.  Handling   4
   4.  Scaling of per-interface rules from different sources in the processing pipe    9
     6.1.  Combining Policy Based Routing with BGP flowspec and
           interface-set . . . . .  . . . . . . . . . . . . . . .   6
   5.  Deployment Considerations . .  10
     6.2.  Combining flow collection with BGP flowspec and
           interface-set . . . . . . . . . . . . . . . .   6
     5.1.  Add-Paths . . . . . .  11
   7.  Scaling of per interface rules . . . . . . . . . . . . . . .  11
   8.  Deployment considerations . . .   6
     5.2.  Inter-domain Considerations . . . . . . . . . . . . . . .  12
   9.   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10.   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   11.   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     11.1.   7
     8.1.  FlowSpec Transitive Extended Communities  . . . . . . . .  13
     11.2.   7
     8.2.  FlowSpec Non-Transitive Extended Communities  . . . . . .  13
     11.3.   7
     8.3.  FlowSpec interface-set Extended Community . . . . . . .  13
     11.4. .   8
     8.4.  Allocation Advice to IANA . . . . . . . . . . . . . . .  13
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     12.1.   8
   9.  Normative References  . . . . . . . . . . . . . . . . . .  14
     12.2.  Informative References . . . . . . . . . . . . . . . . .  14   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14   9

1.  Use case

1.1.  Specific filtering for DDoS

                       -----------------    --- (ebgp) - Peer3 (BW 10G)
                      /                  \/
                     |                   /|
                     |                PE --- (ebgp) - Transit1(BW 4x10G)
 Cust1 --- (ebgp) --- PE                  |
                     |                PE ---- (ebgp) - Peer2 (BW 4*10G)
                     |                   \|
 Cust2 --- (ebgp) --- PE                  |----- (ebgp) - Customer3
                    /|                    |
 Peer1(BW10G)-(ebgp) |                PE --- (ebgp) - Transit2(BW 4x10G)
                     |                    |
                      \                  /
                       ------------------

                                    Figure 1

   The figure 1 above displays

   While 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 provide connectivity to deploy some rate-limiting a homogenous class 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,
   users, it may want often provides connectivity to apply a rate-limiting different groups of
   DNS flows users.
   The nature of 1G, while these different groups, and how they're classified,
   varies based 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 purpose of the network.  In an enterprise
   network, connectivity may exist between data centers, offices, and all PEs may have
   external connectivity.  In a BGP session running flowspec address family.
   The flowspec infrastructure virtual private networking (VPN)
   network, it may be reused by consist of customers in different sites connected
   through a VPN, the service provider to
   implement core network, and external networks such rate-limiting in
   as the Internet.  In a very quick manner and being able to
   adjust values in future quickly without having to configure each node
   one by one.  Using traditional Internet service provider (ISP)
   network, the current network may consist of points of presence (POPs),
   internal infrastructure networks, customer networks, peer networks,
   and transit networks.

   The BGP flowspec specification, it would
   not extension permits traffic filters to be possible distributed
   to implement different rate limiter on different
   interfaces of routers throughout a same router.  The flowspec rule is network.  However, these filters often should
   not be uniformly applied to all
   interfaces in all directions or network interfaces.  As an example, a
   rate-limiting filter applied to the SMTP protocol may be applied to
   customer networks, but not other networks.  Similarly, a DDoS attack
   on some interfaces where flowspec is
   activated the SSH protocol may be deemed appropriate to drop at upstream
   peering routers but not customer routers.

   By default, BGP flowspec rule set would be the same among filters are applied at all
   interfaces.

   Section Section 4 will detail interfaces that
   permit flowspec filters to be installed.  What is needed is a solution way to address this use case
   selectively apply those filters to subsets of interfaces in a
   network.

2.  Interface specific filtering 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 flowspec

   The figure 1 uses case detailed 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 require application of
   its infrastructure by applying ACLs at network boundary.  Maintaining
   and deploying ACLs different BGP
   flowspec rules on hundreds/thousands different sets of routers is really painful
   and time consuming and a service provider would be interested interfaces.

   We propose to
   deploy/updates ACLs using introduce, within BGP flowspec.  In this scenario, depending
   on the interface type (Internet customer, VPN customer, Peer, Transit
   ...) the content flowspec, a traffic filtering
   scope that identifies a group of the ACL may interfaces where a particular filter
   should 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 applied.  Identification of interfaces within BGP flowspec
   will be done through group identifiers.  A group identifier marks a quick deployment
   set of interfaces sharing 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, common administrative property.  Like 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 community, the entry (in case
      equipments are group identifier itself does 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 have any
   significance.  It is primarily
   designed up to allow an upstream autonomous system the network administrator to perform inbound
   filtering in their ingress routers of traffic that associate a given downstream
   AS wishes
   particular meaning 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 group identifier value (e.g. group ID#1
   associated to prevent
   impact like congestions.

             ----------------------
           /                        \
           |   Upstream provider     |
           \                        /
             -----------------------
               |                |
               |P2              |P1
             ----------------------
           /                        \
           |        MyAS             |
           \                        /
             -----------------------

                   Figure 3

   In the figure above, MyAS Internet customer interfaces).  The group identifier is connected to an upstream provider.  If
   a
   malicious traffic comes in from the upstream provider, it local interface property.  Any interface may
   congestion P1 be associated with one
   or P2 links.  If MyAS apply inbound filtering on P1/P2 more group identifiers using manual configuration.

   When a filtering rule advertised through BGP flowspec, the congestion issue will not flowspec must 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 applied
   only to send particular sets of interfaces, the BGP flowspec updates (on eBGP
   sessions) to BGP UPDATE
   will contain 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 identifiers associated with the use case described above that some BGP flowspec rules
   may need to be applied only on specific elements relevant sets 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.
   interfaces.  In addition to the flow specification (flow matching criterion) and
   traffic filtering actions described in [RFC5575], this document
   introduces group identifiers, it will also
   contain the direction the notion of traffic filtering scope.  The traffic filtering scope will describe where a particular flow specification rule must be applied.

   Using a traffic filtering scope applied in a BGP flowspec rule is optional.
   When a rule does not contain any traffic filtering scope parameter,
   [RFC5575] applies.

4.  Interface specific filtering using BGP flowspec

   The use case detailed above requires application of different BGP
   flowspec rules on different set (see
   Section 3).

   Configuration of interfaces.

   We propose to introduce, within BGP flowspec, a traffic filtering
   scope that identifies a group of interfaces where a particular filter
   should apply on.  Identification of identifiers associated to interfaces within may
   change over time.  An implementation MUST ensure that the filtering
   rules (learned from BGP flowspec
   will be done through group identifiers.  A group identifier marks a
   set of interfaces sharing a common administrative property.  Like flowspec) applied to a
   BGP community, particular interface
   are always updated when the group identifier itself does not have any
   significance.  It is up to the network administrator to associate a
   particular meaning to a group identifier value (e.g. group ID#1
   associated to Internet customer interfaces).  The group identifier is
   a local interface property.  Any interface may be associated with one
   or more group identifiers using manual configuration.

   When a filtering rule advertised through BGP flowspec must be applied
   only to particular sets of interfaces, the BGP flowspec BGP update
   will contain the identifiers associated with the relevant sets of
   interfaces.  In addition to the group identifiers, it will also
   contain the direction the filtering rule must be applied in (see
   Section 5).

   Configuration of group identifiers associated to interfaces may
   change over time.  An implementation MUST ensure that the filtering
   rules (learned from BGP flowspec) applied to a particular interface
   are always updated when the group identifier mapping mapping is changing.

   Considering figure 2,

   As an example, we can imagine the following design :

   o  Internet customer interfaces are associated with group-identifier
      1.

   o  VPN customer interfaces are associated with group-identifier 2.

   o  All customer interfaces are associated with group-identifier 3.

   o  Peer interfaces are associated with group-identifier 4.

   o  Transit interfaces are associated with group-identifier 5.

   o  All external provider interfaces are associated with group-
      identifier 6.

   o  All interfaces are associated with group-identifier 7.

   If the service provider wants to deploy a specific inbound filtering
   on external provider interfaces only, the provider can send the BGP
   flow specification using group-identifier 6 and including for the inbound
   direction.

   There are some cases where nodes are dedicated to specific functions
   (Internet peering, Internet Edge, VPN Edge, Service Edge ...), in
   this kind of scenario, there is an interest for a constrained
   distribution of filtering rules that are using the interface specific
   filtering.  Without the constrained route distribution, all nodes
   will received all the filters even if they are not interested in
   those filters.  Constrained route distribution of flowspec filters
   would allow for a more optimized distribution.

5.  Interface-set extended community

   This document proposes a new BGP Route Target extended community
   called "flowspec interface-set".  This document so expands the
   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
   values specified in [RFC4360]).

   In order to ease intra-AS and inter-AS use cases, this document
   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 :

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type (TBD)   |      0x02     |    Autonomous System Number   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :     AS Number (cont.)         |O|I|      Group Identifier     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The flags are :

   o  O : if set, the flow specification rule MUST be applied in
      outbound direction to the interface set referenced by the
      following group-identifier.

   o  I : if set, the flow specification rule MUST be applied in input
      direction to the interface set referenced by the following group-
      identifier.

   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
   interface-set extended community with both flags set to zero 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
   need to propagate the filter informations in the network.

   The Group Identifier is coded as a 14-bit number (values goes from 0
   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 scenario, there is an interest for a Route Target, route constrained
   distribution of flowspec NLRI with
   interface-set may be subject to filtering rules that are using the interface specific
   filtering.  Without the constrained distribution as defined
   in [RFC4684].  Constrained route distribution for flowspec routes
   using interface-set requires discussion and distribution, all nodes
   will be addressed in a
   future revision of the document.

6.  Handling rules from different sources in received all the processing pipe

   A packet on a router may be processed by multiple rules that filters even if they are
   originated by different sources (e.g. statically configured, I2RS
   ephemeral, BGP ephemeral ...).  [RFC5575] does not provide any
   guidance regarding the precedence interested in
   those filters.  Constrained route distribution of BGP flowspec rules compared to
   other sources.  A filters
   would allow for a more optimized distribution.

3.  Interface-set extended community

   This document proposes a new version of BGP flowspec
   [I-D.hares-idr-flowspec-v2] should address these precedence rules
   definition in future. Route Target extended community
   called the "flowspec interface-set".  This document only addresses expands the usage
   definition of "interface-set" in the
   framework Route Target extended community to allow a new
   value of [RFC5575] and the following generic rules SHOULD high order octet (Type field) to be used
   by an implementation:

   o  An inbound 0x07 for the transitive
   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 extended community, or 0x47 for the non-
   transitive flowspec interface-set extended community.  These are in
   addition to the values specified in [RFC4360].

   This new BGP Route Target extended community is made. encoded as follows :

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 0x07 or 0x47  |      0x02     |    Autonomous System Number   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :     AS Number (cont.)         |O|I|      Group Identifier     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The flags are :

   o  An outbound flowspec rule using interface-set SHOULD be processed
      after all existing outbound traffic processing rules (ACL, PBR,
      QoS,  O : if set, the flow collection ...) and SHOULD specification rule MUST 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 direction to 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 referenced by the
      following unordered BGP flowspec version 1 rules with an interface-
   set matching IF1. group-identifier.

   o  flowspec rules IN  I :

      *  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 if set, the following packet processing:

   o  a UDP flow from 10.0.0.1 to 11.0.0.2 on port 53 will specification rule MUST be rejected:
      firstly, it is allowed by applied in inbound
      direction to the static ACL and DSCP is interface set to af11
      but then it is dropped referenced 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 following group-
      identifier.

   Both flags can be set at the same time in the interface-set extended
   community leading to af11.

   o  a TCP flow from 10.0.0.2 rule to 11.0.0.2 on port 80 will be accepted
      and DSCP will be applied in both directions.  An
   interface-set extended community with both flags set to af32: firstly, the static PBR rule set zero MUST be
   treated as an error and as consequence, the
      DSCP flowspec update MUST be
   discarded.  As having no direction indicated as no sense, there is no
   need to af11 and accepts the packet, then propagate the flowspec filter
      rewrites informations in the network.

   The Group Identifier is encoded as a 14-bit number, values 0..16383.

   Multiple instances of the DSCP to af32 and accepts it also.

6.2.  Combining flow collection with BGP flowspec and interface-set

   A router extended community may activate flow collection features (used in collaboration
   with Netflow export).  Flow collection can be done at input side or
   output side.  When
   present in a router is configured to collect flow
   informations on an inbound interface, the flow collection happens
   before any BGP update.  This may occur if the flowspec rule with interface-set: if a particular
   packet flow is denied by needs
   to be applied to multiple sets of interfaces.

   Multiple instances of the extended community in a BGP flowspec rule, it will still update MUST be
   collected.

   The same happens
   interpreted as a "OR" operation.  For example, if a router is configured to collect flow
   informations on an outbound interface, the flow collection happens,
   and then the BGP flowspec rule is applied: the flow is collected
   whatever UPDATE
   contains two interface-set extended communities with group ID 1 and
   group ID 2, the result filter would need to be installed on interfaces
   belonging to Group ID 1 or Group ID 2.

   Similar to using a Route Target extended community, route
   distribution of the BGP flowspec rule.

7. NLRI with interface-set extended communities
   may be subject to constrained distribution as defined in [RFC4684].

4.  Scaling of per interface per-interface rules

   Without "interface-set", all the interfaces are using

   In the same absence of an interface-set extended community, a flowspec filter, while with "interface-set"
   filter is applied to all flowspec enabled interfaces.  When
   interface-set extended communities are present, different interfaces
   may have different flowspec filters (with filtering rules, with different terms and actions).
   Having such flowspec actions.
   These differing rules that are applied on specific interfaces
   may create forwarding instructions that may be make it harder to share forwarding
   instructions within the forwarding plane: a particular term may be present or not in plane.

   Flowspec implementations supporting the
   filter of a particular interface.

   An implementation interface-set extended
   community SHOULD take care about trying to keep sharing
   forwarding structures as much as possible in order to limit minimize the scaling impact.  How the implementation would do so impact in such
   circumstances.  How this is accomplished is out of the scope of the this
   document.

8.

5.  Deployment considerations Considerations

5.1.  Add-Paths

   There are some cases where a particular BGP flowspec NLRI may be
   advertised to different interface groups with a different action.
   For example, a service provider may want to discard all ICMP traffic
   from customer interfaces to infrastructure addresses and want to
   rate-limit the same traffic when it comes from some internal
   platforms.  These particular cases require ADD-PATH ([RFC7911]) to be
   deployed in order to ensure that all paths (NLRI+interface-set group-id+actions) group-
   id+actions) are propagated within the BGP control plane.  Without
   ADD-PATH, only a single "NLRI+interface-set group-id+actions" will be
   propagated, so some filtering rules will never be applied.

9.  Security

5.2.  Inter-domain Considerations

   Managing permanent Access Control List

   The Group Identifier used by using BGP flowspec as
   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
   network security and loosing the ACL configuration may lead interface-set extended community has
   local significance to
   network open for attackers.

   By design, BGP its provisioning Autonomous System.  While
   [RFC5575] permits inter-as advertisement of flowspec rules are ephemeral : the flow rule exists in
   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
   managing the network boundary ACLs by using only flowspec.  In this
   scenario, if , for example, an attacker succeed NLRI, care must
   be taken to make the internal
   BGP session not accept these communities when they would result in
   unacceptable filtering policies.

   Filtering of a router to interface-set extended communities at Autonomous System
   border routers (ASBRs) may thus be down , it can open all boundary ACLs on
   the node, as flowspec rules will disappear due to desirable.

   Note that the BGP session
   down.

   In reality, default behavior without the chance for such attack interface-set feature
   would to occur is low, as boundary
   ACLs should protect the BGP session from being attacked.

   In order have been to complement install the BGP flowspec solution is such deployment
   scenario and provides security against such attack, a service
   provider may activate Long lived Graceful Restart
   [I-D.uttaro-idr-bgp-persistence] filter on the BGP session owning all flowspec
   address family.  So in case
   enabled interfaces.

6.  Security Considerations

   This document extends the Security Considerations of BGP session [RFC5575] by
   permitting flowspec filters to be down, the BGP paths selectively applied to subsets of flowspec rules would
   network interfaces in a particular direction.  Care must be retained and taken to
   not permit the flowspec action will be
   retained.

10. 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
   their valuable comments.

11.

8.  IANA Considerations

11.1.

8.1.  FlowSpec Transitive Extended Communities

   This document requests a new type from the "BGP Transitive Extended
   Community Types" extended community registry from the First Come
   First Served range.  This type name shall be 'FlowSpec Transitive
   Extended Communities'.  IANA has assigned the value 0x07 to this
   type.

   This document requests creation of a new registry called "FlowSpec
   Transitive Extended Community Sub-Types".  This registry contains
   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
   value allocated in this document.  The registration procedure for
   values in this registry shall be First Come First Served.

11.2.

8.2.  FlowSpec Non-Transitive Extended Communities

   This document requests a new type from the "BGP Non-Transitive
   Extended Community Types" extended community registry from the First
   Come First Served range.  This type name shall be 'FlowSpec Non-
   Transitive Extended Communities'.  IANA has assigned the value 0x47
   to this type.

   This document requests creation of a new registry called "FlowSpec
   Non-Transitive Extended Community Sub-Types".  This registry contains
   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
   value allocated in this document.  The registration procedure for
   values in this registry shall be First Come First Served.

11.3.

8.3.  FlowSpec interface-set Extended Community

   Within the two new registries above, this document requests a new
   subtype (suggested value 0x02).  This sub-type shall be named
   "interface-set", with a reference to this document.

11.4.

8.4.  Allocation Advice to IANA

   IANA is requested to allocate the values of the FlowSpec Transitive
   and Non-Transitive Extended Communities such that their values are
   identical when ignoring the second high-order bit (Transitive).  See
   section 2, [RFC4360].  An example allocation would be 0x09/0x49.

   It is suggested to IANA that, when possible, allocations from the
   FlowSpec Transitive/Non-Transitive Extended Community Sub-Types
   registries are made for transitive or non-transitive versions of
   features (section 2, [RFC4360]) that their code point in both
   registries is identical.

12.  References

12.1.

9.  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
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, <http://www.rfc-editor.org/info/rfc4360>. <https://www.rfc-editor.org/info/rfc4360>.

   [RFC4684]  Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
              R., Patel, K., and J. Guichard, "Constrained Route
              Distribution for Border Gateway Protocol/MultiProtocol
              Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
              Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
              November 2006, <http://www.rfc-editor.org/info/rfc4684>. <https://www.rfc-editor.org/info/rfc4684>.

   [RFC5575]  Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
              and D. McPherson, "Dissemination of Flow Specification
              Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
              <http://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]
              Uttaro, J.,
              <https://www.rfc-editor.org/info/rfc5575>.

   [RFC7911]  Walton, D., Retana, A., Chen, E., Decraene, B., and J. Scudder,
              "Support for Long-lived BGP Graceful Restart", draft-
              uttaro-idr-bgp-persistence-03 (work
              "Advertisement of Multiple Paths in progress), November
              2013. BGP", RFC 7911,
              DOI 10.17487/RFC7911, July 2016, <https://www.rfc-
              editor.org/info/rfc7911>.

Authors' Addresses

   Stephane Litkowski
   Orange

   Email: stephane.litkowski@orange.com

   Adam Simpson
   Nokia

   Email: adam.1.simpson@nokia.com

   Keyur Patel
   Arrcus, Inc

   Email: keyur@arrcus.com

   Jeff

   Jeffrey Haas
   Juniper Networks

   Email: jhaas@juniper.net

   Lucy Yong
   Huawei

   Email: lucy.yong@huawei.com