Source Prefix Advertisement for Intra-domain SAVNET

Introduction The main purpose of the intra-domain SAV for an AS A, is to block spoofing data packets from a host network or a customer network that use source addresses of other networks, as well as block spoofing data packets from other ASes that use source addresses of AS A (see ). However, existing intra-domain SAV solutions (e.g., BCP38 and BCP84 ) have problems of high operational overhead or inaccurate validation. Specifically, ACL-based ingress filtering (BCP38 ) requires manual operations to configure and update SAV rules, and strict uRPF (BCP84 ) may improperly block legitimate data packets in the scenario of routing asymmetry. To improve the accuracy upon existing intra-domain SAV mechanisms 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 allows SAVNET routers in an intra-domain network to signal SAV-specific information through SPA messages. 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. 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. The reader is encouraged to be familiar with and .

Terminology SAV Rule: The rule that describes the mapping relationship between a source address (prefix) and its valid incoming router interface(s). SAVNET Router: An intra-domain router that deploys SPA-based SAVNET. Host-facing Router: An intra-domain router facing an intra-domain host network. Customer-facing Router: An intra-domain router facing an intra-domain customer network. Single-homed Stub Network: A stub network that is belonging to or connected to only one AS. Multi-homed Stub Network: A stub network that is belonging to or connected to multiple ASes.

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.

Overview of SPA-based SAVNET SPA-based SAVNET requires SAVNET routers to signal SAV-specific information through SPA message communication. The SAV-specific information contains the necessary information that improves the accuracy of SAV rules and cannot be learned from existing routing information. By using SAV-specific information, SAVNET routers can generate allowlist SAV rules (i.e., "Interface-based prefix allowlist" mode in ) or blocklist SAV rules (i.e., "Interface-based prefix blocklist" mode in ) on specific router interfaces. The SAVNET router can be an intra-domain router facing a stub network (e.g., a host network and a customer network) or facing an external AS. Specifically, to block spoofing data packets from a host network or a customer network that use source addresses of other networks, SPA-based SAVNET can generate an allowlist on interfaces facing a host network or a customer network. The allowlist contains source prefixes of the corresponding network, because data packets from the network can only use source addresses belonging to the network unless there is a special case such as Direct Server Return (DSR). To block spoofing data packets from other ASes that use source addresses of the local AS, SPA-based SAVNET can generate a blocklist on interfaces facing an external AS, containing source prefixes of the local AS. In the following, introduces content of the SPA message and procedure of SAV rule generation. introduces the most recommended use case, an alternative use case, and two corner use cases of SPA-based SAVNET, respectively.

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 A SPA message contains two main types of information:

Source Prefix: This information contains source prefixes learned from the router's local routes to its stub network, i.e., the locally-known source prefixes of the stub network. Specifically, each Dest Prefix in RIB that has an outgoing interface towards the stub network will be considered as a source prefix of the stub network. Note that in the case of asymmetric routes, the locally-known source prefixes may be only a part of all source prefixes of the stub network.
Stub Network Identifier: For each source prefix contained in the SPA message, it is binded with a Stub Network Identifier (SNI). The SNI is used to identify which stub network owns the source prefix. Prefixes belonging to the same stub network MUST have an identical and unique SNI value. Different stub networks MUST have different SNI values. The SNI is the key SAV-specific information used by SPA-based SAVNET when generating allowlists or blocklists.

Source prefixes contained in a SPA message indicate source addresses that can only be used by data packets received from the stub network. Therefore, only SAVNET routers facing a single-homed stub network (but there can be multiple links between the intra-domain network and the stub network) will generate SPA messages.

SPA Message Communication After generating SPA messages, the SAVNET router will provide its SPA messages to other SAVNET routers in the same intra-domain network. shows an example of SPA message communication. Routers A and B are host-facing routers facing the same single-homed stub network. Router C is an AS border router (ASBR) facing an external AS. Routers A and B can automatically exchange their SPA messages to ensure that they learn the full source prefixes of the stub network, even if there is an asymmetric route. Router A or B can automatically provide its SPA message to Router C, informing Router C which source addresses cannot be used by data packets from an external AS.

An example of SPA message communication +----------+ | | | Router A | | Router B | | | +------+---+ <--------- +--+-------+ | | \ SPA message / | | \ of Router B / | | \ / | | +--------------+ | | | Stub Network | | | +--------------+ | +----------------------------------------+ ]]> Implementation consideration: Since the SPA message contains source prefixes of a stub network, SPA message communication can be implemented by using existing intra-domain routing protocols (e.g., OSPF, IS-IS, iBGP). When distributing the IP information of the stub network through the intra-domain routing protocol, the SAVNET router can bind the SNI with the IP information. This document focuses on the protocol-independent design of SPA-based SAVNET. Protocol designs and extensions are not in the scope of this document.

SAV Rule Generation After receiving SPA messages from other SAVNET router, each SAVNET router will generate allowlists or blocklists on specific interfaces:

