Intra-domain Source Address Validation (SAVNET) Architecture

1.1. 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.¶

3.1. Roles of SAVNET Routers

A SAVNET router can act as one or two roles in the intra-domain SAVNET architecture, namely, source entity to send its SAV-specific information to other SAVNET routers, or/and validation entity to receive SAV-specific information from other SAVNET routers.¶

+---------------------+               +-------------------------------------+
|    Source Entity    |               |          Validation Entity          |
|     (Router A)      |               |             (Router B)              |
|                     |               |                                     |
| +-----------------+ |               | +-----------------+     +---------+ |
| |   SAVNET Agent  | | Communication | |   SAVNET Agent  <-----+ RIB/FIB | |
| | +-------------+ | | Channel       | | +-------------+ |     +---------+ |
| | | Information +-----------------------> Information | | Local Routing   |
| | | Sender      | | |(SAV-specific  | | | Receiver    | | Information     |
| | +-------------+ | | Information ) | | +-------------+ |                 |
| +-----------------+ |               | +-----------------+                 |
|                     |               |                                     |
+---------------------+               +-------------------------------------+

3.2. SAV-related Information

3.3. SAV Rule Generation

Figure 2 shows the SAV rule generation process of the SAVNET router acting as validation entity. The SAV Information Manager of SAVNET Agent consolidates SAV-specific information from Information Receiver and local routing information from RIB/FIB into the SAV Information Base. Then, it sends the consolidated information to the SAV Rule Generator. The SAV Rule Generator will generate SAV rules (e.g., tuples like <prefix, interface set, validity state>) based on the consolidated information.¶

SAV Information Manager also provides the support of diagnosis. Operators can look up the information in SAV Information Base for monitoring or troubleshooting purpose.¶

+--------------------------------------------------------+
|                      SAVNET Agent                      |
|                                                        |
| SAV-specific information     Local routing information |
| from Information Receiver    from RIB/FIB              |
|                |                   |                   |
|                |                   |                   |
|            +---v-------------------v----+              |
|            | SAV Information Manager    |              |
|            | +------------------------+ |              |
|            | | SAV Information Base   | |              |
|            | +------------------------+ |              |
|            +----------------------------+              |
|                          |                             |
|                          | SAV-related information     |
|                          |                             |
|            +-------------v--------------+              |
|            | SAV Rule Generator         |              |
|            | +------------------------+ |              |
|            | |        SAV Rules       | |              |
|            | +------------------------+ |              |
|            +----------------------------+              |
+--------------------------------------------------------+

As mentioned in Section 3, validation entity can be either an edge router or a border router. According to the definition of intra-domain SAV proposed in [I-D.ietf-savnet-intra-domain-problem-statement], the edge router is responsible for validating packets received from the connected subnet and blocking those with source addresses of other subnets. While the border router is responsible for validating packets received from other ASes and blocking those with source addresses in internal source prefixes. Therefore, the working mechanisms of SAVNET Agents of edge router and border router are different, especially in the incremental/partial deployment scenario.¶

For an edge router acting as validation entity, it should first combine the local routing information and the SAV-specific information to obtain the complete source prefixes of each connected subnet. Then, it binds the source prefixes of the subnet to its interface connected to the subnet, and conduct SAV at this interface. Packets arriving at the interface will be considered invalid and should be blocked, if their source addresses do not belong to the subnet. In the incremental/partial deployment scenario where not all edge routers connected to the same subnets deploy SAV-specific information communication mechanism, an edge router acting as validation entity may not be able to identify complete source prefixes of the subnet. To avoid improper block problems in this case, validation entity is recommended to use less strict SAV rules. For example, it can choose to only block packets with non-global or non-routable source addresses by using its local routing information.¶

For a border router acting as validation entity, it should combine the local routing information and the SAV-specific information to collect all internal source prefixes, i.e., the source prefixes of all internal subnets. Then, it binds the internal source prefixes to the interfaces connected to other ASes and conducts SAV at these interfaces. Packets arriving at these interfaces will be considered invalid and should be blocked, if their source addresses belong to internal source prefixes. In the incremental/partial deployment scenario where not all edge routers in the intra-domain network deploy SAV-specific information communication mechanism, a border router acting as validation entity may not be able to get complete internal source prefixes. In this scenario, the border router can still block inbound packets with source addresses belonging to the learned internal source prefixes. In addition, if the border router also implements inter-domain SAVNET, its intra-domain SAVNET Agent SHOULD send the intra-domain SAV-specific information to its inter-domain SAVNET Agent, helping the inter-domain SAVNET Agent generate inter-domain SAV rules or inter-domain SAV-specific information.¶

4.1. Use Case 1: Validating Outbound Packets from a Multi-homed Subnet at Edge Routers

