-------------------- Lauri Tarkkala (2004-02-29): IKEv2 is a lock-step protocol by default (when window size is 1). This means that if a retransmission is in progress (with possibly exponential backoff), no new exchanges can be started. This includes exchanges aimed at doing dead-peer-detection. So this problem needs to be resolved. [...] Currently a big hurdle in IKEv2 for the functionality to become "really neat and robust" is the default retransmission behaviour, as suggested in both protocol drafts. If the preferred route goes down during an IKE exchange (e.g. address update), the system will be stuck in the retransmit mode (5 s? 10 s? 15s? 30s? 60s? *shiver*) before it can start doing DPD over all the links. Now assuming that there exist n > 2 routes that the MOBIKE instance wants to probe, and that (n-1) of these preferred ones are broken. Then we end up with a scenario where n retranmissions must fail before the IKE exchange is completed. This is quite suboptimal what could be achieved. Since IKEv2 provides an ordering of IKEv2 messages, and the endpoints are identified independently of the srcip and dstip, it is not unconceivable (to me anyway) to send e.g. dead peer detection messages and address updates simultaneously over several routes simultaneously. This is currently allowed implicitly, but leaving it that way may cause problems. One reason is that the amount of routes grows quite rapidly in terms of endpoint addresses. Another is that the redundant messages may not be of much use if only one endpoint uses them. The question therefore is should MOBIKE negotiate how many non-retransmit redundant messages are desired per message send? -------------------- Jari Arkko (2004-02-29) I think both Francis' and Tero's drafts said something about the window size, but only in relation to verifying order of address updates. I agree that the DPD issue is also relevant. Does this mean that window size > 1 MUST be supported for MOBIKE? -------------------- Tero Kivinen (2004-02-29): No, it means that we must use similar try other IP-addresses for all IKEv2 exchanges, i.e. when doing for example CREATE_CHILD_SA exchange, and you do not receive reply from the other end when using IP1, you should try IP2 and if that fails IP3 etc. The result of this should be processed identically to the dead-peer-detection, i.e. move the traffic to the first IP-address that works. Lauri also suggested that in that case we could sent the retransmission packets to all possible IP-addresses at once, i.e. if IP1 doesn't answer, send next retranmissions to all IP1..IPn simultaneously. > Hmm... maybe. What do others think? By the way, what if > you sent multiple parallel _address updates_ in this case? There is some problems sending packet simultaneously, as if the all the links were broken, and then they came up again, the responder will get random packet which it will process first, and the other end will move to that IP-address, and it might not be the one the other end wanted to be used (i.e. it might accidently move traffic to the costly gprs link, even when the wlan is also working, because there was network problem in London. Of course the other end can fix this by sending address update, in which case the responde should retry the most preferred address. > I don't know. But the less negotiation and configurable > parameters we have, the better ;-) so is there another > way? We can also have fixed limit, i.e. say that you can try only 3 addresses at time. -------------------- Lauri Tarkkala (2004-02-29): This is solved by requiring that address updates be ordered, and the most recent one is the valid one, e.g. "late" address updates are dropped. This I think is already mentioned in the drafts. Or did I misunderstand something? [other message] I stated that if a retransmission over a certain route is in progress and the window size is 1, then no new exchanges can be started. Note also that some of the protocol drafts mentioned an explicit DPD exchange to be performed after a failure was detected. -------------------- Francis Dupont (2004-03-01): I am happy with the idea to send critical messages (address updates can enter in this category) via all paths, or all known to be very different paths (look at OMIPv6 or BUB for an application of this). [other message] IMHO this is a global IKEv2 issue as a DPD request can block a new urgent and critical exchange... Can you send something in the IPsec mailing list asking for a window >= 2 for the receiver part of DPD? -------------------- IETF59 MOBIKE WG minutes: Lauri Tarkkala: DPD again, we need special MOBIKE handling for all IKEv2 exchanges, not just DPD exchanges, because any exchange in IKEv2 can be DPD exchange --------------------