Intra-domain Source Address Validation (SAV) Solution Based on BM-SPF

proposed two use cases to describe the problems of existing intra-domain SAV mechanisms, and mentioned the intra-domain Source Address Validation (SAV) aims to achieve the following objectives: To prevent outbound packets from intra-domain subnets (such as host networks or customer networks) from spoofing the source addresses of other intra-domain subnets or other Autonomous Systems (ASes) To prevent inbound packets from external ASes from spoofing the source addresses of the local AS To achieve these goals, intra-domain SAV needs to focus on the validation mechanisms at three types of routers: host-facing routers, customer-facing routers, and AS border routers. Specifically, host-facing or customer-facing routers need to intercept spoofed packets from the connected networks whose source IP addresses do not belong to those networks. AS border routers need to intercept spoofed packets from other ASes whose source IP addresses belong to the local AS. It is better to find one general solution that can cover all of the above routers, increase the flexibility of intra-SAV deployment within the operator's network. The main challenge for such general solution is how to assure the symmetric routing on routers within the IGP domain. If such challenge is solved, the behavior of edge router(host facing, or customer facing), internal router(the best deployment point for the spine-leaf topology) and AS border router will be same: the SAV can be generated automatically based on the FIB table. proposes a mechanism to accomplish the Shortest Path First (SPF) calculation based on the bidirectional metrics of the links. Under such mechanism, the bidirectional link metrics that are used by the two neighbors to implement the SPF algorithm to calculate the path will be same, which can avoid the asymmetric routing, and them simplify the generation of SAV rule on intra domain IGP routers.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The following terms are used in this draft: BM-SPF: Bidirectional Metric based Shortest Path First Mechanism, defined in .

introduces the BM-SPF router capabilities announcement. Once the routers within the IGP domain know all of routers within its domain support and enable the BM-SPF feature, it can safely generate the SAV based on its FIB table. Figure 1 depicts an example of an AS that all routers within it support BM-SPF.

In an AS that has fully deployed BM-SPF, the bidirectional metric values for SPF calculation on each path are the same. This indicates that when two routers are communicating, the packets between them will be transmitted through the same path. That is to say, when any router within this AS communicates with a peer, whether it is sending packets to that peer or receiving packets from that peer, the same interface is used. In this case, since there is no asymmetric routing, strict uRPF can be safely deployed on any router within the AS to form one SAV defence boundary. Typically, in spine-leaf topology scenario, if we deploy strict uRPF on the spine router, it can prevent leaves connected to the same spine node from spoofing each other, and also the address of other ASes, thus reduces the burden to deploy SAV mechanism on every edge router, as that in conventional deployment.

In Figure 1, Router 1 (the border router) has all the intra-domain prefixes that learned from the IGP protocol. It can generates simply an blocklist containing all these prefixes on interface '#', which is bordered with other AS. When Router 1 receives packets with spoofed P1/P2 from interface ‘#’, the packets will be blocked from entering the AS because the source addresses of these packets are included in the blocklist of Router 1. If Router 1 receives the packet with spoofed source address of the links within the AS, it can also block them automatically.

In Figure 1, the customer network is multi-homed and the host network is single-homed. Router 3 and Router 4 are customer-facing routers, and Router 5 is host-facing router. For single-homed host network, Router 5 need only deploy strict uRPF to achieve the desired effect that interface ‘#’ on Router 5 prevents other spoofed packets(source address is not from P2) from being accepted. For multi-homed customer network, to achieve the effect of engineering return traffic based on the granular address space, two kinds of routes(coarse and granular) should be configured on the customer-facing routers, as shown in Figure 1. On Router 3, a coarse route 10.0.1.0/16 and a granular route 10.0.1.1/24 are configured. On Router 4, a coarse route 10.0.1.0/16 and a granular route 10.0.1.2/24 are configured. These edge routers(Router 3 and Router 4) can need only also deploy strict uRPF to achieve the desired effect. For example, if the packet with source address 10.0.1.2 are coming from interface '#' of Router 3, although it doesn't match the granular FIB entry of 10.0.1.1/24, it match the coarse route 10.0.1.0/16, then the incoming traffic will not be blocked by Router 3. The situation is same for the traffic with source address of 10.0.1.1 that arrives on Router 4.

Deploy the intra-domain SAV mechanism on edge routers and AS border router can solve the intra-domain SAV problem. But in some spine-leaf scenario, there is more efficient deployment point to achieve the same goal. For example, in Figure 1, Router 2 is the spine router, with its three leaf routers(Router 3、Router 4、Router 5). Instead of deploy the intra-domain SAV mechanism on these leaf routers, the operator can select deploy it only on the spine Router 2. Once the Router 2 deploys the strict uRPF, it can safely block the spoofed packet from the host or customer network. In summary, SAV procedures in internal router, host-facing, customer-facing are all same. The procedures in AS border router can easily cover the prefixes from host network, customer network and internal links. Then the intra-domain SAV BM-SPF based solution can easily cover all of the scenarios that are described in .

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

None