> >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. The operator has a choice to consider and select a route as best path (or as add-path) even if the update failed validation or validation was deferred. (Note: Validation may not be deferred sometimes due to processor overload, or known RPKI staleness, etc.) You seem to be suggesting that when there is "validation failure", then "BGPSEC_Path_Signatures" as whole is unusable. That is not the case. "BGPSEC_Path_Signatures" is just a name given to the outer shell of the BGPSEC update. (BGPSEC need not give the outer shell any name at all.) Within it, we have these segments: Secure_Path, Sig_Block, and Additional_Info. Each of these segments has its own proper semantics. Even if the Sig_Block were to have an invalid signature, the Secure_Path segment is still usable as it provides the AS path info. If the operator chose an _Invalid_ update for lack of a better choice, then it is still the Secure_Path that provides the AS path info, and also the update SHOULD be signed and propagated to other BGPSEC peers. Also, if a specific eBGP neighbor is a non-bgpsec speaker, then the selected BGPSEC update (valid or invalid) is converted to a regular BGP-4 update wherein the AS_PATH attribute is constructed from the Secure_Path. So validation failure in BGPSEC does not mean that "the data are just gone." In fact, for clarity sake I would like to suggest that in the spec we consider Secure_Path, Sig_Block, and Additional_Info as distinct BGPSEC attributes. (That is to say we should not lump them together as one attribute.) Sriram _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
