/ I-Tag=Tag_Z,
(Cancel T1-init timer) <-----/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
/ TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=1 & user data 1]
SACK [TSN Ack=init TSN_Z, / ---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=2 & user data 2]
<------/\
\
\------>
Figure 4: INITiation Example
---------
New text: (Section 7.2.1)
---------
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] ------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
/ TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=0 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=1 & user data 2]
<------/\
\
\------>
Figure 4: INITiation Example
---------
Old text: (Section 5.2.4.1)
---------
Endpoint A Endpoint Z
<------------ Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A’
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find a existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A’,
/ I-Tag=Tag_Z’,
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z’,
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match i.e.,
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE-ACK
(Cancel T1-init timer, <------/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/--- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Figure 5: A Restart Example
---------
New text: (Section 5.2.4.1)
---------
Endpoint A Endpoint Z
<-------------- Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<--------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A’
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find a existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A’,
/ I-Tag=Tag_Z’,
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z’,
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match i.e.,
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE-ACK
(Cancel T1-init timer, <------/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/--- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Figure 5: A Restart Example
2.31.3. Solution description
Figure 4 and 5 were changed so that the SSN starts with 0 instead of
1.
2.32. Unrecognized Parameters
2.32.1. Description of the Problem
The RFC does not state clearly in Section 3.3.3.1 whether one or
multiple unrecognized parameters are included in the ’Unrecognized
Parameter’ parameter.
2.32.2. Text Changes to the Document
---------
Old text: (Section 3.3.3)
---------
Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameters Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
---------
New text: (Section 3.3.3)
---------
Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameter Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
---------
Old text: (Section 3.3.3.1)
---------
Unrecognized Parameters:
Parameter Type Value: 8
Parameter Length: Variable Size.
Parameter Value:
This parameter is returned to the originator of the INIT
chunk when the INIT contains an unrecognized parameter
which has a value that indicates that it should be reported
to the sender. This parameter value field will contain
unrecognized parameters copied from the INIT chunk complete
with Parameter Type, Length and Value fields.
---------
New text: (Section 3.3.3.1)
---------
Unrecognized Parameter:
Parameter Type Value: 8
Parameter Length: Variable Size.
Parameter Value:
This parameter is returned to the originator of the INIT
chunk when the INIT contains an unrecognized parameter
that has a value that indicates that it should be reported
to the sender. This parameter value field will contain the
unrecognized parameter copied from the INIT chunk complete
with Parameter Type, Length, and Value fields.
2.32.3. Solution Description
The new text states clearly that only one unrecognized parameter is
reported per parameter.
2.33. Handling of Unrecognized Parameters
2.33.1. Description of the Problem
It is not stated clearly in RFC 2960 [5] how unrecognized parameters
should be handled. The problem comes up when an INIT contains an
unrecognized parameter with highest bits 00. It was not clear
whether an INIT-ACK should be sent.
2.33.2. Text Changes to the Document
Some of the changes given here already include changes suggested in
Section 2.27 of this document.
---------
Old text: (Section 3.2.1)
---------
00 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it.
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an ’Unrecognized Parameter Type’ (in either an
ERROR or in the INIT ACK).
10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an ’Unrecognized Parameter Type’ (in
either an ERROR or in the INIT ACK).
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this parameter; do not process
any further parameters within this chunk.
01 - Stop processing this parameter, do not process
any further parameters within this chunk, and report the
unrecognized parameter in an ’Unrecognized Parameter Type’, as
described in 3.2.2.
10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an ’Unrecognized Parameter Type’, as
described in 3.2.2.
---------
New text: (Note: no old text; clarification added in section 3.2)
---------
3.2.2. Reporting of Unrecognized Parameters
If the receiver of an INIT chunk detects unrecognized parameters and
has to report them according to Section 3.2.1, it MUST put the
’Unrecognized Parameter’ parameter(s) in the INIT-ACK chunk sent in
response to the INIT-chunk. Note that if the receiver of the INIT
chunk is NOT going to establish an association (e.g., due to lack of
resources), an ’Unrecognized Parameter’ would NOT be included with
any ABORT being sent to the sender of the INIT.
If the receiver of an INIT-ACK chunk detects unrecognized parameters
and has to report them according to Section 3.2.1, it SHOULD bundle
the ERROR chunk containing the ’Unrecognized Parameter’ error cause
with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk.
If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk
with the ERROR chunk, the ERROR chunk MAY be sent separately but not
before the COOKIE-ACK has been received.
Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the
first chunk.
2.33.3. Solution Description
The procedure of handling unrecognized parameters has been described
clearly.
2.34. Tie Tags
2.34.1. Description of the Problem
RFC 2960 requires that Tie-Tags be included in the COOKIE. The
cookie may not be encrypted. An attacker could discover the value of
the Verification Tags by analyzing cookies received after sending an
INIT.
2.34.2. Text Changes to the Document
---------
Old text: (Section 1.4)
---------
o Tie-Tags: Verification Tags from a previous association. These
Tags are used within a State Cookie so that the newly
restarting association can be linked to the original
association within the endpoint that did not restart.
---------
New text: (Section 1.4)
---------
o Tie-Tags: Two 32-bit random numbers that together make a 64-
bit nonce. These Tags are used within a State Cookie and TCB
so that a newly restarting association can be linked to the
original association within the endpoint that did not restart
and yet not reveal the true Verification Tags of an existing
association.
---------
Old text: (Section 5.2.1)
---------
For an endpoint that is in the COOKIE-ECHOED state it MUST
populate its Tie-Tags with the Tag information of itself and
its peer (see Section 5.2.2 for a description of the Tie-Tags).
---------
New text: (Section 5.2.1)
---------
For an endpoint that is in the COOKIE-ECHOED state it MUST
populate its Tie-Tags within both the association TCB and
inside the State Cookie (see section 5.2.2 for a description
of the Tie-Tags).
---------
Old text: (Section 5.2.2)
---------
Unless otherwise stated, upon reception of an unexpected INIT for
this association, the endpoint shall generate an INIT ACK with a
State Cookie. In the outbound INIT ACK the endpoint MUST copy its
current Verification Tag and peer’s Verification Tag into a
reserved place within the state cookie. We shall refer to these
locations as the Peer’s-Tie-Tag and the Local-Tie-Tag. The
outbound SCTP packet containing this INIT ACK MUST carry a
Verification Tag value equal to the Initiation Tag found in the
unexpected INIT. And the INIT ACK MUST contain a new Initiation
Tag (randomly generated see Section 5.3.1). Other parameters
for the endpoint SHOULD be copied from the existing parameters
of the association (e.g., number of outbound streams) into the
INIT ACK and cookie.
---------
New text: (Section 5.2.2)
---------
Unless otherwise stated, upon receipt of an unexpected INIT for
this association, the endpoint MUST generate an INIT ACK with a
State Cookie. In the outbound INIT ACK, the endpoint MUST copy
its current Tie-Tags to a reserved place within the State Cookie
and the association’s TCB. We shall refer to these locations
inside the cookie as the Peer’s-Tie-Tag and the Local-Tie-Tag. We
will refer to the copy within an association’s TCB as the Local
Tag and Peer’s Tag. The outbound SCTP packet containing this INIT
ACK MUST carry a Verification Tag value equal to the Initiation
Tag found in the unexpected INIT. And the INIT ACK MUST contain a
new Initiation Tag (randomly generated; see Section 5.3.1). Other
parameters for the endpoint SHOULD be copied from the existing
parameters of the association (e.g., number of outbound streams)
into the INIT ACK and cookie.