idnits 2.17.1 draft-sidrops-bgpsec-validation-signaling-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2020) is 1281 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) == Unused Reference: 'RFC4271' is defined on line 239, but no explicit reference was found in the text -- No information found for draft-borchert-sidrops-bgpsec-validation-state-unverified - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 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 Intended status: Standards Track USA NIST 5 Expires: March 29, 2021 D. Kopp 6 DE-IX 7 September 25, 2020 9 BGPsec Validation State Signaling 10 draft-sidrops-bgpsec-validation-signaling-05 12 Abstract 14 This document defines a new BGP non-transitive extended community to 15 carry the BGPsec path validation state. BGP speakers that receive 16 this community string can use the embedded BGPsec validation state in 17 conjunction with configured local policies to influence their 18 decision process. The ability to accept and act on BGPsec path 19 validation state from a neighbor allows for a reduction of path 20 validation processing load and/or increased resilience in the event 21 that a router is temporarily unable to perform local path validation. 23 Status of This Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 64 3. BGPsec Validation State Extended Community . . . . . . . . . . 3 65 3.1. Error Handling at Peers . . . . . . . . . . . . . . . . . . 5 66 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 This document defines a new BGP non-transitive extended community to 78 carry the BGPsec path validation state. BGP speakers that receive 79 this community string can use the embedded BGPsec validation state in 80 conjunction with configured local policies to influence their 81 decision process. The ability to accept and act on BGPsec path 82 validation state from a neighbor allows for a reduction of path 83 validation processing load and/or increased resilience in the event 84 that a router is temporarily unable to perform local path validation. 86 1.1. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in 91 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 92 capitals, as shown here. 94 2. Suggested Reading 96 It is assumed that the reader is familiar with BGPsec [RFC8205]. 98 3. BGPsec Validation State Extended Community 100 The BGPsec validation state extended community is a non-transitive 101 extended community [RFC4360] with the following encoding: 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | 0x43 | TBD | Reserved | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Reserved |Validationstate| 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 The value of the high-order octet of the extended Type field is 0x43, 112 which indicates it is non-transitive. The value of the low-order 113 octet of the extended Type field as assigned by IANA is TBD. The 114 Reserved field MUST be set to 0 and ignored upon the receipt of this 115 community. The last octet of the extended community is an unsigned 116 integer that gives the BGPsec route's path validation state, see 117 [RFC8205] and [BORCHERT]. 119 The validation state field can assume the following values: 121 +-------+---------------------------------+ 122 | Value | Meaning | 123 +-------+---------------------------------+ 124 | 0 | Validation state = "Unverified" | 125 | 1 | Validation state = "Valid" | 126 | 2 | Validation state = "Not Valid" | 127 +-------+---------------------------------+ 129 If the router supports the extension as defined in this document, it 130 SHOULD attach the BGPsec path validation state extended community to 131 BGPsec UPDATE messages sent to BGP peers by mapping the locally 132 computed validation state into the last octet of the extended 133 community. Operational behavior is governed by Section 6 of 134 [RFC4360]. 136 Note, if a BGPsec speaker attaches this community to an UPDATE that 137 was not explicitly validated at this router, the signaled validation 138 state MUST be set to "Unverified". 140 A receiving BGPsec enabled router SHOULD use the received BGPsec path 141 validation state in situations where a locally computed BGPsec path 142 validation result is not currently available. In the absence of the 143 extended community, the receiving BGPsec enabled router MUST NOT make 144 any assumption about the peer's validation state of the UPDATE. A 145 locally computed validation state for an UPDATE takes precedence over 146 the received validation state. 148 Implementations MUST provide a configuration mechanism to allow the 149 use of this community (both sending and receiving) to be disabled on 150 a per peer basis. By default, routers SHOULD enable use of this 151 community on all iBGP sessions. Implementations MUST NOT send more 152 than one instance of the BGPsec validation state extended community. 153 Implementations MUST NOT send the extended community if not in a 154 BGPsec UPDATE. 156 Implementations MUST drop (without processing) the BGPsec path 157 validation state extended community if received over a BGP session 158 where either the usage is not enabled or it is not part of a BGPsec 159 UPDATE. 161 3.1. Error Handling at Peers 163 If more than one instance of the extended community is received, or 164 if the value received is greater than the largest specified value 165 above (Section 3), then the implementation MUST disregard all 166 instances of this community and MUST apply a strategy similar to 167 "Attribute discard" [RFC7606] Section 2 by discarding the erroneous 168 community and logging the error for further analysis. 170 4. Deployment Considerations 172 As specified in [RFC8205] (Section 5) "a BGPsec speaker MAY 173 temporarily defer validation of incoming UPDATE messages. The 174 treatment of such UPDATE messages, whose validation has been 175 deferred, is a matter of local policy". 177 Furthermore, one can envision that the operator of a BGPsec router 178 decides to defer local BGPsec validation when a validation state 179 value is learned via BGP. The router then will use the validation 180 result learned via the community string and apply it to the route. 181 In case the peer sent the validation state "unverified", the 182 receiving router SHOULD perform BGPsec path validation as described 183 in [RFC8205] (Section 5.2). 185 If the received validation state of a route differs from a BGPsec 186 validation state locally computed according to [RFC8205], then the 187 locally computed BGPsec validation state MUST be used and the 188 received validation state MUST be ignored. 189 5. IANA Considerations 191 IANA shall assign a new value from the "BGP Opaque Extended 192 Community" type registry from the non-transitive range, to be called 193 "BGPsec Path Validation State Extended Community". 195 6. Security Considerations 197 Security considerations such as those described in [RFC4272] continue 198 to apply. Because this document introduces an extended community 199 that will generally be used to affect route selection, the analysis 200 in Section 4.5 ("Falsification") of [RFC4593] is relevant. These 201 issues are neither new nor unique to the validation extended 202 community. 204 The security considerations provided in [RFC8205] apply equally to 205 this application of BGPsec path validation. In addition, this 206 document describes a scheme where router A outsources validation to 207 some router B. If this scheme is used, the participating routers 208 should have the appropriate trust relationship -- B should trust A 209 either because they are under the same administrative control or for 210 some other reasons as explained earlier. The security properties of 211 the TCP connection between the two routers should also be considered. 212 See [RFC7454] (Section 5.1) for advice regarding protection of the 213 TCP connection. 215 7. References 217 7.1. Normative References 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, DOI 221 10.17487/RFC2119, March 1997, . 224 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 225 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 226 February 2006, . 228 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 229 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 230 10.17487/RFC8174, May 2017, . 233 [RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol 234 Specification", RFC 8205, DOI 10.17487/RFC8205, September 235 2017, . 237 7.2. Informative References 239 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 240 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 241 10.17487/RFC4271, January 2006, . 244 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 245 RFC 4272, DOI 10.17487/RFC4272, January 2006, 246 . 248 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 249 Routing Protocols", RFC 4593, DOI 10.17487/RFC4593, 250 October 2006, . 252 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 253 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 254 February 2015, . 256 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 257 Patel, "Revised Error Handling for BGP UPDATE Messages", 258 RFC 7606, DOI 10.17487/RFC7606, August 2015, 259 . 261 [RFC8097] Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. 262 Bush, "BGP Prefix Origin Validation State Extended 263 Community", RFC 8097, DOI 10.17487/RFC8097, March 2017, 264 . 266 [BORCHERT] Borchert, O., Montgomery, D., "BGPsec Validation State 267 Unverified", draft-borchert-sidrops-bgpsec-validation- 268 state-unverified-03, 271 Acknowledgements 273 The authors wish to thank P. Mohapatra, K. Patel, 274 J. Scudder, D. Ward, and R. Bush for producing [RFC8097], 275 which this document is based on. The authors would also 276 like to acknowledge the valuable review, discussions, and 277 suggestions from K. Sriram and N. Hilliard on this 278 document. 280 Authors' Addresses 282 Oliver Borchert 283 National Institute of Standards and Technology (NIST) 284 100 Bureau Drive 285 Gaithersburg, MD 20899 286 United States of America 288 Email: oliver.borchert@nist.gov 290 Doug Montgomery 291 National Institute of Standards and Technology (NIST) 292 100 Bureau Drive 293 Gaithersburg, MD 20899 294 United States of America 296 Email: dougm@nist.gov 298 Daniel Kopp 299 DE-CIX Management GmbH 300 Lichtstrasse 43i 301 Cologne 50825 302 Germany 304 Email: daniel.kopp@de-cix.net