--- 1/draft-ietf-tsvwg-2960bis-00.txt 2006-05-09 22:12:55.000000000 +0200 +++ 2/draft-ietf-tsvwg-2960bis-01.txt 2006-05-09 22:12:55.000000000 +0200 @@ -1,17 +1,17 @@ Network Working Group R. Stewart -Internet-Draft Cisco Systems Inc. -Expires: August 20, 2006 February 16, 2006 +Internet-Draft Editor +Expires: November 10, 2006 May 9, 2006 Stream Control Transmission Protocol - draft-ietf-tsvwg-2960bis-00.txt + draft-ietf-tsvwg-2960bis-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -22,21 +22,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 20, 2006. + This Internet-Draft will expire on November 10, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport PSTN signaling messages over IP networks, but is capable of broader applications. @@ -72,132 +72,141 @@ 1.3.6. Packet Validation . . . . . . . . . . . . . . . . . . 11 1.3.7. Path Management . . . . . . . . . . . . . . . . . . . 11 1.4. Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 12 1.5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 16 1.6. Serial Number Arithmetic . . . . . . . . . . . . . . . . 16 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 17 3. SCTP packet Format . . . . . . . . . . . . . . . . . . . . . 17 3.1. SCTP Common Header Field Descriptions . . . . . . . . . . 18 3.2. Chunk Field Descriptions . . . . . . . . . . . . . . . . 19 3.2.1. Optional/Variable-length Parameter Format . . . . . . 21 - 3.3. SCTP Chunk Definitions . . . . . . . . . . . . . . . . . 23 - 3.3.1. Payload Data (DATA) (0) . . . . . . . . . . . . . . . 23 - 3.3.2. Initiation (INIT) (1) . . . . . . . . . . . . . . . . 25 - 3.3.3. Initiation Acknowledgement (INIT ACK) (2): . . . . . 31 - 3.3.4. Selective Acknowledgement (SACK) (3): . . . . . . . . 35 - 3.3.5. Heartbeat Request (HEARTBEAT) (4): . . . . . . . . . 38 - 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5): . . . 39 - 3.3.7. Abort Association (ABORT) (6): . . . . . . . . . . . 40 - 3.3.8. Shutdown Association (SHUTDOWN) (7): . . . . . . . . 41 - 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8): . . . . 42 - 3.3.10. Operation Error (ERROR) (9): . . . . . . . . . . . . 42 - 3.3.10.1. Invalid Stream Identifier (1) . . . . . . . . . 44 - 3.3.10.2. Missing Mandatory Parameter (2) . . . . . . . . 45 - 3.3.10.3. Stale Cookie Error (3) . . . . . . . . . . . . . 45 - 3.3.10.4. Out of Resource (4) . . . . . . . . . . . . . . 46 - 3.3.10.5. Unresolvable Address (5) . . . . . . . . . . . . 46 - 3.3.10.6. Unrecognized Chunk Type (6) . . . . . . . . . . 47 - 3.3.10.7. Invalid Mandatory Parameter (7) . . . . . . . . 47 - 3.3.10.8. Unrecognized Parameters (8) . . . . . . . . . . 47 - 3.3.10.9. No User Data (9) . . . . . . . . . . . . . . . . 48 - 3.3.10.10. Cookie Received While Shutting Down (10) . . . . 48 - 3.3.11. Cookie Echo (COOKIE ECHO) (10): . . . . . . . . . . . 49 - 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11): . . . . . . 50 - 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14): . . . . . 50 - 4. SCTP Association State Diagram . . . . . . . . . . . . . . . 51 - 5. Association Initialization . . . . . . . . . . . . . . . . . 54 - 5.1. Normal Establishment of an Association . . . . . . . . . 54 - 5.1.1. Handle Stream Parameters . . . . . . . . . . . . . . 56 - 5.1.2. Handle Address Parameters . . . . . . . . . . . . . . 57 - 5.1.3. Generating State Cookie . . . . . . . . . . . . . . . 58 - 5.1.4. State Cookie Processing . . . . . . . . . . . . . . . 59 - 5.1.5. State Cookie Authentication . . . . . . . . . . . . . 60 - 5.1.6. An Example of Normal Association Establishment . . . 60 + 3.2.2. Reporting of Unrecognized Parameters . . . . . . . . 23 + 3.3. SCTP Chunk Definitions . . . . . . . . . . . . . . . . . 24 + 3.3.1. Payload Data (DATA) (0) . . . . . . . . . . . . . . . 24 + 3.3.2. Initiation (INIT) (1) . . . . . . . . . . . . . . . . 26 + 3.3.3. Initiation Acknowledgement (INIT ACK) (2): . . . . . 32 + 3.3.4. Selective Acknowledgement (SACK) (3): . . . . . . . . 36 + 3.3.5. Heartbeat Request (HEARTBEAT) (4): . . . . . . . . . 40 + 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5): . . . 41 + 3.3.7. Abort Association (ABORT) (6): . . . . . . . . . . . 41 + 3.3.8. Shutdown Association (SHUTDOWN) (7): . . . . . . . . 42 + 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8): . . . . 43 + 3.3.10. Operation Error (ERROR) (9): . . . . . . . . . . . . 44 + 3.3.10.1. Invalid Stream Identifier (1) . . . . . . . . . 45 + 3.3.10.2. Missing Mandatory Parameter (2) . . . . . . . . 46 + 3.3.10.3. Stale Cookie Error (3) . . . . . . . . . . . . . 46 + 3.3.10.4. Out of Resource (4) . . . . . . . . . . . . . . 47 + 3.3.10.5. Unresolvable Address (5) . . . . . . . . . . . . 47 + 3.3.10.6. Unrecognized Chunk Type (6) . . . . . . . . . . 48 + 3.3.10.7. Invalid Mandatory Parameter (7) . . . . . . . . 48 + 3.3.10.8. Unrecognized Parameters (8) . . . . . . . . . . 49 + 3.3.10.9. No User Data (9) . . . . . . . . . . . . . . . . 49 + 3.3.10.10. Cookie Received While Shutting Down (10) . . . . 50 + 3.3.10.11. Restart of an Association with New Addresses + (11) . . . . . . . . . . . . . . . . . . . . . . 50 + 3.3.10.12. User-Initiated Abort (12) . . . . . . . . . . . 50 + 3.3.10.13. Protocol Violation (13) . . . . . . . . . . . . 51 + 3.3.11. Cookie Echo (COOKIE ECHO) (10): . . . . . . . . . . . 51 + 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11): . . . . . . 52 + 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14): . . . . . 53 + 4. SCTP Association State Diagram . . . . . . . . . . . . . . . 53 + 5. Association Initialization . . . . . . . . . . . . . . . . . 57 + 5.1. Normal Establishment of an Association . . . . . . . . . 57 + 5.1.1. Handle Stream Parameters . . . . . . . . . . . . . . 59 + 5.1.2. Handle Address Parameters . . . . . . . . . . . . . . 59 + 5.1.3. Generating State Cookie . . . . . . . . . . . . . . . 62 + 5.1.4. State Cookie Processing . . . . . . . . . . . . . . . 63 + 5.1.5. State Cookie Authentication . . . . . . . . . . . . . 63 + 5.1.6. An Example of Normal Association Establishment . . . 64 5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE - ECHO, and COOKIE ACK . . . . . . . . . . . . . . . . . . 62 + ECHO, and COOKIE ACK . . . . . . . . . . . . . . . . . . 66 5.2.1. INIT received in COOKIE-WAIT or COOKIE-ECHOED - State (Item B) . . . . . . . . . . . . . . . . . . . 62 + State (Item B) . . . . . . . . . . . . . . . . . . . 66 5.2.2. Unexpected INIT in States Other than CLOSED, - COOKIE-ECHOED,COOKIE-WAIT and SHUTDOWN-ACK-SENT . . . 63 - 5.2.3. Unexpected INIT ACK . . . . . . . . . . . . . . . . . 63 - 5.2.4. Handle a COOKIE ECHO when a TCB exists . . . . . . . 64 - 5.2.5. Handle Duplicate COOKIE-ACK. . . . . . . . . . . . . 68 - 5.2.6. Handle Stale COOKIE Error . . . . . . . . . . . . . . 68 - 5.3. Other Initialization Issues . . . . . . . . . . . . . . . 68 - 5.3.1. Selection of Tag Value . . . . . . . . . . . . . . . 68 - 6. User Data Transfer . . . . . . . . . . . . . . . . . . . . . 69 - 6.1. Transmission of DATA Chunks . . . . . . . . . . . . . . . 70 - 6.2. Acknowledgement on Reception of DATA Chunks . . . . . . . 72 - 6.2.1. Processing a Received SACK . . . . . . . . . . . . . 75 - 6.3. Management of Retransmission Timer . . . . . . . . . . . 76 - 6.3.1. RTO Calculation . . . . . . . . . . . . . . . . . . . 77 - 6.3.2. Retransmission Timer Rules . . . . . . . . . . . . . 78 - 6.3.3. Handle T3-rtx Expiration . . . . . . . . . . . . . . 79 - 6.4. Multi-homed SCTP Endpoints . . . . . . . . . . . . . . . 80 - 6.4.1. Failover from Inactive Destination Address . . . . . 81 - 6.5. Stream Identifier and Stream Sequence Number . . . . . . 82 - 6.6. Ordered and Unordered Delivery . . . . . . . . . . . . . 82 - 6.7. Report Gaps in Received DATA TSNs . . . . . . . . . . . . 83 - 6.8. Adler-32 Checksum Calculation . . . . . . . . . . . . . . 84 - 6.9. Fragmentation and Reassembly . . . . . . . . . . . . . . 85 - 6.10. Bundling . . . . . . . . . . . . . . . . . . . . . . . . 86 - 7. Congestion control . . . . . . . . . . . . . . . . . . . . . 87 - 7.1. SCTP Differences from TCP Congestion control . . . . . . 87 - 7.2. SCTP Slow-Start and Congestion Avoidance . . . . . . . . 88 - 7.2.1. Slow-Start . . . . . . . . . . . . . . . . . . . . . 89 - 7.2.2. Congestion Avoidance . . . . . . . . . . . . . . . . 90 - 7.2.3. Congestion Control . . . . . . . . . . . . . . . . . 91 - 7.2.4. Fast Retransmit on Gap Reports . . . . . . . . . . . 91 - 7.3. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 92 - 8. Fault Management . . . . . . . . . . . . . . . . . . . . . . 94 - 8.1. Endpoint Failure Detection . . . . . . . . . . . . . . . 94 - 8.2. Path Failure Detection . . . . . . . . . . . . . . . . . 94 - 8.3. Path Heartbeat . . . . . . . . . . . . . . . . . . . . . 95 - 8.4. Handle "Out of the blue" Packets . . . . . . . . . . . . 97 - 8.5. Verification Tag . . . . . . . . . . . . . . . . . . . . 98 - 8.5.1. Exceptions in Verification Tag Rules . . . . . . . . 98 - 9. Termination of Association . . . . . . . . . . . . . . . . . 99 - 9.1. Abort of an Association . . . . . . . . . . . . . . . . . 100 - 9.2. Shutdown of an Association . . . . . . . . . . . . . . . 100 - 10. Interface with Upper Layer . . . . . . . . . . . . . . . . . 103 - 10.1. ULP-to-SCTP . . . . . . . . . . . . . . . . . . . . . . . 103 - 10.2. SCTP-to-ULP . . . . . . . . . . . . . . . . . . . . . . . 114 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 116 - 11.1. Security Objectives . . . . . . . . . . . . . . . . . . . 117 - 11.2. SCTP Responses To Potential Threats . . . . . . . . . . . 117 - 11.2.1. Countering Insider Attacks . . . . . . . . . . . . . 117 - 11.2.2. Protecting against Data Corruption in the Network . . 117 - 11.2.3. Protecting Confidentiality . . . . . . . . . . . . . 118 - 11.2.4. Protecting against Blind Denial of Service Attacks . 118 - 11.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 118 - 11.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 120 - 11.2.4.3. Improper Monopolization of Services . . . . . . 120 - 11.3. Protection against Fraud and Repudiation . . . . . . . . 121 - 12. Recommended Transmission Control Block (TCB) Parameters . . . 122 - 12.1. Parameters necessary for the SCTP instance . . . . . . . 122 - 12.2. Parameters necessary per association (i.e. the TCB) . . . 122 - 12.3. Per Transport Address Data . . . . . . . . . . . . . . . 124 - 12.4. General Parameters Needed . . . . . . . . . . . . . . . . 125 - 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125 - 13.1. IETF-defined Chunk Extension . . . . . . . . . . . . . . 126 - 13.2. IETF-defined Chunk Parameter Extension . . . . . . . . . 126 - 13.3. IETF-defined Additional Error Causes . . . . . . . . . . 127 - 13.4. Payload Protocol Identifiers . . . . . . . . . . . . . . 127 - 14. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 128 - 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 128 - Appendix A. Explicit Congestion Notification . . . . . . . . . . 128 - Appendix B. Alder 32 bit checksum calculation . . . . . . . . . 130 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 131 - 16.1. Normative references . . . . . . . . . . . . . . . . . . 131 - 16.2. Informational References . . . . . . . . . . . . . . . . 133 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 134 - Intellectual Property and Copyright Statements . . . . . . . . . 135 + COOKIE-ECHOED,COOKIE-WAIT and SHUTDOWN-ACK-SENT . . . 67 + 5.2.3. Unexpected INIT ACK . . . . . . . . . . . . . . . . . 68 + 5.2.4. Handle a COOKIE ECHO when a TCB exists . . . . . . . 68 + 5.2.5. Handle Duplicate COOKIE-ACK. . . . . . . . . . . . . 72 + 5.2.6. Handle Stale COOKIE Error . . . . . . . . . . . . . . 72 + 5.3. Other Initialization Issues . . . . . . . . . . . . . . . 72 + 5.3.1. Selection of Tag Value . . . . . . . . . . . . . . . 72 + 5.4. Path Verification . . . . . . . . . . . . . . . . . . . . 73 + 6. User Data Transfer . . . . . . . . . . . . . . . . . . . . . 74 + 6.1. Transmission of DATA Chunks . . . . . . . . . . . . . . . 76 + 6.2. Acknowledgement on Reception of DATA Chunks . . . . . . . 78 + 6.2.1. Processing a Received SACK . . . . . . . . . . . . . 81 + 6.3. Management of Retransmission Timer . . . . . . . . . . . 83 + 6.3.1. RTO Calculation . . . . . . . . . . . . . . . . . . . 83 + 6.3.2. Retransmission Timer Rules . . . . . . . . . . . . . 84 + 6.3.3. Handle T3-rtx Expiration . . . . . . . . . . . . . . 85 + 6.4. Multi-homed SCTP Endpoints . . . . . . . . . . . . . . . 86 + 6.4.1. Failover from Inactive Destination Address . . . . . 87 + 6.5. Stream Identifier and Stream Sequence Number . . . . . . 88 + 6.6. Ordered and Unordered Delivery . . . . . . . . . . . . . 88 + 6.7. Report Gaps in Received DATA TSNs . . . . . . . . . . . . 89 + 6.8. CRC-32c Checksum Calculation . . . . . . . . . . . . . . 90 + 6.9. Fragmentation and Reassembly . . . . . . . . . . . . . . 91 + 6.10. Bundling . . . . . . . . . . . . . . . . . . . . . . . . 92 + 7. Congestion control . . . . . . . . . . . . . . . . . . . . . 93 + 7.1. SCTP Differences from TCP Congestion control . . . . . . 94 + 7.2. SCTP Slow-Start and Congestion Avoidance . . . . . . . . 95 + 7.2.1. Slow-Start . . . . . . . . . . . . . . . . . . . . . 96 + 7.2.2. Congestion Avoidance . . . . . . . . . . . . . . . . 97 + 7.2.3. Congestion Control . . . . . . . . . . . . . . . . . 97 + 7.2.4. Fast Retransmit on Gap Reports . . . . . . . . . . . 98 + 7.3. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 99 + 8. Fault Management . . . . . . . . . . . . . . . . . . . . . . 101 + 8.1. Endpoint Failure Detection . . . . . . . . . . . . . . . 101 + 8.2. Path Failure Detection . . . . . . . . . . . . . . . . . 101 + 8.3. Path Heartbeat . . . . . . . . . . . . . . . . . . . . . 102 + 8.4. Handle "Out of the blue" Packets . . . . . . . . . . . . 104 + 8.5. Verification Tag . . . . . . . . . . . . . . . . . . . . 105 + 8.5.1. Exceptions in Verification Tag Rules . . . . . . . . 105 + 9. Termination of Association . . . . . . . . . . . . . . . . . 106 + 9.1. Abort of an Association . . . . . . . . . . . . . . . . . 107 + 9.2. Shutdown of an Association . . . . . . . . . . . . . . . 107 + 10. Interface with Upper Layer . . . . . . . . . . . . . . . . . 110 + 10.1. ULP-to-SCTP . . . . . . . . . . . . . . . . . . . . . . . 110 + 10.2. SCTP-to-ULP . . . . . . . . . . . . . . . . . . . . . . . 121 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 124 + 11.1. Security Objectives . . . . . . . . . . . . . . . . . . . 124 + 11.2. SCTP Responses To Potential Threats . . . . . . . . . . . 124 + 11.2.1. Countering Insider Attacks . . . . . . . . . . . . . 124 + 11.2.2. Protecting against Data Corruption in the Network . . 125 + 11.2.3. Protecting Confidentiality . . . . . . . . . . . . . 125 + 11.2.4. Protecting against Blind Denial of Service Attacks . 126 + 11.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 126 + 11.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 127 + 11.2.4.3. Improper Monopolization of Services . . . . . . 128 + 11.3. Protection against Fraud and Repudiation . . . . . . . . 128 + 11.4. SCTP Interactions with Firewalls . . . . . . . . . . . . 129 + 11.5. Protection of Non-SCTP Capable Hosts. . . . . . . . . . . 129 + 12. Recommended Transmission Control Block (TCB) Parameters . . . 130 + 12.1. Parameters necessary for the SCTP instance . . . . . . . 131 + 12.2. Parameters necessary per association (i.e. the TCB) . . . 131 + 12.3. Per Transport Address Data . . . . . . . . . . . . . . . 133 + 12.4. General Parameters Needed . . . . . . . . . . . . . . . . 134 + 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 134 + 13.1. IETF-defined Chunk Extension . . . . . . . . . . . . . . 135 + 13.2. IETF-defined Chunk Parameter Extension . . . . . . . . . 135 + 13.3. IETF-defined Additional Error Causes . . . . . . . . . . 136 + 13.4. Payload Protocol Identifiers . . . . . . . . . . . . . . 136 + 14. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 136 + 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 137 + Appendix A. Explicit Congestion Notification . . . . . . . . . . 137 + Appendix B. CRC32c Checksum Calculation . . . . . . . . . . . . 139 + Appendix C. ICMP Handling . . . . . . . . . . . . . . . . . . . 141 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 142 + 16.1. Normative references . . . . . . . . . . . . . . . . . . 142 + 16.2. Informational References . . . . . . . . . . . . . . . . 143 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 145 + Intellectual Property and Copyright Statements . . . . . . . . . 146 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 @@ -206,21 +215,21 @@ 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 eight SCTP inter- + 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 Stream Control Transmission Protocol (SCTP), the services it offers, and the basic concepts needed to understand the detailed description @@ -583,24 +592,25 @@ Note: The relationship between stream numbers in opposite directions is strictly a matter of how the applications use them. It is the responsibility of the SCTP user to create and manage these correlations if they are so desired. o Stream Sequence Number: A 16-bit sequence number used internally by SCTP to assure sequenced delivery of the user messages within a given stream. One stream sequence number is attached to each user message. - o Tie-Tags: Verification Tags from a previous association. These - Tags are used within a State Cookie so that the newly restarting - association can be linked to the original association within the - endpoint that did not restart. + o Tie-Tags: Two 32-bit random numbers that together make a 64- bit + nonce. These Tags are used within a State Cookie and TCB so that + a newly restarting association can be linked to the original + association within the endpoint that did not restart and yet not + reveal the true Verification Tags of an existing association. o Transmission Control Block (TCB): An internal data structure created by an SCTP endpoint for each of its existing SCTP associations to other SCTP endpoints. TCB contains all the status and operational information for the endpoint to maintain and manage the corresponding association. o Transmission Sequence Number (TSN): A 32-bit sequence number used internally by SCTP. One TSN is attached to each chunk containing user data to permit the receiving SCTP endpoint to acknowledge its @@ -733,27 +743,29 @@ | Verification Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Port Number: 16 bits (unsigned integer) This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port and possibly the destination IP address to - identify the association to which this packet belongs. + identify the association to which this packet belongs. The port + number 0 MUST NOT be used. Destination Port Number: 16 bits (unsigned integer) This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the - SCTP packet to the correct receiving endpoint/application. + SCTP packet to the correct receiving endpoint/application. The + port number 0 MUST NOT be used. Verification Tag: 32 bits (unsigned integer) The receiver of this packet uses the Verification Tag to validate the sender of this SCTP packet. On transmit, the value of this Verification Tag MUST be set to the value of the Initiate Tag received from the peer endpoint during the association initialization, with the following exceptions: - A packet containing an INIT chunk MUST have a zero Verification @@ -828,56 +839,66 @@ Chunk Types are encoded such that the highest-order two bits specify the action that must be taken if the processing endpoint does not recognize the Chunk Type. 00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it. 01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the - unrecognized parameter in an 'Unrecognized Parameter Type' - (in either an ERROR or in the INIT ACK). + unrecognized chunk in an 'Unrecognized Chunk Type'. 10 - Skip this chunk and continue processing. 11 - Skip this chunk and continue processing, but report in an ERROR Chunk using the 'Unrecognized Chunk Type' cause of error. Note: The ECNE and CWR chunk types are reserved for future use of Explicit Congestion Notification (ECN). Chunk Flags: 8 bits 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 transmit and are ignored on receipt. Chunk Length: 16 bits (unsigned integer) - This value represents the size of the chunk in bytes including the - Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. + This value represents the size of the chunk in bytes, including + the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any - padding. + chunk padding. + + Chunks (including Type, Length, and Value fields) are padded out + by the sender with all zero bytes to be a multiple of 4 bytes + long. This padding MUST NOT be more than 3 bytes in total. The + Chunk Length value does not include terminating padding of the + chunk. However, it does include padding of any variable-length + parameter except the last parameter in the chunk. The receiver + MUST ignore the padding. + + Note: A robust implementation should accept the Chunk whether or + not the final padding has been included in the Chunk Length. Chunk Value: variable length The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type. - The total length of a chunk (including Type, Length and Value fields) - MUST be a multiple of 4 bytes. If the length of the chunk is not a - multiple of 4 bytes, the sender MUST pad the chunk with all zero - bytes and this padding is not included in the chunk length field. - The sender should never pad with more than 3 bytes. The receiver - MUST ignore the padding bytes. + The total length of a chunk (including Type, Length, and Value + fields) MUST be a multiple of 4 bytes. If the length of the chunk is + not a multiple of 4 bytes, the sender MUST pad the chunk with all + zero bytes, and this padding is not included in the chunk length + field. The sender should never pad with more than 3 bytes. The + receiver MUST ignore the padding bytes. SCTP defined chunks are described in detail in Section 3.3. The guidelines for IETF-defined chunk extensions can be found in Section 13.1 of this document. 3.2.1. Optional/Variable-length Parameter Format Chunk values of SCTP control chunks consist of a chunk-type-specific header of required fields, followed by zero or more parameters. The optional and variable-length parameters contained in a chunk are @@ -919,37 +941,67 @@ the parameter is not a multiple of 4 bytes, the sender pads the Parameter at the end (i.e., after the Parameter Value field) with all zero bytes. The length of the padding is not included in the parameter length field. A sender SHOULD NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes. The Parameter Types are encoded such that the highest-order two bits specify the action that must be taken if the processing endpoint does not recognize the Parameter Type. - 00 - Stop processing this SCTP packet and discard it, do not - process any further chunks within it. + 00 - Stop processing this parameter; do not process any further + parameters within this chunk. - 01 - Stop processing this SCTP packet and discard it, do not - process any further chunks within it, and report the - unrecognized parameter in an 'Unrecognized Parameter Type' - (in either an ERROR or in the INIT ACK). + 01 - Stop processing this parameter, do not process any further + parameters within this chunk, and report the unrecognized + parameter in an 'Unrecognized Parameter', as described in + Section 3.2.2. 10 - Skip this parameter and continue processing. 11 - Skip this parameter and continue processing but report the - unrecognized parameter in an 'Unrecognized Parameter Type' - (in either an ERROR or in the INIT ACK). + unrecognized parameter in an 'Unrecognized Parameter', as + described in Section 3.2.2. + Please note that in all four cases an INIT-ACK or COOKIE-ECHO + chunk is sent. In the 00 or 01 case the processing of the + parameters after the unknown parameter is canceled, but no + processing already done is rolled back. The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are - defined in Section 13.2. + defined in Section 13.2. Note that a parameter type MUST be + unique across all chunks. For example, the parameter type '5' is + used to represent an IPv4 address (see Section 3.2.2). The value + '5' then is reserved across all chunks to represent an IPv4 + address and MUST NOT be reused with a different meaning in any + other chunk. + +3.2.2. Reporting of Unrecognized Parameters + + If the receiver of an INIT chunk detects unrecognized parameters and + has to report them according to Section 3.2.1, it MUST put the + 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in + response to the INIT-chunk. Note that if the receiver of the INIT + chunk is NOT going to establish an association (e.g., due to lack of + resources), an 'Unrecognized Parameter' would NOT be included with + any ABORT being sent to the sender of the INIT. + + If the receiver of an INIT-ACK chunk detects unrecognized parameters + and has to report them according to Section 3.2.1, it SHOULD bundle + the ERROR chunk containing the 'Unrecognized Parameters' error cause + with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. + If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk + with the ERROR chunk, the ERROR chunk MAY be sent separately but not + before the COOKIE-ACK has been received. + + Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the + first chunk. 3.3. SCTP Chunk Definitions This section defines the format of the different SCTP chunk types. 3.3.1. Payload Data (DATA) (0) The following format MUST be used for the DATA chunk: 0 1 2 3 @@ -1040,25 +1093,28 @@ When a user message is fragmented by SCTP for transport, the same stream sequence number MUST be carried in each of the fragments of the message. Payload Protocol Identifier: 32 bits (unsigned integer) This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP - but can be used by certain network entities as well as the peer - application to identify the type of information being carried in - this DATA chunk. This field must be sent even in fragmented DATA - chunks (to make sure it is available for agents in the middle of - the network). + but can be used by certain network entities, as well as by the + peer application, to identify the type of information being + carried in this DATA chunk. This field must be sent even in + fragmented DATA chunks (to make sure it is available for agents in + the middle of the network). Note that this field is NOT touched + by an SCTP implementation, therefore its byte order is NOT + necessarily Big Endian. The upper layer is responsible for any + byte order conversions to this field. The value 0 indicates no application identifier is specified by the upper layer for this payload data. User Data: variable length This is the payload user data. The implementation MUST pad the end of the data to a 4 byte boundary with all-zero bytes. Any padding MUST NOT be included in the length field. A sender MUST never add more than 3 bytes of padding. @@ -1109,26 +1165,33 @@ Note 1: The INIT chunks can contain multiple addresses that can be IPv4 and/or IPv6 in any combination. Note 2: The ECN capable field is reserved for future use of Explicit Congestion Notification. Note 3: An INIT chunk MUST NOT contain more than one Host Name address parameter. Moreover, the sender of the INIT MUST NOT combine 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 - address parameter is present in the received INIT chunk. + address paramete`r is present in the received INIT chunk. Note 4: This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type. + IMPLEMENTATION NOTE: If an INIT chunk is received with known + 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 of the INIT chunk MAY bundle an ERROR chunk with the + COOKIE-ACK chunk later. However, restrictive implementations MAY + send back an ABORT chunk in response to the INIT chunk. + The Chunk Flags field in INIT is reserved and all bits in it should be set to 0 by the sender and ignored by the receiver. The sequence of parameters within an INIT can be processed in any order. Initiate Tag: 32 bits (unsigned integer) The receiver of the INIT (the responding end) records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the receiver of the INIT transmits within this association. @@ -1349,37 +1412,39 @@ The receiver of the INIT ACK records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the INIT ACK receiver transmits within this association. The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for more on the selection of the Initiate Tag value. If the value of the Initiate Tag in a received INIT ACK chunk is - found to be 0, the receiver MUST treat it as an error and close - the association by transmitting an ABORT. + found to be 0, the receiver MUST destroy the association + discarding its TCB. The receiver MAY send an ABORT for debugging + purpose. Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer) This value represents the dedicated buffer space, in number of bytes, the sender of the INIT ACK has reserved in association with this window. During the life of the association this buffer space SHOULD not be lessened (i.e. dedicated buffers taken away from this association). Number of Outbound Streams (OS): 16 bits (unsigned integer) Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST - NOT be used. + NOT be used, and the value MUST NOT be greater than the MIS value + sent in the INIT chunk. Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association discarding its TCB. Number of Inbound Streams (MIS) : 16 bits (unsigned integer) Defines the maximum number of streams the sender of this INIT ACK chunk allows the peer end to create in this association. The value 0 MUST NOT be used. @@ -1402,21 +1467,21 @@ Advertised Receiver Window Credit Mandatory Number of Outbound Streams Mandatory Number of Inbound Streams Mandatory Initial TSN Mandatory Variable Parameters Status Type Value ------------------------------------------------------------- State Cookie Mandatory 7 IPv4 Address (Note 1) Optional 5 IPv6 Address (Note 1) Optional 6 - Unrecognized Parameters Optional 8 + Unrecognized Parameter Optional 8 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) Host Name Address (Note 3) Optional 11 Note 1: The INIT ACK chunks can contain any number of IP address parameters that can be IPv4 and/or IPv6 in any combination. Note 2: The ECN capable field is reserved for future use of Explicit Congestion Notification. Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name @@ -1425,20 +1490,28 @@ INIT ACK. The receiver of the INIT ACK MUST ignore any other address types if the Host Name address parameter is present. IMPLEMENTATION NOTE: An implementation MUST be prepared to receive a INIT ACK that is quite large (more than 1500 bytes) due to the variable size of the state cookie AND the variable address list. For example if a responder to the INIT has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK. + IMPLEMENTATION NOTE: If an INIT-ACK chunk is received with known + parameters that are not optional parameters of the INIT-ACK chunk, + then the receiver SHOULD process the INIT-ACK chunk and send back a + COOKIE-ECHO. The receiver of the INIT-ACK chunk MAY bundle an ERROR + chunk with the COOKIE-ECHO chunk. However, restrictive + implementations MAY send back an ABORT chunk in response to the INIT- + ACK chunk. + In combination with the Source Port carried in the SCTP common header, each IP Address parameter in the INIT ACK indicates to the receiver of the INIT ACK a valid transport address supported by the sender of the INIT ACK for the lifetime of the association being initiated. If the INIT ACK contains at least one IP Address parameter, then the source address of the IP datagram containing the INIT ACK and any additional address(es) provided within the INIT ACK may be used as destinations by the receiver of the INIT-ACK. If the INIT ACK does @@ -1459,42 +1531,43 @@ Parameter Length: variable size, depending on Size of Cookie Parameter Value: This parameter value MUST contain all the necessary state and parameter information required for the sender of this INIT ACK to create the association, along with a Message Authentication Code (MAC). See Section 5.1.3 for details on State Cookie definition. - Unrecognized Parameters: + Unrecognized Parameter: Parameter Type Value: 8 Parameter Length: Variable Size. Parameter Value: This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter which has a value that indicates that it should be reported to the sender. This parameter value field will contain unrecognized parameters copied from the INIT chunk complete with Parameter Type, Length and Value fields. 3.3.4. Selective Acknowledgement (SACK) (3): This chunk is sent to the peer endpoint to acknowledge received DATA chunks and to inform the peer endpoint of gaps in the received subsequences of DATA chunks as represented by their TSNs. - The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver - Window Credit (a_rwnd) parameters. + The SACK MUST contain the Cumulative TSN Ack, Advertised Receiver + Window Credit (a_rwnd), Number of Gap Ack Blocks, and Number of + Duplicate TSNs fields. By definition, the value of the Cumulative TSN Ack parameter is the last TSN received before a break in the sequence of received TSNs occurs; the next TSN value following this one has not yet been received at the endpoint sending the SACK. This parameter therefore acknowledges receipt of all TSNs less than or equal to its value. The handling of a_rwnd by the receiver of the SACK is discussed in detail in Section 6.2.1. @@ -1532,33 +1605,34 @@ | Duplicate TSN X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bits Set to all zeros on transmit and ignored on receipt. Cumulative TSN Ack: 32 bits (unsigned integer) This parameter contains the TSN of the last DATA chunk received in - sequence before a gap. + sequence before a gap. In the case where no DATA chunk has been + received, this value is set to the peer's Initial TSN minus one. Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer) This field indicates the updated receive buffer space in bytes of the sender of this SACK, see Section 6.2.1 for details. Number of Gap Ack Blocks: 16 bits (unsigned integer) - Indicates the number of Gap Ack Blocks included in this SACK. Number of Duplicate TSNs: 16 bit + This field contains the number of duplicate TSNs the endpoint has received. Each duplicate TSN is listed following the Gap Ack Block list. Gap Ack Blocks: These fields contain the Gap Ack Blocks. They are repeated for each Gap Ack Block up to the number of Gap Ack Blocks defined in the Number of Gap Ack Blocks field. All DATA chunks with TSNs greater than or equal to (Cumulative TSN Ack + Gap Ack Block @@ -1721,45 +1793,47 @@ 3.3.7. Abort Association (ABORT) (6): The ABORT chunk is sent to the peer of an association to close the association. The ABORT chunk may contain Cause Parameters to inform the receiver the reason of the abort. DATA chunks MUST NOT be bundled with ABORT. Control chunks (except for INIT, INIT ACK and 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 by the receiver. - If an endpoint receives an ABORT with a format error or for an - association that doesn't exist, it MUST silently discard it. - Moreover, under any circumstances, an endpoint that receives an ABORT - MUST NOT respond to that ABORT by sending an ABORT of its own. + If an endpoint receives an ABORT with a format error or no TCB is + found, it MUST silently discard it. Moreover, under any + circumstances, an endpoint that receives an ABORT MUST NOT respond to + that ABORT by sending an ABORT of its own. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 |Reserved |T| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / zero or more Error Causes / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bits Reserved: 7 bits Set to 0 on transmit and ignored on receipt. T bit: 1 bit - The T bit is set to 0 if the sender had a TCB that it destroyed. - If the sender did not have a TCB it should set this bit to 1. + The T bit is set to 0 if the sender filled in the Verification Tag + expected by the peer. If the Verification Tag is reflected, the T + bit MUST be set to 1. Reflecting means that the sent Verification + Tag is the same as the received one. Note: Special rules apply to this chunk for verification, please see Section 8.5.1 for details. Length: 16 bits (unsigned integer) Set to the size of the chunk in bytes, including the chunk header and all the Error Cause fields present. See Section 3.3.10 for Error Cause definitions. @@ -1865,31 +1939,34 @@ 1 Invalid Stream Identifier 2 Missing Mandatory Parameter 3 Stale Cookie Error 4 Out of Resource 5 Unresolvable Address 6 Unrecognized Chunk Type 7 Invalid Mandatory Parameter 8 Unrecognized Parameters 9 No User Data 10 Cookie Received While Shutting Down + 11 Restart of an Association with New Addresses + 12 User Initiated Abort + 13 Protocol Violation Cause Length: 16 bits (unsigned integer) Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields Cause-specific Information: variable length This field carries the details of the error condition. - Section 3.3.10.1 - Section 3.3.10.10 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 discussed in Section 13.3. 3.3.10.1. Invalid Stream Identifier (1) Cause of error --------------- Invalid Stream Identifier: Indicates endpoint received a DATA chunk @@ -2094,20 +2173,86 @@ Cookie Received While Shutting Down: A COOKIE ECHO was received While the endpoint was in SHUTDOWN-ACK-SENT state. This error is usually returned in an ERROR chunk bundled with the retransmitted SHUTDOWN ACK. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=10 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +3.3.10.11. Restart of an Association with New Addresses (11) + + Cause of error + + -------------- + + Restart of an association with new addresses: An INIT was received on + an existing association. But the INIT added addresses to the + association that were previously NOT part of the association. The + new addresses are listed in the error code. This ERROR is normally + sent as part of an ABORT refusing the INIT (see Section 5.2). + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cause Code=11 | Cause Length=Variable | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / New Address TLVs / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: Each New Address TLV is an exact copy of the TLV that was found + in the INIT chunk that was new, including the Parameter Type and the + Parameter length. + +3.3.10.12. User-Initiated Abort (12) + + Cause of error + -------------- + + This error cause MAY be included in ABORT chunks that are sent + because of an upper layer request. The upper layer can specify an + Upper Layer Abort Reason that is transported by SCTP transparently + and MAY be delivered to the upper layer protocol at the peer. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cause Code=12 | Cause Length=Variable | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Upper Layer Abort Reason / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +3.3.10.13. Protocol Violation (13) + + Cause of error + + -------------- + + This error cause MAY be included in ABORT chunks that are sent + because an SCTP endpoint detects a protocol violation of the peer + that is not covered by the error causes described in Section 3.3.10.1 + to Section 3.3.10.12. An implementation MAY provide additional + information specifying what kind of protocol violation has been + detected. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cause Code=13 | Cause Length=Variable | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Additional Information / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 3.3.11. Cookie Echo (COOKIE ECHO) (10): This chunk is used only during the initialization of an association. It is sent by the initiator of an association to its peer to complete the initialization process. This chunk MUST precede any DATA chunk sent within the association, but MAY be bundled with one or more DATA chunks in the same packet. 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 @@ -2128,20 +2273,26 @@ the chunk header and the size of the Cookie. Cookie: variable size This field must contain the exact cookie received in the State Cookie parameter from the previous INIT ACK. An implementation SHOULD make the cookie as small as possible to insure interoperability. + Note: A Cookie Echo does NOT contain a State Cookie Parameter; + instead, the data within the State Cookie's Parameter Value + becomes the data within the Cookie Echo's Chunk Value. This + allows an implementation to change only the first two bytes of the + State Cookie parameter to become a Cookie Echo Chunk. + 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11): This chunk is used only during the initialization of an association. It is used to acknowledge the receipt of a COOKIE ECHO chunk. This chunk MUST precede any DATA or SACK chunk sent within the association, but MAY be bundled with one or more DATA chunks or SACK chunk in the same SCTP packet. 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 @@ -2168,22 +2318,24 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bits Reserved: 7 bits Set to 0 on transmit and ignored on receipt. T bit: 1 bit - The T bit is set to 0 if the sender had a TCB that it destroyed. - If the sender did not have a TCB it should set this bit to 1. + The T bit is set to 0 if the sender filled in the Verification Tag + expected by the peer. If the Verification Tag is reflected, the T + bit MUST be set to 1. Reflecting means that the sent Verification + Tag is the same as the received one. Note: Special rules apply to this chunk for verification, please see Section 8.5.1 for details. 4. SCTP Association State Diagram During the lifetime of an SCTP association, the SCTP endpoint's association progress from one state to another in response to various events. The events that may potentially advance an association's state include: @@ -2418,53 +2569,58 @@ An endpoint MUST send the INIT ACK to the IP address from which it received the INIT. Note: T1-init timer and T1-cookie timer shall follow the same rules given in Section 6.3. If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter - values, or lack of local resources, it MUST respond with an ABORT + values, or lack of local resources, it SHOULD respond with an ABORT chunk. It SHOULD also specify the cause of abort, such as the type of the missing mandatory parameters, etc., by including the error cause parameters with the ABORT chunk. The Verification Tag field in the common header of the outbound SCTP packet containing the ABORT chunk MUST be set to the Initiate Tag value of the peer. + Note that a COOKIE ECHO chunk that does NOT pass the integrity check + is NOT considered an 'invalid parameter' and requires special + handling see Section 5.1 + After the reception of the first DATA chunk in an association the endpoint MUST immediately respond with a SACK to acknowledge the DATA chunk. Subsequent acknowledgements should be done as described in Section 6.2. When the TCB is created, each endpoint MUST set its internal Cumulative TSN Ack Point to the value of its transmitted Initial TSN minus one. IMPLEMENTATION NOTE: The IP addresses and SCTP port are generally used as the key to find the TCB within an SCTP instance. 5.1.1. Handle Stream Parameters - In the INIT and INIT ACK chunks, the sender of the chunk shall + In the INIT and INIT ACK chunks, the sender of the chunk MUST indicate the number of outbound streams (OS) it wishes to have in the association, as well as the maximum inbound streams (MIS) it will accept from the other endpoint. After receiving the stream configuration information from the other - side, each endpoint shall perform the following check: If the peer's + side, each endpoint MUST perform the following check: If the peer's MIS is less than the endpoint's OS, meaning that the peer is incapable of supporting all the outbound streams the endpoint wants - to configure, the endpoint MUST either use MIS outbound streams, or - abort the association and report to its upper layer the resources - shortage at its peer. + to configure, the endpoint MUST use MIS outbound streams and MAY + report any shortage to the upper layer. The upper layer can then + choose to abort the association if the resource shortage is + unacceptable. After the association is initialized, the valid outbound stream identifier range for either endpoint shall be 0 to min(local OS, remote MIS)-1. 5.1.2. Handle Address Parameters During the association initialization, an endpoint shall use the following rules to discover and collect the destination transport address(es) of its peer. @@ -2507,29 +2663,33 @@ The receiver of the INIT or INIT ACK MUST NOT send user data (piggy-backed or stand-alone) to its peer until the host name is successfully resolved. If the name resolution is not successful, the endpoint MUST immediately send an ABORT with "Unresolvable Address" error cause to its peer. The ABORT shall be sent to the source IP address from which the last peer packet was received. C) If there are only IPv4/IPv6 addresses present in the received INIT - or INIT ACK chunk, the receiver shall derive and record all the - transport address(es) from the received chunk AND the source IP - address that sent the INIT or INIT ACK. The transport address(es) + or INIT ACK chunk, the receiver MUST derive and record all the + transport addresses from the received chunk AND the source IP + address that sent the INIT or INIT ACK. The transport addresses are derived by the combination of SCTP source port (from the common header) and the IP address parameter(s) carried in the INIT or INIT ACK chunk and the source IP address of the IP datagram. The receiver should use only these transport addresses as destination transport addresses when sending subsequent packets to its peer. + D) An INIT or INIT ACK chunk MUST be treated as belonging to an + already established association (or one in the process of being + established) if the use of any of the valid address parameters + contained within the chunk would identify an existing TCB. IMPLEMENTATION NOTE: In some cases (e.g., when the implementation doesn't control the source IP address that is used for transmitting), an endpoint might need to include in its INIT or INIT ACK all possible IP addresses from which packets to the peer could be transmitted. After all transport addresses are derived from the INIT or INIT ACK chunk using the above rules, the endpoint shall select one of the transport addresses as the initial primary path. @@ -2544,20 +2704,35 @@ association with an "Unresolvable Address" error cause if it is unwilling or incapable of using any of the address types indicated by its peer. IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers. + IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either + IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT- ACK + chunk from its peer, it MUST use all the addresses belonging to the + supported address family. The other addresses MAY be ignored. The + endpoint SHOULD NOT respond with any kind of error indication. + + IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported + Address Types' parameter either IPv4 or IPv6, but uses the other + family for sending the packet containing the INIT chunk, or if it + also lists addresses of the other family in the INIT chunk, then the + address family that is not listed in the 'Supported Address Types' + parameter SHOULD also be considered as supported by the receiver of + the INIT chunk. The receiver of the INIT chunk SHOULD NOT respond + with any kind of error indication. + 5.1.3. Generating State Cookie When sending an INIT ACK as a response to an INIT chunk, the sender of INIT ACK creates a State Cookie and sends it in the State Cookie parameter of the INIT ACK. Inside this State Cookie, the sender should include a MAC (see [RFC2104] for an example), a time stamp on when the State Cookie is created, and the lifespan of the State Cookie, along with all the information necessary for it to establish the association. @@ -2617,102 +2792,107 @@ 1) Compute a MAC using the TCB data carried in the State Cookie and the secret key (note the timestamp in the State Cookie MAY be used to determine which secret key to use). Reference [RFC2104] can be used as a guideline for generating the MAC, 2) Authenticate the State Cookie as one that it previously generated by comparing the computed MAC against the one carried in the State Cookie. If this comparison fails, the SCTP packet, including the COOKIE ECHO and any DATA chunks, should be silently discarded, - 3) Compare the creation timestamp in the State Cookie to the current + 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 + 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, + cause to the peer endpoint. - 4) If the State Cookie is valid, create an association to the sender + 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, + carried in the COOKIE ECHO and enter the ESTABLISHED state. - 5) Send a COOKIE ACK chunk to the peer acknowledging reception of the + 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. - 6) Immediately acknowledge any DATA chunk bundled with the COOKIE + 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. + 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. If a COOKIE ECHO is received from an endpoint with which the receiver of the COOKIE ECHO has an existing association, the procedures in Section 5.2 should be followed. 5.1.6. An Example of Normal Association Establishment In the following example, "A" initiates the association and then sends a user message to "Z", then "Z" sends two user messages to "A" later (assuming no bundling or fragmentation occurs): Endpoint A Endpoint Z {app sets association with Z} (build TCB) INIT [I-Tag=Tag_A - & other info] --------\ + & other info] ------\ (Start T1-init timer) \ (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) - - /--- INIT ACK [Veri Tag=Tag_A, + /-- INIT ACK [Veri Tag=Tag_A, / I-Tag=Tag_Z, (Cancel T1-init timer) <------/ Cookie_Z, & other info] (destroy temp TCB) COOKIE ECHO [Cookie_Z] ------\ (Start T1-init timer) \ (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED state) - /---- COOKIE-ACK / (Cancel T1-init timer, <-----/ Enter ESTABLISHED state) {app sends 1st user data; strm 0} DATA [TSN=initial TSN_A - Strm=0,Seq=1 & user data]--\ + Strm=0,Seq=0 & user data]--\ (Start T3-rtx timer) \ \-> /----- SACK [TSN Ack=init - TSN_A,Block=0] + / TSN_A,Block=0] (Cancel T3-rtx timer) <------/ - ... {app sends 2 messages;strm 0} /---- DATA / [TSN=init TSN_Z - <--/ Strm=0,Seq=1 & user data 1] + <--/ Strm=0,Seq=0 & user data 1] SACK [TSN Ack=init TSN_Z, /---- DATA Block=0] --------\ / [TSN=init TSN_Z +1, - \/ Strm=0,Seq=2 & user data 2] + \/ Strm=0,Seq=1 & user data 2] <------/\ \ \------> Figure 4: INITiation Example If the T1-init timer expires at "A" after the INIT or COOKIE ECHO chunks are sent, the same INIT or COOKIE ECHO chunk with the same Initiate Tag (i.e., Tag_A) or State Cookie shall be retransmitted and + the timer restarted. This shall be repeated Max.Init.Retransmits times before "A" considers "Z" unreachable and reports the failure to its upper layer (and thus the association enters the CLOSED state). + When retransmitting the INIT, the endpoint MUST follow the rules defined in 6.3 to determine the proper timer value. 5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK During the lifetime of an association (in one of the possible states), an endpoint may receive from its peer endpoint one of the setup chunks (INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK). The receiver shall treat such a setup chunk as a duplicate and process it @@ -2742,62 +2922,87 @@ The rules in the following sections shall be applied in order to identify and correctly handle these cases. 5.2.1. INIT received in COOKIE-WAIT or COOKIE-ECHOED State (Item B) This usually indicates an initialization collision, i.e., each endpoint is attempting, at about the same time, to establish an association with the other endpoint. - Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an - endpoint MUST respond with an INIT ACK using the same parameters it - sent in its original INIT chunk (including its Initiation Tag, - unchanged). These original parameters are combined with those from - the newly received INIT chunk. The endpoint shall also generate a - State Cookie with the INIT ACK. The endpoint uses the parameters - sent in its INIT to calculate the State Cookie. + Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST + respond with an INIT ACK using the same parameters it sent in its + original INIT chunk (including its Initiation Tag, unchanged). When + responding, the endpoint MUST send the INIT ACK back to the same + address that the original INIT (sent by this endpoint) was sent to. + + Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST + respond with an INIT ACK using the same parameters it sent in its + original INIT chunk (including its Initiation Tag, unchanged), + provided that no NEW address has been added to the forming + association. If the INIT message indicates that a new address has + been added to the association, then the entire INIT MUST be + discarded, and NO changes should be made to the existing association. + An ABORT SHOULD be sent in response that MAY include the error + 'Restart of an association with new addresses'. The error SHOULD + list the addresses that were added to the restarting association. + + When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with + an INIT ACK, the original parameters are combined with those from the + newly received INIT chunk. The endpoint shall also generate a State + Cookie with the INIT ACK. The endpoint uses the parameters sent in + its INIT to calculate the State Cookie. After that, the endpoint MUST NOT change its state, the T1-init timer shall be left running and the corresponding TCB MUST NOT be destroyed. The normal procedures for handling State Cookies when a TCB exists will resolve the duplicate INITs to a single association. For an endpoint that is in the COOKIE-ECHOED state it MUST populate - its Tie-Tags with the Tag information of itself and its peer (see - Section 5.2.2 for a description of the Tie-Tags). + its Tie-Tags within both the association TCB and inside the State + Cookie (see Section 5.2.2 for a description of the Tie-Tags). 5.2.2. Unexpected INIT in States Other than CLOSED, COOKIE- ECHOED,COOKIE-WAIT and SHUTDOWN-ACK-SENT - Unless otherwise stated, upon reception of an unexpected INIT for - this association, the endpoint shall generate an INIT ACK with a - State Cookie. In the outbound INIT ACK the endpoint MUST copy its - current Verification Tag and peer's Verification Tag into a reserved - place within the state cookie. We shall refer to these locations as - the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet - containing this INIT ACK MUST carry a Verification Tag value equal to - the Initiation Tag found in the unexpected INIT. And the INIT ACK - MUST contain a new Initiation Tag (randomly generated see + Unless otherwise stated, upon receipt of an unexpected INIT for this + association, the endpoint shall generate an INIT ACK with a State + Cookie. Before responding, the endpoint MUST check to see if the + unexpected INIT adds new addresses to the association. If new + addresses are added to the association, the endpoint MUST respond + with an ABORT, copying the 'Initiation Tag' of the unexpected INIT + into the 'Verification Tag' of the outbound packet carrying the + ABORT. In the ABORT response, the cause of error MAY be set to + 'restart of an association with new addresses'. The error SHOULD + list the addresses that were added to the restarting association. If + no new addresses are added, when responding to the INIT in the + outbound INIT ACK, the endpoint MUST copy its current Tie-Tags to a + reserved place within the State Cookie and the association's TCB. We + shall refer to these locations inside the cookie as the Peer's-Tie- + Tag and the Local-Tie-Tag. We will refer to the copy within an + association's TCB as the Local Tag and Peer's Tag. The outbound SCTP + packet containing this INIT ACK MUST carry a Verification Tag value + equal to the Initiation Tag found in the unexpected INIT. And the + INIT ACK MUST contain a new Initiation Tag (randomly generated; see Section 5.3.1). Other parameters for the endpoint SHOULD be copied - from the existing parameters of the association (e.g. number of + from the existing parameters of the association (e.g., number of outbound streams) into the INIT ACK and cookie. - After sending out the INIT ACK, the endpoint shall take no further - actions, i.e., the existing association, including its current state, - and the corresponding TCB MUST NOT be changed. + After sending out the INIT ACK or ABORT, the endpoint shall take no + further actions; i.e., the existing association, including its + current state, and the corresponding TCB MUST NOT be changed. Note: Only when a TCB exists and the association is not in a COOKIE- - WAIT state are the Tie-Tags populated. For a normal association INIT - (i.e. the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be - set to 0 (indicating that no previous TCB existed). The INIT ACK and - State Cookie are populated as specified in section 5.2.1. + WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a + value other than 0. For a normal association INIT (i.e., the + endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0 + (indicating that no previous TCB existed). 5.2.3. Unexpected INIT ACK If an INIT ACK is received by an endpoint in any state other than the COOKIE-WAIT state, the endpoint should discard the INIT ACK chunk. An unexpected INIT ACK usually indicates the processing of an old or duplicated INIT chunk. 5.2.4. Handle a COOKIE ECHO when a TCB exists @@ -2810,21 +3015,21 @@ 2) Authenticate the State Cookie as described in Step 2 of Section 5.1.5 (this is case C or D above). 3) Compare the timestamp in the State Cookie to the current time. If the State Cookie is older than the lifespan carried in the State Cookie and the Verification Tags contained in the State Cookie do not match the current association's Verification Tags, the packet, including the COOKIE ECHO and any DATA chunks, should be discarded. The endpoint also MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer endpoint (this is case C or - D in section 5.2). + D in Section 5.2). If both Verification Tags in the State Cookie match the Verification Tags of the current association, consider the State Cookie valid (this is case E of section 5.2) even if the lifespan is exceeded. 4) If the State Cookie proves to be valid, unpack the TCB into a temporary TCB. 5) Refer to Table 2 to determine the correct action to be taken. @@ -2889,24 +3094,24 @@ Tag from the State Cookie, stop any init or cookie timers that may running and send a COOKIE ACK. C) In this case, the local endpoint's cookie has arrived late. Before it arrived, the local endpoint sent an INIT and received an INIT-ACK and finally sent a COOKIE ECHO with the peer's same tag but a new tag of its own. The cookie should be silently discarded. The endpoint SHOULD NOT change states and should leave any timers running. - D) When both local and remote tags match the endpoint should always - enter the ESTABLISHED state, if it has not already done so. It - should stop any init or cookie timers that may be running and send - a COOKIE ACK. + D) When both local and remote tags match, the endpoint should enter + the ESTABLISHED state, if it is in the COOKIE-ECHOED state. It + should stop any cookie timer that may be running and send a COOKIE + ACK. Note: The "peer's Verification Tag" is the tag received in the Initiate Tag field of the INIT or INIT ACK chunk. 5.2.4.1. An Example of a Association Restart In the following example, "A" initiates the association after a restart has occurred. Endpoint "Z" had no knowledge of the restart until the exchange (i.e. Heartbeats had not yet detected the failure of "A"). (assuming no bundling or fragmentation occurs): @@ -2932,34 +3137,33 @@ & other info] (destroy temp TCB,leave original in place) COOKIE ECHO [Veri=Tag_Z', Cookie_Z Tie=Tag_A, Tag_Z]----------\ (Start T1-init timer) \ (Enter COOKIE-ECHOED state) \---> (Find existing association, Tie-Tags match old tags, - Tags do not match i.e. + Tags do not match i.e., case X X M M above, Announce Restart to ULP and reset association). /---- COOKIE-ACK - / - (Cancel T1-init timer, <-----/ + (Cancel T1-init timer, <------/ Enter ESTABLISHED state) {app sends 1st user data; strm 0} DATA [TSN=initial TSN_A - Strm=0,Seq=1 & user data]--\ + Strm=0,Seq=0 & user data]--\ (Start T3-rtx timer) \ \-> - /----- SACK [TSN Ack=init TSN_A,Block=0] + /--- SACK [TSN Ack=init TSN_A,Block=0] (Cancel T3-rtx timer) <------/ Figure 5: A Restart Example 5.2.5. Handle Duplicate COOKIE-ACK. At any state other than COOKIE-ECHOED, an endpoint should silently discard a received COOKIE ACK chunk. 5.2.6. Handle Stale COOKIE Error @@ -3011,20 +3215,82 @@ also necessary to prevent old duplicate packets from previous associations being mistakenly processed as belonging to the current association. Moreover, the Verification Tag value used by either endpoint in a given association MUST NOT change during the lifetime of an association. A new Verification Tag value MUST be used each time the endpoint tears-down and then re-establishes an association to the same peer. +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. + 6. User Data Transfer Data transmission MUST only happen in the ESTABLISHED, SHUTDOWN- PENDING, and SHUTDOWN-RECEIVED states. The only exception to this is that DATA chunks are allowed to be bundled with an outbound COOKIE ECHO chunk when in COOKIE-WAIT state. DATA chunks MUST only be received according to the rules below in ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT. A DATA chunk received in CLOSED is out of the blue and SHOULD be handled per 8.4. A DATA @@ -3095,27 +3360,59 @@ This document is specified as if there is a single retransmission timer per destination transport address, but implementations MAY have a retransmission timer for each DATA chunk. The following general rules MUST be applied by the data sender for transmission and/or retransmission of outbound DATA chunks: A) At any given time, the data sender MUST NOT transmit new data to any destination transport address if its peer's rwnd indicates - that the peer has no buffer space (i.e. rwnd is 0, see + that the peer has no buffer space (i.e., rwnd is 0; see Section 6.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA - chunk in flight to the receiver if allowed by cwnd (see rule B + chunk in flight to the receiver if allowed by cwnd (see rule B, below). This rule allows the sender to probe for a change in rwnd - that the sender missed due to the SACK having been lost in transit - from the data receiver to the data sender. + that the sender missed due to the SACK's having been lost in + transit from the data receiver to the data sender. + + When the receiver's advertised window is zero, this probe is + called a zero window probe. Note that a zero window probe SHOULD + only be sent when all outstanding DATA chunks have been + cumulatively acknowledged and no DATA chunks are in flight. Zero + window probing MUST be supported. + + If the sender continues to receive new packets from the receiver + while doing zero window probing, the unacknowledged window probes + should not increment the error counter for the association or any + destination transport address.This is because the receiver MAY + keep its window closed for an indefinite time. Refer to + Section 6.2 on the receiver behavior when it advertises a zero + window. The sender SHOULD send the first zero window probe after + 1 RTO when it detects that the receiver has closed its window and + SHOULD increase the probe interval exponentially afterwards. Also + note that the cwnd SHOULD be adjusted according to Section 7.2.1. + Zero window probing does not affect the calculation of cwnd. + + The sender MUST also have an algorithm for sending new DATA chunks + to avoid silly window syndrome (SWS) as described in [RFC0813]. + The algorithm can be similar to the one described in Section + 4.2.3.4 of [RFC1122]. + + that the peer has no buffer space (i.e. rwnd is 0, see ). + + However, regardless of the value of rwnd (including if it is 0), + the data sender can always have one DATA chunk in flight to the + receiver if allowed by cwnd (see rule B below). This rule allows + the sender to probe for a change in rwnd that the sender missed + due to the SACK having been lost in transit from the data receiver + to the data sender. B) At any given time, the sender MUST NOT transmit new data to a given transport address if it has cwnd or more bytes of data outstanding to that transport address. C) When the time comes for the sender to transmit, before sending new DATA chunks, the sender MUST first transmit any outstanding DATA chunks which are marked for retransmission (limited by the current cwnd). @@ -3154,21 +3451,35 @@ When starting or restarting the T3-rtx timer, the timer value must be adjusted according to the timer rules defined in Section 6.3.2, and Section 6.3.3. Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 1 above the beginning TSN of the current send window. 6.2. Acknowledgement on Reception of DATA Chunks The SCTP endpoint MUST always acknowledge the reception of each valid - DATA chunk. + DATA chunk when the DATA chunk received is inside its receive window. + + When the receiver's advertised window is 0, the receiver MUST drop + any new incoming DATA chunk with a TSN larger than the largest TSN + received so far. If the new incoming DATA chunk holds a TSN value + less than the largest TSN received so far, then the receiver SHOULD + drop the largest TSN held for reordering and accept the new incoming + DATA chunk. In either case, if such a DATA chunk is dropped, the + receiver MUST immediately send back a SACK with the current receive + window showing only DATA chunks received and accepted so far. The + dropped DATA chunk(s) MUST NOT be included in the SACK, as they were + not accepted. The receiver MUST also have an algorithm for + advertising its receive window to avoid receiver silly window + syndrome (SWS), as described in [RFC0813]. The algorithm can be + similar to the one described in Section 4.2.3.3 of [RFC1122]. The guidelines on delayed acknowledgement algorithm specified in Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an acknowledgement SHOULD be generated for at least every second packet (not every second DATA chunk) received, and SHOULD be generated within 200 ms of the arrival of any unacknowledged DATA chunk. In some situations it may be beneficial for an SCTP transmitter to be more conservative than the algorithms detailed in this document allow. However, an SCTP transmitter MUST NOT be more aggressive than the following algorithms allow. @@ -3179,29 +3490,31 @@ IMPLEMENTATION NOTE: The maximum delay for generating an acknowledgement may be configured by the SCTP administrator, either statically or dynamically, in order to meet the specific timing requirement of the protocol being carried. An implementation MUST NOT allow the maximum delay to be configured to be more than 500 ms. In other words an implementation MAY lower this value below 500ms but MUST NOT raise it above 500ms. - Acknowledgements MUST be sent in SACK chunks unless shutdown was - requested by the ULP in which case an endpoint MAY send an + Acknowledegments MUST be sent in SACK chunks unless shutdown was + requested by the ULP, in which case an endpoint MAY send an acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk format. In particular, the SCTP endpoint MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN - greater than the value in the Cumulative TSN Ack field SHOULD also be - reported in the Gap Ack Block fields. + greater than the value in the Cumulative TSN Ack field are reported + in the Gap Ack Block fields. The SCTP endpoint MUST report as many + Gap Ack Blocks as can fit in a single SACK chunk limited by the + current path MTU. Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. Therefore, the endpoint should use a SACK instead of the SHUTDOWN chunk to acknowledge DATA chunks received out of order . When a packet arrives with duplicate DATA chunk(s) and with no new DATA chunk(s), the endpoint MUST immediately send a SACK with no delay. If a packet arrives with duplicate DATA chunk(s) bundled with new DATA chunks, the endpoint MAY immediately send a SACK. Normally receipt of duplicate DATA chunks will occur when the original SACK @@ -3344,26 +3657,29 @@ monotonically increasing, a SACK whose Cumulative TSN Ack is less than the Cumulative TSN Ack Point indicates an out-of- order SACK. ii) Set rwnd equal to the newly received a_rwnd minus the number of bytes still outstanding after processing the Cumulative TSN Ack and the Gap Ack Blocks. iii) If the SACK is missing a TSN that was previously acknowledged via a Gap Ack Block (e.g., the data receiver reneged on the - data), then mark the corresponding DATA chunk as available for - retransmit: Mark it as missing for fast retransmit as described - in Section 7.2.4 and if no retransmit timer is running for the - destination address to which the DATA chunk was originally - transmitted, then T3-rtx is started for that destination - address. + data), then consider the corresponding DATA that might be + possibly missing: Count one miss indication towards fast + retransmit as described in Section 7.2.4 , and if no retransmit + timer is running for the destination address to which the DATA + chunk was originally transmitted, then T3-rtx is started for + that destination address. + + iv) If the Cumulative TSN Ack matches or exceeds the Fast Recovery + exitpoint (Section 7.2.4), Fast Recovery is exited. 6.3. Management of Retransmission Timer An SCTP endpoint uses a retransmission timer T3-rtx to ensure data delivery in the absence of any feedback from its peer. The duration of this timer is referred to as RTO (retransmission timeout). When an endpoint's peer is multi-homed, the endpoint will calculate a separate RTO for each different destination transport address of its peer endpoint. @@ -3407,22 +3723,26 @@ then the values of RTO.Alpha and RTO.Beta in rule C3 above should be adjusted so that SRTT and RTTVAR still adjust to changes at roughly the same rate (in terms of how many round trips it takes them to reflect new values) as they would if making only one measurement per round-trip and using RTO.Alpha and RTO.Beta as given in rule C3. However, the exact nature of these adjustments remains a research issue. C5) Karn's algorithm: RTT measurements MUST NOT be made using packets that were retransmitted (and thus for which it is ambiguous - whether the reply was for the first instance of the packet or a - later instance). + whether the reply was for the first instance of the the chunk or + for a later instance) + + IMPLEMENTATION NOTE: RTT measurements should only be made using a + chunk with TSN r if no chunk with TSN less than or equal to r is + retransmitted since r is first sent. C6) Whenever RTO is computed, if it is less than RTO.Min seconds then it is rounded up to RTO.Min seconds. The reason for this rule is that RTOs that do not have a high minimum value are susceptible to unnecessary timeouts [ALLMAN99]. C7) A maximum value may be placed on RTO provided it is at least RTO.max seconds. There is no requirement for the clock granularity G used for @@ -3563,66 +3883,67 @@ which the DATA or control chunks being acknowledged were received. When a receiver of a duplicate DATA chunk sends a SACK to a multi- homed endpoint it MAY be beneficial to vary the destination address and not use the source address of the DATA chunk. The reason being that receiving a duplicate from a multi-homed endpoint might indicate that the return path (as specified in the source address of the DATA chunk) for the SACK is broken. Furthermore, when its peer is multi-homed, an endpoint SHOULD try to - retransmit a chunk to an active destination transport address that is - different from the last destination address to which the DATA chunk - was sent. + retransmit a chunk that timed out to an active destination transport + address that is different from the last destination address to which + the DATA chunk was sent. Retransmissions do not affect the total outstanding data count. However, if the DATA chunk is retransmitted onto a different destination address, both the outstanding data counts on the new destination address and the old destination address to which the data chunk was last sent shall be adjusted accordingly. 6.4.1. Failover from Inactive Destination Address Some of the transport addresses of a multi-homed SCTP endpoint may become inactive due to either the occurrence of certain error conditions (see Section 8.2) or adjustments from SCTP user. When there is outbound data to send and the primary path becomes inactive (e.g., due to failures), or where the SCTP user explicitly requests to send data to an inactive destination transport address, before reporting an error to its ULP, the SCTP endpoint should try to send the data to an alternate active destination transport address if one exists. - When retransmitting data, if the endpoint is multi-homed, it should - consider each source-destination address pair in its retransmission - selection policy. When retransmitting the endpoint should attempt to - pick the most divergent source-destination pair from the original - source-destination pair to which the packet was transmitted. + When retransmitting data that timed out, if the endpoint is multi- + homed, it should consider each source-destination address pair in its + retransmission selection policy. When retransmitting timed out data, + the endpoint should attempt to pick the most divergent source- + destination pair from the original source-destination pair to which + the packet was transmitted. Note: Rules for picking the most divergent source-destination pair are an implementation decision and is not specified within this document. 6.5. Stream Identifier and Stream Sequence Number Every DATA chunk MUST carry a valid stream identifier. If an endpoint receives a DATA chunk with an invalid stream identifier, it shall acknowledge the reception of the DATA chunk following the normal procedure, immediately send an ERROR chunk with cause set to "Invalid Stream Identifier" (see Section 3.3.10) and discard the DATA chunk. The endpoint may bundle the ERROR chunk in the same packet as the SACK as long as the ERROR follows the SACK. - The stream sequence number in all the streams shall start from 0 when + The stream sequence number in all the streams MUST start from 0 when the association is established. Also, when the stream sequence - number reaches the value 65535 the next stream sequence number shall + number reaches the value 65535 the next stream sequence number MUST be set to 0. 6.6. Ordered and Unordered Delivery Within a stream, an endpoint MUST deliver DATA chunks received with the U flag set to 0 to the upper layer according to the order of their stream sequence number. If DATA chunks arrive out of order of their stream sequence number, the endpoint MUST hold the received DATA chunks from delivery to the ULP until they are re-ordered. @@ -3699,64 +4020,74 @@ Figure 9 - Reporting a Gap using SACK 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 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, 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 numbers unacknowledged. -6.8. Adler-32 Checksum Calculation +6.8. CRC-32c 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. + 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 shall: + 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. + 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, + 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 + 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: + CRC32c checksum as follows: - 1) Store the received Adler-32 checksum value aside, + 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 an Adler-32 checksum value of - the whole received packet. And, + packet with all '0's and calculate a CRC32c checksum value of the + whole received packet. - 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. + 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. + 6.9. Fragmentation and Reassembly An endpoint MAY support fragmentation when sending DATA chunks, but - MUST support reassembly when receiving DATA chunks. If an endpoint - supports fragmentation, it MUST fragment a user message if the size - of the user message to be sent causes the outbound SCTP packet size - to exceed the current MTU. If an implementation does not support - fragmentation of outbound user messages, the endpoint must return an - error to its upper layer and not attempt to send the user message. + it MUST support reassembly when receiving DATA chunks. If an + endpoint supports fragmentation, it MUST fragment a user message if + the size of the user message to be sent causes the outbound SCTP + packet size to exceed the current MTU. If an implementation does not + support fragmentation of outbound user messages, the endpoint MUST + return an error to its upper layer and not attempt to send the user + message. + + Note: If an implementation that supports fragmentation makes + available to its upper layer a mechanism to turn off fragmentation it + may do so. However, in so doing, it MUST react just like an + implementation that does NOT support fragmentation, i.e., it MUST + reject sends that exceed the current P-MTU. IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer. If its peer is multi-homed, the endpoint shall choose a size no larger than the association Path MTU. The association Path MTU is the smallest Path MTU of all destination addresses. Note: Once a message is fragmented it cannot be re-fragmented. Instead if the PMTU has been reduced, then IP fragmentation must be @@ -3812,21 +4143,24 @@ When bundling control chunks with DATA chunks, an endpoint MUST place control chunks first in the outbound SCTP packet. The transmitter MUST transmit DATA chunks within a SCTP packet in increasing order of TSN. Note: Since control chunks must be placed first in a packet and since DATA chunks must be transmitted before SHUTDOWN or SHUTDOWN ACK chunks, DATA chunks cannot be bundled with SHUTDOWN or SHUTDOWN ACK chunks. - Partial chunks MUST NOT be placed in an SCTP packet. + Partial chunks MUST NOT be placed in an SCTP packet. A partial chunk + is a chunk that is not completely contained in the SCTP packet; i.e., + the SCTP packet is too short to contain all the bytes of the chunk as + indicated by the chunk length. An endpoint MUST process received chunks in their order in the packet. The receiver uses the chunk length field to determine the end of a chunk and beginning of the next chunk taking account of the fact that all chunks end on a 4 byte boundary. If the receiver detects a partial chunk, it MUST drop the chunk. An endpoint MUST NOT bundle INIT, INIT ACK or SHUTDOWN COMPLETE with any other chunks. @@ -3955,39 +4289,43 @@ 7.2.1. Slow-Start Beginning data transmission into a network with unknown conditions or after a sufficiently long idle period requires SCTP to probe the network to determine the available capacity. The slow start algorithm is used for this purpose at the beginning of a transfer, or after repairing loss detected by the retransmission timer. o The initial cwnd before DATA transmission or after a sufficiently - long idle period MUST be <= 2*MTU. + long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 + bytes)). o The initial cwnd after a retransmission timeout MUST be no more than 1*MTU. o The initial value of ssthresh MAY be arbitrarily high (for example, implementations MAY use the size of the receiver advertised window). o Whenever cwnd is greater than zero, the endpoint is allowed to have cwnd bytes of data outstanding on that transport address. - o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST - use the slow start algorithm to increase cwnd (assuming the - current congestion window is being fully utilized). If an - incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be - increased by at most the lesser of 1) the total size of the - previously outstanding DATA chunk(s) acknowledged, and 2) the - destination's path MTU. This protects against the ACK-Splitting + o When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST + use the slow start algorithm to increase cwnd only if the current + congestion window is being fully utilized, an incoming SACK + advances the Cumulative TSN Ack Point, and the data sender is not + in Fast Recovery. Only when these three conditions are met can + the cwnd be increased; otherwise, the cwnd MUST not be increased. + If these conditions are met, then cwnd MUST be increased by, at + most, the lesser of 1) the total size of the previously + outstanding DATA chunk(s) acknowledged, and 2) the destination's + path MTU. This upper bound protects against the ACK-Splitting attack outlined in [SAVAGE99]. In instances where its peer endpoint is multi-homed, if an endpoint receives a SACK that advances its Cumulative TSN Ack Point, then it should update its cwnd (or cwnds) apportioned to the destination addresses to which it transmitted the acknowledged data. However if the received SACK does not advance the Cumulative TSN Ack Point, the endpoint MUST NOT adjust the cwnd of any of the destination addresses. @@ -3990,29 +4328,30 @@ the received SACK does not advance the Cumulative TSN Ack Point, the endpoint MUST NOT adjust the cwnd of any of the destination addresses. Because an endpoint's cwnd is not tied to its Cumulative TSN Ack Point, as duplicate SACKs come in, even though they may not advance the Cumulative TSN Ack Point an endpoint can still use them to clock out new data. That is, the data newly acknowledged by the SACK diminishes the amount of data now in flight to less than cwnd; and so the current, unchanged value of cwnd now allows new data to be sent. + On the other hand, the increase of cwnd must be tied to the Cumulative TSN Ack Point advancement as specified above. Otherwise the duplicate SACKs will not only clock out new data, but also will adversely clock out more new data than what has just left the network, during a time of possible congestion. o When the endpoint does not transmit data on a given transport address, the cwnd of the transport address should be adjusted to - max(cwnd/2, 2*MTU) per RTO. + max(cwnd/2, 4*MTU) per RTO. 7.2.2. Congestion Avoidance When cwnd is greater than ssthresh, cwnd should be incremented by 1*MTU per RTT if the sender has cwnd or more bytes of data outstanding for the corresponding transport address. In practice an implementation can achieve this goal in the following way: @@ -4025,76 +4364,105 @@ Cumulative TSN Ack and by Gap Ack Blocks. o When partial_bytes_acked is equal to or greater than cwnd and before the arrival of the SACK the sender had cwnd or more bytes of data outstanding (i.e., before arrival of the SACK, flightsize was greater than or equal to cwnd), increase cwnd by MTU, and reset partial_bytes_acked to (partial_bytes_acked - cwnd). o Same as in the slow start, when the sender does not transmit DATA on a given transport address, the cwnd of the transport address - should be adjusted to max(cwnd / 2, 2*MTU) per RTO. + should be adjusted to max(cwnd / 2, 4*MTU) per RTO. o When all of the data transmitted by the sender has been acknowledged by the receiver, partial_bytes_acked is initialized to 0. 7.2.3. Congestion Control Upon detection of packet losses from SACK (see Section 7.2.4), An endpoint should do the following: - ssthresh = max(cwnd/2, 2*MTU) + ssthresh = max(cwnd/2, 4*MTU) cwnd = ssthresh + partial_bytes_acked = 0 Basically, a packet loss causes cwnd to be cut in half. When the T3-rtx timer expires on an address, SCTP should perform slow start by: - ssthresh = max(cwnd/2, 2*MTU) + ssthresh = max(cwnd/2, 4*MTU) cwnd = 1*MTU and assure that no more than one SCTP packet will be in flight for that address until the endpoint receives acknowledgement for successful delivery of data to that address. 7.2.4. Fast Retransmit on Gap Reports In the absence of data loss, an endpoint performs delayed acknowledgement. However, whenever an endpoint notices a hole in the arriving TSN sequence, it SHOULD start sending a SACK back every time a packet arrives carrying data until the hole is filled. - Whenever an endpoint receives a SACK that indicates some TSN(s) - missing, it SHOULD wait for 3 further miss indications (via - subsequent SACK's) on the same TSN(s) before taking action with - regard to Fast Retransmit. + Whenever an endpoint receives a SACK that indicates that some TSNs + are missing, it SHOULD wait for 2 further miss indications (via + subsequent SACKs for a total of 3 missing reports) on the same TSNs + before taking action with regard to Fast Retransmit. - When the TSN(s) is reported as missing in the fourth consecutive - SACK, the data sender shall: + Miss indications SHOULD follow the HTNA (Highest TSN Newly + Acknowledged) algorithm. For each incoming SACK, miss indications + are incremented only for missing TSNs prior to the highest TSN newly + acknowledged in the SACK. A newly acknowledged DATA chunk is one not + previously acknowledged in a SACK. If an endpoint is in Fast + Recovery and a SACK arrives that advances the Cumulative TSN Ack + Point, the miss indications are incremented for all TSNs reported + missing in the SACK. - 1) Mark the missing DATA chunk(s) for retransmission, + When the third consecutive miss indication is received for a TSN(s), + the data sender shall do the following: - 2) Adjust the ssthresh and cwnd of the destination address(es) to - which the missing DATA chunks were last sent, according to the - formula described in Section 7.2.3. + 1) Mark the DATA chunk(s) with three miss indications for + retransmission. + + 2) If not in Fast Recovery, adjust the ssthresh and cwnd of the + destination address(es) to which the missing DATA chunks were last + sent, according to the formula described in Section 7.2.3. 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks marked for retransmission will fit into a single packet, subject to constraint of the path MTU of the destination transport address to which the packet is being sent. Call this value K. Retransmit - those K DATA chunks in a single packet. + those K DATA chunks in a single packet. When a Fast Retransmit is + being performed, the sender SHOULD ignore the value of cwnd and + SHOULD NOT delay retransmission for this single packet. 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest outstanding TSN number sent to that address, or the endpoint is retransmitting the first outstanding DATA chunk sent to that address. + 5) Mark the DATA chunk(s) as being fast retransmitted and thus + ineligible for a subsequent fast retransmit. Those TSNs marked + for retransmission due to the Fast Retransmit algorithm that did + not fit in the sent datagram carrying K other TSNs are also marked + as ineligible for a subsequent fast retransmit. However, as they + are marked for retransmission they will be retransmitted later on + as soon as cwnd allows. + + 6) If not in Fast Recovery, enter Fast Recovery and mark the highest + outstanding TSN as the Fast Recovery exit point. When a SACK + acknowledges all TSNs up to and including this exit point, Fast + Recovery is exited. While in Fast Recovery, the ssthresh and cwnd + SHOULD NOT change for any destinations due to a subsequent Fast + Recovery event (i.e., one SHOULD NOT reduce the cwnd further due + to a subsequent fast retransmit). + Note: Before the above adjustments, if the received SACK also acknowledges new DATA chunks and advances the Cumulative TSN Ack Point, the cwnd adjustment rules defined in Section 7.2.1 and Section 7.2.2 must be applied first. A straightforward implementation of the above keeps a counter for each TSN hole reported by a SACK. The counter increments for each consecutive SACK reporting the TSN hole. After reaching 4 and starting the fast retransmit procedure, the counter resets to 0. @@ -4154,32 +4522,20 @@ discovery in [RFC1191] and [RFC1981] applies to SCTP on a per- destination-address basis. Note: For IPv6 destination addresses the DF bit does not exist, instead the IP datagram must be fragmented as described in [RFC2460]. 8. Fault Management 8.1. Endpoint Failure Detection - An endpoint shall keep a counter on the total number of consecutive - retransmissions to its peer (including retransmissions to all the - destination transport addresses of the peer if it is multi-homed). - If the value of this counter exceeds the limit indicated in the - protocol parameter 'Association.Max.Retrans', the endpoint shall - consider the peer endpoint unreachable and shall stop transmitting - any more data to it (and thus the association enters the CLOSED - state). In addition, the endpoint shall report the failure to the - upper layer, and optionally report back all outstanding user data - remaining in its outbound queue. The association is automatically - closed when the peer endpoint becomes unreachable. - The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK), or a HEARTBEAT-ACK is received from the peer endpoint. 8.2. Path Failure Detection When its peer endpoint is multi-homed, an endpoint should keep a error counter for each of the destination transport addresses of the peer endpoint. @@ -4213,24 +4569,30 @@ When the primary path is marked inactive (due to excessive retransmissions, for instance), the sender MAY automatically transmit new packets to an alternate destination address if one exists and is active. If more than one alternate address is active when the primary path is marked inactive only ONE transport address SHOULD be chosen and used as the new destination transport address. 8.3. Path Heartbeat - By default, an SCTP endpoint shall monitor the reachability of the + By default, an SCTP endpoint SHOULD monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport - address(es). + address(es). HEARTBEAT sending MAY begin upon reaching the + ESTABLISHED state and is discontinued after sending either SHUTDOWN + or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a + HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state + (INIT sender) or the ESTABLISHED state (INIT receiver), up until + reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- + ACK-SENT state (SHUTDOWN receiver). A destination transport address is considered "idle" if no new chunk which can be used for updating path RTT (usually including first transmission DATA, INIT, COOKIE ECHO, HEARTBEAT etc.) and no HEARTBEAT has been sent to it within the current heartbeat period of that address. This applies to both active and inactive destination addresses. The upper layer can optionally initiate the following functions: @@ -4262,41 +4625,42 @@ IMPLEMENTATION NOTE: An alternative implementation of the heartbeat mechanism that can be used is to increment the error counter variable every time a HEARTBEAT is sent to a destination. Whenever a HEARTBEAT ACK arrives, the sender SHOULD clear the error counter of the destination that the HEARTBEAT was sent to. This in effect would clear the previously stroked error (and any other error counts as well). The receiver of the HEARTBEAT should immediately respond with a - HEARTBEAT ACK that contains the Heartbeat Information field copied - from the received HEARTBEAT chunk. + HEARTBEAT ACK that contains the Heartbeat Information TLV, together + with any other received TLVs, copied unchanged from the received + HEARTBEAT chunk. Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT should clear the error counter of the destination transport address to which the HEARTBEAT was sent, and mark the destination transport address as active if it is not so marked. The endpoint may optionally report to the upper layer when an inactive destination address is marked as active due to the reception of the latest HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the - association overall error count as well (as defined in section 8.1). + association overall error count as well (as defined in Section 8.1). The receiver of the HEARTBEAT ACK should also perform an RTT measurement for that destination transport address using the time value carried in the HEARTBEAT ACK chunk. - On an idle destination address that is allowed to heartbeat, a - HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that + On an idle destination address that is allowed to heartbeat, it is + recommended that a HEARTBEAT chunk is sent once per RTO of that destination address plus the protocol parameter 'HB.interval' , with - jittering of +/- 50%, and exponential back-off of the RTO if the - previous HEARTBEAT is unanswered. + jittering of +/- 50% of the RTO value, and exponential back-off of + the RTO if the previous HEARTBEAT is unanswered. A primitive is provided for the SCTP user to change the HB.interval and turn on or off the heartbeat on a given destination address. The heartbeat interval set by the SCTP user is added to the RTO of that destination (including any exponential backoff). Only one heartbeat should be sent each time the heartbeat timer expires (if multiple destinations are idle). It is a implementation decision on how to choose which of the candidate idle destinations to heartbeat to (if more than one destination is idle). @@ -4307,60 +4671,66 @@ reason and the ABORT chunk is lost, the local endpoint will only discover the lost ABORT by sending a DATA chunk or HEARTBEAT chunk (thus causing the peer to send another ABORT). This must be considered when tuning the HEARTBEAT timer. If the HEARTBEAT is disabled only sending DATA to the association will discover a lost ABORT from the peer. 8.4. Handle "Out of the blue" Packets An SCTP packet is called an "out of the blue" (OOTB) packet if it is - correctly formed, i.e., passed the receiver's Adler-32 check (see + correctly formed (i.e., passed the receiver's CRC32c check; see Section 6.8), but the receiver is not able to identify the association to which this packet belongs. The receiver of an OOTB packet MUST do the following: - 1) If the OOTB packet is to or from a non-unicast address, silently - discard the packet. Otherwise, + 1) If the OOTB packet is to or from a non-unicast address, a receiver + SHOULD silently discard the packet. Otherwise, 2) If the OOTB packet contains an ABORT chunk, the receiver MUST silently discard the OOTB packet and take no further action. Otherwise, 3) If the packet contains an INIT chunk with a Verification Tag set - to '0', process it as described in Section 5.1. Otherwise, + to '0', process it as described in Section 5.1. If, for whatever + reason, the INIT cannot be processed normally and an ABORT has to + be sent in response, the Verification Tag of the packet containing + the ABORT chunk MUST be the Initiate tag of the received INIT + chunk, and the T-Bit of the ABORT chunk has to be set to 0, + indicating that the Verification Tag is NOT reflected. 4) If the packet contains a COOKIE ECHO in the first chunk, process it as described in Section 5.1. Otherwise, + 5) If the packet contains a SHUTDOWN ACK chunk, the receiver should respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet must fill in the Verification Tag field of the outbound packet with the Verification Tag received in the SHUTDOWN ACK and - set the T-bit in the Chunk Flags to indicate that no TCB was - found. Otherwise, + set the T-bit in the Chunk Flags to indicate that the Verification + Tag is reflected. Otherwise, 6) If the packet contains a SHUTDOWN COMPLETE chunk, the receiver should silently discard the packet and take no further action. Otherwise, - 7) If the packet contains a "Stale cookie" ERROR or a COOKIE ACK the SCTP Packet should be silently discarded. Otherwise, 8) The receiver should respond to the sender of the OOTB packet with an ABORT. When sending the ABORT, the receiver of the OOTB packet MUST fill in the Verification Tag field of the outbound packet with the value found in the Verification Tag field of the OOTB - packet and set the T-bit in the Chunk Flags to indicate that no - TCB was found. After sending this ABORT, the receiver of the OOTB - packet shall discard the OOTB packet and take no further action. + packet and set the T-bit in the Chunk Flags to indicate that the + Verification Tag is reflected. After sending this ABORT, the + receiver of the OOTB packet shall discard the OOTB packet and take + no further action. 8.5. Verification Tag The Verification Tag rules defined in this section apply when sending or receiving SCTP packets which do not contain an INIT, SHUTDOWN COMPLETE, COOKIE ECHO (see Section 5.1), ABORT or SHUTDOWN ACK chunk. The rules for sending and receiving SCTP packets containing one of these chunk types are discussed separately in Section 8.5.1. When sending an SCTP packet, the endpoint MUST fill in the @@ -4381,45 +4751,48 @@ - The sender MUST set the Verification Tag of the packet to 0. - When an endpoint receives an SCTP packet with the Verification Tag set to 0, it should verify that the packet contains only an INIT chunk. Otherwise, the receiver MUST silently discard the packet. B) Rules for packet carrying ABORT: - - The endpoint shall always fill in the Verification Tag field of - the outbound packet with the destination endpoint's tag value if + - The endpoint MUST always fill in the Verification Tag field of + the outbound packet with the destination endpoint's tag value, if it is known. - If the ABORT is sent in response to an OOTB packet, the endpoint - MUST follow the procedure described in Section 8.4. + MUST follow the procedure described in Section 8.4 - - The receiver MUST accept the packet if the Verification Tag - matches either its own tag, OR the tag of its peer. Otherwise, - the receiver MUST silently discard the packet and take no further - action. + - The receiver of an ABORT MUST accept the packet if the + Verification Tag field of the packet matches its own tag and the + T bit is not set OR if it is set to its peer's tag and the T bit + is set in the Chunk Flags. Otherwise, the receiver MUST silently + discard the packet and take no further action. C) Rules for packet carrying SHUTDOWN COMPLETE: - When sending a SHUTDOWN COMPLETE, if the receiver of the SHUTDOWN - ACK has a TCB then the destination endpoint's tag MUST be used. - Only where no TCB exists should the sender use the Verification - Tag from the SHUTDOWN ACK. + ACK has a TCB, then the destination endpoint's tag MUST be used, + and the T-bit MUST NOT be set. Only where no TCB exists should + the sender use the Verification Tag from the SHUTDOWN ACK, and + MUST set the T-bit. - The receiver of a SHUTDOWN COMPLETE shall accept the packet if - the Verification Tag field of the packet matches its own tag OR - it is set to its peer's tag and the T bit is set in the Chunk - Flags. Otherwise, the receiver MUST silently discard the packet - and take no further action. An endpoint MUST ignore the SHUTDOWN - COMPLETE if it is not in the SHUTDOWN-ACK-SENT state. + the Verification Tag field of the packet matches its own tag and + the T bit is not set OR if it is set to its peer's tag and the T + bit is set in the Chunk Flags. Otherwise, the receiver MUST + silently discard the packet and take no further action. An + endpoint MUST ignore the SHUTDOWN COMPLETE if it is not in the + SHUTDOWN-ACK-SENT state. D) Rules for packet carrying a COOKIE ECHO - When sending a COOKIE ECHO, the endpoint MUST use the value of the Initial Tag received in the INIT ACK. - The receiver of a COOKIE ECHO follows the procedures in Section 5. E) Rules for packet carrying a SHUTDOWN ACK @@ -4416,55 +4789,60 @@ D) Rules for packet carrying a COOKIE ECHO - When sending a COOKIE ECHO, the endpoint MUST use the value of the Initial Tag received in the INIT ACK. - The receiver of a COOKIE ECHO follows the procedures in Section 5. E) Rules for packet carrying a SHUTDOWN ACK + - If the receiver is in COOKIE-ECHOED or COOKIE-WAIT state the - procedures in section 8.4 SHOULD be followed, in other words it + procedures in Section 8.4 SHOULD be followed, in other words it should be treated as an Out Of The Blue packet. 9. Termination of Association An endpoint should terminate its association when it exits from service. An association can be terminated by either abort or shutdown. An abort of an association is abortive by definition in that any data pending on either end of the association is discarded and not delivered to the peer. A shutdown of an association is considered a graceful close where all data in queue by either endpoint is delivered to the respective peers. However, in the case of a shutdown, SCTP does not support a half-open state (like TCP) wherein one side may continue sending data while the other end is closed. When either endpoint performs a shutdown, the association on each peer will stop accepting new data from its user and only deliver data in queue at the time of sending or receiving the SHUTDOWN chunk. 9.1. Abort of an Association - When an endpoint decides to abort an existing association, it shall + When an endpoint decides to abort an existing association, it MUST send an ABORT chunk to its peer endpoint. The sender MUST fill in the peer's Verification Tag in the outbound packet and MUST NOT - bundle any DATA chunk with the ABORT. + bundle any DATA chunk with the ABORT. If the association is aborted + on request of the upper layer, a User-Initiated Abort error cause + (see Section 3.3.10.12) SHOULD be present in the ABORT chunk. An endpoint MUST NOT respond to any received packet that contains an ABORT chunk (also see Section 8.4). - An endpoint receiving an ABORT shall apply the special Verification + An endpoint receiving an ABORT MUST apply the special Verification Tag check rules described in Section 8.5.1. - After checking the Verification Tag, the receiving endpoint shall - remove the association from its record, and shall report the - termination to its upper layer. + After checking the Verification Tag, the receiving endpoint MUST + remove the association from its record and SHOULD report the + termination to its upper layer. If a User-Initiated Abort error + cause is present in the ABORT chunk, the Upper Layer Abort Reason + SHOULD be made available to the upper layer. 9.2. Shutdown of an Association Using the SHUTDOWN primitive (see Section 10.1), the upper layer of an endpoint in an association can gracefully close the association. This will allow all outstanding DATA chunks from the peer of the shutdown initiator to be delivered before the association terminates. Upon receipt of the SHUTDOWN primitive from its upper layer, the endpoint enters SHUTDOWN-PENDING state and remains there until all @@ -4502,32 +4881,44 @@ - verify, by checking the Cumulative TSN Ack field of the chunk, that all its outstanding DATA chunks have been received by the SHUTDOWN sender. Once an endpoint as reached the SHUTDOWN-RECEIVED state it MUST NOT send a SHUTDOWN in response to a ULP request, and should discard subsequent SHUTDOWN chunks. If there are still outstanding DATA chunks left, the SHUTDOWN - receiver shall continue to follow normal data transmission procedures - defined in Section 6 until all outstanding DATA chunks are + receiver MUST continue to follow normal data transmission procedures + defined in Section 6, until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user. While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately - respond to each received packet containing one or more DATA chunk(s) - with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If - it has no more outstanding DATA chunks, the SHUTDOWN receiver shall - send a SHUTDOWN ACK and start a T2-shutdown timer of its own, - entering the SHUTDOWN-ACK-SENT state. If the timer expires, the - endpoint must re-send the SHUTDOWN ACK. + respond to each received packet containing one or more DATA chunks + with a SHUTDOWN chunk and restart the T2-shutdown timer. If a + SHUTDOWN chunk by itself cannot acknowledge all of the received DATA + 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 + if duplicate TSNs have been received, then a SACK chunk MUST also be + sent. + + The sender of the SHUTDOWN MAY also start an overall guard timer 'T5- + shutdown-guard' to bound the overall time for shutdown sequence. At + the expiration of this timer, the sender SHOULD abort the association + by sending an ABORT chunk. If the 'T5-shutdown-guard' 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, + the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a T2- + shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If + the timer expires, the endpoint must re-send the SHUTDOWN ACK. The sender of the SHUTDOWN ACK should limit the number of retransmissions of the SHUTDOWN ACK chunk to the protocol parameter ' Association.Max.Retrans'. If this threshold is exceeded the endpoint should destroy the TCB and may report the peer endpoint unreachable to the upper layer (and thus the association enters the CLOSED state). Upon the receipt of the SHUTDOWN ACK, the SHUTDOWN sender shall stop the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its peer, @@ -4699,42 +5089,44 @@ Gracefully closes an association. Any locally queued user data will be delivered to the peer. The association will be terminated only after the peer acknowledges all the SCTP packets sent. A success code will be returned on successful termination of the association. If attempting to terminate the association results in a failure, an error code shall be returned. Mandatory attributes: o association id - local handle to the SCTP association + Optional attributes: None. D) Abort - Format: ABORT(association id [, cause code]) + Format: ABORT(association id [, Upper Layer Abort Reason]) -> result Ungracefully closes an association. Any locally queued user data - will be discarded and an ABORT chunk is sent to the peer. A success + will be discarded, and an ABORT chunk is sent to the peer. A success code will be returned on successful abortion of the association. If attempting to abort the association results in a failure, an error code shall be returned. Mandatory attributes: o association id - local handle to the SCTP association Optional attributes: - o cause code - reason of the abort to be passed to the peer. + o Upper Layer Abort Reason - Reason of the abort to be passed to the + peer. None. E) Send Format: SEND(association id, buffer address, byte count [,context] [,stream id] [,life time] [,destination transport address] [,unorder flag] [,no-bundle flag] [,payload protocol-id] ) -> result @@ -5159,41 +5553,42 @@ When SCTP loses communication to an endpoint completely (e.g., via Heartbeats) or detects that the endpoint has performed an abort operation, it shall invoke this notification on the ULP. The following shall be passed with the notification: o association id - local handle to the SCTP association o status - This indicates what type of event has occurred; The status - may indicate 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. The following may be passed with the notification: o data retrieval id - an identification used to retrieve unsent and unacknowledged data. - o last-acked - the TSN last acked by that peer endpoint; + o last-acked - the TSN last acked by that peer endpoint. - o last-sent - the TSN last sent to that peer endpoint; + o last-sent - the TSN last sent to that peer endpoint. + o Upper Layer Abort Reason - The abort reason specified in case of a + user-initiated abort. F) COMMUNICATION ERROR notification When SCTP receives an ERROR chunk from its peer and decides to notify its ULP, it can invoke this notification on the ULP. The following can be passed with the notification: o association id - local handle to the SCTP association - o error info - this indicates the type of error and optionally some additional information received through the ERROR chunk. G) RESTART notification When SCTP detects that the peer has restarted, it may send this notification to its ULP. The following can be passed with the notification: @@ -5447,20 +5841,64 @@ repudiation is an issue, the use of the IPSEC AH service is recommended to ensure both the integrity and the authenticity of the SCTP packets passed. SCTP also provides no protection against attacks originating at or beyond the SCTP node and taking place within the context of an existing association. Prevention of such attacks should be covered by appropriate security policies at the host site, as discussed in Section 11.2.1. +11.4. SCTP Interactions with Firewalls + + It is helpful for some firewalls if they can inspect just the first + fragment of a fragmented SCTP packet and unambiguously determine + whether it corresponds to an INIT chunk (for further information, + please refer to [RFC1858]). Accordingly, we stress the requirements, + stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled + with any other chunk in a packet, and (2) a packet containing an INIT + chunk MUST have a zero Verification Tag. Furthermore, we require that + the receiver of an INIT chunk MUST enforce these rules by silently + discarding an arriving packet with an INIT chunk that is bundled with + other chunks. + +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. + 12. Recommended Transmission Control Block (TCB) Parameters This section details a recommended set of parameters that should be contained within the TCB for an implementation. This section is for illustrative purposes and should not be deemed as requirements on an implementation or as an exhaustive list of all parameters inside an SCTP TCB. Each implementation may need its own additional parameters for optimization. 12.1. Parameters necessary for the SCTP instance @@ -5628,26 +6067,23 @@ -- through definition of additional chunk types, -- through definition of additional parameter types, or -- through definition of additional cause codes within ERROR chunks In the case where a particular ULP using SCTP desires to have its own ports, the ULP should be responsible for registering with IANA for getting its ports assigned. 13.1. IETF-defined Chunk Extension - The definition and use of new chunk types is an integral part of - SCTP. Thus, new chunk types are assigned by IANA through an IETF - Consensus action as defined in [RFC2434]. - - The documentation for a new chunk code type must include the - following information: + The assignment of new chunk parameter type codes is done through an + IETF Consensus action, as defined in [RFC2434]. Documentation of the + chunk parameter MUST contain the following information: a) A long and short name for the new chunk type; b) A detailed description of the structure of the chunk, which MUST conform to the basic structure defined in Section 3.2; c) A detailed definition and description of intended use of each field within the chunk, including the chunk flags if any; d) A detailed procedural description of the use of the new chunk type @@ -5667,20 +6103,21 @@ b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.2.1. c) Detailed definition of each component of the parameter value. d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same chunk. + e) Each parameter type MUST be unique across all chunks. 13.3. IETF-defined Additional Error Causes Additional cause codes may be allocated in the range 11 to 65535 through a Specification Required action as defined in [RFC2434]. Provided documentation must include the following information: a) Name of the error condition. b) Detailed description of the conditions under which an SCTP @@ -5710,27 +6147,29 @@ protocol identifier with IANA if it is so desired. The use of any specific payload protocol identifier is out of the scope of SCTP. 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 IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to customize some of these protocol parameters (see Section 10). Note: RTO.Min SHOULD be set as recommended above. 15. Acknowledgements The authors wish to thank Mark Allman, R.J. Atkinson, Richard Band, Scott Bradner, Steve Bellovin, Peter Butler, Ram Dantu, R. @@ -5802,101 +6241,188 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Type=13 | Flags=00000000| Chunk Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lowest TSN Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The CWR is considered a Control chunk. -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. +Appendix B. CRC32c Checksum Calculation - 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: + 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. - & Bitwise AND operator. + 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. - >> Bitwise right shift operator. When applied to an unsigned - quantity, as here, right shift inserts zero bit(s) at the left. + 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. - << Bitwise left shift operator. Left shift inserts zero bit(s) at - the right. + 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. - ++ "n++" increments the variable n. + The SCTP transport-level CRC value should be calculated as follows: - % modulo operator: a % b is the remainder of a divided by b. + - CRC input data are assigned to a byte stream, numbered from 0 to + N-1. + - The transport-level byte-stream is mapped to a polynomial value. + An N-byte PDU with j bytes numbered 0 to N-1 is considered as + coefficients of a polynomial M(x) of order 8N-1, with bit 0 of + byte j being coefficient x^(8(N-j)-8), and bit 7 of byte j being + coefficient x^(8(N-j)-1). + - The CRC remainder register is initialized with all 1s and the CRC + is computed with an algorithm that simultaneously multiplies by + x^32 and divides by the CRC polynomial. + - The polynomial is multiplied by x^32 and divided by G(x), the + generator polynomial, producing a remainder R(x) of degree less + than or equal to 31. + - The coefficients of R(x) are considered a 32-bit sequence. + - The bit sequence is complemented. The result is the CRC + polynomial. + - The CRC polynomial is mapped back into SCTP transport-level bytes. + The coefficient of x^31 gives the value of bit 7 of SCTP byte 0, + and the coefficient of x^24 gives the value of bit 0 of byte 0. + The coefficient of x^7 gives bit 7 of byte 3, and the coefficient + of x^0 gives bit 0 of byte 3. The resulting four-byte transport- + level sequence is the 32-bit SCTP checksum value. - #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. + IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor + literature on CRCs often follow an alternative formulation, in which + the register used to hold the remainder of the long-division + algorithm is initialized to zero rather than all-1s, and instead the + first 32 bits of the message are complemented. The long-division + algorithm used in our formulation is specified such that the initial + multiplication by 2^32 and the long-division are combined into one + simultaneous operation. For such algorithms, and for messages longer + than 64 bits, the two specifications are precisely equivalent. That + equivalence is the intent of this document. - Usage example: + Implementors of SCTP are warned that both specifications are to be + found in the literature, sometimes with no restriction on the long- + division algorithm. The choice of formulation in this document is to + permit non-SCTP usage, where the same CRC algorithm may be used to + protect messages shorter than 64 bits. - unsigned long adler = 1L; + There may be a computational advantage in validating the Association + against the Verification Tag, prior to performing a checksum, as + invalid tags will result in the same action as a bad checksum in most + cases. The exceptions for this technique would be INIT and some + SHUTDOWN-COMPLETE exchanges, as well as a stale COOKIE-ECHO. These + special case exchanges must represent small packets and will minimize + the effect of the checksum calculation. - 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; +Appendix C. ICMP Handling - for (n = 0; n < len; n++) { - s1 = (s1 + buf[n]) % BASE; - s2 = (s2 + s1) % BASE; - } - return (s2 << 16) + s1; - } + 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. - /* Return the adler32 of the bytes buf[0..len-1] */ - unsigned long adler32(unsigned char *buf, int len) - { - return update_adler32(1L, buf, len); - } + Note that these procedures differ from [RFC1122] 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. 16. References 16.1. Normative references + [ITU32] "ITU-T Recommendation V.42, "Error-correcting procedures + for DCEs using asynchronous-to-synchronous conversion".", + ITU-T section 8.1.1.6.2. + [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. + [RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP", + RFC 813, July 1982. + + [RFC1122] Braden, R., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. + [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security + Considerations for IP Fragment Filtering", RFC 1858, + October 1995. + [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate @@ -5939,20 +6465,26 @@ [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Commuinications Review 29(5), October 1999. [ALLMAN99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM'99 , 1999. + [WILLIAMS93] + Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION + ALGORITHMS" - Internet publication http:// + www.geocities.com/SiliconValley/Pines/8659/crc.htm.", + 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 Specification version 3.3", RFC 1950, May 1996. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. @@ -5962,21 +6494,21 @@ [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 Protocol", RFC 2522, March 1999. Author's Address Randall R. Stewart - Cisco Systems Inc. + Editor 4875 Forest Drive Suite 200 Columbia, SC 29206 US Email: rrs@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any