Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) Gap Analysis, Problem Statement and Requirements
draft-li-savnet-intra-domain-problem-statement-03

Network Working Group                                              D. Li
Internet-Draft                                                     J. Wu
Intended status: Informational                                    L. Qin
Expires: 11 May 2023                                 Tsinghua University
                                                                M. Huang
                                                                 N. Geng
                                                                  Huawei
                                                         7 November 2022

Source Address Validation in Intra-domain Networks (Intra-domain SAVNET)
            Gap Analysis, Problem Statement and Requirements
           draft-li-savnet-intra-domain-problem-statement-03

Abstract

   Source Address Validation in Intra-domain Networks (Intra-domain
   SAVNET) aims to make improvements to existing intra-domain Source
   Address Validation (SAV).  This document provides the gap analysis of
   existing intra-domain SAV mechanisms, describes the fundamental
   problems, and defines the requirements for improvements.

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.

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 11 May 2023.

Li, et al.                 Expires 11 May 2023                  [Page 1]
Internet-Draft    Intra-domain SAVNET Problem Statement    November 2022

Copyright Notice

   Copyright (c) 2022 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Improper Block  . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Vulnerability in Inbound Direction  . . . . . . . . . . .   6
       3.2.1.  Spoofing from outside the AS  . . . . . . . . . . . .   6
       3.2.2.  Spoofing from undeployed edge routers . . . . . . . .   7
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Inaccurate Validation . . . . . . . . . . . . . . . . . .   9
     4.2.  Limited Protection  . . . . . . . . . . . . . . . . . . .   9
     4.3.  High Operational Overhead . . . . . . . . . . . . . . . .   9
   5.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Accurate SAV  . . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  All-direction Protection  . . . . . . . . . . . . . . . .  10
     5.3.  Acceptable Overhead . . . . . . . . . . . . . . . . . . .  10
   6.  Intra-domain SAVNET Scope . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Source Address Validation (SAV) is important for defending against
   source address spoofing attacks and accurately tracing back to the
   attackers.  To be as effective as possible, SAV should be implemented
   as close to the source as possible.  Given numerous access networks
   managed by different operators, it is difficult to require all access
   networks to deploy SAV at the source (e.g., SAVI[RFC7039]).  When
   some access networks do not deploy SAV, intra-domain SAV helps filter
   out spoofed packets as close to the source as possible.

Li, et al.                 Expires 11 May 2023                  [Page 2]
Internet-Draft    Intra-domain SAVNET Problem Statement    November 2022

   Ingress filtering [RFC2827] [RFC3704] is the current practice of
   intra-domain SAV.  Figure 1 shows the typical adoption scenario of
   ingress filtering.  It is typically deployed at the edge router
   connected to a subnet to block spoofed traffic from the subnet.  A
   subnet refers to a user network attached to the edge router.

      +-------------------------------------------------------------+
      |                                                        AS   |
      |          +----------+            +----------+               |
      |          | Router 5 +------------+ Router 6 |               |
      |          +----------+            +----------+               |
      |            /      \                       \                 |
      |           /        \                       \                |
      |          /          \                     +----------+      |
      |  +----------+     +----------+            | Router 4 |      |
      |  | Router 1 |     | Router 2 |            +--------#-+      |
      |  +------#---+     +--#-------+              /      |        |
      |          \          /                      /       |        |
      |           \        /             +----------+   Subnet3(p3) |
      |            \      /              | Router 3 |               |
      |             \    /               +-----#----+               |
      |           Subnet1(p1)                  |                    |
      |                                   Subnet2(p2)               |
      |                                                             |
      +-------------------------------------------------------------+

      Router 1, 2, 3,and 4 implement ingress filtering at interface #
      to block spoofed traffic from subnet 1, 2, and 3.

       Figure 1: The typical adoption of ingress filtering.

   Static Access Control List (ACL) is a typical implementation of
   ingress filtering.  Operators can configure some matching rules to
   specify which source addresses 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.  Strict unicast Reverse
   Path Forwarding (uRPF) [RFC3704] is another suitable solution to
   achieve ingress filtering in intra-domain networks.  Routers
   deploying strict uRPF accept a data packet only when i) the local
   forwarding information base (FIB) contains a prefix encompassing the
   packet's source address and ii) the corresponding forwarding next hop
   for the prefix matches the packet's incoming direction.  Otherwise,
   the packet will be blocked.  However, in the scenario where data
   packets are under asymmetric routing, strict uRPF often improperly
   blocks legitimate traffic.  Feasible uRPF and loose uRPF are two
   other alternative implementations of ingress filtering, but their

Li, et al.                 Expires 11 May 2023                  [Page 3]
Internet-Draft    Intra-domain SAVNET Problem Statement    November 2022

   filtering rules are very loose and generally permit all (spoofing)
   packets with source addresses in the local FIB.  Therefore, a new
   intra-domain SAV mechanism is required to improve accuracy upon
   current ones.

   This document provides the gap analysis of existing intra-domain SAV
   mechanisms, describes their fundamental problems, and defines the
   requirements for improvements.

2.  Terminology

   SAV: Source Address Validation, i.e. validating the authenticity of a
   packet's source IP address.

   SAV rule: The rule generated by intra-domain SAV mechanisms that
   determines valid incoming interfaces for a specific source prefix.

   SAV table: The data structure that stores SAV rules on the data
   plane.  The router queries its local SAV table to validate the
   authenticity of source addresses.

   Improper block: The packets with legitimate source IP addresses are
   blocked improperly due to inaccurate SAV rules.

   Improper permit: The packets with spoofed source IP addresses are
   permitted improperly due to inaccurate SAV rules.

3.  Gap Analysis

3.1.  Improper Block

   Existing intra-domain SAV mechanisms can improperly block traffic
   with legitimate source addresses due to their technical limitations.
   For example, figure 2 illustrates an intra-domain scenario of multi-
   homed subnet.

   In this scenario, Subnet 1 is attached to two edge routers, i.e.
   Router 1 and Router 2.  Although Subnet 1 owns prefix 10.0.0.0/15,
   Subnet 1 expects traffic destined for 10.1.0.0/16 to come only from
   Router 1 and traffic destined for 10.0.0.0/16 to come only from
   Router 2, for traffic engineering or load balance purposes.  To this
   end, Router 1 only learns the sub prefix 10.1.0.0/16 from Subnet 1,
   while Router 2 only learns the other sub prefix 10.0.0.0/16 from
   Subnet 1.  Then, Router 1 and Router 2 advertise the learned sub
   prefix to other routers in the AS through intra-domain routing
   protocols such as OSPF or IS-IS.  Finally, Router 1 learns the route
   to 10.0.0.0/16 from Router 5, and Router 2 also learns the route to

Li, et al.                 Expires 11 May 2023                  [Page 4]
Internet-Draft    Intra-domain SAVNET Problem Statement    November 2022

   10.1.0.0/16 from Router 5.  Although Subnet 1 only expects incoming
   traffic destined for 10.0.0.0/16 to come from Router 2, it still
   sends outgoing traffic with source addresses of prefix 10.0.0.0/16 to
   Router 1, resulting in routing asymmetry.

    +-------------------------------------------------------------+
    |                                                      AS     |
    |                        +----------+                         |
    |                        | Router 5 |                         |
    | FIB for Router 1       +----------+  FIB for Router 2       |
    | Dest         Next_hop    /      \    Dest         Next_hop  |
    | 10.1.0.0/16  Subnet 1   /        \   10.0.0.0/16  Subnet 1  |
    | 10.0.0.0/16  Router 5  /         \/  10.1.0.0/16  Router 5  |
    |                +----------+     +----------+                |
    |                | Router 1 |     | Router 2 |                |
    |                +-----+#+--+     +-+#+------+                |
    |                        /\         /                         |
    |   Outgoing traffic with \        / Incoming traffic with    |
    |   source IP addresses    \      /  destination IP addresses |
    |   of 10.0.0.0/16          \    \/  of 10.0.0.0/16           |
    |                         +----------+                        |
    |                         | Subnet 1 |                        |
    |                         +----------+                        |
    |                        (10.0.0.0/15 )                       |
    |                                                             |
    +-------------------------------------------------------------+

    If Router 1 and 2 apply ingress filtering at interface #:
       - Strict uRPF has improper block problem;
       - ACL-based SAV requires manual update given prefix or topology
         update in Subnet 1

      Figure 2: Asymmetric routing in multi-homed subnet scenario.

