On Thu, Jul 29, 2010 at 4:14 AM, Sriram, Kotikalapudi <[email protected]> wrote: > The point of my presentation was that we can treat updates with AS_SETs > duly and in accordance with RFC 4271. > No protocol modification is required. > We need not look inside the AS_SET, and also we would require no ROAs for the > AS_SET. > Simply take the AS to the immediate left of the AS_SET to be the origin. > The update/RIB data establish clearly that the ASN in that AS position indeed > matches the AGGREGATOR ASN (wherever it matters for the validation algorithm). > However, the algorithm should not take the AGGREGATOR to be the origin > (in order not to open the door for a new attack possibility -- see slide 7). > Simply taking the AS to the immediate left of the AS_SET to be the origin is > just as good.
I think with the privso that the ROA assigned/checked is for the exact prefix aggregate + 'immediate left of the AS_SET AS'. -chris <normal-joe-hat> > This approach has simplicity and it avoids the new attack possibility. > (My slides have the details and further explanation.) > > Sriram > > ________________________________________ > From: [email protected] [[email protected]] On Behalf Of Randy Bush > [[email protected]] > Sent: Wednesday, July 28, 2010 10:22 AM > To: Jeffrey Haas > Cc: [email protected] > Subject: Re: [sidr] Comment about aggregators and AS_SETs > > want knob to just not bother with aggs. they are a teensie weensie bit > of the routes, often bizarre (have only self, have three copies of self, > private asns, ...), why should i pay with complexity (== fragility) to > accommodate them? > > randy > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
