On Fri, 18 Feb 2011, Russ White wrote:
* Is an Autonomous System (AS) authorized to originate an IP prefix
* Is the AS-Path represented in the route the same as the path
through which the route update traveled
As we've been discussing on the list --I don't think this is a good
goal. The first goal should be to determine what it is we want to show
about the AS Path in relation to other things, and then work on filling
that goal.
Starting with the assumption that proving an update travels a specific
path seems, to me, to be going about things the wrong way.
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.
OK so here goes with the philosophy.
Distributed protocols work because the sender and recipient are working
with a common semantics of what the bits on the wire mean.
The sender is supposed to set certain bits to represent some particular
semantics.
The recipient presumes that semantics when certain bits are set and makes
decisions based on that semantics.
In BGP, the semantics of the protocol are that the AS_PATH represents the
AS's through with the update has traveled.
This is the only reason why loop detection works.
This is the reason that people make decisions based on AS_PATH length.
(Yes, I know this is not the highest priority decision in the procedure,
but it is something everyone uses and one of the few ways to attempt to
have impact on the decision of an AS not a direct neighbor.)
Munging around with the AS_PATH in ways not in the protocol makes things
break.
We could try to list every single one of those, and find a separate way
of dealing with each new way to break things, but we would miss some,
someone would think of something new, whatever.
The point is to try to retain the semantics of the fields in the protocol.
Suppose someone munged around with the AS_PATH so that loops were not
detected. That would be a bad thing. You could invent a way to prevent
that and just that.
Suppose someone munged around with the AS_PATH so that it looked like
there was a loop when there was not. That could be a bad thing (cue
Kapela and Pilosov) You could invent a second way to prevent just that.
Suppose someone made a path look shorter than it was. That could be a bad
thing. You could invent a third way to prevent just that.
Suppose someone inserted some unrelated AS into the AS_PATH to cause a
link elsewhere to break. That would be a bad thing. (reference Steve
Bellovin discussion of link-cutting attacks, cue NANOG's rant against one
certain person's experiment) You could invent a fourth way to prevent
just that.
Suppose....
But maybe you get the idea.
The fundamental problem (security geeks call this a "vulnerability") is
that the AS_PATH is supposed to be constructed in a certain way, the
recipients make decisions based on that assumption, and if it is possible
to mess with that assumption, you've got problems.
End philosophy.
--Sandy
:-)
Russ
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
