RE: Prefix hijacking, how to prevent and fix currently

Mailman List Mirror (Read Only)
1

Please help me understand the argument.

Some Org. D can maliciously announce a subprefix under Org. C's

prefix, and get away with it due to the 'Loose' mode.

So C is advertising valid 192.0.2.0/24

Is D advertising valid 192.0.2.0/23?

This is unfixable problem? If D is advertising invalid or unknown, C

would still work and win, as longest prefix match is done first to the 'valid'

population, if search is found, other populations are not searched.

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.

I think, 'Loose mode', if used at all, should not be used beyond a short grace period.

We need to be pragmatic and ready to compromise. Right now deploying

RPKI puts you in competitive disadvantage, loose mode would remove the

business risk and make it easier to justify deployment.

I agree about making some compromises. But we need to bear in mind

the side effects such as the above in the transition period.

For example, to mitigate the above stated CON, the operator (C in our example)

should go ahead and announce its prefix (e.g., 192.0.2.0/23) in BGP even though

he/she may not currently intend to set up any servers/services in that address space.

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.

Sriram

2

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. :slight_smile:

Kind regards,

Job

3

'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

4

Interesting point. A commmon approach is to announce such internal
prefixes and blackhole packets to and from at a border.

Alternatively they could set "AS 0" in the ROA of such 'not globally
used' prefixes. I don't think loose mode should apply to 'AS 0' ROAs.

Kind regards,

Job

5

> 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?

Interesting point. A commmon approach is to announce such internal
prefixes and blackhole packets to and from at a border.

there are lots of belts/suspenders ways to fix this, yes.

Alternatively they could set "AS 0" in the ROA of such 'not globally
used' prefixes. I don't think loose mode should apply to 'AS 0' ROAs.

ok