SAVNET Working Group                                             W. Wang
Internet-Draft                                                   A. Wang
Intended status: Standards Track                           China Telecom
Expires: 22 August 2025                                 18 February 2025


 Intra-domain Source Address Validation (SAV) Solution Based on BM-SPF
           draft-wang-savnet-intra-domain-solution-bm-spf-00

Abstract

   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.

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 22 August 2025.

Copyright Notice

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










Wang & Wang              Expires 22 August 2025                 [Page 1]

Internet-Draft                BM-SPF-SAVNET                February 2025


   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.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  The Procedure of this Mechanism . . . . . . . . . . . . . . .   3
     4.1.  SAV Procedure on AS Border Routers  . . . . . . . . . . .   5
     4.2.  SAV Procedure on Customer-facing or Host-facing
           Routers . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  SAV Procedure on Internal Routers . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

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

   *  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)

   *  To prevent inbound packets from external ASes from spoofing the
      source addresses of the local AS

   To achieve these goals, intra-domain SAV needs to focus on the
   validation mechanisms at three types of routers: host-facing routers,
   customer-facing routers, and AS border routers.  Specifically, 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.  AS border routers need to intercept spoofed
   packets from other ASes whose source IP addresses belong to the local
   AS.




Wang & Wang              Expires 22 August 2025                 [Page 2]

