Thanks Joel; I think that draft-ietf-lisp-threats-09.txt is a start towards a threats document, but that it has serious omissions and needs more work before being progressed. Here are some specific comments:
Section 2 (On-path Attackers), first paragraph: On-path attackers are attackers that are able to capture and modify all the packets exchanged between an Ingress Tunnel Router (ITR) and an Egress Tunnel Router (ETR). To cope with such an attacker, cryptographic techniques such as those used by IPSec ([RFC4301]) are required. As with IP, LISP relies on higher layer cryptography to secure packet payloads from on path attacks, so this document does not consider on-path attackers. To me an on-path attacker is one which is on the data path. Such an attacker might attack the contents of the data packet. In this case the paragraph seems mostly correct to me: You encrypt the contents if you don't want someone on the path to the destination to look at the contents. However, as is discussed later in the document, LISP allows systems which are not in the normal physical path, through a gleaning attack, to inject themselves into the data path. This could be applied to allow attacker's systems to inject themselves into the path of the key management protocol. This implies that a legitimate user could get keys supplied by an attacker, just as easily as it could get keys supplied by a legitimate Internet site. If you are proposing that end to end encryption is the solution to on path attackers then you need to understand the implications of LISP on the operation of the protocol needed for key management to support end to end encryption. Also, you should mention in this section that a gleaning attack would allow at least in the short term for an attacker to become temporarily on-path even if they are not on what should be the normal path to the destination. An on-path attacker might choose to only change something about the LISP handling details, such as exploding the map cache or redirecting a user to a different site. Some of this is mentioned later in the document. One thing that is not mentioned: Suppose that the encapsulated packet is encrypted. The on-path attacker could however see the LISP header, and thus could change the nonce, or add a nonce, or reply to the nonce, change versioning information,... Are you proposing that the LISP header be encrypted also? If so, where is this specified and what does it do to forwarding performance in the xTR? Section 4.3.1, second paragraph, third sentence: This is not different from today's Internet where a spoofing off-path attacker may inject data packets in any flow. In terms of injecting traffic that the end system receives and acts upon, I believe that this sentence is entirely true. However, in terms of the effect on the router's control plane, and particularly the operation of xTR's, this sentence is not true. Today there is very little that a spoofing attacker that is outside of a particular service provider can do to exercise the control plane of that provider's routers. This is important and intentional (see DOS discussion below). Minor nit, next sentence: A non-spoofing off-path attacker (NSA)... Given recent events, I think that "NSA" is an unfortunate acronym to use here. How about NSOA? Section 4.3.1.1 (Gleaning Attacks), last paragraph: By itself, an attack made solely using gleaning cannot last long, however it should be noted that with current network capacities, a large amount of packets might be exchanged during even a small fraction of time. The amount of damage that might be caused by this may depend upon what happens to be exchanged in that "short amount of time". For example, the initial handshake between sites (at the application layer) could include sign in information (account names and passwords), on the basis that this is the sort of information that needs to be exchanged at the beginning of, for example, financial transactions. My understanding is that for Internet commerce, it is normal for users to be redirected to a different site to enter credit card information. This appears to constitute a "new session" (or at least may be to an entirely different location) and therefore the entire credit card exchange could occur in a small period of time. I think it would be worth mentioning here that the sensitivity of the information that could be exchanged during this "short amount of time" is not known, and could potentially be serious. Also, depending upon how long xTR's are willing to store gleaned information (before the map request comes back), the time that a user is misdirected due to a gleaning attack might be extended by coordinating a DDOS attack with the gleaning attack. For example, an attacker may send packets to a very large number of sites, with a source EID which is from a major stock broker or bank and an RLOC from the attacker's captive servers. The many sites glean the EID to RLOC mapping from the arriving packets. Each pretty much simultaneously initiates an EID lookup (to verify the EID to RLOC mapping). This creates a DOS attack on the control plane of the mapping function supporting that stock broker or bank. This implies that the responses are going to be delayed (and could be greatly delayed), which allows the incorrect mappings to last longer than they otherwise would. This allows any systems that actually happen to be trying to connect to that stock or banking site to be redirected to the a ttacker's site. The attacker then becomes a man in the middle and can for example can obtain the password and account information for users. Last paragraph of section 4.3.2.2: If the size of the Map-Request message is larger than the size of the smallest LISP-encapsulated packet that could trigger such a message, this could lead to amplification attacks (see Section 4.4.1) so that more bandwidth is consumed on the target than the bandwidth necessary at the attacker side. The size of the packet is not the only issue. If the amount of processing required to send a map-request and deal with the reply is greater than the amount of processing that is required to send a packet that triggers such a request, then this could also result in an amplification attack. In principle it would seem that sending out a large number of packets to trigger such a request would be relatively straightforward (for example the attacker might be sending out many packets only incrementing the EID in order to attack the ITR that will need to generate many map requests). We may note that for many systems, particularly very high speed routers (which might exist for example as PE routers connecting very large enterprise customers), the control plane may be several orders of magnitude slower than the data plane, so that an attack that requires response from the router's control plane would be much more serious than an attack of the same size that can be handled in the data plane. I will say more about this in my comments below regarding DOS attacks. Section 4.3.2.3, third paragraph (right after the bullets): The first type of packet should not cause any major problem to ITRs. As the reachability test uses a 24 bits nonce, it is unlikely that an off-path attacker could send a single packet that causes an ITR to believe that the ETR it is testing is reachable while in reality it is not reachable. To increase the success likelihood of such attack, the attacker should create a massive amount of packets carrying all possible nonce values. However, this could be a problem if there are on-path attackers, since they will see the nonce. They could insert nonce's where none are present, requiring a response from the ETR. Given that the control plane of very high speed PE routers may be much slower than the data plane, this could cause a relatively moderate data stream that the data plane or the PE could easily handle to turn into a control plane attack that the control plane of a PE router could not handle. Also, the on-path attacker could see the nonce's and respond "correctly" (or in a way that the ITR that sent the nonce *thinks* is correct), thereby "verifying" connectivity when none is present. You dismissed on-path attacks earlier in the document on the basis that the user data could be encrypted, but these are examples of on-path attacks that would be on the LISP header and operation, and not on the user data. Section 5.2 (Denial of Service): You need to mention here the relative difference in speed between the data plane and the control plane of high speed routers. For example, there are plenty of examples currently widely deployed of routers which can handle a few terabits of data in the data plane. These routers might typically have gigabit Ethernet links to the control processor, but I doubt that any of them could handle Map-Requests coming in at line rate at a gigabit. Thus the ratio between the speed of the control plane the speed of the data plane is significantly greater than 1000. I understand that many PE routers have slower data planes (and the CE "wireless router" that sits in each of our homes is of course a lot slower than this), but large data centers or large enterprise sites could very well be connected to their service provider via a few very high speed PE routers. Therefore an attack that would be trivial to handle in the data plane (say, a few gigabits) could overwhelm the control plane. Gleaning allows incoming packets to create map requests, which allows a data plane attack to turn into a control plane attack. Given the difference in speeds between the data plane and the control plane, this makes it much easier to create an effective DOS attack. Section 8 (Security Considerations). I am pleased that you removed the sentence from section 1 of the previous (-08) draft that read: "As a result of the performed analysis, the document discusses the severity of the threats and proposes recommendations to reach the same level of security in LISP than in Internet today (e.g., without LISP)". This sentence was not actually correct. However, in looking through the document and in thinking about the implications (see the rest of this email) it is quite clear that the security of an Internet using LISP would be significantly less than the current Internet (at least if you assume that there is *any* security at all in the current Internet). I am thinking that there should be a sentence at the end of section 8 to the effect that "At the current time it appears that LISP would have significant security implications if deployed on an Internet-wide scale". Finally, two items left out: I don't see any discussion on the effect of LISP on firewalls. I am assuming that pretty much all currently deployed firewalls are not able to look past a LISP header to inspect the contents of packets. At a minimum, this would seem to imply that LISP will need to be deployed toward the Internet core from the current firewalls, so that the firewalls can be looking at normal (unchanged) IP packets. There is another issue which might belong in the section on privacy: In the Internet today if you want to attack a network with prefix aa.bb/16, and you see this advertisement in the BGP routes, you can pick a random address and send a packet and see if anything happens. You get little feedback. With LISP you can send a map request to a random address in the block and get back a map reply. This gives you an RLOC which is in general the actual IP address of a real PE or CE router. Of course you can repeat this across the entire /16, or even the Internet (given sufficient time and traffic), and get something close to a complete list of LISP xTRs. This implies that if service providers implement LISP on PE routers, then they will be exposing the identity of their PE routers to worldwide inspection. Given the number of PE routers in the world (obviously much larger than the number of service providers, and given PA address aggregation probably larger than the number of routes that show u p in the BGP routing table) we should expect that there are lots of PE routers that have not been carefully secured, and exposing their existence to open worldwide easy discovery would likely open the door to a number of attacks that involve compromise of PE routers. Of course if LISP is deployed on CE routers then their RLOC would similarly be exposed. Thanks, Ross -----Original Message----- From: lisp [mailto:[email protected]] On Behalf Of Joel M. Halpern Sent: Friday, May 09, 2014 11:54 AM To: [email protected] Subject: [lisp] Restarting last call on LISP threats Sorry for the delay getting this out. This email starts a new (and hopefully final) last call on draft-ietf-lisp-threats, version 9: http://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ The last call will end in two weeks, close of business 23-May-2014. Thank you, Joel _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
