Network Working Group K. Xu Internet-Draft J. Wu Intended status: Experimental Tsinghua University Expires: 19 March 2023 Y. Guo Zhongguancun Laboratory H. (Henry). Wang The University of Minnesota at Duluth 15 September 2022 An RPKI and IPsec-based End-to-End Approach for Source Address Validation draft-xu-risav-00 Abstract Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes no place with inspection of the source address. Therefore, malicious attacks or behaviors have been launched with spoofed source addresses. This document defines using RPKI (Resource Public Key Infrastructure) and IPsec (IP Security) to reinforce the security of source addresses in the inter- domain layer. 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 RISAV 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. ASN-Prefix relationship announcement . . . . . . . . . . 5 4.2. Tag management . . . . . . . . . . . . . . . . . . . . . 6 4.3. ASN-Tag relationship announcement . . . . . . . . . . . . 6 5. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Incremental deployment . . . . . . . . . . . . . . . . . 8 6. Security Consideration . . . . . . . . . . . . . . . . . . . 8 6.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Key Guessing and Cracking . . . . . . . . . . . . . . . . 9 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction IP spoofing has been a long-recognized threat to Internet security for decades. Source Address Validation (SAV) provides the integrity of the source address to IP packet. Source Address Validation Architecture (SAVA) has been proposed at [RFC5210]. Inter-domain source address validation 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 implementations with the scalability of large-scale deployments. uRPF [RFC5635], for example, routing-based schemes 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. This document provides an RPKI and IPsec-based inter-domain end-to- end approach to source address validation (RISAV). RISAV is a cryptography-based SAV to guarantee consistent security benefits, which combines RPKI (Resource Public Key Infrastructure), IKE (Internet Key Exchange), and IPsec AH (IPsec Authentication Header). Xu, et al. Expires 19 March 2023 [Page 2] Internet-Draft RISAV September 2022 RPKI provides the reflection relationship between AS numbers (ASN) and IP prefixes. IKE negotiates between two ASes with the Security Association (SA) which contains the algorithm, secret key generating material, and IPsec packet type, and so forth. IPsec AH is the authentication header that is used to provide authenticity of the whole packet, including the source address, in IPsec. 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. ACS: AS Control Server, which is responsible for delivering tags and other information to ASBR. ASBR: AS border router, which is at the boundary of an AS that runs BGP. Tag: The bit-string that authenticates identification of source address of a packet. Signature: The final bit-string is placed at the AH's field, which is different for each packet. 3. Overview RISAV is a cryptography-based end-to-end inter-domain source address validation method that guarantees security benefits at partial deployment. RISAV uses RPKI to obtain the binding relationship between AS numbers and IP prefixes. After that, it uses IKE to negotiate the IKE SA and IPsec SA for generating the tag presenting the integrity of the IP source address. And the IPsec Authentication Header (AH) would be used to carry the tag in communication. 1. RPKI process. The five Reginal Internet Registry (RIR) would be authorized by IANA. They use their root certificate to sign the Certificate Authority (CA) certificate of the Local Internet Registry (LIR). And after that LIR would use a CA certificate to authorize indirectly the Internet Service Provider (ISP) or directly the Autonomous System (AS). When they obtain their own CA certificate, the AS would sign an End Entity (EE) certificate with a Route Origin Authorisation (ROA) which is a cryptographically signed object that states which AS are Xu, et al. Expires 19 March 2023 [Page 3] Internet-Draft RISAV September 2022 authorized to originate a certain prefix. Such the reflection of ASN relationship with IP prefixes would be broadcast to the network. 2. Sign ASBR EE certificate. This EE certificate is just like the BGPsec Router Certificate defined in [RFC8209]. The ASBR would need its own EE certificate for and only for generating and verifying the signature in the AH header directly or indirectly. 3. IKE process. Before IPsec establishing, the SA must be reached an agreement. There are two ways to negotiate the SA. One is mutual config all the parameters and the other one is using IKE for dynamic negotiating these parameters. Currently used is IKE version 2 (IKEv2, for short using IKE below). Typically, IKE would produce IKE SA in the IKE_SA_INIT exchange and IPsec SA in the IKE_AUTH exchange. This will be done in an ACS. 4. SA or tag delivery. When all negotiations are done, the IPsec is established. If the ACS is an ASBR actually, it would deliver SA to the other ASBR in this AS. Otherwise, it would deliver the tags generated by the state machine. This delivery will be processed in a secure channel just like using IPsec ESP. 5. IPsec AH communication. It uses IPsec AH for authentication of the IP source address. IPsec is offten used in tunnel mode as the IPsec VPN. Here, It expands the gateway to the AS border router (ASBR). When two ends x and y in AS X and Y respectively are communicating, the packet from x arriving at its ASBR RA would use the established IPsec channel for adding the representative tag. After the packet arrives at ASBR RB of AS Y, it would be inspected by comparing the consistency of the tag. The tag will be encapsulated in the ICV field in AH. A typical workflow of RESAVRI is shown in Figure 1. Xu, et al. Expires 19 March 2023 [Page 4] Internet-Draft RISAV September 2022 +--------------+ | IANA | +--------------+ |--------------------------+ V | +--------------+ | | RIR | | +--------------+ | / \-----------------+-1. signed CA V V | certificate +--------------+ +--------------+ | | LIR1 | | LIR2 | | +--------------+ +--------------+ | / \-+ V +------ 2. signed EE ceritficate -------+ V +--------------+ | | +--------------+ | | | -------------------------------- | | | | | | 3. IKE negotiation | | | | AS A | | -------------------------------- | | AS B | | | V V | | | ######## -------------------------------- ######## | | # ASBR # 4. SA Deliver # ASBR # | | ######## -------------------------------- ######## | | | | Prefix Y | | Prefix X | +++++++++++++++++++++++++++++++++ | Public Key B | | Public Key A | 5. data transmission | | | | using IPsec AH | | | | +++++++++++++++++++++++++++++++++ | | +--------------+ +--------------+ Figure 1: ERISAV workflow example. 4. Control Plane The functions of the control plane of RISAV include ASN-Prefix relationship announcement, Tag management, and ASN-Tag relationship announcement. 4.1. ASN-Prefix relationship announcement RISAV uses RPKI to manage the relationship between ASN and IP prefixes. So when one AS wants to deploy RISAV, it should implement RPKI first. When RPKI is deployed, the validated ROA cache SHOULD be sent to the ASBR for routing and forwarding packets. The ROA whose status is valid can be used with IPsec to prevent source address spoofing. That means only the prefix contained in valid ROA would valuably and correctly be protected. Xu, et al. Expires 19 March 2023 [Page 5] Internet-Draft RISAV September 2022 For more information about RPKI, one can refer to [RFC6480]. 4.2. Tag management Before introducing the ASN-Tag relationship announcement, it shall be described what is a tag and how it is generated. A tag is a variable bit-string that is generated at an entity in AS. This entity is AS Control Server (ACS). The tag is used with the authentication algorithm to generate the signature. That means the tag is the key to the authentication. When communicating, the tag would not be directly tagged to the IPsec AH of the packet, replacing it with a signature instead, which will be different with different packets. One AS SHOULD have at most two tags in effect in the same bound simultaneously for Key-Rover. It has two ways for an ACS to generate tags. One is using a state machine. The state machine runs and triggers the state transition when time is up. The tag is generated in the process of state transition as the side product. The two ACS in peer AS respectively before data transmission will maintain one state machine pair for each bound. The state machine runs simultaneously after the initial state, state transition algorithm, and state transition interval are negotiated, thus they generate the same tag at the same time. Time triggers state transition which means the ACS MUST synchronize the time to the same time base using like NTP defined in [RFC5905]. The other way to generate a tag is by applying the original SA. The IPsec channel is established when the IKE_AUTH process is finished. SA includes the specified AH, the authentication algorithm, the key used for authentication, etc. So two IKE entities have negotiated SA. All ASBR in one AS SHOULD use the same SA. When it chooses to use a logical ACS, one AS will elect one distinguished ASBR as the ACS. The distinguished ASBR acting as an ACS will represent the whole AS to communicate with peer AS's ACS. This election takes place prior to the IKE negotiation. An ASBR MUST be a BGP speaker before it is elected as the distinguished ASBR. This is an OPTIONAL operation to use this logical ACS. 4.3. ASN-Tag relationship announcement Corresponding to the tag generating, it also has two ways to announce the ASN-Tag binding relationship. The first is to deliver the generated tags and the second is to deliver the original SA. Xu, et al. Expires 19 March 2023 [Page 6] Internet-Draft RISAV September 2022 Thus, there must be a header format definition to transfer these tags and SA. In RISAV, it uses the header and payload formats defined in [RFC5996]. Meanwhile, there are some almost negligible changes to the formats. For the tag generation method, it MUST be to specify the initial state and initial state length of the state machine, the identifier of a state machine, state transition interval, length of generated Tag, and Tag. For the SA, they will transfer all these payloads in a secure channel between ACS and ASBRs, for instance, in ESP [RFC4303]. It is RECOMMENDED to transfer the tags rather than the SA for security and efficiency considerations. The initial state and its length can be specified at the Key Exchange Payload with nothing to be changed. The state machine identifier is the SPI value as the SPI value is uniquely in RISAV. The state transition interval and length of generated Tag should be negotiated by the pair ACS, which will need to allocate one SA attribute. The generated Tag will be sent from ACS to ASBR in a secure channel which MAY be, for example, ESP [RFC4303]. 5. Data Plane The functions of the data plane of RISAV include source address checking and tag processing. RISAV redesign the original AH format as shown in Figure 2. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | SIG Length | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature - SIG (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: RISAV AH Format. Prefix Length: The prefix length in valid ROA matched the IP source address. It presents the valid length of the IP source address prefix. SIG Length: The length of the variable signature. It is the octets in Signature. Xu, et al. Expires 19 March 2023 [Page 7] Internet-Draft RISAV September 2022 Signature: The result of the authentication algorithm with the key. All the ASBRs of the AS are REQUIRED to enable RISAV. And RISAV can OPTIONAL cooperate with intra-domain SAV and access-layer SAV, such as [RFC8704] or SAVI [RFC7039]. Only when intra-domain or access- layer SAV, if deployed, check passed can the packet process and forward correctly. It uses SPI for destination ASBR to locate the SA uniquely when processing the AH header in RISAV. As defined in [RFC4301], the Security Association Database (SAD) stores all the SAs. One data item in SAD includes an Authentication algorithm and corresponding key when AH is supported. The authentication algorithm could be HMAC-MD5, HMAC-SHA-1, or others. As authenticating the whole packet causes a heavy burden in the computation, RISAV defines that it only authenticates the IP source address, IP destination address, and the IP prefix length in ROA, SPI, and Sequence Number Field. The eventual signature is the hash of the 5-tuple before with the key/tag. When a packet arrives at the source ASBR, it will be checked with the destination address by this ASBR first. If the destination address is in the protection range of RISAV, the packet will be checked by the source address next. If the source address belongs to the AS in which the ASBR locates, the packet needs to be filled in the AH header. When a packet arrives at the destination ASBR, it will be checked the destination address and the source address orderly. If the destination belongs to the AS that the destination ASBR locates in and the source address seats in the RISAV protection area, the packet needs to be inspected with the AH header. 5.1. Incremental deployment So far, IPsec is often used as a VPN which is a technology for private network access through public networks. In the final analysis, IPsec is a highly cost-effective ratio mechanism. Original IPsec AH needs to authenticate the whole constant part of a packet so that it needs to spend amounts of time finding and processing unchangeable fields in the packet. However, RISAV only needs to find a few changeless fields to authenticate the packet decreasing the cost dramatically. 6. Security Consideration Xu, et al. Expires 19 March 2023 [Page 8] Internet-Draft RISAV September 2022 6.1. Compatibility When using RISAV, it WOULD be used at last when all other IPsec SA does not match. Such that, RISAV is comparable with the current IPsec Security Architecture. It SHOULD be guaranteed that the preference of RISAV is lower than other IPsec. So it may require the special SPI filled. 6.2. Key Guessing and Cracking For resisting label-based reply attacks, the eventual signature used in a packet is generated by the ASBR by hashing a few fields including the IP source address, IP destination address, and the IP prefix length in ROA, SPI, and Sequence Number Field. The attacker could guess the signature and crack that key using brute force. Nevertheless, it depends on the irreversibility of a hash function to prevent backstepping the key from the signature. Furthermore, to decrease such probability, the key used in generating the signature will be updated periodically. 7. IANA Consideration TBD. 8. Normative References [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, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC5210] 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, June 2008, . Xu, et al. Expires 19 March 2023 [Page 9] Internet-Draft RISAV September 2022 [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, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, DOI 10.17487/RFC5996, September 2010, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, . [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, . Authors' Addresses Ke Xu Tsinghua University Beijing China Email: xuke@tsinghua.edu.cn Xu, et al. Expires 19 March 2023 [Page 10] Internet-Draft RISAV September 2022 Jianping Wu Tsinghua University Beijing China Email: jianping@cernet.edu.cn Yangfei Guo Zhongguancun Laboratory Beijing China Email: guoyangfei@zgclab.edu.cn Haiyang (Henry) Wang The University of Minnesota at Duluth Minnesota, United States of America Email: haiyang@d.umn.edu Xu, et al. Expires 19 March 2023 [Page 11]