Source Address Validation: Use Cases and Gap Analysis
draft-li-sav-gap-analysis-00

Network Working Group                                              D. Li
Internet-Draft                                                     J. Wu
Intended status: Informational                                  Tsinghua
Expires: 28 April 2022                                          M. Huang
                                                                  Huawei
                                                                  L. Qin
                                                                Tsinghua
                                                                 N. Geng
                                                                  Huawei
                                                         25 October 2021

         Source Address Validation: Use Cases and Gap Analysis
                      draft-li-sav-gap-analysis-00

Abstract

   This document identifies the importance and use cases of source
   address validation (SAV) at both intra-AS level and inter-AS level
   (see [RFC5210]).  However, existing intra-AS and inter-AS SAV
   mechanisms, either Ingress ACL filtering [RFC2827], unicast Reverse
   Path Forwarding (uRPF) [RFC3704], or Enhanced Feasible-Path uRPF
   (EFP-uRPF) [RFC8704] has limitations in scalability or accuracy.
   This document provides the gap analysis of the existing SAV
   mechanisms followed with some design considerations.

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 RFC 2119 [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 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 28 April 2022.

Li, et al.                Expires 28 April 2022                 [Page 1]
Internet-Draft         SAV Use Case & Gap Analysis          October 2021

Copyright Notice

   Copyright (c) 2021 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Use Case 1: Intra-AS SAV  . . . . . . . . . . . . . . . .   6
     3.2.  Use Case 2: Inter-AS SAV  . . . . . . . . . . . . . . . .   7
   4.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Existing Intra-AS SAV mechanisms  . . . . . . . . . . . .   7
     4.2.  Existing Inter-AS SAV mechanisms  . . . . . . . . . . . .   9
   5.  Design Considerations . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Source Address Validation (SAV) is important for defensing against
   source address forgery attacks and accurately tracing back to the
   attackers [RFC5210].  Consider that the Internet is extremely large
   and complex.  It is much difficult to solve the source address
   spoofing problem at a single "level" or through a single SAV
   mechanism.  On the one hand, it is unrealistic to require all
   networks to deploy a single SAV mechanism.  On the other hand, the
   failure of a single SAV mechanism will completely disable SAV.

   To address the issue, Source Address Validation Architecture (SAVA)
   was proposed [RFC5210].  According to the operating feature of the
   Internet, SAVA presents a hierarchical architecture which carries out
   source IP address validation at three checking levels, i.e., access
   network, intra-AS, and inter-AS.  Different levels provide different

Li, et al.                Expires 28 April 2022                 [Page 2]
Internet-Draft         SAV Use Case & Gap Analysis          October 2021

   granularities of source IP address authenticity.  In contrast to the
   single-level/point model, SAVA allows incremental deployment of SAV
   mechanisms while keeps effective because of its multiple-fence
   design.  So, enhancing the source IP address validity in all the
   three checking levels is of high importance.  Furthermore, one or
   more independent and loosely-coupled SAV mechanisms can coexist and
   cooperate under SAVA, which is friendly to different users (e.g.,
   providers) with different policies or considerations.  Obviously, the
   quality of SAV mechanisms for their target checking levels is key to
   the performance of SAV.

   There are many SAV mechanisms for different checking levels.  For the
   access network level, Source Address Validation Improvement (SAVI)
   was proposed to force each host to use legitimate source IP address
   [RFC7039].  SAVI acts as a purely network-based solution without
   special dependencies on hosts.  It dynamically binds each legitimate
   IP address to a specific port/MAC address and verifies each packet's
   source address through the binding relationship.  One of the most
   attractive features of SAVI is that it supports the maximally fine
   granularity of individual IP addresses, which is much finer than the
   previous ingress filtering mechanisms.

   At the intra-AS level, static Access Control List (ACL) is a typical
   solution of SAV.  Operators can configure some matching rules to
   specify which kind of packets are acceptable (or unacceptable).  The
   information of ACL should be updated manually so as to keep
   consistent with the newest filtering criteria, which inevitably
   limits the flexibility and accuracy of SAV.  Loose unicast Reverse
   Path Forwarding (uRPF) is another solution suitable to intra-AS SAV
   [RFC8704].  The routers deploying loose uRPF accept any packets whose
   source addresses appear in the local FIB tables.  Due to the loss of
   directionality, loose uRPF may induce false negative problems.
   Strict uRPF was proposed with the consideration of directionality
   [RFC8704].  Routers deploying strict uRPF accepts a data packet only
   when i) the local FIB contains a prefix encompassing the packet's
   source address and ii) the corresponding forwarding action for the
   prefix matches the packet's incoming interface.  Otherwise, the
   packet will be dropped.  However, in the scenarios (e.g., multihoming
   cases) where data packets are under asymmetric routing, strict uRPF
   often results in serious false positive problem [RFC8704].

