Internet DRAFT - draft-geng-idr-flowspec-sav

draft-geng-idr-flowspec-sav







IDR                                                              N. Geng
Internet-Draft                                                    Huawei
Intended status: Standards Track                                   D. Li
Expires: 5 September 2024                            Tsinghua University
                                                            4 March 2024


          BGP Flow Specification for Source Address Validation
                     draft-geng-idr-flowspec-sav-03

Abstract

   BGP FlowSpec reuses BGP route to distribute infrastructure and
   propagates traffic flow information with filtering actions.  This
   document specifies a new flow specification called Incoming-
   Interface-Set. Incoming-Interface-Set can be used together with the
   Source Prefix component to disseminate SAV rules.

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 5 September 2024.

Copyright Notice

   Copyright (c) 2024 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.



Geng & Li               Expires 5 September 2024                [Page 1]

Internet-Draft            BGP FlowSpec for SAV                March 2024


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  SAV Rules . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  BGP FlowSpec for SAV  . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Flow Specification Encoding for SAV . . . . . . . . . . .   5
     3.2.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Other Usages  . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Source Address Validation (SAV) is an efficient method for preventing
   source address spoofing-based attacks.  SAV rules indicate the valid/
   invalid incoming interfaces of a specific source IP address or source
   IP prefix.  The rules can be deployed on edge routers, border
   routers, or aggregation routers for checking the validity of intra-
   domain and inter-domain packets.  For invalid packets, filtering
   actions can be taken such as block, rate-limit, redirect, and
   sampling [I-D.huang-savnet-sav-table].

   There are many mechanisms that can distributedly generate SAV rules
   on routers ([RFC2827], [RFC3704], [RFC5210], [RFC8704], and
   [manrs-antispoofing]).  To facilitate flexible SAV management and
   improve validation accuracy, centralized SAV rule dissemination is
   also needed [I-D.li-savnet-intra-domain-architecture][I-D.wu-savnet-i
   nter-domain-architecture], which can be a complementary to existing
   distributed SAV mechanisms.

   BGP FlowSpec is a convenient and flexible tool for traffic filtering/
   controlling ([RFC8955], [RFC8956]).  It propagates traffic flow
   information for different traffic control purposes through the BGP
   protocol extension.  Existing BGP FlowSpec has supported source
   prefix matching and various traffic filtering actions but does not
   support binding valid/invalid incoming interfaces to source prefixes.
   With a minor extension, BGP FlowSpec can be used for SAV rule
   dissemination.





Geng & Li               Expires 5 September 2024                [Page 2]

Internet-Draft            BGP FlowSpec for SAV                March 2024


   This document specifies a new flow specification component named
   Incoming-Interface-Set. SAV rules can be disseminated through BGP
   FlowSpec by carrying the new flow specification component together
   with Source Prefix component.  Traffic filtering actions of existing
   BGP FlowSpec can also be carried to specify the actions for the
   packets failing source address validation.

   The new extension can be used to configure SAV rules on remote
   routers.  It can also act as a supplement of existing SAV mechanisms
   and help improve SAV accuracy.

1.1.  Terminology

   SAV: Source address validation

   SAV Rule: The rule that indicates the valid/invalid incoming
   interfaces of a specific source IP address or source IP prefix.

   Group Identifier: An ID value that identifies a set of interfaces on
   the target routers (e.g., all the interfaces connected to customer
   ASes).

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

2.  SAV Rules

   SAV rules can be used for checking the validity of source addresses
   of incoming packets.  A rule usually has a format of <source prefix,
   interface set, validity indicator>.  Source prefix is for matching
   specific packets.  Interface set represents a set of physical
   interfaces from which the packets arrive.  Validity indicator
   indicates whether the packets matching the source prefix and arrival
   interface are valid or invalid.  So, validity indicator has a value
   of either valid or invalid.

   For example, the rule <P1, [intf1, intf2], valid> means the source
   prefix P1 must arrive the router at interface Intf1 or Intf2,
   otherwise, P1 is invalid.  For the packets with invalid source
   addresses/prefixes, the filtering actions, such as block, rate-limit,
   and redirect, can be taken [I-D.huang-savnet-sav-table].





Geng & Li               Expires 5 September 2024                [Page 3]

Internet-Draft            BGP FlowSpec for SAV                March 2024


   In real networks, the interface set in SAV rules usually can be
   grouped.  For example, the interfaces can be grouped as:

   *  Subnet interface set that contains the interfaces connecting a
      target subnet.

   *  All customer AS interfaces set or the customer AS interfaces set
      of a customer AS.

   *  All lateral peer AS interfaces set or the lateral peer AS
      interfaces set of a lateral peer AS.

   *  All transit provider AS interfaces set or the transit provider AS
      interfaces set of a transit provider AS.

   These interface set can be identified by a Group Identifier for easy
   management.  Group Identifier is a local interface property on the
   target routers, and the meaning of it depends on the configurations
   of network administrator.  Any interface may be associated with one
   or more Group Identifiers.

