-------------------- IETF60 MOBIKE WG minutes: Pasi: We have two kinds of local problems: one where you get some kind of trigger for L2 or something, and second where you only see lack of packets. I think we should handle both. Jari: Personal data point: half of the time when having connectivity problems I don't see any local indication. We should handle this. Tero: yes. Bill: You need to consider both types. (Example how Solaris multipathing handles both kinds) -------------------- Francis Dupont (2004-08-12): note that this issue applies only if we decide that the protocol should handle everything by itself, i.e., there is no generic control of the mobile/multi-homed environment (what should be likely the case for a not-dedicated-to-IPsec box). -------------------- Francis Dupont (2004-08-13): > Modify that MOBIKE/IKEv2 to include also IPsec then I agree... The > most common way to get the information is to notice that there is > no ESP packets coming in.... => IMHO this is a dangerous path to follow because it shall give a monster for the MOBIKE/IKEv2 tool. I understand you are more interested by MOBIKE SGs than by more generic mobile/multi-homed boxes where MOBIKE is only a small part of the whole thing but please don't specialize MOBIKE as some are always trying to specialize IPsec to VPNs. -------------------- Tero Kivinen (2004-08-13): The MOBIKE/IKEv2 will be used along with IPsec, I do not even consider and option that we would create MOBIKE to be used without IPsec. Most of the IPsec implementations already check out the flow if ESP packets, and can start actions if they are missing for too long (for example IKEv1 you used that for crash recovery and dead peer detection). Why we cannot allow that same mechanism to be used in the MOBIKE? I don't think we want to mandate that thing, but we do want to say that MOBIKE implementations are allowed to consider the connection to be up if there is ESP packets coming from the other end. -------------------- Francis Dupont (2004-08-13): > Do you mean that lack of ESP packets would trigger an IKEv2 > informational request and lack of response to that would trigger > MOBIKE to change paths, or that lack of ESP packets > would directly trigger MOBIKE to change paths? => this is exactly the kind of questions we should avoid: the lack of ESP packets should be reported (not by MOBIKE but by IPsec itself) to the control which can ask to MOBIKE to trigger an IKEv2 informational request or to change paths. The control mechanism can be inside or outside the MOBIKE tool but should NOT be defined by MOBIKE. As a Mobile IPv6 implementor I can say that handoff detection is not so easy and I definitively don't want to get it in my IKE daemon code or in MOBIKE specs. Just ask Jari... -------------------- Vijay Devarapalli (2004-08-13): what is "lack of ESP packets"? for how long do you wait? isnt this dependent on the application? do you want to trigger an IKEv2 informational request everytime the application "pauses"? MOBIKE shouldnt decide. I agree with Francis, that the "lack of ESP packets" should be handled elsewhere in the stack (and not in MOBIKE). -------------------- Mohan Parthasarathy (2004-08-16): There are already other working groups like DNA, multi6 etc. that would come up with mechanisms to detect link changes, path changes etc. MOBIKE could just use that. But your concern is how will MOBIKE interface with other modules to learn the information ? i.e., if there is no mechanism to learn about link up/link down in the system or MIP4/MIP6 is not implemented in the node, what should MOBIKE do ? Also, what does it mean if there are other mechanisms, should MOBIKE use that or invent something new or take into consideration both ? It would be simpler if we just document what sort of triggers ( a few examples) are needed for MOBIKE to work. Whether it is implemented as part of MOBIKE or outside of MOBIKE is an implementation detail. I guess this is what Francis is getting at. If so, i agree. -------------------- Pasi Eronen (2004-08-16): IKEv2 already triggers an informational exchange if there's no incoming ESP traffic for some time (how long you wait is not specified). We're not changing that part, I hope. The main issue for MOBIKE is what to do if we don't receive a reply to the informational request (even after some number of retransmissions). If we don't do anything, the SAs will be closed. In my opinion, that's not acceptable. The lack of replies should trigger changing to some other addresses (if a working path is available). We don't need to specify exactly how this works, and as Francis pointed out, there are many complex issues in e.g. handoff decisions that we don't want to put in MOBIKE specs. What we IMHO do need to specify are the parts required for interoperability, like what is sent/received to/from the other node, and some parts of how those messages are processed. I think this should be specified in the MOBIKE spec; that is, we should not assume that there is some other unspecified protocol (in addition to IKEv2 and ESP/AH) running between the parties. -------------------- Vijay Devarapalli (2004-08-17): > What we IMHO do need to specify are the parts required for > interoperability, like what is sent/received to/from the other > node, and some parts of how those messages are processed. > I think this should be specified in the MOBIKE spec; that is, we > should not assume that there is some other unspecified protocol > (in addition to IKEv2 and ESP/AH) running between the parties. IMHO, I prefer "something in the Mobile Node" telling MOBIKE, "switch to using this address with this VPN GW". then a MOBIKE update should be sent. this is the model I had in my mind. for "something in the Mobile Node" I had assumed DNA, MIP6, Multi6, new address configuration, default router change, etc... -------------------- Mohan Parthasarathy (2004-08-17): > IMHO, I prefer "something in the Mobile Node" telling MOBIKE, > "switch to using this address with this VPN GW". then a MOBIKE > update should be sent. this is the model I had in my mind. > But we don't want to restrict MOBIKE to do it this way. This means we should keep MOBIKE flexible enough to use any external trigger it wants. -------------------- Tero Kivinen (2004-08-17): Atul.Sharma@nokia.com writes: > I agree we should try to recover from as many failures/changes > as possible without making the protocol unreasonably complex. I > think use of keepalives, which are needed anyway, for this purpose > should not make the protocol any more complex than it already is. Note, that NAT-T keepalives are not authenticated, and MUST NOT be used to any other purpose than to keep the NAT mapping up. They MUST NOT be used to give any indication whether the other end is up or not. The sender of the keepalives, can stop sending them at any time, if it detects that NAT does not need them, or it can put the TTL low enough so that they never reach the final IKE destination, but do go through the NAT. And the sender do not send keepalives if it has sent any ESP packets lately to the other end, i.e the ESP packets also acts as keepalives, the specific keepalive packets are only used if there is no other traffic going through. -------------------- Pasi Eronen (2004-08-24): Vijay Devarapalli wrote: > IMHO, I prefer "something in the Mobile Node" telling MOBIKE, > "switch to using this address with this VPN GW". then a MOBIKE > update should be sent. this is the model I had in my mind. > > for "something in the Mobile Node" I had assumed DNA, MIP6, > Multi6, new address configuration, default router change, etc... Those are the things Jari called "local knowledge": something in the mobile node knows what should be done ("switch to this address"), based on information that's "local" in the sense that it's not a result of an end-to-end protocol between the IKEv2 nodes. I don't think there's any disagreement about handling those: we just assume that there's "something" in the mobile node that triggers appropriate MOBIKE messages to be sent. But issue 16 is more about what to do if we know there is a problem (==we don't receive any replies to our IKE requests, even after retransmissions), but we don't know what address change would correct the situation (because the "local knowlege" is either not reliable enough, or the failure is in the "middle" where local knowledge does not reach). Here the options seem to be: (1) fail, (2) send some IKEv2 message(s), either new ones or the one we were retransmitting, along some other path, and use information about their delivery to help deciding what should be done, or (3) send some non-IKEv2 message(s) along some other path. Now, option 1 would be the right choice only if we assume that the "local knowledge" is reliable enough, and we do not care about non-local failures. (Is this the choice you prefer?) Option 3 means we don't have interoperability unless the nodes also agree what that non-IKEv2 end-to-end (between IKEv2 peers) protocol is. So my opinion is strongly something like option 2: if we don't receive replies to our IKEv2 request(s), try sending them along some other path (unless the current path is the only one acceptable to us, of course). -------------------- (issue list editor note: see mailing list archives for most posts about this issue) -------------------- Jari Arkko (2004-12-14): This issue is by the way related to #17, where we decided that we do not assume all pairs of addresses have connectivity. I believe the difference between #17 and #16 is that #17 talks about the connectivity upon an address change; #16 talks about whether we test/react if a currently used path goes broken in a silent way. I think what you say below is pretty much correct. I would add that we really have logically two separate tests: (1) The one that we use when we search for a new path; I feel that MOBIKE needs to define this although there was some discussion about whether we should wait for some other WG to develop it for us. But this is in the domain of issue #17 more than for #16. (2) The one that we use to test that the path is still alive. This we already have in IKEv2, its called DPD. Or do you see why DPD could not be used? And yes, we there seemed to be agreement in DC that the path choice decisions of MOBIKE are influenced by multiple sources, such as what DHCP/DNA/ND/L2 tell us, as well as what DPD tells us. -------------------- Joe Touch (2004-12-14): Links already react to things coming up and down. Routing already moves things around links that disappear. The key question is whether IKE should be doing something directly involving different addresses. That starts sounding like a routing or link management protocol, and can (and will) interact with link or routing adjustments. While I appreciate that IKE should retry, or allow reconecting, which could involve different addresses (i.e., different source address used on retry/restart), managing the addresses seems like it should be a side-effect of the restart (leave the source address blank, let it be filled in on exit) rather than explicitly managed. The latter is asking for interaction with link/routing reconfiguration, in a bad way, IMO. -------------------- Hannes Tschofenig (2004-12-21): maybe we get a little bit lost on this particular issue. what are we discussing here? here is my short summary: a) mobike might get information from other protocols. this might indicate that there is something wrong with the currently selected preferred address. mobike does not specify with which protocols it needs to interact and it does not specify the policy for changing the preferred address. this is implementation dependent. b) there is also a mechanism to detect that something happened along the path between the ikev2 initiator and the ikev2 responder using some sort of message exchange (we called it dead-peer detection - which is not the best name for it; sctp folks called it heartbeat). this message exchange might reveal that something is wrong along the path between from a given source address towards a destination address. this might require a new preferred address to be selected. this new preferred address needs to be communicated to the other ikev2 peer. the format of these messages will be found in a mobike specification. btw, we are not the first discussing this area. there has been a lot of work in the context of sctp on this issue. i have the impression that they have the same view on it. hence, i think that there are not particular problems here (except that we are a little bit struggling with terminology issues). -------------------- Jari Arkko (2005-03-04): We had a lengthy discussion about this in December. Here's what I think the conclusion was: o MOBIKE can be affected by multiple sources of information, both local (L2 tells it no longer is connected) and path-related (DPD tells that we have a problem). o Retrying with new addresses (src and dst) is OK under such problem situations. Recommend leaving specific address selection to lower layers in the stack, e.g., unspecifed source address when using API to IP. o Potential interference with dynamic routing protocols needs to be noted & documented. -------------------- Issue closed with summary "MOBIKE can be affected by multiple sources of information, including failing dead peer detection." on 2005-04-18. --------------------