On 04/02/15 23:20, Robert N. M. Watson wrote:
On 2 Apr 2015, at 21:54, Hans Petter Selasky <h...@selasky.org> wrote:
I see from the code that if two frags have the same IP offset, the whole fragment list
gets dropped, unless the IP payload is zero bytes long. Maybe a "last" variable
should be added?
Hi Robert,
Are you solving an actual problem you've observed, or is this a speculative
proposal?
Yes, I saw in the FreeBSD network code that fragments having IP payload
< 8 are not allowed, after writing this e-mail.
I think you would benefit a great deal from reading Stevens Volume I (second
edition) before proceeding with further changes to the TCP/IP code stack.
I will order and read this book eventually. I appreciate your tip.
I would like have a comment on one final issue about the IP ID field.
Given two [small] prime numbers: P and Q
Assume you have a firewall that separate two networks, called A and B,
that are not allowed to communicate.
In network A an application pings the firewall and sees the IP ID field
changing P steps.
In network B an application pings the firewall and sees the IP ID field
changing Q steps.
If the application in network A always see that the IP ID field is
changing P steps, it knows the application in network B did not send any
packets.
If the application in network B always see that the IP ID field is
changing Q steps, it knows the application in network A did not send any
packets.
Detecting sending and not sending packets can be used as a way of
reliable duplex binary communication.
I think the current and past implementation of the IP ID field in
FreeBSD can be used to leak information between networks, or am I
totally wrong?
As long as the IP ID counters are shared between two or more secured
networks, there will be a problem. Something along the lines of D2211
might be a way to solve such an information leak without too much overhead!
--HPS
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"