Subject: [Mobike] issue 5: zero address set

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Nov 2004 07:01:45 +0200

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-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Mon, 08 Nov 2004 21:59:43 +0200

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 09 Nov 2004 23:13:19 +0100

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.

Regards

[email-masked]

PS: to come back to mobility, when a mobile goes from a physical interface
to another one, in the middle it has two or zero interfaces, and both cases
have "interesting" consequences (here we can see zero cases').
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Mon, 29 Nov 2004 16:04:40 +0200

> Of course, this situation should be temporary.

Right. I have a sense that we have difficulties to
avoid temporary disconnects no matter what we do...
often in wireless we don't get to choose whether we
tell the other nodes that we are going to switch or
go out of coverage; we get a problem and the protocols
have to live with that.

--Jari

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 29 Nov 2004 10:13:26 -0500

> go out of coverage; we get a problem and the protocols

I think there's a difference here between "mobile" (phone) and "nomadic"
(laptop) operation; in many cases, the nomad can do a graceful shutdown
prior to becoming disconnected.

That graceful shutdown means that the peer can be a better network
citizen (avoiding sending useless packets which may bother the next
tenant of the nomad's former address).

Here's an approach which makes zero address support effectively
optional:

Implementations which do support it must be prepared to cope with the
peer losing state while they were disconnected.

Implementations which don't want to support it treat it as if it were a
disconnect operation.

A humorous way to look at it: it's the "Terminator option" ("I'll be
back") to the disconnect operation...

							- Bill