On Thu, 5 Sep 2019, Hank Nussbacher wrote:

On 05/09/2019 16:23, Marco Schmidt wrote:

"A.3.1. Reporting Only persons directly affected by a suspected hijack can report to the RIPE NCC that another party has announced resources registered to or used by the reporter without their consent. "

This thereby precludes any national CERT from reporting to the RIPE NCC any suspected hijacks since they are not directly affected.  Can this text be modified?

Hi Hank, All, If a national CERT receives an hijacked route, it *is* affected -- in the sense their packets will go towards a wrongful destination. Not sure if the issue is with "person" vs. "organization", but a person should be able to report it on behalf of an affected organization... Regards, Carlos

Regards, Hank

...

Dear colleagues,

Policy proposal 2019-03, "Resource Hijacking is a RIPE Policy Violation" is now in the Review Phase.

The goal of this proposal is to define that BGP hijacking is not accepted as normal practice within the RIPE NCC service region.

The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the changes made to version v1.0 include: - Includes procedural steps for reporting and evaluation of potential hijacks - Provides guidelines for external experts - Adjusted title

The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-03 https://www.ripe.net/participate/policies/proposals/2019-03#impact-analysis

And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-03/draft

As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.

At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.

We encourage you to read the proposal, impact analysis and draft document and send any comments to <anti-abuse-wg@ripe.net> before 4 October 2019.

Kind regards,

Marco Schmidt Policy Officer RIPE NCC

Hi Suresh, Hank, All, On Thu, 5 Sep 2019, Suresh Ramasubramanian wrote:

Hijacked route announcements can be carefully targeted to just a victim AS for any attack.

Yes, they can -- and several cases (as far as i read) were already seen when that was done over an IXP. But that doesn't mean that "hijacked" announcement has to be 100% invisible, e.g. if the victim AS is sharing their routing view with someone else... :-)

If that victim AS holder complains to their national CERT the language here precludes the CERT from reporting into RIPE.

