-------------------- Pasi Eronen (2005-03-03): 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 -------------------- Jari Arkko (2005-03-04): Thinking some more about this, I would actually like to go for approach #3. This would simplify our protocol, and would ensure an arhitecture where NAT and firewall traversal can happen easily. If make this decision, it seems that the following other open issues would also be solved: 1 (direct or indirect indicators): Because one side is responsible for the whole thing, we would have to support failure detection using DPD at the initiator side. Note that responder may still need to update its own list of addresses now and then, say if an interface goes down. unassigned issue # (the list complaint that large SGWs should not be forced to check the connectivity to clients): The client would be doing all the work. -------------------- (issue list editor note: see also IETF62 minutes and slides) -------------------- Pasi Eronen (2005-03-07): During the meeting today, Francis pointed out another possibly option not really covered by 1-4. Option 5: "Peers decide the source addresses independently" Host A Host B ------ ------- List_A = (decided by A) --> <-- List_B = (decided by B) dst = List_B[1] dst = List_A[1] src = f_A(List_A, List_B, src = f_B(List_B, List_A, local preferences, local preferences, local info about local info about connectivity, connectivity, whatever) whatever) Pros and cons: + Reasonably simple - No guarantee A-to-B and B-to-A traffic choose the same traffic pair (which complicates things with stateful packet filters) - Host A can't move the "upstream" traffic to some other interface without co-operation from B (if we have partial connectivity). For instance, if Host A has one IPv4 interface and one IPv6 interface, A can't move the traffic to the IPv6 interface unless it somehow convinces B to reorder List_B: how does this happen? (And if the answer is that List_B depends on List_A which depends on List B, how does this work?) - The same thing also applies to failures in the middle: even if both parties' addresses and preferences stay the same, somehow they must reorder either List_A, List_B, or both. (Hmm, I think that any option that is fully symmetric will have these problems.. but there are certainly options that are less asymmetric than option 3.) -------------------- Francis Dupont (2005-03-07): note that f_A is the application of RFC 3484 so it is usually predictable and always deterministic. Aniother point is this makes IKE behavior "standard" in the common case. -------------------- Jari Arkko (2005-05-18): Folks, At IETF-62 and on the list we discussed this issue that relates to what (outer) addresses are selected for the IPsec SAs, and who decides these addresses, the initiator, both peers, etc. This is a central question for the design of the mobike protocol, as it is hard to design further details without knowing the what we decide here. For this reason I'd like us to do a straw poll on what alternative people feel most comfortable with. The alternatives are discussed in http://www.vpnc.org/ietf-mobike/issue20.txt in more detail, but essentially its a question of the following choice: Option 1: "MOBIKE just informs the peer of our addresses; how they get used is a matter of local policy beyond our scope." Option 2: "Use the preferred/primary address" Option 3: "Initiator decides" Option 4: "Use the preferred/primary address if possible" Option 5: "Peers decide the source addresses independently" (There are potential other variants of design but these seem to be the main ones, or at least the current concrete proposals for the MOBIKE protocol are covered above.) Please make your opinion, along with its justifications, known by May 25th. -------------------- James Kempf (2005-05-18): I prefer option 3. -------------------- Pasi Eronen (2005-05-19): Option 3, "Initiator decides". Reasons: - Simple. Very simple in the mobile client connected to stationary gateway case. - Makes it easy to get the same address pair for both directions. This is important for two different reasons. First, it simplifies things if the network contains stateful firewalls or NATs. Second, it's straightforward to implement typical mobility cases, e.g. laptop can move both upstream and downstream traffic from GPRS to WLAN or vice versa, even if both interfaces work. - It does not prevent us from doing the non-mobile multihoming cases either, e.g. gateway-to-gateway. -------------------- Tero Kivinen (2005-05-19): > Option 3: "Initiator decides" As we need to support NATs and supporting NAT quite often means that either the design goes complicated or the host behind NAT (initiator) decides which addresses to use. So I vote for the this option. -------------------- Mohan Parthasarathy (2005-05-20): > Option 3: "Initiator decides" > I am assuming that this means that the initiator tests for bidirectional reachability and then tells the peer about the working address. One main reason why this seems favorable is because it works well with NATs and Firewalls. It does not mean that it does not work when they are not there. But may not work ideally e.g. two SGs connected and only one of them can decide. So, why build a protocol with this limitation ? Does providing an option for either one of them to choose or both of them to choose complicate the protocol (perhaps there could be the ping-pong effect of each one changing back and forth if both of them can choose) ? For example, the initiator says that it wants to be the deciding factor. The responder knows that the initiator is not behind a NAT (by looking at NAT-D payloads), then it might be okay for the responder to choose also, right ? So, the responder can also choose to be the deciding factor in this case. Though i *like* this option, it might make sense to provide some flexibility for this option. -------------------- Jari Arkko (2005-05-20): I'm not sure if this is what you were looking for, but the peers do have some ability to select who decides, simply by choosing who is the initiator... and if you don't like the initial arrangement, you could presumably take the current connection down and re-initiate yourself. -------------------- Geoffrey Huang (2005-05-24): I prefer option 3 for its simplicity. Also, it seems to me that the mobile client-to-gateway scenario is such a compelling use case for Mobike, it makes it natural for the initiator to decide. -------------------- Bill Sommerfeld (2005-05-26): > > Option 3: "Initiator decides" This seems to be the best choice to me. Though I think we haven't yet precisely nailed down what we mean by "initiator". -------------------- Jari Arkko (2005-05-26): >Though I think we haven't yet precisely nailed down what we mean by >"initiator". > > My understanding was that we are talking about the original initiator of the IKEv2 connection, not the initiator of a particular exchange later on. But I could be mistaken. -------------------- Pasi Eronen (2005-05-26): Yes, what was meant is the party who initiated the IKEv2 connection (and not e.g. exchange initiator). And we have to write the definition so that this party stays the same even after rekeying the IKE_SA. (Unlike the "original initiator" in IKEv2, which is not defined anywhere in the document -- Paul's current proposal on the ipsec list is that rekeying the IKE_SA can change who is the "original initiator"). -------------------- Bill Sommerfeld (2005-05-27): so, the way I see it is that choosing the "one side in control" model is the central part of resolving issue 20. after we have implementation experience we may discover that certain uses for mobike (sg-sg or other peer-to-peer uses) may require a different way to pick which end is in control and we can add that later... but only if absolutely necessary. -------------------- Paul Hoffman (2005-05-27): It's pretty clear that there is consensus on Option 3: "Initiator decides". -------------------- Francis Dupont (2005-06-08): => I am already known to be in favor of option 5 with f_A() from RFC 3484. ... PS: I'll answer to other messages but my principles are: - the destination address has to be decided by the peer, this is critical. - the source address selection is not critical (or should not be :-), RFC 3484 proposes a reasonnable and standardized way to select the proper source address according to the destination address. Perhaps I am a bit IPv6 centric but I can't see a good reason to do something special for IPsec. -------------------- Francis Dupont (2005-06-08): James Kempf> I prefer option 3. => I explain why I disagree: option 3 is too dedicated to the mobile client to VPN gateway case, i.e., when A and B are multihomed the only way for the looser (i.e., B) to enforce the choice of its address is to cheat by announcing a List_B reduced to one address... -------------------- Francis Dupont (2005-06-08): Mohan Parthasarathy> Though i *like* this option, it might make > sense to provide some flexibility for this option. => you seem a candidate for option 5 (don't forget that RFC 3484 is a predictable algorithm and List_B is likely to be known before sending the first packet, and BTW how the addresses of this first packet are chosen?). ... PS: in my address set management framework, List_B is initialized by the first packet destination address. In the common case the result will be the same than option 3 but B has the capability to change its address. -------------------- Francis Dupont (2005-06-08): How do you folks feel about this? Please post your comments by Friday, June 3rd. => note I consider that I am not bound by your short delays... It seems we lost the basic idea: the only critical thing is the destination address the peer uses to send packets to us, and we really need to control it, this is why the option 3 for issue 20 is *not* the right one. About issue 19, I believe: - an SA pair MUST be created with the same address pair (just to avoid to provide a way to do something else) - an SA pair SHOULD use the same address pair (this doesn't close the door and avoid a spurious requirement). Regards Francis.Dupont@enst-bretagne.fr PS: to come back to issue 20, it doesn't exist in my address set management framework because it uses the option 2 (use primary address) initialized by the addresses IKE runs over (i.e., without crazy filtering on the path the address pair is proved to work by IKE itself :-). BTW I don't provide a way to use different address pair per way, only per SA pair (which IMHO is enough to support SCTP[-like] contexts). --------------------