Network Working Group K. Xu Internet-Draft J. Wu Intended status: Informational X. Wang Expires: 19 March 2023 Tsinghua University Y. Guo Zhongguancun Laboratory G. Dong China Telecom 15 September 2022 Enhance with RPKI and IPsec for the Source Address Validation draft-xu-erisav-00 Abstract 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 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. Xu, et al. Expires 19 March 2023 [Page 1] Internet-Draft ERISAV September 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 3. Desgin Objectives . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Interactive Process . . . . . . . . . . . . . . . . . . . . . 5 6. Related Extensions . . . . . . . . . . . . . . . . . . . . . 6 7. Security Consideration . . . . . . . . . . . . . . . . . . . 6 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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. Xu, et al. Expires 19 March 2023 [Page 2] Internet-Draft ERISAV September 2022 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: Xu, et al. Expires 19 March 2023 [Page 3] Internet-Draft ERISAV September 2022 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. Xu, et al. Expires 19 March 2023 [Page 4] Internet-Draft ERISAV September 2022 +--------------+ | 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 Xu, et al. Expires 19 March 2023 [Page 5] Internet-Draft ERISAV September 2022 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. 9. Normative References Xu, et al. Expires 19 March 2023 [Page 6] Internet-Draft ERISAV September 2022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", RFC 5635, DOI 10.17487/RFC5635, August 2009, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Ke Xu Tsinghua University Beijing China Email: xuke@tsinghua.edu.cn Jianping Wu Tsinghua University Beijing China Email: jianping@cernet.edu.cn Xiaoliang Wang Tsinghua University Beijing China Email: wangxiaoliang0623@foxmail.com Xu, et al. Expires 19 March 2023 [Page 7] Internet-Draft ERISAV September 2022 Yangfei Guo Zhongguancun Laboratory Beijing China Email: guoyangfei@zgclab.edu.cn Guozhen Dong China Telecom Beijing China Email: donggz@chinatelecom.cn Xu, et al. Expires 19 March 2023 [Page 8]