[ovs-dev] RFC: correct way to deal with runt packets
blp at nicira.com
Wed Aug 11 17:33:58 UTC 2010
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.
More information about the dev