Figure 3 shows an asymmetric routing in the multi-homed subnet scenario. This scenario has been proposed in [I-D.ietf-savnet-intra-domain-problem-statement]. Subnet 1 has prefix 10.0.0.0/15 and is attached to two edge routers, i.e., Router 1 and Router 2. Due to the inbound load balance strategy of Subnet 1, Router 1 only learns the route to sub prefix 10.1.0.0/16 from Subnet 1, while Router 2 only learns the route to the other sub prefix 10.0.0.0/16 from Subnet 1. After that, Router 1 or Router 2 learns the route to the other sub prefix through the intra-domain routing protocol. The FIBs of Router 1 and Router 2 are shown in the figure. Assume Subnet 1 may send outbound packets with source addresses in sub prefix 10.0.0.0/16 to Router 1 for outbound load balance.¶

+-------------------------------------------------------------+
|                                                      AS     |
|                        +----------+                         |
|                        | Router 3 |                         |
| FIB on Router 1        +----------+  FIB on Router 2        |
| Dest         Next_hop   /\      \    Dest         Next_hop  |
| 10.1.0.0/16  Subnet 1   /        \   10.0.0.0/16  Subnet 1  |
| 10.0.0.0/16  Router 3  /         \/  10.1.0.0/16  Router 3  |
|                +----------+     +----------+                |
|                | Router 1 |     | Router 2 |                |
|                +-----+#+--+     +-+#+------+                |
|                        /\         /                         |
|   Outbound traffic with \        / Inbound traffic with     |
|   source IP addresses    \      /  destination IP addresses |
|   of 10.0.0.0/16          \    \/  of 10.0.0.0/16           |
|                           Subnet 1                          |
|                        (10.0.0.0/15 )                       |
|                                                             |
+-------------------------------------------------------------+

In this case, as described in [I-D.ietf-savnet-intra-domain-problem-statement], strict uRPF at Router 1 will improperly block legitimate packets with source addresses in prefix 10.0.0.0/16 from Subnet 1 at interface '#', because it only accepts packets with source addresses in prefix 10.1.0.0/16 from Router 1's interface '#' according to its local routing information.¶

If intra-domain SAVNET is implemented in the network, Router 2 can inform Router 1 that prefix 10.0.0.0/16 also belongs to Subnet 1 by sending SAV-specific information to Router 1. Then, by combining both local routing information and received SAV-specific information, Router 1 learns that Subnet 1 owns both prefix 10.1.0.0/16 and prefix 10.0.0.0/16. Therefore, Router 1 will accept packets with source addresses in prefix 10.1.0.0/16 and prefix 10.0.0.0/16 at interface '#', so improper block can be avoided.¶

4.2. Use Case 2: Validating Inbound Packets from Other ASes at Border Routers

Figure 4 shows the inbound SAV scenario which is proposed in [I-D.ietf-savnet-intra-domain-problem-statement]. Router 3 and Router 4 perform intra-domain SAV at interface '#' to block inbound packets with spoofed internal source addresses.¶

                + Packets with              + Packets with
                | spoofed P1/P2             | spoofed P1/P2
+--------------|---------------------------|----------+
|  AS          \/                          \/         |
|          +--+#+-----+               +---+#+----+    |
|          | Router 3 +-------------->| Router 4 |    |
|          +----------+               +----------+    |
|             /     \                      |          |
|            /       \                     |          |
|          \/         \/                   \/         |
|  +----------+     +----------+      +----------+    |
|  | Router 1 |     | Router 2 |      | Router 5 |    |
|  +----------+     +----------+      +----------+    |
|        \              /                   |         |
|         \            /                    |         |
|          \          /                     \/        |
|           Subnet 1(P1)               Subnet 2(P2)   |
+-----------------------------------------------------+

As described in [I-D.ietf-savnet-intra-domain-problem-statement], if Router 3 and Router 4 deploy ACL-based ingress filtering, the operator needs to manually generate and update ACL rules at Router 3 and Router 4 when internal source prefixes change. The operational overhead of manually maintaining and updating ACL rules will be extremely high, especially when there are multiple inbound validation points.¶

If intra-domain SAVNET is implemented in the network, Router 1, Router 2, and Router 5 will inform Router 3 and Router 4 of the source prefixes of Subnet 1 and Subnet 2 by sending SAV-specific information. The SAV-specific information communication will be triggered if topology or prefix changes. For example, if Subnet 2 has a new source prefix P3, Router 5 will inform Router 3 and Router 4 of the new source prefix of Subnet 2 immediately. After receiving SAV-specific information from other routers, Router 3 and Router 4 can identify internal source prefixes and detect their changes. In this way, Router 3 and Router 4 can automatically generate and update SAV rules at interface '#' to block inbound packets with internal source addresses.¶

5.1. Accurate Validation

In the asymmetric routing scenario shown in Figure 3, the edge router cannot identify the complete source prefixes of the connected subnet only using the router's local routing information. As a result, strict uRPF has improper block problems in the case of asymmetric routing, because it only uses local routing information to generate SAV rules.¶

Intra-domain SAVNET uses SAV-specific information and requires routers to exchange SAV-specific information among each other. The SAVNET router acting as validation entity can combine SAV-specific information with local routing information to generate accurate SAV rules. The use case in Figure 3 has shown that intra-domain SAVNET can achieve more accurate SAV validation compared with strict uRPF in asymmetric routing scenarios.¶

