Source Address Validation enhanced by Network Controller

Introduction Many newly proposed Source Address Validation (SAV) mechanisms such as IGP-based and BGP-based SAVNET solutions take a distributed manner to generate SAV rules. Distributed SAVNET solutions leverage protocol message exchanges among SAVNET routers to acquire source prefix information pertaining to other subnets within intra-domain networks or inter-domain networks, utilizing Source Prefix Announcement (SPA) and Source Prefix Path Detection (SPD) technologies with BGP/IGP protocols extensions. Nonetheless, under circumstances characterized by device heterogeneity, partial upgrades, asymmetric routing, and peculiar address, these solutions grapple with diminished accuracy in Source Address Validation (SAV). Furthermore，there are necessities for enhancement in areas such as automated configuration, threat analysis, traceability, and visualization. In this document, on the basis of distributed intra-domain and inter-domain SAVNET architecture, we propose a controller-based and centralized SAVNET enhancement solution. The distributed SAVNET soulations rely on local routing information and SAV-specific information. In this solution, the controller can generate and deliver SAV rules based on the global information, and can also obtain ROA and other external information to generate inter-domain SAV rules, so as to achieve accurate source address verification (SAV) in both intra-domain and inter-domain in a combination of centralized and distributed ways. In this solution, SAVNET-enabled routers and SAVNET-unenabled routers can cooperate via the network controller. More accurate source address verification rules can be generated based on more comprehensive information in the scenario of partial/incremental deployment of SAVNET. Concurrently, the SAVNET can support accurate verification, automated configuration, threat analysis, traceability and visualization..

Terminology

SAV: Source Address Validation
AS: Autonomous System
SAV-Specific Information: Information specialized for SAV rule generation, exchanged between routers or from the network controller.
SAV-related Information: The information used by a router to make SAV decisions. For intra-domain SAV, SAV-related information includes both local routing information and SAV-specific information.
SAV-specific Information Communication Mechanism: The mechanism for exchanging SAV-specific information between routers. It can be either a new protocol or an extension to an existing protocol.
SAV Information Base: A table or data structure in a router that stores specific SAV information and local routing information.
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 or from network controller.
SAVNET Router: An intra-domain router which runs intra-domain SAVNET.
SAVNET Agent: The agent in a SAVNET router that is responsible for communicating SAV-specific information, processing SAV-related information, and generating SAV rules.
AS Edge Router: An intra-domain router of an AS which is connected to client subnets.
AS Border Router: An intra-domain router of an AS which is connected to other ASes.
Improper Block: The validation results that the packets with legitimate source addresses are blocked improperly due to inaccurate SAV rules.
Improper Permit: The validation results that the packets with spoofed source addresses are permitted improperly due to inaccurate SAV rules.

Scenarios and Requirements for Centralized SAVNET This section introduces the scenarios and requirements of centralized SAVNET, including incremental/partial deployment scenario, obtain information from external systems, automated configuration, analysis and traceability requirements,etc..

Challenges and Limitations of Distributed SAVNET in Incremental/partial deployment The current distributed solutions exchange SAV-specific information between SAVNET routers depends on devices upgrade. Devices utilize the source prefix advertisement (SPA) information to notify other routers about their subnet and prefix information. Unique subnet ID for each subnet should be planned by network manager, and additional identification information such as subnet ID and access mode on the corresponding port of the device should be configured manually, so as to generate more accurate SAV rules. However, devices are upgraded gradually due to various limitations such as device performance、version and vendor. As a result, there are some routers support SAVNET and others do not in an AS. Routers with distributed solution could not generate accurate SAV rules in incremental/partial deployment scenario. Refer to and .Though the SAVNET router can obtain routing information from the local RIB/FIB and generate SAV rules for certain prefixes, in the absence of SAV-specific information, the SAV generated based on the local RIB/FIB has the risk of the improper block and improper permit in special scenarios such as asymmetric routing scenario. Similarly, as not all devices support SAVNET, so it is difficult for SPD source prefix detection packets to be propagated hop-by-hop. Figure 1 illustrates the asymmetric routing in a multi-homing subnet scenario which has been raised in [I-D.ietf-savnet-intra-domain-problem-statement]. Subnet 1 has a prefix of 10.0.0.0/15 and is connected to two edge routers, Router 1 and Router 2. Due to the load balancing policy in the inbound direction of subnet 1, R1 can only learn subnet prefix 10.1.0.0/16 from subnet 1, while R2 can only learn subfix 10.0.0.0/16 from subnet 1. After that, R1 learns another subnet prefix through the intra-domain routing protocol, and so does R2. The FIB of R1 and R2 are shown in Figure 1. R1 is a SAVNET router and R2 is a non-SAVNET router, and R1 and R2 communicate with each other through R3, regardless of whether R3 is a SAVNET router or not, the SPA message cannot be delivered and R2 cannot generate its own SAV-specific information or recognize the SAV-specific information transmitted from R1. Therefore, R1 can only collect part of the prefix information of the subnet to generate SAV rules, and R2 uses the FIB for SAV, then improper block will occure in both R1 and R2 due to incomplete information.

Asymmetric multi-homing scenario in incremental deployment of intra-domain Incremental/partial deployment for inter-domain include: (1) devices partially support SAVNET in an AS; (2) some ASs support SAVNET, while others do not. Figure 2 shows that ASBR1/2/3 are SAVNET routers while ASBR4 is a non-SAVNET router, ASBR4 cannot generate accurate source address verification rules without obtaining SAV-specific information from other AS and other routers in its AS.