Li, et al.                Expires 28 April 2022                 [Page 3]
Internet-Draft         SAV Use Case & Gap Analysis          October 2021

   At the inter-AS level, a combination of Enhanced Feasible-Path uRPF
   (EFP-uRPF) and loose uRPF is recommended in [RFC8704].  Particularly,
   EFP-uRPF is suggested to be applied on customer interfaces.  EPF-uRPF
   on an AS can prevent its customers spoofing its upstream ASes' source
   addresses but fails in the case of two customers spoofing each other.
   On lateral peer interfaces and transit provider interfaces, loose
   uRPF is taken.  As described previously, false negative problems may
   arise.

   SAVI provides a complete and maximally fine-grained access
   validation, but it is impossible to deploy SAVI on every access point
   in the universe.  The "fences" at intra- and inter-AS levels are much
   important for filtering source address forgery packets that are let
   go by access networks.  However, there exist some instinctive
   drawbacks in the existing SAV mechanisms designed for both the intra-
   and inter-AS levels, which leads to inevitable false negative or
   false negative problems.  A more complete SAV mechanism is required
   for both intra- and inter-AS levels.

   This document identifies the use cases of intra- and inter-AS SAVs.
   These cases will help analyze the instinctive drawbacks of the
   existing SAV mechanisms.  After that, some design considerations of
   overcoming the drawbacks will be presented.

2.  Terminology

   False positive means the legitimate data packets are dropped
   unexpectedly.  False negative indicates that the data packets with
   spoofed source IP addresses fail to be filtered.

   Intra-AS SAV denotes the SAV at intra-AS level, which checks the
   source address validity of the data packets (i.e., EAST-WEST traffic)
   within an AS.  Intra-AS SAV can prevent hosts/routers from spoofing
   other source IP blocks in the same AS.

   Inter-AS SAV denotes the SAV at inter-AS level, which verifies the
   authenticity of the source address of incoming traffic (i.e., NORTH-
   SOUTH traffic).  Particularly, the traffic arriving from the customer
   AS is Northward traffic.  The traffic received from the provider/peer
   AS is Southward traffic.

   Two types of SAV modes are defined, i.e., allowlist and blocklist.
   Both of them can be applied to one or more specified interfaces of a
   device (router or switch).  The data packets with source addresses
   appearing in the allowlist and entering the device at the interface
   specified by the allowlist will be accepted.  The device will drop
   the data packets that i) are with source addresses not included in
   the allowlist or ii) are with legal source addresses but enter the

Li, et al.                Expires 28 April 2022                 [Page 4]
Internet-Draft         SAV Use Case & Gap Analysis          October 2021

   device at wrong interfaces.  The SAV tables of all uRPF-like
   mechanisms belong to allowlist.  On the contrary, blocklist only
   focus on validity of the source addresses included in the list.
   Specifically, the data packets with source addresses included in the
   blocklist will be dropped if the arrival interfaces are not expected.
   Otherwise, they will be accepted.  As for the data packets with
   source addresses not included in the blocklist, the device will
   accept them all the time, which is the main difference from the SAV
   mode of allowlist.  Since allowlist and blocklist can work on
   specified interfaces of a device, the decision on the SAV mode choice
   can be made for an interface adaptively.

3.  Use Cases

   Figure 1 illustrates the requirements of SAV in both intra- and
   inter-AS levels.  AS1-AS5 belong to the same customer cone, and AS1
   is the stub AS.  The topology of AS2 is presented while other ASes'
   inner structures are hidden for brevity.

