No it wouldn't. For AS4 to put the goop back in, it needs to add the signatures of AS2 and 3 to the goop chain. The chain of ASNs in the new signature chain needs to be the same AS chain as in the BGPSEC.
--Jakob > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:[email protected]] > Sent: Tuesday, July 29, 2014 1:52 PM > To: Jakob Heitz (jheitz); IETF SIDR; [email protected]; [email protected] > Subject: RE: draft-sriram-route-leak-protection-00 > > >I'm not proposing to include it in the BGPSEC signature, It would > be a separate signature. > >Once AS2 removes it, it removes the attribute and its signature > chain. > >The BGPSEC attribute and its signature chain is a different > signature chain and not removed. > > > >The second attribute I proposed will be covered by the BGPSEC > signature chain and not removed. > > > > Jakob, > > OK, you are proposing a separate signature chain besides the BGPSEC > sig chain. > But any signature chain must continue end-to-end across the whole AS > path. > Because, if a signature chain is allowed to be removed at any point > in the path, then it becomes vulnerable to cut and paste attack. > Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1], > where AS1 is origin. > Let us say, AS2 removed your proposed first attribute and the > associated signature, and forwarded the update to its customer AS3. > Now AS3 forwards the update to its customer AS4. > AS4 can somehow learn that AS1 sent the first attribute to AS2 and > signed it, and it can somehow get that whole 'goop' (i.e. the > attribute and the sig of AS1). > Then AS4 can add back the 'goop', and forward the update to its > *upstream provider* AS5, and AS5 would be fooled and oblivious of > the leak. > > (Note: Again think of the reason why partial path signatures are > disallowed in BGPSEC. > The same principles should apply here too with any other proposed > sig chain.) > > Sriram > > >--Jakob > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
