Prefix hijacking, how to prevent and fix currently

Tue Sep 2 15:53:15 UTC 2014

On Tue, Sep 2, 2014 at 11:25 AM, Job Snijders <job at instituut.net> wrote:
> 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?

'not in use' ... where?

What if the 'owner' of the block has the block only routed
'internally' (either behind gateways/firewalls/airgaps or just inside
their ASN) The expectation of the 'owner' is that they are using the
space and it's not routed 'somewhere else', right?

-chris