idnits 2.17.1 draft-sidrops-bgpsec-validation-signaling-03.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 (July 27, 2020) is 1361 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 231, 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: January 28, 2021 D. Kopp 6 DE-IX 7 July 27, 2020 9 BGPsec Validation State Signaling 10 draft-sidrops-bgpsec-validation-signaling-03 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 . . . . . . . . . . . . . . . . . . 4 66 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 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. This SHOULD be done automatically for iBGP peers and 134 configurable for eBGP peers (see below). 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 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 validation sate of the UPDATE. 146 Implementations MUST provide a configuration mechanism to allow the 147 use of this community (both sending and receiving) to be disabled on 148 a per peer basis. By default, routers SHOULD enable use of this 149 community on all iBGP sessions and routers SHOULD disable the use of 150 this community on all eBGP sessions. Implementations MUST NOT send 151 more than one instance of the origin validation state extended 152 community and MUST drop (without processing) the BGPsec path 153 validation state extended community if received over an External BGP 154 (eBGP) peering session that has not be explicitly configured to 155 enable processing. 157 3.1. Error Handling at Peers 159 If more than one instance of the extended community is received, or 160 if the value received is greater than the largest specified value 161 above (Section 3), then the implementation MUST disregard all 162 instances of this community and MUST apply a strategy similar to 163 "Attribute discard" [RFC7606] Section 2 by discarding the erroneous 164 community and logging the error for further analysis. 166 4. Deployment Considerations 168 As specified in [RFC8205] (Section 5) "a BGPsec speaker MAY 169 temporarily defer validation of incoming UPDATE messages. The 170 treatment of such UPDATE messages, whose validation has been 171 deferred, is a matter of local policy". 173 Furthermore, one can envision that the operator of a BGPsec router 174 decides to defer local BGPsec validation when a validation state 175 value is learned via iBGP or a trusted eBGP peer. The router then 176 will use the validation result learned via the community string and 177 apply it to the route. In case the peer sent the validation state 178 "unverified", the receiving router SHOULD perform BGPsec path 179 validation as described in [RFC8205] (Section 5.2). 181 5. IANA Considerations 183 IANA shall assign a new value from the "BGP Opaque Extended 184 Community" type registry from the non-transitive range, to be called 185 "BGPsec Path Validation State Extended Community". 187 6. Security Considerations 189 Security considerations such as those described in [RFC4272] continue 190 to apply. Because this document introduces an extended community 191 that will generally be used to affect route selection, the analysis 192 in Section 4.5 ("Falsification") of [RFC4593] is relevant. These 193 issues are neither new nor unique to the validation extended 194 community. 196 The security considerations provided in [RFC8205] apply equally to 197 this application of BGPsec path validation. In addition, this 198 document describes a scheme where router A outsources validation to 199 some router B. If this scheme is used, the participating routers 200 should have the appropriate trust relationship -- B should trust A 201 either because they are under the same administrative control or for 202 some other reasons as explained earlier. The security properties of 203 the TCP connection between the two routers should also be considered. 204 See [RFC7454] (Section 5.1) for advice regarding protection of the 205 TCP connection. 207 7. References 209 7.1. Normative References 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, DOI 213 10.17487/RFC2119, March 1997, . 216 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 217 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 218 February 2006, . 220 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 221 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 222 10.17487/RFC8174, May 2017, . 225 [RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol 226 Specification", RFC 8205, DOI 10.17487/RFC8205, September 227 2017, . 229 7.2. Informative References 231 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 232 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 233 10.17487/RFC4271, January 2006, . 236 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 237 RFC 4272, DOI 10.17487/RFC4272, January 2006, 238 . 240 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 241 Routing Protocols", RFC 4593, DOI 10.17487/RFC4593, 242 October 2006, . 244 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 245 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 246 February 2015, . 248 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 249 Patel, "Revised Error Handling for BGP UPDATE Messages", 250 RFC 7606, DOI 10.17487/RFC7606, August 2015, 251 . 253 [RFC8097] Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. 254 Bush, "BGP Prefix Origin Validation State Extended 255 Community", RFC 8097, DOI 10.17487/RFC8097, March 2017, 256 . 258 [BORCHERT] Borchert, O., Montgomery, D., "BGPsec Validation State 259 Unverified", draft-borchert-sidrops-bgpsec-validation- 260 state-unverified-03, 263 Acknowledgements 265 The authors wish to thank P. Mohapatra, K. Patel, 266 J. Scudder, D. Ward, and R. Bush for producing [RFC8097], 267 which this document is based on. The authors would also 268 like to acknowledge the valuable review and suggestions 269 from K. Sriram on this document. 271 Authors' Addresses 273 Oliver Borchert 274 National Institute of Standards and Technology (NIST) 275 100 Bureau Drive 276 Gaithersburg, MD 20899 277 United States of America 279 Email: oliver.borchert@nist.gov 281 Doug Montgomery 282 National Institute of Standards and Technology (NIST) 283 100 Bureau Drive 284 Gaithersburg, MD 20899 285 United States of America 287 Email: dougm@nist.gov 289 Daniel Kopp 290 DE-CIX Management GmbH 291 Lichtstrasse 43i 292 Cologne 50825 293 Germany 295 Email: daniel.kopp@de-cix.net