It might, yes (and that's not optimal), but the victim AS folks could also theoretically do it by themselves...

That is a technicality as I can't imagine RIPE would refuse reports from a CERT, but it is worth fixing.

*Today*, is there any way for a CERT (National or not) or any victim AS to do it...? (I know that this is already possible in LACNIC. They have WARP -- <pub> https://warp.lacnic.net </pub>) Cheers, Carlos

On 05/09/19, 8:26 PM, "anti-abuse-wg on behalf of Carlos Friaças via anti-abuse-wg" <anti-abuse-wg-bounces@ripe.net on behalf of anti-abuse-wg@ripe.net> wrote:

On Thu, 5 Sep 2019, Hank Nussbacher wrote:

...

On 05/09/2019 16:23, Marco Schmidt wrote:

"A.3.1. Reporting Only persons directly affected by a suspected hijack can report to the RIPE NCC that another party has announced resources registered to or used by the reporter without their consent. "

This thereby precludes any national CERT from reporting to the RIPE NCC any suspected hijacks since they are not directly affected. Can this text be modified?

Hi Hank, All,

If a national CERT receives an hijacked route, it *is* affected -- in the sense their packets will go towards a wrongful destination.

Not sure if the issue is with "person" vs. "organization", but a person should be able to report it on behalf of an affected organization...

Regards, Carlos

...

Regards, Hank

...

Dear colleagues,

Policy proposal 2019-03, "Resource Hijacking is a RIPE Policy Violation" is now in the Review Phase.

The goal of this proposal is to define that BGP hijacking is not accepted as normal practice within the RIPE NCC service region.

The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the changes made to version v1.0 include: - Includes procedural steps for reporting and evaluation of potential hijacks - Provides guidelines for external experts - Adjusted title

The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-03 https://www.ripe.net/participate/policies/proposals/2019-03#impact-analysis

And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-03/draft

As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.

At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.

We encourage you to read the proposal, impact analysis and draft document and send any comments to <anti-abuse-wg@ripe.net> before 4 October 2019.

Kind regards,

Marco Schmidt Policy Officer RIPE NCC

Support the withdrawal. -- Sergey Thursday, September 5, 2019, 6:31:28 PM, you wrote:

...

I'd like to suggest to the chairs that this proposal be formally dropped.

RB> please RB> randy

Hi Richard, All, On Thu, 5 Sep 2019, Richard Clayton wrote: (...)

BTW: it should be noted that the ARIN Board of Trustees threw out the same proposal when it was made there...

https://www.arin.net/about/welcome/board/meetings/2019_0620/

The story is a bit longer than that (involves the AC, a petition and then the BoT), but yes, they did. Their PDP has some differences too...

... also (on a brighter note), although law enforcement does move slowly in this space, it does indeed move.

https://krebsonsecurity.com/2019/09/feds-allege-adconion-employees- hijacked-ip-addresses-for-spamming/

This is from ARIN-land. Do you see any chance of something similar within the RIPE NCC service region reaching a court of law?

(and there a couple more cases in the pipeline).

Any of them outside ARIN-land...? Regards, Carlos

-- richard Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

I fully agree with Nick. Drop it like its hot ... Erik Bais

Op 5 sep. 2019 om 18:15 heeft Nick Hilliard <nick@foobar.org> het volgende geschreven:

I'd like to suggest to the chairs that this proposal be formally dropped.

Hi Michele, All, Can you be more specific about which problems derive from this proposal's simple existence...? About: "going to cost more" -- when you try to improve something, it's generally not cheaper, yes. but then there is "worth", which generates different views. (...) The "causes more harms" bit is mostly derived from the possibility of lawsuits...? Regards, Carlos On Mon, 9 Sep 2019, Michele Neylon - Blacknight wrote:

100% agreed

This proposal should be dropped as it's creating more problems, going to cost more and generally causes more harms than those it was aimed to solve.

-- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845

On 05/09/2019, 17:15, "anti-abuse-wg on behalf of Nick Hilliard" <anti-abuse-wg-bounces@ripe.net on behalf of nick@foobar.org> wrote:

Marco Schmidt wrote on 05/09/2019 14:23:

...

The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-03

that is as damning an impact analysis as I've ever seen, and it sends a clear signal that the proposal would not solve the root problem while simultaneously being very harmful to the RIPE NCC.

I'd like to suggest to the chairs that this proposal be formally dropped. It's taken up a good deal of working group time at this point and there is an obvious lack of consensus that the proposal should be adopted as a policy.

Nick

On Mon, 9 Sep 2019, Michele Neylon - Blacknight wrote:

Carlos

Hi Michele, All,

Nick and others have covered why it should be dropped in their emails to this list.

Quoting from Nick's: " that is as damning an impact analysis as I've ever seen, and it sends a clear signal that the proposal would not solve the root problem while simultaneously being very harmful to the RIPE NCC. I'd like to suggest to the chairs that this proposal be formally dropped. It's taken up a good deal of working group time at this point and there is an obvious lack of consensus that the proposal should be adopted as a policy. Nick " I simply read "very harmful" as "the possibility of lawsuits against RIPE NCC". Lawsuits can happen if you have the rules; if the rules are bad (or badly followed) or by the abscence of them (now...). So i don't really agree with "very harmful". The impact analysis points to a broad set of issues, YES, which we (the co-authors) may decide to address or not.

It's also pretty clear that the cost implications of this proposal far outweigh any potential benefit.

Perhaps i missed the numbers. I only read in the IA about "significant finantial impact" (depending on the # of reports received) and "significant cost factor" (from liability insurance).

So it should just be dropped.

And your counterargument about cost is completely divorced from economic reality.

I haven't really seen a price tag. The acceptance of that price tag will depend on the viewpoint -- a victim's viewpoint will certainly tolerate a higher price tag ;-)

RIPE NCC are not the routing police.

Of course not. Here we can agree. But the RIPE NCC already provides some means to identify who is actually breaking the *unwritten* rule that hijacks are not tolerated, and it could do a lot more (imho) for its community at large, the end-users, by removing hijackers from the system after they are *undoubtably* identified. :-) Regards, Carlos

Regards

Michele

-- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845

On 09/09/2019, 15:53, "Carlos Friaças" <cfriacas@fccn.pt> wrote:

Hi Michele, All,

Can you be more specific about which problems derive from this proposal's simple existence...?

About: "going to cost more" -- when you try to improve something, it's generally not cheaper, yes. but then there is "worth", which generates different views.

(...) The "causes more harms" bit is mostly derived from the possibility of lawsuits...?

Regards, Carlos

On Mon, 9 Sep 2019, Michele Neylon - Blacknight wrote:

...

100% agreed

This proposal should be dropped as it's creating more problems, going to cost more and generally causes more harms than those it was aimed to solve.

-- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845

On 05/09/2019, 17:15, "anti-abuse-wg on behalf of Nick Hilliard" <anti-abuse-wg-bounces@ripe.net on behalf of nick@foobar.org> wrote:

Marco Schmidt wrote on 05/09/2019 14:23:

...

The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-03

that is as damning an impact analysis as I've ever seen, and it sends a clear signal that the proposal would not solve the root problem while simultaneously being very harmful to the RIPE NCC.

I'd like to suggest to the chairs that this proposal be formally dropped. It's taken up a good deal of working group time at this point and there is an obvious lack of consensus that the proposal should be adopted as a policy.

Nick

On Thu, 5 Sep 2019, Jacob Slater wrote:

All,

Hi Jacob, All,

Given the number of people who may submit a report (anyone receiving a full table from their upstream(s), assuming the accused hijack makes it into the DFZ),

If that happens, then potentially everyone can be a victim, yes. Then they should be able to place a report. But that's a fundamental part of why some changes are needed: it's not only the legitimate address space owner who is the victim of an hijack. People/networks whose packets are diverted by an hijack are also victims of traffic interception. Afaik, this is possible within LACNIC (i.e. through warp.lacnic.net). When the same proposal was discussed there, the yearly number of reports (if i'm not mistaken) was on the scale of dozens -- and they have a very high degree of helping stop/mitigate the incidents, almost close to 100%, which is fantastic!

I'm still concerned that the proposed policy would cause more harm than good. A random AS that happens to receive the announcement isn't in an authoritative position to know if a given announcement was unauthorized.

I can fully agree that a system based on (possibly forged) LOAs, and unauthenticated IRR created the huge mess we are submerged in today... :(((

Putting them through a reporting process that might well require the disclosure of internal information because of an unrelated individual/group being suspicious is a problem.

I fail to identify exactly were the proposal describes such a need. Even so, the experts should be binded to NDAs... :-) Regards, Carlos

Combined with the issues detailed in the Impact Analysis, I'm opposed to the policy as written.

Jacob Slater

On Thu, Sep 5, 2019 at 9:24 AM Marco Schmidt <mschmidt@ripe.net> wrote: Dear colleagues,

Policy proposal 2019-03, "Resource Hijacking is a RIPE Policy Violation" is now in the Review Phase.

The goal of this proposal is to define that BGP hijacking is not accepted as normal practice within the RIPE NCC service region.

The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the changes made to version v1.0 include: - Includes procedural steps for reporting and evaluation of potential hijacks - Provides guidelines for external experts - Adjusted title

The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-03 https://www.ripe.net/participate/policies/proposals/2019-03#impact-analysis

And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-03/draft

As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.

At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.

We encourage you to read the proposal, impact analysis and draft document and send any comments to <anti-abuse-wg@ripe.net> before 4 October 2019.

Kind regards,

Marco Schmidt Policy Officer RIPE NCC

Hi, On Mon, 9 Sep 2019, Jacob Slater wrote:

All, If that happens, then potentially everyone can be a victim, yes. Then they should be able to place a report.

  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. 

If it's *your* table, you should be able. But please keep in mind than one event or a handful of events shouldn't justify an investigation, or handing a case to "experts".

Afaik, this is possible within LACNIC (i.e. through warp.lacnic.net). When the same proposal was discussed there, the yearly number of reports (if i'm not mistaken) was on the scale of dozens -- and they have a very high degree of helping stop/mitigate the incidents, almost close to 100%, which is fantastic!

  Being asked to fix an issue is very different from getting investigated for an issue with the potential for termination of membership.

If the issue is fixed and the issue originator isn't always the same, then no real need for an investigation. Maybe the amount of text on the current version fades a bit the two main concepts of "persistent" and "intentional".

While I haven't seen a proposal for establishing a system like LACNIC's WARP under RIPE, I'd be open to the idea. 

Great. Does anyone think this is a bad idea? That would probably fall under the ncc-services-wg, so we'll have to see :-)

I fail to identify exactly were the proposal describes such a need. Even so, the experts should be binded to NDAs... :-)

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 much that the 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. 

There should be enough "trail" to justify starting an investigation...

Right now, the policy seems to pull a large amount of resources and risk (per the impact analysis) without enough of a return. 

The "proposal". It's just a proposal...! :-) I agree that there isn't a way to measure how many people around the world would not resort to hijacking if this proposal was in place today :-) Regards, Carlos

Jacob Slater

 

On Mon, Sep 9, 2019 at 3:45 PM Carlos Friaças <cfriacas@fccn.pt> wrote:

On Thu, 5 Sep 2019, Jacob Slater wrote:

> All,

Hi Jacob, All,

> Given the number of people who may submit a report (anyone receiving a > full table from their upstream(s), assuming the accused hijack makes it > into the DFZ),

If that happens, then potentially everyone can be a victim, yes. Then they should be able to place a report. But that's a fundamental part of why some changes are needed: it's not only the legitimate address space owner who is the victim of an hijack. People/networks whose packets are diverted by an hijack are also victims of traffic interception.

Afaik, this is possible within LACNIC (i.e. through warp.lacnic.net). When the same proposal was discussed there, the yearly number of reports (if i'm not mistaken) was on the scale of dozens -- and they have a very high degree of helping stop/mitigate the incidents, almost close to 100%, which is fantastic!

> I'm still concerned that the proposed policy would cause more harm than > good. A random AS that happens to receive the announcement isn't in an > authoritative position to know if a given announcement was unauthorized.

I can fully agree that a system based on (possibly forged) LOAs, and unauthenticated IRR created the huge mess we are submerged in today... :(((

> Putting them through a reporting process that might well require the > disclosure of internal information because of an unrelated > individual/group being suspicious is a problem.

I fail to identify exactly were the proposal describes such a need. Even so, the experts should be binded to NDAs... :-)

Regards, Carlos

> Combined with the issues detailed in the Impact Analysis, I'm opposed to the policy as written. > > Jacob Slater > > On Thu, Sep 5, 2019 at 9:24 AM Marco Schmidt <mschmidt@ripe.net> wrote: >       Dear colleagues, > >       Policy proposal 2019-03, "Resource Hijacking is a RIPE Policy Violation" >       is now in the Review Phase. > >       The goal of this proposal is to define that BGP hijacking is not >       accepted as normal practice within the RIPE NCC service region. > >       The proposal has been updated following the last round of discussion and >       is now at version v2.0. Some of the changes made to version v1.0 include: >       - Includes procedural steps for reporting and evaluation of potential >       hijacks >       - Provides guidelines for external experts >       - Adjusted title > >       The RIPE NCC has prepared an impact analysis on this latest proposal >       version to support the community?s discussion. You can find the full >       proposal and impact analysis at: >       https://www.ripe.net/participate/policies/proposals/2019-03 >       https://www.ripe.net/participate/policies/proposals/2019-03#impact-analysis > >       And the draft documents at: >       https://www.ripe.net/participate/policies/proposals/2019-03/draft > >       As per the RIPE Policy Development Process (PDP), the purpose of this >       four week Review Phase is to continue discussion of the proposal, taking >       the impact analysis into consideration, and to review the full draft >       RIPE Policy Document. > >       At the end of the Review Phase, the Working Group (WG) Chairs will >       determine whether the WG has reached rough consensus. It is therefore >       important to provide your opinion, even if it is simply a restatement of >       your input from the previous phase. > >       We encourage you to read the proposal, impact analysis and draft >       document and send any comments to <anti-abuse-wg@ripe.net> before 4 >       October 2019. > > >       Kind regards, > >       Marco Schmidt >       Policy Officer >       RIPE NCC > > > >

Hi, On Mon, 9 Sep 2019, Jacob Slater wrote:

All, If it's *your* table, you should be able.

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.

Sure, but stat.ripe.net, bgp.he.net, rpki, and many other sources are free for everyone to access. :-)

But please keep in mind than one event or a handful of events shouldn't justify an investigation, or handing a case to "experts".

The current policy proposal doesn't have text to support this.

Honestly, i handed it back in late April. The IA and publishing took some time... :-) What i think supports what i wrote above is in Section 7.0, clause 1: "The RIPE NCC will verify that a report contains sufficient information before assigning it to a group of experts. If this is not the case, the report will be dismissed." Maybe it could be a bit clearer, or we could textually add "one event or a handful of events is not enough".

If the issue is fixed and the issue originator isn't always the same, then no real need for an investigation. Maybe the amount of text on the current version fades a bit the two main concepts of "persistent" and "intentional".

I am in agreement with you on this.

There should be enough "trail" to justify starting an investigation...

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.

Hence Section 7.0, clause 1 :-)

 The "proposal". It's just a proposal...! :-)

 

I agree that there isn't a way to measure how many people around the

world would not resort to hijacking if this proposal was in place today 

My apologies for misspeaking on that one.  Any references I may have made to 2019-3 as a "policy" should read as "policy proposal".

No harm done :-)

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. 

Sure. And i have already read the IA. All of it. Regards, Carlos

Jacob Slater  

On Mon, Sep 9, 2019 at 5:25 PM Carlos Friaças <cfriacas@fccn.pt> wrote:

Hi,

On Mon, 9 Sep 2019, Jacob Slater wrote:

> All, >       If that happens, then potentially everyone can be a victim, yes. >       Then they should be able to place a report. > >   > 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. 

If it's *your* table, you should be able. But please keep in mind than one event or a handful of events shouldn't justify an investigation, or handing a case to "experts".

>       Afaik, this is possible within LACNIC (i.e. through warp.lacnic.net). When >       the same proposal was discussed there, the yearly number of reports (if >       i'm not mistaken) was on the scale of dozens -- and they have a very high >       degree of helping stop/mitigate the incidents, almost close to 100%, which >       is fantastic! > >   > Being asked to fix an issue is very different from getting investigated for an issue with the potential for termination of membership.

If the issue is fixed and the issue originator isn't always the same, then no real need for an investigation. Maybe the amount of text on the current version fades a bit the two main concepts of "persistent" and "intentional".

> While I haven't seen a proposal for establishing a system like LACNIC's WARP under RIPE, I'd be > open to the idea. 

Great. Does anyone think this is a bad idea?

That would probably fall under the ncc-services-wg, so we'll have to see :-)

>       I fail to identify exactly were the proposal describes such a need. >       Even so, the experts should be binded to NDAs... :-) > > > 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 much that the > 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. 

There should be enough "trail" to justify starting an investigation...

> Right now, the policy seems to pull a large amount of resources and risk (per the impact analysis) without enough of a return. 

The "proposal". It's just a proposal...! :-)

I agree that there isn't a way to measure how many people around the world would not resort to hijacking if this proposal was in place today :-)

Regards, Carlos

> Jacob Slater > > > >   > > > On Mon, Sep 9, 2019 at 3:45 PM Carlos Friaças <cfriacas@fccn.pt> wrote: > > >       On Thu, 5 Sep 2019, Jacob Slater wrote: > >       > All, > >       Hi Jacob, All, > > >       > Given the number of people who may submit a report (anyone receiving a >       > full table from their upstream(s), assuming the accused hijack makes it >       > into the DFZ), > >       If that happens, then potentially everyone can be a victim, yes. >       Then they should be able to place a report. >       But that's a fundamental part of why some changes are needed: it's not >       only the legitimate address space owner who is the victim of an hijack. >       People/networks whose packets are diverted by an hijack are also victims >       of traffic interception. > >       Afaik, this is possible within LACNIC (i.e. through warp.lacnic.net). When >       the same proposal was discussed there, the yearly number of reports (if >       i'm not mistaken) was on the scale of dozens -- and they have a very high >       degree of helping stop/mitigate the incidents, almost close to 100%, which >       is fantastic! > > >       > I'm still concerned that the proposed policy would cause more harm than >       > good. A random AS that happens to receive the announcement isn't in an >       > authoritative position to know if a given announcement was unauthorized. > >       I can fully agree that a system based on (possibly forged) LOAs, and >       unauthenticated IRR created the huge mess we are submerged in today... >       :((( > > >       > Putting them through a reporting process that might well require the >       > disclosure of internal information because of an unrelated >       > individual/group being suspicious is a problem. > >       I fail to identify exactly were the proposal describes such a need. >       Even so, the experts should be binded to NDAs... :-) > > >       Regards, >       Carlos > > > >       > Combined with the issues detailed in the Impact Analysis, I'm opposed to the policy as written. >       > >       > Jacob Slater >       > >       > On Thu, Sep 5, 2019 at 9:24 AM Marco Schmidt <mschmidt@ripe.net> wrote: >       >       Dear colleagues, >       > >       >       Policy proposal 2019-03, "Resource Hijacking is a RIPE Policy Violation" >       >       is now in the Review Phase. >       > >       >       The goal of this proposal is to define that BGP hijacking is not >       >       accepted as normal practice within the RIPE NCC service region. >       > >       >       The proposal has been updated following the last round of discussion and >       >       is now at version v2.0. Some of the changes made to version v1.0 include: >       >       - Includes procedural steps for reporting and evaluation of potential >       >       hijacks >       >       - Provides guidelines for external experts >       >       - Adjusted title >       > >       >       The RIPE NCC has prepared an impact analysis on this latest proposal >       >       version to support the community?s discussion. You can find the full >       >       proposal and impact analysis at: >       >       https://www.ripe.net/participate/policies/proposals/2019-03 >       >       https://www.ripe.net/participate/policies/proposals/2019-03#impact-analysis >       > >       >       And the draft documents at: >       >       https://www.ripe.net/participate/policies/proposals/2019-03/draft >       > >       >       As per the RIPE Policy Development Process (PDP), the purpose of this >       >       four week Review Phase is to continue discussion of the proposal, taking >       >       the impact analysis into consideration, and to review the full draft >       >       RIPE Policy Document. >       > >       >       At the end of the Review Phase, the Working Group (WG) Chairs will >       >       determine whether the WG has reached rough consensus. It is therefore >       >       important to provide your opinion, even if it is simply a restatement of >       >       your input from the previous phase. >       > >       >       We encourage you to read the proposal, impact analysis and draft >       >       document and send any comments to <anti-abuse-wg@ripe.net> before 4 >       >       October 2019. >       > >       > >       >       Kind regards, >       > >       >       Marco Schmidt >       >       Policy Officer >       >       RIPE NCC >       > >       > >       > >       > > > >

Hello, As the RIPE NCC's IA shows (imho), the proposed process is not perfect. The main goal of having a process to start with was to allow some action regarding evident cases, and i hope people will agree that significant effort was made to accomodate comments during v1's discussion. We tried to add more "safety knobs", because we felt that a wrong decision (by experts) would be a really, really bad thing, and we wanted to avoid that -- even knowing that sometimes even courts do get it wrong _and_ that ONE 'guilty of hijacking' case wouldn't result immediately in a LIR terminating process. In the case there were no doubts that someone/some company was doing this (i.e. a 'guilty' conclusion), the expected outcome would be for that member to stop that behaviour from that point forward. Regards, Carlos On Mon, 9 Sep 2019, Jacob Slater wrote:

All, Sure, but stat.ripe.net, bgp.he.net, rpki, and many other sources are free for everyone to access. :-)

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. I might strongly suspect that it was - sure. My personal suspicions should not be enough in this instance. 

Honestly, i handed it back in late April. The IA and publishing took some time... :-) What i think supports what i wrote above is in Section 7.0, clause 1: "The RIPE NCC will verify that a report contains sufficient information before assigning it to a group of experts. If this is not the case, the report will be dismissed."

Maybe it could be a bit clearer, or we could textually add "one event or a handful of events is not enough".

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.

Hence Section 7.0, clause 1 :-)

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.  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.

