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. > It is valuable to have this discussion. I am personally sceptical of > preventing the modification of the ORIGIN attribute. However, if others in it seems like there are thorns to watch out for, for sure... and mandatory action will certainly have us falling into the thorns minus protection. > the writhing group see value in protecting the ORIGIN attribute, then I want autocorrect or freudian slip? :) > to know about it. (And it is certainly the case that I understand the issue > better now than I did before this discussion started.) > > -Matt Lepinski > > On Mar 11, 2013 11:34 PM, "Danny McPherson" <da...@tcb.net> wrote: >> >> On 2013-03-11 13:31, Stephen Kent wrote: >>> >>> Danny, >>> >>> We have been told by several operators that the values stated in >>> Section 4.3 of RFC 4271 are not what is used today. We also have been >>> told that, contrary to the "SHOULD NOT" in Section 5.1.1 of this RFC, >>> it is not uncommon for ASes to change this value, en route. Given >>> these two observations, I don't see how one can argue that protecting >>> this attribute via a PATHSEC mechanism makes sense. >> >> >> 84% of ASes are stubs, apparently. Many of our own ASes are stubs and we >> buy transit services in some places from some of the ISPs that like to muck >> with the ORIGIN code to exploit traffic attraction attacks. I'd like a >> secure routing protocol to be derived from requirements that accommodate >> issues that both ISPs and stub ASes are concerned with. That's what I'd >> like as an operator. If this is yet another thing that you believe is beyond >> the scope of SIDR because the current BGPSEC spec doesn't accommodate it >> then why don't we stop pretending to be writing threats and requirements >> documents and you just publish your BGPSEC spec? >> >>> Separately, there is the issue of whether it makes sense to address >>> the security of the ORIGIN attribute in the threats document. The SIDR >>> charter states that the path security goal is "Is the AS-Path >>> represented in the route the same as the path through which the NLRI >>> traveled" >> >> >> Careful, I'm not sure the current BGPSEC spec does that at all for the >> "AS_PATH", and it actually diverges in some places. If you're going to use >> the charter again to nix this requirement as an acceptable residual >> vulnerability in the threats draft then it's crystal clear to me that you >> and the BGPSEC design team simply want to publish the BGPSEC draft as you've >> already envisioned and you don't want to accommodate my operational >> requirements. If that's the case then let's just kill the threats and >> requirements documents and save everyone's time. >> >>> There are a variety of other attributes that do not directly >>> support this goal, and which are not being addressed as part of the >>> PATHSEC model. >> >> >> Right, and I think they should be, as they all impact BGP path selection >> in various ways. >> >>> The threats document already addresses this issue, in >>> the Residual Vulnerabilities section. >> >> >> Out of curiosity, does anyone intend to ever address the growing list of >> "residual vulnerabilities" or is this merely a place to catalog requirements >> that would rather not be addressed? >> >>> I suggest the following updated >>> text for that section, to better explain the criteria for inclusion >>> and exclusion in that document: >>> >>> PATHSEC is not planned to protect all attributes associated with an >>> AS_PATH, even though some of these attributes may be employed as >>> inputs to routing decisions. Thus attacks that modify (or strip) these >>> other attributes are not prevented/detected by PATHSEC. The SIDR >>> charter calls for protecting only the info needed to verify that a >>> received route traversed the ASes enumerated in the AS_PATH, and that >>> the NLRI in the route is what was advertised. (The AS_PATH data also >>> may have traversed ASes within a confederation that are not >>> represented. However, these ASes are not externally visible, and thus >>> do not influence route selection, so their omission in this context is >>> not a security concern.) Thus, protection of other attributes is >>> outside the scope of the charter, at the time this document was >>> prepared. >> >> >> Again, I'd like some clarity on how long we're going to hide behind an >> explicitly worded charter, or if we're actually going to address any of >> these issues? >> >> -danny >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
