Hi Geoff: I just wanted to provide you some more comments for clarity. For updates with AS_SET, the algorithm in your draft only checks the ASN in the AGGREGATOR field to see if it matches with the ASN in the ROA. This approach allows tools for a would be attacker to hijack a prefix in one of these two ways: 1. Artificially inserts an AS_SET (possibly an empty AS_SET or with just his ASN in the AS_SET), places a matching ASN from the covering ROA for the prefix being hijacked into the AGGREGATOR field, and places his own ASN as the first AS after the AS_SET to attract traffic toward him. 2. Takes any legitimate update he sees with an AS_SET in it; leaves the AS_SET and AGGREGATOR field unmodified; places his own ASN immediately next to the AS_SET and propagates the update. (He doesn't need to insert the true origin before his own ASN!).
There is a rather simple modification to your algorithm which mitigates these types attacks. Looking at the update/RIB data analysis in my presentation, it is clear for all practical purposes, that the ASN in the AGGREGATOR field is the same as the "first AS after the AS_SET" with very high probability (when they do not match, it is because the update is evidently flaky involving private ASNs, etc.). So the obvious remedy seems to be as follows: Check if the ASN in the AGGREGATOR field matches the the "first AS after the AS_SET". If true, then call that ASN the origin. Else, consider the origin indeterminable. If you take look at the data analysis in my slides (slides 2-4), the above approach seems quite well supported for determining the origin and at the same time mitigating the type of attacks noted above. Please let me know if this seems reasonable. Thanks. Regards, Sriram > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Sriram, > Kotikalapudi > Sent: Monday, October 11, 2010 10:14 AM > To: Geoff Huston; [email protected] wg > Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted > > Geoff: > > I have a concern about the way the origin is determined > when AS_SET is present in an update. > Quoting from draft-ietf-sidr-roa-validation-07: > "If the final path segment of the AS_PATH is of type AS_SET, indicating > that the route is an aggregate, then the origin AS is taken as the AS > component of the AGGREGATOR attribute [RFC4271], if present. > Otherwise the route's origin AS cannot be determined." > > At the Maastricht SIDR WG meeting, I gave a presentation in which > I highlighted a new attack vector that is possible due to the > above quoted way of determining the origin AS. > Please see slide 7 of said presentation: > http://www.ietf.org/proceedings/78/slides/sidr-4.pdf > http://www.antd.nist.gov/~ksriram/AS_SET_Aggregator_Stats.pdf > (The second link has slightly revised slides with corrections.) > > In the presentation, I also pointed out a simple method for > avoiding the new type of attack (also on slide 7). > This method (or remedy) draws support from the > data that I presented in the preceding slides (slide 2-4). > > After my presentation, there was significant interest in this topic > and some good discussions followed on the list; links to some of which are: > http://www.ietf.org/mail-archive/web/sidr/current/msg01780.html > http://www.ietf.org/mail-archive/web/sidr/current/msg01794.html > http://www.ietf.org/mail-archive/web/sidr/current/msg01791.html > > Of course, a different take on all this is to deprecate the AS_SET. > http://www.ietf.org/mail-archive/web/sidr/current/msg01772.html > Warren Kumari has submitted a draft to IDR to try to accomplish that. > Until that is accomplished, if we think we have to be compliant with > RFC 4271, then I think my suggested solution makes sense. > > You may also factor in some comments/augmentation that Jeff Hass > and Pradosh have made to my proposal: > http://www.ietf.org/mail-archive/web/sidr/current/msg01791.html > http://www.ietf.org/mail-archive/web/sidr/current/msg01794.html > > Regards, > Sriram > ________________________________________ > From: [email protected] [[email protected]] On Behalf Of Geoff Huston > [[email protected]] > Sent: Sunday, October 10, 2010 6:48 AM > To: [email protected] wg > Subject: [sidr] draft-ietf-sidr-roa-validation-07 submitted > > Hi, > > The draft's authors have reviewed the WG discussion and have decided to use, > with > acknowledgement in the draft, and an expression of thanks here, the > terminology in a > related WG draft, draft-ietf-sidr-pfx-validate. The revised terminology does > not refer to a > route as being "valid", "invalid" or "unknown", but refers to an attribute of > the route, > namely its "validity state", and this attribute has the values of "valid", > "invalid" or > "unknown", and notes that "not found" is synonymous to "unknown" in this > context. The > authors trust that this distinction addresses the issues WG members had over > the > terminology in the previous version of this draft, that used such state > attributions directly on > the route itself, rather than on a nominated attribute of the route. > > The announcement of the submission of this revised draft is below. > > regards, > > Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
