Source Prefix Advertisement for Intra-domain SAVNET

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 ). However, existing uRPF mechanisms 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 ). 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. It is a general intra-domain SAV mechanism that apply to different network topologies (e.g., mesh topology or tree topology) or routing scenarios (e.g., asymmetric routing or symmetric routing). 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 Network: An intra-domain stub network consists of hosts. Customer Network: An intra-domain stub network consists of hosts and routers. 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.

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.

Deployment Scope 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 ) or a blocklist SAV rule (i.e., "Interface-based prefix blocklist" mode in ) 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.

By using the generated allowlist SAV rules or blocklist SAV rules, SPA-based SAVNET effectively blocks spoofing data packets from host networks and customer networks that use a source address of other networks and blocks spoofing data packets from external ASes that use a source address of the local AS, while avoiding blocking legitimate data packets.

Incremental Deployment 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. The network operator can incrementally deploy SPA-based SAVNET in his/her AS to gradually improve the defense against source address spoofing attacks. In the following, this document describes the protocol-independent designs for SPA-based SAVNET, include procedures for SPA information generation (in ), SPA information communication (in ), and SAV rule generation (in ).

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.

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 IGP or iBGP. During the propagation of IGP messages, SAVNET routers can learn both routing information and SPA information. Specific protocol designs or extensions for SPA information communication are not in the scope of this document.

SAV Rule Generation After receiving SPA information from other SAVNET routers, SAVNET routers generate allowlist SAV rules or blocklist SAV rules on specific router interfaces. The detailed procedure for allowlist generation is as follows:

Considering all stub networks connected to the router, create a set of SNI values of these stub network. Call it Set A.
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:

Extract unique prefixes from SPA information and routing information learned from the IGP.
Include these prefixes into the blocklist SAV rule at router interfaces facing an external AS.

Use Case

SAV on Host-facing Routers, Customer-facing Routers, and AS Border Routers SPA-based SAVNET is used on host-facing Routers, customer-facing Routers, and AS border routers in an intra-domain network. shows an example. Customer Network is multi-homed to Routers A and B. Host Network is single-homed to Router C. Routers D and E are connected to external ASes. Data packets from Customer Network can use source addresses in prefixes P1 and P2. Data packets from Host Network can use source addresses in prefix P3. P' is the source IP address space for intra-domain router IPs and link IPs. Assume there is an asymmetric forwarding behavior or an asymmetric route among Router A, Router B, and Customer Network due to traffic engineering and load balance. For example, Router A forwards only data packets with destination addresses in prefix P1 to Customer Network while Router B forwards only data packets with destination addresses in prefix P2 to Customer Network. However, Customer Network will sends data packets with source addresses in prefixes P1 and P2 to both routers. In this case, as described in , strict uRPF on Router A's Interface # will improperly block data packets with source addresses in prefix P2 and strict uRPF on Router B's Interface # will improperly block data packets with source addresses in prefix P1.

An example of the most recommended use case of SPA-based SAVNET When deploying SPA-based SAVNET in this AS, SAVNET Routers A, B, and C will provide SPA information to other SAVNET routers. By using the received SPA information, Routers A and B will include both prefixes P1 and P2 in the allowlist at the Interface #, because both prefixes have the SNI value of Customer Network, even if the prefix that routers A and B learn from the local route to Customer Network may be different. Router C will include prefix P3 in the allowlist at its Interface #. Routers D and E will include all internal prefixes in the blocklist at their Interfaces #.

A Special Scenario: 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 must be added into the allowlist SAV rule at interfaces facing a stub network where the content server locates. Since routers as well as current routing architecture do not have this information, this may requires manual configuration.

Considerations of SAV on Inner Routers Host-facing routers, customer-facing routers, and AS border routers serve as key vantage points for performing intra-domain SAV. These routers can effectively prevent spoofing traffic from entering the intra-domain router network, ensuring a more secure and reliable routing environment. In addition to these routers, inner routers (such as Routers F and G in ) may also be able to use SPA information to perform SAV. They can use SPA information together with topology information learned from the IGP to infer the possible incoming directions for a source prefix. However, performing SAV on inner routers may be inefficient in certain network topologies, such as mesh networks. This is because every inner router may receive legitimate data packets with the same source IP address from multiple or even all directions. As a result, the use case of SAV on inner routers is limited.

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

IANA Considerations This document has no IANA actions.