Subject: Initiate Tag with value "0" receive in INIT/INIT_ACK chunk

From: [email-masked] (Antonio Alonso Alarcon ECE/TL/NA TU-148 Tlf.3085)
Date: Thu, 22 Mar 2001 10:51:33 +0100 (MET)

Hi !

 In section 3.3.2 (RFC 2960), page 25 (INIT chunk), it is 
specified that:

  "The Initiate Tag is allowed to have any value except 0.  See
   Section 5.3.1 for more on the selection of the tag value.
   If the value of the Initiate Tag in a received INIT chunk is found
   to be 0, the receiver MUST treat it as an error and close the
   association by transmitting an ABORT."

NOTE: For INIT_ACK chunk we have more or less the same text

 In section 5.1, page 53, we have the following:

  "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."

 But if the Inititate tage value is "0", the ABORT that is sent to the
peer (the one who sent the wrong INIT or INIT_ACK chunk) is coded
with a Verification Tag (in SCTP header) with value "0", so it will be
discarded (as only INIT chunks can be received with VT=0).

  What is the right solution ? We can not allow ABORT chunks with
VT=0 (it would introduce a "security" hole during the Re-start procedure)
but I think that in the wrong INIT chunk case the peer should found
the way to notify the "wrong INITIATE TAG" value to the client (i.e the
side which initiates the establishmnet procedure).

  Is it better not to answer to this wrong INIT ? (in this case the
client will retransmit the wrong INIT chunks as many times as specified
by "Max.Init.Retrans" parameter and then it will stop trying to
establish this assoc). 

Any solution ?

Regards / Antonio

P.D: I think that receiving an INIT_ACK with Init.Tag = 0 is not a
problem due to no answer to this chunk is needed (the server side
does not store any information about this assoc. establishment attempt
after sending the INIT_ACK, so it is not necessary to send and ABORT
chunk to it notifying the wrong value in Init.Tag parameter).

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Randall R. Stewart" <[email-masked]>
Date: Mon, 26 Mar 2001 09:45:56 -0600

> side which initiates the establishmnet procedure).
I think we have discussed this before.... 

You have A)

Side-Broken-A                                Side-Z

--------------------INIT(Tag=0)---------------->

<--------------------------ABORT(?)-------------

The question being what does the sane side Z send to the BROKEN
side A that sent out an INIT with a Tag=0?

The only choice is to send the Tag that was included
i.e. 0, and set the 'T' bit.

Now Broken side A will do one of two things..

A) Consider a 0 Tag as valid (after all it sent it) and
   thus validate 0 in the ABORT against the association
   and thus clean up state.

or

B) Consider a 0 invalid and discard it...

If Case A) happens I seen no problem the broken side 
cleans up state. If case B) happens you are no worse
off than if you had just discarded the INIT.

I fail to see how this could be a security problem. Remember the 
T bit is set to indicate it is YOUR tag... Always the Tag check
must be done before you accept an abort and if the tag is invalid
you never send an abort to an abort... you silently discard.

R

> You are currently subscribed to sigtran as: [email-masked]

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)

---