Ross, see my responses inline. > Detailed comments below. To summarize, these details include three threats > which are new to LISP and which are not adequately explained in the current > threats document: > > (1) The Control Plane Threat: LISP allows a dataplane DOS attack (lots of > packets sent to overwhelm a site) to turn into a control plane attack (the > router is forced to respond to the attack in the control plane, which is of > course frequently multiple orders of magnitude slower than the data plane, > particularly for very high speed routers).
It turns into a control-plane request stream which is many orders of magnitude less than the data packet stream. And since the data-plane bandwidth to the control-plane bandwidth inside of the xTR is also orders of magnitude of difference, you will find this will protect the mapping database control-plane. That is, no router control-plane will be capable of sending Map-Requests at any rate faster than at least 2 orders of magnitude of what the control-plane in that router implementation can do. And then, if this xTR will rate-limit on top of the Map-Request rate, it is even slower. This is not speculation. This has been proven with many different implementation attempts over the last 7 years. > (2) The Privacy Threat: LISP provides an attacker with a relatively easy way > to determine the identity of large numbers of PE and/or CE routers (globally, > if LISP is deployed on that level) . We should document this, but there are tons of easily accessible databases in protocols, operational data structures, key management data, and application systems that do this as well. But LISP can encrypt or require authentication of this information, so it can be hidden from potential attackers. When we built the mapping database system, we wanted it to look like DNS for scale and accessiblility but knew the security concerns and hence why we have several mechanisms to allow a mapping database to be a closed system, even at Internet scale. > (3) the Traffic Gleaning Threat: If an xTR gleans EID -> RLOC mappings from > incoming packets, this provides an easy way for hackers to intercept traffic. > I put this threat third because gleaning can be turned off, and thus this > threat can be defeated simply by not gleaning EID -> RLOC mappings. This is why the spec says MAY for data gleaning. We put this in the main specification because in closed enterprise environments people wanted this feature. > WRT the first of these, Dino has pointed out that the control plane of > routers already receive BGP packets from sources outside their domain. Thus a > DOS attack on the control plane of routers can be launched through BGP. I don't want to make this a LISP versus BGP debate. Because if we do, we won't make any progress. But with a centrally managed database system, you can put controls in without getting an entire Internet peering topology to buy in. The security systems we can put into the mapping database, can be incrementally added and provide benefit to xTRs that don't even know what was added. The mapping database is distributed like DNS to scale but managed centrally. And I am not talking about using SDN type approaches either to achieve this. > However, the number of BGP peers that a router has is limited, and can be > known a priori. Thus it is possible, and relatively common, for a router to > be configured to only accept BGP updates from a very limited number of > identified other routers (in many cases a moderate number of external peers > plus a few internal route reflectors). Each of these known BGP sessions can > be individually rate limited, and no other source can be allowed to send BGP > updates to the router. Also, other control traffic to the router can be > limited to internal peers (eg, OSPF, IS-IS, LDP, and/or RSVP from other > internal routers, plus network management traffic from internal sources > only). Thus today every source of control plane traffic to the router can be > controlled and rate limited. For C If you compare the IGPs and protocols that run inside of an AS with LISP, then LISP has all the same benefits because a single organization is managing the architecture, so they can decide unilaterally decide how much security, gleaning, uRPFing they use. I often compare LISP to BGP because of the scale we want LISP to grow to. > E routers the number of BGP peers can be even more limited, possibly to one > (the PE) or even none (for stub domains use manually configured static > routes). > > If LISP were ubiquitously and globally deployed across the Internet, then > mapping requests could come from pretty much anywhere. Similarly incoming > data plane traffic which contains EID's that are not currently listed But those Map-Requests can be authenticated if the attacker chose a Map-Resolver that wanted to operate at a high security level. There will always be open Map-Resolvers (just like DNS server 8.8.8.8) which has to scale for good and bad requests. Those systems have dozens of implementation techniques to do signature detection and mitigation of suspicious packet-request trains. > in your EID -> RLOC mapping would cause a mapping request to be generated in > the control plane. I understand that mapping requests (both incoming and > outgoing) can be rate limited, but this simply turns a "shut down the > router's control plane" attack to turn into a "shut down the router's mapping > function" attack. If correct operation relies on the mapping function, then > you have still broken the router. You have to couple rate-limiting with some cacheing and timing information. > The second of these is a big deal which has not been talked about much. We > don't want hackers to know the identity of all PE and/or CE routers. It is > difficult to fully anticipate what attacks will occur, but there certainly > have already been intrusions of various kinds against routers and making it > fundamentally easier for hackers to know the identity of a large number of > routers is something that it at least important enough to mention. If I traceroute to your house Ross, I know all routers on the path. LISP does not make this problem worse. And we cannot practically say every weakness in the Internet is also a weakness in LISP, so we may as well not deploy LISP. That will give people the wrong impression. We want to be honest and document threats, but we can't get out of hand, because we will ALWAYs be incomplete. And the danger and effort spent on LISP will be what it can't do rather than what new things it brings to the Internet. > Regarding the third of these, there have already been attacks which mis-route > traffic. Eg: > http://www.wired.com/2013/12/bgp-hijacking-belarus-iceland/ I recommend that no one use data-packet gleaning in an ETR unless the mapping system knows all sources sending map-requests to a closed and control mapping system. Data-plane gleaning should not be used generally on the capital-I Internet. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
