idnits 2.17.1 draft-qingyuan-transparencyrpki-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 4, 2019) is 1635 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC8630' is mentioned on line 138, but not defined == Unused Reference: 'RFC2629' is defined on line 217, but no explicit reference was found in the text == Unused Reference: 'RFC8360' is defined on line 260, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interdomain Routing Working Group Y. Liu 3 Internet-Draft 4 Intended status: Experimental S. Zhang 5 Expires: May 7, 2020 6 Q. Li 8 S. Peng 9 November 4, 2019 11 Requirement for the transparency of RPKI 12 draft-qingyuan-transparencyrpki-00 14 Abstract 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 7, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Transparency Requirements . . . . . . . . . . . . . . . . . . 3 58 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 The certification authority (CA) or independent resource management 66 agency in the RPKI may adversely affect the associated Internet 67 Number Resource (INR) when performing authentication or actions for 68 authentication, such as RFC 8211 [RFC8211]. In Resource Public Key 69 Infrastructure (RPKI) [RFC6480], the operation is called "adverse 70 operation" if its consequence may reduce the amount of Internet 71 Number Resources (INRs) and contrary to the wishes of this INR's 72 owner. There are several forms of adverse operations on objects in 73 the RPKI repository, including Deletion, Suppression, Corruption, 74 Modification, Revocation, and Injection. The adverse operation 75 caused by CA's error or repository operation errors or attacks may be 76 an attack on objects in the RPKI repository [RFC7132]. 78 According to the RPKI specification, even if the INR owner believes 79 that the operation is adverse, the operation will be performed 80 according to the established regulations. For example, RPKI 81 establishes a top-down authoritative architecture based on regional 82 Internet registry (RIRs), which allocates IP address space to the 83 lower level (the upper level allocates to the lower level and the 84 lower level reallocates to the lower level). The security benefits 85 from RPKI are implemented through this architecture. However, in the 86 architecture, CA or resource management agency can unilaterally 87 revoke any IP resources under its control, thus may result in an 88 authority that abuses power. 90 Therefore, it will cause serious security issues, once it is 91 maliciously operated by some authorities. Therefore, we propose to 92 establish a mechanism to increase the transparency of RPKI to curb 93 strong CA or resource management agency. 95 2. Transparency Requirements 97 2.1 the transparency requirements for CA or resource management 98 agencies in RPKI 100 In the current RPKI architecture, any adverse actions taken by a 101 malicious CA or resource management agency are difficult to detect by 102 others. Errors or attacks against CAs or management agency can cause 103 IP addresses to be deleted or invalidated, which may have a 104 significant impact on routing. The main reason for this type of 105 problem is determined by the current architecture of RPKI. The 106 current RPKI architecture has a centralized unilateral authorization, 107 that is, the CA or resource management agency is free to perform any 108 operations (issued, revoked, modified and updated) without any 109 authentication and interaction. At the same time, RPKI's layered 110 architecture gives CAs or resource management agency the ability to 111 unilaterally revoke (or remove) IP prefixes under their control. 112 This has led to concerns about the formation of powerful authorities 113 in RPKI, which have the power to unilaterally operate IP resources 114 and may abuse power. At present, it is difficult to distinguish 115 whether an adverse operation is caused by improper operation of a 116 resource management agency or a legitimate business operation. 118 This draft proposes to reduce the technical risk by improving the 119 operational transparency of RPKI. The current RPKI specification 120 places power entirely in the hands of CAs or resource management 121 agencies. In order to solve this problem, the draft proposes: to add 122 a two-way authorization operation for all operations on objects in 123 the RPKI repository, that is, the CA or the resource management 124 authority needs to obtain the authorization of the INR owner for the 125 Deletion, Suppression, Corruption, Modification, revocation, and 126 Injection operations on the resources owned by the INR holder. This 127 two-way authorization meets the wishes of both the CA or the resource 128 management agency and the INR owner and the agreement between them, 129 and it can restrain the excessive power of the CA or resource 130 management organization, which can operate the INR object arbitrarily 131 without the permission of the INR owner. It is recommended to modify 132 the operation mode of RPKI so that the operations on the INR objects 133 need to meet the wishes of both the operator and the INR owner. 135 2.2 Transparency requirement for Relying Party in RPKI 137 In RPKI, each RP chooses its own set of trust anchors (TAs), which 138 are specified in section 3 of [RFC8630]. Each RP maintains a local 139 cache of RPKI objects and is consistent with the repository. 140 Section 5 of [RFC6481] describes how to maintain a local cache. The 141 RP needs to verify whether the resource certificate conforms to the 142 configuration file described in Section 4 of [RFC6487]. Section 7.1 143 of [RFC6487] describes the process of verifying certificate resources 144 and syntax that each RP should follow, and Section 7.2 introduces the 145 process of RP performing certificate path verification. In order to 146 verify the ROA, the RP needs to perform all the checks specified in 147 [RFC6488], as well as additional specific verification steps to the 148 ROA. More details on ROA verification are in Section 4 of [RFC6482]. 150 To reduce the risk of RPKI, the RP should be able to detect when the 151 RPKI error caused the BGP route to be incorrectly classified as 152 "invalid". The RP can check if it has received all the objects in 153 the manifest, and if the manifest is valid. If the manifest is 154 invalid, the RP should issue an alert for missing information (as 155 indicated in Section 6.5 of [RFC6486]), and the RP decides to respond 156 to this alert at its discretion. 158 The event that the misconfigured or attacked CA or resource 159 management agency incorrectly adds or destroys the ROA is not 160 transparent. If the resource management agency ensures that its 161 manifest is consistent with the objects in the repository, the RP 162 will not issue an alert. The current RPKI specification does not 163 focus on alerts, but it is important. Although the alerts themselves 164 don't solve the problem, they do indicate that there is a problem and 165 can trigger a mitigation mechanism. 167 There is another important threat to transparency: mirror world 168 attack. In a mirror world attack, the resource management agency in 169 an adversarial RPKI provides a view of the RPKI for some RPs while a 170 different view for other RPs. The current RPKI has no mechanism to 171 prevent such attack. The current RPKI system relies entirely on RPs 172 to acquire, update, and verify all signature objects. Therefore, a 173 RP is very likely to obtain the wrong ROAs due to the wrong operation 174 or misbehavior of the issuer, so it cannot distinguish whether this 175 is an error or a normal operation. Therefore, the current 176 architecture of RPKI determines that it is difficult to defend 177 against malicious operations by CA or resource management agency and 178 more complex collusion attacks. 180 In the current RPKI system, the RP node is considered to be secure 181 and reliable. If the RP is malicious, its connected BGP router can 182 be a victim, causing serious routing security problems and 183 corresponding blocking IP addresses. A malicious RP provides an 184 incorrect manifest of valid ROAs, which causes the router to make an 185 error in the validity of the route origination, and indirectly causes 186 some legitimate IP address traffic to be blocked or redirected. For 187 the above problems, under the current architecture and mechanism of 188 RPKI, it is difficult to distinguish whether the operation on various 189 resource certificate objects is due to the misconfiguration (or the 190 malicious behavior) of the resource management agency, or the normal 191 contract between the issuer and the recipient of the resource 192 certificate. 194 At the same time, the current RPKI system makes the load of RPs very 195 heavy. The RPs need to perform the acquisition, verification and 196 synchronization of all resource certificates and ROAs, and also need 197 to interact with the BGP routers connected to them. The reliability, 198 security, and performance of RPs are the bottleneck of the entire 199 RPKI system. 201 3. IANA Considerations 203 This document makes no request of IANA. 205 Note to RFC Editor: this section may be removed on publication as an 206 RFC. 208 4. Security Considerations 210 5. References 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, 214 DOI 10.17487/RFC2119, March 1997, 215 . 217 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 218 DOI 10.17487/RFC2629, June 1999, 219 . 221 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 222 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 223 February 2012, . 225 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 226 Resource Certificate Repository Structure", RFC 6481, 227 DOI 10.17487/RFC6481, February 2012, 228 . 230 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 231 Origin Authorizations (ROAs)", RFC 6482, 232 DOI 10.17487/RFC6482, February 2012, 233 . 235 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 236 "Manifests for the Resource Public Key Infrastructure 237 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 238 . 240 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 241 X.509 PKIX Resource Certificates", RFC 6487, 242 DOI 10.17487/RFC6487, February 2012, 243 . 245 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 246 Template for the Resource Public Key Infrastructure 247 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 248 . 250 [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", 251 RFC 7132, DOI 10.17487/RFC7132, February 2014, 252 . 254 [RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification 255 Authority (CA) or Repository Manager in the Resource 256 Public Key Infrastructure (RPKI)", RFC 8211, 257 DOI 10.17487/RFC8211, September 2017, 258 . 260 [RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., 261 Newton, A., and D. Shaw, "Resource Public Key 262 Infrastructure (RPKI) Validation Reconsidered", RFC 8360, 263 DOI 10.17487/RFC8360, April 2018, 264 . 266 Authors' Addresses 268 Yaping Liu 270 Shuo Zhang 272 Qingyuan Li 273 No. 230, West Waihuan Street. Higher Education Mega Center 274 Guangzhou, Guangdong 510006 275 China 277 Email: liqingyuan94@live.cn 279 Sufang