Pradosh and I were talking about the BGP implementation the other day, and I had a comment about the extended community that is proposed to carry a route's validation state. He said that he had discussed this issue with some folks one on one, but recommended that I bring it to the list for wider discussion.
In the current draft, the extended community is tagged as non-transitive, and because of that, there is language to say that it MUST not be announced to eBGP peers. I think I understand why this would be the case; since there is no certification as to the validity of the data beyond your own AS like there is with the actual RPKI infrastructure, it is not really a trustworthy source of validation data beyond one's own AS. However, I believe that I have a use case where it would be valuable to be able to configure the extended community as transitive. In a scenario where origin validation has relatively wide adoption, I expect that many large ISPs and other networks will set up their own RPKI cache servers to manage origin validation duties for their networks. However, I believe that there will be some other networks that will not want to set up their own RPKI cache. Ok, no big deal, right? While it wouldn't be in the IGP, it's still possible for those networks to configure their routers to use a third party's cache. For example, a network could be using an RPKI cache set up by an ISP for their customers to use, kind of like a cache-only DNS server. But, this assumes that they have software on their AS border routers that supports origin validation at all, which is sort of a big "if". The reality is that there are plenty of people running code and routers that don't have a new feature roadmap anymore, and likely won't be getting this feature, but are otherwise still functional within the area they are serving in a given network. While SIDR origin validation is a good reason to upgrade, it may not actually impress the beancounter crew enough to shake the necessary money loose to do so. I agree that it is much cleaner and more appropriate to actually do your own RPKI validation and provide that info directly to your ASBRs, but I think that making this community configurable as transitive even if we specify that it MUST default to non-transitive gives good flexibility. More specifically, this allows people to take advantage of origin validation for policy decisions such as the examples given in Anaheim even if their ASBRs do not support the full implementation. Carrying the communities into eBGP gives a measure of backwards compatibility that may encourage wider deployment. If we end up going in that direction, it may make sense to identify some best practices around how to ensure that the validity communities that you receive are trustworthy, such as eBGP session authentication, having a policy or knob that removes/ignores validity communities from eBGP peers you do not have a trust relationship with, etc. Thanks, Wes ________________________________ This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
