Stream Control Transmission Protocol.doc

Stream Control Transmission ProtocolIn computer networking, the Stream Control Transmission Protocol (SCTP) is a Transport Layer protocol, serving in a similar role to the popular protocols Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It provides some of the same service features of both: it is message-oriented like UDP and ensures reliable, in-sequence transport of messages with congestion control like TCP.The protocol was defined by the IETF Signaling Transport (SIGTRAN) working group in 2000, and is maintained by the IETF Transport Area (TSVWG) working group. RFC 4960 defines the protocol. RFC 3286 provides an introduction.In the absence of native SCTP support in operating systems it is possible to tunnel SCTP over UDP,1 as well as mapping TCP API calls to SCTP ones.2Internet Protocol SuiteApplication LayerBGP DHCP DNS FTP HTTP IMAP IRC LDAP MGCP NNTP NTP POP RIP RPC RTP SIP SMTP SNMP SSH Telnet TLS/SSL XMPP(more)Transport LayerTCP UDP DCCP SCTP RSVP ECN(more)Internet LayerIP (IPv4, IPv6) ICMP ICMPv6 IGMP IPsec(more)Link LayerARP/InARP NDP OSPF Tunnels(L2TP) PPP Media Access Control(Ethernet, DSL, ISDN, FDDI) (more)This box: viewtalkeditContentshide 1 Message-based multi-streaming 2 Features 3 Motivations 4 Packet structure 5 Security 6 Comparison of Transport Layer protocols 7 Implementations 8 RFC history 9 See also 10 References 11 External links Message-based multi-streamingSCTP applications submit their data to be transmitted in messages (groups of bytes) to the SCTP transport layer. SCTP places messages and control information into separate chunks (data chunks and control chunks), each identified by a chunk header. A message can be fragmented over a number of data chunks, but each data chunk contains data from only one user message. SCTP chunks are bundled into SCTP packets. The SCTP packet, which is submitted to the Internet Protocol, consists of a packet header, SCTP control chunks when necessary, followed by SCTP data chunks when available.SCTP may be characterized as message-oriented, meaning it transports a sequence of messages (each being a group of bytes), rather than transporting an unbroken stream of bytes as does the TCP Protocol. As in the User Datagram Protocol (UDP), in SCTP a sender sends a message in one operation, and that exact message is passed by the receiving SCTP to the receiving application process in one operation. In contrast, TCP is stream-oriented protocol, transporting streams of bytes reliably and in order. However TCP does not allow the receiver to know how many times the sender application called on the TCP transport passing it groups of bytes to be sent out. The sender TCP effectively simply appends more bytes to a queue of bytes waiting to go out over the network, rather than having to keep a queue of individual separate outbound messages which must be preserved as such.The term multi-streaming refers to the capability of SCTP to transmit several independent streams of chunks in parallel, for example transmitting Web page images together with the Web page text. In essence, it is the bundling of several connections into a single SCTP association, operating on messages (or chunks) rather than bytes.TCP preserves byte order in the stream by assigning a sequence number to each packet. SCTP, on the other hand, assigns a sequence number to each message sent in a stream. This allows independent ordering of messages in different streams. However, message ordering is optional in SCTP; a receiving application may choose to process messages in the order they are received instead of the order they were sent.FeaturesFeatures of SCTP include: Multihoming support in which one or both endpoints of a connection can consist of more than one IP address, enabling transparent fail-over between redundant network paths. Delivery of chunks within independent streams eliminate unnecessary head-of-line blocking, as opposed to TCP byte-stream delivery. Path selection and monitoring select a primary data transmission path and test the connectivity of the transmission path. Validation and acknowledgment mechanisms protect against flooding attacks and provide notification of duplicated or missing data chunks. Improved error detection suitable for Ethernet jumbo frames. The designers of SCTP originally intended it for the transport of telephony (Signaling System 7) over Internet Protocol, with the goal of duplicating some of the reliability attributes of the SS7 signaling network in IP. This IETF effort is known as SIGTRAN. In the meantime, other uses have been proposed, for example, the Diameter protocol and Reliable server pooling (RSerPool).MotivationsTCP has provided the primary means to transfer data reliably across the Internet, however TCP has imposed limitations on several applications. From RFC 4960: TCP provides both reliable data transfer and strict order-of-transmission delivery of data. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases, the head-of-line blocking offered by TCP causes unnecessary delay. The stream-oriented nature of TCP is often an inconvenience. Applications must add their own record marking to delineate their messages, and must make explicit use of the push facility to ensure that a complete message is transferred in a reasonable time. The limited scope of TCP sockets complicates the task of providing highly-available data transfer capability using multi-homed hosts. TCP is relatively vulnerable to denial-of-service attacks, such as SYN attacks. Packet structureMain article: SCTP packet structureBitsBits 0781516232431+0Source portDestination port32Verification tag64Checksum96Chunk 1 typeChunk 1 flagsChunk 1 length128Chunk 1 dataChunk N typeChunk N flagsChunk N lengthChunk N dataSCTP packets have a simpler basic structure than TCP packets. Each consists of two basic sections:1. The common header, which occupies the first 12 bytes and is highlighted in blue, and 2. The data chunks, which occupy the remaining portion of the packet. The first chunk is highlighted in green, and the last of N chunks (Chunk N) is highlighted in red. Each chunk has a type identifier that is one byte long yielding, at most, 255 different chunk types. RFC 4960 defines a list of chunk types and there are currently 15 types defined. The remainder of the chunk is a two byte length (maximum size of 65,535 bytes) and the data. If the chunk does not form a multiple of 4 bytes (i.e., the length is not a multiple of 4) then it is implicitly padded with zeros which are not included in the chunk length.SecuritySCTP was designed with features for improved security, such as 4-way handshake (compared to TCP 3-way handshake) to prevent against SYN-flooding attacks, and large Cookies for association verification and authenticity.Reliability was also a key aspect of the security design of SCTP. Multi-homing enables an association to stay open even when some routes and interfaces are down. This is of particular importance for SIGTRAN as it carries SS7 over an IP network using SCTP, and requires strong resilience during link outages to maintain telecommunication service even when enduring network anomalies.Encryption was not part of the original SCTP design.SCTP is sometimes a good fingerprinting candidate. Some operating systems ship with SCTP support enabled, and, as it is not as well known as TCP or UDP, it is sometimes overlooked in firewall and intrusion detection configurations, thus often permitting probing traffic.Comparison of Transport Layer protocolsFeature NameUDPUDP LiteTCPSCTPDCCPRUDPConnection orientedNoNoYesYesYesNoReliable transportNoNoYesYesNoYesUnreliable transportYesYesNoYesYesYesPreserve message boundaryYesYesNoYesYesUnsureOrdered deliveryNoNoYesYesNoNoUnordered deliveryYesYesNoYesYesYesData checksumYesYesYesYesYesUnsureChecksum size (bits)1616163216UnsurePartial checksumNoYesNoNoYesNoPath MTUNoNoYesYesYesUnsureCongestion controlNoNoYesYesYesUnsureMultiple streamsNoNoNoYesNoNoMulti-homing supportNoNoNoYesNoNoBundling / NagleNoNoYesYesNoUnsureImplementationsThe following operating systems implement SCTP: AIX Version 5 Generic BSD with external patch at KAME project Cisco IOS 12 DragonFly BSD since version 1.4 FreeBSD, version 7 and above3 HP-UX, 11i v2 and above4 Operating systems using Linux kernel 2.4 and newer QNX Neutrino Realtime OS, 6.3.0 and above5 Sun Solaris 10 and above 6 Various third-party implementations of SCTP exist for other operating systems. FreeBSD contains the SCTP reference implementation.3Userspace library: The SCTP library (sctplib), with a Windows XP port. Windows: The SctpDrv kernel driver (SctpDrv), which is a port of the BSD SCTP stack to Windows. RFC history RFC 5062 Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures RFC 5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration RFC 5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation RFC 4960 Stream Control Transmission Protocol RFC 4895 Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) RFC 4820 Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) RFC 4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues RFC 3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB) RFC 3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension RFC 3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec RFC 3436 Transport Layer Security over Stream Control Transmission Protocol RFC 3309 Stream Control Transmission Protocol (SCTP) Checksum Change (obsoleted by RFC 4960) RFC 3286 An Introduction to the Stream Control Transmission Protocol RFC 3257 Stream Control Transmission Protocol Applicability Statement RFC 2960 Stream Control Transmission Protocol (updated by RFC 3309 and obsoleted by RFC 4960) See also Transport protocol comparison table Session initiation protocol (SIP), which may initiate multiple streams over SCTP, TCP or UDP References1. Ong, Lyndon; Randall R. Stewart; Qiaobing Xie. Tunneling of SCTP over Single UDP Port. /proceedings/00jul/I-D/sigtran-sctptunnel-00.txt. 2. Bickhar, Ryan; Paul D. Amer; Randall R. Stewart (2007). Transparent TCP-to-SCTP Translation Shim Layer (PDF). /amer/PEL/poc/pdf/EuroBSDCon2007-bickhart-SCTP-Shim-layer.pdf. Retrieved 2008-09-13. 3. a b About FreeBSDs Technological Advances. The FreeBSD Project. 2008-03-09. /features.html. Retrieved 2008-09-13. Excerpt: SCTP: FreeBSD 7.0 is the reference implementation for the new IETF Stream Control Transmission Protocol (SCTP) protocol, intended to support VoIP, telecommunications, and other applications with strong reliability and variable quality transmission through features such as multi-path delivery, fail-over, and multi-streaming. 4. Stream Control Transmission Protocol (SCTP). Hewlett-Packard Development Company. /portal/swdepot/displayInstallInfo.do?productNumber=SCTP. 5. TCP/IP Networking. QNX Developer Support. QNX Software Systems. /developers/docs/6.3.0SP3/neutrino/sys_arch/tcpip.html#SCTP. Retrieved 2008-09-13. 6. Solaris 10 Operating System Networking Extreme Network Performance. Sun Microsystems. /software/solaris/ds/network_performance.jsp#1. Retrieved 2008-09-13. External links Better Networking with SCTP An IBM developerWorks article by M. Tim Jones /html.charters/sigtran-charter.html /html.charters/tsvwg-charter.html http:/www.sctp.de SCTP for QualNet network simulator from DEGAS networking group The Linux Kernel Stream Control Transmission Protocol (lksctp) project The KAME SCTP kernel implementation for Mac OS X SCTP Sequence Diagram Setup, IP Address Reconfiguration and Release (PDF) Tunneling of SCTP over Single UDP Port Open Source / GPL Seagull test tool with SCTP support Parallel computing using the Message-passing Interface (MPI) over SCTP SCTPscan: SCTP port scanner and network scanner, GPL SCTP Support for Nmap SCTP for beginners Retrieved from /wiki/Stream_Control_Transmission_ProtocolSCTP packet structureThe Stream Control Transmission Protocol (SCTP) has a simpler basic packet structure than TCP. Each consists of two basic sections:1. The common header, which occupies the first 12 bytes. In the diagram to the right, this header is highlighted in blue. 2. The data chunks, which form the remaining portion of the packet. In the diagram, the first chunk is highlighted in green and the last of N chunks (Chunk N) is highlighted in red. Contentshide 1 Common header 2 Chunks 3 Chunk types o 3.1 DATA chunk o 3.2 INIT chunk o 3.3 INIT ACK chunk o 3.4 SACK chunk o 3.5 HEARTBEAT chunk o 3.6 HEARTBEAT ACK chunk o 3.7 ABORT chunk o 3.8 SHUTDOWN chunk o 3.9 SHUTDOWN ACK chunk o 3.10 ERROR chunk o 3.11 COOKIE ECHO chunk o 3.12 COOKIE ACK chunk o 3.13 ECNE chunk o 3.14 CWR chunk o 3.15 SHUTDOWN COMPLETE chunk 4 Notes 5 References BitsBits 0781516232431+0Source portDestination port32Verification tag64Checksum96Chunk 1 typeChunk 1 flagsChunk 1 length128Chunk 1 dataChunk N typeChunk N flagsChunk N lengthChunk N dataCommon headerAll SCTP packets require the common header section (shown with a blue background).Source port This field identifies the sending port. Destination port This field identifies the receiving port that hosts use to route the packet to the appropriate endpoint/application. Verification tag A 32-bit random value created during initialization to distinguish stale packets from a previous connection. Checksum SCTPs original design catered for Adler-32; but RFC 3309 changed the protocol to use the CRC32c algorithm. 12 ChunksEach SCTP packet consists, in addition to the common header, of chunks. Each chunk has a common format, but the contents can vary. One chunk appears in the diagram to the right with the green background.Chunk type An 8-bit value predefined by the IETF to identify the contents of the chunk value field. Chunk flags Eight flag-bits whose definition varies with the chunk type. The default value is zero. Chunk length A 16-bit unsigned value specifying the total length of the chunk in bytes (excludes any padding) that includes chunk type, flags, length, and value fields. Chunk value General purpose data field whose definition varies with the chunk type. If the chunk length does not equate to a multiple of 4 bytes then the protocol implicitly pads the chunk with trailing zeros.Optional/variable-length parameter definition+Bits 0 - 1516 - 310Parameter typeParameter length32Parameter valueAdditionally, each chunk type may define a set of parameters which it includes inside the chunk value field (and, consequently, their length in the chunk length).Two types of parameter exist: fixed parameters they must appear and in the order specified variable-length or optional parameters they appear after the fixed parameters and may appear in any order and in any number. For optional/variable-length parameters, the parameter type, parameter length, and parameter value fields all behave just like their chunk counterparts. The minimum size of parameter is 4 bytes and this occurs when the parameter value field is empty and the parameter consists only of the type & length fields.Chunk typesRFC 2960 defines the following list of chunk types.Following this table each chunk and its parameters are defined. Please note the following color scheme: gray: chunk fields red: fixed parameters green/blue: optional/variable-length parameters that alternate colors ValueAbbreviationDescription0DATAPayload data1INITInitiation2INIT ACKinitiation acknowledgement3SACKSelective acknowledgement4HEARTBEATHeartbeat request5HEARTBEAT ACKHeartbeat acknowledgement6ABORTAbort7SHUTDOWNShutdown8SHUTDOWN ACKShutdown acknowledgement9ERROROperation error10COOKIE ECHOState cookie11COOKIE ACKCookie acknowledgement12ECNEExplicit congestion notification echo (reserved)13CWRCongestion window reduced (reserved)14SHUTDOWN COMPLETEShutdown complete15-62N/AReserved by IETF63IETF-defined chunk extensions64-126Reserved by IETF127IETF-defined chunk extensions128-190Reserved by IETF191IETF-defined chunk extensions192-254Reserved by IETF255IETF-defined chunk extensionsDATA chunk+Bits 0 - 78 - 1213141516 - 310Chunk type = 0ReservedUBEChunk length32TSN64Stream identifierStream sequence number96Payload protocol identifier128DataChunk type always zero for payload data (DATA