I realized my wording of sentences was a bit misleading in a few places. These corrections shown below (with [CORRECTION: ... ]). Sorry for the repeat.
Sriram ----- Message showing the Corrections ----- 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 [CORRECTION: valid (invalid)] if it matched [CORRECTION: matched (didn't match)] 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 [CORRECTION: any proposed algorithm] cannot [CORRECTION: must not] 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
