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

[ash kat <[e-mail]>]

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:
  =======
  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.  
   
   
   
  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 <[e-mail]> wrote:
  ash kat wrote:
> 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.
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 815-342-5222(cell)


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