draft-ietf-sidr-rpki-rtr-19.txt   draft-ietf-sidr-rpki-rtr-20.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Internet Initiative Japan Internet-Draft Internet Initiative Japan
Intended status: Standards Track R. Austein Intended status: Standards Track R. Austein
Expires: May 3, 2012 Dragon Research Labs Expires: June 2, 2012 Dragon Research Labs
October 31, 2011 November 30, 2011
The RPKI/Router Protocol The RPKI/Router Protocol
draft-ietf-sidr-rpki-rtr-19 draft-ietf-sidr-rpki-rtr-20
Abstract Abstract
In order to formally validate the origin ASs of BGP announcements, In order to formally validate the origin ASs 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] prefix origin data from a trusted cache. This [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This
document describes a protocol to deliver validated prefix origin data document describes a protocol to deliver validated prefix origin data
to routers. to routers.
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 May 3, 2012. This Internet-Draft will expire on June 2, 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 3, line 36 skipping to change at page 3, line 36
2. Glossary 2. Glossary
The following terms are used with special meaning: The following terms are used with special meaning:
Global RPKI: The authoritative data of the RPKI are published in a Global RPKI: The authoritative data of the RPKI are published in a
distributed set of servers at the IANA, RIRs, NIRs, and ISPs, see distributed set of servers at the IANA, RIRs, NIRs, and ISPs, see
[I-D.ietf-sidr-repos-struct]. [I-D.ietf-sidr-repos-struct].
Cache: A coalesced copy of the RPKI which is periodically fetched/ Cache: A coalesced copy of the RPKI which is periodically fetched/
refreshed directly or indirectly from the global RPKI using the refreshed directly or indirectly from the global RPKI using the
[RFC5781] protocol/tools. Relying party update software such as [RFC5781] protocol/tools. Relying party software is used to
rcynic is used to gather and validate the distributed data of the gather and validate the distributed data of the RPKI into a cache.
RPKI into a cache. Trusting this cache further is a matter Trusting this cache further is a matter between the provider of
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 with receiving, new incoming data and implicit deletes are marked with
the new serial but MUST NOT be sent until the fetch is complete. the new serial but MUST NOT be sent until the fetch is complete.
A serial number is not commensurate between caches, nor need it be A serial number is not commensurate between caches, nor need it be
maintained across resets of the cache server. See [RFC1982] on maintained across resets of the cache server. See [RFC1982] on
DNS Serial Number Arithmetic for too much detail on serial number DNS Serial Number Arithmetic for too much detail on serial number
skipping to change at page 16, line 15 skipping to change at page 16, line 15
to each other. Integrity protection for payloads is also desirable to each other. Integrity protection for payloads is also desirable
to protect against monkey in the middle attacks. Unfortunately, to protect against monkey in the middle attacks. Unfortunately,
there is no protocol to do so on all currently used platforms. there is no protocol to do so on all currently used platforms.
Therefore, as of this document, there is no mandatory to implement Therefore, as of this document, there is no mandatory to implement
transport which provides authentication and integrity protection. transport which provides authentication and integrity protection.
To reduce exposure to dropped but non-terminated sessions, both To reduce exposure to dropped but non-terminated sessions, both
caches and routers SHOULD enable keep alives when available in the caches and routers SHOULD enable keep alives when available in the
chosen transport protocol. chosen transport protocol.
It is expected that, when TCP-AO [RFC2385]is available on all It is expected that, when TCP-AO [RFC5925] is available on all
platforms deployed by operators, it will become the mandatory to platforms deployed by operators, it will become the mandatory to
implement transport. implement transport.
Caches and routers MUST implement unprotected transport over TCP Caches and routers MUST implement unprotected transport over TCP
using a port, RPKI-Rtr, to be assigned, see Section 12. Operators using a port, RPKI-Rtr, to be assigned, see Section 12. Operators
SHOULD use procedural means, ACLs, ... to reduce the exposure to SHOULD use procedural means, ACLs, ... to reduce the exposure to
authentication issues. authentication issues.
If available to the operator, caches and routers SHOULD use one of If available to the operator, caches and routers SHOULD use one of
the following more protected protocols. the following more protected protocols.
skipping to change at page 23, line 33 skipping to change at page 23, line 33
thanks go to Hannes Gredler for showing us the dangers of unnecessary thanks go to Hannes Gredler for showing us the dangers of unnecessary
fields. fields.
14. References 14. References
14.1. Normative References 14.1. Normative References
[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-02 (work in progress), draft-ietf-sidr-pfx-validate-03 (work in progress),
July 2011. October 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.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
skipping to change at page 24, line 20 skipping to change at page 24, line 20
May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
for the TCP Authentication Option (TCP-AO)", RFC 5926, for the TCP Authentication Option (TCP-AO)", RFC 5926,
June 2010. June 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-13 (work in Secure Internet Routing", draft-ietf-sidr-arch-13 (work in
progress), May 2011. progress), May 2011.
 End of changes. 7 change blocks. 
11 lines changed or deleted 14 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/