[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: network partitions and DPD

> 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.

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...

> 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.

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

> 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.

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 ;-).

> 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.

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

> 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
>
>
>
References: