netdev - Re: LRO restructuring?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080811.140351.54834488.davem@davemloft.net>
Date:	Mon, 11 Aug 2008 14:03:51 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	gallatin@...i.com
Cc:	herbert@...dor.apana.org.au, netdev@...r.kernel.org, brice@...i.com
Subject: Re: LRO restructuring?

From: Andrew Gallatin <gallatin@...i.com>
Date: Mon, 11 Aug 2008 09:30:33 -0400

> Last, have you considered simply allowing "inexact" forwarding, where
> the ingress NIC is doing LRO and the egress nic is doing TSO?  You
> loose exact framing information (eg, what you emit might not be framed
> exactly as you receive it), but you can still do filtering, and the
> host overhead is very low.

Intermediate nodes are not supposed to change the transport layer
checksum if at all possible, especially on routers.

Otherwise it is much more difficult to diagnose checksum errors,
and figure out what caused such an error.

When the router doesn't modify the checksum, we know it's an end-node.
Even a firewall only "adjusts" checksums based upon packet
modifications for NAT and such, which will preserve end-node created
errors.

So no this isn't really an option.

This is why Herbert wants to preserve the original headers,
we're not supposed to change them.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html