On 04/01/17 19:24, Russ Housley wrote: > >> ---------------------------------------------------------------------- >> >> 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 …
More or less if traffic to/from ASxxxx is visible to an attacker and/or can be modified by an attacker. That could be due to collusion between the AS and an attacker for example, or because an attacker has compromised some routers within a transit AS. > > If a link goes down, I'm not sure this is only if a link goes down. I'd guess the same risk would exist when any BGPsec path is first seen at a relying party and where that RP doesn't have all the necessary RPKI stuff cached before signature validation. . 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. Right. Sorry to not be clearer on what might become visible to the network outside the RP's AS - I'm afraid I just don't have all the RPKI details in my head;-) > > 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. Right, I think all that'd be needed for this would be to ack that there's this (normally fairly minor) new risk and that you can avoid it if you pre-fetch enough stuff. (As a separate question, I wonder if the amount of stuff involved in the RPKI is such that it'd be fairly easy to pre-fetch it all frequently enough to nearly never hit this problem.) Cheers, S. > > Russ >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
