Skip to main content

BGP Operations for Inter-domain SAV
draft-song-savnet-inter-domain-bgp-ops-02

Document Type Active Internet-Draft (individual)
Authors Xueyan Song , Chunning Dai , Shengnan Yue , Changwang Lin
Last updated 2024-04-17
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-song-savnet-inter-domain-bgp-ops-02
SAVNET Group                                                     X. Song
Internet-Draft                                                    C. Dai
Intended status: Best Current Practice                   ZTE Corporation
Expires: 19 October 2024                                          S. Yue
                                                            China Mobile
                                                                  C. Lin
                                                    New H3C Technologies
                                                           17 April 2024

                  BGP Operations for Inter-domain SAV
               draft-song-savnet-inter-domain-bgp-ops-02

Abstract

   This document attempts to present deployment considerations of source
   address validation using BGP protocol in inter-domain network.

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

Song, et al.             Expires 19 October 2024                [Page 1]
Internet-Draft        BGP OPS for Inter-domain SAV            April 2024

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Prefix-to-Interface Mapping . . . . . . . . . . . . . . . . .   3
   4.  SAV Function  . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Scalability . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Multi-homing Scenarios  . . . . . . . . . . . . . . . . . . .   5
     6.1.  Scenario 1  . . . . . . . . . . . . . . . . . . . . . . .   5
     6.2.  Scenario 2  . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Implementation and Operation Considerations . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   11. Informative References  . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   It is well known that internet routing security challenges include:
   route leaks, route prefix hijacking and source address spoofing.  To
   address these challenges, Resource Public Key Infrastructure (RPKI)
   provides an approach to build a formally verifiable database of IP
   addresses and AS numbers as resources.  And there are RPKI-based BGP
   Prefix Origin Validation (POV) (see [RFC7115]) and BGP AS path
   validation (see [I-D.ietf-sidrops-aspa-verification]) to mitigate
   route leaks.  The Route Origin Authorization currently used for RPKI-
   ROA (see [RFC6811], [RFC9319]) prevents hijacking of route prefix.
   Unlike RPKI-based BGP ROA, POV or ASPA, Source Address Validation
   (SAV) is one feasible way to filter invalid address and mitigate
   source address spoofing attacks in the data plane.

   To help reduce source address spoofing attacks in networks the
   feasible way is to validate whether the source address is spoofed or
   not.  The security requirement is the ability to validate the
   accuracy of incoming interface of the traffic for specific IP address
   prefixes.  More specifically, one router needs to validate that the
   incoming interface receiving the source IP address prefixes is in
   fact the right interface.  This document describes a BGP validation
   mechanism to satisfy this security requirement in inter-domain
   networks.

   As analyzed at [I-D.ietf-savnet-inter-domain-problem-statement],
   there are existing urpf-like mechanisms which describe an approach to
   build source address filtering.  However, the urpf technologies may
   improperly permit spoofed traffic or block legitimate traffic.  For
   example, strict uRPF (see [RFC3704]) technology is a simple way to

Song, et al.             Expires 19 October 2024                [Page 2]
Internet-Draft        BGP OPS for Inter-domain SAV            April 2024

   implement and provides a very reasonable way to single-homing
   scenarios for ingress filtering.  But in asymmetrical or multi-homing
   scenarios it brings wrong block for logic source address prefixes.
   Loose URPF [RFC3704] takes a looser validation mechanism than strict
   URPF to avoid improper block but may permit improperly spoofed source
   address.  However, the urpf technologies may improperly permit
   spoofed traffic or block legitimate traffic.  The FP-uRPF (see
   [RFC3704]) attempts to strike the banlance of the strict and loose
   uRPF but still has some shortcoming.  The EFP-uRPF (see [RFC8704])
   provides a more feasible way in overcoming the improper block of
   strict uRPF in asymetric routing scenario, but EFP-uRPF has not been
   implemented in practical networks yet.

   The BGP validation mechanism introduced in this document aims to
   reduce false positives regarding invalid incoming interface, mitigate
   source address spoofing, resolve the inflexibility about
   directionality of strict-URPF to improve accuracy of source address
   validation in inter-domain networks.  The deployment of Source
   Address Validation using BGP may have many operational
   considerations.

   This document attempts to collect and present some operational and
   security considerations to deploy Source Address Validation on
   routers in inter-domain networks.

