Confeds are out of scope. VPN address families are out of scope.
If the BGPSEC path does not match the AS_PATH, the update is invalid. The validity of an update is used as an input to route selection. If you have been replace/override/removing ASNs, you are free to use that information in route selection too. IOW, the BGPSEC validity of an update does not necessarily prevent you from using the update if you have inside knowledge about AS path mucking. How you use the BGPSEC validity in your route selection is a private matter. On Wednesday, April 11, 2012 7:21 AM, Jeffrey Haas <> wrote: > 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 -- Jakob Heitz. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