Sure. And i have already read the IA. All of it.

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.

Jacob Slater  

 

On Mon, Sep 9, 2019 at 5:56 PM Carlos Friaças <cfriacas@fccn.pt> wrote:

Hi,

On Mon, 9 Sep 2019, Jacob Slater wrote:

> All, >       If it's *your* table, you should be able. > > 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.

Sure, but stat.ripe.net, bgp.he.net, rpki, and many other sources are free for everyone to access. :-)

>       But please keep in mind than one event or a handful of events shouldn't >       justify an investigation, or handing a case to "experts". > > The current policy proposal doesn't have text to support this.

Honestly, i handed it back in late April. The IA and publishing took some time... :-) What i think supports what i wrote above is in Section 7.0, clause 1: "The RIPE NCC will verify that a report contains sufficient information before assigning it to a group of experts. If this is not the case, the report will be dismissed."

Maybe it could be a bit clearer, or we could textually add "one event or a handful of events is not enough".

>       If the issue is fixed and the issue originator isn't always the same, then >       no real need for an investigation. Maybe the amount of text on the current >       version fades a bit the two main concepts of "persistent" and >       "intentional". > > I am in agreement with you on this. > >       There should be enough "trail" to justify starting an investigation... > > 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.

Hence Section 7.0, clause 1 :-)

