[ovs-dev] RFC: correct way to deal with runt packets

[Ben Pfaff]

On Tue, Aug 10, 2010 at 05:46:20PM -0400, Jesse Gross wrote:
> On Tue, Aug 10, 2010 at 5:02 PM, Ben Pfaff <blp at nicira.com> wrote:
> 
> > On Tue, Aug 10, 2010 at 04:56:24PM -0400, Jesse Gross wrote:
> > > On Tue, Aug 10, 2010 at 4:27 PM, Ben Pfaff <blp at nicira.com> wrote:
> > > > In a recent thread, you pointed out that the kernel and user datapaths
> > > > mishandle packets that have too-short IP headers.  That is, if a frame
> > > > has an Ethernet type of 0x0800 (IP), but the Ethernet header is
> > followed
> > > > by less than 20 bytes (the minimum length IP header), then the flow
> > will
> > > > have dl_type 0x0800 and the L3 header pointer in the skb will point to
> > > > the incomplete IP header, with no easy way for code that receives the
> > > > skb and flow to tell that the IP header was missing or truncated.
> > > >
> > > >    3. Leave the dl_type and L3 header pointer set as they are now, but
> > > >       make code that cares about them itself check that the packet is
> > > >       long enough.  This has the potential advantage of dropping
> > > >       branches from the flow_extract() code, which is probably the fast
> > > >       path here, putting all of the checking burden into the code that
> > > >       actually needs to change headers, which probably doesn't get hit
> > > >       as much.
> > >
> > > Options #3 sounds reasonable to me.  What would you do if the header is
> > too
> > > short to perform an action?  Drop the packet?  Not do the action?
> >
> > Just not doing the action would be consistent with what OVS does if the
> > packet is otherwise inappropriate for the action, e.g. ODPAT_SET_TP_SRC
> > does nothing for non-IP packets, so I'd be inclined to do that.
> 
> One thing that makes me a little nervous is if people are trying to use this
> for security applications.  It is conceivable that someone could craft a
> packet long enough to contain an attack payload but with a slightly too
> short header.  If someone created a flow to either drop or modify these
> types of packets then this behavior might allow someone to evade it.  In
> some ways this is similar to the drop frags datapath option.

Do attacks of that form exist?  I would think that the first thing that
a receiving network stack would do would be to validate that the packet
is long enough, and discard it if it is not.