On Thu, Mar 6, 2008 at 6:30 PM, Michael Meisel <meisel@cs.ucla.edu> wrote:
This is worth exploring, but, in APT at least, there is no time that an
ITR requests a mapping from a default mapper without also requesting a
packet to be forwarded on its behalf. So it seems unnecessary.
Hi Michael,
The worm on Grandma's unsecured machine can pump 30kpps through a
properly configured $50 FiOS line at 2mbps. Each worm packet can have
a different, randomly selected destination IP address. If your APT
island provides a gig-e upstream from a neighborhood infested with 100
such worms, what happens when your default mapper gets hit with 3mpps?
It's only 200mbps of traffic after all.
A general purpose answer to this question that works for any such
system is: you build a protection device that will permit no more than
n packets per second from any one source IP address. As a result, the
mapper doesn't see 3mpps; it sees perhaps 10kpps total from the 100
worms and it can keep up with that. Each source is then constrained to
100 "new" destinations per second, but that's generally within bounds
for acceptable source behavior.
The architectural worry is this: how deep in the Internet core is your
mapper? If your mapper is close to the edge then with a protection
device there won't allow enough traffic to kill the mapper. If it's
deep then its share of the traffic from a hundred thousand worms are
going to take it down.
> Depending on return packets to indicate problems, such as the address
> for an ETR becoming unreachable, an ETR becoming unreachable or a
> destination "behind" and ETR becoming unreachable is way too dangerous.
> Path MTU discovery does this and it works quite poorly in practice. At a
> minimum, unreachables will be rate limited. They may also fail to be
> generated, be filtered or spoofed.
Though APT relies on return packets to indicate problems, I think we've
addressed a number of these issues. First of all, we use normal IP
packets for this purpose, so filtering is unlikely. The destination
address for such packets comes from the mapping database, and the sender
cryptographically signs these packets. The info that went into the
mapping database was also cryptographically verified. So spoofing should
be very difficult. Since it's part of the APT protocol, I don't see why
these packets are any less likely to be generated than a BGP withdrawal
today.
I haven't dug through APT wrt this issue, so I can't speak with
authority here. I do note that as listed at
http://bill.herrin.us/network/statechange.html, Pulled Cache with
Change Notification DOES NOT guarantee that state change propagates.
A BGP withdrawal doesn't depend on any given packet reaching its
destination. If the neighbor fails to receive the withdrawal, the BGP
session stalls while the source retries. If completely unsuccessful,
the BGP session fails causing the neighbor to initiate a withdrawal of
ALL of the source's routes. This pattern propagates as far as needed.