Authors:
Avichai Cohen -- Hebrew University
Yossi Gilad -- Boston University and MIT
Amir Herzberg -- Bar Ilan University
Michael Schapira -- Hebrew University
Presenter : Yossi Gilad
BGP was never designed with security in mind. It is inherently insecure. An example of a prefix hijack is provided to illustrate the issue. How can this be fixed? Currently, it is fixed using RPKI, which performs or provides origin authentication as to who owns what prefix that is being advertised. The RPKI local cache syncs with the RPKI remote registry.
Unfortunately, attackers can circumvent this using a Next-AS attack methodology. The state of the art for this is a two step solution. First, RPKI provides origin authentication and secondly, BGPSec provides path manipulation security.
The deployment challenges with BGPSec are that it relies on real time signature verification and validation (needing changes to hardware too), as a result, adoption is quite slow. In the interim of partial adoption happening, the security provided (or should we say, broken down) due to this can be solved with a simple extension to the RPKI approach.
The authors present this paper as a simple extension to help providers gain significant benefits in partial BGPSec deployments with easy deployment methods and minimal overhead. This approach basically extends RPKI to provide last-hop validation.
The simple approach is presented next and evaluation is performed on the CAIDA AS graph. Simulation results are provided for Next-AS and 2-hop attacks. It is postulated that forcing an attacker to do a 2-hop attack is the best you could get for partial deployments currently. Most of the evaluations are focused on proving that this method has minimal overhead and protects partial deployments by forcing attackers to take the above route.
There is also a breakdown or analysis provided by region (North America/Europe etc).
In summary, the premise of the paper is to push attackers to perform 2-hop attacks and shows that path-end validation mitigates high profile incidents. Regulatory and financial efforts are on to pursue mainstream adoption.
Q : Small change, huge benefit. But if other people can put into RPKI that I am going to download into my configs. What if my configs become insecure if the path-validation itself is insecure?
A : Our implementation might has bugs, but in general, it uses the RPKI to perform auth.
Q : Have you quantified the overhead of path validation? Using RPKI, ASes will not change their prefixes frequently, but the topology may change. The overhead of maintaining a path validation repository may be high. Do you have any results?
A : May be an issue because information may take some time to propagate, but that is based off RPKI (default value every ten minutes). It also depends on how often you change your neighbors. If you change them infrequently, you can whitelist all of them, but if you do so frequently, it may be an issue.
Avichai Cohen -- Hebrew University
Yossi Gilad -- Boston University and MIT
Amir Herzberg -- Bar Ilan University
Michael Schapira -- Hebrew University
Presenter : Yossi Gilad
BGP was never designed with security in mind. It is inherently insecure. An example of a prefix hijack is provided to illustrate the issue. How can this be fixed? Currently, it is fixed using RPKI, which performs or provides origin authentication as to who owns what prefix that is being advertised. The RPKI local cache syncs with the RPKI remote registry.
Unfortunately, attackers can circumvent this using a Next-AS attack methodology. The state of the art for this is a two step solution. First, RPKI provides origin authentication and secondly, BGPSec provides path manipulation security.
The deployment challenges with BGPSec are that it relies on real time signature verification and validation (needing changes to hardware too), as a result, adoption is quite slow. In the interim of partial adoption happening, the security provided (or should we say, broken down) due to this can be solved with a simple extension to the RPKI approach.
The authors present this paper as a simple extension to help providers gain significant benefits in partial BGPSec deployments with easy deployment methods and minimal overhead. This approach basically extends RPKI to provide last-hop validation.
The simple approach is presented next and evaluation is performed on the CAIDA AS graph. Simulation results are provided for Next-AS and 2-hop attacks. It is postulated that forcing an attacker to do a 2-hop attack is the best you could get for partial deployments currently. Most of the evaluations are focused on proving that this method has minimal overhead and protects partial deployments by forcing attackers to take the above route.
There is also a breakdown or analysis provided by region (North America/Europe etc).
In summary, the premise of the paper is to push attackers to perform 2-hop attacks and shows that path-end validation mitigates high profile incidents. Regulatory and financial efforts are on to pursue mainstream adoption.
Q : Small change, huge benefit. But if other people can put into RPKI that I am going to download into my configs. What if my configs become insecure if the path-validation itself is insecure?
A : Our implementation might has bugs, but in general, it uses the RPKI to perform auth.
Q : Have you quantified the overhead of path validation? Using RPKI, ASes will not change their prefixes frequently, but the topology may change. The overhead of maintaining a path validation repository may be high. Do you have any results?
A : May be an issue because information may take some time to propagate, but that is based off RPKI (default value every ten minutes). It also depends on how often you change your neighbors. If you change them infrequently, you can whitelist all of them, but if you do so frequently, it may be an issue.
No comments:
Post a Comment