2.  Conventions

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

3.  Prefix-to-Interface Mapping

   The Source Address Validation needs only be done by edge routers (or
   AS boarder routers) in a network and is deployed on current routers
   without significant hardware upgrades.  The prefix-to-interface
   mapping method introduced in this document does not need to update
   current routers with hardware upgrades nor big software updates.  The
   mapping policy should be used in boarder routers (i.e., ASBR) from
   other large networks (such as small stub, enterprise, edge networks,
   etc.).

   The following terms in this document are used:

Song, et al.             Expires 19 October 2024                [Page 3]
Internet-Draft        BGP OPS for Inter-domain SAV            April 2024

   1.  Prefix: Has the content (IP address, prefix length), interpreted
       as customary (see [RFC4632]).
   2.  Incoming Interface: The interface which received the traffic of
       source route prefixes.
   3.  Route Prefix: The prefix derived from a route.
   4.  POI: A tag for IGP/BGP source Prefix Origin Identification (POI).

   Based-on these definitions, any given IP address received from the
   traffic of one specific address prefix derived from a BGP route needs
   be verified locally using BGP validation method.  The deployment for
   prefix-to-interface mapping policy on routers listed as the
   following:

   1.  Add Prefix Origin Identification (POI) to BGP route, the POI tag
       can be set to BGP route prefix from BGP neighbors.
   2.  Create prefix-to-interface mapping policy and apply the policy to
       the incoming interface of the source address received from the
       packets of one specific address prefix.
   3.  When the source prefix is validated to be matched with the
       incoming interface, the packets received are permit to transit;
       if not, the packets received should be discarded or redirected to
       other interfaces based-on the deployed route policy.

4.  SAV Function

   An implementation should provide the ability to match the validation
   policy and set validation state of routes as part of its source
   address validation policy SAV function.  The SAV function involves 2
   characters: source address prefix and incoming interface.

   The objectives of SAV function include (1) set prefix-to-interface
   mapping of BGP route prefix from BGP neighbor with the incoming
   interface as route policy deployed at the edge routers, (2) match the
   validation mapping policy and (3) decide the validation state for the
   source address.  When the traffic of one specific address prefix
   received at one interface of the edge routers, the validation policy
   should be deployed and filtered the source address.  And based-on the
   validation state the source address should be validated correctly.

   The validation state is considered to include:

   *  Valid: The address prefix of received traffic matches the incoming
      interface.
   *  Invalid: The address prefix of received traffic does not match the
      incoming interface.
   *  NotFound: The address prefix of received traffic is not found.

Song, et al.             Expires 19 October 2024                [Page 4]
Internet-Draft        BGP OPS for Inter-domain SAV            April 2024

   When the source address received of traffic which prefix derived from
   the BGP route is not matched with the incoming interface, the
   validation state is considered as "Invalid".  Only the prefix matched
   with the incoming interface the validation state is set as "valid".
   Similarly, if no valid route be found its corresponding address
   packets should be discarded and its validation state should be set as
   "NotFound".

5.  Scalability

   The POI policy can be deployed as different granularity to satisfy
   scalability requirements for source address validation.  The document
   provides the following policies:

   *  AS level Prefix Origin Identification (AS POI): The AS number
      information which can be obtained along the prefix advertisement
      is used for SAV filtering policy.
   *  Community level Prefix Origin Identification (Community POI): The
      policy uses BGP Community feature for source address validation.
      It may require BGP extentions to carry the necessary POI
      information.
   *  Router level Prefix Origin Identification (Router POI): This is
      one practical way to reuse some of the existing fields to indicate
      the directionality or location of the source packets belong to.
      The policy suggests to use router-id as POI.
   *  Prefix level Prefix Origin Identification (Prefix POI): The policy
      is the smallest filtering granularity for source address
      validation.  The traffic packets received at incoming interface of
      BGP ASBR are validated by the POI.  Considering the inter BGP
      domains may be managed by different operators, the Prefix POI is
      recommended be deployed as local policy.

