Subject: [sidr] I-D Action: draft-ietf-sidr-origin-ops-09.txt

From: [email-masked]
Date: Mon, 23 May 2011 09:15:14 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.

	Title           : RPKI-Based Origin Validation Operation
	Author(s)       : Randy Bush
	Filename        : draft-ietf-sidr-origin-ops-09.txt
	Pages           : 9
	Date            : 2011-05-23

   Deployment of RPKI-based BGP origin validation has many operational
   considerations.  This document attempts to collect and present them.
   It is expected to evolve as RPKI-based origin validation is deployed
   and the dynamics are better understood.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-09.txt

---

From: Randy Bush <[email-masked]>
Date: Mon, 23 May 2011 18:24:24 +0200

modded section 3

   Use of RPKI-based origin validation removes any need to originate
   more specifics to protect against mis-origination of a less specific
   prefix.  Having a ROA for the covering prefix should protect it.

   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.

   One advantage of minimal ROA length is that the forged origin attack
   does not work for sub-prefixes that are not covered by overly long
   max length.  E.g. if, instead of 10.0.0.0/16-24, one issues
   10.0.0.0/16 and 10.0.42.0/24, a forged origin attack can not succeed
   against 10.0.66.0/24.  They must attack the whole /16, which is more
   likely to be noticed.

   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.