Li, et al.                Expires 28 April 2022                 [Page 5]
Internet-Draft         SAV Use Case & Gap Analysis          October 2021

                         +---------------------+
                         |         AS5         |
                         +-/\---------------/\-+
                           /                 \
                          /                   \
     +-------------------/----------+          \
     |  AS2    +----------+         |           \
     |         | Router 4 |         |      +------------+
     |         +----------+         |      |     AS4    |--P1''
     |         /          \         |      +-----/\-----+
     | +----------+    +----------+ |            |
     | | Router 2 |----| Router 3 | |            |
     | +----------+    +----------+ |            |
     |   |     \          /     |   |      +------------+
     |   P1'   +----------+     P1  |      |     AS3    |
     |         | Router 1 |         |      +-----/\-----+
     |         +----------+         |            /
     +------------------\-----------+           /
                         \                     /
                          \                   /
                         +-----------------------+
                         |          AS1          |
                         +-----------------------+
     P1 is the source IP address prefix of Router3.
     P1' is the spoofed P1 by Router2 located in the same AS as Router3.
     P1" is the spoofed P1 by Routers located in another AS, i.e., AS4.

     Figure 1: Illustration of the requirements of SAV in both intra-
                        and inter-AS levels

3.1.  Use Case 1: Intra-AS SAV

   In some scenarios especially very large ASes, hosts/routers in the
   same AS may spoof each other's IP addresses.  In Figure 1, Router2
   spoofs P1 that originates from Router3.  With Intra-AS SAV, EAST-WEST
   traffic can be checked, and source address spoofing attacks can be
   prevented.  In the figure, Router1, Router3, and Router4 will drop
   the packets with P1' while accept those with P1, when they deploy
   Intra-AS SAV mechanisms.  Overall, Intra-AS SAV can prevent the
   source address spoofing from the same AS.

Li, et al.                Expires 28 April 2022                 [Page 6]
Internet-Draft         SAV Use Case & Gap Analysis          October 2021

