\subsection{028: eroute table must permit overlapping definitions}

\subsubsection{028: Definition of requirement}

Various people have talked about the concept that one might negotiate a long
term SA, call it "A". At a later time, one negotiates another SA of a shorter
term nature, "B". When B expires, one realizes that A is still valid and
continues to use it. 

\begin{verbatim}

    time---->
  A: |------------------------------------------------------|
  B:                  |---------------|
 SA  AAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAAA
\end{verbatim}

It is not clear why one would do this operationally. 

   Note that the above pattern could occur for a different reason:

\begin{verbatim}
     time---->         *-backhoe event  *-link restored
   A:   |------------------------------------------------------|
   B:   |------------------------------------------------------|
    SA  AAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAAA
\end{verbatim}

Assuming that some routing daemon realized the link was down and was able
to indicate this to KLIPS. The backup SA might (or might not) have been
negotiated far in advance, and it might (or might not) survive long after the
primary link was restored. 

\subsubsection{028: response}

This works just fine in the SAdb. The problem is the reference to the SA.

It does not currently work due to the eroute table. 

For a fix in the eroute world-view, eroute's should have lifetimes. These
should essentially be copied from the SA that they reference. When the eroute
expires, it would turn into a \%trap/\%hold so that traffic does not
get out unencrypted. In order to support overlapping definitions, when an
eroute would replace another eroute, instead of causing an error (EEXISTS) or 
replacing the eroute, link the eroute into a list. Ordering of this list is a 
problem: there are multiple lifetimes (time, bytes and packets) that may
occur. As bytes and packets do not expire, but time does, use the eroute with
the shortest expiry date.

In the eroute plus SAindex indirection table world-view, the reference to the
SA will be via the indirection table. Thus, upon expiry of the SA, then one
can change all references by updating the SAindex indirection table. No
changes to the eroute would be required. Instead, when installing a new
eroute that would replace an existing one, update the SAindex indirection
table instead, and link the SAs such that expiry of one will cause the
indirection table to be updated.  

In the netfilter world-view, it would become the responsibility of user space 
to detect this situation of an overlapping route (since netfilter itself
would not know) and add the appropriate linking of SA's.

The result of one or more of the above fixes would be to permit rollover of
one SA to another rather than replacement.

However, as the operational rational for this is in the space of routing
daemons, it is expected that a seperate MAST device would be configured for
each of the two (or more) logical paths. Each one would be configured with 
a different default SA. There is no eroute and no netfilter rule to change,
so there would be no issue. 

Conclusion: the general requirement is rejected, while the operational
specific of a failover is provided by existing requirements.

This requirement has no clear advantage for Opportunistic Encryption.

