-------------------- Mohan Parthasarathy (2005-10-03): A few comments/questions... If the IPsec SAs were updated in the previous step: If NAT Traversal is not enabled, and the responder supports NAT Traversal (as indicated by NAT detection payloads in the IKE_SA_INIT exchange), and the initiator either suspects or knows that a NAT is likely to be present, enables NAT Traversal. I did not understand this step at all. If the IPsec SAs were updated, then the RR check won't be done. What is that got to do with NAT traversal ? If there are outstanding IKEv2 requests (requests for which the initiator has not yet received a reply), continues retransmitting them using the addresses in the IKE_SA (the new addresses). This does not have a corresponding section in what the responder. Though, trivial would make sense to include them. - Section 4.7 If the initiator is behind NAT, and if he suspects that the peer is *dead*, he can send a DPD message with UPDATE_SA_ADDRESSES to recover faster. This was discussed in the mailing list sometime back. But i don't see this suggestion. Why do we have to know that the NAT mapping has changed explicitly ? If the path still does not work with UPDATE_SA_ADDRESSES, then probably the path has failed. - Section 4.9 Can we show the DPD exchange here with possible payloads ? -------------------- Jari Arkko (2005-10-03): Good question. I don't they have much to do with each other. It seems that the actions in this step should be done in any case. Also, "enables NAT traversal" is a bit vague. Presumably we are sending payloads and making specific actions on the results of seeing payloads come back. Yes. Tero, Pasi, can you say something about this? We have an example in Section 3.2. Would that be sufficient, or do you want more? -------------------- Pasi Eronen (2005-10-04): https://www.machshav.com/pipermail/mobike/2005-October/001099.html The reasoning is that updating the addresses in IPsec SAs and enabling/disabling NAT Traversal go together: if you don't do RR check, you do both immediately; but if you wait for the RR check to finish, you also don't toggle NAT-T before you've updated the addresses in the SA. "Enabling NAT traversal" here means starting UDP encapsulating outgoing ESP packets and sending NAT-Keepalive packets (i.e., it doesn't involve sending any IKEv2 payloads, other than those already explicitly specified in that section). How about adding "(i.e., enables UDP encapsulation of outgoing ESP packets and sending of NAT-Keepalive packets)" there? The responder processes the requests as usual: if the request was CREATE_CHILD_SA, creates the new SA or something, etc. Note that the responder's part start with this text: When processing an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification, the responder: so I'm not sure what should be added here? Knowing that the NAT mapping has changed might be useful, since it allows you to adjust the keepalive interval. But the initiator could also send the UPDATE_SA_ADDRESSES immediately. How about adding "The initiator MAY also omit the separate exchange to detect the change in NAT mappings, and instead send UPDATE_SA_ADDRESSES immediately when doing dead peer detection." to 3rd paragraph of Section 4.7? There is no "DPD exchange" in IKEv2; any INFORMATIONAL exchange confirms the peer is alive (and thus it can include whatever payloads any other INFORMATIONAL exchange includes). -------------------- Mohan Parthasarathy (2005-10-05): https://www.machshav.com/pipermail/mobike/2005-October/001101.html > > The reasoning is that updating the addresses in IPsec SAs and > > enabling/disabling NAT Traversal go together: if you don't do RR > > check, you do both immediately; but if you wait for the RR check to > > finish, you also don't toggle NAT-T before you've updated the > > addresses in the SA. Ah! that makes sense. > > "Enabling NAT traversal" here means starting UDP encapsulating > > outgoing ESP packets and sending NAT-Keepalive packets (i.e., > > it doesn't involve sending any IKEv2 payloads, other than those > > already explicitly specified in that section). > > > > How about adding "(i.e., enables UDP encapsulation of outgoing ESP > > packets and sending of NAT-Keepalive packets)" there? Perhaps, instead of adding, just replace "enabling NAT traversal" with explicit text like what you suggest above. At the end of the same section, there is similar text "enable/disable NAT traversal". Perhaps, that also should say the same thing. > > > > If there are outstanding IKEv2 requests (requests for > > > > which the initiator has not yet received a reply), > > > > continues retransmitting them using the addresses in > > > > the IKE_SA (the new addresses). > > > > > > > > This does not have a corresponding section in what the > > > > responder. Though, trivial would make sense to include > > > > them. > > > > > > Yes. > > > > The responder processes the requests as usual: if the request > > was CREATE_CHILD_SA, creates the new SA or something, etc. > > Note that the responder's part start with this text: > > > > When processing an INFORMATIONAL request containing the > > UPDATE_SA_ADDRESSES notification, the responder: > > > > so I'm not sure what should be added here? But this does not cover the above case. When the window is closed, you are retransmitting requests/responses that does not contain the UPDATE_SA_ADDRESSES. So, it has to be included somewhere to say that "when the responder sees packets coming in with new addresses, it should not update the SA if MOBIKE is enabled". According to the IKEv2 base spec, the IKE SA will be updated if a NAT was detected earlier. > > Knowing that the NAT mapping has changed might be useful, since > > it allows you to adjust the keepalive interval. But the initiator > > could also send the UPDATE_SA_ADDRESSES immediately. > > > > How about adding "The initiator MAY also omit the separate > > exchange to detect the change in NAT mappings, and instead send > > UPDATE_SA_ADDRESSES immediately when doing dead peer detection." > > to 3rd paragraph of Section 4.7? But we still have a problem with the current approach right ? How are we going to fix that ? My experience with NAT keepalives has lead to a very conservative approach :-) If it is 45 seconds, your timer should be around 40 seconds or less to be completely sure that it works always. > > There is no "DPD exchange" in IKEv2; any INFORMATIONAL exchange > > confirms the peer is alive (and thus it can include whatever > > payloads any other INFORMATIONAL exchange includes). But i saw some exchange earlier in the draft. My only intent is to show the possible payloads that can be sent along with this from the MOBIKE perspective. --------------------