[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

What I'm trying to say is that *direct* peers are responsible for leaks as
well (with un/misconfigured prefix list policy). Any other ASN simply have
no strict method and no prior knowledge to determine legitimacy of the
prefix announce, is should seem obvious. I personally don't believe that
introduction of this policy will somehow change behavior of small companies
who accidentally causing hijacks from time to time, but for their (larger
at most) upstreams/peers the policy violation is something they want to
prevent.

Another thing is to determine the existence of the purposeful effort - if
we assume that such thing as leaks caused by state-backed providers exist,
there is a very small chance that the leak would be represented as
non-accidental by its nature and so on, so the policy probably should focus
on preventing leaks caused by non-transit or smaller operators by enforcing
certain rules on those who may be called transit ones, e.g. those whose
business is entirely dependent on proper functioning of their infra.



On Tue, Mar 19, 2019 at 4:14 PM JORDI PALET MARTINEZ via anti-abuse-wg <
anti-abuse-wg at ripe.net> wrote:

> 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/e332ef7b/attachment.html>