draft-ietf-tsvwg-2960bis-01.txt   draft-ietf-tsvwg-2960bis-02.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Editor Internet-Draft Editor
Expires: November 10, 2006 May 9, 2006 Expires: December 10, 2006 June 8, 2006
Stream Control Transmission Protocol Stream Control Transmission Protocol
draft-ietf-tsvwg-2960bis-01.txt draft-ietf-tsvwg-2960bis-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 10, 2006. This Internet-Draft will expire on December 10, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes the Stream Control Transmission Protocol This document describes the Stream Control Transmission Protocol
(SCTP). SCTP is designed to transport PSTN signaling messages over (SCTP). SCTP is designed to transport PSTN signaling messages over
IP networks, but is capable of broader applications. IP networks, but is capable of broader applications.
skipping to change at page 2, line 22 skipping to change at page 2, line 22
-- network-level fault tolerance through supporting of multi- homing -- network-level fault tolerance through supporting of multi- homing
at either or both ends of an association. at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior The design of SCTP includes appropriate congestion avoidance behavior
and resistance to flooding and masquerade attacks. and resistance to flooding and masquerade attacks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Architectural View of SCTP . . . . . . . . . . . . . . . 7 1.2. Architectural View of SCTP . . . . . . . . . . . . . . . 6
1.3. Functional View of SCTP . . . . . . . . . . . . . . . . . 8 1.3. Functional View of SCTP . . . . . . . . . . . . . . . . . 7
1.3.1. Association Startup and Takedown . . . . . . . . . . 9 1.3.1. Association Startup and Takedown . . . . . . . . . . 8
1.3.2. Sequenced Delivery within Streams . . . . . . . . . . 10 1.3.2. Sequenced Delivery within Streams . . . . . . . . . . 9
1.3.3. User Data Fragmentation . . . . . . . . . . . . . . . 10 1.3.3. User Data Fragmentation . . . . . . . . . . . . . . . 9
1.3.4. Acknowledgement and Congestion Avoidance . . . . . . 10 1.3.4. Acknowledgement and Congestion Avoidance . . . . . . 9
1.3.5. Chunk Bundling . . . . . . . . . . . . . . . . . . . 11 1.3.5. Chunk Bundling . . . . . . . . . . . . . . . . . . . 10
1.3.6. Packet Validation . . . . . . . . . . . . . . . . . . 11 1.3.6. Packet Validation . . . . . . . . . . . . . . . . . . 10
1.3.7. Path Management . . . . . . . . . . . . . . . . . . . 11 1.3.7. Path Management . . . . . . . . . . . . . . . . . . . 10
1.4. Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 12 1.4. Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 16 1.5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 15
1.6. Serial Number Arithmetic . . . . . . . . . . . . . . . . 16 1.6. Serial Number Arithmetic . . . . . . . . . . . . . . . . 15
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 17 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 16
3. SCTP packet Format . . . . . . . . . . . . . . . . . . . . . 17 3. SCTP packet Format . . . . . . . . . . . . . . . . . . . . . 16
3.1. SCTP Common Header Field Descriptions . . . . . . . . . . 18 3.1. SCTP Common Header Field Descriptions . . . . . . . . . . 17
3.2. Chunk Field Descriptions . . . . . . . . . . . . . . . . 19 3.2. Chunk Field Descriptions . . . . . . . . . . . . . . . . 18
3.2.1. Optional/Variable-length Parameter Format . . . . . . 21 3.2.1. Optional/Variable-length Parameter Format . . . . . . 20
3.2.2. Reporting of Unrecognized Parameters . . . . . . . . 23 3.2.2. Reporting of Unrecognized Parameters . . . . . . . . 22
3.3. SCTP Chunk Definitions . . . . . . . . . . . . . . . . . 24 3.3. SCTP Chunk Definitions . . . . . . . . . . . . . . . . . 23
3.3.1. Payload Data (DATA) (0) . . . . . . . . . . . . . . . 24 3.3.1. Payload Data (DATA) (0) . . . . . . . . . . . . . . . 23
3.3.2. Initiation (INIT) (1) . . . . . . . . . . . . . . . . 26 3.3.2. Initiation (INIT) (1) . . . . . . . . . . . . . . . . 25
3.3.3. Initiation Acknowledgement (INIT ACK) (2): . . . . . 32 3.3.3. Initiation Acknowledgement (INIT ACK) (2): . . . . . 31
3.3.4. Selective Acknowledgement (SACK) (3): . . . . . . . . 36 3.3.4. Selective Acknowledgement (SACK) (3): . . . . . . . . 35
3.3.5. Heartbeat Request (HEARTBEAT) (4): . . . . . . . . . 40 3.3.5. Heartbeat Request (HEARTBEAT) (4): . . . . . . . . . 39
3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5): . . . 41 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5): . . . 40
3.3.7. Abort Association (ABORT) (6): . . . . . . . . . . . 41 3.3.7. Abort Association (ABORT) (6): . . . . . . . . . . . 40
3.3.8. Shutdown Association (SHUTDOWN) (7): . . . . . . . . 42 3.3.8. Shutdown Association (SHUTDOWN) (7): . . . . . . . . 41
3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8): . . . . 43 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8): . . . . 42
3.3.10. Operation Error (ERROR) (9): . . . . . . . . . . . . 44 3.3.10. Operation Error (ERROR) (9): . . . . . . . . . . . . 43
3.3.10.1. Invalid Stream Identifier (1) . . . . . . . . . 45 3.3.10.1. Invalid Stream Identifier (1) . . . . . . . . . 44
3.3.10.2. Missing Mandatory Parameter (2) . . . . . . . . 46 3.3.10.2. Missing Mandatory Parameter (2) . . . . . . . . 45
3.3.10.3. Stale Cookie Error (3) . . . . . . . . . . . . . 46 3.3.10.3. Stale Cookie Error (3) . . . . . . . . . . . . . 45
3.3.10.4. Out of Resource (4) . . . . . . . . . . . . . . 47 3.3.10.4. Out of Resource (4) . . . . . . . . . . . . . . 46
3.3.10.5. Unresolvable Address (5) . . . . . . . . . . . . 47 3.3.10.5. Unresolvable Address (5) . . . . . . . . . . . . 46
3.3.10.6. Unrecognized Chunk Type (6) . . . . . . . . . . 48 3.3.10.6. Unrecognized Chunk Type (6) . . . . . . . . . . 47
3.3.10.7. Invalid Mandatory Parameter (7) . . . . . . . . 48 3.3.10.7. Invalid Mandatory Parameter (7) . . . . . . . . 47
3.3.10.8. Unrecognized Parameters (8) . . . . . . . . . . 49 3.3.10.8. Unrecognized Parameters (8) . . . . . . . . . . 48
3.3.10.9. No User Data (9) . . . . . . . . . . . . . . . . 49 3.3.10.9. No User Data (9) . . . . . . . . . . . . . . . . 48
3.3.10.10. Cookie Received While Shutting Down (10) . . . . 50 3.3.10.10. Cookie Received While Shutting Down (10) . . . . 49
3.3.10.11. Restart of an Association with New Addresses 3.3.10.11. Restart of an Association with New Addresses
(11) . . . . . . . . . . . . . . . . . . . . . . 50 (11) . . . . . . . . . . . . . . . . . . . . . . 49
3.3.10.12. User-Initiated Abort (12) . . . . . . . . . . . 50 3.3.10.12. User-Initiated Abort (12) . . . . . . . . . . . 49
3.3.10.13. Protocol Violation (13) . . . . . . . . . . . . 51 3.3.10.13. Protocol Violation (13) . . . . . . . . . . . . 50
3.3.11. Cookie Echo (COOKIE ECHO) (10): . . . . . . . . . . . 51 3.3.11. Cookie Echo (COOKIE ECHO) (10): . . . . . . . . . . . 50
3.3.12. Cookie Acknowledgement (COOKIE ACK) (11): . . . . . . 52 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11): . . . . . . 51
3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14): . . . . . 53 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14): . . . . . 52
4. SCTP Association State Diagram . . . . . . . . . . . . . . . 53 4. SCTP Association State Diagram . . . . . . . . . . . . . . . 52
5. Association Initialization . . . . . . . . . . . . . . . . . 57 5. Association Initialization . . . . . . . . . . . . . . . . . 56
5.1. Normal Establishment of an Association . . . . . . . . . 57 5.1. Normal Establishment of an Association . . . . . . . . . 56
5.1.1. Handle Stream Parameters . . . . . . . . . . . . . . 59 5.1.1. Handle Stream Parameters . . . . . . . . . . . . . . 58
5.1.2. Handle Address Parameters . . . . . . . . . . . . . . 59 5.1.2. Handle Address Parameters . . . . . . . . . . . . . . 58
5.1.3. Generating State Cookie . . . . . . . . . . . . . . . 62 5.1.3. Generating State Cookie . . . . . . . . . . . . . . . 61
5.1.4. State Cookie Processing . . . . . . . . . . . . . . . 63 5.1.4. State Cookie Processing . . . . . . . . . . . . . . . 62
5.1.5. State Cookie Authentication . . . . . . . . . . . . . 63 5.1.5. State Cookie Authentication . . . . . . . . . . . . . 62
5.1.6. An Example of Normal Association Establishment . . . 64 5.1.6. An Example of Normal Association Establishment . . . 63
5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE 5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE
ECHO, and COOKIE ACK . . . . . . . . . . . . . . . . . . 66 ECHO, and COOKIE ACK . . . . . . . . . . . . . . . . . . 65
5.2.1. INIT received in COOKIE-WAIT or COOKIE-ECHOED 5.2.1. INIT received in COOKIE-WAIT or COOKIE-ECHOED
State (Item B) . . . . . . . . . . . . . . . . . . . 66 State (Item B) . . . . . . . . . . . . . . . . . . . 65
5.2.2. Unexpected INIT in States Other than CLOSED, 5.2.2. Unexpected INIT in States Other than CLOSED,
COOKIE-ECHOED,COOKIE-WAIT and SHUTDOWN-ACK-SENT . . . 67 COOKIE-ECHOED,COOKIE-WAIT and SHUTDOWN-ACK-SENT . . . 66
5.2.3. Unexpected INIT ACK . . . . . . . . . . . . . . . . . 68 5.2.3. Unexpected INIT ACK . . . . . . . . . . . . . . . . . 67
5.2.4. Handle a COOKIE ECHO when a TCB exists . . . . . . . 68 5.2.4. Handle a COOKIE ECHO when a TCB exists . . . . . . . 67
5.2.5. Handle Duplicate COOKIE-ACK. . . . . . . . . . . . . 72 5.2.5. Handle Duplicate COOKIE-ACK. . . . . . . . . . . . . 71
5.2.6. Handle Stale COOKIE Error . . . . . . . . . . . . . . 72 5.2.6. Handle Stale COOKIE Error . . . . . . . . . . . . . . 71
5.3. Other Initialization Issues . . . . . . . . . . . . . . . 72 5.3. Other Initialization Issues . . . . . . . . . . . . . . . 71
5.3.1. Selection of Tag Value . . . . . . . . . . . . . . . 72 5.3.1. Selection of Tag Value . . . . . . . . . . . . . . . 71
5.4. Path Verification . . . . . . . . . . . . . . . . . . . . 73 5.4. Path Verification . . . . . . . . . . . . . . . . . . . . 72
6. User Data Transfer . . . . . . . . . . . . . . . . . . . . . 74 6. User Data Transfer . . . . . . . . . . . . . . . . . . . . . 73
6.1. Transmission of DATA Chunks . . . . . . . . . . . . . . . 76 6.1. Transmission of DATA Chunks . . . . . . . . . . . . . . . 75
6.2. Acknowledgement on Reception of DATA Chunks . . . . . . . 78 6.2. Acknowledgement on Reception of DATA Chunks . . . . . . . 77
6.2.1. Processing a Received SACK . . . . . . . . . . . . . 81 6.2.1. Processing a Received SACK . . . . . . . . . . . . . 80
6.3. Management of Retransmission Timer . . . . . . . . . . . 83 6.3. Management of Retransmission Timer . . . . . . . . . . . 82
6.3.1. RTO Calculation . . . . . . . . . . . . . . . . . . . 83 6.3.1. RTO Calculation . . . . . . . . . . . . . . . . . . . 82
6.3.2. Retransmission Timer Rules . . . . . . . . . . . . . 84 6.3.2. Retransmission Timer Rules . . . . . . . . . . . . . 83
6.3.3. Handle T3-rtx Expiration . . . . . . . . . . . . . . 85 6.3.3. Handle T3-rtx Expiration . . . . . . . . . . . . . . 84
6.4. Multi-homed SCTP Endpoints . . . . . . . . . . . . . . . 86 6.4. Multi-homed SCTP Endpoints . . . . . . . . . . . . . . . 86
6.4.1. Failover from Inactive Destination Address . . . . . 87 6.4.1. Failover from Inactive Destination Address . . . . . 86
6.5. Stream Identifier and Stream Sequence Number . . . . . . 88 6.5. Stream Identifier and Stream Sequence Number . . . . . . 87
6.6. Ordered and Unordered Delivery . . . . . . . . . . . . . 88 6.6. Ordered and Unordered Delivery . . . . . . . . . . . . . 87
6.7. Report Gaps in Received DATA TSNs . . . . . . . . . . . . 89 6.7. Report Gaps in Received DATA TSNs . . . . . . . . . . . . 88
6.8. CRC-32c Checksum Calculation . . . . . . . . . . . . . . 90 6.8. CRC32c Checksum Calculation . . . . . . . . . . . . . . . 89
6.9. Fragmentation and Reassembly . . . . . . . . . . . . . . 91 6.9. Fragmentation and Reassembly . . . . . . . . . . . . . . 90
6.10. Bundling . . . . . . . . . . . . . . . . . . . . . . . . 92 6.10. Bundling . . . . . . . . . . . . . . . . . . . . . . . . 91
7. Congestion control . . . . . . . . . . . . . . . . . . . . . 93 7. Congestion control . . . . . . . . . . . . . . . . . . . . . 92
7.1. SCTP Differences from TCP Congestion control . . . . . . 94 7.1. SCTP Differences from TCP Congestion control . . . . . . 93
7.2. SCTP Slow-Start and Congestion Avoidance . . . . . . . . 95 7.2. SCTP Slow-Start and Congestion Avoidance . . . . . . . . 94
7.2.1. Slow-Start . . . . . . . . . . . . . . . . . . . . . 96 7.2.1. Slow-Start . . . . . . . . . . . . . . . . . . . . . 95
7.2.2. Congestion Avoidance . . . . . . . . . . . . . . . . 97 7.2.2. Congestion Avoidance . . . . . . . . . . . . . . . . 96
7.2.3. Congestion Control . . . . . . . . . . . . . . . . . 97 7.2.3. Congestion Control . . . . . . . . . . . . . . . . . 96
7.2.4. Fast Retransmit on Gap Reports . . . . . . . . . . . 98 7.2.4. Fast Retransmit on Gap Reports . . . . . . . . . . . 97
7.3. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 99 7.3. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 98
8. Fault Management . . . . . . . . . . . . . . . . . . . . . . 101 8. Fault Management . . . . . . . . . . . . . . . . . . . . . . 100
8.1. Endpoint Failure Detection . . . . . . . . . . . . . . . 101 8.1. Endpoint Failure Detection . . . . . . . . . . . . . . . 100
8.2. Path Failure Detection . . . . . . . . . . . . . . . . . 101 8.2. Path Failure Detection . . . . . . . . . . . . . . . . . 100
8.3. Path Heartbeat . . . . . . . . . . . . . . . . . . . . . 102 8.3. Path Heartbeat . . . . . . . . . . . . . . . . . . . . . 101
8.4. Handle "Out of the blue" Packets . . . . . . . . . . . . 104 8.4. Handle "Out of the blue" Packets . . . . . . . . . . . . 103
8.5. Verification Tag . . . . . . . . . . . . . . . . . . . . 105 8.5. Verification Tag . . . . . . . . . . . . . . . . . . . . 104
8.5.1. Exceptions in Verification Tag Rules . . . . . . . . 105 8.5.1. Exceptions in Verification Tag Rules . . . . . . . . 104
9. Termination of Association . . . . . . . . . . . . . . . . . 106 9. Termination of Association . . . . . . . . . . . . . . . . . 105
9.1. Abort of an Association . . . . . . . . . . . . . . . . . 107 9.1. Abort of an Association . . . . . . . . . . . . . . . . . 106
9.2. Shutdown of an Association . . . . . . . . . . . . . . . 107 9.2. Shutdown of an Association . . . . . . . . . . . . . . . 106
10. Interface with Upper Layer . . . . . . . . . . . . . . . . . 110 10. Interface with Upper Layer . . . . . . . . . . . . . . . . . 109
10.1. ULP-to-SCTP . . . . . . . . . . . . . . . . . . . . . . . 110 10.1. ULP-to-SCTP . . . . . . . . . . . . . . . . . . . . . . . 109
10.2. SCTP-to-ULP . . . . . . . . . . . . . . . . . . . . . . . 121 10.2. SCTP-to-ULP . . . . . . . . . . . . . . . . . . . . . . . 120
11. Security Considerations . . . . . . . . . . . . . . . . . . . 124 11. Security Considerations . . . . . . . . . . . . . . . . . . . 123
11.1. Security Objectives . . . . . . . . . . . . . . . . . . . 124 11.1. Security Objectives . . . . . . . . . . . . . . . . . . . 123
11.2. SCTP Responses To Potential Threats . . . . . . . . . . . 124 11.2. SCTP Responses To Potential Threats . . . . . . . . . . . 123
11.2.1. Countering Insider Attacks . . . . . . . . . . . . . 124 11.2.1. Countering Insider Attacks . . . . . . . . . . . . . 123
11.2.2. Protecting against Data Corruption in the Network . . 125 11.2.2. Protecting against Data Corruption in the Network . . 124
11.2.3. Protecting Confidentiality . . . . . . . . . . . . . 125 11.2.3. Protecting Confidentiality . . . . . . . . . . . . . 124
11.2.4. Protecting against Blind Denial of Service Attacks . 126 11.2.4. Protecting against Blind Denial of Service Attacks . 125
11.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 126 11.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 125
11.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 127 11.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 126
11.2.4.3. Improper Monopolization of Services . . . . . . 128 11.2.4.3. Improper Monopolization of Services . . . . . . 127
11.3. Protection against Fraud and Repudiation . . . . . . . . 128 11.3. Protection against Fraud and Repudiation . . . . . . . . 127
11.4. SCTP Interactions with Firewalls . . . . . . . . . . . . 129 11.4. SCTP Interactions with Firewalls . . . . . . . . . . . . 128
11.5. Protection of Non-SCTP Capable Hosts. . . . . . . . . . . 129 11.5. Protection of Non-SCTP Capable Hosts. . . . . . . . . . . 128
12. Recommended Transmission Control Block (TCB) Parameters . . . 130 12. Recommended Transmission Control Block (TCB) Parameters . . . 129
12.1. Parameters necessary for the SCTP instance . . . . . . . 131 12.1. Parameters necessary for the SCTP instance . . . . . . . 130
12.2. Parameters necessary per association (i.e. the TCB) . . . 131 12.2. Parameters necessary per association (i.e. the TCB) . . . 130
12.3. Per Transport Address Data . . . . . . . . . . . . . . . 133 12.3. Per Transport Address Data . . . . . . . . . . . . . . . 132
12.4. General Parameters Needed . . . . . . . . . . . . . . . . 134 12.4. General Parameters Needed . . . . . . . . . . . . . . . . 133
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 134 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 133
13.1. IETF-defined Chunk Extension . . . . . . . . . . . . . . 135 13.1. IETF-defined Chunk Extension . . . . . . . . . . . . . . 134
13.2. IETF-defined Chunk Parameter Extension . . . . . . . . . 135 13.2. IETF-defined Chunk Parameter Extension . . . . . . . . . 134
13.3. IETF-defined Additional Error Causes . . . . . . . . . . 136 13.3. IETF-defined Additional Error Causes . . . . . . . . . . 135
13.4. Payload Protocol Identifiers . . . . . . . . . . . . . . 136 13.4. Payload Protocol Identifiers . . . . . . . . . . . . . . 135
14. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 136 14. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 135
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 137 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 136
Appendix A. Explicit Congestion Notification . . . . . . . . . . 137 Appendix A. Explicit Congestion Notification . . . . . . . . . . 137
Appendix B. CRC32c Checksum Calculation . . . . . . . . . . . . 139 Appendix B. CRC32c Checksum Calculation . . . . . . . . . . . . 139
Appendix C. ICMP Handling . . . . . . . . . . . . . . . . . . . 141 Appendix C. ICMP Handling . . . . . . . . . . . . . . . . . . . 140
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 142 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 147
16.1. Normative references . . . . . . . . . . . . . . . . . . 142 16.1. Normative references . . . . . . . . . . . . . . . . . . 147
16.2. Informational References . . . . . . . . . . . . . . . . 143 16.2. Informative References . . . . . . . . . . . . . . . . . 148
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 145 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 150
Intellectual Property and Copyright Statements . . . . . . . . . 146 Intellectual Property and Copyright Statements . . . . . . . . . 151
1. Introduction 1. Introduction
EDITORS NOTE: Please read!
This document is the first version of the BIS for RFC2960. However
it is a bit unusual in that it represents NO CHANGES from the
original document (other than these few paragraphs in the
introduction). Instead this document is a compilation of RFC2960
converted to XML. In making such a large conversion of a text
document it was thought well worth having an "initial" pass that
represents NO changes other than the small editorial updates caused
by the xml conversion itself. I have tried to assure that these are
minimized but they are present. Please inspect this document for
typos where I may have inadvertently removed text in the conversion
process.
An undertaking represented by this update is not a small feat and
represents the considerable effort of both the initial authors of
RFC2960: Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer T. Taylor,
I. Rytina, M. Kalla, L. Zhang, V. Paxson and the authors of the SCTP
implementors guide: I. Arias-Rodriguez, K. Poon, A. Caro, M. Tuexen.
Add to this the efforts of all the subsequent seven SCTP inter-
operability tests and you have this document. My thanks cannot be
adequately expressed for all of you who have participated in the
coding, testing and updating process of this document all I can say
is Thank You!
Randall Stewart - Editor
This section explains the reasoning behind the development of the This section explains the reasoning behind the development of the
Stream Control Transmission Protocol (SCTP), the services it offers, Stream Control Transmission Protocol (SCTP), the services it offers,
and the basic concepts needed to understand the detailed description and the basic concepts needed to understand the detailed description
of the protocol. of the protocol.
1.1. Motivation 1.1. Motivation
TCP [RFC0793] has performed immense service as the primary means of TCP [RFC0793] has performed immense service as the primary means of
reliable data transfer in IP networks. However, an increasing number reliable data transfer in IP networks. However, an increasing number
of recent applications have found TCP too limiting, and have of recent applications have found TCP too limiting, and have
skipping to change at page 11, line 33 skipping to change at page 10, line 33
bundling even if the user has requested that SCTP not bundle. The bundling even if the user has requested that SCTP not bundle. The
user's disabling of bundling only affects SCTP implementations that user's disabling of bundling only affects SCTP implementations that
may delay a small period of time before transmission (to attempt to may delay a small period of time before transmission (to attempt to
encourage bundling). When the user layer disables bundling, this encourage bundling). When the user layer disables bundling, this
small delay is prohibited but not bundling that is performed during small delay is prohibited but not bundling that is performed during
congestion or retransmission. congestion or retransmission.
1.3.6. Packet Validation 1.3.6. Packet Validation
A mandatory Verification Tag field and a 32 bit checksum field (see A mandatory Verification Tag field and a 32 bit checksum field (see
Appendix B for a description of the Adler-32 checksum) are included Appendix B for a description of the CRC32c checksum) are included in
in the SCTP common header. The Verification Tag value is chosen by the SCTP common header. The Verification Tag value is chosen by each
each end of the association during association startup. Packets end of the association during association startup. Packets received
received without the expected Verification Tag value are discarded, without the expected Verification Tag value are discarded, as a
as a protection against blind masquerade attacks and against stale protection against blind masquerade attacks and against stale SCTP
SCTP packets from a previous association. The Adler-32 checksum packets from a previous association. The CRC32c checksum should be
should be set by the sender of each SCTP packet to provide additional set by the sender of each SCTP packet to provide additional
protection against data corruption in the network. The receiver of protection against data corruption in the network. The receiver of
an SCTP packet with an invalid Adler-32 checksum silently discards an SCTP packet with an invalid CRC32c checksum silently discards the
the packet. packet.
1.3.7. Path Management 1.3.7. Path Management
The sending SCTP user is able to manipulate the set of transport The sending SCTP user is able to manipulate the set of transport
addresses used as destinations for SCTP packets through the addresses used as destinations for SCTP packets through the
primitives described in Section 10. The SCTP path management primitives described in Section 10. The SCTP path management
function chooses the destination transport address for each outgoing function chooses the destination transport address for each outgoing
SCTP packet based on the SCTP user's instructions and the currently SCTP packet based on the SCTP user's instructions and the currently
perceived reachability status of the eligible destination set. The perceived reachability status of the eligible destination set. The
path management function monitors reachability through heartbeats path management function monitors reachability through heartbeats
skipping to change at page 15, line 41 skipping to change at page 14, line 41
and an SCTP port number (where SCTP is the Transport protocol). and an SCTP port number (where SCTP is the Transport protocol).
o Unacknowledged TSN (at an SCTP endpoint): A TSN (and the o Unacknowledged TSN (at an SCTP endpoint): A TSN (and the
associated DATA chunk) which has been received by the endpoint but associated DATA chunk) which has been received by the endpoint but
for which an acknowledgement has not yet been sent. Or in the for which an acknowledgement has not yet been sent. Or in the
opposite case, for a packet that has been sent but no opposite case, for a packet that has been sent but no
acknowledgement has been received. acknowledgement has been received.
o Unordered Message: Unordered messages are "unordered" with respect o Unordered Message: Unordered messages are "unordered" with respect
to any other message, this includes both other unordered messages to any other message, this includes both other unordered messages
as well as other ordered messages. Unordered message might be as well as other ordered messages. An unordered message might be
delivered prior to or later than ordered messages sent on the same delivered prior to or later than ordered messages sent on the same
stream. stream.
o User message: The unit of data delivery across the interface o User message: The unit of data delivery across the interface
between SCTP and its user. between SCTP and its user.
o Verification Tag: A 32 bit unsigned integer that is randomly o Verification Tag: A 32 bit unsigned integer that is randomly
generated. The Verification Tag provides a key that allows a generated. The Verification Tag provides a key that allows a
receiver to verify that the SCTP packet belongs to the current receiver to verify that the SCTP packet belongs to the current
association and is not an old or stale packet from a previous association and is not an old or stale packet from a previous
skipping to change at page 19, line 14 skipping to change at page 18, line 14
- A packet containing an ABORT chunk may have the verification - A packet containing an ABORT chunk may have the verification
tag copied from the packet which caused the ABORT to be sent. tag copied from the packet which caused the ABORT to be sent.
For details see Section 8.4 and Section 8.5. For details see Section 8.4 and Section 8.5.
An INIT chunk MUST be the only chunk in the SCTP packet carrying An INIT chunk MUST be the only chunk in the SCTP packet carrying
it. it.
Checksum: 32 bits (unsigned integer) Checksum: 32 bits (unsigned integer)
This field contains the checksum of this SCTP packet. Its This field contains the checksum of this SCTP packet. Its
calculation is discussed in Section 6.8. SCTP uses the Adler- 32 calculation is discussed in Section 6.8. SCTP uses the CRC32c
algorithm as described in Appendix B for calculating the checksum algorithm as described in Appendix B for calculating the checksum
3.2. Chunk Field Descriptions 3.2. Chunk Field Descriptions
The figure below illustrates the field format for the chunks to be The figure below illustrates the field format for the chunks to be
transmitted in the SCTP packet. Each chunk is formatted with a Chunk transmitted in the SCTP packet. Each chunk is formatted with a Chunk
Type field, a chunk-specific Flag field, a Chunk Length field, and a Type field, a chunk-specific Flag field, a Chunk Length field, and a
Value field. Value field.
0 1 2 3 0 1 2 3
skipping to change at page 20, line 48 skipping to change at page 19, line 48
01 - Stop processing this SCTP packet and discard it, do not 01 - Stop processing this SCTP packet and discard it, do not
process any further chunks within it, and report the process any further chunks within it, and report the
unrecognized chunk in an 'Unrecognized Chunk Type'. unrecognized chunk in an 'Unrecognized Chunk Type'.
10 - Skip this chunk and continue processing. 10 - Skip this chunk and continue processing.
11 - Skip this chunk and continue processing, but report in an 11 - Skip this chunk and continue processing, but report in an
ERROR Chunk using the 'Unrecognized Chunk Type' cause of ERROR Chunk using the 'Unrecognized Chunk Type' cause of
error. error.
Note: The ECNE and CWR chunk types are reserved for future use of Note: The ECNE and CWR chunk types are reserved for future use of
Explicit Congestion Notification (ECN). Explicit Congestion Notification (ECN) - see Appendix A.
Chunk Flags: 8 bits Chunk Flags: 8 bits
The usage of these bits depends on the chunk type as given by the The usage of these bits depends on the chunk type as given by the
Chunk Type. Unless otherwise specified, they are set to zero on Chunk Type. Unless otherwise specified, they are set to zero on
transmit and are ignored on receipt. transmit and are ignored on receipt.
Chunk Length: 16 bits (unsigned integer) Chunk Length: 16 bits (unsigned integer)
This value represents the size of the chunk in bytes, including This value represents the size of the chunk in bytes, including
the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
skipping to change at page 28, line 9 skipping to change at page 27, line 9
Note 1: The INIT chunks can contain multiple addresses that can be Note 1: The INIT chunks can contain multiple addresses that can be
IPv4 and/or IPv6 in any combination. IPv4 and/or IPv6 in any combination.
Note 2: The ECN capable field is reserved for future use of Explicit Note 2: The ECN capable field is reserved for future use of Explicit
Congestion Notification. Congestion Notification.
Note 3: An INIT chunk MUST NOT contain more than one Host Name Note 3: An INIT chunk MUST NOT contain more than one Host Name
address parameter. Moreover, the sender of the INIT MUST NOT combine address parameter. Moreover, the sender of the INIT MUST NOT combine
any other address types with the Host Name address in the INIT. The any other address types with the Host Name address in the INIT. The
receiver of INIT MUST ignore any other address types if the Host Name receiver of INIT MUST ignore any other address types if the Host Name
address paramete`r is present in the received INIT chunk. address parameter is present in the received INIT chunk.
Note 4: This parameter, when present, specifies all the address types Note 4: This parameter, when present, specifies all the address types
the sending endpoint can support. The absence of this parameter the sending endpoint can support. The absence of this parameter
indicates that the sending endpoint can support any address type. indicates that the sending endpoint can support any address type.
IMPLEMENTATION NOTE: If an INIT chunk is received with known IMPLEMENTATION NOTE: If an INIT chunk is received with known
parameters that are not optional parameters of the INIT chunk then parameters that are not optional parameters of the INIT chunk then
the receiver SHOULD process the INIT chunk and send back an INIT-ACK. the receiver SHOULD process the INIT chunk and send back an INIT-ACK.
The receiver of the INIT chunk MAY bundle an ERROR chunk with the The receiver of the INIT chunk MAY bundle an ERROR chunk with the
COOKIE-ACK chunk later. However, restrictive implementations MAY COOKIE-ACK chunk later. However, restrictive implementations MAY
skipping to change at page 42, line 4 skipping to change at page 41, line 4
responding. responding.
Variable Parameters Status Type Value Variable Parameters Status Type Value
------------------------------------------------------------- -------------------------------------------------------------
Heartbeat Info Mandatory 1 Heartbeat Info Mandatory 1
3.3.7. Abort Association (ABORT) (6): 3.3.7. Abort Association (ABORT) (6):
The ABORT chunk is sent to the peer of an association to close the The ABORT chunk is sent to the peer of an association to close the
association. The ABORT chunk may contain Cause Parameters to inform association. The ABORT chunk may contain Cause Parameters to inform
the receiver the reason of the abort. DATA chunks MUST NOT be the receiver about the reason of the abort. DATA chunks MUST NOT be
bundled with ABORT. Control chunks (except for INIT, INIT ACK and bundled with ABORT. Control chunks (except for INIT, INIT ACK and
SHUTDOWN COMPLETE) MAY be bundled with an ABORT but they MUST be SHUTDOWN COMPLETE) MAY be bundled with an ABORT but they MUST be
placed before the ABORT in the SCTP packet, or they will be ignored placed before the ABORT in the SCTP packet, or they will be ignored
by the receiver. by the receiver.
If an endpoint receives an ABORT with a format error or no TCB is If an endpoint receives an ABORT with a format error or no TCB is
found, it MUST silently discard it. Moreover, under any found, it MUST silently discard it. Moreover, under any
circumstances, an endpoint that receives an ABORT MUST NOT respond to circumstances, an endpoint that receives an ABORT MUST NOT respond to
that ABORT by sending an ABORT of its own. that ABORT by sending an ABORT of its own.
skipping to change at page 45, line 25 skipping to change at page 44, line 25
8 Unrecognized Parameters 8 Unrecognized Parameters
9 No User Data 9 No User Data
10 Cookie Received While Shutting Down 10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses 11 Restart of an Association with New Addresses
12 User Initiated Abort 12 User Initiated Abort
13 Protocol Violation 13 Protocol Violation
Cause Length: 16 bits (unsigned integer) Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields Code, Cause Length, and Cause-Specific Information fields.
Cause-specific Information: variable length Cause-specific Information: variable length
This field carries the details of the error condition. This field carries the details of the error condition.
Section 3.3.10.1 - Section 3.3.10.13 define error causes for SCTP. Section 3.3.10.1 - Section 3.3.10.13 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are Guidelines for the IETF to define new error cause values are
discussed in Section 13.3. discussed in Section 13.3.
3.3.10.1. Invalid Stream Identifier (1) 3.3.10.1. Invalid Stream Identifier (1)
skipping to change at page 55, line 17 skipping to change at page 54, line 17
(from the ESTABLISHED state only) (from the ESTABLISHED state only)
| |
| |
/--------+--------\ /--------+--------\
[SHUTDOWN] / \ [SHUTDOWN] / \
-------------------| | -------------------| |
check outstanding | | check outstanding | |
DATA chunks | | DATA chunks | |
v | v |
+---------+ | +---------+ |
|SHUTDOWN-| | rcv SHUTDOWN/check |SHUTDOWN-| | rcv SHUTDOWN
|PENDING | | outstanding DATA |PENDING | |------------------
+---------+ | chunks +---------+ | check outstanding
| |------------------ | | DATA chunks
No more outstanding | | No more outstanding | |
---------------------| | ---------------------| |
snd SHUTDOWN | | snd SHUTDOWN | |
strt shutdown timer | | strt shutdown timer | |
v v v v
+---------+ +-----------+ +---------+ +-----------+
(4) |SHUTDOWN-| | SHUTDOWN- | (5,6) (4) |SHUTDOWN-| | SHUTDOWN- | (5,6)
|SENT | | RECEIVED | |SENT | | RECEIVED |
+---------+ +-----------+ +---------+ +-----------+
| \ | | \ |
skipping to change at page 62, line 47 skipping to change at page 61, line 47
4) Generate the State Cookie by combining this subset of information 4) Generate the State Cookie by combining this subset of information
and the resultant MAC. and the resultant MAC.
After sending the INIT ACK with the State Cookie parameter, the After sending the INIT ACK with the State Cookie parameter, the
sender SHOULD delete the TCB and any other local resource related to sender SHOULD delete the TCB and any other local resource related to
the new association, so as to prevent resource attacks. the new association, so as to prevent resource attacks.
The hashing method used to generate the MAC is strictly a private The hashing method used to generate the MAC is strictly a private
matter for the receiver of the INIT chunk. The use of a MAC is matter for the receiver of the INIT chunk. The use of a MAC is
mandatory to prevent denial of service attacks. The secret key mandatory to prevent denial of service attacks. The secret key
SHOULD be random ( [RFC1750] provides some information on randomness SHOULD be random ( [RFC4086] provides some information on randomness
guidelines); it SHOULD be changed reasonably frequently, and the guidelines); it SHOULD be changed reasonably frequently, and the
timestamp in the State Cookie MAY be used to determine which key timestamp in the State Cookie MAY be used to determine which key
should be used to verify the MAC. should be used to verify the MAC.
An implementation SHOULD make the cookie as small as possible to An implementation SHOULD make the cookie as small as possible to
insure interoperability. insure interoperability.
5.1.4. State Cookie Processing 5.1.4. State Cookie Processing
When an endpoint (in the COOKIE WAIT state) receives an INIT ACK When an endpoint (in the COOKIE WAIT state) receives an INIT ACK
chunk with a State Cookie parameter, it MUST immediately send a chunk with a State Cookie parameter, it MUST immediately send a
COOKIE ECHO chunk to its peer with the received State Cookie. The COOKIE ECHO chunk to its peer with the received State Cookie. The
sender MAY also add any pending DATA chunks to the packet after the sender MAY also add any pending DATA chunks to the packet after the
COOKIE ECHO chunk. COOKIE ECHO chunk.
The endpoint shall also start the T1-cookie timer after sending out The endpoint shall also start the T1-cookie timer after sending out
the COOKIE ECHO chunk. If the timer expires, the endpoint shall the COOKIE ECHO chunk. If the timer expires, the endpoint shall
retransmit the COOKIE ECHO chunk and restart the T1-cookie timer. retransmit the COOKIE ECHO chunk and restart the T1-cookie timer.
This is repeated until either a COOKIE ACK is received or ' This is repeated until either a COOKIE ACK is received or
Max.Init.Retransmits' is reached causing the peer endpoint to be 'Max.Init.Retransmits' is reached causing the peer endpoint to be
marked unreachable (and thus the association enters the CLOSED marked unreachable (and thus the association enters the CLOSED
state). state).
5.1.5. State Cookie Authentication 5.1.5. State Cookie Authentication
When an endpoint receives a COOKIE ECHO chunk from another endpoint When an endpoint receives a COOKIE ECHO chunk from another endpoint
with which it has no association, it shall take the following with which it has no association, it shall take the following
actions: actions:
1) Compute a MAC using the TCB data carried in the State Cookie and 1) Compute a MAC using the TCB data carried in the State Cookie and
skipping to change at page 73, line 5 skipping to change at page 72, line 5
than 1 second beyond the measured RTT, due to long State Cookie than 1 second beyond the measured RTT, due to long State Cookie
lifetimes making the endpoint more subject to a replay attack. lifetimes making the endpoint more subject to a replay attack.
5.3. Other Initialization Issues 5.3. Other Initialization Issues
5.3.1. Selection of Tag Value 5.3.1. Selection of Tag Value
Initiate Tag values should be selected from the range of 1 to 2**32 - Initiate Tag values should be selected from the range of 1 to 2**32 -
1. It is very important that the Initiate Tag value be randomized to 1. It is very important that the Initiate Tag value be randomized to
help protect against "man in the middle" and "sequence number" help protect against "man in the middle" and "sequence number"
attacks. The methods described in [RFC1750] can be used for the attacks. The methods described in [RFC4086] can be used for the
Initiate Tag randomization. Careful selection of Initiate Tags is Initiate Tag randomization. Careful selection of Initiate Tags is
also necessary to prevent old duplicate packets from previous also necessary to prevent old duplicate packets from previous
associations being mistakenly processed as belonging to the current associations being mistakenly processed as belonging to the current
association. association.
Moreover, the Verification Tag value used by either endpoint in a Moreover, the Verification Tag value used by either endpoint in a
given association MUST NOT change during the lifetime of an given association MUST NOT change during the lifetime of an
association. A new Verification Tag value MUST be used each time the association. A new Verification Tag value MUST be used each time the
endpoint tears-down and then re-establishes an association to the endpoint tears-down and then re-establishes an association to the
same peer. same peer.
skipping to change at page 83, line 33 skipping to change at page 82, line 33
6.3.1. RTO Calculation 6.3.1. RTO Calculation
The rules governing the computation of SRTT, RTTVAR, and RTO are as The rules governing the computation of SRTT, RTTVAR, and RTO are as
follows: follows:
C1) Until an RTT measurement has been made for a packet sent to the C1) Until an RTT measurement has been made for a packet sent to the
given destination transport address, set RTO to the protocol given destination transport address, set RTO to the protocol
parameter 'RTO.Initial'. parameter 'RTO.Initial'.
C2) When the first RTT measurement R is made, set SRTT <- R, RTTVAR C2) When the first RTT measurement R is made, set
<- R/2, and RTO <- SRTT + 4 * RTTVAR.
SRTT <- R,
RTTVAR <- R/2, and
RTO <- SRTT + 4 * RTTVAR.
C3) When a new RTT measurement R' is made, set C3) When a new RTT measurement R' is made, set
RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| SRTT RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|
<- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R' and
SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'
Note: The value of SRTT used in the update to RTTVAR is its value Note: The value of SRTT used in the update to RTTVAR is its value
before updating SRTT itself using the second assignment. before updating SRTT itself using the second assignment.
After the computation, update RTO <- SRTT + 4 * RTTVAR. After the computation, update RTO <- SRTT + 4 * RTTVAR.
C4) When data is in flight and when allowed by rule C5 below, a new C4) When data is in flight and when allowed by rule C5 below, a new
RTT measurement MUST be made each round trip. Furthermore, new RTT measurement MUST be made each round trip. Furthermore, new
RTT measurements SHOULD be made no more than once per round-trip RTT measurements SHOULD be made no more than once per round-trip
for a given destination transport address. There are two reasons for a given destination transport address. There are two reasons
skipping to change at page 90, line 30 skipping to change at page 89, line 30
Figure 9 - Reporting a Gap using SACK Figure 9 - Reporting a Gap using SACK
The maximum number of Gap Ack Blocks that can be reported within a The maximum number of Gap Ack Blocks that can be reported within a
single SACK chunk is limited by the current path MTU. When a single single SACK chunk is limited by the current path MTU. When a single
SACK can not cover all the Gap Ack Blocks needed to be reported due SACK can not cover all the Gap Ack Blocks needed to be reported due
to the MTU limitation, the endpoint MUST send only one SACK, to the MTU limitation, the endpoint MUST send only one SACK,
reporting the Gap Ack Blocks from the lowest to highest TSNs, within reporting the Gap Ack Blocks from the lowest to highest TSNs, within
the size limit set by the MTU, and leave the remaining highest TSN the size limit set by the MTU, and leave the remaining highest TSN
numbers unacknowledged. numbers unacknowledged.
6.8. CRC-32c Checksum Calculation 6.8. CRC32c Checksum Calculation
When sending an SCTP packet, the endpoint MUST strengthen the data When sending an SCTP packet, the endpoint MUST strengthen the data
integrity of the transmission by including the CRC32c checksum value integrity of the transmission by including the CRC32c checksum value
calculated on the packet, as described below. calculated on the packet, as described below.
After the packet is constructed (containing the SCTP common header After the packet is constructed (containing the SCTP common header
and one or more control or DATA chunks), the transmitter MUST and one or more control or DATA chunks), the transmitter MUST
1) fill in the proper Verification Tag in the SCTP common header and 1) fill in the proper Verification Tag in the SCTP common header and
initialize the checksum field to '0's, initialize the checksum field to '0's,
skipping to change at page 102, line 45 skipping to change at page 101, line 45
C) Re-enable heartbeat on a specific destination transport address of C) Re-enable heartbeat on a specific destination transport address of
a given association, and, a given association, and,
D) Request an on-demand HEARTBEAT on a specific destination transport D) Request an on-demand HEARTBEAT on a specific destination transport
address of a given association. address of a given association.
The endpoint should increment the respective error counter of the The endpoint should increment the respective error counter of the
destination transport address each time a HEARTBEAT is sent to that destination transport address each time a HEARTBEAT is sent to that
address and not acknowledged within one RTO. address and not acknowledged within one RTO.
When the value of this counter reaches the protocol parameter ' When the value of this counter reaches the protocol parameter
Path.Max.Retrans', the endpoint should mark the corresponding 'Path.Max.Retrans', the endpoint should mark the corresponding
destination address as inactive if it is not so marked, and may also destination address as inactive if it is not so marked, and may also
optionally report to the upper layer the change of reachability of optionally report to the upper layer the change of reachability of
this destination address. After this, the endpoint should continue this destination address. After this, the endpoint should continue
HEARTBEAT on this destination address but should stop increasing the HEARTBEAT on this destination address but should stop increasing the
counter. counter.
The sender of the HEARTBEAT chunk should include in the Heartbeat The sender of the HEARTBEAT chunk should include in the Heartbeat
Information field of the chunk the current time when the packet is Information field of the chunk the current time when the packet is
sent out and the destination address to which the packet is sent. sent out and the destination address to which the packet is sent.
skipping to change at page 109, line 6 skipping to change at page 108, line 6
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
respond to each received packet containing one or more DATA chunks respond to each received packet containing one or more DATA chunks
with a SHUTDOWN chunk and restart the T2-shutdown timer. If a with a SHUTDOWN chunk and restart the T2-shutdown timer. If a
SHUTDOWN chunk by itself cannot acknowledge all of the received DATA SHUTDOWN chunk by itself cannot acknowledge all of the received DATA
chunks (i.e., there are TSNs that can be acknowledged that are larger chunks (i.e., there are TSNs that can be acknowledged that are larger
than the cumulative TSN, and thus gaps exist in the TSN sequence), or than the cumulative TSN, and thus gaps exist in the TSN sequence), or
if duplicate TSNs have been received, then a SACK chunk MUST also be if duplicate TSNs have been received, then a SACK chunk MUST also be
sent. sent.
The sender of the SHUTDOWN MAY also start an overall guard timer 'T5- The sender of the SHUTDOWN MAY also start an overall guard timer 'T5-
shutdown-guard' to bound the overall time for shutdown sequence. At shutdown-guard' to bound the overall time for the shutdown sequence.
the expiration of this timer, the sender SHOULD abort the association At the expiration of this timer, the sender SHOULD abort the
by sending an ABORT chunk. If the 'T5-shutdown-guard' timer is used, association by sending an ABORT chunk. If the 'T5-shutdown-guard'
it SHOULD be set to the recommended value of 5 times 'RTO.Max'. timer is used, it SHOULD be set to the recommended value of 5 times
'RTO.Max'.
If the receiver of the SHUTDOWN has no more outstanding DATA chunks, If the receiver of the SHUTDOWN has no more outstanding DATA chunks,
the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a T2- the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a T2-
shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If
the timer expires, the endpoint must re-send the SHUTDOWN ACK. the timer expires, the endpoint must re-send the SHUTDOWN ACK.
The sender of the SHUTDOWN ACK should limit the number of The sender of the SHUTDOWN ACK should limit the number of
retransmissions of the SHUTDOWN ACK chunk to the protocol parameter ' retransmissions of the SHUTDOWN ACK chunk to the protocol parameter
Association.Max.Retrans'. If this threshold is exceeded the endpoint 'Association.Max.Retrans'. If this threshold is exceeded, the
should destroy the TCB and may report the peer endpoint unreachable endpoint should destroy the TCB and may report the peer endpoint
to the upper layer (and thus the association enters the CLOSED unreachable to the upper layer (and thus the association enters the
state). CLOSED state).
Upon the receipt of the SHUTDOWN ACK, the SHUTDOWN sender shall stop Upon the receipt of the SHUTDOWN ACK, the SHUTDOWN sender shall stop
the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its peer, the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its peer,
and remove all record of the association. and remove all record of the association.
Upon reception of the SHUTDOWN COMPLETE chunk the endpoint will Upon reception of the SHUTDOWN COMPLETE chunk the endpoint will
verify that it is in SHUTDOWN-ACK-SENT state, if it is not the chunk verify that it is in SHUTDOWN-ACK-SENT state, if it is not the chunk
should be discarded. If the endpoint is in the SHUTDOWN-ACK-SENT should be discarded. If the endpoint is in the SHUTDOWN-ACK-SENT
state the endpoint should stop the T2-shutdown timer and remove all state the endpoint should stop the T2-shutdown timer and remove all
knowledge of the association (and thus the association enters the knowledge of the association (and thus the association enters the
skipping to change at page 123, line 24 skipping to change at page 122, line 24
E) COMMUNICATION LOST notification E) COMMUNICATION LOST notification
When SCTP loses communication to an endpoint completely (e.g., via When SCTP loses communication to an endpoint completely (e.g., via
Heartbeats) or detects that the endpoint has performed an abort Heartbeats) or detects that the endpoint has performed an abort
operation, it shall invoke this notification on the ULP. operation, it shall invoke this notification on the ULP.
The following shall be passed with the notification: The following shall be passed with the notification:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o status - This indicates what type of event has occurred; The status o status - This indicates what type of event has occurred; the status
may indicate that a failure OR a normal termination event may indicate that a failure OR a normal termination event
occurred in response to a shutdown or abort request. occurred in response to a shutdown or abort request.
The following may be passed with the notification: The following may be passed with the notification:
o data retrieval id - an identification used to retrieve unsent and o data retrieval id - an identification used to retrieve unsent and
unacknowledged data. unacknowledged data.
o last-acked - the TSN last acked by that peer endpoint. o last-acked - the TSN last acked by that peer endpoint.
skipping to change at page 125, line 23 skipping to change at page 124, line 23
protection were provided in the application-layer, the SCTP header protection were provided in the application-layer, the SCTP header
would remain vulnerable to deliberate integrity attacks. While the would remain vulnerable to deliberate integrity attacks. While the
existing SCTP mechanisms for detection of packet replays are existing SCTP mechanisms for detection of packet replays are
considered sufficient for normal operation, stronger protections are considered sufficient for normal operation, stronger protections are
needed to protect SCTP when the operating environment contains needed to protect SCTP when the operating environment contains
significant risk of deliberate attacks from a sophisticated significant risk of deliberate attacks from a sophisticated
adversary. adversary.
In order to promote software code-reuse, to avoid re-inventing the In order to promote software code-reuse, to avoid re-inventing the
wheel, and to avoid gratuitous complexity to SCTP, the IP wheel, and to avoid gratuitous complexity to SCTP, the IP
Authentication Header [RFC2402] SHOULD be used when the threat Authentication Header [RFC4302] SHOULD be used when the threat
environment requires stronger integrity protections, but does not environment requires stronger integrity protections, but does not
require confidentiality. require confidentiality.
A widely implemented BSD Sockets API extension exists for A widely implemented BSD Sockets API extension exists for
applications to request IP security services, such as AH or ESP from applications to request IP security services, such as AH or ESP from
an operating system kernel. Applications can use such an API to an operating system kernel. Applications can use such an API to
request AH whenever AH use is appropriate. request AH whenever AH use is appropriate.
11.2.3. Protecting Confidentiality 11.2.3. Protecting Confidentiality
In most cases, the risk of breach of confidentiality applies to the In most cases, the risk of breach of confidentiality applies to the
signaling data payload, not to the SCTP or lower-layer protocol signaling data payload, not to the SCTP or lower-layer protocol
overheads. If that is true, encryption of the SCTP user data only overheads. If that is true, encryption of the SCTP user data only
might be considered. As with the supplementary checksum service, might be considered. As with the supplementary checksum service,
user data encryption MAY be performed by the SCTP user application. user data encryption MAY be performed by the SCTP user application.
Alternately, the user application MAY use an implementation-specific Alternately, the user application MAY use an implementation-specific
API to request that the IP Encapsulating Security Payload (ESP) API to request that the IP Encapsulating Security Payload (ESP)
[RFC2406] be used to provide confidentiality and integrity. [RFC4303] be used to provide confidentiality and integrity.
Particularly for mobile users, the requirement for confidentiality Particularly for mobile users, the requirement for confidentiality
might include the masking of IP addresses and ports. In this case might include the masking of IP addresses and ports. In this case
ESP SHOULD be used instead of application-level confidentiality. If ESP SHOULD be used instead of application-level confidentiality. If
ESP is used to protect confidentiality of SCTP traffic, an ESP ESP is used to protect confidentiality of SCTP traffic, an ESP
cryptographic transform that includes cryptographic integrity cryptographic transform that includes cryptographic integrity
protection MUST be used, because if there is a confidentiality threat protection MUST be used, because if there is a confidentiality threat
there will also be a strong integrity threat. there will also be a strong integrity threat.
Whenever ESP is in use, application-level encryption is not generally Whenever ESP is in use, application-level encryption is not generally
required. required.
Regardless of where confidentiality is provided, the ISAKMP [RFC2408] Regardless of where confidentiality is provided, the IKEv2 [RFC4306]
and the Internet Key Exchange (IKE) [RFC2409] SHOULD be used for key SHOULD be used for key management.
management.
Operators should consult [RFC2401] for more information on the Operators should consult [RFC4301] for more information on the
security services available at and immediately above the Internet security services available at and immediately above the Internet
Protocol layer. Protocol layer.
11.2.4. Protecting against Blind Denial of Service Attacks 11.2.4. Protecting against Blind Denial of Service Attacks
A blind attack is one where the attacker is unable to intercept or A blind attack is one where the attacker is unable to intercept or
otherwise see the content of data flows passing to and from the otherwise see the content of data flows passing to and from the
target SCTP node. Blind denial of service attacks may take the form target SCTP node. Blind denial of service attacks may take the form
of flooding, masquerade, or improper monopolization of services. of flooding, masquerade, or improper monopolization of services.
skipping to change at page 127, line 15 skipping to change at page 126, line 14
The design of SCTP is resistant to flooding attacks, particularly in The design of SCTP is resistant to flooding attacks, particularly in
its use of a four-way start-up handshake, its use of a cookie to its use of a four-way start-up handshake, its use of a cookie to
defer commitment of resources at the responding SCTP node until the defer commitment of resources at the responding SCTP node until the
handshake is completed, and its use of a Verification Tag to prevent handshake is completed, and its use of a Verification Tag to prevent
insertion of extraneous packets into the flow of an established insertion of extraneous packets into the flow of an established
association. association.
The IP Authentication Header and Encapsulating Security Payload might The IP Authentication Header and Encapsulating Security Payload might
be useful in reducing the risk of certain kinds of denial of service be useful in reducing the risk of certain kinds of denial of service
attacks." attacks.
The use of the Host Name feature in the INIT chunk could be used to The use of the Host Name feature in the INIT chunk could be used to
flood a target DNS server. A large backlog of DNS queries, resolving flood a target DNS server. A large backlog of DNS queries, resolving
the Host Name received in the INIT chunk to IP addresses, could be the Host Name received in the INIT chunk to IP addresses, could be
accomplished by sending INIT's to multiple hosts in a given domain. accomplished by sending INIT's to multiple hosts in a given domain.
In addition, an attacker could use the Host Name feature in an In addition, an attacker could use the Host Name feature in an
indirect attack on a third party by sending large numbers of INITs to indirect attack on a third party by sending large numbers of INITs to
random hosts containing the host name of the target. In addition to random hosts containing the host name of the target. In addition to
the strain on DNS resources, this could also result in large numbers the strain on DNS resources, this could also result in large numbers
of INIT ACKs being sent to the target. One method to protect against of INIT ACKs being sent to the target. One method to protect against
skipping to change at page 131, line 17 skipping to change at page 130, line 17
Associations: A list of current associations and mappings to the data Associations: A list of current associations and mappings to the data
consumers for each association. This may be in the consumers for each association. This may be in the
form of a hash table or other implementation dependent form of a hash table or other implementation dependent
structure. The data consumers may be process structure. The data consumers may be process
identification information such as file descriptors, identification information such as file descriptors,
named pipe pointer, or table pointers dependent on how named pipe pointer, or table pointers dependent on how
SCTP is implemented. SCTP is implemented.
Secret Key: A secret key used by this endpoint to compute the MAC. Secret Key: A secret key used by this endpoint to compute the MAC.
This SHOULD be a cryptographic quality random number This SHOULD be a cryptographic quality random number
with a sufficient length. Discussion in RFC1750 can with a sufficient length. Discussion in RFC4086 can
be helpful in selection of the key. be helpful in selection of the key.
Address List: The list of IP addresses that this instance has bound. Address List: The list of IP addresses that this instance has bound.
This information is passed to one's peer(s) in INIT and This information is passed to one's peer(s) in INIT and
INIT ACK chunks. INIT ACK chunks.
SCTP Port: The local SCTP port number the endpoint is bound to. SCTP Port: The local SCTP port number the endpoint is bound to.
12.2. Parameters necessary per association (i.e. the TCB) 12.2. Parameters necessary per association (i.e. the TCB)
skipping to change at page 137, line 25 skipping to change at page 136, line 25
HB.interval - 30 seconds HB.interval - 30 seconds
HB.Max.Burst - 1 HB.Max.Burst - 1
IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to
customize some of these protocol parameters (see Section 10). customize some of these protocol parameters (see Section 10).
Note: RTO.Min SHOULD be set as recommended above. Note: RTO.Min SHOULD be set as recommended above.
15. Acknowledgements 15. Acknowledgements
The authors wish to thank Mark Allman, R.J. Atkinson, Richard Band, An undertaking represented by this updated document is not a small
Scott Bradner, Steve Bellovin, Peter Butler, Ram Dantu, R. feat and represents the summation of the initial authors of RFC2960,
Ezhirpavai, Mike Fisk, Sally Floyd, Atsushi Fukumoto, Matt Holdrege,
Henry Houh, Christian Huitema, Gary Lehecka, Jonathan Lee, David Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer T. Taylor, I. Rytina,
Lehmann, John Loughney, Daniel Luan, Barry Nagelberg, Thomas Narten, M. Kalla, L. Zhang, V. Paxson ,
Erik Nordmark, Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz
Prantner, Jarno Rajahalme, Raymond E. Reeves, Renee Revis, Ivan Arias add to that the comments from every one that contributed to the
Rodriguez, A. Sankar, Greg Sidebottom, Brian Wyld, La Monte Yarroll, original RFC:
and many others for their invaluable comments.
Mark Allman, R.J. Atkinson, Richard Band, Scott Bradner, Steve
Bellovin, Peter Butler, Ram Dantu, R. Ezhirpavai, Mike Fisk, Sally
Floyd, Atsushi Fukumoto, Matt Holdrege, Henry Houh, Christian
Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney,
Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon
Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme,
Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg
Sidebottom, Brian Wyld, La Monte Yarroll, and many others for their
invaluable comments.
then add the authors of the SCTP implementors guide, I. Arias-
Rodriguez, K. Poon, A. Caro, M. Tuexen,
Add to these the efforts of all the subsequent seven SCTP inter-
operability tests and those who commented on the RFC4460 as shown in
its acknowledgments:
Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng,
Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina
Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte,
Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC
Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel,
Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan,
Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann,
Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth
Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John
Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent
Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig,
Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob
Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger,
Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar.
A special thanks to Mark Allman, who should actually be a co-author
for his work on the max-burst, but managed to wiggle out due to a
technicality. Also, we would like to acknowledge Lyndon Ong and Phil
Conrad for their valuable input and many contributions.
And finally you have this document. My thanks cannot be adequately
expressed for all of you who have participated in the coding, testing
and updating process of this document all I can say is Thank You!
Randall Stewart - Editor
Appendix A. Explicit Congestion Notification Appendix A. Explicit Congestion Notification
ECN (Ramakrishnan, K., Floyd, S., "Explicit Congestion Notification", ECN (Ramakrishnan, K., Floyd, S., "Explicit Congestion Notification",
[RFC2481], January 1999) describes a proposed extension to IP that [RFC3168], January 1999) describes a proposed extension to IP that
details a method to become aware of congestion outside of datagram details a method to become aware of congestion outside of datagram
loss. This is an optional feature that an implementation MAY choose loss. This is an optional feature that an implementation MAY choose
to add to SCTP. This appendix details the minor differences to add to SCTP. This appendix details the minor differences
implementers will need to be aware of if they choose to implement implementers will need to be aware of if they choose to implement
this feature. In general [RFC2481] should be followed with the this feature. In general [RFC3168] should be followed with the
following exceptions. following exceptions.
Negotiation: Negotiation:
[RFC2481] details negotiation of ECN during the SYN and SYN-ACK [RFC3168] details negotiation of ECN during the SYN and SYN-ACK
stages of a TCP connection. The sender of the SYN sets two bits in stages of a TCP connection. The sender of the SYN sets two bits in
the TCP flags, and the sender of the SYN-ACK sets only 1 bit. The the TCP flags, and the sender of the SYN-ACK sets only 1 bit. The
reasoning behind this is to assure both sides are truly ECN capable. reasoning behind this is to assure both sides are truly ECN capable.
For SCTP this is not necessary. To indicate that an endpoint is ECN For SCTP this is not necessary. To indicate that an endpoint is ECN
capable an endpoint SHOULD add to the INIT and or INIT ACK chunk the capable an endpoint SHOULD add to the INIT and or INIT ACK chunk the
TLV reserved for ECN. This TLV contains no parameters, and thus has TLV reserved for ECN. This TLV contains no parameters, and thus has
the following format: the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 32768 | Parameter Length = 4 | | Parameter Type = 32768 | Parameter Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ECN-Echo: ECN-Echo:
[RFC2481] details a specific bit for a receiver to send back in its [RFC3168] details a specific bit for a receiver to send back in its
TCP acknowledgements to notify the sender of the Congestion TCP acknowledgements to notify the sender of the Congestion
Experienced (CE) bit having arrived from the network. For SCTP this Experienced (CE) bit having arrived from the network. For SCTP this
same indication is made by including the ECNE chunk. This chunk same indication is made by including the ECNE chunk. This chunk
contains one data element, i.e. the lowest TSN associated with the IP contains one data element, i.e. the lowest TSN associated with the IP
datagram marked with the CE bit, and looks as follows: datagram marked with the CE bit, and looks as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type=12 | Flags=00000000| Chunk Length = 8 | | Chunk Type=12 | Flags=00000000| Chunk Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lowest TSN Number | | Lowest TSN Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The ECNE is considered a Control chunk. Note: The ECNE is considered a Control chunk.
CWR: CWR:
[RFC2481] details a specific bit for a sender to send in the header [RFC3168] details a specific bit for a sender to send in the header
of its next outbound TCP segment to indicate to its peer that it has of its next outbound TCP segment to indicate to its peer that it has
reduced its congestion window. This is termed the CWR bit. For SCTP reduced its congestion window. This is termed the CWR bit. For SCTP
the same indication is made by including the CWR chunk. This chunk the same indication is made by including the CWR chunk. This chunk
contains one data element, i.e. the TSN number that was sent in the contains one data element, i.e. the TSN number that was sent in the
ECNE chunk. This element represents the lowest TSN number in the ECNE chunk. This element represents the lowest TSN number in the
datagram that was originally marked with the CE bit. datagram that was originally marked with the CE bit.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 142, line 7 skipping to change at page 141, line 51
Note that these procedures differ from [RFC1122] and from its Note that these procedures differ from [RFC1122] and from its
requirements for processing of port-unreachable messages and the requirements for processing of port-unreachable messages and the
requirements that an implementation MUST abort associations in requirements that an implementation MUST abort associations in
response to a "protocol unreachable" message. Port unreachable response to a "protocol unreachable" message. Port unreachable
messages are not processed, since an implementation will send an messages are not processed, since an implementation will send an
ABORT, not a port unreachable. The stricter handling of the ABORT, not a port unreachable. The stricter handling of the
"protocol unreachable" message is due to security concerns for hosts "protocol unreachable" message is due to security concerns for hosts
that do NOT support SCTP. that do NOT support SCTP.
The following non-normative sample code is taken from an open-source
CRC generator [WILLIAMS93], using the "mirroring" technique and
yielding a lookup table for SCTP CRC32-c with 256 entries, each 32
bits wide. While neither especially slow nor especially fast, as
software table-lookup CRCs go, it has the advantage of working on
both big-endian and little-endian CPUs, using the same (host-order)
lookup tables, and using only the pre-defined ntohl() and htonl()
operations. The code is somewhat modified from [WILLIAMS93], to
ensure portability between big-endian and little-endian
architectures. (Note that if the byte endian-ness of the target
architecture is known to be little-endian the final bit-reversal and
byte-reversal steps can be folded into a single operation.)
/*************************************************************/
/* Note Definition for Ross Williams table generator would */
/* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */
/* For Mr. Williams direct calculation code use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */
/*************************************************************/
/* Example of the crc table file */
#ifndef __crc32cr_table_h__
#define __crc32cr_table_h__
#define CRC32C_POLY 0x1EDC6F41
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
unsigned long crc_c[256] =
{
0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L,
0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL,
0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL,
0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L,
0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL,
0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L,
0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L,
0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL,
0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL,
0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L,
0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L,
0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL,
0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L,
0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL,
0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL,
0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L,
0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L,
0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L,
0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L,
0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L,
0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L,
0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L,
0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L,
0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L,
0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L,
0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L,
0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L,
0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L,
0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L,
0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L,
0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L,
0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L,
0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL,
0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L,
0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L,
0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL,
0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L,
0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL,
0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL,
0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L,
0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L,
0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL,
0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL,
0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L,
0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL,
0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L,
0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L,
0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL,
0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L,
0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL,
0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL,
0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L,
0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL,
0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L,
0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L,
0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL,
0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL,
0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L,
0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L,
0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL,
0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L,
0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL,
0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL,
0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L,
};
#endif
/* Example of table build routine */
#include <stdio.h>
#include <stdlib.h>
#define OUTPUT_FILE "crc32cr.h"
#define CRC32C_POLY 0x1EDC6F41L
FILE *tf;
unsigned long
reflect_32 (unsigned long b)
{
int i;
unsigned long rw = 0L;
for (i = 0; i < 32; i++){
if (b & 1)
rw |= 1 << (31 - i);
b >>= 1;
}
return (rw);
}
unsigned long
build_crc_table (int index)
{
int i;
unsigned long rb;
rb = reflect_32 (index);
for (i = 0; i < 8; i++){
if (rb & 0x80000000L)
rb = (rb << 1) ^ CRC32C_POLY;
else
rb <<= 1;
}
return (reflect_32 (rb));
}
main ()
{
int i;
printf ("\nGenerating CRC-32c table file <%s>\n",
OUTPUT_FILE);
if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){
printf ("Unable to open %s\n", OUTPUT_FILE);
exit (1);
}
fprintf (tf, "#ifndef __crc32cr_table_h__\n");
fprintf (tf, "#define __crc32cr_table_h__\n\n");
fprintf (tf, "#define CRC32C_POLY 0x%08lX\n",
CRC32C_POLY);
fprintf (tf,
"#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf (tf, "\nunsigned long crc_c[256] =\n{\n");
for (i = 0; i < 256; i++){
fprintf (tf, "0x%08lXL, ", build_crc_table (i));
if ((i & 3) == 3)
fprintf (tf, "\n");
}
fprintf (tf, "};\n\n#endif\n");
if (fclose (tf) != 0)
printf ("Unable to close <%s>." OUTPUT_FILE);
else
printf ("\nThe CRC-32c table has been written to <%s>.\n",
OUTPUT_FILE);
}
/* Example of crc insertion */
#include "crc32cr.h"
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = ~0L;
unsigned long result;
unsigned char byte0,byte1,byte2,byte3;
for (i = 0; i < length; i++){
CRC32C(crc32, buffer[i]);
}
result = ~crc32;
/* result now holds the negated polynomial remainder;
* since the table and algorithm is "reflected" [williams95].
* That is, result has the same value as if we mapped the message
* to a polynomial, computed the host-bit-order polynomial
* remainder, performed final negation, then did an end-for-end
* bit-reversal.
* Note that a 32-bit bit-reversal is identical to four inplace
* 8-bit reversals followed by an end-for-end byteswap.
* In other words, the bytes of each bit are in the right order,
* but the bytes have been byteswapped. So we now do an explicit
* byteswap. On a little-endian machine, this byteswap and
* the final ntohl cancel out and could be elided.
*/
byte0 = result & 0xff;
byte1 = (result>>8) & 0xff;
byte2 = (result>>16) & 0xff;
byte3 = (result>>24) & 0xff;
crc32 = ((byte0 << 24) |
(byte1 << 16) |
(byte2 << 8) |
byte3);
return ( crc32 );
}
int
insert_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned long crc32;
message = (SCTP_message *) buffer;
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
/* and insert it into the message */
message->common_header.checksum = htonl(crc32);
return 1;
}
int
validate_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned int i;
unsigned long original_crc32;
unsigned long crc32 = ~0L;
/* save and zero checksum */
message = (SCTP_message *) buffer;
original_crc32 = ntohl(message->common_header.checksum);
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
return ((original_crc32 == crc32)? 1 : -1);
}
16. References 16. References
16.1. Normative references 16.1. Normative references
[ITU32] "ITU-T Recommendation V.42, "Error-correcting procedures [ITU32] "ITU-T Recommendation V.42, "Error-correcting procedures
for DCEs using asynchronous-to-synchronous conversion".", for DCEs using asynchronous-to-synchronous conversion".",
ITU-T section 8.1.1.6.2. ITU-T section 8.1.1.6.2.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
skipping to change at page 142, line 33 skipping to change at page 147, line 33
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858, Considerations for IP Fragment Filtering", RFC 1858,
October 1995. October 1995.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, August 1996.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999. Control", RFC 2581, April 1999.
16.2. Informational References [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
16.2. Informative References
[FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of [FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP", SIGCOMM'99 V. 26 N. 3 pp 5-21, Tahoe, Reno, and SACK TCP", SIGCOMM'99 V. 26 N. 3 pp 5-21,
July 1996. July 1996.
[SAVAGE99] [SAVAGE99]
Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
"TCP Congestion Control with a Misbehaving Receiver", ACM "TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Commuinications Review 29(5), October 1999. Computer Commuinications Review 29(5), October 1999.
[ALLMAN99] [ALLMAN99]
Allman, M. and V. Paxson, "On Estimating End-to-End Allman, M. and V. Paxson, "On Estimating End-to-End
Network Path Properties", SIGCOMM'99 , 1999. Network Path Properties", SIGCOMM'99 , 1999.
[WILLIAMS93] [WILLIAMS93]
Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION
ALGORITHMS" - Internet publication http:// ALGORITHMS" - Internet publication http://
www.geocities.com/SiliconValley/Pines/8659/crc.htm.", www.geocities.com/SiliconValley/Pines/8659/crc.htm.",
August 1993. August 1993.
[RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996. Specification version 3.3", RFC 1950, May 1996.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196,
September 1997. September 1997.
[RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481,
January 1999.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999. Protocol", RFC 2522, March 1999.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
Author's Address Author's Address
Randall R. Stewart Randall R. Stewart
Editor Editor
4875 Forest Drive 4875 Forest Drive
Suite 200 Suite 200
Columbia, SC 29206 Columbia, SC 29206
US US
Email: rrs@cisco.com Email: rrs@cisco.com
 End of changes. 50 change blocks. 
250 lines changed or deleted 503 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/