idnits 2.17.1 draft-ymbk-sidrops-ov-signal-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 : ---------------------------------------------------------------------------- ** 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 (June 26, 2018) is 2129 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 130, but not defined 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 R. Bush 3 Internet-Draft Internet Initiative Japan 4 Intended status: Standards Track K. Patel 5 Expires: December 28, 2018 Arrcus 6 June 26, 2018 8 Origin Validation Signaling 9 draft-ymbk-sidrops-ov-signal-00 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 December 28, 2018. 47 Copyright Notice 49 Copyright (c) 2018 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." 76 We use the term "Sender" to refer to the router announcing routes to 77 the device evaluating the Origin Validation of the announcements. 78 Beware that the Sender receives signaling back from the Evaluator, 79 which can be somewhat confusing. 81 We use the term "Evaluator" to describe the device receiving routing 82 announcements from senders, applying RPKI-based Origin Validation, 83 and possibly signaling route Invalidity back to the sender(s). 85 2. Suggested Reading 87 It is assumed that the reader understands BGP, [RFC4271], the RPKI, 88 [RFC6480], RPKI-based Prefix Validation, [RFC6811], and the BGP 89 Prefix Origin Validation State Extended Community as described in 90 [RFC8097]. 92 3. Trust Boundary 94 As a general rule, we discourage 'outsourcing trust,' i.e. letting 95 others make security decisions for us. But there are operational 96 environments with a somewhat wide trust boundary, a single operator's 97 PoP for example. 99 As described in [RFC7115], a PoP might have a single RPKI Cache, 100 hence all trust is outsourced to it. So it is reasonable that 101 routers in that PoP could share Origin Validation results instead of 102 each doing full validation. 104 An [RFC4456] Route Reflector Cluster is an obvious candidate for this 105 approach. The route reflector(s) would perform Origin Validation and 106 signal an Invalid route back to the sending client. 108 [RFC8097] provides the obvious signaling mechanism, the BGP Prefix 109 Origin Validation State Extended Community. The device performing OV 110 SHOULD signal back to the sender by announcing the offending prefix 111 marked with the extended community with the last octet having the 112 value 2, indicating an Invalid route. 114 4. The OV Signaling Capability 116 Unfortunately, the router sending the Invalid announcement is not 117 normally expecting to receive it back. Therefore, both parties MUST 118 agree on this feature by using a BGP Capability. 120 To advertise the OV Signaling Capability to a peer, a BGP speaker 121 uses BGP Capabilities Advertisement [RFC5492]. By advertising the OV 122 Signaling Capability to a peer, a BGP speaker conveys that it is able 123 to send, receive, and properly handle OV Signaling using the BGP 124 Prefix Origin Validation State Extended Community. 126 A peer which does not advertise this capability MUST NOT send OV 127 Signaling, and BGP OV Signaling MUST NOT be sent to it. 129 The OV Signaling Capability is a new BGP Capability [RFC5492] defined 130 with Capability code [TBD] and Capability length 0. 132 5. Recommended Action 134 This section assumes that the OV Signaling Capability has been 135 negotiated by the sending and receiving routers. 137 An Evaluating device which performs Origin Validation on a route 138 received from a capable sender and finds a prefix with a particular 139 origin AS to be Invalid (in the [RFC6811] sense), SHOULD announce 140 that prefix back to the sending router from which it was received 141 with the Invalid origin AS and the addition of the Prefix Origin 142 Validation State Extended Community with the last octet being 2. 144 A sender receiving the returned prefix announcement so marked SHOULD 145 withdraw all routes it had announced to that prefix with the Invalid 146 origin AS. This includes withdrawing any instances of additional 147 paths with that origin AS advertised under [RFC7911]. 149 For a sender to properly evaluate the community returned by the 150 evaluator, the sender MUST recognize the community before loop 151 detection. This is a change to the Phase 2 Route Selection process 152 of [RFC4271] Section 9.1.2. 154 If a sender originally received the Invalid route from an evaluator 155 within its trust boundary with which it has negotiated the OV 156 Signaling Capability, it MAY also propagate that signal to the 157 original sender. 159 6. Security Considerations 161 As with all communities which cause semantic change, this use of the 162 BGP Prefix Origin Validation State Extended Community may be abused 163 as an attack vector. Therefore the operator MUST configure their 164 incoming external border to strip the community. 166 As the BGP sessions are already established using whatever channel 167 security the operator chooses or not, this change specifies no 168 additional channel or object security. 170 Outsourcing security is usually considered bad policy. 171 Section Section 3 above discusses why that is not a problem here. 173 Otherwise, this document does not create security considerations 174 beyond those of [RFC6811]. 176 7. IANA Considerations 178 This document requests the IANA assign the "OV Signaling Capability" 179 to the BGP Capabilities described in Section 2.1 in the "Capability 180 Codes" registry's "IETF Review" range [RFC8126].. This document is 181 the reference for the new capability. 183 8. Acknowledgments 185 Thanks to Rob Austein for useful security snark. 187 9. References 189 9.1. Normative References 191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 192 Requirement Levels", BCP 14, RFC 2119, 193 DOI 10.17487/RFC2119, March 1997, 194 . 196 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 197 Reflection: An Alternative to Full Mesh Internal BGP 198 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 199 . 201 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 202 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 203 2009, . 205 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 206 Austein, "BGP Prefix Origin Validation", RFC 6811, 207 DOI 10.17487/RFC6811, January 2013, 208 . 210 [RFC7115] Bush, R., "Origin Validation Operation Based on the 211 Resource Public Key Infrastructure (RPKI)", BCP 185, 212 RFC 7115, DOI 10.17487/RFC7115, January 2014, 213 . 215 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 216 "Advertisement of Multiple Paths in BGP", RFC 7911, 217 DOI 10.17487/RFC7911, July 2016, 218 . 220 [RFC8097] Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. 221 Bush, "BGP Prefix Origin Validation State Extended 222 Community", RFC 8097, DOI 10.17487/RFC8097, March 2017, 223 . 225 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 226 Writing an IANA Considerations Section in RFCs", BCP 26, 227 RFC 8126, DOI 10.17487/RFC8126, June 2017, 228 . 230 9.2. Informative References 232 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 233 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 234 DOI 10.17487/RFC4271, January 2006, 235 . 237 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 238 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 239 February 2012, . 241 Authors' Addresses 243 Randy Bush 244 Internet Initiative Japan 245 5147 Crystal Springs 246 Bainbridge Island, Washington 98110 247 US 249 Email: randy@psg.com 251 Keyur Patel 252 Arrcus 253 2077 Gateway Place, Suite #250 254 San Jose, CA 95119 255 United States of America 257 Email: keyur@arrcus.com