idnits 2.17.1 draft-shore-midcom-apps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 392 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([Srisuresh]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (May 2001) is 8380 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Carpenter' -- Possible downref: Non-RFC (?) normative reference: ref. 'Lear' -- Possible downref: Non-RFC (?) normative reference: ref. 'Srisuresh' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Melinda Shore 3 Cisco Systems 4 May 2001 6 Application Considerations for Midcom Middleboxes 7 9 Status Of This Memo 11 This document is an Internet-Draft and is in full con- 12 formance with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet 15 Engineering Task Force (IETF), its areas, and its work- 16 ing groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum 20 of six months and may be updated, replaced, or obso- 21 leted by other documents at any time. It is inappro- 22 priate to use Internet-Drafts as reference material or 23 to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be 29 accessed at http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2001). All Rights 34 Reserved. 36 Abstract 38 As an architecture is evolving around an interface 39 between middleboxes in the transport plane [Srisuresh] 40 and the applications which must traverse them, we need 41 to document the implications for applications. This 42 documentation is intended both to provide guidance for 43 application designers and to help network architects 44 come to a better understanding of sources of complexity 45 in our networks. 47 1. Introduction 49 The IP protocol suite was originally designed around 50 the notion that intelligence would be placed in the 51 endpoints and the applications running on those end- 52 points, and that the actions of the network itself 53 would be largely limited to routing and forwarding of 54 packets. However, over time and for a variety of rea- 55 sons (security, resource management, accounting, pol- 56 icy, etc) a number of different types of network inter- 57 mediaries have evolved, putting application involvement 58 into the network either explicitly (proxies, stateful 59 inspection firewalls) or implicitly through failure 60 (middleboxes which prevent some applications from func- 61 tioning correctly, such as NATs). [Carpenter] provides 62 an excellent overview of this evolution. 64 One response to the problem of middleboxes in the net- 65 work quietly interfering with applications has been to 66 make the middleboxes explicitly visible to them [mid- 67 com]. Applications controlling middleboxes in the 68 transport layer, such as firewalls and NATs, violates 69 the end-to-end principle as well as the separation of 70 network layers and therefore introduces yet more com- 71 plexity into an already increasingly complex network. 72 Understanding why this is the case and anticipating 73 some of the issues emanating from layer violation can 74 help network designers build their networks to minimize 75 complexity and help application and application proto- 76 col designers be more sensitive to the consequences of 77 middlebox interactions. This document is not intended 78 to present either protocol requirements or an architec- 79 tural framework. 81 2. Terminology 83 ASP Application Service Provider 85 ISP Internet Service Provider 87 3. ASPs and ISPs 89 Business arrangements built around network services are 90 coming to be layered in much the same manner that net- 91 work protocols themselves are layered. It is increas- 92 ingly the case that value-added services are being sold 93 and managed independently of network connectivity 94 itself so that, for example, one might contract for 95 voice or content distribution services with a company 96 which then contracts for bandwidth with yet another 97 company or companies. It is also not uncommon in orga- 98 nizations which deliver both connectivity and services 99 to have them delivered by distinct lines of business 100 with separate administrative and financial structures, 101 effectively operating as separate companies. These 102 arrangements may or may not be independent of "last 103 mile" connectivity. 105 In situations in which packet services and connectivity 106 are being managed by organizations other than those 107 which manage application services, it is possible that 108 middleboxes being operated in the network layer are 109 administratively inaccessible to application service 110 providers. This may be particularly problematic when 111 there is an assumption that the application has access 112 to the middlebox's authentication and authorization 113 infrastructures (or vice versa). 115 4. Third-party Session Mediation 117 The notion of applying external control to firewalls 118 and NATs originally came up within the IETF in the con- 119 text of IP telephony applications. In both enterprise 120 and service provider deployments of these applications 121 (PBX systems would be one example of the former, toll 122 bypass of the latter) it is typically the case that 123 some sort of call control server is used to mediate 124 call signaling. This mediation can consist of call 125 admission control, resource reservation, call routing, 126 billing and settlement, etc. Examples of call control 127 servers include SIP proxy servers and H.323 gatekeep- 128 ers. 130 Because this sort of administrative arrangement is 131 independent of network topology, there are clearly sev- 132 eral implications for interaction with network-layer 133 middleboxes. One obvious consideration is the manage- 134 ment of credentials for authentication and authoriza- 135 tion. A call control server may be able to establish a 136 trust relationship with a network-layer middlebox, but 137 it may well be (indeed, may usually be) that it will be 138 asking to open pinholes for direct communication 139 between calling and called parties rather than for com- 140 munication in which it is a party itself. 142 Another consideration is determining the location of 143 services. Service providers may not wish to expose the 144 topology of their network to external individuals or 145 businesses, and this would include preferring not to 146 reveal the location of firewalls and security gateways 147 (see below). 149 5. Receiving Incoming Sessions 151 Traditionally firewalls are configured to be more per- 152 missive of traffic exiting the protected network than 153 of traffic entering the protected network. In fact, in 154 many configurations a firewall will allow any connec- 155 tion initiated by a protected host but will by default 156 filter connections initiated from outside the network. 158 NAT also presents difficulties for hosts wishing to 159 receive incoming calls. It is overwhelmingly the 160 case that NATted endpoints do not have routable-to 161 addresses, and determining the address at which they 162 make a public appearance is frequently difficult, if 163 not impossible. While some NATs will forward all 164 incoming traffic (or all incoming traffic for a given 165 protocol) to a configured endpoint, this cannot allow 166 multiple NATted endpoints behind the same NAT to 167 receive incoming connections in the general case. 169 There may be several approaches to solving this prob- 170 lem. One would be for an application which expects to 171 receive incoming calls to 1) request a pinhole in a 172 firewall, and 2) request a NAT table mapping and a 173 directory update in anticipation of being contacted. 174 This approach can work, but it makes some assumptions 175 about directory services which may not be true (see 176 below) and is highly wasteful of resources on the mid- 177 dlebox. 179 An approach that scales better would be to have a proxy 180 server or call control server (or even a directory 181 server) available at a routable-to address, which would 182 mean that there would have to be a mechanism for 183 resolving from the address belonging to the called 184 party or server to the address of the proxy server or 185 call control server. This, in turn, implies the exis- 186 tence of an appropriate directory service. Some direc- 187 tory services, such as DNS, may assume a relatively 188 static underlying database and may not be able to func- 189 tion well in the presence of highly dynamic 190 name/address mappings, such an externally controlled 191 NAT may provide. Particular concerns would be speed of 192 update to the database itself, the security of that 193 database, and the speed of propagation of database 194 changes. 196 6. Separation of Signaling and Data Paths 198 In commercial packet multimedia architectures is is 199 commonly the case that call signaling is mediated by 200 call control servers (H.323 gatekeepers, SIP proxy 201 servers) but that media flow directly between end- 202 points. This results in a trapezoidal architecture: 204 signaling 205 CM ------------------------ CM 206 / \ 207 / \ 208 / media \ 209 EP ------------------------------- EP 211 (where "CM" is a call manager and "EP" is a call end- 212 point). There may be firewalls between call managers: 214 CM ---------- FW ---------- CM 215 / \ 216 / \ 217 / \ 218 EP ------------------------------- EP 220 or between endpoints: 222 CM ------------------------ CM 223 / \ 224 / \ 225 / \ 226 EP -------------- FW ------------- EP 228 or between both: 230 CM ---------- FW ---------- CM 231 / \ 232 / \ 233 / \ 234 EP -------------- FW ------------- EP 236 (note that there may also be firewalls between end- 237 points and call managers). 239 There are several concerns here. The first is that a 240 call control server that is in communication with a 241 firewall or NAT in order to permit transit of its own 242 signaling messages may not be aware that there is a 243 firewall or NAT in the media path. A particularly dif- 244 ficult problem, however, is that of route determina- 245 tion: that call control server may have to select from 246 among multiple middleboxes, and for it to know which 247 middlebox needs to be contacted it must have knowledge 248 of transport and/or application network topology and 249 routing policy. Alternatively it could contact all 250 known middleboxes and request a pinhole or NAT mapping, 251 but that is clearly wasteful of resources and can 252 introduce unnecessary gaps in the network perimeter. 254 7. Location and Discovery 256 Application failures caused by inability to traverse a 257 middlebox are most often diagnosed by a deficiency of 258 diagnostic information - they fail quietly, with error 259 indications usually being limited to timeouts or trans- 260 port protocol handshake failures. Firewalls are almost 261 always configured to drop packets without returning 262 ICMP unreachable messages, and ICMP unreachable code 13 263 (prohibited access) messages are rarely, if ever, used. 264 There is currently no mechanism available for applica- 265 tions to discover reliably that a packet filtering 266 middlebox is dropping their packets. 268 It must be noted that even if there were a general 269 mechanism for discovering middleboxes, network adminis- 270 trators tend to prefer not to expose network topology 271 to outsiders (or sometimes even insiders). And it must 272 be further noted that relying on knowledge of network 273 topology introduces new failure modes into applica- 274 tions. 276 Application designers should be aware that discovery 277 can expose them to attackers fraudulently representing 278 themselves as middleboxes and diverting traffic and 279 that a discovered middlebox should authenticate itself 280 to the middle box controller or agent. 282 Eliot Lear has published an internet draft [Lear] 283 describing the requirements for middlebox discovery. 285 8. Performance 287 Among the advantages of externalizing application logic 288 from a transport-layer middlebox is that it removes a 289 processing load as well as removing the packet/stream 290 reassembly latency imposed by stateful inspection. 291 There can be one area of performance impact, however, 292 and that is connection establishment. In addition to 293 introducing at least one additional round trip between 294 the middlebox and the application controlling it, there 295 may be other operations required, such as discovery (if 296 it hasn't already occured), authentication and policy 297 consultation for authorization, etc. The effect will 298 likely be negligible for most applications but may be 299 of concern for voice applications, etc. 301 9. Security Considerations 303 One of the foremost considerations must be whether or 304 not a given agent is authorized to execute given opera- 305 tions on a particular middlebox. The components of 306 that authorization decision include a policy infras- 307 tructure, an authentication infrastructure, and mecha- 308 nisms to provide identity authentication and source 309 authentication. Source authentication is needed in 310 order to prevent the spoofing of authorized control 311 agents. Any middlebox control facility will need 312 access to an authentication infrastructure, if one 313 exists, or will need to pre-share keys, a solution with 314 clear scaling limitations. 316 Middlebox control is predicated on the notion that an 317 application can find a middlebox to control. This 318 implies exposing elements of network topology to an 319 application, and many network administrators would 320 prefer not to do that. A middlebox discovery process 321 could potentially be subverted for the purposes of 322 locating, say, a firewall in order to attack it. Of 323 particular concern would be exposing network topology 324 to applications outside the network perimeter. 326 Application designers should also be aware that it 327 could be possible for an attacker to 1) subvert a dis- 328 covery process to represent him/herself as a middlebox, 329 or 2) spoof registration and control responses as com- 330 ing from an existing middlebox in order to divert traf- 331 fic. The authentication infrastructure must provide 332 for mutual authentication, which may mean the acquisi- 333 tion and installation of certificates from a certifi- 334 cate authority. Self-signed certificates are probably 335 undesirable in this case. 337 References 339 [Carpenter] Carpenter, Brian and Scott Brim, "Middleboxes: 340 taxonomy and issues," April 2001. Work in 341 progress. 343 [Lear] Lear, Eliot, "Requirements for Discovering Mid- 344 dleboxes," April 2001. Work in progress. 346 [midcom] "Middlebox Communication (midcom)" working group 347 charter, http://www.ietf.org/html.charters/mid- 348 com-charter.html. 350 [Srisuresh] Srisuresh, P. et al., "Middlebox Communication 351 Architecture and framework," May 2001. Work in 352 progress. 354 10. Author's Address 356 Melinda Shore 357 Cisco Systems 358 809 Hayts Road 359 Ithaca, NY 14850 360 USA 361 Email: mshore@cisco.com 362 Phone: +1 607 272 7512 364 11. Intellectual Property Statement 366 The IETF takes no position regarding the validity or 367 scope of any intellectual property or other rights that 368 might be claimed to pertain to the implementation or 369 use of the technology described in this document or the 370 extent to which any license under such rights might or 371 might not be available; neither does it represent that 372 it has made any effort to identify any such rights. 373 Information on the IETF's procedures with respect to 374 rights in standards-track and standards-related docu- 375 mentation can be found in BCP-11. Copies of claims of 376 rights made available for publication and any assur- 377 ances of licenses to be made available, or the result 378 of an attempt made to obtain a general license or per- 379 mission for the use of such proprietary rights by 380 implementors or users of this specification can be 381 obtained from the IETF Secretariat. 383 The IETF invites any interested party to bring to its 384 attention any copyrights, patents or patent applica- 385 tions, or other proprietary rights which may cover 386 technology that may be required to practice this stan- 387 dard. Please address the information to the IETF Exec- 388 utive Director. 390 12. Full Copyright Statement 392 Copyright (C) The Internet Society (2000). All Rights 393 Reserved. 395 This document and translations of it may be copied and 396 furnished to others, and derivative works that comment 397 on or otherwise explain it or assist in its implementa- 398 tion may be prepared, copied, published and dis- 399 tributed, in whole or in part, without restriction of 400 any kind, provided that the above copyright notice and 401 this paragraph are included on all such copies and 402 derivative works. However, this document itself may 403 not be modified in any way, such as by removing the 404 copyright notice or references to the Internet Society 405 or other Internet organizations, except as needed for 406 the purpose of developing Internet standards in which 407 case the procedures for copyrights defined in the 408 Internet Standards process must be followed, or as 409 required to translate it into languages other than 410 English. The limited permissions granted above are 411 perpetual and will not be revoked by the Internet Soci- 412 ety or its successors or assigns. This document and 413 the information contained herein is provided on an "AS 414 IS" basis and THE INTERNET SOCIETY AND THE INTERNET 415 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 416 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 417 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 418 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 419 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 421 13. Expiration Date 423 This memo is filed as 424 and expires November, 2001.