Re: [TERNLI] Forwarding corrupt packets

[Joe Touch <[e-mail]>]

Michael Welzl wrote:
>>> chances are that it would reach the right place, so where's
>>> the problem?
>> Why do you believe that? With multiaccess networking regaining dominance
>> (802.11, CDMA, etc.), a bad link checksum means the packet header may be
>> corrupted (as well as the data). In those cases, the *link* MUST NOT
>> forward the packet; it doesn't know where to forward it.
> 
> The same is the case if the IP checksum is wrong.

Agreed.

> In a February 2005 discussion on the end2end-interest list, I said:
> 
>>> Still, that doesn't make sense to me. What if you transfer an
>>> IPv6 packet across a link layer that does *NOT* check your data -
>>> why wouldn't this cause harm to the source / destination addresses,
>>> and therefore cause wrong router behavior downstream? 
> 
> and you answered:
> 
>> It doesn't cause harm at the destination, since there's supposed
>> to be a transport checksum (even for ICMP - one was added). I
>> suppose there's no perceived harm in sending some corrupted
>> traffic through the wrong paths.
>>
>> Note - this is designed to address corruption, not malicious behavior.
> 
> ...and that's why I now believe that. You convinced me of it.

The question is the impact of the bad packet.

If the transport checks things and silently discards bad packets, then
the only harm is bandwidth, and I figured this wouldn't be substantial
(since errors are presumably somewhat random).

If the transport reacts to corrupt packets - as would be the case with
UDP-lite and some configs of DCCP - that would be very bad. The
difference is whether we're talking about corrupted data and corrupted
headers; corrupt data isn't too bad (that's what UDP-lite and DCCP are
designed for). Corrupt headers are VERY bad to forward.

>> The link/net ought not look at the transport layer. If it does, it's
>> because it needs to access info at that layer (for app-layer
>> forwarding). In that case, it's necessary to drop the packet because
>> forwarding isn't possible.
> 
> I'd agree that having it look at the transport layer is not
> clean design, but that's what we ended up with in the UDP-Lite RFC:
> 
>    For a link that supports
>    partial error detection, the Checksum Coverage field in the UDP-Lite
>    header MAY be used as a hint of where errors do not need to be
>    detected.  Lower layers MUST use a strong error detection mechanism
>    [RFC-3819] to detect at least errors that occur in the sensitive part
>    of the packet, and discard damaged packets.  The sensitive part
>    consists of the octets between the first octet of the IP header and
>    the last octet identified by the Checksum Coverage field.  The
>    sensitive part would thus be treated in exactly the same way as for a
>    UDP packet.

The link isn't looking at the net layer for forwarding here; it's
looking only for an optimization to detect errors over a subset of the
packet.

For UDP-lite, when the link error is detected (above), the checksum
coverage field could be wrong, which means that it's inappropriate to
use that information to limit link error coverage, and that the packet
MUST be discarded (see 'discard' above).

> If you're going to do this, it might be better to selectively
> enable/disable it.

I disagree; once link protection is provided as noted above and the
UDP-lite checksum fails, there is NO utility in forwarding the corrupted
packet anywhere. So you forward it to the endpoint... to which port? The
port is corrupt, so you can't know you're sending it the right place.

>>> or by always forwarding corrupt data when at least the IP
>>> checksum is ok, which I'd prefer).
>> If the header is OK (link, net, or app - based on what kind of
>> forwarding is happening), then it's OK to forward. If not, then not.
> 
> What you're saying seems to mean that a link layer must not
> forward corrupt data unless it has a means to check whether
> at least its header is correct.

Yes- that's how I read section 4 of the UDP-lite doc, quoted above, and
repeated in specific here:

----
Lower layers MUST use a strong error detection mechanism [RFC-3819] to
detect at least errors that occur in the sensitive part of the packet,
and discard damaged packets.
----

> I don't know any link layer
> technology that can do this - so you're saying that partial
> and separate checksums as in UDP-Lite and DCCP should not
> exist, or only be there for the case where you have a link
> layer that can restrict its checksum to the link layer header.

That's exactly how I read section 4 above.

> Even that might be a nice feature for a new link layer
> technology in my opinion, but in any case you're
> contradicting existing language in the UDP-Lite and
> DCCP RFCs, where it is assumed that link layers can
> in fact forward corrupt data.

Yup. Further in sec 4 of the same doc:
---
   Link layers that do not support partial error detection suitable for
   UDP-Lite, as described above, MUST detect errors in the entire UDP-
   Lite packet, and MUST discard damaged packets [RFC-3819].
---

> In any case, it seems to me that we're again debating an
> implementation detail here - partial and separate checksums
> are there, so it is assumed that there are (or will be)
> link layers which forward some corrupt packets for one
> way or another. Based on this assumption, wouldn't this
> explicit message make sense?

No; UDP-lite requires that the packets be discarded. I don't agree that
sending a signal about corrupt header info is ever appropriate.

>>>> In those conditions, you might end up with one e2e-pair causing a
>>>> separate endpoint to throttle-back thinking its packets are corrupted.
>>>> That cross-contamination seems like a sufficient reason not to do this.
>>> I don't get this - could you go into more details?
>> A sends to B. The packet gets corrupted and goes to C. C throttle's ITS
>> connections because it got corrupted packets, but it didn't. Or
>> shouldn't have.
> 
> Let's pick DCCP as an example protocol. If C throttles its
> connection because of corruption, it means that the Data
> Checksum option is in place - which will detect a failure
> in the header and therefore drop the packet. This feature
> ("option" - one has to be careful what one calls a feature
> in DCCP) is there to prevent exactly this type of problem
> from occurring.

That assumes:

	a) partial coverage of the packet by a strong link
	layer

	b) correct checksum of the packet at the DCCP-partial
	layer

I.e., IMO, the same requirements as for UDP-lite (I haven't checked
DCCP, which is a longer spec, but I'll assume it has similar
requirements, or -should- ;-)

>>>> IMO, partial transport checksums are useful only where the header
>>>> checksum is still valid; otherwise, there's no point in interpreting the
>>>> header at all.
>>> As I say above, that's an implementation detail in my opinion.
>> I disagree; this is a fundamental statement about interpreting bits that
>> are corrupt. It's a mistake to do so. If that impedes forwarding, then
>> you MUST NOT forward.
> 
> Again, you seem to contradict your original statement from 2005.
> If you changed your mind, why?

See above; header vs. data. I've never presumed that forwarding or
signalling based on a corrupt header is appropriate.

>>> We can make recommendations in either direction - right now,
>>> I'm just suggesting this explicit message between the transport
>>> endpoints and the network.
>> If the network header is corrupt - or even if the transport header is
>> corrupt - the network doesn't know which endpoints or apps in the
>> endpoint to inform.
>>
>> In that case, silence is the appropriate response.
> 
> Same point again.

Same reply ;-)

Joe