Internet-Draft                BM-SPF-SAVNET                February 2025


   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.

   [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 them simplify the generation of
   SAV rule on intra domain IGP routers.

2.  Conventions used in this document

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

3.  Terminology

   The following terms are used in this draft:

      BM-SPF: Bidirectional Metric based Shortest Path First Mechanism,
      defined in [I-D.wang-lsr-bidirectional-metric-spf].

4.  The Procedure of this Mechanism

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

   Figure 1 depicts an example of an AS that all routers within it
   support BM-SPF.











Wang & Wang              Expires 22 August 2025                 [Page 3]

Internet-Draft                BM-SPF-SAVNET                February 2025


                            + Packets with
                            | spoofed P1/P2
  +-------------------------+-------------------------+
  |                         |                         |
  | AS                      \/                        |
  |                    +---+#+----+                   |
  |                    | Router 1 |                   |
  |                    +----------+                   |
  |                         |                         |
  |                         |                         |
  |                    +----------+                   |
  |                    | Router 2 |                   |
  |                    +----------+                   |
  |                      / |       \                  |
  |                    /   |         \                |
  |                  /     |           \              |
  |  10.0.1.0/16    /      |10.0.1.0/16 \             |
  |  10.0.1.1/24   /       |10.0.1.2/24  \            |
  | +----------+     +----------+      +----------+   |
  | | Router 3 |     | Router 4 |      | Router 5 |   |
  | +-----+#+--+     +---+#+----+      +---+#+----+   |
  |        \             /                  |         |
  |         \           /                   |         |
  |          \         /                    |         |
  |       +---------------+         +-------+-------+ |
  |       |   Customer    |         |     Host      | |
  |       |   Network     |         |   Network     | |
  |       |     (P1)      |         |     (P2)      | |
  |       +---------------+         +---------------+ |
  |                                                   |
  +---------------------------------------------------+
 Figure 1: An example of an AS that all routers within it support BM-SPF

   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.

   In this case, since there is no asymmetric routing, strict uRPF can
   be safely deployed on any router within the AS to form one SAV
   defence boundary.  Typically, in spine-leaf topology scenario, if we
   deploy strict uRPF on the spine router, it can prevent leaves
   connected to the same spine node from spoofing each other, and also
   the address of other ASes, thus reduces the burden to deploy SAV
   mechanism on every edge router, as that in conventional deployment.



Wang & Wang              Expires 22 August 2025                 [Page 4]

Internet-Draft                BM-SPF-SAVNET                February 2025


4.1.  SAV Procedure on AS Border Routers

   In Figure 1, Router 1 (the border router) has all the intra-domain
   prefixes that learned from the IGP protocol.  It can generates simply
   an blocklist containing all these prefixes on interface '#', which is
   bordered with other AS.

   When Router 1 receives packets with spoofed P1/P2 from interface ‘#’,
   the packets will be blocked from entering the AS because the source
   addresses of these packets are included in the blocklist of Router 1.

   If Router 1 receives the packet with spoofed source address of the
   links within the AS, it can also block them automatically.

4.2.  SAV Procedure on Customer-facing or Host-facing Routers

   In Figure 1, the customer network is multi-homed and the host network
   is single-homed.  Router 3 and Router 4 are customer-facing routers,
   and Router 5 is host-facing router.

   For single-homed host network, Router 5 need only deploy strict uRPF
   to achieve the desired effect that interface ‘#’ on Router 5 prevents
   other spoofed packets(source address is not from P2) from being
   accepted.

   For multi-homed customer network, to achieve the effect of
   engineering return traffic based on the granular address space, two
   kinds of routes(coarse and granular) should be configured on the
   customer-facing routers, as shown in Figure 1.  On Router 3, a coarse
   route 10.0.1.0/16 and a granular route 10.0.1.1/24 are configured.
   On Router 4, a coarse route 10.0.1.0/16 and a granular route
   10.0.1.2/24 are configured.

   These edge routers(Router 3 and Router 4) can need only also deploy
   strict uRPF to achieve the desired effect.  For example, if the
   packet with source address 10.0.1.2 are coming from interface '#' of
   Router 3, although it doesn't match the granular FIB entry of
   10.0.1.1/24, it match the coarse route 10.0.1.0/16, then the incoming
   traffic will not be blocked by Router 3.  The situation is same for
   the traffic with source address of 10.0.1.1 that arrives on Router 4.











Wang & Wang              Expires 22 August 2025                 [Page 5]

Internet-Draft                BM-SPF-SAVNET                February 2025


4.3.  SAV Procedure on Internal Routers

   Deploy 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, Router 2 is the spine
   router, with its three leaf routers(Router 3、Router 4、Router 5).
   Instead of deploy the intra-domain SAV mechanism on these leaf
   routers, the operator can select deploy it only on the spine Router
   2.  Once the Router 2 deploys the strict uRPF, it can safely block
   the spoofed packet from the host or customer network.

   In summary, SAV procedures in internal router, host-facing, customer-
   facing are all 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
   [I-D.ietf-savnet-intra-domain-problem-statement].

5.  Security Considerations

   The security considerations described in
   [I-D.ietf-savnet-intra-domain-problem-statement] and
   [I-D.ietf-savnet-intra-domain-architecture] also applies to this
   document.

6.  IANA Considerations

   None

7.  Normative References

   [I-D.ietf-savnet-intra-domain-architecture]
              Li, D., Wu, J., Qin, L., Geng, N., and L. Chen, "Intra-
              domain Source Address Validation (SAVNET) Architecture",
              Work in Progress, Internet-Draft, draft-ietf-savnet-intra-
              domain-architecture-01, 14 October 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
              intra-domain-architecture-01>.

   [I-D.ietf-savnet-intra-domain-problem-statement]
              Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source
              Address Validation in Intra-domain Networks Gap Analysis,
              Problem Statement, and Requirements", Work in Progress,
              Internet-Draft, draft-ietf-savnet-intra-domain-problem-
              statement-11, 17 February 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
              intra-domain-problem-statement-11>.



Wang & Wang              Expires 22 August 2025                 [Page 6]

Internet-Draft                BM-SPF-SAVNET                February 2025


   [I-D.wang-lsr-bidirectional-metric-spf]
              Wang, A., "Bidirectional Metric based Shortest Path First
              Mechanism", Work in Progress, Internet-Draft, draft-wang-
              lsr-bidirectional-metric-spf-00, 10 February 2025,
              <https://datatracker.ietf.org/doc/html/draft-wang-lsr-
              bidirectional-metric-spf-00>.

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

Authors' Addresses

   Wei Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: weiwang94@foxmail.com


   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: wangaj3@chinatelecom.cn





















Wang & Wang              Expires 22 August 2025                 [Page 7]