| Internet-Draft | Intra-domain SAVNET Architecture | March 2023 |
| Li, et al. | Expires 13 September 2023 | [Page] |
Intra-domain source address validation (SAV) plays an important role in defending against source address spoofing attacks in intra-domain networks. This document proposes an intra-domain source address validation (intra-domain SAVNET) architecture. Under the architecture, a router can automatically generate accurate SAV rules based on the SAV-related information from multiple information sources. This document does not specify protocols or protocol extensions, instead focusing on architectural components and their functionalities in an intra-domain SAVNET deployment.¶
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 RFC 8174 [RFC8174].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 September 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Source address validation (SAV) is important for mitigating source address spoofing and contributing to the Internet security. Source Address Validation Architecture (SAVA) [RFC5210] divides SAV into three checking levels, i.e., access-network SAV, intra-domain SAV, and inter-domain SAV. When an access network does not deploy SAV (such as SAVI [RFC7039][RFC7513], Cable Source Verify [cable-verify], and IP Source Guard [IPSG]), intra-domain SAV helps block spoofed packets as close to the source as possible.¶
There are some intra-domain SAV mechanisms available. However, existing intra-domain SAV mechanisms have the problems of inaccurate validation under asymmetric routing and high operational overhead in dynamic networks [draft-li-savnet-intra-domain-problem-statement].¶
To solve the problems above, this document proposes an intra-domain source address validation (intra-domain SAVNET) architecture. Under the architecture, routers can collaborate to discover real incoming interfaces of source prefixes adaptive to routing status, and the packets from all directions can be validated, which yields improvements on source address protection.¶
This document focuses on the high-level architecture designs and does not specify protocols or protocol extensions.¶
SAV Rule: The rule that indicates the valid incoming interfaces for a specific source prefix or that indicates the valid source prefixes for a specific interface.¶
SAV Table: The table or data structure that implements the SAV rules and is used for source address validation in the data plane.¶
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.¶
SIB: SAV information base that is for storing SAV-related information collected from different information sources.¶
SMP: SIB management protocol that represents any protocols for managing data in SIB.¶
RPDP: Real path discovering protocol, generally referring to the extension of existing routing protocols. The RPDP messages can explicitly or implicitly indicate the real incoming interfaces of some specified source prefixes.¶
The intra-domain SAVNET architecture is to enhance the intra-domain SAV and aims to achieve the following goals:¶
To achieve the goal of accurate validation, a router cannot generate SAV rules based on only local RIB/FIB because asymmetric routing exists, and purely relying on manual SAV rule configurations for guaranteeing accurate validation is not practical. The key challenge is how to make a router automatically discover real incoming interfaces of source prefixes of both external and internal packets.¶
Consider that the real incoming interfaces are determined by the forwarding rules of other routers in the network and cannot be entirely obtained locally. To address the key challenge, the intra-domain architecture includes a real path discovery protocol (RPDP) by extending existing routing protocols. Routers will propagate SAV-related data by sending RPDP messages adaptive to forwarding rules. These messages will be received by other routers. By combining the information from manual configurations, RIB/FIB, and protocol messages, accurate SAV rules for both external and internal packets can be generated.¶
Other design goals, such as low data plane overhead and easy implementation, are also important, but out of the scope of this document. They should be considered in specific protocols or protocol extensions of SAVNET.¶
The intra-domain SAVNET architecture is depicted from the perspective of a router. Figure 1 shows the architecture which consists of a few components. Among these components, the three of SAV Information Base (SIB) manager, RPDP speaker, and SAV table are specialized for SAV. The other components are existing ones but are required for SAV rule generation.¶
+------------------------------------------+
| Other Protocol Speakers |
+------------------------------------------+
/\
| Protocol Messages
+-----------------------------------------------------+
| Router | |
| \/ |
| +-------------------------------------------------+ |
| | Routing +------------------------+ | |
| | Protocol | RPDP Speaker | | |
| | Speaker +------------------------+ | |
| +-------------------------------------------------+ |
| |Routing /\Routing |SAV |
| |Information |Table |Information |
| |Dissemination | |Dissemination |
| |Messages | |Messages |
| \/ | \/ |
| +--------------------+ +----------------------+ |
| | | |+--------------------+| |
| | Routing | ||SAV Information Base|| |
| | Information |-->|+--------------------+| |
| | Base | | SAV Information Base | |
| | | | Manager | |
| +--------------------+ +----------------------+ |
| |SAV Rules |
| \/ |
| +-----------+ |
| | SAV Table | |
| +-----------+ |
+-----------------------------------------------------+
/\ Manual Configurations
|
+----------------------+
| CLI, YANG, SMP, etc. |
+----------------------+
SIB manager is the core component for SAV rule generation in the architecture. The component collects SAV-related information from multiple information sources, stores the information in SIB after consolidation, and outputs SAV rules based on the stored information. SAV rules indicate the valid incoming interfaces of source prefixes, which can be represented by <Prefix, Interface> pairs.¶
As described previously, collecting SAV-related information purely from local routing information and manual configuration is not enough or practical for learning accurate <Prefix, Interface> pairs. The protocol called RPDP in the document is designed as the third information source which provides accurate SAV information. Therefore, in the architecture, there are total of three information sources, which are listed as follows:¶
Although there are multiple information sources, one can choose some of them (e.g., RIB and RPDP speaker) for SAV instead of using all of them. When more than one information sources are used, data conflicts may exist. To address the issue, priorities can be set to the sources. For the items with data conflicts, the items from the source of higher priority will be preferred. For the items without data conflicts, a union of the items will be taken. For example, suppose that manual configuration has the highest priority. When the information from RIB indicates that Interface 1 is the valid incoming interface of source prefix P1, the operators can manually configure Interface 1 as the invalid interface of P1.¶
By consolidating the information from different sources, SAV manager will get the pairs of <Prefix, Interface> for all prefixes, which are stored in SAV information base. Figure 2 illustrates SAV information base. In the figure, each source prefix (including the default prefix, i.e., 0.0.0.0) has one or more valid incoming interfaces. The information sources for a pair of <Prefix, Interface> are also recorded. For example, P1 has two incoming interfaces of Interface 1 and Interface 3. Any other interfaces except Interface 1 and 3 will be considered invalid for P1. In the example, Interface 3 for P1 is discovered by only RPDP, which may appear in asymmetric routing cases.¶
An SAV table can be generated based on SAV information base. The SAV rules in the table will be installed into the data plane for validating the packets from all directions. The working modes and usage suggestions of SAV table can be found in [draft-huang-savnet-sav-table].¶
+----------------------------------------------------------+ | Source Prefix | Incoming Interface | Information Sources | +---------------+--------------------+---------------------+ | P1 | Interface 1 | b,c | | P1 | Interface 3 | b | | P2 | Interface 2 | b,c | | P3 | Interface 4 | a | | ... | ... | ... | | default | Interface 4 | a | +----------------------------------------------------------+ * a: Manual Config, b: RIB, c: RPDP
The RPDP is for automatically discovering real incoming interfaces of source prefixes. Particularly, the RPDP needs to extend existing routing protocols. The RPDP speaker is responsible for dealing with message interactions of the RPDP, and it naturally resides in the routing protocol speaker. The RPDP messages are carried by newly defined TLVs or messages of routing protocols.¶
Through the RPDP speaker, routers can send RPDP messages explicitly or implicitly indicating the real incoming interfaces of some specified source prefixes. A router receiving RPDP messages can resolve the SAV-related information for rule generation. Thus, there exists cooperation between routers. The followings are some kinds of SAV-related information that can be propagated by RPDP:¶
In the architecture, the RPDP speaker will get routing table from the RIB and policy routing information from the policy-based routing. These kinds of information will be useful for the RPDP speaker constructing and sending RPDP messages. After receiving RPDP messages, the speaker will disseminate SAV information to the SIB manager component.¶
The RPDP speaker should sense the adaptiveness of local source prefixes, forwarding rules, and SAV-related configurations (e.g., tags), etc. The adaptiveness should be notified to related routers through RPDP messages in time.¶
Since an intra-domain network mostly has one administration, it is possible to deploy SAVNET on all routers. Under full deployment, only edge routers need to enable SAV for validating external packets. However, partial deployment may still exist due to phased deployment or the limitations coming from multi-vendor supplement. In such cases, the SAV for internal packets are needed, which is supported by the intra-domain SAVNET architecture.¶
There are another kind of cases where the SAV for internal packets are necessary. Sometimes, the software of some edge routers has been upgraded for supporting SAVNET, but these routers are not able to do SAV due to the limited data plane capability. In such cases, these edges routers can still run SAVNET protocols to help other routers accurately validating external and internal packets.¶
The architecture does not require to be deployed in the whole network like an AS. It also works when an area of the network supports the architecture. A more detailed analysis on partial deployment may be provided in the future version of the document.¶
The security considerations should be provided in the protocol extension documents.¶
An intra-domain network is mostly operated by a single organization or company, so the architecture does not import privacy issues in most cases. There should be an analysis on privacy in the protocol extension documents.¶
This document has no IANA requirements.¶