-------------------- WG charter: In particular, the WG shall NOT develop mechanisms for the following functions: [....] o IP address changes done by third parties (NATs, firewalls etc). In particular, MOBIKE shall not replace or modify IKEv2 NAT traversal function. MOBIKE handles IP address changes initiated by one of the endpoints of the security associations. NAT traversal handles other address changes. MOBIKE should not be tightly coupled with the NAT traversal function, but it is necessary to specify in which cases (if any) they can be used together, and how they interact. -------------------- IETF59 MOBIKE WG minutes: Tero Kivinen: NAT traversal is beyond charter. Pasi Eronen: Charter does not allowing changes to NAT-T, but it does not say that we should not support NAT-T. I want to have both. Paul Hoffman: Good point, we should take NATs in to account. Tero: If starting behind NAT with NAT-T enabled then moving out and back from NAT works with IKEv2 NAT-T. Currently moving from not-behind a NAT to behind a NAT is not supported with only MOBIKE. This would require switching from MOBIKE to NAT-Traversal. But no way to separate NAT modifying a packet or attacker modifying a packet. Henrik Levkowetz: If we don't work with NATs, this won't be very useful. [...] Pasi: One thing mentioned earlier, but lost somewhere. IKEv2 works with NAT-Ts because IP addresses are not sent inside the UDP payload. MOBIKE will break this and we will have problems. Is the intent that MOBIKE and NAT-T are exclusive ? Jari Arkko: Yes Pasi: Does the WG feel this way? Tero: Not sure whether MOBIKE and NAT can be well integrated. Hannes Tschofenig: There are scenarios where you need this, we might want to think about it. Paul: We will. James Kempf: If this is too difficult to do this on the first round. It is acceptable to delay it. Francis Dupont: The scenarios for NAT-T/MOBIKE cases must be documented. Henrik: The usefulness will be severely lower if NAT-T/MOBIKE is not supported. If you want to get this deployed, you need that. -------------------- (issue list editor note: see mailing list archive for more discussions between IETF59 and May 2005) -------------------- Jari Arkko (2005-05-13): Some personal thoughts on solutions for this issue: We have consensus that MOBIKE and NAT-T need to work together. It seems like the core of the remaining issue is "what exactly does this mean" and "what can we achieve, given protocol and other limitations". One way to approch these questions is to try to break down the problem in smaller pieces. For instance, I believe the following questions have been asked at one point or another during the discussion: Scenarios that we can support (a) Can we move behind a NAT? (b) Can we move out from a NAT? (c) To which extent do we support the case that party outside the NAT moves? (d) If we are behind a NAT, can peer have multiple addresses? (e) If we are behind a NAT on one interface, can another interface work without NAT/NAT-T? (f) Can the responder be behind a NAT? New functionality (g) Do we need NAT prevention? (h) Do we want to disable UDP encapsulation when moving outside from behind a NAT? Implementation (i) Send keepalives on current or on all paths? (j) How do we detect NATs? Conformance requirements (k) Is NAT-T support still optional within MOBIKE? Does this cover everything, or do we have additional questions? Here are also some tentative answers to the questions: (a) Can we move behind a NAT? [Yes. But requires NAT-D payloads in the address change message, as discussed under issue 11.] (b) Can we move out from a NAT? [Yes. Does not require much. But see item h.] (c) To which extent do we support the case that party outside the NAT moves? [No. This one is really hard. We will make our life much simpler by saying no here. Outsider may not be able to initiate anything inside. The only exception is covered under item f.] (d) If we are behind a NAT, can peer have multiple addresses? [Yes. Contrary to mobility, multihoming is possible quite easily. Detailed protocol design has some further details that need to be developed later, e.g., is there a need to do keepalives on all address pairs? Tentatively, the answer to that is no.] (e) If we are behind a NAT on one interface, can another interface work without NAT/NAT-T? [Yes.] (f) Can the responder be behind a NAT? [Yes, but in a very limited scenario, when the NAT is a static NAT and not a NAPT.] (g) Do we need NAT prevention? [Yes.] (h) Do we want to disable UDP encapsulation when moving outside from behind a NAT? [Yes.] (i) Send keepalives on current or on all paths? [To be decided later.] (j) How do we detect NATs? [Using NAT-T functionality.] (k) Is NAT-T support still optional within MOBIKE? [Yes. You should be able to use MOBIKE in plain v6 environments, for instance.] -------------------- Tero Kivinen (2005-05-13): ... > (h) Do we want to disable UDP encapsulation when moving outside > from behind a NAT? > [Yes.] I agree on your suggestion for answers for those questions above. > (i) Send keepalives on current or on all paths? > [To be decided later.] Yes, that depends quite a lot about protocol, but if it ends up to be initiator decide style protocol, then the answer will most likely be no. If it is going to be so that both ends can decide which pair of addresses to use, then we must also send keepalives on all paths. So this is related to issue 20. > (j) How do we detect NATs? > [Using NAT-T functionality.] > (k) Is NAT-T support still optional within MOBIKE? > [Yes. You should be able to use MOBIKE in plain v6 environments, > for instance.] Agree on those again. -------------------- Mohan Parthasarathy (2005-05-15): Agreed. -------------------- Pasi Eronen (2005-05-16): I agree with your proposals. As some people have expressed that they have no interest in NAT-T, I think it's important to also have (k): if you implement NAT-T, MOBIKE works with that, but implementing MOBIKE does not force you to do NAT-T if you don't want. -------------------- Jari Arkko (2005-05-29): I believe we have now converged on this issue as well. Tero posted a comment on the keepalive part, which changed the original proposal a bit, however. Note that this is still at a fairly high level. It seems likely that we will hit more detailed issues in actual protocol work. But it may be hard to do further discussion of this part of the issue unless we have a concrete proposal and see those detailed issues in front of us. So my suggestion is that we move on and deal with those issues separately if and when they arise. Resolution: (a) Can we move behind a NAT? [Yes. But requires NAT-D payloads in the address change message, as discussed under issue 11.] (b) Can we move out from a NAT? [Yes. But see item h.] (c) To which extent do we support the case that party outside the NAT moves? [No. Outsider may not be able to initiate anything inside. The only exception is covered under item f.] (d) If we are behind a NAT, can peer have multiple addresses? [Yes.] (e) If we are behind a NAT on one interface, can another interface work without NAT/NAT-T? [Yes.] (f) Can the responder be behind a NAT? [Yes, but in a very limited scenario, when the NAT is a static NAT and not a NAPT.] (g) Do we need NAT prevention? [Yes.] (h) Do we want to disable UDP encapsulation when moving outside from behind a NAT? [Yes.] (i) Send keepalives on current or on all paths? [Just the current one, as the "initiator decides" solution that we have picked in issue 20 makes this the logical choice here.] (j) How do we detect NATs? [Using NAT-T functionality.] (k) Is NAT-T support still optional within MOBIKE? [Yes. You should be able to use MOBIKE in plain v6 environments, for instance.] -------------------- Francis Dupont (2005-06-08): Resolution: (a) Can we move behind a NAT? [Yes. But requires NAT-D payloads in the address change message, as discussed under issue 11.] => NAT-D or NAT-P (both detect NATs), see item j. (b) Can we move out from a NAT? [Yes. But see item h.] (c) To which extent do we support the case that party outside the NAT moves? [No. Outsider may not be able to initiate anything inside. The only exception is covered under item f.] (d) If we are behind a NAT, can peer have multiple addresses? [Yes.] => what is the real meaning of the question (NAT-T one side, MOBIKE the other side?) (e) If we are behind a NAT on one interface, can another interface work without NAT/NAT-T? [Yes.] => I disagree if this gives extra complexity. (f) Can the responder be behind a NAT? [Yes, but in a very limited scenario, when the NAT is a static NAT and not a NAPT.] => I don't see the interest to support this very limited scenario. (g) Do we need NAT prevention? [Yes.] (h) Do we want to disable UDP encapsulation when moving outside from behind a NAT? [Yes.] (i) Send keepalives on current or on all paths? [Just the current one, as the "initiator decides" solution that we have picked in issue 20 makes this the logical choice here.] (j) How do we detect NATs? [Using NAT-T functionality.] => NAT-D or NAT-P (k) Is NAT-T support still optional within MOBIKE? [Yes. You should be able to use MOBIKE in plain v6 environments, for instance.] => the IPv6 case is very important because of the use of IPsec by MIPv6 (a MIPv6 Home Agent and a MOBIKE Security Gateway is nearly the same thing) and of the style of multihoming used for IPv6. --------------------