When you said "you can not sign the update", did you mean "you cannot register a ROA for your prefix with the AS set"?
Sriram > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Chris > Morrow > Sent: Thursday, April 29, 2010 11:30 AM > To: Geoff Huston > Cc: Sandra Murphy; sidr wg > Subject: Re: [sidr] SIDR Charter Question > > > > Geoff Huston wrote: > > On 29/04/2010, at 5:24 AM, Chris Morrow wrote: > > > >> > >> Sandra Murphy wrote: > >>> The relative frequency of use of AS_SETs is interesting, but not really > >>> germane to the point here. > >>> > >>> If we were trying to develop a protection for AS_SETs then we might want > >>> to ask the engineering question of where and how often they were used. > >>> > >>> But for the purpose of validating received updates, we need a rule for > >>> what is done with AS_SETs that appear in the AS_PATH origin. Lack of > >>> rules leaves opportunities for deliberate or accidental mischief. > >>> > >>> AS_SETs might not be used very often, but that doesn't stop someone from > >>> using AS_SETs deliberately with malicious intent. > >> right so as a starting point: > >> "AS_SET in an origin is unvalidatable." > > ("on reciept" i forgot to add) > > >> > >> how about that? (I think this is fine since: > >> 1) they aren't used in production very much anymore > >> 2) where used, they seem to be mis-used > >> 3) the rules for how you do verification/validation of an AS_SET are at > >> best murky. > >> > >> -chris > >> (regular user) > >> > > > > > > You ask: "how about that?" > > > > That still works for me. Ironically (or any other adjective that matches - > > I can think of > quite a few more extreme ones that I could substitute) this is _precisely_ > where all this > started when I proposed using the following definition of an "origin AS" (in > my note from 4 > April): > > > > "A route's "origin AS" is the final element of the route object's > > AS_PATH attribute. If the final AS_PATH element is an AS Set, > > indicating that the route is an aggregate, then the origin AS > > cannot be determined." > > cool, so I actually only did half the problem (reciept), on send as well > we'd have to say: "If you are sending an update (announce or withdrawal) > and that update's origin is an AS_SET, you can not sign the update." > > I think that makes sense because you can't determine which AS in the > AS_SET should do the signing? > > -chris > (again as a regular user) > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
