There is no need to send this attribute to a collector. If a provider respects his customer's wishes to privacy, he will strip the attribute before sending it to a collector.
The worst thing is sending only one prefix per update and having to sign it differently for each AS you send it to. Compared with that, another signature chain is a drop in the bucket. Maybe we can combine ideas. Take your RLP attribute and sign it in another signature chain. Each AS adds its bits and signs it again. First AS to remove it means "propagate to customers only" You still need the "The RLP was added" bit in the BGPSEC signature. Something like that? --Jakob > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sri...@nist.gov] > Sent: Tuesday, July 29, 2014 4:05 PM > To: Jakob Heitz (jheitz); IETF SIDR; i...@ietf.org; grow@ietf.org > Subject: RE: draft-sriram-route-leak-protection-00 > > 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:sidr-boun...@ietf.org] On Behalf Of Jakob Heitz > (jheitz) > Sent: Tuesday, July 29, 2014 5:07 PM > To: Sriram, Kotikalapudi; IETF SIDR; i...@ietf.org; grow@ietf.org > 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:kotikalapudi.sri...@nist.gov] > > Sent: Tuesday, July 29, 2014 1:52 PM > > To: Jakob Heitz (jheitz); IETF SIDR; i...@ietf.org; grow@ietf.org > > 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 > > _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
