[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shim6 and bit errors in data packet headers

On 7-mei-2005, at 1:29, Erik Nordmark wrote:

But there is one style of recovery where the checksum might help.
When B receives a packet and doesn't have matching context state, instead of sending an error to A, B could initiate creating a new context with A.
This approach needs to be done with care to cope with DoS attacks (don't create any state on B etc). But it is an example of something which can benefit from the checksum.
However, if the mechanism can deal with a DoS attack, presumably it can deal with occasional extra work due to bit errors.

Right. There is a problem, though: presumably there is already a failure, or there wouldn't be any "shim6ed" packets coming in. This means that the receiver that is without state can't contact the remote ULID directly for a return routability check.

We can make this work by adding some extra stuff to the initial exchange between the ULIDs: each host would have to generate a hash over a timestamp, the remote ULID and a secret and then transmit this hash directly to the ULID address. When there is a state loss the correspondent is then able to prove that it held the ULID as a reachable address at a known point in time. However, this mechanism may be too open to sniffing attacks.

BTW if we're just worried about single bit errors you don't need a 16 bit checksum for this. Even a parity bit will find single flipped bits without fail. A very short CRC may be a good alternative.

I don't think I said "single" anywhere. 

Ok.

I think we need to be concerned about all in-transit errors that are not detected by the L2 mechanisms (CRC, etc).

Hm, AFAIK _all_ layer 2 checksums are MUCH stronger than the TCP/UDP/ ICMP checksum. And as long as all that the shim does is transform information that is already covered by a checksum later (= addresses, which are in the pseudo header) then there is no need to have a separate checksum here.