-------------------- TEMP-draft-kivinen-mobike-design-00.txt: 3.1 Zero Address Set One of the features which might be usefull would be for the peer to announce the other end that it will now disconnect for some time, i.e. it will not be reachable at all. For instance, a laptop might go to suspend mode. In this case the peer could send address notification with zero new addressess, which means that it will not have any valid addresses anymore. The responder of that kind of notification would then acknoledge that, and could then temporarely disable all SAs. If any of the SAs gets any packets they are simply dropped. This could also include some kind of ACK faking to keep the TCP/IP sessions alive, or it could simply be left to the applications, i.e. allow TCP/IP sessions to notice the link is broken. The local policy could then decide how long the peer would allow other peers to be disconnected, i.e. whether this is only allowed for few minutes, or do they allow users to disconnect Friday evening and reconnect Monday morning (consuming resources during that, but on the other hand not more than is normally used during week days). -------------------- IETF59 MOBIKE WG minutes: Pasi Eronen: I oppose any kind of TCP ACK spoofing as part of this protocol. Tero Kivinen: I agree. Bill Sommerfeld: You can adjust TCP stuff, for instance disable TCP keepalives, to keep them alive for hours or days. So don't specify MitM against TCP in the document. -------------------- Jari Arkko (2004-01-11): There has not been a lot of discussion of this subject on the list or in the meetings, except that in IETF-59 people opposed any kind of TCP spoofing. Unless I hear objections in the next couple of days, we can close this part of the issue. But, theoretically, we could still provide zero address sets without TCP spoofing. What do people think about this? Here's some technical analysis from a personal point of view: It seems that when the a node has no address, its peer could develop some condition which requires sending an IKE message to the node. For instance, rekeying might be necessary for some reason. Or deletion of the SAs. And on the IPsec list we have discussed the possibility of reauthentication requests. Obviously, all of these are going to fail when the node has no address. The same applies to payload packets, given that we are not doing spoofing. As a result, supporting zero address sets does not really help in situations where communication is needed during the period when there is no address. And in any case when an address is finally available, the node has to verify that the SAs are still functional. So there is really no benefit in resumption phase either. Finally, due to the unpredictability of wireless coverage, not being told about a zero address set condition is not a guarantee that the node is reachable. So we cannot easily use this as an indication to applications either. The potential benefit is that no traffic is sent to the peer's old address. This can be useful in terms of saving bandwidth, or avoiding someone else get the packets when an address is recycled. Note that a related benefit is that a laptop that gets suspended for a while does not have to re-establish SAs when it resumes. This may also mean that a user does not have to re-enter passwords or use token cards. However, it seems that this benefit can also be realized with the zero address set, simply by not informing the peer about the loss of address. -------------------- Jari Arkko (2004-11-08): So, the "no TCP spoofing" part is now closed. Pasi, can you split this issue into two parts, and close the TCP part? For the second part, let's make another try with a slightly different process this time. I think we need to be careful about not adding features unless they are absolutely required. So we are going to assume that we do NOT provide zero address sets unless we see multiple people making a case that they actually are needed, and some buy-in for these arguments by the WG. -------------------- Francis Dupont (2004-11-10): I don't believe zero address set support is so useful but I have a little concern about it: when a node has really no available addresses I prefer its peer knows this in place of just keep the last usable address and suggest it does still work... Of course, this situation should be temporary. -------------------- Issue closed after discussion (2004-11-18): "No, there is no need to support this functionality." -------------------- Hannes Tschofenig (2004-12-06): the term 'zero address set' is quite confusing but i tend to agree with the discussions on the mailing list which came to the conclusion that this feature should not incorporated into a mobike protocol. -------------------- Bill Sommerfeld (2004-12-06): whereas I think it makes obvious sense and would like to see it included... -------------------- Jari Arkko (2004-12-06): I guess the key question here is whether there's enough "bang for the buck" in this function for it to be included in MOBIKE. Earlier we didn't see that many people interested, but now we have some. In any case, we need to consider the following: - The benefit this feature offers is about "being a good citizen" (as you Bill put it) and not send unnecessary packets when we know the other end is down. Nevertheless, this is not a functional benefit in the sense that nothing breaks if we don't have it; just that extra packets are sent. - We know we can not use this feature in all cases when the other end is down. We don't always know we are going outside coverage. - We know there's some practical limits to how long this condition can be held and still be considered useful, such as applications on top starting to get timeouts. - There may be some additional complexity for MOBIKE. For instance, assume A and B are talking to each other and that A now informs B that its offline. Now, normally in MOBIKE if B moves it can tell A immediately. But if zero-address set is supported then B must be able to queue this notification. And if all of B's addresses got changed, the situation is not recoverable. -------------------- Hannes Tschofenig (2004-12-08): i am not sure that there is sufficient interest for this functionality. i am still not quite sure that we properly understand this issue. i again thought about it and think that technically we need to provide two things: - temporarily suspend dead peer detection (or path connectivity test) - drop traffic (since it cannot be delivered to the end host anyway) -------------------- Bill Sommerfeld (2004-12-09): On Wed, 2004-12-08 at 05:42, Jari Arkko wrote: > You could also see this function as orthogonal to MOBIKE, i.e., > another IKEv2 feature that can be used to temporarily suspend > all IKE and payload packet flows. I think the on-the-wire protocol representation falls out automatically from whatever mobike-defined IKE extension is used to add or delete addresses from the established IKE SA. end systems which don't implement this would treat this as a tunnel tear-down request. end systems which do implement it would "cap" the tunnel until the peer resumed, some implementation-specific timer expired, or administrative action deleted the tunnel. an end system implementing this would need to be able to cope with lost state on the peer anyway. --------------------