Hi all,
The recent discussions about issue #19 (same addresses for both
directions?) lead me to do some thinking about different ways
the tunnel header addresses for IPsec SAs can be chosen.
It seems that there are a couple of quite different approaches
to this (and some variations of those)... and I also have the
feeling that some of the text in the design draft and protocol
proposals has implicitly assumed one of these without really
making the assumption explicit.
Below I've gone through some of the approaches I've identified
so far, but there probably are others that make sense as well.
These aspects are also related to issue #17 (partial/full
connectivity)
-----
Option 1: "MOBIKE just informs the peer of our addresses; how
they get used is a matter of local policy beyond our scope."
This would be the approach closest to SCTP, I think (and quite
close to the approach in Francis's and Tero's protocol
proposals, I think). The basic operation here would be as
follows: Host A sends a list of its addresses to B (and when the
list changes, sends either a new list or diffs to the previous
one). And vice versa for B.
Host A selects the (tunnel header) src/dst addresses for its
IPsec SAs from its own list and the list it received from B in
any manner it wants. (Most likely this would somehow take into
account local policies and preferences, the order of addresses
in B's list, knowledge about connectivity or lack of it, etc.)
And vice versa for B.
Or in other words, the situation looks something like this:
Host A Host B
------ -------
List_A = (decided by A) -->
<-- List_B = (decided by B)
src,dst = f_A(List_A, List_B, src,dst = f_B(List_B, List_A,
local preferences, local preferences,
local info about local info about
connectivity, connectivity,
whatever) whatever)
Where f_A() and f_B() can be basically anything.
Pros and cons:
+ Similar to SCTP
+ Symmetric behavior may make sense when the situation is
otherwise reasonably symmetric (such as site-to-site VPNs)
+ Handling partial connectivity and failures is reasonably clear:
if an address (interface) goes down, it is removed from the address
list. If the failure is in the "middle" (no connectivity, dpd fails),
the address lists don't change, but both parties choose address pairs
that work based on their own information.
- Failure detection and recovery has to be done by both parties,
possibly increasing complexity
- No guarantee that f_A() and f_B() choose the same address pair;
this might not be desirable in e.g. "mobile client" case.
In particular, Host A can't move the "downstream" traffic
(from B) to some particular interface (address) without
deleting all the other addresses from List_A (unless we make
restrictions about f_A/f_B).
-----
Option 2: "Use the preferred/primary address"
It seems that at least some text in previous versions of the
design draft assumed that the address listed first in
List_A/List_B is the "primary" or "preferred" address that will
get used. We get this alternative by defining a very simple
f_A() and f_B() for option 1.
Host A Host B
------ -------
List_A = (decided by A) -->
<-- List_B = (decided by B)
src,dst = List_A[1],List_B[1] src,dst = List_B[1],List_A[1]
Pros and cons:
+ Simple
+ Really simple for hosts that have a single static IP address
+ Symmetric behavior may make sense when the situation is
otherwise reasonably symmetric (such as site-to-site VPNs)
+ Same address pair used in both direction
- Connectivity information can be taken into account only
when determining List_A/List_B: traffic can be on a path
that both ends know to be unworkable
- For instance, if both A and B have one IPv4 address and one
IPv6 address (and there's no v4/v6 translation), it's not clear
how traffic would be moved from one to the another. It seems that
the order of List_B has to depend on order of List_A which depends
on the order of List_B and so on: unless the protocol specifies
some tie-breaking mechanism (limits how the parties can choose
the order of List_A/List_B), we could even get a ping-pong effect.
-----
Option 3: "Initiator decides"
This is the approach chosen in MOPO-IKE.
Host A Host B
------ -------
List_A = (decided by A) -->
<-- List_B = (decided by B)
src,dst = f_A(List_A, List_B,
local preferences,
local info about
connectivity,
whatever) -->
src,dst = received from A
(BTW, in this approach Host B does not use List_A for updating
IPsec SAs at all; it's only used when List_B changes.)
Pros and cons:
+ Simple to handle partial connectivity and IPv4/v6 cases, without
the danger of ping-pong or other unspecified aspects
+ Very simple for B (VPN gateway in "mobile client" case)
+ In mobile client case, the client probably has a better
information about which addresses should be used.
+ Same address pair used in both directions
+ Easier to work with NATs and stateful firewalls
- Asymmetric behavior, less elegant perhaps
- A's preferences win even in symmetric situations (site-to-site)
-----
Option 4: "Use the preferred/primary address if possible"
We can clearly refine the approach of option 2 by including
slightly more complicated f_A() and f_B(). For instance,
Host A Host B
------ -------
List_A = (decided by A) -->
<-- List_B = (decided by B)
src,dst = src,dst=
if (List_A[1],List_B[1] works) if(List_B[1],List_A[1] works)
List_A[1],List_B[1] List_B[1],List_A[1]
else else
f_A2(List_A, List_B, f_B2(List_B, List_A,
local preferences, local preferences,
local info about local info about
connectivity, connectivity,
whatever) whatever)
Pros and cons:
+ Often uses the same address pair in both directions
- Almost as complex as option 1
- List_B still depends on List_A and vice versa in some
unspecified way, just like option 2
-----
There are of course many other variations of option 1 that place
more or less restrictions of what f_A/f_B do and/or place
restrictions on how List_A/List_B are chosen.
But it seems that all the options involve some trade-offs and
none of them is clearly superior in all circumstances. But
according to my understand, options 2 and 4 have important
missing pieces (how A and B choose the order of List_A/List_B
based on the other) that are needed before their merits can be
fully assessed. On the other hand, options 1 and 3 both seem to
be working alternatives, since in them the hosts don't have to
agree on f_A/f_B or choosing the order of List_A/List_B.
(BTW, most of the differences between the approaches occur only
when both parties have several addresses: otherwise, they're
pretty similar.)
These were just some initial thoughts, and comments are very
welcome (as are variants of options 2 and 4 that fill in the
missing pieces, and other variants).
Best regards,
Pasi
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.