idnits 2.17.1 draft-ietf-sidrops-validating-bgp-speaker-00.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 (February 01, 2018) is 2269 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: August 5, 2018 DE-CIX 6 A. Lambrianidis 7 AMS-IX 8 A. Fenioux 9 France-IX 10 February 01, 2018 12 Signaling Prefix Origin Validation Results from an RPKI Origin 13 Validating BGP Speaker to BGP Peers 14 draft-ietf-sidrops-validating-bgp-speaker-00 16 Abstract 18 This document defines a new BGP transitive extended community, as 19 well as its usage, to signal prefix origin validation results from an 20 RPKI Origin validating BGP speaker to other BGP peers. Upon 21 reception of prefix origin validation results, peers can use this 22 information in their local routing decision process. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 28 "OPTIONAL" in this document are to be interpreted as described in BCP 29 14 [RFC2119] [RFC8174] when, and only when, they appear in all 30 capitals, as shown here. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 5, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. EBGP Prefix Origin Validation Extended Community . . . . . . 3 68 3. BGP Prefix Origin Validation State Utilized at Validating 69 Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Signaling Prefix Origin Validation Results from a Validating 71 Peer to Peers . . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Operational Recommendations . . . . . . . . . . . . . . . . . 5 73 5.1. Local Routing Decision Process . . . . . . . . . . . . . 5 74 5.2. Validating Peers Receiving the EBGP Prefix Origin 75 Validation State Extended Community . . . . . . . . . . . 5 76 5.3. Information about Validity of a BGP Prefix Origin Not 77 Available at a Validating Peer . . . . . . . . . . . . . 6 78 5.4. Error Handling at Peers . . . . . . . . . . . . . . . . . 6 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 83 8.2. Informative References . . . . . . . . . . . . . . . . . 8 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 86 1. Introduction 88 RPKI-based prefix origin validation [RFC6480] can be a significant 89 operational burden for BGP peers to implement and adopt. To 90 facilitate acceptance and usage of prefix origin validation and 91 ultimately increase the security of the Internet routing system, 92 Autonomous Systems may provide RPKI-based prefix origin validation at 93 certain vantage points. The result of this prefix origin validation 94 is signaled to peers by using the EBGP Prefix Origin Validation State 95 Extended Community as introduced in this document. 97 Peers receiving a prefix origin validation result from the validating 98 EBGP peer can use this information in their local routing decision 99 process for acceptance, rejection, preference, or other traffic 100 engineering purposes of a particular route. 102 2. EBGP Prefix Origin Validation Extended Community 104 The origin validation state extended community is a transitive Four- 105 octet AS Specific Extended Community [RFC5668] with the following 106 encoding: 108 0 1 2 3 109 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 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | 0x02 |TBD1 (Sub-Type)| Reserved | Global Admin : 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 : Global Administrator (cont.) |validationstate| 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 Figure 1 118 The value of the high-order octet of the extended Type field is 0x02, 119 which indicates it is transitive. The value of the low-order octet 120 (Sub-Type) of the extended Type field as assigned by IANA is TBD1. 121 The Reserved field MUST be set to 0 and ignored upon receipt of this 122 community. The Global Administrator field MUST be set to the AS 123 number of the validating BGP speaker conducting the prefix origin 124 validation. The last octet of the extended community is an unsigned 125 integer that gives the route's validation state as described in 126 Section 4. 128 If the validating BGP speaker is configured to support the extensions 129 defined in this document, it SHOULD attach the origin validation 130 state extended community to BGP UPDATE messages sent to EBGP peers by 131 mapping the computed validation state in the last octet of the 132 extended community. A receiving BGP speaker, in the absence of a 133 local validation state, SHOULD derive a validation state from the 134 last octet of the received extended community, if present. 136 An implementation SHOULD NOT send more than one instance of the 137 origin validation state extended community. However, if more than 138 one instance is received, an implementation MUST disregard all 139 instances other than the one with the numerically greatest validation 140 state value. If the value received is greater than the largest 141 specified value (2), the implementation MUST apply a strategy similar 142 to attribute discard [RFC7606] by discarding the erroneous community 143 and logging the error for further analysis. 145 3. BGP Prefix Origin Validation State Utilized at Validating Peers 147 A validating BGP speaker that is aware of a BGP Prefix Origin 148 Validation state for a certain route can handle this information in 149 one of the following modes of operation: 151 Simple Tagging: The prefix origin validation state is tagged to the 152 route as described in Section 2. 153 This mode of operation is similar to the traditional BGP decision 154 process, moreover, the prefix origin validation state information 155 is available for peers. 157 Dropping and Tagging: Routes for which the prefix origin validation 158 state is "invalid" (according to [RFC6811]) are dropped by the 159 validating BGP speaker. Routes which show a prefix origin 160 validation state of "not found" and "valid" (according to 161 [RFC6811]) are tagged accordingly, as discussed in Section 2. 162 In this mode of operation, security is rated higher than 163 questionable reachability of a prefix. 165 Prioritizing and Tagging: If the validating BGP speaker holds for a 166 particular prefix more than one route it removes the set of 167 "invalid" routes first and secondly the "not found" routes unless 168 the set of routes is empty. Based on the remaining set of 169 routes, the BGP best path selection algorithm is executed. The 170 selected route is marked according to Section 4. The BGP best 171 path selection algorithm is changed by this mode of operation in 172 such a way that "valid" routes are preferred even if they are 173 unfavorable by the traditional best path selection algorithm. 174 This mode promotes prefix origin validation to be the most 175 important criterion for the path selection. 177 A validating BGP speaker MUST support the Simple Tagging operation 178 mode. Other modes of operation are OPTIONAL. The mode of operation 179 MAY be configured by the validating BGP speaker operator for all 180 connected peers, or for each BGP session with a peer separately. 182 Path hiding, as originally discussed in [RFC7947], may impact end-to- 183 end connectivity for peers receiving prefixes via validating peers, 184 if the best path selected contains a prefix with an "invalid" prefix 185 origin validation state, and is subsequently dropped, either at the 186 peer (Simple Tagging operation mode) or the validating BGP speaker 187 itself (Dropping and Tagging operation mode). 189 However, these modes of operation might be used in combination with 190 [RFC7911] in order to allow a peer to receive all routes and take the 191 routing decision by itself. 193 4. Signaling Prefix Origin Validation Results from a Validating Peer to 194 Peers 196 The EBGP Prefix Origin Validation State Community is utilized for 197 signaling prefix origin validation result from a validating BGP 198 speaker to other peers. 200 This draft proposes an encoding of the prefix origin validation 201 result [RFC6811] as follows: 203 +-------+-----------------------------+ 204 | Value | Meaning | 205 +-------+-----------------------------+ 206 | 0 | Lookup result = "valid" | 207 | 1 | Lookup result = "not found" | 208 | 2 | Lookup result = "invalid" | 209 +-------+-----------------------------+ 211 Table 1 213 This encoding is re-used. Validating peers providing RPKI-based 214 prefix origin validation set the validation state according to the 215 prefix origin validation result (see [RFC6811]). 217 5. Operational Recommendations 219 5.1. Local Routing Decision Process 221 A peer receiving prefix origin validation results from the route 222 server MAY use the information in its own local routing decision 223 process. The local routing decision process SHOULD apply to the 224 rules as described in Section 5 [RFC6811]. 226 A peer receiving a prefix origin validation result from the route 227 server MAY redistribute this information within its own AS. 229 In cases where multiple ASes are being administered by the same 230 authority, peers MAY also redistribute this information across EBGP 231 boundaries of the authority in question. 233 5.2. Validating Peers Receiving the EBGP Prefix Origin Validation State 234 Extended Community 236 A validating BGP speaker receiving routes from peers containing the 237 EBGP Prefix Origin Validation State Extended Community MUST remove 238 the extended community before the route is re-distributed to its 239 peers. This is required regardless of whether the validating BGP 240 speaker is executing prefix origin validation or not. 242 Failure to do so would allow opportunistic peers to advertise routes 243 tagged with arbitrary prefix origin validation results via validating 244 peers, influencing maliciously the decision process of other, non- 245 validating BGP speakers. 247 5.3. Information about Validity of a BGP Prefix Origin Not Available at 248 a Validating Peer 250 In case information about the validity of a BGP prefix origin is not 251 available at the validating BGP speaker (e.g., error in the ROA 252 cache, CPU overload) the validating BGP speaker MUST NOT add the EBGP 253 Prefix Origin Validation State Extended Community to the route. 255 5.4. Error Handling at Peers 257 A route sent by a validating BGP speaker SHOULD only contain none or 258 one EBGP Prefix Origin Validation State Extended Community. 260 A peer receiving a route from a validating BGP speaker containing 261 more than one EBGP Prefix Origin Validation State Extended Community 262 SHOULD only consider the largest value (as described in Table 1) in 263 the validation result field and disregard the other values. Values 264 larger than two in the validation result field MUST be disregarded. 266 6. IANA Considerations 268 IANA is asked to assign a Transitive BGP Opaque Extended Community as 269 defined in Section 4 of [RFC7153]. 271 7. Security Considerations 273 All security considerations described in RFC6811 [RFC6811] fully 274 apply to this document. 276 Additionally, threat agents polluting ROA cache server(s) run by AS 277 operators could cause significant operational impact, since multiple 278 validating BGP speaker clients could be affected. Peers should be 279 vigilant as to the integrity and authenticity of the origin 280 validation results as they are provided by a third party, namely the 281 AS operator hosting both the validating BGP speaker as well as any 282 ROA cache server(s). 284 Therefore, a validating BGP speaker could be misused to spread 285 malicious prefix origin validation results. However, in the case of 286 IXPs, peers already trust the route server for the collection, 287 filtering (e.g., IRR database filtering), and redistribution of BGP 288 routing information to other peers. 290 To facilitate trust and support with peers establishing appropriate 291 controls in mitigating the risks mentioned above, AS operators SHOULD 292 provide out-of-band means for peers to ensure that the ROA validation 293 process has not been compromised or corrupted. 295 While being under DDoS attacks, it is a common practice for peers 296 connected to other Autonomous Systems and make use of blackholing 297 services. Peers are using blackholing to drop traffic, typically by 298 announcing a more specific prefix, which is under attack. A peer 299 SHOULD make sure that this prefix is covered by an appropriate ROA. 301 8. References 303 8.1. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, 307 DOI 10.17487/RFC2119, March 1997, 308 . 310 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 311 Specific BGP Extended Community", RFC 5668, 312 DOI 10.17487/RFC5668, October 2009, 313 . 315 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 316 Austein, "BGP Prefix Origin Validation", RFC 6811, 317 DOI 10.17487/RFC6811, January 2013, 318 . 320 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 321 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 322 March 2014, . 324 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 325 Patel, "Revised Error Handling for BGP UPDATE Messages", 326 RFC 7606, DOI 10.17487/RFC7606, August 2015, 327 . 329 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 330 "Advertisement of Multiple Paths in BGP", RFC 7911, 331 DOI 10.17487/RFC7911, July 2016, 332 . 334 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 335 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 336 May 2017, . 338 8.2. Informative References 340 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 341 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 342 February 2012, . 344 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 345 "Internet Exchange BGP Route Server", RFC 7947, 346 DOI 10.17487/RFC7947, September 2016, 347 . 349 Authors' Addresses 351 Thomas King 352 DE-CIX Management GmbH 353 Lichtstrasse 43i 354 Cologne 50825 355 DE 357 Email: thomas.king@de-cix.net 359 Christoph 360 DE-CIX Management GmbH 361 Lichtstrasse 43i 362 Cologne 50825 363 DE 365 Email: christhoph.dietzel@de-cix.net 367 Daniel Kopp 368 DE-CIX Management GmbH 369 Lichtstrasse 43i 370 Cologne 50825 371 DE 373 Email: daniel.kopp@de-cix.net 375 Aristidis Lambrianidis 376 Amsterdam Internet Exchange 377 Frederiksplein 42 378 Amsterdam 1017 XN 379 NL 381 Email: aristidis.lambrianidis@ams-ix.net 382 Arnaud Fenioux 383 France-IX 384 88 Avenue Des Ternes 385 Paris 75017 386 FR 388 Email: ietf@afenioux.fr