Sandy's observations are correct. Further, the topic of Section 6.6 cannot be either "accepted" or "rejected" as a matter of BGPSEC protocol specification. It is merely a statement that _outside_of_the_BGPSEC_protocol_specification_, any two consenting ASes can have this private arrangement. Section 6.6 clearly notes thus: "This is a private arrangement between said parties and is invisible to other ASes. Thus, this arrangement is not part of the BGPSEC protocol specification." http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#section-6.6
Sriram > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Sandra Murphy > Sent: Friday, July 08, 2011 3:30 PM > To: Chris Hall > Cc: 'sidr wg list' > Subject: Re: [sidr] draft-sriram-bgpsec-design-choices-00 -- IXP and Route > Server > > > > On Fri, 8 Jul 2011, Chris Hall wrote: > > > Randy Bush wrote (on Fri 08-Jul-2011 at 19:24 +0100): > > .... > >>> This is what "6.6 Proxy Signing" in > >>> draft-sriram-bgpsec-design-choices suggests, is it > >>> not ? Or does that blow the trust model to hell, > >>> also ? > > > >> it does indeed. that is why 6.6 was rejected. > > > > Ah. There I was, reading a draft of 5-Jul-2011 and thinking I was up > > to date :-( > > The previous section, 6.5, lists alternatives for handling stub ASs. > Note that alternative 2 is the same description as 6.6, but alternative 2 > was not the chosen alternative. That might be what Randy meant when he > said "rejected." > > Section 6.6 rightly notes that if an AS decided to share its private key > with another AS, no one outside the agreement could tell the difference. > > Therein lies the power and the danger of sharing private keys. > > --Sandy, regular ol' wg member > > > > > > OK. If the RS ASN is in the path, then nobody needs to depend on the > > integrity of the RS (however trustworthy one may expect them to be). > > I look forward to the ASN count mechanism appearing in the draft(s), > > and support for Route Servers making its way into the Requirements. > > > > Chris > > > > _______________________________________________ > > 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
