Subject: [Tsvwg] ambiguity in handling invalid cookie in COOKIE ECHO chunks

From: ash kat <[email-masked]>
Date: Thu, 20 Apr 2006 22:28:15 -0700 (PDT)

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.

---

From: Randall Stewart <[email-masked]>
Date: Fri, 21 Apr 2006 08:52:29 -0400

>     Please help me resolving this conflict.
K. Ash:

Here I disagree with you..

In the case of a COOKIE that has been modified, the integrity
check will fail... i.e. most likely you are being attacked... In this
case, the only logical thing to do is silently discard the packet.

In the case of being short on resources... or NOT having a listener then
it really helps if an ABORT is sent back.... i.e. if an innocent
guy trys to do 'sftp xxx.com' (where sftp is an SCTP based ftp)... it is
nice if an ABORT comes back instead of him hanging around waiting for
INIT time-outs... but some, for security reasons, don't like the idea
of giving clues or hints...

These are two different classes of problems... IMO.. and thus they
are not in conflict.. they would be in conflict if you can site
two places that have the SAME thing that tell you to do different
things... i.e. if the two places that mention a corrupted cookie, not
passing the security check, told you to in one place abort and in
the other silently discard....

The document does not do that...

R

--
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: Mark Butler <[email-masked]>
Date: Fri, 21 Apr 2006 16:17:48 -0600

I agree that if the COOKIE ECHO is corrupt (as opposed to stale) it 
should be silently discarded.

The other conditions where one might ABORT could use some clarification. 
Notably in the case of lack of resources whether you should ABORT or 
discard depends on how long you expect the problem to last.  If 
indefinitely, then ABORT is the correct response.  However, if the 
problem is temporary, silently discarding the packet is much to be 
preferred. 

In the case of a full accept queue, the latter behavior should be 
standardized in the SCTP socket draft, so that connect(2) calls do not 
error out pre-maturely.

 - Mark B.

---

From: Randall Stewart <[email-masked]>
Date: Sat, 22 Apr 2006 10:07:10 -0400

> standardized in the SCTP socket draft, so that connect(2) calls do not 

I agree that in a full-q one-2-one model case you probably want
to silently discard the COOKIE and let the retransmission of the
cookie hopefully help you get the association established... for
BSD this is the default behavior.. but there IS a sysctl to turn
this into a abort response too... since there will be some
that want this..

And as to if you hit the system limit of associations (another
type of resource constraint) then you will get an abort ... since
that is unlikely to clear before your retransmission timer goes
off..

R

---

From: Mark Butler <[email-masked]>
Date: Sat, 22 Apr 2006 17:39:32 -0600

Randall Stewart wrote:

>> The other conditions where one might ABORT could use some 
>> clarification. Notably in the case of lack of resources whether you 
>> should ABORT or discard depends on how long you expect the problem to 
>> last.  If indefinitely, then ABORT is the correct response.  However, 
>> if the problem is temporary, silently discarding the packet is much 
>> to be preferred.
>> standardized in the SCTP socket draft, so that connect(2) calls do 
>> not error out pre-maturely.
>
>

The problem for using sysctls for stuff like this is the way 
applications are written is dependent on what behavior is assumed, such 
that you end up applications that cannot be installed on the same system 
as other applications, because they require incompatible behavior on the 
part of the SCTP stack, no matter what the sysctl option is set to.  
Consequently, whereever incompatible modes need to be supported, socket 
options should be used instead of system level options.

In the long run, I think it would be great to have control chunks that 
carried the following information:

1. Connect request has been queued.  Expected wait time (to COOKIE ACK) 
is x milliseconds.
2. Unable to queue request due to lack of resources. Retry again in x 
milliseconds.

 - Mark B.

---

From: ash kat <[email-masked]>
Date: Mon, 24 Apr 2006 04:32:24 -0700 (PDT)

Hi
   
  Thanks for your response.
   
  I agree with you that the above section 5.1 deals with the lack of resources but it also says about the invalid parameter value. 
   
  However, there is still an ambiguity in section 4 and modified section 5.1 (section 2.47 of draft-ietf-tsvwg-sctpimpguide-16). Both deal with the handling of “invalid cookie (parameter) value in the COOKIE ECHO chunk”, but suggest different actions for the same.
   
  Section 4:
  =======
      discard the packet.  

  Modified section 5.1 (section 2.47 of draft-ietf-tsvwg-sctpimpguide-16)
  ==================================================
        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.
   
  Please note that, in case the corrupted cookie in COOKIE ECHO chunk it will be treated as the invalid parameter value. Hence the line 
  ****invalid parameter values,**** of the above section 5.1 creates ambiguity.
   
  --K.  Äsh

Randall Stewart <[email-masked]> wrote:
K. Ash:

R

--
Randall Stewart
803-345-0369 815-342-5222(cell)

---------------------------------
Celebrate Earth Day everyday!  Discover 10 things you can do to help slow climate change. Yahoo! Earth Day

---

From: Randall Stewart <[email-masked]>
Date: Tue, 25 Apr 2006 10:07:02 -0400

Ahh.. now I see your point .. sorry I missed it
before... :-D

Basically this is EXACTLY the type of thing we need
to find when I get the next rev of the BIS out... (as soon
as RFC 4460 issues).. Places where we changed X (in this
case 5.1) but we forgot to change Y (in this case 4).

I will add this to the "oversight" list of the I-G.. good catch!!

R