>> The point is you've gone beyond the existence of the path here to the >> rightful use of the path --and that is policy.
> don't think so. Yes, you have. Because you've insisted on making the solution work per prefix, you've moved the problem out of the realm of path validation and into the realm of per prefix policy. Paths don't exist per prefix. Paths either exist or don't. Only policies can tell you whether or not a particular path is available for a particular prefix. Since you're signing per prefix/per path, you're actually adding a policy semantic into the protocol that simply didn't exist before BGPSEC. If you backed up to validating the path at the path level, then this problem would go away --but then you're justification for signatures in the packets based on the so call "man in the middle attack," would go away, as well, and the field would be open for a number of different solutions. At that point, you'd actually have to break policy apart as a separate problem, and address it by analyzing the policy problems to be addressed. The problem is you started with a solution, then designed requirements to fit that solution. That the requirements slip this way and that to rule out alternate solutions while keeping your solution as the only viable alternative is a clear symptom of what actually happened. Russ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
