On Sat, May 23, 2009 at 5:52 AM, Iljitsch van Beijnum
<iljitsch(_at_)muada(_dot_)com> wrote:
[belatedly]
On 12 mei 2009, at 21:42, Phillip Hallam-Baker wrote:
As for adding IPSEC to BGP, I would not want to comment on the
competence of the person involved.
We need to replace the MD5 hack with IPsec, because MD5 doesn't have any DoS
potection, crypto algorithm agility or key rollover mechanisms. But of
course that only protects your BGP sessions, not the content of the
information in those sessions.
We should replace the MD5 hack with something that makes for easier
management. It is somewhat disturbing to be reading specs that only
support one algorithm with a reference to a paper describing how that
algorithm was broken.
In particular I find it utterly unbelievable that large backbone
corporation A is going to configure its border routers to simply
accept routing information from large backboe corporation B. If I was
responsible for large corporation A then every piece of external
routing data would be funnelled into a control center and the edge
routers would only respond to control instructions from the control
center. No matter what specifications and standards might opine, that
is how I would run my network.
Sounds like a plan. Now explain to us how your control center knows which
routing information is valid and which isn't? You have in the order of 30
seconds to decide for every update before your customers start to complain
that "the internet" is broken.
30 seconds sounds a reasonable response time to aim for. Central
control need not be a single centralized control room. In fact much
better it is not. Rather what you want is to have centralized policy
development and localized enforcement.
But I think we need to restate the problem. We don't need to prove
that the information is valid so much as determine whether it is
likely to break things or not.
This looks much more like a spam filtering type problem to me than
pure access control.
So a first cut we might make on the data is to identify route
advertisements that are within previously established 'normal' bounds.
We do not need to vet every route advertisement, we only need to look
at those that are 'surprising'. Something of this sort must be taking
place already since each network has to decide whether to (1) use the
new route itself and (2) send out updated advertisements itself.
Having reduced the volume of routes to those that represent
'surprises' we have a problem that cannot be solved for the individual
route announcement in isolation. Like the spam problem we can only
evaluate routes by bringing in additional information to bear. In
particular we need to know if the routes that we are attempting to use
are connecting to the valid endpoints or not. We do not need to do
that for every route advertisement, just as we do not need to content
analyze every potential spam. We can also use reputation. But we do
need a source of grounding data if we are going to use reputation.
Traditional route analysis has to work with the IP level data that is
exposed in the current day Internet. That is fine provided that you
are not under attack from an intelligent adversary. Simply sending out
a bogus BGP announcement is not going to allow you to perform a long
term DDoS attack. The route is going to be quickly discarded if there
is nothing there to connect to.
So in summary, I think that to solve the BGP issue we need to look up
the stack as well and work out methods that allow for reliable
reporting of attack conditions.
--
--
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf