Sriram, Kotikalapudi wrote on 29/7/10 10:14 AM:
> 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. 
> This approach has simplicity and it avoids the new attack possibility.
> (My slides have the details and further explanation.)
>

This is very clear and I support this approach. Also, as I commented
previously, in reality the AS in question is the holder of the covering
address space and, therefore, in position to issue a ROA.

Andrei

> 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

Reply via email to