idnits 2.17.1 draft-ymbk-sidrops-ov-signal-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 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 (July 2, 2019) is 1753 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) == Missing Reference: 'TBD' is mentioned on line 137, but not defined ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Internet Initiative Japan & Arrcus 4 Intended status: Standards Track K. Patel 5 Expires: January 3, 2020 Arrcus 6 July 2, 2019 8 Origin Validation Signaling 9 draft-ymbk-sidrops-ov-signal-03 11 Abstract 13 Within a trust boundary, e.g. an operator's PoP, it may be useful to 14 have only a few central devices do full Origin Validation using the 15 Resource Public Key Infrastructure, and be able to signal to an 16 internal sender that a received route fails Origin Validation. E.g. 17 route reflectors could perform Origin Validation for a cluster and 18 signal back to a sending client that it sent an invalid route. 19 Routers capable of sending and receiving this signal can use the 20 extended community described in [RFC8097]. 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 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 3, 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 1. Introduction 64 Within a routing trust boundary, e.g. an operator's Point of Presence 65 (PoP), it may not be desirable or necessary for all routers to 66 perform Origin Validation using the Resource Public Key 67 Infrastructure (RPKI) per [RFC6811]. A good example is route 68 reflectors (see [RFC4456]). 70 An RPKI-enabled device, an Evaluator, SHOULD signal receipt of an 71 Invalid route back to the sender by announcing that route back to the 72 sender marked with the BGP Prefix Origin Validation State Extended 73 Community as defined in [RFC8097] with a last octet having the value 74 2, meaning "Invalid." In the rest of this document we take the 75 liberty of calling it the "community." 77 We use the term "Sender" to refer to the router announcing routes to 78 the device evaluating the Origin Validation of the announcements. 79 Beware that the Sender receives signaling back from the Evaluator, 80 which can be somewhat confusing. 82 We use the term "Evaluator" to describe the device receiving routing 83 announcements from senders, applying RPKI-based Origin Validation, 84 and possibly signaling route Invalidity back to the sender(s). 86 2. Suggested Reading 88 It is assumed that the reader understands BGP, [RFC4271], the RPKI, 89 [RFC6480], RPKI-based Prefix Validation, [RFC6811], and the BGP 90 Prefix Origin Validation State Extended Community as described in 91 [RFC8097]. 93 3. Trust Boundary 95 As a general rule, we discourage 'outsourcing trust,' i.e. letting 96 others make security decisions for us. But there are operational 97 environments with a somewhat wide trust boundary, a single operator's 98 PoP for example. 100 This is not outsourcing trust; this is remote decision making. It is 101 not letting a third party make the decision; it is simply doing it on 102 a different computer. It's trust in a distributed system, where what 103 is (sometimes) called the Policy Decision Point is not the same as 104 the Policy Enforcement Point. 106 As described in [RFC7115], a PoP might have a single RPKI Cache, 107 hence all trust is vested in it. So it is reasonable that routers in 108 that PoP could share Origin Validation results instead of each doing 109 full validation. 111 An [RFC4456] Route Reflector Cluster is an obvious candidate for this 112 approach. The route reflector(s) would perform Origin Validation and 113 signal an Invalid route back to the sending client. 115 [RFC8097] provides the obvious signaling mechanism, the BGP Prefix 116 Origin Validation State Extended Community. The device performing OV 117 SHOULD signal back to the sender by announcing the offending prefix 118 marked with the extended community with the last octet having the 119 value 2, indicating an Invalid route. 121 4. The OV Signaling Capability 123 Unfortunately, the router sending the Invalid announcement is not 124 normally expecting to receive it back. Therefore, both parties MUST 125 agree on this feature by using a BGP Capability [RFC5492]. 127 To advertise the OV Signaling Capability to a peer, a BGP speaker 128 uses BGP Capabilities Advertisement [RFC5492]. By advertising the OV 129 Signaling Capability to a peer, a BGP speaker conveys that it is able 130 to send, receive, and properly handle OV Signaling using the 131 community. 133 A peer which does not advertise this capability MUST NOT send OV 134 Signaling, and BGP OV Signaling MUST NOT be sent to it. 136 The OV Signaling Capability is a new BGP Capability defined with 137 Capability code [TBD] and Capability length 0. 139 5. Recommended Action 141 This section assumes that the OV Signaling Capability has been 142 negotiated by the sending and receiving routers. 144 An Evaluating device which performs Origin Validation on a route 145 received from a capable sender and finds a prefix with a particular 146 origin AS to be Invalid (in the [RFC6811] sense), MUST announce that 147 prefix back to the sending router from which it was received with the 148 Invalid origin AS and the addition of the community with the last 149 octet being 2. 151 A sender receiving the returned prefix announcement so marked MUST 152 treat it the way it would treat an Invalid origin that it itself 153 detected. It should withdraw all routes it had announced to that 154 prefix with the Invalid origin AS. This includes withdrawing any 155 instances of additional paths with that origin AS advertised under 156 [RFC7911]. 158 For a sender to properly evaluate the community returned by the 159 evaluator, the sender MUST recognize the community before loop 160 detection. This is a change to the Phase 2 Route Selection process 161 of [RFC4271] Section 9.1.2. 163 If a sender originally received the Invalid route from an evaluator 164 within its trust boundary with which it has negotiated the OV 165 Signaling Capability, it MAY also propagate that signal to the 166 original sender. 168 6. Security Considerations 170 As with all communities which cause semantic change, this use of the 171 community may be abused as an attack vector. Therefore the operator 172 MUST configure their incoming external border to strip the community. 174 As the BGP sessions are already established using whatever channel 175 security the operator chooses or not, this change specifies no 176 additional channel or object security. Of course, the BGP transport 177 should be protected for integrity and authentication. TCP-MD5 178 [RFC2385] is available on almost all platforms. If more modern 179 methods are available, they should be used. 181 Outsourcing security is usually considered bad policy. 182 Section Section 3 above discusses why that is not really the case 183 here. 185 Otherwise, this document does not create security considerations 186 beyond those of [RFC6811]. 188 7. IANA Considerations 190 This document requests the IANA assign the "OV Signaling Capability" 191 to the BGP Capabilities described in Section 2.1 in the "Capability 192 Codes" registry's "IETF Review" range [RFC8126].. This document is 193 the reference for the new capability. 195 8. Acknowledgments 197 Thanks to Steve Bellovin for a serious security review, and Rob 198 Austein for a useful security snark. 200 9. References 202 9.1. Normative References 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, 206 DOI 10.17487/RFC2119, March 1997, 207 . 209 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 210 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 211 1998, . 213 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 214 Reflection: An Alternative to Full Mesh Internal BGP 215 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 216 . 218 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 219 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 220 2009, . 222 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 223 Austein, "BGP Prefix Origin Validation", RFC 6811, 224 DOI 10.17487/RFC6811, January 2013, 225 . 227 [RFC7115] Bush, R., "Origin Validation Operation Based on the 228 Resource Public Key Infrastructure (RPKI)", BCP 185, 229 RFC 7115, DOI 10.17487/RFC7115, January 2014, 230 . 232 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 233 "Advertisement of Multiple Paths in BGP", RFC 7911, 234 DOI 10.17487/RFC7911, July 2016, 235 . 237 [RFC8097] Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. 238 Bush, "BGP Prefix Origin Validation State Extended 239 Community", RFC 8097, DOI 10.17487/RFC8097, March 2017, 240 . 242 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 243 Writing an IANA Considerations Section in RFCs", BCP 26, 244 RFC 8126, DOI 10.17487/RFC8126, June 2017, 245 . 247 9.2. Informative References 249 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 250 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 251 DOI 10.17487/RFC4271, January 2006, 252 . 254 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 255 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 256 February 2012, . 258 Authors' Addresses 260 Randy Bush 261 Internet Initiative Japan & Arrcus 262 5147 Crystal Springs 263 Bainbridge Island, Washington 98110 264 US 266 Email: randy@psg.com 268 Keyur Patel 269 Arrcus 270 2077 Gateway Place, Suite #250 271 San Jose, CA 95119 272 United States of America 274 Email: keyur@arrcus.com