Prefix hijacking, how to prevent and fix currently

Mon Sep 1 21:34:27 UTC 2014

>> Loose mode RPKI:
>>  - verified or unknown less-specific route is preferable to failing more-specific

>Or said otherwise when choosing route from Adj-RIBs-In to Loc-RIB longest
>match is not done to whole population, population is first divided to
>'verified', 'unknown' and 'failed' routes, and longest match is done for each
>sub-population in order, until match is found.

Of course, a PRO you are seeking to achieve is:

If Org. A is parent and upstream of Org. B, and Org. A has created a ROA for its 
own less specific, while no ROA has been created (due to negligence, oversight, etc.) 
for the suballocation (more specific) of Org. B,
and if Org. A happens *not* to announce its less specific, then Org. B's announcement 
of the more specific from its own AS will be treated softly. 
That is, Org. B's announcement will be 'Invalid' but nevertheless the route is 
accepted/installed by any receiving AS that is using the 'Loose' mode.  
This is the benign/beneficial use of 'Loose' mode.

But the CON here is:

For instance, Org. C owns a prefix but has not yet deployed any services using it.
Org. C created a ROA (perhaps even an ROA with AS0) purely with the intent 
to make sure that no one else can get away with announcing any
subprefix (more specific) under its prefix unless they have a ROA for the subprefix.
The 'Loose' mode obviously defeats this.
Some Org. D can maliciously announce a subprefix under Org. C's prefix,
and get away with it due to the 'Loose' mode.

So there will be this tension between the PRO and CON of your 'Loose' mode.

I think, 'Loose mode', if used at all, should not be used beyond a short grace period.
Beyond the grace period, network operators and their customers will be 
well advised to adhere to the following from RFC 7115: 
"Before issuing a ROA for a super-block, an operator MUST ensure that
   all sub-allocations from that block that are announced by other ASes,
   e.g., customers, have correct ROAs in the RPKI."

Sriram   