<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Times New Roman \(Cuerpo en alfa";
panose-1:2 2 6 3 5 4 5 2 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EstiloCorreo18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=ES link=blue vlink=purple><div class=WordSection1><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p><div><div><p class=MsoNormal style='margin-left:35.4pt'>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 <o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt'>Just trying to act as the evil advocate, to know others opinions.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:35.4pt'>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. <o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt'>Again, in our LACNIC proposal we have considered that incidental issues will also be communicated to those that created the problem, so we can improve the situation as time passes.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><span lang=EN-US>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.<o:p></o:p></span></p></div><div><div><p class=MsoNormal style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Clearly this is the difficulty that will have the experts, correctly classifying the incidents, and may be this means that first time for some incidents (accidental or not) could not be declared as “on purpose”.<o:p></o:p></span></p></div></div><p class=MsoNormal style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></p><div><div><p class=MsoNormal style='margin-left:35.4pt'>On Tue, Mar 19, 2019 at 4:14 PM JORDI PALET MARTINEZ via anti-abuse-wg <<a href="mailto:anti-abuse-wg@ripe.net">anti-abuse-wg@ripe.net</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:35.4pt'><span lang=ES-TRAD style='font-size:12.0pt'>Hi Andrey,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:35.4pt'><span lang=ES-TRAD style='font-size:12.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:35.4pt'><span lang=EN-US style='font-size:12.0pt'>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 ?</span><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:35.4pt'><span lang=EN-US style='font-size:10.5pt;color:black'><br>Regards,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt;margin-left:35.4pt'><span lang=EN-US style='font-size:10.5pt;color:black'>Jordi</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt;margin-left:35.4pt'><span lang=EN-US style='font-size:10.5pt;color:black'> </span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:35.4pt'><span lang=EN-US style='font-size:12.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:35.4pt'><span lang=EN-US style='font-size:12.0pt'> </span><o:p></o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:70.8pt'><b><span style='font-size:12.0pt;color:black'>De: </span></b><span style='font-size:12.0pt;color:black'>anti-abuse-wg <<a href="mailto:anti-abuse-wg-bounces@ripe.net" target="_blank">anti-abuse-wg-bounces@ripe.net</a>> en nombre de Andrey Korolyov <<a href="mailto:andrey@xdel.ru" target="_blank">andrey@xdel.ru</a>><br><b>Fecha: </b>martes, 19 de marzo de 2019, 13:59<br><b>Para: </b><<a href="mailto:anti-abuse-wg@ripe.net" target="_blank">anti-abuse-wg@ripe.net</a>><br><b>Asunto: </b>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</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:70.8pt'> <o:p></o:p></p></div><div><div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:70.8pt'>You can find the full proposal at:<br><a href="https://www.ripe.net/participate/policies/proposals/2019-03" target="_blank">https://www.ripe.net/participate/policies/proposals/2019-03</a><o:p></o:p></p></blockquote><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:70.8pt'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:70.8pt'>Hey WG,<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:70.8pt'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:70.8pt'>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. <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:70.8pt'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:70.8pt'>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?<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:70.8pt'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:70.8pt'>Thanks. <o:p></o:p></p></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:35.4pt'><br>**********************************************<br>IPv4 is over<br>Are you ready for the new Internet ?<br><a href="http://www.theipv6company.com" target="_blank">http://www.theipv6company.com</a><br>The IPv6 Company<br><br>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.<o:p></o:p></p></div></blockquote></div></div></div><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
http://www.theipv6company.com<br>
The IPv6 Company<br>
<br>
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.<br>
<br>
</body></html>