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

[Jesse Gross]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20100810/2a65e80f/attachment-0003.html>