On Mar 20, 2013, at 7:32 PM, Arturo Servin <[email protected]> wrote:
> > > On 20/03/2013 20:00, Borchert, Oliver wrote: <snip> >> But what does the alert tell me? >> What if one is multi homed, uses two ROAs then switches to be single homed >> and revokes the second ROA. In this case the owner revoked the ROA and this >> is not an attack - here the alert is not of help at all! >> >> Oliver > > That is the problem. It is almost impossible to know when a ROA is > revoked legally or by accident/attack. This would only be a mechanism to > alert when something changes, then you to decide as operator what to do. > But most probably you will end up ignoring all the alerts unless there > is a big fuss about it. I think this thread brings up a very important (but subtle point). Knowing that i) a ROA exists, but is not present is different than ii) a ROA that has been removed by a resource holder, and _that_ is different than iii) the grand-parenting issue… (though that could be a vector to effect case i), above)… For example: i) An adversary intercepts a TCP session and selectively removes branches of a repo (including some ROAs) during an rsync session so that attestation is affected… Yes, yes, I know the crypto makes this apparent, but that's at the cache-level… The RP just knows that there ain't no ROA there... ii) (As mentioned above), resource holder changes their peering… iii) A resource holder surgically takes a descendant's allocations away… I think it is very important (as I think Doug M alluded to) that there be an understanding and some expressiveness around these corner cases. If something is there, if something is validated, if something is not there, if something is missing (i.e. _should_ be there, but isn't) are all different. With an understanding of these sorts of things, operators might be able to find policy knobs that they can use, and with _that_ maybe we can get some informed requirements… Well, ideally, anyway… ;) Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
