On Mon, Oct 14, 2013 at 8:12 AM, Ben Pfaff <b...@nicira.com> wrote: > On Wed, Oct 09, 2013 at 02:57:55PM -0700, Jarno Rajahalme wrote: > > > > On Oct 8, 2013, at 5:13 PM, Ben Pfaff <b...@nicira.com> wrote: > > > > > The issue is not the minimum Ethernet frame size but the minimum IP > > > fragment size. IP fragments are 8-byte aligned and a multiple of 8 > > > bytes in length. One way to implement a simple firewall that handles > > > fragments properly is to pass all "later" fragments (those with an > > > offset greater than 0) and drop "first" fragments (those with an > > > offset of 0) for disallowed IP/port combinations. Then one cannot > > > usefully evade the firewall: the "later" fragments pass the firewall, > > > but the destination host cannot reassemble them into full IP datagrams > > > and will eventually drop them because it never gets the first > > > fragment. > > > > > > One might naturally want to include TCP flags in such a check, but > > > those would not necessarily be in the first fragment. > > > > It seems the current kernel code will parse the port numbers only if the > > whole TCP header is in the first fragment. For this to be safe in the > above > > scenario, the first fragments filter should always filter out zero > ports, as > > they are indistinguishable from missing ports. > > Yes, it seems so. I had forgotten this, even though I wrote the > rationale for it in datapath/README (under "Handling malformed > packets"). > > > Assuming we keep this behavior, the TCP flags will be there as well. > > And since all-zero TCP flags seem illegal, the TCP flags field would help > > in distinguishing missing TCP header from one with zero,zero port pair. > > I guess you are right about this. It seems that SYN or ACK will always > be set. > > Thanks, > > Ben. >
With that settled, I think I'll be happy with this once we get "lib/flow: Always zero init before first use." in.
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
