Subject: Re: [Tsvwg] INIT Collision

From: Brian Tatum <[email-masked]>
Date: Thu, 27 Jul 2006 08:15:26 -0500

I believe this to be a SCTP protocol issue.  I want to make sure that I 
understand this issue from RFC 2960's perspective.

Section 3.3.7 Abort Association (ABORT) (6):
The T bit is set to 0 if the sender had a TCB that it destroyed.
If the sender did not have a TCB it should set this bit to 1.

Section 5.3.1 Selection of Tag Value
A new Verification Tag value MUST be used each time the
endpoint tears-down and then re-establishes an association to the
same peer.

In this case, endpoint A aborted the association when it received an 
INIT with an initiate tag of zero.  Endpoint A indicated that the TCB 
was destroyed by setting the T bit to zero in the ABORT.  When endpoint 
A sends the next INIT message to establish an association, it uses the 
same initiate tag that it did on the previous INIT attempt even though 
we destroyed the TCB.  From my interpretation of section 5.3.1, the 
destruction of the TCB is the same as a tear-down of an association.

Why would a new initiate tag not need to be sent in the INIT from 
endpoint A?

If the T bit was set to 1 in the ABORT could the same initiate tag be 
used in the INIT from endpoint A?

>Hi Bhanu,
>
>
>yes, the left side can resend the INIT with the old init-tag 'x'.
>
>
>Best regards
>Michael
>
>
>On Jul 25, 2006, at 11:38 AM, Bhanu Prakash wrote:
>
>
>Please consider the case mentioned below.
>
>
>     | end point A | ---------INIT (Init tag 'x')---------> | endpoint B|
>
>     | endpoint A | <--------INIT (Init tag 0) -------- |end pointB|
>
>     | endpoint A | ------ABORT (T Bit set to 0)---> | endpoint B|
>
>     | end point A | ---------INIT (Init tag 'x')---------> | endpoint B|
>
>     As per this sequence, on receiving INIT with InitTag set to zero,
>     end point A sends Abort with "T" bit set to zero and again tries
>     to initiate the association by sending INIT (but with same
>     InitTag). Is it correct to reuse the InitTag?
>
>thanks,
>Bhanu
>    
>
>  
>
>
>  
>

-- 
Brian Tatum       (972)519-2781          E-mail: [email-masked]
Alcatel USA, Inc.  3400 West Plano Parkway, MS SWPRO, Plano, Texas 75075
******* Alcatel is not responsible for any opinions stated here. *******

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 27 Jul 2006 09:17:31 -0600

Brian,

Well, no.  See RFC 4460 Section 2.23.

The ABORT, I take it, has a zero verification tag in accordance with 2.23
(i.e. it MUST be set to the initiate tag of the iNIT).  This indicates
that it was the TCB with peer verification tag 0 that was destroyed, not
the TCB with local verification tag x which remains in the COOKIE-WAIT
state.  The second INIT with vtag x is just the retransmission of the
INIT from the COOKIE-WAIT state when the timer expires upon no INIT-ACK.
I don't see anything abnormal with this behaviour.

--brian

Brian Tatum wrote:                             (Thu, 27 Jul 2006 08:15:26)
> 
>    I  believe this to be a SCTP protocol issue.  I want to make sure that
>    I understand this issue from RFC 2960's perspective.
>    was  destroyed  by  setting  the  T  bit  to  zero in the ABORT.  When
>    endpoint A sends the next INIT message to establish an association, it
>    uses  the  same  initiate tag that it did on the previous INIT attempt
>    even  though  we destroyed the TCB.  From my interpretation of section
>    5.3.1,  the  destruction  of  the TCB is the same as a tear-down of an
>    association.

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/