The RPKI validating caches *are* the relaying parties for BGPsec, they are (a) designed to be run on a separate box than the router itself and (b) their behavior WRT exchanges with RPKI repositories is independent of BGP message processing by any of the routers that they serve.
Maybe the first few sections of https://tools.ietf.org/html/rfc6810 would make that point better than my mumblings. e.g., For various research / measurement reasons we run 3 different validating caches that don’t serve a single BGP router. Their exchanges with the repositories are no different than if they served a DFZ BGP router. Dougm — Doug Montgomery, Mgr Internet & Scalable Systems Research at NIST/ITL/ANTD On 1/4/17, 3:48 PM, "Stephen Farrell" <[email protected]> wrote: > >Hiya, > >On 04/01/17 20:00, Montgomery, Douglas (Fed) wrote: >> 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. > >Is that the same traffic a BGPsec relying party sends? > >I can imagine that it might or might not be, but don't >recall the BGPsec spec saying. > >If, in fact, it isn't possible to infer which ASes are >likely to be used from the traffic emitted by an RP >for PKI purposes, then yes, this discuss point goes >away. (I think:-) > >Cheers, >S. > >> >> 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
