Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]

From: Robert Raszuk <[email-masked]>
Date: Fri, 01 Jun 2012 03:17:52 -0700

Hi Russ,

 > Doesn't this also impact 2 octet to 4 octet transition?

I thought about the same but I concluded that it does not. Due to 
inherent day one design of BGP_SEC_PATH which supports 4 octet AS you 
may carry it there as opposed to carry it AS4_PATH attribute.

 > IMHO, this is a huge problem --much larger than we might imagine at
 > this particular moment in time.

I think that the overall assumption is that we will fall back to non-sec 
where ever and for whatever reason needed. With this in mind I am amazed 
to see proponents of BGP Sec not caring about it as the end result will 
be marginal to non BGP Sec deployment result.

For example IBGP speakers will not likely to get upgraded to BGPSec in 
years to come. In traditional ISP this will immediately result in 
downgrade. When you use RR you are a bit better as only RR needs to be 
upgraded, but still this is light years for Internet wide deployment. As 
example I know global SP networks which use full mesh.

I am therefor proposing SIDR overlay as smooth gradual introduction of 
BGP SEC on subset of prefixes yet with full benefits of full blown BGP 
Sec deployment. Maybe just for easy transition ... Of course this 
requires Internet wide encapsulation so those allergic to it will not 
like it :).

Best,
R.

>
>>>> - Extensibility to include new segment types. In principle this is a fairly serious omission, but one can argue that new segment types can't be introduced in practice, since existing implementations will treat them as fatal errors.
>
> Doesn't this also impact 2 octet to 4 octet transition?
>
> IMHO, this is a huge problem --much larger than we might imagine at this
> particular moment in time.
>
> Russ
>

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 4 Jun 2012 14:51:45 -0400

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

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 4 Jun 2012 16:08:32 -0400

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