<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
     docName="draft-wang-savnet-intra-domain-solution-bm-spf-01"
     ipr="trust200902">
  <front>
    <title abbrev="BM-SPF-SAVNET">Intra-domain Source Address Validation (SAV)
    Solution Based on BM-SPF</title>

    <author fullname="Wei Wang" initials="W" surname="Wang">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>102209</code>

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

        <email>weiwang94@foxmail.com</email>
      </address>
    </author>

    <author fullname="Aijun Wang" initials="A" surname="Wang">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>102209</code>

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

        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>

    <author fullname="Ran Pang" initials="R" surname="Pang">
      <organization>China Unicom</organization>

      <address>
        <postal>
          <street>9 Shouti South Rd.</street>

          <city>Beijing</city>

          <region/>

          <code>100089</code>

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

        <phone/>

        <facsimile/>

        <email>pangran@chinaunicom.cn</email>

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

    <date day="20" month="July" year="2025"/>

    <area>RTG Area</area>

    <workgroup>SAVNET Working Group</workgroup>

    <keyword>RFC</keyword>

    <abstract>
      <t>This draft proposes a new intra-domain Source Address Validation
      (SAV) solution. This solution leverages the Bidirectional Metric-based
      Shortest Path First (BM-SPF) mechanism to avoid the complexity
      introduced by asymmetric routing for source address validation. It
      allows intra-domain routers to generate directly the SAV rule from the
      router's FIB table, based on the reality that the source and destination
      interface will be same if the IGP domain is symmetric assured.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t><xref target="I-D.ietf-savnet-intra-domain-architecture"/> proposed
      two use cases to describe the problems of existing intra-domain SAV
      mechanisms, and mentioned the intra-domain Source Address Validation
      (SAV) aims to achieve the following objectives: <list style="symbols">
          <t>To prevent outbound packets from intra-domain subnets (such as
          host networks or customer networks) from spoofing the source
          addresses of other intra-domain subnets or other Autonomous Systems
          (ASes)</t>

          <t>To prevent inbound packets from external ASes from spoofing the
          source addresses of the local AS</t>
        </list>To achieve these goals, intra-domain SAV needs to focus on the
      validation mechanisms at three types of routers: Edge Routers
      (host-facing routers, customer-facing routers), Internal Routers and AS
      Border Routers. Specifically, Edge Routers (host-facing or
      customer-facing routers) need to intercept spoofed packets from the
      connected networks whose source IP addresses do not belong to those
      networks. Interal Routers, such as spine routers, should also be
      considered to deploy SAV mechanism to simplify the overall deployment of
      SAV rules within the network. AS Border Routers need to intercept
      spoofed packets from other ASes whose source IP addresses belong to the
      local AS.</t>

      <t>It is better to find one general solution that can cover all of the
      above routers, increase the flexibility of intra-SAV deployment within
      the operator's network. The main challenge for such general solution is
      how to assure the symmetric routing on routers within the IGP domain. If
      such challenge is solved, the behavior of edge router(host-facing, or
      customer-facing), internal router(the best deployment point for the
      spine-leaf topology) and AS border router will be same: the SAV can be
      generated automatically based on the FIB table.</t>

      <t><xref target="I-D.wang-lsr-bidirectional-metric-spf"/> proposes a
      mechanism to accomplish the Shortest Path First (SPF) calculation based
      on the bidirectional metrics of the links. Under such mechanism, the
      bidirectional link metrics that are used by the two neighbors to
      implement the SPF algorithm to calculate the path will be same, which
      can avoid the asymmetric routing, and simplify the generation of SAV
      rule on intra domain IGP routers.</t>
    </section>

    <section title="Conventions used in this document">
      <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"/>
      .</t>
    </section>

    <section title="Terminology">
      <t>The following terms are used in this draft:<list style="empty">
          <t>BM-SPF: Bidirectional Metric based Shortest Path First Mechanism,
          defined in <xref
          target="I-D.wang-lsr-bidirectional-metric-spf"/>.</t>
        </list></t>
    </section>

    <section title="The Procedure of this Mechanism">
      <t/>

      <t>Figure 1 depicts an example of an AS that all routers within it
      support BM-SPF, the topology is aligned with <xref
      target="I-D.ietf-savnet-intra-domain-architecture"/>. On Router A, a
      summarized route 10.0.0.0/16 and a detailed route 10.0.1.0/24 should be
      configured, with its next hop interface directed to interface "#" of
      Router A. On Router B, a summarized route 10.0.0.0/16 and a detailed
      route 10.0.2.0/24 should be configured, with its next hop interface
      directed to interface "#" of Router B.<figure>
          <artwork><![CDATA[                +----------------------------------+
                |            Other ASes            |
                +----------------------------------+
                   |                            |
+------------------|----------------------------|--------------+
|    AS            |                            |              |
|            +-----#----+                 +-----#----+         |
|            | Router D +-----------------+ Router E |         |
|            +-----+----+                 +-----+----+         |
|                  |                            |              |
|            +----------------------------------------+        |
|            |      Other intra-domain routers        |        |
|            +--+-------------------------------+-----+        |
| 10.0.0.0/16  /       \  10.0.0.0/16           |              |
| 10.0.1.0/24 /         \ 10.0.2.0/24           |              |
|            /           \                      |              |
|     +----------+  +-----+----+          +----------+         |
|     | Router A |  | Router B +----------+ Router C |         |
|     +----#-----+  +-------#--+          +-----#----+         |
|           \              /                    |              |
|            \            /                     |              |
|             \          /                      |              |
|           +--------------+            +--------------+       |
|           |   Customer   |            |    Host      |       |
|           |   Network    |            |   Network    |       |
|           |     (P1)     |            |     (P2)     |       |
|           +--------------+            +--------------+       |
+--------------------------------------------------------------+
Figure 1: An example of an AS that all routers within it support BM-SPF
]]></artwork>
        </figure></t>

      <section title="SAV Procedure on AS Border Routers">
        <t>In Figure 1, the AS Border routers (Router D and Router E) has all
        the intra-domain prefixes that learned from the IGP protocol. The
        interface "#" on AS Border Routers enables mode 2 SAV rule (per <xref
        target="I-D.ietf-savnet-general-sav-capabilities"/>), which can
        generates an interface-based blocklist containing all these prefixes.
        For an AS Border Router (such as Router D or Router E), it should
        performs the following procedures:<list style="numbers">
            <t>Traverse all the prefixes in its FIB table;</t>

            <t>Add all prefixes and the corresponding interface into the
            blocklist on its interface '#';</t>
          </list></t>

        <t>When an AS Border Router receives packets with spoofed P1/P2 from
        interface &lsquo;#&rsquo;, the packets will be blocked from entering
        the AS because the source addresses of these packets are included in
        the blocklist of the AS Border Router.</t>

        <t>If an AS Border Router receives the packet with spoofed source
        address of the links within the AS, it can also block them
        automatically.</t>
      </section>

      <section title="SAV Procedure on Edge Routers">
        <t>In Figure 1, the customer network is multi-homed and the host
        network is single-homed. Router A and Router B are customer-facing
        routers, and Router C is host-facing router. The interfaces "#" on
        Router A, B and C enable mode 1 SAV rule.</t>

        <t>For single-homed host network, Router C can prevent other spoofed
        packets(source address is not from P2) from being accepted.</t>

        <t>For multi-homed customer network, to achieve the effect of
        engineering return traffic based on the granular address space, two
        kinds of routes(summarized and detailed) should be configured on the
        customer-facing routers, as shown in Figure 1.</t>

        <t>For an Edge Router (such as Router A, Router B or Router C), it
        should perform the following procedures:</t>

        <t><list style="numbers">
            <t>Traverse all the prefixes in its FIB table;</t>

            <t>Add all prefixes and the corresponding interface into the allow
            list on its interface '#';</t>
          </list></t>

        <t/>
      </section>

      <section title="SAV Procedure on Internal Routers">
        <t>Deploying the intra-domain SAV mechanism on Edge Routers and AS
        Border Router can solve the intra-domain SAV problem. But in some
        spine-leaf scenario, there is more efficient deployment point to
        achieve the same goal. For example, in Figure 1, if one spine router
        within "Other intra-domain routers" connects Router A, Router B and
        Router C, instead of deploying the intra-domain SAV mechanism on these
        leaf routers, the operator can select deploy it only on the spine
        router. With the BM-SPF mechanism (per <xref
        target="I-D.wang-lsr-bidirectional-metric-spf"/>), only symmetric
        routes exist in an AS with full BM-SPF deployment. The internal router
        (such as the spine leaf) can enable mode 1 SAV rule on its interfaces,
        the SAV procedures is performed in accordance with Section 4.2.</t>

        <t>In summary, SAV procedures in Internal Router and Edge Router (such
        as host-facing router and customer-facing router) are all the same.
        The procedures in AS Border Router can easily cover the prefixes from
        host network, customer network and internal links. Then the
        intra-domain SAV BM-SPF based solution can easily cover all of the
        scenarios that are described in <xref
        target="I-D.ietf-savnet-intra-domain-problem-statement"/>.</t>
      </section>

      <section title="Overview of BM-SPF">
        <t><xref target="I-D.wang-lsr-bidirectional-metric-spf"/> introduces
        the BM-SPF router capabilities announcement. Once the routers within
        the IGP domain know all of routers within its domain support and
        enable the BM-SPF feature, it can safely generate the SAV based on its
        FIB table.</t>

        <t>In an AS that has fully deployed BM-SPF, the bidirectional metric
        values for SPF calculation on each path are the same. This indicates
        that when two routers are communicating, the packets between them will
        be transmitted through the same path. That is to say, when any router
        within this AS communicates with a peer, whether it is sending packets
        to that peer or receiving packets from that peer, the same interface
        is used.</t>

        <t/>
      </section>
    </section>

    <section title="Security Considerations">
      <t>The security considerations described in <xref
      target="I-D.ietf-savnet-intra-domain-problem-statement"/> and <xref
      target="I-D.ietf-savnet-intra-domain-architecture"/> also applies to
      this draft.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>None</t>
    </section>
  </middle>

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

      <?rfc include='reference.I-D.ietf-savnet-intra-domain-problem-statement'?>

      <?rfc include='reference.I-D.ietf-savnet-intra-domain-architecture'?>

      <?rfc include='reference.I-D.wang-lsr-bidirectional-metric-spf'?>

      <?rfc include='reference.I-D.ietf-savnet-general-sav-capabilities'?>
    </references>
  </back>
</rfc>