Partial deployment of Savnet for inter-domain As a result, there is a problem of low accuracy in partial/incremental deployment scenarios. In addition, how to improve the protection effect and enhance the incentive is also one of the enhanced capabilities.

Obtain information from external systems ASBR in each AS collects the SAV-specific information in its AS domain and synchronizes the SAV-specific information with the ASBR of the adjacent AS domain, and also obtains the RPKI ROA and ASPA information, as well as general information such as RIB, FIB, IRR, etc..Based on the above information sources, each AS generates a relatively complete source address verification table. So each AS needs to establish an information exchange channel and mechanism with the RPKI ROA to ensure network security, but routers shouldn’t directly interact with the RPKI ROA and other external systems, and a controller is appropriate to obtain information such as RPKI ROA and ASPA.

Automated configuration Due to the existence of special addresses in the network, such as anycast addresses, the existing distributed SAVNET solutions need to manually identify special addresses and adopt corresponding policies, which brings high management overhead. For example, in Figure 3, P1~P4 are common prefixes, P5 is an anycast prefix with multiple legitimate origins including customer network 1, customer network 3 and external Internet. SAVNET with whitelist to be generated on interfaces a, b, and c, and SAVNET blacklist to can be generated on interfaces d and e. If subnet 1 could not recognize P5 as the an anycast prefix, the blacklist of interfaces d and e includes the prefix P5, causing legitimate packets with P5 as the source to be filtered by mistake when they enter from interfaces d and e. Therefore, in order not to include an anycast prefix into a blacklist, it needs to use a special flag to indicate the anycast prefix when subnet 1 advertises the prefix P5 through the SPA. Prefix type can be obtained and configured on the edge router through the controller if centralized management is possible,.

Impact of anycast prefix In addition, network providers assign access devices, access ports, and public IP addresses to users who connected to their networks, so that the address allocation system in the carrier's network contains information about the customer's network. Source address verification technology can be combined with address allocation systems to automate configuration and achieve traceability based on source prefix. Centralized network controller can switch the authentication mode of all SAVNET routers flexibly through the delivery configuration.

Analysis and traceability requirements Current scheme provides flexible verification modes such as dropping, rate limiting, or allowness for the forged packets in the latest draft sav_table . It will play a great role if the controller can collect more source address forgery information from the router, analyze and trace the source in a centralized manner, visualize the source and target of the attack and threat tracing. Besides, with the continuous expansion of the network scale and the increasing allocation of IP addresses, IP address conflicts include IP address conflicts and IP prefix conflicts will appear, which affects the normal network operation. The controller can find whether the prefixes are reused by checking the prefixes and their binding subnet ID.

Centralized SAVNET capability enhancement solution Figure 4 shows the intra-domain and inter-domain network of the operator network. Customer networks generally access the Internet through the metro network in every province which is an AS and connected to the border router of the operator's backbone network. Border router of operator's backbone network is also interconnected with other operator networks. Since not all customer networks deploy source address verification, it is need for operator network to deploy SAV technology on the border gateway devices of metro networks to perform prefix-level source address verification. It can also deploy the inter-domain SAV to protect the prefixes of Adjacent ASes.There a network controller in an AS domain that manages the access, aggregation, and core devices in the network and knows the network topology of the AS.

Typical carrier network architecture Every AS has a network controller that manages the access, aggregation and core devices in the network and knows the network topology of the whole AS.

Centralized SAVNET solution

Intra-domain SAVNET enhancement This section describes the intra-Domain SAV Enhancement based on Controller. TBD. Figure 5 shows the architecture of the SAV capability enhancement system, which consists of the infrastructure layer, management and control layer, application layer. The infrastructure layer is divided into a data plane and a control plane. Management and control layer refers to a centralized network controller. Application layer at the upper layer can obtain external SAV control policies and display SAV threat information.

In-domain SAVNET capability enhancement architecture based on network controller The scheme not only has the ability to generate source address verification rules through the source prefix information advertised among devices, but also has the ability to receive the SAV rules/policies generated by the network controller. The scheme achives: Collaboration of control plane : Coordination between the control plane of infrastructure layer and the centralized network controller. Collaboration of devices: Collaboration between devices that support SAV and devices that do not support SAV.

Inter-domain SAVNET Capability Enhancement Program Architecture This section describes the intra-Domain SAV Enhancement based on Controller as showed in figure 6. The controller can collect all SAV-Specific information in the AS, and deliver it to the ASBR device for sending to other adjacent ASs. In addition, controller can obtain more comprehensive information to generate more accurate SAV rules by interacting with external systems. To ensure accurate verification, we recommend that generate SAV rule based on a variety of network information,in, RIB, FIB, IRR, RPKI ROA objects, ASPA objects, network topology, SAV-specific messages, BGP messages and so on..

Inter-domain SAVNET capability enhancement architecture based on network controllers

Scheme design This section describes the key technologies, centralized SAV rule generation and use case.

Key technologies This section will describe the key technologies of centralized SAV, including the key module of devices and controller, and the interfaces between devices and controller. TBD.

Centralized SAV rule generation This section will describe the centralized SAV rules generation method and three steps. TBD.

Use Case Several use cases will illustrate that centralized intra-domain SAVNET can achieve more accurate and comprehensive SAV. Case 1: More accurate intra-domain edge protection TBD. Case 2: More accurate intra-domain border protection TBD. Case 3: More accurate Inter-domain protection TBD. Case 4: Accurate protection with anycast address TBD.

Security Considerations TBD.

IANA Considerations TBD.

Acknowledgments TBD.