Em 28-01-2014 15:45, Stuart Henderson escreveu:
> On 2014-01-28, Simon Perreault <sperrea...@openbsd.org> wrote:
>> Le 2014-01-28 03:39, Richard Procter a écrit :
>>> In order to hide payload corruption the update code would
>>> have to modify the checksum to exactly account for it. But
>>> that would have to happen by accident, as it never considers
>>> the payload. It's not impossible, but, on the other hand,
>>> checksum regeneration guarantees to hide any bad data.
>>> So updates are more reliable.
>> This analysis is bullshit. You need to take into account the fact that
>> checksums are verified before regenerating them. That is, you need to
>> compare a) verifying + regenerating vs b) updating. If there's an
>> undetectable error, you're going to propagate it no matter whether you
>> do a) or b).
>>
>> Simon
>>
>>
> Checksums are, in many cases, only verified *on the NIC*.
>
> Consider this scenario, which has happened in real life.
>
> - NIC supports checksum offloading, verified checksum is OK.
>
> - PCI transfers are broken (in my case it affected multiple machines
> of a certain type, so most likely a motherboard bug), causing some
> corruption in the payload, but the machine won't detect them because
> it doesn't look at checksums itself, just trusts the NIC's "rx csum
> good" flag.
>
> In this situation, packets which have been NATted that are corrupt
> now get a new checksum that is valid; so the final endpoint can not
> detect the breakage.
>
> I'm not sure if this is common enough to be worth worrying about
> here, but the analysis is not bullshit.
>
Stuart,
It is more common than you might think. I had some gigabit
motherboards in which some models always would corrupt the packets when
using the onboard nic. I believe that in these cases there isn't much
that the OS can do. Unfortunately, it's always the application job to
detect if it is receiving good or bad data.
Cheers,
--
Giancarlo Razzolini
GPG: 4096R/77B981BC
