<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-li-opsec-sav-gap-analysis-02"
     ipr="trust200902">
  <front>
    <title abbrev="SAV Gap Analysis">Soure Address Validation: Gap
    Analysis</title>

    <author fullname="Dan Li" initials="D." surname="Li">
      <organization>Tsinghua</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <country>China</country>
        </postal>

        <email>tolidan@tsinghua.edu.cn</email>
      </address>
    </author>

    <author fullname="Jianping Wu" initials="J." surname="Wu">
      <organization>Tsinghua</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>jianping@cernet.edu.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Yunan Gu" initials="Y." surname="Gu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>guyunan@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Lancheng Qin" initials="L." surname="Qin">
      <organization>Tsinghua</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>qlc19@mails.tsinghua.edu.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Tao Lin" initials="T." surname="Lin">
      <organization>H3C</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>lintao@h3c.com</email>

        <uri/>
      </address>
    </author>

    <date day="5" month="July" year="2021"/>

    <!---->

    <keyword/>

    <abstract>
      <t>This document identifies scenarios where existing IP spoofing
      approaches for detection and mitigation don't perform perfectly.
      Exsiting SAV (source address validation) approaches, either Ingress ACL
      filtering [RFC2827], unicast Reverse Path Forwarding (uRPF) [RFC3704],
      Feasible Path uRPF [RFC 3704], or Enhanced Feasible-Path uRPF [RFC8704]
      has limitations regarding eihter automated implemetation objective or
      detection accuracy objective (0% false positive and 0% false negative).
      This document provides the gap analysis of the exsting SAV approaches,
      and also provides solution discussions.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t/>

      <section title="Source Address Validation ">
        <t>The Internet is open to traffic, which means that a sender can
        generate traffic and send to any receiver in the Internet as long as
        the address is reachable. Although this openness design improves the
        scalability of the Internet, it also leaves security risks, e.g., a
        sender can forge the source address when sending the packets, which is
        also known as IP spoofing. IP spoofing is constantly used in Denial of
        Service (DoS) attacks, which seriously compromise network security.
        DOS attacks using IP spoofing makes it difficult for operators to
        locate the attacker's actual source address. <xref target="RFC6959"/>
        identifies different types of DOS attacks with IP spoofing, i.e.,
        single-packet attack, flood-based DoS, poisoning attack, spoof-based
        worm/malware propagation, reflective attack, accounting subversion,
        man-in-the-middle attack, third-party recon, etc.</t>
      </section>

      <section title="Existing SAV Techniques Overview">
        <t>Source address validation (SAV) verifies the authenticity of the
        packet's source address to detect and mitigate IP spoofing <xref
        target="RFC2827"/>. Existing methods, such as Source Address
        Validation Improvement (SAVI) <xref target="RFC7039"/>, unicast
        Reverse Path Forwarding (uRPF) (i.e., Strict uRPF, Feasible uRPF and
        Loose uRPF) <xref target="RFC3704"/>, as well as Enhanced
        Feasible-Path Unicast Reverse Path Forwarding (EFP-uRPF) methods <xref
        target="RFC8704"/> are deployed at different network levels to prevent
        IP spoofing.</t>

        <t>Overall, when evaluating a SAV technique, one should consider the
        following two perspectives.</t>

        <t><list style="hanging">
            <t hangText="1)">Precise filtering: Two important indicators for
            precise filtering. 1) 0% false positive (FP) rate. If legitimate
            packets are dropped, it can seriously affect the user experience.
            2) 0% false negative (FN) rate. If some packets with a forged
            source address passes, it poses potential security risks.</t>

            <t hangText="2)">Automatic implementation: In practice, the
            address space may grow, and routing policies may be dynamically
            adjusted. SAV solutions that rely entirely on manual configuration
            are either non-scalable or error-prone.</t>
          </list></t>

        <t>SAVI, typically performed at the access network, is enforced in
        switches, where the mapping relationship between an IP address and
        other "trust anchor" is maintained. A "trust anchor" can be link-layer
        information (such as MAC address), physical port of a switch to
        connect a host, etc. It enforces hosts to use legitimate IP source
        addresses. However, given numerous access networks managed by
        different operators, it is far from practice for all the access
        networks to simultaneously deploy SAVI. Therefore, in order to
        mitigate the security risks raised by source address spoofing, SAV
        performed in network border routers is also necessary. Although it
        does not provide the same filtering granualarity as SAVI does, it
        still helps the tracing of spoofing to a minimized network range.</t>

        <t>Ingress ACLs <xref target="RFC2827"/>, typically performed at the
        network border routers, is performed by manually maintaining a traffic
        filtering access list which contains acceptable source address for
        each interface. Only packets with a source address encompassed in the
        access list can be accepted. It strictly specifies the source address
        space of incoming packets. However, manual-based filtering method is
        error-prone and face scalability issues.</t>

        <t>Strict uRPF, typically performed at the network (IGP areas or ASes)
        border routers, requires that a data packet can be only accepted when
        the FIB contains a prefix that encompasses the source address and the
        corresponding out-interface matches the data incoming interface. It
        has the advantages of simple operation, easy deployment, and automatic
        update. However, in case of multihoming, when the data imcoming
        interface is different from the out-interface, which is also refered
        to as asymmetric routing of data packets, Strict uRPF exibits FP.</t>

        <t>Loose uRPF, sacrificing the directionality of Strict uRPF, only
        requires that the packet's source IP exists as a FIB entry.
        Intuitively, Loose uRPF cannot prevent the attacker from forging a
        source address that already exists in the FIB, which incurs FN
        detection.</t>

        <t>Feasible uRPF (FP-uRPF), typically performed at the network border
        routers, helps mitigate FP of Strict uRPF in the multihoming
        scenarios. Instead of installing only the best route into FIB as
        Strict uRPF does, Feasible uRPF installs all alternative paths into
        the FIB. It helps reduce FP filtering compared with the Strict uRPF,
        in the case when multiple paths are learnt from different interfaces.
        However, it should be noted that Feasible uRPF only works when
        multiple paths are learnt. There are cases when a device only learns
        one path but still has packets coming from other valid interfaces.
        Thus, FP-uRPF performs better than Loose uRPF regarding FP detection,
        but still doesn't not guarantee 0% FP.</t>

        <t>EFP-uRPF, specifically performed at the AS border routers, further
        improves FP-uRPF in the inter-AS scenario. An ASBR, performing
        EFP-uRPF, maintains an RPF filtering list on each customer/peer
        interface. It introduces two algorihtms (i.e., Algorithm A and
        Algorithm B) regarding different application scenarios. In the case
        that a customer interface fails to learn any route from a directly
        connected customer AS, enabling Algorithm A at this customer interface
        may exibit false postive detection. In this case, Algorithm B can
        mitigate the FP. However, in case of two customer ASes spoofing each
        other, Algorithm B exibits FN.</t>

        <t>This document specifically identifies two scenarios, where the
        above mentioned SAV techniques, i.e., Strict uRPF, Loose uRPF,
        FP-uRPF, and EFP-uRPF, fail to guarantee 0% FP and 0% FN
        detection.</t>
      </section>
    </section>

    <section title="Terminology">
      <t>IGP: Interior Gateway Protocol</t>

      <t>IS-IS: Intermediate System to Intermediate System</t>

      <t>BGP: Boarder Gateway Protocol</t>

      <t>RIB: Routing Information Base</t>

      <t>FIB: Forwarding Information Base</t>

      <t>SAV: Source Address Validation</t>

      <t>AD: Administrative Domain</t>
    </section>

    <section title="Problem Statement">
      <t/>

      <section title="Use Case 1: Inter-AS Multi-homing">
        <t>Figure 1 illustrates an inter-AS multihoming case.</t>

        <t>AS2 is multi-homed to AS1 and AS4. AS2 announces P1/P2 to AS1
        through BGP. AS2 doesn't announce any of its routes to AS4 due to
        policy control. P1/P2 are propagated from AS1 to AS4 through BGP.</t>

        <t>AS3 is single-homed to AS4. AS3 announces P3 to AS4 through BGP.
        AS4 propagates P3 to AS1 through BGP.</t>

        <t>Now suppose two data flows coming from AS2 to AS4: Flow 1 with
        source IP as P1, and Flow 2 with source IP as P3 (IP spoofing). Using
        existing SAV methods at AS4, Flow 1 is supposed to be passed, while
        Flow 2 is supposed to be dropped.</t>

        <t><list style="symbols">
            <t>Loose uRPF: works for Flow 1, but fails for Flow 2.</t>

            <t>Strict uRPF: works for Flow 2, but fails for Flow 1 (the
            incoming interface does not match P1/P2's out-interface).</t>

            <t>FP-uRFP: works for Flow 2, but fails for Flow 1 (no feasible
            path for P1/P2 other than the best route exists).</t>

            <t>EFP-uRPF: works for Flow 1, but fails for Flow 2 using
            Algorithm B. Works for Flow 2, but fails for Flow 1 when using
            Algorithm A.</t>
          </list></t>

        <t><figure>
            <artwork align="center"><![CDATA[                    P1[AS1 AS2]
                    P2[AS1 AS2]
+---------------+      (C2P)       +---------------+
|               +------------------>               |
|      AS1      |                  |      AS4      |
|               <------------------+               |
+----+/\+-------+   P3[AS4 AS3]    ++/\+-----+/\+--+
       \               (P2C)         /         \
        \                           /           \
      P1[AS2]              [no prefix adv]     P3[AS3]
      P2[AS2]                     /               \
     (C2P) \                     / (C2P)           \ (C2P)
            \                   /                   \
             \                 /                     \
          +---------------------+         +---------------+
          |                     |         |               |
          |    AS2(customer)    |         | AS3(customer) |
          |                     |         |               |
          +---------------------+         +---------------+
        P1,P2(prefixes originated)       P3(prefix originated)


      Figure 1: Asymmetric data flow in the Inter-AS scenario]]></artwork>
          </figure></t>
      </section>

      <section title="Use Case 2: Intra-AS Multi-homing">
        <t>Figure 2 illustrates an intra-AS multihoming case. To facilitate
        management, one AS can be divided into several administrative domains
        (ADs) and managed by different inner groups. In Figure 2, AD1 is the
        upper level compared to AD2 and AD3, meaning that AD2 or AD3 needs to
        connect through AD1 for external reachability (i.e., networks outside
        AD1). For example, AD1 is the backbone of one national education
        network, while AD2 and AD3 are the campus networks of the two
        universities.</t>

        <t>Router 1 is multi-homed to Router 2 and Router 3. No dynamic
        routing protocol set up between Router 1 and Router 2, as well as
        between Router 1 and Router 3. In AD2, static routes to outside AD2
        are configured on Router 1 with Router 3 as the next hop. In AD1,
        static route to P1 is configured on Router 2 and static route to P2 is
        configured on Router 3, due to traffic control purpose. Router 2 and
        Router 3 are connected with each other using ISIS or OSPF.</t>

        <t>Router 5 is single-homed to Router 3. In AD3, static routes to
        outside AD3 are configured on Router 5 with Router 3 as the next hop.
        In AD1,static route to P3 is configured on Router 3 with Router 5 as
        the next hop.</t>

        <t>Now suppose two data flows coming from Router 1 to Router 3: Flow 1
        with source IP as P1, and Flow 2 with source IP as P3 (IP spoofing).
        Using existing SAV methods at Router 3, Flow 1 is supposed to be
        passed, while Flow 2 is supposed to be dropped.</t>

        <t><list style="symbols">
            <t>Loose uRPF: works for Flow 1, but fails for Flow 2.</t>

            <t>Strict uRPF: works for Flow 2, but fails for Flow 1 (the
            incoming interface does not match P1's out-interface).</t>

            <t>FP-uRFP: works for Flow 2, but fails for Flow 1 (no feasible
            path for P1 other than the best route exists).</t>

            <t>EFP-uRPF: does not apply at the intra-AS case.</t>
          </list></t>

        <t><figure>
            <artwork align="center"><![CDATA[+----------------------------------------------------------------------+
|    AS                                                                |
|                 +--------------------------------+                   |
|                 | AD1     +------------+         |                   |
|                 |         |  Router 4  |         |                   |
|                 |         +-/\------/\-+         |                   |
|  Router 2       |           /        \           |    Router 3       |
|  Static RIB:    |          /          \          |    Static RIB:    |
|  Prefix: P1     | +--------+   [P1]   +--------+ |    Prefix: P2     |
|  NH: Router 1   | |        +---------->        | |    NH: Router 1   |
|                 | |Router 2|          |Router 3| |    Prefix: P3     |
|  IGP RIB:       | |        <----------+        | |    NH: Router 5   |
|  Prefix: P2     | +--------+  [P2,P3] +--------+ |                   |
|  NH: Router 3   +---/\-----------------/\----/\--+    IGP RIB:       |
|  Prefix: P3          \                 /      \       Prefix: P1     |
|  NH: Router 3         \               /        \      NH: Router 2   |
|                        \             /          \                    |
|               [no prefix adv]  [no prefix adv] [no prefix adv]       |
|                          \         /              \                  |
|                   +-------\-------/----+    +------\---------+       |
|                   |AD2  +----------+   |    |AD3  +--------+ |       |
|                   |     | Router 1 |   |    |     |Router 5| |       |
|                   |     +----------+   |    |     +--------+ |       |
|                   |        P1,P2       |    |      P3        |       |
|                   +--------------------+    +----------------+       |
|                 P1,P2(prefixes originated)  P3(prefix originated)    |
|                                                                      |
+----------------------------------------------------------------------+


     Figure 2: Asymmetric data flow in the Intra-AS scenario]]></artwork>
          </figure></t>
      </section>
    </section>

    <section title="Solution Discussions">
      <t>Both EFP-uRPF and FP-uRPF try to achieve a balance between
      flexibility (Loose uRPF) and directionality (Strict uRPF).</t>

      <t>In the inter-AS multi-homing scenario, EFP-uRPF further improves
      FR-uRPF's directionality. The key improvement of EFP-uRPF is that it
      synchronizes certain information between interfaces that share the same
      RPF filtering list, so as to construct an RPF list as comprehensive as
      possible, although <xref target="RFC8704"/> does not explicitly specify
      how the information is synchronized, e.g., what information, in which
      format and in which way. In addition, the construction of RPF lists can
      be further augmented with data from Route Origin Authorization (ROA)
      [RFC6482], as well as Internet Routing Registry (IRR) data. In fact, the
      global availability of ROA and IRR databeses provides a secondary
      information synchronization approach. However, EFP-uRPF still fails to
      achieve 0% FN and 0% FP in case of Figure 1. Further infomration
      synchronization between interfaces might provide further
      improvement.</t>

      <t>The above description works similarly for the intra-AS scenario.
      Information synchronization is also required in order to achieve higher
      filtering accuracy.</t>
    </section>

    <section anchor="Contributors" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Acknowledgments" title="Contributors">
      <t>TBD</t>
    </section>

    <section title="Acknowledgments">
      <t>TBD</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.3988'?>

      <?rfc include='reference.RFC.3209'?>

      <?rfc include='reference.I-D.openconfig-rtgwg-gnmi-spec'?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.1191'?>

      <?rfc include='reference.RFC.1195'?>

      <?rfc include='reference.RFC.7752'?>

      <?rfc include='reference.RFC.7854'?>

      <?rfc include='reference.RFC.6241'?>

      <?rfc include='reference.RFC.1157'?>

      <?rfc include='reference.I-D.ietf-netconf-yang-push'?>

      <?rfc include='reference.RFC.1213'?>

      <?rfc include='reference.I-D.song-ntf'?>

      <?rfc include='reference.I-D.brockners-inband-oam-requirements'?>

      <?rfc include='reference.RFC.6232'?>

      <?rfc include='reference.RFC.3719'?>

      <?rfc include='reference.I-D.ietf-grow-bmp-local-rib'?>

      <?rfc include='reference.I-D.ietf-grow-bmp-adj-rib-out'?>

      <?rfc include='reference.RFC.8231'?>

      <?rfc include='reference.RFC.3704'?>

      <?rfc include='reference.RFC.8704'?>

      <?rfc include='reference.RFC.2827'?>

      <?rfc include='reference.RFC.6959'?>

      <?rfc include='reference.RFC.7039'?>

      <?rfc include='reference.RFC.8210'?>
    </references>
  </back>
</rfc>
