Clarifications to BGP Origin Validation Based on
Resource Public Key Infrastructure (RPKI)
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island
Washington
98110
United States of America
randy@psg.com
Security, Routing
Deployment of BGP origin validation based on Resource Public Key Infrastructure (RPKI)
is hampered by, among other things, vendor
misimplementations in two critical areas: which routes are
validated and whether policy is applied when not specified by
configuration. This document is meant to clarify possible
misunderstandings causing those misimplementations; it thus
updates RFC 6811 by clarifying that all prefixes should have their
validation state set and that policy must not be applied without
operator configuration.
Deployment of RPKI-based BGP origin validation is hampered by,
among other things, vendor misimplementations in two critical areas:
which routes are validated and whether policy is applied when not
specified by configuration. This document is meant to clarify
possible misunderstandings causing those misimplementations.
When a route is distributed into BGP, the origin validation state
is set to NotFound, Valid, or Invalid per .
Operational testing has shown that the specifications of that RFC
were not sufficient to avoid divergent implementations. This
document attempts to clarify two areas which seem to cause
confusion.
The implementation issues seem not to be about how to validate,
i.e., how to decide if a route is NotFound, Valid, or Invalid. The
issues seem to be which routes should be evaluated and have their
evaluation state set, and whether to apply policy without operator
configuration.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
It is assumed that the reader understands BGP , the RPKI , Route Origin
Authorizations (ROAs) , and RPKI-based
Prefix Validation .
Significant Clarification: A router MUST evaluate and set the
validation state of all routes in BGP coming from any source (e.g., eBGP,
iBGP, or redistribution from static or connected routes), unless
specifically configured otherwise by the operator. Otherwise, the
operator does not have the ability to drop Invalid routes coming
from every potential source and is therefore liable to complaints
from neighbors about propagation of Invalid routes. For this
reason, says:
When a BGP speaker receives an UPDATE from a neighbor, it
SHOULD perform a lookup as described above for each of the Routes
in the UPDATE message. The lookup SHOULD also be applied to routes
that are redistributed into BGP from another source, such as
another protocol or a locally defined static route.
goes on to say, "An implementation MAY
provide configuration options to control which routes the lookup is
applied to."
When redistributing into BGP from any source (e.g., IGP, iBGP, or from
static or connected routes), there is no AS_PATH in the input to allow
RPKI validation of the originating Autonomous System (AS). In such cases,
the router MUST use the AS of the router's BGP configuration. If that is
ambiguous because of confederation, AS migration, or other multi-AS
configuration, then the router configuration MUST provide a means of
specifying the AS to be used on the redistribution, either per redistribution or
globally.
Significant Clarification: Once routes are evaluated and have
their state set, the operator should be in complete control of any
policy applied based on the evaluation state. Absent specific
operator configuration, policy MUST NOT be applied.
Automatic origin validation policy actions such as those
described in "BGP Prefix Origin Validation
State Extended Community" MUST NOT be carried out or otherwise
applied unless specifically configured by the operator.
This document does not create security considerations beyond
those of .
This document has no IANA actions.
Many thanks to John Scudder, who had the patience to give
constructive review multiple times, and Keyur Patel, who noted
that the AS might have to be specified. George Michaelson, Jay
Borkenhagen, John Heasley, and Matthias Waehlisch kindly helped
clean up loose wording.