<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)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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;}
/* 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;}
p.m-6688007103036184175gmail-m8597544426812863049msolistparagraph, li.m-6688007103036184175gmail-m8597544426812863049msolistparagraph, div.m-6688007103036184175gmail-m8597544426812863049msolistparagraph
        {mso-style-name:m_-6688007103036184175gmail-m_8597544426812863049msolistparagraph;
        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.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1319727544;
        mso-list-template-ids:-645876962;}
ol
        {margin-bottom:0cm;}
ul
        {margin-bottom:0cm;}
--></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="EN-CA" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks, David.  I’d rather focus on what we CAN do or MIGHT be able to do, instead of focusing on the negative side of things.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">So the carrot hasn’t worked, over the last 20yrs.  That’s fairly clear.  (Nor has it utterly failed, but its degree of success is noticeably less than perfect.)
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Maybe it’s time to get out a (relatively gentle) stick:  No new IP address space for you, until you demonstrate that you have A) correctly/successfully added both IRR and RPKI ROAs for your existing
 allocations/assignments; and B) implemented BGP filtering, if not up to full MANRS, at least done *<b>something</b>* to prevent bogons, hijacks, etc.  (This could be as simple as “I maintain my prefix-lists by hand and apply them to every connection except
 my upstream(s)”.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I don’t know how to solve the multiple chicken-and-egg problems embedded in what I just wrote, but something along those lines would be consistent with the … huh, can’t find it now, I thought there
 was some language in ARIN’s mandate or policy or something that included “fostering” the development of the Internet?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">If the solution to the problem is to get Tier-1 & Tier-2 backbones to implement filtering, we can drag them along with us.  It’s not an overnight fix, but all the little pushes in the right direction
 add up.  It’s hard to bootstrap your way past a chicken-and-egg problem, and I believe it requires deployment of sticks, not carrots.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">The obvious stick to use would be to put conditions-of-use on any and all number resources back in, but we just took out the RDNS provisions, I’m not sure there’s any appetite for adding anything
 new…?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Also – in this hypothetical world where everyone publishes IRR or RPKI data, ARIN gains a very effective stick: immediate masking of your ROA data.  Would require a well-thought-out enforcement policy,
 that would be horrible if deployed accidentally, but it would be a lot more effective than the, er, nearly-nothing ARIN has today.  I don’t love ARIN, in many ways, but it would seem to be self-consistent for an org that is being asked to police certain aspects
 of organizational behaviour, to enact policies giving itself the tools to do said policing.  OTOH, there’s a very good reason “Judge, Jury and Executioner” is an English idiom with
<i>negative</i> connotations.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">-Adam<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;color:#44546A">Adam Thompson</span></b><span lang="EN-US" style="font-size:9.0pt;color:#44546A"><br>
Consultant, Infrastructure Services<br>
<b><img width="127" height="38" style="width:1.3229in;height:.3958in" id="Picture_x0020_1" src="cid:image001.png@01D500E4.2082BC80" alt="merlin-email-logo"></b><br>
100 - 135 Innovation Drive<br>
Winnipeg, MB, R3T 6A8<br>
(204) 977-6824 or 1-800-430-6404 (MB only)<br>
<a href="mailto:athompson@merlin.mb.ca"><span style="color:#44546A">athompson@merlin.mb.ca</span></a><br>
<a href="http://www.merlin.mb.ca/"><span style="color:#44546A">www.merlin.mb.ca</span></a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> David Farmer <farmer@umn.edu>
<br>
<b>Sent:</b> Thursday, May 2, 2019 12:28 PM<br>
<b>To:</b> Scott Leibrand <scottleibrand@gmail.com><br>
<b>Cc:</b> Adam Thompson <athompson@merlin.mb.ca>; arin-ppml@arin.net<br>
<b>Subject:</b> Re: [arin-ppml] prop266 - re-framing the discussion<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">Adam,<br>
<br>
Thank you, for trying to reframe the discussion, I think this is a useful direction to try to move the discussion forward.<br>
<br>
More below;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
On Thu, May 2, 2019 at 10:16 AM Scott Leibrand <<a href="mailto:scottleibrand@gmail.com" target="_blank">scottleibrand@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<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>
<p class="MsoNormal">Do we have any evidence that 1) a significant fraction of BGP hijacking (announcement in BGP of address space registered by an RIR to another organization that has not authorized them to use it) is being performed by organizations that
 have other address space directly registered to them by an RIR?<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Or 2) is nearly all hijacking being performed by entities that have no relationship with the RIR?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If 1) is true, then ARIN could theoretically revoke an organization’s registrations if they used address space that was not registered to them. We can of course debate whether we want RIRs to serve as adjudicators of what space RIR members
 are allowed to announce, but there would at least be something RIRs could do (kick non-cooperators out of the club of RIR registrants) to enforce their decisions if they decided to make them. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">But if 1) is false and 2) is true, then it’s not clear what ARIN could do about a case of BGP hijacking by someone who doesn’t have any ARIN resources registered to them. Can you think of anything we’d actually want ARIN to do in that case?<o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal"><br>
Unfortunately, I believe 1) is false and 2) is true. I'm open to evidence of the contrary, but without such evidence, I'm very skeptical of any proposal for the RIRs, especially ARIN, to be able to do anything meaningful about the situation. Without an enforceable
 contract with the wrongdoers, I don't see what ARIN or the other RIRs can do about the situation. <br>
 <o:p></o:p></p>
<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">ARIN’s only authority is to over their registry of who “has” which addresses, so the only thing I can imagine they could do would be to threaten to revoke unrelated registrations from a transit provider who willfully or negligently accepted
 the BGP announcement of space from an entity it wasn’t registered to. But if tier 1 transit providers aren’t willing to filter, let alone depeer, each other over hijacking today, it seems unlikely they’d be willing to stop accepting formerly legitimate prefixes
 from a peer or customer network just because ARIN is trying to take that space away to punish the network for accepting an unrelated hijacked announcement. <o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">One fundamental problem with any proposal for ARIN or the other RIRs to do anything about these situations, who determines who is responsible for the hijacking event, and to what standard of evidence must the finding be made. The preponderance
 of the evidence or beyond a reasonable doubt? Further, I think everyone agrees that Intent matters in these situations, accidents, and misunderstandings happen and will continue to happen. Deregistering resources because of an accident or a misunderstanding
 seems an unjust punishment and an overaction that will not likely withstand legal scrutiny by the inevitable lawsuit.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The fundamental difference between ARIN, and the other RIRs, and an actual government is that governments have sovereign immunity or state immunity. This is the idea a government cannot be sued without the permission of the government itself
 and they are not subject to the courts of other countries. Without such immunity, the actions of ARIN and the other RIRs are subject to review by at least the courts of the countries they exist in, if not also by the courts of the country where an aggrieved
 party lives. Further, if one of the RIRs were to be found to have acted unjustly in one of these situations, the legal repercussions are likely to threaten their very existence.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Having the RIRs decide these situations seems like it risks the existence of the RIRs, the courts or law enforcement resolving these situations and making lawful orders to the RIRs seems like the only resolution of these situations that
 doesn't risk the existence of the RIRs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <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>
<div>
<div id="m_-6688007103036184175gmail-m_8597544426812863049AppleMailSignature">
<div>
<p class="MsoNormal">Scott<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On May 2, 2019, at 7:18 AM, Adam Thompson <<a href="mailto:athompson@merlin.mb.ca" target="_blank">athompson@merlin.mb.ca</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Instead of focusing on whether the current proposal is or isn’t in scope, I suggest we re-cast the discussion as follows:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<ol start="1" type="1">
<li class="m-6688007103036184175gmail-m8597544426812863049msolistparagraph" style="mso-list:l0 level1 lfo1">
So far, we have unanimous community agreement that BGP hijacking is bad.<o:p></o:p></li><li class="m-6688007103036184175gmail-m8597544426812863049msolistparagraph" style="mso-list:l0 level1 lfo1">
So far, we have broad agreement that “something ought to be done” about BGP hijacking, although detailed opinions vary significantly.<o:p></o:p></li><li class="m-6688007103036184175gmail-m8597544426812863049msolistparagraph" style="mso-list:l0 level1 lfo1">
So what (else) <b><u>can</u></b> ARIN do about it?  (Caveat: the answer “<i>nothing</i>” is unacceptable to a significant proportion of PPML participants.)<o:p></o:p></li></ol>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">My suggested direction to the AC and/or the board would therefore be:  <b><i><u>Find</u></i></b> something ARIN can do to help combat the problem (more effectively).  If this requires
 expanding the scope of ARIN’s operations or policies, bring that back to the membership (possibly via PPML?) with the accompanying financial & legal analysis, as usual.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Now the question becomes: what is the most appropriate mechanism, within ARIN’s existing policies, to bring a request like that to the AC and/or Board?  It seems clear to me that
 the petition already underway here is not meeting, and will not meet, the needs of the community very well.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">-Adam<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span lang="EN-US" style="font-size:10.0pt;color:#44546A">Adam Thompson</span></b><span lang="EN-US" style="font-size:9.0pt;color:#44546A"><br>
Consultant, Infrastructure Services<br>
<b><image001.png></b><br>
100 - 135 Innovation Drive<br>
Winnipeg, MB, R3T 6A8<br>
(204) 977-6824 or 1-800-430-6404 (MB only)<br>
<a href="mailto:athompson@merlin.mb.ca" target="_blank">athompson@merlin.</a></span><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">===============================================<br>
David Farmer               <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">
Email:farmer@umn.edu</a><br>
Networking & Telecommunication Services<br>
Office of Information Technology<br>
University of Minnesota   <br>
2218 University Ave SE        Phone: 612-626-0815<br>
Minneapolis, MN 55414-3029   Cell: 612-812-9952<br>
=============================================== <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>