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

[Randall Stewart <[e-mail]>]

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

ash kat wrote:
> 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


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