Prefix hijacking, how to prevent and fix currently

Tue Sep 2 15:25:39 UTC 2014

On Tue, Sep 02, 2014 at 03:08:28PM +0000, Sriram, Kotikalapudi wrote:
> The example that I gave was not that. In my example, C has legitimate
> ownership of the less specific (e.g., 192.0.2.0/23).  D is malicious
> and attempting to hijack a subprefix (e.g., 192.0.2.0/24).
> Importantly, C has a created a ROA for 192.0.2.0/23 only to protect
> its address space, but currently *does not advertise* this prefix or
> any part of it.  So D's more specific announcement (hijack) is
> 'Invalid' in this scenario, but the 'Loose' mode operation would
> accept/install D's route.  Am I right about that? If yes, that is the
> side effect or CON that I was trying to highlight.

You are right in your observation.

What is the real damage of hijacking a prefix which is not in use?
Email reputation that gets trashed for that prefix? I think the hijacks
we fear most are those of prefixes that are actively in use. For these
attacks I'd want to help customers protect against, and unused space is
low on my priority list.

> Further, at a later/more mature stage of RPKI, when most operators
> have implemented the paragraph I cited from RFC 7115, then routers can
> drop 'Loose' mode.

Implementing a 'Loose mode' would be a local policy decision, made by an
organisation, not a router. :-)

Kind regards,

Job