draft-ietf-sidr-origin-ops-10.txt   draft-ietf-sidr-origin-ops-11.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Internet Initiative Japan Internet-Draft Internet Initiative Japan
Intended status: BCP July 10, 2011 Intended status: BCP October 9, 2011
Expires: January 11, 2012 Expires: April 11, 2012
RPKI-Based Origin Validation Operation RPKI-Based Origin Validation Operation
draft-ietf-sidr-origin-ops-10 draft-ietf-sidr-origin-ops-11
Abstract Abstract
Deployment of RPKI-based BGP origin validation has many operational Deployment of RPKI-based BGP origin validation has many operational
considerations. This document attempts to collect and present them. considerations. This document attempts to collect and present them.
It is expected to evolve as RPKI-based origin validation is deployed It is expected to evolve as RPKI-based origin validation is deployed
and the dynamics are better understood. and the dynamics are better understood.
Requirements Language Requirements Language
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 January 11, 2012. This Internet-Draft will expire on April 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . 3 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . 3
3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . . 3 3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . . 3
4. Within a Network . . . . . . . . . . . . . . . . . . . . . . . 5 4. Within a Network . . . . . . . . . . . . . . . . . . . . . . . 5
5. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
RPKI-based origin validation relies on widespread deployment of the RPKI-based origin validation relies on widespread deployment of the
Resource Public Key Infrastructure (RPKI) [I-D.ietf-sidr-arch]. How Resource Public Key Infrastructure (RPKI) [I-D.ietf-sidr-arch]. How
the RPKI is distributed and maintained globally is a serious concern the RPKI is distributed and maintained globally is a serious concern
from many aspects. from many aspects.
The global RPKI is in very initial stages of deployment, there is no The global RPKI is in very initial stages of deployment, there is no
skipping to change at page 5, line 18 skipping to change at page 5, line 18
Operators SHOULD be conservative in use of max length in ROAs. E.g., Operators SHOULD be conservative in use of max length in ROAs. E.g.,
if a prefix will have only a few sub-prefixes announced, multiple if a prefix will have only a few sub-prefixes announced, multiple
ROAs for the specific announcements SHOULD be used as opposed to one ROAs for the specific announcements SHOULD be used as opposed to one
ROA with a long max length. ROA with a long max length.
An environment where private address space is announced in eBGP the An environment where private address space is announced in eBGP the
operator MAY have private RPKI objects which cover these private operator MAY have private RPKI objects which cover these private
spaces. This will require a trust anchor created and owned by that spaces. This will require a trust anchor created and owned by that
environment, see [I-D.ietf-sidr-ltamgmt]. environment, see [I-D.ietf-sidr-ltamgmt].
Operators owning prefix P should issue ROAs for all ASs which may
announce P.
Operators issuing ROAs may have customers which announce their own Operators issuing ROAs may have customers which announce their own
prefixes and ASs into global eBGP but who do not wish to go though prefixes and ASs into global eBGP but who do not wish to go though
the work to manage the relevant certificates and ROAs. Operators the work to manage the relevant certificates and ROAs. Operators
SHOULD offer to provision the RPKI data for these customers just as SHOULD offer to provision the RPKI data for these customers just as
they provision many other things for them. they provision many other things for them.
While a an operator using RPKI data MAY choose any polling frequency While a an operator using RPKI data MAY choose any polling frequency
they wish for ensuring they have a fresh RPKI cache. However, if they wish for ensuring they have a fresh RPKI cache. However, if
they use RPKI data as an input to operational routing decisions, they they use RPKI data as an input to operational routing decisions, they
SHOULD ensure local cache freshness at least every four to six hours. SHOULD ensure local cache freshness at least every four to six hours.
skipping to change at page 6, line 38 skipping to change at page 6, line 41
vulnerabilities. E.g. if Local Pref is set depending on validity vulnerabilities. E.g. if Local Pref is set depending on validity
state, be careful that peer community signaling MAY NOT upgrade an state, be careful that peer community signaling MAY NOT upgrade an
Invalid announcement to Valid or better. Invalid announcement to Valid or better.
Announcements with Valid origins SHOULD be preferred over those with Announcements with Valid origins SHOULD be preferred over those with
NotFound or Invalid origins, if the latter are accepted at all. NotFound or Invalid origins, if the latter are accepted at all.
Announcements with NotFound origins SHOULD be preferred over those Announcements with NotFound origins SHOULD be preferred over those
with Invalid origins. with Invalid origins.
Announcements with Invalid origins MAY be used, but SHOULD be less Announcements with Invalid origins SHOULD NOT be used, but MAY be
preferred than those with Valid or NotFound. used to meet special operational needs. In such circumstances, the
announcement SHOULD have a lower preference than that given to Valid
or NotFound.
6. Notes 6. Notes
Like the DNS, the global RPKI presents only a loosely consistent Like the DNS, the global RPKI presents only a loosely consistent
view, depending on timing, updating, fetching, etc. Thus, one cache view, depending on timing, updating, fetching, etc. Thus, one cache
or router may have different data about a particular prefix than or router may have different data about a particular prefix than
another cache or router. There is no 'fix' for this, it is the another cache or router. There is no 'fix' for this, it is the
nature of distributed data with distributed caches. nature of distributed data with distributed caches.
There is some uncertainty about the origin AS of aggregates and what, There is some uncertainty about the origin AS of aggregates and what,
skipping to change at page 7, line 39 skipping to change at page 8, line 4
This document has no IANA Considerations. This document has no IANA Considerations.
9. Acknowledgments 9. Acknowledgments
The author wishes to thank Rob Austein, Steve Bellovin, Steve Kent, The author wishes to thank Rob Austein, Steve Bellovin, Steve Kent,
Pradosh Mohapatra, Chris Morrow, Sandy Murphy, Keyur Patel, Heather Pradosh Mohapatra, Chris Morrow, Sandy Murphy, Keyur Patel, Heather
and Jason Schiller, John Scudder, Kotikalapudi Sriram, Maureen and Jason Schiller, John Scudder, Kotikalapudi Sriram, Maureen
Stillman, and Dave Ward. Stillman, and Dave Ward.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-sidr-arch] [I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-13 (work in Secure Internet Routing", draft-ietf-sidr-arch-13 (work in
progress), May 2011. progress), May 2011.
[I-D.ietf-sidr-ghostbusters] [I-D.ietf-sidr-ghostbusters]
Bush, R., "The RPKI Ghostbusters Record", Bush, R., "The RPKI Ghostbusters Record",
draft-ietf-sidr-ghostbusters-04 (work in progress), draft-ietf-sidr-ghostbusters-14 (work in progress),
June 2011. September 2011.
[I-D.ietf-sidr-ltamgmt] [I-D.ietf-sidr-ltamgmt]
Reynolds, M. and S. Kent, "Local Trust Anchor Management Reynolds, M. and S. Kent, "Local Trust Anchor Management
for the Resource Public Key Infrastructure", for the Resource Public Key Infrastructure",
draft-ietf-sidr-ltamgmt-02 (work in progress), June 2011. draft-ietf-sidr-ltamgmt-02 (work in progress), June 2011.
[I-D.ietf-sidr-pfx-validate] [I-D.ietf-sidr-pfx-validate]
Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", Austein, "BGP Prefix Origin Validation",
draft-ietf-sidr-pfx-validate-01 (work in progress), draft-ietf-sidr-pfx-validate-02 (work in progress),
February 2011. July 2011.
[I-D.ietf-sidr-repos-struct] [I-D.ietf-sidr-repos-struct]
Huston, G., Loomans, R., and G. Michaelson, "A Profile for Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", Resource Certificate Repository Structure",
draft-ietf-sidr-repos-struct-08 (work in progress), draft-ietf-sidr-repos-struct-09 (work in progress),
June 2011. July 2011.
[I-D.ietf-sidr-roa-format] [I-D.ietf-sidr-roa-format]
Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", Origin Authorizations (ROAs)",
draft-ietf-sidr-roa-format-12 (work in progress), draft-ietf-sidr-roa-format-12 (work in progress),
May 2011. May 2011.
[I-D.ietf-sidr-rpki-rtr] [I-D.ietf-sidr-rpki-rtr]
Bush, R. and R. Austein, "The RPKI/Router Protocol", Bush, R. and R. Austein, "The RPKI/Router Protocol",
draft-ietf-sidr-rpki-rtr-13 (work in progress), June 2011. draft-ietf-sidr-rpki-rtr-17 (work in progress),
October 2011.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, February 2010. Scheme", RFC 5781, February 2010.
10.2. Informative References 10.2. Informative References
[I-D.wkumari-deprecate-as-sets] [I-D.wkumari-deprecate-as-sets]
 End of changes. 11 change blocks. 
17 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/