idnits 2.17.1 draft-ietf-sigtran-sctp-applicability-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 1) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1038: '...livery mechanism SHOULD meet the follo...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 252 has weird spacing: '...se only one o...' == Line 408 has weird spacing: '...ided on diffe...' == Line 503 has weird spacing: '...es/gaps betwe...' == Line 808 has weird spacing: '...rotocol provi...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1981' on line 1085 looks like a reference -- Missing reference section? 'RFCSALLY' on line 1108 looks like a reference -- Missing reference section? 'SCTP' on line 1062 looks like a reference -- Missing reference section? 'RFC123' on line 660 looks like a reference -- Missing reference section? 'RFC2001' on line 1117 looks like a reference -- Missing reference section? 'RFC2018' on line 1120 looks like a reference -- Missing reference section? 'IANA' on line 1105 looks like a reference -- Missing reference section? 'RFC2597' on line 1095 looks like a reference -- Missing reference section? 'RFC2598' on line 1098 looks like a reference -- Missing reference section? 'RFC2208' on line 1088 looks like a reference -- Missing reference section? 'RFC2401' on line 1082 looks like a reference -- Missing reference section? 'RFC1750' on line 1111 looks like a reference -- Missing reference section? 'SAVAGE99' on line 933 looks like a reference -- Missing reference section? '11' on line 1010 looks like a reference -- Missing reference section? 'RFC2719' on line 1101 looks like a reference -- Missing reference section? 'Q1400' on line 1067 looks like a reference -- Missing reference section? 'HUITEM' on line 1071 looks like a reference -- Missing reference section? 'RFC2373' on line 1073 looks like a reference -- Missing reference section? 'RFC2460' on line 1076 looks like a reference -- Missing reference section? 'RFC814' on line 1079 looks like a reference -- Missing reference section? 'RFC1323' on line 1114 looks like a reference -- Missing reference section? 'SAVAGE9' on line 1123 looks like a reference -- Missing reference section? 'JUNGM00' on line 1128 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT L. Coene 2 Internet Engineering Task Force M. Tuexen 3 Issued: 30 september 2000 Siemens 4 Expires: 31 March 2001 J. Loughney 5 Nokia 6 I. Rytina 7 Ericsson 8 L. Ong 9 Nortel Networks 10 R.R. Stewart 11 Cisco 13 Stream Control Transmission Protocol Applicability Statement 14 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- 31 Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document describes the applicability of the Stream Control 37 Transmission Protocol for general usage in the internet. Some of the 38 prominent features, such a the selective acknowledgement, Congestion 39 control, fast retransmit etc.. are explained in some detail. The 40 design of SCTP against certain forms of attacks in the internet is 41 also discussed. The use and specification of adaptation layers in 42 conjunction with SCTP is described. A few general applications are 43 described such as the transport of signalling information (SS7, 44 DSS1/2 ...) over IP infrastructure 46 Table of Contents 48 Stream Control Transmission Protocol Applicability statement 49 ................................................................ ii 50 Chapter 1: Introduction ........................................ 1 51 Chapter 2: Stream Control Transmission Protocol -- SCTP ........ 3 52 Chapter 2.1: Introduction ...................................... 3 53 Chapter 2.2: Issues affecting deployment of SCTP ............... 3 54 Chapter 2.2.1 : SCTP multhoming ................................ 4 55 Chapter 2.2.2 : Fast retransmit of chunks ...................... 6 56 Chapter 2.2.3 : Use of SCTP in Network Address 57 Translators(NAT) networks ...................................... 6 58 Chapter 2.2.4 : MTU path discovery ............................. 7 59 Chapter 2.2.5 : Use of multiple streams ........................ 7 60 Chapter 2.2.6 : Congestion control & Flow control .............. 8 61 Chapter 2.2.6.1 : 3-Sack rule in SCTP .......................... 10 62 Chapter 2.2.6.2 : Congestion control ........................... 12 63 Chapter 2.2.6.3 : Use of explicit Congestion 64 Notification(ECN) .............................................. 13 65 Chapter 2.2.6.4 : Duplicated messages .......................... 13 66 Chapter 2.2.6.5 : SCTP in high throughput delivery networks 67 ................................................................ 13 68 Chapter 2.2.6.6 : SCTP in long delay/Fat networks(LFN) ......... 13 69 Chapter 2.2.6.7 : SCTP in long thin Networks(LTN) .............. 14 70 Chapter 2.2.7 : Use of the protocol Identifier ................. 14 71 Chapter 2.2.8 : Use of QOS methods ............................. 14 72 Chapter 2.2.9 : SCTP checksum .................................. 15 73 Chapter 2.2.10: ???tunneling ??? .............................. 16 74 Chapter 2.2.11: How to use and define adaptation layers ........ 16 75 Chapter 2.2.12: Security considerations ........................ 17 76 Chapter 3: Adaptation Layers ................................... 20 77 Chapter 4: References and related work ......................... 23 78 Chapter 5: Acknowledgments ..................................... 24 79 Chapter 6: Author's address .................................... 25 81 1 Introduction 83 This document covers subject terminology and makes a overview of 84 the solutions for transporting information over Internet Protocol 85 infrastructure. The transport medium used is the Stream Control 87 Draft SCTP applicability statement March 2000 89 Transmission Protocol (SCTP). However some of the issues may also relate 90 to the transport of information via TCP. 92 SCTP provides the following services to its users: 94 - acknowledged error-free non-duplicated transfer of user data 96 - transport-level segmentation to conform to discovered MTU size 98 - sequenced delivery of user datagrams within multiple streams, 99 with an option for order-of-arrival delivery of individual 100 datagrams 102 - optional multiplexing of user datagrams into SCTP datagrams, sub- 103 ject to MTU size restrictions 105 - enhanced reliability through support of multi-homing at either 106 or both ends of the association. 108 - Explicit indication in the message of the application protocol 109 SCTP is carrying. 111 1.1 Terminology 113 The following terms are commonly identified in related work: 115 Port Number: Indicates on the transport level which application 116 needs to be reached in the layer above. 118 Transport Address: An IP address and a port number forms a tran- 119 sport address which identifies a SCTP association. 121 Protocol Identifier: Indicates the upper layer protocol that is 122 using SCTP for the transport of its data. 124 Chunk: a unit of information within an SCTP datagram, consisting 125 of a chunk header and chunk-specific content. Each chunk can con- 126 tain user or data information about the particular SCTP associa- 127 tion. 129 Draft SCTP applicability statement March 2000 131 Multihoming: Endpoint which uses more than one IP address for 132 receiving SCTP datagrams on the same association. 134 NAT: Network Address Translation 136 SACK: Selective Acknowledgement message, this is a response on the 137 data msg acknowledging the receipt of it at the remote side. 139 TSN: Transaction Sequence Number, this is a number assigned by 140 SCTP to assure reliable delivery of user data within an associa- 141 tion. 143 MTU: Maximum Transmission unit, the maximum length (in bytes) that 144 a message may have without being segmented along the path the mes- 145 sage takes. 147 2 Stream Control Transmission Protocol -- SCTP 149 2.1 Introduction 151 The Stream Control Transmission Protocol (SCTP) provides a high reli- 152 able, redundant transport between two endpoints. The interface between 153 SCTP and its applications is handled via adaptation layers which provide 154 a intermediate layer so that the existing upper layer protocols do not 155 have to change their interface towards the transport medium and internal 156 functionality when they start using SCTP instead of an other transport 157 protocol. 159 The following function are provided by SCTP: 161 - Initialization of transport association 163 - Synchronization of association state 165 - Synchronization of sequence numbering 167 - Reliable Data Transfer 169 - Forward and backward sequence numbering 171 - Timers for transmission and acknowledgement 173 - Notification of out-of-sequence - Retransmission of 174 lost messages 176 - Support of multiple control streams 178 Draft SCTP applicability statement March 2000 180 - Separate sequence control and delivery of each stream 182 - Congestion control 184 - Window flow control 186 - Congestion avoidance based on TCP methods, e.g. using 187 retransmission backoff, window reduction, etc. 189 - Detection of session failure by active means, e.g. heartbeat 191 - Termination of association 193 SCTP does support a number of functions that are not provided by current 194 TCP: 196 - no head-of-line blocking, i.e. multiple streams 198 - multilink failover for added reliability 200 - keep-alive function for active rapid failure detection 202 - message versus byte sequence numbering 204 - tighter timer control (than the standard TCP implementations) 206 By defining the appropriate User adaptation module, a reliable 207 transport mechanism can be provided: 209 - reliable transmission of packets with end-to-end congestion con- 210 trol provided using methods similar to TCP 212 - choice between sequenced and unsequenced, reliable message 213 delivery 215 - keep-alive message 217 Within a association between the two endpoints, 1 or more stream(s) may 218 be available. These streams are visible to the adaptation layers but are 219 invisible to any layer above the adaptation layer. 221 2.2 Issues affecting deployment of SCTP 223 2.2.1 SCTP Multihoming 225 Draft SCTP applicability statement March 2000 227 Redundant communication between 2 SCTP endpoints is achieved by using 228 multihoming where the endpoint is able to send/receive over more than 229 one IP address. 231 Under the assumption that every IP address will have a different, 232 seperate paths towards the remote endpoint, (this is the responsibility 233 of the routing protocols or of manual configuration) , if the transport 234 to one of the IP address (= 1 particular path) fails then the traffic 235 can migrate to the other remaining IP address (= other paths) within the 236 SCTP association. 238 As a practical matter, it is recommended that IP addresses in a mul- 239 tihomed endpoint be assigned IP endpoints from different TLV's to ensure 240 against network failure. 242 Multihoming provides redundant communication in SCTP by allowing commun- 243 ication between two endpoints to continue in the event of failure along 244 a path between the endpoints. 246 In IP implementations the outgoing interface of multihomed hosts is 247 ofter determined by the destination IP address. The mapping is done by a 248 lookup in a routing table maintained by the operating system. Therefore 249 the outgoing interface is not determined by SCTP. Using such implemen- 250 tations, it should be noted that a multihomed host cannot make use of 251 the multiple local IP addresses if the peer is singlehomed. The mul- 252 tihomed host has only one path and will normally use only one of its 253 interfaces to send the SCTP datagrams to the peer. If this physical path 254 fails, the IP routing table in the multihome host has to be changed. 255 Somethink which is out of scope of SCTP. 257 SCTP will always send its traffic to a certain transport address (= des- 258 tination address + port number combination) for as long as the transmis- 259 sion is uninterrupted (= primary). The other transport addresses (secon- 260 dary paths) will act as a backup in case the primary path goes out of 261 service. The changeover between primary are backup will occur without 262 packet loss and is completely transparent to the application. 264 The port number is the same for all transport addresses of that specific 265 association. 267 Applications directly using SCTP may choose to control the multihoming 268 service themselves. The applications have then to supply the specific IP 269 address to SCTP for each datagram. This might be done for reasons of 270 load-sharing and load-balancing across the different paths. This might 271 not be advisable as the throughput of any of the paths is not known in 272 advance and constantly changes due to the actions of other associations 273 and transport protocols along that particular path, would require very 274 tight feedback of each of the paths to the loadsharing functions of the 276 Draft SCTP applicability statement March 2000 278 user. 280 Applications using adaptation layers to run over SCTP do not have that 281 kind of control. The adaptation layers will have to take care of this. 283 By sending a keep alive message on all the multiple paths that are not 284 used for active transmission of messages across the association, it is 285 possible for SCTP to detect whether one or more paths have failed. SCTP 286 will not use these failed paths when a changeover is required. 288 The transmission rate of sending keep alive message should be modifiable 289 and the possible loss of keep alive message could be used for the moni- 290 toring and measurements of the concerned paths. 292 2.2.2 Fast retransmit of chunks 294 The retransmission of a message is basically governed by the retransmis- 295 sion timer. So if no acknowledgement is received after a certain time, 296 then the message is retransmitted. However there is a faster way for 297 retransmitting which is not dependant on that timer. 299 Every second message that a node received will be acknowledge to the 300 remote peer. If gaps occur in the acknowledge message at the remote 301 side, then the remote side will wait 3 further gap reports (acknowledge- 302 ments) before it retransmit the message. As the gap occurs, the node 303 must transmit a SACK on every datagram until there are no more gap. This 304 retransmission will happen far sooner than with a timer. Especially if 305 the traffic volume increases in SCTP, those retransmissions of the 306 chunks would happen faster and faster (and hopefully, they would also be 307 faster acknowledged). In any case if gaps occur, the node will certainly 308 try to acknowledge them faster(irespective of the fact if the SACKs will 309 get to the remote node, where, if received, they would speed up the 310 retransmission of the chunks) 312 See also the paragraph on congestion control and avoidance. 314 2.2.3 Use of SCTP in Network Address Translator (NAT) Networks 316 When a NAT is present between two endpoints, the endpoint that is behind 317 the NAT, i.e., one that does not have a publicly available network 318 address, shall take one of the following options: 320 A) Indicate that only one address can be used by including no transport 321 addresses in the INIT message. This will make the endpoint that receives 323 Draft SCTP applicability statement March 2000 325 this Initiation message to consider the sender as only having that one 326 address. This method can be used for a dynamic NAT, but any multi-homing 327 configuration at the endpoint that is behind the NAT will not be visible 328 to its peer, and thus not be taken advantage of. 330 B) Indicate all of its networks in the Initiation by specifying all the 331 actual IP addresses and ports that the NAT will substitute for the end- 332 point. This method requires that the endpoint behind the NAT must have 333 pre-knowledge of all the IP addresses and ports that the NAT will 334 assign. 336 This requires the adaptation of NAT boxes to search within SCTP outgoing 337 INIT and incoming INIT_ACK mesages for the addresses and replace them 338 with the NAT internal address in addition to replacing the addresses in 339 the IP header. 341 C) Use RSIP where the connection is tunneled from host until the NAT 342 border and the host layers above IP network layer have no knowledge of 343 the NAT internal addresses. 345 D) Use the hostname feature and the DNS to resolve the addresses. The 346 hostname is included in the INIT of the association or in the INIT-ACK. 347 The hostname must be resolved by the DNS before the association is com- 348 pletely set up. That means that more time shall be needed for the com- 349 pletion of the association setup as the DNS has to be queried. 351 2.2.4 MTU path discovery 353 SCTP discovers the maximal length of the message that can be transported 354 through the network to the final destination without having to 355 fragment(=chop something in pieces) the message in IP network layer. 356 This avoids using IP fragmenting. SCTP level segmentation is beneficial 357 because if a packet is lost during network transmission, only that 358 packet will need to be retransmitted. Contrasted with IP-level segmenta- 359 tion, where the whole unsegmented message will have to be retransmitted, 360 this is a much more effective scheme [RFC1981]. 362 2.2.5 Use of multiple streams 364 A stream is a unidirectional flow of user messages between 2 endpoints 365 within a SCTP association. The messages within the stream may be ordered 366 or un-ordered (by request from the user/application). A association can 367 have one or more streams in its association and the number of streams in 368 one direction does NOT need to be the same as the number of streams in 370 Draft SCTP applicability statement March 2000 372 the opposite direction. The number of streams in both directions is thus 373 assymmetrical. 375 The application can choose on which stream it can send it data. Streams 376 may specify order of deliver or sequenced delivery. Some application 377 level protocols may reserve certain streams for certain media, for exam- 378 ple sending graphical content (jpeg, gif, etc.) of a web page through a 379 certain stream while text through others, and streaming content through 380 others. Any packet loss on one stream will not block packet transmis- 381 sion on others. 383 Each stream within a association should be looked upon as a link between 384 two points. If multiple streams are used then the application is dealing 385 with multiple links towards the destination. Some applications may 386 require the use of sequenced delivery, which would require for them to 387 select a certain link to send their message on. 389 2.2.6 Congestion control & Flow control 391 Congestion control and/or avoidance is of primordial importance in any 392 connectionless network. Congestion is the result of approaching or 393 exceeding the processing capacity of the link, network, application 394 and/or transport layers. If the processing capacity is exceeded, then 395 the congestion can be avoided (example taking a other non-congested path 396 towards the destination) or controlled (for example, reducing the rate 397 of messages to that destination = flow control). 399 Flow control algorithms do control the rate with which messages are 400 injected into the network. Both endpoints can try to influence the mes- 401 sage rate of each other based on the congestion they experience at their 402 own side. If no congestion is present in the network, then flow control 403 will still be at work, trying to achieve a steady message rate for that 404 association. 406 The reaction of SCTP to congestion is detailed in the next paragraphs. 408 Congestion can be controlled and/or avoided on different levels: 410 - Transport: congestion control/avoidance within SCTP, TCP(fig 411 2.1.2) 413 - Network : Congestion control/avoidance present in the network 414 layers( example: SCCP, MTP ...) 416 - Link layer: flow control 418 Draft SCTP applicability statement March 2000 420 SCTP conforms to the model of end-to-end congestion control (Fig 421 2.2.6.2) [RFCSALLY] while ISUP and SCCP model themselves on a link and 422 network based congestion control/overload mechanism (Fig 2.2.6.3). 424 End-to-end congestion control is based on the following assumption, if 425 message loss occurs in the network, it happens due to congestion, NOT to 426 a castrophic host, link or router failure in the network. 428 | | 429 | Application and/or transport layer | 430 +---------------------------------------------------+ 431 | A 432 | | 433 | +-------------------------------------+ | 434 ---->| |---- 435 | Network layer | 436 ---->| |---- 437 | +-------------------------------------+ | 438 | | 439 | V 440 +---------------------------------------------------+ 441 | | 442 | Link layer | 444 Fig 2.2.6.1 General Congestion model 446 | | 447 |transport layer| Congestion control present based on 448 | SCTP | windows 449 +---------------+ 450 | A 451 V | 452 +---------------+ 453 | | 454 | Network layer | No congestion control present 455 | IP(v4/v6) | in the IP layer 456 +---------------+ 457 | A 458 V | 459 +---------------+ 460 | Ethernet | No congestion control present 461 | Link layer | in the Ethernet link layer 463 Fig 2.2.6.2 End-to-End congestion control 465 Draft SCTP applicability statement March 2000 467 | | 468 |Application layer| Congestion control present for 469 | TC + MAP, IN... | specific applications 470 +-----------------+ - MAP: No congestion control 471 | A - IN: Call gapping 472 V | 473 +-----------------+ 474 | | 475 | Network layer | Congestion control present in the 476 | SCCP & MTP | in MTP and SCCP based on link and 477 +-----------------+ destination status 478 | A 479 V | 480 +-----------------+ 481 | MTP lvl 2 | Congestion control present 482 | Link layer | in the link layer 484 Fig 2.2.6.3 Distributed congestion control 486 By default, SCTP associations do not have a fixed capacity assigned to 487 them unless other QoS mechanisms are employed. Thus congestion within 488 SCTP association can and will be affected by all traffic using the same 489 links including other SCTP, TCP, RTP, UDP ... traffic traveling on the 490 same path followed by the SCTP association. 492 2.2.6.1 3-SACK rule in SCTP. 494 The Selective Acknowledgement (SACK) is one of the cornerstones of SCTP. 495 It selectively Acknowledges datagrams that have been successfully 496 received by the remote node. It serves 2 purposes: 498 - it indicates until a certain datagram that all previous 499 datagrams have been received (without any holes in the 500 sequence) and 502 - it indicates the datagrams sequence ranges which have been 503 received (and so does indicate the holes/gaps between them). 504 It provides us with a form of gap/hole report on messages that 505 have been lost or delayed. A hole can consist of one or more 506 messages. 508 Draft SCTP applicability statement March 2000 510 sender Receiver 512 - |-----* | - 513 Emission I | * | I Link delay 514 time - |----* * | I time 515 I | * *----------->| - 516 I | * | 517 Round I |---* *------------>| 518 trip I | : * /----|<-------- acknowledge sent 519 time I | : *-------- / --->| after 2 data's 520 I | : /: | 521 - |<------------/ : | 523 Round trip Time = RTT 524 Windowsize = Cwnd 526 Fig 2.2.6.4 Influence of Window Size/ Link Speed/ Round Trip Delay 528 Fig 2.2.6.4 is given here as a example where after receiving 2 messages 529 an advisory acknowledgement (SACK) is sent (in this case window = 4). 530 Therefore the sender could be kept busy. The acknowledgement opens the 531 window again. The total time (from first emission till the receiving of 532 the acknowledgement) calculates as: (max. windowsize * emission time)/2 533 + round trip delay. If the round trip time(RTT) is large, the advisory 534 acknowledgments (SACK) will enhance the throughput. 536 The SACK is always generated and send back to the sender either 538 - after every second message received (delayed ack). 540 - after at most 200ms after receiving the last message. 542 The reason for the holes may be diverse: 544 - simple message loss 546 - different round trip times of messages being transmitted on 547 different interfaces 549 At the sender end, whenever the sender notices a hole in a SACK, it 550 should wait for 3 further SACKs (identifying the same hole) before tak- 551 ing action. This is 3 strikes besides the first one, so that means 4. 552 Thus after 4 SACK, the datagrams belonging to the hole should be 553 retransmitted(and only those). 555 Draft SCTP applicability statement March 2000 557 If gaps occur, the receiver end will send SACKs on every data message 558 received instead on being send on every second data message received. As 559 the sender is waiting for the 3 SACK strikes and the receiver is 560 increasing the SACK rate, that would mean that retransmission would be 561 happening faster. Also the window should be opening up more than in the 562 normal case (= transmission without gaps). 564 The 3 SACKs rule might be relaxed in certain networks provided certain 565 condition are met: 567 - private IP network 569 - closed networks 571 - only a single type of application traffic is running on that 572 network (the message in the network exhibit the same charac- 573 teristics: 574 example: signalling messages). 576 The SACK rule might be configurable in such a networks, if the network 577 operator felt confident in the correctness of the network. This would 578 mean that in case of packet loss, retransmission could be "immediate". 580 SACK will also report duplicate message arrival. See paragraph 2.2.6.4. 582 2.2.6.2 Congestion Control 584 The number of messages in flight is determined by the Congestion window 585 (Cwnd). Every time a message is SACK, a new message(with size x bytes) 586 might be send to the remote side(up till the (Cwnd + 1 MTU - 1) bytes), 587 even if gaps exists which might ultimately lead to retransmissions. 589 The value of the Cwnd is dependant on the slow start and/or congestion 590 avoidance/control and is set in bytes, not messages. (takes care of 591 using small or large messages for pulling a leg on the congestion con- 592 trol algorithm) 594 If messages are getting lost, then it is assumed by SCTP that they are 595 lost according to congestion, not that they are lost due to error on the 596 link(such as cable cutthrough ...). 598 When messages are lost then the rate of messages sending is reduced, 599 till no messages are lost. 601 Draft SCTP applicability statement March 2000 603 The consequence of using congestion control in SCTP or any other tran- 604 sport protocol(provided it is end-to-end) is that during the time the 605 association is up and running, somewhere along the path taken by the 606 messages belonging to a certain association, a node or link may be 607 hovering in or near congestion. 609 2.2.6.3 Use of Explicit Congestion notification (ECN) 611 Explicit Congestion control is a experimental method for communicating 612 congestion back to the end node. SCTP does not support the use of ECN, 613 but specific recommendations for using ECN with SCTP might be forthcom- 614 ing. Specific Chunks have been reserved for ECN's use. See [SCTP] 616 2.2.6.4 Duplicated messages 618 SACKs can get lost(it is best-effort in both directions). The receiving 619 node would then receive duplicated packets, because the sending side 620 thought the messag it send was not acknowledge and thus did not arrive 621 at the receiving end. A reason for such a behavior is imbalance between 622 the 2 traffic direction, use of different up and down path. 624 2.2.6.5 SCTP in high throughput delivery networks 626 The TSN is associated with a message, not with the number of bytes(as is 627 the sequence number of TCP) in the message. So the TSN will wrap around 628 less frequently but has a dependency on the length of each message. Use 629 of short messages will lead to a faster wrapping around of the TSN. So 630 in high throughput networks, it is advised to make the messages as long 631 as possible so that the wrap around will be less frequent. 633 SCTP already has a larger window than TCP does even when TCP is using 634 the "large windows" option. 636 2.2.6.6 SCTP in long delay/Fat networks (LFN) 638 Long delay(Fat) Networks consists of network paths which have a high 639 "bandwidth*delay product"(such as satelite links(high delay) or high 640 capacity fiber(high bandwith)). There the 3-SACK rule would lead to 641 enhanced throughput, if the initial windowsize is set higher than 643 Draft SCTP applicability statement March 2000 645 2(which is the default value for non-LFNs). 647 The initial windowsize should be set to a higher value (4 or 8) as that 648 would mean that 4 messages would be injected in the network and the 649 first sack would come back at about the same time as the last message 650 before the window is full, is injected. 652 Thus to have the most of the 3 sack rule immediatly, the initial window 653 size should at least be set at 4 (and possible at 8 if we are dealing 654 with really very long delays). 656 The drawback of this is that it makes SCTP more aggressive to begin 657 with(certainly when faced with TCP). 659 For a more precise description of the issues associated with this, refer 660 to [RFC123], [RFC2001] and [RFC2018] 662 2.2.6.7 SCTP in Long Thin Networks(LTN) 664 Long thin networks consists of network paths that traverse "very low 665 bit-rate" links(such as 56 Kbit modem links). This means that a single 666 host can very easy saturate such a link(= pushing the link into conges- 667 tion). And it is then this link which determines the congestion control 668 variables in SCTP. 670 2.2.7 Use of the protocol identifier in SCTP 672 Indicates the the upper layer protocol that is using the associations. 673 The protocol identifier is available to the application and is included 674 in each chunk. 0 is the unknown protocol. This protocol id can be used 675 by firewalls for filtering out certain protocols. If firewalls drops 676 certain protocol id's then the association will fail in the end because 677 the TSN will be lost. 679 The protocol identifier is administered by IANA[IANA]. 681 2.2.8 Use of QoS methods 683 SCTP is a end-to-end protocol which cannot guarantee the quality-of- 684 service along the complete path(s) taken by the messages of that partic- 685 ular association. If more guarantees are required for improving the 686 reliability of the transport, some form of QoS mechanism may be needed. 688 The possible schemes are as follows. 690 Draft SCTP applicability statement March 2000 692 2.2.8.1 Over-provisioning 694 Over-provisioning of the links so that the total traffic running over 695 the link never exceeds the link capacity. In practice, this may be dif- 696 ficult to ensure reliably. But SCTP will work to utilise as much of the 697 link as possible(going near or in congestion). 699 2.2.8.2 Private Internets 701 Use of a private network solely for transport purposes. Private networks 702 may allow better control and monitoring of resources available. 704 2.2.8.3 Differentiated services 706 By providing a certain code point in the Type-of-service field (TOS), 707 certain Differential services can be selected. [RFC2597, RFC2598] 709 Setting the code point for transport requires some thought. It is depen- 710 dant on the kind of differentiate service selected. Also the use of 711 traffic is important: example signalling info should have a higher 712 priority than the user data traffic for which the signalling is 713 responsible(and that relation does not always exist). 715 2.2.8.4 Integrated services 717 By use of integrated services [RFC2208], resources are reserved for sig- 718 naling transport. 720 If resources are unavailable for to initiate a new signaling transport, 721 that request will be denied. RSVP may not scale well and this solution 722 may prove to be unfeasible. 724 An example is Multi Protocol Label Switching. 726 2.2.9 SCTP Checksum 728 SCTP uses the Adler-32 checksum algorithm. This algorithm will perform 729 better than a 16 bit (CRC or not) checksum or even a 32 bit CRC check- 730 sum. 732 The message can also be protected by IPSEC which is much stronger. In 734 Draft SCTP applicability statement March 2000 736 that case, the checksum should still be computed. 738 2.2.10 Tunneling of SCTP association over UDP 740 The basic operation of SCTP is to run directly on top of IP. However, 741 due to restrictions placed on implementers by Operating Systems, not all 742 implementations may be able to run over IP directly. Therefore an alter- 743 native is given which might circumvent some or all of the restrictions. 745 The STCP messages are transported over UDP instead. The following issues 746 must be observed: 748 - the port number in the UDP header should be the port number 749 assigned to SCTP. The port number in the SCTP common header 750 should be the one assigned to the user adaptation layer or to 751 the application of SCTP. This means that port numbers previ- 752 ously used in UDP and/or TCP can be reused for the same appli- 753 cation using SCTP. SCTP DOES NOT change the semantics of the 754 port number just because the protocol identifier is added to 755 the SCTP message. 757 - the checksum field might be used as a additional guard 758 against errors(particular errors in the UDP header). However, 759 the SCTP checksum employed is far better at catching errors, 760 but does not take the UDP header into account. 762 2.2.11 How to define and Use adaptation layers 764 Many different applications may use SCTP for different purposes. They go 765 from File transfer over HTTP transport to signalling information tran- 766 sport. 768 Some applications might want preserve the existing interface with its 769 lower layer (in this case SCTP) while for other applications, this does 770 not pose a problem. A narchitecture has been devised to let the applica- 771 tion choose whether they want to run over SCTP directly (just a many 772 applications run over TCP) or let application run on top of a adaptation 773 layer over SCTP. 775 The basic architecture is as in Figure 2.11.1 : 777 Draft SCTP applicability statement March 2000 779 User/Application level Protocols 780 | | | 781 +------------------------------------+ 782 | User Adaptation modules | 783 +------------------------------------+ 784 | 785 +------------------------------------+ 786 |Stream Control Transmission protocol| 787 +------------------------------------+ 788 | 789 +------------------------------------+ 790 | Standard IP Transport | 791 +------------------------------------+ 792 | 793 Network Layer (IP) 795 Figure 2.11.1: Transport Components 797 The three components of the transport protocol are : 799 (1) Adaptation modules that support specific primitives, e.g. manage- 800 ment indications, required by a particular user/ application proto- 801 col. The use of a adaptation protocol is optional. It is only used 802 in case in which the application protocol does not want to change 803 its interface with the underlying layer. 805 (2) the Stream Control Transmission Protocol itself that supports a 806 common set of reliable transport functions. 808 (3) a standard IP transport/network protocol provided by the operating 809 system. In some network scenarios, it has been recognized that TCP 810 can provide limited (but sufficient) reliable transport functional- 811 ity for some applications. 813 2.2.12 Security considerations 815 The following aspects of security are : 817 Authentication: 819 Information is sent/received from a known and/or trusted partner. 821 Draft SCTP applicability statement March 2000 823 Integrity: 825 Information may not be modified while in transit. The integrity of 826 a message in a public network is not guaranteed. 828 Confidentiality: 830 Confidentiality of the user data must be ensured. User data can 831 not be examined by unauthorized users. 833 Availability: 835 The communicating endpoint must remain in service in all cir- 836 cumstances. Some services have very high availability requirements: 837 for example, all SS7 nodes have to remain active for the 99.999% of 838 the time. 840 2.2.12.1 General Considerations 842 SCTP only tries to increase the availability of a network. SCTP does not 843 contain any protocol elements in its messages which are directly related 844 to Authentication, Integrity and Confidentiality functions. It depends 845 for such a features on the IPSEC protocols and architecture and/or on 846 security features of its user protocols. 848 The only function which has some bearing on security of SCTP is the 849 integrity of message in SCTP, which is guarded by a Checksum. This 850 checksum is always mandatory even if IPSEC is NOT used. It is advised to 851 use of IPSEC in the SCTP association on a END-TO-END basis. The use of 852 IPSEC on a part of a path of a SCTP association does NOT relieve SCTP 853 from using the checksum(as this ain't end-to-end transport) 855 The general rule is that IPSEC should be turned on unconditionally. 857 The description of the internet security architecture and the use of it 858 is described in [RFC2401]. 860 2.2.12.2 The cookie mechanism and Denial-of-Service (DOS) attacks 862 The cookie mechanism in SCTP is a measure against Denial-of-Service 863 (DOS) attacks. In a DOS attack, a lot of init chunks are send towards a 864 single terminating node (the source is a bogus node = a invalid source 865 address in the datagram), so that very quickly all resources are used up 867 Draft SCTP applicability statement March 2000 869 and that normal users are rejected due to resource shortage in the ter- 870 minating node/host. 872 How does SCTP counter a DOS attack(A: by running on Linux:-) : When a 873 INIT chunk is received, the TCB info is encoded and put into the cookie 874 and send to the initiating node via the INIT_ACK. No TCB is allocated at 875 the receiving node as all info is encoded in the cookie and the cookie 876 will return in the COOKIE_ACK (at that time the TCB will be really allo- 877 cated with the info from the cookie and a full association is set up). 878 As in the case of a DOS attack, the INIT_ACK will be send back to a 879 bogus address, no COOKIE_ACK will come back and no resources will be 880 tied up in the terminating node. 882 If however the INIT_ACK is not send back to a Bogus address but to a 883 real address, then resources will get reserved and a association will be 884 set up. THis would allow to find out who the initiator is.(provided of 885 course that the initiator started the association in the first place) 886 After the cookie exchange, a DNS query may be launched(if the host 887 option was used in the specification of the endpoint address) to resolve 888 the host name. It is not allowed to do that before as this would tie up 889 resources(wait for the DNS query answer to come back), thus state during 890 the time between INIT_ACK and COOKIE_ACK(thus negating the cookie 891 mechanism for the receiving end of the asociation). 893 But even with that constraint this opens up some interesting DDoS (= DNS 894 DOS) attacks. If X sends to B1, B2, ... B1000000 an INIT with host- 895 name-address = a.example.com then when the cookie exchanges are done 896 1,000,000 hosts will attempt to 1) pound on example.com's DNS server and 897 2) potentially send data to A. This assumes X has sufficient bandwith 898 to send the INIT etc packets to all the B's - or at least that X's band- 899 with exceeds A's bandwith to the net; not an unreasonable assumption. 900 Similar things apply to the INIT-ACK. In both cases example.com would 901 see this DNS traffic coming from all over the place - and nothing would 902 directly point back at X. 904 2.2.12.3 Initiate Tag considerations 906 As the tag is fixed during the whole lifetime of the association, the 907 initiate Tag values should be selected as random as possible to help 908 protect against "man in the middle" and "sequence number" attacks. It is 909 suggested that RFC 1750 [RFC1750] be used for the Tag randomization. A 910 new tag is only assigned if a new association is set up. 912 2.2.12.4 Fingerprinting of SCTP 914 Draft SCTP applicability statement March 2000 916 Different implementations may show a certain fingerprint in their mes- 917 sages when they have to answer to certain messages send to them. It is 918 advisabel to send only the basic required information back according to 919 the SCTP protocol. 921 Fingerprinting is the art of figuring out whose implementation you are 922 dealing with by analysing certain parameters within the syntax of the 923 message. 925 Example: a certain TCAP implementation (from a vendor whose name shall 926 not be mentioned) always fills in the length field of its transaction in 927 a msg to 1 while all other folks fill in the maximum value 4. 929 2.2.12.5 The ACK-Splitting attack 931 The ACK-splitting attack splits up the acknowledgements send back to the 932 sender into segments, which acknowledge only a part of the received 933 message(see [SAVAGE99]) . Normally, a receiver should send back a single 934 acknowledge for a single send data message received. The net result of 935 ACK splitting is that the congestion window will grow for each ACK 936 received which is more than if the congestion window was grown for the 937 acknowledgement of the single message. 939 In SCTP this behaviour is counterd by the fact that the messages are 940 acknowledged and NOT the bytes. If a message is acknowledged, then the 941 congestion window is grown by a certain amount of bytes, depending on 942 the situation: MIN(msg size, path MTU)). A second SACK would Acknowledge 943 the same already acknowledged message and does not grow the congestion 944 window. 946 It is assumed for sake of clarity that one message contains only a sin- 947 gle chunk. 949 3 Adaptation Layers 951 Currently, there are four adaptation layers, to support carrying of SS7 952 application protocols over IP. These adaptation layers are being 953 developed for different purposes, and there is no assumption that they 954 should interwork - i.e. - M2UA carries M3UA. They should be thought of 955 as individual protocols for specific uses. 957 3.1 IUA 959 There is a need for Switched Circuit Network (SCN) signaling protocol 961 Draft SCTP applicability statement March 2000 963 delivery from an ISDN Signaling Gateway (SG) to a Media Gateway Con- 964 troller (MGC). The delivery mechanism should meet the following cri- 965 teria 967 * Support for transport of the Q.921 / Q.931 boundary primitives 969 * Support for communication between Layer Management modules on SG 970 and MGC 972 * Support for management of active associations between SG and MGC 974 This draft supports both ISDN Primary Rate Access (PRA) as well as Basic 975 Rate Access (BRA) including the support for both point-to-point mode and 976 point-to-multipoint modes of communication. QSIG adaptation layer 977 requirements do not differ from Q.931 adaptation layer, hence the pro- 978 cedures described in this draft are also applicable to QSIG adaptation 979 layer. 981 3.2 M2UA 983 There is a need for SCN signaling protocol delivery from an Signaling 984 Gateway (SG) to a Media Gateway Controller (MGC) or IP Signaling Point 985 (IPSP). The delivery mechanism should meet the following criteria: 987 * Support for MTP Level 2 / MTP Level 3 interface boundary 989 * Support for communication between Layer Management modules on SG 990 and MGC 992 * Support for management of active associations between the SG and 993 MGC 995 In other words, the Signaling Gateway will transport MTP Level 3 mes- 996 sages to a Media Gateway Controller (MGC) or IP Signaling Point (IPSP). 997 In the case of delivery from an SG to an IPSP, the SG and IPSP function 998 as traditional SS7 nodes using the IP network as a new type of SS7 link. 999 This allows for full MTP Level 3 message handling and network management 1000 capabilities. 1002 3.3 M3UA 1004 There is a need for SCN signaling protocol delivery from an SS7 1006 Draft SCTP applicability statement March 2000 1008 Signaling Gateway (SG) to a Media Gateway Controller (MGC) or IP- 1009 resident Database as described in the Framework Architecture for Signal- 1010 ling Transport [11]. The delivery mechanism should meet the following 1011 criteria: 1013 * Support for transfer of all SS7 MTP3-User Part messages (e.g., 1014 ISUP, SCCP, TUP, etc.) 1016 * Support for the seamless operation of MTP3-User protocol peers 1018 * Support for the management of SCTP transport associations and 1019 traffic between an SG and one or more MGCs or IP-resident Databases 1021 * Support for MGC or IP-resident Database failover and loadsharing 1023 * Support for the asynchronous reporting of status changes to 1024 management 1026 In simplistic terms, the SG will terminate SS7 MTP2 and MTP3 protocols 1027 and deliver ISUP, SCCP and/or any other MTP3-User protocol messages over 1028 SCTP transport associations to MTP3-User peers in MGCs or IP-resident 1029 Databases. 1031 3.4 SUA 1033 This document details the delivery of SCCP-user messages (MAP & CAP over 1034 TCAP, RANAP, etc.) over IP. The architecture may be from from an SS7 1035 Signaling Gateway (SG) to an IP-based signaling node (such as an IP- 1036 resident Database) as described in the Framework Architecture for Sig- 1037 naling Transport [RFC2719], or between two endpoints located completely 1038 within an IP network. The delivery mechanism SHOULD meet the following 1039 criteria: 1041 * Support for transfer of SS7 SCCP-User Part messages (e.g., TCAP, 1042 RANAP, etc.) 1044 * Support for SCCP connectionless service. 1046 * Support for SCCP connection oriented service. 1048 * Support for the seamless operation of SCCP-User protocol peers 1050 * Support for the management of SCTP transport associations 1051 between an SG and one or more IP-based signaling nodes). 1053 Draft SCTP applicability statement March 2000 1055 * Support for distributed IP-based signaling nodes. 1057 * Support for the asynchronous reporting of status changes to 1058 management 1060 4 References and related work 1062 [SCTP] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , 1063 Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, L. 1064 and Paxson, V."Stream Control Transmission Protocol", , RFCxxxx, July 2000. Work In Progress. 1067 [Q1400] SG11, ITU-T Recommendation Q.1400, " architecture framework for 1068 the development of signaling and OA&M protocols using OSI concepts 1069 ",1993 1071 [HUITEM] Huitema, C., "Routing in the Internet", Prentice-Hall, 1995. 1073 [RFC2373] Hinden, R. and Deering, S., "IP Version 6 Addressing Architec- 1074 ture", RFC 2373, July 1998. 1076 [RFC2460] Hinden, R. and Deering, S., "Internet Protocol, Version 6 1077 (IPv6) Specification", RFC 2460, December 1998. 1079 [RFC814] Clark, D.D., "Names, addresses, ports and routes", RFC 0814, 1080 July 1982. 1082 [RFC2401] Kent, S., and Atkinson, R., "Security Architecture for the 1083 Internet Protocol", RFC 2401, November 1998. 1085 [RFC1981] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery 1086 for IP version 6", RFC 1981, August 1996. 1088 [RFC2208] Mankin, A. Ed., Baker, F., , Braden, B., Bradner, S., O`Dell, 1089 M., Romanow, A., Weinrib, A. and Zhang, L., "Resource ReSerVation 1090 Protocol (RSVP) -- Version 1 Applicability Statement Some Guide- 1091 lines on Deployment" , RFC 2208, September 1997. 1093 Draft SCTP applicability statement March 2000 1095 [RFC2597] Heinanen, J., Baker, F., Weiss, W. and Wroclawski, J., 1096 "Assured Forwarding PHB Group", RFC2597, June 1999 1098 [RFC2598] Jacobson, V., Nichols, K. and Poduri, K., "An Expedited For- 1099 warding PHB", RFC2598, June 1999 1101 [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., 1102 Lin, H., Juhasz, I., Holdrege, M., Sharp, C., "Framework Architec- 1103 ture for Signaling Transport", RFC2719, October 1999 1105 [IANA] Internet Assigned Numbers Authority, http://www.iana.org/, April 1106 2000 1108 [RFCSALLY] Floyd, S. Ed., "Congestion Control Principles", RFCxxxx, July 2000 1111 [RFC1750] Eastlake, 3rd, D., Crocker, S., Schiller, J., "Randomness 1112 Recommendations for Security", RFC1750, December 1994 1114 [RFC1323] Jacobson, V., Braden, R., Borman, D., "TCP Extensions for High 1115 Performance", RFC1323, May 1992 1117 [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast 1118 Retransmit, and Fast Recovery Algorithms ", RFC2001, January 1997 1120 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., Romanow, A., "TCP Selec- 1121 tive Acknowledgement Options ", RFC2018, October 1996 1123 [SAVAGE9] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., 1124 "TCP Congestion Control with a Misbehaving Receiver", ACM Computer 1125 Communication Review, 29(5), October 1999. 1126 http://www.cs.washington.edu/homes/savage/papers/CCR99.pdf 1128 [JUNGM00] Jungmaier, A., Schopp, M. and Tuexen, M., "Performance Evalua- 1129 tion of the Stream Control Transmission Protocol", , July 2000. 1131 6 Acknowledgments 1133 Draft SCTP applicability statement March 2000 1135 The authors wish to thank Renee Revis, Q. Xie, H.J. Schwarzbauer, J.P. 1136 Martin-Flatin and many others for their invaluable comments. 1138 7 Author's Address 1140 Lode Coene 1141 Siemens Atea 1142 Atealaan 34 1143 B-2200 Herentals 1144 Belgium 1146 Phone: +32-14-252081 1147 EMail: lode.coene@siemens.atea.be 1149 John Loughney 1150 Nokia Research Center 1151 Itamerenkatu 11-13 1152 FIN-00180 Helsinki 1153 Finland 1155 Phone: +358-9-43761 1156 EMail: john.loughney@nokia.com 1158 Ian Rytina 1159 Ericsson Australia 1160 37/360 Elizabeth Street 1161 Melbourne, Victoria 3000 1162 Australia 1164 Phone : - 1165 EMail:ian.rytina@ericsson.com 1167 Lyndon Ong 1168 Nortel Networks 1169 4401 Great America Parkway 1170 Santa Clara, CA 95054 1171 USA 1173 Phone: - 1174 EMail: long@nortelnetworks.com 1176 Michel Tuexen 1177 SIEMENS AG 1178 Hofmannstr. 51 1179 81359 Munich 1180 Germany 1182 Draft SCTP applicability statement March 2000 1184 Phone: +49 89 722 47210 1185 EMail: Michael.Tuexen@icn.siemens.de 1187 Randall R. Stewart 1188 24 Burning Bush Trail. 1189 Crystal Lake, IL 60012 1190 USA 1192 Tel: +1-815-479-8536 1193 EMail: rstewart@flashcom.net 1195 Expires: March 31, 2001 1197 Full Copyright Statement 1199 Copyright (C) The Internet Society (2000). All Rights Reserved. 1201 This document and translations of it may be copied and furnished 1202 to 1203 others, and derivative works that comment on or otherwise explain 1204 it or assist in its implementation may be prepared, copied, published 1205 and distributed, in whole or in part, without restriction of any 1206 kind, provided that the above copyright notice and this paragraph 1207 are included on all such copies and derivative works. However, this 1208 document itself may not be modified in any way, such as by 1209 removing the copyright notice or references to the Internet Society or 1210 other Internet organizations, except as needed for the purpose of 1211 developing Internet standards in which case the procedures for 1212 copyrights defined in the Internet Standards process must be 1213 followed, or as required to translate it into languages other than 1214 English. 1216 The limited permissions granted above are perpetual and will not 1217 Be revoked by the Internet Society or its successors or assigns. 1219 This document and the information contained herein is provided on 1220 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1221 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 1222 INCLUDING 1223 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1224 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1225 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1227 Draft SCTP applicability statement March 2000