3.  BGP FlowSpec for SAV

   SAV can be disseminated to Edge/Border/Aggregation routers (i.e.,
   target routers) through BGP FlowSpec, as shown in the figure below.
   The controller is used to set up BGP connection with the routers in a
   SAV-deployed AS or domain.  Note that, SAV rules disseminated by BGP
   FlowSpec can take effect alone or acts as a management tool of other
   SAV mechanisms (e.g., [RFC8704]).

                         +------------+
                         | Controller |
                         +------------+
                           /   |    \
                          / FS | FS  \ FS
                         /     |      \
   +-------------+      +--------------+      +---------+
   | Provider or |      | SAV-deployed |      |         |
   | Customer or |------# AS/Domain    #------| Subnets |
   | Peer AS     |      |              |      |         |
   +-------------+      +--------------+      +---------+

   Existing BGP FlowSpec has supported source prefix matching and
   various traffic filtering actions.  To disseminate SAV rules (<source
   prefix, interface set, validity indicator>), a new flow specification
   component is needed to carry the information of interface set and
   validity indicator.




Geng & Li               Expires 5 September 2024                [Page 4]

Internet-Draft            BGP FlowSpec for SAV                March 2024


3.1.  Flow Specification Encoding for SAV

   The new flow specification component is encoded in the BGP Flowspec
   NLRI.  It SHOULD appear together with Source Prefix component.

   The following new component type is defined:

   *  Type TBD1: Incoming-Interface-Set

   *  Encoding: <type (1 octet), [numeric_op, value]+>

   The new component contains a set of {numeric_op, value} pairs that
   are used to match the Incoming-Interface-Set (i.e., the valid or
   invalid interfaces of a specific source prefix).

   The numeric operator (numeric_op) is encoded as (see RFC8955 sec.
   4.2.1.1):

       0   1   2   3   4   5   6   7
     +---+---+---+---+---+---+---+---+
     | e | a |  len  | 0 |lt |gt |eq |
     +---+---+---+---+---+---+---+---+

   The value field is encoded as:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V|R|     Group Identifier (variable, 6, 14, 30, or 62 bits)    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The length of the value field can be 1, 2, 4, or 8 octets, which
   depends on the len in numeric_op.  Particularly, the most two
   significant bits in the value field are two flags:

   *  Flag V (1 bit): The most significant bit in the value field.  If
      set, the identified interface set is valid for the source prefix.
      If unset, it means the interface set is invalid for the source
      prefix.

   *  Flag R (1 bit): The second most significant bit in the value
      field.  This bit is reserved for future use and MUST be set to
      zero.

   Group Identifier indicates a specific set of interfaces that are
   configured by network administrator.  Zero Group Identifier (i.e.,
   Group Identifier equaling 0) is a reserved value and does not need to
   be configured.  A NLRI may carry one zero Group Identifier and



Geng & Li               Expires 5 September 2024                [Page 5]

Internet-Draft            BGP FlowSpec for SAV                March 2024


   several non-zero Group Identifiers.  The zero Group Identifier means
   any other interfaces on the target router except the interfaces
   indicated by non-zero Group Identifiers in the same NLRI.  If a NLRI
   only contains a zero Group Identifier and has no non-zero Group
   Identifiers, the zero Group Identifier will represent all interfaces
   on the target router.  A NLRI MUST not contain more than one zero
   Group Identifiers, otherwise, the whole NLRI will be ignored.

   The bits lt, gt, and eq can be combined to match a specific Group
   Identifier or a range of Group Identifiers (e.g., greater than Group
   ID1 and less than Group ID2).  For a range of Group Identifiers,
   their corresponding flags (i.e., V and R) MUST be the same.
   Otherwise, the whole NLRI will be ignored.

   If a receiving BGP speaker cannot support this new flow specification
   component type, it MUST discard the NLRI value field that contains
   such unknown components (section 10 of [RFC8955]).  A NLRI value
   field MUST only contain a Source Prefix component and an Incoming-
   Interface-Set component.  If the NLRI value does not satisfy this
   principle, the receiving BGP speaker SHOULD discard the NLRI value
   field (see Section Section 3.3).  Since the NLRI field encoding
   (Section 4 of [RFC8955]) is defined in the form of a 2-tuple <length,
   NLRI value>, message decoding can skip over the unknown NLRI value
   and continue with subsequent remaining NLRIs.