5.2. Automatic Update

In real intra-domain networks, the topology or prefixes of networks may change dynamically. The SAV mechanism MUST automatically update the SAV rules as the network changes. However, ACL-based SAV mechanism requires manual efforts to accommodate to network dynamics, resulting in high operational overhead.¶

Intra-domain SAVNET allows SAVNET routers to exchange the changes of SAV-specific information among each other automatically. After receiving updated SAV-specific information from source entity, SAVNET routers acting as validation entity can generate and update their SAV rules accordingly. The use case in Section 4.2 has shown that intra-domain SAVNET can achieve automatic update.¶

5.3. Incremental/Partial Deployment

Although an intra-domain network mostly has one administration, incremental/partial deployment may still exist due to phased deployment or multi-vendor supplement. In phased deployment scenarios, SAV-specific information of non-deploying routers is not available, so SAVNET routers acting as validation entity may not obtain some needed SAV-specific information.¶

As described in Section 3.3, the architecture can adapt to incremental/partial deployment. If complete SAV-specific information cannot be learned by only SAV-specific information, local routing information can be used to fill the gap. To mitigate the impact of phased deployment, it is also RECOMMENDED that edge routers connected to the same subnet can simultaneously adopt intra-domain SAVNET so that the complete source prefixes of the subnet can be obtained by other routers. For example, in Figure 3, Router 1 and Router 2 are recommended to be upgraded to SAVNET routers together so that the two routers can obtain complete source prefixes of Subnet 1 and generate accurate SAV rules.¶

In addition, SAVNET routers acting as validation entity are RECOMMENDED to support flexible validation modes and perform SAV filtering incrementally to smooth the transition from partial to full deployment.¶

• Validation entity is RECOMMENDED to support flexible validation modes such as interface-based prefix allowlist, interface-based prefix blocklist, and prefix-based interface allowlist [I-D.huang-savnet-sav-table]. The first two modes are interface-scale, and the last one is device-scale. Under incremental/partial deployment, validation entity SHOULD take on the proper validation mode according to the deploying of source entity. For example, if validation entity is able to get the complete set of legitimate source prefixes arriving at a given interface, interface-based prefix allowlist can be enabled at the given interface, and improper block will not exist.¶

• Validation entity is RECOMMENDED to performed SAV-invalid filtering incrementally. The router can first take conservative actions on the validated data packets. That is to say, the router will not directly discard packets with invalid results in the beginning of deployment. It can conduct sampling action for measurement analysis at first, and then conducts rate-limiting action or redirecting action for packets with invalid results. These conservative actions will not result in serious consequences if some legitimate packets are mistakenly considered invalid, while still providing protection for the network. Finally, filtering action is enabled only after confirming that there are no improper block problems.¶

5.4. Convergence

When the SAV-specific information or local routing information changes, the SAVNET Agent MUST be able to detect the changes in time and update SAV rules with the latest information. Otherwise, outdated SAV rules may cause legitimate packets to be blocked or spoofed packets to be accepted.¶

Intra-domain SAVNET requires routers to update SAV-specific information and SAV rules in a timely manner. Since SAV-specific information is originated from source entity, it requires that the source entity MUST timely send the updated SAV-specific information to validation entity. Consider that both routing information and SAV-specific information of a subnet are originated and advertised to other routers in the network by the edge router connected to the subnet, SAV-specific information SHOULD have a similar propagation speed as routing information. Therefore, the converging speed of intra-domain SAVNET is also similar as routing protocol.¶

5.5. Security

Typically, routers in an intra-domain network can trust each other because they would not compromise intra-domain control-plane architectures and protocols.¶

However, in some unlikely cases, some routers may do harm to other routers within the same domain. Operators SHOULD be aware of potential threats involved in deploying the architecture. Some potential threats and solutions are as follows:¶

• Entity impersonation.¶

  • Potential solution: Mutual authentication SHOULD be conducted before session establishment between two entities.¶

  • Gaps: Impersonation may still exist due to credential theft, implementation flaws, or entity being compromised. Some other security mechanisms can be taken to make such kind of impersonation difficult. Besides, the entities SHOULD be monitored so that misbehaved entities can be detected.¶

• Message blocking.¶

  • Potential solution: Acknowledgement mechanisms MUST be provided in the session between a sender and a receiver, so that message losses can be detected.¶

  • Gaps: Message blocking may be a result of DoS/DDoS attack, man-in-the-middle (MITM) attack, or congestion induced by traffic burst. Acknowledgement mechanisms can detect message losses but cannot avoid message losses. MITM attacks cannot be effectively detected by acknowledgement mechanisms.¶

• Message alteration.¶

  • Potential solution: An authentication field can be carried by each message so as to ensure message integrity.¶

  • Gaps: More overhead of control plane and data plane will be induced.¶

• Message replay.¶

  • Potential solution: Authentication value can be computed by adding a sequence number or timestamp as input.¶

  • Gaps: More overhead of control plane and data plane will be induced.¶

To meet the security requirement, the above security threats SHOULD be considered when designing the new intra-domain SAV mechanism.¶