idnits 2.17.1 draft-ietf-midcom-framework-06.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 is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([REQMTS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 183 has weird spacing: '...ms) are alter...' == Line 189 has weird spacing: '...ress to provi...' == Line 900 has weird spacing: '...llowing timel...' -- 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 (December 17, 2001) is 8137 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) == Missing Reference: 'IPSEC-AH' is mentioned on line 646, but not defined == Missing Reference: 'IPSEC-ESP' is mentioned on line 648, but not defined == Missing Reference: 'RFC2026' is mentioned on line 1569, but not defined == Unused Reference: 'RTSP' is defined on line 1499, but no explicit reference was found in the text == Unused Reference: 'FTP' is defined on line 1502, but no explicit reference was found in the text == Unused Reference: 'IPsec-AH' is defined on line 1517, but no explicit reference was found in the text == Unused Reference: 'IPsec-ESP' is defined on line 1520, but no explicit reference was found in the text == Unused Reference: 'TLS' is defined on line 1523, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (ref. 'SIP') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2326 (ref. 'RTSP') (Obsoleted by RFC 7826) ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. 'NAT-TERM') ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. 'NAT-TRAD') ** Obsolete normative reference: RFC 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 2402 (ref. 'IPsec-AH') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. 'IPsec-ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. 'REQMTS' Summary: 17 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Srisuresh 3 INTERNET-DRAFT Kuokoa Networks 4 Expires as of June 17, 2002 J. Kuthan 5 GMD Fokus 6 J. Rosenberg 7 dynamicsoft 8 A. Molitor 9 Aravox Technologies 10 A. Rayhan 11 Consultant 12 December 17, 2001 14 Middlebox communication architecture and framework 15 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet- Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 There are a variety of intermediate devices in the Internet today 41 that require application intelligence for their operation. 42 Datagrams pertaining to real-time streaming applications such 43 as SIP and H.323 and peer-to-peer applications such as Napster 44 and NetMeeting cannot be identified by merely examining packet 45 headers. Middleboxes implementing Firewall and Network Address 46 Translator services typically embed application intelligence 47 within the device for their operation. The document specifies an 48 architecture and framework in which trusted third parties can 49 be delegated to assist the middleboxes to perform their operation 50 without resorting to embedding application intelligence. Doing 51 this will allow a middlebox to continue to provide the services, 52 while keeping the middlebox application agnostic. A principal 53 objective of this document is to describe the underlying 54 framework of middlebox communication (MIDCOM) to enable complex 55 applications through the middleboxes seamlessly using a trusted 56 third party. This document and a companion document on MIDCOM 57 requirements ([REQMTS]) are created as a precursor to 58 rechartering the MIDCOM working group. 60 1. Introduction 62 Intermediate devices requiring application intelligence are the 63 subject of this document. These devices are referred as 64 middleboxes throughout the document. Many of these devices enforce 65 application specific policy based functions such as packet 66 filtering, VPN (Virtual Private Network) tunneling, Intrusion 67 detection, security and so forth. Network Address Translator 68 service, on the other hand, provides routing transparency across 69 address realms (within IPv4 routing network or across V4 and V6 70 routing realms), independent of applications. Application Level 71 Gateways (ALGs) are used in conjunction with NAT to examine and 72 optionally modify application payload so the end-to-end application 73 behavior remains unchanged for many of the applications traversing 74 NAT middleboxes. There may be other types of services requiring 75 embedding application intelligence in middleboxes for their 76 operation. The discussion scope of this document is however limited 77 to Firewall and NAT services. Nonetheless, the MIDCOM framework 78 is designed to be extensible to support the deployment of new 79 services. 81 Tight coupling of application intelligence with middleboxes makes 82 maintenance of middleboxes hard with the advent of new applications. 83 Built-in application awareness typically requires updates of 84 operating systems with new applications or newer versions of 85 existing applications. Operators requiring support for newer 86 applications will not be able to use third party software/hardware 87 specific to the application and are at the mercy of their 88 middlebox vendor to make the necessary upgrade. Further, embedding 89 intelligence for a large number of application protocols within 90 the same middlebox increases complexity of the middlebox and is 91 likely to be error prone and degrade in performance. 93 This document describes a framework in which application 94 intelligence can be moved from middleboxes into external MIDCOM 95 agents. The premise of the framework is to devise a MIDCOM 96 protocol that is application independent, so the middleboxes 97 can stay focused on services such as firewall and NAT. The 98 framework document includes some explicit and implied 99 requirements for the MIDCOM protocol. However, it must be noted 100 that these requirements are only a subset. A separate requirements 101 document lists the requirements in detail. 103 MIDCOM agents with application intelligence can assist the 104 middleboxes through the MIDCOM protocol in permitting applications 105 such as FTP, SIP and H.323. The communication between a MIDCOM agent 106 and a middlebox will not be noticeable to the end-hosts that take 107 part in the application, unless one of the end-hosts assumes the 108 role of a MIDCOM agent. Discovery of middleboxes or MIDCOM agents in 109 the path of an application instance is outside the scope of this 110 document. Further, any communication amongst middleboxes is also 111 outside the scope of this document. 113 This document describes the framework in which middlebox 114 communication takes place and the various elements that constitute 115 the framework. Section 2 describes the terms used in the document. 116 Section 3 defines the architectural framework of a middlebox for 117 communication with MIDCOM agents. The remaining sections cover the 118 components of the framework, illustration using sample flows and 119 operational considerations with the MIDCOM architecture. Section 4 120 describes the nature of MIDCOM protocol. Section 5 identifies 121 entities that could potentially host the MIDCOM agent function. 122 Section 6 considers the role of Policy server and its function 123 with regard to communicating MIDCOM agent authorization policies. 124 Sections 7 is an illustration of SIP flows using MIDCOM framework 125 in which the MIDCOM agent is co-resident on a SIP proxy server. 126 Section 8 addresses operational considerations in deploying a 127 protocol adhering to the framework described here. Section 9 is 128 an applicability statement, scoping the location of middleboxes. 129 Section 11 outlines security considerations for the middlebox 130 in view of the MIDCOM framework. 132 2. Terminology 134 Below are the definitions for the terms used throughout the 135 document. 137 2.1. Middlebox function/service 139 A middlebox function or a middlebox service is an operation or 140 method performed by a network intermediary that may require 141 application specific intelligence for its operation. Policy based 142 packet filtering (a.k.a. firewall), Network address translation 143 (NAT), Intrusion detection, Load balancing, Policy based tunneling 144 and IPsec security are all examples of a middlebox function (or 145 service). 147 2.2. Middlebox 149 Middlebox is a network intermediate device that implements one or 150 more of the middlebox services. A NAT middlebox is a middlebox 151 implementing NAT service. A firewall middlebox is a middlebox 152 implementing firewall service. 154 Traditional middleboxes embed application intelligence within the 155 device to support specific application traversal. Middleboxes 156 supporting MIDCOM protocol will be able to externalize 157 application intelligence into MIDCOM agents. In reality, some of 158 the middleboxes may continue to embed application intelligence 159 for certain applications and depend on MIDCOM protocol and MIDCOM 160 agents for the support of remaining applications. 162 2.3. Firewall 164 Firewall is a policy based packet filtering middlebox function, 165 typically used for restricting access to/from specific devices and 166 applications. The policies are often termed Access Control 167 Lists (ACLs). 169 2.4. NAT 171 Network Address Translation is a method by which IP addresses are 172 mapped from one address realm to another, providing transparent 173 routing to end-hosts. Transparent routing here refers to modifying 174 end-node addresses en-route and maintaining state for these updates 175 so that when a datagram leaves one realm and enters another, 176 datagrams pertaining to a session are forwarded to the right 177 end-host in either realm. Refer [NAT-TERM] for the definition of 178 Transparent routing, various NAT types and the associated terms 179 in use. Two types of NAT are most common. Basic-NAT, where only an 180 IP address (and the related IP, TCP/UDP checksums) of packets is 181 altered and NAPT (Network Address Port Translation), where both an 182 IP address and a transport layer identifier such as a TCP/UDP port 183 (and the related IP, TCP/UDP checksums) are altered. 185 The term NAT in this document is very similar to the IPv4 NAT 186 described in [NAT-TERM], but is extended beyond IPv4 networks 187 to include the IPv4-v6 NAT-PT described in [NAT-PT]. While the 188 IPv4 NAT [NAT-TERM] translates one IPv4 address into another IPv4 189 address to provide routing between private V4 and external V4 190 address realms, IPv4-v6 NAT-PT [NAT-PT] translates an IPv4 address 191 into an IPv6 address and vice versa to provide routing between a 192 V6 address realm and an external V4 address realm. 194 Unless specified otherwise, NAT in this document is a middlebox 195 function referring to both IPv4 NAT as well as IPv4-v6 NAT-PT. 197 2.5. Proxy 199 A proxy is an intermediate relay agent between clients and servers 200 of an application, relaying application messages between the two. 201 Proxies use special protocol mechanisms to communicate with proxy 202 clients and relay client data to servers and vice versa. A Proxy 203 terminates sessions with both the client and the server, acting as 204 server to the end-host client and as client to the end-host server. 206 Applications such as FTP, SIP and RTSP use a control session to 207 establish data sessions. These control and data sessions can take 208 divergent paths. While a proxy can intercept both the control and 209 data sessions, it might intercept only the control session. This 210 is often the case with real-time streaming applications such as 211 SIP and RTSP. 213 2.6. ALG 215 Application Level Gateways (ALGs) are entities that possess the 216 application specific intelligence and knowledge of an associated 217 middlebox function. An ALG examines application traffic in transit 218 and assists middlebox in carrying out its function. 220 An ALG may be co-resident with a middlebox or reside externally, 221 communicating through a middlebox communication protocol. It 222 interacts with a middlebox to set up state, access control 223 filters, use middlebox state information, modify application 224 specific payload or perform whatever else is necessary to enable 225 the application to run through the middlebox. 227 ALGs are different from proxies. ALGs are not visible to 228 end-hosts, unlike the proxies which are relay agents terminating 229 sessions with both end-hosts. ALGs do not terminate session with 230 either end-host. Instead, ALGs examine and optionally modify 231 application payload content to facilitate the flow of application 232 traffic through a middlebox. ALGs are middlebox centric, in that 233 they assist the middleboxes in carrying out their function. 234 Whereas, the proxies act as focal point for application servers, 235 relaying traffic between application clients and servers. 237 ALGs are similar to Proxies, in that, both ALGs and proxies 238 facilitate Application specific communication between clients 239 and servers. 241 2.7. End-Hosts 243 End-hosts are entities that are party to a networked application 244 instance. End-hosts referred in this document are specifically 245 those terminating Real-time streaming Voice-over-IP 246 applications such as SIP and H.323 and peer-to-peer applications 247 such as Napster and NetMeeting. 249 2.8. MIDCOM Agents 251 MIDCOM agents are entities performing ALG functions, logically 252 external to a middlebox. MIDCOM agents possess a combination of 253 application awareness and knowledge of the middlebox function, 254 which combination enables the agents to facilitate traversal of 255 the middlebox by the application's packets. A MIDCOM agent may 256 interact with one or more middleboxes. 258 Only "In-Path MIDCOM agents" are considered in this document. 259 In-Path MIDCOM agents are agents which are within the path of 260 those datagrams that the agent needs to examine and/or modify 261 in fulfilling its role as a MIDCOM agent. "Within the path" here 262 simply means that the packets in question flow through the node 263 that hosts the agent. The packets may be addressed to the agent 264 node at the IP layer. Alternatively they may not be addressed to 265 the agent node but may be constrained by other factors to flow 266 through it. In fact, it is immaterial to the MIDCOM protocol which 267 of these is the case. Some examples of In-Path MIDCOM agents are 268 application proxies, gateways, or even end-hosts that are party to 269 the application. 271 Agents not resident on nodes that are within the path of their 272 relevant application flows are referred to as "Out-of-Path (OOP) 273 MIDCOM agents" and are out of scope of this document. 275 2.9. Policy Server 277 Policy Server is a management entity that acts in advisory 278 capacity and interfaces with a middlebox to communicate policies 279 concerning authorization of MIDCOM agents gaining access to 280 middlebox resources. A MIDCOM agent may be pre-configured on a 281 middlebox. In case a MIDCOM agent is not pre-configured, the 282 middlebox will consult the Policy Server and obtain the agent 283 profile to validate session setup and authorization of the agent 284 to gain access to middlebox resources. A middlebox and a policy 285 server may communicate further if the policy server's policy 286 changes or if a middlebox needs further information. The policy 287 server may at anytime notify the middlebox to terminate 288 authorization for an agent. 290 The protocol facilitating the communication between a middlebox 291 and Policy Server need not be part of MIDCOM protocol. Section 6 292 in the document addresses the Policy server interface and protocol 293 framework independent of the MIDCOM framework. 295 Application specific policy data and policy interface between an 296 agent or application endpoint and a policy server is out of bounds 297 for this document. The Policy server issues addressed in the 298 document are focused at an aggregate domain level as befitting 299 the middlebox. For example, a SIP MIDCOM agent may choose to query 300 a policy server for the administrative (or corporate) domain to 301 find whether a certain user is allowed to make an outgoing call. 302 This type of application specific policy data, as befitting an end 303 user is out of bounds for the Policy server considered in this 304 document. It is within bounds however for the middlebox policy 305 server to specify the specific end-user applications (or tuples) 306 for which an agent is permitted to be an ALG. 308 2.10. Middlebox Communication (MIDCOM) protocol 310 The protocol between a MIDCOM agent and a middlebox that allows 311 the MIDCOM agent to invoke services of the middlebox and allow 312 the middlebox to delegate application specific processing to 313 the MIDCOM agent. The MIDCOM protocol allows the middlebox to 314 perform its operation with the aid of MIDCOM agents, without 315 resorting to embedding application intelligence. The principal 316 motivation behind architecting this protocol is to enable complex 317 applications through middleboxes seamlessly using a trusted third 318 party, i.e., a MIDCOM agent. 320 This is a protocol yet to be devised. 322 2.11. MIDCOM agent registration 324 MIDCOM agent registration is defined as the process of provisioning 325 agent profile information with the middlebox or a policy server(s). 326 MIDCOM agent registration is often a manual operation performed by 327 an operator rather than the agent itself. 329 MIDCOM agent profile may include agent authorization policy (i.e., 330 session tuples for which the agent is authorized to act as ALG), 331 agent-hosting-entity (e.g., Proxy, Gateway or end-host which hosts 332 the agent), agent accessibility profile (including any host level 333 authentication information) and security profile (for the messages 334 exchanged between the middlebox and the agent). 336 2.12. MIDCOM session 338 MIDCOM session is defined to be a lasting association between a 339 MIDCOM agent and a middlebox. The MIDCOM session is not assumed to 340 imply any specific transport layer protocol. Specifically, this 341 should not be construed as referring to a connection-oriented TCP 342 protocol. 344 2.13. Filter Spec 346 Filter Spec (short for filter specification) is a Packet matching 347 information that identifies a set of packets to be treated a 348 certain way by a middlebox. 350 5-Tuple specification of packets in the case of a firewall and 351 5-tuple specification of a session in the case of a NAT middlebox 352 function are examples of filter Spec. 354 2.14. Action Spec 356 Action Spec (short for Action specification) is a description of 357 the middlebox treatment/service to be applied to a set of packets. 359 NAT Address-BIND (or Port-BIND in the case of NAPT) and firewall 360 permit/deny action are examples of Action Spec. 362 2.15. Ruleset 364 The combination of one or more filter Specs and one or more 365 action Specs. Packets matching the filter Spec(s) are to be 366 treated as specified by the associated action Spec(s). The 367 ruleset may also contain auxiliary attributes such as ruleset 368 type, timeout values, creating agent, etc. 370 Rulesets are communicated through the MIDCOM protocol. 372 3.0 Architectural framework for middleboxes 374 A middlebox may implement one or more of the middlebox functions 375 selectively on multiple interfaces of the device. There can be a 376 variety of MIDCOM agents interfacing with the middlebox to 377 communicate with one or more of the middlebox functions on an 378 interface. As such, the middlebox communication protocol must 379 allow for selective communication between a specific MIDCOM agent 380 and one or more middlebox functions on the interface. The following 381 diagram identifies a possible layering of the service supported 382 by a middlebox and a list of MIDCOM agents that might interact 383 with it. 385 +---------------+ +--------------+ 386 | MIDCOM agent | | MIDCOM agent | 387 | co-resident on| | co-resident | 388 | Proxy Server | | on Appl. GW | 389 +---------------+ +--------------+ 390 ^ ^ 391 | | +--------+ 392 MIDCOM | | | Policy | 393 Protocol | | +-| Server | 394 | | / +--------+ 395 +-------------+ | | / 396 | MIDCOM agent| | | / 397 | co-resident | | | / 398 | on End-hosts|<-+ | | / 399 +-------------+ | | | | 400 v v v v 401 +-------------------------------------------+ 402 | Middlebox Communication |Policy | 403 | Protocol (MIDCOM) Interface |Interface | 404 +----------+--------+-----------+-----------+ 405 Middlebox | | | | | 406 Functions | Firewall | NAT | VPN | Intrusion | 407 | | | tunneling | Detection | 408 +----------+--------+-----------+-----------+ 409 Middlebox | Middlebox function specific Ruleset and | 410 Managed | other attributes | 411 Resources | | 412 +-------------------------------------------+ 414 Figure 1: MIDCOM agents interfacing with a middlebox 416 Firewall ACLs, NAT-BINDs, NAT address-maps and Session-state 417 are a few of the middlebox function specific ruleset. A 418 session state may include middlebox function specific 419 attributes such as timeout values, NAT translation 420 parameters (i.e., NAT-BINDS) and so forth. As Session-state 421 may be shared across middlebox functions, a Session-state 422 may be created by a function, and terminated by a different 423 function. For example, a session-state may be created by the 424 firewall function, but terminated by the NAT function, when a 425 session timer expires. 427 Application specific MIDCOM agents (co-resident on the middlebox 428 or external to the middlebox) would examine the IP datagrams and 429 help identify the application the datagram belongs to and assist 430 the middlebox in performing functions unique to the application 431 and the middlebox service. For example, a MIDCOM agent assisting 432 a NAT middlebox might perform payload translations; whereas a 433 MIDCOM agent assisting a firewall middlebox might request the 434 firewall to permit access to application specific dynamically 435 generated session traffic. 437 4. MIDCOM Protocol 439 The MIDCOM protocol between a MIDCOM agent and a middlebox allows 440 the MIDCOM agent to invoke services of the middlebox and allow 441 the middlebox to delegate application specific processing to the 442 MIDCOM agent. The protocol will allow MIDCOM agents to signal 443 the middleboxes to let complex applications using dynamic port 444 based sessions through them (i.e., middleboxes) seamlessly. 446 It is important to note that an agent and a middlebox can be on 447 the same physical device. In such a case, they may communicate 448 using a MIDCOM protocol message formats, but using a non-IP based 449 transport such as IPC messaging (or) they may communicate using a 450 well-defined API/DLL (or) the application intelligence is fully 451 embedded into the middlebox service (as it is done today in many 452 stateful inspection firewall devices and NAT devices). 454 The MIDCOM protocol will consist of a session setup phase, run-time 455 session phase and a session termination phase. 457 Session setup must be preceded by registration of the MIDCOM agent 458 with either the middlebox or the Policy Server. The MIDCOM agent 459 access and authorization profile may either be pre-configured on the 460 middlebox (or) listed on a Policy Server the middlebox is configured 461 to consult. MIDCOM shall be a client-server protocol, initiated by 462 the agent. 464 A MIDCOM session may be terminated by either of the parties. 465 A MIDCOM session termination may also be triggered by one of 466 (a) the middlebox or the agent going out of service and not 467 being available for further MIDCOM operations, or (b) policy 468 server notifying the middlebox that a particular MIDCOM agent 469 is no longer authorized. 471 The MIDCOM protocol data exchanged during run-time is governed 472 principally by the middlebox services the protocol supports. 474 Firewall and NAT middlebox services are considered in this 475 document. Nonetheless, the MIDCOM framework is designed to 476 be extensible to support deployment of other services as well. 478 5.0. MIDCOM Agents 480 MIDCOM agents are logical entities which may reside physically 481 on nodes external to a middlebox, possessing a combination of 482 application awareness and knowledge of middlebox function. A 483 MIDCOM agent may communicate with one or more middleboxes. The 484 issues of middleboxes discovering agents or vice versa are 485 outside the scope of this document. The focus of the document 486 is the framework in which a MIDCOM agent communicates with a 487 middlebox using MIDCOM protocol, which is yet to be devised. 488 Specifically, the focus is restricted to just the In-Path agents. 490 In-Path MIDCOM agents are MIDCOM agents that are located naturally 491 within the message path of the application(s) they are associated 492 with. Bundled session applications such as H.323, SIP and RTSP 493 which have separate control and data sessions may have their 494 sessions take divergent paths. In those scenarios, In-Path MIDCOM 495 agents are those that find themselves in the control path. 496 In majority of cases, a middlebox will likely require the 497 assistance of a single agent for an application in the control 498 path alone. However, it is possible that a middlebox function 499 or a specific application traversing the middlebox might require 500 the intervention of more than a single MIDCOM agent for the same 501 application, one for each sub-session of the application. 503 Application Proxies and gateways are a good choice for In-Path 504 MIDCOM agents, as these entities, by definition, are in the path 505 of an application between a client and server. In addition to 506 hosting the MIDCOM agent function, these natively in-path 507 application specific entities may also enforce application-specific 508 choices locally, such as dropping messages infected with known 509 viruses, or lacking user authentication. These entities can be 510 interjecting both the control and data sessions. For example, FTP 511 control and Data sessions are interjected by an FTP proxy server. 512 However, proxies may also be interjecting just the control session 513 and not the data sessions, as is the case with real-time streaming 514 applications such as SIP and RTSP. Note, applications may not always 515 traverse a proxy and some applications may not have a proxy server 516 available. 518 SIP proxies and H.323 gatekeepers may be used to host MIDCOM 519 agent function to control middleboxes implementing firewall and 520 NAT functions. The advantage of using in-path entities as opposed 521 to creating an entirely new agent is that the in-path entities 522 already possess application intelligence. You will need to merely 523 enable the use of MIDCOM protocol to be an effective MIDCOM 524 agent. Figure 2 below illustrates a scenario where the in-path 525 MIDCOM agents interface with the middlebox. Let us say, the 526 policy Server has pre-configured the in-path proxies as trusted 527 MIDCOM agents on the middlebox and the packet filter 528 implements 'default-deny' packet filtering policy. Proxies use 529 their application-awareness knowledge to control the firewall 530 function and selectively permit a certain number of voice stream 531 sessions dynamically using MIDCOM protocol. 533 In the illustration below, the proxies and the policy server are 534 shown inside a private domain. The intent however is not to imply 535 that they be inside the private boundary alone. The proxies may 536 also reside external to the domain. The only requirement is that 537 there be a trust relationship with the middlebox. 539 +-----------+ 540 | Middlebox | 541 | Policy | 542 | Server |~~~~~~~~~~~~~| 543 +-----------+ \ 544 \ 545 +--------+ \ 546 | SIP |___ \ 547 ________| Proxy | \ Middlebox \ 548 / +--------+.. | +--------------------+ 549 | : | MIDCOM | | | 550 | RTSP +---------+ :..|........| MIDCOM | POLICY | 551 SIP | ____| RTSP |.....|........| PROTOCOL | INTER- | 552 | / | Proxy |___ | | INTERFACE | FACE | 553 | | +---------+ \ \ |--------------------| 554 | | \ \______| |__SIP 555 | | \________| |__RTSP 556 | | ---| FIREWALL |--->-- 557 +-----------+ /---| |---<-- 558 +-----------+| Data streams // +--------------------+ 559 +-----------+||---------->----// | 560 |end-hosts ||-----------<----- . 561 +-----------+ (RTP, RTSP data, etc.) | 562 . Outside the 563 Within a private domain | private domain 565 Legend: ---- Application data path datagrams 566 ____ Application control path datagrams 567 .... Middlebox Communication Protocol (MIDCOM) 568 ~~~~ MIDCOM Policy Server Interface 569 | 570 . private domain Boundary 571 | 573 Figure 2: In-Path MIDCOM Agents for middlebox Communication 575 5.1. End-hosts as In-Path MIDCOM agents 577 End-hosts are another variation of In-Path MIDCOM agents. Unlike 578 Proxies, End-hosts are direct party to the application and 579 possess all the end-to-end application intelligence there is to 580 it. End-hosts presumably terminate both the control and data 581 paths of an application. Unlike other entities hosting MIDCOM 582 agents, end-host is able to process secure datagrams. However, 583 the problem would be one of manageability - upgrading all the 584 end-hosts running a specific application. 586 6.0. Policy Server functions 588 The functional decomposition of the MIDCOM architecture assumes 589 the existence of a logical entity known as Policy Server, 590 responsible for performing authorization and related provisioning 591 services for the middlebox as depicted in figure 1. The Policy 592 server is a logical entity which may reside physically on a 593 middlebox or on a node external to the middlebox. The protocol 594 employed for communication between the middlebox and the policy 595 server is unrelated to the MIDCOM protocol. 597 Agents are registered with a Policy Server for authorization to 598 invoke services of the middlebox. The policy server maintains a list 599 of agents that are authorized to connect to each of the middleboxes 600 the policy server supports. In the context of the MIDCOM Framework, 601 the policy server does not assist a middlebox in the implementation 602 of the services it provides. 604 The policy server acts in an advisory capacity to a middlebox to 605 authorize or terminate authorization for an agent attempting 606 connectivity to the middlebox. The primary objective of a policy 607 server is to communicate agent authorization information so as to 608 ensure that the security and integrity of a middlebox is not 609 jeopardized. Specifically, the policy server should associate a 610 trust level with each agent attempting to connect to a middlebox 611 and provide a security profile. The policy server should be capable 612 of addressing cases when end-hosts are agents to the middlebox. 614 6.1. Authentication, Integrity and Confidentiality 616 Host authenticity and individual message security are two distinct 617 types of security considerations. Host authentication refers to 618 credentials required of a MIDCOM agent to authenticate itself to 619 the middlebox and vice versa. When authentication fails, the 620 middlebox must not process signaling requests received from the 621 agent that failed authentication. Two-way authentication should be 622 supported. In some cases, the 2-way authentication may be tightly 623 linked to the establishment of keys to protect subsequent traffic. 624 Two-way authentication is often required to prevent various active 625 attacks on the MIDCOM protocol and secure establishment of keying 626 material. 628 Security services such as authentication, data integrity, 629 confidentiality and replay protection may be adapted to secure 630 MIDCOM messages in an untrusted domain. Message authentication is 631 same as data origin authentication and is an affirmation that the 632 sender of the message is who it claims to be. Data integrity 633 refers to the ability to ensure that a message has not been 634 accidentally, maliciously or otherwise altered or destroyed. 635 Confidentiality is encryption of message with a key so that only 636 those in possession of the key can decipher the message content. 637 Lastly, replay protection is a form of sequence integrity so when 638 an intruder plays back a previously recorded sequence of messages, 639 the receiver of the replay messages will simply drop the replay 640 messages into bit-bucket. Certain applications of the MIDCOM 641 protocol might require support for non-repudiation as an option of 642 the data integrity service. Typically, support for non-repudiation 643 is required for billing, service level agreements, payment orders, 644 and receipts for delivery of service. 646 IPsec AH ([IPSEC-AH]) offers data-origin authentication, data 647 integrity and protection from message replay. IPsec ESP 648 ([IPSEC-ESP]) provides data-origin authentication to a lesser 649 degree (same as IPsec AH if the MIDCOM transport protocol turns out 650 to be TCP or UDP), message confidentiality, data integrity and 651 protection from replay. Besides the IPsec based protocols, there 652 are other security options as well. TLS based transport layer 653 security is one option. There are also many application-layer 654 security mechanisms available. Simple Source-address based 655 security is a minimal form of security and should be relied on only 656 in the most trusted environments where those hosts will not be 657 spoofed. 659 MIDCOM message security shall use existing standards, whenever the 660 existing standards satisfy the requirements. Security shall be 661 specified to minimize the impact on sessions that do not use the 662 security option. Security should be designed to avoid introducing 663 and to minimize the impact of denial of service attacks. Some 664 security mechanisms and algorithms require substantial processing 665 or storage, in which case the security protocols should protect 666 themselves as well as against possible flooding attacks that 667 overwhelm the endpoint (i.e., the middlebox or the agent) with 668 such processing. For connection oriented protocols (such as TCP) 669 using security services, the security protocol should detect 670 premature closure or truncation attacks. 672 6.2. Registration and deregistration of MIDCOM agents 674 Prior to allowing MIDCOM agents to invoke services of the 675 middlebox, a registration process must take place. Registration 676 is a different process than establishing a MIDCOM session. The 677 former requires provisioning agent profile information with the 678 middlebox or a policy server(s). Agent registration is often a 679 manual operation performed by an operator rather than the agent 680 itself. Setting up MIDCOM session refers to establishing a 681 MIDCOM transport session and exchanging security credentials 682 between an agent and a middlebox. The transport session uses the 683 registered information for session establishment. 685 Profile of a MIDCOM agent includes agent authorization policy 686 (i.e., session tuples for which the agent is authorized to act as 687 ALG), agent-hosting-entity (e.g., Proxy, Gateway or end-host which 688 hosts the agent), agent accessibility profile (including any host 689 level authentication information) and security profile 690 (i.e., security requirements for messages exchanged between the 691 middlebox and the agent). 693 MIDCOM agent profile may be pre-configured on a middlebox. 694 Subsequent to that, the agent may choose to initiate a MIDCOM 695 session prior to any data traffic. For example, MIDCOM agent 696 authorization policy for a middlebox service may be preconfigured 697 by specifying the agent in conjunction with Filter Spec. In the 698 case of a firewall, for example, the ACL tuple may be altered to 699 reflect the optional Agent presence. The revised ACL may look 700 something like the following. 702 (, , , 703 , , , ) 705 The reader should note that this is an illustrative example and 706 not necessarily the actual definition of an ACL tuple. The formal 707 description of the ACL is yet to be devised. Agent accessibility 708 information should also be provisioned. For a MIDCOM agent, 709 accessibility information includes the IP address, trust level, 710 host authentication parameters and message authentication 711 parameters. Once a session is established between a middlebox 712 and a MIDCOM agent, that session should be usable with multiple 713 instances of the application(s), as appropriate. Note, all of this 714 could be captured in an agent profile for ease of management. 716 The technique described above is necessary for the pre-registration 717 of MIDCOM agents with the middlebox. The middlebox provisioning may 718 remain unchanged, if the middlebox learns of the registered agents 719 through a policy server. In either case, the MIDCOM agent should 720 initiate the session prior to the start of the application. If the 721 agent session is delayed until after the application has started, 722 the agent might be unable to process the control stream to permit 723 the data sessions. When a middlebox notices an incoming MIDCOM 724 session, and the middlebox has no prior profile of the MIDCOM agent, 725 the middlebox will consult its Policy Server for authenticity, 726 authorization and trust guidelines for the session. 728 7.0. MIDCOM Framework Illustration using an In-Path agent 730 In figure 3 below, we consider SIP application (Refer [SIP]) to 731 illustrate the operation of the MIDCOM protocol. Specifically, 732 the application assumes a caller, external to a private domain, 733 initiates the call. The middlebox is assumed to be located at 734 the edge of the private domain. A SIP phone (SIP User Agent 735 Client/Server) inside the private domain is capable of receiving 736 calls from external SIP phones. The caller uses a SIP Proxy 737 node, located external to the private domain, as its outbound 738 proxy. No interior proxy is assumed for the callee. Lastly, the 739 external SIP proxy node is designated to host the MIDCOM agent 740 function. 742 Arrows 1 and 8 in the figure below refer to SIP call setup 743 exchange between the external SIP phone and the SIP proxy. 744 Arrows 4 and 5 refer to SIP call setup exchange between the SIP 745 proxy and the interior SIP phone and are assumed to be 746 traversing the middlebox. Arrows 2, 3, 6 and 7 below between the 747 SIP proxy and the middlebox refer to MIDCOM communication. Na 748 and Nb represent RTP/RTCP media traffic (Refer [RTP]) path in 749 the external network. Nc and Nd represent media traffic inside 750 the private domain. 752 _________ 753 --->| SIP |<-----\ 754 / | Proxy | \ 755 | |_________| | 756 1| |^ ^| 4| 757 | || || | 758 |8 2||3 7||6 |5 759 ______________ | || || | _____________ 760 | |<-/ _v|____|v___ \->| | 761 | External | Na | | Nc | SIP Phone | 762 | SIP phone |>------->| Middlebox |>------>| within | 763 | |<-------<|___________|<------<| Pvt. domain| 764 |____________| Nb Nd |____________| 766 Figure 3: MIDCOM framework illustration with In-Path SIP Proxy 768 As for the SIP application, we make the assumption that the 769 middlebox is pre-configured to accept SIP calls into the 770 private SIP phone. Specifically, this would imply that the 771 middlebox implementing firewall service is pre-configured to 772 permit SIP calls (destination TCP or UDP port number set to 773 5060) into the private phone. Likewise, middlebox implementing 774 NAPT service would have been pre-configured to provide a port 775 binding to permit incoming SIP calls to be redirected to the 776 specific private SIP phone. I.e., the INVITE from the external 777 caller is not made to the private IP address, but to the NAPT 778 external address. 780 The objective of the MIDCOM agent in the following illustration 781 is to merely permit the RTP/RTCP media stream (Refer [RTP]) 782 through the middlebox, when using the MIDCOM protocol architecture 783 outlined in the document. RTP/RTCP media stream, When used in 784 conjunction with SIP will typically result in two independent 785 media sessions - one from the callee to the caller and another 786 from the caller to the callee. These media sessions are UDP based 787 and will use dynamic ports. The dynamic ports used for the media 788 stream are specified in the SDP section (Refer [SDP]) of SIP 789 payload message. The MIDCOM agent will parse the SDP section and 790 use the MIDCOM protocol to (a) open pinholes (i.e., permit RTP/RTCP 791 session tuples) in a middlebox implementing firewall service, or 792 (b) create PORT bindings and appropriately modify the SDP content to 793 permit the RTP/RTCP streams through a middlebox implementing NAT 794 service. The MIDCOM protocol should be sufficiently rich and 795 expressive to support the operations described under the timelines. 796 The examples do not show the timers maintained by the agent to 797 keep the middlebox ruleset from timing out. 799 MIDCOM agent Registration and connectivity between the MIDCOM 800 agent and the middlebox are not shown in the interest of 801 restricting the focus of the MIDCOM transactions to enabling the 802 middlebox to let the media stream through. Policy server is also 803 not shown in the diagram below or on the timelines for the same 804 reason. 806 The following subsections illustrate a typical timeline sequence 807 of operations that transpire with the various elements involved 808 in a SIP telephony application path. Each subsection is devoted 809 to a specific instantiation of a middlebox service - NAPT 810 (refer [NAT-TERM], [NAT-TRAD]), firewall and a combination of 811 both NAPT and firewall are considered. 813 7.1. Timeline flow - Middlebox implementing firewall service 815 In the following example, we will assume a middlebox implementing 816 a firewall service. We further assume that the middlebox is 817 pre-configured to permit SIP calls (destination TCP or UDP port 818 number set to 5060) into the private phone. The following timeline 819 illustrates the operations performed by the MIDCOM agent to permit 820 RTP/RTCP media stream through the middlebox. 822 The INVITE from the caller (external) is assumed to include the 823 SDP payload. You will note that the MIDCOM agent requests the 824 middlebox to permit the Private-to-external RTP/RTCP flows 825 before the INVITE is relayed to the callee. This is because, 826 in SIP, the calling party must be ready to receive the media when 827 it sends the INVITE with a session description. If the called 828 party (private phone) assumes this and sends "early media" before 829 sending the 200 OK response, the firewall will have blocked these 830 packets without this initial MIDCOM signaling from the agent. 832 SIP Phone SIP Proxy Middlebox SIP Phone 833 (External) (MIDCOM agent) (FIREWALL (private) 834 | | Service) | 835 | | | | 836 |----INVITE------>| | | 837 | | | | 838 |<---100Trying----| | | 839 | | | | 840 | Identify end-2-end | | 841 | parameters (from Caller's | | 842 | SDP) for the pri-to-Ext | | 843 | RTP & RTCP sessions. | | 844 | (RTP1, RTCP1) | | 845 | | | | 846 | |+Permit RTP1, RTCP1 +>| | 847 | |<+RTP1, RTCP1 OKed++++| | 848 | | | | 849 | |--------INVITE---------------------->| 850 | | | | 851 | |<-----180 Ringing--------------------| 852 |<--180Ringing----| | | 853 | |<-------200 OK-----------------------| 854 | | | | 855 | Identify end-2-end | | 856 | parameters (from callee's | | 857 | SDP) for the Ext-to-Pri | | 858 | RTP and RTCP sessions. | | 859 | (RTP2, RTCP2) | | 860 | | | | 861 | |+Permit RTP2, RTCP2 +>| | 862 | |<+RTP2, RTCP2 OKed++++| | 863 | | | | 864 |<---200 OK ------| | | 865 |-------ACK------>| | | 866 | |-----------ACK---------------------->| 867 | | | | 868 |<===================RTP/RTCP==========================>| 869 | | | | 870 |-------BYE------>| | | 871 | |--------------------------BYE------->| 872 | | | | 873 | |<----------200 OK--------------------| 874 | | | | 875 | |++Cancel permits to | | 876 | | RTP1, RTCP1, RTP2, | | 877 | | and RTCP2 +++++++++>| | 878 | |<+RTP1, RTP2, RTCP1 & | | 879 | | RTCP2 cancelled ++++| | 880 | | | | 881 |<---200 OK-------| | | 882 | | | | 884 Legend: ++++ MIDCOM control traffic 885 ---- SIP control traffic 886 ==== RTP/RTCP media traffic 888 7.2. Timeline flow - Middlebox implementing NAPT service 890 In the following example, we will assume a middlebox implementing 891 NAPT service. We make the assumption that the middlebox is 892 pre-configured to redirect SIP calls to the specific private SIP 893 phone application. I.e., the INVITE from the external caller is 894 not made to the private IP address, but to the NAPT external 895 address. Let us say, the external phone's IP address is Ea, NAPT 896 middlebox external Address is Ma and the internal SIP phone's 897 private address is Pa. SIP calls to the private SIP phone will 898 arrive as TCP/UDP sessions with destination address and port set 899 to Ma and 5060 respectively. The middlebox will redirect these 900 datagrams to the internal SIP phone. The following timeline 901 will illustrate the operations necessary to be performed by the 902 MIDCOM agent to permit the RTP/RTCP media stream through the 903 middlebox. 905 As with the previous example (section 7.1), INVITE from the 906 caller (external) is assumed to include the SDP payload. 907 You will note that the MIDCOM agent requests middlebox to create 908 NAT session descriptors for the private-to-external RTP/RTCP flows 909 before the INVITE is relayed to the private SIP phone (for the 910 same reasons as described in section 7.1). If the called party 911 (private phone) sends "early media" before sending the 200 OK 912 response, the NAPT middlebox will have blocked these packets 913 without the initial MIDCOM signaling from the agent. Also, note 914 that after the 200 OK is received by the proxy from the private 915 phone, the agent requests the middlebox to allocate NAT session 916 descriptors for the external-to-private RTP2 and RTCP2 flows, such 917 that the ports assigned on the Ma for RTP2 and RTCP2 are 918 contiguous. RTCP stream does not happen with a non-contiguous 919 port. Lastly, you will note that even though each media stream 920 (RTP1, RTCP1, RTP2 and RTCP2) is independent, they are all tied to 921 the single SIP control session while their NAT session descriptors 922 were being created. Finally, when the agent issues a terminate 923 session bundle command for the SIP session, the middlebox is 924 assumed to delete all associated media stream sessions 925 automagically. 927 SIP Phone SIP Proxy Middlebox SIP Phone 928 (External) (MIDCOM agent) (NAPT (Private) 929 IP Addr:Ea | Service) IP addr:Pa 930 | | IP addr:Ma | 931 | | | | 932 |----INVITE------>| | | 933 | | | | 934 |<---100Trying----| | | 935 | | | | 936 | |++ Query Port-BIND | | 937 | | for (Ma, 5060) +++>| | 938 | |<+ Port-BIND reply | | 939 | | for (Ma, 5060) ++++| | 940 | | | | 941 | |++ Query NAT Session | | 942 | | Descriptor for | | 943 | | Ea-to-Pa SIP flow+>| | 944 | |<+ Ea-to-Pa SIP flow | | 945 | | Session Descriptor+| | 946 | | | | 947 | Determine the Internal | | 948 | IP address (Pa) | | 949 | of the callee. | | 950 | | | | 951 | Identify UDP port numbers | | 952 | on Ea (Eport1, Eport1+1) | | 953 | for pri-to-ext RTP & RTCP | | 954 | sessions (RTP1, RTCP1) | | 955 | | | | 956 | |++Create NAT Session | | 957 | | descriptors for | | 958 | | RTP1, RTCP1; Set | | 959 | | parent session to | | 960 | | SIP-ctrl session ++>| | 961 | |<+RTP1, RTCP1 session | | 962 | | descriptors created+| | 963 | | | | 964 | | |..redirected..| 965 | |--------INVITE--------|------------->| 966 | | | | 967 | |<-----180Ringing---------------------| 968 | | | | 969 |<--180Ringing----| | | 970 | |<-------200 OK-----------------------| 971 | | | | 972 | Identify UDP port numbers | | 973 | on Pa (Pport2, Pport2+1) | | 974 | for ext-to-pri RTP & RTCP | | 975 | sessions (RTP2, RTCP2) | | 976 | | | | 977 | |++Create consecutive | | 978 | | port BINDs on Ma | | 979 | | for (Pa, Pport2), | | 980 | | (Pa, Pport2+1) ++++>| | 981 | |<+Port BINDs created++| | 982 | | | | 983 | |++Create NAT Session | | 984 | | descriptors for | | 985 | | RTP2, RTCP2; Set | | 986 | | parent session to | | 987 | | SIP-ctrl session ++>| | 988 | |<+RTP2, RTCP2 session | | 989 | | descriptors created+| | 990 | | | | 991 | Modify the SDP | | 992 | parameters in "200 OK" | | 993 | with NAPT PORT-BIND | | 994 | for the RTP2 port on Ma. | | 995 | | | | 996 |<---200 OK ------| | | 997 | | | | 998 |-------ACK------>| | | 999 | | | | 1000 | Modify IP addresses | | 1001 | appropriately in the SIP | | 1002 | header (e.g., To, from, | | 1003 | Via, contact fields) | | 1004 | | |..redirected..| 1005 | |-----------ACK--------|------------->| 1006 | | | | 1007 | | | | 1008 |<===================RTP/RTCP============|=============>| 1009 | | | | 1010 |-------BYE------>| | | 1011 | | | | 1012 | |----------------------|-----BYE----->| 1013 | | | | 1014 | |<----------200 OK--------------------| 1015 | | | | 1016 | |+++Terminate the SIP | | 1017 | | Session bundle +++>| | 1018 | |<++SIP Session bundle | | 1019 | | terminated ++++++++| | 1020 | | | | 1021 |<---200 OK-------| | | 1022 | | | | 1024 Legend: ++++ MIDCOM control traffic 1025 ---- SIP control traffic 1026 ==== RTP/RTCP media traffic 1028 7.3. Timeline flow - Middlebox implementing NAPT and firewall 1030 In the following example, we will assume a middlebox 1031 implementing a combination of a firewall and a stateful NAPT 1032 service. We make the assumption that the NAPT function is 1033 configured to translate the IP and TCP headers of the initial 1034 SIP session into the private SIP phone and the firewall 1035 function is configured to permit the initial SIP session. 1037 In the following time line, it may be noted that the firewall 1038 description is based on packet fields on the wire (ex: as seen 1039 on the external interface of the middlebox). In order to 1040 ensure correct behavior of the individual services, you will 1041 notice that NAT specific MIDCOM operations precede firewall 1042 specific operations on the MIDCOM agent. This is noticeable in 1043 the time line below when the MIDCOM agent processes the 1044 "200 OK" from the private SIP phone. The MIDCOM agent initially 1045 requests the NAT service on the middlebox to set up port-BIND 1046 and session-descriptors for the media stream in both directions. 1047 Subsequent to that, the MIDCOM agent determines the session 1048 parameters (i.e., the dynamic UDP ports) for the media stream, 1049 as viewed by the external interface and requests the firewall 1050 service on the middlebox to permit those sessions through. 1052 SIP Phone SIP Proxy Middlebox SIP Phone 1053 (External) (MIDCOM agent) (NAPT & (Private) 1054 IP Addr:Ea | firewall IP addr:Pa 1055 | | Services) | 1056 | | IP addr:Ma | 1057 | | | | 1058 |----INVITE------>| | | 1059 | | | | 1060 |<---100Trying----| | | 1061 | | | | 1062 | |++ Query Port-BIND | | 1063 | | for (Ma, 5060) +++>| | 1064 | |<+ Port-BIND reply | | 1065 | | for (Ma, 5060) ++++| | 1066 | | | | 1067 | |++ Query NAT Session | | 1068 | | Descriptor for | | 1069 | | Ea-to-Pa SIP flow+>| | 1070 | |<+ Ea-to-Pa SIP flow | | 1071 | | Session Descriptor+| | 1072 | | | | 1073 | Determine the Internal | | 1074 | IP address (Pa) | | 1075 | of the callee. | | 1076 | | | | 1077 | Identify UDP port numbers | | 1078 | on Ea (Eport1, Eport1+1) | | 1079 | for pri-to-ext RTP & RTCP | | 1080 | sessions (RTP1, RTCP1) | | 1081 | | | | 1082 | |++Create NAT Session | | 1083 | | descriptors for | | 1084 | | RTP1, RTCP1; Set the| | 1085 | | parent session to | | 1086 | | point to SIP flow++>| | 1087 | |<+RTP1, RTCP1 session | | 1088 | | descriptors created+| | 1089 | | | | 1090 | |++Permit RTP1 & RTCP1 | | 1091 | | sessions External to| | 1092 | | middlebox, namely | | 1093 | | Ma to Ea:Eport1, | | 1094 | | Ma to Ea:Eport1+1 | | 1095 | | sessions ++++++++++>| | 1096 | |<+Ma to Ea:Eport1, | | 1097 | | Ma to Ea:Eport1+1 | | 1098 | | sessions OKed ++++++| | 1099 | | | | 1100 | | |..redirected..| 1101 | |--------INVITE--------|------------->| 1102 | | | | 1103 | |<-----180Ringing---------------------| 1104 | | | | 1105 |<--180Ringing----| | | 1106 | |<-------200 OK-----------------------| 1107 | | | | 1108 | Identify UDP port numbers | | 1109 | on Pa (Pport2, Pport2+1) | | 1110 | for ext-to-pri RTP & RTCP | | 1111 | sessions (RTP2, RTCP2) | | 1112 | | | | 1113 | |++Create consecutive | | 1114 | | port BINDs on Ma | | 1115 | | for (Pa, Pport2), | | 1116 | | (Pa, Pport2+1) ++++>| | 1117 | |<+Port BINDs created | | 1118 | | on Ma as (Mport2, | | 1119 | | Mport2+1) ++++++++++| | 1120 | | | | 1121 | |++Create NAT Session | | 1122 | | descriptors for | | 1123 | | RTP2, RTCP2; Set the| | 1124 | | parent session to | | 1125 | | point to SIP flow++>| | 1126 | |<+RTP2, RTCP2 session | | 1127 | | descriptors created+| | 1128 | | | | 1129 | Modify the SDP | | 1130 | parameters in "200 OK" | | 1131 | with NAPT PORT-BIND | | 1132 | for RTP2 port on Ma. | | 1133 | | | | 1134 | |++Permit RTP2 & RTCP2 | | 1135 | | sessions External | | 1136 | | middlebox, namely | | 1137 | | Ea to Ma:Mport2, | | 1138 | | Ea to Ma:Mport2+1 | | 1139 | | sessions ++++++++++>| | 1140 | |<+Ea to Ma:Mport2, | | 1141 | | Ea to Ma:Mport2 | | 1142 | | sessions OKed ++++++| | 1143 | | | | 1144 |<---200 OK ------| | | 1145 | | | | 1146 |-------ACK------>| | | 1147 | | |..redirected..| 1148 | |-----------ACK--------|------------->| 1149 | | | | 1150 | | | | 1151 |<===================RTP/RTCP============|=============>| 1152 | | | | 1153 |-------BYE------>| | | 1154 | | | | 1155 | |----------------------|-----BYE----->| 1156 | | | | 1157 | |<----------200 OK--------------------| 1158 | | | | 1159 | |+++Terminate the SIP | | 1160 | | Session bundle +++>| | 1161 | |<++SIP Session bundle | | 1162 | | terminated ++++++++| | 1163 | | | | 1164 | |++Cancel permits to | | 1165 | | sessions External | | 1166 | | middlebox, namely | | 1167 | | Ma to Ea:Eport1, | | 1168 | | Ma to Ea:Eport1+1 | | 1169 | | Ea to Ma:Mport2, | | 1170 | | Ea to Ma:Mport2+1 | | 1171 | | sessions ++++++++++>| | 1172 | |<+Removed permits to | | 1173 | | sessions listed ++++| | 1174 | | | | 1175 |<---200 OK-------| | | 1176 | | | | 1178 Legend: ++++ MIDCOM control traffic 1179 ---- SIP control traffic 1180 ==== RTP/RTCP media traffic 1182 8.0. Operational considerations 1184 8.1. Multiple MIDCOM sessions between agents and middlebox 1186 A middlebox cannot be assumed to be a simple device 1187 implementing just one middlebox function and no more than a 1188 couple of interfaces. Middleboxes often combine multiple 1189 intermediate functions into the same device and have the 1190 ability to provision individual interfaces of the same device 1191 with different sets of functions and varied provisioning for 1192 the same function across the interfaces. 1194 As such, a MIDCOM agent ought to be able to have a single 1195 MIDCOM session with a middlebox and use the MIDCOM interface 1196 on the middlebox to interface with different services on the 1197 same middlebox. 1199 8.2. Asynchronous notification to MIDCOM agents 1201 Asynchronous notification by the middlebox to a MIDCOM agent 1202 can be useful for events such as Session creation, Session 1203 termination, MIDCOM protocol failure, middlebox function 1204 failure or any other significant event. Independently, ICMP 1205 error codes can also be useful to notify transport layer 1206 failures to the agents. 1208 In addition, periodic notification of various forms of data 1209 such as statistics update would also be a useful function 1210 that would be beneficial to certain types of agents. 1212 8.3. Timers on middlebox considered useful 1214 When supporting MIDCOM protocol, the middlebox is required to 1215 allocate dynamic resources as specified in a ruleset, upon request 1216 from agents. Explicit release of dynamically allocated resources 1217 happens when the application session is ended or when a MIDCOM 1218 agent requests the middlebox to release the resource. 1220 However, the middlebox should be able to recover the dynamically 1221 allocated resources even as the agent that was responsible for 1222 the allocation is not alive. Associating a lifetime for these 1223 dynamic resources and using a timer to track the lifetime can 1224 be a good way to accomplish this. 1226 8.4. Middleboxes supporting multiple services 1228 A middlebox could be implementing a variety of services (e.g. NAT 1229 and firewall) in the same box. Some of these services might have 1230 inter-dependency on shared resources and sequence of operation. 1231 Others may be independent of each other. Generally speaking, 1232 the sequence in which these function operations may be performed 1233 on datagrams is not within the scope of this document. 1235 In the case of a middlebox implementing NAT and firewall 1236 services, it is safe to state that the NAT operation on an 1237 interface will precede firewall on the egress and will follow 1238 firewall on the ingress. Further, firewall access control 1239 lists used by a firewall are assumed to be based on session 1240 parameters as seen on the interface supporting firewall service. 1242 8.5. Signaling and Data traffic 1244 The class of applications the MIDCOM architecture is addressing 1245 focus around applications that have a combination of one or more 1246 signaling and data traffic sessions. The signaling may be done 1247 out-of-band using a dedicated stand-alone session or may be done 1248 in-band within data session. Alternately, signaling may also be 1249 done as a combination of both stand-alone and in-band sessions. 1251 SIP is an example of an application based on distinct signaling 1252 and data sessions. SIP signaling session is used for call setup 1253 between a caller and a callee. MIDCOM agent may be required to 1254 examine/modify SIP payload content to administer the middlebox 1255 so as to let the media streams (RTP/RTCP based) through. MIDCOM 1256 agent is not required to intervene in the data traffic. 1258 Signaling and context specific Header information is sent in-band 1259 within the same data stream for applications such as HTTP embedded 1260 applications, sun-RPC (embedding a variety of NFS apps), Oracle 1261 transactions (embedding oracle SQL+, MS ODBC, Peoplesoft) etc. 1263 H.323 is an example of application that sends signaling in both 1264 dedicated stand-alone session as well as in conjunction with data. 1265 H.225.0 call signaling traffic traverses middleboxes by virtue of 1266 static policy, no MIDCOM control needed. H.225.0 call signaling 1267 also negotiates ports for an H.245 TCP stream. A MIDCOM agent is 1268 required to examine/modify the contents of the H.245 so that H.245 1269 can traverse it. 1271 H.245 traverses the middlebox and also carries Open Logical 1272 Channel information for media data. So the MIDCOM agent is once 1273 again required to examine/modify the payload content needs to 1274 let the media traffic flow. 1276 The MIDCOM architecture takes into consideration, supporting 1277 applications with independent signaling and data sessions as 1278 well as applications that have signaling and data communicated 1279 over the same session. 1281 In the cases where signaling is done on a single stand-alone 1282 session, it is desirable to have a MIDCOM agent interpret the 1283 signaling stream and program the middlebox (that transits the 1284 data stream) so as to let the data traffic through uninterrupted. 1286 9. Applicability Statement 1288 Middleboxes may be stationed in a number of topologies. However, the 1289 signaling framework outlined in this document may be limited to only 1290 those middleboxes that are located in a DMZ (De-Militarized Zone) at 1291 the edge of a private domain, connecting to the Internet. 1292 Specifically, the assumption is that you have a single middlebox 1293 (running NAT or firewall) along the application route. Discovery of 1294 middlebox along application route is outside the scope of this 1295 document. It is conceivable to have middleboxes located between 1296 departments within the same domain or inside service provider's 1297 domain and so forth. However, care must be taken to review each 1298 individual scenario and determine the applicability on a 1299 case-by-case basis. 1301 The applicability may also be illustrated as follows. Real-time and 1302 streaming applications such as Voice-Over-IP and peer-to-peer 1303 applications such as Napster and Netmeeting require administering 1304 firewall and NAT middleboxes to let their media streams reach hosts 1305 inside a private domain. The requirements are in the form of 1306 establishing a "pin-hole" to permit a TCP/UDP session (the port 1307 parameters of which are dynamically determined) through a firewall 1308 or retain an address/port bind in the NAT device to permit 1309 sessions to a port. These requirements are met by current 1310 generation middleboxes using adhoc methods, such as embedding 1311 application intelligence within a middlebox to identify the dynamic 1312 session parameters and administering the middlebox internally as 1313 appropriate. The objective of the MIDCOM architecture is to create 1314 a unified, standard way to exercise this functionality, currently 1315 existing in an ad-hoc fashion in some of the middleboxes. 1317 By adopting MIDCOM architecture, middleboxes will be able to 1318 support newer applications they have not been able to support thus 1319 far. MIDCOM architecture does not and must not, in anyway, change 1320 the fundamental characteristic of the services supported on the 1321 middlebox. 1323 Typically, organizations shield a majority of their corporate 1324 resources (such as end-hosts) from visibility to the external 1325 network by the use of a De-Militarized Zone (DMZ) at the domain 1326 edge. Only a portion of these hosts are allowed to be accessed by 1327 the external world. The remaining hosts and their names are unique 1328 to the private domain. Hosts visible to the external world and the 1329 authoritative name server that maps their names to network 1330 addresses are often configured within a DMZ (De-Militarized Zone) 1331 in front of a firewall. Hosts and middleboxes within DMZ are 1332 referred to as DMZ nodes. 1334 Figure 4 below illustrates configuration of a private domain with 1335 a DMZ at its edge. Actual configurations may vary. Internal hosts 1336 are accessed only by users inside the domain. Middleboxes, 1337 located in the DMZ may be accessed by agents inside or outside 1338 the domain. 1340 \ | / 1341 +-----------------------+ 1342 |Service Provider Router| 1343 +-----------------------+ 1344 WAN | 1345 Stub A .........|\|.... 1346 | 1347 +---------------+ 1348 | NAT middlebox | 1349 +---------------+ 1350 | 1351 | DMZ - Network 1352 ------------------------------------------------------------ 1353 | | | | | 1354 +--+ +--+ +--+ +--+ +-----------+ 1355 |__| |__| |__| |__| | Firewall | 1356 /____\ /____\ /____\ /____\ | middlebox | 1357 DMZ-Host1 DMZ-Host2 ... DMZ-Name DMZ-Web +-----------+ 1358 Server Server etc. | 1359 | 1360 Internal Hosts (inside the private domain) | 1361 ------------------------------------------------------------ 1362 | | | | 1363 +--+ +--+ +--+ +--+ 1364 |__| |__| |__| |__| 1365 /____\ /____\ /____\ /____\ 1366 Int-Host1 Int-Host2 ..... Int-Hostn Int-Name Server 1368 Figure 4: DMZ network configuration of a private domain. 1370 10. Acknowledgements 1372 The authors wish to thank Christian Huitema, Joon Maeng, Jon 1373 Peterson, Mike Fisk, Matt Holdrege, Melinda Shore, Paul Sijben, 1374 Philip Mart, Scott Brim and Richard Swale for their valuable 1375 critique, advice and input on an earlier rough version of this 1376 document. The authors owe special thanks to Eliot Lear for 1377 kick-starting the e-mail discussion on use-case scenarios with a 1378 SIP application flow diagram through a middlebox. Much thanks to 1379 Bob Penfield, Cedric Aoun, Christopher Martin, Eric Fleischman, 1380 George Michaelson, Wanqun Bao and others in the MIDCOM work group 1381 for their very detailed feedback on a variety of topics and 1382 adding clarity to the discussion. Last, but not the least, the 1383 authors owe much thanks to Mark Duffy, Scott Brim, Melinda Shore 1384 and others for their help with terminology definition and 1385 discussing the embedded requirements within the framework 1386 document. 1388 11. Security Considerations 1390 Discussed below are security consideration in accessing a 1391 middlebox. Without MIDCOM protocol support, the premise of a 1392 middlebox operation fundamentally requires the data to be in the 1393 clear as the middlebox needs the ability to inspect and/or modify 1394 packet headers and payload. This compromises the confidentiality 1395 requirement in some environments. Further, Updating transport 1396 headers and rewriting application payload data in some cases by 1397 NAT prevents the use of integrity protection on some data streams 1398 traversing NAT middleboxes. Clearly, this can pose a significant 1399 security threat to the application in an untrusted transport 1400 domain. 1402 The MIDCOM protocol framework removes the need for a middlebox to 1403 inspect or manipulate transport payload. This allows applications 1404 to better protect themselves end-to-end with the aid of a trusted 1405 MIDCOM agent. This is especially the case when the agent is 1406 resident on the end-host. When an agent has the same end-to-end 1407 ability as the end-host to interpret encrypted and integrity 1408 protected data, data transiting a middlebox can be encrypted and 1409 integrity protected. The MIDCOM agent will still be able to 1410 interpret the data and simply notify the middlebox to open holes, 1411 install NAT table entries, etc. Note, however, the MIDCOM 1412 framework does not help with the problem of NAT breaking IPsec 1413 since in this case the middlebox still modifies IP and transport 1414 headers. 1416 Security between a MIDCOM agent and a middlebox has a number of 1417 components. Authorization, authentication, integrity and 1418 confidentiality. Authorization refers to whether a particular 1419 agent is authorized to signal middlebox with requests for one or 1420 more applications adhering to a certain policy profile. Failing the 1421 authorization process might indicate resource theft attempt or 1422 failure due to administrative and/or credential deficiencies. In 1423 either case, the middlebox should take the proper measures to 1424 audit/log such attempts and consult its designated policy server 1425 for the required action if the middlebox is configured with one. 1426 Alternatively, the middlebox may resort to a default service deny 1427 policy when a MIDCOM agent fails to prompt the required 1428 credentials. Section 6 discusses the middlebox-policy server 1429 interactions in view of policy decisions. 1431 Authentication refers to confirming the identity of originator 1432 for all datagrams received from the originator. Lack of strong 1433 credentials for authentication of MIDCOM messages between an agent 1434 and a middlebox can seriously jeopardize the fundamental service 1435 rendered by the middlebox. A consequence of not authenticating an 1436 agent would be that an attacker could spoof the identity of a 1437 "legitimate" agent and open holes in the firewall. Another would 1438 be that it could otherwise manipulate state on a middlebox, 1439 creating a denial-of-service attack by closing needed pinholes or 1440 filling up a NAT table. A consequence of not authenticating the 1441 middlebox to an agent is that an attacker could pose as a 1442 middlebox and respond to NAT requests in a manner that would divert 1443 data to the attacker. Failing to submit the required/valid 1444 credentials once challenged may indicate a replay attack and in 1445 which case a proper action is required by the middlebox such as 1446 auditing, logging, consulting its designated policy server to 1447 reflect such failure. A consequence of not protecting the 1448 middlebox against replay attacks would be that a specific 1449 pinhole may be reopened or closed by an attacker at will, thereby 1450 bombarding end hosts with unwarranted data or causing denial of 1451 service. 1453 Integrity is required to ensure that a MIDCOM message has not been 1454 accidentally or maliciously altered or destroyed. Result of a lack 1455 of data integrity enforcement in an untrusted environment could be 1456 that an imposter will alter the messages sent by an agent and 1457 bring the middlebox to a halt or cause a denial of service for the 1458 application the agent is attempting to enable. 1460 Confidentiality of MIDCOM messages ensure that the signaling data 1461 is accessible only to the authorized entities. When a middlebox 1462 agent is deployed in an untrusted environment, lack of 1463 confidentiality will allow an intruder to perform traffic flow 1464 analysis and snoop the middlebox. The intruder could cannibalize 1465 a lesser secure MIDCOM session and destroy or compromise the 1466 middlebox resources he uncovered on other sessions. Needless to 1467 say, the least secure MIDCOM session will become the achilles 1468 heel and make the middlebox vulnerable to security attacks. 1470 Lastly, there can be security vulnerability to the applications 1471 traversing a middlebox when a resource on a middlebox is controlled 1472 by multiple external agents. A middlebox service may be disrupted 1473 due to conflicting directives from multiple agents associated with 1474 different middlebox functions but applied to the same application 1475 session. Care must be taken in the protocol design to ensure that 1476 agents for one function do not abruptly step over resources impacting 1477 a different function. Alternately, the severity of such 1478 manifestations could be lessened when a single MIDCOM agent is 1479 responsible for supporting all the middlebox services for an 1480 application due to the reduced complexity and synchronization effort 1481 in managing the middlebox resources. 1483 REFERENCES 1485 [SIP] Handley, M., H. Schulzrinne, E. Schooler, and 1486 J. Rosenberg, "SIP: Session Initiation Protocol", 1487 RFC 2543, IETF, March 1999. 1489 [SDP] Handley, M., and Jacobson, V., "SDP: session 1490 description protocol", RFC 2327, IETF, April 1998. 1492 [H.323] ITU-T Recommendation H.323. "Packet-based Multimedia 1493 Communications Systems," 1998. 1495 [RTP] Schulzrinne, H., S. Casner, R. Frederick, and V. Jacobson, 1496 "RTP: A Transport Protocol for Real-Time Applications", 1497 RFC 1889, IETF, January 1996. 1499 [RTSP] Schulzrinne, H., A. Rao, R. Lanphier: "Real Time 1500 Streaming Protocol", RFC 2326, IETF, April 1998. 1502 [FTP] J. Postel, J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", 1503 RFC 959 1505 [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address 1506 Translator (NAT) Terminology and Considerations", 1507 RFC 2663, August 1999. 1509 [NAT-TRAD] Srisuresh, P. and Egevang, K., "Traditional IP Network 1510 Address Translator (Traditional NAT)", RFC 3022, 1511 January 2001. 1513 [NAT-PT] Tsirtsis, G. and Srisuresh, P., "Network Address 1514 Translation - Protocol Translation (NAT-PT)", 1515 RFC 2766, February 2000. 1517 [IPsec-AH] Kent, S., and R. Atkinson, "IP Authentication 1518 Header", RFC 2402, November 1998. 1520 [IPsec-ESP] Kent, S., and R. Atkinson, "IP Encapsulating 1521 Security Payload (ESP)", RFC 2406, November 1998. 1523 [TLS] Dierks, T., and Allen, C., "The TLS Protocol 1524 Version 1.0", RFC 2246, January 1999. 1526 [REQMTS] Brim, S. et al., "Middlebox Communication (MIDCOM) 1527 Protocol Requirements", available as an internet draft 1528 , Work in 1529 progress. 1531 Authors' Addresses 1533 Pyda Srisuresh 1534 Kuokoa Networks, Inc. 1535 2901 Tasman Dr., Suite 202 1536 Santa Clara, CA 95054 1537 U.S.A. 1538 EMail: srisuresh@yahoo.com 1540 Jiri Kuthan 1541 GMD Fokus 1542 Kaiserin-Augusta-Allee 31 1543 D-10589 Berlin, Germany 1544 E-mail: kuthan@fokus.gmd.de 1546 Jonathan Rosenberg 1547 dynamicsoft 1548 72 Eagle Rock Avenue 1549 First Floor 1550 East Hanover, NJ 07936 1551 U.S.A. 1552 email: jdrosen@dynamicsoft.com 1554 Andrew Molitor 1555 Aravox technologies 1556 4201 Lexington Avenue North, Suite 1105 1557 Arden Hills, MN 55126 1558 U.S.A. 1559 voice: (651) 256-2700 1560 email: amolitor@visi.com 1562 Abdallah Rayhan 1563 P.O. Box 3511 Stn C 1564 Ottawa, ON, Canada K1Y 4H7 1565 eMail: ar_rayhan@yahoo.ca 1567 Copyright 1569 The following copyright notice is copied from RFC 2026 [RFC2026] 1570 Section 10.4, and describes the applicable copyright for this 1571 document. 1573 Copyright (C) The Internet Society October 1, 2001. All Rights 1574 Reserved. 1576 This document and translations of it may be copied and furnished to 1577 others, and derivative works that comment on or otherwise explain 1578 it or assist in its implementation may be prepared, copied, 1579 published and distributed, in whole or in part, without restriction 1580 of any kind, provided that the above copyright notice and this 1581 paragraph are included on all such copies and derivative works. 1582 However, this document itself may not be modified in any way, such 1583 as by removing the copyright notice or references to the Internet 1584 Society or other Internet organizations, except as needed for the 1585 purpose of developing Internet standards in which case the procedures 1586 for copyrights defined in the Internet Standards process must be 1587 followed, or as required to translate it into languages other than 1588 English. 1590 The limited permissions granted above are perpetual and will not be 1591 revoked by the Internet Society or its successors or assignees. 1593 This document and the information contained herein is provided on 1594 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1595 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1596 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1597 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1598 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.