> ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have a couple of fairly straightforward things I'd > like to briefly discuss... > > [snip] > > (3) section 8: Is there a potential exposure here in that > a relying party who emits e.g. certificate status checks > or cert retrieval queries for an RPKI cert they've not > previously seen is exposing something about the set of > paths its traffic is likely to follow. (This is similar to > why we have OCSP stapling in the web.) IIRC the RPKI specs > may cover this but I suspect it'd be worth noting here as > well even if so as this represents exposing something > about BGP announcement content to off-path parties which I > think is new for BGP. Is that a new thing for BGP? (I > think the new aspect to the attack is that a bad actor who > has already compromised some AS could more easily spot > that traffic from the relying party's AS is likely to > transit the compromised AS.)
I am not sure what you mean by a "compromised AS,” but it may not matters … If a link goes down, and that causes an alternative path to be selected, that forces the validation a new path which might involve a previously unvalidated AS. If an OCSP responder or repository that provides RPKI objects is contacted as part of that validation, then some external entities can detect that something is changing. That is, stuff not normally validated because it is associated with a unselected path gets fetched. That said, the NOC could fetch a snapshot of the RPKI, then the exposure of the switch to a new path can be limited to that AS. This assumes that the snapshot uses CRLs, which seems like a very reasonable choice in the RPKI. Russ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