>        The "proposal". It's just a proposal...! :-) > >         > >       I agree that there isn't a way to measure how many people around the > >       world would not resort to hijacking if this proposal was in place today  > > My apologies for misspeaking on that one.  Any references I may have made to 2019-3 as a "policy" should read as "policy proposal".

No harm done :-)

> 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. 

Sure. And i have already read the IA. All of it.

Regards, Carlos

> Jacob Slater >   > > > On Mon, Sep 9, 2019 at 5:25 PM Carlos Friaças <cfriacas@fccn.pt> wrote: > > >       Hi, > > >       On Mon, 9 Sep 2019, Jacob Slater wrote: > >       > All, >       >       If that happens, then potentially everyone can be a victim, yes. >       >       Then they should be able to place a report. >       > >       >   >       > 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.  > >       If it's *your* table, you should be able. >       But please keep in mind than one event or a handful of events shouldn't >       justify an investigation, or handing a case to "experts". > > >       >       Afaik, this is possible within LACNIC (i.e. through warp.lacnic.net). When >       >       the same proposal was discussed there, the yearly number of reports (if >       >       i'm not mistaken) was on the scale of dozens -- and they have a very high >       >       degree of helping stop/mitigate the incidents, almost close to 100%, which >       >       is fantastic! >       > >       >   >       > Being asked to fix an issue is very different from getting investigated for an issue with the potential for termination of membership. > >       If the issue is fixed and the issue originator isn't always the same, then >       no real need for an investigation. Maybe the amount of text on the current >       version fades a bit the two main concepts of "persistent" and >       "intentional". > > >       > While I haven't seen a proposal for establishing a system like LACNIC's WARP under RIPE, I'd be >       > open to the idea.  > >       Great. Does anyone think this is a bad idea? > >       That would probably fall under the ncc-services-wg, so we'll have to see >       :-) > > > >       >       I fail to identify exactly were the proposal describes such a need. >       >       Even so, the experts should be binded to NDAs... :-) >       > >       > >       > 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 >       much that the >       > 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.  > >       There should be enough "trail" to justify starting an investigation... > > > >       > Right now, the policy seems to pull a large amount of resources and risk (per the impact analysis) without enough of a return.  > >       The "proposal". It's just a proposal...! :-) > >       I agree that there isn't a way to measure how many people around the >       world would not resort to hijacking if this proposal was in place today >       :-) > > >       Regards, >       Carlos > > > > >       > Jacob Slater >       > >       > >       > >       >   >       > >       > >       > On Mon, Sep 9, 2019 at 3:45 PM Carlos Friaças <cfriacas@fccn.pt> wrote: >       > >       > >       >       On Thu, 5 Sep 2019, Jacob Slater wrote: >       > >       >       > All, >       > >       >       Hi Jacob, All, >       > >       > >       >       > Given the number of people who may submit a report (anyone receiving a >       >       > full table from their upstream(s), assuming the accused hijack makes it >       >       > into the DFZ), >       > >       >       If that happens, then potentially everyone can be a victim, yes. >       >       Then they should be able to place a report. >       >       But that's a fundamental part of why some changes are needed: it's not >       >       only the legitimate address space owner who is the victim of an hijack. >       >       People/networks whose packets are diverted by an hijack are also victims >       >       of traffic interception. >       > >       >       Afaik, this is possible within LACNIC (i.e. through warp.lacnic.net). When >       >       the same proposal was discussed there, the yearly number of reports (if >       >       i'm not mistaken) was on the scale of dozens -- and they have a very high >       >       degree of helping stop/mitigate the incidents, almost close to 100%, which >       >       is fantastic! >       > >       > >       >       > I'm still concerned that the proposed policy would cause more harm than >       >       > good. A random AS that happens to receive the announcement isn't in an >       >       > authoritative position to know if a given announcement was unauthorized. >       > >       >       I can fully agree that a system based on (possibly forged) LOAs, and >       >       unauthenticated IRR created the huge mess we are submerged in today... >       >       :((( >       > >       > >       >       > Putting them through a reporting process that might well require the >       >       > disclosure of internal information because of an unrelated >       >       > individual/group being suspicious is a problem. >       > >       >       I fail to identify exactly were the proposal describes such a need. >       >       Even so, the experts should be binded to NDAs... :-) >       > >       > >       >       Regards, >       >       Carlos >       > >       > >       > >       >       > Combined with the issues detailed in the Impact Analysis, I'm opposed to the policy as written. >       >       > >       >       > Jacob Slater >       >       > >       >       > On Thu, Sep 5, 2019 at 9:24 AM Marco Schmidt <mschmidt@ripe.net> wrote: >       >       >       Dear colleagues, >       >       > >       >       >       Policy proposal 2019-03, "Resource Hijacking is a RIPE Policy Violation" >       >       >       is now in the Review Phase. >       >       > >       >       >       The goal of this proposal is to define that BGP hijacking is not >       >       >       accepted as normal practice within the RIPE NCC service region. >       >       > >       >       >       The proposal has been updated following the last round of discussion and >       >       >       is now at version v2.0. Some of the changes made to version v1.0 include: >       >       >       - Includes procedural steps for reporting and evaluation of potential >       >       >       hijacks >       >       >       - Provides guidelines for external experts >       >       >       - Adjusted title >       >       > >       >       >       The RIPE NCC has prepared an impact analysis on this latest proposal >       >       >       version to support the community?s discussion. You can find the full >       >       >       proposal and impact analysis at: >       >       >       https://www.ripe.net/participate/policies/proposals/2019-03 >       >       >       https://www.ripe.net/participate/policies/proposals/2019-03#impact-analysis >       >       > >       >       >       And the draft documents at: >       >       >       https://www.ripe.net/participate/policies/proposals/2019-03/draft >       >       > >       >       >       As per the RIPE Policy Development Process (PDP), the purpose of this >       >       >       four week Review Phase is to continue discussion of the proposal, taking >       >       >       the impact analysis into consideration, and to review the full draft >       >       >       RIPE Policy Document. >       >       > >       >       >       At the end of the Review Phase, the Working Group (WG) Chairs will >       >       >       determine whether the WG has reached rough consensus. It is therefore >       >       >       important to provide your opinion, even if it is simply a restatement of >       >       >       your input from the previous phase. >       >       > >       >       >       We encourage you to read the proposal, impact analysis and draft >       >       >       document and send any comments to <anti-abuse-wg@ripe.net> before 4 >       >       >       October 2019. >       >       > >       >       > >       >       >       Kind regards, >       >       > >       >       >       Marco Schmidt >       >       >       Policy Officer >       >       >       RIPE NCC >       >       > >       >       > >       >       > >       >       > >       > >       > >       > > > >

You are right. I have very little hope of anything concrete coming out of this process, however. On 10/09/19, 4:04 PM, "anti-abuse-wg on behalf of Sérgio Rocha" <anti-abuse-wg-bounces@ripe.net on behalf of sergio.rocha@makeitsimple.pt> wrote: Hi, I agree with Carlos. It is better to have an imperfect policy than not to have any policy and watch these hijacks helplessly in the front row. I can't understand why some people resist having a policy that create a response to those who break the chain of trust on which the internet is based, we can't keep looking at abusers and think it's okay, one of this days will be your network, your client. There are many hijacks that are claimed by the true owners of space and we cannot let these abusers, usually are always the same, remain members, we need to have policies to fight. At RIPE meetings I always hear a lot of people talking about the inability to have any response to these events and when we hear the impact of these actions we realize than something has to be done, it may be not consensual a first version, but all supporters are certain that improvements will be made in the future. Finally, if we do not want nations and governmental laws to regulate the internet, it has to be via entities like RIPE to bring regulation, otherwise we will lose control of the internet and it will start to be controlled by governments. (they are waiting for us to fail) Regards, Sérgio -----Original Message----- From: anti-abuse-wg [mailto:anti-abuse-wg-bounces@ripe.net] On Behalf Of Carlos Friaças via anti-abuse-wg Sent: 10 de setembro de 2019 08:26 To: Jacob Slater <jacob@rezero.org> Cc: anti-abuse-wg@ripe.net Subject: Re: [anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation) Hello, As the RIPE NCC's IA shows (imho), the proposed process is not perfect. The main goal of having a process to start with was to allow some action regarding evident cases, and i hope people will agree that significant effort was made to accomodate comments during v1's discussion. We tried to add more "safety knobs", because we felt that a wrong decision (by experts) would be a really, really bad thing, and we wanted to avoid that -- even knowing that sometimes even courts do get it wrong _and_ that ONE 'guilty of hijacking' case wouldn't result immediately in a LIR terminating process. In the case there were no doubts that someone/some company was doing this (i.e. a 'guilty' conclusion), the expected outcome would be for that member to stop that behaviour from that point forward. Regards, Carlos On Mon, 9 Sep 2019, Jacob Slater wrote: > All, > Sure, but stat.ripe.net, bgp.he.net, rpki, and many other sources are free > for everyone to access. :-) > > > 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. > I might strongly suspect that it was - sure. My personal suspicions > should not be enough in this instance. > > Honestly, i handed it back in late April. The IA and publishing took some > time... :-) > What i think supports what i wrote above is in Section 7.0, clause 1: > "The RIPE NCC will verify that a report contains sufficient information > before assigning it to a group of experts. If this is not the case, the > report will be dismissed." > > Maybe it could be a bit clearer, or we could textually add "one event or a > handful of events is not enough". > > 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. > > Hence Section 7.0, clause 1 :-) > > 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. > 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. > > Sure. And i have already read the IA. All of it. > > 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. > > Jacob Slater > > > > > On Mon, Sep 9, 2019 at 5:56 PM Carlos Friaças <cfriacas@fccn.pt> wrote: > > > Hi, > > > On Mon, 9 Sep 2019, Jacob Slater wrote: > > > All, > > If it's *your* table, you should be able. > > > > 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. > > Sure, but stat.ripe.net, bgp.he.net, rpki, and many other sources are free > for everyone to access. :-) > > > > But please keep in mind than one event or a handful of events shouldn't > > justify an investigation, or handing a case to "experts". > > > > The current policy proposal doesn't have text to support this. > > Honestly, i handed it back in late April. The IA and publishing took some > time... :-) > What i think supports what i wrote above is in Section 7.0, clause 1: > "The RIPE NCC will verify that a report contains sufficient information > before assigning it to a group of experts. If this is not the case, the > report will be dismissed." > > Maybe it could be a bit clearer, or we could textually add "one event or a > handful of events is not enough". > > > > > If the issue is fixed and the issue originator isn't always the same, then > > no real need for an investigation. Maybe the amount of text on the current > > version fades a bit the two main concepts of "persistent" and > > "intentional". > > > > I am in agreement with you on this. > > > > There should be enough "trail" to justify starting an investigation... > > > > 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. > > Hence Section 7.0, clause 1 :-) > > > > > The "proposal". It's just a proposal...! :-) > > > > > > > > I agree that there isn't a way to measure how many people around the > > > > world would not resort to hijacking if this proposal was in place today > > > > My apologies for misspeaking on that one. Any references I may have made to 2019-3 as a "policy" should read as > "policy proposal". > > No harm done :-) > > > > 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. > > Sure. And i have already read the IA. All of it. > > > Regards, > Carlos > > > > > Jacob Slater > > > > > > > > On Mon, Sep 9, 2019 at 5:25 PM Carlos Friaças <cfriacas@fccn.pt> wrote: > > > > > > Hi, > > > > > > On Mon, 9 Sep 2019, Jacob Slater wrote: > > > > > All, > > > If that happens, then potentially everyone can be a victim, yes. > > > Then they should be able to place a report. > > > > > > > > > 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. > > > > If it's *your* table, you should be able. > > But please keep in mind than one event or a handful of events shouldn't > > justify an investigation, or handing a case to "experts". > > > > > > > Afaik, this is possible within LACNIC (i.e. through warp.lacnic.net). When > > > the same proposal was discussed there, the yearly number of reports (if > > > i'm not mistaken) was on the scale of dozens -- and they have a very high > > > degree of helping stop/mitigate the incidents, almost close to 100%, which > > > is fantastic! > > > > > > > > > Being asked to fix an issue is very different from getting investigated for an issue with the potential for > termination of membership. > > > > If the issue is fixed and the issue originator isn't always the same, then > > no real need for an investigation. Maybe the amount of text on the current > > version fades a bit the two main concepts of "persistent" and > > "intentional". > > > > > > > While I haven't seen a proposal for establishing a system like LACNIC's WARP under RIPE, I'd be > > > open to the idea. > > > > Great. Does anyone think this is a bad idea? > > > > That would probably fall under the ncc-services-wg, so we'll have to see > > :-) > > > > > > > > > I fail to identify exactly were the proposal describes such a need. > > > Even so, the experts should be binded to NDAs... :-) > > > > > > > > > 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 > > much that the > > > 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. > > > > There should be enough "trail" to justify starting an investigation... > > > > > > > > > Right now, the policy seems to pull a large amount of resources and risk (per the impact analysis) without > enough of a return. > > > > The "proposal". It's just a proposal...! :-) > > > > I agree that there isn't a way to measure how many people around the > > world would not resort to hijacking if this proposal was in place today > > :-) > > > > > > Regards, > > Carlos > > > > > > > > > > > Jacob Slater > > > > > > > > > > > > > > > > > > > > > On Mon, Sep 9, 2019 at 3:45 PM Carlos Friaças <cfriacas@fccn.pt> wrote: > > > > > > > > > On Thu, 5 Sep 2019, Jacob Slater wrote: > > > > > > > All, > > > > > > Hi Jacob, All, > > > > > > > > > > Given the number of people who may submit a report (anyone receiving a > > > > full table from their upstream(s), assuming the accused hijack makes it > > > > into the DFZ), > > > > > > If that happens, then potentially everyone can be a victim, yes. > > > Then they should be able to place a report. > > > But that's a fundamental part of why some changes are needed: it's not > > > only the legitimate address space owner who is the victim of an hijack. > > > People/networks whose packets are diverted by an hijack are also victims > > > of traffic interception. > > > > > > Afaik, this is possible within LACNIC (i.e. through warp.lacnic.net). When > > > the same proposal was discussed there, the yearly number of reports (if > > > i'm not mistaken) was on the scale of dozens -- and they have a very high > > > degree of helping stop/mitigate the incidents, almost close to 100%, which > > > is fantastic! > > > > > > > > > > I'm still concerned that the proposed policy would cause more harm than > > > > good. A random AS that happens to receive the announcement isn't in an > > > > authoritative position to know if a given announcement was unauthorized. > > > > > > I can fully agree that a system based on (possibly forged) LOAs, and > > > unauthenticated IRR created the huge mess we are submerged in today... > > > :((( > > > > > > > > > > Putting them through a reporting process that might well require the > > > > disclosure of internal information because of an unrelated > > > > individual/group being suspicious is a problem. > > > > > > I fail to identify exactly were the proposal describes such a need. > > > Even so, the experts should be binded to NDAs... :-) > > > > > > > > > Regards, > > > Carlos > > > > > > > > > > > > > Combined with the issues detailed in the Impact Analysis, I'm opposed to the policy as written. > > > > > > > > Jacob Slater > > > > > > > > On Thu, Sep 5, 2019 at 9:24 AM Marco Schmidt <mschmidt@ripe.net> wrote: > > > > Dear colleagues, > > > > > > > > Policy proposal 2019-03, "Resource Hijacking is a RIPE Policy Violation" > > > > is now in the Review Phase. > > > > > > > > The goal of this proposal is to define that BGP hijacking is not > > > > accepted as normal practice within the RIPE NCC service region. > > > > > > > > The proposal has been updated following the last round of discussion and > > > > is now at version v2.0. Some of the changes made to version v1.0 include: > > > > - Includes procedural steps for reporting and evaluation of potential > > > > hijacks > > > > - Provides guidelines for external experts > > > > - Adjusted title > > > > > > > > The RIPE NCC has prepared an impact analysis on this latest proposal > > > > version to support the community?s discussion. You can find the full > > > > proposal and impact analysis at: > > > > https://www.ripe.net/participate/policies/proposals/2019-03 > > > > https://www.ripe.net/participate/policies/proposals/2019-03#impact-analysis > > > > > > > > And the draft documents at: > > > > https://www.ripe.net/participate/policies/proposals/2019-03/draft > > > > > > > > As per the RIPE Policy Development Process (PDP), the purpose of this > > > > four week Review Phase is to continue discussion of the proposal, taking > > > > the impact analysis into consideration, and to review the full draft > > > > RIPE Policy Document. > > > > > > > > At the end of the Review Phase, the Working Group (WG) Chairs will > > > > determine whether the WG has reached rough consensus. It is therefore > > > > important to provide your opinion, even if it is simply a restatement of > > > > your input from the previous phase. > > > > > > > > We encourage you to read the proposal, impact analysis and draft > > > > document and send any comments to <anti-abuse-wg@ripe.net> before 4 > > > > October 2019. > > > > > > > > > > > > Kind regards, > > > > > > > > Marco Schmidt > > > > Policy Officer > > > > RIPE NCC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

Vicarious liability / criminal negligence is also a thing in several jurisdictions so “let us do nothing and we won’t be liable” doesn’t always work. --srs ________________________________ From: Nuno Vieira <nuno@hashpower.pt> Sent: Tuesday, September 10, 2019 5:11 PM To: Suresh Ramasubramanian Cc: Sérgio Rocha; anti-abuse-wg@ripe.net Subject: Re: [anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation) Unfortunately yes. However it doesn’t mean that we shouldn’t discuss this, work on solutions and don’t let this die. Some interim solutions might be good to be deployed, like warp. At least they would serve as statistic or wall of shame. This might only see the sunlight when some government, regulator or some “critical” infrastructure around here gets hijacked, and the collaborative isps/upstreams properly bashed and prosecuted. Nuno Vieira No dia 10/09/2019, às 12:26, Suresh Ramasubramanian <ops.lists@gmail.com> escreveu:

You are right. I have very little hope of anything concrete coming out of this process, however.

On 10/09/19, 4:04 PM, "anti-abuse-wg on behalf of Sérgio Rocha" <anti-abuse-wg-bounces@ripe.net on behalf of sergio.rocha@makeitsimple.pt> wrote:

Hi,

I agree with Carlos. It is better to have an imperfect policy than not to have any policy and watch these hijacks helplessly in the front row.

I can't understand why some people resist having a policy that create a response to those who break the chain of trust on which the internet is based, we can't keep looking at abusers and think it's okay, one of this days will be your network, your client.

There are many hijacks that are claimed by the true owners of space and we cannot let these abusers, usually are always the same, remain members, we need to have policies to fight.

At RIPE meetings I always hear a lot of people talking about the inability to have any response to these events and when we hear the impact of these actions we realize than something has to be done, it may be not consensual a first version, but all supporters are certain that improvements will be made in the future.

Finally, if we do not want nations and governmental laws to regulate the internet, it has to be via entities like RIPE to bring regulation, otherwise we will lose control of the internet and it will start to be controlled by governments. (they are waiting for us to fail)

Regards, Sérgio

-----Original Message----- From: anti-abuse-wg [mailto:anti-abuse-wg-bounces@ripe.net] On Behalf Of Carlos Friaças via anti-abuse-wg Sent: 10 de setembro de 2019 08:26 To: Jacob Slater <jacob@rezero.org> Cc: anti-abuse-wg@ripe.net Subject: Re: [anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation)

Hello,

As the RIPE NCC's IA shows (imho), the proposed process is not perfect.

The main goal of having a process to start with was to allow some action regarding evident cases, and i hope people will agree that significant effort was made to accomodate comments during v1's discussion.

We tried to add more "safety knobs", because we felt that a wrong decision (by experts) would be a really, really bad thing, and we wanted to avoid that -- even knowing that sometimes even courts do get it wrong _and_ that ONE 'guilty of hijacking' case wouldn't result immediately in a LIR terminating process.

In the case there were no doubts that someone/some company was doing this (i.e. a 'guilty' conclusion), the expected outcome would be for that member to stop that behaviour from that point forward.

Regards, Carlos

...

On Mon, 9 Sep 2019, Jacob Slater wrote:

All, Sure, but stat.ripe.net, bgp.he.net, rpki, and many other sources are free for everyone to access. :-)

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. I might strongly suspect that it was - sure. My personal suspicions should not be enough in this instance.

