Re: issue 5: zero address set

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.

The deadline for this argumentation is Wednesday,
Nov 17th.

--Jari

Jari Arkko wrote:
> 
> 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
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> 
>