Reliable deletes are basically essential for decent interop of IKE, and most people I talked to at the last bakeoff agree with me. However, I am concerned that the draft that mentioned them (son-of-ike) has not only not progressed, but has vanished.
That is problem 1. Equally important is how reliable notifies will work. One of the brilliant aspects of the draft (i erroneously thought) was that it also addressed the backwards compatibility problem. I had initially interpreted the draft to say that reliable notifies were exactly like normal notifies, except that the payload contained an extra Nonce field for liveness checking of the Ack. I felt this brilliant, since down level clients who didn't support the reliable notify wouldn't send a response, ignore the nonce, but otherwise process the message. The cost is a few extra retransmissions, which also serve to insure that the peer gets the message anyway.
It was pointed out to me, however, that there is a new exchange number for reliable notifies. Doing this breaks all the beautiful backwards compatibility. Of course, we can do the standard silly IKE thing of negotiating reliable delete functionality with the vendor ID payload, or sending double the notifies, once with the standard number, and once with the new one. Both of these methods seem much less clean then just having a single info exchange ID.
Can someone justify the choice of changing the exchange type, and also comment on if there are any plans to actually advance this necessary functionality beyond the word-of-mouth stage.
bs