just a few comments. About the MITM motivation
The draft says that route leaks can attract traffic and put the AS on the traffic's path and are therefore MITM attacks. I don't buy this. All BGP updates have the potential to attract traffic and put the AS on the traffic path. We don't call them all MITM attacks. And calling a route leak a MITM attack depends not on what the leaker does, but on its business relationship. That is, if ISP1 is AS1's customer, not its transit provider, propagating IPS2's update would not be considered a route leak. But AS1 propagating ISP2's update is just as much attracting traffic from ISP1 and just as much putting AS1 on the traffic path, but is considered totally normal, not a MITM attack. The customers might trust their immediate provider and therefore trust it to propagate their route, but that trust dilutes further away. And the further away, the harder it is to know the business relationships to judge the route as benign or leak. I think there are plenty of reasons to consider route leaks a problem to be solved without resorting to scare words. About the spread of route leaks Route leaks spread because the leaker has neighbors (and they have neighbors, etc) who choose that path. So it is the leaker's position in the physical and policy topology that makes the route leak spread. Any leaker in a position to leak a route and have the leak spread is also in a position to mis-originate a prefix. And doesn't need to wait to receive an update for the prefix to do so. This policy topology affects the mis-origination problem, too. Even with a route leaks solution in place, the former leaker can cause the same impact with a mis-origination, instead. Policy has a lot to answer for. (:-)) --Sandy _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
