Skip to main content

Distributed Source Address Validation (DSAV) Framework
draft-li-dsav-framework-00

The information below is for an old version of the document.
Document Type Active Internet-Draft (individual)
Authors Dan Li , Jianping Wu , Mingqing Huang , Lancheng Qin , Nan Geng
Last updated 2021-12-11
Stream (None)
Formats plain text html xml htmlized pdfized bibtex
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-li-dsav-framework-00
Network Working Group                                              D. Li
Internet-Draft                                                     J. Wu
Intended status: Informational                                  Tsinghua
Expires: 14 June 2022                                           M. Huang
                                                                  Huawei
                                                                  L. Qin
                                                                Tsinghua
                                                                 N. Geng
                                                                  Huawei
                                                        11 December 2021

         Distributed Source Address Validation (DSAV) Framework
                       draft-li-dsav-framework-00

Abstract

   This document provides an overall framework of Distributed Source
   Address Validation (DSAV) including both intra-AS and inter-AS
   levels.  It also describes related 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 14 June 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Li, et al.                Expires 14 June 2022                  [Page 1]
Internet-Draft               DSAV Framework                December 2021

   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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  DSAV Framework  . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Multicast Tree-like Path Probing  . . . . . . . . . . . .   5
     3.2.  Separate Address Information Advertisement  . . . . . . .   7
   4.  Accuracy  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Consistency . . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Deployability . . . . . . . . . . . . . . . . . . . . . . . .  10
   7.  Security  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Source address validation (SAV) is important to mitigate source
   address spoofing and contribute to the Internet security.  However,
   existing SAV mechanisms have limitations in accuracy.  Specifically,
   intra-AS SAV mechanisms (e.g. strict uRPF[RFC3704]) have serious
   false positive problems in the case of routing asymmetry, while
   inter-AS SAV mechanisms (e.g. loose uRPF[RFC3704] and EFP-
   uRPF[RFC8704]) have inherent false negative problems.  The root cause
   of their limitations is that they all achieve SAV based on local
   forwarding information base (FIB) or routing information base (RIB),
   which may not match the real forwarding direction from the source.
   In order to guarantee the accuracy, SAV should follow the real data-
   plane forwarding path.

Li, et al.                Expires 14 June 2022                  [Page 2]
Internet-Draft               DSAV Framework                December 2021

   This document provides a path probing-based framework to generate
   accurate SAV tables on routers at both intra-AS and inter-AS levels.
   In Distributed Source Address Validation (DSAV) framework, each
   router or AS originates probing packets carrying source address
   information as well as destination address information.  Routers or
   ASes along the forwarding path can identify valid incoming interfaces
   for related source prefixes and relay new probing packets based on
   the destination address information.  In particular, multicast tree-
   like path probing and separate address information advertisement are
   proposed in DSAV to reduce the communication overhead.

   This document also describes basic considerations related to DSAV,
   including accuracy, consistency, and deployability.

2.  Terminology

   Distributed Source Address Validation (DSAV)

   Some definitions during a path probing process:

   *  Node: A router or AS in this document.

   *  Probe initiation node: The node generating original probing
      packets.

   *  On-path node: The node along any of the forwarding paths of
      probing packets.  On-path nodes with respect to a probing packet
      include both the traversed and destination nodes.

   *  Probing packet: The packet originated from probe initiation nodes
      for generating SAV rules along its forwarding paths.

3.  DSAV Framework

   DSAV is a path probing-based SAV framework for generating SAV rules
   on routers.  It supports SAV at both the intra-AS and inter-AS
   levels.  Intra-AS SAV avoids source address spoofing from within AS.
   Inter-AS SAV prevents source address spoofing among ASes.  Despite of
   different application scenarios, DSAVs at the two levels hold the
   same key idea.  The core workflow of DSAV is briefly described as
   follows:

   a.  A probe initiation node (router or AS) generates probing packets
       carrying the source prefixes originated locally and the
       destination prefixes reachable by the node.

Li, et al.                Expires 14 June 2022                  [Page 3]
Internet-Draft               DSAV Framework                December 2021

   b.  Each probing packet will be forwarded from the probe initiation
       node to the corresponding destination node specified by the
       packets.

   c.  Each on-path node along the forwarding path of the probing packet
       will learn the arrival interface of the probing packet.  The
       learned interface will be considered as a legitimate arrival
       interface for data packets with same source IP addresses carried
       by the probing packet.  The pair <source prefix, interface> will
       be taken as SAV rules on on-path nodes.

   d.  These on-path nodes will enable the learned SAV rule at their
       data plane.  Any data packets mismatching the SAV rule will be
       considered as forged traffic and be dropped immediately.

   e.  Every node can act as a probe initiation node as well as an on-
       path node at the same time.  It can send original probing packets
       to protect its source addresses from be forged by attackers.
       Meanwhile, it can be an on-path node and generates SAV rules for
       source addresses of other probe initiation node.

   f.  The above steps can be executed periodically or when any of
       source address information, destination address information, or
       forwarding rules change.

   Figure 1 illustrates the workflow of DSAV.  There are total of four
   nodes in the network shown in Figure 1.  The network runs some
   routing protocols such as OSPF, IS-IS, and BGP.  Thus, Prefixes P1
   and P2, belonging to Node 1 and Node 3 respectively, are reachable by
   all the nodes.  Let's consider a path probing process where Node 1 is
   the probe initiation node.  Node 1 sends a probing packet carrying
   source address information (i.e., P1) and destination address
   information (i.e., P2).  According to the destination address
   information, the probe packet will be forwarded through the path of
   Node 1 -> Node 2 -> Node 3.  Node 2 and Node 3 (i.e., on-path nodes)
   will learn the SAV rule for P1, i.e., the pair <P1, interface '#'>.
   The rule indicates that data packets with source addresses of P1
   should arrive at Node 2 and Node 3 from interface '#'.  In this way,
   when Node 4 forwards packets with spoofed addresses of P1' to Node 2,
   Node 2 will drop them immediately based on the SAV rules.

Li, et al.                Expires 14 June 2022                  [Page 4]
Internet-Draft               DSAV Framework                December 2021

                            +---------------+
                            |     Node 1    +---+P1
                            +-------+-------+
                                    |
                                    | probing pkt:src_v=[P1],dst_v=[P2]
                                    |
          +----------+      +-------#-------+
          |  Node 4  +------+     Node 2    |
          +-----+----+      +-------+-------+
                |                   |
                +                   | probing pkt:src_v=[P1],dst_v=[P2]
                P1'                 |
                            +-------#--------+
                            |     Node 3     +---+P2
                            +----------------+
          P1 is the source prefix of Node 1.
          P1' is the spoofed P1 by Node 4.
          P2 is the source prefix of Node 3.
          '#' means the legitimate interface for packets with
              source addresses of P1.

                  Figure 1: An illustration of DSAV

   The example in Figure 1 shows a very simple DSAV scenario.  In real
   networks, there can be lots of nodes as well as a large number of IP
   address prefixes.  To provide a complete protection for the target
   network, every node can act as a probe initiation node and send
   probing packets, which will inevitably result in much overhead and
   limit the scalability of DSAV.  To address the issue, two mechanisms,
   i.e., multicast tree-like path probing and separate prefix
   information advertisement, are proposed and presented next.

3.1.  Multicast Tree-like Path Probing

   Consider that the number of probe initiation nodes and their
   reachable destination prefixes can be extremely large.  The
   communication overhead of DSAV is unacceptable for each node sending
   an individual probing packet to each reachable destination prefix.
   Multicast tree-like path probing is such a mechanism that can greatly
   reduce the number of probing packets.

   Particularly, a probe initiation node only needs to send one probing
   packet to each of its neighboring nodes (Here, packet fragmentation
   is not considered for brevity).  Each probing packet carries a source
   prefix list and a destination prefix list.  The source prefix list
   includes all the source address prefixes originated locally.  The
   destination prefix list contains all the reachable destination

Li, et al.                Expires 14 June 2022                  [Page 5]
Internet-Draft               DSAV Framework                December 2021

   prefixes corresponding to the same next hop in the FIB.  Then, the
   probing packet is sent to the corresponding next-hop node, i.e., the
   on-path node of the probing packet.  The on-path node receives the
   probing packet and generates SAV rules in the same way as described
   previously.  After that, the on-path node relays the received probing
   packet and sends packets to one or more neighboring nodes according
   to the destination prefix list of the received packet.  Each probing
   packet relayed by the on-path node carries an updated destination
   prefix list that is a subset of the original list.  The updated list
   contains only the destination prefixes of the original list
   corresponding to the same neighboring node.  Note that, the source
   prefix list has no need to be updated.  The relayed probing packet
   will then continue probing forwarding paths through the updated
   destination prefix list.  The following on-path nodes will generate
   SAV rules accordingly and relay the probing packets until reaching
   all the destination nodes.  The traversed forwarding paths during a
   path probing process look like a multicast tree, and the probe
   initiation node of the process is the root of the tree.

                                      +----------+
                                      |  Node 1  +---+P1
                                      +----+-----+
                                           | pkt:src_v=[P1],
                                           | dst_v=[P2,P3,P4]
                        pkt:src_v=[P1],    |
            +----------+  dst_v=[P4] +-----#-----+
            |  Node 4  #-------------+  Node 2   |---+P2
            +-----+----+             +-----+-----+
                  |                        | pkt:src_v=[P1],
                  +                        | dst_v=[P3]
                  P4                       |
                                     +-----#-----+
                                     |  Node 3   +---+P3
                                     +-----------+
              P1, P2, P3, and P4 are IP address prefixes belonging
                  to Node 1, 2, 3, and 4, respectively.
              Node 1 is the probe initiation node, and the other
                  nodes are on-path nodes.
              '#' means the legitimate interface for the packets with
                  source addresses of P1.

            Figure 2: An example of multicast tree-like path probing

   An example of multicast tree-like path probing is shown in Figure 2.
   Node 1 is the probe initiation node, and P2~P4 are reachable locally.
   Node 1 sends a probing packet to Node 2 with source prefix list [P1]
   and destination prefix list [P2, P3, P4].  Node 2 learns the SAV rule
   from the probing packet and relays the packet with updated

Li, et al.                Expires 14 June 2022                  [Page 6]
Internet-Draft               DSAV Framework                December 2021

   destination prefix list to Node 3 and 4.  The source prefix list
   keeps unchanged, while the destination prefix list is updated
   according to the forwarding rules on Node 2.  Finally, Node 2~4 learn
   and enable the SAV rule, i.e., <P1, interface '#'>.

   With multicast tree-like path probing, DSAV can reduce much
   unnecessary probing packets in networks and thus consumes less
   network resources.

3.2.  Separate Address Information Advertisement

   Probing packets may have large packet sizes because their source and
   destination prefix lists can be very large.  Besides, a binding of
   prefix information advertisement and path probing will sometimes
   induce much unnecessary overhead.  For example, a change on either
   destination prefix information or forwarding rules will make the
   probe initiation node advertise its source address information again
   even though no changes happen on source address information at all.
   Separate address information advertisement is taken to tackle the
   above problem by decoupling address information advertisement and
   path probing.

   Particularly, a node can be represented by a node ID (e.g., the
   router-ID for a router or the ASN for an AS).  For each probe
   initiation node, its source addresses together with its node ID can
   be advertised to other nodes through broadcast or existing underlay
   routing protocols (such as OSPF, IS-IS, and BGP).  Then, every node
   will know the mappings from a node ID to a list of source addresses.
   Now, probing packets do not need to carry a long list of source
   address prefixes whose field can be replaced with just one source
   node ID.

   Similarly, the reachable destination information of each probe
   initiation node can also be advertised separately, and then the
   destination prefix list in a probing packet can be replaced with a
   list of destination node IDs.  However, the replacement of source and
   destination prefix lists may result in false negative problems in
   some scenarios where the destination prefixes belonging to the same
   destination node have different forwarding paths.  Some additional
   mechanisms need to be imported into these scenarios.

Li, et al.                Expires 14 June 2022                  [Page 7]
Internet-Draft               DSAV Framework                December 2021

4.  Accuracy

   The goal of DSAV is to achieve high accuracy, i.e., achieve zero
   false positive and try best to reduce false negative.  Zero false
   positive guarantees legitimate traffic not being dropped by mistake,
   while reducing false negative means filtering source address forgery
   traffic as much as possible.

   The accuracy of DSAV is determined by the accuracy of source address
   information advertisement, destination address information
   advertisement, and path probing results.  The completeness of address
   information advertisement is important for the accuracy improvement
   of DSAV.  So, each probe initiation node should discover and
   advertise local address information carefully with the help of either
   automatic programs or manual configurations.  In the case of
   incomplete address information advertisement, on-path nodes can take
   a remedy method in their data planes, i.e., a combination of
   allowlist and blocklist.  Allowlist blocks any packets with unknown
   source addresses or illegal arrival interfaces, which requires
   complete address information advertisement.  In contrast, blocklist
   only drops packets with known source addresses but illegal arrival
   interfaces.  Packets with unknown source addresses are accepted under
   blocklist.  Combining allowlist and blocklist properly is helpful to
   eliminate false positive cases.

   The accuracy of path probing is also challenging.  Path probing
   should fully discover all the real forwarding paths of each
   destination prefix.  Any factor that can affect forwarding should be
   considered.  Here are three kinds of common forwarding cases:

   *  FIBs only match destination address prefixes.

   *  ECMP (Equal-cost multi-path routing) or UCMP (Unequal-cost multi-
      path routing).  To achieve multi-path routing, hashing functions
      are usually taken, which map packet header field values (e.g.,
      source/destination IP address, source/destination port number,
      protocol number) to candidate next hops.  Packets with the same
      destination IP address may be forwarding to different next hops.

   *  ACL redirection.  An ACL rule can have multiple match fields, and
      the match field of destination IP addresses can be included or not
      in an ACL rule.  So, similar to ECMP/UCMP, the packets with the
      same destination IP address may have different next-hop
      interfaces.

