idnits 2.17.1 draft-mankin-im-session-guide-00.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 12 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 27 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 491: '... messages MUST be capable of negotia...' RFC 2119 keyword, line 494: '...ession messaging MUST NOT use UDP as a...' RFC 2119 keyword, line 496: '...ession messaging MUST support congesti...' RFC 2119 keyword, line 499: '... MUST explicitly specify the identit...' RFC 2119 keyword, line 504: '... MUST support end-to-end confidentia...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) == Unused Reference: 'MIDCOM' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'STUN' is defined on line 588, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) -- Possible downref: Normative reference to a draft: ref. 'MESSAGE' -- Possible downref: Normative reference to a draft: ref. 'SESSION' -- Possible downref: Normative reference to a draft: ref. 'IM-SDP' ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Downref: Normative reference to an Informational RFC: RFC 3027 (ref. 'NAT') -- Possible downref: Non-RFC (?) normative reference: ref. 'NAT-G' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIDCOM' -- Possible downref: Non-RFC (?) normative reference: ref. 'STUN' -- Possible downref: Non-RFC (?) normative reference: ref. 'OPES' -- Possible downref: Non-RFC (?) normative reference: ref. 'CONG' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft Allison Mankin 4 draft-mankin-im-session-guide-00.txt USC/ISI 5 November, 2001 Jon Peterson 6 Expires: May, 2002 NeuStar 8 Guidelines for Instant Message Sessions 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/lid-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This document is an individual submission to the IETF. Comments 31 should be directed to the authors. 33 Abstract 35 This document recommends a set of guidelines for session-based 36 instant messaging, focusing particularly on security properties, the 37 selection of transport protocols and the effects of network 38 intermediaries. 40 1. Introduction 42 As the standardization of instant messaging systems in the IETF has 43 progressed, a model has developed that decouples the signaling used 44 to establish an instant messaging session from session data itself. A 45 set of guidelines with regard to protocol and architecture selection 46 for decomposed sessions of instant messages are proposed in this 47 document. 49 Guidelines for Instant Message Sessions November 2001 51 After introducing the distinction between the 'session model' of 52 instant message transmission and the traditional 'paging model', the 53 authors propose a set of rules for selecting underlying transport 54 protocols for instant messaging sessions and describe some session- 55 layer characteristics that are required for proper management and 56 security of instant messages. These principles are complicated by the 57 introduction of network intermediaries that operate on instant 58 messaging sessions; the repercussions of intermediaries for the 59 transport and session layer mechanisms are explored, and measures to 60 diminish the impact of intermediaries on instant message sessions are 61 recommended. Finally, a set of normative guidelines derived from the 62 preceding text are enumerated. 64 The guidelines presented in this document have resulted from 65 discussions in the SIMPLE WG of the IETF pursuant to the use of the 66 Session Initiation Protocol (SIP, [2543]) for instant messaging 67 applications. The guidelines below have been somewhat generalized to 68 apply more broadly to any instant messaging system that admits of a 69 signaling/session distinction. SIP is however used in examples 70 throughout the document to illustrate typical protocol behavior. 72 2. Session Model and Paging Model 74 2.1 Session Model 76 Some solutions for exchanging instant messages propose a two-layer 77 approach in which preliminary signaling is used to characterize an 78 instant messaging session that will be established separately. 79 Usually the traffic of the instant messaging session, when it has 80 been initiated, will follow a different path through the network than 81 the signaling that preceded it. Architectures using this 82 signaling/session distinction will hereafter be referred to as 83 examples of the 'session model.' An example of the session model is 84 given in [SESSION]. 86 1)Request +-------+ 87 +--------->| IM |-----------+ 88 | Session |Session| | 89 | |Router | 2) Accept | 90 SIGNALING | +--------| |<--------+ | 91 | | +-------+ Session| | 92 | | | | 93 | V | V 94 +---------+ SESSION +---------+ 95 |IM Client|<------------------------>|IM Client| 96 +---------+ 3) Exchange IMs +---------+ 98 Guidelines for Instant Message Sessions November 2001 100 102 The purpose of the initial signaling in the session model is twofold: 104 First, to locate the party with whom the originator would like to have a 105 session. This may include transmitting messages through proxy servers or 106 other signaling intermediaries before the message arrives at the host 107 with whom an instant messaging session will be shared. 109 Second, to negotiate capabilities associated with the exchange of 110 instant messages. These would include acceptable MIME types that might 111 appear in messages, as well as necessary information about how and where 112 instant messages should be sent (IP addresses and ports, transports, and 113 so forth). 115 Once preliminary signaling has completed, the instant messaging session 116 begins in accordance with the characteristics described in the 117 preliminary signaling. Usually, this will entail establishing a new 118 network connection specifically for instant messages separate from the 119 network connection that was used for signaling. Ideally, this instant 120 messaging connection will go directly end-to-end between the 121 participants in a session. 123 This signaling/session distinction is common in Internet telephony 124 systems (such as SIP), Internet gaming and many other real-time 125 communications applications, although commonly in these applications the 126 session is described as 'media' and is transmitted over RTP ([1889]). 128 2.2 Paging Model 130 In contrast to the session model is the 'paging model' for instant 131 messaging, in which the preliminary signaling and the transmission of 132 actual instant messages are conflated. Rather than sending any 133 preliminary signaling, endpoints send instant messages without preamble; 134 a set of headers containing routing and capability information is 135 prepended to each individual instant message. An example of the paging 136 model can be found in [MESSAGE]. 138 Guidelines for Instant Message Sessions November 2001 140 1) Transmit +-------+ 141 +--------->| IM |-----------+ 142 | IM | | | 143 | |Router | 2) ACK | 144 SIGNALING | +--------| |<--------+ | 145 IMs | | +-------+ IM | | 146 | | | | 147 | V | V 148 +---------+ +---------+ 149 |IM Client| |IM Client| 150 +---------+ +---------+ 152 154 2.3 Comparison of paging and session 156 The session model arises from concerns that the paging model is not 157 sufficiently scalable. When large numbers of users are sending many 158 messages simultaneously through the same signaling infrastructure, 159 the signaling infrastructure becomes strained. In the paging model, 160 each instant message contains its own routing and capability data; 161 the signaling infrastructure must therefore essentially make a new 162 forwarding decision each time an instant message is sent. 164 Additionally, from a sheer network capacity perspective instant 165 messages sent using the paging model are larger than instant messages 166 sent using the session model. The size of any headers containing 167 routing and capability information may significantly exceed the size 168 of an instant message. In the session model, only session management 169 information adds to the length of the instant messaging content. 171 Finally, the separation of signaling and session greatly facilitates 172 the implementation of complex services like advanced call-control 173 (transfer and redirection) and conferencing. Note that the examples 174 below assume simple two-participant IM sessions. 176 3. Transport for Instant Messaging Sessions 178 3.1 Transport 180 In the session model, when an instant messaging session is requested, 181 the preliminary signaling proposes the characteristics of the 182 connection over which instant messages will be sent. These 183 characteristics include the underlying transport protocol that will 184 be used to carry instant messages. 186 Any IM system that supports the session model needs a means for 188 Guidelines for Instant Message Sessions November 2001 190 specifying in the preliminary signaling what transport protocol 191 should be used in the instant messaging session. 193 Only protocols supporting congestion control are suitable for 194 carrying sessions of instant messages. Therefore, protocols such as 195 UDP cannot be specified for this purpose. Transport protocols such as 196 TCP and SCTP, which have well-understood congestion control 197 properties, should be used instead. 199 For example, when SIP is used to set up an instant messaging session, 200 an INVITE is sent containing a Session Description Protocol (SDP, 201 [2327]) body that characterizes the desired session; the SDP 202 extensions for instant messaging ([IM-SDP]) allow for the 203 specification of a transport protocol. 205 3.2 Session 207 Merely sending the body of an instant message (perhaps wrapped in 208 MIME headers) over the selected transport layer is, however, not 209 sufficient to create an instant messaging session. Some amount of 210 information is needed at the session layer in order to properly 211 manage a session once it has been established. 213 For example, there needs to be enough information available in each 214 instant message that both participants can determine which session 215 the instant message belongs to (and with that, the identity of the 216 other participant(s) in the session), where this particular instant 217 message fits into the sequence of messages transmitted in the course 218 of this session, and so forth. 220 In simple end-to-end cases much of this information could be inferred 221 from transport or network-layer qualities (from what IP address did I 222 receive this message, what port did it arrive on, etc). But the 223 explicit presence of this information in session messaging becomes 224 important when multiple instant messaging sessions are established 225 between a pair of endpoints. This can occur when the endpoints in 226 question are aggregating instant messaging sessions on behalf of a 227 number of participants (possibly for scalability reasons). Each 228 aggregating endpoint must know, when it receives an instant message 229 from its peer aggregator, which IM client is associated with that 230 particular session. 232 Guidelines for Instant Message Sessions November 2001 234 sender 235 +---------+ individual +---------+ 236 |IM Client|----------+ +---------|IM Client| 237 +---------+ session | | +---------+ 238 +-------+ +-------+ 239 | IM | | IM | 240 +---------+ | | | | +---------+ 241 |IM Client|--------| Muxer |----------| Muxer |-------|IM Client| 242 +---------+ | | aggregate| | +---------+ 243 +-------+ circuit +-------+ 244 | | receiver 245 +---------+ | | +---------+ 246 |IM Client|----------+ +---------|IM Client| 247 +---------+ individual+---------+ 249 251 It may also be desirable for the session layer to manage flow control 252 between competing instant messaging session within an 253 aggregated 'application circuit' in order to ensure that each session 254 receives an equitable share of network and processing resources. 256 Finally, the session layer protocol should have some means of ensuring 257 end-to-end instant message integrity and confidentiality, as well as 258 mutual authentication for session participants. While few would dispute 259 that these are important qualities for an instant messaging system, it 260 is important to note that they apply both to the signaling and the 261 session components of an IM system when the two are decomposed. Even if 262 mutual authentication was performed in the application layer signaling, 263 it is still important that authenticate the remote side of the instant 264 messaging session as well. Obviously confidentiality and integrity as 265 important, if not more so, for the instant messages themselves as they 266 are for session establishment signaling. 268 3.3 Case study of SIP for instant messaging sessions 270 Some have argued within the SIMPLE working group that SIP should be used 271 both to signal the request for a session and then within the session to 272 carry IMs; i.e. that SIP itself should be used as a session-layer 273 protocol to carry instant messages during an instant messaging session. 275 This also raises concerns about the applicability of SIP to the problem 276 of session layer management. If at all possible, the session layer 277 should not carry any superfluous information. While clearly SIP headers 278 provide some of the information described above, they also contain a 279 great deal of routing data (in Via headers, Record-Route and Route, for 280 example) that don't immediately seem necessary in an instant messaging 282 Guidelines for Instant Message Sessions November 2001 284 system. 286 Some known problems arise from using SIP as a session layer protocol 287 when session intermediaries are introduced; these problems are detailed 288 further below. 290 4. Session Intermediaries 292 Ideally, when the session model is used, after the preliminary signaling 293 has been completed session traffic can travel end-to-end between the 294 participants in the session without any further interaction with 295 intermediary network elements. However, in some instances service 296 providers may wish to introduce session intermediaries through which 297 instant messaging session traffic is transmitted. The presence of 298 intermediaries can, however, greatly impact transport and session layer 299 activity in an instant messaging system. 301 4.1 Why Intermediaries? 303 +-------+ 304 +--------->| IM |<----------+ 305 | |Session| | 306 | |Router | | 307 SIGNALING | | | | 308 | +-------+ | 309 | | 310 V SESSION V 311 +---------+ +------------+ +---------+ 312 |IM Client|<---->|Intermediary|<---->|IM Client| 313 +---------+ +------------+ +---------+ 315 317 The most common reason for introducing a session intermediary is 318 network address translation (NAT, [NAT]). As is detailed in [NAT-G], 319 protocols that have separate signaling and session layers have some 320 significant problems traversing NATs. For the most part these 321 problems result from the citation within signaling of IP addresses 322 and ports that are intended for subsequent use in establishing the 323 session - if a signaling message containing these citations crosses a 324 NAT boundary, the addresses to which the message refers may no longer 325 be meaningful (or routable) to a recipient. 327 Application Layer Gateways (ALGs) that analyze and modify signaling 328 in order to facilitate the traversal of specific applications are in 329 widespread use today. Some work has been done towards a more 331 Guidelines for Instant Message Sessions November 2001 333 sophisticated solution to this problem within the MIDCOM working 334 group. In the MIDCOM model (see [x]), an element positioned as a 335 session router can re-write certain aspects of the signaling and 336 control, through an external protocol, an intermediary (or 337 'middlebox') like a NAT in order to allow a session to traverse that 338 intermediary seamlessly. In many MIDCOM architectures, it is 339 desirable for the addition of a middlebox to a network to be 340 transparent to applications that traverse it - in other words, an 341 application has no way of knowing, based on its conventional 342 inspection of signaling and session traffic, that a middlebox is in 343 its session path. ALGs, MIDCOM and pre-MIDCOM architectures are 344 becoming increasingly common elements in service provider networks. 346 NAT NAT 347 +---------+ || +------------+ || +---------+ 348 |IM Client|<-||->|Intermediary|<-||->|IM Client| 349 +---------+ || +------------+ || +---------+ 351 353 But even aside from the necessity of NAT traversal there are a number 354 of reasons why a service provider might introduce session 355 intermediaries. The service provider might wish to enforce certain 356 policies at a session layer (regarding the size of messages, their 357 payload type, perhaps even their content). In some regions lawful 358 intercept of instant messages sent by certain participants might be 359 required. Service providers might want to monitor instant messages 360 statistically for network management or capacity planning. 361 Aggregating many individual sessions into 'application circuits' 362 containing instant messages from multiple sessions (as shown above) 363 also requires intermediaries. 365 4.2 Effects of intermediaries on security 367 The first and most obvious concern with session intermediaries is 368 their potential interference with the secure end-to-end transmission 369 of instant messages. Regardless of whether security is assured in the 370 network, transport or application layer, session establishment is 371 jeopardized if intermediaries need to access the encrypted portions 372 messages in order to fulfill their purpose. Authentication mechanisms 373 may similarly fail if an IM client unknowingly challenges an 374 intermediary in place of a participant. 376 Intermediaries must explicitly be made a part of any desired security 377 associations if session establishment is to be successful. 379 An intermediary also introduces a new point in the network that 380 attackers might attempt to compromise. The security of the end-to-end 382 Guidelines for Instant Message Sessions November 2001 384 session is therefore predicated on the security of these 385 intermediaries. 387 Note that in some architectures it might be desirable to introduce 388 intermediaries specifically to terminate security associations (like 389 TLS proxies/aggregators) for scalability reasons. Not all 390 intermediaries have negative effects on security - but if they are 391 deployed in ignorance of security requirements then they may lead to 392 widespread system failures. 394 4.3 Effects of intermediaries on transport 396 The introduction of intermediaries also potentially allows the 397 characteristics of sessions to be altered in mid-network without the 398 knowledge or consent of the endpoints. 400 +---------+ TCP +------------+ UDP +------------+ TCP +---------+ 401 |IM Client|<---->|Intermediary|<---->|Intermediary|<---->|IM Client| 402 +---------+ +------------+ +------------+ +---------+ 404 406 SIP, for example, only permits transport protocols to be set hop-by- 407 hop rather than end-to-end. Were SIP to be used as a session-layer 408 protocol for an instant messaging session in a network with session 409 intermediaries, this could lead to certain hops in a session 410 reverting to undesirable protocols (e.g. UDP). However, if transport 411 is set globally for a session, there is no risk of this. 413 Even if the transport selected by the endpoints supports congestion 414 control and remains unchanged by intermediaries, network flows that 415 are controlling congestion only over short sequential hops can 416 inhibit competing longer path flows and can use more than a fair 417 share of path resources. A large service provider fielding many 418 intermediaries might thereby inadvertantly (or intentionally) shut 419 out traffic traversing its network that it doesn't intermediate (for 420 further information see [CONG]). 422 Finally, note that setting up multiple 'application circuits' between 423 two hosts is undesirable regardless of their congestion control 424 properties. This is especially important in architectures in which 425 intermediaries aggregate requests for a number of clients. A pair of 426 intermediaries each responsible for a number of users initiating 427 sessions with one another must not establish one circuit per session, 428 obviously. But moreover proxies also should not establish, say, five 429 circuits with one another and load-balance session traffic across 431 Guidelines for Instant Message Sessions November 2001 433 them. 435 4.4 Proliferation of Intermediaries 437 All of the above effects are compounded by the proliferation of 438 intermediaries. In the worst case each administrative domain and/or 439 each NAT boundary which session traffic traverses could conceivably 440 introduce its own intermediary or intermediaries to a session. 442 The proliferation of intermediaries is undesirable as it leads to 443 fate sharing among many unrelated elements in the network. This 444 becomes especially problematic as sessions traverse different 445 administrative domains each of which controls intermediaries. 447 Proliferation makes it much more likely that an individual session 448 will fail, and much more difficult to diagnose failures when they 449 occur. 451 4.5 Discovery of Unknown Intermediaries 453 It may not always be obvious to clients initiating a session that 454 intermediaries have inserted themselves into the session path. 455 However, because of the concerns raised above, endpoints may wish to 456 know of the presence of intermediaries. 458 One mechanism that can be used to determine whether or not any 459 intermediaries are in the session path is to send encrypted instant 460 messages. If any intermediaries require access to the content of the 461 messages in order to perform their function, then session 462 establishment will fail. However, it may not be clear to either 463 endpoint where or why session establishment has failed if this 464 occurs. 466 It is therefore desirable that an intermediary have a mechanism for 467 informing both participants in a session of the intermediary's 468 presence. 470 Discovery will not by itself solve any of the concerns with 471 intermediaries, of course. If an intermediary is broken, or its 472 disposition prevents the creation of necessary security associations, 473 then hopefully there is some way that clients can get around it in 474 order to establish a session. This would only be possible if one of 475 the clients had control over whether or not the intermediary is in 476 the session path. 478 Following the recommendation of a 'one party consent' model given in 479 [OPES], one of the principal participants in the session is required 480 to explicitly authorize an intermediary to enter the session stream. 482 Guidelines for Instant Message Sessions November 2001 484 Service providers should not interpose an intermediary into a instant 485 messaging session unless a client requests that the presence of an 486 intermediary. 488 5. Normative Guidelines 490 o Preliminary signaling used to establish a session of instant 491 messages MUST be capable of negotiating a common underlying transport 492 protocol for instant messaging. 494 o Session messaging MUST NOT use UDP as a transport layer because of 495 UDP's lack of congestion control. Transport protocols used for 496 session messaging MUST support congestion control. 498 o A transport/session layer protocol for instant messaging sessions 499 MUST explicitly specify the identities of the participants in the 500 session, a unique session identifier, and sequencing information for 501 messages in a session. 503 o A transport/session layer solution for instant messaging sessions 504 MUST support end-to-end confidentiality and integrity mechanisms for 505 instant messages. 507 o A transport/session layer solution for instant messaging sessions 508 MUST support end-to-end mutual authentication. 510 o A transport/session layer solution for instant messaging sessions 511 MUST support a mechanism through which a participant in a session can 512 discover the presence of an intermediary. 514 o A transport/session layer solution for instant messaging sessions 515 SHOULD support a mechanism for specifying a single transport protocol 516 end-to-end. 518 o End-to-end security mechanisms for instant messaging sessions 519 SHOULD accommodate network intermediaries that are have been 520 authorized to act on the session. For example, headers on which 521 intermediaries need to operate might be kept in cleartext while the 522 remainder of an instant message was encrypted from end-to-end. 524 o Intermediaries SHOULD NOT interpose themselves between endpoints in 525 a session unless they are specifically authorized to do so by one of 526 the principal participants in a session. 528 o Any intermediaries interposing themselves in instant messaging 529 sessions themselves MUST notify all participants of their presence 530 through either the preliminary signaling or subsequent session 531 messaging. 533 Guidelines for Instant Message Sessions November 2001 535 o Service providers SHOULD NOT deploy intermediaries where they are 536 not absolutely necessary. 538 6. Security Considerations 540 Security considerations for instant messaging sessions are discussed 541 in some detail in Sections 3.2 and 4.2. 543 7. IANA Considerations 545 This document does not have any implications for IANA. 547 8. References 549 [2543] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, 550 "SIP: session initiation protocol," RFC2543, Internet Engineering 551 Task Force, Mar. 1999. 553 [1889] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, 554 "RTP: a transport protocol for real-time applications," RFC1889, 555 Internet Engineering Task Force, Jan. 1996. 557 [MESSAGE] Rosenberg, J. , Willis, D. , Rosenberg, J. , Sparks, R. , 558 Campbell, B. , Schulzrinne, H. , Lennox, J. , Huitema, C. , Aboba, B. 559 , Gurle, D. and D. Oran, "SIP Extensions for Instant Messaging", 560 draft-ietf-simple-im-01.txt (work in progress), July 2001. 562 [SESSION] Campbell, B. and J. Rosenberg, "SIP Instant Message 563 Sessions", draft-ietf-simple-im-session-00.txt (work in progress), 564 July 2001. 566 [IM-SDP] Campbell, B. and J. Rosenberg, "SDP Extensions for SIP 567 Instant Message Sessions", internet-draft draft-ietf-simple-im- 568 sdp-00.txt, July 2001 570 [2327] Handley, M. and V Jacobson, "SDP: Session Description 571 Protocol", RFC 2327, April 1998. 573 [NAT] M. Holdrege and P. Srisuresh, "Protocol complications with the 574 IP network address translator," Request for Comments 3027, Internet 575 Engineering Task Force, Jan. 2001. 577 [NAT-G] D. Senie, "NAT friendly application design guidelines," 578 Internet Draft, Internet Engineering Task Force, Mar. 2001. Work in 579 progress. 581 [MIDCOM] P. Srisuresh, J. Kuthan, and J. Rosenberg, "Middlebox 582 communication architecture and framework," Internet Draft, Internet 584 Guidelines for Instant Message Sessions November 2001 586 Engineering Task Force, Feb. 2001. Work in progress. 588 [STUN] J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy, "STUN - 589 Simple Traversal of UDP Through NATs", Internet Draft, Internet 590 Engineering Task Force, Oct. 2001. Work in progress. 592 [OPES] Internet Architecture Board, "IAB Architectural and Policy 593 Considerations for OPES", Internet-Draft, Internet Engineering Task 594 Force, Oct. 2001. Work in progress. 596 [CONG] S. Floyd and K. Fall, "Promoting the Use of End-to-End 597 Congestion Control in the Internet", IEEE/ACM Transactions on 598 Networking, May 3 1999 599 (http://www.aciri.org/floyd/papers/collapse.may99.pdf) 601 9. Authors' Addresses 603 Allison Mankin 604 USC/ISI 605 4350 N. Fairfax Drive, Suite 620 606 Arlington VA 22203 607 Email: mankin@isi.edu 608 Phone: +1-703-812-3706 610 Jon Peterson 611 NeuStar, Inc. 612 1800 Sutter Street, Suite 570 613 Concord, CA 94520 614 Jon.Peterson@NeuStar.com 616 Full Copyright Statement 618 Copyright (c) The Internet Society (2001). All Rights Reserved. 620 This document and translations of it may be copied and furnished to 621 others, and derivative works that comment on or otherwise explain it 622 or assist in its implementation may be prepared, copied, published 623 and distributed, in whole or in part, without restriction of any 624 kind, provided that the above copyright notice and this paragraph are 625 included on all such copies and derivative works. However, this 626 document itself may not be modified in any way, such as by removing 627 the copyright notice or references to the Internet Society or other 628 Internet organizations, except as needed for the purpose of 629 developing Internet standards in which case the procedures for 630 copyrights defined in the Internet Standards process must be 631 followed, or as required to translate it into languages other than 632 English. 634 Guidelines for Instant Message Sessions November 2001 636 The limited permissions granted above are perpetual and will not be 637 revoked by the Internet Society or its successors or assigns. 639 This document and the information contained herein is provided on an 640 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 641 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 642 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 643 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 644 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.