On 06/04/2010, at 4:37 AM, Danny McPherson wrote: > > 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. >
The circularity of this has not escaped me - I recall about 3 (or was it 4) years ago arguing for the need for some form of signed credentials that would support proxy aggregation in BGP as the associated transformation of a number of discrete originations into a single origination with an associated AS Set. AS I recall the argument was tied up with the multiple signature debate, as essentially a proxy aggregation should reflect in some form or fashion the assent of those entities whose routes have been aggregated in this fashion At the time the opposition from working group participants to this concept was small in number but, from my perspective, typically vehement. I gave up. Others should not feel in any way constrained by my experiences in trying to push that particular barrow. Good luck. regards, Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
