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

["John G. Scudder" <[e-mail]>]

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