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.
That’s indeed right. First publication of the draft is quite old now and we
might have not adjusted vocabulary from what was happening in other docs that
got published quicker.
Assuming that's right, I'm curious what the rationale is for giving not-found
routes a low preference?
I’ll start quoting section 5 of RFC7115:
As origin validation will be rolled out incrementally, coverage will
be incomplete for a long time. Therefore, routing on NotFound
validity state SHOULD be done for a long time. As the transition
moves forward, the number of BGP announcements with validation state
NotFound should decrease. Hence, an operator’s policy should not be
overly strict and should prefer Valid announcements; it should attach
a lower preference to, but still use, NotFound announcements, and
drop or give a very low preference to Invalid announcements. Merely
de-preferencing Invalid announcements is ill-advised; see previous
paragraph.
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.
What you say is intersting and I will cc Randy :-)
Actually I think the "lower preference" thing still makes some sense. I still
see the case where you receive the routes from different peerings, for which
you either check or do not check the received prefix against the ROA. I can
give the below example:
- An ISP would check all routes received from an IXP
- This ISP would have a loose policy on its transit (with no verification
because he trusts the transit provider)
The basic ISP policy would be to prefer the routes received through the IXP.
But with the policy described in RFC7115 and repeated in the bgp-opsec draft
the internet route would be prefered. I think this makes some sense and I’ve
seen some similar things some years ago when we were doing route validation
against the RADB.
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.
No problem, it’s an interesting point.
I’d personally keep it as-is (except « NotFound ») given the above example but
I’m interested by what others think.
Thanks!
Jerome
Regards,
--John
P.S.: This shouldn't be construed as a full review of the document, which I
haven't done.
--
Jerome Durand
Consulting Systems Engineer - Routing & Switching
jerduran(_at_)cisco(_dot_)com - +33 6 35 11 60 50
blogs: http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr
twitter: @JeromeDurand
linkedin: http://fr.linkedin.com/in/jeromedurand
CISCO France
11, rue Camille Desmoulins
92782 Issy les Moulineaux
CEDEX 9
FRANCE