idnits 2.17.1 draft-ietf-sidrops-validating-bgp-speaker-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 23, 2019) is 1732 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: 'RFC7153' is defined on line 291, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. King 3 Internet-Draft C. Dietzel 4 Intended status: Standards Track D. Kopp 5 Expires: January 24, 2020 DE-CIX 6 A. Lambrianidis 7 AMS-IX 8 July 23, 2019 10 Signaling Prefix Origin Validation Results from an RPKI Origin 11 Validating BGP Speaker to BGP Peers 12 draft-ietf-sidrops-validating-bgp-speaker-03 14 Abstract 16 This document describes the use of BGP large communities, as well as 17 its usage, to signal prefix origin validation results from an RPKI 18 Origin validating BGP speaker to other BGP peers. Upon reception of 19 prefix origin validation results, peers can use this information in 20 their local routing decision process. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 26 "OPTIONAL" in this document are to be interpreted as described in BCP 27 14 [RFC2119] [RFC8174] when, and only when, they appear in all 28 capitals, as shown here. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 24, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. EBGP Prefix Origin Validation Large Community . . . . . . . . 3 66 3. BGP Prefix Origin Validation State Utilized at Validating 67 Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Signaling Prefix Origin Validation Results from a Validating 69 Peer to Peers . . . . . . . . . . . . . . . . . . . . . . . . 4 70 5. Operational Recommendations . . . . . . . . . . . . . . . . . 5 71 5.1. Local Routing Decision Process . . . . . . . . . . . . . 5 72 5.2. Validating Peers Receiving the EBGP Prefix Origin 73 Validation State Large Community . . . . . . . . . . . . 5 74 5.3. Information about Validity of a BGP Prefix Origin Not 75 Available at a Validating Peer . . . . . . . . . . . . . 6 76 5.4. Error Handling at Peers . . . . . . . . . . . . . . . . . 6 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 80 7.2. Informative References . . . . . . . . . . . . . . . . . 7 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 83 1. Introduction 85 RPKI-based prefix origin validation [RFC6480] can be a significant 86 operational burden for BGP peers to implement and adopt. To 87 facilitate acceptance and usage of prefix origin validation and 88 ultimately increase the security of the Internet routing system, 89 Autonomous Systems may provide RPKI-based prefix origin validation at 90 certain vantage points. The result of this prefix origin validation 91 is signaled to peers by using the EBGP Prefix Origin Validation State 92 Large Community as introduced in this document. 94 Peers receiving a prefix origin validation result from the validating 95 EBGP peer can use this information in their local routing decision 96 process for acceptance, rejection, preference, or other traffic 97 engineering purposes of a particular route. 99 2. EBGP Prefix Origin Validation Large Community 101 The origin validation state large community 12-octet function 102 specific large community [RFC8092] with the following encoding: 104 0 1 2 3 105 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 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Global Administrator | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | TBD1 (Sub-Type) | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Validation State | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 Figure 1 116 The value of the field TBD1 (Sub-Type) has to be assigned. The 117 Global Administrator field MUST be set to the AS number of the 118 validating BGP speaker conducting the prefix origin validation. The 119 last field of the large community is an unsigned integer that gives 120 the route's validation state as described in Section 4. 122 If the validating BGP speaker is configured to support the extensions 123 defined in this document, it SHOULD attach the origin validation 124 state large community to BGP UPDATE messages sent to EBGP peers by 125 mapping the computed validation state in the last field of the large 126 community. A receiving BGP speaker, in the absence of a local 127 validation state, SHOULD derive a validation state from the last 128 field of the received large community, if present. 130 An implementation SHOULD NOT send more than one instance of the 131 origin validation state large community. However, if more than one 132 instance is received, an implementation MUST disregard all instances 133 other than the one with the numerically greatest validation state 134 value. If the value received is greater than the largest specified 135 value (2), the implementation MUST apply a strategy similar to 136 attribute discard [RFC7606] by discarding the erroneous community and 137 logging the error for further analysis. 139 3. BGP Prefix Origin Validation State Utilized at Validating Peers 141 A validating BGP speaker that is aware of a BGP Prefix Origin 142 Validation state (see Section 4) for a certain route can handle this 143 information in one of the following modes of operation, attaching 144 validation state to routes as discussed in Section 2: 146 Simple Tagging: In this mode of operation, the BGP best path 147 selection algorithm is executed. The prefix origin validation 148 state is tagged accordingly. 150 Dropping and Tagging: Routes for which the prefix origin validation 151 state is "invalid" (according to [RFC6811]) are dropped by the 152 validating BGP speaker. Based on the remaining set of routes, 153 the BGP best path selection algorithm is executed. The prefix 154 origin validation state of "not found" or "valid" (according to 155 [RFC6811]) is tagged accordingly. 157 Strict Dropping and Tagging: Routes for which the prefix origin 158 validation state is "invalid" or "not found" (according to 159 [RFC6811]) are dropped by the validating BGP speaker. Based on 160 the remaining set of routes, the BGP best path selection 161 algorithm is executed. The prefix origin validation state of 162 "valid" is tagged to the advertised route. 164 A validating BGP speaker MUST support the Dropping and Tagging 165 operation mode. Other modes of operation are OPTIONAL. The mode of 166 operation MAY be configured by the validating BGP speaker operator 167 for all connected peers, or for each BGP session with a peer 168 separately. 170 Path hiding, as originally discussed in [RFC7947], may impact end-to- 171 end connectivity for peers receiving prefixes via validating BGP 172 speakers, if the best path selected contains a prefix with a prefix 173 origin validation state which is subsequently dropped. 175 However, these modes of operation might be used in combination with 176 any options discussed in Section 2.3.2 of [RFC7947] in order to allow 177 a peer to receive one or more routes and take the routing decision by 178 itself, or with implementations who support sending the next best 179 available path. 181 4. Signaling Prefix Origin Validation Results from a Validating Peer to 182 Peers 184 The EBGP Prefix Origin Validation State Community is utilized for 185 signaling prefix origin validation result from a validating BGP 186 speaker to other peers. 188 This draft proposes an encoding of the prefix origin validation 189 result [RFC6811] as follows: 191 +-------+-----------------------------+ 192 | Value | Meaning | 193 +-------+-----------------------------+ 194 | 0 | Lookup result = "valid" | 195 | 1 | Lookup result = "not found" | 196 | 2 | Lookup result = "invalid" | 197 +-------+-----------------------------+ 199 Table 1 201 This encoding is re-used. Validating peers providing RPKI-based 202 prefix origin validation set the validation state according to the 203 prefix origin validation result (see [RFC6811]). 205 5. Operational Recommendations 207 5.1. Local Routing Decision Process 209 A peer receiving prefix origin validation results from the route 210 server MAY use the information in its own local routing decision 211 process. The local routing decision process SHOULD apply to the 212 rules as described in Section 5 [RFC6811]. 214 A peer receiving a prefix origin validation result from the route 215 server MAY redistribute this information within its own AS. 217 In cases where multiple ASes are being administered by the same 218 authority, peers MAY also redistribute this information across EBGP 219 boundaries of the authority in question. 221 5.2. Validating Peers Receiving the EBGP Prefix Origin Validation State 222 Large Community 224 A validating BGP speaker receiving routes from peers containing the 225 EBGP Prefix Origin Validation State Large Community MUST remove the 226 large community before the route is re-distributed to its peers. 227 This is required regardless of whether the validating BGP speaker is 228 executing prefix origin validation or not. 230 Failure to do so would allow opportunistic peers to advertise routes 231 tagged with arbitrary prefix origin validation results via validating 232 peers, influencing maliciously the decision process of other, non- 233 validating BGP speakers. 235 5.3. Information about Validity of a BGP Prefix Origin Not Available at 236 a Validating Peer 238 In case information about the validity of a BGP prefix origin is not 239 available at the validating BGP speaker (e.g., error in the ROA 240 cache, CPU overload) the validating BGP speaker MUST NOT add the EBGP 241 Prefix Origin Validation State Large Community to the route. 243 5.4. Error Handling at Peers 245 A route sent by a validating BGP speaker SHOULD only contain none or 246 one EBGP Prefix Origin Validation State Large Community. 248 A peer receiving a route from a validating BGP speaker containing 249 more than one EBGP Prefix Origin Validation State Large Community 250 SHOULD only consider the largest value (as described in Table 1) in 251 the validation result field and disregard the other values. Values 252 larger than two in the validation result field MUST be disregarded. 254 6. Security Considerations 256 All security considerations described in RFC6811 [RFC6811] fully 257 apply to this document. 259 Additionally, threat agents polluting ROA cache server(s) run by AS 260 operators could cause significant operational impact, since multiple 261 validating BGP speaker clients could be affected. Peers should be 262 vigilant as to the integrity and authenticity of the origin 263 validation results as they are provided by a third party, namely the 264 AS operator hosting both the validating BGP speaker as well as any 265 ROA cache server(s). 267 Therefore, a validating BGP speaker could be misused to spread 268 malicious prefix origin validation results. However, in the case of 269 IXPs, peers already trust the route server for the collection, 270 filtering (e.g., IRR database filtering), and redistribution of BGP 271 routing information to other peers. 273 To facilitate trust and support with peers establishing appropriate 274 controls in mitigating the risks mentioned above, AS operators SHOULD 275 provide out-of-band means for peers to ensure that the ROA validation 276 process has not been compromised or corrupted. 278 7. References 279 7.1. Normative References 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, 283 DOI 10.17487/RFC2119, March 1997, 284 . 286 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 287 Austein, "BGP Prefix Origin Validation", RFC 6811, 288 DOI 10.17487/RFC6811, January 2013, 289 . 291 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 292 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 293 March 2014, . 295 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 296 Patel, "Revised Error Handling for BGP UPDATE Messages", 297 RFC 7606, DOI 10.17487/RFC7606, August 2015, 298 . 300 [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, 301 I., and N. Hilliard, "BGP Large Communities Attribute", 302 RFC 8092, DOI 10.17487/RFC8092, February 2017, 303 . 305 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 306 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 307 May 2017, . 309 7.2. Informative References 311 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 312 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 313 February 2012, . 315 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 316 "Internet Exchange BGP Route Server", RFC 7947, 317 DOI 10.17487/RFC7947, September 2016, 318 . 320 Authors' Addresses 321 Thomas King 322 DE-CIX Management GmbH 323 Lichtstrasse 43i 324 Cologne 50825 325 DE 327 Email: thomas.king@de-cix.net 329 Christoph Dietzel 330 DE-CIX Management GmbH 331 Lichtstrasse 43i 332 Cologne 50825 333 DE 335 Email: christoph.dietzel@de-cix.net 337 Daniel Kopp 338 DE-CIX Management GmbH 339 Lichtstrasse 43i 340 Cologne 50825 341 DE 343 Email: daniel.kopp@de-cix.net 345 Aristidis Lambrianidis 346 Amsterdam Internet Exchange 347 Frederiksplein 42 348 Amsterdam 1017 XN 349 NL 351 Email: aristidis.lambrianidis@ams-ix.net