Internet-Draft | RPKI-Based Policy Without Route Refresh | November 2021 |
Bush, et al. | Expires 19 May 2022 | [Page] |
- Workgroup:
- Network Working Group
- Internet-Draft:
- draft-ymbk-sidrops-rov-no-rr-02
- Updates:
- 8481 (if approved)
- Published:
- Intended Status:
- Standards Track
- Expires:
RPKI-Based Policy Without Route Refresh
Abstract
A BGP Speaker performing RPKI-based policy should not issue Route Refresh to its neighbors when receiving new RPKI data. A method for avoiding doing so is described.¶
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Status of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 May 2022.¶
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
1. Introduction
Memory constraints in early routers caused classic [RFC4271] BGP implementations to not keep a full Adj-RIB-In (Sec. 1.1). When doing RPKI-based Route Origin Validation ([RFC6811] and [RFC8481]), and similar RPKI-based policy, if such a BGP speaker receives new RPKI data, it might not have kept paths previously marked as Invalid etc. Such an implementation must then request a Route Refresh [RFC7313] from its neighbors to recover the paths which might be covered by these new RPKI data. This will be perceived as rude by those neighbors as it passes a serious resource burden on to them. This document recommends implementations keep but mark paths affected by RPKI-based policy so Route Refresh is no longer needed.¶
3. ROV Experience
As Route Origin Validation dropping Invalids has depoyed, some router implementations have been found which, when receiving new RPKI data (VRPs, see [I-D.ietf-sidrops-8210bis]) issue a BGP Route Refresh [RFC7313] to all sending BGP peers so that it can reevaluate the received paths aginst the new data.¶
In actual deployment this has been found to be very destructive, transferring a serious resource burden to the unsuspecting peers. In reaction, RPKI based Route Origin Validation (ROV) has been turned off; and there have been actual de-peerings.¶
As RPKI registration and ROA creation have steadily increased, this problem has increased, not just proportionally, but on the order of the in-degree of ROV implementing routers. As ASPA ([I-D.ietf-sidrops-aspa-verification]) becomes used, the problem will increase.¶
4. Keeping Partial Adj-RIB-In Data
Ameliorating this problem by keeping a full Adj-RIB-In can be a problem for resource constrained routers. In reality, only some data need be retained.¶
When RPKI data cause one or more paths to be dropped, withdrawn, or merely not chosn as best path due to RPKI-based policy (ROV, ASPA, etc.), those paths MUST be saved and marked so that later VRPs can reevaluate them against then current policy.¶
As storing these paths could cause problems in resource constrained devices, there MUST be a knob allowing operator control of this feature. Such a knob MUST NOT be per peer, as this could cause inconsistent behavior.¶
5. Operational Recommendations
Routers MUST either keep the full Adj-RIB-In or implement the specification in Section 4.¶
Operators deploying ROV and/or other RPKI based policies SHOULD ensure that the router implementation is not causing unnecessary Route Refresh requests to neighbors.¶
If the router does not implement these recommendations, the operator SHOULD enable the vendor's knob to keep the full Adj-RIB-In, sometimes referred to as "soft reconfiguration inbound". The operator should then measure to ensure that there are no unnecessary Route Refresh requests sent to neighbors.¶
If the router has insufficient resources to support this, it MUST not be used for Route Origin Validation. I.e. the knob in Section 4 should only be used in very well known and controlled circumstances.¶
Internet Exchange Points which provide [RFC7947] Route Servers should be aware that some members could be causing an undue Route Refresh load on the Route Servers and take appropriate administrative and/or technical measures.¶
6. Security Considerations
This document describes a denial of service which Route Origin Validation or other RPKI policy may place on a BGP neighbor, and describes how it may be ameliorated.¶
Otherwise, this document adds no additional security considerations to those already described by the referenced documents.¶
7. IANA Considerations
None¶
8. Acknowledgements
The authors wish to thank Ben Maddison and Nick Hilliard.¶
9. References
9.1. Normative References
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- [RFC4271]
- Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, , <https://www.rfc-editor.org/info/rfc4271>.
- [RFC7313]
- Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced Route Refresh Capability for BGP-4", RFC 7313, DOI 10.17487/RFC7313, , <https://www.rfc-editor.org/info/rfc7313>.
- [RFC8174]
- Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References
- [I-D.ietf-sidrops-8210bis]
- Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2", Work in Progress, Internet-Draft, draft-ietf-sidrops-8210bis-03, , <https://www.ietf.org/archive/id/draft-ietf-sidrops-8210bis-03.txt>.
- [I-D.ietf-sidrops-aspa-verification]
- Azimov, A., Bogomazov, E., Bush, R., Patel, K., and J. Snijders, "Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-verification-08, , <https://www.ietf.org/archive/id/draft-ietf-sidrops-aspa-verification-08.txt>.
- [RFC6480]
- Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, , <https://www.rfc-editor.org/info/rfc6480>.
- [RFC6482]
- Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, , <https://www.rfc-editor.org/info/rfc6482>.
- [RFC6811]
- Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, , <https://www.rfc-editor.org/info/rfc6811>.
- [RFC7947]
- Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, DOI 10.17487/RFC7947, , <https://www.rfc-editor.org/info/rfc7947>.
- [RFC8481]
- Bush, R., "Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)", RFC 8481, DOI 10.17487/RFC8481, , <https://www.rfc-editor.org/info/rfc8481>.