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