Re: [sidr] draft-sriram-bgpsec-design-choices-00 -- IXP and Route Server

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: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] 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
> > sidr@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidr
> >
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr