> On Sep 18, 2018, at 15:07 , Job Snijders <job@ntt.net> wrote:
>
> On Tue, Sep 18, 2018 at 02:44:30PM -0700, Owen DeLong wrote:
>> ROAs are useful for one hop level validation. At the second AS hop
>> they are 100% useless.
>
> This conversation cannot be had without acknowledging there are multiple
> layers of defense in securing BGP. We should also acknowledge that the
> majority of Internet traffic passes over AS_PATHs that are only one hop.
> Networks that exchange significant amounts of traffic, tend to peer
> directly with each other.
Actually, I don’t buy that at all.
Without going into too much detail, I know of at least one former employer who is quite
well peered, distributes a great deal of traffic and sends a tremendous amount of it
via multiple ASNs.
an IP resource holder can sign multiple ROA for a single prefix, it's perfectly valid to have:
157.130.0.0/16 AS112
So 'peered well via multiple ASN isn't really a problem here'. Are you making an argument of the form: "1% of the problems are not solved so this solution can't possibly work" ?
Using ROA from the RPKI system tied through/to the IRR data and applied as filters on the bgp sessions of a network should provide that ASN with more assurance that they will not accept and propagate a route hijack or mistake. Adding in validation is nice as well, and may allow you to be a little less diligent about route filtering... I think more than 1 protection is a good plan though (OV + filters seems sane to me, especially in a world where you can automate that whole lot)
>
>>> In other words, RPKI and the Prefix-to-AS validation procedure give
>>> us much more definitive inputs for routing policies compared to what
>>> can be derived from the IRR.
>>
>> Please explain to me how you distinguish good from bad in the
>> following scenario… You peer with AS6939. You receive routes for
>> 2001:db8:f300::/48 with the following AS Paths
>>
>> 1. 6939 1239 54049 2312 1734
>> 2. 6939 44046 12049 174 1734
>>
>> Which one is valid? Which one is not? How did the ROA tell you this?
>
> Both path 1 and 2 are invalid, because of peerlock we'd never accept
> 1239 behind 6939, or 174 behind 6939. AS_PATH filtering combined with
> Origin Validation is where the magic is.
OK, poor examples crafted at random. Point is there are plenty of valid AS Paths
out there that you can’t actually validate.
I think Job's point is that there really are note that many... perhaps that's an NTT particular view? I know that my production network's view is similar in 'shorter as paths'. I expect that in large-isp-land it's more prevalent than not.
>>> RPKI is useful in context of a defense in depth strategy. If one
>>> combines "peerlock" AS_PATH filters with origin validation the end
>>> result is bullet proof. Even if NTT is the only one to deploy this
>>> combination, the benefits are notable.
>>
>> Indeed, if peerlock gets wider deployment, it might prove useful. But
>> unless I’m really misunderstanding peerlock, I don’t see that RPKI
>> brings much else to the table in addition.
>
> Wide deployment is not relevant, this is a unilateral defense mechanism,
> so I fear there may indeed be a degree of misunderstanding.
Point being that there are very very few ASNs using peer lock. Peer lock
alone AIUI pretty well covers the issue. RPKI provides very little (if any)
verification.
I suppose if you are happy just doing peer lock on/for your network and customers then cool!
The RPKI system isn't being forced on you. It seems like a helpful addition to me, but that may not be your outlook.
-chris