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] Fwd: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud
- Previous message (by thread): [anti-abuse-wg] Fwd: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud
- Next message (by thread): [anti-abuse-wg] Fwd: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Gert Doering
gert at space.net
Sun Nov 9 19:44:32 CET 2014
Hi, On Fri, Nov 07, 2014 at 05:23:52AM +0100, Michael Horn wrote: > Just to get to the bottom of ripe-policy-addressable parts of this > issue... are there any statistics on the legitimate and necessary usage > of RIPE-NCC-RPSL-MNT? I have no statistics. The legitimate and necessary usage is if you want to document your routing policy in the RIPE region but happen to have out of region networks "in your AS", for whatever reason. Now, enabling creation of database entries without authentication for the good guys (because we had no idea how to *do* authentication for these objects, the RPSL-dist-auth drafts didn't really fly) also enables this attack angle. > How reasonable would it be to do either one (or a combination) of these: > > a) deprecate this mechanism entirely > b) devise a way to (manually and/or automagically) check if the > respective usage in a certain case is legitimate > c) check existing objects for likeliness of fraudulent usage > (in coordination with the legitimate address space users) This mechanism needs to go away, and I think everybody agrees here. George Michaelson's idea to use RPKI to permit foreign-region entries into the RIPE DB ("if the ROA validates, route: objects may be created") might work out nicely (or not, for legacy resources that currently cannot get an ROA) - or Kaveh's approach to refuse creation of route: objects for those with a conflicting ROA. Sounds similar, isn't :-) c) might actually be not that hard ("just check the originating database if a route: or ROA exists") but will quite likely turn up a pile of old and non-maintained junk, so be a lot of work... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: </ripe/mail/archives/anti-abuse-wg/attachments/20141109/95c4529e/attachment.sig>
- Previous message (by thread): [anti-abuse-wg] Fwd: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud
- Next message (by thread): [anti-abuse-wg] Fwd: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]