3.2.  Use Case 2: Inter-AS SAV

   In Figure 1, AS4 spoofs AS2's IP address prefix, i.e., P1 originated
   from Router3.  AS5 will receive the Northward traffic from AS2 and
   AS4 with legitimate and spoofed IP addresses, respectively.  An SAV
   mechanism is necessary for AS5 to drop the illegal traffic.  From the
   view point of Southward traffic, AS1 may also receive spoofed traffic
   from AS3 (if AS3 accepts the data packets with source prefix P1").
   So, the deployment of SAV on AS1 is also important.  Overall, Inter-
   AS SAV is necessary and can improve the confidence of the source IP
   address validity among ASes.

   Furthermore, most of the existing mechanisms applied to Intra-AS or
   Inter-AS SAV only take the manner of allowlist.  However, a allowlist
   may result in false positive when a legitimate IP address does not
   appear in the allowlist.  That is, allowlist can be incomplete.

   In contrast, blocklist can avoid false positive in some way as it
   only drop illegal packets currently known by it, even though
   incomplete blocklist may result in false negative.  The choice
   between allowlist and blocklist is important for improving the
   accuracy of SAV.

4.  Gap Analysis

   High accuracy is the basic requirement of any intra- or inter-AS SAV
   mechanism.  For any SAV mechanism, false positive must be avoided
   because legitimate traffic must not be influenced.  On that basis,
   SAV should also reduce false negative as much as possible.  However,
   existing SAV mechanisms can not well meet these requirements.

4.1.  Existing Intra-AS SAV mechanisms

   Operators can configure static ACLs on border nodes to validate
   source addresses.  The main drawback of ACL-based SAV is high
   operational overhead.  Limited application scenarios make the ACL-
   based method unable to do sufficient SAV on EAST-WEST traffic.

   Strict uRPF can generate SAV tables automatically, but it also has
   limited application scenarios.  Figure 2 illustrates an intra-AS SAV
   scenario.  In the scenario, AS1 runs strict uRPF.  An access network
   having IP address prefix 10.0.0.0/15 is attached to two border
   routers (Router1 and Router2) of AS1.  Due to customer's policy, it
   advertises 10.0.0.0/16 to Router1 and 10.1.0.0/16 to Router2.  Then,
   Router1 and Router2 will advertise the learned IP address prefixes to
   other routers in AS1 through intra-domain routing protocols such as
   OSPF and IS-IS.

Li, et al.                Expires 28 April 2022                 [Page 7]
Internet-Draft         SAV Use Case & Gap Analysis          October 2021

   Although customer only advertises 10.0.0.0/16 to Router1, it may send
   packets with source IP addresses belonging to 10.1.0.0/16 to Router1
   due to load balancing requirements.  Suppose the destination node is
   Router5.  Then the path to destination is
   Customer->Router1->Router3->Router5, while the reverse path is
   Router5->Router4->Router2->Customer.  The round trip routing path is
   asymmetric, which cannot be dealt with well by strict uRPF.

   Specifically speaking, strict uRPF is faced with the false positive
   problem under asymmetric routing scenarios.  When Router1/Router3
   runs strict uRPF, it learns SAV rules that packets with source
   address prefix of 10.0.0.0/16 should enter the router on interface
   '#'.  Note that strict uRPF takes allowlist in which the rule
   <10.0.0.0/16,interface '#> is maintained.  When the packets with
   source addresses of 10.1.0.0/16 arrive, they will be dropped, which
   results in false positive.  Similarly, when strict uRPF is deployed
   on Router2, the false positive problem still exists.

                +-----------------------------------+
                |  AS1      +----------+            |
                |           | Router 5 |            |
                |           +----------+            |
                |             /      \              |
                |            /        \             |
                |  +----------+      +----------+   |
                |  | Router 3 |------| Router 4 |   |
                |  +----#-----+      +----------+   |
                |       |                 |         |
                |       |                 |         |
                |  +----------+      +----------+   |
                |  | Router 1 |      | Router 2 |   |
                |  +----#-----+      +----------+   |
                |       \                 /         |
                +--------\---------------/----------+
                          \             /
                      10.0.0.0/16  10.1.0.0/16
                            \         /
                        +-------------------+
                        |  access network   |----10.0.0.0/15
                        +-------------------+
                Figure 2: An intra-AS SAV scenario

Li, et al.                Expires 28 April 2022                 [Page 8]
Internet-Draft         SAV Use Case & Gap Analysis          October 2021

4.2.  Existing Inter-AS SAV mechanisms

   The most popular inter-AS SAV is suggested by [RFC8704], which
   combines EFP-uRPF algorithm B and loose uRPF.  In particular, EFP-
   uRPF algorithm B is for Northward traffic validation.  It sacrifices
   the directionality of customer interfaces for reducing false positive
   cases [RFC8704].  Loose uRPF is for validating Southward traffic on
   lateral peer and transit provider interfaces.  It sacrifices
   directionality of Southward traffic completely.  Such a combined
   method sacrificing directionality will leads to false negative
   sometimes.

   Figure 3 illustrates an inter-AS SAV scenario where the above inter-
   AS SAV method will fail.  In the figure, there are two customer ASes,
   i.e., AS1 and AS2.  Both of them are attached to a provider AS, i.e.,
   AS4.  AS4 has a lateral peer and a provider, i.e., AS3 and AS5.
   Particularly, AS1 has IP address prefix P1 and advertises it to AS4.
   IP address prefix P2 is allocated to AS2 and is also advertised to
   AS4.  AS3 has IP address prefix P3 and AS5 has IP address prefix P5.
   P3 and P5 are also advertised to AS4 through BGP.  AS4 deploys SAV
   policies, i.e., a combination of EFP-uRPF algorithm B and loose uRPF.

                             +-----------------+
                             |  AS5 (provider) +---+P5
                             +--------+--------+
                                      |
                                      | P5[AS5]
                        P3            |
          +----------+ [AS3] +-------\/--------+
          |AS3 (peer)+------>+       AS4       |
          +-----+----+       +-+/\+-------+/\+-+
                |               /           \
                +              /             \
                P3     P1[AS1]/               \ P2[AS2]
                             /                 \
                            /                   \
                  +----------------+    +----------------+
            P1+---+ AS1 (customer) |    | AS2 (customer) +---+P2
                  +----------------+    +----------------+

                  Figure 3: An inter-AS SAV scenario

Li, et al.                Expires 28 April 2022                 [Page 9]
Internet-Draft         SAV Use Case & Gap Analysis          October 2021

   For Northward traffic, AS4 applies EFP-uRPF.  Under EFP-uRPF, AS4
   will generate allowlists considering P1 and P2 are legitimate on both
   the two customer interfaces.  When AS1 spoofs IP address prefix P2 of
   AS2, the malicious Northward traffic cannot be filtered by AS4.  The
   same is true when AS2 forges P1 of AS1.  That is to say, EPF-uRPF
   cannot prevent source address spoofing among customers even though it
   only focus on Northward traffic.

   For Southward traffic, AS4 deploys loose uRPF for the interfaces of
   AS3 and AS5.  It will learn that the packets with source addresses of
   P3 or P5 can be accepted without validating the specific arrival
   interface.  Since loose uRPF loses directionality completely, it
   obviously will fail in dealing with the source address spoofing
   between its lateral peer and provider, i.e., AS3 and AS5.

   The instinctive drawbacks of uRPF-like SAV mechanisms come from the
   dependence on local FIB and RIB.  Local FIB and RIB roughly describe
   the relationship among customers, providers, and lateral peers, which
   inherently cannot completely restore directionality information of
   network traffic.  The mismatching of advertised routing information
   and real data path (e.g., asymmetric routing) will do reduce the
   accuracy of source address validation.

5.  Design Considerations

   The key to address the instinctive drawbacks of existing intra- and
   inter-AS SAV mechanisms is to overcome the limitations of advertised
   routing information (expressed as RIB and FIB).  That is to say, SAV
   should follow the real data forwarding path.  To this end, a path
   probing method can be taken.  Particularly, a router (called a start
   router) can proactively send probing packets carrying source
   addresses originated locally to all the destinations known by the
   router.  These packets will be forwarded to each destination along
   the real forwarding paths.  Routers along the forwarding paths will
   relay these packets.  At the same time, these traversed routers learn
   the pair <source address prefix, interface> infomration for the start
   router and could generate SAV tables based on such information.  SAV
   tables will be used to filter packets to prevent spoofing IP
   addresses originated from the start router.

Li, et al.                Expires 28 April 2022                [Page 10]
Internet-Draft         SAV Use Case & Gap Analysis          October 2021

   The goal of the design is to achieve zero false positive while trying
   best to reduce false negative in both Intra-AS and Inter-AS SAVs.  In
   practice, it cannot be guaranteed that complete forwarding
   information is always learned from all interfaces.  Therefore, a
   combination of allowlist and blocklist is an alternative way to
   improve the accuracy of SAV.  If an interface is able to learn the
   complete forwarding information, allowlist is fine.  Otherwise,
   blocklist would be better than allowlist since the former only
   validates the legality of learned address information.

   Besides high accuracy, designing a practical SAV mechanism needs to
   consider many practical issues:

   *  High scalability.  The design should not induce much overhead
      (e.g., bandwidth cost of path probing).  A fast convergence
      performance under environment changes is also important for
      improving the scalability in different scales of networks.

   *  High deployability.  SAV tables should be generated automatically
      to reduce the operational cost in practice.  A strategy of
      incremental deployment also needs to be considered.

   *  High security.  The design should include mechanisms to guarantee
      the integrity of probing packets.  The path probing-based SAV
      should be free of Man-in-the-Middle Attack.

6.  Security Considerations

   TBD

7.  Contributors

   TBD

8.  Acknowledgments

   TBD

9.  Normative References

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

Li, et al.                Expires 28 April 2022                [Page 11]
Internet-Draft         SAV Use Case & Gap Analysis          October 2021

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

   [RFC7039]  Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
              "Source Address Validation Improvement (SAVI) Framework",
              RFC 7039, DOI 10.17487/RFC7039, October 2013,
              <https://www.rfc-editor.org/info/rfc7039>.

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

Authors' Addresses

   Dan Li
   Tsinghua
   Beijing
   China

   Email: tolidan@tsinghua.edu.cn

   Jianping Wu
   Tsinghua
   Beijing
   China

   Email: jianping@cernet.edu.cn

   Mingqing Huang
   Huawei
   Beijing
   China

Li, et al.                Expires 28 April 2022                [Page 12]
Internet-Draft         SAV Use Case & Gap Analysis          October 2021

   Email: huangmingqing@huawei.com

   Lancheng Qin
   Tsinghua
   Beijing
   China

   Email: qlc19@mails.tsinghua.edu.cn

   Nan Geng
   Huawei
   Beijing
   China

   Email: gengnan@huawei.com

Li, et al.                Expires 28 April 2022                [Page 13]