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

[Stephen Farrell <[e-mail]>]

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
>