Source Prefix Advertisement for Intra-domain SAVNET

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 4 September 2025.¶

Copyright Notice

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

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

The main purpose of intra-domain SAV for an AS is blocking spoofing data packets from host networks and customer networks that use a source address of other networks and blocking spoofing data packets from external ASes that use a source address of the local AS (see [I-D.ietf-savnet-intra-domain-problem-statement]). However, existing uRPF mechanisms [RFC3704] will improperly block legitimate data packets in the case of asymmetric forwarding or asymmetric routing, while ACL-based ingress filtering relies entirely on manual update (see [I-D.ietf-savnet-intra-domain-problem-statement]).¶

To improve the accuracy and enable automatic update, this document proposes an intra-domain SAV mechanism, called source prefix advertisement (SPA) for intra-domain SAVNET (SPA-based SAVNET for short), to advance the technology for intra-domain SAV. SPA-based SAVNET allows routers in an intra-domain network to exchange SPA information. By using SPA information and routing information, intra-domain routers can determine more accurate SAV rules in an automatic manner.¶

The reader is encouraged to be familiar with [I-D.ietf-savnet-intra-domain-problem-statement] and [I-D.ietf-savnet-intra-domain-architecture].¶

2. Overview of SPA-based SAVNET

The deployment scope of SPA-based SAVNET for an AS includes host-facing routers, customer-facing routers, and AS border routers. SPA-based SAVNET allows these routers to exchange SPA information through the existing internal gateway protocol (IGP). By learning SPA information from other SAVNET routers, each SAVNET router can generate an allowlist SAV rule (i.e., "Interface-based prefix allowlist" mode in [I-D.huang-savnet-sav-table]) or a blocklist SAV rule (i.e., "Interface-based prefix blocklist" mode in [I-D.huang-savnet-sav-table]) on the specific router interface:¶

• For host-facing routers, they generate an allowlist SAV rule on interfaces facing a host network. The allowlist SAV rule exactly covers the space of source IP addresses that are used by data packets of the host network.¶

• For customer-facing routers, they generate an allowlist SAV rule on interfaces facing a customer network. The allowlist SAV rule exactly covers the space of source IP addresses that are used by data packets of the customer network.¶

• For AS border routers, they generate a blocklist SAV rule on interfaces facing an external AS. The allowlist SAV rule exactly covers the space of source IP addresses that are used by data packets of the local AS.¶

SPA-based SAVNET provides incremental benefits when incrementally deployed within the deployment scope. Every SAVNET router that adopts SPA-based SAVNET can identify spoofing data packets coming from a host network, customer network, or an AS. By using allowlist SAV rules, host-facing routers and customer-facing routers that adopt SPA-based SAVNET will block spoofing data packets from host networks and customer networks that use a source address of other networks. By using blocklist SAV rules, AS border routers that adopt SPA-based SAVNET will block spoofing data packets from external ASes that use a source address of the local AS.¶

In the following, this document describes the protocol-independent designs for SPA-based SAVNET, include procedures for SPA information generation (in Section 3), SPA information communication (in Section 4), and SAV rule generation (in Section 5). SPA information communication can be implemented by using an existing routing protocol. Specific protocol designs or extensions for SPA information communication are not in the scope of this document.¶

3. SPA Information Generation

Each SAVNET router connected to an intra-domain stub network (e.g., a host network or a customer network) generates SPA information. The content of SPA information mainly includes two parts:¶

• Source Prefix List (SPL): This list includes prefixes learned from the router's local routes towards the stub network. Specifically, each Dest Prefix in the router's RIB that has an outgoing interface towards the stub network will be included. If there is no asymmetric route between the SAVNET router and the stub network, the generated SPL should cover the source IP address space used by data packets of the stub network. However, if the asymmetric route exists, the generated SPL may include only a portion of the source IP address space of the stub network.¶

• Stub Network Identifier (SNI): This identifier indicates the identity of a stub network. Every intra-domain stub network must have a unique SNI value. Each prefix in the SPL is labeled with the SNI value of the corresponding stub network.¶

4. SPA Information Communication

After generating SPA information, each SAVNET router will provide its SPA information to other SAVNET routers. SPA information communication can be implemented by using the IGP (e.g., OSPF, IS-IS, or IBGP). During the propagation of IGP messages, SAVNET routers can learn both routing information and SPA information.¶

5. SAV Rule Generation

After receiving SPA information from other SAVNET router, SAVNET routers generate allowlist SAV rules or blocklist SAV rules on specific router interfaces.¶

The detailed procedure for allowlist generation is as follows:¶

1. Considering all stub network connected to the router, create a set of SNI values of these stub network. Call it Set A.¶

2. Considering all SPA information, for each SNI value in Set A, create a set of unique source prefixes that have the same SNI value. Include these prefixes into the allowlist SAV rule at router interfaces facing the stub network which has the same SNI value.¶

The detailed procedure for blocklist generation is as follows:¶

1. Extract unique prefixes from SPA information and routing information learned from the IGP.¶

2. Include these prefixes into the blocklist SAV rule at router interfaces facing an external AS.¶

6. Use Case

            +----------------------------------+
            |            Other ASes            |
            +----------------------------------+
               |                             |
+--------------|-----------------------------|--------+
|   AS         |                             |        |
|        +-----#----+                  +-----#----+   |
|        | Router D | -----------------| Router E |   |
|        +----------+                  +----------+   |
|              |                             |        |
|              |                             |        |
|              |                             |        |
|        +----------+                  +----------+   |
|        | Router F |                  | Router G |   |
|        +----------+                  +----------+   |
|         /         \                        |        |
|        /           \                       |        |
|       /             \                      |        |
| +----------+   +----------+          +----------+   |
| | Router A |---| Router B +----------+ Router C |   |
| +----#-----+   +-------#--+          +-----#----+   |
|       \               /                    |        |
|        \             /                     |        |
|         \           /                      |        |
|        +--------------+            +--------------+ |
|        |   Customer   |            |    Host      | |
|        |   Network    |            |   Network    | |
|        |  (P1 and P2) |            |    (P3)      | |
|        +--------------+            +--------------+ |
+-----------------------------------------------------+
SAV Rules generated by SPA-based SAVNET:
- Allowlist at Router A's Interface #: [P1, P2]
- Allowlist at Router B's Interface #: [P1, P2]
- Allowlist at Router C's Interface #: [P3]
- Blocklist at Router D's Interface #: [P1, P2, P3, P']
- Blocklist at Router E's Interface #: [P1, P2, P3, P']

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

8. IANA Considerations

This document has no IANA actions.¶

9. References

Authors' Addresses