On 14/10/2010, at 6:52 AM, Sriram, Kotikalapudi wrote: > Hi Geoff: > > I just wanted to provide you some more comments for clarity.
Unfortunately, I'm not sure that this note had your intended effect. > 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. But surely this can work for ANY prefix - i.e. replace the received AS path with a bogus AS path and leave only the (valid) Origin AS. If one is going to lie about the Path than politely asking the liar to only lie in ways that this particular framework can detect is surely a little far-fetched isn't it? > 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!). But surely if the check is on the AGGREGATOR field then this would not alter anything. I'm not sure what your point is here in this second case. > > There is a rather simple modification to your algorithm > which mitigates these types attacks. I honestly don't think so. > 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. > Its as reasonable as any other mechanism for origin validation that leaves the AS PATH untouched. i.e. its a wafer thin veneer of potential plausibility masking a rather large and gaping hole of vulnerability. :-) Presumably if one were to introduce some form of path validation to replace that gaping hole with something a little more substantial one would also add a mechanism that would validate the aggregator as well. In which case, if the aggregator and path are validated then why would the origin AS definition require this double-barrelled approach of having both match? So I'm at a loss to understand why adding a further constraint (that the AGGREGATOR matches the "first AS after the AS_SET") helps in any way. Why do you think that this additional constraint in the definition of an origin AS is a net improvement? I'm also unsure as to your approach ere - surely the appropriate analysis here is to ensure that the definition encompasses valid (as per the BGP spec) actions by BGP speakers. i.e. if a BGP speaker acts in accordance with RFC4271, and generates ROAs as appropriate, then shouldn;t we be worried here is there are cases where acting within the spec produces outcomes that are judged to be not valid. So rather than "mitigating attack" lets look at this from the other perspective - does this definition fail to encompass legitimate actions on the part of BGP speakers? Back to basics - in the current BGP definition (you know, the one that still allows silly stuff to happen with proxy aggregation and AS Sets), isn't the Aggregator path attribute meant to denote the AS identity of the BGP speaker who performed the more recent proxy aggregation that formed this particular aggregate prefix? And its thats the case then surely that AS is the origin of the aggregated route? Yes? As far as I can tell your case would be stronger if you proposed "use Aggregator, if present, otherwise use the AS that follows (where "follows" is defined as "to the left of" in a Right to Left sequence ordering of the path from origin to local) the AS Set. If there are multiple instances of AS Set in the path and no aggregator, then abandon all hope and surrender to the gods with an unknown origin AS" as this would align wioth the text of the BGP spec that makes AGGREGATOR optional. But requiring a match is going one step further than the BGP spec, surely. So I'd like to propose the following text in section 3,. which adds a sentence immediately before the final sentence in the paragraph: 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. If the AGGREGATOR attribute is missing, then the origin AS is the first AS element of the last path segment of type AS_SEQUENCE (i.e. the AS in the rightmost position immediately preceding the final AS_SET path segment in the protocol message. Otherwise the route's origin AS cannot be determined." It does not attempt to impose a greater constraint on the definition than that of the BGP standard itself, which notes that AGGREGATOR is an optional transitive attribute containing the last AS number that formed the aggregate route. So either its there and therefore its the most recent aggregator or its not there in which case look at AS the immediately precedes the AS Set. (Frankly, deprecating AS-Sets is a far better answer to this particular definitional problem you have noted, and having some form of mechanism that validates path is about the only way I know how to detect folk who lie about the path. You can't substitute an origin validation technique for path validation. Square pegs, round holes, etc.) regards, Geoff > 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 -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 [email protected] _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
