Subject: Re: Bugs in PF_KEY marshalling, socket-buffer overflow
To: None <sommerfeld@netbsd.org>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: tech-net
Date: 05/22/2004 17:21:56
In message <20040522010918.CC67F17921@portal.hamachi.org>Bill Sommerfeld writes
>> ask Craig Metz who designed PF_KEY. you can reach him at
>> cmetz at inner.net.
>
>On the other hand, the other name on that RFC sits in an office across
>the hall from me, implemented PF_KEY in solaris (including reliable
>start/end records for SADB_DUMP) [...]
Bill,
hmm, first *and* last.
Let me guess: the sequence-number in the first record is (record-count
- 1), which tells the requesting app how many records to expect;
whilst the sequence-number field in the last record is 0 to indicate
the end of the stream.
Reliably delivering the last record means Solaris apps (unlike KAME)
could always find the end of the dump stream. And because the first
message is delivered reliably, an app can (reliably) detect drop by
counting how many DUMP responses it got, and comparing to the difference
between first and last sequence numbers. Right?
Thats at least a clearly defensible design :-).