6.  Multi-homing Scenarios

6.1.  Scenario 1

   In terms of the URPF technologies may improperly permit spoofed
   traffic or block legitimate traffic, the URPF enhancements for
   solving limitations of strict URPF for inter-domain networks is
   mainly on improvement of ingress filtering accuracy in multi-homing
   scenarios.

   The following figure 1 shows an example for Content Delivery Networks
   (CDN) service access to Service Provider Networks (SPN) through the
   Internet Service Provider (ISP) networks.  For the ISPs are outside
   networks of SPN, the SPN needs to verify the validity of source
   address prefix of traffic received from ISPs.  The CDN1 announces
   source prefix P1 to the ISP1 and ISP2, announces source prefix P2 to

Song, et al.             Expires 19 October 2024                [Page 5]
Internet-Draft        BGP OPS for Inter-domain SAV            April 2024

   ISP1, and prefix P3 to ISP2.  The POP1 (Point of Presence) is the
   point or infrastructure used for access of ISP1 and ISP2.  The POP1
   learns routes directly connected ISPs and some non-directly connected
   ISPs/CDNs from multiple ISPs.  The set of routes learned from the
   same non-directly connected ISP is inconsistent but overlapped.

   It's assumed that the prefix from ISPs in the following figure are
   trusted.

                          Prefix:A,B,D,F
                          +------------+
                      /---|   ISP100   |---\
      +---------+    /    +------------+    \
      | SP      |   /                        \ Prefix: A,B,C
      |        +----+                        +----------+
      |        |POP1|                        |   CDN1   |
      |        +----+                        +----------+
      +---------|    \    +------------+    /
                      \---|   ISP200   |---/
                          +------------+
                          Prefix:A,C,E,F

           Figure 1: SAV Functions for CDN Multi-homing Scenario

   It's assumed that the POI for the prefix origin from ISP100 is set as
   100, and POI for ISP200 is set as 200.  The prefix-to-interface
   mapping rule is based-on AS level and is showed as the below table 1.

                     +========+=========+===========+
                     | Prefix | POI     | Interface |
                     +========+=========+===========+
                     | A      | 100,200 | 1,2       |
                     +--------+---------+-----------+
                     | B      | 100     | 1         |
                     +--------+---------+-----------+
                     | C      | 200     | 2         |
                     +--------+---------+-----------+
                     | D      | 100     | 1         |
                     +--------+---------+-----------+
                     | E      | 200     | 2         |
                     +--------+---------+-----------+
                     | F      | 100,200 | 1,2       |
                     +--------+---------+-----------+

                       Table 1: Prefix-to-Interface
                                 Mapping

Song, et al.             Expires 19 October 2024                [Page 6]
Internet-Draft        BGP OPS for Inter-domain SAV            April 2024

   When the packets received in POP1 the source address is validated
   using prefix-to-interface mapping rule.  For example, prefix A tagged
   with POI 100 and 200, respectively matched with Int1 and Int2 of
   POP1, so the packets of prefix A will be permitted to transit by Int1
   and Int2.  For prefix B tagged with POI 100 can only be permitted by
   Int1 according to the prefix-to-interface mapping rule.  Similarly,
   the prefix F comes from both ISP1 and ISP2 will be permitted by Int1
   and Int2.

   The SAV actions table shows as table 2.

                      +===========+========+========+
                      | Interface | Prefix | Action |
                      +===========+========+========+
                      | 1         | A      | Permit |
                      +-----------+--------+--------+
                      | 1         | B      | Permit |
                      +-----------+--------+--------+
                      | 1         | C      | Deny   |
                      +-----------+--------+--------+
                      | 1         | D      | Permit |
                      +-----------+--------+--------+
                      | 1         | E      | Deny   |
                      +-----------+--------+--------+
                      | 1         | F      | Permit |
                      +-----------+--------+--------+
                      | 2         | A      | Permit |
                      +-----------+--------+--------+
                      | 2         | B      | Deny   |
                      +-----------+--------+--------+
                      | 2         | C      | Permit |
                      +-----------+--------+--------+
                      | 2         | D      | Deny   |
                      +-----------+--------+--------+
                      | 2         | E      | Permit |
                      +-----------+--------+--------+
                      | 2         | F      | Permit |
                      +-----------+--------+--------+

                            Table 2: SAV Action

   In this case, the prefix from the same origin (i.e., AS number) as a
   whole set is trusted and the prefix-to-interface mapping rule is
   applied to the incoming interfaces of traffic received for source
   validation in routers.

