draft-ietf-sidr-origin-ops-07.txt   draft-ietf-sidr-origin-ops-08.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Internet Initiative Japan Internet-Draft Internet Initiative Japan
Intended status: BCP May 3, 2011 Intended status: BCP May 10, 2011
Expires: November 4, 2011 Expires: November 11, 2011
RPKI-Based Origin Validation Operation RPKI-Based Origin Validation Operation
draft-ietf-sidr-origin-ops-07 draft-ietf-sidr-origin-ops-08
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 November 4, 2011. This Internet-Draft will expire on November 11, 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 4, line 34 skipping to change at page 4, line 34
A transit provider or a network with peers SHOULD validate origins in A transit provider or a network with peers SHOULD validate origins in
announcements made by upstreams, downstreams, and peers. They still announcements made by upstreams, downstreams, and peers. They still
SHOULD trust the caches provided by their upstreams. SHOULD trust the caches provided by their upstreams.
Before issuing a ROA for a block, an operator MUST ensure that any Before issuing a ROA for a block, an operator MUST ensure that any
sub-allocations from that block which are announced by other ASs, sub-allocations from that block which are announced by other ASs,
e.g. customers, have correct ROAs in play. Otherwise, issuing a ROA e.g. customers, have correct ROAs in play. Otherwise, issuing a ROA
for the super-block will cause the announcements of sub-allocations for the super-block will cause the announcements of sub-allocations
with no ROAs to be Invalid. with no ROAs to be Invalid.
Use of RPKI-based origin validation obviates the utility of
announcing many longer prefix when the covering prefix would do.
To aid translation of ROAs into efficient search algorithms in
routers, ROAs SHOULD be as precise as possible, i.e. match prefixes
as announced in BGP. E.g. software and operators SHOULD avoid use of
excessive max length values in ROAs unless operationally necessary.
Therefore, ROA generation software MUST use the prefix length as the
max length if the user does not specify a max length.
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
ROAs for the specific announcements SHOULD be used as opposed to one
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 issuing ROAs may have customers announce their own prefixes Operators issuing ROAs may have customers announce their own prefixes
and ASs into global eBGP but who do not wish to go though the work to and ASs into global eBGP but who do not wish to go though the work to
manage the relevant certificates and ROAs. The operator SHOULD manage the relevant certificates and ROAs. The operator SHOULD
provision the RPKI data for these customers just as they provision provision the RPKI data for these customers just as they provision
many other things for them. many other things for them.
 End of changes. 4 change blocks. 
4 lines changed or deleted 20 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/