Understand, but the further we qualify, the harder it will be to launch a real attack. I am not saying it is happening, but just want to be practical.
Dino On Mar 21, 2013, at 10:10 AM, Ronald Bonica <[email protected]> wrote: > Assume that the site is sufficiently well-connected so that the entire attack > flow and all of the ICMP responses can get through. > > Ron > > >> -----Original Message----- >> From: Dino Farinacci [mailto:[email protected]] >> Sent: Thursday, March 21, 2013 1:06 PM >> To: Ronald Bonica >> Cc: Joel M. Halpern; [email protected]; Noel Chiappa; >> [email protected] >> Subject: Re: Analyzing Options 1 - 6 (was: Need comments on LISP >> Threats Analysis) >> >>> 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
