[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! Messenger’s low  PC-to-Phone call rates.