On Wed, Apr 22, 2020 at 2:03 PM Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Apr 22, 2020 at 1:32 PM Danny McPherson <danny@tcb.net> wrote:
On 2020-04-22 12:51, Andrey Kostin wrote:
BCP38 website doesn't proclaim anybody in person to be unsafe, but if it would be possible to make such test it'd be more useful than that RPKI test.
BTW, has anybody yet thought/looked into extending RPKI-RTR protocol for validation of prefixes received from peer-as to make ingress filtering more dynamic and move away prefix filters from the routers?
Do you really want those things in soft-state and not with some giant operational buffer to absorb all the brokenness that's sure to arise?
a question about the data types here... So, a neighbor with no downstream ASN could be filtered directly with ROA == prefixlist-content. A neighbor with a downstream ASN has to be ROA (per asn downstream) == prefixlist-content.
So you'd now have to do some calculations which are more complicated than just; "is roa for this prefix here and valid" to construct a prefix-list. correct?
Sorry, and this sidesteps the intent of the peer as well. For instance you may have a peer with 2 'downstream' asn, only 1 of which they wish to provide transit to you (from you?) for... how would you know this intent/policy from the peer's perspective? today you know that (most likely) from IRR data. is your answer ASPA / AS-Cone ?