Re: [TERNLI] Forwarding corrupt packets

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 04 September 2006 18:02 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKIm5-0006k3-Rm; Mon, 04 Sep 2006 14:02:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKIm4-0006fH-AP for ternli@ietf.org; Mon, 04 Sep 2006 14:02:20 -0400
Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKIm2-0003NX-Um for ternli@ietf.org; Mon, 04 Sep 2006 14:02:20 -0400
Received: from [192.168.1.100] (p508FCA94.dip.t-dialin.net [80.143.202.148]) by ilsa.franken.de (Postfix) with ESMTP id 405F4245CA; Mon, 4 Sep 2006 20:02:14 +0200 (CEST) (KNF account authenticated via SMTP-AUTH)
In-Reply-To: <1157390125.3291.43.camel@lap10-c703.uibk.ac.at>
References: <1157097623.3192.34.camel@lap10-c703.uibk.ac.at> <44F83E74.1080603@isi.edu> <1157121036.3192.148.camel@lap10-c703.uibk.ac.at> <44F84AD5.7070307@isi.edu> <1157131227.3192.220.camel@lap10-c703.uibk.ac.at> <44F8780D.9060503@isi.edu> <1157356740.3197.57.camel@lap10-c703.uibk.ac.at> <85C961BE-2B32-4A31-8235-49CCDCF1332D@lurchi.franken.de> <44FC2484.50201@erg.abdn.ac.uk> <EE4E54BA-BCEB-4DD7-86AB-B2A44A24ACD0@lurchi.franken.de> <44FC2CA7.90602@erg.abdn.ac.uk> <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de> <1157390125.3291.43.camel@lap10-c703.uibk.ac.at>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4E862E2A-DF85-47C1-98A1-991F3CB58B27@lurchi.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Subject: Re: [TERNLI] Forwarding corrupt packets
Date: Mon, 4 Sep 2006 20:02:11 +0200
To: Michael Welzl <michael.welzl@uibk.ac.at>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Cc: Randall Stewart <rrs@cisco.com>, ternli@ietf.org, Joe Touch <touch@ISI.EDU>
X-BeenThere: ternli@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <ternli.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ternli>
List-Post: <mailto:ternli@ietf.org>
List-Help: <mailto:ternli-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=subscribe>
Errors-To: ternli-bounces@ietf.org

Hi Michael,

see my comments in-line.

I'll not respond the next week, because I'll be on vacation :-)
I'm CCing Randall Stewart, he is definitely also interest in
this subject and should be available next week.

Best regards
Michael

On Sep 4, 2006, at 7:15 PM, Michael Welzl wrote:

> 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:
Hmmmm.
>
>>>>> * 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 think we have to consider two cases:
- An on path attacker. He can do everything, SCTP, as any other
   transport layer (UDP, TCP, DCCP) does not provide any way of
   protection. You could use SCTP-AUTH to prevent this, but this
   would need a shared secret and SCTP-AUTH is an extension, not
   part of "plain SCTP".
- An off path attacker. SCTP uses a 32 bit random number (the
   verification tag) to protect against bind attackers. We
   also recommend that one side uses a random port number (ephemeral)
   which would give another 14 bit randomness to guess. So it
   is 48 bit of randomness an attacker has to guess. The probability
   is 1/2^48 which is pretty small.

So I do not think that this adds an additional threat to SCTP.
But if you have an attack in mind, I would be very interested
to think about it. We (the authors of the ID) do NOT want to
make SCTP with that extension weaker than without.
>
> 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...
Do not get me wrong: This "we just try" means that we try to
lookup the TCB. And I think if there is an error in the port number
V-tag combination, then we will not find a TCB. Everything has to match.
>
>
>> 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).
What we know is:
- the payload was corrupted (the SCTP common header was intact)
- the receiver proofed that he got the packet. So it is not in the
   network anymore
We assume that this is NOT an indication of congestion. So we can  
fast retransmit
it...

>
>
> Cheers,
> Michael
>
>