>> In some ways I think building a taxonomy of scenarios that could be >> called route-leaks is useful, but I do think there is a danger is >> overly fixating on a precise definition of a commonly used term ... > > The state today is: "I know it when I see it" > which isn't super helpful in the 'gosh, it'd sure be nice to stop > having ISPA leaking my routes all over creation' fight.
Chris, If we step back for a moment and look at how we tackled prefix hijacks, there is a valuable lesson there that applies also to tackling route leaks. Initially, we classified prefix hijacks into two types: 1. Prefix hijack, 2. Subprefix hijack. This was based on commonly observed hijack incidents. We started looking at solutions, and determined that generating ROAs for the prefixes would be a solution for the first one. Then we thought a bit more, and determined that specifying MaxLength in the ROA would be a partial solution for the second one. After we included ROAs in our design, we realized that there are these two new classes of prefix hijacks that try to defy ROAs and maxLength: 3. Subprefix hijack where maxLength is not violated, 4. Faked-origin (prefix/subprefix) hijack. Thus, our understanding evolved to classify prefix hijacks into four types, each calling for possibly a different solution component. This was, in part, the consequence of the solutions we were considering. Then we thought that perhaps we can put two ASes in the ROA (origin AS and the second AS) to try to disadvantage the faked-origin hijacks. Because then the hijacked route is at least two hops longer compared to the legitimate one. But eventually, we decided to do the path signatures since we had to protect AS path anyway, and path signatures approach also solved prefix hijacks of Type 3 and Type 4 above -- because they are essentially path modifications. Viola: Now we have the solution for all four classes of hijacks plus full AS path protection! (Granted -- our solution is not yet complete because it doesn't solve route leaks.) The essential lesson that I think we learned from the above is that classification based on observed or easily conjectured scenarios works! So yes, classify and conquer should be the motto here. As is evident from the above, starting to propose solutions based on what we know -- even if it is partial knowledge -- is helpful. And with some solution components in place, further taxonomy naturally evolves to provide greater clarity into problem definition and classification. Sriram _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow