I'm not at my usual spot in the week to catch up on IETF mail, but this thread is noisy enough that it's caught my attention anyway. :-)
On Tue, Apr 10, 2012 at 01:37:34PM -0400, Warren Kumari wrote: > I think that sone of the biggest issues to keep in mind with carrying the > "same" data in two places is what to do when you suddenly discover that they > are not actually the same? The apparent issue in this thread is basically, "what happens to AS_PATH?" Glancing at draft-ietf-sidr-bgpsec-protocol-02 (and not thoroughly reading it), there's commentary about what should be done with the AS_PATH. That commentary is mostly correct in the sense that all of the path loop detection is already present. (And the mostly is important.) IMO, there are two specific issues with regard to removing the AS_PATH and one with keeping it. 1. What do you do about confederations? These ASes are not only typically internal but would have to use some sort of internal certs if we decided to cover the confederation case. Additionally, the current encoding format doesn't include AS_PATH segment type as part of the signature. Note in particular that confederation segments MUST be stripped when crossing an eBGP boundary. 2. More generally, what do you do about incremental deployment *within* the AS? One presumption I've been working on that I *thought* was shared by the WG was that BGPSEC procedures only had to be done at eBGP edges. While this is primarily true for signature validation purposes, a desired side effect of having the signature as a optional,transitive that paralleled the AS_PATH was that iBGP speakers don't have to even be BGPSEC aware. This lets you upgrade your network from the outside first and get benefit. As John Scudder likes to say, "a hard, crunchy shell". :-) IMO, we should keep the AS_PATH. 3. Which brings us to the third point - what do we do when the signature and the AS_PATH disagree with each other? Note that this was also a problem for 4-byte ASes (RFC 4893). That spec chose to simply trust the 4-byte path beyond a certain point. (I don't necessarily agree with it, but that's what consensus was.) Exactly what we do here needs to be specified, and some of that specification will come from deciding what we want to do about some things. For example, we want to prevent the path from being shortened. As long as the ASes involved in both signature and path are congruent, we can use the length in the signature if the number of ASes in the path are shorter than the signature. In the case where the paths are still congruent but the AS_PATH has a longer prepend (see my ingress prepending use case from a few sessions back), it may be fine to use the AS_PATH (and its length for route selection purposes). Yes, I understand there isn't consensus here. 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. I see there's a thread about proxy signing and perhaps that discussion is over there. I'll hopefully get to it in a few days. (And if you're not familiar with those three features and their deployment scenarios, please take some time to become familiar. Not dealing with them will be a significant deployment hurdle.) -- Jeff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
