Re: Thoughts about issues 10/19: changing address vs. paths, and so on...

Pasi,

A few questions/comments below..

> 
> 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)
>
By symmetric behavior, you mean both side selecing addresses
as opposed to one side selecting the address.
By"reasonably symmetric", you mean path between A and B
is symmetric. So, symmetric behavior may not be desired always
if there is no symmetry in the path.

> + 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).
>   
Also in the case of firewall/NAT you may want the same address
pair.

> -----
> 
> 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]
> 
So, what happens after the failure ?

> 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.
> 
I don't understand this alternative at all. Could you please eloborate a little
bit more ?

> -----
> 
> 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

It is possible that the path selected by the initiator does not work
for the responder. 
> - 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.
> 
I agree that the only meaningful options here are between (1) and (3).
I don't know whether it is possible to choose between either of these
options (Though (3) looks good, it still has a problem in choosing a
potentially unusable path for the responder). One possibility is to
 include the ability of negotiation. For example,

1) Each of the nodes send their lists.
2) The initiator can propose to be the decision maker in choosing the
    new path. If the other end does not agree to it, both ends choose
    their own paths.

Potentially, the responder can also choose to be the decision maker.
Don't know whether it makes sense given the scenarios in the document.
Any reason, why this option is not considered here ?

-mohan

> (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
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike