<div dir="ltr">All,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sure, but <a href="http://stat.ripe.net/" rel="noreferrer" target="_blank">stat.ripe.net</a>, <a href="http://bgp.he.net/" rel="noreferrer" target="_blank">bgp.he.net</a>, rpki, and many other sources are free<br>for everyone to access. :-)<br></blockquote><div><br></div><div>Having a copy of the table and see historical data doesn't automatically give one the ability to determine if a given announcement was a hijack.</div><div>I might strongly suspect that it was - sure. My personal suspicions should not be enough in this instance. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Honestly, i handed it back in late April. The IA and publishing took some<br>time... :-)<br>What i think supports what i wrote above is in Section 7.0, clause 1:<br>"The RIPE NCC will verify that a report contains sufficient information<br>before assigning it to a group of experts. If this is not the case, the<br>report will be dismissed."<br><br>Maybe it could be a bit clearer, or we could textually add "one event or a<br>handful of events is not enough".<br></blockquote><div>Stating that a single report isn't enough doesn't solve the issue. A thousand reports might not give enough quality information to justify an investigation; a single report from an authoritative source might. It is for this reason that - in order to save resources - I'm concerned with the amount of people who could potentially submit a report.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hence Section 7.0, clause 1 :-)<br></blockquote><div>Section 7 of the current draft gives the accused the opportunity to defend themselves as the second step, right after the NCC "verifies" the request. </div><div>The accused entity is still being "asked" (under pressure) to provide information on the basis of a report that may or may not have come from someone who actually knows about the situation.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sure. And i have already read the IA. All of it.<br></blockquote><div>OK. I've done the same. I still feel that the IA outlines a lot of issues and problems. At this time, I don't think that the potential benefits of the proposal outweigh the costs.</div><div><br></div><div>Jacob Slater</div><div> </div><div><br></div><div> <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 9, 2019 at 5:56 PM Carlos Friaças <<a href="mailto:cfriacas@fccn.pt">cfriacas@fccn.pt</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
Hi,<br>
<br>
<br>
On Mon, 9 Sep 2019, Jacob Slater wrote:<br>
<br>
> All,<br>
>       If it's *your* table, you should be able.<br>
> <br>
> Again, I disagree. Just because you have a copy of the routing table doesn't automatically put you in a position to know what is going on with each entry present in that table.<br>
<br>
Sure, but <a href="http://stat.ripe.net" rel="noreferrer" target="_blank">stat.ripe.net</a>, <a href="http://bgp.he.net" rel="noreferrer" target="_blank">bgp.he.net</a>, rpki, and many other sources are free <br>
for everyone to access. :-)<br>
<br>
<br>
>       But please keep in mind than one event or a handful of events shouldn't<br>
>       justify an investigation, or handing a case to "experts".<br>
> <br>
> The current policy proposal doesn't have text to support this.<br>
<br>
Honestly, i handed it back in late April. The IA and publishing took some <br>
time... :-)<br>
What i think supports what i wrote above is in Section 7.0, clause 1:<br>
"The RIPE NCC will verify that a report contains sufficient information <br>
before assigning it to a group of experts. If this is not the case, the <br>
report will be dismissed."<br>
<br>
Maybe it could be a bit clearer, or we could textually add "one event or a <br>
handful of events is not enough".<br>
<br>
<br>
<br>
>       If the issue is fixed and the issue originator isn't always the same, then<br>
>       no real need for an investigation. Maybe the amount of text on the current<br>
>       version fades a bit the two main concepts of "persistent" and<br>
>       "intentional".<br>
> <br>
> I am in agreement with you on this.<br>
><br>
>       There should be enough "trail" to justify starting an investigation...<br>
> <br>
> If the person submitting a report isn't in an authoritative position to say whether or not an announcement was a hijack, there isn't a good enough "trail" to justify starting an investigation.<br>
<br>
Hence Section 7.0, clause 1 :-)<br>
<br>
<br>
<br>
>        The "proposal". It's just a proposal...! :-)<br>
><br>
>        <br>
><br>
>       I agree that there isn't a way to measure how many people around the<br>
><br>
>       world would not resort to hijacking if this proposal was in place today <br>
> <br>
> My apologies for misspeaking on that one.  Any references I may have made to 2019-3 as a "policy" should read as "policy proposal".<br>
<br>
No harm done :-)<br>
<br>
<br>
> Just because a policy proposal has the chance to discourage bad actors doesn't mean we should ignore the potential consequences of implementing the proposal. <br>
<br>
Sure. And i have already read the IA. All of it.<br>
<br>
<br>
Regards,<br>
Carlos<br>
<br>
<br>
<br>
> Jacob Slater<br>
>  <br>
> <br>
> <br>
> On Mon, Sep 9, 2019 at 5:25 PM Carlos Friaças <<a href="mailto:cfriacas@fccn.pt" target="_blank">cfriacas@fccn.pt</a>> wrote:<br>
> <br>
><br>
>       Hi,<br>
> <br>
><br>
>       On Mon, 9 Sep 2019, Jacob Slater wrote:<br>
><br>
>       > All,<br>
>       >       If that happens, then potentially everyone can be a victim, yes.<br>
>       >       Then they should be able to place a report.<br>
>       ><br>
>       >  <br>
>       > I disagree. Just because you see what you think is a hijack in the full table doesn't mean you have enough information to justify a full investigation that is likely to consume valuable time and resources. <br>
><br>
>       If it's *your* table, you should be able.<br>
>       But please keep in mind than one event or a handful of events shouldn't<br>
>       justify an investigation, or handing a case to "experts".<br>
> <br>
><br>
>       >       Afaik, this is possible within LACNIC (i.e. through <a href="http://warp.lacnic.net" rel="noreferrer" target="_blank">warp.lacnic.net</a>). When<br>
>       >       the same proposal was discussed there, the yearly number of reports (if<br>
>       >       i'm not mistaken) was on the scale of dozens -- and they have a very high<br>
>       >       degree of helping stop/mitigate the incidents, almost close to 100%, which<br>
>       >       is fantastic!<br>
>       ><br>
>       >  <br>
>       > Being asked to fix an issue is very different from getting investigated for an issue with the potential for termination of membership.<br>
><br>
>       If the issue is fixed and the issue originator isn't always the same, then<br>
>       no real need for an investigation. Maybe the amount of text on the current<br>
>       version fades a bit the two main concepts of "persistent" and<br>
>       "intentional".<br>
> <br>
><br>
>       > While I haven't seen a proposal for establishing a system like LACNIC's WARP under RIPE, I'd be<br>
>       > open to the idea. <br>
><br>
>       Great. Does anyone think this is a bad idea?<br>
><br>
>       That would probably fall under the ncc-services-wg, so we'll have to see<br>
>       :-)<br>
> <br>
> <br>
><br>
>       >       I fail to identify exactly were the proposal describes such a need.<br>
>       >       Even so, the experts should be binded to NDAs... :-)<br>
>       ><br>
>       ><br>
>       > While having the experts under NDA is a step in the right direction, it still involves effectively being required to turn information over to external parties due to the suspicions of some random AS. My concern isn't so<br>
>       much that the<br>
>       > information will be leaked; my concern is that, fundamentally, being required to turn information over to a third party on someone's unsupported suspicions seems wrong. <br>
><br>
>       There should be enough "trail" to justify starting an investigation...<br>
> <br>
> <br>
><br>
>       > Right now, the policy seems to pull a large amount of resources and risk (per the impact analysis) without enough of a return. <br>
><br>
>       The "proposal". It's just a proposal...! :-)<br>
><br>
>       I agree that there isn't a way to measure how many people around the<br>
>       world would not resort to hijacking if this proposal was in place today<br>
>       :-)<br>
> <br>
><br>
>       Regards,<br>
>       Carlos<br>
> <br>
> <br>
> <br>
><br>
>       > Jacob Slater<br>
>       ><br>
>       ><br>
>       ><br>
>       >  <br>
>       ><br>
>       ><br>
>       > On Mon, Sep 9, 2019 at 3:45 PM Carlos Friaças <<a href="mailto:cfriacas@fccn.pt" target="_blank">cfriacas@fccn.pt</a>> wrote:<br>
>       ><br>
>       ><br>
>       >       On Thu, 5 Sep 2019, Jacob Slater wrote:<br>
>       ><br>
>       >       > All,<br>
>       ><br>
>       >       Hi Jacob, All,<br>
>       ><br>
>       ><br>
>       >       > Given the number of people who may submit a report (anyone receiving a<br>
>       >       > full table from their upstream(s), assuming the accused hijack makes it<br>
>       >       > into the DFZ),<br>
>       ><br>
>       >       If that happens, then potentially everyone can be a victim, yes.<br>
>       >       Then they should be able to place a report.<br>
>       >       But that's a fundamental part of why some changes are needed: it's not<br>
>       >       only the legitimate address space owner who is the victim of an hijack.<br>
>       >       People/networks whose packets are diverted by an hijack are also victims<br>
>       >       of traffic interception.<br>
>       ><br>
>       >       Afaik, this is possible within LACNIC (i.e. through <a href="http://warp.lacnic.net" rel="noreferrer" target="_blank">warp.lacnic.net</a>). When<br>
>       >       the same proposal was discussed there, the yearly number of reports (if<br>
>       >       i'm not mistaken) was on the scale of dozens -- and they have a very high<br>
>       >       degree of helping stop/mitigate the incidents, almost close to 100%, which<br>
>       >       is fantastic!<br>
>       ><br>
>       ><br>
>       >       > I'm still concerned that the proposed policy would cause more harm than<br>
>       >       > good. A random AS that happens to receive the announcement isn't in an<br>
>       >       > authoritative position to know if a given announcement was unauthorized.<br>
>       ><br>
>       >       I can fully agree that a system based on (possibly forged) LOAs, and<br>
>       >       unauthenticated IRR created the huge mess we are submerged in today...<br>
>       >       :(((<br>
>       ><br>
>       ><br>
>       >       > Putting them through a reporting process that might well require the<br>
>       >       > disclosure of internal information because of an unrelated<br>
>       >       > individual/group being suspicious is a problem.<br>
>       ><br>
>       >       I fail to identify exactly were the proposal describes such a need.<br>
>       >       Even so, the experts should be binded to NDAs... :-)<br>
>       ><br>
>       ><br>
>       >       Regards,<br>
>       >       Carlos<br>
>       ><br>
>       ><br>
>       ><br>
>       >       > Combined with the issues detailed in the Impact Analysis, I'm opposed to the policy as written.<br>
>       >       ><br>
>       >       > Jacob Slater<br>
>       >       ><br>
>       >       > On Thu, Sep 5, 2019 at 9:24 AM Marco Schmidt <<a href="mailto:mschmidt@ripe.net" target="_blank">mschmidt@ripe.net</a>> wrote:<br>
>       >       >       Dear colleagues,<br>
>       >       ><br>
>       >       >       Policy proposal 2019-03, "Resource Hijacking is a RIPE Policy Violation"<br>
>       >       >       is now in the Review Phase.<br>
>       >       ><br>
>       >       >       The goal of this proposal is to define that BGP hijacking is not<br>
>       >       >       accepted as normal practice within the RIPE NCC service region.<br>
>       >       ><br>
>       >       >       The proposal has been updated following the last round of discussion and<br>
>       >       >       is now at version v2.0. Some of the changes made to version v1.0 include:<br>
>       >       >       - Includes procedural steps for reporting and evaluation of potential<br>
>       >       >       hijacks<br>
>       >       >       - Provides guidelines for external experts<br>
>       >       >       - Adjusted title<br>
>       >       ><br>
>       >       >       The RIPE NCC has prepared an impact analysis on this latest proposal<br>
>       >       >       version to support the community?s discussion. You can find the full<br>
>       >       >       proposal and impact analysis at:<br>
>       >       >       <a href="https://www.ripe.net/participate/policies/proposals/2019-03" rel="noreferrer" target="_blank">https://www.ripe.net/participate/policies/proposals/2019-03</a><br>
>       >       >       <a href="https://www.ripe.net/participate/policies/proposals/2019-03#impact-analysis" rel="noreferrer" target="_blank">https://www.ripe.net/participate/policies/proposals/2019-03#impact-analysis</a><br>
>       >       ><br>
>       >       >       And the draft documents at:<br>
>       >       >       <a href="https://www.ripe.net/participate/policies/proposals/2019-03/draft" rel="noreferrer" target="_blank">https://www.ripe.net/participate/policies/proposals/2019-03/draft</a><br>
>       >       ><br>
>       >       >       As per the RIPE Policy Development Process (PDP), the purpose of this<br>
>       >       >       four week Review Phase is to continue discussion of the proposal, taking<br>
>       >       >       the impact analysis into consideration, and to review the full draft<br>
>       >       >       RIPE Policy Document.<br>
>       >       ><br>
>       >       >       At the end of the Review Phase, the Working Group (WG) Chairs will<br>
>       >       >       determine whether the WG has reached rough consensus. It is therefore<br>
>       >       >       important to provide your opinion, even if it is simply a restatement of<br>
>       >       >       your input from the previous phase.<br>
>       >       ><br>
>       >       >       We encourage you to read the proposal, impact analysis and draft<br>
>       >       >       document and send any comments to <<a href="mailto:anti-abuse-wg@ripe.net" target="_blank">anti-abuse-wg@ripe.net</a>> before 4<br>
>       >       >       October 2019.<br>
>       >       ><br>
>       >       ><br>
>       >       >       Kind regards,<br>
>       >       ><br>
>       >       >       Marco Schmidt<br>
>       >       >       Policy Officer<br>
>       >       >       RIPE NCC<br>
>       >       ><br>
>       >       ><br>
>       >       ><br>
>       >       ><br>
>       ><br>
>       ><br>
>       ><br>
> <br>
> <br>
></blockquote></div>