idnits 2.17.1 draft-aoun-midcom-intrarealmcalls-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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 104 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 171 instances of too long lines in the document, the longest one being 77 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- The document date (February 2002) is 8105 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-midcom-framework-06 == Outdated reference: A later version (-01) exists of draft-rosenberg-midcom-stun-00 == Outdated reference: A later version (-02) exists of draft-ietf-mmusic-sdp-offer-answer-01 Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIDCOM Working Group C.Aoun 3 Internet Draft S. Sen 4 Category: Informational Nortel Networks 5 Expires on July 2001 February 2002 7 Identifying intra-realm calls and 8 Avoiding media tromboning 9 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 This draft suggests several ways to identify calls initiated between 33 users within the same addressing realm. By having this capability, 34 media flows are kept within the same realm, thus avoiding usage of 35 certain network intermediaries and reducing bandwidth requirements 36 on certain access links. 38 Table of Contents 39 Status of this Memo ................................................1 40 Abstract ...........................................................1 41 1 Introduction .....................................................2 42 2 Conventions used in this document ................................3 43 3 Terminology Used .................................................3 44 4 Deployment scenarios .............................................3 45 4.1 Call scenarios .................................................4 46 4.2 Application requirements .......................................5 47 5 Potential solutions to the problem ...............................6 48 5.1 Use domain name comparisons ....................................6 49 5.2 Use realm identifiers ..........................................6 50 5.3 Offer/Answer both private and public addresses .................7 51 6 Conclusion .......................................................8 52 7 References .......................................................8 53 8 Acknowledgments ..................................................9 54 9 Authors' Address .................................................9 55 10 Intellectual Property Statement .................................9 56 11 Full Copyright Statement ........................................9 58 1 Introduction 60 This draft suggests several ways way to identify if a call is being 61 initiated between users within the same realm. If this capability is 62 implemented, media flows are kept within the same addressing realm 63 whenever possible, thus avoiding usage of certain network 64 intermediaries and reducing bandwidth requirements on external links 65 into the realm. 67 Within the MIDCOM and pre-MIDCOM frameworks a solution must be found 68 to avoid calls established within the same realm using unnecessary 69 resources on the Middleboxes and on other devices such as Media 70 Proxies that could the pre-MIDCOM framework. 72 Within the MIDCOM framework, if there is no means to identify which 73 calls are intra-realm calls, all media flows will be routed to the 74 Middlebox applying the NAT function on the media flows and will need 75 to be looped back into the same realm at the Middlebox. Whether this 76 loop back behavior works correctly may depend on the Middlebox 77 implementation. 79 Within the pre-Midcom framework, if intra-realm calls are not 80 identified when reflector methods such as STUN ([STUN]) are used, 81 the Middlebox will need to loop back the flows. As discussed above 82 this requires a specific behavior of the Middlebox. 83 When Middleboxes have symmetric NAT implementations, Media Proxies 84 located outside the realm are used during the call and the media 85 flows will need to traverse the Middleboxes and the external links 86 to the realm. This is a serious waste of bandwidth on the 87 Middleboxes' external links which are often one of the major 88 bottlenecks in a network. 90 A generic model must be found by handling the source of the problem, 91 which is identifying intra-realm calls and then providing 92 appropriate address and port pairs to both parties in call that 93 avoid the media flows leaving the realm. 95 Several potential methods will be discussed in this draft. By 96 issuing this draft, the authors would like to start discussions on 97 solving this problem. The authors recognize that there might be 98 other alternatives to solve the problem. 100 Before proposing solutions to the problem, deployment scenarios need 101 to be considered. 103 Section 4 discusses network deployment cases. 104 Section 5 discusses potential solutions to the problem. 106 2 Conventions used in this document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 110 this document are to be interpreted as described in RFC-2119. 112 3 Terminology Used 114 MB: Middle Box - ref to the terminology used in [FRMWRK] 116 4 Deployment scenarios 118 ++++++++++++++++++++++++++ 119 +++++++++++++++++++ ++++++++++++++++ + y.com + 120 +finance.us.x.com + + + ++++++ +++++++++++ 121 + +++++ + + +----++MB6+ + tg1 + 122 + fg1 +MB2+ +--/+ + ++++++ + is.y.com+ 123 + +++++ + / +The Internet + + +++++++++++ 124 + +++++ +/ + + +++++++++++++++ + 125 + +MB1+ + + + +finance.y.com+ + 126 + fg +++++ + + + + fg + + 127 +++++++++++++++++++ + + + + + 128 | ++++++++++++++++ ++++++++++++++++++++++++++ 129 | / | | 130 | / | | 131 | ++++++++++++++++++ | | 132 | + +MB3+ + | | 133 | + +++++ + | | 134 | +eng.europe.x.com+ | | 135 | + tg1 + | | 136 | ++++++++++++++++++ | | 137 | | | | 138 +++++++++++++ +++++++++++++++++++++++++++++++++++++++++ 139 + x.com + + +MB4+ +MB5+ + 140 + Intranet + + +++++ +++++ + 141 + +-------+ Europe.x.com +++++++++++++++++++++++ 142 +++++++++++++ + + finance.Europe.x.com+ 143 +++++++++++++++++++ + 144 +eng.Europe.x.com++ fg + 145 + ++++++++++++++++++++++++ 146 + tg2 tg3 + + 147 +++++++++++++++++++++++++++++++++++++++++ 149 This section covers different network types, multi-homed networks 150 spanning several sites (with different registered address blocks) as 151 well as standard networks having one interconnect. 153 One assumption in this document is that inside a corporate network, 154 all private addresses are unique within the corporate's address 155 realm. 157 When corporations merge together, NAT will need to be used between 158 the private network segments during network migration. 160 4.1 Call scenarios 162 Since the document tries to provide solutions that will avoid intra- 163 realm calls going through the various MBs. These call scenarios need 164 to be used to check if the solution allows the required 165 functionality. 167 There are several intra-realm call types: 169 a1) Intra-name domain calls on same site or 170 a2) between different sites: 171 tg1.eng.europe.x.com calls tg2.eng.europe.x.com 172 or 173 tg2.eng.europe.x.com calls tg3.eng.europe.x.com 175 b1) Inter-name domain calls within same site (same public address 176 block)or 177 b2) different sites(different public address blocks): 178 tg2.eng.europe.x.com calls fg.finance.europe.x.com 179 or 180 tg1.eng.europe.x.com calls calls fg.finance.europe.x.com 182 Solutions need to be found to avoid the media streams from all 183 these call types going through MBs. 185 Registered address allocation might be important for the problem's 186 solution; the following two cases are considered: 188 Corporate networks could have a single main registered 189 address block provided by a regional (RIPE, ARIN, APNIC, etc) 190 Internet registry, which could be split across several sites. 191 Alternatively several non-contiguous registered blocks could 192 be provided by one or several Internet regional registries. 194 4.2 Application requirements 196 Certain applications may involve an entity handling the 197 application session control and another entity handling media 198 processing (i.e. a decoupled approach), other applications may 199 involve a single entity to host both roles (i.e. a coupled 200 approach). 202 In case the used solution to identify intra-realm calls uses the 203 address or the Fully Qualified Domain Name (FQDN) of the 204 application session control flow host, it may not solve the 205 problem for applications using the decoupled approach mentioned 206 above. 208 5 Potential solutions to the problem 210 5.1 Use domain name comparisons 212 Several applications' signaling protocols (H323, SIP, MEGACO or 213 MGCP) use FQDNs in their messages to identify the originator of the 214 signaling message. 216 When the "signaling proxy" (could be a SIP Proxy, an H323 GK in 217 routed mode or an MGC) receives the signaling messages from both 218 ends it will compare the domain names from the two messages. The 219 comparison will be done by comparing all characters following the 220 first "." in the FQDN. 222 The same could be done for peered relations between application 223 clients (i.e. the signaling does not go through an intermediary). 225 When tg1.eng.europe.x.com calls tg2.eng.europe.x.com, the result of 226 the comparison will show that both parties are in the same realm. 228 However when call types b1) or b2) are established, the comparison 229 will erroneously indicate that the parties to the call are not in 230 the same realm. 232 Accordingly this solution is not applicable to all network 233 deployments. 235 A further problem is that the protocols mentioned above do not 236 always use FQDNs to identify the application end points, which would 237 further limit this approach. 239 5.2 Use realm identifiers 241 A realm identifier could be used within the application signaling 242 messages to link the address provided with a certain realm. 244 Since users will be calling people from several different networks, 245 the realm identifier is required to be globally unique. 247 This might require that a single organization which would manage the 248 realm identifiers within the Internet, in the same way that 249 ICANN/IANA does for the root name servers. 251 This is a serious operational burden. 253 There are some possible alternative ways to provide a unique realm 254 identifier without the previous burden such as : 256 a) Registered network addresses as realm ID. 258 If a corporate has several non-contiguous address blocks, the 259 signaling proxy or the peer (if the signaling is not proxied) will 260 need to compare the network address prefix to all the others used by 261 the same company. If the network address does not match any of the 262 prefixes in the list of its company network addresses, the remote 263 end is assumed to be in another addressing realm. 265 b)In case a corporation (or customer) has a globally unique AS 266 number with a random customer number as a realm ID else the 267 customer's ISP AS number with a 32 bit customer identifier unique 268 within the customers of the ISP as the realm ID. Some corporation 269 have their own globally unique AS number, their realm ID will be 270 their AS number added to a random (or null) customer ID 272 If the customer network spans across several sites, the customer 273 network could be connected to several ISPs depending on the site 274 location. 275 In this case we consider that the customer or corporation will 276 choose one of its ISPs' AS number along with one of the assigned 277 customer Ids to the corporation, as the realm ID. 279 In both a) and b), it will be necessary to inform the customers' 280 application clients of the realm ID. We can assume that there are 281 some out of band mechanisms (configuration or otherwise) to achieve 282 this. 284 The authors acknowledges that there might be better approaches to 285 define a unique realm ID in the Internet without having the 286 operational burden raised above. 288 In addition, in order for this scheme to work, it requires that the 289 calling party sends both private and public addresses, because the 290 calling party is not aware of the called party's realm so a single 291 address/port pair won't help. 293 It is obvious that the realm ID approach requires extension to the 294 application signaling protocols, specifically for the media's 295 session description information carried as part of the protocols, 296 namely: 298 -H.245 for H.323 299 -SDP for SIP, Megaco and MGCP 300 -And other description means for other protocols 302 5.3 Offer/Answer both private and public addresses 304 Discovering intra-realm calls can be looked upon as a way to 305 discover the ideal media session for the call. Using the SDP 306 Offer/Answer model [OA], the initial Offer from the caller can 307 advertise two media sessions one with private IP address/port 308 (called private media session) and the other with public IP 309 address/port (called public media session). The Answer similarly 310 contains two corresponding media session descriptions accepting the 311 Offer. With this transaction, both the caller and the callee knows 312 about the media session representations of each other. In the next 313 step, the caller sends a simple probe message to the private media 314 session of the callee and starts a Timer. If the callee receives a 315 probe message, then it acknowledges it with a response to the 316 private media session address of the caller. This peer-to-peer probe 317 protocol is TBD, but it can be a derivate of any echo-server 318 protocol. 320 If the callee receives a probe message, then it must send an updated 321 Offer to the caller accepting the private media session and 322 rejecting the public media session. If the callee end-point decides 323 to send media after responding to the initial Offer (but before 324 receiving any probe message), it must always use the public IP 325 address/port. Once it has received a probe message and has not yet 326 started sending media, it should do so only after sending out the 327 updated Offer. 329 If the caller has sent out a probe message toward the callee, it 330 should not start sending media before the Timer expires or it 331 receives an updated Offer from the callee. In case the Timer 332 expires, it must send media to the public IP address/port only. 334 There is a possible scenario where the callee located in a different 335 address realm is using a private address that is being used in the 336 realm of the caller. Then the probe packet of the caller, intended 337 to be sent to the private address of the callee, will reach an 338 unintended destination in his own realm. But it would be extremely 339 difficult for this endpoint to hijack the session with a made-up 340 Offer, as it had not received the initial Offer. 342 Other security implications of this scheme is for further study. 344 6 Conclusion 346 The authors believe that there is some potential in the methods 347 discussed in 5.2 and 5.3 as solutions to identify intra-realm calls. 349 The authors invite the IETF community to start tackling the problem 350 and build a standard way to solve the issue. 352 7 References 354 [FRMWRK] Srisuresh, Kuthan, Rosenberg, Molitor, Rayhan, 355 "MIDCOM Architecture & Framework", 356 Internet draft, draft-ietf-midcom-framework-06.txt 358 [STUN] Rosenberg,Weinberger,Huitema,Mahy, 359 "STUN - Simple Traversal of UDP Through NATs", 360 Internet draft, draft-rosenberg-midcom-stun-00.txt 362 [OA] Rosenberg, Schulzrinne, 363 "An Offer/Answer Model with SDP", 364 Internet draft, draft-ietf-mmusic-sdp-offer-answer-01.txt 366 8 Acknowledgments 368 The authors would like to thank the following people for their 369 useful comments and suggestions related to this draft: Francois 370 Audet, Patrick Bradd, Elwyn Davies, Julian Mitchell and Moses Sun. 372 9 Authors' Address 374 Cedric Aoun 375 Nortel Networks 376 33 Quai Paul Doumer 377 92415 Courbevoie Cedex 378 FRANCE 380 Email: cedric.aoun@nortelnetworks.com 382 Sanjoy Sen 383 Nortel Networks 384 2735-C Glenville Drive 385 Richardson, Texas 386 USA 387 Email: sanjoy@nortelnetworks.com 388 10 Intellectual Property Statement 390 The IETF takes no position regarding the validity or scope of any 391 intellectual property or other rights that might be claimed to 392 pertain to the implementation or use of the technology described in 393 this document or the extent to which any license under such rights 394 might or might not be available; neither does it represent that it 395 has made any effort to identify any such rights. Information on the 396 IETF's procedures with respect to rights in standards-track and 397 standards-related documentation can be found in BCP-11. Copies of 398 claims of rights made available for publication and any assurances 399 of licenses to be made available, or the result of an attempt made 400 to obtain a general license or permission for the use of such 401 proprietary rights by implementors or users of this specification 402 can be obtained from the IETF Secretariat. 404 The IETF invites any interested party to bring to its attention any 405 copyrights, patents or patent applications, or other proprietary 406 rights which may cover technology that may be required to practice 407 this standard. Please address the information to the IETF Executive 408 Director. 410 11 Full Copyright Statement 411 Copyright (C) The Internet Society (2000). All Rights Reserved. 413 This document and translations of it may be copied and furnished to 414 others, and derivative works that comment on or otherwise explain it 415 or assist in its implementation may be prepared, copied, published 416 and distributed, in whole or in part, without restriction of any 417 kind, provided that the above copyright notice and this paragraph 418 are included on all such copies and derivative works. However, this 419 document itself may not be modified in any way, such as by removing 420 the copyright notice or references to the Internet Society or other 421 Internet organizations, except as needed for the purpose of 422 developing Internet standards in which case the procedures for 423 copyrights defined in the Internet Standards process must be 424 followed, or as required to translate it into languages other than 425 English. The limited permissions granted above are perpetual and 426 will not be revoked by the Internet Society or its successors or 427 assigns. This document and the information contained 428 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 429 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 430 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 431 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 432 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 433 PARTICULAR PURPOSE."