Enhance with RPKI and IPsec for the Source Address Validation

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

Copyright Notice

Copyright (c) 2022 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.¶

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

AH:

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

ASBR:

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

CA:

Certification authority.¶

EE:

End entity.¶

IKE:

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

NIR:

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

RIR:

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

RPKI:

Resource Public Key Infrastructure, which is a special PKI.¶

Tag:

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        |              |
|              |     ++++++++++++++++++++     |              |
+--------------+                              +--------------+

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

6. Related Extensions

As discussed before, there are almost negligible changes to current protocols. ERISAV just needs one new IPsec SA for the requirements of source address validation. It just requires requesting a new attribute for storing and transporting the tag information. The tag will be used as the key during the authentication process. The process of AH also needs some changes. It takes a few unchangeable fields as input to generate a signature replacing the original tag for security consideration.¶

7. Security Consideration

TBD.¶

8. IANA Consideration

TBD.¶

Authors' Addresses