[members-discuss] Effective countermeasures against BGP hijacking

Hi Cedric,

> Am 01.08.2018 um 15:45 schrieb Cedric R <ml at servperso.com <mailto:ml at servperso.com>>:
> 
> Hello,
> I think it's not a bad idea but the real solution remain RPKI.
> If transit operator like HE or L3 start to reject INVALID RPKI and some riskly network start to sign theyr route (and it's pretty simple with RIR tools) we can clear a part of the problem quickly.
> I don't talk about reject unsigned route, but only invalid signed.

I absolutely agree with you. Personally I believe, for making progress with technology, we will always need some innovators and big players which are able and willing to create a certain amount of pressure on the market. If the big transit providers or networks like Google, Amazon, etc. would agree about a certain date after which they will reject all invalid RPKI, I guess we would see some spike in RPKI adoption VERY quickly. Similiar thing just happening with HTTPS/TLS and their flagging of http:// as insecure in their latest Chrome builds. Same story around three years ago with Google's call for mobile-first and responsiveness. Concerning BGP, unfortunately I do not expect the any of the big ones to take this step anywhere soon, as it would also dramatically impact their own availability and revenue. So what other options do we have then?


> Also AS blacklisting can be quickly spoofed.
> What append if someone use hijacked ASN behind it's legit ASN to announce hijacked prefix (not every filters drop that).

To be honest, that’s an issue I haven't thought about yet but you are absolutely right.
The only feasible solution here would be strict IRRDB filtering on autnum/as-set.

Best Regards
Dominic


> Best Regards
> Cedric Rossius
> 
> Le 01-08-18 à 11:59, Dominic Schallert a écrit :
>> Dear colleagues,
>> 
>> I’m sure some of you have read about this recent incident; https://bgpstream.com/event/144058 <https://bgpstream.com/event/144058> . Nowadays we’re talking about transport security, https-per-default, etc. but the most fundamental parts of the internet such as BGP, are basically broken from a security perspective. While RPKI/ROA/ROV could fix most of the current security-related struggles, their deployment currently competes somewhat with IPv6 - or even worse - and therefore won’t be a practical solution in the forseeable future. Strict IRRDB and route object filtering is complicated (or almost impossible) as well.
>> 
>> So I’m wondering, why can't we just have an automated blacklist like RBL's for mailservers, where all AS'es detected for hijacking prefixes are automatically blacklisted, similiar to Team Cymru's fullbogons feed? The list combined with some scripting could then be used for realtime AS-path filtering at border routers. Delisting of blacklisted ASNs should happen only after a pre-defined amount of time (eg. 14 days) or after paying a fee to a charity/non-profit and providing a statement on the issue which is publicy released. The idea is to hurt those who can’t get their stuff - especially prefix filtering - together.
>> 
>> I still remember the days where everyone complained about RBLs, nowadays almost every mailserver setup relies on them. Sometimes extreme problems require extrem solutions.
>> 
>> Mit besten Grüßen
>> Kind Regards
>> 
>> Dominic Schallert, BA
>> 
>> 
>> <logo_email.png>
>> 
>> 
>> schallert​.com e.U. | Hauptstraße 35b, 6800 Feldkirch, Austria
>> 
>> FN: 440372g  | UID: ATU66209211 | Gerichtsstand: Feldkirch
>> 
>> Tel.: +43 680 146 1947 | Fax: +43 134 242 642 616
>> 
>> www.schallert.com <http://www.schallert.com/>  | office at schallert.com <mailto:office at schallert.com>
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> members-discuss mailing list
>> members-discuss at ripe.net <mailto:members-discuss at ripe.net>
>> https://mailman.ripe.net/ <https://mailman.ripe.net/>
>> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ml%40servperso.com <https://lists.ripe.net/mailman/options/members-discuss/ml%40servperso.com>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20180801/8432740d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20180801/8432740d/attachment.sig>