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. It is valuable to have this discussion. I am personally sceptical of preventing the modification of the ORIGIN attribute. However, if others in the writhing group see value in protecting the ORIGIN attribute, then I want 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<https://www.ietf.org/mailman/listinfo/sidr> >
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