Song, et al.             Expires 19 October 2024                [Page 7]
Internet-Draft        BGP OPS for Inter-domain SAV            April 2024

6.2.  Scenario 2

   The following figure 2 shows an example of multipoint interconnection
   between multiple POP points and the same ISP.  In this case, the set
   of routes learned from different POP points to the same ISP is
   inconsistent but overlapped.  This section provides 2 POI policies
   apllied in AS-level and Router-level.

           +----------------------------------+
           |              ISP200              |
           +----------------------------------+
                |            |          |
                |  Prefix:A,C|          |
      Prefix:A,B|            |          |Prefix:A,B,C
              +----+       +----+     +----+
           +--|POP1|-------|POP2|-----|POP3|--+
           |  +----+       +----+     +----+  |
           |     \           |          /     |
           |      \          |         /      |
           |       \         |        /       |
           |         +---------------+        |
           |         |      RR       |        |
           |         +---------------+    SP  |
           +----------------------------------+

         Figure 2: SAV Functions for Multiple POPs Access Scenario

   In this case, the prefix-to-interface mapping rule shows as the table
   3.

                       +========+=====+===========+
                       | Prefix | POI | Interface |
                       +========+=====+===========+
                       | A      | 200 | 1,2,3     |
                       +--------+-----+-----------+
                       | B      | 200 | 1,3       |
                       +--------+-----+-----------+
                       | C      | 200 | 2,3       |
                       +--------+-----+-----------+

                           Table 3: Prefix-to-
                            Interface Mapping

Song, et al.             Expires 19 October 2024                [Page 8]
Internet-Draft        BGP OPS for Inter-domain SAV            April 2024

   If AS POI applied in the case the traffic packets of prefix (i.e., A,
   B and C in this example) received at POP1 from AS 200 are treated
   from the same trusted source.  If the POI policy replaced by router
   POI the packets of prefix C will be filtered and processed as invalid
   source address at POP1 in this example.

   Through BGP method provided in this document, the SAV function is
   applied by BGP edge routers (i.e., SAV validation node) using prefix-
   to-interface rules to complete source address validation accurately.
   It's obvious that the BGP method described in section 5.1 and 5.2
   improves the source address validation accuracy and overcomes the
   limitation of strict URPF method in multi-homing scenarios.

7.  Implementation and Operation Considerations

   This document assumes the BGP route prefix origin is trusted.  The
   validation to the origination Autonomous System (AS) of BGP routes is
   out of the scope of the document.  The source address validation is
   selected for filtering invalid address or mitigating source address
   spoofing through validating the incoming interface of traffic
   received for one specific source prefix is in fact the right
   interface.  The mapping policy as discussed in section 3 can be used
   to take action and based on the validation state to complete SAV
   function introduced in section 4 for address filtering.

   The policies can be implemented include (1) identifying the route
   prefix advertised by different ISPs(i.e., BGP neighbors) as different
   POIs.  (2) applying Prefix-to-Interface mapping rule to the BGP edge
   routers and process the Source Address Validation (SAV) function. (3)
   making the corresponding action based-on the validation state.

   The validating router uses the result of source address validation to
   influence local policy in one network.  In deployment, the policy
   should fit into the routers existing policy and allows a network to
   deploy incrementally or partially.  The prefix-to-interface mapping
   rules used by the BGP edge routers are expected to be updated based-
   on the real network requirement.

   The following operational considerations applied to the BGP
   validation mechanism:

   *  The BGP validation mechanism SHOULD support backward compatibility
      with existing routers.
   *  The BGP validation mechanism SHOULD be hardware friendly, does not
      require hardware upgrades nor big software updates.
   *  The BGP validation mechanism SHOULD comply with the routers
      existing policies and allow for incremental and partial network
      deployment.

