Hiya, On 04/01/17 21:39, Montgomery, Douglas (Fed) wrote: > 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.
Sure. That makes sense. But where's it stated for BGPsec that the RP ought act that way? Cheers, S. > > 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 >>>>> >>>> >>> >> >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
