idnits 2.17.1 draft-ietf-nsis-ntlp-sctp-14.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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2010) is 5051 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4347 (ref. '2') (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4960 (ref. '3') (Obsoleted by RFC 9260) == Outdated reference: A later version (-06) exists of draft-ietf-tsvwg-dtls-for-sctp-05 -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '9') (Obsoleted by RFC 9293) == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-22 == Outdated reference: A later version (-09) exists of draft-ietf-behave-sctpnat-02 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Fu 3 Internet-Draft C. Dickmann 4 Intended status: Experimental University of Goettingen 5 Expires: December 27, 2010 J. Crowcroft 6 University of Cambridge 7 June 25, 2010 9 General Internet Signaling Transport (GIST) over Stream Control 10 Transmission Protocol (SCTP) and Datagram Transport Layer Security 11 (DTLS) 12 draft-ietf-nsis-ntlp-sctp-14.txt 14 Abstract 16 The General Internet Signaling Transport (GIST) protocol currently 17 uses TCP or Transport Layer Security (TLS) over TCP for connection 18 mode operation. This document describes the usage of GIST over the 19 Stream Control Transmission Protocol (SCTP) and Datagram Transport 20 Layer Security (DTLS). It discusses how the use of SCTP can take 21 advantage of features provided by SCTP, as well as how to establish 22 GIST security over datagram transport protocols with DTLS. 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 December 27, 2010. 41 Copyright Notice 43 Copyright (c) 2010 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 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 5 72 3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1. Message Association Setup . . . . . . . . . . . . . . . . 5 74 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 6 76 3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 6 77 3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 7 78 3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 7 79 4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 8 80 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 8 81 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 8 82 5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 8 83 5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 9 84 6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 9 85 7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 9 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 88 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 94 1. Introduction 96 This document describes the usage of the General Internet Signaling 97 Transport (GIST) protocol [1] and Datagram Transport Layer Security 98 (DTLS) [2] over the Stream Control Transmission Protocol (SCTP) [3]. 100 GIST, in its initial specification for connection mode operation, 101 runs on top of a byte-stream oriented transport protocol providing a 102 reliable, in-sequence delivery, i.e., using the Transmission Control 103 Protocol (TCP) [9] for signaling message transport. However, some 104 Next Steps in Signaling (NSIS) Signaling Layer Protocol (NSLP) [10] 105 context information has a definite lifetime, therefore, the GIST 106 transport protocol could benefit from flexible retransmission, so 107 stale NSLP messages that are held up by congestion can be dropped. 108 Together with the head-of-line blocking and multihoming issues with 109 TCP, these considerations argue that implementations of GIST should 110 support SCTP as an optional transport protocol for GIST. Like TCP, 111 SCTP supports reliability, congestion control and fragmentation. 112 Unlike TCP, SCTP provides a number of functions that are desirable 113 for signaling transport, such as multiple streams and multiple IP 114 addresses for path failure recovery. Furthermore, SCTP offers an 115 advantage of message-oriented transport instead of using the byte 116 stream oriented TCP where one has to provide its own framing 117 mechanisms. In addition, its Partial Reliability extension (PR-SCTP) 118 [4] supports partial retransmission based on a programmable 119 retransmission timer. Furthermore, DTLS provides a viable solution 120 for securing SCTP [5], which allows SCTP to use almost all its 121 transport features and its extensions. 123 This document defines the use of SCTP as the underlying transport 124 protocol for GIST and the use of DTLS as a security mechanism for 125 protecting GIST Messaging Associations and discusses the implications 126 on GIST state maintenance and API between GIST and NSLPs. 127 Furthermore, this document describes how GIST is transported over 128 SCTP and used by NSLPs in order to exploit the additional 129 capabilities offered by SCTP to deliver GIST C-mode messages more 130 effectively. More specifically: 131 o How to use the multiple streams feature of SCTP. 132 o How to use the PR-SCTP extension of SCTP. 133 o How to take advantage of the multi-homing support of SCTP. 135 GIST over SCTP described in this document do not require any changes 136 to the high level operation and structure of GIST. However, adding 137 new transport options requires additional interface code and 138 configuration support to allow applications to exploit the additional 139 transport when appropriate. In addition, SCTP implementions to 140 transport GIST MUST support the optional feature of fragmentation of 141 SCTP user messages. 143 Additionally, this document also specifies how to establish GIST 144 security using DTLS for use in combination with e.g., SCTP and UDP. 146 2. Terminology and Abbreviations 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [6]. Other 151 terminologies and abbreviations used in this document are taken from 152 related specifications ([1], [2], [3], [4]): 153 o SCTP - Stream Control Transmission Protocol 154 o PR-SCTP - SCTP Partial Reliability Extension 155 o MRM - Message Routing Method 156 o MRI - Message Routing Information 157 o SCD - Stack-Configuration-Data 158 o Messaging Association (MA) - a single connection between two 159 explicitly identified GIST adjacent peers, i.e. between a given 160 signalling source and destination address. A messaging 161 association may use a transport protocol; if security protection 162 is required, it may use a specific network layer security 163 association, or use a transport layer security association 164 internally. A messaging association is bi-directional; signaling 165 messages can be sent over it in either direction, referring to 166 flows of either direction. 167 o SCTP Association - A protocol relationship between SCTP endpoints, 168 composed of the two SCTP endpoints and protocol state information. 169 An association can be uniquely identified by the transport 170 addresses used by the endpoints in the association. Two SCTP 171 endpoints MUST NOT have more than one SCTP association between 172 them at any given time. 173 o Stream - A unidirectional logical channel established from one to 174 another associated SCTP endpoint, within which all user messages 175 are delivered in sequence except for those submitted to the 176 unordered delivery service. 178 3. GIST Over SCTP 180 This section defines a new MA-Protocol-ID type, "Forwards-SCTP", for 181 using SCTP as GIST transport protocol. The use of DTLS in GIST is 182 defined in Section 7. 184 3.1. Message Association Setup 185 3.1.1. Overview 187 The basic GIST protocol specification defines two possible protocols 188 to be used in Messaging Associations, namely Forwards-TCP and TLS. 189 This information is a main part of the Stack Configuration Data (SCD) 190 [1]. This section adds "Forwards-SCTP" as another possible protocol 191 option. In Forwards-SCTP, analog to Forwards-TCP, connections 192 between peers are opened in the forwards direction, from the querying 193 node, towards the responder. 195 3.1.2. Protocol-Definition: Forwards-SCTP 197 The MA-Protocol-ID "Forwards-SCTP" denotes a basic use of SCTP 198 between peers. Support for this protocol is OPTIONAL. If this 199 protocol is offered, MA-protocol-options data MUST also be carried in 200 the SCD object. The MA-protocol-options field formats are: 201 o in a Query: no information apart from the field header. 202 o in a Response: 2 byte port number at which the connection will be 203 accepted, followed by 2 pad bytes. 205 The connection is opened in the forwards direction, from the querying 206 node towards the responder. The querying node MAY use any source 207 address and source port. The destination for establishing the 208 message association MUST be derived from information in the Response: 209 the address from the interface- address from the Network-Layer- 210 Information object and the port from the SCD object as described 211 above. 213 Associations using Forwards-SCTP can carry messages with the transfer 214 attribute Reliable=True. If an error occurs on the SCTP connection 215 such as a reset, as can be reported by an SCTP socket API 216 notification[11], GIST MUST report this to NSLPs as discussed in 217 Section 4.1.2 of [1]. For the multi-homing scenario, when a 218 destination address of a GIST over SCTP peer encounters a change, the 219 SCTP API will notify GIST about the availability of different SCTP 220 endpoint addresses and possible change of the primary path. 222 3.2. Effect on GIST State Maintenance 224 As SCTP provides additional functionality over TCP, this section 225 discusses the implications of using GIST over SCTP on GIST State 226 Maintenance. 228 While SCTP defines uni-directional streams, for the purpose of this 229 document, the concept of a bi-directional stream is used. 230 Implementations MUST establish downstream and upstream (uni- 231 directional) SCTP streams always together and use the same stream 232 identifier in both directions. Thus, the two uni-directional streams 233 (in opposite directions) form a bi-directional stream. 235 Due to the multi-streaming support of SCTP, it is possible to use 236 different SCTP streams for different resources (e.g., different NSLP 237 sessions), rather than maintaining all messages along the same 238 transport connection/association in a correlated fashion as TCP 239 (which imposes strict (re)ordering and reliability per transport 240 level). However, there are limitations to the use of multi- 241 streaming. When an SCTP implementation is used for GIST transport, 242 all GIST messages for a particular session MUST be sent over the same 243 SCTP stream to assure the NSLP assumption of in-order delivery. 244 Multiple sessions MAY share the same SCTP stream based on local 245 policy. 247 The GIST concept of Messaging Association re-use is not affected by 248 this document or the use of SCTP. All rules defined in the GIST 249 specification remain valid in the context of GIST over SCTP. 251 3.3. PR-SCTP Support 253 A variant of SCTP, PR-SCTP [4] provides a "timed reliability" 254 service, which would be particularly useful for delivering GIST 255 Connection mode messages. It allows the user to specify, on a per 256 message basis, the rules governing how persistent the transport 257 service should be in attempting to send the message to the receiver. 258 Because of the chunk bundling function of SCTP, reliable and 259 partially reliable messages can be multiplexed over a single PR-SCTP 260 association. Therefore, an SCTP implementation for GIST transport 261 SHOULD attempt to establish a PR-SCTP association using "timed 262 reliability" service instead of a standard SCTP association, if 263 available, to support more flexible transport features for potential 264 needs of different NSLPs. 266 When using a normally reliable session (as opposed to a partially 267 reliable session), if a node has sent the first transmission before 268 the lifetime expires, then the message MUST be sent as a normal 269 reliable message. During episodes of congestion this is particularly 270 unfortunate, as retransmission wastes bandwidth that could have been 271 used for other (non-lifetime expired) messages. The "timed 272 reliability" service in PR-SCTP eliminates this issue and is hence 273 RECOMMENDED to be used for GIST over PR-SCTP. 275 3.4. API between GIST and NSLP 277 GIST specification defines an abstract API between GIST and NSLPs. 278 While this document does not change the API itself, the semantics of 279 some parameters have slightly different interpretation in the context 280 of SCTP. This section only lists those primitives and parameters, 281 that need special consideration when used in the context of SCTP. 282 The relevant primitives from [1] are as follows: 283 o The Timeout parameter in API "SendMessage": According to [1], this 284 parameter represents the "length of time GIST should attempt to 285 send this message before indicating an error." When used with PR- 286 SCTP, this parameter is used as the timeout for the "timed 287 reliability" service of PR-SCTP. 288 o "NetworkNotification": According to [1], this primitive "is passed 289 from GIST to a signalling application. It indicates that a 290 network event of possible interest to the signalling application 291 occurred." Here, if SCTP detects a failure of the primary path, 292 GIST SHOULD also indicate this event to the NSLP by calling this 293 primitive with Network-Notification-Type "Routing Status Change". 294 This notification should be done even if SCTP was able to retain 295 an open connection to the peer due to its multi-homing 296 capabilities. 298 4. Bit-Level Formats 300 4.1. MA-Protocol-Options 302 This section provides the bit-level format for the MA-protocol- 303 options field that is used for SCTP protocol in the Stack- 304 Configuration-Data object of GIST. 306 0 1 2 3 307 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 : SCTP port number | Reserved : 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 SCTP port number = Port number at which the responder will accept 313 SCTP connections 315 The SCTP port number is only supplied if sent by the responder. 317 5. Application of GIST over SCTP 319 5.1. Multi-homing support of SCTP 321 In general, the multi-homing support of SCTP can be used to improve 322 fault-tolerance in case of a path- or link-failure. Thus, GIST over 323 SCTP would be able to deliver NSLP messages between peers even if the 324 primary path is not working anymore. However, for the Message 325 Routing Methods (MRMs) defined in the basic GIST specification such a 326 feature is only of limited use. The default MRM is path-coupled, 327 which means, that if the primary path is failing for the SCTP 328 association, it most likely is also for the IP traffic that is 329 signaled for. Thus, GIST would need to perform a refresh to the NSIS 330 nodes to the alternative path anyway to cope with the route change. 331 When the two endpoints of a multi-homed SCTP association (but none of 332 the intermediate nodes between them) support NSIS, GIST over SCTP 333 provides a robust means for GIST to deliver NSLP messages even when 334 the primary path fails but at least one alternative path between 335 these (NSIS-enabled) endpoints of the multihomed path is available. 336 Additionally, the use of the multi-homing support of SCTP provides 337 GIST and the NSLP with another source to detect route changes. 338 Furthermore, for the time between detection of the route change and 339 recovering from it, the alternative path offered by SCTP can be used 340 by the NSLP to make the transition more smoothly. Finally, future 341 MRMs might have different properties and therefore benefit from 342 multi-homing more broadly. 344 5.2. Streaming support in SCTP 346 Streaming support in SCTP is advantageous for GIST. It allows better 347 parallel processing, in particular by avoiding head of line blocking 348 issue in TCP. Since a same GIST MA may be reused by multiple 349 sessions, using TCP as transport for GIST signaling messages 350 belonging to different sessions may be blocked if another message is 351 dropped. In the case of SCTP, this can be avoided as different 352 sessions having different requirements can belong to different 353 streams, thus a message loss or reordering in a stream will only 354 affect the delivery of messages within that particular stream, and 355 not any other streams. 357 6. NAT Traversal Issue 359 NAT traversal for GIST over SCTP will follow Section 7.2 of [1] and 360 the GIST extensibility capabilities defined in [12]. This 361 specification does not define NAT traversal procedure for GIST over 362 SCTP, although an approach for SCTP NAT traversal is described in 363 [13]. 365 7. Use of DTLS with GIST 367 This section specifies a new MA-Protocol-ID "DTLS" for the use of 368 DTLS in GIST, which denotes a basic use of datagram transport layer 369 channel security, initially in conjunction with GIST over SCTP. It 370 provides server (i.e., GIST transport receiver) authentication and 371 integrity (as long as the NULL cipher suite is not selected during 372 cipher suite negotiation), as well as optionally replay protection 373 for control packets. The use of DTLS for securing GIST over SCTP 374 allows GIST to take the advantage of features provided by SCTP and 375 its extensions. The usage of DTLS for GIST over SCTP is similar to 376 TLS for GIST as specified in [1], where a stack-proposal containing 377 both MA-Protocol-IDs for SCTP and DTLS during the GIST handshake 378 phase. 380 The usage of DTLS [2] for securing GIST over datagram transport 381 protocols MUST be implemented and SHOULD be used. 383 GIST message associations using DTLS may carry messages with transfer 384 attributes requesting confidentiality or integrity protection. The 385 specific DTLS version will be negotiated within the DTLS layer 386 itself, but implementations MUST NOT negotiate to protocol versions 387 prior to DTLS v1.0 and MUST use the highest protocol version 388 supported by both peers. NULL authentication and integrity ciphers 389 MUST NOT be negotiated for GIST nodes supporting DTLS. For 390 confidentiality ciphers, nodes can negotiate the NULL ciphersuites. 391 The same rules for negotiating TLS cipher suites as specified in 392 Section 5.7.3 of [1] apply. 394 DTLS renegotiation [7] may cause problems for applications such that 395 connection security parameters can change without the application 396 knowing it. Hence, it is RECOMMENDED that renegotiation be disabled 397 for GIST over DTLS. 399 No MA-protocol-options field is required for DTLS. The configuration 400 information for the transport protocol over which DTLS is running 401 (e.g. SCTP port number) is provided by the MA-protocol-options for 402 that protocol. 404 8. Security Considerations 406 The security considerations of [1], [3] and [2] apply. Additionally, 407 although [5] does not support replay detection in the DTLS over SCTP, 408 the SCTP replay protection mechanisms [3] [8] should be able to 409 protect NSIS messages transported using GIST over (DTLS over) SCTP 410 from replay attacks. 412 9. IANA Considerations 414 This specification requests the following codepoints (MA-Protocol- 415 IDs) be assigned in a registry created by [1]: 417 +---------------------+------------------------------------------+ 418 | MA-Protocol-ID | Protocol | 419 +---------------------+------------------------------------------+ 420 | 3 | SCTP opened in the forwards direction | 421 | | | 422 | 4 | DTLS initiated in the forwards direction | 423 +---------------------+------------------------------------------+ 425 Note that MA-Protocol-ID "DTLS" is never used alone but always 426 coupled with a transport protocol specified in the stack proposal. 428 10. Acknowledgments 430 The authors would like to thank John Loughney, Jukka Manner, Magnus 431 Westerlund, Sean Turner, Lars Eggert, Jeffrey Hutzelman, Robert 432 Hancock, Andrew McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan 433 Demter, Lauri Liuhto, Michael Tuexen, and Roland Bless for their 434 helpful suggestions. 436 11. References 438 11.1. Normative References 440 [1] Schulzrinne, H. and M. Stiemerling, "GIST: General Internet 441 Signalling Transport", draft-ietf-nsis-ntlp-20 (work in 442 progress), June 2009. 444 [2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 445 Security", RFC 4347, April 2006. 447 [3] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 448 September 2007. 450 [4] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, 451 "Stream Control Transmission Protocol (SCTP) Partial 452 Reliability Extension", RFC 3758, May 2004. 454 [5] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 455 Transport Layer Security (DTLS) for Stream Control Transmission 456 Protocol (SCTP)", draft-ietf-tsvwg-dtls-for-sctp-05 (work in 457 progress), March 2010. 459 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 460 Levels", BCP 14, RFC 2119, March 1997. 462 [7] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport 463 Layer Security (TLS) Renegotiation Indication Extension", 464 RFC 5746, February 2010. 466 [8] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 467 "Authenticated Chunks for the Stream Control Transmission 468 Protocol (SCTP)", RFC 4895, August 2007. 470 11.2. Informative References 472 [9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 473 September 1981. 475 [10] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 476 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 477 June 2005. 479 [11] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei, 480 "Sockets API Extensions for Stream Control Transmission 481 Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-22 (work in 482 progress), March 2010. 484 [12] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and 485 Extending the NSIS Protocol Family", draft-ietf-nsis-ext-07 486 (work in progress), April 2010. 488 [13] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 489 Transmission Protocol (SCTP) Network Address Translation", 490 draft-ietf-behave-sctpnat-02 (work in progress), December 2009. 492 Authors' Addresses 494 Xiaoming Fu 495 University of Goettingen 496 Institute of Computer Science 497 Goldschmidtstr. 7 498 Goettingen 37077 499 Germany 501 Email: fu@cs.uni-goettingen.de 502 Christian Dickmann 503 University of Goettingen 504 Institute of Computer Science 505 Goldschmidtstr. 7 506 Goettingen 37077 507 Germany 509 Email: mail@christian-dickmann.de 511 Jon Crowcroft 512 University of Cambridge 513 Computer Laboratory 514 William Gates Building 515 15 JJ Thomson Avenue 516 Cambridge CB3 0FD 517 UK 519 Email: jon.crowcroft@cl.cam.ac.uk