draft-ietf-sidr-rpki-rtr-07.txt   draft-ietf-sidr-rpki-rtr-08.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: July 16, 2011 ISC Expires: August 20, 2011 ISC
January 12, 2011 February 16, 2011
The RPKI/Router Protocol The RPKI/Router Protocol
draft-ietf-sidr-rpki-rtr-07 draft-ietf-sidr-rpki-rtr-08
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 July 16, 2011. This Internet-Draft will expire on August 20, 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 16, line 14 skipping to change at page 16, line 14
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 as described in [I-D.ietf-sidr-roa-validation]. results are as described in [I-D.ietf-sidr-pfx-validate].
If data from multiple caches are held, implementations MUST NOT If data from multiple caches are held, implementations MUST NOT
distinguish between data sources when performing validation. distinguish between data sources when performing validation.
When a more preferred cache becomes available, if resources allow, it When a more preferred cache becomes available, if resources allow, it
would be prudent for the client to start fetching from that cache. would be prudent for the client to start fetching from that cache.
The client SHOULD attempt to maintain at least one set of data, The client SHOULD attempt to maintain at least one set of data,
regardless of whether it has chosen a different cache or established regardless of whether it has chosen a different cache or established
a new connection to the previous cache. a new connection to the previous cache.
skipping to change at page 19, line 28 skipping to change at page 19, line 28
Cache: Relying party update sofcware such as rcynic is used to Cache: Relying party update sofcware such as rcynic is used to
gather and validate the distributed data of the RPKI into a cache. gather and validate the distributed data of the RPKI into a cache.
Trusting this cache further is a matter between the provider of Trusting this cache further is a matter between the provider of
the cache and a relying party. the cache and a relying party.
Serial Number: A 32-bit monotonically increasing ordinal which wraps Serial Number: A 32-bit monotonically increasing ordinal which wraps
from 2^32-1 to 0. It denotes the logical version of a cache. A from 2^32-1 to 0. It denotes the logical version of a cache. A
cache increments the value by one when it successfully updates its cache increments the value by one when it successfully updates its
data from a parent cache or from primary RPKI data. As a cache is data from a parent cache or from primary RPKI data. As a cache is
receiving, new incoming data, and implicit deletes, are marked receiving, new incoming data, and implicit deletes, are marked
with the new serial but MUST not be sent until the fetch is with the new serial but MUST NOT be sent until the fetch is
complete. A serial number is not commensurate between caches, nor complete. A serial number is not commensurate between caches, nor
need it be maintained across resets of the cache server. See need it be maintained across resets of the cache server. See
[RFC1982] on DNS Serial Number Arithmetic for too much detail on [RFC1982] on DNS Serial Number Arithmetic for too much detail on
serial number arithmetic. serial number arithmetic.
12. IANA Considerations 12. IANA Considerations
This document requests the IANA to create a registry for PDU types. This document requests the IANA to create a registry for PDU types.
This document requests the IANA to create a registry for Error Codes. This document requests the IANA to create a registry for Error Codes.
skipping to change at page 20, line 12 skipping to change at page 20, line 12
The authors wish to thank Steve Bellovin, Rex Fernando, Russ Housley, The authors wish to thank Steve Bellovin, Rex Fernando, Russ Housley,
Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Robert Raszuk, John Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Robert Raszuk, John
Scudder, Ruediger Volk, and David Ward. Particular thanks go to Scudder, Ruediger Volk, and David Ward. Particular thanks go to
Hannes Gredler for showing us the dangers of unnecessary fields. Hannes Gredler for showing us the dangers of unnecessary fields.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-sidr-roa-validation] [I-D.ietf-sidr-pfx-validate]
Huston, G. and G. Michaelson, "Validation of Route Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Origination using the Resource Certificate PKI and ROAs", Austein, "BGP Prefix Origin Validation",
draft-ietf-sidr-roa-validation-10 (work in progress), draft-ietf-sidr-pfx-validate-01 (work in progress),
November 2010. February 2011.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[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.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006. Authentication Protocol", RFC 4252, January 2006.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, February 2010.
14.2. Informative References 14.2. Informative 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-11 (work in Secure Internet Routing", draft-ietf-sidr-arch-11 (work in
progress), September 2010. progress), September 2010.
[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-06 (work in progress), draft-ietf-sidr-repos-struct-06 (work in progress),
November 2010. November 2010.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996. Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, February 2010.
Authors' Addresses Authors' Addresses
Randy Bush Randy Bush
Internet Initiative Japan, Inc. Internet Initiative Japan, Inc.
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
US US
Phone: +1 206 780 0431 x1 Phone: +1 206 780 0431 x1
Email: randy@psg.com Email: randy@psg.com
 End of changes. 8 change blocks. 
14 lines changed or deleted 14 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/