On 3 Apr 2015, at 10:24, Hans Petter Selasky <h...@selasky.org> wrote:
>> Before engaging further in this conversation, and trying to modify the >> behaviour of the TCP/IP stack, you need to educate yourself about the design >> and history of the protocols involved. Otherwise, you're going to repeatedly >> suggest ideas that are fundamentally broken, and we're going to waste our >> time shooting them down when you could just have done a bit of background >> reading and learned the basics of the protocol design and implementation. > > I went to wikipedia and looked up covert channel and found this: > https://www.sans.org/security-resources/idfaq/covert_chan.php > > What's described there is entirely about Peer2Peer communication. What I'm > describing is broadcast for the whole system or firewall. Don't you > understand that the IP ID counter is _linearly_ adding up and feeding back > the sum to the source. It is like a radio channel for the whole firewall. Do > you know how analog modems work? I have other things to do this easter and I > don't want to spend more time with this either. I think the people > responsible in the IP-stack area should make a fix. The IP ID must be > randomized much more than it is today. What I understand is that you are uninterested in doing the basic background reading required to have a sensible conversation about this code, and instead you are hacking away at the code and proposing changes without understanding the requirements. Once you've read Stevens Volume I and the appropriate sections of the FreeBSD D+I code, we can start talking about requirements for the IP ID code. If you want to talk about covert channels, then you need to move beyond Wikipedia as your primary information source, as there is an extensive literature in TCP/IP covert and side channels. Please stop proposing changes to protocols and code that you simply don't understand (i.e., to use different IP ID values for different fragments of the same datagram!), and do the basic background reading. There are real problems to solve here, and I'm certainly open to proposals to solve them -- but it can't be done without an awareness of the framing concerns about protocol design, network-stack interope rability, etc. This is not an area suitable for casual dabbling: if you want to do work in this area, you will need to spend weeks or months coming up to speed. Robert _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
