svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf

[Hans Petter Selasky]

On 04/02/15 23:20, Robert N. M. Watson wrote:
> On 2 Apr 2015, at 21:54, Hans Petter Selasky <hps at 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