Inter-Domain Routing                                        S. Litkowski
Internet-Draft                                                Individual
Intended status: Standards Track                              A. Simpson
Expires: May 21, 2020                                              Nokia
                                                                K. Patel
                                                             Arrcus, Inc
                                                                 J. Haas
                                                        Juniper Networks
                                                                 L. Yong
                                                                  Huawei
                                                       November 18, 2019


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

Abstract

   The BGP Flow Specification (flowspec) Network Layer Reachability
   Information (BGP NLRI) extension (draft-ietf-idr-rfc5575bis) is used
   to distribute traffic flow specifications into BGP.  The primary
   application of this extension is the distribution of traffic
   filtering policies for the mitigation of distributed denial of
   service (DDoS) attacks.

   By default, flow specification filters are applied on all forwarding
   interfaces that are enabled for use by the BGP flowspec extension.  A
   network operator may wish to apply a given filter selectively to a
   subset of interfaces based on an internal classification scheme.
   Examples of this include "all customer interfaces", "all peer
   interfaces", "all transit interfaces", etc.

   This document defines BGP Extended Communities (RFC4360) that allow
   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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.






Litkowski, et al.         Expires May 21, 2020                  [Page 1]


Internet-Draft            flowspec-interfaceset            November 2019


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 https://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 May 21, 2020.

Copyright Notice

   Copyright (c) 2019 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
   (https://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
   2.  Interface specific filtering using BGP flowspec . . . . . . .   3
   3.  Interface-set extended community  . . . . . . . . . . . . . .   5
   4.  Scaling of per-interface rules  . . . . . . . . . . . . . . .   6
   5.  Deployment Considerations . . . . . . . . . . . . . . . . . .   6
     5.1.  Add-Paths . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Inter-domain Considerations . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  FlowSpec Transitive Extended Communities  . . . . . . . .   7
     8.2.  FlowSpec Non-Transitive Extended Communities  . . . . . .   7
     8.3.  FlowSpec interface-set Extended Community . . . . . . . .   8
     8.4.  Allocation Advice to IANA . . . . . . . . . . . . . . . .   8



Litkowski, et al.         Expires May 21, 2020                  [Page 2]


Internet-Draft            flowspec-interfaceset            November 2019


   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Use case

   While a network may provide connectivity to a homogenous class of
   users, it often provides connectivity to different groups of users.
   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
   external connectivity.  In a virtual private networking (VPN)
   network, it may consist of customers in different sites connected
   through a VPN, the provider core network, and external networks such
   as the Internet.  In a traditional Internet service provider (ISP)
   network, the network may consist of points of presence (POPs),
   internal infrastructure networks, customer networks, peer networks,
   and transit networks.

   The BGP flowspec extension permits traffic filters to be distributed
   to routers throughout a network.  However, these filters often should
   not be uniformly applied to all 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 the SSH protocol may be deemed appropriate to drop at upstream
   peering routers but not customer routers.

   By default, BGP flowspec filters are applied at all interfaces that
   permit flowspec filters to be installed.  What is needed is a way to
   selectively apply those filters to subsets of interfaces in a
   network.

2.  Interface specific filtering using BGP flowspec

   The uses case detailed above require application of different BGP
   flowspec rules on different sets of interfaces.

   We propose to introduce, within BGP flowspec, a traffic filtering
   scope that identifies a group of interfaces where a particular filter
   should be applied.  Identification of interfaces within BGP flowspec
   will be done through group identifiers.  A group identifier marks a
   set of interfaces sharing a common administrative property.  Like a
   BGP community, 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.




Litkowski, et al.         Expires May 21, 2020                  [Page 3]


Internet-Draft            flowspec-interfaceset            November 2019


   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 3).

   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 is changing.

   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 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.








Litkowski, et al.         Expires May 21, 2020                  [Page 4]


Internet-Draft            flowspec-interfaceset            November 2019


3.  Interface-set extended community

   This document proposes a new BGP Route Target extended community
   called the "flowspec interface-set".  This document expands the
   definition of the Route Target extended community to allow a new
   value of high order octet (Type field) to be 0x07 for the transitive
   flowspec interface-set 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 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  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 inbound
      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 encoded as a 14-bit number, values 0..16383.

   Multiple instances of the interface-set extended community may be
   present in a BGP update.  This may occur if the flowspec rule needs
   to be applied to multiple sets of interfaces.

   Multiple instances of the extended community in a BGP update MUST be
   interpreted as a "OR" operation.  For example, if a BGP UPDATE



Litkowski, et al.         Expires May 21, 2020                  [Page 5]


Internet-Draft            flowspec-interfaceset            November 2019


   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.

   Similar to using a Route Target extended community, route
   distribution of flowspec NLRI with interface-set extended communities
   may be subject to constrained distribution as defined in [RFC4684].

4.  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.

   Flowspec implementations supporting the interface-set extended
   community SHOULD take care to minimize the scaling impact in such
   circumstances.  How this is accomplished is out of the scope of this
   document.

5.  Deployment 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) 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.

5.2.  Inter-domain Considerations

   The Group Identifier used by the interface-set extended community has
   local significance to its provisioning Autonomous System.  While
   [I-D.ietf-idr-rfc5575bis] permits inter-as advertisement of flowspec
   NLRI, care must be taken to not accept these communities when they
   would result in unacceptable filtering policies.

   Filtering of interface-set extended communities at Autonomous System
   border routers (ASBRs) may thus be desirable.




Litkowski, et al.         Expires May 21, 2020                  [Page 6]


Internet-Draft            flowspec-interfaceset            November 2019


   Note that the default behavior without the interface-set feature
   would to have been to install the flowspec filter on all flowspec
   enabled interfaces.

6.  Security Considerations

   This document extends the Security Considerations of
   [I-D.ietf-idr-rfc5575bis] 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
   their valuable comments.

8.  IANA Considerations

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.

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




Litkowski, et al.         Expires May 21, 2020                  [Page 7]


Internet-Draft            flowspec-interfaceset            November 2019


   value allocated in this document.  The registration procedure for
   values in this registry shall be First Come First Served.

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.

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].

   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.

9.  Normative References

   [I-D.ietf-idr-rfc5575bis]
              Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
              Bacher, "Dissemination of Flow Specification Rules",
              draft-ietf-idr-rfc5575bis-17 (work in progress), June
              2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <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, <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, <https://www.rfc-editor.org/info/rfc4684>.






Litkowski, et al.         Expires May 21, 2020                  [Page 8]


Internet-Draft            flowspec-interfaceset            November 2019


   [RFC7911]  Walton, D., Retana, A., Chen, E., and J. Scudder,
              "Advertisement of Multiple Paths in BGP", RFC 7911,
              DOI 10.17487/RFC7911, July 2016,
              <https://www.rfc-editor.org/info/rfc7911>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Stephane Litkowski
   Individual

   Email: slitkows.ietf@gmail.com


   Adam Simpson
   Nokia

   Email: adam.1.simpson@nokia.com


   Keyur Patel
   Arrcus, Inc

   Email: keyur@arrcus.com


   Jeffrey Haas
   Juniper Networks

   Email: jhaas@juniper.net


   Lucy Yong
   Huawei

   Email: lucy.yong@huawei.com












Litkowski, et al.         Expires May 21, 2020                  [Page 9]