This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/anti-abuse-wg@ripe.net/
[anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
- Previous message (by thread): [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
- Next message (by thread): [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Carlos Friaças
cfriacas at fccn.pt
Wed Mar 20 09:17:59 CET 2019
On Wed, 20 Mar 2019, Andrey Korolyov wrote: > > And when everything is made clear, if a report is filed against AS1, AS1's > holder might have a problem, so i see a strong reason for not even trying > :-) > > > Out of interest, take an AS1 with single malicious upstream AS2, what stops AS2 to pretend that AS1 has made bogus announcements > and make them for its own purposes? This situation looks pretty real without RPKI or other advertisement strengthening methods, > as I could see. How experts are supposed to behave in this situation? That's an extra incentive for AS1 to create its ROAs properly...? :-)) What you describe is a supplier/customer relation. If the supplier is malicious, the customer can also file a report about the supplier's actions, and of course, if they are in conflict, AS1 can declare through it's aut-num that it has no relation with AS2 anymore, and that should catch the expert's eye... Cheers, Carlos
- Previous message (by thread): [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
- Next message (by thread): [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]