Re: [TERNLI] Forwarding corrupt packets

[Michael Tuexen <[e-mail]>]

Dear all,
for SCTP there is an ID
http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-05.txt
which sends back a packet to the sender if the receiver detects a  
transport
layer checksum failure...

Best regards
Michael

On Sep 4, 2006, at 9:59 AM, Michael Welzl wrote:

>> 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).
>
> Agreed.
>
>
>> 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.
>
> I still don't get it - no matter how you use them, the
> reaction of DCCP and UDP-Lite would always be to silently
> discard a packet if the transport header is wrong, so
> no harm is being done (except for the potential waste of
> bandwidth you mention above, but we agree that this isn't
> substantial).
>
>
>>>> 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).
>
> I see that this is in the specification, but I question that
> it would have to be so strict (could also be a SHOULD in my
> opinion). The reason is that the checksum coverage field is
> itself covered by UDP-Lite's checksum in any case, so the
> harm is again just a waste of bandwidth.
>
>
>>> 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.
>
> I agree that UDP-lite detection by links as above eliminates
> any need for such explicit signaling. I however question that
> this is clean design - now links should detect UDP-Lite, look
> at the checksum coverage field, then they should also detect
> DCCP and forward corrupt data if it makes sense according
> to the DCCP header. What's next?
>
> This is why I'd prefer an explicit message. This being said,
> there are of course also issues with it - for instance, if
> the link layer should only do this for the specific flow
> which requests it, it must again look at the IP header to
> classify flows. This is probably not much "cleaner" than the
> scenario I criticize here. Then again, a link could just
> forward any corrupt data for a while upon reception of such
> a message, and that single state would have to be refreshed.
>
> I'm guessing that you won't like that - such behavior
> of course requires all the receivers to be able to
> "survive" the reception of corrupt data. I think
> that this should be the case anyway, though - that's
> why we have transport checksums.
>
>
>>> 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 say that this is too strict, based on our previous
> discussion, where you (convincingly) argued that it was
> okay for a link to forward IPv6 packets with errors.
>
> Now you refer to a much stricter specification - so let's
> use TCP over IPV6 as a reference, not UDP-Lite.
>
>
>>> 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.
>
> Hm, right, both the UDP-Lite and DCCP spec are as strict
> as that about this issue, requiring this (in my opinion
> ugly) method of communication between the transport and
> link layers anyway, perhaps making it pointless to add
> additional explicit communication...
>
>
>>> 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].
>> ---
>
> *sigh* ... I just forgot how strict all that text was.
> I wish it wasn't.
>
>
>>> 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- ;-)
>
> This would also work without a), and that's exactly why
> I think that the specifications (indeed, both of them
> have these statements you quote here) are too strict in
> this aspect.
>
> But that's just the way they are, so I guess there's
> no point in debating them right now.
>
>
>>> 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.
>
> Well yes, you said it's appropriate to forward an IPv6 packet
> with a broken IPv6 header, or at least that it doesn't cause
> harm. This type of forwarding just isn't happening for DCCP
> and UDP-Lite because their specs are so strict about this matter.
>
> Cheers,
> Michael
>
>
>