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