4.4.2 004: Response

Part one is committed to. There is an issue that we currently do not look for expired SAs unless we are attempting to use them. To fix this, we will need to walk the SA table periodically.

Part two raises some design questions. Specifically, how does one know if the outer destination is routable unless looks?

• each SA (and thus each conn) could maintain a pointer to a struct dst_entry. This has some savings in that one doesn't have to lookup the route each time that the SA is used. (One does the lookup if the entry is either invalid, or non-existant, this is just a cache. The TCP PCB does this as well)

  As these structures are reference counted, we can safely hang on to this.

  If asked about link status of a MAST device, then one just has to walk all SAs associated with this device, looking for at least one with SA which has not been obsoleted.

• alternatively, we do as we currently do, but upon failure to find a route to the outer dst, we bash the link status of the device to down. (We only change when all SAs say down, which makes this somewhat difficult)

  Once the device is down, then we should really discard any packets that arrive at the MAST device. We do not want to waste time encrypting things we would then through away.

  We could do something like let 1% through to do the above test, but that seems like a poor choice, since routing daemons may have found other ways around in the meantime, so no traffic would ever reach us.

The first solution is preferred, but neither are committed to at this time.