[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reaching out to ARIN members about their RPKI INVALID prefixes
> On Sep 18, 2018, at 15:07 , Job Snijders <job at 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.
>>> 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.
>>> 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)