idnits 2.17.1 draft-ietf-sigtran-sctp-applicability-01.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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1021 lines 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 2 instances of too long lines in the document, the longest one being 9 characters in excess of 72. == There are 8 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 808: '...rk. The delivery mechanism SHOULD meet...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 285 has weird spacing: '...ided on diffe...' == Line 365 has weird spacing: '...es/gaps betwe...' == Line 641 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? 'RFCRSIP' on line 866 looks like a reference -- Missing reference section? 'RFC1981' on line 845 looks like a reference -- Missing reference section? 'RFCSALLY' on line 869 looks like a reference -- Missing reference section? 'RFC123' on line 502 looks like a reference -- Missing reference section? 'RFC2001' on line 878 looks like a reference -- Missing reference section? 'RFC2018' on line 881 looks like a reference -- Missing reference section? 'IANA' on line 863 looks like a reference -- Missing reference section? 'RFC2597' on line 853 looks like a reference -- Missing reference section? 'RFC2598' on line 856 looks like a reference -- Missing reference section? 'RFC2208' on line 848 looks like a reference -- Missing reference section? 'RFC2401' on line 842 looks like a reference -- Missing reference section? 'RFC1750' on line 872 looks like a reference -- Missing reference section? '11' on line 785 looks like a reference -- Missing reference section? 'RFC2719' on line 859 looks like a reference -- Missing reference section? 'SCTP' on line 822 looks like a reference -- Missing reference section? 'Q1400' on line 827 looks like a reference -- Missing reference section? 'HUITEM' on line 831 looks like a reference -- Missing reference section? 'RFC2373' on line 833 looks like a reference -- Missing reference section? 'RFC2460' on line 836 looks like a reference -- Missing reference section? 'RFC814' on line 839 looks like a reference -- Missing reference section? 'RFC1323' on line 875 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 23 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 Siemens 3 Issued: 8 may 2000 J. Loughney 4 Expires: 30 October 2000 Nokia 5 I. Rytina 6 Ericsson 7 L. Ong 8 Nortel Networks 10 Stream Control Transmission Protocol Applicability Statement 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- 28 Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 This document describes the applicability of the Stream Control 34 Transmission Protocol for general usage. A few general applications 35 are described such as the transport of signalling information (SS7, 36 DSS1/2 ...) over IP infrastructure. The use and specification of 37 adaptation layers in conjunction with SCTP is described. 39 1 Introduction 41 This document covers subject terminology and makes a overview of the 42 solutions for transporting information over Internet Protocol 43 infrastructure. The transport medium used is the Stream Control 44 Transmission Protocol (SCTP). However some of the issues may also 45 relate to the transport of information via TCP. 47 SCTP provides the following services to its users: 49 - acknowledged error-free non-duplicated transfer of user data 51 - transport-level segmentation to conform to discovered MTU size 53 - sequenced delivery of user datagrams within multiple streams, with 54 an option for order-of-arrival delivery of individual datagrams 56 - optional multiplexing of user datagrams into SCTP datagrams, 57 subject to MTU size restrictions 59 - enhanced reliability through support of multi-homing at either 60 or both ends of the association. 62 - Explicit indication in the message of the application protocol SCTP 63 is carrying. 65 1.1 Terminology 67 The following terms are commonly identified in related work: 69 Port Number: Indicates on the transport level which application 70 needs to be reached in the layer above. Transport Address: An IP 71 address and a port number forms a transport address which identifies 72 a SCTP association. Protocol Identifier: Indicates the upper layer 73 protocol that is using SCTP for the transport of its data. Chunk: a 74 unit of information within an SCTP datagram, consisting of a chunk 75 header and chunk-specific content. Each chunk can contain user or 76 data information about the particular SCTP association. Multihoming: 77 Endpoint which uses more than one IP address for receiving SCTP 78 datagrams on the same association. NAT: Network Address Translation 79 SACK: Selective Acknowledgement message, this is a response on the 80 data msg acknowledging the receipt of it at the remote side. TSN: 81 Transaction Sequence Number, this is a number assigned by SCTP to 82 assure reliable delivery of user data within an association. 84 2 Stream Control Transmission Protocol -- SCTP 86 2.1 Introduction 88 The Stream Control Transmission Protocol (SCTP) provides a high 89 reliable, redundant transport between two endpoints. The interface 90 between SCTP and its applications is handled via adaptation layers 91 which provide a intermediate layer so that the existing upper layer 92 protocols do not have to change their interface towards the transport 93 medium and internal functionality when they start using SCTP instead 94 of an other transport protocol. 96 The following function are provided by SCTP: - Initialization of 97 transport association - Synchronization of association state - 98 Synchronization of sequence numbering - Reliable Data Transfer - 99 Forward and backward sequence numbering - Timers for transmission and 100 acknowledgement - Notification of out-of-sequence - Retransmission of 101 lost messages - Support of multiple control streams - Separate 102 sequence control and delivery of each stream - Congestion control - 103 Window flow control - Congestion avoidance based on TCP methods, e.g. 104 using 105 retransmission backoff, window reduction, etc. - Detection of 106 session failure by active means, e.g. heartbeat - Termination of 107 association SCTP does support a number of functions that are not 108 provided by current TCP: - no head-of-line blocking, i.e. multiple 109 streams - multilink failover for added reliability - keep-alive 110 function for active rapid failure detection - message verses byte 111 sequence numbering - tighter timer control (than standard TCP 112 implementations) 114 By defining the appropriate User adaptation module, a reliable 115 transport mechanism can be provided: - reliable transmission of 116 packets with end-to-end congestion control provided using methods 117 similar to TCP - choice between sequenced and unsequenced, reliable 118 message delivery - keep-alive message 120 Within a association between the two endpoints, 1 or more stream(s) 121 may be available. These streams are visible to the adaptation layers 122 but are invisible to any layer above the adaptation layer. 124 2.2 Issues affecting deployment of SCTP 126 2.2.1 SCTP Multihoming 128 Redundant communication between 2 SCTP endpoints is achieved by using 129 multihoming where the endpoint is able to send/receive over more than 130 one IP address. 132 Under the assumption that every IP address will have a different path 133 towards the remote endpoint, (this is the responsibility of the 134 routing protocols or of manual configuration), if the transport to 135 one of the IP address (= 1 particular path) fails then the traffic 136 can migrate to the other remaining IP address (= other paths) within 137 the SCTP association. 139 As a practical matter, it is recommended that IP addresses in a 140 multihomed endpoint be assigned IP endpoints from different TLV's to 141 ensure against network failure. 143 Multihoming provides redundant communication in SCTP by allowing 144 communication between two endpoints to continue in the event of 145 failure along a path between the endpoints. 147 SCTP will always send its traffic to a certain transport address (= 148 destination address + port number combination) for as long as the 149 transmission is uninterrupted (= primary). The other transport 150 addresses (secondary paths) will act as a backup in case the primary 151 path goes out of service. The changeover between primary are backup 152 will occur without packet loss and is completely transparent to the 153 application. 155 The port number is the same for all transport addresses of that 156 specific association. 158 Applications directly using SCTP may choose to control the 159 multihoming service themselves. The applications have then to supply 160 the specific IP address to SCTP for each datagram. This might be done 161 for reasons of load-sharing and load-balancing across the different 162 paths. This might not be advisable as the throughput of any of the 163 paths is not known in advance and constantly changes due to the 164 actions of other associations and transport protocols along that 165 particular path, would require very tight feedback of each of the 166 paths to the loadsharing functions of the user. 168 Applications using adaptation layers to run over SCTP do not have 169 that kind of control. The adaptation layers will have to take care of 170 this. 172 By sending a keep alive message on all the multiple paths that are 173 not used for active transmission of messages across the association, 174 it is possible for SCTP to detect whether one or more paths have 175 failed. SCTP will not use these failed paths when a changeover is 176 required. 178 The transmission rate of sending keep alive message should be 179 modifiable and the possible loss of keep alive message could be used 180 for the monitoring and measurements of the concerned paths. 182 2.2.2 Fast retransmit of chunks 184 The retransmission of a message is basically governed by the 185 retransmission timer. So if no acknowledgement is received after a 186 certain time, then the message is retransmitted. However there is a 187 faster way for retransmitting which is not dependant on that timer. 189 Every second message that a node received will be acknowledge to the 190 remote peer. If gaps occur in the acknowledge message at the remote 191 side, then the remote side will wait 3 further gap 192 reports(acknowledgements) before it retransmit the message. As the 193 gap occurs, the node must transmit a SACK on every datagram until 194 there are no more gap. This retransmission will happen far sooner 195 than with a timer. Especially if the traffic volume increases in 196 SCTP, those retransmissions of the chunks would happen faster and 197 faster (and hopefully, they would also be faster acknowledged). In 198 any case if gaps occur, the node will certainly try to acknowledge 199 them faster(irespective of the fact if the SACKs will get to the 200 remote node, where, if received, they would speed up the 201 retransmission of the chunks) 203 See also the paragraph on congestion control and avoidance. 205 2.2.3 Use of SCTP in Network Address Translator (NAT) Networks 207 When a NAT is present between two endpoints, the endpoint that is 208 behind the NAT, i.e., one that does not have a publicly available 209 network address, shall take one of the following options: 211 A) Indicate that only one address can be used by including no 212 transport addresses in the INIT message. This will make the endpoint 213 that receives this Initiation message to consider the sender as only 214 having that one address. This method can be used for a dynamic NAT, 215 but any multi-homing configuration at the endpoint that is behind the 216 NAT will not be visible to its peer, and thus not be taken advantage 217 of. 219 B) Indicate all of its networks in the Initiation by specifying all 220 the actual IP addresses and ports that the NAT will substitute for 221 the endpoint. This method requires that the endpoint behind the NAT 222 must have pre-knowledge of all the IP addresses and ports that the 223 NAT will assign. 225 This requires the adaptation of NAT boxes to search within SCTP 226 outgoing INIT and incoming INIT_ACK mesages for the addresses and 227 replace them with the NAT internal address in addition to replacing 228 the addresses in the IP header. 230 C) Use RSIP [RFCRSIP] where the connection is tunneled from host 231 until the NAT border and the host layers above IP network layer have 232 no knowledge of the NAT internal addresses. 234 D) Use the hostname feature and the DNS to resolve the addresses. 235 (Ed note: have to figure out hows this precisely works) 237 2.2.4 MTU path discovery 239 SCTP discovers the maximal length of the message that can be 240 transported through the network to the final destination without 241 having to fragment(=chop something in pieces) the message in IP 242 network layer. This avoids using IP fragmenting. SCTP level 243 segmentation is beneficial because if a packet is lost during network 244 transmission, only that packet will need to be retransmitted. 245 Contrasted with IP-level segmentation, where the whole unsegmented 246 message will have to be retransmitted, this is a much more effective 247 scheme [RFC1981]. 249 2.2.5 Use of multiple streams 251 A stream in a one-directional stream of bytes between 2 endpoints 252 within a SCTP association. A association can have one or more streams 253 in its association and the number of streams in one direction does 254 NOT need to be the same as the number of streams in the opposite 255 direction. The number of streams in both directions is thus 256 assymmetrical. 258 The application can choose on which stream it can send it data. 259 Streams may specify order of deliver or sequenced delivery. Some 260 application level protocols may reserve certain streams for certain 261 media, for example sending graphical content (jpeg, gif, etc.) of a 262 web page through a certain stream while text through others, and 263 streaming content through others. Any packet loss on one stream will 264 not block packet transmission on others. 266 Each stream within a association should be looked upon as a link 267 between two points. If multiple streams are used then the application 268 is dealing with multiple links towards the destination. Some 269 applications require the use of sequenced delivery, which would 270 require for them to select a certain link to send their message on. 272 2.2.6 Congestion control & avoidance 274 Congestion control and/or avoidance is of primordial importance in 275 any connectionless network. Congestion is the result of approaching 276 or exceeding the processing capacity of the link, network, 277 application and/or transport layers. If the processing capacity is 278 exceeded, then the congestion can be avoided (example taking a other 279 non-congested path towards the destination) or controlled (for 280 example, reducing the rate of messages to that destination). 282 The reaction of SCTP to congestion is detailed in the next 283 paragraphs. 285 Congestion can be controlled and/or avoided on different levels: - 286 Transport: congestion control/avoidance within SCTP, TCP(fig 2.1.2) - 287 Network : Congestion control/avoidance present in the network layers( 288 example: SCCP, MTP ...) - Link layer: flow control 290 SCTP conforms to the model of end-to-end congestion control (Fig 291 2.2.6.2) [RFCSALLY] while ISUP and SCCP model themselves on a link 292 and network based congestion control/overload mechanism (Fig 293 2.2.6.3). 295 | | 296 | Application and/or transport layer | 297 +---------------------------------------------------+ 298 | A 299 | | 300 | +-------------------------------------+ | 301 ---->| |---- 302 | Network layer | 303 ---->| |---- 304 | +-------------------------------------+ | 305 | | 306 | V 307 +---------------------------------------------------+ 308 | | 309 | Link layer | 311 Fig 2.2.6.1 General Congestion model 313 | | 314 |transport layer| Congestion control present based on 315 | SCTP | windows 316 +---------------+ 317 | A 318 V | 319 +---------------+ 320 | | 321 | Network layer | No congestion control present 322 | IP(v4/v6) | in the IP layer 323 +---------------+ 324 | A 325 V | 326 +---------------+ 327 | Ethernet | No congestion control present 328 | Link layer | in the Ethernet link layer 330 Fig 2.2.6.2 End-to-End congestion control 332 | | 333 |Application layer| Congestion control present for 334 | TC + MAP, IN... | specific applications 335 +-----------------+ - MAP: No congestion control 336 | A - IN: Call gapping 337 V | 338 +-----------------+ 339 | | 340 | Network layer | Congestion control present in the 341 | SCCP & MTP | in MTP and SCCP based on link and 342 +-----------------+ destination status 343 | A 344 V | 345 +-----------------+ 346 | MTP lvl 2 | Congestion control present 347 | Link layer | in the link layer 349 Fig 2.2.6.3 Distributed congestion control 351 By default, SCTP associations do not have a fixed capacity assigned 352 to them unless other QoS mechanisms are employed. Thus congestion 353 within SCTP association can and will be affected by all traffic using 354 the same links including other SCTP, TCP, RTP, UDP ... traffic 355 traveling on the same path followed by the SCTP association. 357 2.2.6.1 3-SACK rule in SCTP. 359 The Selective Acknowledgement (SACK) is one of the cornerstones of 360 SCTP. It selectively Acknowledges datagrams that have been 361 successfully received by the remote node. It serves 2 purposes: - it 362 indicates until a certain datagram that all previous datagrams have 363 been received (without any holes in the sequence) and - it indicates 364 the datagrams sequence ranges which have been received (and so does 365 indicate the holes/gaps between them). It provides us with a form of 366 gap/hole report on messages that have been lost or delayed. A hole 367 can consist of one or more messages. 369 sender Receiver 371 - |----- | - 372 Emission I | | I Link delay 373 time - |---- | I time 374 | ----------->| - 375 - |--- | 376 I | ------------>| 377 Round I |-- | 378 trip I | ------------->| 379 time I | /----|<-------- acknowledge sent 380 I | -------- / --->| after 3 data's 381 I | / | 382 - |<------------/ | 384 Round trip Time = RTT 385 Windowsize = Cwnd 387 Fig 2.2.6.4 Influence of Window Size/ Link Speed/ Round Trip Delay 389 Fig 2.2.6.4 is given here as a example where after receiving 3 390 messages an advisory acknowledgement (SACK) is sent (in this case 391 window = 6). Therefore the sender could be kept busy. The 392 acknowledgement opens the window again. The total time (from first 393 emission till the receiving of the acknowledgement) calculates as: 394 (max. windowsize * emission time)/2 + round trip delay. If the round 395 trip time(RTT) is large, the advisory acknowledgments (SACK) will 396 enhance the throughput. 398 The SACK is always generated and send back to the sender either - 399 after every second message received (delayed ack). - after at most 400 200ms after receiving the last message. 402 The reason for the holes may be diverse: - simple message loss - 403 different round trip times of messages being transmitted on different 404 interfaces 406 At the sender end, whenever the sender notices a hole in a SACK, it 407 should wait for 3 further SACKs (identifying the same hole) before 408 taking action. This is 3 strikes besides the first one, so that means 409 4. Thus after 4 SACK, the datagrams belonging to the hole should be 410 retransmitted(and only those). 412 If gaps occur, the receiver end will send SACKs on every data message 413 received instead on being send on every second data message received. 414 As the sender is waiting for the 3 SACK strikes and the receiver is 415 increasing the SACK rate, that would mean that retransmission would 416 be happening faster. Also the window should be opening up more than 417 in the normal case (= transmission without gaps). 419 The 3 SACKs rule might be relaxed in certain networks provided 420 certain condition are met: 422 - private IP network - closed networks - only a single type of 423 application traffic is running on that network (the message in the 424 network exhibit the same characteristics: 425 example: signalling messages). 427 The SACK rule might be configurable in such a networks, if the 428 network operator felt confident in the correctness of the network. 429 This would mean that in case of packet loss, retransmission could be 430 "immediate". 432 SACK will also report duplicate message arrival. See paragraph 433 2.2.6.4. 435 2.2.6.2 Congestion Control 437 The number of messages in flight is determined by the Congestion 438 window (Cwnd). Every time a message is SACK, a new message might be 439 send to the remote side(up till the Cwnd), even if gaps exists which 440 might ultimately lead to retransmissions. 442 The value of the Cwnd is dependant on the slow start and/or 443 congestion avoidance/control. 445 If messages are getting lost, then it is assumed by SCTP that they 446 are lost according to congestion, not that they are lost due to error 447 on the link(such as cable cutthrough ...). 449 When messages are lost then the rate of messages sending is reduced, 450 till no messages are lost. 452 2.2.6.3 Use of Explicit Congestion notification (ECN) 454 Explicit Congestion control is a experimental method for 455 communicating congestion back to the end node. SCTP does not support 456 the use of ECN, but specific recommendations for using ECN with SCTP 457 might be forthcoming. 459 2.2.6.4 Duplicated messages 461 SACKs can get lost. The receiving node would then received duplicated 462 packets. A reason for such a behavior is imbalance between the 2 463 traffic direction, use of different up and down path. 465 (Ed note: something more has to be put here, still thinking on the 466 right words and reading a couple of RFCs on the subject :-) 468 2.2.6.5 SCTP in high throughput delivery networks 470 The TSN is associated with a message, not with the number of bytes(as 471 is the sequence number of TCP) in the message. So the TSN will wrap 472 around less frequently but has a dependency on the length of each 473 message. Use of short messages will lead to a faster wrapping around 474 of the TSN. So in high throughput networks, it is advised to make the 475 messages as long as possible so that the wrap around will be less 476 frequent. 478 SCTP already has a larger window than TCP does even when TCP is using 479 the "large windows" option. 481 2.2.6.6 SCTP in long delay/Fat networks (LFN) 483 Long delay(Fat) Networks consists of network paths which have a high 484 "bandwidth*delay product"(such as satelite links(high delay) or high 485 capacity fiber(high bandwith)). There the 3-SACK rule would lead to 486 enhanced throughput, if the initial windowsize is set higher than 487 2(which is the default value for non-LFNs). 489 The initial windowsize should be set to a higher value (4 or 8) as 490 that would mean that 4 messages would be injected in the network and 491 the first sack would come back at about the same time as the last 492 message before the window is full, is injected. 494 Thus to have the most of the 3 sack rule immediatly, the initial 495 window size should at least be set at 4 (and possible at 8 if we are 496 dealing with really very long delays). 498 The drawback of this is that it makes SCTP more aggressive to begin 499 with(certainly when faced with TCP). 501 For a more precise description of the issues associated with this, 502 refer to [RFC123], [RFC2001] and [RFC2018] 504 2.2.6.7 SCTP in Long Thin Networks(LTN) 506 Long thin networks consists of network paths that traverse "very low 507 bit-rate" links(such as 56 Kbit modem links). This means that a 508 single host can very easy saturate such a link(= pushing the link 509 into congestion). 511 2.2.7 Use of the protocol identifier in SCTP 513 Indicates the the upper layer protocol that is using the 514 associations. The protocol identifier is available to the application 515 and is included in each chunk. 0 is the unknown protocol. This 516 protocol id can be used by firewalls for filtering out certain 517 protocols. If firewalls drops certain protocol id then then 518 association will fail in the end because the TSN will be lost. If the 519 chunk(without its user data) is simulated with the TSN in it, then 520 the user data will be dropped, but the association is preserved. 522 The protocol identifier is administered by IANA[IANA]. 524 2.2.8 Use of QoS methods 526 SCTP is a end-to-end protocol which cannot guarantee the quality-of- 527 service along the complete path(s) taken by the messages of that 528 particular association. If more guarantees are required for improving 529 the reliability of the transport, some form of QoS mechanism may be 530 needed. 532 The possible schemes are as follows. 534 2.2.8.1 Over-provisioning 536 Over-provisioning of the links so that the total traffic running over 537 the link never exceeds the link capacity. In practice, this may be 538 difficult to ensure reliably. 540 2.2.8.2 Private Internets 542 Use of a private network solely for transport purposes. Private 543 networks may allow better control and monitoring of resources 544 available. 546 2.2.8.3 Differentiated services 548 By providing a certain code point in the Type-of-service field (TOS), 549 certain Differential services can be selected. [RFC2597, RFC2598] 551 Setting the code point for transport requires some thought. It is 552 dependant on the kind of differentiate service selected. Also the use 553 of traffic is important: example signalling info should have a higher 554 priority than the user data traffic for which the signalling is 555 responsible(and that relation does not always exist). 557 2.2.8.4 Integrated services 559 By use of integrated services [RFC2208], resources are reserved for 560 signaling transport. 562 If resources are unavailable for to initiate a new signaling 563 transport, that request will be denied. RSVP may not scale well and 564 this solution may prove to be unfeasible. 566 An example is Multi Protocol Label Switching. 568 2.2.9 SCTP Checksum 570 SCTP uses the Adler-32 checksum algorithm. This algorithm will 571 perform better than a 16 bit (CRC or not) checksum or even a 32 bit 572 CRC checksum. 574 The message can also be protected by IPSEC which is much stronger. In 575 that case, the checksum should still be computed. 577 2.2.10 Tunneling of SCTP association over UDP 579 The basic operation of SCTP is to run directly on top of IP. However, 580 due to restrictions placed on implementers by Operating Systems, not 581 all implementations may be able to run over IP directly. Therefore an 582 alternative is given which might circumvent some or all of the 583 restrictions. 585 The STCP messages are transported over UDP instead. The following 586 issues must be observed: - the port number in the UDP header should 587 be the port number assigned to SCTP. The port number in the SCTP 588 common header should be the one assigned to the user adaptation layer 589 or to the application of SCTP. This means that port numbers 590 previously used in UDP and/or TCP can be reused for the same 591 application using SCTP. SCTP DOES NOT change the semantics of the 592 port number just because the protocol identifier is added to the SCTP 593 message. - the checksum field might be used as a additional guard 594 against errors(particular errors in the UDP header). However, the 595 SCTP checksum employed is far better at catching errors, but does not 596 take the UDP header into account. 598 2.2.11 How to define and Use adaptation layers 600 Many different applications may use SCTP for different purposes. They 601 go from File transfer over HTTP transport to signalling information 602 transport. 604 Some applications might want preserve the existing interface with its 605 lower layer (in this case SCTP) while for other applications, this 606 does not pose a problem. A narchitecture has been devised to let the 607 application choose whether they want to run over SCTP directly (just 608 a many applications run over TCP) or let application run on top of a 609 adaptation layer over SCTP. 611 The basic architecture is as in Figure 2.11.1 : 613 User/Application level Protocols 614 | | | 615 +------------------------------------+ 616 | User Adaptation modules | 617 +------------------------------------+ 618 | 619 +------------------------------------+ 620 |Stream Control Transmission protocol| 621 +------------------------------------+ 622 | 623 +------------------------------------+ 624 | Standard IP Transport | 625 +------------------------------------+ 626 | 627 Network Layer (IP) 629 Figure 2.11.1: Transport Components 631 The three components of the transport protocol are : Adaptation 632 modules that support specific primitives, e.g. management 633 indications, required by a particular user/ application protocol. The 634 use of a adaptation protocol is optional. It is only used in case in 635 which the application protocol does not want to change its interface 636 with the underlying layer. 638 the Stream Control Transmission Protocol itself that supports a 639 common set of reliable transport functions. 641 a standard IP transport/network protocol provided by the operating 642 system. In some network scenarios, it has been recognized that TCP 643 can provide limited (but sufficient) reliable transport functionality 644 for some applications. 646 2.2.12 Security considerations 648 The following aspects of security are : 650 Authentication: 652 Information is sent/received from a known and/or trusted partner. 654 Integrity: 656 Information may not be modified while in transit. The integrity of a 657 message in a public network is not guaranteed. 659 Confidentiality: 661 Confidentiality of the user data must be ensured. User data can not 662 be examined by unauthorized users. 664 Availability: 666 The communicating endpoint must remain in service in all 667 circumstances. Some services have very high availability 668 requirements: for example, all SS7 nodes have to remain active for 669 the 99.999% of the time. 671 2.2.12.1 General Considerations 673 SCTP only tries to increase the availability of a network. SCTP does 674 not contain any protocol elements in its messages which are directly 675 related to Authentication, Integrity and Confidentiality functions. 676 It depends for such a features on the IPSEC protocols and 677 architecture. 679 The only function which has some bearing on security of SCTP is the 680 integrity of message in SCTP, which is guarded by a Checksum. This 681 checksum is mandatory if IPSEC is NOT used. If IPSEC is used then the 682 SCTP checksum becomes optional. The use of IPSEC in the SCTP 683 association must in this case be END-TO-END. The use of IPSEC on a 684 part of a path of a SCTP association does NOT relieve SCTP from using 685 the checksum(as this ain't end-to-end transport) 687 The general rule is that IPSEC should be turned on unconditionally. 689 The description of the internet security architecture and the use of 690 it is described in [RFC2401]. 692 2.2.12.2 The cookie mechanism and Denial-of-Service (DOS) attacks 694 The cookie mechanism in SCTP is a measure against Denial-of-Service 695 (DOS) attacks. In a DOS attack, a lot of init chunks are send towards 696 a single terminating node (the source is a bogus node = a invalid 697 source address in the datagram), so that very quickly all resources 698 are used up and that normal users are rejected due to resource 699 shortage. 701 When a INIT chunk is received, the TCB info is encoded and put into 702 the cookie and send to the initiating node via the INIT_ACK. No TCB 703 is allocated at the receiving node as all info is encoded in the 704 cookie and the cookie will return in the COOKIE_ACK (at that time the 705 TCB will be really allocated with the info from the cookie and a full 706 association is set up). As the INIT_ACK will be send back to a bogus 707 address, no COOKIE_ACK will come back and no resources will be tied 708 up in the terminating node. 710 2.2.12.3 Initiate Tag considerations 712 As the tag is fixed during the whole lifetime of the association, the 713 initiate Tag values should be selected as random as possible to help 714 protect against "man in the middle" and "sequence number" attacks. It 715 is suggested that RFC 1750 [RFC1750] be used for the Tag 716 randomization. A new tag is only assigned if a new association is set 717 up. 719 2.2.12.4 Fingerprinting of SCTP 721 Different implementations may show a certain fingerprint in their 722 messages when they have to answer to certain messages send to them. 723 It is advisabel to send only the basic required information back 724 according to the SCTP protocol. 726 2.2.12.5 The ACK-Splitting attack 728 (Ed note : something need to be provided here) 730 3 Recommendations 732 To be provided. 734 4 Adaptation Layers 736 Currently, there are four adaptation layers, to support carrying of 737 SS7 application protocols over IP. These adaptation layers are being 738 developed for different purposes, and there is no assumption that 739 they should interwork - i.e. - M2UA carries M3UA. They should be 740 thought of as individual protocols for specific uses. 742 4.1 IUA 744 There is a need for Switched Circuit Network (SCN) signaling protocol 745 delivery from an ISDN Signaling Gateway (SG) to a Media Gateway 746 Controller (MGC). The delivery mechanism should meet the following 747 criteria 749 * Support for transport of the Q.921 / Q.931 boundary primitives * 750 Support for communication between Layer Management modules on SG and 751 MGC * Support for management of active associations between SG and 752 MGC 754 This draft supports both ISDN Primary Rate Access (PRA) as well as 755 Basic Rate Access (BRA) including the support for both point-to-point 756 mode and point-to-multipoint modes of communication. QSIG adaptation 757 layer requirements do not differ from Q.931 adaptation layer, hence 758 the procedures described in this draft are also applicable to QSIG 759 adaptation layer. 761 4.2 M2UA 763 There is a need for SCN signaling protocol delivery from an Signaling 764 Gateway (SG) to a Media Gateway Controller (MGC) or IP Signaling 765 Point (IPSP). The delivery mechanism should meet the following 766 criteria: 768 * Support for MTP Level 2 / MTP Level 3 interface boundary * 769 Support for communication between Layer Management modules on SG and 770 MGC * Support for management of active associations between the SG 771 and MGC 773 In other words, the Signaling Gateway will transport MTP Level 3 774 messages to a Media Gateway Controller (MGC) or IP Signaling Point 775 (IPSP). In the case of delivery from an SG to an IPSP, the SG and 776 IPSP function as traditional SS7 nodes using the IP network as a new 777 type of SS7 link. This allows for full MTP Level 3 message handling 778 and network management capabilities. 780 4.3 M3UA 782 There is a need for SCN signaling protocol delivery from an SS7 783 Signaling Gateway (SG) to a Media Gateway Controller (MGC) or IP- 784 resident Database as described in the Framework Architecture for 785 Signalling Transport [11]. The delivery mechanism should meet the 786 following criteria: 788 * Support for transfer of all SS7 MTP3-User Part messages (e.g., 789 ISUP, SCCP, TUP, etc.) * Support for the seamless operation of 790 MTP3-User protocol peers * Support for the management of SCTP 791 transport associations and traffic between an SG and one or more MGCs 792 or IP-resident Databases * Support for MGC or IP-resident Database 793 failover and loadsharing * Support for the asynchronous reporting of 794 status changes to management 796 In simplistic terms, the SG will terminate SS7 MTP2 and MTP3 797 protocols and deliver ISUP, SCCP and/or any other MTP3-User protocol 798 messages over SCTP transport associations to MTP3-User peers in MGCs 799 or IP-resident Databases. 801 4.4 SUA 803 This document details the delivery of SCCP-user messages (MAP & CAP 804 over TCAP, RANAP, etc.) over IP. The architecture may be from from 805 an SS7 Signaling Gateway (SG) to an IP-based signaling node (such as 806 an IP-resident Database) as described in the Framework Architecture 807 for Signaling Transport [RFC2719], or between two endpoints located 808 completely within an IP network. The delivery mechanism SHOULD meet 809 the following criteria: 811 * Support for transfer of SS7 SCCP-User Part messages (e.g., TCAP, 812 RANAP, etc.) * Support for SCCP connectionless service. * Support 813 for SCCP connection oriented service. * Support for the seamless 814 operation of SCCP-User protocol peers * Support for the management 815 of SCTP transport associations between an SG and one or more IP-based 816 signaling nodes). * Support for distributed IP-based signaling 817 nodes. * Support for the asynchronous reporting of status changes 818 to management 820 5 References and related work 822 [SCTP] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , 823 Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and 824 Paxson, V."Stream Control Transmission Protocol", , April 2000. Work In Progress. 827 [Q1400] SG11, ITU-T Recommendation Q.1400, " architecture framework 828 for the development of signaling and OA&M protocols using OSI 829 concepts ",1993 831 [HUITEM] Huitema, C., "Routing in the Internet", Prentice-Hall, 1995. 833 [RFC2373] Hinden, R. and Deering, S., "IP Version 6 Addressing 834 Architecture", RFC 2373, July 1998. 836 [RFC2460] Hinden, R. and Deering, S., "Internet Protocol, Version 6 837 (IPv6) Specification", RFC 2460, December 1998. 839 [RFC814] Clark, D.D., "Names, addresses, ports and routes", RFC 0814, 840 July 1982. 842 [RFC2401] Kent, S., and Atkinson, R., "Security Architecture for the 843 Internet Protocol", RFC 2401, November 1998. 845 [RFC1981] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery 846 for IP version 6", RFC 1981, August 1996. 848 [RFC2208] Mankin, A. Ed., Baker, F., , Braden, B., Bradner, S., 849 O`Dell, M., Romanow, A., Weinrib, A. and Zhang, L., "Resource 850 ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some 851 Guidelines on Deployment" , RFC 2208, September 1997. 853 [RFC2597] Heinanen, J., Baker, F., Weiss, W. and Wroclawski, J., 854 "Assured Forwarding PHB Group", RFC2597, June 1999 856 [RFC2598] Jacobson, V., Nichols, K. and Poduri, K., "An Expedited 857 Forwarding PHB", RFC2598, June 1999 859 [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, 860 L., Lin, H., Juhasz, I., Holdrege, M., Sharp, C., "Framework 861 Architecture for Signaling Transport", RFC2719, October 1999 863 [IANA] Internet Assigned Numbers Authority, http://www.iana.org/, 864 April 2000 866 [RFCRSIP] Borella, M., Grabelsky, D., Lo, J., Tuniguchi, K. "Realm 867 specific IP",RFCxxxx, xxxx 2000 869 [RFCSALLY] Floyd, S. Ed., "Congestion Control Principles", RFCxxxx, April 2000 872 [RFC1750] Eastlake, 3rd, D., Crocker, S., Schiller, J., "Randomness 873 Recommendations for Security", RFC1750, December 1994 875 [RFC1323] Jacobson, V., Braden, R., Borman, D., "TCP Extensions for 876 High Performance", RFC1323, May 1992 878 [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast 879 Retransmit, and Fast Recovery Algorithms ", RFC2001, Januarey 1997 881 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., Romanow, A., "TCP 882 Selective Acknowledgement Options ", RFC2018, October 1996 884 6 Acknowledgments 886 The authors wish to thank Renee Revis, R.R. Stewart, Q. Xie, H.J. 887 Schwarzbauer, M. Tuexen, J.P. Martin-Flatin and many others for their 888 invaluable comments. 890 7 Author's Address 892 Lode Coene 893 Siemens Atea 894 Atealaan 34 895 B-2200 Herentals 896 Belgium 898 Phone: +32-14-252081 899 EMail: lode.coene@siemens.atea.be 901 John Loughney 902 Nokia Research Center 903 Itamerenkatu 11-13 904 FIN-00180 Helsinki 905 Finland 907 Phone: +358-9-43761 908 EMail: john.loughney@nokia.com 910 Ian Rytina 911 Ericsson Australia 912 37/360 Elizabeth Street 913 Melbourne, Victoria 3000 914 Australia 916 Phone : - 917 EMail:ian.rytina@ericsson.com 919 Lyndon Ong 920 Nortel Networks 921 4401 Great America Parkway 922 Santa Clara, CA 95054 923 USA 925 Phone: - 926 EMail: long@nortelnetworks.com 928 Expires: October 30, 2000 930 Full Copyright Statement 932 Copyright (C) The Internet Society (2000). All Rights Reserved. 934 This document and translations of it may be copied and furnished 935 to 936 others, and derivative works that comment on or otherwise explain 937 it or assist in its implementation may be prepared, copied, published 938 and distributed, in whole or in part, without restriction of any 939 kind, provided that the above copyright notice and this paragraph 940 are included on all such copies and derivative works. However, this 941 document itself may not be modified in any way, such as by 942 removing the copyright notice or references to the Internet Society or 943 other Internet organizations, except as needed for the purpose of 944 developing Internet standards in which case the procedures for 945 copyrights defined in the Internet Standards process must be 946 followed, or as required to translate it into languages other than 947 English. 949 The limited permissions granted above are perpetual and will not 950 Be revoked by the Internet Society or its successors or assigns. 952 This document and the information contained herein is provided on 953 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 954 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 955 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 956 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 957 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.