draft-ietf-sidr-rpki-rtr-01.txt   draft-ietf-sidr-rpki-rtr-02.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft IIJ Internet-Draft IIJ
Intended status: Standards Track R. Austein Intended status: Standards Track R. Austein
Expires: February 16, 2011 ISC Expires: March 2, 2011 ISC
August 15, 2010 August 29, 2010
The RPKI/Router Protocol The RPKI/Router Protocol
draft-ietf-sidr-rpki-rtr-01 draft-ietf-sidr-rpki-rtr-02
Abstract Abstract
In order to formally validate the origin ASes of BGP announcements, In order to formally validate the origin ASes of BGP announcements,
routers need a simple but reliable mechanism to receive RPKI routers need a simple but reliable mechanism to receive RPKI
[I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted
cache. This document describes a protocol to deliver validated cache. This document describes a protocol to deliver validated
prefix origin data to routers over ssh. prefix origin data to routers over ssh.
Requirements Language Requirements Language
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 February 16, 2011. This Internet-Draft will expire on March 2, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 15, line 28 skipping to change at page 15, line 28
MyKey: The private ssh key of this client. MyKey: The private ssh key of this client.
Due to the distributed nature of the RPKI, caches simply can not be Due to the distributed nature of the RPKI, caches simply can not be
rigorously synchronous. A client may hold data from multiple caches, rigorously synchronous. A client may hold data from multiple caches,
but MUST keep the data marked as to source, as later updates MUST but MUST keep the data marked as to source, as later updates MUST
affect the correct data. affect the correct data.
Just as there may be more than one covering ROA from a single cache, Just as there may be more than one covering ROA from a single cache,
there may be multiple covering ROAs from multiple caches. The there may be multiple covering ROAs from multiple caches. The
results are the same as described in [I-D.ietf-sidr-roa-validation] results are as described in [I-D.ietf-sidr-roa-validation].
as follows:
o Data from no cache has a covering ROA, so the result is 'unknown'. If data from multiple caches are held, implementations MUST NOT
distinguish between data sources when performing validation.
o One or more closest covering ROAs exist but none match the AS of When a more preferred cache becomes available, if resources allow, it
the BGP update, so the result is 'invalid'. would be prudent for the client to start fetching from that cache.
o One or more closely covering ROAs have an AS match, while other The client SHOULD attempt to maintain at least one set of data,
equally closely covering ROAs do not have an AS match, so the regardless of whether it has chosen a different cache or established
result is 'valid'. a new connection to the previous cache.
o There are multiple covering ROAs but none with an AS that matches A client MAY drop the data from a particular cache when it is fully
the BGP annoucement, so the result is 'invalid'. in synch with one or more other caches.
When a more preferred cache becomes available, if resources allow, it A client SHOULD delete the data from a cache when it has been unable
would be prudent for the client to start fetching from that cache. to refresh from that cache for a configurable timer value. The
The client MAY drop the data from older, less preferred cache(s) when default for that value is twice the polling period for that cache.
it is fully in synch with one or more other caches.
When a client loses connectivity to the cache it is currently using, If a client loses connectivity to a cache it is using, or otherwise
or otherwise decides to switch to a new cache, it SHOULD retain the decides to switch to a new cache, it SHOULD retain the data from the
data from the previous cache until it has a full set of data from previous cache until it has a full set of data from one or more other
some other cache. It should do this regardless of whether it has caches. Note that this may already be true at the point of
chosen a different cache or established a new connection to the connection loss if the client has connections to more than one cache.
previous cache. However, a configurable timer MUST be provided to
bound how long it will retain the "stale" data.
8. Deployment Scenarios 8. Deployment Scenarios
For illustration, we present three likely deployment scenarios. For illustration, we present three likely deployment scenarios.
Small End Site: The small multi-homed end site may wish to outsource Small End Site: The small multi-homed end site may wish to outsource
the RPKI cache to one or more of their upstream ISPs. They would the RPKI cache to one or more of their upstream ISPs. They would
exchange authentication material with the ISP using some out of exchange authentication material with the ISP using some out of
band mechanism, and their router(s) would connect to one or more band mechanism, and their router(s) would connect to one or more
up-streams' caches. The ISPs would likely deploy caches intended up-streams' caches. The ISPs would likely deploy caches intended
 End of changes. 10 change blocks. 
25 lines changed or deleted 22 lines changed or added

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