[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: about the ULID in the TCP checksum
On 2006-12-28 18:57, marcelo bagnulo braun wrote:
Iljitsch in his review raises the following issue:
my comments are inline
The result of this consistent mapping is that there is no impact on
the ULPs. In particular, there is no impact on pseudo-header
checksums and connection identification.
The problem here is that some intermediate system, such as a firewall
or a smart NIC, may take it upon itself to check the TCP or UDP
checksum and discard the packet if the checksum fails.
how common is this practice? is this widely used?
I've not heard of firewalls doing this, but TCP relays are a known
form of evil - probably shim6 would not work on such a path.
TCP/IP offload mechanisms in general will have to be shim6-aware,
for sure. This is going to be very common in server clusters.
(In general, do we need a TCP/shim6 probing procedure, to check
whether a path actually works?)
For firewalls and the like, the best thing is probably either to
fully monitor the shim state so they can do this properly, or forego
such checking if a shim header is present.
yes, this is probably useful in terms of security also, just like in the
case to TCP connections, where the firewall can decide to accept
segments of connections for which the firewall have previosuly seen SYN
do you think we should add text about this? (if you do, please send text)
For NICs a better solution would be to do an incremental checksum
verification and only over the ULP segment, so that the host stack
must complete the calculation by applying the increment from the
pseudo header, which can largely be cached, so the performance
advantages are almost completely preserved
i don't understand what do you mean by incremental checksum
verification... could you expand on this?