Stephen, If I understand your question, I don’t think one can infer anything about the BGP feeds or route selection processes of an AS based upon the traffic a validating cache sends to RPKI repositories.
The design of RPKI validating caches (and all implementations that I know of) prefetch and validate RPKI objects independent of BGP traffic processing. That is, they are background processing the entire RPKI, and are not event driven by BGP traffic. As a matter of fact, the RPKI validating cache’s are typically on systems that have no reason to implement BGP at all. Also the RPKI-to-Rtr protocol between the cache and router is batch driven (roughly) by the validation process, not BGP event driven. I.e., the RPKI traffic to a validating cache in an AS with no BGP feeds and one with full BGP feeds is the same, and both independent of BGP event processing. If that was not the supposition of your question … please ignore. dougm — Doug Montgomery, Mgr Internet & Scalable Systems Research at NIST/ITL/ANTD On 1/4/17, 2:33 PM, "sidr on behalf of Stephen Farrell" <[email protected] on behalf of [email protected]> wrote: > > >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 >> > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
