> Damien, > > In a private email, someone pointed out that the attack described below will > generate at most 1K ICMP messages per second and that won't be enough to case > thrashing. In order to make the attack work, we will need to: > > - increase the number of hosts in the site
But then the bottleneck of the attack is limited to the site's bandwidth to the backbone. > - increase number of packets per second in the attack flow > - engineer the attack flow so that the majority of packets actually reach > hosts and elicit ICMP Port Unreachable messages. > > Assuming that it is possible to engineer such an example, are Options #5 and > #6 our only mitigation? > > Ron Dino > > >> -----Original Message----- >> From: Ronald Bonica >> Sent: Thursday, March 21, 2013 6:12 AM >> To: 'Joel M. Halpern'; 'Dino Farinacci'; '[email protected]' >> Cc: 'Noel Chiappa'; '[email protected]' >> Subject: Analyzing Options 1 - 6 (was: Need comments on LISP Threats >> Analysis) >> >> Damien, >> >> In order to shed light on the relative merits of Options 1 through 6, >> you might want to consider the following attack in the threats >> document. >> >> Modifying the Reference Network slightly, the LISP site at the bottom >> of the diagram is served by LR3 and LR4 (as it is in Figure 1). Behind >> LR3 and LR4 are two CPE routers, called CPE1 and CPE2. Behind CPE1 and >> CPE2 are IPv4 subnets A-Z. Each subnet is numbered from a /24. On >> average, 25 hosts are attached to each subnet. >> >> An attacker sends a continuous stream of traffic towards the site. The >> stream is not particularly large, when compared to the aggregate of >> traffic flowing into the site. However, it does contain over 1K PPS. >> Each packet contained by the stream is unique, in that it contains: >> >> - a spoofed source address that is selected at random from a pool of >> valid IPv4 prefixes >> - a destination address that is selected at random from subnets A-Z >> - protocol and port numbers that are selected at random from a pool of >> protocol and port numbers that represent applications that are likely >> to be running at the site >> >> The attack stream can be sourced by either SA, by a host on the global >> Internet that is connected via a PITR, or by HA, if L1 and L2 don't >> validate source addresses as they should. >> >> Now assume that LR3 and LR4 allow the stream to pass into the site >> (Option #1). CPE1 and CPE2 will send an ICMP Destination Unreachable >> Message in response in response to each packet that is destined for an >> address to which no host is assigned. The hosts will most likely send >> an ICMP Port Unreachable message in response to each packet that is >> actually delivered to the host. Because each ICMP message is destined >> for a randomly selected, spoofed address, EID-to-RLOC cache thrashing >> is a real possibility. >> >> Option #5 prevents cache thrashing by sizing the cache appropriately. >> Option #6 allows LR3 and LR4 to provide continue to serve the site, >> even in the face of cache thrashing. None of the other options appear >> to help much. >> >> Do you agree? If so, are Options #5 or #6 required whenever LISP is >> deployed in an uncontrolled environment (e.g., on the global Internet)? >> >> Ron > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
