1 \subsection{004: connection up, down, wanted}
3 \subsubsection{004: Definition of requirement }
5 All internal SA entries should have a status of whether the connection is up
6 (keying material is available), down (keying material has expired), or is
7 wanted (keying material not yet available). This is part one.
9 There is an additional situation in which the MAST device may need to be
10 marked down. This is when it is known by the routing system that all routes
11 to the outer destination will fail. This will typically only be true for
12 systems without default routes (i.e. that are in a default-free zone). This
13 second feature is part two.
15 \subsubsection{004: Response}
17 Part one is committed to. There is an issue that we currently do not
18 look for expired SAs unless we are attempting to use them. To fix this,
19 we will need to walk the SA table periodically.
21 Part two raises some design questions. Specifically, how does one know if
22 the outer destination is routable unless looks?
25 \item each SA (and thus each conn) could maintain a pointer to
26 a struct dst\_entry. This has some savings in that one doesn't
27 have to lookup the route each time that the SA is used.
28 (One does the lookup if the entry is either invalid, or non-existant,
29 this is just a cache. The TCP PCB does this as well)
31 As these structures are reference counted, we can safely hang
34 If asked about link status of a MAST device, then one just has to walk
35 all SAs associated with this device, looking for at least one with SA
36 which has not been obsoleted.
38 \item alternatively, we do as we currently do, but upon failure to find
39 a route to the outer dst, we bash the link status of the device to
40 down. (We only change when all SAs say down, which makes this somewhat
43 Once the device is down, then we should really discard any packets that
44 arrive at the MAST device. We do not want to waste time encrypting things
45 we would then through away.
47 We could do something like let 1\% through to do the above test, but that
48 seems like a poor choice, since routing daemons may have found other ways
49 around in the meantime, so no traffic would ever reach us.
53 See also requirement 1.
55 The first solution is preferred, but neither are committed to at this time.