Christopher Morrow писал 2020-04-22 14:05:
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 ?
ASPA/As-Cone is a concept about whole as-path verification afaik, but I
may be mistaken.
ROA validation prevents hijacking but doesn't prevent route-leaks. If my
transit providers already do ROV, effect of doing it in local network
will be limited to direct peers only and expected to be considerably
small. For route-leaks prevention we still have to rely on IRR and
filters configured directly on routers. Maintaining filters on routers
is quite intensive task and they took a lot of space in the
configuration. Adopting validation or similar mechanism for it could
make it more dynamic and less resources-consuming. Or maybe I'm trying
to invent a bicycle?
Kind regards,
Andrey
