idnits 2.17.1 draft-ietf-sidrops-route-server-rpki-light-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8097]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 10, 2017) is 2572 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: 'RFC4360' is defined on line 250, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 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 D. Kopp 4 Intended status: Standards Track DE-CIX 5 Expires: October 12, 2017 A. Lambrianidis 6 AMS-IX 7 A. Fenioux 8 France-IX 9 April 10, 2017 11 Signaling Prefix Origin Validation Results from a Route Server to Peers 12 draft-ietf-sidrops-route-server-rpki-light-02 14 Abstract 16 This document defines the usage of the BGP Prefix Origin Validation 17 State Extended Community [RFC8097] to signal prefix origin validation 18 results from a route server to its peers. Upon reception of prefix 19 origin validation results peers can use this information in their 20 local routing decision process. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 26 be interpreted as described in [RFC2119] only when they appear in all 27 upper case. They may also appear in lower or mixed case as English 28 words, without normative meaning. 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 http://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 October 12, 2017. 47 Copyright Notice 49 Copyright (c) 2017 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 (http://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. BGP Prefix Origin Validation State Utilized at Route-Servers 3 66 3. Signaling Prefix Origin Validation Results from a Route 67 Server to Peers . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Operational Recommendations . . . . . . . . . . . . . . . . . 4 69 4.1. Local Routing Decision Process . . . . . . . . . . . . . 4 70 4.2. Route Server Receiving the BGP Prefix Origin Validation 71 State Extended Community . . . . . . . . . . . . . . . . 4 72 4.3. Information about Validity of a BGP Prefix Origin Not 73 Available at a Route-Server . . . . . . . . . . . . . . . 5 74 4.4. Error Handling at Peers . . . . . . . . . . . . . . . . . 5 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 79 7.2. Informative References . . . . . . . . . . . . . . . . . 6 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 RPKI-based prefix origin validation [RFC6480] can be a significant 85 operational burden for BGP peers to implement and adopt. In order to 86 boost acceptance and usage of prefix origin validation and ultimately 87 increase the security of the Internet routing system, IXPs may 88 provide RPKI-based prefix origin validation at the route server 89 [RFC7947]. The result of this prefix origin validation is signaled 90 to peers by using the BGP Prefix Origin Validation State Extended 91 Community as introduced in [RFC8097]. 93 Peers receiving the prefix origin validation result from the route 94 server(s) can use this information in their local routing decision 95 process for acceptance, rejection, preference, or other traffic 96 engineering purposes of a particular route. 98 2. BGP Prefix Origin Validation State Utilized at Route-Servers 100 A route server that is aware of a BGP Prefix Origin Validation state 101 for a certain route can handle this information in one of the 102 following modes of operation: 104 Simple Tagging: The prefix origin validation state is tagged to the 105 route as described in Section 3. 106 This mode of operation is like the tradional way route servers 107 work, however, the prefix origin validation state information is 108 additionally available for peers. 110 Dropping and Tagging: Routes for which the prefix origin validation 111 state is "invalid" (according to [RFC6811]) are dropped by the 112 route server. Routes which show a prefix origin validation state 113 of "not found" and "valid" (according to [RFC6811]) are tagged 114 accordingly to Section 3. 115 Security is higher rated than questionable reachability of a 116 prefix by this mode of operation. 118 Prioritizing and Tagging: If the route server learned for a 119 particular prefix more than one route it removes firstly the set 120 of "invalid" routes and secondly the "not found" routes unless 121 the set of routes is empty. Based on the set of routes left over 122 the BGP best path section algorithm is executed. The selected 123 route is marked accordinly to Section 3. 124 The BGP best path selection algorithm is changed by this mode of 125 operation in such a way that "valid" routes are preferred even if 126 they are unfavorable by the traditional best path selection 127 algorithm. This puts prefix origin validation on top of the best 128 path selection. 130 A route server MUST support the Simple Tagging mode of operation. 131 Other modes of operation are OPTIONAL. The mode of operation MAY be 132 configured by the route server operator for a route server instance 133 or for each BGP session with a peer seperately. 135 These mode of operations might be used in combination with [RFC7911] 136 in order to allow a peer to receive all routes and take the routing 137 decision by itself. 139 3. Signaling Prefix Origin Validation Results from a Route Server to 140 Peers 142 The BGP Prefix Origin Validation State Extended Community (as defined 143 in [RFC8097]) is utilized for signaling prefix origin validation 144 result from a route server to peers. 146 [RFC8097] proposes an encoding of the prefix origin validation result 147 [RFC6811] as follows: 149 +-------+-----------------------------+ 150 | Value | Meaning | 151 +-------+-----------------------------+ 152 | 0 | Lookup result = "valid" | 153 | 1 | Lookup result = "not found" | 154 | 2 | Lookup result = "invalid" | 155 +-------+-----------------------------+ 157 Table 1 159 This encoding is re-used. Route servers providing RPKI-based prefix 160 origin validation set the validation state according to the prefix 161 origin validation result (see [RFC6811]). 163 4. Operational Recommendations 165 4.1. Local Routing Decision Process 167 A peer receiving prefix origin validation results from the route 168 server MAY use the information in its own local routing decision 169 process. The local routing decision process SHOULD apply to the 170 rules as described in section 5 [RFC6811]. 172 A peer receiving a prefix origin validation result from the route 173 server MAY redistribute this information within its own AS. 175 4.2. Route Server Receiving the BGP Prefix Origin Validation State 176 Extended Community 178 An IXP route server receiving routes from its peers containing the 179 BGP Prefix Origin Validation State Extended Community MUST remove the 180 extended community before the route is re-distributed to its peers. 181 This is required regardless of whether the route server is executing 182 prefix origin validation or not. 184 Failure to do so would allow opportunistic peers to advertise routes 185 tagged with arbitrary prefix origin validation results via a route 186 server, influencing maliciously the decision process of other route 187 server peers. 189 4.3. Information about Validity of a BGP Prefix Origin Not Available at 190 a Route-Server 192 In case information about the validity of a BGP prefix origin is not 193 available at the route server (e.g., error in the ROA cache, CPU 194 overload) the route server MUST NOT add the BGP Prefix Origin 195 Validation State Extended Community to the route. 197 4.4. Error Handling at Peers 199 A route sent by a route server SHOULD only contain none or one BGP 200 Prefix Origin Validation State Extended Community. 202 A peer receiving a route from a route server containing more than one 203 BGP Prefix Origin Validation State Extended Community SHOULD only 204 consider the largest value (as described in Table 1) in the 205 validation result field and disregard the other values. Values 206 larger than two in the validation result field MUST be disregarded. 208 5. IANA Considerations 210 None. 212 6. Security Considerations 214 All security considerations described in RFC RFC6811 [RFC6811] fully 215 apply to this document. 217 Additionally, threat agents polluting ROA cache server(s) run by IXP 218 operators could cause significant operational impact, since multiple 219 route server clients could be affected. Peers should be vigilant as 220 to the integrity and authenticity of the origin validation results, 221 as they are provided by a third party, namely the IXP operator 222 hosting both the route server as well as any ROA cache server(s). 224 Therefore, a route server could be misused to spread malicious prefix 225 origin validation results. However, peers already trust the route 226 server for the collection, filtering (e.g. IRR database filtering), 227 and redistribution of BGP routing information to other peers. So, no 228 change in the trust level is needed for this proposal. 230 To facilitate trust and help with peers establishing appropriate 231 controls in mitigating the risks mentioned above, IXPs SHOULD provide 232 out-of-band means for peers to ensure that the ROA validation process 233 has not been compromised or corrupted. 235 While beeing under DDoS attacks, it is a common practice for peers 236 connected to an IXP to make use of blackholing services (see 237 [RFC7999]). Peers are using blackholing to drop traffic, typically 238 by announcing a more specific prefix, which is under attack. A peer 239 SHOULD make sure that this prefix is covered by an appropriate ROA. 241 7. References 243 7.1. Normative References 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, 247 DOI 10.17487/RFC2119, March 1997, 248 . 250 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 251 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 252 February 2006, . 254 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 255 Austein, "BGP Prefix Origin Validation", RFC 6811, 256 DOI 10.17487/RFC6811, January 2013, 257 . 259 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 260 "Advertisement of Multiple Paths in BGP", RFC 7911, 261 DOI 10.17487/RFC7911, July 2016, 262 . 264 [RFC8097] Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. 265 Bush, "BGP Prefix Origin Validation State Extended 266 Community", RFC 8097, DOI 10.17487/RFC8097, March 2017, 267 . 269 7.2. Informative References 271 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 272 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 273 February 2012, . 275 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 276 "Internet Exchange BGP Route Server", RFC 7947, 277 DOI 10.17487/RFC7947, September 2016, 278 . 280 [RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G. 281 Hankins, "BLACKHOLE Community", RFC 7999, 282 DOI 10.17487/RFC7999, October 2016, 283 . 285 Authors' Addresses 287 Thomas King 288 DE-CIX Management GmbH 289 Lichtstrasse 43i 290 Cologne 50825 291 DE 293 Email: thomas.king@de-cix.net 295 Daniel Kopp 296 DE-CIX Management GmbH 297 Lichtstrasse 43i 298 Cologne 50825 299 DE 301 Email: daniel.kopp@de-cix.net 303 Aristidis Lambrianidis 304 Amsterdam Internet Exchange 305 Frederiksplein 42 306 Amsterdam 1017 XN 307 NL 309 Email: aristidis.lambrianidis@ams-ix.net 311 Arnaud Fenioux 312 France-IX 313 88 Avenue Des Ternes 314 Paris 75017 315 FR 317 Email: afenioux@franceix.net