This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[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
- Previous message (by thread): [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
- Next message (by thread): [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
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Tue Mar 19 14:14:05 CET 2019
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 at ripe.net> en nombre de Andrey Korolyov <andrey at xdel.ru> Fecha: martes, 19 de marzo de 2019, 13:59 Para: <anti-abuse-wg at 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. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/anti-abuse-wg/attachments/20190319/9148f1b1/attachment.html>
- Previous message (by thread): [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
- Next message (by thread): [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
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]