1) I would like to understand how can we detect and potentially prevent activities like this? I understand native BGP was not design to authenticate IP owners to the BGP broadcaster. Therefore, issues like this due to a human error would happen. How can activities like this be detected as this is clearly a threat if someone decides to broadcast IP networks of an organization and knock the real org. off the Net. 2) In reference to prevention, I recall there were discussions about secure BGP (S-BGP), Pretty Good BGP, or Secure Original BGP but I don't remember if any one of them was finalized (from practicality viewpoint) and if any one of them is implementable/enforceable by ISPs (do anyone have any insight)? 3) If I was to ask for an opinion, from your viewpoint which one is better and why and which one is not doable and why not?
Thank you in advance,
Parthiv
This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and notify us immediately.
For detection, there are a few solutions, but mostly it's just monitoring
the route table for your specific routes and being alerted when things
change. For prevention there are things like RPKI ( https://www.arin.net/resources/rpki/index.html) that can help. There are a
few other possibilities as well, each with their own pros and cons and
various cases of weakness. RPKI seems to be the current favorite and most
widely supported. Well, by vendors at least...
1) I would like to understand how can we detect and potentially
prevent activities like this? I understand native BGP was not design to
authenticate IP owners to the BGP broadcaster. Therefore, issues like
this due to a human error would happen. How >can activities like this be
detected as this is clearly a threat if someone decides to broadcast IP
networks of an organization and knock the real org. off the Net.
The most basic short answer would be use of proper filtering and LOAs.
Transit providers should be checking whether or not customers have
permission to act as a transit provider for prefixes or originate the
prefixes not registered to them by the RIRs.
If every operator would have controls in place to ensure folks are
originating the routes they are supposed to then you wouldn't have a
problem. However, it seems the best course of action is to implement
"checks and balances" internally to each organization which usually
prevents all together or mitigate things as much as possible. Human
error is inevitable. We have outside monitoring (bgpmon) for our
prefixes.
2) In reference to prevention, I recall there were discussions about
secure BGP (S-BGP), Pretty Good BGP, or Secure Original BGP but I don't
remember if any one of them was finalized (from practicality viewpoint)
and if any one of them is >implementable/enforceable by ISPs (do anyone
have any insight)?
If I had to pick one based on practicality it would be secure original
BGP. You can create a fairly secure BGP session by using multiple
mechanisms (prefix lists/filters/routemaps, password, iACL,
TTL-security, AS limits etc.)
However, there are caveats to anything.
1) I would like to understand how can we detect and potentially prevent activities like this? I understand native BGP was not design to authenticate IP owners to the BGP broadcaster. Therefore, issues like this due to a human error would happen. How can activities like this be detected as this is clearly a threat if someone decides to broadcast IP networks of an organization and knock the real org. off the Net.
There are a few BGP monitoring tools available, BGPMon.net is one such
service.
2) In reference to prevention, I recall there were discussions about
secure BGP (S-BGP), Pretty Good BGP, or Secure Original BGP but I don't
remember if any one of them was finalized (from practicality viewpoint)
and if any one of them is implementable/enforceable by ISPs (do anyone
have any insight)?
The thing we can improve today is providers doing a better job of
filtering. But that's still not full proof. Since many folks use
max-prefix filters only on for example Internet Exchange points, it's
easy to pick up a hijacked route from peers.
In the long term RPKI should solve this, but that's not full proof
either. The next step is full path validation, that's going to take a
while. For more info see for example: Securing BGP routing with RPKI and ROA's | BGPmon or Resource Public Key Infrastructure - Wikipedia