[Tsvwg] ambiguity in handling invalid cookie in COOKIE ECHO chunks
ash kat <ashwani_groups@yahoo.com> Fri, 21 April 2006 05:28 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWoBm-00042N-W8; Fri, 21 Apr 2006 01:28:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWoBl-00042I-A2 for tsvwg@ietf.org; Fri, 21 Apr 2006 01:28:17 -0400
Received: from web37407.mail.mud.yahoo.com ([209.191.87.60]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWoBk-00007B-Dl for tsvwg@ietf.org; Fri, 21 Apr 2006 01:28:17 -0400
Received: (qmail 1730 invoked by uid 60001); 21 Apr 2006 05:28:15 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=x8PrgGEH0WOJWK05UwNuXTiErIuwBa4zQ9CB/tSZsOJJgj/S+KZNFqBOVTSxzeka0nzbw4W1+kawDB1b45NCaP5Zb76hRTVtygY8YO1GsmyQgHXhQHZYBEY7sQPH5d7cPVYs3l+C+X/oseurR5ywbfKHC3y3APdya9FCmGwco7k= ;
Message-ID: <20060421052815.1728.qmail@web37407.mail.mud.yahoo.com>
Received: from [203.145.132.100] by web37407.mail.mud.yahoo.com via HTTP; Thu, 20 Apr 2006 22:28:15 PDT
Date: Thu, 20 Apr 2006 22:28:15 -0700
From: ash kat <ashwani_groups@yahoo.com>
To: tsvwg@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1310778812-1145597295=:98111"
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Subject: [Tsvwg] ambiguity in handling invalid cookie in COOKIE ECHO chunks
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
Hi All I was looking at the behavior of SCTP stack when the COOKIE ECHO chunk contains the invalid cookie. The following section of RFC2960 are conflicting each other: Section 4 (Page# 50) Notes: 1) If the State Cookie in the received COOKIE ECHO is invalid (i.e., failed to pass the integrity check), the receiver MUST silently discard the packet. Or, if the received State Cookie is expired (see Section 5.1.5), the receiver MUST send back an ERROR chunk. In either case, the receiver stays in the CLOSED state. Section 5.1 (Page# 52) If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it MUST respond with an ABORT chunk. It SHOULD also specify the cause of abort, such as the type of the missing mandatory parameters, etc., by including the error cause parameters with the ABORT chunk. The Verification Tag field in the common header of the outbound SCTP packet containing the ABORT chunk MUST be set to the Initiate Tag value of the peer. Section 5.1.5 (Page# 56) 2) Authenticate the State Cookie as one that it previously generated by comparing the computed MAC against the one carried in the State Cookie. If this comparison fails, the SCTP packet, including the COOKIE ECHO and any DATA chunks, should be silently discarded. While section 2.47 of draft-ietf-tsvwg-sctpimpguide-16 has some modifications on this: 2.47. Sending of ABORT chunks 2.47.1. Description of the problem Section 5.1 of RFC2960 [7] requires that an ABORT chunk is sent in response to an INIT chunk when there is no listening end point. To make port scanning harder someone might not want these ABORTs to be received by the sender of the INIT chunks. Currently the only way to enforce this is by using a firewall discarding the packets containing the INIT chunks or the packets containing the ABORT chunks. It is desirable that the same can be done without a middle box. 2.47.2. Text changes to the document --------- Old text: (Section 5.1) --------- If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it MUST respond with an ABORT chunk. --------- New text: (Section 5.1) --------- If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it SHOULD respond with an ABORT chunk. But still the conflict is there. In my point of view there should be only one of these three actions, which should be specified when the SCTP receive the COOKIE ECHO chunk with an invalid cookie. i) MUST silently discard (section 4 of RFC2960) ii) SHOULD respond with an ABORT (section 2.47 of draft-ietf-tsvwg-sctpimpguide-16) iii) should be silently discarded. (section 5.1.5 of RFC2960) Please help me resolving this conflict. -K. Äsh --------------------------------------------------------------------------------------- Sooner or later, those who win are those who think they can. --------------------------------------------------------------------------------------- --------------------------------- How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates.
- [Tsvwg] ambiguity in handling invalid cookie in C… ash kat
- Re: [Tsvwg] ambiguity in handling invalid cookie … Randall Stewart
- Re: [Tsvwg] ambiguity in handling invalid cookie … Mark Butler
- Re: [Tsvwg] ambiguity in handling invalid cookie … Randall Stewart
- Re: [Tsvwg] ambiguity in handling invalid cookie … Mark Butler
- Re: [Tsvwg] ambiguity in handling invalid cookie … ash kat
- Re: [Tsvwg] ambiguity in handling invalid cookie … Randall Stewart
- Re: [Tsvwg] ambiguity in handling invalid cookie … Randall Stewart