[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Michael's comments on ikev2 draft
> > Agreed. Implementations which don't send deletes continue
> to be a source of
> > interoperability problems.
>
> Which indicates foolish assumptions on the other end, since
> delivery of
> Delete is unreliable and most aspects of Delete support are optional.
The problem is that the WG never standardized on an interoperable rekeying
behaviour. We follow the now-expired Tim Jenkins rekeying draft, but others
have invented at least 3 other distinct rekeying techniques. Fortunately,
where incompatibilities exist, they are mostly fixed by the reception of a
delete. The delete may be unreliable, but it still gets there most of the
time.
(I should point out that if the ADs had let us evolve IKE 3 years ago, we
would have all implemented acknowledged deletes by now.)
Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Henry Spencer
> Sent: Tuesday, December 18, 2001 1:08 AM
> To: Andrew Krywaniuk
> Cc: 'Michael Richardson'; ipsec@lists.tislabs.com
> Subject: Re: Michael's comments on ikev2 draft
>
>
> On Mon, 10 Dec 2001, Andrew Krywaniuk wrote:
> > > 3. Delete payloads are a MUST, which is also good.
> >
> > Agreed. Implementations which don't send deletes continue
> to be a source of
> > interoperability problems.
>
> Which indicates foolish assumptions on the other end, since
> delivery of
> Delete is unreliable and most aspects of Delete support are optional.
>
> However, the deeper point -- that too many significant things
> in IKE are
> unreliable or optional or both, and this needs fixing -- is valid.
>
>
> Henry Spencer
>
> henry@spsystems.net
>
>
Follow-Ups:
References: