draft-ietf-sidr-origin-ops-00.txt   draft-ietf-sidr-origin-ops-01.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft IIJ Internet-Draft IIJ
Intended status: BCP January 1, 2011 Intended status: BCP January 9, 2011
Expires: July 5, 2011 Expires: July 13, 2011
RPKI-Based Origin Validation Operations RPKI-Based Origin Validation Operations
draft-ietf-sidr-origin-ops-00 draft-ietf-sidr-origin-ops-01
Abstract Abstract
Deployment of the RPKI-based BGP origin validation has many Deployment of the RPKI-based BGP origin validation has many
operational considerations. This document attempts to collect and operational considerations. This document attempts to collect and
present them. It is expected to evolve as RPKI-based origin present them. It is expected to evolve as RPKI-based origin
validation is deployed and the dynamics are better understood. validation is deployed 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 July 5, 2011. This Internet-Draft will expire on July 13, 2011.
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 3, line 37 skipping to change at page 3, line 37
RPKI-based origin validation has been designed so that, with prudent RPKI-based origin validation has been designed so that, with prudent
local routing policies, there is no liability that normal Internet local routing policies, there is no liability that normal Internet
routing is threatened by unprudent deployment of the global RPKI, see routing is threatened by unprudent deployment of the global RPKI, see
Section 5. Section 5.
2. Suggested Reading 2. Suggested Reading
It is assumed that the reader understands BGP, [RFC4271], the RPKI, It is assumed that the reader understands BGP, [RFC4271], the RPKI,
see [I-D.ietf-sidr-arch], the RPKI Repository Structure, see see [I-D.ietf-sidr-arch], the RPKI Repository Structure, see
[I-D.ietf-sidr-repos-struct], ROAs, see [I-D.ietf-sidr-roa-format], [I-D.ietf-sidr-repos-struct], ROAs, see [I-D.ietf-sidr-roa-format],
the RPKI to Router Protocol, see [I-D.ymbk-rpki-rtr-protocol], and the RPKI to Router Protocol, see [I-D.ietf-sidr-rpki-rtr], and RPKI-
RPKI-based Prefix Validation, see [I-D.pmohapat-sidr-pfx-validate]. based Prefix Validation, see [I-D.ietf-sidr-pfx-validate].
3. RPKI Distribution and Maintenance 3. RPKI Distribution and Maintenance
The RPKI is a distributed database containing certificates, CRLs, The RPKI is a distributed database containing certificates, CRLs,
manifests, ROAs, and Ghostbuster Records as described in manifests, ROAs, and Ghostbuster Records as described in
[I-D.ietf-sidr-repos-struct]. Policies and considerations for RPKI [I-D.ietf-sidr-repos-struct]. Policies and considerations for RPKI
object generation and maintenance are discussed elsewhere. object generation and maintenance are discussed elsewhere.
A local valid cache containing all RPKI data may be gathered from the A local valid cache containing all RPKI data may be gathered from the
global distributed database using the rsync protocol and a validation global distributed database using the rsync protocol and a validation
skipping to change at page 4, line 44 skipping to change at page 4, line 44
preferences, etc. This allows a network to incrementally deploy preferences, etc. This allows a network to incrementally deploy
validation capable border routers. validation capable border routers.
eBGP speakers which face more critical peers or up/downstreams would eBGP speakers which face more critical peers or up/downstreams would
be candidates for the earliest deployment. Validating more critical be candidates for the earliest deployment. Validating more critical
received announcements should be considered in partial deployment. received announcements should be considered in partial deployment.
5. Routing Policy 5. Routing Policy
Origin validation based on the RPKI merely marks a received Origin validation based on the RPKI merely marks a received
announcement as having an origin which is Validated, Unknown, or announcement as having an origin which is Valid, NotFound, or
Invalid. How this is used in routing is up to the router operator's Invalid. See [I-D.ietf-sidr-pfx-validate]. How this is used in
local policy. See [I-D.pmohapat-sidr-pfx-validate]. routing is specified by the operator's local policy.
Reasonable application of local policy should be designed eliminate Local policy using relative preference is suggested to manage the
the threat of unroutability of prefixes due to ill-advised or uncertainty associated with a system in flux, applying local policy
incorrect certification policies. to eliminate the threat of unroutability of prefixes due to ill-
advised certification policies and/or incorrect certification data.
E.g. until the community feels comfortable relying on RPKI data,
routing on Invalid origin validity, though at a low preference, will
likely be prevalent for a long time.
As origin validation will be rolled out over years coverage will be As origin validation will be rolled out incrementally, coverage will
spotty for a long time. Hence a normal operator's policy should not be incomplete for a long time. Therefore, routing on NotFound
be overly strict, perhaps preferring valid announcements and giving validity state will be advisable for a long time. As the transition
very low preference, but still using, invalid announcements. moves forward, the number of BGP announcements with validation state
NotFound should decrease. Hence an operator's policy should not be
overly strict, preferring Valid announcements, attaching a lower
preference to, but still using, NotFound announcements, and giving
very low preference to, but still using, Invalid announcements.
Some may choose to use the large Local-Preference hammer. Others Some may choose to use the large Local-Preference hammer. Others
might choose to let AS-Path rule and set their internal metric, which might choose to let AS-Path rule and set their internal metric, which
comes after AS-Path in the BGP decision process. comes after AS-Path in the BGP decision process.
Certainly, routing on unknown validity state will be prevalent for a Announcements with Valid origins SHOULD be preferred over those with
long time. NotFound or Invalid origins.
Until the community feels comfortable relying on RPKI data, routing
on invalid origin validity, though at a low preference, may be
prevalent for a long time.
Announcements with valid origins SHOULD be preferred over those with
unknown or invalid origins.
Announcements with unvalidatable origins SHOULD be preferred over Announcements with NotFound origins SHOULD be preferred over those
those with invalid origins. with Invalid origins.
Announcements with invalid origins MAY be used, but SHOULD be less Announcements with Invalid origins MAY be used, but SHOULD be less
preferred than those with valid or unknown. preferred than those with 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 6, line 15 skipping to change at page 6, line 16
The data plane may not follow the control plane. The data plane may not follow the control plane.
8. IANA Considerations 8. IANA Considerations
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, Pradosh The author wishes to thank Rob Austein, Steve Bellovin, Pradosh
Mohapatra, Chris Morrow, Keyur Patel, Heather and Jason Schiller, Mohapatra, Chris Morrow, Keyur Patel, Heather and Jason Schiller,
John Scudder, and Dave Ward. John Scudder, Maureen Stillman, and Dave Ward.
10. References 10. References
10.1. Normative References 10.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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
skipping to change at page 6, line 41 skipping to change at page 6, line 42
Resource Certificate Repository Structure", Resource Certificate Repository Structure",
draft-ietf-sidr-repos-struct-06 (work in progress), draft-ietf-sidr-repos-struct-06 (work in progress),
November 2010. November 2010.
[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-09 (work in progress), draft-ietf-sidr-roa-format-09 (work in progress),
November 2010. November 2010.
[I-D.ymbk-rpki-rtr-protocol] [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-ymbk-rpki-rtr-protocol-06 (work in progress), draft-ietf-sidr-rpki-rtr-06 (work in progress),
July 2010. January 2011.
[I-D.pmohapat-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-pmohapat-sidr-pfx-validate-07 (work in progress), draft-ietf-sidr-pfx-validate-00 (work in progress),
April 2010. July 2010.
[I-D.wkumari-deprecate-as-sets] [I-D.wkumari-deprecate-as-sets]
Kumari, W., "Deprecation of BGP AS_SET, AS_CONFED_SET.", Kumari, W., "Deprecation of BGP AS_SET, AS_CONFED_SET.",
draft-wkumari-deprecate-as-sets-01 (work in progress), draft-wkumari-deprecate-as-sets-01 (work in progress),
September 2010. September 2010.
10.2. Informative References 10.2. Informative References
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
 End of changes. 16 change blocks. 
36 lines changed or deleted 38 lines changed or added

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