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 o f 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 (le ft-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
