On Wed, Mar 21, 2012 at 12:36 PM, Brian Dickson <[email protected]> wrote: > > > On Wed, Mar 21, 2012 at 12:10 PM, Christopher Morrow > <[email protected]> wrote: >> >> On Wed, Mar 21, 2012 at 11:50 AM, Brian Dickson >> <[email protected]> wrote: >> > >> > >> > On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas <[email protected]> >> > wrote: >> >> >> >> By "we" I assume you are asking the bigger question about what the >> >> broad >> >> requirements / objectives should be. >> >> >> >> The current BGPSEC design, chooses to only focus on the protocol on the >> >> wire, and starts with the attributes that had both an identified threat >> >> and a existence proof of a reasonable mechanism to address that threat. >> >> >> > >> > If that statement were true, I think there would be much more support >> > and >> > progress >> > for the bgpsec-protocol component of the SIDR WG. >> > >> > However, the current interpretation (by whom, is not clear) seems to be, >> > that only certain attributes (AS-path and nothing else?) are included in >> > what is protected. >> > >> > Any attempt to discuss inclusion of other attributes, and reasonable >> > mechanisms >> > for including those in the protection regime, has been shouted down by a >> > small group >> > which includes a self-selected group of implementers. >> > >> >> you seem to want to read: >> http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01 >> > > Yes, I have read that, and the relevant bits are pretty much as follows: > > "It was decided..." (in a number of places). > > The section on "what is signed" lists a few attributes, and focuses on the > "how" > rather than the "what" or "why". >
yup, part of that could be more explanatory. > The only place where what is not signed is discussed is in 2.4.1, where it > basically > says, "are local, or lack clear security needs." > I think sriram means really that each of these items are actually modified/modifiable at each router hop (each bgp peer), and if they get signed how does that make any sense at all if on one hop you sign: community 701:666 but at the next 701:666 7018:12 and at the next ''. ?? localpref, similarly is meaningless outside the local ASN, metric as well can get fudged with at each hop (peer) so signing that is ... problematic/impossible. > This is a conclusion, not supported by any analysis, and refuted > (repeatedly) by a number > of folks in the WG. sure, got text ? > The threat model discussion is excluding real threat issues, on the basis of > saying > that the WG charter is limited to protecting only the AS path. along with: "Show the math" (or equivalent in the case of the leaks problem) > I will claim it is possible to protect attributes which change, and that > discussion on which > attributes should be signed, should be open for discussion. curious how that'd be done, got examples? -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
