Geoff: You seem to agree about the feasibility of the new attack vector. While I was calling it origin manipulation, you see it as AS path modification. Let us go with AS path modification (yes, I agree you are right because an artificial AS_SET is inserted by the attacker into the AS path!). However, your comment about square pegs, rounds holes does not seem relevant here. Until now, for a normal prefix update (i.e., one without proxy aggregation, without AS_SET), we have always felt certain that RPKI ROA-based validation provided full assurance that the origin would to be valid if it matched with the AS in the covering ROA, even if the rest of the AS_PATH was altered in some way. Now (with the algorithm in the draft in its current form) we seem to have lost that assurance. For a normal prefix update (i.e., one without proxy aggregation, without AS_SET), now there can be false origination and this false update would be evaluated as “valid” by the algorithm, only because the hijacker manipulated the AS path cleverly enough to take advantage of what I think of as a loophole in the algorithm. Since we decided that the origin AS occurs in a particular position in the AS_PATH for normal prefix updates, the algorithm cannot take its eyes off of that spot for any other type of prefix updates (e.g., with AS_SET) when validating origin.
Although I like my empirical/heuristics-based proposal for a modification of the algorithm; I would let others speak up if anyone likes it and sees some merit. (Jeff Hass and Pradosh and few others did express support soon after Maastricht SIDR; no surprise if they would think differently now – the AS_SET issue seems inherently complicated.) In any case, you have cited complications also due to Appendix F.6 in RFC 4271 (another matter that Appendix F.6 seems so surreal). I fully agree with you and Chris Morrow that deprecating AS_SETs seems the best (and may be the only) way out. I also feel that at present the document should defer statement on validation of updates with AS_SET to a future time, pending outcome of the IDR action. Regards, Sriram ________________________________________ From: Geoff Huston [[email protected]] Sent: Sunday, October 17, 2010 5:01 PM To: Sriram, Kotikalapudi Cc: [email protected] wg Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted At the risk of repeating myself, let me offer three thoughts as simply as I can, and one not so simply: Origination validation does not stop folk lying in the AS_PATH, and, by implication lying in the AGGREGATOR path attribute as well. I do not understand what can be gained by believing otherwise. You can't substitute an origin validation technique for path validation. Square pegs, round holes, etc. If folk act within the constraints of the specification of BGP as defined by the current BGP spec, then any additional constraints applied in this draft should not invalidate an otherwise conforming BGP update message. The text I've proposed in -08 of the draft attempts to meet the above two objectives, without heading off into extraneous or diversionary areas. After reading Appendix F.6. of RFC4271 again I'm even less convinced that "the AS immediately preceding the final AS_SET in the AS_PATH" means anything at all in the context of which AS performed the AS_PATH aggregation. The "AS before the last AS_SET" assumes that the aggregation algorithm is "bung all the AS's in the AS_PATHS of the routes being aggregated into a bucket, pull out duplicates and put it into a AS_SET". But that's not what is described in Appendix F.6. The algorithm provided in that section of the draft allows for the construction of multiple AS_SET path elements in the AS_PATH and also allows for the aggregated path constructed by this algorithm to start with an AS_SEQUENCE, not an AS_SET. In this case the task of identifying the AS that performed the aggregation is actually quite fuzzy if no AGGREGATOR is present. I suspect that if one were to quibble with the "AS before the last AS_SET" as being what you do when no AGGREGATOR is present, then this section of RFC4271 leads me to say that the best you can say when no AGGREGATOR is present is that the origin AS is one of the AS's in the initial AS_SEQUENCE path element, but it is, strictly speaking, indeterminate as to which one it is. This leads to the alternative interpretation that the text in the -07 version was actually a "better" approach, namely that if no AGGREGATOR is present then its not possible to tell definitively which AS actually undertook the proxy aggregation action, and hence which AS should be deemed to be the origin AS. i.e. taking a conforming route that has not been altered in any malicious way and erring to a validation state determination of "unknown" is perhaps better in such circumstances than taking the same conforming route and erring to a validation state conclusion of "invalid". In such a context of a strict interpretation of the BGP spec as it relates to proxy aggregation, the AGGREGATOR AS, if present, should be listed somewhere in the initial (left-most) path element, and this path element must be an AS_SEQUENCE path element, and the AGGREGATOR performed the most recent proxy aggregation to form this route. If the AGGREGATOR attribute is missing, then the path aggregation algorithm as presented in the BGP spec leads me to conclude that it is not possible to definitively identify the AS that performed the proxy aggregation in all circumstances. At the risk of repeating myself again, the sooner the IDR WG deprecates AS_SETs in the BGP spec, the better! _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
