Re: [TERNLI] Forwarding corrupt packets

[Michael Welzl <[e-mail]>]

Hi,

I think that this SCTP proposal is very interesting -
especially because it doesn't use another checksum but
just assumes that everything is right because it's
improbable to hit the right association anyway. I'm
not yet quite sure whether I like or dislike the
idea, though.

I guess I dislike it:

> >>> * How do you find the process to respond to (since ports are not   
> >>> protected by an IP checksum)?
> >> We just try. Please note that the IP addresses (protected by the  
> >> IP  header checksum),
> > Yes for IPv4, but not for IPv6.
> Correct. However, if there is an error in the IP addresses, it is  
> unlikely that the
> 16+16+2+2+4=40 bytes still match an existing association.

unlikely enough? does this enable an attacker to do bad things,
or doesn't it?

I'm thinking of a very recent email by Joe, where he explained
that bad things can happen if a receiver tells a sender to
slow down because the receiver has received a (corrupt) packet
which it should never have received in the fist place. My
argument was that this would never happen - in DCCP as well
as UDP-Lite, the transport header is always checked.

All of a sudden, your proposal seems to change this matter.
In this context, "we just try" just doesn't have a good
sound to it...


> Hmm. What we have in mind is that the sender gets an indication that  
> a packet was not successfully
> received but was not dropped because of congestion in the network. So  
> the sender does not see
> this "packet drop" as a congestion indication.

and how does a sender react? In the discussions for the
DCCP Data Checksum, there was agreement that we don't know
enough about the right sender reaction to corruption yet -
but simply sending at the same rate without reducing it
at all would not be the right thing to do.

This seems to contradict the following part of your draft:

      The DATA
      chunk should be treated just as if it had been marked for fast
      retransmit with the exception that no adjustment should be made to
      the value of cwnd (providing that the receiver can validate a
      portion of the packet as being what was sent).


Cheers,
Michael