2.34.3. Solution Description
The solution to this problem is not to use the real Verification Tags
within the State Cookie as tie-tags. Instead, two 32-bit random
numbers are created to form one 64-bit nonce and stored both in the
State Cookie and the existing association TCB. This prevents
exposing the Verification Tags inadvertently.
2.35. Port Number Verification in the COOKIE-ECHO
2.35.1. Description of the Problem
The State Cookie sent by a listening SCTP endpoint may not contain
the original port numbers or the local Verification Tag. It is then
possible that the endpoint, on receipt of the COOKIE-ECHO, will not
be able to verify that these values match the original values found
in the INIT and INIT-ACK that began the association setup.
2.35.2. Text Changes to the Document
---------
Old text: (Section 5.1.5)
---------
3) Compare the creation timestamp in the State Cookie to the
current local time. If the elapsed time is longer than the
lifespan carried in the State Cookie, then the packet,
including the COOKIE ECHO and any attached DATA chunks,
SHOULD be discarded and the endpoint MUST transmit an ERROR
chunk with a "Stale Cookie" error cause to the peer endpoint,
4) If the State Cookie is valid, create an association to the
sender of the COOKIE ECHO chunk with the information in the
TCB data carried in the COOKIE ECHO, and enter the
ESTABLISHED state,
5) Send a COOKIE ACK chunk to the peer acknowledging reception
of the COOKIE ECHO. The COOKIE ACK MAY be bundled with an
outbound DATA chunk or SACK chunk; however, the COOKIE ACK
MUST be the first chunk in the SCTP packet.
6) Immediately acknowledge any DATA chunk bundled with the COOKIE
ECHO with a SACK (subsequent DATA chunk acknowledgement should
follow the rules defined in Section 6.2). As mentioned in step
5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
MUST appear first in the SCTP packet.
---------
New text: (Section 5.1.5)
---------
3) Compare the port numbers and the Verification Tag contained
within the COOKIE ECHO chunk to the actual port numbers and the
Verification Tag within the SCTP common header of the received
packet. If these values do not match, the packet MUST be
silently discarded.
4) Compare the creation timestamp in the State Cookie to the
current local time. If the elapsed time is longer than the
lifespan carried in the State Cookie, then the packet,
including the COOKIE ECHO and any attached DATA chunks,
SHOULD be discarded, and the endpoint MUST transmit an
ERROR chunk with a "Stale Cookie" error cause to the peer
endpoint.
5) If the State Cookie is valid, create an association to the
sender of the COOKIE ECHO chunk with the information in the
TCB data carried in the COOKIE ECHO and enter the
ESTABLISHED state.
6) Send a COOKIE ACK chunk to the peer acknowledging receipt of
the COOKIE ECHO. The COOKIE ACK MAY be bundled with an
outbound DATA chunk or SACK chunk; however, the COOKIE ACK
MUST be the first chunk in the SCTP packet.
7) Immediately acknowledge any DATA chunk bundled with the COOKIE
ECHO with a SACK (subsequent DATA chunk acknowledgement should
follow the rules defined in Section 6.2). As mentioned in step
5, if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
MUST appear first in the SCTP packet.
2.35.3. Solution Description
By including both port numbers and the local Verification Tag within
the State Cookie and verifying these during COOKIE-ECHO processing,
this issue is resolved.
2.36. Path Initialization
2.36.1. Description of the Problem
When an association enters the ESTABLISHED state, the endpoint has no
verification that all of the addresses presented by the peer do in
fact belong to the peer. This could cause various forms of denial of
service attacks.
2.36.2. Text Changes to the Document
---------
Old text: None
---------
---------
New text: (Section 5.4)
---------
5.4. Path Verification
During association establishment, the two peers exchange a list of
addresses. In the predominant case, these lists accurately represent
the addresses owned by each peer. However, it is possible that a
misbehaving peer may supply addresses that it does not own. To
prevent this, the following rules are applied to all addresses of the
new association:
1) Any address passed to the sender of the INIT by its upper layer is
automatically considered to be CONFIRMED.
2) For the receiver of the COOKIE-ECHO the only CONFIRMED address is
the one that the INIT-ACK was sent to.
3) All other addresses not covered by rules 1 and 2 are considered
UNCONFIRMED and are subject to probing for verification.
To probe an address for verification, an endpoint will send
HEARTBEATs including a 64-bit random nonce and a path indicator (to
identify the address that the HEARTBEAT is sent to) within the
HEARTBEAT parameter.
Upon receipt of the HEARTBEAT-ACK, a verification is made that the
nonce included in the HEARTBEAT parameter is the one sent to the
address indicated inside the HEARTBEAT parameter. When this match
occurs, the address that the original HEARTBEAT was sent to is now
considered CONFIRMED and available for normal data transfer.
These probing procedures are started when an association moves to the
ESTABLISHED state and are ended when all paths are confirmed.
Each RTO a probe may be sent on an active UNCONFIRMED path in an
attempt to move it to the CONFIRMED state. If during this probing
the path becomes inactive, this rate is lowered to the normal
HEARTBEAT rate. At the expiration of the RTO timer, the error
counter of any path that was probed but not CONFIRMED is incremented
by one and subjected to path failure detection, as defined in section
8.2. When probing UNCONFIRMED addresses, however, the association
overall error count is NOT incremented.
The number of HEARTBEATS sent at each RTO SHOULD be limited by the
HB.Max.Burst parameter. It is an implementation decision as to how
to distribute HEARTBEATS to the peer’s addresses for path
verification.
Whenever a path is confirmed, an indication MAY be given to the upper
layer.
An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with
the following exceptions:
- A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED
address.
- A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address.
- A COOKIE-ACK MAY be sent to an UNCONFIRMED address, but it MUST be
bundled with a HEARTBEAT including a nonce. An implementation that
does NOT support bundling MUST NOT send a COOKIE-ACK to an
UNCONFIRMED address.
- A COOKE-ECHO MAY be sent to an UNCONFIRMED address, but it MUST be
bundled with a HEARTBEAT including a nonce, and the packet MUST NOT
exceed the path MTU. If the implementation does NOT support
bundling or if the bundled COOKIE-ECHO plus HEARTBEAT (including
nonce) would exceed the path MTU, then the implementation MUST NOT
send a COOKIE-ECHO to an UNCONFIRMED address.
---------
Old text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
---------
New text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.Interval - 30 seconds
HB.Max.Burst - 1
2.36.3. Solution Description
By properly setting up initial path state and accelerated probing via
HEARTBEAT’s, a new association can verify that all addresses
presented by a peer belong to that peer.
2.37. ICMP Handling Procedures
2.37.1. Description of the Problem
RFC 2960 does not describe how ICMP messages should be processed by
an SCTP endpoint.
2.37.2. Text Changes to the Document
--------
Old text: None
--------
---------
New text
---------
11.5. Protection of Non-SCTP Capable Hosts.
To provide a non-SCTP capable host with the same level of protection
against attacks as for SCTP-capable ones, all SCTP stacks MUST
implement the ICMP handling described in Appendix C.
When an SCTP stack receives a packet containing multiple control or
DATA chunks and the processing of the packet requires the sending of
multiple chunks in response, the sender of the response chunk(s) MUST
NOT send more than one packet. If bundling is supported, multiple
response chunks that fit into a single packet MAY be bundled together
into one single response packet. If bundling is not supported, then
the sender MUST NOT send more than one response chunk and MUST
discard all other responses. Note that this rule does NOT apply to a
SACK chunk, since a SACK chunk is, in itself, a response to DATA and
a SACK does not require a response of more DATA.
An SCTP implementation SHOULD abort the association if it receives a
SACK acknowledging a TSN that has not been sent.
An SCTP implementation that receives an INIT that would require a
large packet in response, due to the inclusion of multiple ERROR
parameters, MAY (at its discretion) elect to omit some or all of the
ERROR parameters to reduce the size of the INIT-ACK. Due to a
combination of the size of the COOKIE parameter and the number of
addresses a receiver of an INIT may be indicating to a peer, it is
always possible that the INIT-ACK will be larger than the original
INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as
small as possible to reduce the possibility of byte amplification
attacks.
---------
Old text: None
---------
---------
New text: (Appendix C)
---------
Appendix C ICMP Handling
Whenever an ICMP message is received by an SCTP endpoint the
following procedures MUST be followed to ensure proper utilization of
the information being provided by layer 3.
ICMP1) An implementation MAY ignore all ICMPv4 messages where the
type field is not set to "Destination Unreachable".
ICMP2) An implementation MAY ignore all ICMPv6 messages where the
type field is not "Destination Unreachable, "Parameter
Problem" or "Packet Too Big".
ICMP3) An implementation MAY ignore any ICMPv4 messages where the
code does not indicate "Protocol Unreachable" or
"Fragmentation Needed".
ICMP4) An implementation MAY ignore all ICMPv6 messages of type
"Parameter Problem" if the code is not "Unrecognized next
header type encountered".
ICMP5) An implementation MUST use the payload of the ICMP message (V4
or V6) to locate the association that sent the message that
ICMP is responding to. If the association cannot be found, an
implementation SHOULD ignore the ICMP message.
ICMP6) An implementation MUST validate that the Verification Tag
contained in the ICMP message matches the verification tag of
the peer. If the Verification Tag is not 0 and does NOT
match, discard the ICMP message. If it is 0 and the ICMP
message contains enough bytes to verify that the chunk type is
an INIT chunk and that the initiate tag matches the tag of the
peer, continue with ICMP7. If the ICMP message is too short
or the chunk type or the initiate tag does not match, silently
discard the packet.
ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4
"Fragmentation Needed", an implementation MAY process this
information as defined for PATH MTU discovery.
ICMP8) If the ICMP code is a "Unrecognized next header type
encountered" or a "Protocol Unreachable", an implementation
MUST treat this message as an abort with the T bit set if it
does not contain an INIT chunk. If it does contain an INIT
chunk and the association is in COOKIE-WAIT state, handle the
ICMP message like an ABORT.
ICMP9) If the ICMPv6 code is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter.
Note that these procedures differ from RFC 1122 [1] and from its
requirements for processing of port-unreachable messages and the
requirements that an implementation MUST abort associations in
response to a "protocol unreachable" message. Port unreachable
messages are not processed, since an implementation will send an
ABORT, not a port unreachable. The stricter handling of the
"protocol unreachable" message is due to security concerns for hosts
that do NOT support SCTP.
2.37.3. Solution Description
The new appendix now describes proper handling of ICMP messages in
conjunction with SCTP.
2.38. Checksum
2.38.1. Description of the problem
RFC 3309 [6] changes the SCTP checksum due to weaknesses in the
original Adler 32 checksum for small messages. This document, being
used as a guide for a cut and paste replacement to update RFC 2960,
thus also needs to incorporate the checksum changes. The idea is
that one could apply all changes found in this guide to a copy of RFC
2960 and have a "new" document that has ALL changes (including RFC
3309).
2.38.2. Text Changes to the Document
---------
Old text:
---------
6.8 Adler-32 Checksum Calculation
When sending an SCTP packet, the endpoint MUST strengthen the data
integrity of the transmission by including the Adler-32 checksum
value calculated on the packet, as described below.
After the packet is constructed (containing the SCTP common header
and one or more control or DATA chunks), the transmitter shall:
1) Fill in the proper Verification Tag in the SCTP common header
and initialize the checksum field to 0’s.
2) Calculate the Adler-32 checksum of the whole packet, including
the SCTP common header and all the chunks. Refer to
appendix B for details of the Adler-32 algorithm. And,
3) Put the resultant value into the checksum field in the common
header, and leave the rest of the bits unchanged.
When an SCTP packet is received, the receiver MUST first check the
Adler-32 checksum:
1) Store the received Adler-32 checksum value aside,
2) Replace the 32 bits of the checksum field in the received SCTP
packet with all ’0’s and calculate an Adler-32 checksum value
of the whole received packet. And,
3) Verify that the calculated Adler-32 checksum is the same as the
received Adler-32 checksum. If not, the receiver MUST treat
the packet as an invalid SCTP packet.
The default procedure for handling invalid SCTP packets is to
silently discard them.
---------
New text:
---------
6.8 CRC-32c Checksum Calculation
When sending an SCTP packet, the endpoint MUST strengthen the data
integrity of the transmission by including the CRC32c checksum
value calculated on the packet, as described below.
After the packet is constructed (containing the SCTP common header
and one or more control or DATA chunks), the transmitter MUST
1) fill in the proper Verification Tag in the SCTP common header
and initialize the checksum field to ’0’s,
2) calculate the CRC32c checksum of the whole packet, including
the SCTP common header and all the chunks (refer to
appendix B for details of the CRC32c algorithm); and
3) put the resultant value into the checksum field in the common
header, and leave the rest of the bits unchanged.
When an SCTP packet is received, the receiver MUST first check the
CRC32c checksum as follows:
1) Store the received CRC32c checksum value aside.
2) Replace the 32 bits of the checksum field in the received SCTP
packet with all ’0’s and calculate a CRC32c checksum value of
the whole received packet.
3) Verify that the calculated CRC32c checksum is the same as the
received CRC32c checksum. If it is not, the receiver MUST
treat the packet as an invalid SCTP packet.
The default procedure for handling invalid SCTP packets is to
silently discard them.
Any hardware implementation SHOULD be done in a way that is
verifiable by the software.
---------
Old text:
---------
Appendix B Alder 32 bit checksum calculation
The Adler-32 checksum calculation given in this appendix is
copied from [RFC1950].
Adler-32 is composed of two sums accumulated per byte: s1 is the
sum of all bytes, s2 is the sum of all s1 values. Both sums are
done modulo 65521. s1 is initialized to 1, s2 to zero. The
Adler-32 checksum is stored as s2*65536 + s1 in network byte
order.
The following C code computes the Adler-32 checksum of a data
buffer. It is written for clarity, not for speed. The sample
code is in the ANSI C programming language. Non C users may
find it easier to read with these hints:
& Bitwise AND operator.
>> Bitwise right shift operator. When applied to an
unsigned quantity, as here, right shift inserts zero bit(s)
at the left.
<< Bitwise left shift operator. Left shift inserts zero
bit(s) at the right.
++ "n++" increments the variable n.
% modulo operator: a % b is the remainder of a divided by b.
#define BASE 65521 /* largest prime smaller than 65536 */
/*
Update a running Adler-32 checksum with the bytes buf[0..len-1]
and return the updated checksum. The Adler-32 checksum should
be initialized to 1.
Usage example:
unsigned long adler = 1L;
while (read_buffer(buffer, length) != EOF) {
adler = update_adler32(adler, buffer, length);
}
if (adler != original_adler) error();
*/
unsigned long update_adler32(unsigned long adler,
unsigned char *buf, int len)
{
unsigned long s1 = adler & 0xffff;
unsigned long s2 = (adler >> 16) & 0xffff;
int n;
for (n = 0; n < len; n++) {
s1 = (s1 + buf[n]) % BASE;
s2 = (s2 + s1) % BASE;
}
return (s2 << 16) + s1;
}
/* Return the adler32 of the bytes buf[0..len-1] */
unsigned long adler32(unsigned char *buf, int len)
{
return update_adler32(1L, buf, len);
}
---------
New text:
---------
Appendix B CRC32c Checksum Calculation
We define a ’reflected value’ as one that is the opposite of the
normal bit order of the machine. The 32-bit CRC is calculated as
described for CRC-32c and uses the polynomial code 0x11EDC6F41
(Castagnoli93) or x^32+x^28+x^27+x^26+x^25
+x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0.
The CRC is computed using a procedure similar to ETHERNET CRC
[ITU32], modified to reflect transport level usage.
CRC computation uses polynomial division. A message
bit-string M is transformed to a polynomial, M(X), and the CRC
is calculated from M(X) using polynomial arithmetic [PETERSON 72].
When CRCs are used at the link layer, the polynomial is derived
from on-the-wire bit ordering: the first bit ’on the wire’ is the
high-order coefficient. Since SCTP is a transport-level protocol,
it cannot know the actual serial-media bit ordering. Moreover,
different links in the path between SCTP endpoints may use
different link-level bit orders.
A convention must therefore be established for mapping SCTP
transport messages to polynomials for purposes of CRC computation.
The bit-ordering for mapping SCTP messages to polynomials is that
bytes are taken most-significant first; but within each byte, bits
are taken least-significant first. The first byte of the message
provides the eight highest coefficients. Within each byte,
the least-significant SCTP bit gives the most significant
polynomial coefficient within that byte, and the most-significant
SCTP bit is the least significant polynomial coefficient in that
byte. (This bit ordering is sometimes called ’mirrored’ or
’reflected’ [WILLIAMS93].) CRC polynomials are to be transformed
back into SCTP transport-level byte values, using a consistent
mapping.
The SCTP transport-level CRC value should be calculated as
follows:
- CRC input data are assigned to a byte stream, numbered from