Source Prefix Advertisement for Intra-domain SAVNET
Internet-Draft draft-li-savnet-source-prefix-advertisement-00
Dan Li
Tsinghua University
Beijing
China
tolidan@tsinghua.edu.cn
Nan Geng
Huawei
Beijing
China
gengnan@huawei.com
Lancheng Qin
Zhongguancun Laboratory
Beijing
China
qinlc@mail.zgclab.edu.cn
08 July 2024
Routing
SAVNET
Internet-Draft
This document proposes the Source Prefix Advertisement (SPA) technology for intra-domain SAVNET, called SPA-based SAVNET. SPA-based SAVNET allows routers in an intra-domain network to exchange SAV-specific information through SPA messages. By using SAV-specific information carried in SPA messages, routers can generate more accurate and robust SAV rules in an automatic way. This document introduces the content of SPA messages and the process of generating SAV rules using SPA messages. SPA messages can be transmitted by a new protocol or an extension to an existing protocol. Protocol designs and extensions are not in the scope of this document.
Introduction
The purpose of intra-domain source address validation (SAV) is to prevent outgoing data packets from an intra-domain subnet (e.g., a host network or a customer network) from forging source addresses of other intra-domain subnets or other ASes, and to prevent incoming data packets from external ASes from forging source addresses of the local AS. To this end, intra-domain SAV should focus on SAV at edge routers (i.e., host-facing routers or customer-facing routers), and AS border routers (see [I-D.ietf-savnet-intra-domain-architecture]). Specifically, edge routers should block data packets from the connected host network or customer network with a spoofed source IP address not belonging to that network. AS border routers should block data packets from other ASes with a spoofed source IP address belonging to the local AS.
Existing intra-domain SAV solutions (e.g., BCP38 [RFC2827] and BCP84 [RFC3704]) have problems of high operational overhead or inaccurate validation (see [I-D.ietf-savnet-intra-domain-problem-statement]). Specifically, ACL-based ingress filtering (BCP38 [RFC2827]) requires manual operations to configure and update the SAV rules, while uRPF-based solutions (BCP84 [RFC3704]) may improperly block legitimate data packets in the scenario of routing asymmetry. To improve the accuracy upon existing intra-domain SAV solutions and enable automatic update, intra-domain SAVNET architecture requires SAVNET routers to automatically generate SAV rules by using SAV-specific information [I-D.ietf-savnet-intra-domain-architecture].
This document proposes the Source Prefix Advertisement (SPA) technology for intra-domain SAVNET, called SPA-based SAVNET. Following the intra-domain SAVNET architecture, SPA-based SAVNET focuses on SAV at edge routers and AS border routers in an intra-domain network. It allows SAVNET routers within an intra-domain network to communicate SAV-specific information through SPA messages. SAVNET routers will not communicate SAV-specific information with routers/devices in intra-domain subnets and other ASes. By using SAV-specific information, SAVNET routers can generate more accurate and robust SAV rules in an automatic way.
This document introduces the content of SPA messages and the process of generating SAV rules using SPA messages. SPA messages can be transmitted by a new protocol or an extension to an existing protocol. Protocol designs and extensions are not in the scope of this document.
Terminology
SAV Rule: The rule in a router that describes the mapping relationship between a source address (prefix) and the valid incoming interface(s). It is used by a router to make SAV decisions and is inferred from the SAV Information Base.
Host-facing Router: An intra-domain router of an AS which is connected to an intra-domain host network (i.e., a layer-2 network).
Customer-facing Router: An intra-domain router of an AS which is connected to an intra-domain customer network running the routing protocol (i.e., a layer-3 network).
Edge router: A host-facing router or a customer-facing router.
AS Border Router: An intra-domain router of an AS which is connected to other ASes.
Subnet: An intra-domain host network or an intra-domain customer network.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Goal of SPA-based SAVNET
Figure 1 shows an intra-domain network that adopts SPA-based SAVNET. Router 1 and Router 2 are edge routers that enable SAV at the interfaces facing to a subnet. Router 3 is an AS border router that enables SAV at the interfaces facing to an AS.
This document defines four types of interfaces that should enable SPA-based SAVNET:
- Single-homing interface. The interface of an edge router that faces to a singled-homed subnet. For example, Intf.1 in Figure 1 is a "Single-homing interface".
- Complete multi-homing interface. For an edge router facing to a multi-homed subnet, if all routers facing to the multi-homed subnet are in the same AS, the interface facing to this subnet is "Complete multi-homing interface". In this case, the multi-homed subnet is called complete multi-homed subnet. For example, Intf.2 and Intf.3 in Figure 1 are "Complete multi-homing interfaces".
- Incomplete multi-homing interface. For an edge router facing to a multi-homed subnet, if some other routers facing to the multi-homed subnet are in other ASes, the interface facing to this subnet is "Incomplete multi-homing interface". In this case, the multi-homed subnet is called incomplete multi-homed subnet. For example, Intf.4 in Figure 1 is "Incomplete multi-homing interface".
- Internet interface. The interface of an AS border router that faces to another AS. Generally, a network usually has multiple "Internet interfaces" for load balancing or backup. For example, Intf.5 and Intf.6 in Figure 1 are "Internet interfaces".
An intra-domain network that adopts SPA-based SAVNET

+-----------------------------------------+
|               Other ASes                |
+-----------------------------------------+
              |      |                |
              |      |                |
+-------------|------|----------------|---+
| AS          |      |                |   |
|       Intf.5|      |Intf.6          |   |
|           +-*------*-+              |   |
|           | Router 3 |              |   |
|           +----------+              |   |
|              /     \                |   |
|             /       \               |   |
|            /         \              |   |
|   +----------+     +----------+     |   |
|   | Router 1 |     | Router 2 |     |   |
|   +--#-----#-+     +-#-----*--+     |   |
|Intf.1|      \Intf.2 /Intf.3 \Intf.4 |   |
|      |       \     /         \      |   |
|      |        \   /           \     |   |
|   Subnet1    Subnet2           Subnet3  |
|    (P1)      (P2, P3)          (P4,P5)  |
+-----------------------------------------+

Routers 1 and 2 are edge routers
Router 3 is an AS border router
Intf '#' enables prefix allowlist
Intf '*' enables prefix blocklist

The goal of SPA-based SAVNET is to automatically generate prefix allowlist or blocklist for the four types of interfaces:
- Single-homing interface. SPA-based SAVNET generates a prefix allowlist (i.e., "Interface-based prefix allowlist" mode in [I-D.huang-savnet-sav-table]) at each "Single-homing interface". The prefix allowlist should contain all source prefixes of the connected subnet and blocks data packets from that subnet with source addresses not belonging to these source prefixes. In Figure 1, the prefix allowlist for Intf. 1 should contain the source prefix of Subnet1 (i.e., prefix P1).
- Complete multi-homing interface. Same as "Single-homing interface", SPA-based SAVNET generates a prefix allowlist at each "Complete multi-homing interface", containing all source prefixes of the connected subnet. In Figure 1, the prefix allowlists for Intf. 2 or Intf. 3 should include the source prefixes of Subnet2 (i.e., prefixes P2 and P3). By using the prefix allowlist, Routers 1 and 2 can accurately block spoofing data packets from Subnet2 using source IP addresses not in prefixes P2 and P3.
- Incomplete multi-homing interface. For an "Incomplete multi-homing interface", if there is a asymmetric routing among the connected subnet and its multiple provider networks, it is hard to identify all source prefixes of the subnet without communication between the multiple provider networks. Therefore, SPA-based SAVNET generates a prefix blocklist (i.e., "Interface-based prefix blocklist" mode in [I-D.huang-savnet-sav-table]) at each "Incomplete multi-homing interface". The prefix blocklist should include all source prefixes belonging to the subnets connected to "Single-homing interfaces" and "Complete multi-homing interfaces". In Figure 1, the prefix blocklist of Intf. 4 should contain the source prefixes of Subnet1 and Subnet2 (i.e., prefixes P1, P2, and P3).
- Internet interface. Same as "Incomplete multi-homing interface", SPA-based SAVNET generates a prefix blocklist at each "Internet interface", containing all source prefixes belonging to the subnets connected to "Single-homing interfaces" and "Complete multi-homing interfaces". In Figure 1, the prefix blocklist of Intf. 5 and Intf. 6 should contain the source prefixes of Subnet1 and Subnet2 (i.e., prefixes P1, P2, and P3).
Source Prefix Advertisement Procedure
Source Prefix Advertisement (SPA) procedure includes three main steps: SPA message generation, SPA message communication, and SAV rule generation.
SPA Message Generation
An edge router with a "Single-homing interface" or "Complete multi-homing interface" will generate SPA messages containing four main types of information:
- Source Prefix: This information contains source prefixes of its single-homed subnet or complete multi-homed subnet that are learned through the router's local routes to that subnet. Specifically, each Dest Prefix in RIB that records the interface facing to the subnet as an outgoing interface will be considered as a source prefix of the subnet. For each source prefix, SPA message records three indicators which are introduced in the following.
- Multi-homing Interface Group Type (MIIG-Type): This indicates the type of the interface that learns the prefix. MIIG-Type MUST be one of the four types mentioned above.
- Multi-homing Interface Group Tag (MIIG-Tag): This is used to identify the subnet that owns the prefix. The prefixes belonging to the same subnet MUST have the identical MIIG-Tag value. Different subnets MUST have different MIIG-tag values.
- (Only) Source Flag: This indicates whether the prefix is owned by one subnet. By default, the flag is set because source IP addresses used in data packets originated from a subnet should belong to the subnet in most cases. However, for anycast addresses/prefixes or direct server return (DSR) addresses/prefixes, the flag should be unset (possibly manually).
SPA Message Communication
After generating SPA messages, the edge router will send its SPA messages to other edge routers and AS border routers. SPA messages can be transmitted by a new protocol or an extension to an existing protocol. Protocol designs and extensions are not in the scope of this document.
SAV Rule Generation
The following describes how to generate SAV rules on the above four types of interfaces.
- For a "Single-homing interface", the router can generate a prefix allowlist by using its own SPA messages without SPA messages from other routers. The prefix allowlist contains source prefixes of the single-homed subnet that are learned through the router's local routes to that subnet.
- For a "Complete multi-homing interface", the router generates the prefix allowlist by using both its own SPA messages and SPA messages from other routers facing to the same complete multi-homed subnet. All source prefixes in these SPA messages with the "MIIG-Tag" of the complete multi-homed subnet will be added into the prefix allowlist.
- For an "Incomplete multi-homing interface" or "Internet interface", the router generates a prefix blocklist. It processes its own SPA messages and SPA messages from other routers. Prefixes in these SPA messages with MIIG-Types of "Single-homing interface" or "Complete Multi-homing interface" and with Source Flag being set will be added into the prefix blocklist. Prefixes with Source Flag being unset will not be added into the blocklist because the prefix is multi-source and the "Incomplete multi-homing interface" or "Internet interface" may receive legitimate data packets using this prefix as source IP addresses.
Note that, SPA-based SAVNET can also work if the subnet is a stub AS. The source prefixes of the stub AS can be considered as the internal prefixes of the local AS when using SPA-based SAVNET.
Use Case
Figure 2 shows a use case of SPA-based SAVNET in an intra-domain network. Intf.1 of Router 1 is a "Single-homing interface" facing to Subnet1 which has prefix P1. Intf.2 of Router 1 and Intf.3 of Router 2 are "Complete multi-homing interfaces" facing to Subnet2 which has prefixes P2 and P3. Due to traffic engineering and load balance, Router 1 only learns the route to prefix P2 from Intf.2, while Router 2 only learns the route to prefix P3 from Intf.3. Intf.4 of Router 2 is an "Incomplete multi-homing interface" facing to Subnet 3 which has prefixes P4 and P5. Intf.5 and Intf.6 of Router 3 are "Internet interfaces" facing to other ASes.
A use case of SPA-based SAVNET

