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

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

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 [[e-mail]]
Sent: Thursday, May 31, 2012 1:31 PM
To: Sriram, Kotikalapudi
Cc: Murphy, Sandra; [e-mail] List; [e-mail] 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