Hi Andrey,
While it looks, in a first sight, a very good idea, if a neighbor ASN fails to do the filtering (for whatever reason, not necessarily on purpose), should we not just “punish” that one, but also next one and so on ?
Regards,
Jordi
De: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> en nombre de Andrey Korolyov <andrey@xdel.ru>
Fecha: martes, 19 de marzo de 2019, 13:59
Para: <anti-abuse-wg@ripe.net>
Asunto: Re: [anti-abuse-wg] [routing-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation) to be discussed on Anti-Abuse Working Group Mailing List
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-03
Hey WG,
out of curiosity, why neighboring ASNs are not carrying any responsibility for not filtering out a malicious advertisement from a directly-peered neighbor in the proposal? AFAIU most leaks happen because large parties are letting their ACL loose, not because some state-backed player decides to take a pick on someone's else traffic (though both variants exists). The peer who allows any prefix announcement originating from its direct neighbor is no less responsible for the hijack as the origin AS itself.
Could you please suggest a possibility to include that kind of relations (determined by third parties, as currently stated for hijacker's AS in the draft) and measures against a transit/upstream in same manner as they are currently defined for a hijacker?
Thanks.