idnits 2.17.1 draft-ietf-rtcweb-data-channel-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3931 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-03) exists of draft-stewart-tsvwg-sctp-ndata-01 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-00 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-04 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-06 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-03 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-11 == Outdated reference: A later version (-03) exists of draft-tuexen-tsvwg-sctp-prpolicies-02 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Jesup 3 Internet-Draft Mozilla 4 Intended status: Standards Track S. Loreto 5 Expires: January 16, 2014 Ericsson 6 M. Tuexen 7 Muenster Univ. of Appl. Sciences 8 July 15, 2013 10 RTCWeb Data Channels 11 draft-ietf-rtcweb-data-channel-05.txt 13 Abstract 15 The Web Real-Time Communication (WebRTC) working group is charged to 16 provide protocol support for direct interactive rich communication 17 using audio, video, and data between two peers' web-browsers. This 18 document specifies the non-media data transport aspects of the WebRTC 19 framework. It provides an architectural overview of how the Stream 20 Control Transmission Protocol (SCTP) is used in the WebRTC context as 21 a generic transport service allowing Web Browser to exchange generic 22 data from peer to peer. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 16, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Use Cases for Unreliable Data Channels . . . . . . . . . 3 62 3.2. Use Cases for Reliable Data Channels . . . . . . . . . . 3 63 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. SCTP over DTLS over UDP Considerations . . . . . . . . . . . 5 65 6. The Usage of SCTP in the RTCWeb Context . . . . . . . . . . . 8 66 6.1. SCTP Protocol Considerations . . . . . . . . . . . . . . 8 67 6.2. Association Setup . . . . . . . . . . . . . . . . . . . . 9 68 6.3. SCTP Streams . . . . . . . . . . . . . . . . . . . . . . 9 69 6.4. Channel Definition . . . . . . . . . . . . . . . . . . . 9 70 6.5. Usage of Payload Protocol Identifier . . . . . . . . . . 10 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 10.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 Non-media data types in the context of RTCWeb are handled by using 82 SCTP [RFC4960] encapsulated in DTLS [RFC6347]. 84 +----------+ 85 | SCTP | 86 +----------+ 87 | DTLS | 88 +----------+ 89 | ICE/UDP | 90 +----------+ 92 Figure 1: Basic stack diagram 94 The encapsulation of SCTP over DTLS (see 95 [I-D.ietf-tsvwg-sctp-dtls-encaps]) over ICE/UDP (see [RFC5245]) 96 provides a NAT traversal solution together with confidentiality, 97 source authentication, and integrity protected transfers. This data 98 transport service operates in parallel to the media transports, and 99 all of them can eventually share a single transport-layer port 100 number. 102 SCTP as specified in [RFC4960] with the partial reliability extension 103 defined in [RFC3758] provides multiple streams natively with 104 reliable, and partially-reliable delivery modes. 106 The remainder of this document is organized as follows: Section 4 and 107 Section 3 provide requirements and use cases for both unreliable and 108 reliable peer to peer datagram base channel; Section 5 arguments SCTP 109 over DTLS over UDP; Section 6 provides an specification of how SCTP 110 should be used by the RTCWeb protocol framework for transporting non- 111 media data between browsers. 113 2. Conventions 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 3. Use Cases 121 This section defined use cases specific to data channels. For 122 general use cases see [I-D.ietf-rtcweb-use-cases-and-requirements]. 124 3.1. Use Cases for Unreliable Data Channels 126 U-C 1 A real-time game where position and object state information 127 is sent via one or more unreliable data channels. Note that at 128 any time there may be no media channels, or all media channels may 129 be inactive, and that there may also be reliable data channels in 130 use. 132 U-C 2 Providing non-critical information to a user about the reason 133 for a state update in a video chat or conference, such as Mute 134 state. 136 3.2. Use Cases for Reliable Data Channels 138 U-C 3 A real-time game where critical state information needs to be 139 transferred, such as control information. Such a game may have no 140 media channels, or they may be inactive at any given time, or may 141 only be added due to in-game actions. 143 U-C 4 Non-realtime file transfers between people chatting. Note 144 that this may involve a large number of files to transfer 145 sequentially or in parallel, such as when sharing a folder of 146 images or a directory of files. 148 U-C 5 Realtime text chat while talking with an individual or with 149 multiple people in a conference. 151 U-C 6 Renegotiation of the set of media streams in the 152 PeerConnection. 154 U-C 7 Proxy browsing, where a browser uses data channels of a 155 PeerConnection to send and receive HTTP/HTTPS requests and data, 156 for example to avoid local internet filtering or monitoring. 158 4. Requirements 160 This section lists the requirements for P2P data channels between two 161 browsers. 163 Req. 1 Multiple simultaneous data channels MUST be supported. Note 164 that there may 0 or more media streams in parallel with the data 165 channels, and the number and state (active/inactive) of the media 166 streams may change at any time. 168 Req. 2 Both reliable and unreliable data channels MUST be 169 supported. 171 Req. 3 Data channels MUST be congestion controlled; either 172 individually, as a class, or in conjunction with the media 173 streams, to ensure that data channels don't cause congestion 174 problems for the media streams, and that the RTCWeb PeerConnection 175 as a whole is fair with competing traffic such as TCP. 177 Req. 4 The application SHOULD be able to provide guidance as to the 178 relative priority of each data channel relative to each other, and 179 relative to the media streams. [ TBD: how this is encoded and 180 what the impact of this is. ] This will interact with the 181 congestion control algorithms. 183 Req. 5 Data channels MUST be secured; allowing for confidentiality, 184 integrity and source authentication. See 185 [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch] for 186 detailed info. 188 Req. 6 Data channels MUST provide message fragmentation support 189 such that IP-layer fragmentation can be avoided no matter how 190 large a message the Javascript application passes to be sent. It 191 also MUST ensure that large data channel transfers don't unduely 192 delay traffic on other data channels. 194 Req. 7 The data channel transport protocol MUST NOT encode local IP 195 addresses inside its protocol fields; doing so reveals potentially 196 private information, and leads to failure if the address is 197 depended upon. 199 Req. 8 The data channel transport protocol SHOULD support 200 unbounded-length "messages" (i.e., a virtual socket stream) at the 201 application layer, for such things as image-file-transfer; 202 Implementations might enforce a reasonable message size limit. 204 Req. 9 The data channel transport protocol SHOULD avoid IP 205 fragmentation. It MUST support PMTU discovery and MUST NOT rely 206 on ICMP or ICMPv6 being generated or being passed back, especially 207 for PMTU discovery. 209 Req. 10 It MUST be possible to implement the protocol stack in the 210 user application space. 212 5. SCTP over DTLS over UDP Considerations 214 The important features of SCTP in the RTCWeb context are: 216 o TCP-friendly congestion control. 218 o The congestion control is modifiable for integration with media 219 stream congestion control. 221 o Support for multiple channels with different characteristics. 223 o Support for out-of-order delivery. 225 o Support for large datagrams and PMTU-discovery and fragmentation. 227 o Reliable or partial reliability support. 229 o Support of multiple streams. 231 SCTP multihoming will not be used in RTCWeb. The SCTP layer will 232 simply act as if it were running on a single-homed host, since that 233 is the abstraction that the lower layer (a connection oriented, 234 unreliable datagram service) exposes. 236 The encapsulation of SCTP over DTLS defined in 237 [I-D.ietf-tsvwg-sctp-dtls-encaps] provides confidentiality, source 238 authenticated, and integrity protected transfers. Using DTLS over 239 UDP in combination with ICE enables NAT traversal in IPv4 based 240 networks. SCTP as specified in [RFC4960] MUST be used in combination 241 with the extension defined in [RFC3758] and provides the following 242 interesting features for transporting non-media data between 243 browsers: 245 o Support of multiple unidirectional streams. 247 o Ordered and unordered delivery of user messages. 249 o Reliable and partial-reliable transport of user messages. 251 Each SCTP user message contains a so called Payload Protocol 252 Identifier (PPID) that is passed to SCTP by its upper layer and sent 253 to its peer. This value can be used to multiplex multiple protocols 254 over a single SCTP association. The sender provides for each 255 protocol a specific PPID and the receiver can demultiplex the 256 messages based on the received PPID. 258 The encapsulation of SCTP over DTLS, together with the SCTP features 259 listed above satisfies all the requirements listed in Section 4. 261 The layering of protocols for WebRTC is shown in the following Figure 262 2. 264 +------+ 265 |RTCWEB| 266 | DATA | 267 +------+ 268 | SCTP | 269 +--------------------+ 270 | STUN | SRTP | DTLS | 271 +--------------------+ 272 | ICE | 273 +--------------------+ 274 | UDP1 | UDP2 | ... | 275 +--------------------+ 277 Figure 2: WebRTC protocol layers 279 This stack (especially in contrast to DTLS over SCTP [RFC6083] in 280 combination with SCTP over UDP [RFC6951]) has been chosen because it 282 o supports the transmission of arbitrary large user messages. 284 o shares the DTLS connection with the media channels. 286 o provides privacy for the SCTP control information. 288 Considering the protocol stack of Figure 2 the usage of DTLS over UDP 289 is specified in [RFC6347], while the usage of SCTP on top of DTLS is 290 specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. 292 Since DTLS is typically implemented in user-land, the SCTP stack also 293 needs to be a user-land stack. 295 When using DTLS as the lower layer, only single homed SCTP 296 associations MUST be used, since DTLS does not expose any address 297 management to its upper layer. The ICE/UDP layer can handle IP 298 address changes during a session without needing to notify the DTLS 299 and SCTP layers, though it would be advantageous to retest path MTU 300 on an IP address change. 302 DTLS implementations used for this stack SHOULD support controlling 303 fields of the IP layer like the Don't fragment (DF)-bit in case of 304 IPv4 and the Differentiated Services Code Point (DSCP) field required 305 for supporting [I-D.ietf-rtcweb-qos]. Being able to set the (DF)-bit 306 in case of IPv4 is required for performing path MTU discovery. The 307 DTLS implementation SHOULD also support sending user messages 308 exceeding the path MTU. 310 Incoming ICMP or ICMPv6 messages can't be processed by the SCTP 311 layer, since there is no way to identify the corresponding 312 association. Therefore SCTP MUST support performing Path MTU 313 discovery without relying on ICMP or ICMPv6 as specified in [RFC4821] 314 using probing messages specified in [RFC4820]. The initial Path MTU 315 MUST NOT exceed 1280 [ *** need justification ***] bytes until 316 measured otherwise. 318 In general, the lower layer interface of an SCTP implementation 319 SHOULD be adapted to address the differences between IPv4 or IPv6 320 (being connection-less) or DTLS (being connection-oriented). 322 When protocol stack of Figure 2 is used, DTLS protects the complete 323 SCTP packet, so it provides confidentiality, integrity and source 324 authentication of the complete SCTP packet. 326 This protocol stack MUST support the usage of multiple SCTP streams. 327 A user message can be sent ordered or unordered and with partial or 328 full reliability. The partial reliability extension MUST support 329 policies to limit 331 o the transmission and retransmission by time. 333 o the number of retransmissions. 335 Limiting the number of retransmissions to zero combined with 336 unordered delivery provides a UDP-like service where each user 337 message is sent exactly once and delivered in the order received. 339 SCTP provides congestion control on a per-association base. This 340 means that all SCTP streams within a single SCTP association share 341 the same congestion window. Traffic not being sent over SCTP is not 342 covered by the SCTP congestion control. Due to the typical parallel 343 SRTP media streams, a delay-sensitive congestion control algorithm 344 MUST be supported and the congestion control MAY be coordinated 345 between the data channels and the media streams to avoid a data 346 channel transfer ending up with most or all the channel bandwidth. 348 Since SCTP does not support the negotiation of a congestion control 349 algorithm, the algorithm either MUST be negotiated before 350 establishment of the SCTP association or MUST NOT require any 351 negotiation because it only requires sender side behavior using 352 existing information carried in the association. 354 6. The Usage of SCTP in the RTCWeb Context 356 6.1. SCTP Protocol Considerations 358 The DTLS encapsulation of SCTP packets as described in 359 [I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used. The following SCTP 360 protocol extensions are required: 362 o The stream reset extension defined in [RFC6525] MUST be supported. 363 It is used for closing channels. 365 o The dynamic address reconfiguration extension defined in [RFC5061] 366 MUST be used to signal the support of the stream reset extension 367 defined in [RFC6525], other features of [RFC5061] MUST NOT be 368 used. 370 o The partial reliability extension defined in [RFC3758] MUST be 371 supported. In addition to the timed reliability PR-SCTP policy 372 defined in [RFC3758], the limited retransmission policy defined in 373 [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported. 375 o The message interleaving extension defined in 376 [I-D.stewart-tsvwg-sctp-ndata] MUST be supported. 378 6.2. Association Setup 380 The SCTP association will be set up when the two endpoints of the 381 WebRTC PeerConnection agree on opening it, as negotiated by JSEP 382 (typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. Additionally, 383 the negotiation SHOULD include some type of congestion control 384 selection. It will use the DTLS connection selected via SDP; 385 typically this will be shared via BUNDLE or equivalent with DTLS 386 connections used to key the DTLS-SRTP media streams. 388 The application SHOULD indicate the initial number of streams 389 required when opening the association, and if no value is supplied, 390 the implementation SHOULD provide an appropriate default. If more 391 simultaneous streams are needed, [RFC6525] allows adding additional 392 (but not removing) streams to an existing association. Note there 393 can be up to 65536 SCTP streams per SCTP association in each 394 direction. 396 6.3. SCTP Streams 398 SCTP defines a stream as an unidirectional logical channel existing 399 within an SCTP association one to another SCTP endpoint. The streams 400 are used to provide the notion of in-sequence delivery and for 401 multiplexing. Each user message is sent on a particular stream, 402 either order or unordered. Ordering is preserved only for ordered 403 messages sent on the same stream. 405 6.4. Channel Definition 407 The W3C has consensus on defining the application API for WebRTC 408 dataChannels to be bidirectional. They also consider the notions of 409 in-sequence, out-of-sequence, reliable and un-reliable as properties 410 of Channels. One strong wish is for the application-level API to be 411 close to the API for WebSockets, which implies bidirectional streams 412 of data and waiting for onopen to fire before sending, a textual 413 label used to identify the meaning of the stream, among other things. 415 The realization of a bidirectional Data Channel is a pair of one 416 incoming stream and one outgoing SCTP stream. 418 The simple protocol specified in [I-D.jesup-rtcweb-data-protocol] 419 MUST be used to set up and manage the bidirectional data channels. 421 Note that there's no requirement for the SCTP streams used to create 422 a bidirectional channel have the same number in each direction. How 423 stream values are selected is protocol and implementation dependent. 425 Closing of a Data Channel MUST be signaled by resetting the 426 corresponding streams [RFC6525]. Resetting a stream set the Stream 427 Sequence Numbers (SSNs) of the stream back to 'zero' with a 428 corresponding notification to the application layer that the reset 429 has been performed. Streams are available to reuse after a reset has 430 been performed. 432 [RFC6525] also guarantees that all the messages are delivered (or 433 expired) before resetting the stream. 435 6.5. Usage of Payload Protocol Identifier 437 The SCTP Payload Protocol Identifiers (PPIDs) can be used to signal 438 the interpretation of the "Payload data", like the protocol specified 439 in [I-D.jesup-rtcweb-data-protocol] uses them to identify a 440 Javascript string, a Javascript binary data (ArrayBuffer or Blob) and 441 to provide fragmentation support for large messages that may cause 442 the message to monopolize the SCTP association. 444 7. Security Considerations 446 This document does not add any additional considerations to the ones 447 given in [I-D.ietf-rtcweb-security] and 448 [I-D.ietf-rtcweb-security-arch]. 450 8. IANA Considerations 452 This document does not require any actions by the IANA. 454 9. Acknowledgments 456 Many thanks for comments, ideas, and text from Harald Alvestrand, 457 Adam Bergkvist, Cullen Jennings, Eric Rescorla, Randall Stewart, 458 Justin Uberti, and Magnus Westerlund. 460 10. References 462 10.1. Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 468 Conrad, "Stream Control Transmission Protocol (SCTP) 469 Partial Reliability Extension", RFC 3758, May 2004. 471 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 472 Parameter for the Stream Control Transmission Protocol 473 (SCTP)", RFC 4820, March 2007. 475 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 476 Discovery", RFC 4821, March 2007. 478 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 479 4960, September 2007. 481 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 482 Kozuka, "Stream Control Transmission Protocol (SCTP) 483 Dynamic Address Reconfiguration", RFC 5061, September 484 2007. 486 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 487 (ICE): A Protocol for Network Address Translator (NAT) 488 Traversal for Offer/Answer Protocols", RFC 5245, April 489 2010. 491 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 492 Security Version 1.2", RFC 6347, January 2012. 494 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 495 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 496 6525, February 2012. 498 [I-D.stewart-tsvwg-sctp-ndata] 499 Stewart, R., Tuexen, M., and S. Loreto, "A New Data Chunk 500 for Stream Control Transmission Protocol", draft-stewart- 501 tsvwg-sctp-ndata-01 (work in progress), February 2013. 503 [I-D.jesup-rtcweb-data-protocol] 504 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 505 Protocol", draft-jesup-rtcweb-data-protocol-04 (work in 506 progress), February 2013. 508 [I-D.ietf-tsvwg-sctp-dtls-encaps] 509 Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS 510 Encapsulation of SCTP Packets for RTCWEB", draft-ietf- 511 tsvwg-sctp-dtls-encaps-00 (work in progress), February 512 2013. 514 [I-D.ietf-rtcweb-security] 515 Rescorla, E., "Security Considerations for RTC-Web", 516 draft-ietf-rtcweb-security-04 (work in progress), January 517 2013. 519 [I-D.ietf-rtcweb-security-arch] 520 Rescorla, E., "RTCWEB Security Architecture", draft-ietf- 521 rtcweb-security-arch-06 (work in progress), January 2013. 523 [I-D.ietf-rtcweb-jsep] 524 Uberti, J. and C. Jennings, "Javascript Session 525 Establishment Protocol", draft-ietf-rtcweb-jsep-03 (work 526 in progress), February 2013. 528 [I-D.ietf-rtcweb-qos] 529 Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and 530 other packet markings for RTCWeb QoS", draft-ietf-rtcweb- 531 qos-00 (work in progress), October 2012. 533 10.2. Informative References 535 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 536 Transport Layer Security (DTLS) for Stream Control 537 Transmission Protocol (SCTP)", RFC 6083, January 2011. 539 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 540 Control Transmission Protocol (SCTP) Packets for End-Host 541 to End-Host Communication", RFC 6951, May 2013. 543 [I-D.ietf-rtcweb-use-cases-and-requirements] 544 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 545 Time Communication Use-cases and Requirements", draft- 546 ietf-rtcweb-use-cases-and-requirements-11 (work in 547 progress), June 2013. 549 [I-D.tuexen-tsvwg-sctp-prpolicies] 550 Loreto, S., Seggelmann, R., Stewart, R., and M. Tuexen, 551 "Additional Policies for the Partial Delivery Extension of 552 the Stream Control Transmission Protocol", draft-tuexen- 553 tsvwg-sctp-prpolicies-02 (work in progress), July 2013. 555 Authors' Addresses 557 Randell Jesup 558 Mozilla 559 US 561 Email: randell-ietf@jesup.org 562 Salvatore Loreto 563 Ericsson 564 Hirsalantie 11 565 Jorvas 02420 566 FI 568 Email: salvatore.loreto@ericsson.com 570 Michael Tuexen 571 Muenster University of Applied Sciences 572 Stegerwaldstrasse 39 573 Steinfurt 48565 574 DE 576 Email: tuexen@fh-muenster.de