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

Reliable delete notifies

Brian Swander writes:
> 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.  

Most of the current implementations will ignore the notification if it
contains anything special, and having nonce there usually qualifies as
a something special. I.e that kind of backward compatibility only
works for very few implementations. 

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

You send new notification that has new exchange type. The old
implementation does not understand that and replies with
INVALID-EXCHANGE-TYPE notification (because it does not know that this
was notification, it will send notification even when we should not
send error notifications to notifications). When you see this
INVALID-EXCHANGE-TYPE you will know that the other end does not
support reliable notifications and can fall back to old method. 

> Both of these methods seem much less clean then just
> having a single info exchange ID.  

>From the discussion in the interop and last few IETF WGs, it seems to
be that WG wants to have new version of IKE that will have some
backward incompatible changes anyways. This will be done by updating
the IKE version number and in new IKE version 2 we can deprecate the
old exchange ID. 
-- 
kivinen@ssh.fi                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
References: