Subject: network partitions and DPD

From: Michael Thomas <[email-masked]>
Date: Mon, 3 Sep 2001 09:01:07 -0700 (PDT)

I had a brief conversation with Bill Sommerfeld at
last IETF about his idea of birth certificates for
IKE with regards KINK. While the idea has a fairly
straightforward solution for KINK (since there's a
reliable source of time from the KDC), I realized
that birth certificates only catch the case where
one of the peers has rebooted. This leaves an
important case with no solution.

That case is where the two peers are separated for
some amount of time by a network partition leaving
a pending connection half open. Consider the case
where the final reply is lost by the initiator and
all subsequent retransmissions fail because of a
network partition. This leaves correct state on
the respondent and incorrect state on the
initiator.

If we want to solve for this -- and I think
there's good motivation for plugging these sorts
of black hole situations in the name of a robust
protocol -- I believe that a failed operation must
always result in the side perceiving the failure
to remove its state for the operation in progress;
this is simple enough. 

The more difficult problem to deal with is what
happens on the side if it believes that its side
of the connection is fully formed? In the example
above, Bob would have both SA's installed and not
know that the network had partitioned. In this
case, Bob may send to a blackhole at Alice and
given current IPsec mechanisms, I don't believe
there's a way to recover. 

One proposal I've heard is that Alice should
initiate keying if she sees SPI's from an unknown
source. The problem is that Alice does not
necessarily have enough information to figure out
how to re-create the SA. This is particularly true
if there are multiple acceptible forms of
identity, different selectors on each end, etc.
Thus, it seems to me that the only reasonable
thing that Alice can do is send Bob an
unauthenticated message giving him a clue that
something might be amiss. The natural thing to
here is to send some sort of ICMP message, I
think.

When Bob receives the ICMP message, he doesn't
really know for sure that the message wasn't
spoofed, but he at least knows how to
reinstantiate the SA. What seems like it would be
useful is for Bob to try to first see if this was
a spoofed attack in the case of IKE (KINK doesn't
suffer from the sort of public key make-work DoS
attack as IKE, so it's more ignorable). Also, it
would be nice if Bob could basically pick up where
they left off. That is, if the ISAKMP SA was
already established, then it would be advantageous
to keep using it if it were a quick mode SA that
was half open. 

At this point, it would seem that Bob should just
remove its old SA's, and initiate a fresh
one. Since Alice had no state in the first place,
I'd think that we'd be back in the ground state,
and that we'd be fully recovered by then. 

What is probably the interesting question is how
best to implement the test to check if the ICMP
message was legitimate. Also, there's a question
in my mind whether there's a need to check other
SA's at the same time. This, I think, needs more
work.

If you made it down here, happy labor day (or end
'o vacation outside NA :-)

       Mike

---

From: "Geoffrey Huang" <[email-masked]>
Date: Wed, 5 Sep 2001 20:47:45 -0700

> important case with no solution.

Yes, I've had the same conversation with Bill.  I think we agreed that
different problems would require different solutions.  (This sentiment has
been voiced by others -- Tero K. comes to mind at the bakeoff.)

I've forgotten, btw, how the birth certificates idea differs from initial
contact...

> the respondent and incorrect state on the

Yes.  There's also the case where one of the peer crashes (and doesn't
necessarily reboot).

> to remove its state for the operation in progress;

Agreed.  This is what we specified in the DPD draft (curiously, you have
"DPD" in the subject line, but you make no mention of it in your e-mail at
all ;-).

> here is to send some sort of ICMP message, I

This assumes that connectivity between Alice and Bob has been restored.  In
many cases, it won't have been, in which I think DPD is probably the best
way to solve the problem.  If the case is that Alice has rebooted, and Bob
continues to send IPSec traffic, Alice could send an unauthenticated Invalid
SPI notify.  It's up to Bob what to do at this point: ignore it (it was
unprotected), kick off a new IKE SA to Alice, etc.  The problem of DoS
exists here, of course, which you point out below.

-g