| < draft-ietf-sidr-route-server-rpki-light-00.txt | draft-ietf-sidr-route-server-rpki-light-01.txt > | |||
|---|---|---|---|---|
| Network Working Group T. King | Network Working Group T. King | |||
| Internet-Draft D. Kopp | Internet-Draft D. Kopp | |||
| Intended status: Standards Track DE-CIX | Intended status: Standards Track DE-CIX | |||
| Expires: December 10, 2016 A. Lambrianidis | Expires: June 11, 2017 A. Lambrianidis | |||
| AMS-IX | AMS-IX | |||
| A. Fenioux | A. Fenioux | |||
| France-IX | France-IX | |||
| June 8, 2016 | December 8, 2016 | |||
| Signaling Prefix Origin Validation Results from a Route-Server to Peers | Signaling Prefix Origin Validation Results from a Route-Server to Peers | |||
| draft-ietf-sidr-route-server-rpki-light-00 | draft-ietf-sidr-route-server-rpki-light-01 | |||
| Abstract | Abstract | |||
| This document defines the usage of the BGP Prefix Origin Validation | This document defines the usage of the BGP Prefix Origin Validation | |||
| State Extended Community [I-D.ietf-sidr-origin-validation-signaling] | State Extended Community [I-D.ietf-sidr-origin-validation-signaling] | |||
| to signal prefix origin validation results from a route-server to its | to signal prefix origin validation results from a route-server to its | |||
| peers. Upon reception of prefix origin validation results peers can | peers. Upon reception of prefix origin validation results peers can | |||
| use this information in their local routing decision process. | use this information in their local routing decision process. | |||
| Requirements Language | Requirements Language | |||
| skipping to change at page 1, line 46 ¶ | skipping to change at page 1, line 46 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on December 10, 2016. | This Internet-Draft will expire on June 11, 2017. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 2, line 34 ¶ | skipping to change at page 2, line 34 ¶ | |||
| Server to Peers . . . . . . . . . . . . . . . . . . . . . . . 3 | Server to Peers . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Operational Recommendations . . . . . . . . . . . . . . . . . 3 | 3. Operational Recommendations . . . . . . . . . . . . . . . . . 3 | |||
| 3.1. Local Routing Decision Process . . . . . . . . . . . . . 3 | 3.1. Local Routing Decision Process . . . . . . . . . . . . . 3 | |||
| 3.2. Route-Server Receiving the BGP Prefix Origin Validation | 3.2. Route-Server Receiving the BGP Prefix Origin Validation | |||
| State Extended Community . . . . . . . . . . . . . . . . 3 | State Extended Community . . . . . . . . . . . . . . . . 3 | |||
| 3.3. Information about Validity of a BGP Prefix Origin Not | 3.3. Information about Validity of a BGP Prefix Origin Not | |||
| Available at a Route-Server . . . . . . . . . . . . . . . 4 | Available at a Route-Server . . . . . . . . . . . . . . . 4 | |||
| 3.4. Error Handling at Peers . . . . . . . . . . . . . . . . . 4 | 3.4. Error Handling at Peers . . . . . . . . . . . . . . . . . 4 | |||
| 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | |||
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 | |||
| 6.2. Informative References . . . . . . . . . . . . . . . . . 5 | 6.2. Informative References . . . . . . . . . . . . . . . . . 5 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 1. Introduction | 1. Introduction | |||
| RPKI-based prefix origin validation [RFC6480] can be a significant | RPKI-based prefix origin validation [RFC6480] can be a significant | |||
| operational burden for BGP peers to implement and adopt. In order to | operational burden for BGP peers to implement and adopt. In order to | |||
| boost acceptance and usage of prefix origin validation and ultimately | boost acceptance and usage of prefix origin validation and ultimately | |||
| increase the security of the Internet routing system, IXPs may | increase the security of the Internet routing system, IXPs may | |||
| provide RPKI-based prefix origin validation at the route-server | provide RPKI-based prefix origin validation at the route-server | |||
| [I-D.ietf-idr-ix-bgp-route-server]. The result of this prefix origin | [I-D.ietf-idr-ix-bgp-route-server]. The result of this prefix origin | |||
| validation is signaled to peers by using the BGP Prefix Origin | validation is signaled to peers by using the BGP Prefix Origin | |||
| skipping to change at page 4, line 40 ¶ | skipping to change at page 4, line 40 ¶ | |||
| None. | None. | |||
| 5. Security Considerations | 5. Security Considerations | |||
| A route-server could be misused to spread malicious prefix origin | A route-server could be misused to spread malicious prefix origin | |||
| validation results. However, peers have to trust the route-server | validation results. However, peers have to trust the route-server | |||
| anyway as it collects and redistributes BGP routing information to | anyway as it collects and redistributes BGP routing information to | |||
| other peers. | other peers. | |||
| To countermeasure DDoS attacks, it is widespread to provide | ||||
| blackholing services at IXPs (see RFC 7999 [RFC7999]). Peers are | ||||
| using blackholing to drop traffic, typically by announcing smaller | ||||
| subnets, which are unter attack. Assuming, for practical reasons, | ||||
| peers will not reflect these announcements in their ROAs. In such | ||||
| situations, the RPKI validation status for a prefixes, providing a | ||||
| ROA, would be "Invalid". Given that other peers evaluating the RPKI | ||||
| status, this leads to a degradation of prefixes being blackholed. | ||||
| It's recommended that peers validating the RPKI status use a adopted | ||||
| classification for such prefixes. | ||||
| The introduction of a mechanisms described in this document does not | The introduction of a mechanisms described in this document does not | |||
| pose a new class of attack vectors to the relationship between route- | pose a new class of attack vectors to the relationship between route- | |||
| servers and peers. | servers and peers. | |||
| 6. References | 6. References | |||
| 6.1. Normative References | 6.1. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| skipping to change at page 5, line 14 ¶ | skipping to change at page 5, line 27 ¶ | |||
| [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended | [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended | |||
| Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, | Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, | |||
| February 2006, <http://www.rfc-editor.org/info/rfc4360>. | February 2006, <http://www.rfc-editor.org/info/rfc4360>. | |||
| [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. | [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. | |||
| Austein, "BGP Prefix Origin Validation", RFC 6811, | Austein, "BGP Prefix Origin Validation", RFC 6811, | |||
| DOI 10.17487/RFC6811, January 2013, | DOI 10.17487/RFC6811, January 2013, | |||
| <http://www.rfc-editor.org/info/rfc6811>. | <http://www.rfc-editor.org/info/rfc6811>. | |||
| [RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G. | ||||
| Hankins, "BLACKHOLE Community", RFC 7999, | ||||
| DOI 10.17487/RFC7999, October 2016, | ||||
| <http://www.rfc-editor.org/info/rfc7999>. | ||||
| 6.2. Informative References | 6.2. Informative References | |||
| [I-D.ietf-idr-ix-bgp-route-server] | [I-D.ietf-idr-ix-bgp-route-server] | |||
| Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, | Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, | |||
| "Internet Exchange BGP Route Server", draft-ietf-idr-ix- | "Internet Exchange BGP Route Server", draft-ietf-idr-ix- | |||
| bgp-route-server-10 (work in progress), April 2016. | bgp-route-server-12 (work in progress), June 2016. | |||
| [I-D.ietf-sidr-origin-validation-signaling] | [I-D.ietf-sidr-origin-validation-signaling] | |||
| Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. | Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. | |||
| Bush, "BGP Prefix Origin Validation State Extended | Bush, "BGP Prefix Origin Validation State Extended | |||
| Community", draft-ietf-sidr-origin-validation-signaling-07 | Community", draft-ietf-sidr-origin-validation-signaling-07 | |||
| (work in progress), November 2015. | (work in progress), November 2015. | |||
| [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support | [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support | |||
| Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, | Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, | |||
| February 2012, <http://www.rfc-editor.org/info/rfc6480>. | February 2012, <http://www.rfc-editor.org/info/rfc6480>. | |||
| End of changes. 9 change blocks. | ||||
| 8 lines changed or deleted | 24 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||