[Design] requirements list

[John Denker]

At 08:52 PM 8/3/01 -0400, Michael Richardson wrote:

> >>>>> "John" == John Denker <jsd@research.att.com> writes:
>     John> Currently klips1 apparently identifies a tunnel by what remote
>     John> subnet it serves.  That means that if a new tunnel is brought up
>     John> serving the same subnet, it supersedes the previous one.
>
>     John> We need a more complex semantics, and some way of expressing it.
>     John>   -- SOMETIMES you do want the new tunnel to supersede the old one.
>     John>   -- SOMETIMES you want the new tunnel to operate in parallel,
>     John> using equal-cost multipath, for load sharing.
>
>   When you say this, what precisely is it that you would actually express?
>
>   Is this expressed by the operator? Would you tell pluto?
>
>   Or is this something that pluto tells KLIPS?

Well, that's an interesting question.  I don't have definitive answers, but 
here are some desiderata and hypotheses that we can consider:

1) First, let's consider the ordinary prosaic scenario:  There is 
conceptually only one tunnel.  There is only one "conn" defined in 
ipsec.conf.  A little while before the old SA expires, we negotiate a new 
one.  We want to start using the new one as soon as it is available, in 
order to prevent lost packets due to race conditions (such as 
time-in-transit effects, or clock drift relative to our peer, et cetera).

This process, where an elderly SA retires and is succeeded by a younger 
one, we can call a "lineage".

In this case, pluto takes the initiative and keep klips informed.  I don't 
think the routing daemons need to know about it at all.  This is a feature, 
because it means that prosaic users don't need to get tangled up in the 
complexity of routing daemons.

2) Now let's consider the failover scenario, i.e. UNequal-cost 
multipath.  Pluto can contact its peer and negotiate N different tunnels 
serving the same subnets.  Each of these will have its own separate 
lineage, its own succession of SAs over time.

The collection of all N lineages serving the same same subnets via the same 
gateways we can call a "tribe".

Conceptually, at the IPsec level, each lineage "theoretically" should be 
managed separately.  The tasks of sorting out which tunnel to use, moment 
by moment, "theoretically" should be foisted on the routing daemons.

For the pluto at this end, it might be almost that simple.  However, at the 
far end, there are some devilish details.  Suppose our end contacts the far 
end and proposes a renewal.  The packet format on the wire does not make it 
super-easy to distinguish a proposal for renewing tunnel A from a proposal 
for renewing some other tunnel in the same tribe.

The best tactic I can think of is to let each lineage have its own RSA 
id.  (If that means we can't use pre-shared secrets for multipath, so be 
it.)  If somebody has a better tactic, please let us know.

3) Now let's consider the load-sharing scenario, i.e. equal-cost multipath.

I think it can be treated as a special case of the failover scenario, where 
multiple lineages are assigned the same cost.

Actually it may be much simpler than the failover scenario, because it can 
be done without involving router daemons, just relying on the kernel's 
built-in equal-cost multipath features.

>   I can very simply see one expressing:
>
>conn me-you1
>      left=5.6.7.8
>      leftsubnet=1.2.3.0/24
>      right=9.1.2.3
>      rightsubnet=10.2.3.0/24
>
>conn me-you2
>      left=5.6.7.8
>      leftsubnet=1.2.3.0/24
>      right=9.2.4.5
>      rightsubnet=10.2.3.0/24

That's about right.

We will need to add something to specify the IP address of the mast 
device(s) -- in contrast to left=... which specifies the wild-side address.

And BTW recall that the right=... concept needs to be redesigned to handle 
road warriors, especially when we have address inertia.  But that is a 
whole nother topic.

>   And then some kind of thing to state relationship, e.g.:
>      multipath=me-you1
>   or
>      fail-over-to=me-you2

Do we need that?  The alternative would be to handle this at the router 
level, by assigning some sort of cost to the route created by each conn.

This begs the question of to what extent the router configuration file 
needs to be coordinated with the IPsec configuration file.
   -- Is the cost assigned in the ipsec.conf file, or
   -- is the cost assigned in the router.conf file, or
   -- do we derive both of those from higher-order configuration specification?

>   I'm not sure how the mobility system occurs.

I'm not either.  Here are some vague preliminary thoughts:

This requires layer-crossing.  That's the whole point.  In one scenario, 
the mobile unit measures the RF signal strength on various channels, and 
then sends a message suggesting which tunnel should be used.
  -- HD suggested that there could be special IKE messages for this IBM 
and/or IWBM (I've Been Moved and/or I Will Be Moved).
  -- Another possibility is to just send ordinary router messages through 
the tunnel.  (This poses some mild chicken-and-egg problems, but there 
should be ways of solving them.....)