Re: [Sidrops] On validating AS paths

[Christopher Morrow <[e-mail]>]

On Mon, Jul 1, 2019 at 3:33 PM Iljitsch van Beijnum <[e-mail]> wrote:
>
> On 1 Jul 2019, at 20:27, Christopher Morrow <[e-mail]> wrote:
>
> >> Yes. Note that in my previous message I was specifically addressing validating the _entire_ path, while ASPA only concerns itself with validating the "up" part of the path, where the only valid relationships are provider-customer and sibling-sibling.
>
> > isn't this the point of 'bgpsec'? meaning: "you can do this when you
> > see bgpsec signed paths from bgp peers"
>
> Unless I'm missing something (I don't think so, but it's a complicated system so maybe I am), BGPsec gives you two things:
>
> 1. Signatures on all the hops in the path, so you can check that the BGP update did traverse those routers/ASes and no others
>
> 2. A signature from any given AS in the path on the next hop AS, so you can determine that the update was propagated as intended by each previous hop
>

yup, that's bgpsec.

> These features are orthogonal to the issue of route leaks as defined as types 1 - 4 in RFC 7908: these break the valley-freeness property that we expect to see in valid paths, but as they're accidental, they don't do anything that BGPsec doesn't like.
>

ah! yes, this is the same sort of stuff sahron goldberg,. et-al
wrangled in several papers over the last 10 or so years:
  "RPKI, SIDR, BGPSEC are nice, but you STILL have to plan to do some
prefix filtering"

(note that also danny mcpherson was an 'early adoptor' of this
premise... "Hey, this won't stop leaks, so.. like... wtf dudes?"
perhaps a tad more eloquently put by danny)

> Note that the second feature seems impressive until you realize that it's a feature of the internet that ALL BGP updates reach ALL ASes, and that the source only gets to select the next hop AS, but that any ASes after that can apply any mistaken or malicious policy that they see fit.
>

"all" -  where there isn't some policy enforcing a block/etc, or where
best-path didn't cause the route to propagate. sure.

> Of course if it turns out that some of these route leaks are NOT accidental and when we manage to stop them by validating the AS path in non-BGPsec BGP and then the culprits start creating fake AS paths to get around that validation, at that point BGPsec can fix that problem.
>
> But as it is today BGPsec is an unimplemented fix for unimplemented problems.  :-)  :-(  :-)

my guess is we don't know the shape of today's problem :( but ok.

> Once we can validate paths then BGPsec will be of additional value, but I expect that the huge overhead that it carries will never justify the benefits. If people are leaking routes maliciously, as some people have accused China Telecom of doing [*], then path validation even on unprotected paths they'd have to inject fake paths to get through the validation to keep doing that. At that point, there's really no plausible deniability anymore.
>
> [*] https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050&context=mca