ok. How about: Each AS signs it as having passed it along, just like the BGPSEC. Then after one AS removes it, a subsequent AS cannot add it back.
--Jakob > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sri...@nist.gov] > Sent: Tuesday, July 29, 2014 10:10 AM > To: Jakob Heitz (jheitz); IETF SIDR; i...@ietf.org; g...@ietf.org > Subject: RE: draft-sriram-route-leak-protection-00 > > Jacob, > > Please see comment inline below. > > Sriram > > >Add a new attribute that means "this route may be advertised up". > >This attribute must be signed by the originator of the route. > > >Add a second attribute that means "The first attribute was added". > >This attribute must be included in the BGPSEC signature. > > >If an AS asserts that the route can no longer be advertised up, It > >simply removes the first attribute along with its signature. > > >Since the first attribute must be signed by the originator, no one > else can add it back. > > The assertion "no one else can add it back" is not true. > In your proposal, as I understand it, > only the origin AS is signing the first attribute to its neighbor > (i.e. second AS). > Therefore, after an AS along the path removes the first attribute > along with the origin's signature, a subsequent adversary AS can > always cut and paste that thing back. > Please let me know if I misunderstood something. > (Note: We carefully avoided this kind of cut and paste problem in > Path Signing in BGPSEC by requiring each AS to sign to the next AS > in the AS path.) > > Sriram > > >Now, an AS that considers itself a provider of the advertised route > to the peer from which it received the advertisement can filter on > the presence of the second attribute and the lack of the first to > prevent the leak. > > >The advantage of this solution is that it will not expose the > customer-provider relationship to any customers. > > >--Jakob _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
