On Fri, 18 Feb 2011, Russ White wrote:
In my view of things, this is exactly the right way to do things.
Anything else is baling wire holding some pieces together, not a solution.
The problem lies right here:
In BGP, the semantics of the protocol are that the AS_PATH represents
the AS's through with the update has traveled.
No, it doesn't, really. Not in all cases.
In the *protocol* this is true. Certainly people mess with configurations
and implementations to get their own twisty features in, but in the
protocol, that's what is supposed to happen. It is what the recipients
rely on.
The point is to try to retain the semantics of the fields in the protocol.
The point should be to find out what it is you're trying to secure, and
then find a way to secure it. This _assumes_ the thing to secure is the
current semantics of the protocol.
But you're not addressing all the underlying assumptions that go with
those semantics.
But maybe you get the idea.
Suppose someone invented a way to prevent all of that without trying to
verify what path an update followed?
As I said, one could try to list all the ways of making bad things happen
by exploiting the vulnerability (munging the semantics), but it would be
hopeless.
Let me ask you something --does IPsec try to verify the path the packet
takes, or the contents of the packet? If the right solution for IPsec is
to validate the content of the packet, then why is the right solution
for BGP to verify the path of the packet?
The semantics of IP is that the source address is the host that sent the
packet and the contents of the packet are as sent.
Not much more.
So that's what IPsec protects. That semantics.
(Try to list all the bad things you can do by messing with IP packets and
address each one.)
The BGP protocol has a different semantics and so it has a different
protection.
--Sandy
:-)
Russ
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
