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

["Sriram, Kotikalapudi" <[e-mail]>]

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