3.2.  Examples

   Example 1: Configure source prefix P1 as valid at AS1's interfaces
   (Group Identifier=ID1) connecting a multi-homed subnet.

   Encoding description: NLRI carries a P1 in a Source Prefix component
   and a Incoming-Interface-set component with (V=1, R=0, Group
   Identifier=ID1).

   Example 2: Configure source prefix P2 as invalid at AS2's interfaces
   (Group Identifier=ID2) connecting to transit providers and as valid
   for any other interfaces.

   Encoding description: NLRI carries a P2 in a Source Prefix component
   and a Incoming-Interface-set component with (V=0, R=0, Group
   Identifier=ID2) and (V=1, R=0, Group Identifier=0).

3.3.  Other Usages

   The Incoming-Interface-Set component can be used as a general flow
   specification instead of SAV-specific component.  Other components
   can be combined with the new component for matching specific traffic.




Geng & Li               Expires 5 September 2024                [Page 6]

Internet-Draft            BGP FlowSpec for SAV                March 2024


4.  Error Handling

   TBD

5.  IANA Considerations

   This document requests a new entry in "Flow Spec component types
   registry" with the following values:

   +=======+========================+===============+
   | Type  | IPv4/IPv6 Name         | Reference     |
   +=======+========================+===============+
   | TBD1  | Incoming-Interface-set | This document |
   +-------+------------------------+---------------+

6.  Security Considerations

   TBD.

7.  Acknowledgements

   Many thanks to the comments from Shunwan Zhuang, Susan Hares, Jeffrey
   Haas, Mingqing Huang, Mingxing Liu etc.

8.  References

8.1.  Normative References

   [RFC8955]  Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
              Bacher, "Dissemination of Flow Specification Rules",
              RFC 8955, DOI 10.17487/RFC8955, December 2020,
              <https://www.rfc-editor.org/info/rfc8955>.

   [RFC8956]  Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed.,
              "Dissemination of Flow Specification Rules for IPv6",
              RFC 8956, DOI 10.17487/RFC8956, December 2020,
              <https://www.rfc-editor.org/info/rfc8956>.

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

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

8.2.  Informative References



Geng & Li               Expires 5 September 2024                [Page 7]

Internet-Draft            BGP FlowSpec for SAV                March 2024


   [I-D.li-savnet-intra-domain-architecture]
              Li, D., Wu, J., Qin, L., Geng, N., Chen, L., Huang, M.,
              and F. Gao, "Intra-domain Source Address Validation
              (SAVNET) Architecture", Work in Progress, Internet-Draft,
              draft-li-savnet-intra-domain-architecture-06, 21 January
              2024, <https://datatracker.ietf.org/doc/html/draft-li-
              savnet-intra-domain-architecture-06>.

   [I-D.wu-savnet-inter-domain-architecture]
              Wu, J., Li, D., Huang, M., Chen, L., Geng, N., Liu, L.,
              and L. Qin, "Inter-domain Source Address Validation
              (SAVNET) Architecture", Work in Progress, Internet-Draft,
              draft-wu-savnet-inter-domain-architecture-06, 5 February
              2024, <https://datatracker.ietf.org/doc/html/draft-wu-
              savnet-inter-domain-architecture-06>.

   [I-D.huang-savnet-sav-table]
              Huang, M., Cheng, W., Li, D., Geng, N., Liu, Chen, L., and
              C. Lin, "General Source Address Validation Capabilities",
              Work in Progress, Internet-Draft, draft-huang-savnet-sav-
              table-04, 21 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-huang-savnet-
              sav-table-04>.

   [manrs-antispoofing]
              "MANRS Implementation Guide", January 2023,
              <https://www.manrs.org/netops/guide/antispoofing>.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <https://www.rfc-editor.org/info/rfc2827>.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
              2004, <https://www.rfc-editor.org/info/rfc3704>.

   [RFC5210]  Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams,
              "A Source Address Validation Architecture (SAVA) Testbed
              and Deployment Experience", RFC 5210,
              DOI 10.17487/RFC5210, June 2008,
              <https://www.rfc-editor.org/info/rfc5210>.

   [RFC8704]  Sriram, K., Montgomery, D., and J. Haas, "Enhanced
              Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
              RFC 8704, DOI 10.17487/RFC8704, February 2020,
              <https://www.rfc-editor.org/info/rfc8704>.




Geng & Li               Expires 5 September 2024                [Page 8]

Internet-Draft            BGP FlowSpec for SAV                March 2024


Authors' Addresses

   Nan Geng
   Huawei
   Beijing
   China
   Email: gengnan@huawei.com


   Dan Li
   Tsinghua University
   Beijing
   China
   Email: tolidan@tsinghua.edu.cn





































Geng & Li               Expires 5 September 2024                [Page 9]