Jason Thorpe <thorpej@nas.nasa.gov> writes:
>  > 2) There's no need to check the header checksum.  In the rare case
>  >    where it's incorrect, either: a) we will fail to find a flow and go
>  >    through the slow path anyway, or b) it will be dropped by the
>  >    destination host.  I believe many hardware routers don't do this
>  >    either.
> 
> Probably worth checking Router Requirements...

And if we do this, can we make it a syctl option just in case we
someday discover a problem? I don't know why, but I'm worried that
this and 3) might somehow allow a clever person to get security
compromising packets past a router that might not ordinarily pass
them. (I suppose it is because it is reminisent of the origins of some
of the Cisco bugs like this in their fast forwarding path.) I'm not
saying I can think of the way yet, but having a way to turn these
optimizations off should an exploit be found makes me more
comfortable.

>  > 3) There's no need to check the IP packet length.  Again, in the rare
>  >    case where it's incorrect, it will be rejected on the destination
>  >    host.  Furthermore, truncating the packet may actually reduce
>  >    efficiency (e.g. by forcing us to repad a packet to send it out an
>  >    Ethernet interface).
> 
> If you're referring to the change made in rev 1.6, this actually fixed
> a bug which I believe caused some systems to crash... Bill Sommerfeld
> can probably shed more light on this.
> 
>         -- Jason R. Thorpe <thorpej@nas.nasa.gov>