On Apr 5, 2010, at 12:28 PM, Sandra Murphy wrote: > There's also the point to be concerned about, which is defining the > validation of BGP routes to handle an AS_SET origin, to avoid creating a way > for an attacker to counter the validation check. > > No matter how few times the feature is used in practice, the feature exists > in BGP and in the implemented code. Not used in practice does not mean it > could not be used in malice. > > So, for a wild example, suppose the validation check looked to see if one > single AS in the origin AS_SET matched a valid ROA for the prefix, and passed > the BGP route as valid. That would give a malicious person a way to ensure > that their bogus route would be accepted. If on the other hand, the > validation code looked to see if all ASs in the AS_SET matched a valid ROA, > that might break legitimate uses. > > We need a defined way to deal with AS_SETs that doesn't afford opportunities > for the malicious source while still permitting either the accidental or the > rare intentional use.
I agree, and I think that reinforces my earlier statements. One might say that to deal with the vast majority of the cases today, if an AS_SET contains only a single AS, and there's a valid ROA for that origin AS for the prefix in question, it should be considered valid. Additionally (more generically to capture the above as well), if AS_SETs are going to be employed by an AS then all ASes in the set must have a corresponding ROA for the prefix in question, else the route is invalid. Of course, a big disclaimer security consideration statement there as well to outline your example above and state this is a dumb idea in practice; but that's a different issue... -danny _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
