> Nonetheless, all of the methods for whacking a ROA described in the > paper are detectable by anyone who monitors the RPKI. One might argue > that each resource holder should monitor his/her RPKI pub point to > detect any action that causes one's ROA to become unverifiable.
thanks to shane for whacking me on this general area in taipei. the results are in draft-ietf-sidr-origin-ops-20.txt Operators should use tools which warn them of any impending ROA or certificate expiry which could affect the validity of their own data. Ghostbuster Records, see [RFC6493], can be used to facilitate contact with upstream CAs to effect repair. and As reliable access to the global RPKI and an operator's caches (and possibly other hosts, e.g. DNS root servers) is important, an operator SHOULD take advantage of relying party tools which report changes in BGP or RPKI data which would negatively affect validation of such prefixes. > As above, the actions described in these sections are all easily > detectable by the targeted entity. suggestions for strengthening the draft appreciated. terse, steve, terse :) randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
