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
- 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
> -----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
