Jari Arkko wrote:
> > Case 2 is more complicated, since it does not tell where the
> > problem is. Presumably both ends can detect the problem, and
> > will eventually do so. But which end should do something about
> > it? And if both ends are multihomed, which of the remaining
> > paths should be used?
>
> Good questions! There may also be a difference in the reasons
> why we get case 2, for instance:
>
> - case 1 is about to happen, but we got the ICMP first
> and will see the L2 event or case 3 indication from the
> peer soon.
>
> - case 1 has happened, but our L2 or L3 is incapable of
> detecting the problem.
>
> - routing problem in the network in between.
>
> These may also require different responses. The right
> thing for the first bullet would be to wait, I think.
> I don't know what the right response for the other two
> bullets is, and I'm not even 100% sure bullet three is in
> scope of MOBIKE...
From the protocol point of view, the last two bullets are
difficult to distinguish... the only difference seems to be that
in the second bullet, the routing problem is "near" one of the
endpoints, while in the third, it's somewhere "in between".
> > These two cases seem to also require quite different messages
> > from the protocol. Case 1 is just "my new address is X"
> > message: reasonably simple to implement, especially at the
> > receiving end.
>
> Yes.
>
> > Case 2 seems to require some kind of address lists, but this
>
> Routing problems might even require address x address pairs.
Yes. Especially if both ends are multihomed, lack of packets alone
doesn't tell which end should change its address (or even both).
And not all combinations are even guaranteed to work: if we have
e.g. two multihomed security gateways connected via two different
private networks, both ends have to change their address when the
current path fails.
> > might not be enough. For instance, it might make sense to
> > distinguish "primary path" (or "primary address") from "current
> > path" (that is used for traffic now), since we might want to
> > switch back to the primary path when it becomes available again.
>
> Why?
I was thinking about the case where the failures are detected only
by lack of packets, and one end (maybe the initiator) is responsible
for doing something about it.
Assume that path (I1,R1) goes down, and the initiator asks the
responder to switch using (I1,R2). The initiator might still want to
remember that the responder preferred R1 to R2 (e.g. R1 is behind a
high-speed link but R2 is a slower backup link). This way it could
continue to test (I1,R1) every now and then, and switch back when it
becomes available again.
(This distinction might not be needed in all possible protocols,
though; presumably each party can remember its own preferences
anyway.)
> > One option which might simplify case 2 is that the parties
> > would agree in the beginning which of them (only one) is
> > responsible for this "path failover" functionality... or
> > are there some failure cases I haven't considered?
>
> Yes. Or we could hardcode it in the protocol, say the
> IKEv2 initiator handles all path failover problems. (In
> addition, we need to decide which of these failover
> problems we will solve in MOBIKE.)
I've been sketching one possible way how this "path failover"
could work. The payloads or messages are not that complicated,
but we should also specify the expected behavior of the endpoints,
and that seems more complicated...
o Both parties to DPD as usual (meaning that if DPD fails
totally, the IKE SA is closed)
o Both parties can send CHANGE_ADDRESS payload at any time,
containing its new address. The recipient updates all SAs
immediately, and triggers an empty informational exchange
to be sent "some time soon" (not necessarily immediately).
o This might be even made NAT compatible by defining that
all-zeroes (or missing) address means "use the IP address
from IP header" (and also include NAT_DETECTION_* payloads
or something).
o The responder can send an address list to the initiator (and
update it later), containing its addresses (with first one
being the primary address). The initiator stores this list,
but does not immediately do anything to any SAs.
o When the initiator thinks that something is wrong (e.g. it
has retransmitted a request several times, or retransmitted a
response several times), it triggers "path testing". Path
testing works as follows:
- Initiator first makes a list of paths that are to be
tested, using the address list received from other end, and
its own addresses. This could be either all N*M paths, or
if the initiator has some additional knowledge, only a
subset of that.
- Initiator sends the previous IKEv2 request (not a new one,
to avoid problems with window size) over all the paths.
- The responder retransmits its last response. The initiator
checks the IP header of the responses, and keeps track
which paths seem to work.
- The initiator does a couple of retransmissions over those
paths which don't seem to work.
- After a while, it knows which paths work and which don't.
It then selects one of those that work, considering both
its own and responder's preferences in some unspecified
manner.
- Initiator then updates its own SAs (both source address to
use, and peer's address). If its own address changed, it
sends CHANGE_ADDRESS payload to the responder. If the
responder's address needs changing, it also includes
CHANGE_YOUR_ADDRESS payload, containing the address the
responder should use as the source address.
- When the responder receives this message, it checks that
the address given in CHANGE_YOUR_ADDRESS is ok, and updates
its own SAs (both source and peer address). It also
triggers an empty informational exchange to be sent "some
time soon".
- If the initiator receives a CHANGE_ADDRESS payload
during path testing, it stops the test and processes
the payload as usual (including triggering an empty
informational exchange "some time soon").
- If the initiator finds a need to send a CHANGE_ADDRESS
payload due to some L2/L3 signal, it stops the path test.
o If the current path is not the preferred path, the initiator
starts "path testing" every now and then to see if the
preferred path has started working again.
Hmm, I'm not sure whether this actually works in all possible
cases... at least having only one party do the failover
seems to simplify some things, since there are less
opportunities for synchronization problems :-) Also, the
"path testing" sketched above probably sends more
packets than are strictly necessary in some cases.
Best regards,
Pasi
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.