Expiring a Prefix From a Subnet

The most common reason to meddle with the data that routers advertise is a network renumbering. We'll take a closer look at the entire procedure in chapter 24, right now we just make the router advertisement daemon expire a prefix from a subnet.

We can't just remove the prefix from the router; if we did this, then the router wouldn't know that the subnet is directly reachable and therefore couldn't deliver packets with a destination address from the prefix.

If we just set the preferred and valid lifetimes to zero, then according to what we've seen so far all hosts will mark the prefix as invalid and not use it anymore even for existing connections. An attacker connected to the subnet could therefore run a very simple denial of service attack by just sending router advertisements for the prefixes with zero lifetimes.

To avoid these attacks, RFC 2462 [110, section 5.5.3] demands that a host will behave like this only if the router advertisement was authenticated with an IPsec AH header—which isn't available for multicasts. Otherwise a host will lower the valid lifetime it stores for the prefix to no less than two hours.

It is however possible to set the preferred lifetime to zero with an appropriate router advertisement. While this might still be used for a less threatening denial of service attack under certain conditions, quickly deprecating an address is desirable when we need to fix a problem on short notice.

So unless we set up an IPsec framework that supports multicast authentication, expiring a prefix from a subnet takes at least two hours, but as long as we have another preferred prefix available we can quickly switch over to it. The deprecated prefix won't be used anymore except for existing connections.

In the previous section we have seen that some of the advertising daemons don't implement absolute expiration dates properly. The easiest strategy to deal with the situation is this:

1. To expire a prefix from the subnet we first set the preferred lifetime in the advertisement daemon's configuration to zero and restart the daemon.

2. We need to figure out for how long we need to keep a deprecated prefix before we can turn it invalid. This depends on the applications we use as well as the willingness of our upstream provider to keep the prefix routed to us. If we aren't in a rush, keeping the prefix deprecated for a week is in many cases desirable. We need to keep it for at least two hours, unless we use IPsec authentication in the subnet.

3. At least two hours before we finally want to invalidate the prefix we set its valid lifetime to zero and restart the advertising router.

4. When the address is finally expired, we remove it entirely from the router configuration.

To avoid serious problems if anything goes wrong, three measures have proven particularly useful:

□ An alternate prefix, either the successor of the one we expire, or a unique-local prefix, should be configured. All nodes must be reachable through this alternate prefix.

□ Every change to the router configuration must be visible in the advertisement packages. To avoid surprises it is extremely helpful to observe them in a packet sniffer.

□ After every step the hosts must show an updated interface configuration. Some advertising routers don't immediately send an advertisement when they are restarted, so we must wait a while for the daemon to send an updated advertisement.

Was this article helpful?

0 0

Post a comment