idnits 2.17.1 draft-borchert-sidrops-rpki-state-unverified-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 draft header indicates that this document updates RFC6811, but the abstract doesn't seem to directly say this. It does mention RFC6811 though, so this could be OK. -- The draft header indicates that this document updates RFC8097, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2018) is 2005 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force (IETF) O. Borchert 3 Internet-Draft D. Montgomery 4 Updates: 6811, 8097 (if approved) USA NIST 5 Intended status: Standards Track 6 Expires: April 26, 2019 October 23, 2018 8 RPKI Validation State Unverified 9 draft-borchert-sidrops-rpki-state-unverified-00 11 Abstract 13 In case operators decide not to evaluate BGP route prefixes according 14 to RPKI origin validation, none of the available states as specified 15 in RFC 6811 do properly represent this decision. This document 16 introduces "Unverified" as well-defined validation state which allows 17 to properly identify route prefixes as not evaluated according to 18 RPKI route origin validation. 20 Status of This Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Initializing route prefixes . . . . . . . . . . . . . . . . . 3 62 3.1. Update to RFC 6811 . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Update to RFC 8097 . . . . . . . . . . . . . . . . . . . . 4 64 3. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 70 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 Prefix origin validation provides well-defined validation states. 76 Though, there are instances in which no evaluation of a route prefix 77 is performed, not through RPKI route origin validation [RFC6811], 78 signaling via the extended community string as specified in 79 [RFC8097], or operator configuration. In these circumstances RFC 6811 80 specifies the implementation SHOULD initialize the validation state 81 of such route to "NotFound". Here, the absence of a well-defined 82 validation state for a route prefix not evaluated, requires the usage 83 of a state otherwise reserved as outcome of the evaluation of such. 84 This "waters" down the meaning of the used state. The specification 85 of a proper validation state that allows identifying non-evaluated 86 routes, becomes of essence once an operator decides to write policies 87 on the validation state "NotFound". A route prefix labeled "NotFound" 88 cannot be considered same as an unverified route prefix. 90 Hence, this document updates RFC 6811 and RFC 8097 by adding the 91 proposed validation state "Unverified". 93 1.1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 2. Suggested Reading 103 It is assumed that the reader understands BGP [RFC4271], the RPKI 104 [RFC6480], Route Origin Authorizations (ROAs) [RFC6482], RPKI-based 105 Prefix Validation [RFC6811], BGP Prefix Origin Validation State 106 Extended Community [RFC8097], Clarifications to BGP Origin Validation 107 Based on Resource Public Key Infrastructure (RPKI) [RFC8481] 109 3. Initializing route prefixes 111 This document introduces the validation state "Unverified" to be used 112 for route prefixes that are not evaluated through either operator 113 configuration, RPKI route origin validation, or other means such as 114 receiving a signaled validation state via the extended community 115 string. To allow proper initialization the following state is 116 introduced: 118 o Unverified: Specifies the state of a route prefix on which no 119 evaluation has been performed. 121 3.1. Update to RFC 6811 123 RFC 6811 specifies that: 125 If validation is not performed on a Route, the implementation 126 SHOULD initialize the validation state of such a route to 127 "NotFound". 129 This document specifies that: 131 If no evaluation of a route prefix is performed in any form, the 132 implementation MUST initialize the validation state of such a route 133 to "Unverified". 135 This removes the necessity to initialize the route with any of the 136 states "Valid", "Invalid", or "NotFound" and therefore does not 137 "water-down" the meaning of such. 139 3.2. Update to RFC 8097 141 As specified in RFC 8097: 143 If the router is configured to support the extensions defined in 144 this document" - (RFC 8097) - ", it SHOULD attach the origin 145 validation state extended community to BGP UPDATE messages sent to 146 IBGP peers by mapping the computed validation state in the last 147 octet of the extended community. 149 The missing part here is what to do with route prefixes not evaluated 150 and no validation state was assigned. At this point the only solution 151 is to omit the extended community for such routes. If the usage of 152 the extended community would have been negotiated during the BGP OPEN 153 MESSAGE the receiver would be able to determine that the sender did 154 not evaluate the route in any form. But this is not the case, so a 155 receiver does not know if the sender is RPKI capable and chose not to 156 attach the origin validation state to the BGP UPDATE or the route did 157 not have any validation state assigned. 159 Hence, this document specifies for all routes that are labeled as 160 "Unverified" to attach the "unverified" state extended community to 161 BGP UPDATE messages send to IBGP peers by mapping the computed 162 validation state in the last octet of the extended community. 164 AS specified in the table below, this document adds the value 165 "unverified = 3" to the list of acceptable values. 167 The value on the protocol 169 +-------+------------------------------+ 170 | Value | Meaning | 171 +-------+------------------------------+ 172 | 0 | Lookup result = "valid" | 173 | 1 | Lookup result = "not found" | 174 | 2 | Lookup result = "invalid" | 175 | 3 | Lookup result = "unverified" | 176 +-------+------------------------------+ 178 3. Usage Considerations 180 The well-defined validation state "Unverified" allows to distinguish 181 between evaluated routes and non-evaluated routes. This allows the 182 operator to create policies to treat such route prefixes different 183 from route prefixes labeled with one of the validation states 184 "Valid", "NotFound", or "Invalid". 186 4. Security Considerations 188 This document introduces no new security concerns beyond what is 189 described in [RFC6811] and [RFC8097] 191 5. IANA Considerations 193 This document has no IANA actions. 195 6. References 197 6.1. Normative References 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, DOI 201 10.17487/RFC2119, March 1997, . 204 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 205 Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 206 10.17487/RFC6811, January 2013, . 209 [RFC8097] Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. 210 Bush, "BGP Prefix Origin Validation State Extended 211 Community", RFC 8097, DOI 10.17487/RFC8097, March 2017, 212 . 214 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 215 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 216 10.17487/RFC8174, May 2017, . 219 8.2. Informative References 221 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 222 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 223 10.17487/RFC4271, January 2006, . 226 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 227 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 228 February 2012, . 230 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 231 Origin Authorizations (ROAs)", RFC 6482, DOI 232 10.17487/RFC6482, February 2012, . 235 [RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based 236 on Resource Public Key Infrastructure (RPKI)", RFC 8481, 237 DOI 10.17487/RFC8481, September 2018, . 240 Acknowledgements 242 The authors would like to acknowledge the valuable review and 243 suggestions from K. Sriram on this document. 245 Authors' Addresses 247 Oliver Borchert 248 National Institute of Standards and Technology (NIST) 249 100 Bureau Drive 250 Gaithersburg, MD 20899 251 United States of America 253 Email: oliver.borchert@nist.gov 255 Douglas Montgomery 256 National Institute of Standards and Technology (NIST) 257 100 Bureau Drive 258 Gaithersburg, MD 20899 259 United States of America 261 Email: dougm@nist.gov