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.