> 1. People think having one signature chain in updates is bad enough. > You are proposing two signature chains.
That to me has zero practical/real deployment relevance. Cheers, R. On Wed, Jul 30, 2014 at 1:05 AM, Sriram, Kotikalapudi < [email protected]> wrote: > Jakob, > > OK, understood. > But I still have these additional concerns/questions about your proposed > method: > 1. People think having one signature chain in updates is bad enough. > You are proposing two signature chains. > 2. How do you address the issue when an AS that is not the originator > Wants to signal to a peer that the update should not be propagated > Laterally to another peer or to an upstream provider > (I.e., update can only be forwarded to customers). > What tagging or attribute can you use to enable this if you were to > extend your method? > Please see what Method 2 does ('10' tag), slide 8 in my presentation: > http://www.ietf.org/proceedings/90/slides/slides-90-grow-2.pdf > 3. The reason for your proposed method is that you wanted > ASes not to have to disclose peering relationships. > My method (the draft we are discussing) does not require that > explicitly. > Sure, you can infer something from the tagging. > But even in your approach, if there were Routeviews/RIPE-RIS like > collectors, > That collected the signed updates, then it is easy to tell who > stripped the > First attribute and towards which neighbor. > So there is an implicit discernable peering disclosure there too. > > Sriram > > -----Original Message----- > From: sidr [mailto:[email protected]] On Behalf Of Jakob Heitz > (jheitz) > Sent: Tuesday, July 29, 2014 5:07 PM > To: Sriram, Kotikalapudi; IETF SIDR; [email protected]; [email protected] > Subject: Re: [sidr] draft-sriram-route-leak-protection-00 > > 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 > > > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