Allowlist generation procedure: A SAVNET router facing a stub network can generate an allowlist on the corresponding interface by using its own SPA message as well as SPA messages of other SAVNET routers (if any) facing the same stub network. All source prefixes in SPA messages with the SNI of its stub network will be added into the allowlist. The stub network can be a host network, a customer network, a stub OSPF area, or a stub AS. When using an allowlist on an interface facing a stub network, it must ensure that the stub network is not multi-homed to another AS.
Blocklist generation procedure: A SAVNET router can generate a blocklist by using SPA messages from other SAVNET routers. All source prefixes in SPA messages will be added into the blocklist. The blocklist is recommended to be used on interfaces facing an external AS or facing a stub network that is multi-homed to multiple ASes.

Use Case

The Most Recommended Use Case SPA-based SAVNET is highly recommended to be deployed at host-facing routers, customer-facing routers, and AS border routers. It is because that these routers are closer to the source and thus will be more effective in identifying and discarding source-spoofed data packets. SPA-based SAVNET generates allowlists on interfaces facing a host network, a customer network, or a stub AS, and generates blocklists on interfaces facing a non-stub AS. shows an example of the most recommended use case. SPA-based SAVNET is deployed at Routers A, B, and C. The stub network 1 or 2 can be a host network, a customer network, or a stub AS. Stub network 1 is single-homed to the intra-domain network but multi-connected to Routers A and B. Stub network 1 is single-homed to the intra-domain network and single-connected to Router B. Router C is connected to an external non-stub AS. Stub network 1 has two source prefixes P1 and P2. Due to traffic engineering and load balance, Router A only learns the route to prefix P1 from its Interface '#' and Router B only learns the route to prefix P2 from its Interface '#'. The SNI value of stub network 1 is set as 1, and the SNI value of stub network 2 is set as 2.

An example of the most recommended use case of SPA-based SAVNET Router A generates a SPA message containing source prefix P1 with a SNI value of 1. Router B generates a SPA message containing source prefix P2 with a SNI value of 1, and source prefix P3 with a SNI value of 1. After that, Router A or Router B provides its SPA message to other SAVNET routers. Router A or Router B finally generates an allowlist on its Interface '#' containing source prefixes P1 and P2, because both source prefixes have the SNI value of stub network 1. In addition, Router B generates an allowlist on its Interface 'X' containing source prefix P3 because only prefix P3 has the SNI value of stub network 2. Router C finally generates a blocklist on its Interface '#' containing all source prefixes of all SPA messages, i.e., prefixes P1, P2, and P3. By using the allowlist or blocklist on different router interfaces, the intra-domain network can effectively prevent spoofing data packets from entering the intra-domain network while avoiding improper blocks. Routers A and B will only allow data packets from stub network 1 with source addresses in prefixes P1 and P2. Router B will only allow data packets from stub network 2 with source addresses in prefix P3. Router C will block data packets from external ASes with source addresses in prefixes P1, P2, and P3.

An Alternative Use Case SPA-based SAVNET can also be used on Area Border Routers (ABR) in inter-area cases. For example, if the stub network in is a stub OSPF area, SPA-based SAVNET can also generate an allowlist on interfaces facing the stub OSPF area and thus only allow data packets using source addresses belonging to the stub OSPF area. However, it is less effective than deploying SPA-based SAVNET on interfaces facing a host network, a customer network, or a stub AS, because allowlists on ABRs are coarser. As a result, deploying SPA-based SAVNET on ABRs is an alternative rather than the most recommended use case.

Two Corner Use Cases

Direct Server Return (DSR) In the case of DSR, the content server in a stub network will send data packets using source addresses of the anycast server in another AS (see ). To avoid blocking these special data packets, these specially used source addresses should be added into allowlists on interfaces facing a stub network where the content server locates.

Multi-homed Stub Network As mentioned in , if a stub network is multi-homed to other ASes, SPA-based SAVNET must not generate SPA messages for this stub network and must not use an allowlist on the interface facing this stub network. It is because the router facing this stub network may only learns a part of source prefixes of the stub network. Therefore, it is recommended to use a blocklist in this case.

Convergence Considerations The propagation speed of SPA messages is a key factor affecting 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.

Incremental Deployment Considerations In the most recommended use case, SPA-based SAVNET is deployed on all host-facing routers, customer-facing routers, and AS border routers. When SPA-based SAVNET has not been deployed in all of these required routers simultaneously, SPA-based SAVNET supports incremental deployment by providing incremental benefits. For allowlist generation, if the SAVNET router faces a stub network with only one link to the intra-domain network, it can generate an accurate allowlist on the corresponding interface without SPA messages of other routers. If the SAVNET router faces a stub network with multiple links to the intra-domain network, it only needs SPA messages of other routers facing the same stub network to generate a complete allowlist. For blocklist generation, if the SAVNET router only learns partial internal prefixes, the generated blocklist can still be used to prevent spoofing data packets using source addresses in these prefixes from entering the intra-domain network. As a result, when SPA-based SAVNET is partially deployed on the required routers, it can still block spoofing data packets on SAVNET routers.

Security Considerations The security considerations described in and also applies to this document.

IANA Considerations This document has no IANA actions.