On Sep 8, 2014, at 11:42 AM, The IESG <iesg-secretary(_at_)ietf(_dot_)org>
wrote:
The IESG has received a request from the Operational Security
Capabilities for IP Network Infrastructure WG (opsec) to consider the
following document:
- 'BGP operations and security'
<draft-ietf-opsec-bgp-security-05.txt> as Best Current Practice
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2014-09-22.
...
I happened to notice, in S. 6.1.2.4 (SIDR):
o If an ROA is not found then the prefix SHOULD be accepted but
corresponding route SHOULD be given a low preference.
The draft isn't precise about what's meant by "ROA is not found", but probably
it's the same as NotFound in RFC 7115 and 6811. Assuming that's right, I'm
curious what the rationale is for giving not-found routes a low preference? By
definition, they don't compete with a route that is in any other state --
NotFound basically means there is no ROA that has anything to say about this
prefix at all, so all routes for this prefix will be NotFound.
The net result is according to the draft's recommendation all routes for the
prefix in question will be "accepted but ... given a low preference". The
recommendation ends up being mostly harmless, but also not useful.
(I say only *mostly* harmless since I guess some operator could be confused
into thinking they're more secure than they actually are.)
Sorry for the late comment.
Regards,
--John
P.S.: This shouldn't be construed as a full review of the document, which I
haven't done.