[174258] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Prefix hijacking, how to prevent and fix currently

daemon@ATHENA.MIT.EDU (Christopher Morrow)
Tue Sep 2 11:56:07 2014

X-Original-To: nanog@nanog.org
In-Reply-To: <20140902152539.GG25691@Vurt.local>
Date: Tue, 2 Sep 2014 11:53:15 -0400
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Job Snijders <job@instituut.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>, "Sriram,
 Kotikalapudi" <kotikalapudi.sriram@nist.gov>
Errors-To: nanog-bounces@nanog.org

On Tue, Sep 2, 2014 at 11:25 AM, Job Snijders <job@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

home help back first fref pref prev next nref lref last post