> nope, it's bits that you can choose to use or not. In other words, you've added another set of "wiggle words" to your definition. "It's not policy because it's not signing something saying you shouldn't do x, and because anyone can ignore the signature anyway."
Sorry, I don't buy it. You are adding bits that allow (even demand) a receiver to discern the intent of the transmitter about the usability of a specific path. I don't care how many wiggle words you put around it --it's still policy. Now if you're going to dive into policy, then dive into policy. There's nothing wrong with diving into policy, so long as you actually address the issue. That means determining which policies should be protected, and what the tradeoffs are for protecting each one. > I'm really not trying to sneak anything. we seem to be at an impasse. I've seen more than a small number of presentations on BGPSEC. I've read more than a small number of drafts. I've had more than a small number of private conversations about BGPSEC/S-BGP. In _every_ conversation I've ever had, in _every_ presentation I've ever seen, the one singular reason given for signing the BGP update is this: So a remote AS can determine whether or not some previous AS _intended_ to allow reachability through a particular peer for a particular prefix. Perhaps the way to resolve the impasse is to accept that what you are trying to do goes beyond simple "bits on the wire" security, bring the policy problems out into the open, and have a discussion about them. Or to come to the realization that you simply can't secure any routing protocol by simply "signing the bits on the wire," because many of the semantics everyone is so concerned about are actually not in the "bits on the wire" to be signed in the first place. Russ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
