On 11/14/08 3:07 PM, "Geoff Huston" <[EMAIL PROTECTED]> wrote:
> WG Chair hat off
Minneapolis hat soon to be on! Brrrrrr.....
>
> One possible answer is that relying parties simply assume that ROAs
> are universally used and any and every route object that does not
> match a currently valid ROA is discarded. I trust you would agree that
> this would be an unwise assumption for a relying party yo make. In a
> world of incremental deployment where only a few prefix holders are
> generating ROAs this assumption would effectively cause a relying
> party to reject all of the (valid) routing table with the exception of
> the set of objects covered by ROAs. Not good. Even in a world of
> comprehensive deployment this would be an unwise move. Because prefix
> holders essentially publish their own signed objects in a repository
> of their choosing, relying parties, if they wish to avoid using the
> services of RPKI aggregators or middle-agents will need to access wach
> and every repository in order to collect the ROAs and the necessary
> certificate material that is required to validate each ROA. But what
> if the ROA for a prefix is contained in a repository that is located
> at an address that is described in the ROA. i.e. you can't get the ROA
> until you treat the corresponding route object as valid, and you can;t
> treat it as valid until you have the ROA.
>
> The other option is that the relying party assumes that ROAs are not
> universally deployed, and that implies that a relying party must
> assume that there exists valid route objects for which there is no
> corresponding ROA. In a world of partial deployment where a relying
> party has no idea whether the absence of a ROA indicates an attempted
> routing hijack of the simple absence of a ROA, then the relying party
> really is no better off than if there were no ROAs whatsoever!
This reminds me of the +all/-all,~all SPF wars, where die-hards insisted on
-all but nearly everybody did ~all.
There are likely to be 3 types of route objects:
- those covered by ROAs
- those covered by BOAs (and perhaps a wider BOA)
- those covered by neither
Given that incremental deployment means the Internet will start out with
route objects covered by neither, policy will have to determine what to do
when a route object is not covered by a ROA (the bad situation you mention
above). BOAs do not get us out of this.
>> And who is to be in the business of publishing trusted BOAs for
>> bogons?
>> Seems to me that it would be fraught with peril if they screw it up.
>>
>
> Only the certified holder of an address block can generate a BOA. So I
> suppose the answer to your question would depend on your preferred
> interpretation of what is a "bogon".
Clear as mud! But this just re-enforces what I just said. There will be
route objects not covered by either a BOA or a ROA.
That being said, I'm not gonna fall on my sword over this. In the end, BOAs
may likely end up like SPF -all, ignored.
-andy
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
