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