[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Reliable delete notifies
resending in plain text, I hope...
-----Original Message-----
From: Brian Swander
Sent: Friday, October 06, 2000 2:48 PM
To: ipsec
Subject: Reliable delete notifies
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