Hey Sandy, Sorry about the delay. I've commented below:
On Mar 12, 2013, at 6:45 PM, "Murphy, Sandra" <[email protected]> wrote: > 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. As I recall Danny pointing out: when an adversary is on (or in) path, and subverts some aspect of communications, it is sometimes called a MITM attack. I don't think we intended to coin a new phrase, just use the colloquialism. I think the nuance you may be keying off is that someone that is on/in path may not (necessarily) be attacking. I think this draft is worried about improper manipulation of the path because of the potential for an attack. The existing text: ``the authors believe the capability to prevent leaks and MITM leak-attacks should be a first-order engineering objective in any secure routing architecture. was meant to disambiguate this. > > 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. Again, the discussion of route leaks is in terms of the attack vector they open up. It's a vulnerability that we think needs attention. > 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. This is a vulnerability assessment. ``Attack'' is intended to be descriptive, not a scare word. > > 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. (:-)) I don't know that this is true, but I will claim that these are different problems and ought not to be conflated. Much of the reason for this draft was to make that point. This was mentioned in the existing text: It is important to note that the route leaks described herein are NOT 'misorginiations.' Rather, these are cases in which routes are propagated with their authentic origins, but are misdirected through unexpected intermediaries. Thanks! Eric _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
