Re: [sidr] request for agenda items for interim meeting 6 Jun

["Sriram, Kotikalapudi" <[e-mail]>]

>
>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