> because with ipsec the content inside the encrypted payload (or even > the content after the AH header) is not intended to be played with by > anyone along the path. Detection of bit flippage in the packet is the > point of ipsec. > > BGP requires that folk along the path adjust metrics, communities, > localpref (inside their ASNs) etc. It's not appropriate to 'secure the > whole of the update' since that can not be done.
But you're missing the point. Sandy said, "all we're trying to do is secure the existing protocol semantics." As Sandy herself said, the only "semantics" in IP are things that are contained within the header. So why not just secure the header. So the "securing the semantics" argument won't fly. Tell me what you want to secure, not how you intend to secure it. If the charter says, "we want to prove an update followed the AS Path listed in the update," then I will ask why we shouldn't prove the rest of the semantics, as well --who added what communities, who removed communities, and were they authorized to do so; who changed the next hop, and is the next hop really the correct and authorized one; etc. --these are all part of the "semantics" of BGP, as well. If you're going to say, "secure the semantics," then secure all of them. If you're going to say, "secure the data," then figure out what matters in terms of how the data looks, and secure that. :-) Russ
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
