Subject: Re: Bugs in PF_KEY marshalling, socket-buffer overflow
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: tech-net
Date: 05/22/2004 14:14:51
In message <15033.1085192361@marajade.sandelman.ottawa.on.ca>Michael Richardson wri
tes
> It was a neat idea, but was a mistake.
> The idea is 10 years old, from before we even Photorus, and we thought
>that we'd have a multitude of key managers hanging out. The reality is
>that we don't yet have one good key manager, let alone multiple ones.
Michael,
Don't let Itojun trick you into conflating two quite separate issues.
The reliability or non-reliability of RFC-2367 is a red herring.
Even if you grant Itojun's point[*] the KAME PF_KEY code *still* has a bug.
That bug is that the PF_KEY will discard part of a DUMP response
stream, but gives the application *NO WAY* to discover the truncation.
The application has no way to resynchronize with the PF_KEY message
stream (no way to find the end of the dump stream, after truncation),
and thus no way to recover. The application deadlocks.
[*] No sane, sensible Internet engineer would agree with Itojun.
Unreliable notification of ACQUIREs means unreliable IPSEC, to the
exact same degree; end of story. Then again, it wouldn't be the first
time Itojun has bought into a damn-fool stupid idea, just because
someone wrote it up as an Internet-Draft.
> Making it un-reliable or multicast was a mistaken.
True, but completely irrelevant to the fact that the KAME PF_KEY has a
bug in how it notifies applications of truncation of a stream of DUMP
responses. (i.e., it doesn't.)
As far as I can see, Itojun's responses to this point are bordering
on mendacious.