<?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-sava-intra-domain-use-cases-00"
     ipr="trust200902">
  <front>
    <title abbrev="SAVA Intra-domain Use Cases">Soure Address Validation
    Architecture (SAVA): Intra-domain Use Cases</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="12" month="July" year="2020"/>

    <!---->

    <keyword/>

    <abstract>
      <t>This document identifies scenarios where existing approaches for
      detection and mitigation of source address spoofing don't perform
      perfectly. Either Ingress ACL filtering [RFC3704], 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 identifies two such
      scenarios and 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 without
        permission of the receiver. Although this openness design improves the
        scalability of the Internet, it also leaves security risks, namely, a
        sender can forge his/her source address when sending the packets,
        which is also well known as source address spoofing.</t>

        <t>Due to the lack of source address spoofing detection mechanism,
        Denial of Service (DoS) attacks seriously compromise network security.
        By employing source address spoofing, attackers can well hide
        themselves and pin the blame on the destination networks.
        Administrators often spend a lot of effort identifying attack packets
        without being able to locate the attacker's true source address. In
        addition to DOS attacks, source address spoofing is also used in a
        multitude of ways. The threats of source address spoofing have been
        well documented in <xref target="RFC6959"/>. To briefly summarize, the
        possible attacks by source address spoofing includes 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 source address spoofing
        <xref target="RFC2827"/>. Source Address Validation Improvement (SAVI)
        method <xref target="RFC7039"/> implements SAV at a fine granularity
        of host-level IP address validataion. The unicast Reverse Path
        Forwarding (uRPF) techniques (such as Strict uRPF, Feasible uRPF and
        Loose uRPF) <xref target="RFC3704"/> are particularly designed to
        perform SAV in the granularity of IP network. The Enhanced
        Feasible-Path Unicast Reverse Path Forwarding (EFP-uRPF) methods <xref
        target="RFC8704"/> further improve Feasible uRPF to reduce false
        positives in the case of inter-AS routing asymmetry and
        multihoming.</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 away 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 configuration brings
        scalability and reliability issues.</t>

        <t>Strict uRPF, typically performed at the network (IGP areas or ASes)
        boarder 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 the case of multihoming, when the data imcoming
        interface is different from the out-interface of the packet source IP
        address, using the longest prefix match , also refered to as
        asymmetric routing of data packets, Strict uRPF exibits false
        positive.</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.</t>

        <t>Feasible uRPF, typically performed at the network border routers,
        helps mitigate false positive 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 false positive 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 is learnt. There are cases when a device only
        learns one path but still has packets coming from other valid
        interfaces.</t>

        <t>EFP-uRPF, specifically performed at the AS border routers, further
        improves Feasible uRPF in the inter-AS scenario. An AS performing
        EFP-uRPF maintains an individual RPF list on every 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 the directly
        connected customer AS, enabling Algorithm A at this customer interface
        may exibit false postive filtering. In this case, enabling Algorithm B
        may mitigate the false positive. However, in case of directly
        connected customer ASes spoofing each other, Algorithm B exibits false
        negative.</t>
      </section>

      <section title="SAV Requirements and Challenges">
        <t>As the above overview indicates, to evaluate the quality of a
        specific SAV technique, one should balance between two general
        requirements: precise filtering and automatic implementation.</t>

        <t><list style="symbols">
            <t>Precise filtering: Two important indicators for precise
            filtering. 1) 0% false positive. If legitimate packets may be
            dropped, it can seriously affect the user's internet experience.
            2) 0% false negative. If some packets with a forged source address
            may pass through the SAV smoothly, it will pose potential security
            risks.</t>

            <t>Automatic implementation: In reality, the address space of an
            administrative domain (AD) may grow or update, and the routing
            policy within the address domain may be dynamically adjusted. One
            solution that relies entirely on manual configuration is neither
            scalable nor easy to deploy.</t>
          </list>Then to consider the whole network SAV soltuion, one should
        never rely on a single point but a systematic SAV technique
        combination depoyled at different network levels. As shown in Figure
        1, packet filtering at different levels from the access network to the
        AS boarder are all needed. In Figure 1, the administrive domain (AD)
        concept is used, which refers to a network domain managed by the same
        operator (OTT, ISP and so on). One AD is allowed to be divided into
        several sub-ADs and managed by different inner groups. There may exist
        different levels for sub-ADs. For example, sub-AD1 is the upper level
        compared to sub-AD2, meaning that sub-AD2 needs to connect through
        sub-AD1 for external reachability (i.e., networks outside AD1). So
        filtering at sub-AD boarders (between different levels and within the
        same level) is also necessary. Further, different sub-ADs can belong
        to one single AS or multiple ASes, which makes the filtering at the
        sub-AD boarders either intra-AS filtering or inter-AS filetering. In
        the rest of this document, we use the term SAVA (SAV architecture) to
        refer to the discussion of the systematic SAV solution.</t>

        <t><figure>
            <artwork><![CDATA[
+-------------------------------------+
|  AD1                                |
|                                     |
| +---------------------------------+ |
| | Sub-AD1   +--------+            | |
| |           |Router 4|            | |           +-------------+
| |           +--X---X-+            | |           | AD2         |
| |            X       X            | |           | +--------+  |
| |           X          X          | | +-----------+Router 6|  |
| |         X              X        | | +         | +--------+  |
| |   +---X----+        +---X+--------+ SAVA-Inter|             |
| |   |Router 2|        |Router 3|  | | Domain    |             |
| |   +--- X---+        +--X+-----------+         | +--------+  |
| +-------- X ---------- X ---------+ | +-----------+Router 5|  |
|             X         X  SAVA-Intra |           | +--------+  |
| +-----------+X------ X+--Domain---+ |           +-------------+
| | sub-AD2    +X-----X-+           | |
| |            |Router 1|           | |
| |            ++-----+-+           | |
| |             |     |             | |
| |             |     |             | |
| |             |     |             | |
| |     +-------++   ++-------+     | |
| |     |Switch 1|   |Switch 2|     | |
| |     ++------++   ++-------+     | |
| |      |      |     |  SAVA-Access| |
| |      |      |     |  (SAVI)     | |
| |      |      |     |      |      | |
| |   +--+-+ +--+-+  ++---+ ++---+  | |
| |   |Host| |Host|  |Host| |Host|  | |
| |   +----+ +----+  +----+ +----+  | |
| +---------------------------------+ |
|                                     |
+-------------------------------------+

            Figure 1: SAVA]]></artwork>
          </figure></t>

        <t>Looking back at specific SAV approaches, most limitations are
        caused by multihoming. Further, it is due to the routing information
        asymmetry at the mutil-homed devices. This document identifies two
        specific scenarios where existing SAV techniques fail to meet the
        above mentioned requirements.</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>FIB: Forwarding Information Base</t>

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

      <t>SAVA: Source Address Validation Architecture</t>

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

    <section title="Problem Statement">
      <t>As stated in Section 1.3, existing methods, e.g., Loose/Strict mode
      uRPF, FP-uRPF, EFP-uRPF are not able to achieve 100% accurate filtering
      (i.e., 0% FN and 0% FP) in certain scenarios. This document specifically
      indicate two typical intra-domain cases that conventional approaches
      fail to cover: 1) all sub-ADs are under the same AS; 2) sub-ADs are
      under different ASes.</t>

      <section title="SAVA Intra-domain Use Case 1: Intra-AS Multi-homing">
        <t>Figure 2 illustrates an intra-AS multihoming case, where sub-AD1,
        sub-AD2 and sub-AD3 are under the same AS.</t>

        <t>Router 1 is multi-homed to Router 2 and Router 3. Router 1 doesn't
        announce any of its routes to Router 2 nor Router 3. Static routes are
        configured on Router 1, Router 2 and Router 3. Supposely, both Router
        2 and Router 3 should have static routes P1/P2 with Router 1 as next
        hop configured. However, due to configuration error, or traffic
        control purpose, on Router 3, no P1/P2 static routes are configured.
        Router 2 and Router 3 are connected with ISIS or OSPF. P1/P2 are
        flooded from Router 2 to Router 3.</t>

        <t>Router 5 is single-homed to Router 3. Router 5 announces P3 to
        Router 3 using ISIS or OSPF. Router 3 floods P3 to Router 2 .</t>

        <t>Now suppose two data flow 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/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: does not apply at the intra-AS case.</t>
          </list></t>

        <t><figure>
            <artwork align="center"><![CDATA[+----------------------------------------------------------------+
| AS          +--------------------------------+                 |
|             |sub-AD1   +--------+            |                 |
|Static:      |          |Router 4|            | Static: NA      |
|Prefix: P1   |          +--X---X-+            |                 |
|NH: Router 1 |           X       X            | IGP:            |
|Prefix: P2   |          X          X          | Prefix: P1      |
|NH: Router 1 | +--------+ [P1,P2]  +--------+ | NH: Router 2    |
|             | |        +---------->        | | Prefix: P2      |
|IGP:         | |Router 2|          |Router 3| | NH: Router 2    |
|Prefix: P3   | |        +<---------+        | | Prefix: P3      |
|NH: Router 3 | +--------+   [P3]   +--------+ | NH: Router 5    |
|             +-------X---------------X------X-+                 |
|                      X             X         X                 |
|            [no prefix adv]  [no prefix adv]    X [P3]          |
|                        X         X               X             |
|             +----------+X------ X+----------+  +--X+---------+ |
|             |sub-AD2    +X-----X-+          |  |sub-AD3      | |
|             |           |Router 1|          |  |  +---X----- | |
|             |           ++-----+-+          |  |  |Router 5| | |
|             |         P1 |     | P2         |  |  +--------- | |
|             |            |     |            |  |      P3     | |
|             |    +-------++   ++-------+    |  +-------------+ |
|             |    |Switch 1|   |Switch 2|    |                  |
|             |    ++------++   ++------++    |                  |
|             |     |      |     |      |     |                  |
|             |  +--+-+ +--+-+  ++---+ ++---+ |                  |
|             |  |Host| |Host|  |Host| |Host| |                  |
|             |  +----+ +----+  +----+ +----+ |                  |
|             +-------------------------------+                  |
+----------------------------------------------------------------+

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

      <section title="SAVA Intra-domain Use Case 2: Inter-AS Multihoming">
        <t>Figure 3 illustrates an inter-AS multihoming case, where sub-AD1,
        sub-AD2 and sub-AD3 are under three different ASes.</t>

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

        <t>Router 5 (AS3) is single-homed to Router 3 (AS1). Router 5
        announces P3 to Router 3 through BGP. Router 3 propagates P3 to Router
        2 through BGP.</t>

        <t>Now suppose two data flow 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/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[+----------------------------------------------------------------+
|             +--------------------------------+                 |
|             |sub-AD1   +--------+            |                 |
|             |AS1       |Router 4|            |                 |
| BGP:        |          +--X---X-+            | BGP:            |
| Prefix: P1  |           X       X            | Prefix: P1      |
| NH: Router 1|          X          X          | NH: Router 2    |
| Prefix: P2  | +--------+ [P1,P2]  +--------+ | Prefix: P2      |
| NH: Router 1| |        +---------->        | | NH: Router 2    |
|             | |Router 2|          |Router 3| |                 |
| Prefix: P3  | |        +<---------+        | | Prefix: P3      |
| NH: Router 3| +--------+   [P3]   +--------+ | NH: Router 5    |
|             +-------X---------------X------X-+                 |
|                      X             X         X                 |
|               [P1/P2] X     [no prefix adv]    X [P3]          |
|                        X         X               X             |
|             +----------+X------ X+----------+  +--X+---------+ |
|             |sub-AD2    +X-----X-+          |  |sub-AD3      | |
|             |AS2        |Router 1|          |  |AS3  X       | |
|             |           ++-----+-+          |  |  +---X----- | |
|             |         P1 |     | P2         |  |  |Router 5| | |
|             |            |     |            |  |  +--------- | |
|             |    +-------++   ++-------+    |  |      P3     | |
|             |    |Switch 1|   |Switch 2|    |  +-------------+ |
|             |    ++------++   ++------++    |                  |
|             |     |      |     |      |     |                  |
|             |  +--+-+ +--+-+  ++---+ ++---+ |                  |
|             |  |Host| |Host|  |Host| |Host| |                  |
|             |  +----+ +----+  +----+ +----+ |                  |
|             +-------------------------------+                  |
+----------------------------------------------------------------+

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

    <section title="Solution Consideration">
      <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, thanks to the availability of the route origin
      information. More specifically, the construction of RPF lists using
      EFP-uRPF Algorithm A or B is augmented with data from Route Origin
      Authorization (ROA) [RFC6482], as well as Internet Routing Registry
      (IRR) data, making EFP-uRPF performing better than FR-uRPF regarding
      directionality. In fact, the global availability of ROA and IRR
      databeses provides a way for the multiple transit providers of the same
      multihomed network to share such information without extra way of data
      syncronization.</t>

      <t>In addition, although ERP-uRPF is striving for more accurate RPF list
      construction, there's still currenly no way of constructing an
      100%-accurate RPF list in the case shown in Figure 3. In order to to
      conquer such problem, it could help if devices in the upper level
      sub-AD(s) (i.e., Router 2 and Router 3) can share more information with
      each other through certain way.</t>

      <t>What's worse, in case of the intra-AS multi-homing, as indicated in
      Figure2, there's no such prefix to sub-AD mapping (e.g., P3 originates
      from sub-AD3) database publiclly available as ROA or IRR database, or
      automatically retrievable as RPKI ROA through RTR protocol <xref
      target="RFC8210"/>. Thus, enhancing such information sharing between
      devices of the upper level sub-AD(s) (i.e., Router 2 and Router 3) for
      the same multi-homed network, by extending certain routing protocols,
      could be a possible way.</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>
