Internet-Draft SAV Security March 2023
Guo, et al. Expires 10 September 2023 [Page]
Network Working Group
Intended Status:
X. Guo
China Telecom
D. Chen
China Telecom
Z. Xiong
China Telecom
J. Chen
China Telecom
X. Liu
China Telecom

Source Address Validation enhances its security using blockchain


The new Source Address Validation(SAV) mechanism must not introduce additional security vulnerabilities or risks, and the SAV mechanism should ensure the integrity and trusted origin of the protocol packets that deliver the required SAV information. This document explores the use of blockchain technology to enhance the security of the SAV mechanism itself without modifying existing protocols to ensure the accuracy of the generated SAV rules.

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 10 September 2023.

Table of Contents

1. Introduction

SAV rules are generated based on routing information (FIB/RIB) or non-routing information. If the routing information is poisoned by an attacker, then there will be no way to verify the authenticity of the routing information and the generated SAV rules will be incorrect. Many legitimate packets may be improperly discarded or illegal packets with spoofed source addresses may be improperly allowed. Overall, SAVNET faces similar security threats to BGP, and if the SAV mechanism or protocol requires information exchange, consideration should be given to avoiding routing information tampering or injection.

2. Terminology

SAV: Source Address Validation, i.e., validating the authenticity of a packet's source IP address.

SAV rule: The filtering rule generated by inter-domain SAV mechanisms that determines valid incoming interfaces for a specific source prefix.

RPKI: Resource Public Key Infrastructure,an opt-in service that provides security for Internet routing.

Improper block: Cases when packets with legitimate source addresses are improperly blocked.

Improper permit: Cases when packets with spoofed source addresses are improperly permitted.

3. Security Threats Analysis

The main security threats to SAV come from the following areas.

3.1. RPKI

The basic idea of RPKI is to construct a PKI (public key infrastructure) to accomplish the authentication of ownership and usage of IP address prefixes and ASNs. It helps routers verify the authenticity of BGP messages by issuing and certifying digital certificates and digital signatures, thus enhancing the security of the BGP protocol and avoiding Internet routing hijacking. However, RPKI cannot resist malicious acts initiated by CAs for the benefit of countries and organizations, and the tree structure of RPKI has the defect of single point of failure, and the whole network may be paralyzed after the attack of high-level CAs, so RPKI has the problem of being centralized and tamperable. In addition, RPKI also has a limited scale of global deployment due to its complex protocol mechanism and high processing overhead.

3.2. AS Prefix Advertisements

The existing routing protocols cannot guarantee the integrity of AS prefix advertisements and cannot authenticate whether the AS advertisement IP prefix authorization is legitimate. This lack of authenticated unconditional trust can be used by malicious nodes to forge and advertise false or non-compliant AS advertisement information through replay attacks or message injection attacks, resulting in network prefix information, network topology information, AS path information and other key information being hijacked, impersonated, stolen, and tampered with by attackers, which in turn leads to the delivery and proliferation of false routing information, causing security events such as traffic eavesdropping and traffic black holes.

3.3. Malicious Router

After gaining control of the legitimate router through the attack, the attacker disguises the malicious router as a peer node of another router to establish a session with that router, propagating false advertisement messages or tampering with legitimate advertisement messages, which will not only destroy the SAV function but also affect the entire routing domain.

4. Solution

As a distributed ledger system of the new generation of Internet, blockchain can record, encrypt and authenticate the whole life cycle transactions of data assets on the Internet in a distributed way. Its security is "endorsed" by the cryptography algorithm used by blockchain technology. After verification, each transaction interaction process can be permanently stored in the distributed database (block). Once verified, it will be shared, anonymous and tamper-proof, and easy to query.

Blockchain technology, due to its natural attributes of decentralization, tamper-proof and traceability, is supported by distributed node authentication and consensus mechanisms, allowing any two nodes in a distributed network to reach an unmediated trust. Another advantage of applying blockchain to SAV is that it can add additional security without changing the BGP protocol, and by using blockchain SAV can be protected in several ways.

4.1. Replace RPKI

The decentralized, tamper-proof and traceability features of blockchain enable it to solve the centralized and tamper-proof problems of RPKI. Through the two functions of resource transaction record and resource retrieval of blockchain's smart contract technology, the IP address and ASN registration and allocation information are recorded, and the tracking of their usage is supported, so as to realize the authorization authentication of IP address and ASN network resources, prevent the security threat of prefix hijacking and avoid the repeated allocation of resources.

4.2. AS Prefix Advertisement Information Authentication

The blockchain smart contract technology is used to record the process of IP address authorization. When the AS prefix advertisement is required, the prefix advertisement of the source AS can be stored on the blockchain as transaction information. After receiving the source AS advertisement information, the destination AS determines the integrity of the received AS advertisement information through the transaction information saved on the chain. In this way, the destination AS can verify the validity of the AS advertisement information, and then determine whether there is any unauthorized change attempt, and whether the resource is repeatedly allocated, so as to avoid tampering with the AS advertisement information and prefix hijacking.

4.3. Malicious Router Discovery

Store the routing topology relationship in the blockchain. When the AS discovers the malicious advertisement information of the AS through the blockchain verification, the network location of the malicious router can be located in a timely manner by combining the advertisement information source and the routing topology relationship stored in the blockchain to avoid the malicious router causing greater harm to the network. Routing topology is stored in the blockchain through consensus mechanism. Any modification and update of topology data in the blockchain requires the consent of most nodes in the blockchain network to avoid malicious modification of routing topology by a few malicious routers.

5. Security Considerations

There could be new blockchain related attacks that SAV would experience if blockchain were to be added into SAV's policy system. We will explore some of those here or in a new draft.

6. Acknowledgments


7. Normative References

Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, , <>.
Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, , <>.
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, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, , <>.

Authors' Addresses

Xuesong Guo
China Telecom
Dabei Chen
China Telecom
Zihan Xiong
China Telecom
Jun Chen
China Telecom
Xiaoping Liu
China Telecom