Re: [sidr] draft-sriram-route-leak-protection-00

["Jakob Heitz (jheitz)" <[e-mail]>]

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:[e-mail]]
> Sent: Tuesday, July 29, 2014 10:10 AM
> To: Jakob Heitz (jheitz); IETF SIDR; [e-mail]; [e-mail]
> 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