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 A new version of I-D, draft-ietf-sidr-roa-validation-07.txt has been successfully submitted by Geoff Huston and posted to the IETF repository. Filename: draft-ietf-sidr-roa-validation Revision: 07 Title: Validation of Route Origination using the Resource Certificate PKI and ROAs Creation_date: 2010-10-10 WG ID: sidr Number_of_pages: 10 Abstract: This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
