On Wednesday, April 11, 2012 7:21 AM, Jeffrey Haas <> wrote: > In the case where the paths are not congruent (which shouldn't happen > unlike the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec across > other BGP), we probably have some sort of hard error case. One > reasonable assumption is > that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP > speaker doing path manipulations for policy. IMO, the proper > behavior here is to *not* propagate the route at a BGPSEC ASBR > boundary; any BGP speaker that manipulates the AS_PATH in such a way > as to break the congruency of ASes between AS_PATH and signature MUST > be a BGPSEC speaker. > > The above still doesn't deal with common deployment considerations > such as as-override, replace-as and remove-private.
This just highlights the semantic difference between the BGPSEC path and the AS_PATH. They may be different legitimately. This is why we need both. A receiver can make its own decision whether the difference between the paths should cause path invalidation or not. If a sender is legitimately manipulating an AS_PATH, then the receiver should know about it and use this knowledge to help in the decision. -- Jakob Heitz. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
