Internet-Draft ERISAV September 2022
Xu, et al. Expires 19 March 2023 [Page]
Network Working Group
Intended Status:
K. Xu
Tsinghua University
J. Wu
Tsinghua University
X. Wang
Tsinghua University
Y. Guo
Zhongguancun Laboratory
G. Dong
China Telecom

Enhance with RPKI and IPsec for the Source Address Validation


Packet forwarding on Internet typically takes no place with inspection of the source address. Thus malicious attacks or abnormal behavior have been launched with the spoofed source addresses. This document describes an inter-domain source address validation with RPKI (Resource Public Key Infrastructure) and IPsec (IP Security), including the motivation, tech framework, main interactive process, and optional extensions.

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 19 March 2023.

Table of Contents

1. Introduction

IP spoofing has been a long-recognized threat to Internet security for decades. Inter-domain source address validation (SAV) has long served as the primary defense mechanism due to its better cost-effectiveness. However, over years of effort, inter-domain source address validation deployment is still not optimistic. An important reason for this is the difficulty of balancing the clear security benefits of partial deployments with the scalability of large-scale deployments. uRPF [RFC5635], for example, is a routing-based scheme to filter spoofed traffic, which may result in a lack of security benefits due to the dynamic nature of routing or incomplete information caused by partial deployments.

RPKI architecture [RFC6480] represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers. IPsec security architecture is used to secure the IP packet in host-to-host, host-to-network, and network-to-network modes. This document defines using present technologies to reinforce the security of source address in the inter-domain layer.

This document describes an inter-domain source address validation with RPKI and IPsec, including the motivation, tech framework, main interactive process, and extensions.

2. Terms and Definitions

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.

Commonly used terms in this document are described below.


IPsec Authentication Header, which is used to provide connectionless integrity and data origin authentication for IP datagrams and to provide protection against replays.


AS border router, which is at the boundary of an AS.


Certification authority.


End entity.


Internet Key Exchange, which is used in IPsec to negotiate IKE SA and IPsec SA.


National Internet registry, which is a special case for RIR.


Regional Internet registry, which is a governing body that is responsible for the administration of Internet addresses in a specific geographic region.


Resource Public Key Infrastructure, which is a special PKI.


The authentic identification of the source address of a packet and placed at the AH's ICV field.

3. Desgin Objectives

Source Address Validation (SAV) aims at preventing the source address from being spoofed. It should work at the network layer and provide a veritable IP source address.

When a packet is sent to the network, for saving network bandwidth and computation resources, the router forwards the packet using the destination address and without any inspection of the source address. The packet may come from a forger or impostor of the source address so that the destination end becomes a latent victim.

The design goals of ERISAV includes follows:

  1. Extensible current protocols. With the bindings and extensions of the current protocols, it would extremely reduce the cost of updating software, firmware, and hardware. And more importantly, it would be compatible with the current network. In ERISAV, it chooses the RPKI, IKE, and IPsec AH.
  2. Flatten end-to-end mode. Flatten mode, following the end-to-end design principle, ensures that the undeployed router has no perception of this mechanism. And it can be processed and deployed incrementally.
  3. Cryptography-based lightweight labels. A cryptographic packet-by-packet signature could guarantee that the reverse computation is infeasible and when it is cracked, the label has been changed to another. And this packet signature could efficiently be verified and resist to label-based replay attacks.
  4. Inter-domain collaboration trustness. Build an inter-domain trust alliance and complete source address validation via inter-domain collaboration.

4. Overview

ERISAV is a cryptography-based end-to-end inter-domain source address validation method that guarantees security benefits at partial deployment. ERISAV combines three existing mechanisms. It uses the RPKI trust chain for the ASN-IP Prefix binding relationship, IKE for tag/key negotiation and delivery, and IPsec AH for carrying the identification of the source address in data transmission.

A typical workflow of ERISAV is shown in Figure 1.

                        |     IANA     |
                              V                    |
                       +--------------+            |
                       |      RIR     |            |
                       +--------------+            |
                      /                \-----------+- 1. signed CA
                     V                  V          |   certificate
             +--------+                +--------+  |
             |  LIR1  |                |  LIR2  |--+
             +--------+                +--------+
            /                                    \
           V                                      V
+--------------+                              +--------------+
|              |     --------------------     |              |
|              |      2. IKE negotiation      |              |
|              |       and SA delivery        |              |
|     AS X    ###### -------------------- ######    AS Y     |
|   Prefix Px #ASBR#                      #ASBR#  Prefix Py  |
|  Public Key ###### ++++++++++++++++++++ ###### Public Key  |
|              |     3. data transmission     |              |
|              |        using IPsec AH        |              |
|              |     ++++++++++++++++++++     |              |
+--------------+                              +--------------+
Figure 1: RISAV workflow example.

5. Interactive Process

ERISAV mainly contains 3 steps.

  1. IANA issues a Certification Authority (CA) certificate to each Regional Internet Registry (RIR). RIR uses its root CA to issue a CA certificate for LIR or NIR which will issue a CA certificate for one AS. The AS issues a new End Entity (EE) certificate to enable verification of signatures on RPKI signed objects. This builds the trust chain using RPKI to guarantee the Internet number resource including AS number and IP prefix are correctly announced. Moreover, the public key of AS will be seated at the CA certificate, which will be used for communication with each other following.
  2. IPsec IKE negotiates the tag tagged in the packet. IKE also negotiates the authentication algorithm, authentication key, and others specified by SA. These will be stored in the SAD and SPD described in [RFC4301]. IPsec AH [RFC4302] is the authentication header of the IPsec Security Architecture. It authenticates the whole packet for integrity. However, source address validation does not require such strong authentication. It just needs to protect the source address from being spoofed. So it needs a new authentication process. This new authentication process will only take a few changeless fields as input. And the original tag will be seen as the authentication key. The result of this process will produce a new label called the packet signature that will be filled in the packet properly. And this label or the SA MUST send to all the ASBR for communication.
  3. Data transmission uses the IPsec AH header extension to the packet. IPsec AH carries the tag in its field. The tag represents the authenticity of the source address. When the source ASBR forwards a packet originating from the ASBR's located AS, the ASBR will check the destination of the packet. If it is forwarded to the ERISAV protection area, the ASBR will add the IPsec AH header extension with the related tag filled. If the destination ASBR receives a packet coming from the ERISAV protection area, the ASBR will compare the tag with its local tag. If they are matched, the source address of this packet will be seemd as not tampered. Otherwise, the packet will be discarded because the source address is a spoofing address.

7. Security Consideration


8. IANA Consideration


9. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, , <>.
Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, , <>.
Kumari, W. and D. McPherson, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", RFC 5635, DOI 10.17487/RFC5635, , <>.
Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

Authors' Addresses

Ke Xu
Tsinghua University
Jianping Wu
Tsinghua University
Xiaoliang Wang
Tsinghua University
Yangfei Guo
Zhongguancun Laboratory
Guozhen Dong
China Telecom