On 12/03/13 10:21 -0400, Christopher Morrow wrote: > On Tue, Mar 12, 2013 at 9:38 AM, Matthew Lepinski > <mlepinski.i...@gmail.com> wrote: > > A quick clarification: The current BGPSEC protocol specification can easily > > be modified to protect the ORIGIN attribute. (That is, prevent it from being > > modified by intermediate ASes.) > > > > I can very quickly put out an update to the BGPSEC protocol specification if > > the working group decides that there is a requirement to protect the ORIGIN > > attribute. > > I wonder if it's worth protecting it as an option? > In other words protect origin at the origin's discretion.
Although I was skeptical of origin code validation, this seems like another reasonable alternative. As an operator, I wouldn't mind the option of only optionally validating origin code, or conversely on sending side allow those who choose to have it validated as you suggest take the risk that the only path in some cases may be dropped by others doing validation (if the majority of their transit providers are already doing origin code manipulation for instance). I'm seeing origin manipulation already from certain peers and I believe some in the same situation many have choosen to flatten origin themselves (set to igp on incoming) as a result to prevent it from affecting their BGP decision process. Other stub AS may use origin code as a traffic engineering knob internally. For these reasons, I think origin code validation should be optional at best (this threat is not high on my list frankly). Jon _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
