Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

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" <[e-mail]> 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"
>>> <[e-mail] on behalf of [e-mail]> 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
>>>>>
>>>>
>>>
>>
>