Source Prefix Advertisement for Intra-domain SAVNET

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 ). 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 and BCP84 ) have problems of high operational overhead or inaccurate validation (see ). Specifically, ACL-based ingress filtering (BCP38 ) requires manual operations to configure and update the SAV rules, while uRPF-based solutions (BCP84 ) 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 . 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 when, and only when, they appear in all capitals, as shown here.

Goal of SPA-based SAVNET 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 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 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 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 are "Internet interfaces".

An intra-domain network that adopts SPA-based SAVNET 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 ) 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 , 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 , 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 ) 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 , 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 , 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 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 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 , 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 and also applies to this document.

IANA Considerations This document has no IANA actions.