Re: [Sidrops] Call for SIDROPS WG Agenda Items

[Tim Bruijnzeels <[e-mail]>]

Sriram,

I have nothing against BGPSec deployment personally, on the contrary.. I am well aware of the island theorem, but I just observe that years after standardisation deployment is not happening. And I fear that it’s largely because today such islands are hard to build, expensive, and lack of support in hardware routers makes the mission all the more difficult. And unless your neighbours also deploy there is no reward. This is a hard sell.

I am also well aware that with ASPA or similar approaches the path can still be forged, especially under partial deployment - albeit that it’s harder.

I see the two techniques as orthogonal. BGPSec is what you would need to be certain that the path is not forged, but it says nothing about whether these paths are according to policy. A technique like ASPA provides verifiable and light-weight (which is good!) policy, but no absolute certainty of path correctness.

So, I believe that ASPA has a valid place of its own. It will make things better than today. Moreover it will be cheap to deploy. RPKI validators can do the crypto and routers already have a lot (all?) of the config hooks in place to use this information.

It does not exclude future BGPSec deployment. To quote the little green guy: Hard to see the future is. But I suspect that the chances of BGPSec deployment will actually increase if RPKI has an ASPA like feature. It allows for step by step improvements: origin (ROAs), policy (ASPA) and then finally when there is significant uptake of the first two, it will be easier to do the extra step and build bgpsec islands.

Tim

> On 10 Jul 2018, at 20:25, Sriram, Kotikalapudi (Fed) <[e-mail]> wrote:
> 
> Tim,
> 
>> IMHO one of the big issues with BGPSec deployment is that 
>> it's all or nothing, so there really is no incentive to deploy until everybody else has done so.
> 
> IMO, these are two different goals: (1) All AS hops must be valid for the update to be valid, 
> and (2) the benefit of BGPsec for early adopters with incremental deployment.
> BGPsec is successful on meeting both goals.
> 
> SIDR path validation always had the requirement that the AS path in the
> announced update MUST be provably valid; not merely feasible
> (see 4.2 in RFC 7353). 
> 
> SIDR WG ruled out partial path validation because that would
> keep the door open for cut-and-paste or forged path attacks.
> 
> Without BGPsec, the following can happen.
> Even with checking all AS hops in the update against a database
> that provides a white list of peering relationships 
> (e.g., proposed ASPA, CAIDA peering data),
> an update with forged path is still possible. For example, consider a prefix that is
> multihomed and has two RAOs with ASNs of two different providers,
> and the prefix is only announced through one provider.
> An MITM attack is possible that exploits the other ROA and the white list
> to forge a route consisting of only valid AS hops (end-to-end).
> 
> Regarding, (2) the benefit of BGPsec for early adopters and incremental deployment,
> please see Section 6.3.2, RFC 8374 ( https://tools.ietf.org/html/rfc8374#page-26 ):
> 
> 6.3.2.  Discussion
> 
>   The partial-deployment approach to incremental deployment will result
>   in "BGPsec islands".  Updates that originate within a BGPsec island
>   will generally propagate with signed AS paths to the edges of that
>   island.  As BGPsec adoption grows, the BGPsec islands will expand
>   outward (subsuming non-BGPsec portions of the Internet) and/or pairs
>   of islands may join to form larger BGPsec islands.
> 
> The ASes within each BGPsec island are backward compatible with
> traditional BGP ASes that are outside the islands (see Section 4.4 of RFC 8205).  
> 
> Sriram
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>