IETF Logo Mail Archive

Re: [Tsvwg] SCTP and ICMP Protocol Unreachable

"Brian F. G. Bidulock" <bidulock@openss7.org> Wed, 20 September 2006 11:51 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ0cB-0008Mz-P2; Wed, 20 Sep 2006 07:51:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ0c9-0008Mo-La for tsvwg@ietf.org; Wed, 20 Sep 2006 07:51:41 -0400
Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ0c5-0002Fa-7H for tsvwg@ietf.org; Wed, 20 Sep 2006 07:51:41 -0400
Received: from ns.pigworks.openss7.net (IDENT:JZ38F6k0P1WTzQJYgLsKSl2TRzmoXsdP@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k8KBpaD19951; Wed, 20 Sep 2006 05:51:36 -0600
Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k8KBpZO31113; Wed, 20 Sep 2006 05:51:35 -0600
Date: Wed, 20 Sep 2006 05:51:35 -0600
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: Michael Tuexen <Michael.Tuexen@micmac.franken.de>, sctp-impl@cisco.com, IETF Transport Area Mailing List <tsvwg@ietf.org>
Subject: Re: [Tsvwg] SCTP and ICMP Protocol Unreachable
Message-ID: <20060920055135.A30614@openss7.org>
Mail-Followup-To: Michael Tuexen <Michael.Tuexen@micmac.franken.de>, sctp-impl@cisco.com, IETF Transport Area Mailing List <tsvwg@ietf.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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20060920094032.GA28221@artesyncp.com>; from Stephane@artesyncp.com on Wed, Sep 20, 2006 at 10:40:32AM +0100
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc:
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: bidulock@openss7.org
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

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.)

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/

v2.23.0 | Report a Bug | By Email