Sriram, Kotikalapudi wrote: > When you said "you can not sign the update", > did you mean "you cannot register a ROA for your prefix with the AS set"?
yes, three folks now have corrected me. (I got ahead of myself) -chris >> -----Original Message----- >> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] 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 >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
