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 > 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