Honestly, i handed it back in late April. The IA and publishing took some time... :-) What i think supports what i wrote above is in Section 7.0, clause 1: "The RIPE NCC will verify that a report contains sufficient information before assigning it to a group of experts. If this is not the case, the report will be dismissed."

Maybe it could be a bit clearer, or we could textually add "one event or a handful of events is not enough".

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.

Hence Section 7.0, clause 1 :-)

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. 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.

Sure. And i have already read the IA. All of it.

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.

Jacob Slater

On Mon, Sep 9, 2019 at 5:56 PM Carlos Friaças <cfriacas@fccn.pt> wrote:

Hi,

...

On Mon, 9 Sep 2019, Jacob Slater wrote:

All, If it's *your* table, you should be able.

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.

Sure, but stat.ripe.net, bgp.he.net, rpki, and many other sources are free for everyone to access. :-)

...

But please keep in mind than one event or a handful of events shouldn't justify an investigation, or handing a case to "experts".

The current policy proposal doesn't have text to support this.

Honestly, i handed it back in late April. The IA and publishing took some time... :-) What i think supports what i wrote above is in Section 7.0, clause 1: "The RIPE NCC will verify that a report contains sufficient information before assigning it to a group of experts. If this is not the case, the report will be dismissed."

Maybe it could be a bit clearer, or we could textually add "one event or a handful of events is not enough".

