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

[Randall Stewart <[e-mail]>]

Ash:

As I work on getting the changes into the BIS... I had
a closer look at this.. and have an observation or two ..

1) The section in 4 that you refer to has to do with
    dealing with invalid parameters (you highlighted this).

2) A cookie echo is NOT a parameter.

I don't know if that is an ambiguity or not.. so
I will add the following right below the paragraph
you point out, it now reads (including your paragraph
for context):


"
<t>
    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. 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.
</t>
<t>
Note that a COOKIE ECHO chunk that does NOT pass the integrity check
is NOT considered an 'invalid parameter' and requires special handling
see <xref target="5.1"/>
</t>

"

This new paragraph will point someone to the right section for
handling the integrity check failure :-D

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)