Re: [Tsvwg] SCTP and ICMP Protocol Unreachable

Michael Tuexen <Michael.Tuexen@micmac.franken.de> Wed, 20 September 2006 16:06 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4aH-0004sk-20; Wed, 20 Sep 2006 12:06:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4aF-0004q6-4g for tsvwg@ietf.org; Wed, 20 Sep 2006 12:05:59 -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 1GQ4aD-00066M-PZ for tsvwg@ietf.org; Wed, 20 Sep 2006 12:05:59 -0400
Received: from [192.168.1.100] (p508FE92A.dip.t-dialin.net [80.143.233.42]) by ilsa.franken.de (Postfix) with ESMTP id 725EC245C7; Wed, 20 Sep 2006 18:05:56 +0200 (CEST) (KNF account authenticated via SMTP-AUTH)
In-Reply-To: <20060920055135.A30614@openss7.org>
References: <20060918104158.GA4005@artesyncp.com> <97E14960-E231-4CB6-B42B-6735ED42B3F4@lurchi.franken.de> <20060919134359.GE11488@artesyncp.com> <161FAFDF-8B94-48B5-8477-0F2F85B75627@micmac.franken.de> <20060920094032.GA28221@artesyncp.com> <20060920055135.A30614@openss7.org>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <9C48BA4E-7C94-4EF6-B2FD-3AD374552CF3@micmac.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] SCTP and ICMP Protocol Unreachable
Date: Wed, 20 Sep 2006 18:05:59 +0200
To: bidulock@openss7.org
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: sctp-impl@cisco.com, IETF Transport Area Mailing List <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Brian,

see my comment in-line.

Best regards
Michael

On Sep 20, 2006, at 1:51 PM, Brian F. G. Bidulock wrote:

> Stephane,
>
> Stephane Chazelas wrote:                  (Wed, 20 Sep 2006 10:40:32)
>>
>> There has to be another explanation. Would you be so kind as to
>> point me to where to find those examples you were refering to,
>> please?
>
> Section 5.3. of:
>   http://www.ietf.org/internet-drafts/draft-ietf-tsvwg- 
> sctpthreat-00.txt
>
> With the new requirements to validate addresses with a nonce-HB before
> sending to them, most of the destination address list spoofing attacks
> are defeated.
>
> Also, not sending to a destination (putting it on a permanent black  
> list
> for the association and not even sending heartbeats) after  
> receiving the
> ICMP serves to defeat the attack equally well to aborting the
> association.  (Not to mention that we won't even send other than INIT
> or HB chunks to a non-SCTP aware host any more and nonce-HB is very
> restricted and avoids amplification.)
The idea with the text in () is problematic. An host might support SCTP
at given points of time. Only after a kernel extension is loaded or
when a userland implementation is running. So putting it in a permanent
black list does not allow starting SCTP on hosts...
>
> I agree with you: an SCTP implementation should be allowed to  
> strike the
> destination instead of the association, thus bypassing busted middle
> boxes, but I think that it MUST strike the destination to avoid  
> hackers
> bypassing a given nonce-HB implementation.
>
> --brian
>
> -- 
> Brian F. G. Bidulock
> bidulock@openss7.org
> http://www.openss7.org/
>