Li, et al.                 Expires 11 May 2023                  [Page 5]
Internet-Draft    Intra-domain SAVNET Problem Statement    November 2022

   If Router 1 applies strict uRPF at the subnet interface, the SAV rule
   is that Router 1 only accepts packets with source addresses of
   10.1.0.0/16 from Subnet 1.  Therefore, when Subnet 1 sends packtes
   with source addresses of 10.0.0.0/16 to Router 1, strict uRPF at
   Router 1 will improperly block these legitimate packets.  Similarly,
   when Router 2 with strict uRPF deployed receives packets with source
   addresses of prefix 10.1.0.0/16 from Subnet 1, it will also
   improperly block these legitimate packets.  If Router 1 and 2 apply
   ACL-based SAV at interfaces '#', it requires manual update given
   prefix or topology update in Subnet 1.  Once the network operator
   does not update the ACL in time, resulting in the ACL status is
   inconsistent with the routing status, it will cause improper block
   problems as well.  Overall, strict uRPF has serious improper block
   problem in the case of routing asymmetry, and ACL-based SAV needs
   high operational overhead in dynamic networks.

3.2.  Vulnerability in Inbound Direction

   As shown in Figure 1, ingress filtering is typically deployed at the
   edge router connected to a subnet and only works for outbound traffic
   (traffic from the subnet to other networks) but does not work for
   inbound traffic (traffic from other networks to the subnet).  It
   prevents subnets from originating spoofed traffic, but does not
   protect subnets from being the victim of source address spoofing
   attack.

3.2.1.  Spoofing from outside the AS

   Figure 3 shows a scenario of source address spoofing from outside AS.
   Although the AS has applied ingress filtering at all edge routers,
   the spoofed traffic (even with forged intra-domain source addresses)
   can easily enter from inbound direction due to the lack of inbound
   SAV.

Li, et al.                 Expires 11 May 2023                  [Page 6]
Internet-Draft    Intra-domain SAVNET Problem Statement    November 2022

                    + Spoofed traffic with source addresses
                    | of p1, p2, or p3
     +--------------|----------------------------------------------+
     |              |                                         AS   |
     |          +--\/------+            +----------+               |
     |          | Router 5 +------------> Router 6 |               |
     |          +----------+            +----------+               |
     |            /      \                       \                 |
     |           /        \                      \/                |
     |          \/        \/                     +----------+      |
     |  +----------+     +----------+            | Router 4 |      |
     |  | Router 1 |     | Router 2 |            +--------#-+      |
     |  +------#---+     +--#-------+              /      |        |
     |          \          /                      \/      \/       |
     |           \        /             +----------+   Subnet3(p3) |
     |            \      /              | Router 3 |               |
     |            \/    \/              +-----#----+               |
     |           Subnet1(p1)                  |                    |
     |                                        \/                   |
     |                                   Subnet2(p2)               |
     +-------------------------------------------------------------+

       Spoofed traffic can easily enter subnets from inbound direction
       without being detected by ingress filtering

             Figure 3: Spoofing from outside AS.

3.2.2.  Spoofing from undeployed edge routers

   In practice, it is often a challenge to apply intra-domain SAV to all
   edge routers.  For example, the improper block problem described in
   Section 3.1 prevents ingress filtering from being implemented in some
   multi-homed scenarios.  In addition, there are also some routers that
   cannot support SAV due to their capabilities, versions, and vendors.
   However, when ingress filtering is partially deployed, the
   effectiveness of intra-domain SAV will be significantly degraded.