+-------------------------------------------+
|               Other ASes                  |
+----------------+------+----------------+--+
                 |      |                |
                 |      |                |
+----------------|------|----------------|--+
|    AS          |      |                |  |
|          Intf.5+      +Intf.6          |  |
|             +-+*+----+*+-+             |  |
|             |  Router 3  |             |  |
| [P1,SI,     /\--------/\-+  [P1,SI,    |  |
| Sub1,SRC]   / /        \ \  Sub1,SRC]  |  |
| [P2,CI,    / /[P3,CI,   \ \ [P2,CI,    |  |
| Sub2,SRC] / /  Sub2,SRC] \ \ Sub2,SRC] |  |
|     +------\/----+   +-----\/-----+    |  |
|     |  Router 1  |   |  Router 2  |    |  |
|     +--+#+---+#+-+   +-+#+---+*+--+    |  |
|   Intf.1|      \Intf.2 /Intf.3 \Intf.4 |  |
|         |       \     /         \      |  |
|         |        \   /           \     |  |
|      Subnet1    Subnet2           Subnet3 |
|       (P1)      (P2, P3)          (P4,P5) |
+-------------------------------------------+

Routers 1 and 2 are edge routers
Router 3 is an AS border router
Intf '#' enables prefix allowlist
Intf '*' enables prefix blocklist

Router 1 generates SPA messages for source prefixes (i.e., prefixes P1 and P2) learned from its local routes to Subnet 1 and Subnet 2. For prefix P1, the MIIG-Type is "Single-homing interface", the MIIG-Tag is "Subnet1", and the Source Flag is set (i.e., [P1, SI, Sub1, SRC]). For prefix P2, the MIIG-Type is "Complete multi-homing interface", the MIIG-Tag is "Subnet2", and the Source Flag is set (i.e., [P2, CI, Sub2, SRC]). After generating SPA messages, Router 1 sends its SPA messages to Routers 2 and 3.
Router 2 generates SPA messages for prefix P3. The MIIG-Type is "Complete multi-homing interface", the MIIG-Tag is "Subnet2", and the Source Flag is set (i.e., [P3, CI, Sub2, SRC]). After that, it sends its SPA messages to Routers 1 and 3.
As described in Section 3.3, Routers 1, 2, and 3 generate SAV rules after receiving SPA messages from other routers. For Router 1, it generates a prefix allowlist at Intf.1 containing prefix P1 by using its own SPA message [P1, SI, Sub1, SRC]. By using its own SPA message [P2, CI, Sub2, SRC] and Router 2's SPA messages [P3, CI, Sub2, SRC], it generates a prefix allowlist at Intf.2 containing prefixes P2 and P3. For Router 2, it generates a prefix allowlist at Intf.2 containing prefixes P2 and P3 by using its own SPA message [P3, CI, Sub2, SRC] and Router 1's SPA message [P2, CI, Sub2, SRC]. At Intf.4, Intf.5, or Intf.6, Router 2 or Router 3 generates a prefix blocklist containing prefixes P1, P2, and P3 by using all SPA messages of Router 1 and Router 2.
By using prefix allowlist or blocklist at different interfaces, the intra-domain network can prevent data packets using spoofing source addresses from entering the network while avoiding improper block. Intf.1 will only accept data packets from Subnet 1 with source addresses in prefix P1. Intf.2 and Intf.3 will only accept data packets from Subnet 2 with source addresses in prefixes P2 and P3. Intf.4, Intf.5, and Intf.6 will block data packets from Subnet 3 or other ASes with source addresses in prefixes P1, P2, and P3.
Convergence Considerations
The propagation speed of SAV-specific is a key factor affecting the convergence. Consider that routing information and SAV-specific information can be originated and advertised through a similar way, SAV-specific information SHOULD at least have a similar propagation speed as routing information. When designing SPA message communication methods, routing protocol-based methods should be preferred.
Deployment Considerations
SPA-based SAVNET can support incremental deployment by providing incremental benefits. In the scenario of incremental deployment, a router can only receive SPA messages from edge routers that deploy SPA-based SAVNET. For a router with a "Single-homing interface", it can generate accurate SAV rules at that interface without SPA messages from other routers. For a router with a "Complete multi-homing interface", it only needs SPA messages from other edge routers connected to the same subnet, but not from all edge routers. For a router with a "Incomplete multi-homing interface" or "Internet interface", if it only learns partial internal prefixes by processing SPA messages, the generated SAV rule can still prevent spoofing traffic using source addresses in those prefixes from entering the intra-domain network. In addition, the router can use routing information to learn more internal prefixes.
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.
IANA Considerations
This document has no IANA actions.
References
Normative References
[I-D.ietf-savnet-intra-domain-problem-statement]

Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements
Dan Li
Tsinghua University
Jianping Wu
Tsinghua University
Lancheng Qin
Tsinghua University
Mingqing(Michael) Huang
Huawei
Nan Geng
Huawei
13 February 2024
Internet-Draft draft-ietf-savnet-intra-domain-problem-statement-03
[I-D.ietf-savnet-intra-domain-architecture]

Intra-domain Source Address Validation (SAVNET) Architecture
Dan Li
Tsinghua University
Jianping Wu
Tsinghua University
Lancheng Qin
Tsinghua University
Nan Geng
Huawei
Li Chen
Zhongguancun Laboratory
12 April 2024
Internet-Draft draft-ietf-savnet-intra-domain-architecture-00
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[RFC2827]

Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
P. Ferguson
D. Senie
May 2000
BCP 38
RFC 2827
DOI 10.17487/RFC2827
[RFC3704]

Ingress Filtering for Multihomed Networks
F. Baker
P. Savola
March 2004
BCP 84
RFC 3704
DOI 10.17487/RFC3704
[I-D.huang-savnet-sav-table]

General Source Address Validation Capabilities
Mingqing(Michael) Huang
Weiqiang Cheng
China Mobile
Dan Li
Tsinghua University
Nan Geng
Huawei Technologies
Mingxing Liu
Huawei Technologies
Li Chen
Zhongguancun Laboratory
Changwang Lin
New H3C Technologies
3 March 2024
Internet-Draft draft-huang-savnet-sav-table-05