Li, et al.                Expires 14 June 2022                  [Page 8]
Internet-Draft               DSAV Framework                December 2021

   To achieve high accuracy of path probing, either a probe initiation
   node or an on-path node need to answer two questions accurately:
   which set of next-hop interfaces are for probing and what is the
   destination prefix list of the probing packet for each next-hop
   interface.  Before sending/relaying probing packets, a node should
   look up all the local forwarding rules to answer the above two
   questions.

5.  Consistency

   The factors influencing the accuracy of DSAV may change with time.
   Such changes will lower the performance of SAV and lead to false
   positive/negative problems.  The SAV rules generated through DSAV
   should be updated in time so as to keep consistent with new source
   address information, destination address information or path probing
   results.  The consistency of DSAV is important for the SAV framework
   working well in real networks.

   A simple method is to update source/destination address information
   and probe forwarding paths periodically.  An aging mechanism can also
   be used for SAV rules.  That is, SAV rules will expire after a period
   of time.  However, these solutions may take much time before
   eliminating false positive/negative.  Some quick convergence
   mechanisms are necessary to achieve consistency of DSAV in time.
   Here are some preliminary ideas for different cases:

   *  Address information changes.  A node sends new information
      advertisements immediately upon discovering its local source/
      destination address information changes.

   *  Forwarding path changes.  On-path nodes can store the probing
      information of recently relayed probing packets.  When route
      configuration or topology changes, some nodes' forwarding rules
      become different.  These nodes can generate probing packets for
      themselves as well as the nodes whose probing packets were ever
      relayed by them.  Then, new forwarding paths can be probed
      quickly.  For the scenarios where fast reroute (FRR) is deployed,
      the backup forwarding paths can be pre-probed, and the
      corresponding SAV rules can be installed in advance for fast
      convergence under failures.

Li, et al.                Expires 14 June 2022                  [Page 9]
Internet-Draft               DSAV Framework                December 2021

6.  Deployability

   It is difficult to ensure that all nodes deploy DSAV simultaneously,
   especially at inter-AS level.  In this case, each node only learns
   partial source address information or incomplete legitimate incoming
   interfaces for a source prefix, which can lead to false positive
   problems.  Therefore, DSAV should support incremental and partial
   deployment.

   When deployed incrementally or partially, nodes should still achieve
   zero false positive and minimize false negative based on incomplete
   SAV tables.  The process of data-plane SAV is as follows:

   *  For the source address whose source address information and
      incoming interface information are fully learned, nodes can
      strictly validate the authenticity by querying <source prefix,
      interface> in SAV tables, i.e. allowlist mode.

   *  For the source address whose source address information or
      incoming interface information is only partially learned or even
      not learned, nodes should pass those packets by default to avoid
      false positive problems, i.e. blocklist mode, since it is hard to
      identify the authenticity with incomplete information.

   Since inter-AS topology is greatly complex and ASes are managed by
   individual network operators, determining wheter the incoming
   interface information for a source prefix is learned completely is a
   real challenge.  Besides, in DSAV framework, neighboring (next-hop)
   node plays an important role in the propagation of probing packets,
   namely, a node cannot send or receive any probing packet if its
   neighboring nodes don't support DSAV.  Hence, at inter-AS level, DSAV
   recommends incremental deployment by customer cones.  This deployment
   pattern ensures that each AS learns complete source address
   information and incoming interface information for other ASes within
   the same customer cone.  With the merger of different customer cones
   where DSAV is deployed, the deployment scope of DSAV will gradually
   expand, and the defense capability against source address spoofing
   will gradually increase.

7.  Security

   TBD

8.  Normative References

Li, et al.                Expires 14 June 2022                 [Page 10]
Internet-Draft               DSAV Framework                December 2021

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

   [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

Li, et al.                Expires 14 June 2022                 [Page 11]
Internet-Draft               DSAV Framework                December 2021

   Mingqing Huang
   Huawei
   Beijing
   China

   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 14 June 2022                 [Page 12]