> I think we are chasing our tails around the use of path as an abstraction > of the set of peering relationships and PATH as a specific sequence of > announcements of a given prefix (I.e., the AS_PATH attribute). > > Not that the debate isn't amusing, but sorting out those terms out might > allow it to move forward.
Precisely! Which "protocol semantic" are we trying to get right? Are we trying to secure the bits of the protocol on the wire? If so, then why not all the bits? Is there an argument other than, "the rest of the bits are too hard to secure?" If so, then why do we much care about "man in the middle attacks" at the database level? Or are we trying to secure the database --the path itself as an abstract object? If so, how do we deal with policy that should hang off the path? The second way allows us to break the problem into multiple pieces, examine each, and make independent tradeoffs. The first --so far, I don't see where it's led us anyplace useful --partly because we keep munging different pieces of the two ways of looking at the problem together into one "thing" --"we're just securing the semantics of the protocol on the wire, but we really want to secure this and that piece of database integrity by doing so." Russ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
