idnits 2.17.1 draft-sidrops-bgpsec-validation-signaling-04.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 22, 2020) is 1309 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 235, 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 26, 2021 D. Kopp 6 DE-IX 7 September 22, 2020 9 BGPsec Validation State Signaling 10 draft-sidrops-bgpsec-validation-signaling-04 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 peering 158 session where either the usage is not enabled or it is not part of a 159 BGPsec 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 iBGP or a trusted eBGP peer. The router then 180 will use the validation result learned via the community string and 181 apply it to the route. In case the peer sent the validation state 182 "unverified", the receiving router SHOULD perform BGPsec path 183 validation as described in [RFC8205] (Section 5.2). 185 5. IANA Considerations 187 IANA shall assign a new value from the "BGP Opaque Extended 188 Community" type registry from the non-transitive range, to be called 189 "BGPsec Path Validation State Extended Community". 191 6. Security Considerations 193 Security considerations such as those described in [RFC4272] continue 194 to apply. Because this document introduces an extended community 195 that will generally be used to affect route selection, the analysis 196 in Section 4.5 ("Falsification") of [RFC4593] is relevant. These 197 issues are neither new nor unique to the validation extended 198 community. 200 The security considerations provided in [RFC8205] apply equally to 201 this application of BGPsec path validation. In addition, this 202 document describes a scheme where router A outsources validation to 203 some router B. If this scheme is used, the participating routers 204 should have the appropriate trust relationship -- B should trust A 205 either because they are under the same administrative control or for 206 some other reasons as explained earlier. The security properties of 207 the TCP connection between the two routers should also be considered. 208 See [RFC7454] (Section 5.1) for advice regarding protection of the 209 TCP connection. 211 7. References 213 7.1. Normative References 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, DOI 217 10.17487/RFC2119, March 1997, . 220 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 221 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 222 February 2006, . 224 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 225 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 226 10.17487/RFC8174, May 2017, . 229 [RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol 230 Specification", RFC 8205, DOI 10.17487/RFC8205, September 231 2017, . 233 7.2. Informative References 235 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 236 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 237 10.17487/RFC4271, January 2006, . 240 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 241 RFC 4272, DOI 10.17487/RFC4272, January 2006, 242 . 244 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 245 Routing Protocols", RFC 4593, DOI 10.17487/RFC4593, 246 October 2006, . 248 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 249 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 250 February 2015, . 252 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 253 Patel, "Revised Error Handling for BGP UPDATE Messages", 254 RFC 7606, DOI 10.17487/RFC7606, August 2015, 255 . 257 [RFC8097] Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. 258 Bush, "BGP Prefix Origin Validation State Extended 259 Community", RFC 8097, DOI 10.17487/RFC8097, March 2017, 260 . 262 [BORCHERT] Borchert, O., Montgomery, D., "BGPsec Validation State 263 Unverified", draft-borchert-sidrops-bgpsec-validation- 264 state-unverified-03, 267 Acknowledgements 269 The authors wish to thank P. Mohapatra, K. Patel, 270 J. Scudder, D. Ward, and R. Bush for producing [RFC8097], 271 which this document is based on. The authors would also 272 like to acknowledge the valuable review, discussions, and 273 suggestions from K. Sriram and N. Hillard on this 274 document. 276 Authors' Addresses 278 Oliver Borchert 279 National Institute of Standards and Technology (NIST) 280 100 Bureau Drive 281 Gaithersburg, MD 20899 282 United States of America 284 Email: oliver.borchert@nist.gov 286 Doug Montgomery 287 National Institute of Standards and Technology (NIST) 288 100 Bureau Drive 289 Gaithersburg, MD 20899 290 United States of America 292 Email: dougm@nist.gov 294 Daniel Kopp 295 DE-CIX Management GmbH 296 Lichtstrasse 43i 297 Cologne 50825 298 Germany 300 Email: daniel.kopp@de-cix.net