...

If the issue is fixed and the issue originator isn't always the same, then no real need for an investigation. Maybe the amount of text on the current version fades a bit the two main concepts of "persistent" and "intentional".

I am in agreement with you on this.

There should be enough "trail" to justify starting an investigation...

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.

Hence Section 7.0, clause 1 :-)

...

The "proposal". It's just a proposal...! :-)

I agree that there isn't a way to measure how many people around the

world would not resort to hijacking if this proposal was in place today

My apologies for misspeaking on that one. Any references I may have made to 2019-3 as a "policy" should read as "policy proposal".

No harm done :-)

...

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.

Sure. And i have already read the IA. All of it.

Regards, Carlos

...

Jacob Slater

On Mon, Sep 9, 2019 at 5:25 PM Carlos Friaças <cfriacas@fccn.pt> wrote:

Hi,

...

On Mon, 9 Sep 2019, Jacob Slater wrote:

All, If that happens, then potentially everyone can be a victim, yes. Then they should be able to place a report.

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.

If it's *your* table, you should be able. But please keep in mind than one event or a handful of events shouldn't justify an investigation, or handing a case to "experts".

...

Afaik, this is possible within LACNIC (i.e. through warp.lacnic.net). When the same proposal was discussed there, the yearly number of reports (if i'm not mistaken) was on the scale of dozens -- and they have a very high degree of helping stop/mitigate the incidents, almost close to 100%, which is fantastic!

Being asked to fix an issue is very different from getting investigated for an issue with the potential for termination of membership.

If the issue is fixed and the issue originator isn't always the same, then no real need for an investigation. Maybe the amount of text on the current version fades a bit the two main concepts of "persistent" and "intentional".

...

While I haven't seen a proposal for establishing a system like LACNIC's WARP under RIPE, I'd be open to the idea.

Great. Does anyone think this is a bad idea?

That would probably fall under the ncc-services-wg, so we'll have to see :-)

...

I fail to identify exactly were the proposal describes such a need. Even so, the experts should be binded to NDAs... :-)

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 much that the 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.

