Sriram, Confederations are an example of a standardized change to BGP that modified handling and semantics of the AS_PATH. There are various non-standardized AS_PATH rewriting knobs as well, as previously discussed.
--John On Jun 4, 2012, at 2:51 PM, Sriram, Kotikalapudi wrote: > Thanks for the clarification. > The Secure_Path semantics in BGPSEC are the same as the *essential semantics* > of BGP AS_PATH. > The *essential semantics* being the sequence of ASs the prefix announcement > has passed through > (including AS prepending). > So the Secure_Path semantics would be compatible with AS_PATH as long as said > essential semantics do not change. > I am curious if there is a realistic example of feature change to BGP > such that the AS_PATH would no longer adhere to its essential semantics. > > Sriram > ________________________________________ > From: John G. Scudder [[email protected]] > Sent: Thursday, May 31, 2012 1:31 PM > To: Sriram, Kotikalapudi > Cc: Murphy, Sandra; [email protected] List; [email protected] list > Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun > > On May 30, 2012, at 8:02 PM, Sriram, Kotikalapudi wrote: > >>> >>> Right, and agreed (see "formally an attack" above). But to repeat my further >>> point, if the AS_PATH is present (even if not secured): "at least there's >>> scope for a >>> network operator on the receiving end to tolerate the validation failure >>> and use >>> the route anyway, if desired. In the case where there's no AS_PATH, the >>> data are >>> just gone with no chance for appeal." >>> >> >> John, >> >> I do not agree that in the event of "validation failure" the route becomes >> unusable >> in BGPSEC as currently specified. > > That's not what I meant. My point was that a feature may be applied that > wants to change the AS_PATH in a way that can't be represented in the > BGPSEC_Path_Signatures. In other words, your later statement: > >> the Secure_Path segment is still usable as it provides the AS path info. > > is not correct in all cases. Likewise, to this statement: > >> So validation failure in BGPSEC does not mean that "the data are just gone." > > My point is not that validation failure causes this. It's that absent > AS_PATH, a semantically non-representable AS_PATH will be lost if forced > through BGPSEC_Path_Signatures. > > To reiterate, the options to address the case where a feature wants to > produce output that can't be represented in BGPSEC_Path_Signatures are: > > - Don't solve it. Effectively forbid any such feature. > - Carry both AS_PATH and BGPSEC_Path_Signatures in every update. Rules for > reconciliation would be required. > - Downgrade BGPSEC update to BGP update. > - Extend BGPSEC_Path_Signatures format to be able to represent the needed > feature. (As Sandy noted, this only makes sense insofar as the feature isn't > formally an attack, so this option is incomplete.) > > The validation failure I spoke of is a potential *consequence* of the middle > two options above, and as you say, the operator can then decide what to do. > > --John _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
