RE: Prefix hijacking, how to prevent and fix currently
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
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
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
On Tue, Sep 02, 2014 at 11:53:15AM -0400, Christopher Morrow wrote:
On Tue, Sep 2, 2014 at 11:25 AM, Job Snijders <job@instituut.net> wrote:
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. 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
On Tue, Sep 2, 2014 at 12:08 PM, Job Snijders <job@instituut.net> wrote:
On Tue, Sep 02, 2014 at 11:53:15AM -0400, Christopher Morrow wrote:
On Tue, Sep 2, 2014 at 11:25 AM, Job Snijders <job@instituut.net> wrote:
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
participants (3)
-
Christopher Morrow -
Job Snijders -
Sriram, Kotikalapudi