There should be enough "trail" to justify starting an investigation...

...

Right now, the policy seems to pull a large amount of resources and risk (per the impact analysis) without enough of a return.

The "proposal". It's just a proposal...! :-)

I agree that there isn't a way to measure how many people around the world would not resort to hijacking if this proposal was in place today :-)

Regards, Carlos

...

Jacob Slater

On Mon, Sep 9, 2019 at 3:45 PM Carlos Friaças <cfriacas@fccn.pt> wrote:

...

On Thu, 5 Sep 2019, Jacob Slater wrote:

All,

Hi Jacob, All,

...

Given the number of people who may submit a report (anyone receiving a full table from their upstream(s), assuming the accused hijack makes it into the DFZ),

If that happens, then potentially everyone can be a victim, yes. Then they should be able to place a report. But that's a fundamental part of why some changes are needed: it's not only the legitimate address space owner who is the victim of an hijack. People/networks whose packets are diverted by an hijack are also victims of traffic interception.

Afaik, this is possible within LACNIC (i.e. through warp.lacnic.net). When the same proposal was discussed there, the yearly number of reports (if i'm not mistaken) was on the scale of dozens -- and they have a very high degree of helping stop/mitigate the incidents, almost close to 100%, which is fantastic!

...

I'm still concerned that the proposed policy would cause more harm than good. A random AS that happens to receive the announcement isn't in an authoritative position to know if a given announcement was unauthorized.

I can fully agree that a system based on (possibly forged) LOAs, and unauthenticated IRR created the huge mess we are submerged in today... :(((

...

Putting them through a reporting process that might well require the disclosure of internal information because of an unrelated individual/group being suspicious is a problem.

I fail to identify exactly were the proposal describes such a need. Even so, the experts should be binded to NDAs... :-)

Regards, Carlos

...

Combined with the issues detailed in the Impact Analysis, I'm opposed to the policy as written.

Jacob Slater

On Thu, Sep 5, 2019 at 9:24 AM Marco Schmidt <mschmidt@ripe.net> wrote: Dear colleagues,

Policy proposal 2019-03, "Resource Hijacking is a RIPE Policy Violation" is now in the Review Phase.

The goal of this proposal is to define that BGP hijacking is not accepted as normal practice within the RIPE NCC service region.

The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the changes made to version v1.0 include: - Includes procedural steps for reporting and evaluation of potential hijacks - Provides guidelines for external experts - Adjusted title

The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-03 https://www.ripe.net/participate/policies/proposals/2019-03#impact-analysis

And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-03/draft

As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.

At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.

We encourage you to read the proposal, impact analysis and draft document and send any comments to <anti-abuse-wg@ripe.net> before 4 October 2019.

Kind regards,

Marco Schmidt Policy Officer RIPE NCC

On Mon, 9 Sep 2019, Alexander Talos-Zens wrote:

Hej,

Hi Alexander, All, (please see inline)

this is my first post in this list - my perspective is taht of a security guy with little knowledge about BGP or the inner workings of RIPE, but very interested in everything that helps definding against the bad guys.

Den 2019-09-05 kl. 15:23, skrev Marco Schmidt:

...

The goal of this proposal is to define that BGP hijacking is not accepted as normal practice within the RIPE NCC service region.

Firstly, thanks everyone involved for the effort in setting up this policy proposal. I like many points, e.g. that it makes clear that accidental events shall not be reprimanded. Others might deserve being rephrased, e.g. CSIRTS being entitled to file reports.

That detail is new on version 2, derived from comments to version 1. :-) The idea was to prevent anyone to "hunt" for hijacks and overload the system with reports, i guess. We didn't have that in version 1, so we added it to v2. As a workaround, a CSIRT (i work for one...) can ask the victim to file the report, or help the victim in doing that.

On the other hand, I had a hard time trying to determine the positive impact of the proposed policy.

The original idea is/was: Some (persistent, intentional) hijackers are RIPE NCC members, and if they don't respect the address space allocated to others, perhaps they shouldn't be inside the system. However, it's important to note, that *one* policy violation will not result in the member/hijacker losing membership status...

On the formal side, to define that hijacking is a violation of policy without specifying which policy is violated gives me a mental blue screen.

There is currently no policy against hijacking. Member X can actually hijack blocks or parts of blocks from Members Y,W,Z (or members from other RIRs) and life goes on. This proposal tries to establish that persistent, intentional hijacking is not to be tolerated -- unfortunately not everyone agrees... :-)

As far as I know, please correct me if I'm wrong, there is no policy in RIPE that proscribes hijacking, and neither would 2019-03 do that.

2019-03 tries to introduce the notion that hijacking (again, persistent & intentional) is not acceptable.

This makes sense to me, as (again, correct me if I'm wrong) RIPE isn't involved in routing operations - but that's where hijacking attacks take place.

Yes and no (imho). RIPE NCC (and/or the RIPE community) doesn't tell anyone what to configure on their routers. However what's the point of a registry system if some of its members decide to grab some space from other members...?

Should RIPE kick out the evil LIRs? Maybe, but the proposed policy doesn't do that. The opposite holds true: "RIPE-716) may apply." and "This policy does not endorse the initiation of an LIR closure procedure on the basis of a single policy violation." No mention what happens after multiple (how many? depending on LIR size? ...) violations.

More than one, at least. This is something new in v2, because in the 400+ messages discussion about v1, several voices pointed out that losing LIR status shouldn't happen immediately at the first "offence"... so we took note and accomodated this comment in v2. I can easily agree v2 is less "strict" even if not enough for some (or most) people.

I failed to find any way how implementing this proposal would improve security.

The way i see this as "preventive", is that *today* there isn't absolutely nothing at RIR/Registry policy level against hijacks (i mean, in any of the 5 RIRs, where we also launched this proposal). If the proposal reaches to a point (clearly not in v2) where it would get adopted, then a potential hijacker would know that it could lose it's LIR status (and corresponding numbering resources).

I've also tried to save the proposal's impetus by coming up with realistic and effective suggestions - but failed as well.

If you read v1, it was significantly shorter... but the thing is that a lot of people expressed opposition to several aspects (or the lack of some) and we've tried to address them all [back in late April...] :-)

For now, my conclusion is that this isn't the way to go.

Thanks for your input! Best Regards, Carlos

Cheers,

Alexander

-- Alexander Talos-Zens IT-Security - ACOnet-CERT Zentraler Informatikdienst http://zid.univie.ac.at

Universität Wien Universitätsstraße 7 1010 Wien T +43-1-4277-14351 at@univie.ac.at GPG-Key-Id: 0x757A494B