Li, et al.                 Expires 11 May 2023                  [Page 7]
Internet-Draft    Intra-domain SAVNET Problem Statement    November 2022

      +-------------------------------------------------------------+
      |                                                        AS   |
      |          +----------+            +----------+               |
      |          | Router 5 +------------> Router 6 |               |
      |          +----------+            +----------+               |
      |            /      /\                      \                 |
      |           /        \                      \/                |
      |          /          \                     +----------+      |
      |  +----------+     +----------+            | Router 4 |      |
      |  | Router 1 |     | Router 2 |            +--------#-+      |
      |  +----------+     +----------+              /      |        |
      |          \         /\                      /       \/       |
      |           \        / Spoofing    +----------+   Subnet3(p3) |
      |            \      /  traffic     | Router 3 |      |        |
      |             \    /               +-----#----+      +        |
      |           Subnet1(p1)                  |        Reflector   |
      |               |                        |                    |
      |               +                   Subnet2(p2)-+Victim       |
      |         Attacker (spoof p2)                                 |
      +-------------------------------------------------------------+

          Partial deployment scenario:
              - Router 3 and 4 deploy ingress filtering
              - Router 1 and 2 do not deploy ingress filtering

        Figure 4: Reflection attack in a partial deployment scenario.

   Figure 4 describes a reflection attack in a partial deployment
   scenario.  Router 1, 2, 3, and 4 are edge routers, each connected to
   a subnet.  Router 5 and 6 are two core routers that are responsible
   for transmitting traffic.  Assume only Router 3 and 4 apply ingress
   filtering at subnet interfaces, while Router 1 and 2 do not apply
   ingress filtering.  In this case, although subnets that deploy
   ingress filtering at the edge router (e.g., Subnet 2 and Subnet 3)
   cannot forge source addresses of other subnets, they are still
   vulnerable to reflection attacks from other undeployed subnets (e.g.,
   Subnet 1).

   For example, to conduct a reflection attack to the victim in Subnet
   2, the attacker in Subnet 1 can send a forged request with victim's
   source address to the reflector in Subnet 3.  Since Router 2 does not
   apply ingress filtering, the forged request will successfully enter
   the intra-domain network and be forwarded to the reflector.  When
   receiving the forged request, Router 4 will also permit the request
   due to the lack of inbound SAV.  In the end, the reflector will
   receive the forged request and generate a large number of responses
   to the victim, and the reflection attack succeeds.

Li, et al.                 Expires 11 May 2023                  [Page 8]
Internet-Draft    Intra-domain SAVNET Problem Statement    November 2022

4.  Problem Statement

   This section summarizes the fundamental problems existing in current
   intra-domain SAV from the above gap analysis.  The inaccurate
   validation, limited protection, and high operational overhead of
   current intra-domain SAV mechanisms are three main factors that
   hinder the deployment and compromise the effectiveness of intra-
   domain SAV.

4.1.  Inaccurate Validation

   ACL-based ingress filtering needs manual configuration and thus faces
   limitations in flexibility and accuracy in dynamic networks.  Strict
   uRPF-based ingress filtering automatically generates SAV tables, but
   may improperly block legitimate traffic under asymmetric routing.
   The root cause is that strict uRPF leverages the local FIB table to
   determine the incoming interface for source addresses, which may not
   match the real data-plane forwarding path from the source, due to the
   existence of asymmetric routes.  Hence, it may mistakenly consider a
   valid incoming interface as invalid, resulting in improper block
   problems; or consider an invalid incoming interface as valid,
   resulting in improper permit problems.

4.2.  Limited Protection

   Currently, ingress filtering is applied at edge routers and only
   works for traffic from direcly connected subnets, resulting in the
   inability to block spoofed traffic from inbound direction.
   Therefore, spoofed traffic with intra-domain source addresses can
   easily flow to any subnet from outside AS or undeployed edge routers
   (when intra-domain SAV is partially deployed).

