On Nov 16, 2008, at 5:25 PM, Geoff Huston wrote:
I assume you are referring to the situation where, for example, a ROA exists for 10.1.0.0/16 origin AS 1, and NO ROA exists for 10.1.0.0/16 origin AS2, and you are seeing a route object for 10.1.0.0/16 with origin AS 2, yes?
Or perhaps 10.1.0.0/24, sure..
The problem is that as a relying party you can't tell whether the problem is with the retrieval of ROA objects or whether the route object is bogus. i.e. what if the ROA for 10.1.0.0/16 origin AS 2 was published a few seconds ago, whereas your local cache of ROA objects was last refreshed a day ago. i.e. everything you have at hand is valid, the manifests are good, and you are seeing something that is not oin a locally held ROA, _but_ it is still valid.
This is one of the reasons timing issues need to be considered, and one of the many reasons people stopped using explicit prefix filters. The route would be announced, the prefix was dropped, the filters were updated to support the announcement, but the route wouldn't be accepted unless the session was reset or a route re-announcement was triggered. You can imagine how painful this can be across multiple AS hops.
If there was also a BOA published for 10.1.0.0/16 then as a relying party you now have grounds to believe that anything not described in a valid ROA can be regarded as an invalid object. In this case there is still the issue of time lag, and if the prefix holder had intended to authorize 10.1.0.0/16 using AS 2 as an origination in addition to AS1 then it would be incumbent on the prefix holder to generate and publish the new ROA well in advance of the advertisement of the new route.
So clearly, the same case holds true for the BOA. If a BOA was just removed from the repository a few seconds ago but as a relying party I don't update my "accept policies" because of a problem with the retrieval of the BOA, it's just perturbing the issue. This could be especially problematic during natural disasters or other similar events where a publisher of a BOA can't update a repository or it can't be accessed by a relying party, and therefore, route changes that are common during those events can't happen.
Of course there is also the other case where AS 1 insists on a ROA as a precondition for originating the route, and AS 2 does not, and the prefix holder performs only what is required and no more. In this case both routes are valid, but only one as a ROA. In tis case the problem is not one of timing at the relying party side, and will not be resolved by bring the relying party into sync with the authority publisher.
Yes, I think there are lots of issues of this nature, issues which BOAs only exacerbate.
So the BOA is a way of implementing the RPSEC requirement of being able to support environments of incremental deployment, where it is not assured that everyone is publishing these authorities. Now if you are of the view that the requirement of devising mechanisms to support incremental piecemeal deployment is daft or unnecessary, then perhaps this is a debate that in the IETF context should be held in the context of the RPSEC WG, as the SIDR requirement here is one that was gather up from the earlier RPSEC work and generate mechanisms that met those requirements as stated in the RPSEC documents.
I'm not entirely convinced of this yet... Also, Sam had a query about BOAs including AS numbers, and I think that's a good point. Is the goal for an issue to say AS n can announce prefix x, but no one else, that would take one ROA and two BOAs, right? Why wouldn't that just be done implicitly with a ROA? -danny _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
