-------------------- Tero Kivinen (2005-10-28): https://www.machshav.com/pipermail/mobike/2005-October/001242.html The current document is missing text what happens if the return routability check fails. Should we add some text about that? If there it is genuine attack then we of course want to tear down the IKE SA (i.e. we do not get any reply back for the RR at all). The problem is that this might cause IKE SA to teared down even when there is no attack in case the selected link goes down before the RR but after the update. I.e the case is like this: Initiator Responder --------- --------- Currently using IP_I1 and IP_R1 for traffic Send address update (IP_I2:500 -> IP_R1:500) HDR, SK { N(UPDATE_SA_ADDRESSES) } --> Responder processes the request and send ACK. <-- (IP_R1:500 -> IP_I2:500) HDR, SK { } Initiator updates the IPsec SAs to IP_I2, IP_R1. Link between IP_I2 and IP_R1 breaks down. Responder starts DPD lost <-- (IP_R1:500 -> IP_I2:500) HDR, SK { N(COOKIE2) } lost <-- (IP_R1:500 -> IP_I2:500) HDR, SK { N(COOKIE2) } lost <-- (IP_R1:500 -> IP_I2:500) HDR, SK { N(COOKIE2) } The inititor will not see those return routability packets. The IPsec traffic is still going through from responder to initiator, as it uses old IP_R1 and IP_I1 addresses (they are not yet updated as the RR has not finished yet). <-- (IP_R1 -> IP_I1) ESP packet Data from initiator to the responder does not go through as he is using new IP addresses (IP_I2 -> IP_R1) ESP packet --> lost <-- (IP_R1 -> IP_I1) ESP packet Initiator will still see packets coming from the responder but to the old address. Now the Initiator needs to understand that even if he is getting packets in, he should start DPD in case those packets are coming from the different address than where they should be coming. This is not mentioned in the document now. If initiator does that, this will fix the situation. Responder is still doing RR. lost <-- (IP_R1:500 -> IP_I2:500) HDR, SK { N(COOKIE2) } Initiator notices that is not getting any trafic to the address pair where he is sending traffic, and decides to start DPD. (IP_I2:500 -> IP_R1:500) HDR, SK { } --> lost (IP_I2:500 -> IP_R1:500) HDR, SK { } --> lost (IP_I2:500 -> IP_R1:500) HDR, SK { } --> lost Initiator notices it is not getting data back, thus tries other addresses (IP_I1:500 -> IP_R1:500) HDR, SK { } --> Responder will get get that and reply to it. <-- (IP_R1:500 -> IP_I1:500) HDR, SK { } Initiator detects that IP_I2, IP_R1 address pair is not working and switches to the working IP_I1, IP_R1 address pair. (IP_I1:500 -> IP_R1:500) HDR, SK { N(UPDATE_SA_ADDRESSES) } --> Responder processes the request and send ACK. <-- (IP_R1:500 -> IP_I2:500) HDR, SK { } Responder retransmits the old ongoing RR to the new updated address. <-- (IP_R1:500 -> IP_I1:500) HDR, SK { N(COOKIE2) } Initiator respondeds to RR. (IP_I1:500 -> IP_R1:500) HDR, SK { N(COOKIE2) } --> Responder gets ack to RR, but notices that address has changed since it was started, so he need to restart the RR <-- (IP_R1:500 -> IP_I1:500) HDR, SK { N(COOKIE2') } Initiator respondeds to new RR. (IP_I1:500 -> IP_R1:500) HDR, SK { N(COOKIE2') } --> Responder is now happy, and will update the IPsec SAs to the IP_R1, IP_I2 address pair (or actually they are already there, as it never got them changed, but they might have moved to some new address). So we probably want to say something about this, as it do require the initiator to understand that even when it is getting ESP packets in it might need to start DPD in case the IP addresses of the ESP packets are different from what he thinks they should be. -------------------- Jari Arkko (2005-10-28): https://www.machshav.com/pipermail/mobike/2005-October/001243.html Isn't that already stated somewhere? Seems like its a part of the NAT behaviour... Anyway, I believe we do need to say something about the case that you mentioned. It is indeed possible that an update fails in any of its stages, including RR. What I would suggest is that if you don't complete the update then you continue operating as if it didn't happen, and be prepared to accept/initiate another address update. -------------------- Tero Kivinen (2005-10-31): https://www.machshav.com/pipermail/mobike/2005-October/001245.html At least it is not mentioned in the NAT-T drafts and I do not think it is mentioned in the IKEv2 draft either. Protocol draft says: ---------------------------------------------------------------------- IKEv2 performs Dead Peer Detection (DPD) if there has recently been only outgoing traffic on all of the SAs associated with the IKE_SA. ---------------------------------------------------------------------- and that is under NAT-T. IKEv2 draft says: ---------------------------------------------------------------------- ... If there has only been outgoing traffic on all of the SAs associated with an IKE_SA, it is essential to confirm liveness of the other endpoint to avoid black holes. If no cryptographically protected messages have been received on an IKE_SA or any of its CHILD_SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. Receipt of a fresh cryptographically protected message on an IKE_SA or any of its CHILD_SAs assures liveness of the IKE_SA and all of its CHILD_SAs. Note that this places requirements on the failure modes of an IKE endpoint. An implementation MUST NOT continue sending on any SA if some failure prevents it from receiving on all of the associated SAs. If CHILD_SAs can fail independently from one another without the associated IKE_SA being able to send a delete message, then they MUST be negotiated by separate IKE_SAs. ---------------------------------------------------------------------- So that does not say anything about the IP-addresses. I think we need some paragraph about that to the mobike draft. > Anyway, I believe we do need to say something about > the case that you mentioned. It is indeed possible that > an update fails in any of its stages, including RR. What > I would suggest is that if you don't complete the update > then you continue operating as if it didn't happen, and > be prepared to accept/initiate another address update. The problem in the failing in the RR step is that it is negotiatiation initiated by the responder, thus it cannot fall back to other addresses. It is also normal IKEv2 message, which means it must get reply back or otherwise the whole IKE SA is deleted. So we cannot fail that RR, we must finish it, and we can only finish it with the help of initiator noticing that the path does not work, and falling back to some other path. -------------------- Pasi Eronen (2005-11-14): https://www.machshav.com/pipermail/mobike/2005-November/001299.html Discussing this face-to-face clarified the situation: I guess all we need is a way for the initiator to discover the situation. Your proposal about considering the IP address when deciding whether to start DPD sounds like the way to go. Could you figure out what needs to be added and/or changed in the draft to make this work? -------------------- Tero Kivinen (2005-11-14): https://www.machshav.com/pipermail/mobike/2005-November/001301.html Hmm... I think we need new section probably after "Failure Recover and Timeouts" explaining DPD behavior: X.X Dead Peer Detection MOBIKE protocol uses same DPD method than normal IKEv2, but as the IP addresses might change in the MOBIKE also they should be taken account when determing whether the other peer is alive and in sync with address updates. This means that, if there is incoming traffic, but that does not use current address pair, that should not be considered to proof that the other end is alive. -------------------- Jari Arkko (2005-11-15): https://www.machshav.com/pipermail/mobike/2005-November/001310.html OK. Somewhat edited version below: "MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but as addresses may change, it is not sufficient to just verify that the peer is alive, but also that it is synchronized with the address updates and has not, for instance, ignored an address update due to failure to complete return routability test. This means that when there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the addresses used in those packets and determine that they correspond to those that should be employed. If they do not, such packets SHOULD NOT be used as evidence that the peer is able to communicate with this node and or that the peer has received all address updates." -------------------- Pasi Eronen (2005-11-16): https://www.machshav.com/pipermail/mobike/2005-November/001312.html Looks OK to me. -------------------- Tero Kivinen (2005-11-16): https://www.machshav.com/pipermail/mobike/2005-November/001315.html Looks good. --------------------