Internet-Draft Intra-domain SAVNET Architecture March 2023
Li, et al. Expires 13 September 2023 [Page]
Network Working Group
Intended Status:
Standards Track
D. Li
Tsinghua University
J. Wu
Tsinghua University
M. Huang
L. Chen
Zhongguancun Laboratory
N. Geng
L. Qin
Tsinghua University
F. Gao
Zhongguancun Laboratory

Intra-domain Source Address Validation (SAVNET) Architecture


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.

Requirements Language

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].

Status of This Memo

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

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.

Table of Contents

1. Introduction

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.

2. Terminology

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.

3. Design Goals

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.

4. Intra-domain SAVNET Architecture

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. |
Figure 1: The intra-domain SAVNET Architecture

4.1. SAV Information Base Manager

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., 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
Figure 2: An illustration of SAV information base

4.2. RPDP and RPDP Speaker

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.

5. Partial Deployment

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.

6. Security Considerations

The security considerations should be provided in the protocol extension documents.

7. Privacy Considerations

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.

8. IANA Considerations

This document has no IANA requirements.

9. References

9.1. Normative References

Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) Gap Analysis, Problem Statement, and Requirements", .
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

9.2. Informative References

Cisco, "Cable Source-Verify and IP Address Security", , <>.
Huang, M., Zhou, T., Geng, N., Li, D., Chen, L., and J. Wu, "Source Address Validation Table Abstraction and Application", .
Cisco, "Configuring DHCP Features and IP Source Guard", , <>.
Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, "A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience", RFC 5210, DOI 10.17487/RFC5210, , <>.
Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, , <>.
Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, , <>.

Authors' Addresses

Dan Li
Tsinghua University
Jianping Wu
Tsinghua University
Mingqing Huang
Li Chen
Zhongguancun Laboratory
Nan Geng
Lancheng Qin
Tsinghua University
Fang Gao
Zhongguancun Laboratory