--- 1/draft-ietf-sidr-bgpsec-ops-08.txt 2016-06-15 18:15:53.970443081 -0700 +++ 2/draft-ietf-sidr-bgpsec-ops-09.txt 2016-06-15 18:15:53.990443575 -0700 @@ -1,18 +1,18 @@ Network Working Group R. Bush Internet-Draft Internet Initiative Japan -Intended status: Best Current Practice June 6, 2016 -Expires: December 8, 2016 +Intended status: Best Current Practice June 16, 2016 +Expires: December 18, 2016 BGPsec Operational Considerations - draft-ietf-sidr-bgpsec-ops-08 + draft-ietf-sidr-bgpsec-ops-09 Abstract Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed. Requirements Language @@ -30,21 +30,21 @@ 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 http://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 December 8, 2016. + This Internet-Draft will expire on December 18, 2016. Copyright Notice Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -55,38 +55,38 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . 3 4. AS/Router Certificates . . . . . . . . . . . . . . . . . . . 3 5. Within a Network . . . . . . . . . . . . . . . . . . . . . . 3 6. Considerations for Edge Sites . . . . . . . . . . . . . . . . 4 - 7. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 4 + 7. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 5 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 12.2. Informative References . . . . . . . . . . . . . . . . . 8 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction BGPsec, [I-D.ietf-sidr-bgpsec-overview], is a new protocol with many operational considerations. It is expected to be deployed incrementally over a number of years. As core BGPsec-capable routers may require large memory and/or modern CPUs, it is thought that origin validation based on the RPKI, [RFC6811], will occur over the - next twp to three years and that BGPsec will start to deploy well + next two to three years and that BGPsec will start to deploy well after that. BGPsec relies on widespread propagation of the Resource Public Key Infrastructure (RPKI) [RFC6480]. How the RPKI is distributed and maintained globally and within an operator's infrastructure may be different for BGPsec than for origin validation. BGPsec need be spoken only by an AS's eBGP speaking, AKA border, routers, and is designed so that it can be used to protect announcements which are originated by small edge routers. This has @@ -165,26 +165,33 @@ received across a trust boundary. 6. Considerations for Edge Sites An edge site which does not provide transit and trusts its upstream(s) SHOULD only originate a signed prefix announcement and need not validate received announcements. BGPsec protocol capability negotiation provides for a speaker signing the data it sends without being able to accept signed data. Thus a - smallish edge router may hold only its own signing key(s), sign it's + smallish edge router may hold only its own signing key(s), sign its announcements, but not receive signed announcements and therefore not need to deal with the majority of the RPKI. Thus such routers CPU, RAM, and crypto needs are trivial and additional hardware should not be needed. + Operators might need to use hardware with limited resources. In such + cases, BGPsec protocol capability negotiation allows for a resource + constrained edge router to hold only its own signing key(s) and sign + its announcements, but not receive signed announcements. Therefore, + the router would not have to deal with the majority of the RPKI, + potentially saving the need for additional hardware. + As the vast majority (84%) of ASs are stubs, and they announce the majority of prefixes, this allows for simpler and less expensive incremental deployment. It may also mean that edge sites concerned with routing security will be attracted to upstreams which support BGPsec. 7. Routing Policy Unlike origin validation based on the RPKI, BGPsec marks a received announcement as Valid or Invalid, there is no explicit NotFound @@ -265,22 +272,22 @@ or router may have different data about a particular prefix or router than another cache or router. There is no 'fix' for this, it is the nature of distributed data with distributed caches. Operators who manage certificates SHOULD have RPKI GhostBuster Records (see [RFC6493]), signed indirectly by End Entity certificates, for those certificates on which others' routing depends for certificate and/or ROA validation. Operators should be aware of impending algorithm transitions, which - will be rare and slow-paced, see see [RFC6916]. They should work - with their vendors to ensure support for new algorithms. + will be rare and slow-paced, see [RFC6916]. They should work with + their vendors to ensure support for new algorithms. As a router must evaluate certificates and ROAs which are time dependent, routers' clocks MUST be correct to a tolerance of approximately an hour. If a router has reason to believe its clock is seriously incorrect, e.g. it has a time earlier than 2011, it SHOULD NOT attempt to validate incoming updates. It SHOULD defer validation until it believes it is within reasonable time tolerance.