-------------------- Tero Kivinen (2005-07-12): > 1.2 MOBIKE protocol overview ... > One important aspect of this information gathering that has to be > visible in the messages is determining whether a certain pair of > addresses can be used. IKEv2 Dead Peer Detection (DPD) feature can > provide information that the currently used pair does or does not > work. There are, however, some complications in using it for other > addresses, and thus MOBIKE adds a new IKEv2 message that can be used > to "test" whether some particular pair of addresses works or not, > without yet committing to changing the addresses currently in use. I do not agree on that reason. It is very simple to say in the MOBIKE protocol, that implementations MUST NOT do dynamical address update if MOBIKE extensions are enabled, i.e. they MUST always do address updates only when receiving CHANGE_PATH message in case MOBIKE extensions are enabled. That will take care of all the problems using normal IKEv2 packet to test path. > 2.3 Changing path of IPsec SAs > > In MOBIKE, the initiator of the IKE_SA decides what addresses are > used in the IPsec SAs. That is, the responder never updates any > IPsec SAs without receiving an explicit CHANGE_PATH request from the > initiator. (As described below, the responder can, however, update > the IKE_SA in some circumstances.) I think we should say that responder never updates IKE_SA without explicit CHANGE_PATH. Not by any dynamic updates because of NAT-T code or any other reason. We simpy say that it always keeps the IKE_SA addresses intact. > The description in this section assumes that the initiator has > already decided what the new addresses should be. How this decision > is made is beyond the scope of this specification. When this > decision has been made, the initiator > > o Updates the IKE_SA and IPsec SAs with the new addresses, and sets > the "pending_update" flag in the IKE_SA. > > o 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 assume that this implicitly means that retransmissions sent during that time are sent to new address instead of old one? This is not really mentioned anywhere, and it needs a lot of text more to describe that. That same text is also needed if we want to get rid of the PATH_TEST exchange completely. This text should be enough: ---------------------------------------------------------------------- When sending any IKE packets we first try the operational address pair. If we do not get reply back from that we try all other address pairs until we get reply back, or the exchange times out, in which case the IKE SA is deleted. The order in which the address pairs are tried is implementation specific, and can use information from various places. The other end receiving those packets, should reply to all of them it receives, with the addresses and ports reversed. Recipient of any other packet than N(CHANGE_PATH) MUST NOT cause any update in the IKE_SA or IPsec SA addresses (also in case when NAT-T is used). This way any IKE packet can be used to test weather the path works or not. If during the sending of IKE packet we detect that the operational address pair is not working anymore, the original initiator (not the exchange initiator) should take actions to fix the situation by finding new operational address pair, and sending N(CHANGE_PATH) for the new operational address pair. If it was original initiator who was initiating the IKE exchange, then after the exchange finishes it already knows the new address pair which works, so he can simply send N(CHANGE_PATH) to update to new working operational address pair. If it was original responder who was initiating the IKE exchange, it does NOT do any updates itself, it simply assumes that original initiator seeing IKE packets coming from different address pair than current one is, initiates a DPD test itself to verify weather the operational address pair is working, and after that will fall back to another address pairs, and result update to the operational address pair in initiator, it will then send N(CHANGE_PATH) notify to update the operational address pair. If operational address pair is broken down when we are sending N(CHANGE_PATH) exchange, then it is possible that the responder will be updated to the some other address pair than what initiator originally intended (in case of uni-directional connection, i.e. responder getting the first N(CHANGE_PATH) in, but initiator not getting the reply back, thus trying other addresses, and finally getting reply back). In this case the initiator should immediately update his own operational address pair to the one that is working, and do another N(CHANGE_PATH) exchange with the known working address pair to make sure that the initiator and responder do agree on the address pair. Only after when he gets reply back from the address pair he intended to use in the first place, he can be sure that both peers agree on the address pair. In case NAT-T is enabled then implemenations MUST make sure that initiator does DPD in a way that will take care of the updating the other peers addresses in case the NAT mapping is lost. This means that when initiator who is behind NAT start DPD because of the lack of packets from the other peer, he includes the N(CHANGE_PATH) to the exchange too, to make sure that the other peer will update its mapping. If it does not get reply back using operational address pair, it tries other address pairs, and if it does get reply back it does normal operation, i.e. restarts the N(CHANGE_PATH) for that new operational address pair. ---------------------------------------------------------------------- > Note that if the responder has NAT Traversal enabled, it can update > the addresses in both the IKE_SA and IPsec SAs as usual (if it > implements the "SHOULD" from [IKEv2] Section 2.23. There is no reason for the other end to enable the SHOULD in case the MOBIKE is used. We can simply say that it MUST NOT do the dynamic address updates in case MOBIKE is enabled. > 2.5 Path testing If we take my previous text in 2.3, then this section would simply say: Any IKE packets can be used for path testing as long as it has property that responder cannot generate reply packet to it without seeing the request packet. Normally any INFORMATIONAL exchange with N(COOKIE2) is enough. -------------------- Pasi Eronen (2005-07-12): Hmm... it seems the issue of a separate path test message vs. using normal informational exchange for path testing depends a lot on how we handle changes in NAT mappings (if e.g. NAT is rebooted or keepalive interval is too long). It seems that we have several possibilities here. Some preliminary thoughts of what the alternatives might be (but other alternatives might exist too): Option 1: Existing IKEv2 NAT Traversal and its dynamic updates (when using NAT-T, host outside NAT automatically updates the address/port from any authenticated packet). Option 2: Disable the NAT-T dynamic updates, and create a new mechanism for handling NAT mapping changes in MOBIKE. Option 2a: Responder (outside NAT) could notify the initiator when it sees that the port changed, but wait for initiator's CHANGE_PATH message before updating anything. Option 2b: Initiator could send CHANGE_PATH messages all the time just in case the NAT mappings might have changed (even though from its point of view, nothing has changed). Option 2c: More alternatives certainly exist.. Option 3: Disable NAT-T dynamic updates, but don't specify any alternatives for handling NAT mappings changes (==essentially break when NAT mappings change). I'm strongly for option 1 here (although it seems that we probably need a separate path test message then). Option 3 does not sound very attractive compared to 1, and at least 2a would IMHO require rechartering the WG. (The charter says "the WG shall NOT develop mechanisms for the following functions: [..] IP address changes done by third parties (NATs, firewalls etc). [..] MOBIKE handles IP address changes initiated by one of the endpoints of the security associations. NAT traversal handles other address changes.") -------------------- Tero Kivinen (2005-07-14): Pasi.Eronen@nokia.com writes: > Hmm... it seems the issue of a separate path test message > vs. using normal informational exchange for path testing > depends a lot on how we handle changes in NAT mappings (if > e.g. NAT is rebooted or keepalive interval is too long). Not really. The problem only occurs if we want to use the path test to test previously broken path without affecting the currect path and there is NAT-T between. If we use path test only when the operational address pair has already broken down then we do not need to modify dynamic address updates of the NAT-T. > Option 1: Existing IKEv2 NAT Traversal and its dynamic updates > (when using NAT-T, host outside NAT automatically updates the > address/port from any authenticated packet). Note, that the dynamic automatically NAT-T address updates is SHOULD in the IKEv2 draft, and it is SHOULD because implementors said they will not implement it, and do not want it to be MUST so they can leave it out... I do not know if anybody has yet really implemented it (I know that our code do have some hooks for it so it can be added, but currently it is still not implemented). I do not even know if anybody ever implemented that on the IKEv1 NAT-T. I think most of the implementors consider that feature so small corner case, that they do not bother implementing it and testing it. > Option 2: Disable the NAT-T dynamic updates, and create a new > mechanism for handling NAT mapping changes in MOBIKE. As IKEv2 NAT-T does not need to do dynamic updates, we might want to implement our own mechanism anyways, if we consider problem important. > Option 2a: Responder (outside NAT) could notify the initiator > when it sees that the port changed, but wait for initiator's > CHANGE_PATH message before updating anything. I do not see need for that. The rebooting of the NAT already caused lots of packets to be dropped, so the user is going to notice it anyways. For the non NAT-T user rebooting of the NAT did cause all the connections to be broken. We can simply assume that the initiator fixes the issue when it notices it (by not receiving any packets). > Option 2b: Initiator could send CHANGE_PATH messages all the > time just in case the NAT mappings might have changed (even > though from its point of view, nothing has changed). Initiator does not know if anything has changed, but something might have changed, so he might want to make sure that both peers share the same view of the operational addresses, thus sending CHANGE_PATH messages, when it sees no traffic from the other end. > Option 2c: More alternatives certainly exist.. One option is the initiator to start DPD with NAT-D payloads, and when it receives reply from the other end, he can compare those NAT-D payloads to the NAT-D payloads it received earlier, and if they do not match, he knows the NAT has been rebooted, and can start corrective actions (i.e. send CHANGE_PATH). I think 2b is simpliest and offers fast enough recovery in the rebooting NAT case. The good thing about that is that it does not require any extra code in the responder (except that responder needs to disable dynamic automatic updates in case it happened to support those, and MOBIKE is enabled), and requires very little code in the initiator (i.e. if NAT-T was enabled, add CHANGE_PATH notify to DPD packet). > Option 3: Disable NAT-T dynamic updates, but don't specify any > alternatives for handling NAT mappings changes (==essentially > break when NAT mappings change). I think this is the most common case of the IKEv1 and IKEv2 NAT-T handling today. And would be quite ok for us too, but as the 2b is better, and it requires so small implementation changes that it will get implemented, I think that is better. The MOBIKE implementations needs to implement the CHANGE_PATH anyways (and yes, I think most of the implementations will at that point also implement the dynamic automatic updates for regular NAT-T (when no MOBIKE) as it comes almost free after the infrastructure required for MOBIKE and CHANGE_PATH is there. > I'm strongly for option 1 here (although it seems that we > probably need a separate path test message then). Option 1 does not require separate path test unless you want to be able to test unidirectional broken paths, and do not want to cause any lost packets during the process. > Option 3 does not sound very attractive compared to 1, and at least > 2a would IMHO require rechartering the WG. Yes, I do not think the option 3 is really useful option, as it simply leaves the problem open. > (The charter says "the WG shall NOT develop mechanisms for the > following functions: [..] IP address changes done by third > parties (NATs, firewalls etc). [..] MOBIKE handles IP address > changes initiated by one of the endpoints of the security > associations. NAT traversal handles other address changes.") I am not sure if even the 2a would require rechartering, at least 2b and 2c is more or less describing "how they interact" (NAT-T and MOBIKE). Actually the original idea behind the charter was that MOBIKE would not do anything about NATs, i.e. if NAT is detected, then we do not use MOBIKE, but simply use normal NAT-T (note the "if any" in the text saying "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"). This was already decided in the WG that we do want to use MOBIKE and NAT-T together. My understanding of the that charter text is that we are not allowed to modify actual UDP encapsulation part of the NAT-T, and we must use the NAT-T mechanisms in the IKEv2, but we can profile the NAT-T (i.e. say which features are mandatory to implement and which are not, or which features must be enabled or disabled). -------------------- Pasi Eronen (2005-07-14): Tero Kivinen wrote: > > Pasi.Eronen@nokia.com writes: > > Hmm... it seems the issue of a separate path test message > > vs. using normal informational exchange for path testing > > depends a lot on how we handle changes in NAT mappings (if > > e.g. NAT is rebooted or keepalive interval is too long). > > Not really. The problem only occurs if we want to use the path > test to test previously broken path without affecting the > currect path and there is NAT-T between. If we use path test > only when the operational address pair has already broken down > then we do not need to modify dynamic address updates of the > NAT-T. This was discussed already in May 2005... At least some people thought that it would be useful to allow path testing even when the current path is working (and without disrupting ongoing communication). > > Option 1: Existing IKEv2 NAT Traversal and its dynamic updates > > (when using NAT-T, host outside NAT automatically updates the > > address/port from any authenticated packet). > > Note, that the dynamic automatically NAT-T address updates is > SHOULD in the IKEv2 draft, and it is SHOULD because > implementors said they will not implement it, and do not want > it to be MUST so they can leave it out... > > I do not know if anybody has yet really implemented it (I know > that our code do have some hooks for it so it can be added, > but currently it is still not implemented). > > I do not even know if anybody ever implemented that on the > IKEv1 NAT-T. I think most of the implementors consider that > feature so small corner case, that they do not bother > implementing it and testing it. Linux (Open|something)SWAN implements it for IKEv1 NAT-T. I don't know about others... > > Option 2: Disable the NAT-T dynamic updates, and create a new > > mechanism for handling NAT mapping changes in MOBIKE. > > As IKEv2 NAT-T does not need to do dynamic updates, we might want > to implement our own mechanism anyways, if we consider problem > important. I'm not quite sure how important problem this is, but since the problem is already solved in IKEv2 NAT-T, I think we should have really good reasons for not using that solution. (Much better ones than "I didn't bother to implement that SHOULD in my product" or "Not invented here / We just like doing things differently"). > The MOBIKE implementations needs to implement the CHANGE_PATH > anyways (and yes, I think most of the implementations will at > that point also implement the dynamic automatic updates for > regular NAT-T (when no MOBIKE) as it comes almost free after > the infrastructure required for MOBIKE and CHANGE_PATH is > there. If that's the case, wouldn't it be simpler to just use the same mechanism (dynamic automatic updates) when NAT-T is used with and without MOBIKE? -------------------- [Issue list editor's note: see mailing list archives for more discussion] -------------------- Jari Arkko (2005-09-27): Based on discussion, it appears that most people prefer the following: 1) NAT-detection payload -based NAT reboot/change detection as a complement to existing source address -based mechanisms. This mechanism would be used if MOBIKE is on, because otherwise MOBIKE probing would become harder. Detection would be done by including NAT detection payloads in dead peer detection messages. Existing source address -based detection is still allowed in limited manner: "MUST NOT do automatic update with IKEv2 packets when MOBIKE is used (breaks the probing), but you MAY do it for ESP packets." 2) Use IKE messages for the path testing that is needed in MOBIKE. I have specifically left out the conclusion about whether to do return routability after a NAT change is detected. I'm hoping its covered by the policy that we already have for return routability usage. If people disagree about this we'll open a separate issue on it. Also, it was brought up during the discussion that our charter talks about NAT traversal, requires us to not change IKEv2 NAT traversal but also requires us to document how they work together. There has been a discussion of how well the different alternative proposals follow the charter. We discussed this with Paul and concluded that its important we choose the solution that the group feels is the technically correct one. The charter requires us to document interactions, which we are doing. We also do not change anything in the regular NAT traversal behaviour, except that when both NAT traversal and MOBIKE are being used we need to handle source address changes in MOBIKE-compatible manner. We realize that any specification of the interaction that goes beyond ("they can be used completely independently" and "they can not be used together at all") is walking a fine line between complying and violating the charter. But we feel that in this case we are still reasonably within charter. --------------------