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". 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." This is a conclusion, not supported by any analysis, and refuted (repeatedly) by a number of folks in the WG. This is the crux of the issue. The logic applied by a few folks is circular, in that the design choices and protocol design have been made without input from the WG, and in fact are ignoring significant threat model issues. 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. However, the charter does not say "AS path", and the (real) threat models definitely extend beyond AS-path forgery. And, I believe, there may have been some assertions that there is no way to protect attributes which might change in flight (legitimately), and using that as a reason not to include other attributes in the -design- doc or -threat- doc. So, I will make a counter-assertion. 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. Brian > > I agree that the design _should_ start with examining threat models > against > > attributes > > which are used in path selection, and on identifying reasonable > mechanism(s) > > to address > > those threats. > > > > Doing so would require, at a minimum, stopping forward progress on > -protocol > > docs, > > until the -reqs- and -threat- are adequately addressed. > > > > BTW - I am in favor of this, and suggest that this proposal be submitted > to > > the WG > > to establish general consensus (or not). > > > > Chairs? > > > > Respectfully, > > Brian Dickson > > > > > >> > >> Discussing if there are other attributes that meet that rubric is an > >> incremental discussion relative to the current proposal. > >> > >> Stepping back to the bigger question if we should be securing something > >> other than what is on the wire (or can be put on the wire with new IDR > >> tweaks) is a much broader discussion of our basic goals. > >> > >> dougm > >> -- > >> Doug Montgomery Mgr. Internet & Scalable Systems Research / ITL / NIST > >> > >> > >> > >> > >> > >> > >> On 3/21/12 11:13 AM, "Russ White" <[email protected]> wrote: > >> > >> > > >> >> I think we are chasing our tails around the use of path as an > >> >>abstraction > >> >> of the set of peering relationships and PATH as a specific sequence > of > >> >> announcements of a given prefix (I.e., the AS_PATH attribute). > >> >> > >> >> Not that the debate isn't amusing, but sorting out those terms out > >> >> might > >> >> allow it to move forward. > >> > > >> >Precisely! Which "protocol semantic" are we trying to get right? > >> > > >> >Are we trying to secure the bits of the protocol on the wire? If so, > >> >then why not all the bits? Is there an argument other than, "the rest > of > >> >the bits are too hard to secure?" If so, then why do we much care about > >> >"man in the middle attacks" at the database level? > >> > > >> >Or are we trying to secure the database --the path itself as an > abstract > >> >object? If so, how do we deal with policy that should hang off the > path? > >> > > >> >The second way allows us to break the problem into multiple pieces, > >> >examine each, and make independent tradeoffs. The first --so far, I > >> >don't see where it's led us anyplace useful --partly because we keep > >> >munging different pieces of the two ways of looking at the problem > >> >together into one "thing" --"we're just securing the semantics of the > >> >protocol on the wire, but we really want to secure this and that piece > >> >of database integrity by doing so." > >> > > >> >Russ > >> > >> _______________________________________________ > >> sidr mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/sidr > > > > > > > > _______________________________________________ > > sidr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/sidr > > >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