4.3.  High Operational Overhead

   Since existing intra-domain SAV mechanisms fail to adapt to dynamic
   or asymmetric routing scenarios, if network operators want to apply
   intra-domain SAV and avoid improper block , they has to figure out
   which edge routers have asymmetric routing to the directly connected
   subnet, and implement ACL-based SAV at those edge routers instead of
   strict uRPF.  In addition, they have to manually update the ACL
   filtering rules in time when the subnet's prefix or topology changes.
   Both identifying asymmetric routes and manual update impose
   significant operational overhead on network operators.

5.  Requirements

   To make improvements to existing intra-domain SAV mechanisms, a new
   intra-domain SAV mechanism MUST satisfy the following requirements.

Li, et al.                 Expires 11 May 2023                  [Page 9]
Internet-Draft    Intra-domain SAVNET Problem Statement    November 2022

5.1.  Accurate SAV

   The new intra-domain SAV mechanism MUST ensure accurate SAV and avoid
   improper block under asymmetric routing.  Routers MUST be able to
   learn the real incoming interfaces for packets originated from the
   subnet which owns the corresponding source prefix.  In other words,
   accurate SAV MUST match the real data-plane forwarding path from the
   source.  Since this requirement cannot be met by using local FIB
   information, additional control-plane mechanisms SHOULD be needed to
   deliver the required information.

5.2.  All-direction Protection

   The new intra-domain SAV mechanism MUST work for traffic coming from
   all directions (i.e. for traffic coming from both subnet and
   neighboring router) and MUST be deployed in more routers to block
   spoofed traffic (from outside AS and undeployed edge routers) as
   close to the source as possible.  Especially, when partially
   deployed, it SHOULD be able to limit the malicious behavior of
   undeployed subnets to some extent.  At least, to prevent reflection
   attacks, it should prevent undeployed subnets from forging source
   addresses of deployed subnets.

5.3.  Acceptable Overhead

   The mechanism MUST not induce much overhead.  First, it MUST be able
   to automatically update and adapt to dynamic or asymmetric routing
   scenarios, instead of relying entirely on manual update.  Second, it
   MUST avoid data-plane packet modification and limit the number of
   control-plane protocol messages.

6.  Intra-domain SAVNET Scope

   Intra-domain SAVNET focuses on the same scope corresponding to
   existing intra-domain SAV mechanisms.  Generally, it includes all IP-
   encapsulated scenarios:

   *  Native IP forwarding: including both global routing table
      forwarding and CE site forwarding of VPN;

   *  IP-encapsulated Tunnel (IPsec, GRE, SRv6, etc.): focusing on the
      validation of the outer layer IP address;

   *  Both IPv4 and IPv6 addresses

   Scope does not include:

Li, et al.                 Expires 11 May 2023                 [Page 10]
Internet-Draft    Intra-domain SAVNET Problem Statement    November 2022

   *  Non-IP packets: including MPLS label-based forwarding and other
      non-IP-based forwarding.

7.  Security Considerations

   Intra-domain SAVNET focuses on routing protocol-based mechanisms.  It
   aims to use or extend existing routing architecture or protocols to
   implement the SAV function.  The intra-domain SAVNET mechanism MUST
   not introduce additional security vulnerabilities or confusion to the
   existing intra-domain control-plane protocols.  Similar to the
   security scope of intra-domain routing protocols, intra-domain SAVNET
   should ensure integrity and authentication of protocol packets that
   deliver the required SAV information.

   Intra-domain SAVNET does not provide protection against compromised
   or misconfigured routers that poison existing control plane
   protocols.  Such routers can not only disrupt the SAV function, but
   also affect the entire routing domain.

8.  IANA Considerations

   This document does not request any IANA allocations.

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

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

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

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

Li, et al.                 Expires 11 May 2023                 [Page 11]
Internet-Draft    Intra-domain SAVNET Problem Statement    November 2022

Authors' Addresses

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

   Jianping Wu
   Tsinghua University
   Beijing
   China
   Email: jianping@cernet.edu.cn

   Lancheng Qin
   Tsinghua University
   Beijing
   China
   Email: qlc19@mails.tsinghua.edu.cn

   Mingqing Huang
   Huawei
   Beijing
   China
   Email: huangmingqing@huawei.com

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

Li, et al.                 Expires 11 May 2023                 [Page 12]