Song, et al.             Expires 19 October 2024                [Page 9]
Internet-Draft        BGP OPS for Inter-domain SAV            April 2024

   *  The BGP validation mechanism SHOULD support actual network
      implement requirement.

8.  Security Considerations

   The BGP method introduced in this document provides a feasible way to
   validate address of traffic received for one specific source prefix.
   In this document, the BGP route prefix in inter-domain network is
   considered as trusted.  If there are invalid routes which are not
   matched with the current BGP route table should be blocked.  The
   validation of origination AS of BGP routes is introduced in BGP POV
   document (see [RFC6811]).  This document only attempts to verify the
   incoming interface is in fact the right interface for the source
   prefix.  The detailed inter-domain SAV security please refer to
   [I-D.wu-savnet-inter-domain-architecture].

9.  IANA Considerations

   This document has no requests for IANA.

10.  Acknowledgements

   The authors would like to acknowledge Wei Yuehua, Xiao Min, Liu Yao,
   Zhou Fenlin for their thorough review and feedbacks.

11.  Informative References

   [I-D.ietf-savnet-inter-domain-problem-statement]
              Li, D., Wu, J., Liu, L., Huang, M., and K. Sriram, "Source
              Address Validation in Inter-domain Networks Gap Analysis,
              Problem Statement, and Requirements", Work in Progress,
              Internet-Draft, draft-ietf-savnet-inter-domain-problem-
              statement-04, 19 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
              inter-domain-problem-statement-04>.

   [I-D.ietf-sidrops-aspa-verification]
              Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
              J., and K. Sriram, "BGP AS_PATH Verification Based on
              Autonomous System Provider Authorization (ASPA) Objects",
              Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
              verification-17, 29 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-verification-17>.

   [I-D.wu-savnet-inter-domain-architecture]
              Li, D., Wu, J., Huang, M., Chen, L., Geng, N., Liu, L.,
              and L. Qin, "Inter-domain Source Address Validation

Song, et al.             Expires 19 October 2024               [Page 10]
Internet-Draft        BGP OPS for Inter-domain SAV            April 2024

              (SAVNET) Architecture", Work in Progress, Internet-Draft,
              draft-wu-savnet-inter-domain-architecture-07, 4 March
              2024, <https://datatracker.ietf.org/doc/html/draft-wu-
              savnet-inter-domain-architecture-07>.

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

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

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
              2006, <https://www.rfc-editor.org/info/rfc4632>.

   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation", RFC 6811,
              DOI 10.17487/RFC6811, January 2013,
              <https://www.rfc-editor.org/info/rfc6811>.

   [RFC7115]  Bush, R., "Origin Validation Operation Based on the
              Resource Public Key Infrastructure (RPKI)", BCP 185,
              RFC 7115, DOI 10.17487/RFC7115, January 2014,
              <https://www.rfc-editor.org/info/rfc7115>.

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

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

   [RFC9319]  Gilad, Y., Goldberg, S., Sriram, K., Snijders, J., and B.
              Maddison, "The Use of maxLength in the Resource Public Key
              Infrastructure (RPKI)", BCP 185, RFC 9319,
              DOI 10.17487/RFC9319, October 2022,
              <https://www.rfc-editor.org/info/rfc9319>.

Authors' Addresses

Song, et al.             Expires 19 October 2024               [Page 11]
Internet-Draft        BGP OPS for Inter-domain SAV            April 2024

   Xueyan Song
   ZTE Corporation
   China
   Email: song.xueyan2@zte.com.cn

   Chunning Dai
   ZTE Corporation
   China
   Email: dai.chunning@zte.com.cn

   Shengnan Yue
   China Mobile
   China
   Email: yueshengnan@chinamobile.com

   Changwang Lin
   New H3C Technologies
   China
   Email: linchangwang.04414@h3c.com

Song, et al.             Expires 19 October 2024               [Page 12]